Xcode 27 PrivacyInfo.xcprivacy가 Archive에 포함되지 않을 때? 2026 점검

📋 목차

증상: 프로젝트에는 PrivacyInfo.xcprivacy가 보이는데 Archive에는 없거나 제출 검증에서 오류가 납니다.
빠른 해결: 소스 폴더가 아니라 최종 .xcarchive 안의 앱과 포함된 의존성부터 확인한 뒤, target 리소스 설정과 패키지·SDK 산출물로 거슬러 올라가세요.

iOS 앱 개발자: 로컬 빌드는 되지만 앱의 개인정보 매니페스트가 Archive에서 빠지는 경우에 해당합니다.
모바일 CI 엔지니어: Swift Package나 바이너리 SDK의 매니페스트가 최종 산출물에 들어갔는지 확인해야 합니다.
DevOps 엔지니어: 원격 Mac에서 같은 커밋의 Archive 차이를 재현하고 검증 기록을 남기려는 경우에 유용합니다.

마지막 검토: 2026년 10월 5일. Xcode 27은 현재 도구 체인 배경으로만 다룹니다. 개인정보 매니페스트의 규칙이 Xcode 27에서 바뀌었다고 추정하지 않습니다. Xcode 공식 페이지와 Apple의 개인정보 매니페스트 안내를 기준으로 확인하세요.

Xcode 27 PrivacyInfo.xcprivacy Archive: 소스 파일과 최종 산출물은 다릅니다

프로젝트 탐색기나 저장소에서 파일이 보이는지는 시작점일 뿐입니다. Archive에 포함됐는지는 실제 빌드 결과로 판정해야 합니다. .xcarchive의 앱 번들 아래에서 파일을 찾고, 프레임워크와 리소스 번들도 따로 살펴보세요.

예시 경로에서 <Archive>는 실제 보관 파일 경로, <앱이름>은 앱 번들 이름을 뜻합니다.

ARCHIVE="<Archive>.xcarchive"
find "$ARCHIVE/Products" -name "PrivacyInfo.xcprivacy" -print

출력 결과가 없다면 우선 파일이 빌드 리소스로 복사되지 않았는지 봅니다. 결과가 있더라도 예상한 앱·프레임워크 번들 안에 있는지 확인해야 합니다. 다른 위치에서 발견된 파일 하나만으로 앱이 필요한 매니페스트를 올바르게 포함했다고 판단하지 마세요.

Apple은 개인정보 매니페스트를 앱 또는 서드파티 SDK의 개인정보 처리 방식을 설명하는 파일로 안내합니다. 제품 유형에 따라 배치 위치가 다를 수 있으므로, 경로를 하나로 고정하지 말고 번들에 콘텐츠를 배치하는 공식 안내와 실제 Archive의 번들 구조를 함께 대조하세요.

앱 자체의 iOS 개인정보 매니페스트가 빠졌다면 설정과 빌드 대상을 비교하세요

앱 소유 매니페스트가 보이지 않을 때는 파일의 존재보다 해당 파일이 현재 Archive에 사용한 앱 target에 연결됐는지가 중요합니다. 다른 target에만 추가했거나, 리소스 복사 단계에서 제외됐다면 저장소에는 파일이 있어도 최종 앱 번들에는 없을 수 있습니다.

다음 순서로 검사하면 프로젝트 설정 문제와 산출물 문제를 구별할 수 있습니다.

현재 Archive를 만든 Scheme과 Build Configuration을 기록합니다. 작업 브랜치에서 Archive를 생성한 Scheme과 설정이 일치하는지 확인합니다.
프로젝트에서 PrivacyInfo.xcprivacy의 소속 target을 확인합니다. 앱 target이 아닌 테스트나 다른 제품 target에만 연결된 상태인지 살펴봅니다.
해당 target의 리소스 빌드 단계와 파일 참조를 점검합니다. 파일이 프로젝트 탐색기에 표시되는 것과 빌드 리소스로 복사되는 것은 별개입니다.
같은 Scheme과 Configuration으로 Archive를 다시 만듭니다. 조건을 바꾸지 않고 재실행해야 변경 전후를 비교할 수 있습니다.
새 .xcarchive에서 앞의 find 명령을 실행하고, 앱 번들 안의 실제 경로를 기록합니다.
Archive에 파일이 있는데 제출 검증이 실패한다면 누락 문제로 단정하지 말고 형식과 선언을 검사합니다.

주의: Archive 안의 파일을 직접 고쳐 통과시키려 하지 마세요. 서명된 산출물의 내용을 변경하면 서명 검증에 영향을 줄 수 있습니다. 원본 프로젝트나 의존성을 수정한 뒤 다시 Archive를 만들어야 합니다.

