AI 활용기: 앱 공장을 여러 개 만들다가 하나로 합쳤다
표시 날짜는 이 글이 다루는 작업의 대표 기록일이며, 당시 발행된 글을 뜻하지 않습니다. 이후 회고와 적용 방법은 2026년 9월에 정리했습니다.
여러 분야의 앱을 동시에 만드는 사람에게, 공장을 통째로 복사하는 방식이 언제 한계에 부딪히고 무엇부터 공통 엔진으로 묶어야 하는지 보여준다.
9월 7일 통합에서 기능형·신앙·심리처럼 콘텐츠 기준이 다른 부분만 프로필로 남기고, 7단계 공정과 검사 절차는 공통 엔진으로 옮겼다. 진행표도 손으로 고치는 문서 대신 공정 정의에서 자동으로 만들어지게 됐다.
지금 운영 중인 여러 프로젝트에서 ‘분야마다 다른 것’과 ‘항상 같은 것’을 표로 나눠 적어보고, 같은 것부터 하나의 정의로 합친다.
연재 목차
먼저 답하면
공장 하나를 새로 열 때마다 이전 공장 폴더를 통째로 복사하는 방식을 8월까지 썼다. 9월 7일 커밋(95b811b)에서 이 복사를 그만뒀다.
AI로 앱을 만들 때는 먼저 제작 속도에 눈이 간다. 그런데 앱과 공장이 늘어나니 다른 문제가 생겼다. 한쪽에서 고친 검사를 다른 쪽에도 옮겨야 했고, 같은 ‘완료’가 서로 다른 상태를 가리키기도 했다.
기본 순서는 기획, 조사, 명세, 디자인, 개발, 검증, 출시 준비였다. 앱 종류가 달라질 때마다 이 공정을 통째로 복사하는 방식을 계속 유지할 수 있을지가 문제였다.
공통 규칙과 분야별 판단 나누기
9월 7일에는 공통 엔진과 분야별 프로필을 나누는 통합이 기록됐다. 기능형·신앙·심리처럼 콘텐츠 기준이 다른 부분은 프로필에 두고 단계와 검사 절차는 함께 쓰는 방향이었다. 진행표도 따로 손으로 고치는 문서보다 공정 정의에서 만들어지도록 했다.
공통 결함을 고칠 자리는 줄어든다. 그렇다고 앱마다 제공할 효용까지 같아져서는 안 된다. 절차를 재사용하는 것과 제품을 복제하는 것은 다른 문제였다.
이미 제출 준비 단계에 도달한 앱을 보존하는 경계도 뒀다. 새 공정 규칙을 고치다가 이전 결과물까지 계속 흔들지 않으려는 구조다. 이 통합 자체가 앱의 심사 승인이나 매출을 뜻하지는 않는다.
AI에게 일을 많이 맡기려면 지시문만 길어지는 것으로는 부족했다. 지금 어느 단계인지, 무엇이 비었는지, 공통 문제를 어디서 고칠지 확인할 수 있어야 했다.
다시 공장을 만든다면 처음부터 함께 쓸 규칙과 제품별 판단을 나누려 한다. 같은 검사를 거치더라도 그 앱을 사용할 이유는 따로 만들어야 한다. 공통 엔진이 대신해주는 것은 거기까지가 아니었다.
공통 엔진을 나눌 때 확인할 경계
여러 앱의 공정을 합칠 때는 반복되는 단계와 제품별 기준을 따로 적는다. 빌드·파일 검사·진행표는 공통으로 두고, 어떤 문제를 풀 것인지와 콘텐츠의 적절성은 분야별로 남긴다. 앱마다 같은 이름의 검사 파일을 복사해두면 나중에 수정이 빠질 수 있다.
작은 검증은 공통 규칙 하나를 바꾼 뒤 서로 다른 분야의 시험 앱에서 같은 변경을 읽는지 보는 것이다. 반대로 특정 분야의 조건이 다른 분야까지 영향을 주지 않는지도 확인한다. 과거 제출본은 동결하고 새 공정의 결과와 구분한다.
이 구조는 규칙을 유지할 자리를 줄이는 데 도움이 된다. 하지만 사용 이유나 디자인 판단을 공통화해서는 제품이 비슷해질 수 있다. 자동화할 절차와 매번 새로 판단할 부분의 경계를 문서에 남기는 것이 먼저다.