업로드 완료 표시 → TestFlight에 빌드가 없음 가장 빠른 해결 → 같은 명령을 반복하지 말고 아카이브·검증, 전송, 애플 처리, 규정·제출 중 어느 단계에서 멈췄는지 먼저 분리합니다.
애플은 업로드한 빌드가 Processing 상태로 24시간을 넘기면 문제가 있을 수 있다고 안내합니다. 따라서 첫 조치는 재시도가 아니라 상태와 로그 확인입니다. (애플의 빌드 업로드 상태 안내)
이 글은 다음 사용자를 위한 점검표입니다.
- Xcode Organizer 또는 Transporter로 올렸지만 검증, 인증, 전송 오류가 반복되는 독립 개발자
- fastlane이나 스크립트로 배포하면서 실패 단계가 로그에 남지 않는 작은 팀
- 안정적인 맥이 없어 반복 가능한 iOS 배포 환경을 만들려는 윈도우 또는 리눅스 개발자
먼저 실패 지점을 네 단계로 나눕니다
App Store Connect 업로드 실패는 한 가지 오류명이 아닙니다. 아래 순서로 구분해야 서명 문제와 네트워크 문제를 혼동하지 않습니다.
| 확인 단계 | 화면에서 보이는 증상 | 먼저 볼 위치 | 다음 조치 |
|---|---|---|---|
| 아카이브·검증 | Archive 또는 Validate 단계에서 즉시 실패 | Organizer의 검증 결과, 서명 오류 | Xcode와 SDK, 서명, 식별자 확인 |
| 전송 | 업로드 중 멈춤, 인증 만료, 연결 종료 | Organizer 또는 Transporter 전송 로그 | 네트워크와 인증을 확인한 뒤 재전송 |
| 애플 처리 | 업로드는 완료됐지만 Processing 또는 Failed | App Store Connect의 빌드 업로드 기록 | 상태 상세 오류와 이메일 확인 |
| 규정·제출 | Invalid Binary, Missing Compliance, 버전 선택 불가 | TestFlight와 앱 버전 화면 | 바이너리 수정, 수출 규정 답변, 앱 기록 점검 |
Processing, Failed, Complete는 빌드 업로드 상태입니다. Complete가 되면 테스트에 사용할 준비가 된 상태이고, Failed라면 빌드 상세 화면에서 오류를 확인해야 합니다. Invalid Binary와 Missing Compliance는 별도의 조치가 필요한 빌드 상태입니다. ([애플의 빌드 상태 정의](https://developer.apple.com/help/app-store-connect/reference/app-build-statuses/?utm_source=openai))
주의: Organizer에서 “업로드 완료”가 표시되어도 TestFlight에 즉시 보인다는 뜻은 아닙니다. 애플 시스템의 처리가 끝나야 App Store Connect의 빌드 목록에 표시됩니다.
Xcode 26과 SDK를 아카이브 기준으로 확인합니다
2026년 4월 28일부터 App Store Connect에 올리는 iOS 및 iPadOS 앱은 Xcode 26 이상과 iOS 26 또는 iPadOS 26 SDK 이상으로 빌드해야 합니다. 현재 창에서 어떤 Xcode를 열었는지가 아니라, 실제 Archive가 어느 Xcode와 SDK로 만들어졌는지가 중요합니다. (애플의 2026년 제출 요구 사항)
다음 명령으로 현재 선택된 개발 도구를 확인합니다.
xcode-select -p
xcodebuild -version
xcodebuild -showsdks아카이브를 만든 뒤에는 Organizer에서 아카이브의 상세 정보를 열고 사용한 Xcode와 SDK를 확인합니다. 별도의 Xcode 버전을 설치해 두었더라도 xcode-select가 예전 경로를 가리키면 예상과 다른 도구 체인으로 빌드될 수 있습니다.
점검 순서는 다음과 같습니다.
xcodebuild -version으로 실제 Xcode 버전을 확인합니다.xcodebuild -showsdks로 대상 플랫폼 SDK를 확인합니다.- iOS 앱이면 iOS 26 SDK 이상인지 확인합니다.
- 프로젝트와 각 타깃의 Deployment Target을 확인합니다.
- 주 앱, 앱 확장, 위젯, 알림 서비스 등 모든 구성 요소가 같은 배포 조건을 만족하는지 봅니다.
- Xcode 27 Beta를 사용했다면 정식 제출 기준과 혼동하지 않습니다.
서명과 앱 연결 정보를 한 덩어리로 검증합니다
검증 실패가 발생하면 인증서 하나만 교체하는 방식으로 접근하지 마십시오. App Store Connect는 업로드 파일 안의 Bundle ID와 버전 번호를 사용해 앱 기록과 연결하고, 빌드 번호로 업로드된 빌드를 구분합니다.
다음 순서로 확인하면 불필요한 인증서 재발급을 줄일 수 있습니다.
- 프로젝트의 Team이 올바른 개발자 계정인지 확인합니다.
- 주 앱의 Bundle ID가 App Store Connect 앱 기록과 같은지 비교합니다.
- Marketing Version이 해당 앱 버전과 일치하는지 확인합니다.
- Build Number가 이미 업로드된 값과 중복되지 않는지 확인합니다.
- Distribution 인증서와 Provisioning Profile의 용도가 배포 목적에 맞는지 봅니다.
- 앱 확장과 위젯의 Bundle ID, Team, Profile을 각각 확인합니다.
- Entitlements에 포함된 기능이 App ID와 프로파일에서 허용되는지 확인합니다.
Invalid Binary가 표시되면 애플이 바이너리를 받았지만 업로드 요구 사항을 충족하지 못했다는 의미입니다. 이때 주 앱만 다시 서명하면 확장 기능에서 같은 오류가 반복될 수 있습니다. 빌드 상세 화면의 오류와 경고를 모두 저장한 뒤 구성 요소별로 비교해야 합니다.
경험상 로그에서 Bundle ID, Team ID, 인증서 이름, 프로파일 이름을 그대로 공개하면 계정 구조가 노출될 수 있습니다. 공유용 로그에서는
com.example.app,TEAM_ID,KEY_ID,/path/to/archive처럼 치환하고 개인 키나 토큰은 절대 포함하지 마십시오.
Organizer, Transporter, 자동화 로그를 나누어 봅니다
업로드 도구는 역할이 다릅니다. Organizer는 아카이브와 검증 결과를 함께 보기 좋고, Transporter는 전송 진행과 배달 기록을 확인하기 쉽습니다. App Store Connect API를 이용한 자동화에서는 JWT 인증과 API 키 권한이 별도의 실패 원인이 됩니다. 애플은 Transporter와 API를 통한 바이너리 업로드를 공식 지원합니다. (애플의 업로드 방식 안내)
Organizer에서 확인할 항목
- 아카이브가 실제로 생성되었는지
- Validate 단계에서 나온 오류 코드
- 업로드 대상 앱과 버전
- Delivery Log의 마지막 성공 단계
- 인증서와 프로파일 관련 경고
Transporter에서 확인할 항목
- 전송이 시작되기 전에 인증이 거부됐는지
- 파일 전송 중 연결이 끊겼는지
- 전송은 끝났지만 애플 처리 단계에서 실패했는지
- 같은 아카이브가 이미 접수됐는지
자동화에서 확인할 항목
- API 키가 폐기되었거나 만료된 환경 변수가 없는지
- 키의 역할이 해당 작업에 충분한지
- 비밀 키 파일의 권한과 경로가 올바른지
- 스크립트가 실패해도 종료 코드를 정상적으로 반환하는지
- 로그에 개인 키와 JWT가 출력되지 않는지
Transporter 업로드가 네트워크 중단으로 끝났다면 먼저 동일한 아카이브를 재전송할 수 있습니다. 반대로 패키지 내용, 서명, 식별자 오류가 보고됐다면 Transporter만 반복 실행하지 말고 Organizer에서 다시 Validate해야 합니다.
TestFlight에 보이지 않는 빌드의 상태를 판별합니다
빌드가 사라진 것이 아니라 아직 처리 중일 수 있습니다. App Store Connect의 빌드 업로드 기록과 TestFlight의 빌드 목록을 따로 확인해야 합니다.
Processing: 애플이 업로드 파일을 처리하는 중입니다.Complete: 처리에 성공했고 테스트에 사용할 수 있습니다.Failed: 처리가 끝났지만 오류가 발생했습니다.Invalid Binary: 현재 업로드 요구 사항을 충족하지 못했습니다.Missing Compliance: 수출 규정 정보를 추가해야 합니다.
Processing이 24시간을 넘기면 애플 문서가 안내하는 지원 요청 기준에 해당할 수 있습니다. 그 전에는 같은 빌드를 여러 번 올리지 말고 업로드 시각, 빌드 번호, 앱 기록, 계정 역할을 정리하십시오.
Missing Compliance라면 TestFlight의 해당 빌드에서 Manage를 선택해 암호화 사용 여부에 답하거나, 이미 승인된 문서를 제출해야 합니다. 이것은 바이너리를 다시 만드는 문제와 다를 수 있습니다. ([TestFlight 수출 규정 정보 안내](https://developer.apple.com/help/app-store-connect/test-a-beta-version/provide-export-compliance-information-for-beta-builds/?utm_source=openai))
버전 화면에서 빌드를 선택할 수 없는 경우에는 다음을 확인합니다.
- 올린 빌드의 Bundle ID가 현재 앱 기록과 같은지 확인합니다.
- 앱 버전의 플랫폼이 iOS로 설정되어 있는지 확인합니다.
- 빌드 상태가
Complete인지 확인합니다. - 필요한 수출 규정 질문에 답했는지 확인합니다.
- 해당 계정 역할에 버전과 빌드를 관리할 권한이 있는지 확인합니다.
재발 방지를 위한 배포 환경 점검 순서
한 번 해결하는 것보다 다음 업로드에서 같은 문제가 재현되지 않게 만드는 편이 중요합니다.
- 도구 고정: 사용할 Xcode 26 버전과 macOS 버전을 문서에 기록합니다.
- 소스 고정: 커밋 아이디, 의존성 버전, 빌드 설정을 함께 저장합니다.
- 아카이브 생성: 주 앱과 모든 확장 기능을 포함해 Archive합니다.
- 메타데이터 확인: Bundle ID, 버전, 빌드 번호, Team을 기록합니다.
- 로컬 검증: Organizer에서 Validate를 먼저 실행합니다.
- 전송 실행: Organizer, Transporter, 자동화 명령 중 하나를 선택하고 도구를 섞지 않습니다.
- 백그라운드 확인: App Store Connect에서 Processing, Failed, Complete 상태를 확인합니다.
- TestFlight 확인: 빌드 번호와 처리 완료 여부를 확인합니다.
- 로그 보관: 시간, Xcode 버전, 전송 도구, 오류 코드, 복구 조치를 남깁니다.
선택 점수
각 항목에 해당하면 1점을 더합니다.
- 매번 같은 Xcode와 SDK를 사용합니다.
- 업로드 전 Validate 로그를 저장합니다.
- 전송과 처리 상태를 구분해 기록합니다.
- API 키와 개인 키를 스크립트에서 분리했습니다.
- 원격 접속이 끊겨도 업로드 작업이 중단되지 않는 환경이 있습니다.
로컬 맥의 장점은 디버깅과 기기 연결입니다. 그러나 네트워크 단절, 저장 공간 부족, 운영체제 업데이트, 개인 컴퓨터 종료는 반복 업로드 작업의 장애 요인이 됩니다. 원격 맥은 물리 기기 연결이 필요한 테스트에는 적합하지 않을 수 있지만, Archive와 업로드를 같은 환경에서 반복해야 할 때는 더 일정한 실행 조건을 만들 수 있습니다. 필요한 경우 MACGPU의 맥 원격 이용 환경과 맥 미니 렌탈 선택지를 비교한 뒤 판단하십시오.
결론적으로 현재 로컬 환경이 안정적이고 직접 기기 테스트가 많다면 그대로 사용하는 편이 낫습니다. 반대로 업로드 때마다 네트워크가 끊기거나 macOS와 Xcode 구성이 바뀌고, 매주 여러 번 같은 배포 작업을 반복한다면 상시 원격 맥이 더 적합할 수 있습니다. 로컬 장비를 새로 구매하는 방식은 초기 비용과 관리 부담이 생기고, 일반 클라우드 환경은 Xcode와 서명 작업에서 제약이 생길 수 있습니다. 이런 경우 MACGPU의 원격 맥을 임시 배포 환경으로 먼저 검증한 뒤, 반복 작업이 확인될 때 지속 이용으로 전환하는 접근이 현실적입니다.
자주 발생하는 업로드 문제를 마지막으로 확인합니다
Xcode 업로드 오류의 로그 위치
Organizer에서 해당 아카이브를 선택하고 Validate 또는 Distribute 과정의 상세 로그를 엽니다. 업로드 도중 중단됐다면 Transporter의 배달 기록도 확인해야 합니다. 자동화라면 명령 실행 시각, 실제 Xcode 경로, 아카이브 경로, 빌드 번호, 종료 코드를 한 파일에 남겨야 어느 단계에서 실패했는지 재현할 수 있습니다.
업로드 완료 후 TestFlight에 보이지 않는 경우
먼저 App Store Connect의 빌드 상태가 Processing인지 확인합니다. 처리 중이라면 업로드 파일이 접수된 것이므로 즉시 새 빌드를 만들 필요가 없습니다. 상태가 Complete인데도 보이지 않으면 Bundle ID, 앱 기록, 플랫폼, 수출 규정 정보와 계정 역할을 확인해야 합니다.
Invalid Binary가 반복되는 경우
주 앱의 서명만 고쳐서는 해결되지 않을 수 있습니다. 위젯, 앱 확장, 알림 서비스처럼 함께 포함된 구성 요소를 각각 점검해야 합니다. 오류 상세에 식별자, 권한, SDK, 서명 문제가 함께 나타나는지 확인한 뒤 새 아카이브를 생성합니다.
Transporter 중단 뒤 재패키징 여부
전송 중 네트워크가 끊겼고 파일 검증 오류가 없다면 같은 아카이브를 다시 보내는 것이 먼저입니다. 파일 손상, 서명 불일치, Bundle ID 오류가 보고됐다면 재전송이 아니라 Organizer의 Validate부터 다시 실행해야 합니다.
Processing이 오래 지속되는 경우
Processing이 24시간 안에 끝나지 않는다고 같은 빌드를 반복해서 올리면 문제를 더 복잡하게 만들 수 있습니다. 업로드 시각과 빌드 번호를 기록하고, 상태 상세와 계정의 알림을 확인합니다. 24시간이 지난 뒤에도 변화가 없다면 애플 지원 요청에 빌드 식별 정보와 탈취되지 않은 로그 요약을 첨부합니다.
문제가 불안정한 로컬 네트워크나 매번 달라지는 macOS 환경에서 발생한다면, 현재 맥을 계속 고치는 것보다 배포 작업을 고정된 환경으로 옮기는 편이 합리적일 수 있습니다. 직접 기기 테스트와 즉시 디버깅이 많다면 로컬 맥을 유지하십시오. 반대로 반복적인 Archive와 업로드가 중심이고, 장시간 켜 둔 배포 환경이 필요하다면 MACGPU의 원격 맥 환경을 먼저 시험한 뒤 임시 이용과 지속 이용 중 하나를 선택하는 방식이 안전합니다.