접속 정보부터 작업 환경까지

M4에 연결하는 세 가지 방법

명령줄 작업에는 SSH, 직접 조작에는 원격 데스크톱, 자동 빌드에는 CI runner를 사용하세요. 세 가지 모두 하나의 전용 물리 노드에 연결되며, 서로 다른 환경이 아닙니다.

기존 대여 고객은 콘솔에서 주문에 해당하는 인스턴스 상세 정보를 열어 호스트 주소, SSH 포트, 사용자 이름과 제공 안내를 확인하세요. 이 문서의 호스트 변수는 모두 해당 인스턴스의 실제 값으로 바꿔야 합니다.

SSH호스트 확인, 파일 동기화, 빌드 명령 실행
원격 데스크톱Xcode, 시뮬레이터, macOS 화면 조작
CI runner프로젝트 작업을 전용 물리 노드에 할당
검증 가능한 연결부터 설정

SSH: 키를 만들고 호스트 별칭 설정하기

먼저 명령줄 연결을 확인한 다음 원격 데스크톱과 파이프라인을 설정하세요. SSH는 노드에 접속할 수 있는지 확인하고 인증 문제를 진단하는 가장 빠른 방법이기도 합니다.

  1. 01

    로컬에서 키 생성하기

    자신의 컴퓨터에서 실행하세요. 클라우드 노드에서는 실행하지 마세요. 키에 암호를 설정하고, 전용 키가 이미 있다면 재사용하세요. 사용 중인 파일을 덮어쓰지 마세요. 개인 키는 항상 로컬에 보관하고 노드에는 .pub 로 끝나는 공개 키만 전달하세요.

    ssh-keygen -t ed25519 -f ~/.ssh/xcnode_ed25519 -C "xcnode-workstation"
    ssh-add ~/.ssh/xcnode_ed25519

    만약 ssh-add 에서 인증 에이전트에 연결되지 않았다는 메시지가 나오면, 로컬 SSH agent가 실행 중인지 먼저 확인하세요. 키 암호와 원격 사용자 비밀번호는 서로 다릅니다.

  2. 02

    공개 키 설치 및 호스트 확인

    인스턴스 안내에 따라 변수 세 개를 설정하세요. 제공 안내에서 최초 비밀번호 인증을 허용한 경우에만 ssh-copy-id를 사용하세요. 공개 키가 이미 등록되어 있다면 바로 로그인을 테스트하면 됩니다. 처음 연결할 때는 호스트 지문을 확인하고, 확인 메시지가 표시됐다는 이유만으로 알 수 없는 호스트를 신뢰하지 마세요.

    read -r -p "Host: " NODE_HOST
    read -r -p "SSH port: " NODE_PORT
    read -r -p "User: " NODE_USER
    ssh-copy-id -i ~/.ssh/xcnode_ed25519.pub -p "$NODE_PORT" "$NODE_USER@$NODE_HOST"
    ssh -i ~/.ssh/xcnode_ed25519 -p "$NODE_PORT" "$NODE_USER@$NODE_HOST"

    위 변수 입력 명령은 Bash용입니다. macOS의 zsh에서는 먼저 bash 를 실행한 다음 명령을 실행하세요. 처음 공개 키를 설치하는 데 문제가 있으면 콘솔의 접속 정보 관리 절차를 이용하거나 지원 티켓을 제출하세요. 비밀번호를 반복해서 시도하지 마세요.

  3. 03

    별칭 저장 및 환경 확인

    로컬 ~/.ssh/config 에 별칭을 추가하세요. 아래 꺾쇠괄호로 표시된 항목은 인스턴스 값으로 바꾸고 꺾쇠괄호는 제거해야 합니다. Windows OpenSSH도 사용자 폴더의 .ssh/config를 읽습니다.

    Host xcnode-work
      HostName <INSTANCE_HOST>
      Port <SSH_PORT>
      User <INSTANCE_USER>
      IdentityFile ~/.ssh/xcnode_ed25519
      IdentitiesOnly yes
      ServerAliveInterval 30
      ServerAliveCountMax 3
    ssh xcnode-work
    uname -m
    sysctl -n machdep.cpu.brand_string
    xcode-select -p
    xcodebuild -version

    uname -m 실행 결과는 arm64여야 합니다. 칩 이름이 주문한 모델과 일치하는지 확인하세요. Xcode 버전은 노드에 실제로 설치된 버전을 기준으로 합니다. 연결 유지 설정만으로 작업이 자동 재개되지는 않으므로, 오래 걸리는 빌드는 runner나 영구 세션 관리 도구에 맡기세요.

