앱 공장 7화 – 통과시키기보다 떨어뜨리도록 검증 관문을 만든 이유

1. 앱 하나가 아니라 계정 전체를 봐야 했습니다

저도 앱을 하나씩 만들 때는 이번 앱이 잘 동작하는지를 먼저 봤습니다. 하지만 같은 개발자 계정으로 여러 앱을 계속 올리면서 판단 기준이 달라졌습니다.

각 앱이 따로 보면 쓸 만해도 기능과 화면이 비슷한 앱이 계속 쌓이면 반복 콘텐츠처럼 보일 수 있습니다. 하나의 심사 반려로 끝나는 것이 아니라 나머지 앱의 심사와 개발자 계정에도 영향을 줄 수 있는 문제였습니다.

그래서 앱 공장의 아이디어 검증은 좋은 점을 찾아 통과시키는 관문보다, 계정에 위험할 수 있는 이유를 찾아 떨어뜨리는 관문에 가깝게 만들었습니다.

2. 후보를 직전 앱 하나와만 비교하지 않습니다

처음에는 새 후보를 직전에 만든 앱과만 비교했습니다. 지금은 후보가 나오면 현재 저장소에 있는 전체 앱의 포트폴리오 정보를 먼저 덤프합니다. 앱 이름, 핵심 기능, 디자인 콘셉트, 공통 패키지 밖에 남은 고유 코드가 비교 대상입니다.

‘기존 앱과 겹치지 않는다’는 문장만으로는 통과할 수 없습니다. 어떤 앱과 무엇이 다르고, 사용자가 다시 열 이유가 무엇인지 실제 포트폴리오 데이터를 인용해야 합니다.

직전 앱과 색상만 다르거나 데이터만 교체한 경우도 막습니다. 디자인 콘셉트는 로테이션 원장으로 관리하고, 사용할 수 있는 콘셉트가 바닥나면 새로운 콘셉트를 먼저 정의한 뒤 진행합니다.

3. 기계 REJECT와 주관 기각을 분리했습니다

앱 이름이 같거나 콘셉트 레시피가 중복되거나, 등록되지 않은 공통 UI를 사용하는 문제는 코드로 판단할 수 있습니다. 이런 경우에는 검사 도구가 exit code 2로 바로 REJECT합니다.

고유기능, 수요, 경쟁, 수익성은 코드 한 줄로 결정하기 어렵습니다. 이 항목은 작성한 에이전트와 다른 critic이 근거를 보고 채점합니다. 앱의 핵심 기능 중 최소 20%는 기존 포트폴리오와 달라야 한다는 기준도 함께 확인합니다.

두 종류를 분리한 이유는 고치는 방법이 다르기 때문입니다. 기계 중복은 이름이나 콘셉트를 실제로 교체해야 하고, 주관 기각은 지적받은 가치를 다른 방식으로 설계해야 합니다.

4. 애매하면 평균이 아니라 최소점을 사용합니다

여러 critic이 같은 후보를 다르게 평가할 수 있습니다. 한 명이 5점, 다른 한 명이 2점을 줬을 때 평균을 내는 방법도 생각했습니다. 하지만 그렇게 하면 무난한 점수처럼 보였습니다.

계정 보호 항목에서는 평균 대신 가장 낮은 점수를 채택합니다. 한 명이라도 반복 콘텐츠나 차별화 부족의 근거를 찾았다면 그 문제를 먼저 해소하고 다시 보는 편이 안전하다고 판단했습니다.

따라서 이 관문은 통과율을 높이도록 최적화되어 있지 않습니다. 기각 사유가 명확하지 않거나 근거가 없는 감점은 허용하지 않지만, 근거가 있는 위험을 다른 장점으로 상쇄하지도 않습니다.

5. REJECT를 자동 통과로 바꾸지 않습니다

자동화가 멈추는 것이 싫어서 일정 횟수 뒤 검증을 건너뛰면 계정 보호 관문이 의미가 없어집니다. 앱 공장에서는 REJECT를 무시한 채 다음 단계로 가는 경로를 두지 않았습니다.

대신 기각 사유를 해결한 다른 방향을 설계합니다. 같은 주제에서 해결할 수 없으면 다른 주제를 정찰합니다. 멈추지 않는다는 의미를 검증을 우회하는 것이 아니라 검증을 통과할 다른 입력을 찾는 것으로 바꿨습니다.

이 방식은 앱을 빨리 늘리는 데에는 불리할 수 있습니다. 하지만 공장의 목표는 앱 개수만 늘리는 것이 아니라 계속 출시할 수 있는 계정을 유지하는 것입니다.

6. 정리

앱을 많이 만들수록 검증 관문은 통과를 돕는 역할보다 위험을 먼저 찾는 역할이 필요했습니다. 전체 포트폴리오 비교, 고유기능 기준, 콘셉트 로테이션과 보수적인 점수 집계를 넣은 이유입니다.

다음 글에서는 이 관문을 AI가 심사할 때 생긴 또 다른 문제, 거의 모든 결과에 4점이나 5점을 주는 현상을 어떻게 줄였는지 정리해 보겠습니다.

---