5인 팀이 10배로 출시하는 법: eSimphony의 AI 네이티브 엔지니어링

eSimphony는 다섯 명의 엔지니어링 팀이 만듭니다. 이 제품은 150개국 이상을 커버하고, 네이티브 iOS와 Android 앱을 배포하며, 다지역 통신사 연동 스택을 운영하고, 다섯 개 언어를 전 구간에서 지원하며, 매주 제품 변경을 출시합니다. 우리는 천 명짜리 통신사가 아닙니다. 의도적인 레버리지로 움직이는 작은 팀입니다.

그 레버리지는 지난 18개월 동안 몸에 익힌 특정한 엔지니어링 방식에서 나옵니다. 우리는 이를 AI 네이티브 개발이라고 부릅니다. 실제로 어떤 모습인지 보여 드리겠습니다.

팀의 형태

엔지니어 다섯 명. 프로덕트 디자이너 한 명. 아직도 제품 명세 일부를 직접 쓰는 CEO 한 명. 공식 프로덕트 매니저는 없습니다. 명세는 CEO와 Moza의 초안 보조, 그리고 엔지니어링 판단에서 나옵니다. 전담 QA 팀도 없습니다. 테스트는 빌드 루프의 일부입니다. 별도의 DevOps도 없습니다. 인프라는 그 기능을 출시하는 사람이 소유합니다.

자랑이 아닙니다. 제약입니다. 이 정도 팀 규모로 eSimphony 수준의 제품을 내놓는 유일한 방법은 엔지니어 한 명의 산출을 곱하는 것입니다. AI가 우리가 기댄 곱셈기입니다.

다섯 단계 워크플로

eSimphony의 모든 변경은 카피 수정이든 새 통신사 연동이든 같은 다섯 단계를 거칩니다. 각 단계는 AI의 도움을 받고, 각 단계에는 사람이 개입합니다.

1. 탐색 (기술 장벽 없애기)

새 요구사항이 들어오면("이집트 커버리지를 위해 X 통신사를 연동해야 한다") 엔지니어의 첫 수는 모르는 것을 추측하는 게 아닙니다. AI를 써서 이틀이 아니라 20분 만에 미지의 영역을 훑는 것입니다.

실제로는 이렇습니다. 이집트 MVNO를 연동해 본 적 없는 엔지니어가 통신사 API 문서를 AI 어시스턴트에 넣고, 연동 표면에 대한 구조화된 요약을 받고, 예외 상황에 대해 추가 질문을 던지고("이 시장의 일반적인 eKYC 흐름은 어떻게 되나?"), 점심 전에 공수와 리스크, 미지 항목을 담은 한 장짜리 평가서를 만들어 냅니다.

무엇이 달라지느냐면, 병목이 더 이상 "이 도메인을 아는 엔지니어가 우리에게 있나?"가 아니라는 점입니다. 이제는 "지금 있는 엔지니어가 AI의 도움으로 몇 시간 안에 이 도메인에서 충분히 유능해질 수 있나?"입니다. 거의 항상 답은 예입니다.

2. 명세 (몇 주가 아니라 몇 시간)

대부분의 회사에서 제품 명세는 1~3주가 걸립니다. PM이 초안을 쓰고, 이해관계자가 검토하고, 예외 상황이 추가되고, 인수 조건이 다듬어지고, 그다음에 엔지니어링이 범위를 다시 잡습니다. 명세가 "완료"될 즈음이면 원래의 기회는 이미 움직여 있습니다.

우리 방식은 이렇습니다. 엔지니어(또는 기능에 따라 CEO)가 한 줄짜리 제품 아이디어를 씁니다. AI가 그것을 구조화된 PRD로 확장합니다. 사용자 흐름, 예외 상황, 성공 지표, 인수 조건, 미해결 질문까지요. 팀은 45분짜리 작업 세션에서 다듬습니다. 명세는 같은 날 엔지니어링으로 넘어갑니다.

대가도 있습니다. 이 방식으로 나온 명세는 PM이 2주 동안 만든 전통적인 명세보다 조금 거칩니다. 우리는 그걸 받아들입니다. 첫 구현까지의 시간을 압축하는 값어치가 남는 모호함보다 큽니다. 그 모호함은 만들기 전이 아니라 만드는 동안 해소됩니다.

3. 디자인 (빠른 피드백 루프)

UI 비중이 큰 기능에서는 디자이너가 엔지니어와 나란히 "디자인-빌드-피드백" 루프를 돌립니다. 단위는 며칠이 아니라 몇 분입니다. AI로 생성한 목업(Figma 플러그인과 이미지 생성기)으로 변형안을 빠르게 탐색합니다. 엔지니어가 몇 시간 만에 프로토타입을 올립니다. 디자이너는 실기기에서 검토합니다. 반복 주기는 당일 단위입니다.

