앱 화면부터 그리면 왜 완성 뒤에 다시 만들게 될까요?
앱 화면을 그리기 전에 고객이 먼저 정해야 하는 항목을 모았습니다. 앱의 목적과 로그인 여부, 결제 방식, 측정 항목, 스토어 이미지, 계정과 서명 키를 다룹니다.
목차
앱을 만들기로 하셨고 참고할 화면도 몇 장 모아 두셨습니다. 그런데 모아 두신 화면의 버튼을 누르면 무엇이 일어나는지는 아직 문장으로 남아 있지 않을 겁니다. 개발은 버튼마다 일어나는 일을 적은 문장에서 시작합니다.
만들 앱이 무엇을 하는지부터 문장으로 남깁니다
애플 앱스토어와 구글 플레이(이하 스토어)는 앱을 올리기 전에 심사합니다. 규정에 맞지 않으면 등록이 거절되며 이를 반려라고 부릅니다.
애플은 앱의 목적을 심사합니다. 애플의 앱 심사 지침(App Store Review Guidelines)에는 받지 않는 앱이 적혀 있습니다. 웹사이트를 그대로 옮긴 앱과 쓸모가 뚜렷하지 않은 앱입니다.
화면을 그리기 전에 두 가지를 정해 두시면 됩니다. 앱이 어떤 사람의 어떤 문제를 푸는지, 그 문제가 왜 앱이라야 풀리는지입니다. 앱이 푸는 문제와 앱이어야 하는 이유가 정해지지 않으면 심사에서 반려될 수 있습니다.
첫 출시에 넣을 기능과 제외할 기능을 정합니다
넣을 기능과 제외할 기능은 스토어 규정을 기준으로 삼고 로그인 기능을 넣을지부터 정해 두시면 됩니다. 애플 심사 지침은 계정을 만드는 앱이라면 계정 삭제도 앱 안에서 할 수 있어야 한다고 요구합니다. 계정이 꼭 필요한 기능이 없는 앱은 로그인 없이 쓰게 하라고도 권합니다.
유료화 방식도 첫 출시 전에 정합니다. 앱 안에서 기능이나 콘텐츠를 잠그고 푸는 방식이라면 인앱 결제를 씁니다. 인앱 결제는 앱 안에서 애플이나 구글의 결제 창으로 돈을 받는 방식입니다. 애플 심사 지침은 앱이 자체 방식으로 기능을 여는 것을 허용하지 않습니다. 라이선스 키를 입력하게 하거나 QR 코드를 읽게 하는 방식이 그 예입니다. 어떤 기능을 유료로 둘지는 화면을 그리기 전에 정해야 결제 방식이 처음부터 맞게 들어갑니다.
나중에 넣을 기능의 화면만 미리 그려 두면 심사에서 반려될 수 있으므로 첫 출시에서 제외할 기능도 정해 둡니다. 애플 심사 지침이 임시 문구와 빈 웹사이트를 제출하기 전에 지우라고 적어 두었으니 제외한 기능은 화면에서도 지웁니다.
앱의 목적, 로그인 여부, 결제 방식은 고객만 답할 수 있습니다. 답이 없으면 개발사가 가정으로 채웁니다. 개발사가 가정으로 채운 부분은 만든 뒤에야 틀렸다는 사실이 드러나기 쉽습니다.
화면 목록과 별도로 화면을 지나는 순서를 정합니다
화면 열 개를 나열하는 일과 그 화면을 어떤 순서로 지나가는지 정하는 일은 다릅니다. 화면을 지나가는 순서를 사용자 흐름이라고 부릅니다. 버튼을 누르면 다음에 무엇이 뜨는지, 오류가 나면 어디로 돌아가는지가 사용자 흐름입니다.
계정 삭제 화면을 앱 어디에 둘지와 추적 동의 화면을 어느 시점에 보여 줄지는 사용자 흐름을 정해야 압니다. 추적 동의 화면은 앱이 사용자의 행동을 추적해도 되는지 묻는 화면입니다. 계정 삭제 화면과 추적 동의 화면은 모두 애플 심사에서 요구하는 항목이어서 화면 목록만 봐서는 어디에 넣을지 알 수 없습니다.
화면 목록만 넘기면 개발사는 화면 사이의 이동을 짐작해서 이어 붙여야 합니다. 사용자 흐름이 없으면 개발사가 계정 삭제 위치를 짐작해 넣게 됩니다.
스토어에 올릴 이미지는 고객이 준비합니다
스크린샷(스토어 소개 페이지에 올리는 앱 화면 사진)과 아이콘은 고객이 준비하는 이미지입니다. 개발이 끝나면 저절로 나오는 것으로 여기시면 출시 직전에 일이 몰립니다.
아이폰 앱의 스크린샷은 애플이 정한 화면 크기별로 세트를 등록합니다. 앱이 아이패드에서도 실행되면 아이패드용 스크린샷이 따로 필요합니다. 구글 플레이는 앱 아이콘과 스크린샷, 피처 그래픽의 크기와 형식을 정해 두고 있습니다. 피처 그래픽은 소개 페이지 상단에 쓰는 가로형 이미지입니다. 두 스토어의 이미지 규격을 디자이너에게 미리 전달해 두시면 출시 직전에 다시 만드는 일을 줄일 수 있습니다.
구글 플레이의 짧은 설명(앱 이름 아래에 보이는 한 줄 소개)에는 글자 수 제한이 있습니다. 홍보 문구를 쓰기 전에 현재 제한 글자 수를 확인해 두시면 문구를 다시 쓰는 일이 줄어듭니다.
실제 화면과 다른 이미지는 심사에서 문제가 됩니다. 애플 심사 지침은 스크린샷이 앱을 실제로 쓰는 화면을 보여야 한다고 적어 두었습니다.
분석 데이터가 쌓이는 구글 계정은 고객 이름으로 만듭니다
개발자 계정의 명의와 서류는 앱 발주 전에 계정 명의와 법인 서류를 먼저 정해야 하는 이유에 따로 정리했습니다. 여기서는 앱 분석 데이터가 쌓이는 곳을 다룹니다.
앱의 사용 기록을 분석하려면 구글의 Firebase를 붙이는 방법이 있습니다. Firebase는 구글이 제공하는 앱 분석 서비스입니다. 앱 서버(화면 뒤에서 데이터를 저장하고 처리하는 프로그램) 기능도 있습니다. 이 서비스를 쓰면 구글 계정 아래에 분석 데이터를 쌓는 공간이 만들어집니다. 이 글에서는 분석 데이터를 쌓는 공간을 분석 공간이라고 부릅니다.
분석 공간을 개발사 이름의 구글 계정으로 만들면 분석 데이터가 개발사 소유로 남습니다. 프로젝트 종료 후에 고객이 데이터를 보려면 개발사에서 이전받아야 합니다. 처음부터 고객의 구글 계정 아래에 분석 공간을 만들면 이전 절차가 사라집니다.
소스 코드는 앱을 만든 원본 프로그램 파일이고 저장소는 소스 코드를 변경 이력과 함께 보관하는 곳입니다. 저장소의 소유자는 계약서에 적어 정하며 적혀 있지 않으면 프로젝트 종료 후에 접근 권한을 다시 협의하게 됩니다.
기획 문서와 시제품도 소유를 계약서에 적어 두시면 프로젝트 종료 후에 쓰실 수 있습니다. 시제품은 화면을 눌러 볼 수 있게 만든 견본입니다.
무엇을 측정할지 만들기 전에 정합니다
앱 분석에는 붙이는 순서가 있습니다. 먼저 어떤 SDK를 쓸지 정합니다. SDK는 분석 같은 기능을 앱에 붙여 주는 외부 프로그램 묶음입니다. 그다음 앱이 어떤 정보를 모으는지 스토어에 알리는 양식을 채웁니다. 애플에서는 App Privacy 항목이고 구글 플레이에서는 Data safety 양식입니다. SDK를 나중에 바꾸면 정보 수집 신고 양식도 다시 써야 할 수 있습니다.
다른 앱과 웹사이트를 넘나들며 사용자를 추적하는 광고 측정을 쓰실 계획일 수 있습니다. 그렇다면 아이폰에서는 추적 동의 화면(App Tracking Transparency)을 먼저 보여 주고 동의를 받아야 합니다. 기기를 구분하는 식별 정보를 가져오기 전에도 사용자 동의가 필요합니다. 추적 동의 문구도 개발을 시작하기 전에 정해 둘 항목입니다.
측정할 항목을 먼저 정해 두면 정보 수집 신고 양식과 추적 동의 문구를 한 번에 채울 수 있습니다. 항목을 하나씩 추가하면 그때마다 양식과 동의 문구를 다시 수정해야 합니다.
완성의 기준을 미리 정합니다
애플 심사 지침은 제출하는 앱이 기기에서 시험을 마친 최종본이어야 한다고 적고 있습니다. 실행 중에 꺼지거나 뚜렷한 기술 문제가 있는 빌드(제출용으로 묶어 낸 앱 파일)는 반려 대상입니다. 로그인이 있는 앱이라면 심사팀이 쓸 시험용 계정(데모 계정)을 넘겨야 합니다. 그 계정은 실제로 작동해야 합니다.
시험할 기기와 통과 기준은 고객이 정하고 개발사는 그 기준대로 시험합니다. 완성의 기준이 없으면 「다 됐다」는 말이 사람마다 다른 뜻이 됩니다.
프로젝트가 끝나면 서명 키와 계정 권한도 함께 받습니다
완성된 코드 파일만 받으면 다음 업데이트를 다른 곳에 맡기기 어렵습니다. 서명은 앱을 올린 곳이 누구인지 증명하는 전자 도장이며 서명용 인증서와 키가 필요합니다. 저장소 접근 권한과 분석 공간 관리자 권한까지 있어야 다음 담당자가 이어받을 수 있습니다.
스토어 계정의 소유자는 계약 갱신과 결제 정보 관리를 맡습니다. 소유자가 고객 쪽에 있어야 프로젝트 종료 후에도 계정을 고객이 직접 관리할 수 있습니다.
그래서 화면을 그리기 전에 목적, 로그인, 결제 방식부터 정해야 합니까?
네. 네. 화면 시안 전에 앱의 목적, 로그인 여부, 결제 방식, 측정 항목에 답해 두시면 시안을 다시 그릴 일이 줄어듭니다.
스토어 규정과 연결된 항목은 시안보다 더 먼저 정해 두시면 좋습니다. 계정 삭제 위치와 추적 동의 시점, 완성의 기준을 제출 직전에 정하면 화면 흐름을 다시 수정해야 할 수 있습니다.
아직 답을 정하지 못한 항목이 있다면 「미정」이라고 적어 개발사에 전달하시면 됩니다. 미정으로 적힌 항목부터 상담할 수 있습니다.
엔소프 컴퍼니는 앱 화면을 그리기 전에 정한 내용을 이어받아 출시 뒤 반복 업무를 AI 에이전트로 개발해 드립니다
앱의 목적과 사용자 흐름이 정리되면 출시 뒤에 사람이 반복하는 일도 보입니다. 문의를 접수해 분류하는 일과 이용 숫자를 모아 월 보고서로 만드는 일이 그렇습니다.
고객이 원하실 경우 엔소프 컴퍼니는 문의 접수와 월 보고서 작성을 AI 에이전트로 개발해 드립니다. AI 에이전트는 문의 접수나 기록 정리 같은 반복 업무를 사람 대신 처리하는 프로그램입니다.
AI 에이전트를 붙이면 앱으로 들어온 문의를 종류별로 나누어 한곳에 기록하게 만들 수 있습니다. 분석 공간에 쌓인 이용 숫자는 매달 보고서 한 장으로 모이는데 한 번에 모두 맡기지 않고 문의 접수 하나로 시작하셔도 됩니다.
문의를 옮겨 적고 숫자를 모으던 일이 줄면 그 일에 쓰던 직원 시간과 인건비가 함께 줄어듭니다.
프로젝트를 마치면 앱의 목적과 범위를 적은 문서와 사용자 흐름도를 넘겨드립니다. 서명용 인증서와 저장소 접근 권한, 분석 공간 관리자 권한도 고객께 이전해 드립니다. AI 에이전트를 함께 개발했다면 그 에이전트가 돌아가는 장치와 계정도 넘겨드립니다.
지금 준비 중인 앱과 출시 뒤에 직접 처리하실 반복 업무를 알려 주시면 됩니다. 그 업무를 AI 에이전트에게 어떻게 맡길 수 있는지 엔소프 컴퍼니가 설명해 드립니다.
자주 묻는 질문
- 로그인 기능은 나중에 정해도 됩니까?
- 늦어도 화면 설계 전에는 정해 두셔야 사용자 흐름에 계정 삭제 화면이 들어갑니다. 계정을 만드는 기능을 넣기로 하셨다면 계정 삭제 화면을 빠뜨릴 때 심사에서 반려될 수 있습니다.
- 외부 테스터가 보낸 의견은 어디로 옵니까?
- TestFlight는 애플이 제공하는 앱 시험 배포 서비스입니다. 개발팀 밖의 외부 테스터에게 시험판을 배포하려면 의견을 받을 이메일 주소를 미리 등록해야 합니다. 그 주소를 고객이 확인할 수 있는 주소로 두시면 의견을 고객이 바로 받습니다.
- 분석 공간도 인계 대상입니까?
- 네. 분석 공간의 관리자 권한이 함께 넘어와야 합니다. 권한을 넘겨받지 못하면 그동안 쌓인 데이터를 새 담당자가 확인할 방법이 마땅치 않습니다.