대상 리전
싱가포르, 일본(도쿄), 한국(서울), 홍콩 중 주요 개발자 또는 아티팩트 저장 경로에 적합한 리전을 선택하세요. 개인의 위치만 기준으로 삼지 말고 코드 저장소와 의존성 소스까지의 네트워크 경로도 고려해야 합니다.
SG · JP · KR · HK먼저 리전, 모델과 사용 기간을 정한 뒤 자격 증명 강화, SSH 검증, 그래픽 데스크톱 초기화와 첫 Xcode 빌드를 진행하세요. 모든 단계의 상태를 검토 가능하게 기록합니다.
모델 선택은 칩만 보는 일이 아닙니다. 리전, 접속 방식, 툴체인 버전과 팀 담당자가 개통 후 첫 한 시간에 직접 영향을 줍니다.
싱가포르, 일본(도쿄), 한국(서울), 홍콩 중 주요 개발자 또는 아티팩트 저장 경로에 적합한 리전을 선택하세요. 개인의 위치만 기준으로 삼지 말고 코드 저장소와 의존성 소스까지의 네트워크 경로도 고려해야 합니다.
SG · JP · KR · HK가벼운 빌드는 Orb M4 16으로 시작할 수 있습니다. 더 큰 의존성 그래프와 병렬 작업은 Orb M4 24를 검토하고, 고메모리 빌드나 로컬 AI 실험에는 Orb M4 Pro를 선택하세요.
총 3가지 구성단기 검증에는 일간 또는 주간, 안정적인 파이프라인에는 월간 또는 분기 요금제를 선택하세요. 먼저 내부 검수 일정을 기록한 뒤 갱신 여부를 결정해, 담당자 없는 임시 주문에 운영 배포를 맡기지 않도록 하세요.
일 · 주 · 월 · 분기이 노드 전용 Ed25519 공개 키를 준비하고, 개인 키가 승인된 기기 또는 관리형 키 시스템에만 저장되는지 확인하세요. 개인용 키를 팀 공유 자격 증명으로 복사하지 마세요.
Ed25519 권장노드 책임자, CI 관리자와 장애 담당자를 명확히 정하세요. 각 구성원은 독립된 키를 사용하고 추가, 변경 및 폐기 기록을 남기며, 하나의 자격 증명으로 팀 전체를 관리하지 마세요.
1인 1자격 증명macOS, Xcode, 명령줄 도구, Ruby, Node, CocoaPods 및 의존성 관리자의 버전을 미리 고정하세요. 버전 요구 사항을 저장소에 기록하고 노드 초기화 시 항목별로 확인합니다.
재현 가능한 버전 필수콘솔에는 모델별 선택 가능한 리전이 표시됩니다. 카탈로그의 조합은 일반적으로 주문할 수 있지만 실제 사용 가능 여부는 콘솔의 실시간 응답을 기준으로 합니다.
Orb M4 16은 M4, 16GB 메모리, 256GB 스토리지입니다. Orb M4 24는 M4, 24GB 메모리, 512GB 스토리지입니다. Orb M4 Pro는 M4 Pro, 64GB 메모리, 2TB 스토리지입니다.
싱가포르, 일본(도쿄), 한국(서울) 또는 홍콩을 선택할 수 있으며, 기간은 일간·주간·월간·분기입니다. 팀 내부 자산 기록에 리전 코드와 갱신 시점을 기록하세요.
모델, 리전, 기간 및 추가 항목을 확인한 뒤 주문을 완료하세요. 노드 주소, 초기 접속 정보와 서비스 상태는 콘솔에서 제공되므로 승인되지 않은 채널로 전달하지 마세요.
초기 정보는 첫 번째 관리형 연결을 설정하는 데만 사용하세요. 키 검증, 접속 설정 조정과 복구 기록을 완료하기 전에는 운영 저장소나 서명 자료를 가져오지 마세요.
개발자 키는 대화형 문제 해결에 사용하고, 러너 키에는 파이프라인에 필요한 권한만 부여하세요. 구성원이 팀을 떠나면 해당 공개 키를 폐기하고 전체 공유 자격 증명을 교체하지 마세요.
네트워크, 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
그래픽 데스크톱은 디스플레이, 시스템 환경설정과 Xcode의 첫 대화형 설정에 적합합니다. 공개 페이지에는 접속 자격 증명이 제공되지 않으며, 구체적인 주소와 접속 정보는 개통 후 확인할 수 있습니다.
각 설정을 완료한 뒤 한 번 로그아웃하고 다시 연결해 새 세션에서도 구성이 유효한지 확인하세요.
현재 네트워크와 화면에 적합한 해상도를 먼저 선택하세요. 글자가 너무 작거나 화면 지연이 뚜렷하면 해상도를 낮춘 뒤 네트워크 경로를 검토하세요.
팀이 합의한 시스템 언어, 지역 형식과 시간대를 통일해 빌드 로그, 날짜 출력과 자동화 스크립트가 일관되게 작동하도록 하세요.
화면 잠금이 지속 실행이 필요한 작업을 중단하지 않는지 확인하는 동시에 무단 접근은 제한하세요. 대화형 세션과 CI 작업은 별도로 검증해야 합니다.
그래픽 세션을 한 번 의도적으로 끊은 뒤 다시 연결해 데스크톱 상태, 해상도와 실행 중인 프로세스가 예상과 일치하는지 확인하세요.
마이그레이션은 세 단계로 진행합니다. 먼저 검증 가능한 데이터를 옮기고, 다음으로 툴체인을 고정한 뒤 CI를 연결하세요. 저장소, 의존성과 자동화 설정을 한 번에 검토 없이 복사하지 마세요.
필요한 저장소, 의존성 잠금 파일, 빌드 스크립트와 테스트 데이터만 이전하세요. 임시 캐시, 오래된 아티팩트와 소유자 없는 파일은 제외하고, 이전 후 저장소 상태와 주요 파일 요약을 검증합니다.
저장소 요구 사항에 따라 Xcode, 명령줄 도구와 의존성 관리자를 설치하세요. 실제 버전 출력을 기준선 기록에 저장하고, 명확한 버전 번호 대신 “최신 버전”을 사용하지 마세요.
self-hosted runner를 등록한 후 먼저 관리형 테스트 작업을 실행하세요. 실패 로그, 캐시 정리와 복구 단계를 실행할 수 있는지 확인한 뒤 운영 브랜치를 단계적으로 연결합니다.
마이그레이션 완료 기준:동일한 커밋을 로컬과 클라우드 Mac에서 기록된 툴체인으로 빌드하고, 주요 테스트 결과가 일치하며 문서에 따라 다시 배포할 수 있어야 합니다.
첫 빌드의 목표는 가장 짧은 실행 시간이 아니라 툴체인, 의존성, 권한과 출력 경로가 모두 재현 가능한지 입증하는 것입니다.
현재 선택된 개발자 디렉터리, Xcode 버전과 사용 가능한 SDK가 프로젝트 요구 사항과 일치하는지 확인하세요.
Xcode 라이선스에 동의한 뒤 잠금 파일에 따라 Ruby, Node, CocoaPods 또는 기타 프로젝트 의존성을 정확히 설치하세요.
workspace, scheme과 configuration을 명시하고 전체 표준 출력을 별도의 로그 파일에 저장하세요.
커밋 번호, 툴체인 버전, 시작 및 종료 시간, 종료 코드와 아티팩트 위치를 기록해 이후 변경 사항과 비교할 기준으로 삼으세요.
$ 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 **
self-hosted runner를 연결한 후 먼저 전용 태그와 테스트 브랜치로 범위를 제한하고, 운영 빌드를 단계적으로 허용하세요.
작업은 환경 출력, 의존성 복원, 단위 테스트와 배포하지 않는 빌드 한 번만 실행합니다. 태그 라우팅, 로그 전체 기록과 캐시 정리가 정상인지, 실패 시 중지할 수 있는지 확인한 뒤 운영 브랜치를 연결하세요.
아래 검사 결과를 팀 운영 매뉴얼에 기록하세요. 노드는 연중 운영할 수 있지만 빌드 프로세스에는 여전히 명확한 데이터, 모니터링과 대응 책임이 필요합니다.
저장소, 빌드 구성, 키 복구 정보와 필요한 아티팩트를 노드 외부에도 복사해 두고 복구 검증을 한 번 완료해야 합니다.
복구 검증 완료최소한 디스크 여유 공간, 빌드 종료 코드, 작업 대기 시간과 러너 온라인 상태를 기록하고 이상 기준을 정의하세요.
지표 담당자 지정주 담당자와 보조 담당자 모두 노드 기록, 빌드 로그와 콘솔 티켓에 접근할 수 있으며 인수인계 경로가 문서화되어 있어야 합니다.
주·보조 담당자 확인주문 기간과 내부 확인 시점을 기록하고 특정 구성원의 기억에 의존하지 마세요. 구성 변경 전 현재 작업 일정을 먼저 평가하세요.
기간 기록 완료사용자 키, 러너 키와 해당 권한을 목록화해 다른 구성원에게 영향을 주지 않고 개별 철회할 수 있어야 합니다.
항목별 기록 1건노드 번호, 발생 시간, 재현 단계와 비식별화한 로그를 언제든 정리할 수 있고, 승인된 구성원이 콘솔에 로그인해 티켓을 제출할 수 있어야 합니다.
자료 즉시 제출 가능모델, 리전과 사용 기간을 선택하고 개통 후 이 가이드에 따라 안전한 접속, 첫 빌드와 CI 검수를 완료하세요.