여러 브랜드 앱을 한 코드베이스에서 운영할 때 명시적 프로필 설정과 CI 검증을 함께 설계하는 방법을 설명합니다. 운영 단계에서 판단의 출발점은 ‘명시적인 빌드 범위’입니다. 이번 산출물에 포함될 제품을 설정으로 고정하면 의도치 않은 브랜드 리소스와 기능이 섞이는 일을 줄일 수 있습니다.
이 글의 범위
실제 경험이나 측정 결과를 가정하지 않고, 공식 문서로 확인 가능한 개념과 적용 순서를 일반 가이드로 설명합니다. 제품 버전과 서비스 정책은 바뀔 수 있으므로 적용 전 연결된 공식 문서를 다시 확인하세요.
 |
| selectedProfiles로 빌드 대상을 제어할 때의 장단점 핵심 판단 흐름 설명용 개념도 |
그림 1. selectedProfiles로 빌드 대상을 제어할 때의 장단점의 핵심 판단 순서를 정리한 설명용 개념도입니다. 실제 서비스 화면, 운영 로그 또는 측정 결과가 아닙니다.
selectedProfiles 방식의 이점과 비용
명시적인 빌드 범위
이번 산출물에 포함될 제품을 설정으로 고정하면 의도치 않은 브랜드 리소스와 기능이 섞이는 일을 줄일 수 있습니다.
번들 최적화 가능성
빌드 단계에서 제외가 실제 번들 제외로 이어지는지는 도구 체인에 따라 다릅니다. 런타임에서 메뉴만 숨긴 것을 번들 제거로 착각하지 않습니다.
설정 조합 증가
프로필 수가 늘수록 가능한 조합과 테스트 범위가 커집니다. 지원하는 조합을 제한하고 이름 있는 빌드 프리셋으로 관리하는 편이 안전합니다.
네이티브 설정 동기화
패키지명, 딥링크, 아이콘, Firebase 설정처럼 JavaScript 밖의 값도 선택된 프로필과 일치해야 합니다.
재현 가능한 산출물
커밋, 프리셋, 환경, 의존성 잠금 파일을 함께 기록해야 같은 앱을 다시 만들 수 있습니다.
도구보다 먼저 볼 기준
selectedProfiles는 빌드 의도를 명시하는 좋은 출발점이지만 그 자체가 완전한 제품 분리 기능은 아닙니다. ‘명시적인 빌드 범위’에서 시작해 ‘번들 최적화 가능성’와의 경계를 정하면 구현할 범위와 실패했을 때 확인할 지점을 구분하기 쉬워집니다.
CI에 연결하는 점검 순서
- 지원할 프로필 조합을 프리셋 이름으로 정의합니다.
- 각 프리셋에 필요한 리소스와 네이티브 설정 목록을 만듭니다.
- 빌드 전 스키마 검증으로 누락·중복 프로필을 차단합니다.
- 생성된 앱의 패키지명, 링크 스킴, 버전, 포함 기능을 자동 검사합니다.
- 산출물 메타데이터에 프리셋과 커밋을 기록합니다.
변경 전 체크 포인트
| 확인 항목 | 질문 |
|---|---|
| 첫 기준: 명시적인 빌드 범위 | 변경 전에 전제와 목적을 확인했는가? |
| 분리 대상: 번들 최적화 가능성 | 다른 책임과 섞이지 않게 경계를 정했는가? |
| 피할 패턴: 존재하지 않는 프로필 이름을 조용히 무시하기 | 본문에서 경고한 패턴이 남아 있지 않은가? |
| 오류와 복구 | 정상 경로뿐 아니라 실패와 되돌리기도 확인했는가? |
설정 파일 하나에 기대면 생기는 문제
- 존재하지 않는 프로필 이름을 조용히 무시하기
- 런타임 숨김을 코드·리소스 제거로 오해하기
- 로컬 설정과 CI 환경 변수가 서로 다른 우선순위를 갖기
- 모든 조합을 지원한다고 선언하고 실제 테스트는 한 조합만 하기
결론
selectedProfiles는 빌드 의도를 명시하는 좋은 출발점이지만 그 자체가 완전한 제품 분리 기능은 아닙니다. 지원 프리셋, 스키마 검증, 네이티브 설정 검사와 산출물 기록이 함께 있어야 운영 가능한 방식이 됩니다.
댓글 없음:
댓글 쓰기