xcodebuild exit code 65가 보이면 먼저 수정 명령을 실행하지 말고 전체 로그와 xcresult를 보존해야 합니다. 이 상태값만으로 서명 오류인지 컴파일 오류인지 판단할 수 없으므로, 빌드 단계와 테스트 단계, 아카이브와 내보내기 단계를 나눠 첫 번째 유효한 오류부터 추적해야 합니다.
이 글은 다음 개발자를 위한 안내입니다.
- 그래픽 환경에서는 빌드되지만 SSH 또는 CI에서 실패하는 독립 개발자
- 시뮬레이터 자동 테스트 중 대상 장치나 앱 시작 문제를 겪는 소규모 팀
- 원격 맥에서 아카이브와 서명을 실행하는 배포 담당자
[ SECTION_01 ] 실패 현장 보존
로그 마지막에 다음처럼 표시되는 경우가 많습니다.
** TEST FAILED **
xcodebuild: error: ...
Command PhaseScriptExecution failed
Process completed with exit code 65
마지막 줄의 65는 작업이 성공적으로 끝나지 않았다는 결과에 가깝습니다. 실제 원인은 앞부분의 컴파일 오류, 스크립트 실패, 테스트 실행 오류 또는 서명 오류일 수 있습니다. 따라서 로그 끝의 상태값만 보고 인증서를 교체하거나 캐시를 지우면 원인을 가릴 수 있습니다.
CI에서는 표준 출력과 표준 오류를 각각 보존하고, 실행 명령과 작업 디렉터리도 함께 남겨야 합니다. 테스트 결과는 -resultBundlePath로 결과 묶음에 저장할 수 있습니다. Apple은 테스트 실행 결과를 결과 묶음과 함께 해석하는 방법을 안내하고 있습니다. 테스트 실행 결과와 해석 방법을 기준으로 결과 파일을 보존합니다.
set -o pipefail
xcodebuild \
-workspace Sample.xcworkspace \
-scheme Sample \
-destination 'platform=iOS Simulator,id=REDACTED' \
test \
-resultBundlePath build/TestResult.xcresult \
2>&1 | tee build/xcodebuild.log
status=${PIPESTATUS[0]}
printf 'xcodebuild status: %s\n' "$status"
exit "$status"
프로젝트 이름, 사용자 이름, 경로, 번들 식별자, 팀 식별자, 장치 식별자는 CI 로그에서 가려야 합니다. 원격 환경을 외부에 공유할 때도 인증서 이름과 저장소 주소를 그대로 남기지 않는 편이 안전합니다.
CI에서 실패 로그와 xcresult를 함께 남기는 방법은 무엇인가요?
명령에 tee를 연결해 사람이 읽는 로그를 저장하고, 테스트 작업에는 결과 묶음 경로를 지정하면 됩니다. 빌드가 실패해도 결과 파일이 생성되는지 확인해야 합니다. 결과 묶음이 없다면 테스트 실행 전 단계에서 중단되었거나, 작업 디렉터리와 권한 설정이 잘못되었을 가능성이 있습니다.
[ SECTION_02 ] 프로젝트 입구와 Scheme 확인
그래픽 환경과 명령줄의 차이는 프로젝트 입구에서 시작되는 경우가 많습니다. 의존성 관리 후 실제 작업 입구가 작업 공간으로 바뀌었는데도 프로젝트 파일을 호출하면 다른 설정이 읽힐 수 있습니다.
먼저 다음을 분리해 확인합니다.
- 작업 공간을 써야 하는 프로젝트인지, 프로젝트 파일을 써야 하는지
- 호출한 Scheme이 실제로 존재하는지
- Scheme이 공유 상태인지
- 명령줄에서 읽은 구성과 그래픽 환경의 구성이 같은지
- 선택한 SDK와 Destination이 원격 맥에 설치되어 있는지
공유되지 않은 Scheme은 개발자 컴퓨터의 그래픽 환경에서는 보이지만 저장소를 새로 받은 CI에서는 보이지 않을 수 있습니다. Apple의 Scheme 사용자 설정 문서는 Scheme의 구성과 공유 방식을 확인하는 기준이 됩니다.
xcodebuild -list -workspace Sample.xcworkspace
xcodebuild -showBuildSettings \
-workspace Sample.xcworkspace \
-scheme Sample
두 환경에서 같은 명령을 실행하되 민감한 값은 가립니다. 출력된 구성 이름, SDK, 검색 경로가 다르면 코드보다 실행 환경을 먼저 고쳐야 합니다. 구성 파일을 사용하는 프로젝트라면 Build Configuration 파일 문서와 저장소의 구성 파일 경로를 함께 대조합니다.
그래픽 Xcode에서는 되는데 xcodebuild는 왜 실패하나요?
그래픽 Xcode가 선택한 Scheme, 구성, 장치와 명령줄이 선택한 값이 다를 수 있기 때문입니다. 특히 공유되지 않은 Scheme, 다른 작업 공간, 로그인 셸에서 빠진 환경 변수, SSH 세션의 다른 작업 디렉터리가 대표적인 차이입니다. 같은 커밋과 같은 명령을 두 세션에서 비교하면 프로젝트 문제와 실행 환경 문제를 나눌 수 있습니다.
[ SECTION_03 ] 의존성과 스크립트 단계
exit code 65가 소스 코드 자체를 뜻하는 것은 아닙니다. 로그의 첫 번째 오류가 다음 어느 구간에 있는지 표시해야 합니다.
- 패키지 해석 또는 저장소 인증
- Swift나 Objective-C 컴파일
- 리소스 처리
- 링크
- Run Script 실행
잠금 파일이 저장소에 포함되지 않았거나, 사설 저장소 인증이 SSH 세션에서 빠지면 의존성 단계에서 실패할 수 있습니다. 스크립트가 특정 셸 경로를 가정하거나 그래픽 로그인에서만 존재하는 환경 변수를 읽는 경우도 있습니다.
처음부터 모든 캐시를 삭제하는 방법은 권장되지 않습니다. 캐시 삭제로 증상이 사라져도 잠금 파일, 스크립트, 구성 차이가 남기 때문입니다. 먼저 같은 커밋을 새 작업 디렉터리에 받아서 재현합니다. 그 뒤에 필요한 범위만 정리합니다.
주의: 캐시 삭제, 의존성 재해석, 인증 정보 교체는 재현 조건을 바꿀 수 있습니다. 원본 로그를 보존한 뒤 한 가지 변경만 적용하고 결과를 기록해야 합니다.
[ SECTION_04 ] 시뮬레이터와 테스트 실행
테스트 작업에서는 제품을 만드는 단계와 테스트를 실행하는 단계를 분리해야 합니다. build-for-testing이 실패하면 컴파일이나 테스트 제품 생성 문제입니다. 이 단계가 성공하고 test-without-building에서 실패하면 장치 선택, 앱 시작, 테스트 서비스 또는 세션 문제일 가능성이 커집니다.
xcodebuild \
-workspace Sample.xcworkspace \
-scheme Sample \
-destination 'platform=iOS Simulator,id=REDACTED' \
build-for-testing
xcodebuild \
-workspace Sample.xcworkspace \
-scheme Sample \
-destination 'platform=iOS Simulator,id=REDACTED' \
test-without-building \
-resultBundlePath build/RunResult.xcresult
원격 맥에서는 다음 조건을 확인합니다.
- 요청한 운영 체제 대상이 실제로 설치되어 있는지
- 장치 식별자가 현재 환경에서 유효한지
- 시뮬레이터가 부팅된 상태인지
- 그래픽 로그인 없이도 테스트에 필요한 서비스가 시작되는지
- SSH와 CI에서 환경 변수가 동일한지
Apple의 테스트 환경 변수 참고 자료는 자동화 세션에서 읽히는 값을 확인할 때 사용할 수 있습니다. 테스트 작업을 단계별로 나누는 방식은 Xcode Cloud 작업 구성 문서의 흐름과도 맞습니다.
exit code 65가 서명 오류인지 컴파일 오류인지 어떻게 구분하나요?
로그의 첫 번째 유효한 오류와 실패 단계로 구분합니다. CompileSwift, 링크, 리소스 처리 항목이 먼저 나오면 프로젝트 빌드 영역을 조사합니다. CodeSign, 인증서, 프로비저닝 프로파일이 먼저 나오면 서명 영역을 조사합니다. 테스트 제품 생성 뒤 앱 시작이나 테스트 시간 초과가 나오면 서명보다 테스트 실행 환경을 먼저 확인해야 합니다.
[ SECTION_05 ] Archive와 서명 권한
Archive가 만들어졌는지와 내보내기가 성공했는지는 별개의 상태입니다. 다음 네 가지를 별도로 기록해야 합니다.
- 일반 Build 성공 여부
- Archive 생성 여부
- 코드 서명 성공 여부
- 내보내기 또는 업로드 성공 여부
키체인에 서명 인증서만 있고 개인 키가 없으면 서명이 완료되지 않습니다. 프로비저닝 프로파일의 앱 식별자와 팀 정보가 프로젝트와 맞지 않아도 실패합니다. Apple은 Mac 배포용 서명 코드 생성 절차와 프로비저닝 프로파일의 서명 구조를 각각 설명합니다.
SSH나 백그라운드 작업에서는 대화형 키체인 잠금 해제, 사용자 승인, 인증서 접근 권한이 자동으로 처리되지 않을 수 있습니다. 팀 인증서를 옮길 때는 팀 서명 인증서 공유 방법을 확인하고, 기존 인증서를 삭제하기 전에 영향을 받는 앱과 복구 방법을 기록해야 합니다.
Archive 과정을 스크립트로 바꾼 경우에는 Xcode Archive 과정 사용자 설정 문서도 대조합니다. 서명 자산을 바꾸는 조치는 마지막 수단으로 두고, 동일한 프로젝트와 다른 임시 키체인에서 먼저 검증하는 편이 안전합니다.
[ SECTION_06 ] 원격 환경 판정과 최종 점검
같은 커밋으로 작업을 반복했을 때 실패 위치가 고정되는지 확인하면 수정 방향이 선명해집니다.
- 항상 같은 커밋에서 같은 컴파일 오류가 발생하면 프로젝트를 수정합니다.
- 그래픽 세션에서는 성공하고 SSH에서만 실패하면 세션, 권한, 환경 변수를 확인합니다.
- 특정 호스트에서만 실패하면 해당 맥의 SDK, 시뮬레이터, 키체인 상태를 점검합니다.
- 재연결이나 호스트 재시작 뒤에만 실패하면 상주 서비스와 로그인 조건을 점검합니다.
- Build는 성공하지만 Test만 실패하면 테스트 대상과 실행 환경을 분리합니다.
- Archive는 성공하지만 내보내기만 실패하면 서명 자산과 내보내기 설정을 분리합니다.
실행 가능한 검증 목록
- [ ] 실패한 전체 표준 출력과 표준 오류를 저장합니다.
- [ ] 실행 명령, 커밋 식별자, 작업 디렉터리를 기록합니다.
- [ ]
xcresult생성 여부와 내부 오류를 확인합니다. - [ ] 프로젝트와 작업 공간 중 올바른 입구를 선택합니다.
- [ ] Scheme 공유 상태와 구성 이름을 비교합니다.
- [ ] 잠금 파일, 사설 저장소 인증, 셸 경로를 비교합니다.
- [ ]
build-for-testing과test-without-building을 따로 실행합니다. - [ ] SDK, 시뮬레이터 대상, 장치 식별자를 확인합니다.
- [ ] 인증서에 개인 키가 있고 프로파일이 맞는지 확인합니다.
- [ ] 그래픽 세션, SSH, CI에서 같은 커밋으로 다시 검증합니다.
- [ ] 재연결과 호스트 재시작 뒤에도 결과가 같은지 확인합니다.
이 목록에서 프로젝트 관련 항목만 계속 실패하면 코드를 고칩니다. 특정 사용자나 세션에서만 실패하면 원격 환경을 재구성합니다. 반복 실행이 필요한 팀이라면 임시 호스트보다 격리된 상주 환경이 적합한지 평가해야 합니다. 이때는 NOVAKVM의 원격 맥 환경처럼 동일한 커밋으로 Build, Test, Archive를 비교할 수 있는 구성을 검토할 수 있습니다.
자체 장비는 물리 장치 연결과 장기 고정 부하에 유리합니다. 반면 초기 구매 비용, 저장 공간 관리, 전원과 네트워크 장애 대응, 한 대에 여러 작업이 몰리는 문제가 남습니다. 일반 클라우드 환경은 macOS 전용 도구와 서명 흐름이 제한될 수 있고, 임시 실행마다 환경을 다시 맞춰야 하는 부담도 있습니다. 프로젝트 단위의 원인 확인이 끝난 뒤 원격 맥을 별도 빌드 서버로 분리하면 기존 개발 장비를 계속 점유하지 않고 재현 시험을 진행할 수 있습니다. 필요하다면 맥 미니 대여 가격과 구성을 기준으로 임시 검증 환경과 상주 환경을 나눠 비교하시기 바랍니다.
xcodebuild exit code 65의 핵심은 숫자를 고치는 데 있지 않습니다. 실패 현장을 보존하고, Build·Test·Archive·내보내기를 분리한 뒤, 같은 커밋이 같은 환경에서 다시 실패하는지 확인해야 합니다. 그 결과가 원래 호스트에만 묶여 있다면, 격리된 NOVAKVM 원격 맥에서 대조 작업을 실행하는 편이 프로젝트를 불필요하게 수정하는 것보다 안전합니다.