먼저 연결하고, 그다음 빌드하세요

첫 SSH 연결부터
첫 archive까지

노드를 처음 받은 개발자를 위한 안내입니다. 먼저 연결과 도구 체인을 확인한 다음 파이프라인에 연결하세요. 아래 명령은 작업 예시이며 실제 노드 상태를 나타내지 않습니다.

기존 노드는 1단계부터 시작하세요. 접속 정보, 만료 시각, 실제 사용 가능 여부는 콘솔에 표시되는 최신 정보를 기준으로 합니다.

01 / 연결

먼저 내 물리 노드인지 확인하세요

콘솔에서 해당 인스턴스를 열고 노드, IP, SSH 포트와 사용자 이름을 확인하세요. 이전 지원 티켓의 접속 정보를 복사하거나 로그인 비밀번호를 저장소에 기록하지 마세요.

  1. 01

    인스턴스 정보 확인

    콘솔에서 인스턴스 세부 정보를 열고 IP, 포트, 현재 접속 정보를 기록하세요. 아래에서 이 값은 NODE_IP로,SSH_PORT 와 NODE_USER 는 각각 포트와 사용자 이름을 나타냅니다. 실행 전에 로컬 터미널에서 값을 지정하고, 변수명을 주소로 그대로 사용하지 마세요.

  2. 02

    호스트 지문 확인

    처음 연결하면 호스트를 신뢰할지 묻는 메시지가 표시됩니다. 표시된 지문을 신뢰할 수 있는 경로로 받은 정보와 대조한 뒤 확인하세요. 대조할 수 없다면 먼저 지원 티켓을 제출하세요. 호스트 확인을 끄는 옵션으로 메시지를 우회하지 마세요.

  3. 03

    비밀번호 변경 및 공개 키 설정

    처음 로그인한 뒤 passwd 를 실행해 현재 사용자의 비밀번호를 변경하세요. 공개 키는 노드에 복사해도 되지만 개인 키는 항상 로컬에 보관하세요. 현재 연결은 유지한 채 별도 터미널에서 공개 키 로그인이 되는지 확인한 다음 인증 정책을 조정하세요.

접속 정보를 별칭으로 관리하기

로컬의 ~/.ssh/config 에 아래 설정을 추가하고, 대문자로 된 세 항목을 인스턴스 세부 정보의 실제 값으로 바꾸세요. IdentityFile 은 로컬에 있는 개인 키 파일을 가리킵니다. 아직 키를 만들지 않았다면 오른쪽의 생성 명령을 먼저 실행하세요.

Host armshell-dev
  HostName NODE_IP
  User NODE_USER
  Port SSH_PORT
  IdentityFile ~/.ssh/armshell_ed25519
  IdentitiesOnly yes
  ServerAliveInterval 30
  ServerAliveCountMax 3

저장한 뒤 ssh armshell-dev 로 연결하세요. 호스트 지문이 바뀌었다면 인스턴스가 재배포되었는지 먼저 확인하세요. 기록을 바로 삭제하고 계속 로그인하지 마세요.

개인 키가 아닌 공개 키 업로드

아래 공개 키 등록 명령은 로컬에서 실행합니다. 별칭을 설정했고 비밀번호 로그인이 가능해야 합니다. 키에 암호를 설정하고 로컬에 안전한 백업을 보관하세요.

ssh-keygen -t ed25519 -f ~/.ssh/armshell_ed25519
cat ~/.ssh/armshell_ed25519.pub | ssh armshell-dev \
'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'
ssh -o PreferredAuthentications=publickey armshell-dev

로그인한 뒤 whoami와 sw_vers 및 df -h를 실행해 사용자, 시스템 버전, 사용 가능한 디스크 공간을 확인하세요. 권한이 예상과 다르면 개발 도구를 설치하기 전에 먼저 권한 문제를 해결하세요.

02 / 도구 체인

먼저 대화형 빌드를 확인하고 CI로 넘기세요

대상 Xcode가 설치되어 있고 최초 실행 설정까지 완료되었는지 확인하세요. 아래는 명령과 출력 형식의 예시입니다. 버전, SDK, 인증서 이름은 노드와 프로젝트에 따라 다르며 사전 설치 목록을 뜻하지 않습니다.

dev@armshell-tokyo
$ sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer

$ sudo xcodebuild -runFirstLaunch
$ xcodebuild -showsdks
iOS SDKs:
    iOS 18.0                       -sdk iphoneos18.0
