앱 공장 6화 – AI가 고른 앱 주제가 다섯 번 연속 기각당했습니다

1. 인기보다 좁은 기회를 찾기로 했습니다

앱 공장의 첫 칸은 구현이 아니라 주제 선정입니다. 앞선 글에서 반복 절차를 파일로 옮긴 과정까지 정리했지만, 무슨 앱을 만들 것인지는 여전히 비어 있었습니다.

처음에는 사람들이 많이 찾는 주제를 고르면 된다고 생각했습니다. 그런데 인기 주제는 이미 포화라 차별화 관문에서 막혔고, 살아남더라도 반복 콘텐츠 정책과 부딪혔습니다. 여기에 서버를 두지 않는다는 제약까지 겹쳤습니다. 제가 찾아야 했던 것은 인기 자체가 아니라 이 제약들이 만나는 좁은 기회였습니다.

후보는 수요, 실현성, 계정 안전, 광고 수익 적합이라는 네 축으로 점수를 냈습니다. 축을 더하지 않고 곱한 이유는 치명적인 결함을 다른 높은 점수가 덮지 못하게 하기 위해서였습니다. 계정 안전이나 실현성이 0이면 나머지 점수와 관계없이 즉시 탈락시켰습니다.

2. 첫 세 후보는 같은 축에서 떨어졌습니다

첫 번째 후보는 복지 혜택 자격 조회 앱이었습니다. 수요와 차별화는 통과했지만 한 번 조회하면 끝난다는 이유로 기각됐습니다. 자격은 몇 년에 한 번 바뀌고 신청은 일 년에 한 번인데, 그 사이에 앱을 다시 열 이유가 없었습니다. 알림이 앱을 대신해 버리는 구조이기도 했습니다.

두 번째는 매일 체조 앱이었습니다. 습관을 만드는 앱이지만 운동하는 동안에는 화면을 보지 않았습니다. 광고가 실릴 자리가 없었습니다.

세 번째는 갱년기 증상 기록 앱이었습니다. 유발 요인을 한 번 파악하고 나면 더 볼 것이 없었습니다. 기록형 앱처럼 보였지만 실제 사용 흐름은 한 번 보고 끝나는 조회형 앱과 비슷했습니다.

세 후보 모두 차별화는 통과했습니다. 문제는 광고 수익 적합이라는 마지막 축이었습니다. 같은 이유가 세 번 반복되고 나서야 우연이 아니라는 것을 알았습니다. 한 번 소비하면 끝나는 정보나 통찰은 광고 앱으로 성립하기 어려웠습니다.

3. 네 번째 기각에서 갱신 조건이 세 문장으로 남았습니다

네 번째 후보는 텃밭 재배 캘린더였습니다. 매주 할 일이 달라지니 갱신 신호가 있다고 생각했습니다. 심사원이 해부한 결과는 달랐습니다. 파종일에 시즌 전체 일정이 이미 정해지고, 첫날 화면을 저장해 두면 다시 열 필요가 없었습니다. 한 시즌이 지나면 사용자가 내용을 외우고, 겨울에는 넉 달 동안 사용 이유가 사라졌습니다.

달력이 넘어간다는 사실만으로는 갱신이 아니었습니다. 이 실패에서 세 조건이 남았습니다.

• 예측 불가: 내일 값을 오늘 알 수 없어야 합니다.
• 내재화 불가: 오래 써도 사용자가 머릿속으로 대체할 수 없어야 합니다.
• 연중 상시: 계절에 따라 사용 이유가 사라지지 않아야 합니다.

처음부터 설계한 체크리스트가 아니었습니다. 세 번 같은 자리에서 떨어지고, 네 번째 후보를 다시 뜯어본 뒤에야 기각 사유가 문장 세 줄로 바뀌었습니다.

4. 다섯 번째 후보는 체크리스트를 통과하고도 떨어졌습니다