세 가지 클라이언트 OS, 각기 다른 확인 사항

먼저 로컬에서 ssh -V를 실행할 수 있는지 확인하세요. 보조 명령이 없다고 해서 노드가 SSH를 지원하지 않는 것은 아닙니다.

로컬 클라이언트 준비 및 공개 키 설치 방법
로컬 운영체제SSH 클라이언트공개 키 설치참고 사항
macOS터미널에 OpenSSH 기본 포함ssh-copy-id 일반적으로 별도 설치가 필요합니다. 제공 안내에 따라 공개 키를 등록할 수도 있습니다.기본 셸은 대개 zsh입니다. Bash 전용 입력 구문을 그대로 사용하지 마세요.
WindowsPowerShell에서 OpenSSH Client 사용WSL에서 ssh-copy-id를 사용하거나 콘솔에서 공개 키를 등록할 수 있습니다.PowerShell과 WSL은 사용자 폴더와 키 파일이 서로 다릅니다.
Linux배포판의 OpenSSH 클라이언트 패키지대개 ssh-copy-id가 포함됩니다. 없다면 클라이언트 도구를 먼저 설치하세요.개인 키 권한은 600으로,~/.ssh 디렉터리 권한은 700으로 설정하세요.
화면 조작이 필요하다면

원격 데스크톱: SSH 터널 우선 사용

SSH 연결이 원활한지 확인한 다음 화면 공유 서비스와 그래픽 세션을 점검하세요. 포트에 연결된다고 해서 데스크톱도 준비된 것은 아닙니다.

macOS 화면 공유

로컬 Mac에서는 기본 제공되는 ‘화면 공유’ 앱을 사용할 수 있습니다. VNC의 일반적인 서비스 포트는 TCP 5900이지만 실제 포트, 인증 방식, 활성화 여부는 인스턴스 제공 안내를 따르세요.

원격에서 5900 포트를 사용하는지 확인한 뒤, 로컬 터미널에서 터널을 만들고 터미널을 계속 실행해 두세요. 여기서는 로컬 서비스와 충돌하지 않도록 15900을 사용합니다.

ssh -N -L 127.0.0.1:15900:127.0.0.1:5900 \\
  -o ExitOnForwardFailure=yes xcnode-work

그런 다음 다른 터미널에서 클라이언트를 여세요:

open "vnc://127.0.0.1:15900"
터널은 로컬 루프백 주소에서만 수신합니다

Windows / Linux VNC 클라이언트

인스턴스의 인증 방식을 지원하는 VNC 클라이언트(예: TigerVNC)를 선택하세요. 같은 방식으로 SSH 터널을 만든 다음 클라이언트 대상에 127.0.0.1을 입력하고 포트에는 15900을 입력하세요.

포트 입력 방식은 클라이언트마다 다릅니다. 포트 입력란을 따로 제공하는 클라이언트도 있고, 전체 포트를 지정할 때 이중 콜론을 사용하는 클라이언트도 있습니다. 클라이언트 안내에 따라 입력하고 포트를 디스플레이 번호로 착각하지 마세요.

macOS 화면 공유 인증은 일반 VNC와 항상 호환되는 것은 아닙니다. 인증에 실패하면 먼저 클라이언트 지원 여부와 제공 안내를 확인하세요. 호환성을 위해 노드의 접근 보호를 함부로 낮추지 마세요.

데스크톱 접속 정보와 SSH 키는 따로 관리하세요

화질을 낮춰 먼저 원활하게 사용해 보세요

