지난 1년 동안 저는 App Store와 Play Console에 90개 이상의 모바일 앱을 출시했습니다. 거의 모든 앱은 AI 코딩 에이전트(AI coding agents)의 강력한 도움을 받아 제작되었습니다(주로 Claude Code를 사용했으며, 과정 중에 다른 도구들도 섞어서 사용했습니다). 이 숫자는 대부분의 앱이 실제로 무엇인지 이해하기 전까지는 터무니없게 들릴 수 있습니다. 이 앱들은 90개의 개별 스타트업과 90개의 로드맵이 아니라, 1인 팀이 만든 작고 집중된 유틸리티 및 니치(niche) 게임들입니다.

저는 제 워크플로(workflow)에서 실제로 무엇이 변했는지 기록하고 싶습니다. 왜냐하면 제가 온라인에서 읽는 대부분의 "AI 코딩 에이전트" 관련 콘텐츠는 숨 가쁜 과장 광고이거나 반사적인 회의론 중 하나이기 때문입니다. 적어도 저에게 있어 현실은 그 두 극단보다 더 무질서하면서도 더 유용했습니다.

해금(Unlock)된 것은 코드 생성(Code Generation)이 아니었다

사람들이 가장 먼저 가정하는 것은 AI 에이전트가 당신보다 코드를 더 빨리 타이핑하기 때문에 가치 있다는 것입니다. 그것도 사실이지만, 흥미로운 부분은 아닙니다. 흥미로운 부분은 코딩 에이전트가 작은 앱 전체의 컨텍스트(context)를 작업 메모리에 유지하고 일관되게 행동할 수 있다는 점입니다. 12개의 파일에 걸쳐 변수 이름을 바꾸거나, 스키마(schema)를 업데이트하고 그것을 건드리는 모든 곳을 수정하거나, 빌드(build)를 실행하고 에러를 읽은 뒤, 당신이 스택 트레이스(stack trace)를 채팅창에 복사해서 붙여넣지 않아도 스스로 수정할 수 있습니다.

제가 에이전트를 자동 완성 엔진(autocomplete engine)으로 취급하는 것을 멈추고, 단순 반복 작업(grunt work)에 지치지 않는 주니어 엔지니어(junior engineer)로 취급하기 시작하자 포트폴리오 방식의 접근이 가능해졌습니다. 한 사람이 90개의 코드베이스(codebases)를 수동으로 유지 관리할 수는 없습니다. 하지만 한 사람과, 리포지토리(repo)를 가리키며 "빌드가 깨졌으니 수정해"라고 말할 수 있는 에이전트가 있다면 가능합니다.

진짜 복잡함은 스토어 제출 과정에 있다

앱을 작성하는 것은 결코 병목 현상(bottleneck)이 아니었습니다. App Store Connect와 Google Play Console 제출이 병목이었습니다. 두 플랫폼 모두 당신의 코드가 작동하는지 여부와는 상관없는, 놓치기 쉽고 사소한 수십 가지의 요구 사항을 가지고 있습니다:

• 구독형 앱은 설명란에 EULA(최종 사용자 라이선스 계약) 링크를 포함해야 합니다. 그렇지 않으면 사람이 검토하기도 전에 스크립트에 의해 자동으로 거절됩니다.
• 일부 지역에만 설정된 무료 체험(Free trials)은 한 지역에서는 심사를 통과하지만, 다른 지역에서는 구매 오류를 발생시킵니다.
• App Store Connect에서 앱 레코드를 삭제해도 번들 ID(Bundle ID)는 해제되지 않습니다. 이는 영구적으로 예약되며, 빠르게 반복 개발(Iterating)을 진행할 때 매우 중요한 문제입니다.
• Google Play의 분류기(Classifier)는 실제 권한 사용이 완전히 무해하더라도 "Android 시스템 로그를 읽음"과 같은 문구를 플래그(Flag)로 표시하며, 이의 신청 경로도 명확하지 않습니다.

이 중 그 어떤 것도 첫 앱을 만드는 튜토리얼에는 나오지 않습니다. 수십 번 거절당하고 체크리스트를 작성하기 시작한 후에야 비로소 알게 되는 것들입니다. 저는 결국 에이전트(Agent)가 해당 체크리스트를 실제 제출 전 게이트 스크립트(Pre-submission gate script)로 관리하도록 만들었습니다. 90개의 앱에 걸쳐 18개의 규칙을 스스로 기억하는 것을 더 이상 신뢰할 수 없었기 때문입니다.

에이전트는 당신이 절대 찾아내지 못할 지루한 버그를 찾는 데 탁월합니다

실제로 타격을 준 버그들은 비즈니스 로직(Business logic)에 있는 것이 아니었습니다. 그것들은 다음과 같은 것들이었습니다: 플러그인이 제거된 후 남겨진 퇴역한 광고 SDK 의존성(Dependency)이 특정 Android 버전의 콜드 스타트(Cold start) 시에만 충돌을 일으키는 경우. 또는 제가 테스트한 모든 시뮬레이터에서는 작동했지만, JS 엔진의 Intl 구현 방식이 예상과 다르게 로컬라이제이션(Localization)을 처리하여 실제 일본 기기에서는 잘못된 결과를 반환하는 로케일(Locale) 체크 문제 등 말입니다.

