개발 slecs

유료 버전을 별도로 배포하기 위해 applicationId 분리

목차

Play Store에서 같은 앱의 유료/무료 버전을 독립적으로 배포하려고 Android 앱의 applicationId를 변경했다. 한 줄짜리 설정 변경처럼 보이지만, 사실 아키텍처, 배포, 테스트 전체가 얽혀 있던 결정이었다.

왜 applicationId를 달리해야 했는가

처음엔 같은 applicationId로 내부적으로 버전을 구분하는 게 낫지 않을까 고민했다. 핵심 코드도 공유되니까, 패키징만 다르면 되지 않을까 하는 식으로. 하지만 모바일 OS 수준에서 applicationId는 앱의 절대적 신원이다. 같은 ID면 같은 앱이고, 한 기기에 동시 설치는 물리적으로 불가능하다.

그렇다면 사용자 경험은 어떻게 될까? 무료 버전으로 써보다가 유료로 업그레이드하려면, 앱을 완전히 제거했다가 새로 깔아야 한다. 설정, 저장 데이터, 캐시가 모두 초기화된다는 뜻이다. 이건 명백히 좋지 않은 경험이었다. 프로덕트팀과 이야기하다 보니 "사용자가 한 기기에 둘 다 설치할 수 있어야 한다"는 요구사항이 나왔고, 결국 applicationId를 분리하는 게 피할 수 없는 결론이었다.

build.gradle.kts에서의 실제 변경

Android 프로젝트에서는 보통 두 가지 접근이 있다.

1) productFlavor를 이용 (권장)

android {
  productFlavors {
    create("free") {
      applicationId = "com.example.app"
      dimension = "version"
    }
    create("pro") {
      applicationId = "com.example.app.pro"
      dimension = "version"
    }
  }
}

2) 직접 applicationId 설정

android {
  applicationId = "com.example.app.pro"
}

우리는 flavor 방식을 택했다. 이유는 CI/CD가 깔끔해지고, 빌드 커맨드 하나로 두 버전을 자동 생성할 수 있기 때문이다. gradle assembleProRelease 하면 유료 버전만, gradle assembleFreeRelease 하면 무료 버전만 나온다. 배포 파이프라인도 이를 활용해서 체계적으로 관리할 수 있다.

이 변경이 미친 연쇄 효과

처음엔 applicationId 하나만 바꾸면 되는 줄 알았는데, 실제로는 여러 부분이 연결되어 있었다.

영역 같은 applicationId 다른 applicationId
동시 설치 불가능 (하나만 설치 가능) 가능 (한 기기에 둘 다)
데이터 공유 SharedPreferences, DB 공유 쉬움 OS 수준에서 격리됨
배포 구조 한 APK 관리 두 APK 병렬 관리
버전 관리 versionCode 같음 versionCode 다름 권장
테스트 복잡도 한 버전만 테스트 각 버전별 독립 검증

신경 써야 할 부분이 몇 개 있었다:

데이터 격리와 공유
다른 applicationId를 쓰면 OS 수준에서 데이터가 격리된다. 이건 보안상 좋지만, 유료/무료가 user profile 같은 공통 데이터를 필요로 하면 명시적으로 처리해야 한다.

Intent와 Deep Link
유료 앱에서 무료 앱을 호출해야 하거나 그 반대 경우, AndroidManifest의 intent filter가 꼬지기 쉽다. scheme이나 host를 다시 설정해야 한다.

CI/CD 파이프라인 복잡도
이제 배포가 두 배로 복잡해진다. 테스트도 두 flavor 각각 돌려야 하고, release 빌드도 두 개 생성해서 Play Store에 올려야 한다. 스크립트를 짤 때 실수하면 잘못된 버전을 배포할 수 있다.

팀 온보딩
팀원들이 "flavor를 선택해서 빌드하세요"라는 프로세스를 이해하지 못하면, 자꾸 잘못된 버전을 빌드한다. 문서화가 중요했다.

회고: 기술 결정의 범위

사실 이 작업을 하면서 깨달은 게 있다. 단순한 설정 변경처럼 보였지만, 영향 범위가 생각보다 훨씬 크다는 거였다. applicationId 하나를 바꿨는데, 그 효과가 아키텍처, 배포 프로세스, 테스트 전략, 팀의 빌드 절차까지 미친다. 이런 "아키텍처 결정"을 할 때는 기술 리더가 단순히 "기술적으로 가능한가"에서 끝나지 말고, "팀이 이걸 유지보수할 수 있을까", "배포 과정이 얼마나 복잡해질까", "나중에 변경하려면 비용이 얼마나 들까"까지 고민해야 한다는 생각이 들었다. 한 줄의 코드/설정이 얼마나 큰 파급력을 가질 수 있는지를 다시 한번 일깨워준 작업이었다.


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

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

댓글 0

첫 댓글 달아줘.