App Store Connect Missing Compliance: 2026 암호화 수출은 어떻게 입력할까?

첫 판단은 HTTPS 사용 여부가 아니라 최종 빌드에 포함된 암호화 출처로 내려야 합니다. Apple 운영체제가 제공하는 암호화 기능만 사용했다면 보통 파일 제출 없이 처리하고, 외부 표준 알고리즘이나 비표준 암호화가 포함됐다면 App Store Connect 설문과 관련 자료를 먼저 확인해야 합니다.

증상 → 가장 빠른 해결: 빌드 업로드는 성공했지만 TestFlight에서 Missing Compliance가 표시된다면, App Store Connect Missing Compliance를 오류 서명이나 잘못된 바이너리로 보지 말고 최종 Archive의 암호화 사용 여부와 Info.plist를 차례로 검증해야 합니다.

이 글은 TestFlight 업로드 뒤 배포가 멈춘 독립 개발자와 소규모 팀을 위한 실행 지침입니다. HTTPS, Keychain, 로그인 SDK, 결제 SDK 또는 종단 간 암호화를 사용하는 앱, 그리고 원격 Mac이나 지속적 통합 환경에서 반복적으로 빌드하는 팀이 특히 유용하게 활용할 수 있습니다.

SECTION 01App Store Connect Missing Compliance 상태 구분

Missing Compliance는 업로드된 빌드에 수출 규정 관련 정보가 아직 제공되지 않았다는 뜻입니다. Apple은 빌드 상태와 TestFlight의 수출 규정 절차를 별도로 안내하고 있으며, 이 상태를 Invalid Binary, 서명 실패 또는 Apple 서버의 처리 대기 상태와 같은 문제로 해석해서는 안 됩니다.

Apple의 빌드 상태 설명에 따르면 빌드 상태는 업로드 및 처리 결과를 보여주는 영역입니다. 반면 수출 규정 정보는 별도의 질문에 답하거나 승인된 자료를 연결하는 절차입니다. 따라서 업로드가 성공했다는 사실만으로 TestFlight 배포에 필요한 모든 정보가 끝난 것은 아닙니다.

먼저 세 가지 경로로 나누세요

자료 없이 설문 답변으로 처리하는 경로
앱이 Apple 운영체제가 제공하는 암호화 기능만 사용하고, 앱이나 포함된 라이브러리가 별도 암호화 구현을 추가하지 않았다면 이 경로를 우선 검토합니다.
추가 확인이 필요한 경로
외부 SDK나 라이브러리가 표준 암호화 알고리즘을 자체적으로 포함하거나, 어떤 기능이 실제 최종 빌드에 들어갔는지 확인되지 않았다면 SDK 문서와 바이너리 구성을 조사한 뒤 설문에 답합니다.
자료 제출 또는 공식 분류가 필요한 경로
자체 암호화 프로토콜, 공인 표준으로 보기 어려운 알고리즘, 보안 통신이나 보안 저장 자체가 핵심인 앱이라면 Info.plist 값을 바꾸는 것만으로 해결하려 하지 말고 필요한 신고와 분류 자료를 준비합니다.

판정 조건 체크 목록

다음 항목을 순서대로 확인하면 판단을 빠르게 좁힐 수 있습니다.

[ ] 앱 자체 코드에 암호화 알고리즘이나 별도 보안 프로토콜이 없습니다.
[ ] 정적·동적 라이브러리와 모든 SDK의 암호화 구현 여부를 확인했습니다.
[ ] 최종 Archive에 실제 포함된 의존성 목록을 보관했습니다.
[ ] Apple 시스템 API만 사용하는 기능과 외부 구현을 구분했습니다.
[ ] 배포 지역과 앱의 실제 보안 기능을 확인했습니다.
[ ] 추가 자료가 필요한지 App Store Connect 설문에서 확인했습니다.
[ ] 판단 결과와 최종 Info.plist 값이 서로 일치합니다.

