앱 공장 0화 – AI 에이전트에게 앱 개발을 통째로 맡겨봤습니다

안녕하세요. 앱 공장이라는 이름으로 앱을 만들고 있는 조현철입니다.

앱 공장이라고 이름을 붙이고 나니 조금 거창해 보이긴 합니다. 실제로 제가 하는 일은 오늘 만들 만한 주제를 찾는 명령을 실행하고, 그 주제로 앱을 만들어 달라는 명령을 실행하는 것입니다. 그 뒤의 조사, 검증, 기획, 디자인, 개발, 테스트와 배포는 AI 에이전트가 이어서 진행합니다.

처음부터 이런 형태를 생각했던 것은 아닙니다. 예전에 Android로 만든 앱들이 하나둘 늘어나면서 유지보수가 점점 버거워졌고, 그 문제를 해결하려다 보니 지금의 구조까지 오게 되었습니다. 이번 글은 앱 공장 시리즈의 0화로, 왜 이걸 만들게 되었고 현재 어디까지 왔는지를 정리해 보려고 합니다.

1. 시작은 유지보수 문제였습니다

앱이 두세 개일 때는 각각 관리해도 크게 문제가 없었습니다. 광고 라이브러리를 올리면 앱마다 같은 코드를 고치고, 디자인을 바꾸면 또 앱마다 수정했습니다. 조금 귀찮기는 해도 할 만했습니다.

그런데 앱이 다섯 개를 넘어가니 손으로 감당하기가 어려워졌습니다. 한 앱에서 고친 내용을 다른 앱에 빼먹기도 했고, 같은 기능인데도 앱마다 구현이 조금씩 달라졌습니다. 새 앱을 하나 만드는 시간보다 이미 만든 앱들을 계속 관리하는 시간이 더 신경 쓰이기 시작했습니다.

그래서 앱을 하나 더 만드는 대신 공통으로 사용할 구조를 먼저 만들어 보기로 했습니다.

2. 1기 – 공통 구조를 먼저 만들었습니다

현재 앱 공장은 Flutter 모노레포로 구성되어 있습니다. 여러 앱에서 같이 사용하는 부분은 다섯 개의 패키지로 나눴습니다.

• core_ui는 디자인 토큰과 공통 UI를 관리합니다.
• core_ads는 광고의 종류와 노출 빈도를 관리합니다.
• core_storage는 앱 내부의 로컬 저장을 담당합니다.
• core_common은 앱별 설정 파일을 읽습니다.
• core_telemetry는 분석과 크래시 수집을 담당합니다.

앱 이름, 패키지 ID, 디자인 콘셉트, 광고를 보여줄 위치처럼 앱마다 달라지는 값은 assets/config/app.yaml 파일로 옮겼습니다. 화면 코드에서 광고 ID를 직접 알 필요도 없고, 공통 기능을 바꾸기 위해 여러 앱을 찾아다닐 필요도 없어졌습니다.

이 구조 위에서 이름추첨기와 번호추첨기 같은 기존 Android 앱을 Flutter로 다시 만들었고, 로또고와 콘지기도 함께 작업했습니다. 여기까지를 앱 공장 1기라고 부르고 있습니다.

이때까지만 해도 목표는 유지보수를 줄이는 것이었습니다. 공통 구조가 생기면서 앱을 만드는 속도도 확실히 빨라졌습니다. 그런데 한 달쯤 지나니 예상하지 못했던 다른 문제가 생겼습니다.

3. 만드는 건 빨라졌는데, 무엇을 만들지가 막혔습니다

구조를 아무리 잘 만들어도 주제가 없으면 새 앱을 만들 수 없습니다. 며칠 고민해서 아이디어를 하나 떠올려도 Play 스토어를 찾아보면 비슷한 앱이 이미 여러 개 있었습니다. 만들 수는 있지만 굳이 만들어야 할 이유를 설명하기 어려운 경우도 많았습니다.

앱 구현은 빨라졌는데 아이디어를 찾고 검증하는 데 더 많은 시간이 들기 시작했습니다. 여기서 질문을 조금 바꿔봤습니다.

사람이 아이디어를 계속 짜내는 대신, 조사부터 개발까지 AI가 맡으면 더 나은 결과가 나올 수 있을까?

