참고, 2026년 8월: 이 글은 이전 릴리스 때 작성되었고, 당시의 등급 구조를 설명하고 있어요. AlcoLog는 v1.2.0에서 Pro 등급을 Premium으로 합쳤기 때문에 지금은 유료 등급이 하나뿐이에요. 합치는 과정에서 잃은 기능은 없고, Pro를 쓰던 분은 추가 비용 없이 Premium으로 옮겨졌어요.

구독, 앱 내 구입, Watch 컴패니언 앱, 위젯, 또는 건강과 조금이라도 관련된 포지셔닝을 갖춘 v1.0 iOS 앱을 곧 출시하려 한다면, App Review 과정은 문서에서 말하는 것보다 어려울 거예요. 이 글은 한 번의 출시 과정(5일 동안 네 번의 거절, 다섯 명의 심사자, 하나의 바이너리)과 그 과정을 버틸 수 있게 해 준 패턴을 정리한 기록이에요. 이 경험은 진지한 인디 앱을 출시하는 일 중에서 가장 기록이 적은 부분이고, 문서화된 버전(WWDC 세션, 심사 지침 페이지, 개발자 포럼)은 매일 겪는 현실과 맞지 않기 때문에 공유해요.

지금 한창 심사 중이고 당장 쓸 수 있는 해결책을 찾고 있다면, "제출 전에 고쳐야 할 것"과 "이해해 둘 만한 패턴"으로 바로 건너뛰세요. 맥락이 궁금하다면 개인적인 타임라인은 글 후반부에 있어요.

# 제출 전에 고쳐야 할 것

네 번의 거절에서 나온 항목들이에요. 미리 고쳐 두면, 구독이 있는 민감한 카테고리 v1.0 앱이 거절당할 만한 부분의 대부분을 없앨 수 있어요.

# 구독 결제 화면의 가격 표시 위계

구독에 관한 Apple의 휴먼 인터페이스 가이드라인은 가격 표시에 대해 모호한 부분이 없어요. 청구되는 금액이 가장 눈에 띄는 가격 요소여야 해요. 마케팅 본능(할인이 이득처럼 느껴지게 하기)은 여기서 틀린 본능이에요. 규정 준수 본능(청구 금액을 타이포그래피의 주인공으로 만들기)이 맞는 본능이에요.

실제로는 이런 뜻이에요. 정가가 가장 크고 굵은 요소여야 해요. 첫 구매 가격이나 할인 가격은 더 작게, "첫 기간:"이라는 명시적인 라벨과 함께 표시해야 해요. 작은 표시 안에 퍼센트 배지를 넣지 마세요(“25% OFF” 대신 "LAUNCH OFFER"를 쓰세요). 이 점에 대한 3.1.2© 결제 및 구독 조항의 적용은 심사자마다 일관돼요.

# 명시적인 데이터 삭제 경로

'계정’이 선택형 익명 식별자에 불과하더라도, Apple의 5.1.1(v)는 라벨이 붙어 있고, 눈에 보이고, 즉시 작동하는 삭제 경로를 요구해요. 토글을 끄는 것을 암묵적인 삭제로 보는 방식은 개발자 입장에서는 규정을 지킨 것처럼 보이지만, 현재의 심사 기준은 충족하지 못해요.

첫 빌드부터 개인정보 보호나 설정 화면에 명시적인 “내 데이터 삭제” 버튼을 넣어 두세요. 확인 알림도 추가하세요. 주변 문구가 나중에 고칠 생각인 임시 일정이 아니라 실제 삭제 동작을 설명하는지 확인하세요.

# Info.plist에서 흔적만 남은 선언 점검하기

백그라운드 모드, 백그라운드 가져오기, 위치 권한, HealthKit 선언 같은 Info.plist 항목은 코드베이스가 바뀌는 동안 몇 달씩 쓰이지 않은 채 남아 있을 수 있어요. 이런 항목이 실제 기능과 맞지 않으면 지적을 받아요. 여기에 대한 2.5.4 소프트웨어 요구 사항의 적용은 기계적이고 모호한 부분이 없어요.

구체적으로는, UIBackgroundModes 항목은 모두 그것을 실제로 쓰는 기능과 짝을 이뤄야 해요. 앱이 "location"을 백그라운드 모드로 선언했는데 연속 백그라운드 위치를 전혀 쓰지 않고 allowsBackgroundLocationUpdates = false로 되어 있다면, 그 선언을 지우세요. 지역 모니터링에는 필요 없어요. 점검은 10분이면 끝나고, 거절 한 번을 막아 줘요.

