AI가 쓴 기획서로 게임 14종을 한 번에 만든 방법 — 장르 두 개를 섞고, 브리프 두 장으로 에이전트를 나눠 돌린 기록

11월 7일 저녁, 새 게임 14종을 한꺼번에 만들었습니다. 정확히는 한 종을 먼저 끝까지 만들고, 그걸 본보기로 나머지 13종을 AI 에이전트 여러 명에게 동시에 맡겼습니다. 이 글은 그때 쓴 기획서(브리프)가 어떻게 생겼고, 누가 무엇을 맡았고, 무엇으로 통과와 탈락을 갈랐고, 결국 어디에 실렸는지에 대한 기록입니다. 기획서 자체도 AI가 썼습니다. 제가 한 일은 방향을 고르고, 기본안을 확정하고, 결과를 받아 보는 쪽이었습니다.

먼저 숫자부터 맞춰 둡니다. 작업 기록의 결정 문서 제목이 “짬뽕 신작 14종”이고, 관문 표에도 게임이 정확히 14줄 있습니다. 처음 만든 마작 원정 1종과 병렬로 만든 13종을 합친 수입니다.

출발점: 남의 게임을 뜯지 않고 장르만 섞기

시작은 엉뚱한 데서 나왔습니다. 리버스 엔지니어링 도구를 사업에 쓸 수 있는지 보자는 이야기였고, 웹 게임 포털 CrazyGames의 인기 목록도 같이 조사했습니다. 결론은 도구를 쓰지 않는 쪽이었습니다. 남의 게임에서 코드나 그림을 뽑아내는 순간 침해가 되기 때문입니다. 대신 인기 장르를 재료로만 쓰기로 했습니다. 규칙(메커니즘)은 저작권 대상이 아니니, 서로 다른 장르 두 개를 섞으면 어디에도 없는 오리지널이 됩니다.

그렇게 나온 결합안이 14개입니다. 1순위는 마작 원정으로 정했습니다. 이전부터 세워 둔 전략 메모가 10대보다 30~50대 사용자를 우선으로 두고 있는데, 마작은 50대 선호가 강하고, 로그라이크 구조가 다시 찾아오게 만들고, 이미 있는 카드 게임 코드를 다시 쓸 수 있었기 때문입니다.

순서	한국어명	섞은 장르	영문명	토스 허브
1	마작 원정	마작 솔리테어 × 덱빌딩 로그라이크	Mahjong Quest	퍼즐카페
2	번호 낚시	낚시 × 번호 뽑기	Number Ball Angler	보류(Play 전용)
3	띠 운세 공방	방치형 타이쿤 × 띠 운세	Zodiac Fortune Workshop	오락실
4	합체 수비대	머지 × 타워 디펜스	Merge Gate Guards	오락실
5	숫자 뱀	지렁이 게임 × 2048	Doubling Snake	오락실
6	나사 퍼즐 블록	나사 풀기 × 블록 채우기	Bolt Drop Fill	퍼즐카페
7	역사 지도 찍기	위치 맞히기 × 한국사·지리	History Map Pin	하루상식
8	오목 카드 대국	오목 × 로그라이크 능력 카드	Gomoku Card Duel	한판승부
9	당구 공성전	당구 × 성 무너뜨리기	Cue Ball Siege	공성전
10	분식집 머지	서빙 × 머지	Bunsik Snack Merge	퍼즐카페
11	한글 연금술	원소 조합 × 한글 자모	Hangul Alchemy	하루상식
12	윷 땅따먹기	땅따먹기 × 윷놀이	Yut Land Grab	한판승부
13	박자 두더지	리듬 × 두더지 잡기	Drum Beat Moles	오락실
14	버드 서바이버	서바이버류 × 탭 버드	Wingbeat Survivors	오락실

고르는 과정에서 떨어뜨린 것도 있습니다. 리버스 엔지니어링 도구는 아예 쓰지 않았고, 참고한 원작의 이름은 게임 코드와 화면 어디에도 넣지 않았습니다. 나중에 검토할 때 원작 이름 열 개 남짓을 소스 전체에서 검색해 0건인 것을 확인했고, 14개 폴더에 이미지·오디오 파일이 하나도 없다는 것도 확인했습니다. 그림은 전부 CSS와 캔버스로 그렸습니다. 마작 패도 그림이 아니라 글자로 그린 패입니다.