처음 연결할 때는 자동 또는 낮은 화질을 선택하고 모니터 한 대만 사용하세요. 대용량 파일 전송과 전체 화면 동영상 재생도 동시에 하지 않는 것이 좋습니다. 글자가 선명하고 클릭이 안정적으로 동작하면 해상도와 색상 품질을 단계적으로 높이세요. SSH 파일 전송이 빠르더라도 원격 데스크톱의 왕복 지연이 짧다는 뜻은 아닙니다.

화면이 검게 나오면 터널이 계속 실행 중인지, 대상 포트가 맞는지, 화면 공유가 활성화되어 있는지, 원격에서 사용할 수 있는 그래픽 세션이 있는지 순서대로 확인하세요. 세션이 충돌하면 팀원과 사용 시간을 조율하고, 빌드 중인 사용자를 강제로 로그아웃하지 마세요.

작업을 자동으로 노드에 전달

CI 연동: 한 번 등록하고 자동 시작 확인

runner는 로컬 컴퓨터가 아니라 클라우드 Mac에서 작업을 실행합니다. 먼저 대화형 작업으로 툴체인을 검증한 다음 서비스로 설정하세요.

GitHub Actions self-hosted runner

프로젝트 또는 조직의 runner 설정으로 이동해 macOS ARM64를 선택하세요. 현재 설정 페이지에 표시된 다운로드 및 체크섬 확인 명령에 따라 프로그램을 준비하고, 등록 URL과 단기 토큰도 같은 페이지에서 발급받으세요.

cd ~/actions-runner
read -r -p "Registration URL: " RUNNER_URL
read -r -s -p "Registration token: " RUNNER_TOKEN
printf '\n'
./config.sh --url "$RUNNER_URL" --token "$RUNNER_TOKEN" \\
  --name xcnode-work --labels xcnode,arm64
unset RUNNER_TOKEN
./run.sh

위 입력 명령은 Bash에서 실행하세요. 테스트 작업을 제출해 runner가 온라인 상태이고 빌드까지 완료하는지 확인한 뒤, 포그라운드 프로세스를 중지하고 서비스를 설치하세요:

./svc.sh install
./svc.sh start
./svc.sh status

다른 아키텍처의 시스템에 작업이 배정되지 않도록 워크플로에 명시적인 라벨을 지정하세요:

runs-on: [self-hosted, macOS, ARM64, xcnode]
steps:
  - run: xcodebuild -version

등록 토큰은 장기간 사용하는 프로젝트 키가 아닙니다. 저장소, 빌드 출력, 지원 티켓 첨부 파일에 넣지 마세요.

GitLab Runner

프로젝트나 그룹에서 runner를 만든 다음 현재 플랫폼 안내에 따라 runner 인증 토큰을 발급받으세요. macOS ARM64 버전을 설치하고 대상 실행 사용자 계정의 그래픽 세션 터미널에서 등록하세요. root로 프로젝트 빌드를 실행하지 마세요.

gitlab-runner register

인스턴스 URL과 인증 토큰을 대화형으로 입력하고 shell 실행기를 선택하세요. runner에 xcnode 및 arm64 라벨을 설정하고 신뢰할 수 있는 프로젝트로 사용을 제한하세요.

gitlab-runner install
gitlab-runner start
gitlab-runner status

최소 테스트 작업으로 환경을 확인한 뒤 서명과 아카이빙을 추가하세요:

build-check:
  tags: [xcnode, arm64]
  script:
    - uname -m
    - xcode-select -p
    - xcodebuild -version

Shell 실행기는 실행 사용자 계정의 파일에 접근할 수 있습니다. 전용 머신이라고 해서 같은 계정에서 실행되는 신뢰할 수 없는 작업까지 격리되는 것은 아닙니다.

자동 시작과 대화형 기능은 따로 확인하세요