iOS Simulator SDKs:
    Simulator - iOS 18.0           -sdk iphonesimulator18.0

$ bundle exec fastlane match development --readonly
[09:12:01]: Successfully decrypted certificates repo
[09:12:03]: Installing certificate...
[09:12:05]: Installing provisioning profile...
[09:12:06]: All required keys, certificates and provisioning profiles are installed

$ xcodebuild -workspace App.xcworkspace -scheme App \
    -configuration Release -destination 'generic/platform=iOS' \
    -archivePath "$HOME/build/App.xcarchive" archive
** ARCHIVE SUCCEEDED **

버전 선택은 노드 단위로 적용됩니다

xcode-select 은 기본 개발자 디렉터리를 변경하므로 같은 노드의 다른 작업에도 영향을 줍니다. 여러 버전을 병행할 때는 작업별로 DEVELOPER_DIR를 설정하고, 로그 첫 부분에 xcodebuild -version을 출력해 인수인계 후 잘못된 도구 체인을 사용하는 일을 방지하세요.

현재 세션에서 키체인을 잠금 해제할 수 있어야 합니다

이 예시는 프로젝트에 fastlane, Gemfile, 인증서 저장소 접근 권한이 설정되어 있다고 가정합니다. 먼저 읽기 전용 모드로 기존 인증서를 동기화하세요. 빌드 사용자는 자신의 키체인을 읽고 잠금 해제할 수 있어야 합니다. 서명에 실패하면 인증서와 프로비저닝 프로파일을 반복해서 새로 만들기보다 권한과 프로파일을 먼저 확인하세요.

archive 성공이 배포 완료를 뜻하지는 않습니다

먼저 워크스페이스와 scheme 이름을 확인한 다음 archive 결과물을 점검하세요. 설치 패키지를 내보내려면 배포 방식에 맞는 내보내기 설정도 필요합니다. 첫 빌드가 성공하면 Xcode 버전, 의존성 잠금 파일, 전체 명령을 기록한 뒤 파이프라인으로 옮기세요.

03 / 그래픽 인터페이스

화면 조작이 필요할 때 데스크톱 세션을 여세요

명령줄은 전송, 빌드, 로그 확인에 적합합니다. 도구를 처음 설정하거나 키체인 알림을 확인하거나 인터페이스를 디버깅할 때 macOS 그래픽 인터페이스를 사용하세요. 데스크톱 접속은 로그인 후 인스턴스 세부 정보에서 제공됩니다.

활성화 및 권한

인스턴스에서 제공하는 데스크톱 접속 경로로 시스템에 들어간 뒤, ‘시스템 설정 → 일반 → 공유’에서 ‘화면 공유’를 확인하세요. 지정된 사용자만 접근하도록 설정하고 모든 사용자 접근은 허용하지 마세요. 화면 공유와 원격 관리가 동시에 사용할 수 없다면 두 설정을 함께 변경하기 전에 현재 설정을 먼저 확인하세요.

처음 데스크톱에 접속할 수 없다면 콘솔에서 지원 티켓을 제출해 확인을 요청하세요. 익숙하지 않은 상태에서 시스템의 원격 접근 서비스를 일괄 변경하지 마세요.

콘솔에 로그인해 지원 티켓 제출

클라이언트 및 연결 경로

로컬 기기가 macOS라면 기본 ‘화면 공유’ 클라이언트를 사용할 수 있습니다. 다른 시스템에서는 VNC 프로토콜과 보안 연결을 지원하는 클라이언트를 사용하세요. 인스턴스에서 제공하는 안전한 접속 방식을 우선 사용하고, 데스크톱 서비스를 신뢰할 수 없는 네트워크에 직접 노출하지 마세요.

노드의 VNC 서비스가 로컬 포트 5900에서 수신 대기 중임을 확인했다면 아래 SSH 터널을 사용해 클라이언트를 로컬 127.0.0.1:5901에 연결하세요.

ssh -N -L 5901:127.0.0.1:5900 armshell-dev

먼저 화면 전송 부담 줄이기

처음 연결할 때는 1440 × 900 해상도와 단일 화면으로 시작하고 불필요한 애니메이션을 끄는 것이 좋습니다. 대역폭이 제한적이라면 화질이나 프레임률을 낮추세요. 해상도를 높여도 빌드 속도는 빨라지지 않으며 화면 전송량만 늘어납니다.

