hsb.horse
모바일 앱의 도메인 변경이 발생했을 때, 구 버전을 계속 사용하는 사용자에게 어떻게 대응하고 있을까?
나는 그동안 웹 프론트엔드와 백엔드, 현재는 AWS 중심의 인프라 엔지니어로 일해왔다. 웹 개발의 자유도가 높다는 것을 알기에 모바일 앱의 심사나 릴리스 사이클 제약이 신경 쓰인다. 또한 인프라 관점에서 볼 때, 오래된 도메인을 계속 유지하는 비용과 리스크도 신경 쓰인다.
이 글에서는 여러 레이어에서 본 모바일 앱의 과제를 정리하고, 시작 시 메타데이터를 가져오는 접근법을 제안한다. 벤더 의존을 피하면서 운영 부담을 줄이는 구성이다.
각 레이어에서 본 모바일 앱의 과제
인프라 엔지니어 관점
인프라와 앱의 직접적인 접점은 FQDN이다. 서비스가 오래 지속되면 이 도메인 관리가 부채가 될 수 있다.
BFF 리아키텍처 등으로 새 도메인을 발행하면, 구 도메인을 유지하면서 새 도메인으로 리다이렉트할 필요가 생긴다. DNS 레코드를 계속 유지하고 불필요한 호스트가 계속 가동된다. 엔드포인트는 언제든 장애 지점이 될 수 있다. 지울 수 있다면 지우고 싶지만, 구 앱 버전의 사용자가 있는 한 지울 수 없다.
웹 프론트엔드 엔지니어 관점
웹 프론트엔드의 강점은 배포의 자유도이다. 심사도 설치도 없다. 캐시를 무시하고 새로고침하면 최신 버전이 도착한다. 작은 수정이라면 하루에 여러 번 릴리스할 수 있다.
모바일 앱은 심사가 있어서 이런 자유도를 얻을 수 없다. 릴리스하고 싶을 때 릴리스할 수 있다는 느낌이 모바일 개발에서는 통용되지 않는다.
백엔드 엔지니어 관점
BFF 측의 과제는 API 호환성 유지이다. 버저닝을 어떻게 설계하든 오래된 구현을 계속 유지해야 한다. 이것도 지우고 싶지만 지울 수 없는 코드가 쌓이는 구조다.
제안하는 구성: 시작 시 메타데이터 가져오기
다음 구성을 고려하고 있다.
meta.example.com이라는 도메인을 준비하고 CloudFront와 S3로 배포한다. 경로에 번들 ID를 사용하고 그 하위에 metadata.json을 배치한다.
meta.example.com/├── com.example.app-a/│ ├── metadata.json│ └── metadata.sha256├── com.example.app-b/│ ├── metadata.json│ └── metadata.sha256└── com.example.app-c/ ├── metadata.json └── metadata.sha256앱 시작 시 이 JSON을 가져와서 백엔드와 정적 자산의 엔드포인트를 동적으로 설정한다. 가져온 메타데이터는 로컬에 캐시하고 적절한 재검증 간격을 설정한다.
metadata.json 스키마 예시:
{ "$schema": "https://meta.example.com/schemas/metadata/v1.json", "bundle_id": "com.example.app-a", "sha256": "xxxxxxxx", "revalidate_interval": 604800, "backend": { "host": "https://api.example.com", "ping": "/health", "retry": { "max_retries": 5, "backoff_factor": 2 } }, "static_assets": { "host": "https://cdn.example.com" }, "maintenance_mode": { "enabled": false, "begin": "2026-02-14T00:00:00Z", "end": "2026-02-14T03:00:00Z", "message": "점검 중입니다" }}이 방식의 이점은 백엔드 도메인 변경이나 점검 알림을 인프라 측에서만 완료할 수 있다는 점이다. 앱 측은 시작 시 메타데이터를 가져오기만 하면 하드코딩된 엔드포인트에 묶이지 않게 된다.
CloudFront의 캐시 TTL을 1일에서 1주일 정도로 설정하면, 빈번한 업데이트가 없을 것으로 가정하고 비용도 최소화할 수 있다. 캐시 버스팅 메커니즘도 고려해 둘 필요가 있다.
기존 솔루션과의 비교
Firebase Remote Config
Firebase Remote Config는 현재 무료로 제공되고 있다. 기능적으로는 충분하다. 다만 다음과 같은 우려가 있다.
첫째는 향후 유료화 리스크이다. Google 서비스는 과거에 무료에서 유료로 전환된 사례가 있다. 예산 계획에 영향을 줄 수 있다.
다음은 관리 비용이다. 앱마다 Firebase 프로젝트를 생성해야 한다. 관리하는 앱이 많아질수록 프로젝트 수와 권한 관리의 복잡성이 증가한다. 대기업에서 여러 앱을 운영하는 경우 이 관리 공수는 무시할 수 없다.
자체 구현의 트레이드오프
CloudFront+S3 자체 구현은 초기 구축 비용이 든다. 그러나 장기적인 벤더 록인 리스크를 피하고 여러 앱의 설정을 일원 관리할 수 있다. 스키마의 진화도 우리가 직접 제어할 수 있다.
S3라면 최악의 경우 JSON 파일을 만들어 GUI 콘솔에서 드래그 앤 드롭으로 파일을 업로드하기만 하면 업데이트 메커니즘이 생긴다. 최초 단계에서는 이것이 가장 편리하다고 생각한다. 다만 나중에 롤백 전략 등을 검토할 때 업데이트 방법을 제한하여 적절히 수행할 필요가 있다고 생각한다.
고려사항과 스코프 외
고려사항
후방 호환성 스키마는 v1에서 v2로 진화한다. 구 앱이 새 스키마를 읽지 못하는 문제는 스키마 설계에서 후방 호환성을 유지함으로써 대응한다.
보안 JSON 변조 리스크는 사내 보안 관리에 달려 있다. 최소 권한의 원칙으로 S3 버킷을 관리하고, CloudFront의 서명된 URL 등도 검토한다.
스코프 외 항목
롤백 전략 JSON 업데이트 실수가 모든 사용자에게 즉시 반영될 리스크가 있다. 롤백 전략은 별도로 검토가 필요하다.
클라이언트의 네트워크 에러 핸들링 최초 시작 시 JSON 취득 실패나 오프라인 시 동작은 앱 측의 책임이다. 앱 측에서 최적의 핸들링을 수행해야 한다.
오프라인 우선 앱 이 방식은 시작 시 네트워크 액세스를 전제로 한다. 오프라인이 기본이 되는 앱에는 적합하지 않다.
실제 운용 시나리오
이 방식이 효과적인 것은 다음과 같은 케이스다.
도메인 변경이 발생했을 때. 구 도메인을 계속 유지할 필요가 없어져, JSON을 업데이트하는 것만으로 새 엔드포인트로 유도할 수 있다.
점검 알림이 필요할 때. metadata.json의 maintenance_mode를 유효로 하는 것만으로 앱 측이 점검 화면을 표시해 준다. 정지를 동반하는 작업 전에 사용자에게의 전달이 확실히 이루어질 수 있다.
여러 앱의 설정을 일원 관리하고 싶을 때. 도메인은 1개에 집약하면서 앱마다 경로를 잘라 메타데이터를 배치한다. 관리 포인트를 줄일 수 있다.
소감과 질문
이 접근법은 근본적으로 뒷 레이어에서 본 운용 효율의 이야기다. 모바일 앱 개발의 현장 경험이 풍부한 엔지니어에게는 부족한 시점이나 더 좋은 방법이 있을지도 모른다.
여러분의 현장에서는 도메인 변경이나 점검 알림을 어떻게 해결하고 있을까. Firebase Remote Config 등의 기존 서비스를 사용하고 있나, 아니면 자체 구현을 하고 있나. 만약 이 방식에 대한 우려나 개선안이 있다면 꼭 알고 싶다.