프로 테마, 독립된 서명으로 배포 관리 정리하다

프로 버전의 여러 테마(Crimson, Graphite, Ivory, Noir, Slate)들을 각각 독립적인 keystore로 서명하도록 전환했다. 각 테마 build.gradle.kts를 수정하고, 배포 계획 문서를 함께 업데이트했다.

멀티 테마 구조, 배포 관리가 복잡해지는 이유

처음엔 모든 테마가 하나의 공유 keystore를 써서 배포됐을 거다. 간단해 보이지만, 프로 버전의 테마가 늘어날수록 문제가 생긴다. 예를 들어:

• 한 테마의 keystore가 만료되거나 손상되면 전체 테마 배포가 영향을 받는다
• 각 테마별로 다른 보안 정책(예: 만료 기간, 인증서 강도)을 적용하기 어렵다
• 테마별 독립적인 배포 추적이 모호해진다
• CI/CD 파이프라인에서 각 테마를 구분해서 처리하기 복잡해진다

이걸 체감한 순간이 "아, 이제 배포 워크플로우를 정리해야 할 때"라는 신호다. 테마가 5개, 10개로 늘어날 때마다 같은 실수를 반복하는 건 팀 규모가 커질수록 소음이 된다.

변경 전략: 각 테마의 build.gradle.kts 독립화

각 build.gradle.kts에서 keystore 경로/별칭을 테마별로 다르게 지정하면:

// before: 공유 keystore
signingConfigs {
    release {
        keyStore file("../shared.keystore")
        // ...
    }
}

// after: 테마별 독립 keystore
signingConfigs {
    release {
        keyStore file("../keystores/crimson.keystore")  // Crimson 만의 keystore
        // ...
    }
}

이렇게 분리하면 CI/CD에서 각 테마를 독립적으로 빌드·배포할 때 어떤 keystore를 써야 하는지가 명확해진다.

배포 추적과 보안의 균형

PAID_RELEASE_PLAN.md 업데이트는 단순한 문서 정리가 아니다. 이건 팀 전체가 "지금 Crimson은 어디까지 진행됐나", "어떤 keystore로 서명되는가"를 한눈에 알 수 있게 하는 일이다. 특히 여러 개발자가 동시에 여러 테마를 배포할 때는 이 문서가 배포 사고를 방지하는 체크리스트 역할을 한다.

프로 버전 배포는 보안이 중요하다. keystore가 유출되거나 손상되면 앱 서명이 깨진다. 독립 keystore로 분리하면:

• 각 테마의 keystore를 별도로 보호할 수 있다
• 한 테마의 문제가 다른 테마로 전파되지 않는다
• 감사(audit) 로그를 테마별로 추적하기 쉬워진다

멀티 테마 아키텍처에서 배운 점

이런 작업을 하면서 느낀 건, 테마/스킨 같은 변형 구조는 초기에 작을 땐 중앙화(centralized)가 편하지만, 그 수가 증가하면 빠르게 분산화(decentralized) 전략으로 옮겨야 한다는 거다. 특히 빌드, 배포, 서명 같은 운영 영역은 더욱 그렇다.

5개 테마는 아직 관리 가능한 숫자지만, 이 변경은 10개, 20개로 늘어날 때를 미리 대비하는 거다. 팀 리딩 입장에서는 이런 "작은 정리"가 나중의 "큰 재구성"을 막는 예방 투자라고 본다.

앞으로 새로운 프로 테마가 추가될 때마다, 이 구조를 그대로 따라가면 배포 일관성을 유지할 수 있다.

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

• 기계식키보드 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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