문제를 찾고 빌드를 다시 시작하세요

결제가 확인되면 콘솔에 로그인해 해당 주문과 노드 상세 정보를 열고 노드 IP 주소, 사용자 이름, 초기 비밀번호를 확인하세요. 연결하기 전에 주문의 모델, 노드, 기간이 결제 시 선택한 내용과 일치하는지 확인하세요. 인도 진행 상태는 콘솔에 표시되는 최신 정보를 기준으로 합니다.

1. 01주문 확인

   주문 번호, 모델, 노드 코드를 기록해 다른 노드의 이전 접속 정보를 사용하지 않도록 하세요.

2. 02접속 정보 확인

   IP 주소와 사용자 이름 전체를 복사하고 공백이 잘못 포함되지 않았는지 확인하세요. 초기 비밀번호를 공개 로그에 붙여 넣지 마세요.

3. 03처음으로 비밀번호 변경

   로그인에 성공하면 현재 사용자 비밀번호를 변경하고, 본인이 사용하는 비밀번호 관리 도구에 저장하세요.

ssh -p 22 USER@NODE_IP
passwd

콘솔에 표시된 값으로 USER 와 NODE_IP 를 바꾸세요. 상세 정보에 다른 포트가 표시되면 해당 포트를 사용하세요. SSH에서 비밀번호를 입력할 때 문자가 표시되지 않는 것은 정상입니다.

먼저 ‘결제 요청됨’과 ‘플랫폼에서 입금 확인됨’을 구분하세요. 카드 결제 완료 화면이나 온체인 송금 제출 기록은 주문의 입금 상태를 대신하지 않습니다. 해당 주문을 새로고침하고 결제 금액과 거래 상태를 확인하세요. 화면이 아직 갱신되지 않았더라도 결제를 반복하지 마세요.

결제 내역과 주문 상태가 일치하지 않으면 콘솔 티켓에 주문 번호, 결제 수단, 금액, 결제 시간과 시간대를 첨부하세요. USDT-TRC20 결제는 트랜잭션 해시도 함께 제출하세요. 카드 결제는 결제 영수증의 참조 정보만 제공하면 됩니다. 전체 카드 번호, 보안 코드, SMS 인증 코드는 보내지 마세요.

Arm Line M4 사양은 M4 / 16GB / 256GB, Arm Grid M4 Pro 사양은 M4 Pro / 64GB / 2TB입니다. 두 모델 모두 싱가포르, 일본 도쿄, 한국 서울, 홍콩, 미국 동부의 5개 노드에서 대여할 수 있습니다. 실제 이용 가능 여부는 콘솔의 최신 정보를 기준으로 합니다.

대화형 작업은 팀과 노드 간 네트워크 경로를 우선 고려하세요. 무인 빌드는 코드, 의존성, 빌드 결과물의 전송 경로도 확인해야 합니다. 주문이 예상과 다르면 먼저 티켓으로 확인한 뒤 프로젝트와 서명 자료를 업로드하세요.

먼저 중복된 원격 세션을 종료하고 다시 연결하세요. 현재 노드에 연결 중인지 확인한 뒤 macOS가 잠금 화면이나 사용자 전환 화면에 있는지 살펴보세요. SSH에 계속 로그인할 수 있다면 빌드 로그를 먼저 저장하세요. archive 작업이 실행 중인 노드를 바로 강제로 재시동하지 마세요.

그래픽 인터페이스에 접속할 수 있다면 ‘시스템 설정 → 일반 → 공유’에서 화면 공유와 접근 허용 사용자를 확인하세요. macOS 버전에 따라 항목 위치가 다를 수 있습니다. SSH에서 현재 콘솔 사용자를 확인하면 그래픽 세션이 있는지 판단하는 데 도움이 됩니다.

stat -f '%Su' /dev/console

화면이 계속 검게 나오면 티켓에 ‘SSH 접속 가능 여부’, 화면이 검게 되기 전 수행한 작업, 클라이언트 이름과 버전을 적고 비밀번호가 포함되지 않은 스크린샷을 첨부하세요. 문제를 확인하려고 시스템 프로세스를 반복해서 종료하지 마세요.

먼저 VNC 클라이언트의 디스플레이 모드를 ‘창에 맞춤’으로 설정해 클라이언트 확대/축소와 원격 기기의 실제 해상도를 구분하세요. 원격 기기의 ‘시스템 설정 → 디스플레이’에서 현재 디스플레이 옵션을 확인할 수 있습니다. 먼저 1920 × 1080으로 테스트한 뒤 클라이언트 화면과 네트워크 상태에 맞춰 조정하세요.

지역 간 연결에서는 해상도와 색 심도를 낮추고 압축 수준을 높이는 것이 좋습니다. 먼저 텍스트 입력과 메뉴 조작이 원활한지 확인한 뒤 화질을 높이세요. 빌드 작업은 원격 데스크톱의 화질에 영향을 받지 않으므로 로그를 보기 위해 고해상도 그래픽 세션을 계속 유지할 필요는 없습니다.