기획서는 두 장으로 나눴다

프로토타입 브리프의 절 구성

에이전트에게 준 첫 기획서는 “짬뽕 신작 공통 브리프”라는 한 장짜리 문서입니다. 게임마다 따로 쓰지 않고 13명이 같은 문서를 받았습니다. 게임별 내용은 결합안 표 한 줄과 게임 폴더 이름뿐이고, 나머지는 전부 공통 규칙입니다. 절은 여섯 개입니다.

1. 기준 구현 — 먼저 만든 마작 원정 폴더를 “구조를 그대로 따른다”고 지정합니다. 규칙과 점수는 화면 코드가 없는 파일 하나에, 테스트는 그 파일을 불러 밸런스를 시뮬레이션하는 파일에 둡니다. 공용 모듈을 어떤 경로로 불러야 테스트가 깨지지 않는지까지 적었습니다.
2. 이번 단계 범위 — “플레이 가능한 프로토타입(한국어만)”. 홈, 플레이, 결과, 기록, 오늘의 판까지만 만들고, 광고·하트·번역·푸시·공유·랭킹·크로스프로모는 “붙이지 않는다”고 못 박았습니다. 보상형 광고를 넣을 만한 자리는 상태 문서에 메모만 하게 했습니다.
3. 반드시 지킬 것 — “규칙(메커니즘)만 섞은 오리지널”, 번역투 금지, 도박·사행성 표현 금지, 바닥 고정 UI는 토스 배너 높이만큼 띄우기, 부팅 뒤 첫 화면 다시 그리지 않기 같은 항목입니다. 대부분은 앞선 앱들이 실제로 반려되거나 화면이 가려졌던 경험에서 나온 줄입니다.
4. 금지 — 절 제목이 “다른 에이전트 12명이 같은 저장소에서 동시에 일한다”입니다. 자기 게임 폴더 밖 파일은 만들지도 고치지도 말 것, 패키지 설치와 git 명령 금지, 브라우저 도구 금지.
5. 끝내기 전 검증 — 규칙 테스트, 타입 검사 오류 0, 빌드 성공, 상태 문서 작성. 넷 다 통과해야 완료입니다.
6. 보고 — “250자 이내 한국어”. 완료 여부, 테스트 개수, 빌드 크기, 화면에서 꼭 볼 점, 막힌 것.

마지막 절이 짧은 데는 이유가 있습니다. 13명이 각자 긴 보고서를 보내면 받는 쪽이 그걸 다 읽지 못합니다. 보고를 짧게 묶고, 자세한 건 게임 폴더의 상태 문서에 남기게 했습니다.

셸 브리프가 따로 있는 이유

두 번째 문서는 “셸 연결 브리프”입니다. 셸은 게임 바깥을 감싸는 출시용 껍데기입니다. 광고, 하트, 리더보드, 푸시 동의, 공유, 크로스프로모, 9개 언어 번역, 뒤로가기 처리가 여기에 들어갑니다.

이걸 첫 브리프에 같이 넣지 않은 이유는 두 가지입니다. 첫째, 게임이 재미있는지와 출시 규칙을 지키는지는 다른 문제라서 한 에이전트가 한꺼번에 하면 둘 다 흐려집니다. 프로토타입 단계에서 광고를 금지한 것도 그래서입니다. 둘째, 셸 규칙은 토스 심사 기준이라 문장 하나하나가 정확해야 합니다. 셸 브리프의 보상형 광고 절 제목이 “토스 반려 기준이라 정확히”입니다. 예를 들면 이런 줄들입니다.

• 보상형은 “교환형만”. 광고를 끝까지 보면 그 동작(힌트, 추가 시도 등)을 바로 수행합니다. 게임마다 한두 자리, 판마다 횟수 제한.
• 광고 버튼은 라벨 앞에 TV 표시를 붙이고, “그 버튼 바로 아래”에 예고 한 줄. 아래·위 같은 방향 단어는 금지, 토스트로만 알리는 것도 금지.
• 광고가 없는 웹에서는 광고 버튼과 예고를 숨깁니다. 브리프에는 이유가 괄호로 붙어 있습니다. “웹에서 예고는 거짓말”.
• 전면 광고는 직접 띄우지 않습니다. 하트 모듈이 알아서 붙이기 때문에 겹칩니다.

