코딩 초보자가 AI 에이전트 지시로 게임을 4개 스토어에 출시한 경험: 성공과 실패

고지 사항: 이 글은 AI 어시스턴트(Claude)의 도움을 받아 작성되었습니다. 게시하기 전에 git 기록 및 테스트 출력 결과와 수치를 확인했습니다.

10월 2일, 저는 실제 아이폰에서 제 게임을 테스트하다가 이상한 것을 발견했습니다. 리워드 광고를 보고 돌아왔더니 조이스틱이 엄지손가락이 마지막에 있던 곳에 고정되어 있었습니다. 그날 밤에는 더 심해졌습니다. 광고를 본 후 모든 사운드 효과가 사라졌습니다.

그 순간, 1,450개의 자동화 테스트는 모두 통과하고 있었습니다. 저는 코드를 작성하지 않았고, 테스트도 작성하지 않았습니다. AI 코딩 에이전트들이 했습니다. 버그를 발견한 것은 실제 휴대폰 위의 제 엄지손가락이었습니다.

저는 한국에서 혼자 일하는 소프트웨어 개발 초보자입니다. 이 게임을 제가 직접 프로그래밍한 것이 아닙니다. 저는 AI 코딩 에이전트들(주로 Claude Code, Codex와 Kimi가 번갈아 사용됨)에게 지시했습니다. 그 결과물은 원-핑거 모바일 로그라이트인 Afterclose: Night Delivery이며, 현재 Google Play, Toss 앱 내의 미니앱 플랫폼인 Apps in Toss, ONE 스토어, 그리고 App Store 네 곳에 제출되었습니다. 이것이 그 과정에 대한 솔직한 기록입니다.

수치

• 가드레일 파일(guardrail file). 레포지토리에 있는 AGENTS.md에 하드 규칙을 설정했습니다: 내 승인 없이 스토어 제출 또는 리뷰 버튼을 절대 누르지 않기, 비밀 키를 절대 출력하지 않기, bun run check (린트, 타입 체크, 테스트)가 통과하기 전에 커밋하지 않기. 이 파일을 읽는 모든 에이전트는 동일한 규칙을 상속받습니다.
• 빌드 전 읽기 전용 감사(Read-only audits before building). 큰 라운드가 시작될 때 저는 감사 에이전트들에게 코드를 읽고 아무것도 건드리지 않으면서 문제점을 보고하게 했습니다. 그런 다음 파일 영역별로 작업을 분할하고, 각 구현 에이전트에게 자체 git worktree를 할당한 후 마지막에 병합했습니다. 12라운드에서는 열 개의 worktree를 사용했습니다.
• 균형을 위한 시뮬레이션 플레이어(Simulated players for balance). 난이도는 수백 번의 근무 시간 동안 테스트 봇들이 플레이하는 것으로 측정했습니다. 저는 느낌이 아니라 숫자를 원했습니다.
• 페르소나 QA(Persona QA). 19라운드에서는 각기 다른 '특성'(느린 반응, 통근자, 육십 대)을 가진 여섯 개의 에이전트가 실제 브라우저에서 플레이했습니다.
• 에셋(Assets). 아트워크의 대부분은 AI 이미지 도구로 만들고 제가 다듬었습니다. 음향 효과는 CC0 팩에서 가져왔고 음악은 코드로 합성했습니다.

잘 작동한 것 (What worked)

파일 영역별로 분할하면 병렬 작업이 깔끔하게 유지된다. 11라운드에서는 다섯 개의 작업 흐름(결제 동작, 장비 기능, 캐릭터 비주얼, 맵 확장, 균형)이 있었습니다. 저는 공유 타입을 그리고 효과 이벤트를 먼저 커밋한 다음, 각 에이전트에게 자체 worktree를 할당했습니다. 유일한 병합 충돌은 생성된 글꼴 파일이었고, 하나의 명령을 다시 실행하여 해결했습니다.

'더 좋은가?' 대신 숫자를 요청하라. 저의 난이도 규칙은 '날이 지남에 따라 어려워지고, 업그레이드할 때 쉬워지며, 전반적으로 너무 쉽지도 어렵지도 않다'였습니다. 저는 이것을 다음과 같이 바꿨습니다: '48번의 시뮬레이션 실행으로 도달한 최고의 날은 기준선에서 ±1일 이내에 머무른다.' 일단 문장이 되자, 어떤 에이전트가 수행했든 모든 변경 사항이 동일한 표로 보고되었습니다. 또한 희귀할수록 강하다는 규칙을 숫자로 설정했습니다 (흔한 아이템은 난이도의 약 절반 일치, 가장 희귀한 등급은 5에서 7 사이).

