AppForge 회고: 빌드 성공과 제품 완성 사이에 있던 것들

앱을 자동으로 만드는 도구를 개발하면서 가장 크게 바뀐 것은 코드 생성 방식보다 완료의 기준이었다.

AppForge는 기획부터 개발, QA까지 단계가 이어지는 구조다. 그런데 실제 생성 경로를 실행했을 때 중간에 멈춘 문제가 있었고, 그 경로를 개선한 뒤에도 결과물의 제품 품질은 기대에 못 미쳤다. 파이프라인을 끝까지 통과하는 것과 내가 쓰고 싶은 앱이 만들어지는 것은 다른 문제였다.

이 글은 2026년 9월 30일~10월 1일의 AppForge 작업 대화를 바탕으로 정리한 회고다. 실행 결과는 당시 보고된 범위로 다루고, 설계 설명은 프로젝트의 코드·문서와 대조했다.

앱을 만드는 것보다, 만드는 과정을 다시 실행할 수 있어야 했다

AppForge는 터미널에서 제품 아이디어를 입력하면 여러 AI 작업자가 기획·디자인·개발·검증을 이어 가도록 만든 도구다. 공장의 제어부는 Rust이고, 생성되는 모바일 프로젝트는 별도 작업 공간에 둔다.

내가 실제 생성 경로에 넣은 사례는 캐주얼 퍼즐 게임 Pocket Flow였다. 유지보수하기 쉬운 그래픽과 작은 게임 범위를 원했지만, 작은 범위라고 해서 자동화의 실패 지점까지 작아지는 것은 아니었다.

9월 30일, 실행이 되지 않는 화면을 보고 요청을 바꿨다. 정상적으로 앱이 만들어지는지 직접 실행하고, 실패하면 수정한 뒤 다시 실행하라는 것이었다. 한 번의 코드 생성보다 실패 지점을 드러내는 반복 실행이 필요했다.

실제 앱 화면이 아니라 생성·검증·수정의 관계를 설명한 개념도다. 출시 완료를 나타내는 그림은 아니다.

실패는 모델 바깥에서도 생겼다

당시 실행·수정 기록에는 프롬프트의 내용을 다듬는 것만으로 해결되지 않는 문제가 여럿 남아 있다.

당시 드러난 문제	작업 흐름에 미친 영향	여기서 얻은 기준
서로 충돌하는 CLI 실행 옵션	AI 작업자가 시작하기 전에 실패	에이전트 호출 자체를 검증해야 한다
실행 중 붙여 넣은 긴 요구사항을 명령으로 해석	제품 요구사항이 다음 작업에 반영되지 않음	명령과 제품 입력의 경계를 분리해야 한다
Git 작업 공간 검사 관련 오류	생성된 프로젝트에서 작업 시작이 막힘	생성 작업 공간의 전제를 명시해야 한다
Android SDK 위치 탐지 실패	소스가 있어도 네이티브 빌드 불가	코드와 로컬 실행 환경을 함께 확인해야 한다
출시 보고서의 BLOCKED와 완료 상태가 불일치	아직 막힌 단계를 완료로 오해	프로세스 종료와 제품 판단을 구분해야 한다

각 항목은 당시 대화에 남은 문제·수정 보고다.

특히 마지막 문제가 중요했다. 작업자가 정상 종료했다는 것은 명령 실행이 끝났다는 뜻이지, 앱이 출시 가능하다는 뜻은 아니었다. 보고서에 문제가 남아 있는데 대시보드만 완료를 표시하면, 자동화는 실패를 감추는 도구가 된다.

exit 0과 PASS를 같은 것으로 취급하지 않기

확인한 현재 소스에는 Quality·QA·Release에서 PASS 판단 파일과 비어 있지 않은 보고서를 함께 확인하는 로직이 있다. 새 Quality 실행은 이전 QA 판단을 무효화한다. 다만 보고서 본문의 판단과 파일 값이 일치하는지, 근거가 정확한지까지 자동으로 검사하지는 않는다. 이는 소스 구조의 확인이며 현재 버전의 빌드·실행을 보증하는 결과는 아니다.

이 방식의 핵심은 파일 개수가 아니다. 어떤 코드 상태를 검증했는지에 맞춰 승인 상태도 갱신해야 한다는 것이다. 수정하기 전의 PASS를 수정한 뒤에도 그대로 쓰면, 검증하지 않은 결과물에 검증 표시를 붙이게 된다.

내가 이해한 완료 조건은 이렇게 나뉜다.

확인한 것	아직 증명하지 못하는 것
AI 작업자가 정상 종료함	요구사항을 만족하는 앱인지
테스트·빌드가 통과함	실제 화면에서 사용자가 막히지 않는지
시뮬레이터에서 앱이 실행됨	주요 사용자 흐름을 끝까지 쓸 수 있는지
스토어 자료가 준비됨	검토·서명·심사·출시가 완료됐는지

판단 파일도 실제로 수행한 검사와 보고서에 남긴 근거만큼만 믿기로 했다. PASS라는 문자열이 좋은 제품을 보장하지는 않는다. 다만 무엇을 확인하고 무엇을 확인하지 못했는지 분리할 출발점은 된다.