그 결과 디자인과 엔지니어링은 순차적이지 않고 동시적입니다. 디자인이 "최종"이 될 무렵이면 구현은 이미 프로덕션에 거의 다 와 있습니다.

4. 빌드 (AI가 코드를 쓰고, 사람이 모든 diff를 검토)

가장 눈에 띄는 AI 네이티브 지점입니다. 오늘날 eSimphony의 엔지니어링 과정은 이렇습니다.

• 새 코드의 약 90%를 AI가 생성합니다(Cursor, Claude, GitHub Copilot을 종종 조합해서)
• 엔지니어는 아키텍처 결정, 연동 경계, 시스템에 대한 깊은 이해가 필요한 까다로운 비즈니스 로직을 씁니다
• 모든 코드는 병합 전에 100% 사람이 검토합니다. 모든 diff, 모든 PR. 예외 없습니다.

마지막 항목이 결정적이고 자주 오해받습니다. "AI가 코드를 쓴다"는 말은 "사람이 코드를 안 본다"는 뜻이 아닙니다. 엔지니어의 역할이 구현을 타이핑하는 데서 구현을 검토하는 쪽으로 옮겨간다는 뜻입니다. 인지적 작업, 즉 이게 명세와 맞는가, 예외 상황을 처리하는가, 아키텍처에 들어맞는가, 확장되는가는 여전히 엔지니어의 몫입니다. 기계적인 작업, 즉 의도를 문법적으로 올바르고 관용적인 코드로 옮기는 일이 위임됩니다.

eSimphony의 전형적인 PR은 이렇습니다.

• 200800줄 변경(2024년경 팀들의 통상 100200줄 대비)
• 엔지니어 한 명이 상세히 검토
• 새 코드에 대해 80%가 넘는 커버리지의 AI 생성 단위 테스트가 붙는 경우가 많음
• 리뷰어 코멘트는 문법이 아니라 아키텍처에 집중

5. 출시 (몇 분 만에 대응)

출시는 점진적입니다. 위험한 변경에는 기능 플래그를, 백엔드 서비스에는 카나리 배포를, 그리고 롤아웃 몇 분 안에 이상 징후를 드러내는 AI 모니터링 텔레메트리를 씁니다. 출시가 뭔가를 망가뜨리면 롤백은 시간 단위가 아니라 분 단위입니다.

"AI 모니터링 텔레메트리"는 한 문장 덧붙일 만합니다. 배포 후 AI 에이전트가 오류율, 지연 시간, 사용자 신고, 전환율의 이상을 감시합니다. 이상이 기준을 넘으면 당직 엔지니어에게 유력한 근본 원인 요약과 함께 호출이 갑니다. 감지까지 걸리는 시간이 "오전 9시에 사용자가 버그를 신고"에서 "09시 03분에 알림 발생"으로 압축됩니다.

수치

지난 12개월의 대략적인 지표입니다.

• 스프린트 주기: 1주. 새 기능은 매주, 작은 수정은 매일 출시됩니다.
• 엔지니어 5명이 제품에 풀타임으로 일합니다. 파트타임 계약 엔지니어 한 명이 더 있습니다.
• 새 코드의 90% 이상을 AI가 생성합니다(주로 Cursor와 Claude).
• **병합된 코드의 100%**가 사람의 검토를 거쳤습니다.
• 기능 명세부터 프로덕션까지 중앙값: 5~10일.
• 분기당 프로덕션 장애: 1~2건. 우리 범위 대비 업계 평균 이하입니다.
• 엔지니어링으로 에스컬레이션되는 고객 지원 티켓: 주당 약 5건. 대부분 당일에 해결됩니다.

이 수치는 이론이 아닙니다. 우리 팀의 실제 운영 템포입니다.

이것이 아닌 것

eSimphony의 AI 네이티브 개발이 무엇을 뜻하지 않는지 분명히 해 둘 만합니다.

"바이브 코딩"이 아닙니다. 코드는 한 줄씩 검토됩니다. 아키텍처 결정은 사람이 합니다. AI는 타이핑을 가속할 뿐 사고를 가속하지 않습니다.

"테스트를 안 한다"가 아닙니다. AI가 생성한 테스트에는 뚜렷한 약점이 있습니다(예외 상황보다 정상 경로를 훨씬 꼼꼼히 테스트하는 경향이 있습니다). 그래서 엔지니어가 가장자리에 대한 테스트를 직접 씁니다. 새 코드의 테스트 커버리지는 꾸준히 80%를 넘습니다.

"시니어 엔지니어가 필요 없다"가 아닙니다. 정반대입니다. AI는 시니어의 판단 가치를 크게 끌어올립니다. 시니어 엔지니어는 AI 산출물을 처음부터 쓰는 것보다 5~10배 빠르게 검토하고 다듬을 수 있기 때문입니다. 시니어 리뷰 없이 AI를 쓰는 주니어 엔지니어는 컴파일은 되지만 구조적으로 취약한 코드를 내놓기 쉽습니다.