# App Store 메타데이터에 작동하는 이용 약관 링크

App Store Connect의 개인정보 처리방침 항목은 잘 알려져 있어요. 이용 약관 요구 사항은 덜 알려져 있어요. Apple의 표준 EULA를 쓴다면 앱 설명에 이용 약관 링크를 넣으세요. 맞춤 EULA를 쓴다면 App Store Connect의 맞춤 EULA 항목에 추가하세요.

약관 페이지 자체에는 모든 유료 상품의 구독 기간, 가격, 갱신 방식이 공개되어 있어야 해요. 대부분의 팀은 이런 요소가 여러 페이지에 흩어져 있거나 개인정보 처리방침 안에 묻혀 있어요. 심사자가 2분 안에 읽을 수 있는 약관 페이지 하나로 모으세요.

# App Preview 영상: 있는 그대로의 화면 녹화를 쓰세요

3D 휴대폰 목업, 기기 프레임, 연출된 마케팅 구성은 2.3.4 정확한 메타데이터 조항에서 심사자의 재량에 달린 문제예요. 공개 가이드 페이지는 기기 프레임을 명시적으로 금지하지 않지만, 심사자들이 따르는 내부 교육 자료는 금지하는 것으로 보여요. 기본 해상도의 평범한 화면 녹화는 확실히 안전해요.

마케팅용 꾸밈은 자체 웹사이트, 소셜 미디어, Reddit에 쓰세요. App Preview 자리에는 화면 녹화를 넣으세요. "잘 다듬은 목업 미리보기"와 "있는 그대로의 화면 녹화 미리보기"의 전환율 차이는 작아요. 줄어드는 위험은 커요.

# App Review Notes에 명시적인 IAP 이동 경로

심사자는 앱 하나에 5~15분의 시간 예산으로 일해요. 해당 버전에 연결된 IAP를 항상 모두 찾아내지는 못해요. IAP에 앱의 서로 다른 경로(별도의 결제 화면, 별도의 카드, 더 깊은 메뉴)로 접근한다면, App Review Notes에 모든 IAP로 가는 경로를 한 단계씩 적어 두세요.

효과가 있었던 형식이에요.

Premium 구독과 평생 IAP: 설정 탭 > Premium 카드 > Premium 받기 버튼 > Premium 업그레이드 시트 Pro 구독과 평생 IAP: 설정 탭 > Pro 카드 > Pro 받기 버튼 소모성 팁 항목: 설정 탭 > 등급 카드 아래로 스크롤 > 팁 카드 > 팁 옵션 표시

과해 보일 수 있어요. 하지만 이렇게 하면, 그렇지 않았을 때 하루를 잡아먹는 특정 거절(지침 2.1(b) 추가 정보 필요)을 막을 수 있어요.

# 제출과 확정된 출시일 사이의 일정 여유

민감한 카테고리에서 구독이 있는 v1.0을 제출한다면, 첫 제출과 외부에 확정해 둔 출시일 사이에 최소 7일의 여유를 잡으세요. 빠르게 답하면 거절 한 번의 주기는 대략 24시간이에요. 민감한 카테고리의 v1.0 제출에서 네 번의 거절은 현실적인 최악의 경우예요.

출시일이 외부에 확정되어 있다면(사전 주문 설정, 앱 내 이벤트 예약, 마케팅 일정 확정, 기자 연락 완료), 7일의 여유가 최소예요. 10일이면 더 편해요. 7일보다 짧으면 절차상의 거절 한 번 때문에 날짜를 놓칠 위험이 있어요.

# 이해해 둘 만한 패턴

문서만 봐서는 잘 드러나지 않는, 과정 안에서 본 몇 가지예요.

# 거절할 때마다 다른 것을 찾아내요

네 번의 거절은 서로 겹치지 않는 항목을 지적했어요. 모든 심사자는 이전 심사자가 통과시킨 모든 화면에 접근할 수 있었어요. 첫 번째 심사자는 메타데이터의 EULA 링크를 지적했어요. 두 번째는 같은 바이너리에서 서로 다른 세 가지(백그라운드 모드, 가격 표시, 삭제 버튼)를 지적했어요. 세 번째는 마케팅 자료를 지적했어요. 네 번째는 화면 이동에 관한 질문을 했어요.

