워치페이스 여러 변형, SDK 버전 동시 통일

최근에 Wear OS 워치페이스 프로젝트의 5개 워치페이스(crimson, graphite, ivory, noir, slate)를 동시에 새 SDK 버전으로 업그레이드하고, 클로즈드 테스트 전에 릴리스 체크리스트를 정리하는 작업을 했다. 이번 글에선 여러 워치페이스 변형을 관리할 때 마주하는 문제와 그걸 어떻게 풀어냈는지 회고해본다.

Wear OS 워치페이스의 "다변종 지옥"

워치페이스는 디자인 테마별로 여러 개의 변형을 배포한다. 같은 로직으로 동작하지만 리소스(색상, 이미지, 폰트)만 다른 형태인데, 프로젝트 구조상으로는 각각 독립적인 모듈로 관리되는 경우가 많다. 우리 프로젝트도 마찬가지라서 faces/crimson, faces/graphite 같은 식으로 5개 디렉토리가 있었다.

문제는 뭔가. 이 5개 모듈이 각각 build.gradle.kts를 가지고 있으면서, gradle 버전, targetSdk, version code 같은 빌드 설정이 서로 다르게 떨어져 있다는 거다. 한두 개 워치페이스면 모르겠지만, 5개가 되면 한 번에 관리하기 힘들어진다.

• crimson 은 targetSdk 33인데, graphite는 34?
• ivory 의 version code는 1인데, noir는 2?
• slate 는 누가 마지막으로 업데이트했고, 지금 어떤 상태인가?

이런 질문들이 생긴다. 클로즈드 테스트를 시작하려면 이 불일치들을 모두 정렬해야 한다. 왜냐면 Wear OS 앱스토어 배포 시스템이 같은 앱 (다만 여러 변형)의 경우 version code 순서가 엄격하기 때문이다.

일괄 업그레이드: appId 확인과 SDK 맞추기

이번 작업의 핵심은 두 가지였다:

1. console-7 appIds 확인
각 워치페이스가 플랫폼(Play Console)에 제대로 등록되어 있고, appId 가 일관되게 설정되었는지 재확인했다. 누군가 실수로 다른 appId를 사용한다면, 배포 후 별개의 앱으로 인식되어 버린다.

2. targetSdk 와 version code 일괄 정렬
- crimson, graphite, ivory, noir, slate → 모두 targetSdk 34로 통일
- version code → 모두 vc2로 통일
- RELEASE_PLAN.md에 이 현황을 기록

각 워치페이스의 build.gradle.kts 파일을 수정했다. 패턴은 이런 식이다:

// Before: 각자 다른 설정
android {
    compileSdk = 33  // 또는 34
    defaultConfig {
        targetSdk = 33  // 또는 34
        versionCode = 1  // 또는 2
    }
}

// After: 모두 동일
android {
    compileSdk = 34
    defaultConfig {
        targetSdk = 34
        versionCode = 2
    }
}

왜 이 작업이 중요했나

표면적으로 보면 "gradle 설정값 몇 개 바꾼 거" 같지만, 실제로는 여러 의미가 있다:

특히 클로즈드 테스트 단계인 지금이 이런 작업을 하는 적절한 시점이다. 정식 배포 직전에 이 불일치들을 방치했다간, 한두 개 변형이 배포 실패하는 난감한 상황이 발생할 수 있다.

배운 점: 다변종 관리의 원칙

이런 작업을 하면서 느낀 건, 여러 변형을 가진 프로젝트는 처음부터 "버전 관리 규칙"을 명확히 해야 한다는 거다.

우리 경우, 지금까지는 각 워치페이스가 자신의 build.gradle.kts를 독립적으로 관리해왔다. 그게 유연하긴 하지만, 배포 시점에 가면 이렇게 정렬 작업을 해야 한다. 다음엔 좀 더 자동화된 방법을 고려할 수도 있다:

• 공통 gradle 파일로 선언: buildSrc 나 root build.gradle.kts에서 targetSdk, versionCode 같은 값을 정의하고, 각 모듈이 그걸 참조하게 한다.
• 릴리스 체크리스트 자동화: gradle task로 모든 워치페이스의 설정을 한 번에 검사하고 불일치를 리포트하는 script를 만든다.
• RELEASE_PLAN.md 자동 생성: 빌드 시점의 모든 워치페이스 메타데이터를 수집해서 문서에 기록한다.

이번 commit은 그 첫 단계. 수동으로라도 체크리스트를 맞추고, 문서에 남기는 것만으로도 다음 릴리스 때는 한결 수월해진다.

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

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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