앱인토스 미니앱 반려 대응기: 등록·표현·시장성을 나눠 보기

앱 심사 반려를 받으면 아이디어부터 의심하게 됩니다. 하지만 원인은 등록·표현·제품 가설로 나눠 봐야 합니다. 앱인토스 미니앱 등록 경험을 정리했습니다.

큰 맘먹고 개발한 앱 심사에서 반려 메일을 받으면 가장 먼저 "이 아이디어가 별로였나"라는 생각이 듭니다. 하지만 반려의 원인은 생각보다 자주 제품이 아니라 제출물 자체에 오류가 있기 때문이에요. 최근 앱인토스 미니앱을 여러 개 등록하면서 알게된 노하우를 공유해보겠습니다.

반려 메일을 과해석 하지 마세요

심사 피드백은 대개 짧습니다. "서비스 내용을 확인하기 어렵습니다", "수정 후 재검토가 필요합니다" 같은 문장입니다.

이것도 아니면 채팅으로 앱 설명을 해달라고 합니다.

문제는 이 문장을 읽는 우리가 스스로 긴 해석을 덧붙인다는 점입니다. 서비스가 매력이 없다는 뜻인가, 사용자가 없을 것이라는 뜻인가, 기능을 전부 바꿔야 한다는 뜻인가.

하지만 심사팀, 심사AI가 확인한 것은 사용자의 문제와 시장성 전체가 아니에요. 제출된 앱 정보, 아이콘, 소개 문구, 카테고리, 번들, 화면, 결과 표현입니다. 그중 하나가 불완전하면 서비스의 가능성과 무관하게 반려될 수 있습니다.

그래서 반려를 받았을 때 첫 질문은 "아이디어가 틀렸나?"가 아니라 "심사자가 무엇을 보고 판단했나?"여야 합니다. 이 순서를 바꾸면 대응이 훨씬 차분해집니다.

첫 번째 확인: 앱의 완성도

가장 먼저 볼 것은 콘솔에 실제로 등록된 정보입니다. 기획서나 저장소에 준비되어 있다는 사실만으로는 충분하지 않습니다.

세금을 계산하는 계산기 프로젝트를 점검했을 때도 코드와 계산 테스트, 로고 파일, 상세 설명은 각각 준비되어 있었습니다. 그런데 콘솔에 등록된 실제 앱 정보에서는 아이콘·설명·카테고리가 비어 있었습니다. 앱이 부족해서가 아니라, 앱 자체가 제품을 대신 설명하지 못했기 때문입니다.

여기서 필요한 점검은 단순합니다.

콘솔에 보이는 앱 이름과 번들 안의 표시 이름이 같은가
아이콘은 로컬 파일 경로가 아니라 콘솔에 업로드한 실제 이미지로 연결됐는가
서비스 소개, 카테고리, 키워드가 비어 있지 않은가
설명만 읽어도 사용자가 무엇을 입력하고 어떤 결과를 받는지 알 수 있는가
제출한 빌드가 최신 코드와 최신 설정을 포함하는가

특히 이름 불일치는 사소해 보여도 치명적입니다. 한 번은 앱은 번들 내부의 표시 이름과 콘솔에 등록된 앱 이름이 달라 반려된 적이 있습니다. 기능 오류가 아니라 사용자가 보는 서비스 정체성이 등록 정보와 맞지 않았던 문제였습니다. 이런 유형의 반려는 제품을 갈아엎을 일이 아니라, 제출 항목을 실제 서비스와 일치시키고 다시 검수받을 일입니다.

두 번째 확인: 서비스와 표현

등록 정보가 갖춰져 있는데도 반려된다면, 그다음은 결과 화면과 설명의 표현을 봐야 합니다.

"예상 세액 계산"과 "환급액 안내"는 비슷해 보이지만 심사 관점에서는 다르게 해석될 수 있습니다. 후자는 개인별 상황에 따라 달라지는 결과를 확정적으로 안내하거나, 세무 판단을 대신하는 서비스처럼 보일 여지가 있습니다. 실제 계산 로직이 같더라도 사용자가 읽는 문장이 서비스의 범위를 넓혀버리는 것입니다.

그래서 한 프로젝트에서는 "환급"이나 "돌려받을 금액" 같은 표현 대신 "예상 세액", "추가 납부 예상액", "차감 예상액"처럼 계산 결과의 한계를 드러내는 단어로 바꿨습니다. 이건 심사를 피하기 위한 말장난이 아니라, 서비스가 실제로 할 수 있는 일과 사용자가 기대하게 되는 일을 일치시키는 작업입니다.

표현을 점검할 때는 다음 기준으로 진행했습니다.

결과가 참고용 계산인지, 확정 판단처럼 읽히는지
사용자의 건강·법률·세금·금융 결정을 대신하는 것처럼 보이지 않는지
"조회", "진단", "추천", "보장" 같은 단어가 실제 기능보다 과한 약속을 만들지 않는지
결과 화면에 계산 기준, 제한 조건, 다음 확인 경로가 충분히 안내되는지

좋은 앱이라도 표현이 서비스와 다르면 심사가 지연됩니다. 반대로 표현을 정확히 정리하면 지체없이 바로 승인되기도 합니다.