번역은 9개 언어를 전부 직접 넣되, 한글 연금술과 역사 지도 찍기 두 종은 내용이 한국어 자체라 한국어만 두게 했습니다. 끝내기 전 검증에는 번역 파일에서 유니코드 이스케이프와 금지어 개수를 세는 한 줄짜리 명령이 들어 있고, 결과가 0 0이어야 합니다.

세 역할로 나눈 분업

실제 작업은 세 역할로 나뉘었습니다.

• 오케스트레이터(메인 세션) — 결합안 표와 두 브리프를 쓰고, 1순위 마작 원정을 직접 끝까지 만들어 기준 구현으로 세웠습니다. 에이전트를 띄우고, 돌아온 결과를 브라우저로 열어 보고, 검사 스크립트를 돌리고, 커밋했습니다.
• 프로토타입 에이전트 13명 — 첫 브리프를 받아 게임 하나씩. 자기 폴더 안에서 규칙, 테스트, 화면을 만들었습니다.
• 셸 에이전트 13명 — 셸 브리프를 받아 같은 게임 13종에 셸을 붙였습니다. 프로토타입 에이전트가 남긴 상태 문서의 “보상형 후보”를 읽고 그중 한두 자리를 고르는 식으로 앞 단계와 이어집니다.

모델도 역할마다 다르게 골랐습니다. 설계와 판단은 상위 모델이, 구현은 다른 모델이 맡는 식이고, 셸처럼 규칙이 촘촘히 적힌 일은 더 가벼운 모델 하나로 돌렸습니다. 웹 조사와 번역까지 합하면 이날 띄운 하위 에이전트는 29개였습니다.

단계	맡은 쪽	입력	산출물	완료 기준
결합안	오케스트레이터	인기 장르 목록, 전략 메모	결합안 14개와 순서	사용자 “1순위부터 진행”
기준 구현	오케스트레이터	1순위 결합안	마작 원정 프로토타입과 셸, 테스트 7개	375×812 화면에서 1판부터 결과까지 자동 클릭
프로토타입	에이전트 13명	공통 브리프	게임 폴더 13개, 상태 문서	테스트·타입 검사·빌드·상태 문서
셸	에이전트 13명	셸 브리프, 상태 문서	9개 언어, 광고·하트·랭킹·공유	위 넷 + 배너 감사 + 이스케이프·금지어 0 0
결정	사용자	기본안 D1~D17	허브 배치, 이름, 광고 교체	기본안 확정
관문	오케스트레이터	14종	관문 표	다섯 항목 전부 통과
허브 수록	오케스트레이터	허브 설정 6개	토스·Play 허브 번들	허브 감사 오류 0, 검수 요청

경계는 브리프의 금지 절이 그었습니다. 에이전트는 자기 게임 폴더 밖을 못 건드리고, 공용 패키지·앱 목록·허브 설정·도구는 오케스트레이터만 고칩니다. 화면 확인도 오케스트레이터 몫이라 에이전트에게는 브라우저 도구를 막았습니다. 이 경계는 예전에 AI 세션 세 개가 같은 일을 두 번 하고 기록을 덮어쓴 일에서 얻은 규칙을 게임 단위로 옮긴 것입니다.

그래도 한 번 샜습니다. 당구 공성전 셸 에이전트가 공용 임시 폴더에 있던 다른 에이전트의 패치 스크립트를 실행해, 나사 퍼즐 블록 파일에 패치가 한 번 더 들어갔습니다. 저장소 경계는 막았지만 임시 폴더는 막지 않았던 겁니다. 중복 코드가 없다는 것까지는 확인했지만, 그 패치가 다른 내용을 덮었는지는 차이를 끝까지 대조하지 못했습니다.

실기기 10분 관문, 그리고 그것을 건너뛴 이유

처음 계획한 관문은 사람 손이었습니다. 인수인계 문서의 순서는 “실기기 10분 플레이 관문(개발폰 adb 무선) → 통과작만 다음 단계, 미통과는 수정 목록”이었고, 결정 문서의 D13도 “실기기 10분 플레이 관문을 통과한 작품부터”였습니다. 14종을 다 내는 것이 규칙이지만, 순서는 품질순으로 정하자는 뜻이었습니다.

실제로는 이 관문을 건너뛰었습니다. 11월 8일에 “실기기 테스트 결과 스킵하고 다음 단계 진행해. 필요하면 출시 후에라도 내가 수정 지시할게”라고 결정했고, 사람의 10분 플레이 대신 자동 관문 다섯 항목을 돌렸습니다.

