새 앱이거나 이전에 ODR을 사용한 적 없는 앱이라면, 업로드 제한이 시작되기 전에 업로드 산출물에서 ODR을 제거하고 Background Assets 이전을 검토해야 합니다. 이미 ODR을 사용 중인 앱은 당장 작동을 멈추는 대상이 아니므로, 현재 리소스 구조를 확인한 뒤 단계적으로 이전을 계획합니다.
이 글은 앱이나 게임에 On-Demand Resources를 넣어 배포하는 iOS 개발자, 리소스 다운로드 구조를 맡은 엔지니어, Xcode 기반 빌드와 배포를 관리하는 CI 담당자를 위한 점검 절차입니다.
마지막 업데이트: 2026년 11월 12일. 적용 대상과 날짜는 Apple의 App Store Connect 업로드 안내를 기준으로 확인했습니다.
업로드 제한과 운영 중인 앱의 영향
Apple은 2027년 초부터 새 앱과 이전에 ODR을 사용하지 않은 앱이 ODR 콘텐츠를 포함해 올리는 업로드를 받지 않겠다고 안내했습니다. 정확한 시행일은 발표되지 않았으므로, 날짜를 임의로 정해 배포 계획에 넣지 마세요. 프로젝트의 출시 일정과 업로드 자격을 따로 확인해야 합니다. 해당 안내를 출시 전에 다시 확인해 변경 여부도 살펴보세요.
이 변경은 세 가지를 구분해서 읽어야 합니다. ODR 사용이 새 운영체제에서 폐기된다는 안내, 특정 앱의 ODR 포함 업로드 제한, 이미 ODR을 쓰는 앱의 동작은 같은 뜻이 아닙니다. Apple은 ODR을 iOS 27, iPadOS 27, tvOS 27, visionOS 27부터 폐기한다고 밝혔지만, 이미 사용 중인 앱이 곧바로 중단된다고 밝힌 것은 아닙니다. App Store Connect의 ODR 안내를 기준으로 구분하세요.
따라서 “Xcode에서 빌드된다”는 사실만으로 업로드 가능 여부를 판단하면 안 됩니다. 빌드는 성공해도 앱의 업로드 대상과 과거 사용 이력에 따라 제한에 걸릴 수 있습니다. 반대로 기존 ODR 앱이라는 이유만으로 즉시 배포 중단이나 강제 이주를 전제로 삼을 필요도 없습니다.
ODR을 App Store Connect에 언제까지 올릴 수 있나요?
새 앱 또는 과거에 ODR을 사용하지 않은 앱은 2027년 초부터 ODR 콘텐츠를 포함한 업로드가 제한됩니다. Apple은 구체적인 시작 날짜를 공개하지 않았으므로, 배포 계획은 “연초의 특정 날짜”에 맞추지 말고 해당 안내의 최신 상태를 기준으로 갱신하세요. 업로드 전에 적용 대상과 제한 안내를 다시 확인하는 편이 안전합니다.
프로젝트가 제한 대상인지 판별하기
먼저 현재 소스 코드만 보지 말고, 업로드할 산출물과 앱의 배포 이력을 함께 살펴야 합니다. 아래 항목을 체크리스트로 기록하면 팀 간 판단 차이를 줄일 수 있습니다.
- [ ] 프로젝트 설정에서 On-Demand Resources 기능이 켜져 있는지 확인합니다.
- [ ] 실제 보관 및 배포용 산출물에 ODR 리소스 태그나 관련 리소스 팩이 들어 있는지 확인합니다.
- [ ] 이전에 배포한 앱 버전이 ODR을 사용했는지, 관련 배포 기록과 설정을 확인합니다.
- [ ] 새 앱인지, 과거에 ODR을 사용한 적 없는 앱인지 구분해 업로드 제한 적용 여부를 기록합니다.
- [ ] 앱 코드에서
NSBundleResourceRequest호출을 찾아 기능별 호출 위치와 실패 처리를 목록화합니다.
마지막 항목은 단순 검색으로 끝내지 마세요. NSBundleResourceRequest 공식 문서에서 확인할 수 있듯, 이 API는 앱이 ODR 리소스를 요청하고 사용하는 흐름과 연결됩니다. 호출이 화면 표시, 게임 레벨 잠금 해제, 다운로드 완료 판단에 엮여 있는지 따라가야 이주 범위를 정할 수 있습니다.
Background Assets 이전은 리소스 구조를 다시 설계하는 작업
Background Assets가 NSBundleResourceRequest를 바로 대체하나요?
그렇지 않습니다. 기존 ODR 태그를 Background Assets의 asset pack에 그대로 대응시키는 자동 변환으로 보면 안 됩니다. 앱에서 리소스가 필요한 시점, 다운로드를 시작할 조건, 로컬에서 사용 가능하다고 판단하는 방법을 다시 설계해야 합니다.
먼저 태그별 리소스 목록을 기능 단위로 나눕니다. 앱 실행 직후 필요한 파일인지, 특정 콘텐츠를 열 때 필요한지, 사용 후 정리할 수 있는지 구분하세요. 이어서 다운로드 실패나 지연이 생겼을 때 사용자가 볼 상태와 재시도 경로를 정합니다. 기존 ODR의 다운로드 완료 신호를 새 구조에서도 같은 의미로 취급하면, 파일이 아직 준비되지 않은 상태에서 화면이나 레벨이 열릴 수 있습니다.
Managed Background Assets는 Apple이 호스팅하는 방식을 선택할 수 있습니다. 이 경우 관리형 asset pack 만들기 문서와 Apple 호스팅 pack 다운로드 설정을 기준으로 앱과 pack의 연결 및 다운로드 동작을 구성합니다. 서버 운영과 배포 책임을 직접 관리해야 한다면 직접 호스팅하는 프로젝트 설정도 비교하세요. 호스팅 방식이 달라지면 업로드와 유지 관리 책임도 달라지므로, 기존 태그 구조만 보고 결정을 내리지 않는 것이 좋습니다.
시스템이 관리하는 다운로드를 선택해도 다운로드가 반드시 성공하거나 앱이 즉시 파일을 사용할 수 있다는 뜻은 아닙니다. 네트워크 상태나 앱의 처리 흐름에 대비해 준비 상태 확인, 대기 화면, 실패 시 재시도 또는 대체 동작을 설계해야 합니다. 기능별로 “리소스가 없을 때 앱이 무엇을 해야 하는가”를 먼저 정의하면 asset pack 경계를 정하기가 쉬워집니다.
Xcode에서 로컬 asset pack 동작을 확인하는 방법
Apple은 Xcode와 함께 제공되는 로컬 mock server를 이용한 테스트 절차를 안내합니다. Background Assets 로컬 테스트 문서를 따라 로컬에서 pack 동작을 살펴보되, 로컬 테스트 통과를 App Store 심사 통과로 간주하지 마세요.
- [ ] 이전 대상 기능과 리소스 목록을 정리하고, 각 리소스가 필요한 시점을 기록합니다.
- [ ] Managed 또는 직접 호스팅 중 어느 방식을 쓸지 정하고, 업로드와 유지 관리 담당자를 지정합니다.
- [ ] 앱의 리소스 요청 코드를 새 다운로드 흐름에 맞게 바꾸고, 준비 상태와 실패 처리를 추가합니다.
- [ ] Xcode 로컬 mock server로 pack 요청과 앱의 리소스 사용 흐름을 확인합니다.
- [ ] 실제 프로젝트의 보관, 업로드, 테스트 배포 절차에서도 앱과 asset pack이 함께 기대한 상태로 제공되는지 검증합니다.
- [ ] 검증 결과와 남은 실패 조건을 기록한 뒤, 제한 적용 대상 앱의 다음 업로드 계획을 갱신합니다.
Apple 호스팅 방식을 쓴다면 App Store Connect의 asset pack 업로드 절차와 TestFlight에서 Apple 호스팅 asset pack을 테스트하는 방법을 프로젝트 배포 절차와 대조하세요. 로컬 mock server는 앱의 리소스 처리 동작을 확인하는 단계입니다. 실제 업로드나 테스트 배포를 대신하지 않으므로 두 결과를 별도로 기록해야 합니다.
프로젝트 상황별 선택 기준
| 선택지 | 적합한 상황 | 확인할 점 |
|---|---|---|
| ODR 유지 후 이전 계획 수립 | 이미 ODR을 사용하는 앱이며 즉각적인 구조 변경보다 안정적인 운영이 우선인 경우 | 운영체제 폐기 안내와 향후 배포 조건을 추적하고, 태그와 요청 코드를 목록화합니다. |
| Managed Background Assets로 이전 | Apple 호스팅을 활용하고, 앱 리소스 다운로드 흐름을 새 구조에 맞게 바꿀 수 있는 경우 | 앱과 asset pack의 배포 관계, 로컬 사용 가능 여부, 다운로드 실패 처리를 검증합니다. |
| 직접 호스팅 방식 검토 | pack 제공과 유지 관리를 프로젝트 서버 쪽에서 통제해야 하는 경우 | 호스팅 설정과 운영 책임을 팀이 맡을 수 있는지 확인합니다. |
| 새 앱에서 ODR 제외 | 새로 출시하거나 이전에 ODR을 사용하지 않은 앱인 경우 | 제한 대상 업로드에 ODR 콘텐츠가 남지 않도록 설정과 보관 산출물을 함께 점검합니다. |
ODR을 이미 쓰는 앱은 “바로 중단”이 아니라 “현재 범위 파악 후 이전 시점 결정”이 우선입니다. 새 앱이나 과거 사용 이력이 없는 앱은 업로드 산출물에 ODR이 남지 않도록 출시 전에 확인하세요. 어떤 경우든 앱을 빌드할 수 있다는 사실만으로 업로드 조건을 통과한다고 결론 내릴 수는 없습니다.
개발 팀이 자체 Mac을 사용하면 하드웨어와 macOS 환경을 직접 통제할 수 있지만, 장비 구입과 유지 관리가 필요하고 특정 빌드 담당자의 컴퓨터에 검증이 묶일 수 있습니다. 일반 클라우드 서버는 macOS와 Xcode가 필요한 작업을 대신하지 못합니다. 반면 원격 Mac은 필요한 기간에 Xcode 빌드와 리소스 검증 환경을 마련하는 선택지지만, 지속적인 고정 부하나 물리 장비 연결이 필요한 팀에는 자체 장비가 더 적합할 수 있습니다.
이전을 위해 macOS에서 Xcode를 실행하고 pack 빌드와 프로젝트 배포 흐름을 다시 검증해야 한다면, 먼저 원격 Mac 이용 안내에서 이용 환경을 살펴보세요. 일시적인 이전 작업이나 테스트에만 Mac이 필요한 팀은 metalvnc의 요금 안내를 확인해 필요한 사용 기간과 자체 장비 유지 비용을 비교할 수 있습니다. 안정적인 상시 부하나 물리 인터페이스가 핵심 조건이라면 렌탈보다 자체 Mac을 우선 검토하고, 프로젝트의 테스트 주기와 배포 방식에 맞을 때만 원격 Mac을 선택하세요.
업로드 제한 대응, 전용 맥에서 배포 흐름을 검증하세요
metalvnc의 전용 물리 맥에서 온디맨드 리소스가 포함된 프로젝트를 빌드하고 테스트해 보세요.