문제 해결의 다음 단계 찾기

먼저 확인하고, 필요하면 문의하세요

인도 상태는 주문에서, 연결은 포트에서, 빌드는 로그부터 확인하세요. 키워드를 검색해 바로 실행할 수 있는 점검 방법을 찾아보세요.

키워드를 입력해 관련 항목을 확인하세요. 검색 후 Enter를 누르면 첫 번째 답변으로 이동합니다.

클라우드 Mac 대여 콘솔에서 주문 보기

사용 중인 머신에 문제가 있다면 같은 티켓에 정보를 추가해 주세요. 문제를 이어서 확인할 수 있습니다.

문제가 발생한 단계 선택

문제 유형별로 나누어 살펴보세요. 네트워크 문제를 빌드 오류로 오인하지 않도록 먼저 머신에 연결되는지 확인한 다음 도구 체인과 서명을 점검하세요.

01 / 인도

부팅 및 인도

결제 후 진행 상황 확인, 접속 정보 조회, 상태 및 연결 정보 점검 방법을 안내합니다.

인도 절차 확인
02 / 연결

원격 연결

SSH 시간 초과, 공개 키 거부, 원격 데스크톱 연결 실패 등 오류 유형별 점검 방법을 확인하세요.

연결 오류 해결
03 / 빌드

Xcode 및 서명

아카이브 로그부터 프로비저닝 프로파일 일치 여부까지, 컴파일·아카이브·내보내기 단계를 구분해 확인하세요.

빌드 및 서명 문제 해결
04 / 결제

결제 및 갱신

일·주·월·분기별 요금표를 확인하고 갱신 메뉴와 결제 상태를 살펴보세요.

결제 규칙 확인
먼저 머신 인도 상태를 확인하세요

인도 진행 상황은 주문 상태에서 확인하세요

결제, 주문 처리, 머신 인도는 각각 별도의 단계입니다. 결제 후에는 먼저 주문을 확인하세요. 결제 페이지에 표시된 내용만으로 머신에 연결할 수 있다고 판단하지 마세요.

  1. 01

    결제 결과 확인

    콘솔에서 주문 번호, 모델, 대여 기간, 결제 상태를 확인하세요. 온체인 송금이나 카드 결제를 완료했다고 해서 주문 상태가 즉시 갱신되는 것은 아닙니다.

  2. 02

    인도 상태 확인

    해당 주문이나 인스턴스 상세 정보를 열어 현재 처리 상황을 확인하세요. 정확한 인도 시간과 사용 가능 여부는 콘솔에 실시간으로 표시되는 상태를 기준으로 합니다.

  3. 03

    연결 정보 확인

    인도 후 인스턴스 상세 정보에서 호스트 주소, 사용자 이름, SSH 포트, 최초 로그인 정보를 확인하세요. 다른 주문의 설정을 재사용하지 말고 해당 인스턴스에 표시된 값을 사용하세요.

결제했는데 연결 정보가 보이지 않는 이유는 무엇인가요?

먼저 이번 결제에 해당하는 주문을 확인한 뒤 콘솔에서 결제 상태를 확인하세요. 결제가 확인됐는데도 인스턴스가 처리 중이라면 주문 번호, 결제 방법, 결제 증빙 번호, 현재 상태를 티켓에 적어 주세요. 지원팀에서 인도 단계를 확인할 수 있습니다.

USDT-TRC20 결제는 트랜잭션 해시를 보관하세요. 카드 결제는 결제 기록 번호를 보관하세요. 카드 번호 전체, 보안 코드, 콘솔 비밀번호는 보내지 마세요. 같은 결제 건으로 새 주문을 반복해서 만들지 마세요.

SSH 시간 초과와 공개 키 거부는 각각 무엇을 확인해야 하나요?

연결 시간 초과:인스턴스가 인도되어 연결 가능한 상태인지 먼저 확인한 다음 호스트 주소와 포트를 한 글자씩 대조하고, 로컬 네트워크, 프록시, 접근 규칙을 점검하세요. 시간 초과는 인증 전에 발생하므로 공개 키를 반복해서 바꾸는 것으로는 대개 네트워크 경로 문제를 해결할 수 없습니다.

Permission denied (publickey):사용자 이름, 사용 중인 개인 키, 콘솔에 등록된 공개 키가 서로 맞는지 확인하세요. 업로드하는 것은 공개 키 파일의 내용입니다. 개인 키는 로컬에 보관하고 지원팀에 보내지 마세요. 아래의 HOST, PORT, USER를 인스턴스 상세 정보에 표시된 실제 값으로 바꾸세요.

