앱 발주 전에 계정 명의와 법인 서류를 먼저 정해야 하는 이유

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

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

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

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

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

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

법인 서류부터 준비합니다

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

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

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

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

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

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

개인정보 처리방침에는 수집 항목, 사용 방식, 제3자 공유 방식, 보관과 삭제 방법, 동의 철회 방법이 들어갑니다. 문서 작성은 개발사가 도울 수 있지만 내용을 책임지는 쪽은 데이터를 실제로 다루시는 고객입니다.

방침이 살아 있는 URL이어야 한다는 점도 놓치기 쉽습니다. Apple 심사 지침은 제출 시점에 링크가 전부 작동해야 한다고 정해 두고 있습니다. 심사 중 방침 페이지가 열리지 않으면 링크 작동 기준을 충족하지 못합니다. 도메인과 호스팅을 누가 관리하시는지도 이때 함께 확인해 두시면 됩니다. 호스팅은 웹사이트를 인터넷에 올려 두는 공간을 빌리는 서비스입니다.

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

Apple의 App Privacy 항목과 Google Play의 Data safety 양식이 있습니다. 둘 다 고객 팀이 직접 만든 코드 바깥까지 묻습니다. 분석 도구, 광고 네트워크, 외부 SDK가 수집하는 데이터까지 전부 포함됩니다. SDK는 다른 회사가 만든 기능을 앱에 끼워 넣는 프로그램 묶음입니다.

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

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

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

App Store Connect에는 앱 이름, 연령 등급, 번들 ID, SKU, 기본 언어, 대표 카테고리를 등록합니다. 대부분 나중에 수정할 수 있지만 번들 ID는 예외입니다. 번들 ID는 앱마다 붙는 고유한 식별 이름이어서 빌드를 한 번 업로드하고 나면 바꿀 수 없습니다. 빌드는 스토어에 올리는 완성된 앱 파일입니다.

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

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

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

임시 문구가 남은 화면, 내용이 없는 웹사이트, 열리지 않는 링크는 심사 반려의 원인이 됩니다.

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

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

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

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

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

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

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

타깃 API 레벨 기준은 앱에 기능을 더하든 말든 해마다 올라갑니다. 코드를 한 줄도 수정하지 않아도 기준선이 올라간 날부터 배포가 막힙니다.

프로젝트 종료 후 앱을 다시 빌드할 담당자는 계약서에 적어 두어야 합니다. 만들고 넘기는 계약만 맺으면 그 일을 할 사람이 없습니다. 유지보수 항목이 있어야 앱을 계속 내려받게 할 수 있습니다.

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

스토어 계정 명의가 아직 정해지지 않았다면 먼저 확인해 볼 만합니다. 화면 설계보다 먼저 결정할 문제입니다.

법인 계정을 만들 계획이라면 착수 전에 회사의 D-U-N-S 번호 보유 여부를 확인하십시오.

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

이미 발주사 명의로 계정을 만들 준비가 되어 있다면 다음 단계로 넘어가셔도 됩니다.