이건 버그가 아니에요. App Review가 구성된 방식의 특징이에요. 심사는 앱 단위가 아니라 문제 단위로 이뤄지는 것으로 보여요. 심사자는 시간 예산 안에서 처음 발견한 큰 문제에서 멈춰요. 빠짐없이 점검할 의무가 없고, 이전 심사자가 받아들인 부분에 ‘이미 통과’ 상태를 주는 시스템도 없어요. 이 구조는 개발자의 경험보다 조직의 처리량을 우선해요.

그 의미는 이래요. 한 번의 심사로 종합적인 점검을 받을 수는 없어요. 지금 심사자가 자신의 시간 안에서 찾아낸 것만 받을 수 있고, 다음 심사자가 다음 차례에 독립적으로 다른 무엇이든 찾아낼 수 있다는 걸 받아들여야 해요.

# 거절은 대체로 갈수록 범위가 작아져요

보장이 아니라 느슨한 패턴이에요. 첫 거절은 대개 본질적이에요(빠진 요구 사항, 구조적인 문제). 두 번째도 여전히 본질적이지만 체크리스트에 가까워요. 세 번째는 주변적인 메타데이터로 옮겨 가요. 네 번째는 때로는 거절이 아니라 절차상의 질문이에요.

이유는 앱이 심사를 거칠 때마다 '나아져서’가 아니에요. 이전에 지적된 항목은 고쳐지고, 이전에 통과한 항목은 더 이상 대상이 아니게 되면서, 바이너리와 메타데이터에서 심사할 수 있는 영역이 매번 줄어들기 때문이에요. 심사자들이 각자 독립적으로 남은 체크리스트 영역을 소진해 가니까, 나중 심사일수록 찾을 게 적어요.

과정 중에는 위안이 되는 패턴이지만, 여기에 기대지는 마세요. 후반의 심사자도 앞선 심사자들이 놓친 본질적인 항목을 찾아낼 수 있어요.

# 심사자마다 꼼꼼함이 크게 달라요

같은 바이너리에 대한 네 번의 심사에서, 심사자마다 찾아낸 것의 차이가 컸어요. 한 명은 세 가지를 찾았어요. 다른 한 명은 주변적인 항목 하나를 찾았어요. 세 번째는 앱의 두 번째 탭에 있는 카드를 탭하면 답이 나오는 질문을 했어요.

어떤 심사자가 내 제출물을 받을지는 전혀 통제할 수 없어요. 편차를 전제로 계획하세요. 다음 심사가 이전보다 더 꼼꼼하거나 더 관대할 거라고 가정하지 마세요. 폭넓은 분포에서 독립적으로 뽑힌 표본이에요.

# 베타 앱 심사 승인은 정식 App Review 승인을 예측하지 못해요

두 과정은 담당 팀도 기준도 달라요. 정식 심사에서 지적받는 기능을 그대로 갖춘 빌드가 베타를 통과하는 건 모순이 아니에요. 서로 다른 두 심사 과정일 뿐이에요.

TestFlight로 정식 심사를 통과할 준비가 되었는지 확인하고 있다면, 잘못된 신호에 기대고 있는 거예요. TestFlight는 빌드 유효성과 기본적인 규정 준수 문제를 잡아내요. 정식 App Review는 적용 범위 전체를 봐요. 둘은 서로 대신할 수 없어요.

# 민감한 카테고리의 심사 요인은 겹쳐 쌓여요

구독은, 특히 첫 구매 가격이나 체험 혜택이 있으면 자동으로 3.1.2 조항 적용을 불러요. 건강과 관련된 카테고리(음주, 피트니스, 정신 건강, 수면)는 1.4.1 의학적 주장 문제에 대한 심사자의 관심을 끌어요. 개인정보에 민감한 기능(위치, HealthKit, 익명 식별자)은 5.1.1 검토를 불러요. 첫 버전인 v1.0 제출은 종합 심사를 받아요. 출시일과 연결된 앱 내 이벤트는 메타데이터 검토를 불러요.

요인 하나하나는 감당할 만해요. 하지만 곱셈처럼 겹쳐 쌓여요. 구독, 여러 플랫폼, 앱 내 이벤트를 갖춘 민감한 카테고리의 진지한 출시는 모든 요인이 동시에 작동해요. IAP가 없는 무료 단일 화면 유틸리티는 2분 만에 통과해요. 심사가 얼마나 어려운지는 앱의 품질이 아니라 출시의 진지함과 폭에 비례해요.

# 문서와 실제 적용이 항상 완벽히 맞지는 않아요