• 타입 검사 오류 0
• 게임별 규칙 테스트 전부 통과(14종 합계 219개)
• 빌드 성공
• 하트 감사 통과(하트 게이트와 남은 하트 표시가 제대로 붙었는지)
• 배너 감사 통과(바닥 고정 UI가 토스 배너에 가리지 않는지)

14종 모두 통과했지만 한 종은 고치고 나서였습니다. 띠 운세 공방에 남은 하트 배지가 없어서 하트 감사에 걸렸고, 리셋 버튼 옆에 배지를 붙였습니다. 이런 감사 도구들이 왜 생겼는지는 출시 사고 21건 글에 있습니다.

내용 검수도 따로 했습니다. 역사 지도 찍기는 게임에서 3km 안에 찍으면 만점인데, 어림값으로 들어가 있던 좌표 6곳(우금치, 다부동, 고부, 관산성, 기벌포, 청해진)을 실제 위치와 대조해 모두 1km 안쪽인 것을 확인했습니다. 한글 연금술의 낱말 381개는 기존 초성 퀴즈 앱의 목록을 가져온 것이라 목록 전체를 읽어 검수했고, 애매했던 ‘달걀판’은 표준국어대사전 표제어로 확인했습니다.

솔직히 말하면, 이 관문은 “돌아가는가”는 잡지만 “재미있는가”와 “손에 맞는가”는 못 잡습니다. 테스트 219개 중 어느 것도 오목 칸이 약 22px라 손가락으로 누르기 어렵다는 걸 알려 주지 않습니다. 실기기 확인은 토스 테스트 번들과 디버그 APK로 출시 뒤에도 할 수 있게 열어 두었습니다.

이름 짓기: 한국어는 에이전트가, 영문은 검색으로

한국어 이름은 각 프로토타입 에이전트가 지은 이름을 그대로 썼습니다. 영문명은 달랐습니다. 에이전트들이 붙인 임시 영문명을 Play, App Store, 웹 게임 포털에서 검색해 보니 겹치는 게 많았습니다.

• 나사 퍼즐 블록의 임시명 “Screw Block Puzzle”은 비슷한 이름의 게임이 여럿 있어 Bolt Drop Fill로 바꿨습니다.
• 합체 수비대의 “Merge Defense”는 같은 이름이 웹 포털과 Play에 다 있어 Merge Gate Guards가 됐습니다.
• 버드 서바이버는 후보였던 다른 이름 하나도 이미 있어서 버리고 Wingbeat Survivors로 갔습니다.
• 당구 공성전은 임시명에 겹치는 게 없었지만 새로 지었고, 중간 후보 하나는 유명 게임과 비슷해 버렸습니다.
• 번호 낚시는 영문명에 로또라는 단어를 넣지 않았습니다.
• 띠 운세 공방, 오목 카드 대국, 윷 땅따먹기, 한글 연금술은 같은 이름이 없어 그대로 뒀습니다.

마작 원정의 Mahjong Quest는 검색 결과 같은 이름의 게임이 이미 여러 개 있었습니다. 대안 이름까지 제안됐지만 이미 확정한 이름이라 바꾸지 않았습니다. 확인 범위도 문서에 그대로 적혀 있습니다. 웹 검색 결과만 봤고, 상표 검색은 하지 않았습니다.

허브 수록

토스에는 새 앱을 하나씩 등록할 자리가 없어서, 신작은 이미 있는 허브 앱 안에 넣는 것이 규칙입니다. 허브가 어떻게 만들어졌는지는 게임 50종을 허브 9개로 묶은 글에 있습니다. 배치는 위 표 그대로입니다. 퍼즐카페에 3종, 오락실에 5종, 한판승부와 하루상식에 2종씩 들어갔습니다. 띠 운세 공방은 이름에 운세가 들어가지만 방치형 게임이라 비게임인 운세 허브가 아닌 오락실로 갔습니다.

예외가 둘 있습니다. 번호 낚시는 번호 뽑기 성격이라 사행성 반려 전례를 고려해 토스 허브에서는 보류하고, Play용 허브에만 넣었습니다. 9개 언어 문구 모두에 “당첨과 관계없어요”라는 고지를 유지했습니다. 당구 공성전은 처음에 올림픽 허브에 넣었다가, 가로 화면 게임만 모은 공성전 허브가 생기면서 그쪽으로 옮겼습니다.