코덱과 화면 변화에 따라 대역폭 사용량이 달라지므로 모든 작업에 적용할 수 있는 고정 대역폭은 보장되지 않습니다. 연결이 끊기거나 버벅이면 대용량 파일 업로드를 잠시 멈추고 SSH에도 지연이 있는지 비교해 보세요.

데스크톱과 명령줄은 같은 단독 물리 노드에서 사용합니다.
04 / 지속적 통합

방금 확인한 환경에서 Runner를 실행하세요

전용 macOS 빌드 사용자로 Runner를 등록하세요. 먼저 동시 작업 수를 1로 설정해 의존성, 서명, 결과물 전송을 확인한 다음 메모리와 디스크 사용량에 따라 동시 실행 수를 늘리세요. 신뢰할 수 없는 병합 요청을 배포 자격 증명이 있는 실행기에 맡기지 마세요.

GitLab: shell executor 등록

먼저 Apple Silicon에 적합한 GitLab Runner를 설치하세요. 아래 명령은 실행 파일이 현재 사용자의 PATH에 있고, CI 관리 화면에서 Runner를 생성해 서버 주소와 인증 토큰을 발급받았다고 가정합니다.

read -r CI_SERVER_URL
read -rs RUNNER_TOKEN
gitlab-runner register --non-interactive \
  --url "$CI_SERVER_URL" \
  --token "$RUNNER_TOKEN" \
  --executor shell
unset RUNNER_TOKEN
gitlab-runner verify
gitlab-runner install
gitlab-runner start
gitlab-runner status

CI 관리 화면에서 명확한 태그를 설정하세요. 예를 들면 macos-arm64 와 프로젝트에서 요구하는 Xcode 버전입니다. 작업 태그와 Runner 태그가 일치해야 합니다. 정식 빌드 전에 whoami와 xcodebuild -version을 실행해 확인하세요.

GitHub Actions: 자체 호스팅 Runner 등록

저장소 또는 조직의 Runner 설정에서 macOS ARM64 설치 패키지와 해당 등록 명령을 확인하세요. 다운로드, 검증, 압축 해제를 마친 뒤 압축을 푼 디렉터리로 이동해 아래 명령을 실행합니다. 두 변수는 설정 페이지에서 확인할 수 있습니다.

read -r REPOSITORY_URL
read -rs RUNNER_TOKEN
./config.sh --url "$REPOSITORY_URL" \
  --token "$RUNNER_TOKEN" \
  --labels macos-arm64 --unattended
unset RUNNER_TOKEN
./svc.sh install
./svc.sh start
./svc.sh status

워크플로에서는 runs-on: [self-hosted, macOS, ARM64]를 사용하고, 사용자 지정 태그가 있다면 함께 지정하세요. 등록 토큰을 설정했다고 서비스가 실행되는 것은 아닙니다. 설정을 마친 뒤에도 서비스 상태와 실제 테스트 작업을 확인해야 합니다.

launchd 상시 실행: 서비스 설치 후 실제 로드 항목 확인

위의 서비스 설치 명령은 각 Runner 구현에 맞는 macOS 서비스 설정을 생성합니다. 각 Runner에서 제공하는 관리 명령을 우선 사용하고, 같은 Runner를 실행하는 서비스를 별도로 중복 설정하지 마세요.

사용자별 LaunchAgent는 보통 해당 사용자가 로그인할 때 로드됩니다. 재시작 후에도 무인 실행이 필요하다면 Runner의 서비스 지원 방식, 로그인 상태, 키체인 정책을 먼저 확인하세요. ‘현재 온라인’이라고 해서 재시작 후에도 반드시 작동하는 것은 아닙니다.

ls "$HOME/Library/LaunchAgents"
launchctl print "gui/$(id -u)"
gitlab-runner status
./svc.sh status

실제 Runner 디렉터리에서 해당하는 점검 명령을 각각 실행하세요. CI의 비대화형 환경에는 터미널의 PATH가 없을 수 있습니다. Homebrew, Ruby, Xcode 경로를 버전 관리되는 빌드 스크립트에 지정하고 토큰이 로그에 출력되지 않도록 하세요.

05 / 데이터

변경된 항목만 동기화하고 노드 외부에 백업하세요

소스 코드는 저장소에서 clone하는 방식을 우선 사용하세요. 큰 디렉터리, 빌드 결과물, 저장소에 넣기 적합하지 않은 파일은 SSH를 통한 rsync 증분 동기화로 전송할 수 있습니다. 대여한 노드는 작업 환경이지 데이터의 유일한 사본이 되어서는 안 됩니다.