거절 사유가 링크된 공개 페이지에 명시되어 있지 않은 지침을 인용할 수도 있어요. 심사자들은 공개 심사 지침과 겹치지만 똑같지는 않은 내부 교육 자료를 바탕으로 일해요. 공개 문서와 맞지 않는 거절을 받았다면 정중하게 반론을 제기할 수 있어요. 번복될 때도 있고, 아닐 때도 있어요.

반론을 제기할 때는 Resolution Center에 서면으로, 공개 지침을 인용하고 적용된 구체적인 조항을 묻는 구조화된 문단으로 쓰세요. 불만이 드러나는 표현은 피하세요. 심사자는 정해진 시간 안에서 답변을 읽어요. 꼼꼼히 읽히는 답변은 그 사실을 존중하는 답변이에요.

# 거절에 건설적으로 대응하는 방법

Resolution Center에서 주고받을 때 도움이 되는 몇 가지 실용적인 메모예요.

# 가능하면 당일에 답하세요

과정에서 가장 빨리 벗어나는 방법은 과정을 계속 움직이게 하는 거예요. 거절 주기의 시계는 답할 때마다 다시 시작돼요. 당일 답변은 같은 주 안의 해결로 이어지고, 며칠 걸리는 답변은 그만큼 과정을 늘려요.

그러려면 팀이 수정 사항을 빠르게 내보낼 수 있는 구조여야 해요. 인디 개발자라면 대개 제출 후 며칠 동안 일정을 비워 둔다는 뜻이에요. 제출 기간을 뒤에서 돌아가는 일처럼 다룰 수는 없어요.

# 수정 사항은 한 번의 재제출에 묶으세요

거절에서 세 가지가 지적되었다면, 세 가지를 모두 고친 뒤 다시 제출하세요. “세 개 중 두 개는 고쳤고, 세 번째는 작업 중이에요” 같은 답장을 보내지 마세요. 다음 심사자는 완전히 다른 항목을 찾아낼 거고, 일부만 고친 답장은 대기열에 과정 하나를 더 얹을 뿐이에요.

# 수정 확인용 화면 녹화를 첨부하세요

사소하지 않은 수정이라면, 수정이 작동하는 모습을 보여 주는 30초짜리 화면 녹화를 첨부하세요. 삭제 흐름, 바로잡은 가격 표시, 새 이동 경로 같은 것들이요. 심사자가 직접 찾아가지 않고도 수정을 볼 수 있으면, 다음 심사에서 그 문제를 통과시킬 가능성이 높아져요.

# 답장에서 종합적인 심사를 요청하세요

남은 우려가 있다면 추가 주기로 나눠지지 않고 이번 심사에서 한꺼번에 제기해 달라고 정중하게 요청하는 건 합리적이에요. 항상 통하지는 않지만, 가끔은 통해요. 표현이 중요해요. “지금까지 제기된 모든 문제에 신속하고 성실하게 대응했습니다. 추가 주기를 최소화할 수 있도록, 이번 심사에서 해당되는 모든 지침에 대해 종합적으로 검토해 주시면 감사하겠습니다.”

이렇게 하면 심사자의 다음 답변은 앱을 통과시키거나, 남은 우려를 모두 제기하는 쪽이 돼요. 두 결과 모두 또 한 번의 단일 문제 거절보다 나아요.

# 매번의 심사를 독립적인 것으로 다루세요

다음 심사자가 이전 심사자의 메모를 읽었을 거라고 가정하고 싶어져요. 아마 읽지 않았을 거예요. Resolution Center 답장은 매번 그것만으로 완결되어야 하고, 이전 대화를 보지 못한 사람을 위해 제출 상태를 요약해야 해요.

그래서 주기마다 약간의 반복은 필요해요. 첫 번째 심사자에게 효과가 있었던 자세한 App Review Notes는 세 번째 심사자를 위해 다시 첨부하거나 다시 적어야 해요. 조직의 기억을 가정하지 마세요.

# 개인적인 타임라인

맥락을 위해, 실제 5일이 어땠는지 적어 볼게요.

토요일 오후에 빌드 22를 제출했어요. 제출물에는 자동 갱신 구독 4개, 비소모성 평생 IAP 2개, 소모성 팁 항목 5개, 앱 설명, 스크린샷, App Preview 영상, 출시 주간과 연결된 앱 내 이벤트, 그리고 175개 국가에서 출시일에 맞춰 설정한 사전 주문이 들어 있었어요.

