원격 Mac CI의 xcresult는 어떻게 내보낼까? 2026 가이드
원격 Mac CI에서 테스트 결과 패키지가 생성되지 않거나 내려받을 수 없는 문제를 다룹니다. 결과 경로 지정부터 실패 작업의 업로드, 다운로드 후 확인, 보관과 접근 권한 점검까지 역할별로 안내합니다.
목차
테스트가 실패했는데 CI 기록에는 로그만 남고 결과 패키지가 보이지 않나요?
이번 주에는 xcodebuild test에 작업별 결과 패키지 경로를 지정하고, 테스트가 실패해도 업로드 단계를 실행하도록 구성하세요. 내려받은 xcresult를 실제로 열어야 전달 과정까지 확인한 것입니다.
이 글은 원격 맥 CI의 테스트 결과를 보존해야 하는 CI 유지 관리자, 실패 정보와 커버리지를 확인하는 테스트 엔지니어, 보관과 접근 범위를 정하는 플랫폼 및 배포 담당자를 위한 안내입니다.
CI 유지 관리자: 결과 패키지가 생성되는 테스트인지 확인합니다
먼저 워크플로가 실제로 테스트를 실행하는지 확인하세요. xcodebuild로 빌드만 수행했다면 테스트 결과 패키지가 생성되지 않을 수 있습니다. 테스트 로그, 앱 아카이브와 Xcode 테스트 결과 패키지는 서로 다른 자료입니다. 로그에는 명령 실행 과정이 담기지만, xcresult는 테스트 실행 결과와 관련 정보를 확인하는 데 사용됩니다. Apple은 테스트 결과를 읽고 해석하는 방법을 안내하고 있습니다. Apple의 테스트 실행 및 결과 해석 안내에서 프로젝트에 필요한 결과 정보도 함께 확인하세요.
| CI에 남는 자료 | 무엇을 확인할 수 있나요? | xcresult를 대신할 수 있나요? |
|---|---|---|
| 빌드 로그 | 명령 실행 중 출력과 오류 | 테스트 요약이나 결과 자료를 확인하는 용도와 다릅니다 |
| 앱 아카이브 | 배포용으로 만든 앱 산출물 | 테스트 결과 패키지가 아닙니다 |
| Xcode 테스트 결과 패키지 | 테스트 결과와 관련 진단 정보 | 테스트 실행을 보존하고 확인하는 자료입니다 |
테스트 로그만 업로드하는 설정이라면 테스트 실패의 원인을 살필 정보를 충분히 가져오지 못할 수 있습니다. 반대로 테스트를 실행하지 않는 작업에 결과 패키지 업로드만 추가하면 대상 경로가 없어 업로드가 실패하거나 빈 결과만 남을 수 있습니다.
xcodebuild test에서 결과 패키지 경로를 어떻게 지정하나요?
테스트 명령에 -resultBundlePath를 넣고, 저장 위치를 작업별 경로로 지정하세요. 예를 들면 다음과 같습니다.
xcodebuild test \
-scheme "<스킴 이름>" \
-destination "<대상 기기>" \
-resultBundlePath "<작업별 결과 경로>"
실제 옵션과 사용 방식은 Xcode 버전 및 명령 구성에 맞춰 Apple의 Xcode 명령줄 도구 참조를 확인하세요. 경로는 저장소의 기존 파일이나 소스 디렉터리를 덮어쓰지 않는 위치로 정하고, 병렬 테스트 작업에는 서로 다른 경로를 배정해야 합니다. 같은 경로를 함께 쓰면 한 작업이 다른 작업의 결과를 덮어쓰거나 업로드 단계가 잘못된 패키지를 선택할 수 있습니다.
빌드 엔지니어: 작업마다 추적 가능한 경로를 만듭니다
경로에는 실행 기록과 테스트 작업을 알아볼 수 있는 식별 정보를 반영하되, 실제 저장소 이름이나 커밋 식별자를 문서와 공유 로그에 그대로 노출하지 않도록 하세요. 경로를 환경 변수로 관리하면 테스트 명령과 업로드 단계가 같은 값을 참조하게 만들 수 있습니다.
RESULT_BUNDLE="<작업별 결과 경로>"
xcodebuild test \
-scheme "<스킴 이름>" \
-resultBundlePath "$RESULT_BUNDLE"
다음 항목을 순서대로 실행하면 경로 문제를 좁히기 쉽습니다.
- 작업 시작 전에 결과 패키지가 놓일 상위 디렉터리를 정합니다.
- 작업마다 겹치지 않는 결과 경로를 전달합니다.
- 테스트 종료 뒤 지정한 경로에 결과 패키지가 생겼는지 확인합니다.
- 업로드 단계의 경로 값이 테스트 단계의 값과 같은지 비교합니다.
- 병렬 작업을 실행해도 결과 패키지가 서로 덮어쓰이지 않는지 시험합니다.
결과가 나오지 않는다면 업로드 설정부터 바꾸기보다 테스트 명령이 실행됐는지, 결과 경로가 유효한지 먼저 확인하세요. Apple은 Xcode 테스트와 결과 패키지 관련 명령을 문서화하고 있습니다. xcresulttool 같은 명령줄 도구로 확인하려면 Apple의 Xcode 명령줄 도구 참조와 사용 중인 Xcode 버전의 안내를 기준으로 삼으세요.
워크플로 유지 관리자: 실패해도 업로드 단계가 실행되게 합니다
테스트 명령이 실패 상태를 반환하면 일반적인 단계 실행 조건에 따라 뒤의 업로드 단계가 건너뛰어질 수 있습니다. 업로드 단계는 실패 여부와 관계없이 실행되도록 설정하고, 결과 파일이 없을 때는 워크플로에서 알아볼 수 있게 처리하세요. GitHub Actions에서는 워크플로 표현식과 작업 조건을 이용해 단계를 제어할 수 있습니다. 정확한 조건 사용법은 GitHub Actions 표현식 문서를 확인하세요.
- name: 테스트 실행
run: <테스트 명령>
- name: 테스트 결과 업로드
if: always()
uses: actions/upload-artifact@<버전>
with:
name: <작업을 식별하는 이름>
path: <결과 패키지 경로>
if-no-files-found: error
테스트 실패 뒤에 원격 Mac CI의 xcresult가 업로드되지 않는다면 어디부터 볼까요?
먼저 업로드 단계가 실패한 테스트 다음에도 실행됐는지 확인하세요. 실행 기록에는 업로드 단계가 생략됐는지, 경로에 파일이 없었는지, 업로드 단계가 오류를 냈는지 흔적이 남습니다. 다음으로 업로드 경로가 결과 패키지 위치와 일치하는지 살펴보세요. 파일 하나, 디렉터리, 여러 경로를 넘기는 방식은 액션 설정에 따라 달라질 수 있으므로 임의로 단정하지 말고 GitHub Actions 아티팩트 보존 안내를 확인하세요.
| 진단 우선순위 | 관찰된 상태 | 다음 점검 |
|---|---|---|
| 높음 | 업로드 단계가 건너뛰어짐 | 실패 뒤에도 실행되는 조건인지 확인합니다 |
| 높음 | 업로드 단계에서 파일을 찾지 못함 | 테스트 단계의 실제 결과 경로와 업로드 경로를 대조합니다 |
| 중간 | 아티팩트는 보이지만 결과 패키지가 열리지 않음 | 디렉터리 또는 다중 경로 처리와 패키지 내부 파일을 확인합니다 |
| 중간 | 실행 기록에서 아티팩트가 보이지 않음 | 실행 기록, 접근 권한, 보관 설정을 확인합니다 |
캐시는 빌드 재사용을 위한 장치이며, 실패한 테스트 결과를 실행 기록에 전달하는 아티팩트와 목적이 다릅니다. 결과를 보존하려면 캐시 저장 여부만 확인하지 말고 워크플로 아티팩트로 올라왔는지 점검하세요. GitHub의 워크플로 아티팩트 개념 안내는 아티팩트가 빌드 및 테스트 출력을 저장하고 실행 뒤 내려받는 데 쓰이는 방식을 설명합니다.
테스트 실패를 이유로 업로드를 생략하면, 실패 원인을 나중에 확인할 자료까지 함께 잃을 수 있습니다. 실패 작업을 보존하는 조건은 정상 작업과 별도로 검증하세요.
테스트 엔지니어: 내려받은 결과 패키지를 직접 엽니다
GitHub Actions에서 받은 결과를 어떻게 확인하나요?
워크플로 실행 기록에서 아티팩트를 내려받고, macOS 환경에서 Xcode 또는 xcresulttool로 열어 보세요. GitHub의 워크플로 실행에서 아티팩트를 내려받는 안내를 따라 실행 기록에서 대상 아티팩트를 선택할 수 있습니다. Xcode 버전이 다르면 표시 방식이나 명령 옵션이 달라질 수 있으므로, 결과를 검사할 환경의 Xcode 문서도 함께 확인하세요.
패키지가 다운로드됐다는 사실만으로 내용이 정상이라고 판단하지 마세요. 테스트 요약이 표시되는지, 실패 테스트의 세부 정보와 로그를 열 수 있는지 확인합니다. 프로젝트에서 커버리지나 첨부 파일을 분석한다면 그 자료가 실제 결과 패키지에 포함되고 접근 가능한지도 확인하세요. Apple은 Xcode 테스트 결과를 보고 검사하는 방법을 공식 안내로 제공합니다.
실패 테스트의 결과를 남기는 가장 빠른 확인 방법은 무엇인가요?
성공한 테스트와 의도적으로 실패하도록 만든 테스트를 각각 실행하세요. 두 실행 모두 결과 패키지가 만들어지고 아티팩트로 올라오는지 확인한 뒤, 내려받은 파일을 열어 요약과 실패 정보를 살펴보세요. 실패 실행에서만 누락된다면 테스트 종료 코드 뒤의 단계 조건을, 두 실행 모두에서 누락된다면 결과 경로와 업로드 대상 설정을 우선 점검합니다.
플랫폼 책임자: 이름, 보관 기간과 접근 권한을 정합니다
아티팩트 이름은 워크플로 실행, 커밋, 테스트 작업을 구별할 수 있게 구성하세요. 다만 토큰이나 비공개 저장소 주소처럼 민감한 값은 이름이나 업로드 파일에 넣지 않습니다. 보관 기간은 플랫폼 설정과 프로젝트의 진단 요구에 따라 정해야 합니다. 여기서 모든 저장소에 공통으로 적용되는 기본 보관 일수를 가정하지 마세요. 실제 값은 워크플로와 저장소 설정에서 확인해야 합니다.
결과 패키지와 테스트 로그에는 프로젝트 구조, 테스트 입력, 오류 메시지와 내부 동작이 드러날 수 있습니다. 누구나 열 수 있는 공개 파일로 취급하지 말고, 실행 기록과 아티팩트를 읽을 수 있는 계정을 필요한 범위로 제한하세요. 아티팩트가 얼마나 오래 보관되는지와 누가 내려받을 수 있는지도 현재 플랫폼 설정을 기준으로 검토해야 합니다.
- 보관 기간을 프로젝트의 조사 및 재현 요구와 맞춥니다.
- 실행 기록과 아티팩트를 읽을 수 있는 역할을 정합니다.
- 이름에 작업 식별 정보를 포함하되 민감한 값을 제외합니다.
- 만료된 결과와 접근 권한이 없는 결과를 구분해 안내합니다.
원격 맥에서 테스트 작업을 계속 운영할 환경을 평가 중이라면 원격 맥 노드 안내에서 접속 가능한 실행 환경을 살펴보세요. 노드 선택은 프로젝트의 CI 구성과 운영 책임에 맞춰 판단하고, 테스트 결과 보관과 권한 설정은 별도로 설계해야 합니다.
배포 책임자: 실패 작업으로 전달 경로를 끝까지 검수합니다
아래 조건 분기로 운영 방식을 결정하세요.
- 테스트 명령이 실행되고 결과 경로에 패키지가 생기면, 업로드 경로와 이름을 확인한 뒤 정상 업로드를 검증합니다.
- 테스트가 실패해도 업로드 단계가 실행되고 패키지를 받을 수 있다면, 내려받아 테스트 요약과 실패 내용을 확인합니다.
- 업로드 단계가 생략되면, 단계 실행 조건을 수정하고 실패 테스트로 다시 검증합니다.
- 업로드 단계는 실행됐지만 파일을 찾지 못하면, 결과 경로와 업로드 대상의 일치 여부를 확인합니다.
- 아티팩트가 실행 기록에 없거나 접근할 수 없다면, 보관 설정과 읽기 권한을 확인합니다.
이 검수는 결과 생성, 업로드, 다운로드, 읽기까지 이어지는 전달 경로를 확인합니다. 원격 맥에서 테스트를 실행하는 방식을 정할 때는 서울 원격 맥 노드 정보도 참고할 수 있습니다. 다만 실행 환경을 선택했다고 결과가 자동으로 보관되는 것은 아닙니다. 프로젝트의 워크플로와 접근 정책에서 실제 동작을 검증해야 합니다.
로컬 맥만 사용하면 빌드 환경이 개발자 장비의 가용성과 설정에 묶일 수 있고, 리눅스 서버만으로는 Xcode 테스트 작업을 수행할 수 없습니다. 맥을 직접 구매하면 장비를 관리하고 온라인 상태를 유지하는 책임이 따릅니다. 테스트 작업을 맡길 원격 실행 환경이 필요하지만 장비를 상시 관리하고 싶지 않다면, VPSMAC의 원격 맥 대여를 검토할 수 있습니다. 반대로 장기간 고정된 고부하 작업이나 물리 장비 연결이 핵심이라면 직접 보유한 맥이 더 적합할 수 있습니다. 어느 방식을 택하든 테스트 실패, 업로드, 다운로드, 결과 패키지 열기까지 확인한 뒤 운영 환경에 반영하세요.