출시한 지 한참 된 앱에서 작은 버그를 고쳐 업데이트를 올립니다. 심사에 들어가기도 전에 메일이 한 통 옵니다. ITMS-91061, 개인정보 매니페스트가 없다는 내용입니다. 기능은 그대로고 화면도 그대로인데 업로드 단계에서 막힙니다.
메일에 적힌 이름은 우리가 만든 코드가 아닙니다. 앱에 들어간 외부 라이브러리 이름입니다. 그 라이브러리를 고칠 권한은 우리 개발사에 없습니다. 앱 외주 견적을 받을 때 외부 SDK 목록을 함께 받아두라고 권하는 이유가 여기 있습니다.
견적서에는 기능이 적히고, 그 기능을 돌리는 SDK는 안 적힙니다
견적서 항목은 보통 '푸시 알림', '지도 표시', '소셜 로그인'처럼 기능 단위로 적힙니다. 그 기능을 무엇으로 구현하는지는 적히지 않습니다. 고객 입장에서는 결과만 보면 되니 그동안 문제가 없었습니다.
하지만 같은 '푸시 알림'이라도 외부 SDK를 붙였는지 직접 구현했는지에 따라 2년 뒤에 생기는 일이 달라집니다. 그래서 견적 요청서에 한 줄만 더 넣으세요. "앱에 들어가는 외부 SDK와 라이브러리의 이름, 버전을 목록으로 주세요"입니다.
반려 메일은 매니페스트와 서명, 두 종류로 따로 옵니다
애플 개발자 포럼에 올라온 실제 메일 문구는 이렇습니다. 앱에 들어간 특정 SDK가 프라이버시에 영향을 주는 서드파티 SDK로 지정돼 있고, 2025년 2월 12일부터 그 SDK에 개인정보 매니페스트 파일이 있어야 한다는 내용입니다. 이것이 ITMS-91061입니다.
서명이 빠진 경우는 ITMS-91065로 따로 옵니다. 매니페스트와 서명은 별개 요건이라, 매니페스트를 해결한 뒤 서명에 다시 걸리는 사례가 포럼에 보고돼 있습니다. 메일 하나를 해결했다고 끝난 것이 아닙니다.
매니페스트는 SDK 안에 들어 있어야 합니다. 우리 앱의 매니페스트에 SDK의 개인정보 처리 내용을 대신 적어 넣는 것은 애플이 안내문에서 명시적으로 금지하고 있습니다.
애플은 종류가 아니라 이름으로 86개를 지정해 두었습니다
애플은 대상 SDK를 '분석 도구 전체'처럼 묶지 않고 이름으로 지정합니다. 2026년 10월 25일 기준 공식 페이지에 86개 이름이 올라 있습니다. Firebase 계열, Facebook SDK 계열, OneSignal, Flutter, Capacitor, Cordova, UnityFramework, RxSwift, Alamofire, Lottie, OpenSSL 같은 것들입니다.
흔히 떠올리는 지도나 결제 SDK는 이 목록에 없습니다. 대신 알림(OneSignal), 크래시 리포트(FirebaseCrashlytics), 위치(geolocator_apple)처럼 데이터를 다루는 것들과, 앱 전체가 그 위에 올라가 있는 크로스플랫폼 프레임워크가 들어 있습니다.
목록에 오른 SDK는 모든 버전이 대상이고, 그 SDK를 다시 포장한 SDK도 대상입니다. 우리가 직접 고른 적이 없는데 다른 SDK가 끌고 들어온 라이브러리 때문에 반려되는 일이 여기서 나옵니다.
고칠 권한은 우리 개발사가 아니라 SDK 제공사에 있습니다
애플의 안내는 짧고 분명합니다. 메일에 적힌 SDK 이름을 확인하고, 그 SDK 제공사에 연락해 매니페스트가 포함된 새 버전을 받으라고 적혀 있습니다. 우리 개발사가 할 수 있는 일은 새 버전이 나왔는지 확인하고 적용해 다시 올리는 것까지입니다.
SDK가 유료 상용 제품이면 지원 창구에 문의를 넣을 수 있습니다. 오픈소스면 깃허브 저장소에 이슈를 올리고 기다리는 것이 전부입니다. 어느 쪽이든 "며칠까지 고쳐주겠다"는 약속을 받아낼 수단이 없습니다.
기다리는 기간은 제공사 사정이고, 우리가 줄일 수 없습니다
2026년 7월 애플 포럼에 올라온 사례가 이 구조를 잘 보여줍니다. Capacitor 기반 앱인데, 공식 배포 프레임워크가 오래된 SDK로 빌드돼 ITMS-90111에 걸립니다. 직접 다시 빌드하면 서명이 사라져 이번에는 ITMS-91065에 걸립니다.
글쓴이는 그 서명을 만들 수 있는 쪽이 배포사의 빌드 파이프라인뿐이라고 적었습니다. 같은 내용으로 올린 깃허브 이슈에도 응답이 없는 상태였습니다. 이때 개발사가 쥔 카드는 '대기'와 '교체' 두 장뿐입니다.
교체 개발비는 새 기능 값이 아니라 원상 복구 값입니다
푸시 SDK를 바꾸면 발송 서버, 토큰 저장 방식, 수신 통계가 함께 바뀝니다. 크로스플랫폼 프레임워크가 걸리면 영향 범위는 앱 전체입니다. 화면 하나 고치는 일과 견적을 같은 기준으로 매길 수 없습니다.
금액은 앱마다 달라 일반화할 수 없습니다. 중요한 것은 이 작업의 성격입니다. 돈을 더 내고 받는 결과물이 어제와 똑같은 앱입니다. 눈에 보이는 변화가 없는 지출이라 계약서에 미리 적혀 있지 않으면 거의 반드시 분쟁이 됩니다.
견적을 받을 때 이 여섯 줄을 같이 받아두세요
개발사가 이미 가지고 있는 정보라 만드는 데 오래 걸리지 않습니다. 착수 전에 요청하면 거절할 이유도 없습니다.
- 외부 SDK와 라이브러리 이름, 적용 버전
- 애플 지정 목록 포함 여부
- 매니페스트와 서명이 들어간 버전 번호
- 유료인지 무료인지, 지원 창구가 어디인지
- 그 SDK를 빼면 어떤 기능이 사라지는지
- 교체 후보로 검토할 수 있는 대안
이 목록이 있으면 반려 메일을 받은 날 바로 판단할 수 있습니다. 목록이 없으면 원인을 찾는 데만 며칠이 더 들어갑니다.
유지보수 계약서는 'SDK 요건 변경 대응'을 세 갈래로 나눠 적으세요
첫째, SDK 제공사가 새 버전을 내놓은 경우입니다. 버전을 올리고 재빌드해 다시 업로드하는 작업은 유지보수 기본 범위에 넣는 것이 맞습니다. 둘째, 제공사가 대응하지 않아 다른 SDK로 교체해야 하는 경우입니다. 이쪽은 별도 유상으로 하고, 공수 산정 기준과 착수 승인 절차를 지금 적어두세요.
셋째, 대기 기간의 책임입니다. 제공사 미대응으로 업데이트가 막힌 기간은 개발사의 지체 책임에서 제외하는 조항을 넣으세요. 대신 개발사는 반려 메일을 받으면 며칠 안에 원인 SDK 이름과 제공사 대응 현황을 보고할 의무를 집니다.
"애플 정책 변경 대응은 유지보수에 포함됩니다"를 구두로 듣는 것은 의미가 없습니다. 버전 업데이트까지인지 교체까지인지, 문장으로 구분해 적혀 있어야 합니다.
모든 앱이 이 요건에 걸리는 것은 아닙니다
안드로이드만 배포하는 앱은 해당이 없습니다. 애플 생태계의 요건입니다. 또 이 요건은 신규 앱 제출과 지정 SDK를 새로 추가하는 업데이트에 걸립니다. 기존 SDK를 그대로 둔 업데이트에 어디까지 적용되는지는 공식 문서에 명확히 적혀 있지 않고, 포럼에서도 답이 정리되지 않았습니다.
애플 목록에 없는 SDK는 지금 대상이 아닙니다. 다만 목록은 애플이 갱신하는 것이고 선정 기준은 공개되지 않았습니다. 오늘 목록에 없다는 사실이 영구 면제를 뜻하지는 않습니다.
지정 목록과 매니페스트 요건은 애플 Third-party SDK requirements와 개인정보 매니페스트 추가 안내에서 직접 확인하세요. 계약 범위를 문장으로 정리하는 이야기는 실무 가이드에 모아두었고, 견적 단계 점검이 필요하면 Codeforest로 문의하셔도 됩니다.
결론: 목록 한 장과 계약서 세 줄로 정리하세요
업데이트가 막히는 원인은 우리 앱 코드가 아니라 앱에 들어간 남의 코드입니다. 고칠 권한도 그쪽에 있습니다. 견적 단계에서 할 수 있는 대비는 무엇이 들어가는지를 목록으로 확보해두는 것뿐입니다.
그다음은 문장입니다. 버전 업데이트까지는 유지보수 범위, 교체는 유상, 제공사 미대응 기간은 개발사 책임에서 제외. 이 세 줄이 계약서에 없으면 기다리는 시간과 추가 비용은 결국 앱을 가진 쪽이 전부 지게 됩니다.