그 전 6주 동안 예상할 수 있는 문제를 하나씩 체계적으로 없앴어요. App Review Notes에는 심사가 몰릴 가능성이 가장 큰 부분을 심사자가 이해하기 쉽게 설명해 두었어요. DSA 판매자 정보는 일주일 전에 승인되었어요. App 개인정보 보호 라벨도 게시되어 있었어요. 베타 앱 심사는 여러 빌드를 통과시켰어요. 준비됐다고 느꼈어요.

2일차, 오전 5시 15분: 첫 번째 거절. 지침 3.1.2©. App Store 메타데이터에 작동하는 이용 약관 링크가 없었어요. 당일에 수정을 내보냈어요(앱 내 업그레이드 시트에 약관 링크를 추가하고, 약관 페이지에 모든 유료 상품을 공개하도록 내용을 늘리고, 앱 설명을 업데이트했어요). 주기 하루.

4일차, 오후 4시 3분: 두 번째 거절. 메시지 하나에 세 가지 항목. 지침 2.5.4(있으면 안 되었던, 흔적만 남은 UIBackgroundModes “location” 항목). 지침 3.1.2©(첫 구매 가격이 청구 금액보다 더 눈에 띄게 표시됨). 지침 5.1.1(v)(익명 식별자 토글 끄기에 라벨이 붙은 명시적인 삭제 버튼이 필요함). 당일에 수정을 내보냈어요(Info.plist 항목을 지우고, 가격 위계를 뒤집고, 확인 알림이 있는 명시적인 “익명 데이터 삭제” 버튼을 추가했어요). 주기 하루.

5일차, 오후 5시 5분: 세 번째 거절. 지침 2.3.4 정확한 메타데이터. App Preview 영상에 앱 화면을 보여 주는 3D 휴대폰 목업이 들어 있었어요. 심사자의 메모는 “앱이 사용되는 모습을 충분히 보여 주지” 않는 콘텐츠를 지적했고, 특히 기기 프레임을 짚었어요.

문제는 developer.apple.com/app-store/app-previews/에 있는 공개 가이드 페이지가 기기 프레임을 명시적으로 금지하지 않는다는 거였어요. 가장 가까운 문서화된 규칙은 "앱 안에 머무르세요"로, 어깨 너머로 찍은 장면이나 기기를 물리적으로 조작하는 장면에 대한 예시가 붙어 있었어요. 둘 다 해당되지 않았어요.

출시가 나흘 남았고 이미 누적 지연이 나흘이었기 때문에, 저는 거래를 했어요. 재제출이 막히지 않도록 App Preview 영상을 뺐어요. 제가 놓친 구체적인 지침 조항이 있다면 재검토해 달라고 정중하게 요청했어요. 남은 우려가 있다면 이번 심사에서 한꺼번에 제기해 달라는, 정중하고 구조화된 문단도 보냈어요. App Preview 삭제는 그대로 유지되었어요. 재검토 요청에는 직접적인 답이 없었어요.

6일차, 오후 7시 23분: 네 번째 메시지. 지침 2.1(b) 추가 정보 필요. 엄밀히 말하면 거절은 아니었어요. 질문을 하기 위해 심사를 잠시 멈춘 거였어요. 심사자는 해당 버전에 연결된 IAP 중 두 개를 찾지 못했고, 어디서 찾을 수 있는지 물었어요.

심사자가 첨부한 스크린샷에는 첫 번째 결제 화면이 제대로 나와 있었어요. 두 번째 결제 화면은 같은 설정 화면에 있었고, 심사자가 이미 찾아간 첫 번째 카드 바로 아래 카드를 탭하면 열렸어요. 11개 IAP 전부에 대한 단계별 이동 경로를 적어 한 시간 안에 답장했어요.

7일차, 오후 8시 30분: 승인. 빌드가 통과했어요. 사전 주문이 활성화되었어요. 출시 주간은 5월 11일로 정해졌어요.

5일은 치열했어요. 돌이켜 보면 어느 날도 존폐가 걸린 일은 아니었지만, 과정 한가운데서는 그렇게 느껴지지 않았어요. 누적된 지연 때문에 출시일을 놓칠 뻔했지만 놓치지는 않았어요. 실제로 출시된 제품은 제출 전에 만든 그대로예요. 심사를 통과하려고 잘라 내거나, 바꾸거나, 미룬 건 하나도 없어요.

# 지적받지 않은 것에서 배울 게 있어요

네 번의 심사에서, 제가 가장 오래 걱정했던 부분들은 한 번도 지적받지 않았어요.

