앱 화면을 그리기 전에 정해야 할 것들

스토어 규정이 정해 둔 요건이 있고 무엇을 만들지처럼 고객이 직접 정해야 하는 결정이 있습니다. 앱 화면을 그리기 전에 제품 쪽에서 결론을 내야 하는 항목만 모았습니다.

앱을 만들기로 하셨습니다. 참고할 화면도 몇 장 모아 두셨습니다. 그런데 이 화면에서 버튼을 누르면 무엇이 일어나는지는 아직 문장으로 남아 있지 않을 겁니다. 개발은 그 문장부터 시작합니다.

무엇을 만드는지부터 문장으로 남깁니다

스토어는 화면 개수를 심사하지 않습니다. 존재 이유를 봅니다. Apple 가이드라인 4.2가 그 기준입니다. 웹사이트를 포장만 바꾼 앱, 쓸모가 뚜렷하지 않은 앱은 앱스토어에 맞지 않는다고 적어 두었습니다.

화면을 그리기 전에 두 가지를 정하셔야 합니다. 이 앱이 어떤 사람의 어떤 문제를 푸는지, 그 문제가 왜 앱이라야 풀리는지입니다. 이유를 정리하지 않으신 채 시작하시면 심사에서 바로 이 조항에 걸릴 수 있습니다.

1차 버전의 포함 범위와 제외 범위를 정합니다

범위를 정하는 기준은 감이 아니라 스토어 규정입니다. 로그인 기능을 넣으실지부터 정하십시오. Apple 가이드라인 5.1.1(v)는 계정을 만드는 앱이라면 계정 삭제도 앱 안에서 되게 하라고 요구합니다. 계정이 꼭 필요한 기능이 아니라면 로그인 없이 쓰게 두라고도 권합니다.

유료화 방식도 이 단계에서 정하십시오. 앱 안에서 기능이나 콘텐츠를 잠그고 푸는 구조라면 인앱 결제를 씁니다. 가이드라인 3.1.1은 앱이 자체 방식으로 기능을 여는 것을 허용하지 않습니다. 라이선스 키나 QR 코드, 암호화폐가 그런 방식입니다. 어떤 기능을 유료로 두실지는 화면을 그리기 전에 정하셔야 결제 구조가 처음부터 맞게 들어갑니다.

1차 버전에서 뺄 기능도 정하십시오. 나중에 넣을 기능을 화면에만 미리 그려 두시면 심사에서 빈 화면으로 잡힐 수 있습니다. Apple 심사 지침은 임시 문구와 빈 웹사이트를 제출하기 전에 지우라고 정해 두고 있습니다. 뺀 기능은 화면에서도 지웁니다.

존재 이유, 로그인 여부, 결제 구조. 이 세 가지는 개발사가 대신 정할 수 없습니다. 고객이 답을 주지 않으시면 개발사가 가정으로 채웁니다. 그 가정이 틀렸다는 사실은 만들고 난 뒤에야 드러나기 쉽습니다.

화면 목록과 사용자 흐름은 다릅니다

화면 열 개를 나열하는 일과 그 화면을 어떤 순서로 지나가는지 정하는 일은 다릅니다. 버튼을 누르면 다음에 무엇이 뜨는지, 오류가 나면 어디로 돌아가는지가 흐름입니다.

흐름이 정해져야 알 수 있는 것이 있습니다. 계정 삭제를 앱 어느 화면에서 하게 할지가 그렇습니다. 광고 추적 동의를 사용자가 어느 시점에 만나게 하실지도 그렇습니다. 두 가지 모두 스토어가 요구하는 항목인데, 화면 목록만 봐서는 어디에 넣을지 알 수 없습니다.

흐름을 정해 두지 않으시면 화면마다 다른 판단으로 이어 붙습니다. 그 판단은 개발사가 내리게 됩니다.

스토어에 올릴 이미지는 고객이 준비합니다

스크린샷과 아이콘은 고객이 공급하는 자산입니다. 개발이 끝나면 저절로 나오는 것으로 여기시면 출시 직전에 일이 몰립니다.

iOS는 화면 크기별로 스크린샷 세트를 등록합니다. 아이폰에서 실행되는 앱은 6.9인치나 6.5인치 가운데 한 세트가 필요하고 아이패드에서도 실행되면 아이패드용 세트가 따로 필요합니다. Google Play도 아이콘과 피처 그래픽, 스크린샷의 크기와 형식을 정해 두고 있습니다. 디자이너에게 두 스토어의 규격을 미리 넘겨 두시면 출시 직전에 다시 만드는 일이 없습니다.

짧은 설명도 글자 수가 정해져 있습니다. Google Play의 짧은 설명은 80자를 넘길 수 없습니다. 마케팅 문구를 쓰기 전에 이 제한부터 맞추십시오.

