처음 목표는 단순했다.
하루에 앱 하나를 만들어보자.
지금 다시 읽으면 조금 과장된 목표처럼 보인다. 앱 하나를 만든다는 건 코드만 작성하는 일이 아니기 때문이다. 무엇을 만들지 정해야 하고, 화면을 설계해야 하고, 개발하고, 테스트하고, 스토어에 올릴 준비도 해야 한다.
그런데 실제로 해보니 됐다.
그 사실이 아직도 조금 놀랍다.
코드를 빨리 만드는 것만으로는 공장이 아니었다
처음에는 AI가 코드를 빨리 작성하면 앱을 많이 만들 수 있을 거라고 생각했다.
실제로 코드가 나오는 속도는 빨랐다. 하지만 앱 하나가 끝났다고 말하려면 그 앞뒤에 더 많은 일이 남았다.
- 어떤 문제를 해결할지 정하는 기획
- 이전 앱과 겹치지 않는지 확인하는 검증
- 색과 글꼴, 화면 구조를 정하는 디자인
- 공통 코드와 앱 전용 코드를 나누는 개발
- 에뮬레이터에서 실제 화면을 확인하는 QA
- 광고와 분석, 스토어 등록정보를 연결하는 배포 준비
코드 생성만 자동화하면 이 과정 사이사이에서 계속 내가 불려 나왔다.
그래서 앱 코드를 더 잘 만들게 하는 것보다, 내가 앱을 만들 때 해오던 순서를 먼저 꺼내놓는 일이 필요했다.
내가 하던 일을 스킬로 옮겼다
기획할 때 무엇을 확인하는지 적었다.
디자인할 때 이전 앱과 같은 구성을 반복하지 않도록 기준을 만들었다. 개발할 때는 공통 패키지에 둘 코드와 앱 안에 둘 코드를 나누는 규칙을 넣었다. QA에서는 화면이 열린다는 것만 보지 않고 빈 상태, 오류 상태, 권한 상태까지 확인하도록 했다.
이 절차를 Claude Code 스킬로 하나씩 옮겼다.
현재 저장소에는 12개 앱 디렉터리와 21개의 작업 스킬, 5개의 공통 Flutter 패키지가 있다.
주제 조사
→ 아이디어 검증
→ 제품 기획
→ 브랜드와 화면 설계
→ 앱 생성
→ 개발과 에뮬레이터 QA
→ 출시 점검
→ Play 배포
→ 지표를 보고 다시 개선
각 단계가 다음 단계에 필요한 파일을 남기도록 연결했다. 기획이 끝나면 사람이 읽는 문서만 남는 것이 아니라 제품 정보와 마일스톤이 JSON으로 남았다. 개발이 끝났다는 말만 믿지 않고 분석, 테스트, 아키텍처 검사와 별도 검토 결과를 통과 증거로 요구했다.
스킬을 만들고 워크플로로 이어 붙였더니 생각보다 훨씬 잘 수행했다.
AI가 갑자기 더 똑똑해졌다기보다, 내가 매번 설명하던 순서와 판단 기준이 파일 안에 남았기 때문인 것 같다.
배포 파이프라인까지 붙이니 내가 할 일이 거의 없어졌다
처음에는 앱 코드가 만들어지면 그다음부터는 내가 직접 처리했다.
Firebase 프로젝트를 만들고, 광고 설정을 연결하고, 앱을 빌드하고, 스토어 등록정보와 정책 항목을 채웠다. 코드가 빨리 나온 만큼 이 구간이 더 크게 보였다.
그래서 배포 과정도 같은 흐름에 넣었다.
되돌릴 수 있는 비공개 설정은 자동으로 진행하고, 외부에 공개되거나 되돌리기 어려운 지점에서만 나에게 확인하도록 경계를 정했다. 앱별 설정은 app.yaml로 모으고, 광고 코드는 화면마다 직접 넣는 대신 placement 이름으로 선언했다. AAB 빌드와 업로드, 스토어 준비 상태 확인도 도구와 스킬로 연결했다.
이렇게 하니 내가 직접 해줄 일이 거의 없는 상태에서 앱 하나가 결과물로 나왔다.
정말 뚝딱 나오는 것처럼 보였다.
물론 실제로 아무 일도 하지 않은 것은 아니다. 그 전에 수많은 실패와 수정이 있었고, 실패할 때마다 다음 실행에서 같은 곳에 걸리지 않도록 절차를 바꿨다. 눈앞의 한 번을 자동화한 것이 아니라, 다음 앱에서도 다시 쓸 수 있게 만드는 시간이 더 길었다.
하루에 하나가 가능했던 데에는 내 계정 조건도 있었다
이 경험을 누구에게나 그대로 적용할 수 있는 공식처럼 말하고 싶지는 않다.
내 Google Play 개발자 계정은 신규 개인 개발자 계정에 적용되는 비공개 테스트 요건의 대상이 아니었다. 그래서 앱마다 테스터 12명을 모아 14일 동안 비공개 테스트를 유지한 뒤 프로덕션 액세스를 신청하는 단계를 거치지 않아도 됐다.
현재 Google Play 정책상 2023년 11월 13일 이후 생성된 개인 개발자 계정은 최소 12명의 테스터가 14일 동안 계속 참여한 비공개 테스트를 마쳐야 프로덕션 액세스를 신청할 수 있다.[1]
신규 계정이라면 하루에 하나씩 코드를 완성할 수 있더라도, 실제 스토어 공개 속도는 이 테스트 요건에 맞춰 달라질 수밖에 없다.
Firebase에서도 운영상의 한계가 나타났다.
나는 앱 하나당 Firebase 프로젝트 하나를 만들었다. 분석과 Crashlytics, Remote Config를 앱별로 분리하기에는 관리가 편했다. 그런데 앱이 10개쯤 쌓이자 프로젝트 생성 한도에 닿았고, 할당량 증설을 신청하는 과정이 필요했다.
Firebase 공식 문서도 프로젝트 생성 한도가 Firebase만의 별도 숫자가 아니라 Google Cloud 프로젝트 할당량과 연결되며, 필요한 경우 프로젝트 할당량 증가를 요청할 수 있다고 설명한다.[2] 내 계정에서 마주친 시점은 10개 안팎이었지만, 이 숫자를 모든 계정에 동일한 기본 한도라고 일반화할 수는 없다.
자동화가 잘 돌아가더라도 계정 정책과 외부 서비스의 할당량까지 사라지는 것은 아니었다.
결국 사람이 남은 곳은 코딩이 아니었다
앱 공장을 만들면서 사람이 할 일이 없어질 거라고 생각한 적도 있었다.
그런데 마지막까지 남은 일은 코드를 작성하는 일이 아니었다.
- 이 앱이 정말 필요한가
- 기존 앱과 충분히 다른가
- 어떤 실패까지 허용할 것인가
- 데이터가 없는데 개선됐다고 말해도 되는가
- 계정에 위험을 줄 수 있는 선택인가
- 지금 외부에 공개해도 되는가
이런 질문은 자동화할 수 없다는 뜻은 아니다. 실제로 일부는 기계 검사와 독립 검토 단계로 옮겼다. 다만 무엇을 기준으로 검사할지, 어느 지점에서 멈출지는 여전히 사람이 정해야 했다.
코드 작성이 빨라질수록 오히려 무엇을 왜 만들 것인지 결정하는 일이 더 크게 남았다.
하루에 앱 하나를 만드는 것은 가능했다.
그런데 매일 앱 하나를 만들 수 있다는 것과, 매일 앱 하나를 만들어야 한다는 것은 다른 질문이었다.
영상은 끝났고, 이제 공장을 남기려 한다
앱 공장 이야기는 0화부터 13화까지 영상과 글로 정리했다.
마지막 13화에서는 실수를 기록하는 데서 멈추지 않고, 같은 유형이 두 번 나오면 규약이나 코드 가드로 올리는 과정을 다뤘다.
앱 공장 13화 – 같은 실수를 두 번 하면 그때부터 사람이 지키는 규칙이 아니게 됩니다
이제 다음으로는 실제 앱을 복제하는 코드가 아니라, 앱을 만들던 공장의 구조를 보일러플레이트로 정리해 공개할 준비를 하고 있다.
영상에서는 내가 왜 이런 결정을 했는지를 설명했다.
저장소를 열게 되면 그 결정들이 실제 파일과 코드에서 어떻게 남았는지 다른 사람도 확인할 수 있을 것이다. 누군가는 지나치게 복잡하다고 할 수도 있고, 누군가는 필요한 스킬 몇 개만 떼어갈 수도 있다.
아직은 나도 잘 모르겠다.
하루에 하나가 정말 가능하다는 것은 확인했다.
이제 궁금한 것은, 이 공장이 내 손을 떠났을 때도 제대로 움직일 수 있느냐는 쪽이다.
답글 남기기