macOS의 사용자 단위 서비스는 보통 launchd가 관리하며 사용자 세션에 의존할 수 있습니다. 서비스를 설치한 뒤 프로세스, 로그, 대기열 상태를 확인하고 팀이 허용하는 시간에 재시작 후 복구 동작을 테스트하세요. 시뮬레이터나 그래픽 조작이 필요한 작업은 로그인 세션이 요구 사항을 충족하는지도 검증해야 합니다. runner가 온라인으로 표시되는지만 확인해서는 안 됩니다.

단일 작업부터 시작해 프로젝트의 실제 최대 메모리 사용량을 기록한 다음 병렬 작업 수를 늘리세요. 프로젝트와 Xcode 버전별로 캐시를 구분하고 빌드 결과물은 별도로 아카이빙하세요. 시스템 키체인의 서명 자료를 사용할 때는 서비스 사용자에게 접근 권한이 있는지도 확인해야 합니다. 터미널 빌드가 성공했다고 백그라운드 빌드도 성공하는 것은 아닙니다.

실제 네트워크에 맞춰 위치 선택

노드 4곳, 자주 쓰는 사무실 네트워크부터 테스트

싱가포르, 도쿄, 서울, 홍콩에서 각각 두 가지 모델을 이용할 수 있습니다. 실시간 이용 가능 여부는 콘솔에서 확인하세요. 지리적 거리는 출발점일 뿐이며, 통신사 경로와 팀의 근무 시간도 중요합니다.

싱가포르

동남아시아 팀이라면 우선 검토해 보세요. 실제 사무실 네트워크로 원격 데스크톱 반응을 테스트한 다음 프로젝트 가져오기와 빌드 결과물 업로드 경로를 확인하세요.

sg · UTC+8

도쿄

일본 및 동아시아 팀이라면 우선 검토해 보세요. 시간대가 가깝다고 네트워크가 반드시 더 빠른 것은 아니므로 혼잡 시간대와 한산한 시간대의 연결 상태를 비교하세요.

jp · UTC+9

서울

한국 및 동북아시아 팀이라면 우선 검토해 보세요. 상시 실행하는 runner는 코드 저장소와 패키지 저장소에 안정적으로 접근할 수 있는지 특히 확인해야 합니다.

kr · UTC+9

홍콩

중국 남부 및 동남아시아 팀이라면 우선 검토해 보세요. 여러 시간대의 팀원이 데스크톱을 공유한다면 그래픽 세션의 사용 시간과 종료 시간을 미리 정하세요.

hk · UTC+8

왕복 시간, 변동 폭, 실제 작업—세 가지를 기록하세요

할당된 인스턴스의 실제 호스트 주소를 대상으로 테스트하세요. 웹사이트 도메인 측정 결과로 노드 성능을 대신할 수 없습니다. 아래 명령은 노드 변수를 설정한 로컬 Bash 터미널에서 실행하세요.

ping -c 20 "$NODE_HOST"
ssh -p "$NODE_PORT" "$NODE_USER@$NODE_HOST" 'uptime'

Windows PowerShell에서는 ping -n 20 <INSTANCE_HOST>을 사용하세요. 패킷 손실과 왕복 시간 범위를 기록한 뒤 실제 Git 가져오기나 빌드 결과물 전송도 테스트하세요. 네트워크 정책에 따라 ICMP가 차단될 수 있습니다. ping 응답이 없더라도 실제 SSH 포트는 별도로 테스트해야 합니다.

팀에서 자주 사용하는 네트워크와 업무 시간대에 테스트를 반복하세요. 이 문서는 일률적인 지연 시간을 보장하지 않습니다. 측정 결과는 해당 시점의 네트워크 경로 상태만 보여줍니다. 아직 대여 전이라면 지원 이메일로 테스트 방법을 문의하세요. 확인되지 않은 노드 주소를 임의로 사용하지 마세요.

개념을 한눈에 정리

연결 관련 용어 8가지

리소스 범위, 연결 프로토콜, 작업 스케줄링을 먼저 구분해야 문제를 진단할 때 서로 다른 계층을 혼동하지 않습니다.

