// APP FACTORY · EP. 01
앱을 여러 개 만들어 보니 코드를 작성하는 시간보다 무엇을 만들지 정하고 내보낼 상태인지 판단하는 시간이 더 길었습니다. 주제 조사부터 검토용 배포까지 이어지는 앱 공장의 전체 구조를 정리했습니다.
1. 코드를 작성하는 시간이 가장 길지 않았습니다
지난 0화에서 제가 앱 공장에 입력하는 명령은 두 줄이라고 말씀드렸습니다. 이번에는 그 두 줄 뒤에서 실제로 어떤 일이 진행되는지 정리해 보려고 합니다.
앱 하나를 만든다고 하면 보통 화면을 그리고 기능을 붙이는 시간을 먼저 떠올립니다. 저도 처음에는 그 부분을 줄이면 앱을 빨리 만들 수 있을 거라고 생각했습니다. 그런데 앱을 여러 개 만들어 보니 코드는 생각보다 빨리 나왔습니다. 공통 구조가 잡힌 뒤에는 더 빨라졌습니다.
오히려 시간이 오래 걸린 것은 코드의 앞뒤였습니다. 무엇을 만들지 정하려면 비슷한 앱이 있는지 찾아봐야 했고, 백엔드 없이 만들 수 있는지도 확인해야 했습니다. 구현이 끝난 뒤에는 실제 기기에서 잘 움직이는지, 스토어 정책에 걸리는 부분은 없는지 다시 확인해야 했습니다.
그래서 자동화의 대상을 코딩에서 판단으로 옮겼습니다. 무엇을 만들지 고르는 판단과, 만들어진 결과가 내보낼 기준을 넘었는지 확인하는 판단입니다.
2. 저장소를 열면 앱보다 공장 설비가 먼저 보입니다
앱을 만드는 저장소라면 앱 코드가 대부분일 것 같지만, 이 저장소에서는 오히려 공장 설비가 본체입니다. 구조는 크게 네 부분으로 나눴습니다.
여러 앱이 함께 사용하는 공유 패키지 5개, 각 단계의 절차를 적어 둔 스킬 문서 21개, 검사와 배포를 담당하는 도구, 그리고 규약을 보여주는 예시 앱입니다.
공유 패키지는 화면 구성, 광고, 저장, 설정, 사용 기록을 담당합니다. 스킬 문서는 주제를 고르는 단계부터 스토어에 올리는 단계까지 에이전트가 따라야 할 순서와 통과 조건을 담고 있습니다. 사람이 읽고 참고하는 문서라기보다 에이전트가 실제로 실행할 운영 절차에 가깝습니다.
3. 첫 검토용 배포까지 여섯 단계를 거칩니다
파이프라인은 먼저 한국에서 지금 필요한 주제를 조사하는 것부터 시작합니다. 후보가 나오면 기존 앱과 겹치지 않는지, 사용자가 다시 열 이유가 있는지 검증합니다.
통과한 후보는 제품 기획과 로드맵으로 바뀌고, 브랜드 콘셉트와 로고를 정한 뒤 화면을 설계합니다. 그다음 앱을 스캐폴드하고 첫 기능을 구현합니다.
여기까지 끝나면 Firebase App Distribution으로 테스터에게 보냅니다. 처음에는 이걸 배포라고 부르니 스토어 출시와 헷갈리기도 했습니다. 앱 공장에서 첫 배포는 스토어 공개가 아니라 실제 기기에 설치해 검토할 수 있는 상태를 뜻합니다.
특히 아이디어 검증 단계에서는 실제로 네 번 연속 기각된 적도 있었습니다. 이전 같았으면 사람에게 다른 주제를 물었겠지만, 지금은 기각 이유를 다음 입력으로 사용해 다른 각도로 다시 설계합니다.
4. 첫 배포 뒤에는 반복 구간으로 들어갑니다
첫 배포 전까지는 앞 단계가 끝나야 다음 단계로 넘어가는 직선 구간입니다. 첫 배포가 끝난 뒤에는 로드맵의 다음 마일스톤을 하나씩 구현하고 검증하고 다시 배포하는 반복 구간으로 바뀝니다.
대화만으로 이 과정을 이어가면 세션이 바뀔 때 어디까지 했는지 잃기 쉽습니다. 그래서 상태는 product.json, roadmap.json, plan.md, state.json, audit.log.jsonl 같은 파일에 남깁니다.
파일을 보면 지금 어느 단계인지, 무엇을 통과했고 무엇이 실패했는지, 다음에 해야 할 일이 무엇인지 다시 계산할 수 있습니다. 에이전트가 기억력이 좋아서 이어가는 것이 아니라 저장소에 남은 상태를 읽고 이어가는 방식입니다.
5. 사람이 멈춰 서는 자리는 네 군데입니다
자동으로 진행한다고 해서 사람이 완전히 빠지는 것은 아닙니다. 제가 멈춰서 확인하도록 남겨 둔 자리는 네 군데입니다.
주제 재구성 시도를 정해 둔 횟수만큼 소진했을 때, 같은 문제로 세 번 계속 실패했을 때, 로그인이나 자격증명이 필요할 때, 그리고 스토어 심사 제출처럼 되돌리기 어려운 외부 공개 작업을 할 때입니다.
반대로 그 밖의 작업에서는 다음에 무엇을 할지 묻지 않도록 했습니다. 구현이 끝나면 검증하고, 실패하면 수정하고, 통과하면 다음 단계로 이동합니다. 이 경계를 정하지 않으면 자동화라고 해도 사람은 계속 화면 앞에서 대기해야 했습니다.
6. 정리
앱 공장의 핵심은 명령 한 줄로 코드를 많이 만드는 것이 아니었습니다. 코드 앞뒤에 있던 조사와 검증을 같은 파이프라인에 넣고, 상태와 통과 조건을 파일로 남기는 것이 더 중요했습니다.
이번 글에서는 전체 흐름을 먼저 살펴봤습니다. 다음 글에서는 이 파이프라인에서 무엇을 AI에게 맡기고 어떤 작업을 사람이 승인하도록 남겼는지 조금 더 자세히 다뤄보겠습니다.
답글 남기기