"디자인이나 제품 사고가 필요 없다"가 아닙니다. 명확한 명세와 잘 다듬은 사용자 흐름이 없으면 AI는 쓸모없습니다. "무엇을 왜 누구를 위해 만들 것인가"라는 인지적 작업은 여전히 사람의 몫입니다.

필요한 것

중요한 순서대로 세 가지입니다.

1. 엄격한 사람 리뷰

AI가 생성한 모든 코드 한 줄은 병합 전에 시니어 엔지니어의 검토를 거칩니다. "딱 봐도 맞는" 작은 변경에 리뷰를 건너뛰고 싶은 유혹은 실재하고 위험합니다. 우리는 100% 리뷰라는 선을 지켜 왔습니다.

2. 탄탄한 아키텍처 가드레일

AI가 코드를 생성할 때는 그 자리의 관례를 따릅니다. 강한 관례 = 강한 AI 산출물입니다. 우리는 명확한 모듈 경계, 일관된 이름 짓기, 타입이 잘 잡힌 인터페이스, 그리고 "우리는 여기서 이렇게 한다"는 명시적 문서화에 많이 투자했습니다. AI가 패턴을 깔끔하게 맞출 수 있도록요.

3. AI를 기본값으로 받아들이는 문화

팀은 모든 워크플로에서 AI 활용이 기본값이라는 데 명시적으로 합의했습니다. 새 엔지니어는 이 기본값 위에서 온보딩됩니다. 반론("그래도 저는 직접 쓰는 게 좋습니다")은 듣고 논의하지만, 특별한 이유가 없는 한 기계적인 일은 AI가 맡는다는 것이 팀의 규범입니다.

AI를 쓰지 않는 곳

• AI가 생성한 코드를 검토하는 일(사람의 새 눈이 필요합니다)
• 무엇을 만들지 정하는 일(제품 전략은 사람의 몫입니다)
• 고객 지원 에스컬레이션 직접 응대(어려운 사례는 사람이 처리합니다)
• 인사 평가와 팀 피드백(사람만)
• 채용 결정(사람만, 소싱과 스크리닝은 AI가 보조)

패턴은 이렇습니다. AI는 실행을 증강하고, 사람은 결정을 소유합니다.

이것이 제품에 중요한 이유

이 워크플로의 산출물은 제품에서 드러납니다. 우리가 내놓은 것들입니다.

• 평생 eSIM 아키텍처(대부분의 회사에서는 여러 분기가 걸리는 프로젝트)
• 다섯 개 언어를 지원하는 AI 여행 동반자 Moza
• 세 개 지역에 걸친 AI 다이내믹 요금제
• 자동 복구가 되는 AI 문제 해결
• 매주 릴리스되는 네이티브 iOS와 Android 앱
• 99.9% 이상 가동률의 다지역 백엔드
• 제품 전 영역에 걸친 5개 언어 현지화

이 목록은 보통 엔지니어 30~50명과 3년 이상을 요구합니다. 우리는 엔지니어 5명으로 18개월 만에 해냈습니다.

채용에 관한 메모

우리는 팀을 신중하게 키우고 있습니다. 여기서 잘하는 엔지니어들은 세 가지 특성을 공유합니다.

1. 산출량보다 판단력. 타이핑은 AI가 합니다. 우리는 검토하고 결정하고 형태를 잡는 데 뛰어난 엔지니어를 원합니다.
2. AI를 동료로 대하는 편안함. AI를 마법의 신탁이나 정체성의 위협으로 보지 않고 동료처럼 대하는(위임하고, 검토하고, 반박하는) 엔지니어입니다.
3. 사용자를 신경 씀. AI 네이티브 워크플로는 컴파일은 되지만 의미 없는 코드를 대량으로 뽑아낼 만큼 빠릅니다. 모든 PR을 "이게 사용자에게 도움이 되는가"에 붙들어 매는 엔지니어가 최고의 결과를 냅니다.

여기에 해당한다면 채용 중입니다. 채용 페이지로 연락하거나 Trung에게 직접 메시지를 보내세요.

다음에 나올 것

지금의 제품을 만든 그 워크플로가 로드맵을 출시하고 있습니다.

• 다중 eSIM 관리(2026년 5월)
• 가족 요금제(2026년 6월)
• 로열티와 리워드(2026년 8월)
• 전 세계 직접 통신사 커버리지(2027년)

전통적인 통신사라면 각각이 여러 달짜리 프로젝트입니다. 우리 내부 추정으로는 네 가지 모두 같은 5인 팀으로 일정대로 나옵니다.

그것이 레버리지입니다. 그것이 우리의 베팅입니다. 작은 팀이 산업 전체의 관성에 맞서 출시하는 방법입니다.

eSimphony를 직접 보거나, 우리의 포지셔닝에 대한 글을 읽거나, MVNO Nation Americas 피치덱을 확인해 보세요.