물리 노드
macOS를 실제로 실행하는 Apple Silicon 머신입니다. 주문 시 공유 호스트의 가상 머신이 아니라 장비 한 대가 할당됩니다.
전용
대여 기간 동안 해당 물리 머신을 한 고객에게 할당합니다. CPU, GPU, 통합 메모리를 다른 고객과 나눠 쓰지 않습니다.
VNC
원격 화면과 키보드·마우스 입력을 전송하는 프로토콜입니다. 서비스 상태, 포트, 인증을 각각 확인해야 합니다.
Screen Sharing
원격 그래픽 세션에 접속하는 macOS의 화면 공유 기능 및 클라이언트입니다. SSH 명령줄 연결을 대신할 수는 없습니다.
SSH 키
공개 키와 개인 키로 구성되는 인증 정보입니다. 공개 키는 노드에 등록하고 개인 키는 보호된 클라이언트에만 보관하세요.
self-hosted runner
전용 노드에서 CI 작업을 실행하는 에이전트 프로그램입니다. 노드 자체의 툴체인, 권한, 캐시를 사용합니다.
Thunderbolt 5 병렬 연결
노드를 선택할 때 추가하는 옵션입니다. 여러 장비가 자동으로 하나의 공유 메모리 시스템으로 합쳐지는 것은 아니며, 소프트웨어에서 분산 작업을 지원해야 합니다.
통합 메모리
Apple Silicon에서는 CPU와 GPU가 하나의 메모리 풀을 사용합니다. 따라서 빌드, 시뮬레이터, 모델 작업의 메모리 사용량을 함께 계획해야 합니다.
연결한 뒤에도 접근은 안전하게

키 연결 확인 후 접근 권한 강화

유일한 연결을 검증하기 전에 인증 설정을 변경하지 마세요. 현재 세션을 유지한 채 두 번째 터미널에서 새 키로 로그인할 수 있는지 확인한 다음 노드 정책을 조정하세요.

비밀번호 인증 비활성화

현재 macOS 버전에 맞춰 sshd 설정과 포함된 설정 파일을 확인하세요. 공개 키 인증은 활성화하고 비밀번호 및 키보드 대화형 인증은 비활성화해야 합니다. 다른 파일의 설정이 덮어쓸 수 있는 항목 하나만 수정하지 마세요.

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

설정을 적용하기 전에 sudo /usr/sbin/sshd -t 로 구문을 확인한 다음 인스턴스 안내에 따라 적용하세요.

필요한 포트만 열기

제공된 포트로 SSH에 연결하세요. 원격 데스크톱은 로컬 터널을 통해 접속하고 5900 포트를 공용 네트워크에 직접 노출하지 마세요. 임시 테스트 서비스는 사용 후 종료하고 수신 주소와 방화벽 규칙도 함께 확인하세요.

lsof -nP -iTCP -sTCP:LISTEN

runner는 보통 CI 서비스에 먼저 연결합니다. 그렇다고 인바운드 관리 포트를 추가로 열 필요는 없습니다.

사용자와 작업별로 접속 정보 관리

팀원마다 별도의 공개 키를 사용하고, 구성원이 팀을 떠나면 해당 권한을 제거하세요. runner는 신뢰할 수 있는 저장소의 작업만 받도록 하고, 프로젝트 키는 CI 플랫폼의 보호된 변수로 관리하세요. 스크립트나 프로젝트 파일에 넣지 마세요.

호스트 지문이 변경되면 인스턴스가 재설치되었는지 먼저 확인하세요. 로컬 기록을 바로 삭제하고 연결을 계속하지 마세요.

지원 티켓에는 민감 정보를 제거한 로그, 주문 번호, 실패 단계를 첨부하세요. 개인 키, 비밀번호, 등록 토큰은 보내지 마세요.

로컬 작업 단계를 반복 가능한 원격 개발 환경으로

먼저 모델과 대여 기간을 선택한 다음 인스턴스 접속 정보를 확인하세요. SSH 연결을 검증하고 원격 데스크톱과 빌드 대기열을 차례로 설정하면 됩니다. 기존 인스턴스에서 문제가 발생하면 콘솔에 민감 정보를 제거한 진단 기록을 제출하세요.