App Store 리젝 여러 건을 팀이 함께 추적하는 문서 체계 구축
목차
App Store 심사에서 리젝이 나올 때, 특히 여러 건이 동시에 들어오면 팀이 현황을 정확히 파악하기 어려워진다. "어디까지 수정했고, 어떤 부분이 남았는지" 를 공유하는 과정이 생각보다 복잡하기 때문이다. 메시지나 이슈로만 전달하면 시간이 지나면서 누가 뭘 하고 있는지 흐릿해지고, 특히 여러 사람이 동시에 다른 리젝에 대응할 때는 더 그렇다. 이번 작업은 그 문제를 명확한 문서 체계로 해결하려던 시도였다.
여러 리젝, 하나의 대시보드
App Store 에서 받은 리젝들을 정리해보니 ATT(광고 추적 투명성), 기기 음성 허용 프롬프트, 광고 노출 방식, 구매 확인 실패 등 여러 카테고리였다. 각각 수정 방식과 검증 기준이 다르기 때문에, 이를 한데 모아서 "지금 어떤 상태인가" 를 한눈에 볼 수 있게 정리해야 했다. 특히 팀원들이 각자 다른 부분을 병렬로 작업할 때는 더욱 그렇다.
APPLE-REVIEW-STATUS.md 라는 중앙 추적 문서를 만들고, 각 리젝별로 다음을 기록했다:
- 리젝 이유와 Apple 의 구체적 지적 사항
- 우리의 대응 계획
- 현재 진행 상황 (미작업 → 작업 중 → 완료)
단순히 텍스트로만 설명하는 것보다는 스크린샷을 before/after 로 나란히 배치하는 게 훨씬 효과적이었다.
Before/After 스크린샷의 가치
예를 들어 "광고 노출 방식 리젝" 을 수정했을 때, "우리가 이렇게 고쳤다" 는 말보다 실제 UI 변화를 보여주는 게 훨씬 명확하다. 리뷰어가 우리 변경사항을 믿고 다시 심사할 때도, 그 사람이 정확히 뭐가 바뀌었는지 알 수 있으면 실수가 줄어든다.
변경 파일에 포함된 스크린샷들:
- att-before-광고동시노출.png / att-after-광고차단.png → ATT 관련 UI 변화
- bedtime-기기음성.png → 기기 음성 허용 프롬프트 상태
- 구매-확인실패.png → 구매 흐름 검증 화면
각 스크린샷은 단순한 증거가 아니라, "우리가 뭘 이해했는지" 를 보여주는 커뮤니케이션 도구였다.
문서화가 팀 리딩에 미치는 영향
이런 추적 문서의 가치를 실감한 건 두 가지 상황에서다.
첫째, 새로 투입된 팀원이 "지금 Apple 심사 상황이 어떻게 되냐" 고 물었을 때, 한 파일을 보여주니 5분 만에 현황을 다 파악했다. 구두 설명은 건너뛸 수 있었다.
둘째, 심사 리젝이 대량으로 들어올 때도 문서가 있으니 패닉하지 않았다. "APPLE-REVIEW-STATUS.md 열어서 리스트에 추가하고, 각자 맡은 부분 진행하자" 는 명확한 프로세스가 생겼기 때문이다. 우선순위도 문서에 함께 기록할 수 있었다 — "우리가 먼저 해야 할 건 뭔가" 를 한눈에 보고 작업 순서를 결정할 수 있었다.
다음 단계로의 개선
이 방식을 운영하다 보니 몇 가지 더 보이는 부분들이 있다. 예를 들어:
- 각 리젝의 "예상 재심사 일정"을 기록하는 칸
- 리젝 원인이 우리 코드 버그인지, 정책 해석 차이인지 분류
- 과거 유사 리젝들과의 연관성 태그
하지만 지금은 기본 틀을 다져서 팀이 현황 추적을 편히 할 수 있게 만드는 게 우선이다. 문서화는 팀원들이 실제로 쓰는 형태로 진화해야 하니까.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.