여기서 에이전트를 진정으로 유용하게 만든 것은 영리함이 아니라 끈기와 광범위함이었습니다. 저는 에이전트에게 90개의 모든 리포지토리(Repo)를 스캔하여 특정 안티 패턴(Anti-pattern)(참조되지 않는 의존성, 하드코딩된 스테이징 URL, 런처와 스토어 등록 정보 간의 중복 아이콘 불일치 등)을 찾아달라고 요청할 수 있었고, 주말 내내 수동으로 grep을 돌리는 대신 단 몇 분 만에 실제 답변을 얻을 수 있었습니다. 이 가치는 포트폴리오가 크기 때문에 복리로 증가합니다. 앱 3개에 동일한 기술을 적용하는 것은 그저 "찾기 및 바꾸기를 조금 더 복잡하게 사용하는 것"에 불과할 것입니다.

여전히 에이전트에게만 전적으로 신뢰하지 않는 부분

한계를 솔직하게 밝히고 싶습니다. 여기서 과장하는 것은 누구에게도 도움이 되지 않기 때문입니다.

• 실제 돈과 관련된 모든 것 — 인앱 결제 (in-app purchase) 설정, 구독 가격 책정, Stripe 웹훅 (webhooks) — 은 매번 수동 검토 과정을 거칩니다. 에이전트는 이전의 실수를 패턴 매칭 (pattern-matching) 하는 데는 능숙하지만, 무엇을 확인해야 하는지 정확히 알려주지 않는 한 잘못된 가격 지점을 잡아내는 데는 서툽니다.
• 파괴적인 작업 (강제 푸시 (force pushes), 데이터베이스 마이그레이션 (database migrations), 리뷰를 차단하는 레코드 삭제)은 절대 완전히 위임하지 않습니다. 저는 되돌릴 수 없는 모든 작업에 대해 "에이전트가 제안하고, 내가 승인한다"를 엄격한 규칙으로 삼습니다.
• 오래 걸리거나 불안정한 외부 프로세스 — 공유 임시 디렉토리 때문에 간헐적으로 실패하는 빌드(build), 또는 전파(propagation)에 대해 거짓 정보를 제공하는 CDN 캐시(cache) — 는 여전히 해당 패턴이 무작위가 아님을 인지할 인간이 필요합니다.

솔직한 요약은, AI 코딩 에이전트가 판단력이 필요한 소프트웨어 출시 과정을 대체하지는 못했다는 것입니다. 대신 인내심이 필요한 부분들을 대체했습니다. 즉, 백 줄짜리 디프 (diff)의 모든 줄을 읽는 것, 90개의 앱 중 어떤 앱이 여전히 폐기된 권한 (deprecated permission)을 사용하는지 기억하는 것, 혹은 피곤하다는 이유로 11단계를 건너뛰지 않고 동일한 15단계의 제출 체크리스트를 다시 실행하는 것과 같은 일들 말입니다.

무엇이 실제로 이를 지속 가능하게 만들었나

특정 도구보다 더 중요했던 두 가지 습관이 있습니다:

1. 실패 모드 (failure modes)를 마주할 때마다 기록하기: 기억력을 믿는 대신, 에이전트가 나중에 다시 읽을 수 있도록 일반 파일에 기록합니다. 제출이 동일한 이유로 두 번째 실패했을 때, 그것은 일회성 사건이 아니라 프로세스의 버그였습니다.
2. 검증을 타협 불가능한 것으로 취급하기: 에이전트가 "빌드 성공 (build succeeded)"이라고 보고하는 것은 컴파일러가 불평하지 않았다는 사실 외에는 아무것도 증명하지 않습니다. 저는 무언가가 완료되었다고 판단하기 전에 실제 아티팩트 (artifact) 확인 — 바이너리 (binary)가 업로드되었는지, 스토어 등록 정보에 반영되었는지, 앱이 정상적으로 열리는지 — 을 요구하는 법을 배웠습니다.

만약 여러분이 이 분야를 탐구하고 있으며, 단순히 읽는 것에 그치지 않고 AI 코딩 에이전트(AI coding agent)를 활용한 빌드 과정을 실제로 연습할 수 있는 더 구조화된 방법을 원하신다면, 제가 배운 내용들을 AI Craft Campus라는 작은 실습 리소스에 모아두었습니다. 이 리소스는 "AI에게 코드를 좀 써달라고 요청했다"라는 단계에서 벗어나, "AI 에이전트에게 반복적인 작업을 맡기며 실제로 작동하는 작은 소프트웨어 포트폴리오를 운영한다"라는 단계로 나아가고 싶은 분들을 대상으로 합니다. 이 역시 이 글의 나머지 부분과 마찬가지로 계속 발전시켜 나가는 과정에 있습니다.

90개의 앱은 결승선이 아니라, 단지 현재 카운터가 위치한 지점일 뿐입니다. 저를 여기까지 오게 만든 워크플로우 — 작은 저장소(repos), 지루한 부분에 대한 공격적인 자동화(automation), 그리고 "성공적으로 빌드되었다"를 완료(done)의 정의로 삼는 것에 대한 건강한 불신 — 이야말로 여러분이 어떤 특정 도구를 사용하든 관계없이 실제로 채택하기를 권장하는 부분입니다.