‘시간 초과’는 대개 네트워크 경로나 포트에서 응답을 받지 못한 경우입니다. ‘연결 거부’는 연결 거부 응답을 받은 것이므로 포트와 서비스를 확인하세요. ‘인증 실패’는 사용자 이름, 비밀번호, 키를 확인해야 합니다. 먼저 로컬 터미널에서 점검한 뒤 필요한 로그 일부를 티켓에 첨부하세요.

nc -vz NODE_IP 22
ssh -vv -o ConnectTimeout=10 -p 22 USER@NODE_IP

회사 네트워크에서 아웃바운드 연결이 제한되어 있다면 다른 네트워크에서 다시 시도하고 두 결과를 기록하세요. 로그에는 오류 행만 남기고 실제 공인 IP, 사용자 이름, 개인 키 경로 등 민감한 정보는 가리세요. 개인 키 파일을 지원팀에 보내지 마세요.

전체 시스템을 재설치하면 호스트 지문이 바뀔 수 있습니다. 콘솔에서 노드의 신원을 먼저 확인하세요. 신원이 확인되기 전에는 호스트 키 경고를 무시하지 마세요.

원격 기기의 ‘시스템 설정 → 키보드 → 텍스트 입력’에서 입력 소스를 확인하고, ‘보조 키’에서 Command, Option, Control의 매핑을 점검하세요. Windows 키보드와 Mac 키보드는 보조 키 위치가 다릅니다. 먼저 일반 텍스트 편집기에서 기호 입력을 테스트한 다음 터미널 명령어를 입력하세요.

원격 클라이언트에서만 문제가 생기면 클라이언트의 키보드 배열과 단축키 전달 설정을 확인하세요. 클립보드 동기화가 되지 않으면 다시 연결하고 클라이언트의 클립보드 공유 옵션을 확인하세요. 공개 클립보드 서비스를 통해 비밀번호나 서명 자료를 전송하지 마세요.

먼저 현재 개발자 디렉터리와 버전을 확인하세요. 그래픽 인터페이스에서 특정 Xcode를 열었다고 해서 명령줄에서도 같은 버전을 사용한다는 뜻은 아닙니다. 전역 전환은 같은 노드의 다른 작업에도 영향을 줍니다. 공유 빌드 파이프라인이라면 개별 작업에서 DEVELOPER_DIR를 설정하는 편이 좋습니다.

xcode-select -p
xcodebuild -version
DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer \
  xcodebuild -version

경로는 노드에 실제로 설치된 Xcode를 가리켜야 합니다. 전역으로 전환해야 한다면 현재 툴체인에 의존하는 작업을 먼저 중지한 다음 sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer를 실행하세요. 처음 사용하는 구성 요소와 라이선스 요건은 대화형 세션에서 미리 확인해야 합니다.

runner 실행 사용자와 인증서가 저장된 키체인을 확인하세요. 그래픽 세션의 로그인 상태가 백그라운드 서비스에 그대로 적용되지는 않습니다. 재시작 후에는 파이프라인 정책에 따라 전용 빌드 키체인의 잠금을 해제해야 할 수도 있습니다. 다음 명령어로 서명 ID를 확인하고 대화형으로 잠금을 해제할 수 있습니다.

security find-identity -v -p codesigning
security unlock-keychain "$HOME/Library/Keychains/build.keychain-db"

예시의 빌드 키체인은 미리 만들어 두어야 합니다. 무인 작업은 CI의 비밀 변수에서 필요한 인증 정보를 읽고, 명령어 에코를 끄며, 인증서 접근 범위를 제한해야 합니다. 문제를 확인할 때는 오류 코드와 민감 정보를 가린 로그만 제공하세요. 키체인 비밀번호, 개인 키, 인증서 내보내기 비밀번호는 보내지 마세요.

먼저 프로젝트에서 검증된 서명 방식을 유지하세요. 자동 서명은 제어된 자동화 권한이 있는 워크플로에 적합합니다. 수동 프로파일은 배포 파이프라인에서 인증서, 프로파일, 내보내기 설정을 고정하려는 경우에 적합합니다. 같은 문제를 확인하는 동안 서명 방식과 Xcode 버전을 동시에 바꾸지 마세요.

수동 설정에서는 Bundle Identifier, Team ID, 인증서 유효 기간, 프로파일 유형, 내보내기 방식을 하나씩 확인하세요. 여러 target이 있는 프로젝트라면 확장 프로그램의 식별자와 권한도 점검하세요. ‘컴파일 실패’와 ‘내보내기 실패’를 구분해 기록하고, 티켓에 실패 단계, 원본 오류 메시지, 민감 정보를 가린 내보내기 설정을 첨부하세요.