먼저 미리 본 뒤 업로드하세요

양쪽에서 먼저 rsync --version을 확인하세요. 아래는 일반적인 기본 옵션을 사용합니다. 경로 끝에 슬래시를 붙이면 디렉터리 안의 내용을 동기화하며, 제외 항목은 프로젝트에 맞게 조정하세요. 미리보기 결과를 모두 확인한 뒤 -n을 제거하세요.

rsync -avzn --exclude '.git/' --exclude 'build/' \
  ./project/ armshell-dev:~/work/project/

rsync -avz --exclude '.git/' --exclude 'build/' \
  ./project/ armshell-dev:~/work/project/

rsync -avz armshell-dev:~/build/ ./artifacts/

확인 없이 --delete를 추가하지 마세요. 대상에만 있는 파일이 삭제됩니다. 키, 인증서, 민감한 데이터가 포함된 로그는 접근 권한을 따로 관리하고 전체 작업 디렉터리에 넣어 공개적으로 배포하지 마세요.

Thunderbolt 5 연결은 인터넷 속도 향상 기능이 아닙니다

Thunderbolt 5 병렬 연결은 여러 노드가 협력해 대용량 파일을 처리해야 하는 경우에 사용합니다. 로컬 네트워크와 노드 사이의 인터넷 연결을 대체하지 않으며, 모든 rsync 작업을 자동으로 빠르게 만들어 주지도 않습니다. 주문 전에 사용할 노드, 데이터 규모, 작업 흐름을 설명하고 적합한 연결 방식을 확인하세요.

작업 공간이 더 필요하다면 +1TB SSD 또는 +2TB SSD 추가를 검토할 수 있습니다. 디스크를 확장해도 백업이 되는 것은 아닙니다. 코드, 결과물, 인증서는 노드 외부에도 사본을 보관해야 합니다.

배포할 때마다 전송된 파일을 읽을 수 있는지 확인하고 중요한 결과물은 체크섬을 기록하세요. 만료 전에 동기화 명령의 성공 메시지만 확인하지 말고 별도의 복구 테스트도 한 번 이상 완료하세요.

06 / 계정 및 이용 기간

출시 전 점검 목록에 만료일 확인 추가

콘솔에서 주문, 인스턴스 만료 시각, 청구 내역과 갱신 작업을 확인하세요. 노드는 365일 내내 정상적으로 운영됩니다. 이용 기간과 주문 상태는 콘솔 기록을 기준으로 관리해야 합니다.

이용 기간과 시간 확인

서비스는 일간, 주간, 월간, 분기별로 이용할 수 있습니다. 콘솔에 표시된 시작·종료 시각과 시간대를 확인하고 빌드, 결과물 전송, 백업에 필요한 여유를 확보하세요. 장시간 작업이 진행 중일 때까지 갱신을 미루거나 자동 결제가 반드시 된다고 가정하지 마세요.

주문 상세 정보와 만료 시각을 기준으로 확인하세요.

변경 내용을 확인한 뒤 이전하세요

기종 업그레이드, 저장 공간 추가, 이용 기간 변경 전에 현재 주문에서 가능한 작업, 견적, 적용 방식을 확인하세요. 모든 변경이 기존 노드에서 즉시 적용된다고 가정하지 마세요. 환경을 이전해야 한다면 먼저 의존성 목록, 서명 설정, 데이터 사본을 보관하세요.

환산 방식이나 적용 시점이 명확하지 않다면 지원 티켓으로 확인하세요.

결제 및 입금 확인

결제 수단은 USDT-TRC20 및 Visa / Mastercard / Amex(Stripe)만 지원하며, USD로 결제됩니다. 실제 사용 가능한 결제 게이트웨이는 백엔드 응답을 기준으로 합니다. 온체인 결제는 네트워크, 금액, 수신 정보를 확인하고 카드 결제는 청구 페이지의 인증 절차를 완료하세요.

상태가 갱신되지 않으면 주문 번호와 거래 기록을 첨부해 지원 티켓을 제출하세요.
문제가 생기면 계층별로 점검하세요

연결 문제인지 작업 문제인지 먼저 구분하세요

문제를 문의할 때 주문 번호, 노드, 발생 시각과 시간대, 실행한 명령, 오류 전문을 함께 제공하세요. 스크린샷이나 민감 정보를 가린 터미널 출력을 보낼 수 있지만 비밀번호, 개인 키, 토큰, 전체 결제 카드 정보를 보내지 마세요.