허브 안에서는 게임마다 허브 기능에도 연결했습니다. 오락실 주간 리그는 게임별 기준점으로 점수를 정규화하는데, 숫자 뱀은 1500점, 버드 서바이버는 120초, 합체 수비대는 20웨이브를 기준점으로 잡았습니다. 박자 두더지의 기준점 15000은 문서에도 “추정”이라고 적혀 있습니다. 한판승부의 통합 등급에는 오목 카드 대국과 윷 땅따먹기가 판이 끝날 때 결과 신호를 보내도록 붙였습니다.

잘 안 된 것

검토 문서에 적힌 것 중 굵직한 것만 옮깁니다.

• 손으로 끝까지 해 본 판이 없었습니다. 13종을 한 시간 남짓에 병렬로 만들었고, 셸을 붙인 뒤 광고 버튼을 실제로 눌러 본 것은 역사 지도 찍기 하나였습니다. 마작 패 약 40px, 오목 칸 약 22px 같은 터치 크기도 실기기에서 보지 않았습니다.
• 밸런스 메모가 남았습니다. 나사 퍼즐 블록은 생성된 레벨이 탐색 없이 바로 풀려 쉬울 수 있고, 박자 두더지는 최고 등급이 빡빡합니다.
• 기획 메모와 구현이 어긋난 곳이 있습니다. 윷 땅따먹기는 체크리스트 메모에 “다른 사람의 기록 플레이와 겨룸”이라고 적혀 있었는데 구현은 AI 2~3명과의 대전입니다. 한글 연금술은 메모가 “실제 사전만”이었는데 실제로는 기존 앱 목록을 가져왔습니다. 오목 카드 대국은 보스 능력 하나를 승률 문제로 다른 능력으로 바꿨고, 분식집 머지는 리더보드 값을 브리프와 다르게 잡았습니다. 이런 변경은 에이전트 보고에는 있었지만 메인 요약에서 빠졌습니다. 제 판단으로는 보고를 250자로 묶은 대가입니다.
• 보고 숫자가 엇갈렸습니다. 13종 테스트 수가 커밋 메시지에는 186개, 메인 보고에는 198개로 적혔습니다. 개별 보고를 더해 보면 198개가 맞았습니다.
• 필요 없는 할 일이 남았습니다. 셸 에이전트들은 토스 콘솔에서 게임별 랭킹 정렬을 설정해야 한다고 적었는데, 허브 안에서는 게임별 토스 리더보드 제출이 꺼집니다. 할 일 목록에서 뺐습니다.
• 처음 고른 광고 자리 세 곳을 바꿨습니다. 합체 수비대, 숫자 뱀, 버드 서바이버의 보상형은 “되살리기” 형태였는데, 앞선 앱들의 실측 기록을 근거로 웨이브 재도전, 먹이 바꾸기, 시작 강화 고르기로 교체했습니다.

브리프를 아무리 촘촘히 써도 빈칸은 생깁니다. 이번에는 “임시 폴더”와 “보고에 무엇을 꼭 넣을지”가 빈칸이었습니다. 다음 브리프에는 공용 임시 폴더 금지와, 설계를 바꿨다면 보고 첫 줄에 적으라는 줄이 들어갈 차례입니다.

지금 상태

• 토스: 번호 낚시를 뺀 13종이 허브 다섯 곳(퍼즐카페, 오락실, 한판승부, 하루상식, 공성전) 안에 들어가 있습니다.
• Google Play: 14종 모두 아직 개별 앱으로는 나가지 않았습니다. 마작 원정부터 품질순으로, 주간 새 앱 생성 한도 안에서 하나씩 냅니다.
• 실기기 플레이 확인은 출시 뒤 테스트 번들과 디버그 빌드로 이어서 합니다.

만든 앱들은 GAMES와 APPS에 있습니다. 소식은 이 블로그와 인스타그램(@fadongkwon.soft)↗ (새 창에서 열림)에서 전해드립니다.

이 글은 2026년 11월 7~10일 작업 문서(공통 브리프, 셸 브리프, 결정 기록, 검토 정리)를 기준으로 썼습니다. 허브 배치와 이름은 이후 바뀔 수 있습니다.