첫 네 항목까지 모두 확인되고 외부 암호화 구현이 없다면 설문 답변 중심의 경로를 검토합니다. 외부 SDK의 구현을 확인하지 못했다면 두 번째 경로로 돌아가야 합니다. 자체 암호화나 보안 기능이 핵심이라면 마지막 경로를 선택하고, 값만 바꾸어 질문을 우회하지 않아야 합니다.

핵심은 앱의 업무 코드만 보는 것이 아닙니다. 앱 자체 코드, 시스템 API, 정적 또는 동적 라이브러리, 로그인·결제 SDK, 분석 모듈을 포함한 업로드된 완성 빌드 전체가 신고 대상이 될 수 있습니다.

SECTION 02Apple 시스템 암호화만 쓰는 앱은 어떻게 확인하나요?

일반적인 네트워크 앱이 시스템 네트워크 프레임워크를 통해 HTTPS를 사용하거나, Keychain과 운영체제의 암호화 저장 기능을 호출하는 경우가 있습니다. 이런 사용만으로 복잡한 수출 자료 제출이 자동으로 필요하다고 단정할 수는 없습니다. 반대로 HTTPS를 사용한다는 이유만으로 무조건 면제라고 단정해서도 안 됩니다.

다음 증거를 모아 내부 검토 기록으로 남기면 좋습니다.

앱 코드에서 직접 구현한 암호화 알고리즘이나 별도 프로토콜이 있는지 확인합니다.
의존성 관리 파일과 포함된 정적·동적 라이브러리 목록을 저장합니다.
각 SDK가 암호화를 직접 구현하는지, 운영체제 기능을 호출하는지 공식 문서로 확인합니다.
앱의 실제 기능이 단순한 전송 보호인지, 보안 통신이나 보안 저장 기능 자체를 제공하는지 설명합니다.
App Store Connect 설문 답변 화면과 최종 판단 근거를 내부 문서에 보관합니다.

이 목록은 법률 자문을 대신하지 않습니다. 다만 나중에 SDK를 교체하거나 빌드 환경을 옮겼을 때 같은 질문을 다시 검토할 수 있는 기술적 근거가 됩니다. Apple의 수출 규정 개요와 암호화 수출 규정 준수 안내를 함께 확인해야 합니다.

HTTPS와 Keychain만 사용하면 설문은 어떻게 답하나요?

최종 빌드에 Apple 운영체제가 제공하는 암호화 기능만 있고 외부 암호화 구현이 없다면, 해당 사실을 기준으로 설문을 답합니다. 단순히 사업 코드에서 암호화 함수를 호출하지 않았다는 이유만으로 판단하지 말고, SDK와 라이브러리까지 확인해야 합니다.

이때 내부 기록에는 다음을 구분해 적습니다.

HTTPS 연결에 사용한 네트워크 계층
Keychain 또는 시스템 보안 저장소 사용 여부
외부 암호화 라이브러리의 포함 여부
배포 대상 지역과 앱의 실제 보안 기능
최종 Archive에서 확인한 설정

SECTION 03외부 SDK나 자체 알고리즘이 들어가면 무엇이 달라지나요?

로그인 SDK나 결제 SDK가 통신을 보호한다는 사실만으로 신고 결론이 자동으로 정해지지는 않습니다. SDK가 Apple 시스템 기능을 호출하는지, 표준 암호화 알고리즘을 바이너리 안에 직접 포함하는지, 해당 기능이 앱에서 실제로 활성화되는지를 구분해야 합니다.

표준 암호화 라이브러리를 포함한 경우

다음 순서로 확인합니다.

SDK 공식 문서에서 암호화 구현 주체를 확인합니다.
배포된 바이너리와 라이브러리 구성에서 관련 모듈의 존재를 점검합니다.
앱 빌드 설정에서 해당 보안 기능이 실제로 활성화되는지 확인합니다.
App Store Connect 설문에서 사용 목적과 범위를 사실대로 답합니다.
설문 결과가 자료 제출을 요구하면 관련 문서를 준비합니다.