ssh -vv -o IdentitiesOnly=yes \
  -i ~/.ssh/id_ed25519 \
  -p PORT USER@HOST

진단 출력을 제출하기 전에 호스트 주소, 개인 경로 등 민감한 정보를 삭제하세요. 오류 유형과 인증 단계는 남겨 두세요. 호스트 지문이 바뀌었다면 최근에 OS를 재설치했는지 먼저 확인하고, 지문 검증을 무작정 건너뛰지 마세요.

SSH는 되는데 원격 데스크톱이 열리지 않으면 무엇을 확인해야 하나요?

먼저 인스턴스 상세 정보의 데스크톱 연결 정보를 확인하고 같은 머신을 사용 중인지 확인하세요. 원격 데스크톱과 SSH는 서로 다른 연결 경로이므로 SSH가 된다는 것만으로는 SSH 경로에 접근할 수 있다는 뜻입니다.

연결 안내에 따라 데스크톱 서비스, 접근 포트, 터널 대상이 맞는지 확인하세요. 검은 화면이 나타나면 클라이언트 메시지와 발생 단계를 기록한 뒤 해상도나 화질을 낮춰 표시 문제인지 인증 실패인지 구분하세요. 재시작해야 한다면 실행 중인 아카이브나 테스트 작업을 먼저 중단하세요.

연결 설정과 전환 순서는 다음을 참조하세요: SSH 및 원격 연결 안내 데스크톱은 로그인 후 인스턴스 상세 정보에서 이용할 수 있습니다.

첫 번째 실제 오류부터 찾으세요

아카이브 실패 시 모든 것을 먼저 지우지 마세요

먼저 실패 당시 상태를 보존한 다음 Xcode, Scheme, 종속성, 대상 플랫폼을 점검하세요. 로그 마지막의 실패 요약은 결과일 뿐입니다. 첫 번째 컴파일 오류나 서명 오류부터 확인해야 합니다.

archive 오류는 어떤 순서로 확인해야 하나요?

현재 커밋, 빌드 명령, Xcode 버전을 기록하고 Scheme이 존재하며 아카이브용으로 설정되어 있는지 확인하세요. 명령줄 작업이라면 선택된 개발자 도구 디렉터리도 확인해 데스크톱에서 연 Xcode와 CI가 실제로 사용하는 버전이 다른 일이 없도록 하세요.

xcode-select -p
xcodebuild -version
xcodebuild -list -workspace App.xcworkspace

App.xcworkspace와 App을 프로젝트의 실제 이름으로 바꾸세요. workspace를 사용하는 프로젝트에서 project를 잘못 지정하지 마세요. 종속성 복원 누락, 공유 Scheme 미커밋, 배포 대상과 SDK의 불일치 때문에 아카이브 단계 전에 실패할 수 있습니다.

set -o pipefail
xcodebuild \
  -workspace App.xcworkspace \
  -scheme App \
  -destination 'generic/platform=iOS' \
  -archivePath "$PWD/output/App.xcarchive" \
  archive 2>&1 | tee archive.log

이 단계에서 생성되는 것은 .xcarchive이며 배포 가능한 IPA가 아닙니다. 아카이브는 성공했지만 내보내기에 실패했다면 빌드 종속성을 전부 다시 처리하지 말고 서명과 프로비저닝 프로파일을 확인하세요.

DerivedData는 언제 정리해야 하나요?

도구 체인을 바꾼 뒤 모듈 캐시 비호환이나 생성 파일 불일치가 발생하거나, 같은 커밋이 깨끗한 환경에서는 통과하지만 기존 캐시가 있는 환경에서 실패할 때 캐시 문제인지 확인하세요. 먼저 해당 프로젝트의 빌드를 중단하고 로그를 저장하세요. 사용자 디렉터리 전체를 정리 대상으로 삼지 마세요.

이번 빌드에 새 프로젝트 전용 디렉터리를 지정하는 것이 더 안전한 확인 방법입니다. 이전 디렉터리는 나중에 확인할 수 있도록 보존하세요. 새 디렉터리에서도 실패한다면 캐시를 반복해서 지우지 말고 소스 코드, 종속성, 설정을 살펴보세요.

