Capgo 환경 베스트 프랙티스: 하나의 Mobile App ID로 스테이징하기

팀들은 보통 모바일 환경을 위해 세 가지 방식 중 하나를 선택합니다:

앱 ID 두 개 (프로덕션 + 사전 프로덕션)
앱 ID 하나 + 런타임 환경 동적 전환
앱 ID 하나 + Capgo 채널

앞의 두 방식도 가능하지만 장기적으로는 마찰이 생깁니다. 실제 팀에서는 보통 Capgo 채널 모델이 가장 깔끔합니다.

앱 ID 중복이 문제를 일으키는 이유

사용하기 com.myapp 및 com.myapp.beta 단순해 보이지만 금방 중복이 생깁니다:

두 개의 릴리스 파이프라인
push ID, 딥링크, 권한 매핑까지 두 세트
분석과 크래시 식별자도 두 개
환경마다 다른 설정과 일관성 없는 동작

결국 스토어 콘솔, 팀, 내부 QA 가이드까지 두 개의 제품을 관리해야 합니다.

런타임 스위칭 설정이 자주 복잡해지는 이유

“하나의 앱 ID + 런타임 스위칭” 패턴은 보통 앱 시작 시 환경 변수나 플래그를 읽어 API, 키, 업데이트 동작을 동적으로 재라우팅하는 방식을 의미합니다.

이 방식은 다음 상황이 오면 한계에 부딪힙니다:

설정 상태가 오래되어 QA가 의도된 플로우를 우회하기 시작할 때,
누군가가 프로덕션에서 잘못된 엔드포인트를 사용할 때,
환경 차이(drift)로 재현이 어려운 버그가 발생할 때,
사용자 기기에서 "이 바이너리가 어떤 버전의 설정을 쓰고 있는가?"를 디버깅해야 할 때.

이러한 복잡성은 릴리스마다 커지며, 팀의 속도를 떨어뜨리는 원인이 됩니다.

Capgo 방식: 앱 ID는 하나, 채널은 여러 개

Capgo는 채널을 통해 환경 제어를 명확하게 합니다:

App Store / Play에 프로덕션 앱 ID를 하나만 유지하세요.
네이티브 변경이 필요한 경우를 제외하고는 '셸'용 네이티브 바이너리를 하나만 배포하세요.
앱 식별자를 복제하는 대신 채널로 동작을 라우팅하세요.

실제로 이는 다음과 같은 것을 의미합니다:

production: 모든 사용자
staging: 내부 QA 및 릴리스 후보
beta: 초대된 테스터
hotfix: 긴급 패치 트랙

TestFlight/Play 내부 테스트 앱은 계속 staging 유지할 수 있습니다. 새로운 네이티브 앱을 게시하지 않고 Capgo를 통해 JS/CSS/에셋 업데이트를 반복적으로 수행할 수 있습니다.

실무에서 권장되는 구조

1) 네이티브 릴리스 베이스라인

마지막 네이티브 바이너리는 여러 번의 JS 반복에서도 동일하게 유지됩니다:

bun run build
bunx cap sync
# generate Xcode/Android Studio archives as usual

실제로 네이티브 표면 영역이 변경된 경우에만 네이티브 바이너리를 다시 빌드합니다.

2) 환경을 위한 전용 채널 사용

채널을 사용하여 업데이트를 게시합니다:

bun run build
bunx @capgo/cli deploy --channel staging

QA에서 테스트하고 문제를 수정한 후 승격합니다:

bunx @capgo/cli promote vX.Y.Z --channel production

명시적인 버전 관리를 선호한다면:

bunx @capgo/cli deploy vX.Y.Z --channel staging
bunx @capgo/cli promote vX.Y.Z --channel production

3) TestFlight를 “항상 사전 프로덕션”으로 유지

iOS 워크플로우에서 이는 TestFlight 빌드가 사전 프로덕션 업데이트와 연관된 상태로 유지될 수 있음을 의미합니다:

각 JS 변경 사항마다 빈번한 네이티브 제출이 필요하지 않습니다.
QA는 항상 스테이징 채널을 통해 프로덕션에 가까운 code를 검증합니다.
프로덕션 사용자는 승격된 프로덕션 채널 번들만 수신합니다.

4) 채널 전환은 제어된 워크플로우에만 사용

고급 팀을 위해 QA/관리자 사용자에게 제어된 채널 전환을 노출하세요:

import { CapacitorUpdater } from '@capgo/capacitor-updater';

await CapacitorUpdater.setChannel({
  channel: 'staging',
  triggerAutoUpdate: true
});

선택 사항입니다. 대부분의 팀은 대시보드에서 채널을 할당하고, 모든 고객이 아닌 내부 사용자만 채널을 전환합니다.

운영 체크리스트

앱 ID 1개만 사용 (중복된 production/staging ID 금지)
베이스라인 네이티브 빌드 파이프라인 1개
채널 매핑 문서화 (staging, beta, production, hotfix)
CI/CD에서 프로모션 경로 강제 적용
실제 네이티브 변경 시에만 네이티브 리빌드
롤백을 정기적으로 테스트

실용적 이점

이 접근 방식은 환경 드리프트를 제거하고, 빌드 변경을 줄이며, 수정 속도를 높입니다:

QA가 현실적인 바이너리를 확보합니다 (가짜 'staging app' 식별자 없음),
TestFlight 배포 경로가 안정적으로 유지됩니다,
팀이 '이중 앱 ID 부채'를 피할 수 있습니다,
JS 전용 수정 사항을 Capgo를 통해 빠르게 배포할 수 있습니다.

최종 결과는 더 단순한 거버넌스입니다: 아티팩트 감소, 더 깔끔한 텔레메트리, 그리고 릴리스 운영에서의 예상치 못한 문제 감소.

Capgo 환경 베스트 프랙티스: 하나의 Mobile App ID로 Staging 환경 구성하기부터 계속하기

사용 중이라면 Capgo 환경 베스트 프랙티스: 하나의 Mobile App ID로 스테이징하기 채널 라우팅과 단계적 배포를 계획하려면, 다음을 연결하세요: 채널 Channels의 구현 세부 사항은 다음을 참고하세요: 채널 Channels의 구현 세부 사항은 다음을 참고하세요: 채널 Channels의 구현 세부 사항은 다음을 참고하세요: Beta Testing 솔루션 Beta Testing 솔루션의 제품 워크플로우를 위한, 그리고 버전 타겟팅 솔루션 Version Targeting Solution의 제품 워크플로우용.