같은 Scheme으로 다시 만들었는데도 결과가 다르면 생성된 Archive의 경로와 빌드 로그를 보존하세요. 단순히 프로젝트 탐색기 화면만 비교하면 복사 단계에서 빠진 것인지, 다른 target을 보관한 것인지 구분하기 어렵습니다.

Swift Package와 SDK는 각각의 리소스 경계를 따라가세요

Swift Package: Sources 폴더에 둔 파일과 패키지 리소스는 같지 않습니다

Swift Package의 PrivacyInfo.xcprivacy는 파일이 Sources 아래에 있다는 이유만으로 앱에 포함되지 않습니다. 패키지에서 리소스를 처리하는 규칙에 맞춰 선언했는지 확인하고, 패키지 산출물과 최종 앱 번들을 각각 살펴보세요. Apple의 Swift Package 리소스 번들링 안내는 패키지 리소스 선언과 처리 방식을 설명합니다.

패키지 자체 산출물에 매니페스트가 없으면 패키지의 리소스 선언을 먼저 확인합니다. 패키지 번들에는 들어 있지만 최종 앱에서 예상한 위치를 찾지 못했다면, 앱 target의 포함 관계나 번들 구조가 원인일 수 있습니다. 두 문제를 한꺼번에 “앱 설정 오류”로 처리하지 말고 검사 지점을 나눠야 합니다.

제3자 SDK: SDK 번들에 있는지와 Archive에 보존됐는지를 따로 봅니다

SDK 공급자가 매니페스트를 제공하는지 확인한 뒤, 바이너리 프레임워크나 리소스 번들 안에 실제 파일이 있는지 검사합니다. 이어서 최종 Archive에서도 SDK 번들의 구조와 파일을 확인하세요. 앱의 매니페스트를 추가하는 일만으로 SDK 코드의 처리 방식을 대신 신고할 수는 없습니다.

Apple은 특정 서드파티 SDK에 대한 제출 요구 사항과 대상 목록을 관리합니다. 따라서 모든 SDK가 같은 요구를 받는다고 가정하지 말고, 현재의 서드파티 SDK 요구 사항에서 해당 SDK가 대상인지 확인하세요. 매니페스트의 데이터 사용 설명은 Apple의 개인정보 매니페스트 데이터 사용 안내와 맞춰 검토합니다.

책임 경계도 분명히 하세요. SDK 내부 동작과 제공 파일은 SDK 공급자에게 확인하고, 프로젝트에 해당 SDK를 넣고 Archive에 보존하는 과정은 앱 통합 담당자가 확인해야 합니다. SDK의 매니페스트가 아예 없거나 선언이 실제 동작과 맞지 않는다면 공급자에게 확인을 요청하고, 자체 앱 매니페스트로 덮어쓰지 않습니다.

참고: Apple이 요구하는 대상 SDK인지 여부는 현재 공식 목록으로 판정하세요. 이전에 다른 SDK에서 적용했던 처리 방식을 새 의존성에도 그대로 적용하면 놓치는 조건이 생길 수 있습니다.

원격 Mac CI에서만 빠지면 같은 커밋의 입력과 결과를 대조하세요

로컬에는 파일이 있는데 원격 Mac CI 산출물에 없다면, 먼저 소스 자체가 다른지 빌드 입력이 다른지 가려야 합니다. 같은 커밋이라도 활성 Xcode, 빌드 설정, 의존성 해석 결과가 다르면 생성되는 Archive를 같은 것으로 볼 수 없습니다.

다음 자료를 한 작업 단위로 모으세요.

커밋 식별 정보와 Archive에 사용한 Scheme 및 Configuration
활성 Xcode 버전과 빌드 로그
Swift Package 및 기타 의존성의 해석 결과
CI에서 생성한 .xcarchive 경로와 find 검사 결과
로컬에서 같은 조건으로 생성한 Archive의 검사 결과

각 환경에서 매니페스트 파일 자체를 찾은 뒤, 앱·패키지·SDK 중 어느 번들에 있는지 비교하세요. 로컬에만 있다면 target 리소스 설정, 체크아웃된 소스, 의존성 해석 차이를 살핍니다. 두 환경 모두 파일을 포함하지만 제출 결과가 다르면 파일 경로와 내용 검증으로 넘어가세요.

원격 Mac은 macOS Archive를 다시 생성하고 비교할 수 있는 실행 환경이지, 매니페스트의 내용이 정확한지 판정해 주는 검증 대체물이 아닙니다. 로컬과 CI 결과를 장기간 비교해야 한다면 맥 미니 렌탈 가이드를 검토해 전용 macOS 빌드 환경이 필요한지 판단할 수 있습니다.

