노드 인도부터 빌드 기준선까지

클라우드 Mac을 개발 및 CI 워크플로에 연결하세요

먼저 리전, 모델과 사용 기간을 정한 뒤 자격 증명 강화, SSH 검증, 그래픽 데스크톱 초기화와 첫 Xcode 빌드를 진행하세요. 모든 단계의 상태를 검토 가능하게 기록합니다.

노드 유형
전용 Apple Silicon 물리 노드
제공 리전
SG · JP · KR · HK
완료 목표
첫 빌드 및 CI 테스트 작업 통과
ORB / NODE COMMISSIONING RUNBOOK 01
선택 강화 연결 빌드 CI 연결
대상 노드 Apple Silicon / 전용 물리 머신
리전
선택 대기
SSH 키
입력 대기
Xcode 기준선
검증 대기
러너
등록 대기
인도 판정 모든 검사를 통과한 후에만 운영 작업을 맡기세요
주소, 자격 증명 및 실시간 사용 가능 상태는 콘솔 응답을 기준으로 합니다 365 DAYS
시작 전 확인

먼저 6가지 입력 정보를 준비하세요

모델 선택은 칩만 보는 일이 아닙니다. 리전, 접속 방식, 툴체인 버전과 팀 담당자가 개통 후 첫 한 시간에 직접 영향을 줍니다.

01

대상 리전

싱가포르, 일본(도쿄), 한국(서울), 홍콩 중 주요 개발자 또는 아티팩트 저장 경로에 적합한 리전을 선택하세요. 개인의 위치만 기준으로 삼지 말고 코드 저장소와 의존성 소스까지의 네트워크 경로도 고려해야 합니다.

SG · JP · KR · HK
02

노드 모델

가벼운 빌드는 Orb M4 16으로 시작할 수 있습니다. 더 큰 의존성 그래프와 병렬 작업은 Orb M4 24를 검토하고, 고메모리 빌드나 로컬 AI 실험에는 Orb M4 Pro를 선택하세요.

총 3가지 구성
03

사용 기간

단기 검증에는 일간 또는 주간, 안정적인 파이프라인에는 월간 또는 분기 요금제를 선택하세요. 먼저 내부 검수 일정을 기록한 뒤 갱신 여부를 결정해, 담당자 없는 임시 주문에 운영 배포를 맡기지 않도록 하세요.

일 · 주 · 월 · 분기
04

SSH 공개 키

이 노드 전용 Ed25519 공개 키를 준비하고, 개인 키가 승인된 기기 또는 관리형 키 시스템에만 저장되는지 확인하세요. 개인용 키를 팀 공유 자격 증명으로 복사하지 마세요.

Ed25519 권장
05

팀 접속 목록

노드 책임자, CI 관리자와 장애 담당자를 명확히 정하세요. 각 구성원은 독립된 키를 사용하고 추가, 변경 및 폐기 기록을 남기며, 하나의 자격 증명으로 팀 전체를 관리하지 마세요.

1인 1자격 증명
06

macOS 툴체인

macOS, Xcode, 명령줄 도구, Ruby, Node, CocoaPods 및 의존성 관리자의 버전을 미리 고정하세요. 버전 요구 사항을 저장소에 기록하고 노드 초기화 시 항목별로 확인합니다.

재현 가능한 버전 필수
주문 및 인도

세 번의 선택으로 노드 구성을 정하세요

콘솔에는 모델별 선택 가능한 리전이 표시됩니다. 카탈로그의 조합은 일반적으로 주문할 수 있지만 실제 사용 가능 여부는 콘솔의 실시간 응답을 기준으로 합니다.

  1. 01

    3가지 모델 중 하나 선택

    Orb M4 16은 M4, 16GB 메모리, 256GB 스토리지입니다. Orb M4 24는 M4, 24GB 메모리, 512GB 스토리지입니다. Orb M4 Pro는 M4 Pro, 64GB 메모리, 2TB 스토리지입니다.

  2. 02

    리전 및 사용 기간 선택

    싱가포르, 일본(도쿄), 한국(서울) 또는 홍콩을 선택할 수 있으며, 기간은 일간·주간·월간·분기입니다. 팀 내부 자산 기록에 리전 코드와 갱신 시점을 기록하세요.

  3. 03

    주문 확인 후 인도 기록 대기

    모델, 리전, 기간 및 추가 항목을 확인한 뒤 주문을 완료하세요. 노드 주소, 초기 접속 정보와 서비스 상태는 콘솔에서 제공되므로 승인되지 않은 채널로 전달하지 마세요.