SSH 시간 초과, 어디부터 확인할까요?
  1. 인스턴스 세부 정보에서 IP, 포트, 주문 및 실행 상태를 다시 확인해 이전 주소에 연결하고 있지 않은지 점검하세요.
  2. 로컬에서 ssh -vvv armshell-dev를 실행해 시간 초과, 연결 거부, 인증 실패 중 어떤 문제인지 확인하세요. 세 가지는 서로 다른 오류입니다.
  3. 로컬 네트워크와 아웃바운드 규칙을 확인하고 신뢰할 수 있는 다른 네트워크에서 다시 테스트하세요. ICMP 응답이 없다는 사실만으로 SSH 서비스를 사용할 수 없다고 단정할 수 없습니다.
  4. 인증 단계에서 멈춘다면 사용자 이름, 개인 키 권한, 공개 키 등록 위치를 확인하세요. 계속 시간 초과가 발생한다면 민감 정보를 가린 로그를 첨부해 지원 티켓을 제출하고 비밀번호를 반복해서 재설정하지 마세요.
Xcode 다운로드와 의존성 가져오기가 느린데, 어떻게 구분하나요?
  1. 먼저 df -h 로 디스크 공간을 확인해 설치 패키지, 압축 해제, 이전 버전을 함께 보관할 공간이 충분한지 확인하세요.
  2. Xcode 설치 패키지 전송, 의존성 저장소 가져오기, 최초 컴파일을 구분하세요. 컴파일 로그가 멈췄다고 해서 반드시 다운로드 중인 것은 아닙니다.
  3. 신뢰할 수 있는 출처의 전체 설치 패키지를 사용하고 무결성을 확인하세요. 대용량 파일을 전송할 때는 백업 작업과 대역폭을 동시에 사용하지 않도록 하세요.
  4. 출처 유형, 파일 크기, 시작 시각, 오류를 기록하세요. 접근 토큰이 포함된 다운로드 URL은 보내지 마세요. 노드 네트워크를 확인해야 한다면 이 정보를 지원 티켓에 첨부하세요.
원격 데스크톱에 연결했는데 화면이 검은색인가요?
  1. 먼저 SSH가 정상인지 확인해 노드 전체에 접근할 수 없는 것인지 데스크톱 세션에만 문제가 있는지 구분하세요.
  2. 연결한 사용자에게 화면 공유 권한이 있는지, 사용 가능한 그래픽 세션이 있는지 확인하고 해상도를 낮춘 뒤 다시 연결하세요.
  3. SSH 터널을 사용한다면 터널을 실행한 터미널이 계속 열려 있는지, 클라이언트가 노드의 다른 포트가 아닌 로컬 매핑 포트에 연결하는지 확인하세요.
  4. 빌드 중인 노드를 강제로 재시작하지 마세요. 확인 가능한 로그를 먼저 저장하고 로그인 화면이 보이는지 설명한 뒤 지원 티켓을 제출하세요.
Runner가 연결을 끊었거나, 온라인인데도 작업을 받지 않나요?
  1. 먼저 서비스 상태와 프로세스 로그를 확인한 뒤 CI 관리 화면을 점검하세요. 노드에 SSH로 로그인할 수 있어도 Runner 서비스가 실행 중이라는 뜻은 아닙니다.
  2. 온라인인데 작업을 받지 않는다면 프로젝트 권한, Runner 태그, 워크플로 선택 조건, 보호 브랜치 설정을 확인하세요.
  3. 재시작 후 연결이 끊긴다면 launchd 로드 도메인과 빌드 사용자 로그인 상태를 확인하세요. 터미널에서 수동으로 실행하는 것은 상시 서비스의 대안이 아닙니다.
  4. 작업 시작 후 실패한다면 사용자, PATH, Xcode 버전, 작업 디렉터리를 출력하고 키체인과 디렉터리 권한을 확인하세요. Runner를 반복해서 등록 해제하고 다시 만드는 것을 첫 번째 조치로 삼지 마세요.

SSH 연결은 됐는데 문제가 해결되지 않았나요?

오류와 함께 상황을 알려주세요

요금제 선택이나 구매 전 문의는 이메일로 연락할 수 있습니다. 기존 주문의 기술 및 청구 관련 문의는 콘솔에 로그인해 지원 티켓을 제출하세요. 인스턴스와 처리 기록을 함께 확인할 수 있습니다.