Xcode 27 iOS 앱 출시 전 어떻게 검수하나요? 2026 체크리스트

Archive 성공은 출시 완료가 아닙니다. Xcode 27 iOS 앱 출시 전 검수는 신원 정보, 산출물, 서명, 업로드 상태, App Store Connect 연결까지 모두 통과해야 하며, 마지막에는 실제 TestFlight 설치 또는 심사 제출용 빌드로 확인해야 합니다.

이 글은 처음 앱을 제출하는 독립 개발자, 원격 맥 빌드 환경을 관리하는 개발자, 스크립트나 CI로 자동 업로드하는 소규모 팀을 위한 안내서입니다. 단순히 Xcode에서 빌드가 끝났는지가 아니라, 각 단계에서 어떤 증거를 확인하고 언제 작업을 멈춰야 하는지에 초점을 둡니다.

출시 완료의 판정 기준

iOS 앱 출시는 한 번의 성공 메시지로 판정하지 않습니다. Archive가 만들어졌는지, 배포용 IPA가 생성됐는지, 업로드가 끝났는지, App Store Connect의 처리가 완료됐는지, TestFlight에서 사용할 수 있는지, 심사 제출용 빌드로 선택되는지를 나누어 확인해야 합니다.

Apple의 앱 배포 준비 문서는 배포 전에 앱의 설정과 산출물을 확인하도록 안내합니다. Xcode 배포 문서 역시 Archive와 배포 방식이 서로 다른 검증 단계임을 전제로 합니다.

따라서 “Archive가 성공했다”는 문구는 산출물 생성 단계의 통과만 의미합니다. App Store Connect에서 처리된 빌드가 올바른 앱 버전에 연결되고, TestFlight 또는 심사 제출 화면에서 선택될 때 비로소 다음 단계로 이동할 수 있습니다.

앱 신원과 버전 정보

Bundle ID와 Target 확인

먼저 최종 Archive에서 실제 Bundle ID를 확인해야 합니다. Xcode 프로젝트 설정에 표시된 값만 믿으면 안 됩니다. 여러 Target, 환경별 설정 파일, 스킴별 변수 때문에 화면의 설정과 실제 산출물의 값이 달라질 수 있기 때문입니다.

다음 항목은 서로 같은 앱을 가리켜야 합니다.

• [ ] 최종 Archive의 Bundle ID가 App Store Connect 앱 기록과 일치합니다.
• [ ] Archive에 포함된 Target이 출시 대상 Target과 일치합니다.
• [ ] 올바른 Team으로 서명되어 있습니다.
• [ ] iOS용 Release Archive이며 시뮬레이터 산출물이 아닙니다.
• [ ] 앱 이름과 표시 대상이 테스트 앱이나 개발용 앱으로 남아 있지 않습니다.

Apple은 새 앱 기록을 추가하는 절차에서 Bundle ID와 앱 기록의 연결을 요구합니다. 따라서 Bundle ID가 다르면 업로드 자체가 성공하더라도 예상한 앱에 표시되지 않는 문제가 생길 수 있습니다.

version number와 build string

iOS 앱의 버전 정보는 사용자에게 표시되는 version number와 내부 빌드를 구분해야 합니다. 같은 버전으로 수정된 빌드를 추가할 때는 build string을 바꾸고, 사용자에게 새 버전으로 제공할 때는 version number도 새 값으로 관리합니다.

최종 Archive의 실제 값은 Xcode의 General 화면, 빌드 설정, 자동화 스크립트가 말하는 값보다 우선합니다. 다음처럼 확인합니다.

• Archive를 열어 실제 version number를 기록합니다.
• 같은 Archive의 build string을 기록합니다.
• App Store Connect에서 목표 버전의 빌드 목록을 엽니다.
• 해당 값이 기대한 버전 아래에 연결되는지 확인합니다.
• 이미 사용된 build string을 다시 보내려 하지 않습니다.

새 버전을 만들지, 기존 버전에 빌드를 추가할지는 앱 기록의 상태로 판단해야 합니다. 아직 새 버전이 없다면 새 버전을 만들고, 같은 버전의 오류 수정이라면 새로운 build string으로 업로드합니다. 업로드에 실패한 산출물의 숫자를 그대로 재사용할 수 있다고 가정하지 말고, 플랫폼에 해당 값이 등록됐는지 먼저 확인해야 합니다.

Archive와 서명 산출물

Xcode 27 Archive 성공 뒤의 확인

