워치페이스 옵트인 정책을 설치무관 기준으로 통일

6개 워치페이스의 옵트인 게이트 정책을 확정했다. 그간 모호했던 "언제부터 사용자에게 이 페이스를 공개할 것인가"라는 질문에 명확한 답을 내린 작업이다.

배경: 왜 정책을 문서화했는가

여러 워치페이스를 함께 개발·배포하다 보면 릴리스 타이밍을 어떻게 관리할지가 중요해진다. 특히 팀의 모든 구성원이 "이 워치페이스는 언제부터 일반 사용자에게 보일 것인가"에 대해 같은 기준으로 판단해야 한다. 그렇지 않으면 개발자마다 다르게 해석하거나, 운영 단계에서 롤아웃 일정이 꼬인다.

RELEASE_PLAN.md를 수정한 것도 이 때문이다. 릴리스 계획은 단순히 "언제 배포하나"를 정리하는 문서가 아니라, 팀 전체가 따를 의사결정 기록이기도 하다. 이 파일에 정책을 명시하면 코드리뷰나 배포 단계에서 "아, 이건 이 정책에 따르는 거네"라고 누구나 쉽게 확인할 수 있다.

결정: 게이트 기준을 "옵트인 일수"로 확정

게이트 = 옵트인 일수 (설치 시점 무관)

이 정책의 핵심은 "설치 무관"이다. 만약 설치 일수 기준이라면:
- 기존 사용자(예: 작년부터 앱을 쓴 사람)와 신규 사용자가 같은 버전이라도 다른 워치페이스를 보게 된다.
- 운영팀이 "이 워치페이스는 설치한 지 30일 이상인 사용자에게만 보이므로, 신규 가입자는 못 본다"는 별도 로직을 만들어야 한다.

대신 옵트인 일수 기준을 택함으로써:
- 모든 사용자가 동일한 조건에 따른다. 누가 먼저 설치했는지는 상관없다.
- "5.0.0 버전에서 crimson 페이스를 옵트인했다 → 모든 사용자는 5.0.0 설치 후 5일째부터 이용 가능"이라는 단순한 규칙이 된다.

이 정책은 네 개의 gradle 빌드 파일(faces/crimson/build.gradle.kts, faces/graphite/build.gradle.kts, faces/ivory/build.gradle.kts 등)에 반영된다. 각 워치페이스의 빌드 설정에서 메타데이터나 플래그로 "이 페이스는 몇 일 후 공개"라는 정보를 담을 수 있고, 클라이언트가 버전 정보와 함께 그 값을 읽어 화면에 보여줄지 말지를 판단한다.

팀 관점의 변화

이런 정책 확정이 작아 보일 수도 있지만, 실제로는:

실제로 빌드 파일들을 수정할 때 "어 잠깐, 이 워치페이스는 설치 일수로 할 건가, 옵트인 일수로 할 건가?" 하는 질문이 나오곤 했다. 문서화로 그런 회의를 줄인 것이다.

배운 점

이 커밋을 통해 느낀 것은, 기술 의사결정을 미루고 "일단 구현하고 나중에 정하자"는 태도가 팀에 얼마나 비용을 초래하는가 하는 것이다. 단순한 메타데이터 정책 하나가 결정되지 않으면:

• 개발자가 각자 다르게 해석해서 코드가 일관성 없어진다.
• 코드리뷰가 길어진다. ("왜 이 기준?")
• 나중에 "아 우리가 했던 정책이 뭐였지?"라고 문서를 뒤진다.

그래서 지금은 "문서부터 정책을 명확히 하고, 그 정책을 코드에 반영한다"는 순서를 먼저 한다. RELEASE_PLAN.md 같은 파일은 단순 기록이 아니라 실행 계획이다.

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

• 사무의자 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

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