xcodebuild \
  -workspace App.xcworkspace \
  -scheme App \
  -derivedDataPath "$PWD/.build/DerivedData-check" \
  -destination 'generic/platform=iOS' \
  build

빌드가 복구된 뒤 프로젝트별로 불필요한 이전 디렉터리를 정리하세요. 소스 코드, 서명 파일, 아카이브 산출물, DerivedData를 분리해 보관하면 실수로 삭제할 위험을 줄일 수 있습니다.

시뮬레이터 런타임이나 테스트 대상을 찾을 수 없으면 어떻게 하나요?

먼저 작업이 기기 아카이브인지 시뮬레이터 테스트인지 확인하세요. 기기용 archive에는 iOS 기기 대상을 사용하고, 시뮬레이터 테스트에는 현재 Xcode에서 지원하는 런타임과 기기가 필요합니다. 배포용 아카이브 대상 대신 시뮬레이터 대상을 사용하지 마세요.

xcrun simctl list runtimes
xcrun simctl list devices available
xcodebuild -showdestinations \
  -workspace App.xcworkspace -scheme App

런타임이 없다면 Xcode 설정에서 해당 플랫폼 구성 요소를 설치하세요. 해당 명령을 지원하는 Xcode 버전에서는 아래 방법으로 iOS 플랫폼 구성 요소를 다운로드할 수도 있습니다. 먼저 사용 가능한 디스크 공간을 확인하고 명령줄에서 사용할 Xcode 버전이 선택되어 있는지 확인하세요.

xcodebuild -downloadPlatform iOS

설치 후 destinations 목록을 다시 확인하고 실제로 사용 가능한 대상을 CI에 지정하세요. 다른 머신의 시뮬레이터 기기 식별자를 계속 사용하지 마세요.

서명 자산은 별도로 전달하세요

인증서, 프로비저닝 프로파일, API Key는 각각 역할이 다릅니다

.p12는 인증서와 개인 키를 제공하고, 프로비저닝 프로파일은 앱과 기능을 제한하며, API Key는 인증이 필요한 API에 사용됩니다. 서로 대체할 수 없습니다.

.p12를 가져왔는데 CI에서 서명 ID를 찾지 못하는 이유는 무엇인가요?

.p12 파일을 안전한 경로로 머신에 전달해 빌드에 사용할 키체인으로 가져오고, 파일에 해당 인증서와 짝을 이루는 개인 키가 포함되어 있는지 확인하세요. 인증서만 있고 개인 키가 없으면 코드 서명을 완료할 수 없습니다. 가져오기 암호는 CI의 비밀 변수로 전달하고 저장소, 명령 스크립트, 티켓에 적지 마세요.

security find-identity -v -p codesigning

실제로 runner를 실행하는 사용자 환경에서 확인 명령을 실행하세요. 데스크톱 사용자가 인증서를 볼 수 있다고 해서 다른 서비스 사용자도 볼 수 있는 것은 아닙니다. 키체인이 잠금 해제되어 있는지, 해당 사용자의 검색 목록에 포함되어 있는지, 서명 프로세스에 접근 권한이 있는지도 확인하세요.

빌드 전용 키체인을 사용하고 작업이 끝나면 절차에 따라 잠그세요. 도움이 필요하면 민감한 정보를 제거한 ID 확인 결과와 오류 문구만 제공하고 .p12, 개인 키, 가져오기 암호는 보내지 마세요.

아카이브는 성공했는데 IPA 내보내기에서 프로비저닝 프로파일이 일치하지 않는다고 나오나요?

Bundle ID, Team ID, 내보내기 용도, entitlements 네 가지를 일치시키세요. 확장 프로그램이 포함된 앱은 서명이 필요한 각 Target에 맞는 설정이 있어야 합니다. 기본 앱이 일치해도 확장 프로그램까지 일치한다는 뜻은 아닙니다.

프로비저닝 프로파일이 유효한지, 사용 중인 인증서가 포함되어 있는지, 내보내기 옵션의 서명 방식이 프로젝트 설정과 일치하는지도 확인하세요. 개발 및 테스트용 설정과 배포용 설정은 다르므로 파일 이름이 비슷하다는 이유만으로 선택하지 마세요.

내보내기 단계의 로그와 ExportOptions.plist에서 민감한 정보를 제거한 사본을 보관하세요. 티켓을 제출할 때 archive 단계와 exportArchive 단계 중 어디에서 실패했는지 적으면 문제 범위를 바로 좁힐 수 있습니다.

