앱 리젝 답변: Resolution Center 대처법

Resolution Center라는 이름은 이제 없어요. 리젝에 답할 때는 앱의 App Review 섹션에서 Reply to App Review 버튼을 눌러요. 영어로 쓰고, 세 가지 정보를 주세요. 무엇이 문제였는지, 무엇을 바꿨는지, 어떻게 확인하면 되는지요. App Review Board는 이 답변을 보낸 다음에만 쓰는 단계예요. 그것도 앱이 인용된 규정을 지키고 있다고 확신할 때만요.

저는 2026년에 제 앱들을 위해 이런 답변을 직접 썼어요. 미니게임 알람 앱 Solys, 그리고 트레이딩 시뮬레이터 TradaZen이에요. 지금 어디서 답하는지, 무엇을 쓰는지, 언제 영상을 첨부하는지, 언제 이의 제기를 하는지, 그리고 무엇이 통하지 않는지 정리했어요. 리젝 사유 자체는 애플이 앱을 리젝하는 이유를 읽어 보세요.

Resolution Center는 어디로 갔나요?

공식 도움말 Reply to App Review messages는 이제 App Review 섹션이라고 불러요. 제출물을 다시 보낼 때까지 여기서 첨부 파일을 포함해 애플과 메시지를 주고받아요. 경로는 이래요.

1. Apps에서 앱을 열어요.
2. 페이지 상단에서 해결되지 않은 문제 링크를 클릭해요. 도움말의 다른 페이지에서는 View App Review Issues & Messages라고 불러요.
3. In Progress 영역에서 제출물 옆의 Resolve를 클릭해요.
4. Reply to App Review를 클릭하고 Reply 필드에 작성해요.
5. 스크린샷이나 문서를 첨부하려면 Attach File을 클릭한 뒤 Reply를 클릭해요.

답변할 수 있는 역할은 Account Holder, Admin, App Manager뿐이에요. App Review 페이지에 따르면 제출 상태는 App Store Connect나 iPhone, iPad용 App Store Connect 앱에서 확인할 수 있어요.

쓰기 전에: 어떤 메시지를 받았나요?

올바른 답변은 메시지에 따라 달라져요. 내 앱을 변호하고 싶은 마음이 기준이 아니에요. 제가 답변 필드를 열기 전에 쓰는 표예요.

애플이 말하는 것	할 일	새 빌드
Information Needed	질문에 답하기	아니요
버그나 문제 있는 화면	수정 후 답하기	예
스토어 정보, 링크, 스크린샷	스토어 정보 수정	아니요
앱을 잘못 이해함	증거와 함께 설명	경우에 따라
계속되는 의견 차이	Board에 이의 제기	아니요
Bug Fix Submissions 제안	답변으로 수락	아니요

세 가지가 모든 걸 바꿔요.

• 메타데이터 리젝에는 새 빌드가 필요 없어요. 애플 도움말에 그렇게 나와 있어요. 수정한 뒤 같은 빌드를 다시 보내면 돼요. 문제 문구가 스토어 정보에 있는 2.3.10 리젝이 흔히 이런 경우예요.
• "Information Needed"는 본질적인 리젝이 아니에요. 심사자가 질문을 하는 거예요. 가이드라인 2.1 가이드에서 실제 버그 지적과의 차이를 설명해요.
• Bug Fix Submissions는 제안이에요. 앱이 이미 출시되어 있고 메시지가 "Bug Fix Submissions: The issues we've identified below are eligible to be resolved on your next update"로 시작한다면, 메시지에 답해서 업데이트 승인을 요청할 수 있어요. 이때 앱을 다시 제출하지 마세요. 새 심사가 시작돼요. 문제는 다음 버전에서 해결하면 돼요.

무엇을 쓸까: 네 블록 템플릿

애플은 App Review에 연락하기에 관한 조언을 공개했어요. 해야 할 것: 요청하는 내용을 구체적으로 쓰고, 앱이 오해받았다고 생각하면 앱을 이해하는 데 도움이 되는 정보를 주세요. 피할 것: 답변 필드로 이의 제기를 하거나 신속 심사를 요청하는 것, 다른 개발자 앱의 진행 상황을 묻는 것이에요.

제 템플릿은 네 블록이에요. 영어로, 형용사 없이 쓰세요. 대괄호 안은 모두 바꾸고, 보낸 빌드에서 사실인 것만 쓰세요.

Hello App Review team,

Thank you for your review and for the details on
Guideline [number].

