Apple 심사 다섯 번 거부를 거쳐 배운 것들

일일 성경 앱을 iOS에 출시하기 위해 Apple App Store 심사에 올린 지 몇 주. 빌드 1에서 4까지 줄줄이 리젝을 맞으며, 다섯 번째 제출 때야 비로소 통과 소식을 받았다. 이번 작업은 그 과정에서 불거진 로그인 버그, EULA 미비, 계정삭제 기능 부재, Kakao 로그인 권한 정책 등 여러 이슈를 한 번에 해결하는 수정이었다.

왜 이렇게 자주 리젝을 받았나

Apple은 보안과 사용자 개인정보 보호에 엄격하다. 특히 신생 앱이나 업데이트에 대해서는 더 철저히 본다. 우리가 처음 제출했을 때는 이 기준을 제대로 파악하지 못하고 있었다.

주요 거부 사유들:

• 로그인 로직 버그: 사용자 인증 흐름에서 세션 관리가 불안정했다. 특정 상황에서 이미 로그인한 사용자를 다시 로그인하도록 강제하거나, 로그아웃 후에도 캐시된 정보가 남아있는 문제가 있었다.
• 법률 문서 부재: EULA(최종 사용자 라이선스 계약)가 앱 내에서 명시적으로 제시되지 않았다. Apple은 앱이 데이터를 수집하거나 서비스를 제공한다면, 사용자가 동의 과정을 거쳐야 한다고 본다.
• 계정삭제 기능 없음: GDPR과 한국의 개인정보 보호법 등에 따르면, 사용자는 언제든지 자신의 계정을 삭제할 수 있어야 한다. 이 기능이 없으면 심사 거부 사유가 된다.
• Kakao 로그인 권한 정책: SNS 연동 로그인을 제공할 때 Apple은 해당 제3자 서비스(Kakao)의 권한 정책을 명확히 하도록 요구한다.

변경 사항: 어디를 손댔나

특히 눈여겨봐야 할 부분은 상태 관리 로직과 설정 화면이다. 단순히 UI 버튼을 추가하는 것이 아니라, 로그아웃과 계정삭제의 동작을 명확히 구분해야 했다. 로그아웃은 로컬 토큰만 제거하지만, 계정삭제는 백엔드에 요청을 보내 영구적으로 사용자 데이터를 삭제해야 한다.

이 과정에서 배운 것

1. 첫 제출 전에 정책을 먼저 읽어야 한다

Apple의 App Store Review Guidelines는 무섭지만, 정확하다. "보안", "개인정보 보호", "데이터 삭제" 섹션을 꼼꼼히 읽고 나서 기능을 설계하면 후행 수정이 훨씬 줄어든다.

2. 법률 문서는 개발이 아니라 기획 단계의 책임

로그인 기능을 만들 때 "EULA를 앱에 띄워야 하나?"라는 질문이 개발 완료 후가 아니라, 설계 단계에서 나와야 한다. 이 부분은 팀 리드로서 더 명확한 체크리스트를 만들 필요를 느꼈다.

3. 상태 관리의 일관성이 보안의 기초

로그인 버그는 사실 "로그인을 빼먹은" 것이 아니라, 상태 전환 과정에서 일부 캐시가 정리되지 않은 문제였다. 이는 단순히 버그가 아니라, 사용자 신뢰도와 직결된다.

4. SNS 로그인은 진입장벽이 높다

Kakao 로그인 하나를 추가하려면 Apple 심사 과정에서도, iOS entitlements에서도 여러 단계를 거친다. 초기 설계 때 "우리가 정말 필요한 건가?"라는 질문을 던져야 한다.

결국 중요한 것

다섯 번의 거부는 실패가 아니라, 팀이 함께 학습하는 과정이었다. 개발자는 기술적으로 완벽한 코드를 짤 수 있어도, 법률·보안·정책 영역의 요구사항을 놓치기 쉽다. 이럴 때 QA, 기획, 법무팀과의 협업이 얼마나 중요한지 다시 한 번 체감했다. 다음 프로젝트부터는 심사 정책을 먼저 정리한 후에 기능 설계를 시작하겠다는 다짐을 했다.

🛒 이 글과 어울리는 추천 상품

• 노트북 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.