App Store Connect API Key는 어떻게 관리해야 하나요?

.p8 파일은 접근이 제한된 디렉터리에 보관하고 Key ID, Issuer ID, 파일 경로는 CI의 비밀 변수로 전달하세요. 업로드나 자동화 작업에 필요한 권한만 사용하고 키 내용을 lane에 직접 넣거나 저장소에 커밋하지 마세요.

API Key는 해당 인증 방식을 지원하는 업로드 및 관리 절차에 사용할 수 있지만, 로컬 코드 서명에 필요한 인증서와 개인 키를 대체하지는 않습니다. TestFlight 업로드에 실패하면 로컬 산출물의 서명 오류인지, API 인증·앱 권한·버전 정보 오류인지 먼저 구분하세요.

키를 교체한 뒤 runner 설정을 업데이트하고 이전 키 참조를 제거하세요. 지원이 필요하면 민감한 정보를 제거한 오류 코드와 실행 단계를 알려 주세요. .p8 파일은 보내지 마세요.

Fastlane match를 새 머신에 설정할 때 무엇부터 확인해야 하나요?

서명 저장소 접근 권한, 암호 해독 암호, 배포 유형, 앱 식별자, 팀 설정을 확인하세요. 일반적인 CI 작업에서는 이미 준비된 서명 자산을 읽기 전용으로 가져오도록 설정해 실행할 때마다 인증서를 만들거나 수정하지 않도록 하세요.

lane :prepare_signing do
  match(
    type: "appstore",
    readonly: true,
    app_identifier: ENV.fetch("APP_IDENTIFIER"),
    team_id: ENV.fetch("TEAM_ID")
  )
end

저장소 접근 자격 증명과 암호 해독 암호는 각각 별도로 관리하세요. 읽기 실패는 저장소 인증을, 암호 해독 실패는 암호를 확인하세요. 설치는 성공했지만 서명이 실패하면 키체인과 프로비저닝 프로파일을 점검하세요. 세 가지 오류를 모두 “match가 작동하지 않음”으로 묶지 마세요.

대여 기간과 결제를 따로 확인하세요

4가지 대여 기간, 요금표 기준으로 결제

일·주·월·분기 요금은 각각 별도로 책정되며 일일 요금을 다른 기간에 단순히 곱하지 않습니다. 두 모델 모두 가상 머신이 아닌 독립형 물리 머신입니다. 실제 주문 금액은 결제 내역을 기준으로 합니다.

기본 모델 요금표(미국 달러, USD)
모델 및 구성일주월분기
OSXBuild Bake M4
M4 / 16GB / 256GB		$20.1$54.2$100.3$272.8
OSXBuild Bake M4 Pro
M4 Pro / 64GB / 2TB		$60.3$162.9$301.6$820.4
대여 기간 네 가지는 어떻게 비교하고 추가 옵션은 어떻게 계산하나요?

머신을 사용할 연속 기간을 기준으로 주기를 선택한 다음 같은 주기의 모델 가격과 추가 옵션을 확인하세요. 정확한 시작 및 종료 시각은 주문에 표시된 값을 따릅니다. ‘월’을 해당 월의 남은 일수로 단순히 계산하지 마세요.

추가 SSD와 Thunderbolt 5 병렬 구성에는 각각 4가지 주기의 요금표가 있습니다. 구성 도구에서 필요한 옵션을 선택한 다음 결제 내역을 확인하세요. 기본 모델 가격만 보고 최종 청구액을 판단하지 마세요. 전체 요금표와 선택 가이드는 다음을 참조하세요: 대여 플랜 및 추가 옵션。

어디서 갱신하나요? 만료 전에는 무엇을 해야 하나요?

콘솔에 로그인해 해당 구독이나 주문으로 이동한 뒤 만료일, 갱신 옵션, 청구 내역을 확인하세요. 결제를 완료한 후 새 만료일이 반영됐는지 다시 확인하세요. 결제 페이지를 열었거나 결제를 제출했다는 이유만으로 갱신이 완료됐다고 판단하지 마세요.

자동 갱신 설정 여부와 미결제 청구서 여부는 해당 주문의 설정과 상태를 기준으로 합니다. 머신을 계속 사용하려면 미리 갱신을 완료하고 결과를 확인하세요. 대여를 종료할 예정이라면 소스 코드, 산출물, 필요한 설정을 미리 내보내세요.