빌드 경로를 고친 뒤, 제품 품질이라는 다음 문제가 남았다

10월 1일 작업 보고에는 Android APK 생성과 iOS 네이티브 빌드, 시뮬레이터 실행이 기록됐다. 동시에 Release는 BLOCKED였고, UI 조작 검증도 건너뛴 부분이 있었다. SKIPPED는 PASS가 아니다. 따라서 이 결과를 “스토어 출시까지 완전 자동화했다”라고 요약하면 실제 경계를 지우게 된다.

그다음 내가 다시 한 질문은 품질에 관한 것이었다. 동작 경로가 나아졌는데도 결과물의 완성도가 낮았고, 의도한 모델 설정이 실제 호출에 적용됐는지도 확인할 필요가 있었다.

이때 요구한 변화는 “한 번 만들고 테스트”에서 “만들고 → 까고 → 다시 만들고”로의 전환이었다. 단순히 모델 이름만 바꾸는 것이 아니라, 만들어진 결과물을 비평하고 개선하는 루프를 작업 안에 넣자는 뜻이었다.

다만 당시 기록만으로는 모델 설정의 영향과 디자인 비평 루프의 효과를 분리해 판단하기 어렵다. 특정 모델이나 설정 하나가 낮은 품질의 원인이라고 단정할 근거는 없다. 당시 요청한 설정 변경 전체가 적용됐다고 이 글에서 주장하지도 않는다.

코드가 컴파일되는지와 제품이 이해하기 쉬운지에는 서로 다른 질문이 필요했다.

• 첫 화면에서 무엇을 해야 하는지 알 수 있는가?
• 핵심 조작에 피드백이 있는가?
• 실패한 뒤 다시 시작할 수 있는가?
• 빈 상태·오류 상태에서도 길을 잃지 않는가?
• 수정 후에도 앞서 통과한 흐름이 유지되는가?

이 질문들을 자동 평가로 어디까지 다룰 수 있는지는 여전히 개선해야 할 영역이다. 기술 검사와 제품 비평을 구분한 것은 결론이 아니라 다음 개발의 기준에 가깝다.

반복 실행에는 재개와 무효화가 함께 필요했다

실패할 때마다 이미 끝난 기획·개발을 전부 다시 돌리면 시간과 구독 사용량을 소비한다. 그래서 완료된 단계는 재사용하고 실패한 지점에서 이어 가는 구조가 중요했다.

하지만 단계를 건너뛰는 것만으로는 충분하지 않다. 제품 요구사항이나 코드가 바뀌었다면 그 변화의 영향을 받는 결과물과 검증 상태도 다시 확인해야 한다. 재개는 편의를 위한 기능이고, 무효화는 오래된 결과를 믿지 않기 위한 장치다.

자동화를 설계할 때 남기고 싶은 기록도 달라졌다. “작업 완료” 한 줄보다 어느 단계에서 어떤 산출물을 만들었는지, 무엇을 검증했는지, 다음 실행이 어디서 시작하는지가 유용했다. 여러 프로젝트를 오갈수록 이 기록은 작업 기억을 복구하는 비용을 줄이는 데도 연결된다.

출시를 사람에게 남기는 것은 자동화의 실패가 아니다

AppForge의 현재 설계는 스토어 초안 준비와 최종 제출을 구분한다. 외부 게시·업로드에는 대상과 산출물에 맞춘 별도 승인이 필요하고, 최종 심사 제출과 프로덕션 출시는 사람이 확인하는 경계로 남긴다.

앱 파일이 만들어졌다고 해서 개인정보처리방침, 서명, 스토어 메타데이터, 실기기 확인까지 해결된 것은 아니다. 자동으로 계속할 수 있는 작업과 계속하면 안 되는 작업을 구별해야 한다.

이번 작업에서 얻은 결론은 “AI에게 더 많이 맡기자”보다 구체적이다. AI가 무엇을 했는지 확인할 수 있고, 실패한 작업을 다시 실행할 수 있으며, 사람의 판단이 필요한 지점에서는 멈추는 시스템을 만들자.

다음 앱에서도 확인할 기준은 같다.

1. 실제 생성 경로를 한 번 이상 실행해 본다.
2. 소스 생성·빌드·실행·사용자 흐름 검증을 따로 기록한다.
3. 수정하면 이전 검증의 유효성도 다시 판단한다.
4. 기술적 통과와 제품 품질을 별도의 질문으로 검토한다.
5. 준비 완료와 외부 제출·출시 완료를 혼동하지 않는다.

앱 자동화의 가치는 성공 메시지를 빨리 만드는 데 있지 않았다. 실패와 미완료가 보이는 상태에서도 다음 작업을 이어 갈 수 있게 만드는 데 있었다.

관련 자료

• AppForge 소스와 작업 흐름
• 여러 프로젝트를 운영하며 느낀 작업 기억의 부담

편집 검토: 2026년 10월 2일 코드·문서를 읽기 전용으로 확인했다. 앱 빌드·실행·스토어 출시를 재검증하지 않았으며, 실행 결과는 당시 작업 보고를 기준으로 정리했다. 성능 향상·매출·출시 실적은 추정하지 않았다.