앱스토어 심사에서 배운 것 — 코드를 보기 전에 약속부터 맞춰야 했어요

심사 결과 메일이 왔습니다. 앱은 제 폰에서 잘 열렸고, 가입도 됐고, 일정도 저장됐어요. 그래서 먼저 코드를 의심했습니다. 어디서 꺼졌을까, 결제 요청이 실패했을까, 로그에 빨간 줄이 있었을까 하고요.

그런데 거절 사유는 다른 데 있었습니다. 스크린샷 가장자리의 투명한 영역, 눌렀을 때 열리지 않는 지원 페이지, 아이폰용 설명에 들어간 다른 모바일 플랫폼 이름. 앱 안의 핵심 기능보다 스토어에 내놓은 약속의 불일치가 먼저 보인 거예요.

그때 심사를 기능 시험이라고만 생각했던 게 문제였습니다. 심사자는 코드를 함께 만든 사람이 아니에요. 스토어 설명을 읽고, 스크린샷을 보고, 지원 링크를 누르고, 앱 안에서 같은 경험이 나오는지 확인합니다. 한쪽에는 "가능하다"고 적혀 있는데 다른 쪽에는 길이 없으면, 앱이 실행된다는 사실만으로 통과 이유가 되지 않아요.

이 글은 거절을 피하는 비법이 아닙니다. Apple의 App Review Guidelines와 App Store Connect 공식 도움말을 2026년 8월 22일 다시 확인하고, 제가 실제로 잘못 본 순서를 정리한 글이에요. 심사 결과는 앱마다 다르지만, 제출 전에 무엇을 직접 확인할지는 같은 방식으로 정할 수 있습니다.

심사는 코드와 메타데이터를 함께 봅니다

Apple 공식 지침 2.1은 제출물이 최종 상태여야 하고 필요한 메타데이터와 URL이 작동해야 한다고 안내해요. 2.3은 앱 설명, 스크린샷, 미리보기, 개인정보 정보가 실제 핵심 경험을 정확히 반영하고 최신이어야 한다고 적고요.

메타데이터라는 말이 어렵게 들리지만, 스토어에서 사용자가 보는 포장지라고 생각하면 됩니다. 앱 이름, 부제, 설명, 키워드, 스크린샷, 지원 URL, 개인정보 처리방침, 새 버전 설명이 여기 들어가요. 포장지가 실제 물건과 다르면, 기능이 잘 돌아가도 신뢰할 수 없는 제출이 됩니다.

제가 처음에는 "앱이 잘 된다"를 완료 기준으로 잡았어요. 지금은 다섯 장면으로 나눕니다.

1. 처음 보는 사람이 스토어 설명만 읽고 핵심 기능을 정확히 이해할 수 있는가.
2. 스크린샷에 나온 화면이 현재 앱에서 실제로 나오는가.
3. 지원·개인정보 URL을 로그아웃 상태와 휴대폰에서 열 수 있는가.
4. 심사자가 가입·결제·계정 삭제의 끝까지 갈 수 있는가.
5. 모든 언어의 설명이 같은 제품 상태를 말하는가.

이 다섯 가지 중 하나라도 "아마 될 것"이면 제출 준비가 끝난 게 아니에요. 완료 기준을 한 문장으로 쓰는 법을 앱 화면뿐 아니라 스토어에도 적용해야 합니다.

스크린샷의 빈 픽셀도 제출물입니다

둥근 휴대폰 프레임을 예쁘게 만들려고 바깥을 투명하게 둔 적이 있어요. 눈으로는 흰 배경처럼 보여서 문제를 못 느꼈습니다. 그런데 업로드와 심사 과정에서는 투명 영역이 빈 데이터로 남아요.

Apple의 스크린샷 규격을 2026년 8월 22일 확인하면 JPEG·JPG·PNG 형식을 받고, 알파 채널이나 투명 영역은 허용하지 않는다고 명시돼 있습니다. 당시에는 거절 메일을 받고 나서야 이 한 줄을 찾았어요. 배경색으로 평평하게 저장한 뒤 다시 올렸고요.

여기서 배운 건 "투명 PNG를 쓰지 마세요"보다 큽니다. 디자인 도구의 화면과 제출된 파일은 같은 것이 아니에요. 저장한 결과물을 다시 열어 크기, 투명도, 잘린 글자, 상태바, 실제 계정 정보 노출을 확인해야 합니다.

Apple 지침 2.3.9는 스크린샷과 미리보기에서 실제 사람의 정보 대신 가상 계정 정보를 쓰라고 안내해요. 공유 캘린더라면 이름과 일정 제목이 더 쉽게 노출되고요. 실제 가족 일정이나 실제 초대 메일을 그대로 촬영하지 않고, 심사용 가상 일정으로 다시 만드는 편이 맞습니다.

저는 이제 스크린샷을 홍보 이미지로만 보지 않아요. 앱의 기능과 개인정보 처리를 동시에 보여 주는 시험 화면으로 봅니다. 혼자 만들 때 무엇을 검증해야 하는지에도 이 기준을 이어 놓았어요.

지원 URL은 주소가 아니라 실제 문입니다