먼저 코드 호스팅 플랫폼에서 runner 등록이 유효한지 확인한 다음 노드의 서비스 상태, 저장소 연결, 작업 태그를 점검하세요. GitHub Actions의 다음 명령어는 runner 설치 디렉터리에서 실행해야 합니다. GitLab Runner 명령어는 해당 프로그램이 설치되어 있어야 합니다.

./svc.sh status
gitlab-runner status
launchctl list | grep -i runner

launchd로 관리되는 서비스는 서비스 정의의 실행 사용자, 작업 디렉터리, 로그 경로를 확인하세요. 부팅 시 자동 시작과 사용자 로그인 후 시작은 서로 다릅니다. 설정한 다음 대화형 터미널 없이도 동작하는지 확인하세요. runner 등록 토큰을 티켓에 붙여 넣지 마세요.

실패한 작업에서 민감하지 않은 환경 정보를 출력해 실제 실행 사용자, 현재 디렉터리, PATH, Xcode 버전을 확인하세요. 백그라운드 서비스는 대화형 셸의 설정을 모두 자동으로 불러오지 않는 경우가 많습니다.

whoami
pwd
printf '%s\n' "$PATH"
xcodebuild -version

필요한 경로를 작업 환경에 명시하세요. 동시 실행 작업마다 작업 영역, DerivedData, 아카이브 디렉터리, 임시 파일 경로를 분리하세요. 먼저 단일 작업으로 깨끗한 빌드를 완료한 뒤 동시 실행 수를 점차 늘리세요. 두 배포 작업이 같은 내보내기 디렉터리나 서명 리소스를 동시에 수정하지 않도록 하세요.

반드시 TRC20 네트워크를 선택하세요. 현재 주문에 표시된 수취 주소, 결제 금액, 결제 안내를 정확히 확인하세요. 다른 주문이나 예전 스크린샷의 주소를 재사용하지 마세요. 송금 전에 지갑에서 올바른 네트워크를 선택했는지 확인하세요.

온체인 확인은 보통 몇 분 정도 걸리므로 거래 상태를 확인할 시간을 두세요. 실제 소요 시간은 네트워크 혼잡도, 지갑의 브로드캐스트, 결제 게이트웨이가 요구하는 확인 횟수에 따라 달라지며, 정해진 입금 시간을 보장하지 않습니다. 주문에 표시된 확인 결과를 따르세요. 송금을 제출했다고 해서 플랫폼에서 입금이 확인된 것은 아닙니다.

거래가 확인됐는데도 주문이 갱신되지 않으면 주문 번호, 트랜잭션 해시, 송금 금액, 시간과 시간대를 제출하세요. 송금을 반복하지 말고 지갑 복구 문구나 개인 키를 티켓에 제공하지 마세요.

Visa / Mastercard / Amex 결제는 Stripe에서 처리합니다. 결제 후 콘솔로 돌아와 해당 청구 상태와 USD 금액을 확인하세요. 은행에 거래 내역이 표시되지만 청구 상태가 일치하지 않으면 영수증을 보관해 티켓을 접수하세요. 결제를 연속으로 반복하지 마세요.

주문 번호, 결제 시간과 시간대, 금액, 실패 안내 또는 결제 참조 번호를 제공하세요. 스크린샷에는 전체 카드 번호, 보안 코드, 개인 민감 정보가 보이지 않도록 가리세요. 지원팀은 SMS 인증 코드가 필요하지 않습니다.

대여 기간은 일, 주, 월, 분기 단위로 제공됩니다. 시작 시간, 종료 시간, 갱신 작업, 주문 상태는 콘솔의 해당 주문 및 청구 내역을 기준으로 확인하세요. 현지에서 송금을 시작한 시간을 바탕으로 서비스 종료 시각을 직접 계산하지 마세요.

만료 전에 주문의 갱신 상태와 청구 금액을 확인하세요. 미결제 상태에서도 서비스가 연장될 것이라고 가정하지 마세요. runner를 일시 중지하거나 SSH 연결을 끊어도 대여가 종료되는 것은 아닙니다. 구성을 변경해야 한다면 티켓으로 가능한 방법을 먼저 확인한 뒤 프로젝트 이전과 빌드 중단을 계획하세요.

대여 종료 후 노드의 모든 데이터가 삭제됩니다. 서비스가 끝나기 전에 소스 코드, 아카이브 결과물, 필요한 로그, 자체 설정 백업을 다른 곳으로 옮기고 백업을 복원할 수 있는지 확인하세요. 노드 디스크를 유일한 사본으로 사용하지 마세요.

runner 등록을 해제하고 노드에서 사용한 자동화 토큰을 폐기한 뒤 자체 보안 정책에 따라 서명 자료를 처리하세요. 다른 노드로 이전하려면 새 노드 검증을 마친 다음 배포 작업을 전환하세요.