빠른 흐름
text
Addressables group
-> local build path / remote build path
-> local load path / remote load path
-> profile로 환경별 값 전환기본 흐름
- Addressables를 진짜로 도입하는 이유는 단순 비동기 로드보다 배포 전략에 있는 경우가 많습니다. 로컬에 포함할 콘텐츠와 원격으로 내려받을 콘텐츠를 나누고, 환경별 주소를 관리하며, 패치 가능한 콘텐츠 경계를 만드는 것이 핵심입니다.
Group은 어떤 자산을 함께 빌드하고 어떤 방식으로 배포할지 정하는 단위입니다. 자산을 단순 분류하는 폴더가 아니라, 수명주기와 배포 방식을 공유하는 콘텐츠 묶음으로 보는 편이 맞습니다.Profile은 개발, 스테이징, 운영처럼 환경별 build/load path를 전환하는 설정 계층입니다. 그래서 Addressables는 코드보다 배포 설정이 더 중요한 시스템이 될 때가 많습니다.- 원격 콘텐츠 구조를 쓰면 앱 본체를 다시 배포하지 않고도 자산 묶음을 갱신할 수 있지만, 그만큼 카탈로그 버전, 캐시, 다운로드 실패, CDN 경로 같은 운영 이슈를 함께 생각해야 합니다.
- 즉 Addressables 원격 운영은 "자산을 로드한다"보다 "콘텐츠를 서비스한다"에 가깝습니다. 작은 프로젝트에서는 과할 수 있지만, 라이브 운영이나 대형 프로젝트에서는 큰 차이를 만듭니다.
체크포인트
| 상황 | 적합한 선택 |
|---|---|
| 어떤 자산을 함께 배포할지 결정 | Group으로 배포 단위 정의 |
| 개발/스테이징/운영 경로 전환 | Profile 전환으로 build/load path 관리 |
| 앱 재배포 없이 자산 갱신 | Remote Content group으로 원격 배포 |
| 소규모 프로젝트, 라이브 운영 없음 | 원격 구조 없이 로컬 Addressables로 충분 |
| 비교 | 더 잘 맞는 쪽 | 이유 |
|---|---|---|
| 로컬 포함 자산 vs 원격 배포 자산 | local group / remote group | 배포 주기와 패치 빈도가 다름 |
| 환경별 경로 하드코딩 vs Profile 관리 | Profile | dev/staging/prod 전환 실수를 줄이기 쉬움 |
| 로딩 기능 관점 vs 서비스 운영 관점 | 운영 관점 | 카탈로그, CDN, 캐시, 복구까지 같이 봐야 함 |
주의할 점
Addressables 원격 구조는 로딩 기능이 아니라 운영 체계입니다. 경로, 캐시, 카탈로그 버전, 다운로드 실패 복구를 함께 설계하지 않으면 오히려 문제가 커집니다.
text
// ❌ 원격 Group만 만들고 운영 설계 없음
→ 카탈로그 버전 불일치로 로드 실패
→ 캐시 오염 시 복구 방법 없음
→ 개발/운영 CDN 경로 혼용
// ✅ 원격 구조 도입 전 설계 체크리스트
- Profile: 개발/스테이징/운영 build·load path 분리
- 카탈로그 업데이트 정책: 앱 실행 시 갱신 여부
- 다운로드 실패 처리: 재시도, 로컬 fallback
- CDN 캐시 무효화 전략
// ❌ dev profile로 빌드한 catalog를 운영 CDN에 그대로 업로드
// → load path 불일치로 운영 빌드에서 자산 로드 실패참고 링크
3 sources