업무 코드에서 알고리즘을 직접 호출하지 않았더라도, 포함된 SDK가 자체적으로 표준 암호화를 구현한다면 자동으로 면제라고 볼 수 없습니다. 미국 수출 분류가 관련되는 경우에는 미국 암호화 자주 묻는 질문 자료를 확인하되, 앱의 구체적인 분류를 글 하나만으로 확정하지 않아야 합니다.

프랑스에 배포하는 앱은 별도 확인이 필요할 수 있습니다. 프랑스의 암호화 수단 관련 규제 안내를 검토하고, 앱 기능과 배포 방식에 맞는 전문 자문을 받아야 합니다. 특정 SDK나 앱이 반드시 신고 대상이거나 반드시 면제된다고 일반화해서는 안 됩니다.

자체 프로토콜이나 보안 제품이라면 어떻게 처리하나요?

자체 암호화 프로토콜, 널리 인정된 표준에 속하지 않는 알고리즘, 보안 통신과 보안 저장을 주된 기능으로 제공하는 앱은 보수적으로 접근해야 합니다. 이 경우 Info.plist 값을 바꾸어 질문을 숨기는 방식은 적절한 해결책이 아닙니다.

구분해야 할 자료는 다음과 같습니다.

CCATS: 미국 수출 분류와 관련해 필요한 경우 검토하는 공식 분류 자료입니다.
프랑스 암호화 신고 자료: 프랑스 배포와 관련된 별도 규제 절차를 검토할 때 사용합니다.
Apple 심사용 코드 제공: Apple의 심사 과정에서 기능을 확인하기 위한 자료이며, 수출 분류 자료와 같은 의미는 아닙니다.

이 세 가지는 서로 대체 관계가 아닙니다. 자료의 필요 여부는 앱의 암호화 기능, 배포 지역, 사용 목적과 법적 지위에 따라 달라질 수 있으므로 의심이 남으면 수출 통제 경험이 있는 전문가에게 확인해야 합니다.

주의: 로그인 SDK, 결제 SDK, 오픈 소스 암호화 라이브러리를 모두 같은 범주로 처리하지 마세요. SDK 이름보다 실제 포함된 구현과 최종 빌드에서 활성화된 기능이 판단의 출발점입니다.

SECTION 04`ITSAppUsesNonExemptEncryption`은 어떻게 설정하나요?

ITSAppUsesNonExemptEncryption은 앱이 면제되지 않는 암호화를 사용하는지 나타내는 Info.plist 키입니다. Apple의 해당 키 문서 기준으로 프로젝트 설정이 아니라 최종 앱 번들의 값이 중요합니다.

NO: 최종 앱이 면제되지 않는 암호화를 사용하지 않는다는 판단을 나타냅니다.
YES: 면제되지 않는 암호화를 사용한다고 판단한 경우에 해당합니다.
미설정: App Store Connect가 빌드별로 수출 규정 정보를 다시 요구할 수 있습니다.

따라서 NO는 질문을 회피하는 우회 값이 아닙니다. 앱과 포함된 의존성을 검토한 뒤 실제 판단과 일치할 때만 사용해야 합니다. 승인 코드가 발급된 경우에는 ITSEncryptionExportComplianceCode의 사용 가능 여부와 적용 범위를 Apple 절차에 맞춰 확인합니다.

`Info.plist`를 바꿨는데 새 빌드에서도 다시 묻는 이유는 무엇인가요?

가장 흔한 원인은 소스 설정과 최종 Archive의 설정이 서로 다르기 때문입니다. 다른 빌드 구성에서 Archive했거나, 빌드 단계에서 별도 Info.plist가 사용됐거나, 수정 전 아카이브를 다시 업로드했을 수 있습니다.

다음 순서로 재현을 막습니다.

암호화 출처와 SDK 목록을 고정합니다.
개발 설정이 아닌 실제 배포용 빌드 설정을 수정합니다.
새 Archive를 생성합니다.
최종 앱 번들의 Info.plist에서 키와 값을 확인합니다.
이전 Archive가 아닌 새 빌드를 업로드합니다.
TestFlight의 빌드 세부 정보에서 Provide Export Compliance Information 절차를 완료합니다.
빌드가 테스트 가능 상태로 바뀌는지 확인합니다.