다섯 번째 후보는 장바구니 소매가를 보여주는 앱이었습니다. 가격은 내일 값을 오늘 모르고, 아무리 써도 외울 수 없으며, 사계절 내내 바뀝니다. 앞선 실패로 만든 세 조건을 처음으로 깨끗하게 통과했습니다.

그런데 두 심사원이 모두 기각했습니다. 데이터를 가진 기관이 이미 무료 공식 앱을 운영하고 있었고, 우리가 추가하려던 고유 기능은 관심 품목 즐겨찾기 하나뿐이었습니다. 공식 앱이 같은 기능을 추가하면 차이가 바로 사라집니다. 공개 데이터 위에 화면을 하나 더 얹는 것만으로는 고유 기능이 되지 않았습니다.

경쟁 조사에도 구멍이 있었습니다. 유통업자용 도매 앱만 비교하고 같은 데이터로 만든 소비자용 공식 앱을 빠뜨렸습니다. 이후에는 공공 데이터를 사용하는 주제라면 데이터를 가진 기관이 직접 만든 공식 앱을 반드시 확인하도록 규칙을 추가했습니다.

세션 깊이도 부족했습니다. 관심 품목 몇 개의 등락을 확인하고 3초 만에 나가는 사용 흐름이라 광고가 노출될 시간이 없었습니다. 매일 열 이유와 화면에 머물 이유는 다른 문제였습니다. 체크리스트에는 네 번째 조건으로 세션 깊이가 추가됐습니다.

5. 실패를 줄이되 검증을 대신하지는 않았습니다

다음 후보부터는 기존 앱의 주제, 고유 기능, 디자인 콘셉트를 파일로 덤프해 심사 입력에 강제로 넣었습니다. 기존 데이터를 보지 않은 채 “새로운 주제”라고 말하는 주장은 무효로 처리했습니다.

그다음에는 이름과 콘셉트 중복처럼 기계가 확실히 판정할 수 있는 항목을 미리 검사했습니다. 사전선별과 뒤 단계의 검증이 같은 스캔 로직과 임계값을 사용하게 해 두 규칙이 서로 달라지지 않도록 했습니다.

다만 사전선별은 검증이 아닙니다. 확실히 거절될 후보를 일찍 걷어낼 뿐, 수요와 고유 기능이 충분한지는 다음 관문이 다시 판단합니다. 실제로 다섯 후보 모두 사전선별을 지난 뒤 다음 관문에서 떨어졌습니다.

6. 여섯 번째 후보가 연패를 끊었습니다

여섯 번째 후보는 한국어 데일리 퍼즐을 묶은 앱이었습니다. 심사원 세 명이 조건부 통과를 냈습니다. 퍼즐은 10분에서 15분 동안 사용자를 붙잡아 세션 깊이가 있었고, 순수한 놀이라 데이터 소유 기관과 경쟁하지 않았습니다. 날짜에 따라 매일 새로운 문제가 생겨 갱신도 계속됐고 기존 앱과 카테고리도 겹치지 않았습니다.

처음부터 바로 통과한 것은 아닙니다. 콘텐츠를 매일 만들어야 하니 서버 없이 운영할 수 없다는 이유로 한 번 거절됐습니다. 매일 생성하는 대신 1~2년 치를 미리 앱에 넣고 이후에는 정적 페이지로 조금씩 보충하는 구조로 바꿨습니다. 심사원 두 명이 배포 설정을 확인한 뒤 거절을 철회했습니다.

서버를 두지 않는 제약을 없앤 것이 아니라 그 제약 안에서 다시 설계한 결과였습니다.

7. 정리

다섯 번의 기각은 손실처럼 보였지만 지금도 후보를 거르는 체크리스트를 남겼습니다. 규칙은 처음부터 완성된 설계에서 나온 것이 아니라 실패를 따라다니며 자랐습니다.

다음 글에서는 주제를 통과시키기보다 기각을 기본값으로 둔 이유와, 그 기본값이 과하게 작동했을 때 무엇을 고쳤는지 이어서 정리하겠습니다.

---