실제 화면과 다른 이미지는 심사에서 문제가 됩니다. Apple 심사 지침은 스크린샷이 앱을 실제로 쓰는 화면을 보여야 한다고 정해 두고 있습니다.

백엔드 계정은 누구 이름으로 만드는지 정합니다

개발자 계정의 명의와 서류는 앱 발주 전에 개발사가 대신할 수 없는 것들에 따로 정리했습니다. 여기서 볼 것은 그 계정 안에 쌓이는 데이터입니다. 분석 도구를 붙이려면 Firebase나 구글 클라우드 프로젝트가 있어야 합니다. 이 프로젝트는 특정 구글 계정 아래에 만들어집니다.

이 계정을 개발사 이름으로 만들면 분석 데이터와 백엔드 로그도 개발사 소유로 남습니다. 프로젝트 종료 후에 고객이 이 데이터를 보시려면 다시 이전받으셔야 합니다. 처음부터 고객의 구글 계정 아래에 프로젝트를 만들면 이 단계가 사라집니다.

소스 코드 저장소의 소유권은 스토어 규정에 나오지 않습니다. 계약서에서 정하는 사안입니다. 계약서에 이 항목이 없으면 프로젝트 종료 후에 저장소 접근 권한을 다시 협의하시게 됩니다.

기획 단계에서 나온 문서와 프로토타입도 같습니다. 엔소프 컴퍼니는 이 산출물을 고객 소유로 둡니다. 계약서에 그렇게 적습니다.

무엇을 측정할지 만들기 전에 정합니다

분석 도구에는 붙이는 순서가 있습니다. 어떤 SDK를 쓸지 먼저 정하십시오. 그다음 Apple의 App Privacy 항목과 Google Play의 Data safety 양식을 채웁니다. SDK를 나중에 바꾸시면 이 신고도 다시 쓰셔야 합니다.

다른 앱에서 하는 행동까지 추적하는 광고 측정을 쓰실 계획일 수 있습니다. 그렇다면 iOS에서는 App Tracking Transparency 권한을 따로 받아야 합니다. 기기 식별자에 접근하기 전에 물어야 합니다. 다른 앱과 웹사이트를 넘나드는 추적을 시작하기 전에도 마찬가지입니다. 이 동의 문구도 개발 착수 전에 정할 항목입니다.

측정하실 항목을 먼저 정해 두시면 신고서와 동의 문구를 한 번에 채웁니다. 하나씩 추가하시면 그때마다 둘 다 다시 엽니다.

완성의 기준을 미리 정합니다

Apple 가이드라인 2.1은 완성을 기기에서 실제로 테스트한 상태로 정의합니다. 실행 중에 꺼지거나 뚜렷한 기술 문제가 있는 빌드는 반려 대상입니다. 로그인이 있는 앱이라면 데모 계정을 심사 팀에 넘기고 그 계정이 실제로 작동해야 합니다.

누가 어떤 기기로 테스트하고 무엇을 통과 기준으로 볼지는 고객과 개발사가 같이 정합니다. 기준이 없으면 「다 됐다」는 말이 사람마다 다른 뜻이 됩니다.

프로젝트 종료 후에 받아야 하는 것들

완성된 코드 파일만 받으시면 다음 업데이트를 다른 곳에 맡기기 어렵습니다. 서명에 쓰는 인증서와 키, 저장소 접근 권한, 분석 프로젝트의 관리자 권한까지 함께 넘어와야 다음 담당자가 그대로 이어받습니다.

Apple 계정에서는 Account Holder 역할을 맡은 사람만 계약을 갱신하고 결제 정보를 관리하고 API 접근 권한을 내줍니다. Google Play도 계정 소유자만 결제 프로필을 연결하고 수정합니다. 이 역할이 고객 쪽에 있어야 프로젝트 종료 후에도 계정이 막히지 않습니다.

그래서 지금 이 항목들을 정해야 합니까?

네, 지금 정하셔야 합니다. 화면 시안이 먼저 나오면 이 순서가 뒤집힙니다.

존재 이유, 로그인 여부, 결제 구조, 측정 항목은 화면을 그린 뒤 끼워 맞출 수 없습니다. 개발사가 가정으로 채운 부분은 완성 뒤에야 틀렸다는 사실이 드러납니다. 그때는 화면과 흐름을 다시 고치는 비용이 듭니다.

스토어 규정도 뒤에서 걸립니다. 계정 삭제, 추적 동의, 완성의 기준은 제출 직전이 아니라 설계 전에 정해야 합니다. 그래야 심사에서 반려될 일이 줄어듭니다. 미뤄 둔 질문은 사라지지 않고 심사 단계에서 다시 돌아옵니다.

결론은 하나입니다. 화면 시안을 들고 오시기 전에 이 항목들에 먼저 답하는 것입니다.