최종 파일은 plutil 같은 검증 도구로 확인할 수 있지만, 계정 정보나 비공개 경로를 로그에 그대로 남기지 않아야 합니다. Apple의 빌드 업로드 안내도 함께 확인하세요.

TestFlight에서 Missing Compliance가 보이면 바로 설치할 수 있나요?

항상 설치할 수 있다고 가정하면 안 됩니다. 내부 테스터에게 표시되는 빌드라도 수출 규정 정보가 완료되지 않으면 배포나 설치가 제한될 수 있습니다. 먼저 TestFlight의 빌드 세부 정보에서 베타 빌드 수출 규정 정보 제공 절차를 열고, 설문에 답하거나 승인된 자료를 연결해야 합니다.

SECTION 05원격 Mac 배포 과정에 합규 검사를 어떻게 넣나요?

원격 Mac이나 지속적 통합 환경에서는 한 번 해결한 Missing Compliance가 다음 빌드에서 되살아나는 일이 더 위험합니다. 기계가 바뀌었기 때문이 아니라, Archive 구성·의존성·업로드 경로가 달라졌기 때문일 수 있습니다.

배포 전 검증 순서

의존성 목록과 변경된 SDK를 저장합니다.
최종 Archive의 Info.plist 값을 확인합니다.
업로드 로그에서 새 빌드 번호와 대상 앱을 확인합니다.
App Store Connect의 처리 상태와 수출 규정 상태를 각각 기록합니다.
TestFlight에서 실제 설치 가능 상태를 확인합니다.
그래픽 화면을 통한 업로드와 자동화 업로드가 같은 결과를 내는지 비교합니다.
설정을 변경했다면 새 Archive로 반복 검증합니다.

판정은 세 가지로 남기면 운영자가 빠르게 대응할 수 있습니다.

설문 처리만 필요함: 암호화 출처가 확인됐고 추가 자료가 요구되지 않는 경우입니다.
빌드 설정으로 반복 질문을 줄일 수 있음: 면제 판단이 명확하고 최종 Info.plist 값이 누락된 경우입니다.
자료 승인 후 배포해야 함: 외부 표준 암호화, 비표준 알고리즘 또는 지역별 규정 검토가 남은 경우입니다.

원격 환경을 새로 마련해야 한다면 MACNOX의 한국어 원격 Mac 이용 안내를 검토할 수 있습니다. 다만 원격 Mac은 합규 판단을 대신하지 않습니다. 필요한 것은 깨끗한 배포 환경, 재현 가능한 Archive, 접근 권한 분리입니다. 비용과 사용 기간을 비교해야 한다면 MACNOX 요금 안내에서 현재 조건을 확인한 뒤, 장기 상시 부하에는 직접 구매나 자체 서버가 더 적합한지도 함께 판단해야 합니다.

로그와 화면 캡처에는 계정 이름, Bundle ID, API Key, 승인 코드, 비공개 SDK 이름과 내부 파일 경로를 남기지 마세요. 합규 기록은 남겨야 하지만, 자격 증명과 내부 구조까지 외부 저장소에 복사할 필요는 없습니다.

이번 문제의 핵심은 NO를 빠르게 넣는 것이 아닙니다. 완성된 빌드의 암호화 출처를 확인하고, 그 결과에 맞는 설문·자료·Info.plist를 같은 기준으로 관리하는 것입니다. 현재 환경이 로컬 Mac 한 대라면 의존성 확인, Archive 검사, 업로드 재시도를 매번 수동으로 해야 하고, 전용 Mac을 직접 구매하면 초기 비용과 유지 관리 책임이 생깁니다. 단기간 출시나 반복 검증이 목적이라면 MACNOX의 원격 Mac을 이용해 먼저 배포 환경을 재현해 보는 편이 더 유연할 수 있습니다. 설정이 끝난 뒤에는 실제 Archive, 업로드, TestFlight 분배를 한 번 수행해 합규 정보와 서명 자산이 함께 재현되는지 확인하세요.