Xcode 27에서 Archive가 성공했다면 Organizer에서 해당 Archive의 앱 식별자, 버전, 빌드, Team, 배포 목적을 확인합니다. Debug 빌드나 시뮬레이터 빌드는 이 검사를 대신할 수 없습니다. Release Archive와 배포용 IPA가 실제로 같은 소스와 설정에서 만들어졌는지도 기록해야 합니다.

Apple의 배포용 앱 준비 안내는 배포 과정에서 서명과 앱 산출물을 함께 점검하도록 설명합니다. 그러므로 Archive만 보관하고 IPA나 dSYM을 별도로 관리하지 않는 방식은 자동화 환경에서 추적성이 약합니다.

• [ ] Archive 파일을 보관했습니다.
• [ ] 배포용 내보내기 결과인 IPA를 보관했습니다.
• [ ] 해당 빌드에서 생성된 dSYM을 보관했습니다.
• [ ] IPA의 Bundle ID와 version number를 확인했습니다.
• [ ] IPA의 build string이 Archive와 같습니다.
• [ ] Entitlements가 출시 목적에 필요한 권한과 일치합니다.
• [ ] Debug 서명이나 개발용 Provisioning Profile이 섞이지 않았습니다.

dSYM은 충돌 분석에 필요한 파일이므로 IPA와 다른 빌드에서 생성된 것을 보관하면 출시 후 오류 분석이 어려워집니다. 자동화 스크립트가 Archive를 한 번 만들고, 별도의 명령으로 다시 빌드해 IPA를 만드는 구조라면 두 산출물이 같은 소스와 빌드 설정을 사용했는지 확인해야 합니다.

주의: 키체인에 인증서가 있다는 사실만으로 서명이 준비됐다고 볼 수 없습니다. 비대화형 스크립트가 올바른 키체인에 접근하는지, Provisioning Profile이 해당 Bundle ID와 배포 목적을 지원하는지까지 확인해야 합니다.

원격 맥 빌드 환경

원격 맥 빌드에서는 사람이 화면을 보며 승인하는 단계가 누락되기 쉽습니다. 키체인 잠금, 인증서 접근 권한, 환경 변수, 임시 파일 정리, SSH 세션 종료가 모두 배포 결과에 영향을 줄 수 있습니다.

원격 환경을 점검할 때는 다음 항목을 별도로 기록합니다.

• Xcode 27 정식 버전인지, Xcode 27.2 Beta인지 구분합니다.
• 스크립트가 기대하는 Xcode 경로와 실제 선택된 개발자 도구가 같은지 확인합니다.
• 서명 인증서와 Provisioning Profile의 보관 위치와 접근 방식을 기록합니다.
• 비밀 값이 로그에 평문으로 남지 않는지 확인합니다.
• SSH나 원격 화면 연결이 끊겨도 Archive 결과와 로그가 보존되는지 확인합니다.
• 재연결 후 같은 작업을 중복 실행하지 않도록 실행 상태를 확인합니다.

Apple의 Xcode 출시 기록에서 정식 버전과 시험 버전의 상태를 먼저 확인해야 합니다. Xcode 27.2 Beta에서 동작한 설정을 Xcode 27 정식 버전의 확정된 동작으로 간주하면 안 됩니다.

업로드와 플랫폼 처리 상태

App Store Connect 업로드 뒤의 판정

Transporter나 명령줄 도구가 성공 코드로 종료됐다는 사실은 파일 전달이 끝났다는 뜻에 가깝습니다. App Store Connect가 빌드를 처리하고, 오류와 경고를 반영하고, 특정 앱 버전에 연결할 때까지는 출시 검수가 끝나지 않습니다.

Apple의 빌드 업로드 안내는 업로드 뒤 플랫폼에서 빌드가 처리되는 단계를 구분합니다. 따라서 로컬 로그만 보지 말고 App Store Connect의 빌드 화면에서 다음 값을 다시 확인해야 합니다.

• 업로드된 시간과 대상 앱이 예상과 같은지 확인합니다.
• version number와 build string을 다시 대조합니다.
• Processing 중인지, 완료됐는지, 오류가 발생했는지 확인합니다.
• 경고가 단순 안내인지, 제출을 막는 문제인지 구분합니다.
• 같은 빌드를 다른 버전에 연결하려고 하지 않았는지 확인합니다.

Processing이 오래 지속된다고 해서 즉시 같은 파일을 반복 업로드하면 안 됩니다. 먼저 플랫폼에 build string이 이미 표시되는지 확인하고, 표시된다면 오류 내용과 처리 상태를 기준으로 다음 행동을 정해야 합니다. 빌드가 실패했다면 로그의 오류를 수정한 뒤 새로운 산출물을 만들어야 하며, 기존 파일 이름만 바꾸어 다시 보내는 방식은 검수 근거가 되지 않습니다.