노드 자격 증명 및 보안

접근 지점을 먼저 잠근 뒤 개발 환경을 설치하세요

초기 정보는 첫 번째 관리형 연결을 설정하는 데만 사용하세요. 키 검증, 접속 설정 조정과 복구 기록을 완료하기 전에는 운영 저장소나 서명 자료를 가져오지 마세요.

FIRST ACCESS RECORD 첫 로그인 후 실행

임시 접속을 감사 가능한 진입점으로 전환하세요

  • 인도 자료 확인 노드 번호, 주소, 포트와 리전이 주문과 일치하는지 확인하고 결과를 팀 자산 목록에 기록하세요.
  • 독립 SSH 공개 키 등록 관리자, 개발자와 자동화 러너에 서로 다른 키를 할당해 사용자 접속과 CI 접속이 같은 개인 키를 공유하지 않도록 하세요.
  • 접속 설정 조정 키 로그인이 작동하는지 확인한 뒤 임시 자격 증명의 사용 범위를 줄이세요. 변경할 때마다 검증된 복구 경로를 하나씩 남기세요.
  • 복구 정보 저장 노드 번호, 승인된 구성원, 키 지문, 복구 담당자와 마지막 검증 시간을 기록하세요. 복구 자료는 노드 자체와 분리해 보관해야 합니다.
자격 증명 경계

사용자와 자동화 분리

개발자 키는 대화형 문제 해결에 사용하고, 러너 키에는 파이프라인에 필요한 권한만 부여하세요. 구성원이 팀을 떠나면 해당 공개 키를 폐기하고 전체 공유 자격 증명을 교체하지 마세요.

독립 지문 추적 가능
복구 검증

변경 전 롤백 경로를 먼저 확인하세요

네트워크, SSH 또는 그래픽 세션 설정을 변경하기 전에 현재 사용 가능한 세션을 유지하고, 콘솔의 복구 정보가 두 번째 담당자에게 검토되었는지 확인하세요.

연결 문제 해결 단계 보기
첫 SSH 연결

먼저 지문을 검증하고 시스템 상태를 확인하세요

호스트 지문 확인을 건너뛰지 마세요. 주소와 포트는 콘솔에서 가져오고, 신뢰할 수 있는 지문은 팀이 확인한 인도 기록과 대조해야 합니다.

노드 접속 기록 실행 대기
# 콘솔 주소를 확인한 후에만 변수 설정
export NODE_HOST="NODE_ADDRESS"
export NODE_PORT="22"

# 전용 개인 키 권한 수정
chmod 600 ~/.ssh/orbvps_node

# 호스트 지문을 읽어 표시한 후 인도 기록과 대조
ssh-keyscan -p "$NODE_PORT" "$NODE_HOST" \
  | ssh-keygen -lf -

# 첫 연결 시작
ssh -p "$NODE_PORT" \
  -i ~/.ssh/orbvps_node \
  nodeadmin@"$NODE_HOST"

# 로그인 후 하드웨어, 시스템 및 디스크 상태 확인
$ uname -m
arm64
$ sw_vers
$ sysctl -n machdep.cpu.brand_string
$ df -h /
$ uptime
SSH ACCEPTANCE 4 CHECKS
  1. 지문 일치 스캔 결과가 신뢰할 수 있는 인도 기록과 일치해야 합니다. 일치하지 않으면 연결을 중지하고 콘솔 티켓으로 확인하세요.
  2. 키 권한 정상 개인 키 권한이 너무 넓으면 SSH가 로드를 거부합니다. 현재 사용자만 읽고 쓸 수 있도록 권한을 수정하세요.
  3. 아키텍처 arm64 로그인 후 프로세서 아키텍처와 칩 정보를 확인해 잘못된 호스트에 툴체인을 계속 배포하지 않도록 하세요.
  4. 디스크 및 가동 시간 확인 가능 루트 볼륨 여유 공간, 시스템 버전과 가동 시간을 기록해 이후 빌드 장애를 조사할 때의 초기 상태로 삼으세요.
그래픽 데스크톱 초기화

VNC 세션을 재현 가능한 작업 환경으로 조정하세요

그래픽 데스크톱은 디스플레이, 시스템 환경설정과 Xcode의 첫 대화형 설정에 적합합니다. 공개 페이지에는 접속 자격 증명이 제공되지 않으며, 구체적인 주소와 접속 정보는 개통 후 확인할 수 있습니다.