그리고 조건을 하나 더 붙였습니다. 빨리 만드는 것만이 아니라 완성도도 같이 유지해야 했습니다. 비슷한 앱을 템플릿으로 찍어내면 개발은 빠를 수 있지만 Google Play의 반복 콘텐츠 정책에서 문제가 될 수 있습니다. 앱 하나가 아니라 개발자 계정 전체가 위험해질 수 있는 부분이라 이 조건은 양보할 수 없었습니다.

4. 2기 – AI 에이전트에게 전체 과정을 맡겼습니다

지금 제가 직접 입력하는 명령은 크게 두 개입니다.

/topic-scout
/factory-autobuild <선택한 주제>

/topic-scout는 한국의 현재 이슈와 검색 수요, 경쟁 앱, 사용할 수 있는 데이터가 있는지를 조사합니다. 후보가 나오면 기존 앱들과 겹치지 않는지도 같이 확인합니다.

주제가 정해지면 /factory-autobuild가 아이디어 검증, 제품 기획, 브랜딩, 화면 설계, Flutter 구현, 에뮬레이터 QA와 테스트 배포를 이어서 진행합니다. 처음에는 각 단계가 끝날 때마다 제가 확인해야 하지 않을까 생각했는데, 그렇게 하면 결국 사람이 계속 대기해야 했습니다. 그래서 되돌릴 수 있는 작업은 자동으로 진행하고 외부에 공개되는 지점에서만 멈추도록 기준을 정했습니다.

AI가 만든 결과를 같은 AI가 그대로 통과시키지 않도록 한 것도 중요했습니다. 코드처럼 기계적으로 검사할 수 있는 것은 테스트와 스크립트가 확인하고, 차별화처럼 답이 하나가 아닌 항목은 작성자와 다른 검증자가 따로 심사합니다. 기각됐을 때는 무시하고 진행하는 것이 아니라, 왜 기각됐는지를 다시 입력으로 사용해 다른 방향을 설계합니다.

이 방식으로 가림노트, 모임각, 오늘빨래, 연표의 달인, 하루퍼즐, 계산근육, 문장수리소, 드립공작소를 만들었습니다. 같은 저장소와 공통 패키지를 사용하지만 앱의 핵심 기능과 디자인은 겹치지 않도록 했습니다. 직전에 사용한 디자인 콘셉트를 다시 선택하면 검증 단계에서 통과하지 못하게 만든 것도 이 때문입니다.

5. 현재까지의 결과

영상 공개 시점을 기준으로 앱은 모두 12개가 되었습니다. 이 중 10개를 Google Play에 올렸고 나머지 2개는 아직 올리지 않은 상태입니다.

• 공장이 새로 만든 앱 7개는 신규 등록 심사를 받았습니다.
• 기존 앱 3개는 Flutter와 공장 구조로 옮긴 뒤 업데이트 심사를 받았습니다.
• 10개 모두 반려 없이 통과했습니다.

반려가 없었다는 숫자만으로 공장이 완성됐다고 보기는 어려울 것 같습니다. 실제 사용자가 계속 사용하는지, 광고 수익이 나는지, 출시 후 업데이트를 얼마나 적은 비용으로 이어갈 수 있는지도 봐야 합니다. 그래도 같은 템플릿을 복제하는 방식이 아니라 앱마다 다른 이유를 만들기 위해 넣었던 장치들이 최소한 첫 번째 관문에서는 동작한 것으로 볼 수 있었습니다.

6. 앞으로 다룰 내용

이번 0화에서는 앱 공장을 만들게 된 배경과 현재 결과를 간단하게 정리했습니다. 이후 글에서는 공장이 실제로 어떻게 움직이는지부터 하나씩 다뤄보려고 합니다.

• 무엇을 AI에게 맡기고 어디에서 사람이 멈춰 세우는지
• 서버를 두지 않기로 한 결정이 앱 주제와 구조를 어떻게 바꿨는지
• 아이디어가 연속으로 기각됐을 때 어떤 식으로 다시 설계했는지
• AI 심사원이 모든 결과에 높은 점수를 주는 문제를 어떻게 막았는지
• 배포가 끝난 뒤 측정과 개선을 다시 공장에 넣는 방법
• 같은 실수가 두 번 나오면 문서가 아니라 스크립트가 막게 만든 과정

앱을 만드는 이야기이긴 하지만, AI 에이전트에게 일을 어디까지 맡겨야 할지 고민하시는 분들에게도 참고가 될 수 있을 것 같습니다. 다음 글에서는 두 명령 뒤에서 어떤 단계들이 이어지는지 앱 공장의 전체 구조부터 정리해 보겠습니다.

---