먼저 직접 확인해 보세요

먼저 다음 명령을 실행해 xcode-select -p 및 xcodebuild -version을 확인하고 현재 개발자 디렉터리와 버전을 기록하세요. 대상 Xcode가 설치되어 있는지 확인한 뒤 개발자 디렉터리를 해당 버전의 Contents/Developer로 변경하세요. 아래 경로는 앱 이름이 Xcode.app인 경우에 해당합니다. 노드에서 버전이 포함된 앱 이름을 사용한다면 실제 경로에 맞게 바꾸세요.

xcode-select -p
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
xcodebuild -version

CI 프로세스는 DEVELOPER_DIR 로 시스템 선택을 덮어쓸 수 있습니다. 터미널과 파이프라인의 버전이 다르면 시스템 설정만 보지 말고 job의 환경 변수와 runner 서비스 사용자를 확인하세요. 특정 작업에서 다른 버전이 필요하다면 해당 작업에 개발자 디렉터리를 명시적으로 지정해 같은 노드의 다른 빌드에 영향을 주지 않도록 하세요.

사용량을 확인한 다음 정리 여부를 결정하세요. 툴체인 변경 후 캐시 관련 오류나 인덱스 문제가 발생하거나 디스크 공간이 부족할 때 DerivedData를 정리할 수 있습니다. 일반적인 컴파일 오류를 무조건 캐시 문제로 보지는 마세요. 관련 빌드 작업을 종료한 후 캐시 디렉터리 이름을 바꿔 보관하면 바로 재귀 삭제하는 것보다 복구하기 쉽습니다.

du -sh "$HOME/Library/Developer/Xcode/DerivedData"
mv "$HOME/Library/Developer/Xcode/DerivedData" "$HOME/Library/Developer/Xcode/DerivedData.backup.$(date +%s)"

디렉터리가 있을 때만 이름을 바꾸세요. Xcode는 다음 빌드에서 캐시를 다시 생성합니다. 이름을 바꿔도 디스크 공간은 확보되지 않습니다. 새 빌드가 정상인지 확인한 다음 실제 백업 경로의 이전 캐시를 삭제하세요. 필요한 아카이브는 보관하고 Archives, 프로젝트 디렉터리, 서명 자료를 함께 지우지 마세요. CI에서 사용자 지정 -derivedDataPath를 사용한다면 현재 사용자의 기본 디렉터리가 아니라 지정된 경로를 확인해야 합니다.

서명하려면 유효한 인증서와 이에 대응하는 개인 키가 필요합니다. 인증서 파일만으로는 보통 서명을 완료할 수 없습니다. 키체인 접근을 통해 사용할 권한이 있는 서명 자료를 가져온 다음 실제 빌드를 실행하는 사용자 계정에서 사용 가능한 ID를 확인하세요. 문의에 인증서 파일이나 가져오기 암호를 첨부하지 마세요.

security find-identity -v -p codesigning
security list-keychains -d user

대화형 사용자에게 ID가 보인다고 해서 runner 서비스 사용자에게도 보이는 것은 아닙니다. 서비스 실행 계정, 키체인 검색 목록, 잠금 해제 상태, 접근 권한을 확인하세요. 키체인 접근 제어를 조정해야 한다면 필요한 서명 도구에만 권한을 부여하세요. 오류를 없애려고 모든 앱에 개인 키 접근을 허용하지 마세요. 문의 시 민감한 정보를 제거한 ID 점검 결과, 오류 코드, 실행 사용자 유형을 알려 주세요.

SSH 터미널에서만 확인하지 말고 실패한 job에서 같은 환경 점검을 실행하세요. 실행 사용자, 개발자 디렉터리, Xcode 버전, PATH, 사용 가능한 시뮬레이터를 비교하세요. 서비스 프로세스가 대화형 셸 설정을 불러오지 않을 수 있으므로 직접 실행에 성공해도 서비스 환경이 같다는 뜻은 아닙니다.

whoami
xcode-select -p
xcodebuild -version
printf '%s\n' "$PATH"
xcrun simctl list devices available