App Store Connect에서 빌드와 메타데이터를 확인하는 방법도 함께 확인하면 플랫폼에 등록된 실제 값을 기준으로 판단할 수 있습니다.

TestFlight와 심사 연결

Complete 뒤에 확인할 항목

App Store Connect에서 빌드 상태가 Complete으로 보이면 처리가 끝난 것입니다. 그러나 곧바로 심사 제출이 가능하다는 뜻은 아닙니다. 빌드가 올바른 플랫폼 버전 아래에 표시되고, 제출용 빌드로 선택되며, 수출 규정이나 필수 정보에 막히지 않는지 추가로 확인해야 합니다.

TestFlight 검수는 다음 순서로 진행합니다.

• [ ] 목표 앱 버전의 빌드 목록에서 올바른 build string을 찾습니다.
• [ ] 해당 빌드를 TestFlight 내부 테스트 또는 외부 테스트 대상으로 선택할 수 있는지 확인합니다.
• [ ] 실제 기기에 설치해 실행과 업데이트를 확인합니다.
• [ ] Missing Compliance와 수출 규정 관련 질문을 확인합니다.
• [ ] 앱이 기대한 환경 설정과 API 서버를 사용하는지 확인합니다.
• [ ] 심사 제출 화면에서 해당 빌드를 선택할 수 있는지 확인합니다.
• [ ] 제출을 막는 누락 정보와 경고가 없는지 확인합니다.

TestFlight에서 설치가 된다는 사실만으로 심사 제출이 보장되는 것도 아닙니다. 반대로 App Store Connect에서 Complete으로 표시되더라도 실제 기기에서 시작 화면, 로그인, 결제, 네트워크 연결 같은 핵심 경로를 확인하지 않았다면 출시 검수가 부족합니다.

Apple의 제출할 빌드를 선택하는 안내는 플랫폼에서 사용 가능한 빌드를 선택하는 절차를 설명합니다. 이 화면에서 빌드를 선택할 수 있는지 확인하는 것이 Complete 이후의 중요한 판정 기준입니다.

원격 맥 운영 판단

원격 맥은 반복적인 Archive, IPA 내보내기, 업로드, 로그 보관을 맡기기에 적합할 수 있습니다. 다만 App Store Connect의 최종 상태와 TestFlight 설치 결과를 대신 확인하는 도구는 아닙니다. 원격 환경에서 자동화할수록 사람의 마지막 확인 지점을 명확히 남겨야 합니다.

다음 조건이면 원격 맥 빌드 환경을 계속 사용하는 편이 합리적입니다.

• 반복적으로 Archive와 업로드를 수행합니다.
• 개발자의 개인 맥을 항상 켜 두기 어렵습니다.
• SSH, 스크립트, CI를 이용해 동일한 배포 절차를 재현해야 합니다.
• 서명 자료와 로그를 정해진 위치에서 관리할 수 있습니다.
• 실패한 작업을 중복 실행하지 않고 복구할 운영 절차가 있습니다.

반대로 가끔 한 번 제출하는 앱이라면 먼저 필요한 기간만 원격 환경을 사용하는 방식이 부담이 적습니다. 지속적인 배포가 필요하다면 RUVCLOUD의 맥 원격 사용 안내에서 접근 방식과 사용 조건을 확인하고, 비용은 한국어 요금 안내에서 별도로 비교하는 편이 좋습니다.

이번 체크리스트의 핵심은 Xcode 27 Archive 성공을 최종 결과로 착각하지 않는 것입니다. 최종 Archive의 신원 정보와 버전 값을 확인하고, 같은 산출물의 서명과 dSYM을 검증한 뒤, App Store Connect의 Processing과 Complete 상태를 다시 확인해야 합니다. 마지막으로 TestFlight 설치 또는 제출용 빌드 선택까지 끝나야 실제 출시 준비가 완료됩니다.

현재 개인 맥만 사용하는 방식은 장비 전원, 로컬 디스크, 키체인 상태, Xcode 설치 버전에 의존하고, Windows나 Linux에서 진행하는 방식은 macOS 전용 배포 도구를 직접 실행할 수 없다는 제약이 있습니다. 반복 Archive와 업로드, 실패 후 복구가 필요한 개발자라면 RUVCLOUD의 원격 맥을 임시 또는 지속적인 실행 환경으로 비교해 볼 수 있습니다. 반대로 제출 빈도가 낮거나 물리적인 기기 연결이 반드시 필요한 작업이라면 먼저 단기 사용으로 적합성을 확인하는 편이 안전합니다.