앱 공장 8화 – 기획서를 사람이 읽는 글로만 쓰면 자동화가 거기서 멈춥니다

1. 기획서를 잘 써도 에이전트는 일을 시작하지 못했습니다

앞선 7화에서 주제 하나가 검증 관문을 통과했습니다. 다음은 기획서를 쓰는 단계였는데 자동화가 여기에서 한 번 끊겼습니다.

사람은 기획서를 읽으며 이번 범위가 어디까지인지, 무엇이 되면 끝인지, 누가 결과를 판정할지를 문맥에서 알아냅니다. 에이전트는 그렇게 읽지 못했습니다. 더 위험한 것은 이해하지 못해 멈추는 것이 아니라 이해한 것처럼 진행한다는 점이었습니다.

그래서 사람이 읽는 문서와 기계가 실행하는 문서를 분리하기로 했습니다. 기획서를 더 길게 쓰는 문제가 아니라, 판단의 배경과 실행 규칙을 서로 다른 형식으로 옮기는 문제였습니다.

2. 기획 산출물을 세 종류로 나눴습니다

첫째는 사람이 읽는 기획서입니다. 왜 이 앱을 만드는지, 무엇을 빼기로 했는지처럼 결정의 배경이 들어갑니다.

둘째는 앱의 정체성 문서입니다. 이름, 패키지 이름, 고유 기능 한 문장, 디자인 레시피, 스토어 등록 정보처럼 웬만해서는 바뀌지 않는 값을 둡니다. 기획서와 정체성 문서는 사람이 읽을 것이므로 형식이 조금 느슨해도 됩니다.

셋째는 로드맵입니다. 이것은 기계가 하나씩 소진하는 작업 큐라 형식이 엄격합니다. 마일스톤마다 이번에 만들 범위와 합격 조건이 붙고, 에이전트는 아직 끝나지 않은 마일스톤을 찾아 조건을 하나씩 처리합니다.

영상에서 사용한 드립 앱의 로드맵은 240줄이고 마일스톤이 9개였습니다. 첫 번째 마일스톤에만 합격 조건이 5개 붙어 있었습니다.

3. 합격 조건 옆에 판정 주체를 적었습니다

마일스톤과 합격 조건만 적어두면 충분할 것 같았지만, 누가 판정하는지 빠져 있으면 에이전트가 자기가 만든 결과를 스스로 통과시켰습니다. 그래서 조건마다 판정 주체를 나타내는 꼬리표를 붙였습니다.

처음에는 두 종류였습니다. 정적 분석, 테스트, 아키텍처 검사, 에뮬레이터 실행처럼 코드로 확인할 수 있는 조건은 스크립트가 판정합니다. 다른 앱과 화면이 구별되는가처럼 코드로 재기 어려운 조건만 작성자와 분리된 심사자에게 넘깁니다.

실제로 운영해 보니 세 번째 종류가 필요했습니다. 재방문율 15%, 완주율 40%처럼 사용자가 앱을 쓰기 시작한 뒤에야 알 수 있는 조건입니다. 이것은 코드도 사람의 즉시 판단도 아니어서 지표라는 별도 꼬리표로 분리했습니다.

4. 228개 조건 중 62%는 코드가 판정했습니다

당시 만든 앱 8개의 로드맵을 모두 열어 세어 보니 마일스톤은 52개, 합격 조건은 228개였습니다.

• 코드 판정: 62%
• 사람 또는 주관 심사: 23%
• 출시 후 지표 대기: 15%

자동 판정이 절반 정도일 거라고 예상했는데 실제로는 더 높았습니다. 62%만큼은 에이전트가 사람을 부르지 않고 처리할 수 있었습니다. 꼬리표가 없었다면 매 조건을 물어보거나, 반대로 전부 스스로 통과시켰을 것입니다.

마일스톤도 최소 기능 8개, 고도화 35개, 지표 기반 5개, 데이터 갱신 4개로 나눴습니다. 최소 기능이 앱마다 정확히 하나씩 있었고, 실제 작업 대부분은 첫 출시 이후의 고도화였습니다.

5. 기획서 자체도 다음 단계로 가기 전에 검사했습니다

기획서와 로드맵의 필수 항목, 타입, 금지 규칙을 검사하는 스크립트를 두었습니다. 외부 데이터에 대체 경로가 없거나 스토어 등록 정보가 빠져 있으면 코드를 작성하는 단계로 넘어가지 못합니다.

스토어 문구를 기획 단계에서 검사한 이유는 마지막에 붙이는 장식이 아니라 검색 유입과 제품 설명의 일부라고 봤기 때문입니다. 중요하다고 문서에 적는 대신, 없으면 다음 단계로 못 가게 순서를 강제했습니다.

텔레메트리도 같은 시점에 정했습니다. 드립 앱에는 이벤트 12개가 있었고 재방문율과 완주율 임계값까지 기획 단계에서 기록했습니다. 데이터가 나온 뒤 기준을 정하면 판정이 아니라 사후 합리화가 되기 때문입니다.

분석 서버를 두지 않는 제약도 그대로 유지했습니다. 이벤트는 앱 안에 쌓고, 익명 ID와 첫 실행 날짜·방문한 날을 기기에 기록해 재방문율을 계산했습니다.

6. 디자인도 창작과 규격 생성을 분리했습니다

디자인 도구가 만든 그림 하나를 공장이 그대로 소비할 수는 없었습니다. 공장에는 정해진 크기와 형식의 아이콘·전경·스플래시 이미지가 필요했습니다.

창작은 디자인 도구가 맡고, 마스터 이미지를 고르는 일은 사람이 맡았습니다. 아이콘 1024픽셀, Android 12용 전경, 스플래시 로고처럼 정확한 규격을 만드는 작업은 결정적인 스크립트로 분리했습니다. 같은 입력이면 언제 실행해도 같은 결과가 나오게 했습니다.

마스터 이미지의 배경이 투명하지 않으면 아이콘 여백이 검게 채워지는 문제도 있었습니다. 눈으로 확인하는 단계까지 보내지 않고 스크립트가 불투명 이미지를 바로 거부하도록 했습니다. 잘못된 결과가 끝까지 간 뒤 되돌리는 것보다 앞에서 막는 편이 훨씬 쌌습니다.

7. 정리

기획 산출물을 세 종류로 나누고 합격 조건마다 판정 주체를 붙이자, 228개 조건 중 62%를 코드가 먼저 처리하게 됐습니다. 사람에게 묻지 않아도 되는 범위와 사람이 개입해야 하는 범위가 문서 안에서 드러났습니다.

하지만 주관 심사로 남은 23%를 누구에게 맡길지는 아직 남아 있었습니다. 다음 9화에서는 AI 심사원에게 채점을 맡긴 뒤 21개 관점이 모두 통과한 기록과, 실제로 통과를 막은 장치가 무엇이었는지 이어서 정리합니다.

---