시뮬레이터 목록에 대상 기기가 없다면 필요한 런타임이 설치되어 있는지, 테스트 작업의 destination이 일치하는지 확인하세요. runner가 오프라인으로 표시되면 서비스 시작 상태와 작업 로그를 확인한 다음 네트워크 연결과 등록 정보를 점검하세요. 기준 데이터가 없다면 빌드 작업 하나로 먼저 검증하고 동시 실행 수를 단계적으로 늘리면서 통합 메모리와 디스크 사용량을 살펴보세요.

전용 노드란 물리 리소스를 다른 임차인과 나누어 쓰지 않는다는 뜻이지, 같은 노드의 여러 작업이 서로 영향을 주지 않는다는 뜻은 아닙니다. GitHub Actions와 GitLab CI의 전체 설정 방법은 연결 가이드에서 확인하세요.

지갑의 송금 완료, 온체인 확인, 주문 확인은 서로 다른 단계입니다. 확인 시간은 온체인 처리와 결제 게이트웨이 상태에 따라 달라지므로 이 페이지에서는 일정한 소요 시간을 안내하지 않습니다. 먼저 결제 페이지에 표시된 네트워크, 수취 주소, 금액이 맞는지 확인하세요. 그런 다음 해당 거래의 성공 여부와 콘솔의 주문 상태를 확인하세요.

주문이 아직 갱신되지 않았다고 해서 결제를 반복하지 마세요. 수동 확인이 필요하면 주문 번호, 트랜잭션 해시, 송금 금액과 시각을 제출하고 시간대를 명시하세요. 트랜잭션 해시로 거래를 조회할 수 있습니다. 시드 구문, 지갑 개인 키, 암호는 필요하지 않으며 보내서도 안 됩니다. 네트워크나 금액이 결제 안내와 다르다면 거래 기록을 보관하고 문의에 사실대로 적어 주세요.

먼저 결제 페이지의 오류 안내와 주문 상태를 확인한 다음 카드 발급사가 해당 USD 거래를 허용하는지, 추가 인증이 필요한지 확인하세요. 발급사의 승인 대기 내역이 주문 결제 완료를 의미하지는 않습니다. 카드 알림만으로 서비스 제공 여부를 판단하지 마세요.

여러 번 실패했다면 빠르게 연속 재시도하지 말고 카드 발급사에 거절 사유를 확인하세요. 콘솔에는 결제가 확인되지 않지만 은행에 청구 내역이 표시된다면 주문 번호, 결제 시각, 금액, 민감한 정보를 가린 오류 메시지를 알려 주세요. 결제 거래 ID가 있다면 함께 제출하세요. 전체 카드 번호, 보안 코드, 인증 문자는 보내지 마세요. 지원팀은 주문 및 결제 기록을 확인하며, 환불 또는 승인 취소 여부는 게이트웨이와 카드 발급사의 결과에 따라 확인됩니다.

콘솔에 표시된 만료 시각을 기준으로 확인하세요. 알림 발송 시각과 전송 상태는 콘솔에서 확인해야 합니다. 이 페이지에서는 일정한 사전 알림 일수를 보장하지 않으므로 알림 수신 여부만으로 사용 가능 여부를 판단하지 마세요. 팀 일정에 만료 시각을 별도로 등록하고 갱신 결과를 확인할 담당자를 지정하는 것이 좋습니다.

일, 주, 월, 분기 중 주기를 선택한 뒤 갱신 청구서의 기기 모델, 추가 항목, 대여 기간이 맞는지 확인하세요. 결제 후에는 결제 페이지 스크린샷에만 의존하지 말고 주문 상태가 갱신됐는지 확인하세요. 만료 후에는 노드를 사용할 수 없으므로 프로젝트, 산출물, 필요한 설정을 만료 전에 백업하세요. 콘솔의 시각이나 금액이 예상과 다르면 청구서 번호를 보관해 문의한 뒤 결제를 진행할지 결정하세요.

전체 이용 주기 요금과 스토리지 확장 비용은 요금제 페이지에서 확인하세요. 기존 주문의 결제 문제는 콘솔 문의로 확인해야 하며, 이메일에 기기 암호를 첨부하지 마세요.