DESKTOP BASELINE 그래픽 세션 검수 목록

각 설정을 완료한 뒤 한 번 로그아웃하고 다시 연결해 새 세션에서도 구성이 유효한지 확인하세요.

01

디스플레이 및 해상도

현재 네트워크와 화면에 적합한 해상도를 먼저 선택하세요. 글자가 너무 작거나 화면 지연이 뚜렷하면 해상도를 낮춘 뒤 네트워크 경로를 검토하세요.

02

시스템 언어 및 시간대

팀이 합의한 시스템 언어, 지역 형식과 시간대를 통일해 빌드 로그, 날짜 출력과 자동화 스크립트가 일관되게 작동하도록 하세요.

03

화면 잠금 정책

화면 잠금이 지속 실행이 필요한 작업을 중단하지 않는지 확인하는 동시에 무단 접근은 제한하세요. 대화형 세션과 CI 작업은 별도로 검증해야 합니다.

04

연결 끊김 및 재연결

그래픽 세션을 한 번 의도적으로 끊은 뒤 다시 연결해 데스크톱 상태, 해상도와 실행 중인 프로세스가 예상과 일치하는지 확인하세요.

마이그레이션 경로

로컬 Mac에서 안정적인 클라우드 빌드 노드로 이전하세요

마이그레이션은 세 단계로 진행합니다. 먼저 검증 가능한 데이터를 옮기고, 다음으로 툴체인을 고정한 뒤 CI를 연결하세요. 저장소, 의존성과 자동화 설정을 한 번에 검토 없이 복사하지 마세요.

LOCAL
01

데이터 및 저장소 이전

필요한 저장소, 의존성 잠금 파일, 빌드 스크립트와 테스트 데이터만 이전하세요. 임시 캐시, 오래된 아티팩트와 소유자 없는 파일은 제외하고, 이전 후 저장소 상태와 주요 파일 요약을 검증합니다.

  • 기본 브랜치 및 원격 주소 확인
  • 서브모듈 및 대용량 파일 의존성 확인
  • 테스트 데이터 비식별화
TOOLCHAIN
02

툴체인 설치 및 고정

저장소 요구 사항에 따라 Xcode, 명령줄 도구와 의존성 관리자를 설치하세요. 실제 버전 출력을 기준선 기록에 저장하고, 명확한 버전 번호 대신 “최신 버전”을 사용하지 마세요.

  • Xcode 및 SDK 버전 기록
  • 잠금 파일에 따라 의존성 복원
  • Shell 및 런타임 경로 고정
CLOUD MAC
03

CI 연결 및 롤백 검증

self-hosted runner를 등록한 후 먼저 관리형 테스트 작업을 실행하세요. 실패 로그, 캐시 정리와 복구 단계를 실행할 수 있는지 확인한 뒤 운영 브랜치를 단계적으로 연결합니다.

  • 전용 태그로 작업 범위 제한
  • 캐시 적중 및 정리 검증
  • 러너 중지 및 롤백 리허설

마이그레이션 완료 기준:동일한 커밋을 로컬과 클라우드 Mac에서 기록된 툴체인으로 빌드하고, 주요 테스트 결과가 일치하며 문서에 따라 다시 배포할 수 있어야 합니다.

첫 빌드

검토 가능한 성공 기준선을 생성하세요

첫 빌드의 목표는 가장 짧은 실행 시간이 아니라 툴체인, 의존성, 권한과 출력 경로가 모두 재현 가능한지 입증하는 것입니다.

  1. 01

    Xcode 경로 및 버전 확인

    현재 선택된 개발자 디렉터리, Xcode 버전과 사용 가능한 SDK가 프로젝트 요구 사항과 일치하는지 확인하세요.

  2. 02

    라이선스 동의 및 의존성 설치

    Xcode 라이선스에 동의한 뒤 잠금 파일에 따라 Ruby, Node, CocoaPods 또는 기타 프로젝트 의존성을 정확히 설치하세요.

  3. 03

    관리형 빌드 실행

    workspace, scheme과 configuration을 명시하고 전체 표준 출력을 별도의 로그 파일에 저장하세요.

  4. 04

    기준선 기록 저장

    커밋 번호, 툴체인 버전, 시작 및 종료 시간, 종료 코드와 아티팩트 위치를 기록해 이후 변경 사항과 비교할 기준으로 삼으세요.