도구 전환을 자유롭게 만드는 인계 문서

Claude Code, Codex, Kimi 사이를 오가기 때문에 어떤 도구든 하나의 파일을 읽고 상태, 검증 명령어(verification commands), 금지 사항(don'ts) 및 남은 작업을 파악할 수 있어야 합니다. 각 QA 라운드에서도 보고서(docs/qa에 18개)가 남아있었기 때문에, 세션이 끊겨도 "어디까지 했더라?"라는 시간을 허비하는 일이 없었습니다.

문제가 발생한 부분

1. 테스트는 통과했지만, 휴대폰 배터리가 방전됨. 약 12시간 이내에 네 가지 실제 기기 관련 문제가 발견되었습니다.

• 광고가 나온 후 조이스틱이 멈춤 현상(freezing). iOS는 네이티브 전체 화면 광고가 표시되는 동안 웹뷰로 터치 종료 이벤트(touch-end event)를 전달하지 않기 때문에, 게임은 이전 손가락이 여전히 눌려 있다고 판단하여 새로운 모든 터치를 무시했습니다.
• 광고 이후 모든 음향 효과가 소리가 나지 않게 됨. 광고 SDK가 오디오 세션(audio session)을 가져갔다가 돌려주지만, 웹 오디오 컨텍스트(web audio context)는 중단된 상태로 유지되며, iOS는 터치에 의해 트리거되지 않은 재개(resume)를 무시합니다.
• 레벨업, 시프트 완료 및 결과 화면의 음향 효과가 코드에는 존재했지만 재생되지 않음: 끊어진 와이어.
• 오디오 버벅임(Audio stutter).

이 문제들은 에이전트들이 진단하고 수정했습니다. 하지만 이를 알아차린 사람은 저였고, TestFlight를 터치하며 테스트하던 중이었습니다. 이후 이 모든 것은 회귀 테스트(regression test)가 되었으며, 순서는 항상 "실제 기기에서 발견된 후, 테스트로 고정됨"이었습니다.

2. 게임에서 전혀 사용하지 않은 텍스트 때문에 스토어에서 거부당함. 10월 7일, Apps in Toss 리뷰는 제 번들(my translation)을 다음과 같은 이유로 거부했습니다: "릴리스될 수 있는 미니 앱 번들은 테스트 광고 그룹 ID를 포함할 수 없습니다." 해당 ID는 개발 모드에서만 사용되었기 때문에 실제 운영 환경에서는 실행되지 않았습니다. 하지만 저는 런타임에 이 문자열 ait-ad-test-...가 여전히 번들에 남아있다고 판단했고, 리뷰 시스템은 로직이 아닌 텍스트를 읽었습니다. 저는 빌드 시간에 해당 값을 사라지게 만들고, 그 문자열이 살아남으면 빌드를 중단하는 규칙을 빌드 스크립트에 추가한 후 재제출했습니다. 그리고 밤늦게인 10월 9일에 라이브되었습니다.

3. 일반적인 스토어 함정들.

• Google Play는 versionCode를 재사용하는 것을 허용하지 않습니다. 저는 검토 과정에 있던 버전 (3)에서 버그를 발견하여 (4)로 교체해야 했습니다. 테스트는 여전히 "3"을 예상하고 있었고, 제가 예상을 수정할 때까지 실패했습니다.
• Play 스토어는 긴 변이 짧은 변의 두 배를 초과하는 스크린샷을 거부하므로, 모든 것을 1080×1920으로 다시 잘라야 했습니다.
• Toss SDK를 3.x로 업그레이드하자 가짜 브릿지(fake bridge)에 의존하던 14개의 엔드투엔드 테스트가 깨졌습니다. 에이전트가 이 가짜 코드를 새로운 프로토콜에 맞게 다시 작성했습니다.
• App Store 빌드는 10월 4일에 제출되었고, 제가 글을 쓰는 지금도 검토 중입니다.

다섯 가지 교훈

1. AI에게 자신의 작업 등급을 매기도록 요청하면 관대할 것입니다. 저는 QA 평가를 AI에 맡겼습니다. 각 후속 감사(follow-up audit)가 진행될 때마다 점수가 하락했습니다: 8.9 → 7라운드에서 8.5, 9.3 → 8라운드에서 8.7, 9.3 → 9라운드에서 8.8, 9.4 → 10라운드에서 9.1, 9.5 → 9라운드에서 9.2. 연속 다섯 번 동안 0.3점에서 0.6점씩 하락했습니다. 8라운드 이전의 읽기 전용 감사에서는 앞선 7라운드가 놓쳤던 세 가지 심각한 버그를 발견했습니다: 지연된 저장 복원(delayed save restore)이 백업을 덮어쓸 수 있음, 장치 날짜 변경이 일일 보상을 반복함, 환불이 영구 구매 항목을 남김. 감사를 먼저 하고, 그다음 빌드를 하세요.

2. 녹색 테스트는 AI가 생각한 것만 보호합니다. 같은 에이전트가 코드와 테스트를 작성했기 때문에, 이들은 사각지대를 공유합니다. 광고 이후의 침묵은 실제 광고가 나오는 실제 휴대폰에서만 나타납니다. 출시 전에 직접 게임을 만져볼 시간이 필요했습니다.

3. 먼저 측정 도구를 불신하세요. 세 번의 시뮬레이션 실행에서는 한 지표가 19% 더 나쁘게 보였고, 여섯 번의 실행에서는 5% 더 나쁘게 보였습니다. 16회 실행에 걸친 기준 평균은 24.4에서 48회 실행에 걸쳐 23.7로 변했습니다. 한때 봇이 진열대 앞에서 45초 동안 멈춰서 새로운 스토어가 어렵게 보이게 만들었지만(첫 시도 성공률 63%에서 75%), 실제로는 괜찮았습니다(경로 탐색 수정 후 100%). 그리고 어떤 라운드가 게임을 갑자기 +2.9일 더 쉽게 만들었을 때, 원인은 제가 의심했던 처치 점수 변경이 아니라 장비 드롭이었습니다.

4. 검토는 당신의 의도가 아닌 번들(bundle)의 텍스트를 읽습니다. 거절을 자동화된 점검으로 전환하세요. Toss에서 거절당한 후, 에이전트에게 스캔을 빌드 단계에 추가하도록 요청했습니다. 단 한 번 실수로 실패하는 것이 좋은 거래입니다.

5. 초보자의 일은 판단과 실제 검증입니다. 제 11차 감사(audit)를 통해 휴대폰 버전에는 조이스틱과 버튼 하나만 있는 반면, 대부분의 부츠 옵션이 키보드 전용 기술에 의존하고 있어 휴대폰에서는 아무 기능도 하지 않는다는 것을 발견했습니다. 에이전트들은 대시 버튼을 추가할지 말지 결정하지 못했고, 제가 "대시는 왜 없나요?"라고 묻자 그것을 만들어냈습니다. 그리고 19차 감사에서 한 에이전트는 "카드를 읽는 동안 타이머가 작동합니다"라고 보고했지만, 저는 코드를 열어보고 사실이 아님을 확인했습니다. 무엇이 진실인지 판단하고 AI의 보고서를 액면 그대로 받아들이지 않는 것이 제 역할이었습니다.

다음 계획 (What's next)

• Apple의 검토를 기다리는 중입니다.
• 독일어, 프랑스어, 번체 중국어, 브라질 포르투갈어 스토어 텍스트는 AI로 번역되었으며 네이티브 스피커가 확인하지 않았습니다.
• 현재 충돌 보고(crash reporting) 기능이 없어 플레이어의 휴대폰에서 발생하는 오류를 자동으로 받을 수 없습니다.
• 밸런스는 오직 봇(bots)으로만 측정되었습니다. 실제 플레이어 데이터는 초반 게임 분량 곡선(early-game quota curve)을 바꿀 것입니다.
• 홍보(Promotion) 역시 제가 진정한 초보자인 분야입니다. 제 첫 영상은 약 29시간 만에 YouTube 조회수 230회를 기록했습니다. 아직 자랑할 것은 없습니다.

게임에 대해 궁금하다면 (If you're curious about the game)

Afterclose: Night Delivery는 원-핑거 로그라이트 아케이드입니다. 배달 로봇 Pico가 어두운 가게에서 야간 근무를 합니다. 화물을 챙기고, 계산대에서 현금을 받고, 할당량을 채우고, 탈출하는 내용입니다. 장비(Gear)는 최대 +20까지 강화할 수 있으며, 강화에 실패해도 장비가 파괴되지 않습니다 (만렙인 +11부터는 레벨이 하나 떨어질 뿐입니다). 그리고 설치 비용은 무료입니다.

• Android: https://play.google.com/store/apps/details?id=com.rewardry.afterclose
• 사이트: https://afterclosegame.com/afterclose/
• iPhone: 검토 중입니다.

질문이나 '여기가 틀렸다'는 수정 의견도 환영합니다. 특히 AI 에이전트를 사용해 출시하면서 걸렸던 스토어의 함정들에 대해 듣고 싶습니다.