앱 발주 전에 개발사가 대신할 수 없는 것들

앱스토어 계정과 개인정보 처리방침은 개발사가 아니라 발주사의 이름으로 남습니다. 착수 전에 고객이 직접 정해야 하는 항목만 정리했습니다.

앱 발주를 준비하고 계십니다. 화면 목록도 정리해 두셨습니다. 그런데 스토어 계정을 누구 이름으로 열지는 아직 정하지 않으셨을 겁니다. 그 결정이 앱보다 오래 남습니다.

계정을 누구 이름으로 열지부터 정하십시오

앱스토어 계정은 원칙적으로 고객의 이름으로 엽니다. 개인 자격으로 가입하면 고객의 실명이 판매자명으로 그대로 노출됩니다. 법인 자격이면 회사명이 노출됩니다.

계정을 만든 사람이 계약의 주체가 됩니다. 계약서에 서명하고 결제 정보를 등록할 권한을 그 사람이 갖습니다. 개발사 담당자가 대신 계정을 열면 이 권한도 개발사가 가져갑니다. 고객께서 나중에 되찾으시려면 절차가 따로 붙습니다.

나중에 발주사 명의로 옮기는 절차는 있습니다. 다만 간단하지 않습니다.

법인 서류부터 준비합니다

Apple과 Google 모두 법인 계정에 D-U-N-S 번호를 요구합니다. 던앤브래드스트리트가 발급하는 사업자 식별 번호입니다. 신청하실 때 법인명, 본사 주소, 우편물 주소, 담당자 연락처가 필요합니다. 개인 자격으로 가시려면 이 번호는 건너뛰셔도 됩니다.

Apple은 상호(DBA)나 지점, 개인사업자를 법인으로 인정하지 않습니다. 정식 법인격이 없으면 개인 자격으로만 가입할 수 있습니다. 이 경우 판매자명에 회사명 대신 대표자 실명이 뜹니다.

Apple 법인 계정에는 조건이 더 붙습니다. 회사 도메인으로 된 업무 이메일이 있어야 합니다. 그 도메인으로 실제로 열리는 공개 웹사이트도 있어야 합니다. 계정을 여는 사람은 회사를 법적으로 대표하거나 그 권한을 위임받은 사람이어야 합니다.

Google Play도 마찬가지입니다. 조직 계정은 D-U-N-S 번호 없이는 계정 생성 자체가 막힙니다. 이 서류는 개발 착수보다 먼저 준비해 두셔야 일정이 밀리지 않습니다.

개인정보 처리방침은 고객 회사의 정책입니다

두 회사 모두 개인정보 처리방침 URL을 필수로 요구합니다. Apple은 스토어 메타데이터뿐 아니라 앱 내부에도 같은 링크를 걸어야 합니다.

이 문서에는 무엇을 수집하는지, 어떻게 쓰는지, 제3자와 어떻게 공유하는지가 들어갑니다. 보관과 삭제는 어떻게 하는지, 동의를 어떻게 철회하는지도 들어갑니다. 문서 작성은 개발사가 도울 수 있습니다. 그 내용을 책임지는 쪽은 데이터를 실제로 다루시는 고객입니다.

방침이 살아 있는 URL이어야 한다는 점도 놓치기 쉽습니다. Apple 심사 지침은 제출 시점에 링크가 전부 작동해야 한다고 정해 두고 있습니다. 심사할 때 방침 페이지가 안 열리면 이 요건에 걸립니다. 도메인과 호스팅을 누가 관리하시는지도 이때 함께 확인해 두시면 됩니다.

SDK가 모으는 데이터도 고객 책임입니다

Apple의 App Privacy 항목과 Google Play의 Data safety 양식이 있습니다. 둘 다 고객 팀이 직접 만든 코드 바깥까지 묻습니다. 분석 도구, 광고 네트워크, 외부 SDK가 수집하는 데이터까지 전부 포함됩니다.

Google은 이 신고의 책임 소재를 분명히 밝힙니다. 정확하고 완전한 신고의 책임은 고객에게만 있다고 명시합니다. Apple도 허위 신고에는 업데이트 차단이나 앱 삭제로 대응합니다.

분석 SDK 하나를 나중에 추가하면 이 신고도 다시 써야 합니다. 어떤 SDK를 쓸지 정하시는 시점과 신고 시점이 떨어져 있으면 어긋남이 생깁니다. 신고 내용이 실제 수집 범위를 놓치기 쉽습니다.