첫 빌드 기준선 명령 예시
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer

$ xcodebuild -version
Xcode <PROJECT_VERSION>

$ sudo xcodebuild -license accept
$ bundle install
$ bundle exec pod install

$ mkdir -p build-logs
$ set -o pipefail
$ xcodebuild \
  -workspace App.xcworkspace \
  -scheme App \
  -configuration Release \
  clean build \
  | tee build-logs/first-success.log

** BUILD SUCCEEDED **
CI 연결

러너가 실행해야 할 작업만 받도록 하세요

self-hosted runner를 연결한 후 먼저 전용 태그와 테스트 브랜치로 범위를 제한하고, 운영 빌드를 단계적으로 허용하세요.

RUNNER PROFILE

러너 ID

이름
orb-m4-ci-01
태그
macos · arm64 · xcode
작업 디렉터리
/Users/runner/work
동시성 정책
단일 작업부터 검증 시작
ACCESS POLICY

권한 및 키

  • 독립 러너 사용자 자동화 작업이 관리자용 대화형 계정을 장기간 사용하지 않도록 하세요.
  • 용도별 키 분리 저장소 읽기, 아티팩트 쓰기와 배포 작업에 각각 필요한 최소 권한만 부여하세요.
  • 민감한 값을 저장소에 기록하지 않기 관리형 CI 변수로 주입하고 로그에 전체 값이 표시되지 않는지 확인하세요.
CACHE CONTROL

캐시 및 복구

  • 캐시 키에 버전 포함 잠금 파일 요약, 아키텍처와 툴체인 버전을 캐시 키에 포함하세요.
  • 클린 빌드 허용 모든 파이프라인은 캐시를 비운 뒤에도 전체 빌드를 한 번 완료할 수 있어야 합니다.
  • 작업 디렉터리 증가 제한 DerivedData, 아카이브와 임시 아티팩트가 차지하는 공간을 정기적으로 확인하세요.
CONTROLLED TEST JOB

예측 가능한 테스트 작업부터 실행하세요

작업은 환경 출력, 의존성 복원, 단위 테스트와 배포하지 않는 빌드 한 번만 실행합니다. 태그 라우팅, 로그 전체 기록과 캐시 정리가 정상인지, 실패 시 중지할 수 있는지 확인한 뒤 운영 브랜치를 연결하세요.

예상 종료 코드
0 / 성공
필수 보관 항목
로그, 커밋 번호, 아티팩트 요약
실패 처리
운영 작업을 중지하고 기준선 확인으로 돌아가기
출시 전 확인

6가지 상태를 모두 명확히 한 후에만 운영 빌드를 실행하세요

아래 검사 결과를 팀 운영 매뉴얼에 기록하세요. 노드는 연중 운영할 수 있지만 빌드 프로세스에는 여전히 명확한 데이터, 모니터링과 대응 책임이 필요합니다.

백업

저장소, 빌드 구성, 키 복구 정보와 필요한 아티팩트를 노드 외부에도 복사해 두고 복구 검증을 한 번 완료해야 합니다.

복구 검증 완료

모니터링

최소한 디스크 여유 공간, 빌드 종료 코드, 작업 대기 시간과 러너 온라인 상태를 기록하고 이상 기준을 정의하세요.

지표 담당자 지정

알림 담당자

주 담당자와 보조 담당자 모두 노드 기록, 빌드 로그와 콘솔 티켓에 접근할 수 있으며 인수인계 경로가 문서화되어 있어야 합니다.

주·보조 담당자 확인

갱신 시점

주문 기간과 내부 확인 시점을 기록하고 특정 구성원의 기억에 의존하지 마세요. 구성 변경 전 현재 작업 일정을 먼저 평가하세요.

기간 기록 완료

접근 권한 철회

사용자 키, 러너 키와 해당 권한을 목록화해 다른 구성원에게 영향을 주지 않고 개별 철회할 수 있어야 합니다.

항목별 기록 1건

장애 문의 경로

노드 번호, 발생 시간, 재현 단계와 비식별화한 로그를 언제든 정리할 수 있고, 승인된 구성원이 콘솔에 로그인해 티켓을 제출할 수 있어야 합니다.

자료 즉시 제출 가능
배포 준비

검증 가능한 클라우드 Mac 한 대에서 시작하세요

모델, 리전과 사용 기간을 선택하고 개통 후 이 가이드에 따라 안전한 접속, 첫 빌드와 CI 검수를 완료하세요.