앱 출시는 외주 범위일까요 | 스토어 등록 6가지
개발이 끝나도 앱은 바로 안 열려요. 플레이스토어 심사는 약 7일, 앱스토어는 1～2주가 걸리고 거절도 흔해요. 개발자 계정 명의부터 재제출 책임까지, 계약 전에 문장으로 정해둘 6가지를 10년 넘게 앱을 운영해온 개발사 기준으로 정리했어요.
핵심 요약 — 개발 완료와 앱 출시는 다른 날이에요. 공개된 자료 기준으로 구글 플레이는 심사에 약 7일, 애플 앱스토어는 1～2주가 걸리고 거절도 드물지 않아요. 계약 전에 정해둘 건 여섯 가지예요. 개발자 계정 명의, 등록 작업 주체, 심사 자료 준비, 재제출 횟수, 거절 메일 수신자, 그리고 출시 이후 정책 변경 대응이에요. 앱을 직접 만들고 운영해온 개발사 기준으로 정리했어요.
“개발은 끝났다는데 왜 아직 앱이 안 보이죠?”
앱 프로젝트 막바지에 자주 나오는 질문이에요. 개발이 끝난 시점과 사용자가 내려받을 수 있는 시점 사이에는 생각보다 긴 구간이 있어요. 그 구간이 누구 일인지 계약서에 안 적혀 있으면 그때부터 이야기가 복잡해져요.
오늘은 그 구간을 나눠서 정리해볼게요.
1. 개발이 끝났는데 왜 출시가 안 될까요
만드는 일과 통과시키는 일이 다르기 때문이에요.
앱은 웹사이트처럼 올리면 바로 열리지 않아요. 구글과 애플이 각자 심사를 하고, 통과해야 스토어에 노출돼요. 공개된 자료 기준으로 구글 플레이는 대략 7일, 애플 앱스토어는 1주에서 2주 정도가 걸려요. 여기에 거절이 한 번 끼면 그만큼 더 늘어나요.
문제는 이 기간이 견적서에 잘 안 보인다는 거예요. 개발 일정에는 “8주”라고 적혀 있는데 그 8주가 개발 완료까지인지 출시까지인지가 흐릿해요. 오픈 날짜를 정해둔 프로젝트라면 이 차이가 곧바로 사고가 돼요.
2. 스토어 등록은 견적서 어디에 적혀 있나요
대개 안 적혀 있어요.
앱 개발 견적서는 보통 화면과 기능 단위로 쪼개져 있어요. 로그인, 목록, 상세, 결제 같은 식이죠. 스토어 등록은 화면이 아니라서 이 목록에 자리가 없어요. 그래서 견적에 들어갔는지 아닌지가 애매한 채로 계약까지 가는 경우가 많아요.
확인하는 방법은 간단해요. 견적서에서 이 세 항목이 보이는지 찾아보세요.
- 스토어 등록 대행 (초회 제출)
- 심사 대응 및 재제출
- 스토어 등록 자료 제작 (스크린샷·소개 문구)
세 번째는 특히 자주 빠져요. 스토어에 올라가는 스크린샷과 소개 문구는 디자인 작업이자 마케팅 작업이라 개발 범위와 성격이 달라요. 개발사가 만들어주는 곳도 있고 발주사가 준비하는 곳도 있어요. 어느 쪽이든 정해두기만 하면 돼요.
3. 개발자 계정은 누구 이름으로 만들어야 할까요
발주사 명의가 원칙이에요.
개발사 계정으로 앱을 올리면 당장은 편해요. 개발사가 이미 계정을 갖고 있으니 절차가 빠르거든요. 그런데 나중에 문제가 두 가지 생겨요.
첫째, 앱을 다른 계정으로 옮기는 절차가 번거로워요. 개발사를 바꾸거나 직접 운영하려고 할 때 이 단계에서 시간이 많이 들어요.
둘째가 더 중요해요. 심사 거절 메일이 계정 주인에게만 가요. 왜 거절됐는지를 발주사가 직접 못 보게 되는 거예요. 개발사가 전달해주긴 하지만, 원문을 못 보면 사유가 기능 문제인지 정책 문제인지 판단하기 어려워요.
운영사 Tip — 저희는 계정 생성과 결제 수단은 발주사가 준비하고, 개발사에는 작업 권한만 초대하는 형태를 권해요. 소유는 발주사가, 작업은 개발사가 하는 구조예요. 계정 소유권을 계약 전에 확인하는 방법은 운영 이관 구조 확인법에 더 자세히 적어뒀어요.
참고로 구글은 2026년 4월부터 플레이 콘솔 정책을 바꿔서 앱을 등록하기 전에 안드로이드 개발자 인증을 먼저 받도록 하고 있어요. 계정 준비에 걸리는 시간이 예전보다 늘었으니 개발 막바지에 시작하지 마시고 착수 무렵에 미리 만들어두시는 게 좋아요.
4. 심사는 왜 거절될까요
기능 문제보다 준비물 문제가 많아요.
공개된 심사 사례들을 보면 거절 사유는 대체로 비슷한 자리에서 반복돼요.
| 자주 나오는 거절 사유 | 실제로 필요한 준비 |
|---|---|
| 로그인 화면에서 더 진행이 안 됨 | 심사용 테스트 계정을 제출 자료에 첨부 |
| 스크린샷·소개 문구가 실제와 다름 | 실제 화면 기준으로 자료 재작성 |
| 앱 이름과 개발자 정보가 안 맞음 | 계정 명의와 앱 표기 통일 |
| 사용자가 글·사진을 올리는데 신고 기능이 없음 | 신고·차단·삭제 기능 추가 |
| 실행 중 오류가 발생함 | 제출 전 실기기 점검 |
네 번째 항목을 눈여겨보세요. 이건 자료 문제가 아니라 기능을 더 만들어야 하는 사유예요. 사용자가 콘텐츠를 올릴 수 있는 앱인데 신고와 차단 기능이 요구사항에 없으면, 심사 단계에서야 추가 개발이 생겨요. 그때는 이미 일정이 없어요.
그래서 요구사항 정리 단계에서 “사용자가 무언가를 올릴 수 있는가”를 한 번 확인하시면 좋아요. 답이 예라면 신고 관련 기능을 처음부터 범위에 넣어야 해요.
5. 거절되면 누가 다시 제출하나요
이 문장이 계약서에 없으면 대개 다툼이 생겨요.
거절 사유가 개발사 쪽 실수면 개발사가 고치는 게 맞아요. 그런데 사유가 자료 문제거나 정책 해석 문제면 애매해져요. 소개 문구를 발주사가 썼는데 그게 과장 표현으로 걸렸다면 누구 책임일까요. 실제로 이런 경우가 꽤 있어요.
정해두면 좋은 건 두 가지예요.
- 재제출을 몇 회까지 개발사가 대응하는지 (예: 초회 등록 + 재제출 2회 포함)
- 그 이상은 어떤 기준으로 계산하는지 (시간제 추가 정산 등)
숫자로 적어두면 서로 편해요. 개발사도 무한정 대응을 떠안지 않아서 견적을 정확히 낼 수 있고, 발주사도 추가 비용이 언제 생기는지 미리 알 수 있어요. 앱 외주 계약에서 미리 확인할 항목들은 앱 개발 외주 계약 전 체크리스트에 함께 묶어뒀어요.
지금 준비 중인 앱이 어느 단계까지 계약에 들어가 있는지 헷갈리시면 견적서만 보고도 짚어드릴 수 있어요. 범위부터 같이 확인해볼까요 →
6. 출시 이후에도 스토어 일은 계속 생겨요
한 번 올리면 끝나는 일이 아니에요.
구글과 애플은 정책을 주기적으로 바꿔요. 개인정보 처리 방침 표기 방식이 바뀌거나, 지원해야 할 운영체제 버전 기준이 올라가거나, 새 권한 항목을 설명하라고 요구하는 식이에요. 기한 안에 대응하지 않으면 업데이트가 막히거나 노출이 중단되기도 해요.
이건 기능 개선이 아니라서 유지보수 계약에 잘 안 들어가요. 그런데 실제로는 매년 몇 번씩 생겨요.
직접 운영해보니 — 저희는 자체 SaaS 4종을 직접 운영하고 있어서 이 알림을 계속 받는 쪽이에요. 그래서 앱 프로젝트를 맡을 때 유지보수 범위에 스토어 정책 대응을 따로 한 줄 넣어요. 만들어서 넘기기만 했다면 굳이 안 넣었을 항목인데, 넘겨받아 운영해보면 이게 매년 실제로 손이 가는 일이라는 걸 알게 되거든요.
기기 연동이 있는 앱이면 여기에 하나가 더 붙어요. 저희가 진행한 코닥 인스턴트 프린터 연동 앱은 2020년 2월에 출시했고 개발 기간은 2개월, 기획 1명·디자인 1명·개발 2명이 투입됐어요. [제조 · App] 이 프로젝트에서 가장 까다로웠던 건 화면이 아니라 아이폰·안드로이드의 수많은 기기와 인화 장치 사이의 연결과 오류 처리였어요. 이런 앱은 새 단말이 나올 때마다 확인할 조합이 늘어나요. 자세한 내용은 코닥 프린터 앱 블루투스 연동 사례에 적어뒀어요.
7. 계약 전에 문장으로 정해둘 6가지
여기까지를 표로 모으면 이래요. 견적서를 받았을 때 이 여섯 줄이 있는지 보시면 돼요.
| # | 정해둘 것 | 권장 형태 |
|---|---|---|
| 1 | 개발자 계정 명의 | 발주사 명의, 개발사는 작업 권한만 |
| 2 | 스토어 등록 주체 | 초회 제출을 누가 하는지 명시 |
| 3 | 등록 자료 제작 | 스크린샷·소개 문구를 누가 만드는지 |
| 4 | 재제출 대응 횟수 | 숫자로 (예: 2회 포함, 초과 시 별도) |
| 5 | 거절 메일 수신 | 발주사도 받을 수 있게 계정·담당자 등록 |
| 6 | 출시 후 정책 대응 | 유지보수 범위에 한 줄로 포함 |
흔한 실수 — 다섯 번째가 가장 많이 빠져요. 계정 명의를 발주사로 해뒀어도 알림 수신자를 개발사 담당자만 등록해두면 결과는 같아요. 계정을 만들 때 수신 이메일을 한 번 확인해보세요.
8. 자주 묻는 질문 (FAQ)
앱 스토어 등록은 개발 견적에 보통 포함되나요?
포함되는 곳도 있고 아닌 곳도 있어요. 견적서에 ‘개발’까지만 적혀 있으면 등록과 심사 대응은 빠져 있을 가능성이 높아요. 초회 등록과 재제출을 몇 회까지 포함하는지 숫자로 적어달라고 요청해보세요.
개발자 계정은 우리 회사 이름으로 만들어야 하나요?
네, 발주사 명의를 권해요. 나중에 앱을 옮기기 쉽고, 무엇보다 심사 거절 메일을 직접 볼 수 있어요. 계정과 결제 수단은 발주사가 준비하고 개발사에는 작업 권한만 주는 형태가 안전해요.
심사에서 거절되면 출시가 얼마나 밀리나요?
수정하고 다시 제출하면 심사가 처음부터 다시 시작돼요. 사유에 따라 며칠에서 한두 주가 더 걸린다고 보시면 돼요. 못 미루는 날짜가 있다면 제출 시점을 2주 정도 앞당겨 잡는 걸 권해요.
안드로이드와 iOS 중 어느 쪽이 더 오래 걸리나요?
공개된 기준으로는 애플 쪽이 조금 더 걸리는 편이에요. 다만 구글도 2026년 4월부터 개발자 인증 절차가 추가돼서 계정 준비 시간이 늘었어요. 두 스토어를 같이 여는 프로젝트라면 계정 준비를 개발 초반에 시작하시는 게 좋아요.
9. 마무리 — 출시일은 개발 완료일이 아니에요
정리하면 한 문장이에요. 개발이 끝난 날과 사용자가 앱을 내려받는 날은 다른 날이고, 그 사이 구간이 계약서에 적혀 있어야 해요.
이 구간은 금액으로 보면 크지 않아요. 그런데 오픈 날짜가 걸린 프로젝트에서는 여기서 사고가 가장 많이 나요. 심사에 걸리는 일주일과 거절 한 번이 합쳐지면 이 주가 사라지거든요.
저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논·코닥·KICT 같은 곳과 함께해 왔고요. 앱을 만들어 넘기기만 한 게 아니라 저희 이름으로 스토어에 올려서 몇 년째 유지하고 있어서, 정책이 바뀔 때마다 어디가 걸리는지를 실제로 겪는 쪽이에요. 준비 중인 앱의 출시 일정이 현실적인지 궁금하시면 일정부터 같이 봐드릴게요 →
관련 글