번들 ID는 한 번 정하면 그대로 갑니다

App Store Connect에는 여러 항목을 등록합니다. 앱 이름, 연령 등급, 번들 ID, SKU, 기본 언어, 대표 카테고리입니다. 대부분 나중에 고칠 수 있습니다. 번들 ID는 예외입니다. 빌드를 한 번 업로드하고 나면 바꿀 수 없습니다.

Firebase에 등록하는 순간에도 똑같이 고정됩니다. 분석과 백엔드를 나중에 옮기려 해도 이 값은 따라옵니다. 번들 ID는 기술 용어처럼 보이지만 실은 착수 전에 고객이 정해야 하는 이름입니다. 회사명이나 서비스명이 바뀔 가능성이 있다면, 이 시점에 미리 짚어야 합니다.

심사에는 실제로 작동하는 앱을 올려야 합니다

Apple 가이드라인 2.1은 분명합니다. 로그인이 있는 앱이라면 데모 계정 정보를 제공해야 합니다. 백엔드 서비스도 켜둔 채로 심사에 올려야 합니다. Google Play도 활성화된 데모 계정과 로그인 정보를 요구합니다.

아직 채우지 않은 임시 문구, 빈 웹사이트, 눌러도 열리지 않는 링크. 이 조항에 걸리는 대표적인 원인입니다.

스크린샷도 마찬가지입니다. 실제 화면과 다른 마케팅용 이미지는 심사에서 문제가 됩니다. 심사는 기획안이 아니라 지금 작동하는 앱을 봅니다. 올리실 화면은 실제로 그렇게 나오는 화면이어야 합니다.

계정을 나중에 옮기면 잃는 것이 생깁니다

착수 단계에서 개발사 계정으로 먼저 올리고 나중에 발주사 계정으로 옮기는 방식을 고려하실 수 있습니다. 이전 절차는 실제로 있습니다. 무엇을 잃는지가 문제입니다.

Apple은 이전 전에 테스트 빌드와 테스터를 전부 지우도록 요구합니다. 이전 후에는 Apple Pay 가맹점 ID를 새로 만들어야 하고 프로모션 코드는 더 이상 생성할 수 없습니다. 그동안 쌓인 App Analytics 이력은 넘긴 쪽에서 더 이상 볼 수 없습니다.

Google Play도 다르지 않습니다. 테스트 그룹과 매출 리포트는 계정을 옮겨도 따라오지 않습니다. 처음부터 발주사 명의로 시작하면 이 손실 자체가 생기지 않습니다.

앱은 완성 후에도 계속 손이 갑니다

Google Play는 타깃 API 레벨을 해마다 올립니다. 이 기준보다 낮은 앱은 최신 기기에서 노출과 배포가 제한됩니다. Apple도 매번 새 버전의 Xcode와 SDK로 다시 빌드해야 제출이 이어집니다.

이 기준은 앱에 기능을 더하든 말든 해마다 올라갑니다. 코드를 한 줄도 안 고쳐도 기준선이 올라간 날부터 배포가 막힙니다.

프로젝트 종료 후에 이 재빌드를 누가 맡을지는 계약서에서 정해집니다. 만들고 넘기는 계약만 맺으면 그 일을 할 사람이 없습니다. 유지보수 항목이 있어야 앱을 계속 내려받게 할 수 있습니다.

그래서 계정 명의는 지금 정해야 합니까?

네, 지금 계정 명의를 정하셔야 합니다. 화면 설계보다 먼저 결정할 문제입니다.

법인 계정은 D-U-N-S 번호가 없으면 계정을 만들 수 없습니다. 이 서류는 개발 착수 전에 준비해 두셔야 일정이 밀리지 않습니다.

판단을 미루면 개발사 명의로 먼저 올리는 방식을 고르게 됩니다. 그러면 나중에 명의를 옮길 때 테스트 이력과 매출 리포트를 잃습니다. 번들 ID도 빌드를 한 번 올리고 나면 바꿀 수 없습니다. 처음부터 발주사 명의로 시작하면 이런 손실 자체가 생기지 않습니다.

결론은 하나입니다. 화면 목록을 준비하시는 지금, 계정 명의와 서류 순서부터 정하시는 것입니다.