개인정보 처리방침 주소는 준비했는데 지원 페이지는 경로만 만들어 둔 적이 있어요. App Store Connect에는 URL이 들어갔지만 눌러 보면 없는 페이지였습니다. 칸을 채웠으니 완료라고 생각한 거예요.

Apple 지침 2.1은 완전히 작동하는 URL을 요구하고, 지침 앞부분은 앱과 Support URL에 사용자가 연락할 수 있는 쉬운 방법을 포함하라고 안내합니다. 앱 개인정보 관리 공식 문서에는 iOS 앱의 개인정보 처리방침 URL과 데이터 처리 설명이 필요하다고 적혀 있고요.

확인은 단순해요. App Store Connect에 복사한 바로 그 주소를 새 브라우저 창에서 엽니다. 로그인하지 않은 상태로 열고, 휴대폰에서도 열고, 문의 방법과 개인정보 처리방침이 실제로 보이는지 확인해요. 로컬 컴퓨터에서만 열리는 주소나 임시 페이지는 문이 아닙니다.

지원 페이지는 거절을 막는 장식도 아니에요. 출시 뒤 결제 복원, 계정 삭제, 알림 문제를 겪은 사람이 갈 곳입니다. 앱이 살아 있는 동안 유지해야 하는 제품의 일부예요. 결제를 붙이며 배운 것처럼 출시 이후의 복구 경로가 먼저 있어야 합니다.

다른 플랫폼 이름 한 단어도 맥락을 봐요

아이폰 스토어 설명에 Android라는 이름을 넣었다가 수정한 적이 있어요. "서로 기기가 달라도 함께 쓴다"는 장점을 설명하려고 넣었는데, Apple 지침 2.3.10은 앱과 메타데이터가 지원하는 Apple 플랫폼의 경험에 집중해야 하며, 특별히 승인된 상호작용이 아니라면 다른 모바일 플랫폼이나 앱 마켓의 이름·아이콘·이미지를 포함하지 말라고 안내합니다.

같은 기능을 설명해도 표현은 바꿀 수 있어요. 다른 스토어 이름을 내세우는 대신 "초대한 상대와 함께 일정을 본다"처럼 현재 Apple 앱에서 확인되는 경험을 적는 겁니다. 다만 실제로 다른 기기에서 사용할 수 없는 상태라면 그 문장도 쓰면 안 돼요. 표현을 순하게 바꾸는 게 아니라 제품 상태와 맞추는 일이니까요.

현지화가 여러 언어라면 한글 설명 한 곳만 고쳐서는 안 됩니다. 언어별 설명, 부제, 새 버전 안내, 스크린샷의 글자를 각각 확인해야 해요. 저는 한 문장을 바꾼 뒤 다른 언어에 예전 약속이 남아 있는 범위를 뒤늦게 봤습니다. 아이폰과 Android를 함께 만들며 생기는 경계는 코드만의 문제가 아니었어요.

계정 삭제는 버튼 그림으로 끝나지 않아요

Apple 지침 5.1.1(v)는 계정 생성을 지원하는 앱이 앱 안에서 계정 삭제를 제공해야 한다고 안내합니다. Apple의 계정 삭제 공식 안내는 전체 계정과 관련 개인정보를 삭제해야 하고, Sign in with Apple을 지원하면 REST API로 사용자 토큰을 해지해야 한다고 설명해요.

제가 놓쳤던 건 화면과 실제 상태의 차이였습니다. "계정 삭제" 버튼을 눌렀다는 사실과 서버 기록이 지워지고 로그인 권한이 끊겼다는 사실은 달라요. 공유 공간, 초대, 결제 권한, 위젯에 남은 일정도 함께 봐야 하고요. 앱 본체에서 계정이 사라졌는데 홈 화면 위젯에 전 사용자의 일정이 남으면 그건 개인정보 문제입니다.

삭제 시험은 같은 계정으로 다시 로그인해 보는 데까지 가야 해요. 삭제된 데이터가 되살아나지 않는지, 다른 구성원의 공유 공간이 어떻게 처리되는지, 구매 복원 안내가 맞는지 확인합니다. 기능 하나를 누르는 시험이 아니라 상태가 끝까지 닫히는 시험이에요.

위젯 하나를 만들며 겪은 조용한 실패도 같은 문제였어요. 앱 화면이 비었다고 위젯 저장소까지 자동으로 비는 건 아니었습니다.

첫 인앱 상품은 앱 버전과 함께 봐야 했어요

결제 상품을 따로 만들어 두면 심사도 따로 끝날 거라고 생각하기 쉬워요. Apple의 인앱 구매 제출 공식 문서를 2026년 8월 22일 확인하면, 소모성·비소모성·자동 갱신 구독·비갱신 구독은 각 유형의 첫 상품을 새 앱 버전과 함께 제출해야 한다고 안내합니다. 첫 상품이 승인된 뒤에는 같은 유형의 추가 상품을 앱 버전 없이 제출할 수 있고요.

