안녕하세요. 최근 혼자 ‘숨비’라는 모바일 게임을 만들었습니다. 제주 해녀의 물질에서 영감을 받은 세로형 로그라이크입니다. 한 번의 숨으로 바다에 들어가 해산물을 캐고, 더 욕심낼지 지금 돌아올지를 판단하는 게임입니다.
7월 2일 설계를 시작해 7월 9일 Google Play에 첫 빌드를 올렸고, 플레이하면서 아쉬웠던 부분을 계속 고쳐 7월 19일에는 v1.1 빌드까지 프로덕션에 업로드했습니다.
처음부터 궁금했던 건 단순히 “AI가 코드를 얼마나 빨리 짜는가”가 아니었습니다. 여러 AI 모델에 서로 다른 역할을 주고 하나의 개발팀처럼 굴리면, 실제로 출시할 만한 게임을 어디까지 만들 수 있을까. 그걸 시험해보고 싶었습니다.
어떤 게임인가
‘숨비’는 해녀가 물질을 마치고 수면으로 올라와 내쉬는 휘파람 같은 숨, ‘숨비소리’에서 따온 이름입니다.
한 판은 10~30초 정도입니다. 한 손으로 해녀를 움직여 더 깊이 내려가거나 주변 해산물을 캡니다. 수면에 무사히 닿아야 채집물을 온전히 가져올 수 있어서, 조금 더 욕심낼지 지금 돌아갈지를 계속 저울질하게 됩니다. 올라오면 채집물을 정산하고 폐활량, 오리발, 망사리, 눈썰미를 키운 뒤 다시 잠수합니다.
매 판 세 가지 능력 중 하나를 고르는 로그라이크 드래프트, 해산물 도감 60종, 장비와 성장 트리, 해녀 등급 승급, 100m까지 이어지는 숨골을 넣었습니다. 조작은 단순하게 두되, 잠수를 반복할수록 노리는 기록과 빌드가 달라지게 만들었습니다.
AI를 한 명의 만능 개발자로 쓰지 않았습니다
한 모델이 설계부터 구현, 자기 검수까지 모두 맡으면 자기 전제를 그대로 정답 처리하기 쉽습니다. 그래서 역할을 이렇게 나눴습니다.
- Fable 5: 게임 구조와 기능 명세, 경제 밸런스 목표, 완료 조건 설계
- Opus 4.8: Flutter·Flame 구현, 테스트 작성, 디버깅
- Fable 5: 처음 쓴 명세와 구현 결과를 다시 대조해 누락과 회귀 점검
- Codex GPT-5.5: 코드와 변경분을 독립적으로 리뷰하고 엣지 케이스 지적
작업 순서는 대체로 설계 → 구현 → 원 설계자의 재검증 → 독립 코드 리뷰 → 자동 테스트와 실기 플레이였습니다.
해보니 프롬프트를 멋지게 쓰는 것보다 검증할 수 있는 완료 조건을 먼저 잡는 일이 더 중요했습니다. “성장감을 좋게 만들어줘” 대신 첫 10분의 구매 횟수, 첫 승급까지 걸리는 시간, 어느 성장 구간에서도 아무것도 살 수 없는 시간이 길게 생기지 않는지 등을 숫자로 정했습니다. 그런 다음 경제 시뮬레이터와 테스트로 확인했습니다.
현재 자동 테스트는 627개이며 모두 통과합니다. Flutter 정적 분석도 앱 코드·테스트·도구 범위에서 오류 없이 통과합니다.
AI가 그럴듯하게 틀린 사례들
첫 설계가 바로 재미있는 게임이 되지는 않았습니다.
초기 버전은 한 판에 캘 수 있는 대상이 5~9개뿐이었습니다. 채집 게임인데 바다가 비어 보였죠. 직접 해보고 이 구조를 버렸습니다. 성장할수록 필드가 풍성해지고, 캔 자리에는 다시 해산물이 자라도록 바꿨습니다. 특정 성장 빌드에서는 한 판에 약 40개까지 캘 수 있습니다.
성장 트리도 비슷했습니다. 노드는 290개나 됐지만 실제 플레이는 일직선에 가까웠습니다. AI는 “노드 290개”라는 요구를 충족했지만, 선택하는 재미까지 만든 건 아니었습니다. 결국 세 가지 특화 경로와 영구 노드 구조를 다시 나눴습니다.
AI는 코드를 빠르게 많이 만들지만 재미와 우선순위까지 보장하지는 못했습니다. 직접 플레이하며 “이건 재미없다”, “기능은 많은데 다음 목표가 안 보인다”고 잘라 말하는 일은 여전히 사람 몫이었습니다.
이미지와 사운드도 직접 파이프라인을 만들었습니다
해녀 캐릭터, 해산물, 장비, 카드 아이콘 같은 주요 이미지 에셋은 GPT 이미지 생성 API로 만들었습니다. 생성된 시트를 그대로 쓰지 않고 크로마키 제거, 프레임 정렬, 크기 통일, 픽셀 양자화를 거치는 보정 파이프라인에 넣은 뒤 확인했습니다. 배경과 기포, 빛줄기 등은 대부분 코드로 그렸습니다.
사운드는 외부 에셋을 모으는 대신 Dart 코드로 WAV를 합성했습니다. 잠수가 끝날 때 들리는 숨비소리는 게임 이름과 한 판의 끝이 만나는 핵심 사운드로 잡았습니다.
만들고 나서 달라진 생각
흔히 “AI는 잘 시켜야 잘한다”고 합니다. 이번에는 그보다 “틀렸을 때 잡아낼 구조가 있어야 한다”는 쪽을 더 크게 배웠습니다.
설계자와 구현자, 검수자를 나누고 다른 모델이 계획과 코드를 공격적으로 들여다보게 했습니다. 마지막 판정은 숫자와 테스트, 실제 플레이에 맡겼습니다. 이 방식이 한 모델과 긴 대화를 이어가며 전부 맡기는 것보다 훨씬 안정적이었습니다.
AI가 빨라져도 1인 개발의 병목은 없어지지 않았습니다. 대신 병목의 위치가 코딩에서 판단으로 옮겨갔습니다. 무엇을 남기고 버릴지, 왜 지금 재미가 없는지 정하는 일이 가장 오래 걸렸습니다.
Google Play
https://play.google.com/store/apps/details?id=com.kinderia.sumbi
아직 혼자 만든 게임이라 부족한 부분이 많습니다. 재미가 없는지, 성장 메뉴가 너무 복잡하지 않은지 의견을 듣고 싶습니다. 개발 방식이나 모델별 역할 분담에 관한 질문도 편하게 남겨주세요.