What you reported: [one sentence that restates
Apple's message, in your own words].

What changed in build [version (build)]:
- [Screen or element]: [what it does now]
- [Screen or element]: [what it does now]

How to verify:
1. [Starting point, e.g. fresh install]
2. [Action]
3. [Expected result]

We tested this flow on [devices and iOS versions].
[Attached: a short screen recording of the fixed flow.]

If anything else is unclear, please tell us which
screen or wording, and we will change it.

Best regards,
[Your name]

블록마다 역할이 있어요. 첫 번째는 메시지를 읽었다는 증거예요. 두 번째는 빌드를 명시해요. 심사자는 의도가 아니라 바이너리를 테스트하니까요. 세 번째는 심사자의 시간을 아껴 줘요. 마지막은 변론하지 않고 대화의 문을 열어 둬요.

규정별 템플릿은 전용 가이드에 있어요. 예를 들어 가이드라인 3.1.2나 가이드라인 4.3이요. 다운로드할 수 있는 App Review 노트 템플릿에도 답변 틀이 들어 있어요.

Solys와 TradaZen 답변에서 배운 것

Solys, 가이드라인 2.1. 심사자는 게임을 우회할 방법을 요구했어요. 제 답변은 막히는 화면과 온보딩의 플레이 가능한 데모를 짚은 뒤 진짜 원인을 밝혔어요. iPad 호환 모드에서는 장애물을 넘을 수 없게 됐던 거예요. 번호를 붙인 수정 사항 두 개를 나열했고, 그중 하나는 실패 후 데모를 건너뛰는 링크였어요. 그다음 iPhone SE부터 가장 큰 iPhone까지 테스트한 시뮬레이터를 적었어요. 알람의 긴급 정지 버튼도 설명했는데, 그건 버튼을 작동시키는 코드를 다시 읽어 본 뒤였어요. 빌드에서 확인하지 않은 내용은 앱에 대해 절대 쓰지 마세요.

TradaZen, 가이드라인 5.6. 2026년 10월, 애플은 앱이 원치 않는 인앱 구매를 유도한다고 판단했어요. 구체적인 요소는 지목하지 않았어요. 저는 사용자를 속일 수 있는 부분을 찾아봤어요. 페이월 상단의 X 버튼이 화면을 닫지 않고 할인 오퍼를 열고 있었어요. 제 답변은 이 점을 한 문장으로 인정했어요. 제 실수였다고요. 그다음 화면별로 모든 변경 사항을 나열했어요. X 버튼을 선물 아이콘으로 바꿨고, 오퍼가 저절로 다시 열리지 않게 했고, 프로모션 알림 하나를 삭제했어요. 여전히 규정을 지키는 부분도 언급했어요. 실제 청구 가격이 가장 눈에 띄고, 구매 복원과 법적 링크가 있다는 점이요. 마지막으로 여전히 모호하다고 보는 화면이 있으면 무엇이든 수정하겠다고 제안했어요. 새 빌드도 함께 보냈어요.

두 답변은 같은 논리를 따라요. 진짜 원인, 눈에 보이는 수정, 그것을 확인하는 경로예요.

영상이나 스크린샷을 언제 첨부할까

애플 도움말은 스크린샷과 문서를 첨부 파일로 받아요. 수정된 화면의 짧은 영상은 세 가지 경우에 유용해요.

• 문제가 기기나 조건에 따라 달라질 때. iPad 호환 모드나 권한 거부 같은 경우요.
• 화면까지 가는 경로가 길 때. 예를 들어 온보딩 끝에 있는 화면이요.
• 기능을 재현하기 어려울 때. App Review 페이지는 재현하기 어려운 환경이나 특정 하드웨어가 필요한 기능이라면 데모 영상을 준비해 두라고 해요.

액세서리와 연결된 앱이라면 완전한 심사 도움말이 화면 녹화가 아니라 애플 기기에서 실제로 촬영한 영상을 요구해요. 페이월 문구나 이름을 바꾼 버튼이라면 스크린샷으로 충분해요.

통화나 미팅 요청하기

글로 부족하다면 애플은 두 가지 옵션을 제공해요.

• 애플 담당자와의 통화. App Review의 첫 답변을 받은 뒤 Reply to App Review 창에서 요청해요. 시간대와, 원한다면 희망 언어를 적으세요. 미리 App Review Information의 연락처를 확인하세요. 애플에 따르면 이런 통화는 보통 영업일 기준 3~5일 안에 이뤄져요.
• App Review와의 30분 화상 미팅. 화요일이나 목요일에 규정에 대해 이야기하는 자리예요. 정보 제공용이라서 심사를 앞당기거나 보장하지 않아요.

App Review Board에 이의 제기하기

이의 제기는 마지막 단계예요. Appeal to the App Review Board 페이지에 따르면, 앱이 규정을 지킨다고 생각하는데 리젝됐거나 부당하게 대우받았다고 느낄 때 적합해요.

먼저 App Store Connect에서 메시지에 답해 상황을 명확히 하세요. 그래도 안 되면 Submit an appeal to App Review 양식을 작성하세요. 규칙은 이래요.

• 리젝된 앱당 이의 제기는 한 번이고, 인용된 모든 규정을 다뤄야 해요.
• 규정을 인용하고, 앱이 어떻게 지키는지 항목별로 설명하세요.
• 이미 수정해서 앱을 다시 보냈다면 이의 제기를 하지 마세요.
• 단순한 정보 요청에는 이의 제기를 하지 마세요.

애플은 두 가지 예시를 들어요. 제가 옮겨 볼게요. 완전한 예: "제 앱은 정보 불충분으로 2.1에 따라 리젝됐습니다. 데모 계정과 기능 테스트 단계는 App Review Information에 있으며, 기능을 보여 주는 스크린샷도 함께 있습니다." 불완전한 예: "이 앱은 우리 회사에 중요하며 리젝되지 말았어야 합니다."

Board는 App Store Connect로 답하고, 정보를 요청하거나 통화를 제안할 수 있어요. 애플은 이의 제기 처리 기간을 공개하지 않아요. 애플 포럼에서는 2주 넘게 기다렸다는 개발자들도 있어요. 수정이 간단하다면 고친 빌드를 다시 보내는 편이 대개 더 빨라요.

통하는 것, 통하지 않는 것

도움이 되는 것	역효과인 것
애플의 사유를 다시 짚기	내 입장 변론하기
수정된 빌드 명시하기	나중에 고치겠다고 약속하기
따라갈 경로 제공하기	경쟁 앱 언급하기
증거 첨부하기	Reply로 이의 제기하기
완전한 답변	고치지 않고 다시 보내기

"제 화면은 이미 승인됐었어요"도 통하지 않아요. 버전마다 다시 심사를 받고, 때로는 다른 심사자가 봐요. App Review Guidelines는 같은 규정으로 여러 번 리젝된 앱은 심사가 더 오래 걸린다고 경고해요. 심사 기간은 App Store 심사 기간을 읽어 보세요.

보내기 전에 답변 검토받기

Review Kit에는 제 앱들이 받은 실제 메시지, 보낸 수정 사항, 그리고 애플이 리젝하면 답변을 준비해 주는 Claude Code 스킬이 들어 있어요. 사람의 시선이 필요하다면 저와 한 시간 예약하세요. 애플의 메시지를 함께 읽고 답변을 같이 써요. 전체 과정은 애플에 리젝된 앱 페이지에 있어요.

아직 앱을 제출하지 않았나요? 무료 진단을 받아 보세요. 제 애플 리젝 방지 체크리스트를 보내 드려요. 이런 답변을 쓸 일이 없도록요.

자주 묻는 질문

App Store Connect에서 Resolution Center는 어디에 있나요?

이제 App Review 섹션이라고 불러요. 앱을 열고 페이지 상단의 해결되지 않은 문제 링크를 클릭한 뒤, 제출물 옆의 Resolve를 클릭하세요. Reply to App Review 버튼을 누르면 답변 필드와 첨부 파일 추가가 열려요.

애플은 답변하는 데 얼마나 걸리나요?

애플은 서면 답변 기간을 공개하지 않아요. 심사의 경우 애플은 제출물의 50% 이상을 24시간 안에, 90%를 48시간 안에 검토한다고 밝혀요. App Review에 요청한 통화는 보통 영업일 기준 3~5일 안에 이뤄져요. App Review Board는 발표된 기간이 없어요.

App Review에 프랑스어로 답해도 되나요?

애플 도움말은 서면 답변의 언어를 정해 두지 않아요. 저는 한 번에 이해되도록 짧은 영어 문장으로 써요. 통화라면 애플이 희망 언어를 적을 수 있게 해 주지만, 보장되지는 않아요.

리젝에 몇 번까지 이의 제기할 수 있나요?

리젝된 앱당 한 번이에요. 메시지가 여러 규정을 인용했다면 이의 제기에서 모두 다뤄야 해요. 애플은 먼저 App Store Connect에서 답하고, 이미 수정된 빌드를 다시 보냈다면 이의 제기를 하지 말라고 해요.

답하기 전에 빌드를 다시 보내야 하나요?

문제가 앱 안에 있다면 그래요. 수정하고 빌드를 보낸 다음, 그 빌드를 명시해서 답하세요. 스토어 정보나 스크린샷 같은 메타데이터 리젝이라면 아니에요. App Store Connect에서 수정하고 같은 빌드를 다시 보내면 돼요.