파일은 있지만 검증에서 실패한다면 문법과 선언을 분리하세요

파일이 Archive에 있다는 사실만으로 내용이 유효하다고 볼 수 없습니다. 먼저 plist 형식 오류, 허용되지 않는 키나 값, 필수 사유 API 선언과 실제 사용의 불일치를 서로 다른 문제로 분류하세요.

문법 확인에는 다음과 같이 파일 경로를 지정할 수 있습니다.

plutil -lint "<PrivacyInfo.xcprivacy 경로>"

이 검사는 plist 형식이 읽히는지 확인하는 용도입니다. 개인정보 선언이 올바른지까지 판정하지는 않습니다. 선언 항목은 데이터 사용 설명 문서와 필수 사유 API 안내에 따라 실제 사용과 대조하세요.

Apple의 TN3181 무효 개인정보 매니페스트 진단 문서도 참고해 형식 오류와 유효하지 않은 선언을 분리합니다. 파일이 존재하지만 App Store Connect 검증이 계속 실패한다면, 오류 메시지를 기준으로 해당 번들의 매니페스트와 선언 값을 확인하고 수정 후 새 Archive를 생성하세요.

어떤 경로부터 확인할지 결정 조건과 점검 평가

다음 조건으로 첫 조사 지점을 정하세요. 한 경로에서 원인이 확인되지 않으면 다음 항목으로 넘어갑니다.

최종 .xcarchive에서 파일이 전혀 검색되지 않으면 앱 target의 리소스 복사 설정부터 확인합니다. 앱 자체 파일이 아니라면 Swift Package의 리소스 선언이나 SDK 내부 파일로 범위를 좁힙니다.
Swift Package 산출물에도 파일이 없으면 패키지의 리소스 선언을 수정하고 패키지 산출물을 다시 확인합니다. 패키지에는 있지만 앱에서 누락되면 앱에 포함되는 번들 구조를 점검합니다.
SDK 번들에 파일이 없으면 SDK 공급자의 제공 여부와 공식 요구 대상 여부를 확인합니다. 앱 매니페스트에 SDK 내용을 대신 추가하는 방식으로 해결하지 않습니다.
파일이 있지만 예상 위치와 다르면 제품 유형에 맞는 번들 경로와 Archive 대상이 맞는지 확인합니다. 앱, 프레임워크, 리소스 번들의 경로를 서로 바꿔 적용하지 않습니다.
파일과 위치가 맞는데 검증 오류가 나면 형식과 선언을 확인합니다. 수정은 빌드 원본에 반영하고 새 Archive로 검증합니다.
로컬과 원격 Mac CI의 결과가 다르면 같은 커밋, 활성 Xcode, 빌드 설정, 의존성 결과부터 비교합니다. 조건을 기록하지 못했다면 먼저 빌드 기록을 보완합니다.

점검 상황	우선 확인할 위치	평가
앱 자체 파일이 Archive에서 안 보임	앱 target과 리소스 빌드 단계	높은 우선도
Swift Package에서 누락됨	패키지 리소스 선언과 패키지 번들	높은 우선도
SDK 파일 유무가 불분명함	바이너리 프레임워크와 리소스 번들	높은 우선도
파일은 있으나 검증이 실패함	plist 형식, 선언 값, 필수 사유 API	매우 높은 우선도
로컬만 성공하고 CI는 실패함	커밋, 활성 Xcode, 설정, 의존성, Archive	높은 우선도

현재 빌드 방식과 원격 Mac을 선택하는 기준

Linux 빌드 노드는 macOS 전용 Xcode Archive를 직접 대체할 수 없고, 개발자 로컬 Mac만으로 운영하면 빌드 환경과 의존성 상태가 팀원마다 달라질 수 있습니다. 공용 Mac을 번갈아 쓰는 방식은 사용 가능 시간과 재현 기록을 관리하기 어렵습니다. 반면 원격 Mac은 분리된 macOS 빌드 노드에서 Archive를 재생성하고 CI 결과를 비교하는 데 도움이 되지만, 매니페스트의 정확성을 자동으로 보증하지는 않습니다.

간헐적인 재현이나 독립된 CI 검증 환경이 필요한 경우에는 MacDate의 원격 Mac 구성 안내를 살펴보고 전용 노드가 필요한지 검토하세요. 이미 장기간 안정적으로 사용하는 로컬 Mac이 있고 물리 장치 연결이 필요하다면 직접 보유하는 편이 더 적합할 수 있습니다. 선택과 관계없이 최종 판정 기준은 같은 빌드 조건에서 생성한 Archive의 번들 구조와 유효성 검사 결과입니다.