중요한 건 외우는 게 아닙니다. "상품만 올리면 되겠지"라고 추측하지 말고, 내가 제출하는 상품 유형의 현재 공식 절차를 읽는 거예요. 결제 정책은 바뀌고, 앱의 상품 상태에 따라 화면도 달라지니까요.

심사 메모에는 심사자가 유료 기능을 찾는 경로와 테스트 조건을 짧고 정확하게 적습니다. 보이지 않는 상품이라면 이유를 설명해야 하고요. 리뷰어가 알아서 탐색할 거라고 기대하지 마세요.

여기서 자주 어긋나는 생각들

"심사 거절은 코드 버그라는 뜻이다." 코드 버그일 수도 있어요. 하지만 Apple 공식 지침은 완성도, 정확한 메타데이터, 작동하는 URL, 개인정보, 결제 상품도 함께 봅니다. 실제로 제가 고친 건 투명 스크린샷, 지원 페이지, 플랫폼 표현이었어요. 거절 사유의 조항과 재현 경로를 먼저 읽고 고칠 층을 정해야 합니다.

"다른 앱들도 그렇게 하니 괜찮다." 스토어에 보이는 다른 앱의 화면은 내 제출의 승인 근거가 아니에요. 출시 시점, 권한, 심사 맥락이 다릅니다. 현재 공식 지침과 내 거절 메시지가 기준이에요. 경쟁 앱을 근거로 예외를 추측하면 고칠 범위만 흐려집니다.

"거절되면 설명 메일로 설득하면 된다." 오해라면 근거와 재현 영상을 보내는 게 맞아요. 그러나 실제로 URL이 열리지 않거나 스크린샷에 투명 영역이 있다면 긴 설명이 파일을 바꾸지 못합니다. 사실 문제는 고치고, 판단이 갈리는 문제만 짧게 설명하세요.

"한 번 통과한 문구는 앞으로도 안전하다." 앱 기능과 공식 지침은 바뀝니다. 지원 플랫폼이 달라지고, 결제 상품이 늘고, 개인정보 처리가 달라지면 예전 설명은 낡아요. Apple도 메타데이터를 최신으로 유지하라고 안내합니다. 통과는 영구 허가증이 아니라 그 버전과 제출물에 대한 결과예요.

규정 숫자를 과잉 해석하지 마세요

이 글의 조항 번호는 2026년 8월 22일 확인한 Apple 공식 문서를 찾기 쉽게 적은 표지예요. 조항 번호만 복사해 체크했다고 끝내지 마세요. 같은 조항 안에서도 앱 유형과 기능에 따라 적용 맥락이 다릅니다.

스크린샷 규격, 계정 삭제, 첫 인앱 구매 절차도 이후 바뀔 수 있어요. 다음 제출 때는 이 글이 아니라 링크된 공식 페이지의 최신 내용을 다시 확인해야 합니다. 제가 겪은 거절 장면은 경험이고, 모든 앱이 같은 이유로 거절된다는 통계가 아니에요.

제출 전에는 화면이 아니라 경로를 걸어 보세요

앱을 처음 설치한 상태에서 시작합니다. 스토어 설명을 읽고, 지원 URL을 열고, 가입하고, 상대를 초대하고, 유료 기능을 찾고, 구매를 복원하고, 로그아웃하고, 계정을 삭제해요. 그 사이 홈 화면 위젯과 알림에 이전 정보가 남는지도 봅니다.

이 경로를 종이에 한 줄씩 적으면 코드 지식이 없어도 확인할 수 있어요. "버튼 있음"이 아니라 "누르면 어디까지 가고 무엇이 남는가"를 보는 겁니다. AI에게 맡기면 안 되는 최종 확인이 바로 이 부분이에요.

자주 묻는 질문

스크린샷은 실제 앱 화면만 써야 하나요?

핵심 경험을 정확하게 보여 주고, Apple의 크기·형식 규격을 지켜야 합니다. 2026년 8월 공식 규격상 투명 영역과 알파 채널은 허용되지 않아요. 실제 개인정보 대신 가상 계정과 가상 일정을 사용하세요.

지원 URL과 개인정보 처리방침 URL은 둘 다 필요한가요?

역할이 다릅니다. 지원 URL은 사용자가 도움과 연락 방법을 찾는 문이고, 개인정보 처리방침은 어떤 데이터를 왜 다루는지 설명하는 문서예요. App Store Connect에 적은 정확한 주소를 로그아웃 상태와 휴대폰에서 직접 열어 보세요.

계정 삭제 버튼만 있으면 되나요?

아니요. 전체 계정과 관련 데이터가 실제로 처리되는지 확인해야 해요. Sign in with Apple을 쓰면 공식 안내에 따라 사용자 토큰 해지도 고려해야 하고, 공유 데이터·결제 안내·위젯에 남는 정보까지 시험해야 합니다.

거절 메일을 받으면 가장 먼저 무엇을 하나요?

거절 조항과 심사자가 적은 재현 경로를 그대로 읽어요. 코드, 메타데이터, URL, 개인정보, 결제 중 어느 층의 문제인지 나눈 뒤 직접 재현하세요. 모르는 상태에서 빌드를 다시 올리면 같은 문제가 반복됩니다.