Apple은 업로드된 빌드가 App Store Connect에 나타나기 전에 처리된다고 안내합니다. Apple의 빌드 업로드 안내를 기준으로 보면, CI의 업로드 성공은 테스트 가능 상태와 다릅니다. 먼저 App Store Connect에서 빌드 상태를 확인하고, Apple 처리와 빌드 자격, 테스트 그룹 배포 순으로 원인을 좁히세요. 지연만 보고 CI를 다시 실행하거나 서명 자산을 바꾸지는 마세요.
기업 IT 또는 배포 책임자라면 업로드 후 상태 확인과 담당자 호출 절차를 정해야 합니다.
CI 플랫폼 엔지니어라면 실패 지점이 맥 빌드, 업로드, Apple 처리 중 어디인지 구분해야 합니다.
QA 또는 테스트 책임자라면 빌드가 올바른 테스트 그룹에 배정됐는지 확인해야 합니다.
SECTION 01 TestFlight CI 업로드 결과와 테스트 가능 상태의 경계
릴리스 흐름은 다음 단계로 나눠 봐야 합니다.
- CI 빌드 및 업로드: 아카이브와 업로드 도구가 반환한 결과, 전달 로그를 확인합니다. 전송 작업이 성공했더라도 다음 단계의 처리가 끝났다는 뜻은 아닙니다.
- App Store Connect 처리: 업로드된 빌드가 처리되고, Apple이 표시하는 빌드 상태가 갱신되는 단계입니다. Apple의 빌드 상태 안내에서 상태 의미를 확인하세요.
- TestFlight 배포 및 설치: 빌드가 테스트에 사용할 수 있는 상태인지 확인한 뒤 테스트 그룹과 테스터 접근을 점검합니다. TestFlight 개요는 테스트 흐름과 관리 항목을 설명합니다.
따라서 CI 작업의 초록색 결과만으로 QA에 테스트를 시작하라고 알리면 안 됩니다. 처음 할 일은 새 빌드 생성이 아니라 해당 실행의 빌드 기록과 전달 로그를 찾아, App Store Connect에 동일한 산출물이 접수됐는지 확인하는 것입니다. 빌드와 메타데이터 화면 안내를 참고해 앱과 빌드 정보를 대조하세요.
SECTION 02 Apple 처리 상태 확인
상태를 볼 때는 앱 이름만 검색하지 말고 플랫폼, 버전, 빌드 번호를 함께 확인하세요. 목록에서 찾은 빌드의 현재 상태를 기록하고, 그 상태가 CI 결과와 같은 산출물을 가리키는지 비교해야 합니다. Apple은 업로드 상태와 처리된 빌드 상태를 별도로 설명하므로, 업로드 상태 안내와 빌드 상태 안내를 각각 확인하세요.
처리 중이라면 업로드 명령의 종료 결과만으로 완료 여부를 판단하지 마세요. 처리 완료 시간을 임의의 서비스 수준 목표처럼 약속하지 말고, 팀이 정한 확인 주기와 담당자 호출 기준을 적용하세요. 화면에 오류나 추가 조치 안내가 보이면 해당 내용을 저장해 다음 조사에 넘깁니다.
상태가 바뀌지 않는다는 이유만으로 같은 산출물을 계속 올리면 기록이 복잡해지고, 어떤 업로드가 테스트 대상인지 혼동할 수 있습니다. 기존 빌드의 상태와 로그를 먼저 보존하세요.
SECTION 03 빌드 자격과 Invalid Binary 구분
App Store Connect에 빌드가 표시되지만 테스트에 사용할 수 없다면, 업로드 단계의 실패와 빌드 자격 문제를 나눠야 합니다. Apple이 표시하는 Invalid Binary 같은 상태는 단순히 테스터에게 배포되지 않았다는 뜻과 같지 않습니다. 구체적인 원인은 현재 화면의 오류와 Apple의 업로드 요구 사항을 기준으로 확인하세요.
기록할 항목은 다음과 같습니다.
- 앱의 식별 정보와 대상 플랫폼
- 버전 및 빌드 번호
- CI 실행 기록과 업로드 도구의 결과
- 전달 로그에서 확인한 오류 또는 완료 정보
- App Store Connect에 표시된 빌드 상태와 오류 문구
여기서 앱 식별자나 버전 정보가 예상과 다르면, 다른 앱 또는 다른 빌드를 확인하고 있을 가능성부터 검토하세요. 오류가 아카이브의 자격이나 업로드 요구 사항을 가리킬 때는 원인을 수정한 뒤 새 산출물을 만들어 전달합니다. 반대로 Apple 처리가 진행 중인데 같은 산출물을 다시 제출하는 것은 문제 해결과 다릅니다.
SECTION 04 테스트 그룹과 테스터 접근 점검
빌드가 처리됐더라도 테스트 그룹에 연결되지 않았거나 테스터가 초대를 받지 못했다면 설치할 수 없습니다. 먼저 대상 플랫폼과 테스트 목적에 맞는 빌드인지 확인한 다음, 그 빌드가 올바른 그룹에 배정됐는지 살펴보세요.
내부 테스트와 외부 테스트는 진행 조건이 같다고 가정하면 안 됩니다. 그룹 유형에 따라 필요한 배정 및 검토 흐름을 App Store Connect 화면과 Apple의 최신 안내에서 확인하세요. Apple의 빌드에 테스터 추가 안내와 내부 테스터 안내는 그룹 및 초대 확인에 참고할 수 있습니다.
그룹과 빌드 연결이 맞다면 테스터 초대 상태, 사용 중인 계정, 테스트 앱에 표시되는 안내를 확인하세요. 특정 기기나 네트워크를 원인으로 지목하기 전에 테스터 화면에 실제로 나타나는 메시지를 기록해야 합니다. 이 순서를 지키면 맥 CI 문제와 계정 또는 배포 문제를 섞지 않고 조사할 수 있습니다.
SECTION 05 CI 재시도와 증거 보관 기준
아래 항목을 위에서부터 확인하고, 처음 해당하는 조건에 맞춰 조치하세요. 체크한 단계가 확인되지 않았다면 재시도를 보류하고 상태나 로그를 더 수집합니다.
- [ ] App Store Connect에서 빌드가 보이고 처리가 진행 중입니다. 새 빌드를 만들지 말고 현재 상태와 화면의 오류 안내를 기록합니다. 상태가 바뀌지 않거나 추가 조치가 표시되면 팀의 담당자 확인 절차로 넘깁니다.
- [ ] 업로드 도구가 실패했고 전달 로그에도 완료 증거가 없습니다. 로그에서 네트워크, 인증 또는 전송 실패를 확인합니다. 원인을 확인한 뒤 업로드 단계의 재시도를 검토합니다.
- [ ] Apple이 빌드 자격 오류를 표시합니다. 같은 산출물을 반복 제출하지 말고 오류 문구와 아카이브 정보를 확인합니다. 수정이 필요하면 변경을 반영한 새 산출물을 만들어 전달합니다.
- [ ] 빌드가 테스트 가능한 상태지만 테스터가 찾거나 설치하지 못합니다. CI를 재실행하지 말고 빌드와 테스트 그룹의 연결, 초대, 계정 및 테스터 안내를 점검합니다.
- [ ] 위 조건 중 어느 것도 확인되지 않았습니다. 재시도를 보류하고 빌드 식별 정보, CI 결과, 전달 로그와 App Store Connect 상태가 같은 산출물을 가리키는지 대조한 뒤 담당자에게 전달합니다.
파이프라인에는 빌드 식별 정보, 업로드 도구 결과, 전달 로그를 찾을 수 있는 위치, App Store Connect의 최종 상태를 남기세요. 실제 릴리스 작업으로 아카이브 생성부터 테스트 그룹에서 빌드를 확인하는 단계까지 검증하고, 어느 단계에서 증거가 끊기는지 확인해야 합니다. 같은 실패가 반복될 때도 이 기록이 있어야 맥 노드 환경을 조정할지, Apple 처리나 그룹 설정을 담당자에게 넘길지 판단할 수 있습니다.
SECTION 06 자주 묻는 문제
CI에서는 성공인데 빌드가 보이지 않는 경우
업로드 결과와 App Store Connect 처리는 별도 단계입니다. CI 실행과 전달 로그에서 대상 빌드를 식별한 다음, App Store Connect에서 앱, 플랫폼, 버전, 빌드 번호가 일치하는 항목을 찾으세요. 처리 중이거나 오류가 표시되면 상태를 기록하고, 근거 없이 새 빌드를 올리지 마세요.
처리 중 상태에서 재실행을 검토하는 기준
처리 중이라는 표시만으로 CI를 다시 돌리지 마세요. 기존 빌드가 접수됐는지와 업로드 도구의 결과를 확인하고, Apple 화면에 처리 실패나 추가 조치 안내가 있는지 살펴보세요. 재시도는 업로드 단계의 실패가 로그로 확인됐을 때 검토하고, 그 외에는 팀의 담당자 확인 절차를 따르세요.
처리된 빌드를 테스터가 설치하지 못하는 경우
먼저 해당 빌드가 테스트할 수 있는 상태인지, 맞는 플랫폼과 테스트 그룹에 연결됐는지 확인하세요. 다음으로 초대가 전달됐는지와 테스터가 올바른 계정으로 접근하는지 살펴봅니다. 설치 화면의 안내도 기록하세요. 이 문제는 빌드 업로드 재시도보다 그룹 배정이나 테스터 접근 확인이 우선일 수 있습니다.
업로드 실패, Invalid Binary, 배포 문제의 구별
업로드 도구와 전달 로그에 실패가 남으면 업로드 경로를 조사하세요. Apple이 산출물을 받았지만 Invalid Binary를 표시하면 해당 오류와 빌드 정보를 기준으로 자격 문제를 살펴봅니다. 빌드가 처리됐는데 테스트 그룹에서 보이지 않거나 설치할 수 없다면 그룹 연결, 초대, 테스터 안내를 확인하세요. 서로 다른 단계의 오류를 같은 재시도로 해결하려 하지 마세요.
현재 맥 CI를 자체 운영하면 장비 구매 비용이 먼저 들고, 운영체제와 개발 도구 유지 관리도 팀이 맡아야 합니다. 공유 노드의 자원이 겹치거나 장비에 장애가 생기면 복구와 작업 분리도 직접 설계해야 합니다. 장기간 높은 부하를 꾸준히 처리하거나 물리 인터페이스가 필요한 팀이라면 자체 장비가 더 적합할 수 있습니다. 반면 출시 점검이나 장애 재현을 위해 별도 맥 환경을 잠시 확보하려는 경우에는 VPSNIX 원격 맥을 대안으로 검토할 수 있습니다. 도움말 센터에서 이용 환경을 확인하고, 요금 안내를 현재 자체 운영 비용과 비교해 필요 기간과 운영 책임에 맞는지 판단하세요.
SECTION 07 자주 묻는 질문 FAQ
CI에서 업로드가 성공했는데 App Store Connect에서 빌드가 보이지 않는 이유는 무엇인가요?
업로드 도구의 성공 결과는 전달 작업의 결과이지, 빌드가 Apple의 처리를 마치고 테스트에 공개됐다는 뜻은 아닙니다. 먼저 CI 결과와 전달 로그를 보관하고 App Store Connect의 빌드 목록에서 앱, 플랫폼, 버전 정보를 확인하세요. 상태가 처리 중이라면 새 아카이브를 만들기보다 상태가 바뀌는지 확인하고, 화면에 표시된 오류가 있을 때 그 내용을 기준으로 대응합니다.
App Store Connect에서 처리 중인 빌드를 CI에서 다시 올려야 하나요?
처리 중이라는 상태만으로 재업로드를 결정하지 마세요. Apple은 업로드된 빌드가 처리된 뒤 App Store Connect에 표시된다고 안내하므로, 먼저 기존 빌드의 상태와 업로드 도구 결과, 전달 로그를 서로 대조해야 합니다. 오류나 처리 실패가 확인되지 않았다면 같은 산출물을 반복 제출하지 말고 팀의 대기 및 담당자 확인 절차를 따르세요.
처리가 끝난 빌드를 테스트 그룹에서 찾을 수 없으면 무엇부터 확인하나요?
빌드가 실제로 테스트 가능한 상태인지 확인한 다음, 대상 플랫폼과 앱이 맞는지 살펴보세요. 이어서 해당 빌드가 의도한 내부 또는 외부 테스트 그룹에 배정됐는지, 테스트 초대가 대상자에게 전달됐는지 확인합니다. 빌드가 목록에 있다는 사실만으로 모든 테스터에게 접근 권한이 생기는 것은 아니므로, 테스터 계정과 초대 상태도 함께 대조해야 합니다.
IPA 업로드 오류와 Invalid Binary, TestFlight 배포 문제는 어떻게 구별하나요?
CI의 업로드 결과와 전달 로그에서 파일 전송 단계의 오류가 있는지 먼저 확인하세요. Apple이 빌드를 받았지만 Invalid Binary 같은 상태를 표시한다면, 업로드 자체의 재시도보다 화면의 오류와 앱 식별자, 버전, 빌드 번호를 확인해 빌드 자격 문제를 조사해야 합니다. 빌드가 정상적으로 처리됐는데 테스터가 보거나 설치하지 못한다면 테스트 그룹 배정과 초대 등 배포 단계로 범위를 옮기세요.