세 번째 확인: 앱의 시장성 검증

반려가 등록이나 표현 문제였다고 해서, 아이디어가 반드시 시장성이 있다는 뜻은 아닙니다. 반려 원인과 제품 가설은 서로 다른 질문입니다.

등록 문제를 고치면 심사를 통과할 수 있습니다. 하지만 사용자가 정말 이 기능을 찾는지, 반복해서 쓰는지, 유입 비용보다 수익이 나오는지는 별도 검증이 필요합니다.

실업급여 계산기와 퇴직금 계산기 앱을 만들 때 초기에는 이 둘을 분리했습니다. 먼저 키워드 수요와 기존 앱 대비 검색량을 확인해 시장성을 봤습니다. 그다음 계산 기준, 결과 문구, 광고 진입 시점, 콘솔 등록 정보를 제품과 심사 기준에 맞게 설계했습니다.

심사 반려를 해결하는 일과 시장성을 판단하는 일을 섞으면, 둘 다 제대로 답하지 못합니다. "반려됐으니 시장성이 없다"는 결론도 성급하고, "심사만 통과했으니 잘될 것"이라는 결론도 성급합니다.

반려를 받은 뒤의 30분 점검 순서

다음에 반려를 받는다면 아이디어를 지우기 전에 30분만 이렇게 써보면 좋겠습니다.

먼저 10분 동안 콘솔을 봅니다. 기획 문서가 아니라 실제 심사 화면에서 이름, 아이콘, 설명, 카테고리, 제출 상태를 확인합니다.

그다음 10분은 심사 피드백의 단어를 그대로 분해합니다. "서비스 확인", "정책", "표현", "번들", "이름" 중 무엇에 가까운지 표시합니다. 추측으로 원인을 하나로 정하지 않습니다.

마지막 10분에는 앱을 처음 쓰는 사람의 눈으로 결과 화면을 읽습니다. 이 서비스가 어떤 입력을 받고, 어떤 결과를 보여주며, 어디까지가 참고 정보인지 20초 안에 이해되는지 봅니다.

이 과정이 끝난 뒤에야 다음 행동을 정합니다.

아이콘, 이름, 카테고리, 설명이 비어 있거나 어긋났다면 → 등록 문제로 수정
결과의 약속이 기능 범위를 넘는다면 → 표현 문제로 수정
기능은 명확하고 등록도 정상인데 수요 근거가 약하다면 → 제품 가설 재검토
둘 이상의 문제가 섞여 있다면 → 등록 → 표현 → 시장성 순서로 분리 대응

반려는 실패가 아니라 관찰값이다

작은 서비스를 계속 만들다 보면 반려는 피하기 어렵습니다. 문제는 반려 자체보다, 그 피드백을 너무 크게 해석하는 데 있습니다.

반려됐다고 너무 마음쓰지 마세요. 특정 제출물과 특정 표현이 현재 심사 기준에서 충분히 설명되지 않았다는 경우가 많거든요.

아이디어를 버리는 결정은 더 무거운 근거가 필요합니다. 실제 사용자 문제, 검색 수요, 반복 사용 가능성, 운영 비용, 수익 구조를 봐야 합니다.

반대로 심사 대응은 더 작고 구체적으로 해야 합니다. 실제 등록 정보가 채워졌는지, 이름과 아이콘이 일치하는지, 결과 문구가 기능의 경계를 지키는지부터 확인하면 됩니다.

만든 것을 쉽게 버리지 않되, 고집스럽게 밀어붙이지도 않는 것. 반려를 제품 문제·등록 문제·표현 문제로 나눠 보는 습관은 작은 서비스를 오래 운영하게 만드는 기본 장치입니다.

자주 묻는 질문

Q. 심사에서 반려되면 앱 아이디어를 바로 바꿔야 하나요?
A. 아닙니다. 먼저 실제 제출 정보와 반려 사유를 확인해야 합니다. 아이콘, 설명, 카테고리, 이름 불일치처럼 등록 미완성 문제라면 아이디어를 바꿀 이유가 없습니다.

Q. 심사 피드백이 너무 짧으면 어떻게 하나요?
A. 피드백 문구를 추측으로 확대 해석하지 말고, 콘솔의 실제 제출 정보와 결과 화면을 함께 점검하세요. 필요하면 심사 채널에 서비스의 입력, 결과, 한계를 짧게 설명해 확인을 요청하는 편이 낫습니다.

Q. 계산기 앱에서 특히 조심할 표현은 무엇인가요?
A. 확정적인 판단이나 보장을 암시하는 말입니다. "예상", "참고", "계산 기준"을 명확히 하고, 법률·세무·금융 결정을 대신하는 것처럼 보이는 표현은 피하는 것이 좋습니다.

Q. 등록 문제를 고치고 통과하면 시장성도 검증된 건가요?
A. 아닙니다. 심사 통과는 서비스가 제출 기준을 충족했다는 의미입니다. 수요와 재방문, 수익성은 출시 뒤 별도로 측정해야 합니다.

Q. 반려 이력이 반복되면 앱 자체에 불이익이 있나요?
A. 공식적으로 확인된 바는 없습니다. 다만 등록 정보와 표현을 미리 점검하면 반려 횟수 자체를 줄일 수 있습니다.