유료 워치페이스 앱 제출 상태 검증 완성

유료 watchface 앱 5개를 마켓플레이스 콘솔에 제출하고, 각 앱의 제출 상태를 자동으로 검증하는 기능을 완성했다. 이 작업은 단순해 보이지만, 여러 앱을 일괄 관리하면서 휴먼 에러를 줄이고 출시 프로세스를 재현 가능하게 만드는 데 꽤 중요했다.

왜 이 작업이 필요했나

처음에는 각 watchface 앱(graphite, ivory, noir, slate 등)을 수동으로 콘솔에 접속해 제출하고, 상태를 확인했다. 문제는 이게 번거로울 뿐 아니라 실수하기 쉽다는 것이다. "어떤 앱은 제출했는데 어떤 앱은 빼먹었다", "제출했는데 검증 과정에서 걸렸는데 몰랐다" 같은 상황이 발생할 수 있다. 특히 유료 앱은 출시 후 환불·거부 같은 일이 발생하면 팀 전체에 영향을 미치기 때문에, 상태 관리가 정확해야 한다.

또한 팀에 새로운 멤버가 들어오거나 다른 사람이 이 업무를 인수인계받을 때, "어떤 순서로 제출하는지", "각 앱의 빌드 설정은 뭐가 다른지" 같은 절차를 일일이 설명하기보다는, 코드와 문서가 그 일을 대신하도록 하는 게 훨씬 효율적이다.

무엇을 바꿨는가

변경 파일들의 역할:

이 변경들은 함께 작동한다. build.gradle.kts가 정확하게 설정되어야 빌드가 성공하고, PAID_RELEASE_PLAN.md에 그 절차가 기록되며, .gitignore가 민감한 정보를 보호한다.

상태 검증의 중요성

"verify state"라는 표현이 핵심이다. 제출 후 "상태가 정말 SUBMITTED인지", "validation이 통과했는지" 자동으로 확인하는 로직이 있으면, 몇 달 뒤에 "어? 이 앱은 왜 아직 pending인데?" 하는 상황을 조기에 발견할 수 있다. 또한 여러 앱을 동시에 제출할 때, 하나라도 실패하면 그걸 즉시 알 수 있게 된다.

이런 검증 로직은 특히 CI/CD 파이프라인에 들어가기 좋다. 예를 들어 "매주 월요일 아침에 모든 유료 앱의 제출 상태를 자동으로 확인하고, 문제가 있으면 팀에 알린다" 같은 자동화가 가능해진다.

배운 점과 다음 고려사항

이 작업을 하면서 느낀 건, 출시 프로세스가 복잡할수록 자동화와 문서화의 필요성이 높다는 것이다. 유료 앱은 단순히 코드를 푸시하는 게 아니라, 서명, 제출, 검증, 모니터링 같은 여러 단계를 거친다. 이 각 단계에서 휴먼 에러가 발생할 가능성이 높다.

앞으로 생각해볼 부분:
- 각 앱별 제출 로그: 언제 누가 제출했는지, 어떤 버전이 제출됐는지 추적하기
- rollback 절차: 문제가 발생했을 때 빠르게 이전 버전으로 되돌리는 방법
- 팀 내 권한 관리: 누가 제출할 수 있는지, 검증 권한은 누가 가지는지 정의

5개 앱을 일괄 관리하다 보니, 각각을 개별적으로 취급하는 것보다는 "하나의 출시 시스템"으로 보는 게 훨씬 효율적이다는 걸 알았다. 아직 끝이 아니라, 이게 첫 번째 단계일 뿐이다.

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

• 외장SSD 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

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