외주로 앱을 만들어 본 창업자라면 한 번쯤 겪었을 거예요. 개발은 끝났다고 하는데, 정작 앱스토어에는 안 올라가 있는 상황. 애플 앱스토어와 구글 플레이는 앱을 올린다고 바로 공개되지 않아요. 애초에 구글 개발자 계정 만드는 법부터 막히면 심사는 시작도 못 해요. 심사(review)를 통과해야 하고, 이 심사에서 막히면 출시일은 기약 없이 밀립니다. 문제는 많은 외주 계약서가 “앱 개발 완료”까지만 정의하고, “스토어 출시 완료”는 누구 책임인지 적어 두지 않는다는 거예요.
그 틈에서 분쟁이 생깁니다. 외주사는 “코드는 다 만들었으니 잔금 주세요”라고 하고, 발주사는 “스토어에 안 올라갔는데 무슨 완료냐”라고 하죠. 2026년에도 이 다툼은 흔합니다. 그래서 앱 출시는 개발이 끝난 뒤가 아니라, 계약서를 쓰는 단계에서 미리 합의해 둬야 해요. 아래 8가지를 계약과 체크리스트에 넣어 두세요. 다만 계약서에 적기 전에 RFP 작성 단계에서 같은 내용을 먼저 밝혀야 업체들이 같은 기준으로 견적을 줍니다.
가장 먼저, 그리고 가장 자주 사고가 나는 부분이에요. 애플 개발자 계정(연 99달러)과 구글 플레이 콘솔 계정(최초 25달러)은 발주사 명의로 만들어야 합니다. 외주사 계정에 앱을 올리면, 나중에 외주사와 사이가 틀어졌을 때 앱 자체를 인질로 잡힐 수 있어요. 계약서에 “모든 스토어 계정은 발주사 소유, 관리자 권한은 발주사 보유”를 명시하세요.
완료의 기준을 ‘심사 승인 후 스토어에 공개된 상태’로 정의하세요. “빌드 업로드”가 아니라 “심사 통과 및 출시”가 완료 시점입니다. 그리고 첫 심사에서 리젝이 나도 그건 정상 과정이에요. 보통 1~2회 리젝은 흔하니, “최초 출시까지 외주사가 심사 대응을 책임지며, 정당한 리젝 사유는 무상으로 수정한다”는 문구를 넣으세요.
리젝의 상당수는 똑같은 사유에서 나와요. 애플 가이드라인 기준으로 자주 걸리는 것들이에요. ① 로그인이 필요한 앱인데 심사용 테스트 계정을 안 줌 ② 외부 결제를 유도하거나 인앱결제를 우회 ③ 개인정보 처리방침 URL이 누락되거나 깨짐 ④ 앱이 ‘미완성’으로 보이는 더미 화면이나 크래시 ⑤ 위치, 연락처 같은 권한을 요청하면서 이유 설명이 없음. 계약서에 “외주사는 출시 전 스토어 심사 체크리스트를 제출한다”를 넣으면 이 점검이 강제됩니다.
디지털 재화나 구독을 파는 앱이라면 애플과 구글의 인앱결제를 써야 하고, 수수료는 보통 15~30%예요. 이걸 모르고 자체 결제(PG)만 붙였다가 통째로 리젝되는 경우가 많습니다. 외주 계약 단계에서 ① 인앱결제 연동 범위가 견적에 포함됐는지 ② 구독, 복원, 환불 흐름까지 구현하는지 ③ 수수료를 감안한 가격 정책을 누가 검토하는지 정해 두세요.
앱 아이콘, 기기별 사이즈의 스크린샷, 앱 설명, 키워드, 미리보기 영상, 연령 등급 설문 — 이게 다 준비돼야 출시가 됩니다. 의외로 “코드는 끝났는데 스크린샷이 없어서” 출시가 일주일 밀리는 경우가 많아요. 누가 무엇을 만드는지(외주사 vs 발주사 마케팅) 계약 부속서에 표로 정리하세요.
애플 공식 안내로는 제출건의 90%가 24시간 안에 심사되고, 구글은 계정에 따라 최대 7일 또는 그 이상이 걸릴 수 있어요(각 스토어 공식 문서 기준, 아래 절에 출처). 하지만 리젝이 나면 수정과 재제출로 며칠이 추가됩니다. “마케팅 행사 날짜에 맞춰 출시”가 목표라면, 일정에 최소 1~2주의 심사 버퍼를 넣으세요. 계약서의 마일스톤도 “개발 완료”와 “스토어 출시”를 분리하고, 출시 마일스톤에 버퍼를 반영합니다.
심사에 제출하기 전에 애플 TestFlight, 구글 내부 테스트 트랙으로 실제 기기에서 한 번 돌려야 해요. 발주사가 직접 베타 빌드를 받아 핵심 시나리오(가입, 결제, 핵심 기능)를 확인하는 단계를 계약에 넣으세요. 심사관이 발견할 크래시를 우리가 먼저 잡는 게 훨씬 쌉니다.
출시가 끝이 아니에요. 출시 직후 치명적 버그가 나오면 누가, 며칠 안에 수정 빌드를 올리나요? “출시 후 30일간 긴급 버그는 무상으로 24시간 내 대응하며 스토어 재심사 대응을 포함한다”처럼 하자보수 범위에 출시 후 대응을 명시하세요. 인수인계 체크리스트에 스토어 계정과 인증서, 서명 키도 꼭 포함하고요.
세 사례 모두 계약서에 한 줄만 더 있었으면 막혔을 일이에요.
애플 공식 안내 기준으로 제출건의 90%가 24시간 안에 심사됩니다(Apple Developer, App Review). 체감보다 빠른 숫자인데, 일정이 밀리는 이유는 심사 자체가 아니라 그 앞뒤에 있어요.
발주자가 일정을 잡을 때 섞어 쓰면 안 되는 구간이 셋이에요. 빌드 업로드 → 제출 → 심사 → 출시인데, 90%/24시간은 이 중 심사 구간 하나에만 해당해요. 스크린샷·설명·연령 등급 설문이 안 끝나면 제출 자체가 안 되고, 리젝이 나면 수정과 재제출로 처음부터 다시예요.
| 구간 | 누가 하나 | 막히는 전형적 이유 |
|---|---|---|
| 빌드 업로드 | 개발사 | 인증서·프로비저닝 만료, 계정 권한 없음 |
| 제출 준비 | 발주사(마케팅) | 스크린샷·설명·개인정보 처리방침 URL 미비 |
| 심사 | 스토어 | 애플 90%가 24시간 내 · 구글은 계정에 따라 최대 7일 이상 |
| 출시 | 발주사 | 수동 출시로 걸어 두고 아무도 버튼을 안 누름 |
그래서 심사 기간을 일정에 넣을 때는 「심사 N일」이 아니라 「리젝 1회분」을 넣어야 해요. 리젝은 예외가 아니라 기본값에 가깝습니다.
애플은 심사 촉진 요청(expedited review)을 받아요. 공식 안내는 두 경우를 듭니다 — 치명적 버그 수정(현재 버전에서 그 버그를 재현하는 단계를 같이 적어야 해요)과 행사 연계 앱(행사명·날짜·앱과의 관계를 적어야 해요). 아무 때나 쓰는 카드가 아니라서, 외주 계약서에 “촉진 요청은 누가 어떤 기준으로 넣는다”를 미리 적어 두는 편이 낫습니다.
리젝 사유에 동의할 수 없으면 App Review Board 이의 제기가 있어요. 공식 안내는 제출 건당 한 번만, 추가 자료 요청에 먼저 답한 뒤, 가이드라인 어느 조항에 어떻게 부합하는지를 구체적으로 쓰라고 안내합니다. 감정적인 재제출보다 이쪽이 빠릅니다.
구글 공식 문서는 일부 개발자 계정에 대해 더 꼼꼼히 검토하며, 그 결과 심사가 최대 7일 또는 예외적으로 그 이상 걸릴 수 있다고 밝히고 있어요(Google Play Console 고객센터). 같은 앱이라도 계정에 따라 기간이 달라진다는 뜻이에요.
외주에서 이게 문제가 되는 지점은 분명해요. 개발사가 급하게 만든 신규 개인 계정으로 올리면, 계정 자체가 검토 대상이 되어 일정이 통째로 흔들립니다. 신규 개인 계정에는 비공개 테스트 요건도 따로 붙어요. 계정을 어느 명의로 언제 만들어 둘지는 구글 개발자 계정 만드는 법에 정리해 뒀어요.
| 상황 | 일정에 반영할 것 | 계약서에 적을 것 |
|---|---|---|
| 발주사 조직 계정이 이미 있음 | 심사 버퍼 + 리젝 1회분 | 계정 명의는 발주사, 개발사는 권한만 |
| 계정을 이번에 새로 만듦 | 계정 개설·검토 기간을 별도로 | 계정 개설 완료일을 마일스톤으로 분리 |
| 개발사 개인 계정으로 올림 | 🔴 권하지 않음 | 이전 비용·책임을 명시하거나 착수 전 교체 |
| 행사 날짜가 고정 | 행사 2주 전 제출 목표 | 촉진 요청 주체와 기준 |
정리하면 애플은 심사가 빠르고 구글은 계정 상태가 변수예요. 두 스토어를 같은 일정표에 묶어 두면 느린 쪽에 전부 끌려갑니다. 출시일을 하나로 잡더라도 제출일은 따로 잡으세요.
① 스토어 계정 명의가 발주사인가 ② ‘출시 완료’의 정의가 계약서에 있는가 ③ 심사용 테스트 계정과 개인정보 처리방침 URL이 준비됐는가 ④ 인앱결제 정책을 확인했는가 ⑤ 스크린샷과 설명 등 등록 자산 담당자가 정해졌는가 ⑥ 일정에 심사 버퍼 1~2주가 있는가 ⑦ TestFlight 사전 검증을 했는가 ⑧ 출시 후 30일 긴급 대응이 합의됐는가. 여덟 개 중 막히는 항목이 있다면, 개발이 끝나기 전에 지금 합의하세요.
포텐랩은 30개가 넘는 프로젝트를 97% 수행완수율로 마무리해 왔어요. 그 비결은 화려한 코드가 아니라, 출시와 인수인계까지를 처음부터 계약에 넣고 Notion으로 매일 투명하게 공유하는 일하는 방식에 있습니다. 앱 출시를 앞두고 있거나 외주 계약을 검토 중이라면, 포텐랩 포트폴리오를 살펴보고 상담을 남겨 주세요. 코드가 끝나는 날이 아니라, 스토어에 무사히 올라가는 날까지 함께 갑니다.