대여 기간이 끝나면 머신은 회수 절차에 들어가며 디스크는 안전하게 삭제된 후 OS가 재설치됩니다. 노드를 유일한 백업 장소로 사용하지 말고, 만료 후 로컬 파일을 다시 가져올 수 있다고 기대하지 마세요.

어떤 결제 수단을 지원하나요? 결제 문제는 어떻게 확인하나요?

USDT-TRC20 및 Visa / Mastercard / Amex(Stripe 경유)만 지원하며 모든 결제는 미국 달러(USD)로 처리됩니다. 실제로 이용 가능한 결제 게이트웨이는 백엔드 응답을 기준으로 합니다.

USDT-TRC20 결제 시 결제 페이지의 네트워크, 수신 주소, 금액을 각각 확인하고 이전 주문의 결제 정보를 재사용하지 마세요. 카드 결제는 게이트웨이 안내에 따라 인증을 완료한 뒤 콘솔로 돌아가 상태를 확인하세요.

결제 문제를 문의할 때는 주문 번호, 선택한 결제 수단, 민감한 정보를 제거한 오류 메시지, 거래 번호를 제공하세요. 신용카드 결제는 Stripe에서 처리하므로 티켓이나 이메일에 카드 번호 전체 또는 보안 코드를 적을 필요가 없습니다.

문제 상황을 함께 알려 주세요

티켓 제출 전, 다음 네 가지를 확인하세요

“패키징 실패”라고만 쓰는 것보다 재현 절차를 알려 주는 편이 훨씬 도움이 됩니다. 실행 중인 작업과 관련된 문제라면 재시작이나 설정 변경 전에 현재 상태를 먼저 보존하세요.

  • 상태를 저장한 뒤 재시작을 시도했습니다

    먼저 빌드와 테스트를 중단하고 로그와 커밋되지 않은 파일을 저장한 뒤 머신을 재시작하세요. 재시작 전후의 현상을 기록하세요. 현재 작업을 중단하면 안 된다면 아직 재시작하지 않았다는 점과 이유를 티켓에 적어 주세요.

  • SSH 포트와 공개 키를 확인했습니다

    현재 인스턴스 정보를 기준으로 호스트, 사용자 이름, 포트, 키 쌍이 맞는지 확인하세요. 구체적인 오류 문구를 알려 주고 개인 키나 최초 로그인 비밀번호는 업로드하지 마세요.

  • 로그 마지막 50줄을 첨부했습니다

    로그 마지막 50줄과 첫 번째 관련 오류의 앞뒤 내용을 첨부하고 명령, Xcode 버전, 커밋 식별자를 적어 주세요. 로그가 길다면 콘솔 티켓에 파일을 첨부하고 토큰과 서명 관련 비밀 정보는 먼저 제거하세요.

  • 노드와 주문 번호를 적었습니다

    주문 번호, 노드, 문제가 발생한 시각과 시간대, 예상 결과, 실제 결과를 적어 주세요. 마지막으로 정상 작동한 시점도 알려 주면 지원팀이 기본 정보를 반복해서 확인하는 일을 줄일 수 있습니다.

빌드 산출물은 변경하지 않고 로그 마지막 부분만 추출합니다:

tail -n 50 archive.log

인증서 개인 키, .p12 암호, .p8 파일, 접근 토큰, 콘솔 비밀번호를 지원 자료에 포함하지 마세요.

아직 해결되지 않았다면 점검 결과를 보내 주세요

기존 주문이나 머신에 문제가 있다면 콘솔에 로그인해 티켓을 제출하세요. 구매 전 문의, 로그인할 수 없는 문제, 추가 연락 정보가 필요한 경우에는 다음 이메일로 문의하세요: support@osxbuild.com。

아시아 태평양 및 미국 서부 시간대를 고려해 지원을 이어서 처리합니다. 답변 진행 상황은 티켓 기록이나 이메일로 안내합니다. 문의할 때 시간대와 문제 해결에 참여할 수 있는 시간을 적고, 새 점검 결과는 기존 티켓에 추가해 주세요.

문의 안내에서 상담 유형별로 준비해야 할 정보를 확인할 수 있습니다. 머신은 365일 연중 내내 정상 운영되며, 티켓 답변 시간과 노드 운영 시간은 서로 다릅니다.

로그인하여 티켓 제출 문의 안내 보기