습관 점수 기능(가중치가 있는 여섯 가지 항목에 걸쳐 올린 요인과 내린 요인을 보여 주는 0~100점 점수). 약 기록 기능(기록만 하고, 조언을 내놓지 않음). 개인정보 보호 모델(계정 없음, 기기 안의 데이터, 명시적인 삭제가 가능한 선택형 익명 공유). HealthKit 쓰기. 건강 관련 주장이나 개인정보 문제를 불러올 가능성이 가장 컸던 이 부분들은 네 번의 심사 어디에서도 지적받지 않았어요. 독립적인 심사자 네 명이 모두 살펴봤고, 모두 지적하지 않기로 했어요.

민감한 카테고리에서 앱을 만드는 분들에게 주는 의미는 이래요. 선제적으로 공개하는 작업이 중요해요. 방법론을 설명하는 App Review Notes, 앱 안의 고지 사항, 신중하게 고른 이름, 앱 설명의 보수적인 표현. 어느 것도 화려하지 않아요. 하지만 모두가, 가장 논란이 될 만한 부분을 네 명의 심사자가 연달아 지적하지 않기로 한 데 기여했어요. 18+ 연령 등급, 첫 실행 때의 고지 사항 시트, 관련 영역의 명시적인 “의학적 조언을 제공하지 않아요” 문구. 모두 효과가 있었어요.

대신 지적받은 건 절차적이고 기계적인 부분이었어요. 가격 표시 위계. 백그라운드 모드 선언. 메타데이터 링크의 유무. 마케팅 자료의 구성. IAP를 찾기 쉬운지 여부. 앱의 본질적인 부분은 매번 통과했어요.

# 인디 개발자를 위한 마지막 메모

위에 깔끔하게 들어가지 않은 몇 가지 관찰이에요.

App Store에서 보이는 저렴한 앱들이 더 관대한 대우를 받는 게 아니에요. 기준이 낮았던 몇 년 전에 승인되었거나, 진지한 출시가 불러오는 검토 요인을 건드리지 않을 뿐이에요. 이 시스템은 공도 적고 위험도 적은 앱에 적은 검토로 보상해요. 들인 노력과 신경이 심사가 더 어려운 이유 중 하나예요. 앱의 품질에 대한 평가가 아니에요.

이 시스템에는 원하는 경험을 줄 만큼의 인력이 없어요. App Review는 외주 인력 풀이에요. 심사자는 앱 하나에 몇 분씩, 하루에 수십 개의 앱을 처리해요. 개별 앱의 구체적인 UX가 아니라 체크리스트로서의 심사 지침을 교육받아요. 공감의 간극은 개인의 문제가 아니라 구조의 문제예요.

인디 개발자들의 경험을 기록하면 결국 변화가 생겨요. Apple은 지난 10년 동안 App Review를 의미 있게 개선했어요. 그중 일부는 인디 개발자들이 꾸준히 경험을 기록하고 그 압력이 모인 데서 비롯되었어요. 내 거절 하나 때문에 특정 심사자가 다시 교육받지는 않아요. 하지만 인디 개발자들의 경험이 구조적으로 모이면 결국 조직을 움직여요.

만든 제품은 아마 그대로 출시될 거예요. 잘릴까 봐 걱정했던 기능은 모두 그대로 출시되었어요. 네 번의 거절을 겪는 동안은 존폐가 걸린 일처럼 느껴졌어요. 하지만 분명하게 답하기를 멈추지 않고 출시일 여유를 뒷주머니에 넣어 두는 한, 실제 결과는 승인으로 모였어요.

지금 한창 심사 중이고 Resolution Center에서 밤을 새우고 있다면: 출시는 이뤄져요. 계속 답하세요. 시스템은 개인적인 게 아니에요. 제품은 당신의 것이에요.

이 글은 iOS 음주 기록 앱 AlcoLog의 출시를 기록한 거예요. AlcoLog는 위에서 설명한 과정을 거쳐 2026년 5월 11일 App Store에 출시돼요. 앱은 무료이고 선택형 Premium 등급이 있으며, 지금 175개 국가에서 사전 주문할 수 있어요.

iOS 개발자이고 App Review 경험을 나누고 싶다면, r/iOSProgramming과 Indie Hackers의 인디 iOS 커뮤니티가 시작하기 좋은 곳이에요. 각자 겪은 일을 구체적으로 기록할수록, 모인 기록이 다음 사람에게 더 쓸모 있어져요.