먼저 머신에 접속하고 프로젝트와 모델을 옮긴 다음, 노드에서 서비스가 계속 실행되도록 설정하세요. 이 페이지의 명령은 인스턴스가 인도된 Mac mini를 대상으로 합니다. 공개 IP, 사용자 이름, 자격 증명은 콘솔의 인스턴스 정보를 기준으로 확인하세요.
주문하셨나요? 먼저 콘솔에서 인스턴스가 인도되었는지 확인한 다음 아래 순서대로 진행하세요.
XCODEOPS / RUNBOOK
처음 이용한다면 접속, 마이그레이션, MLX 순서로 읽어 보세요. 이미 실행 환경이 있는 팀은 네트워크 노드 선택과 문제 해결 섹션으로 바로 이동할 수 있습니다.
접속 정보는 콘솔의 인스턴스 상세에서만 확인하세요. 초기 자격 증명을 저장소, CI 로그, 팀 채팅에 남기지 마세요. 먼저 키 인증 접속을 확인한 다음 로그인 방식을 강화하세요.
콘솔에 로그인해 인도된 인스턴스를 열고 노드, 공개 IP, SSH 포트, 로그인 사용자 이름을 기록하세요. 인스턴스 상태를 확인한 뒤 접속을 시도하고, 실제 사용 가능 여부는 콘솔에 표시되는 최신 정보를 기준으로 판단하세요.
로컬에서 전용 키를 생성한 뒤 콘솔의 키 등록 메뉴나 인스턴스 계정의 승인된 키 목록에 공개 키를 추가하세요. 공개 키만 업로드하고 개인 키는 항상 본인 기기에 보관하세요.
두 번째 터미널에서 키 로그인이 되는지 먼저 확인한 다음 팀 정책에 따라 SSH 비밀번호 로그인을 비활성화하세요. 변경 전에 현재 세션을 유지하고 설정 문법을 확인해 인스턴스에 다시 접속하지 못하는 상황을 방지하세요.
키를 생성한 뒤 .pub 파일의 내용을 업로드하세요. 아래 설정의 예시 주소는 문서용 예약 주소입니다. 사용하기 전에 콘솔에 표시된 실제 IP, 포트, 사용자 이름으로 바꾸세요.
ssh-keygen -t ed25519 -f ~/.ssh/xops_node
cat ~/.ssh/xops_node.pub~/.ssh/config
Host xops-node
HostName 192.0.2.10
User mac-user
Port 22
IdentityFile ~/.ssh/xops_node
IdentitiesOnly yes저장한 뒤 chmod 600 ~/.ssh/config를 실행하고 ssh xops-node를 실행하세요. 처음 접속할 때는 호스트 지문을 확인하세요. 연결에 문제가 있으면 IP, 포트, 키 권한, 인스턴스 상태를 먼저 점검하세요.
Xcode 그래픽 인터페이스를 사용하거나 빌드 결과물을 확인하려면 먼저 인스턴스에서 화면 공유가 활성화되어 있는지 확인한 다음 원격 5900 포트를 로컬로 포워딩하세요. SSH 세션이 끊기면 터널도 닫힙니다.
ssh -N -L 5901:127.0.0.1:5900 xops-node터미널을 열어 둔 상태에서 로컬 Mac의 ‘화면 공유’ 앱이나 VNC 호환 클라이언트로 다음 주소에 연결하세요. vnc://127.0.0.1:5901그래픽 인터페이스 로그인 권한과 SSH 권한은 각각 확인하세요. 두 권한에 같은 자격 증명이 사용된다고 가정하지 마세요.
rsync 와 같은 파일 동기화 도구를 사용하세요.다시 생성할 수 있는 프로젝트 파일부터 동기화하고 도구 체인을 복원한 뒤 CI를 연결하세요. 모델 가중치, 서명 자료, 빌드 캐시는 각각 처리 방법이 다릅니다. 로컬 머신의 사용자 디렉터리 전체를 검토 없이 복사하지 마세요.
로 rsync 를 사용해 프로젝트와 모델 가중치를 증분 동기화하세요. 먼저 테스트 전송을 한 번 실행한 뒤 대상 디렉터리, 파일 권한, 사용 가능한 저장 공간을 확인하세요. 외장 드라이브 이미지는 형식과 용량을 미리 확인한 오프라인 마이그레이션에만 적합합니다.
rsync -avh --progress ./project/ \
xops-node:~/work/project/대용량 가중치는 나눠 전송하세요. 전송 후 파일 크기와 체크섬을 비교하고 개인 키나 임시 토큰이 프로젝트 디렉터리에 섞이지 않도록 하세요.
로컬에서 Homebrew Bundle로 Brewfile을 내보내 노드에서 가져오세요. 그런 다음 Xcode 버전, 명령줄 도구, 종속성 잠금 파일을 확인하세요. 서명 인증서는 별도로 전송하고 가져온 후 키체인 접근을 제한하세요.
brew bundle dump --file=./Brewfile
rsync -av ./Brewfile xops-node:~/work/
ssh xops-node 'brew bundle --file=~/work/Brewfile'로컬 Python 가상 환경을 그대로 복사하지 마세요. 대상 머신에서 종속성을 다시 설치해야 합니다.
기존 CI 프로젝트에 자체 호스팅 러너를 등록하고 지정한 저장소나 팀에 연결하세요. 빌드 캐시는 별도 디렉터리에 두고, 메모리와 빌드 부하에 맞춰 동시 실행 수를 설정하세요.
이 시간은 마이그레이션 작업을 위한 예상 범위이며 인스턴스 인도 시간은 아닙니다. 첫 동기화 전에 사용 가능한 디스크 공간을 확인하세요. 용량 확장이 필요하면모델 및 추가 옵션에서 선택 가능한 구성을 확인할 수 있습니다.
Apple Silicon의 통합 메모리는 CPU와 GPU가 함께 사용합니다. 모델을 메모리에 올릴 수 있는지는 양자화 형식, 컨텍스트 길이, 다른 프로세스의 메모리 사용량에도 달려 있습니다. 사양을 선택할 때 시스템과 서비스에 여유 공간을 남기고, 표시된 메모리 용량 전체를 가중치 공간으로 계산하지 마세요.
인스턴스에 서비스 전용 Python 환경을 만드세요. 아래 모델 경로는 인스턴스에 동기화된 로컬 디렉터리를 가리킵니다. 실행한 뒤 먼저 인스턴스 내부에서 OpenAI 호환 API를 확인하세요.
python3 -m venv ~/mlx-service/.venv
~/mlx-service/.venv/bin/python -m pip install mlx-lm
~/mlx-service/.venv/bin/python -m mlx_lm.server \
--model ~/models/quantized-model \
--host 127.0.0.1 --port 8080curl http://127.0.0.1:8080/v1/models모델 파일이 온전한지, Python 환경을 사용할 수 있는지, 포트를 다른 프로세스가 점유하고 있지 않은지 먼저 확인하세요. 버전에 따라 mlx-lm 매개변수가 달라질 수 있으므로 실제 배포 전 인스턴스에 설치된 버전의 명령 도움말을 확인하세요.
기본값은 127.0.0.1에서만 수신합니다. 내부에서 소수의 요청만 처리한다면 팀원이 각자 SSH 터널을 설정할 수 있습니다. 공용 진입점이 필요하면 인증, 접근 제어, TLS를 갖춘 리버스 프록시를 사용하고 보호되지 않은 추론 엔드포인트를 인터넷에 직접 공개하지 마세요.
ssh -N -L 8080:127.0.0.1:8080 xops-node포그라운드 명령이 안정적으로 동작하는지 확인한 뒤 서비스용 사용자 수준 launchd 설정을 만드세요. 가상 환경의 Python, 모델 경로, 작업 디렉터리, 로그 파일을 지정합니다. 설정을 확인한 다음 현재 사용자 세션에 로드하고, 인스턴스를 재시작한 뒤 프로세스와 엔드포인트를 다시 점검하세요.
plutil -lint ~/Library/LaunchAgents/com.xcodeops.mlx.plist
launchctl bootstrap gui/$(id -u) \
~/Library/LaunchAgents/com.xcodeops.mlx.plist메모리 참고: 16GB는 소형 양자화 모델 실험에 적합하고, 24GB는 일반적인 7B~8B 양자화 모델을 단일 서비스로 검증하는 데 사용할 수 있습니다. 64GB는 더 큰 모델이나 여러 작업을 위한 여유를 제공합니다. 실제 처리량은 모델, 컨텍스트, 부하에 따라 달라지므로 실제 요청 샘플로 측정하세요.
전용 물리 머신은 Xcode 컴파일, 시뮬레이터 테스트, 자체 호스팅 러너 실행에 적합합니다. 같은 머신의 CPU, GPU, 통합 메모리를 다른 테넌트의 작업이 점유하지 않습니다. 하지만 시뮬레이터 테스트를 통과해도 실제 기기의 카메라, Bluetooth, 성능 테스트까지 통과한 것은 아닙니다.
Xcode와 시뮬레이터 런타임 버전을 고정한 다음 주요 기기 화면 크기와 OS 버전에 맞춰 테스트 매트릭스를 구성하세요. 먼저 xcrun simctl list devices available 로 실제 사용 가능한 기기를 확인해 파이프라인에서 설치되지 않은 런타임을 참조하지 않도록 하세요.
먼저 러너에서 재현 가능한 테스트와 아카이브를 완료한 다음 팀에서 사용 중인 서명 절차에 따라 TestFlight 빌드를 업로드하세요. 인증서, 프로비저닝 프로파일, 업로드 자격 증명은 접근을 제어할 수 있는 저장소에 보관하고 저장소나 보존되는 빌드 로그에 넣지 마세요.
확인 항목: 서명 / 아카이브 / 업로드 결과센서, 실제 네트워크 전환, 전력 소비, 주변 기기 연동이 포함된 테스트는 팀이 관리하는 실제 기기에서 검증해야 합니다. 클라우드 노드에서 빌드와 배포를 담당하고, 최종 회귀 테스트와 문제 재현은 로컬 기기에서 진행할 수 있습니다.
확인 항목: 기기 로그 / 재현 절차싱가포르, 도쿄, 서울, 홍콩 노드를 선택할 수 있습니다. 팀원의 위치, 통신사 라우팅, 저녁 시간대 혼잡도에 따라 실제 체감 성능이 달라집니다. 추론 API는 ping만 확인하지 말고 요청 왕복 시간과 모델 생성 시간도 함께 측정하세요.
아래 표는 밀리초 단위이며 지정된 기준에 따라 정리한 참고 데이터입니다. 어느 사용자 네트워크에 대해서도 실시간 성능을 보장하지 않습니다. 실제 사용 환경에서 반복 측정한 뒤 노드를 선택하세요.
| 출발 도시 | 싱가포르 | 도쿄 | 서울 | 홍콩 |
|---|---|---|---|---|
| 상하이 | 76 ms | 58 ms | 53 ms | 41 ms |
| 선전 | 62 ms | 72 ms | 65 ms | 29 ms |
| 타이베이 | 64 ms | 46 ms | 54 ms | 39 ms |
| 방콕 | 43 ms | 109 ms | 98 ms | 66 ms |
| 자카르타 | 38 ms | 109 ms | 115 ms | 74 ms |
| 시드니 | 101 ms | 132 ms | 146 ms | 141 ms |
| 오사카 | 75 ms | 32 ms | 47 ms | 65 ms |
| 부산 | 85 ms | 44 ms | 24 ms | 71 ms |
측정 기준: ICMP 왕복 시간 평균, 각 경로에서 연속 100회 측정, 평일 저녁 시간대, 가정용 광대역 인터넷 접속. 노드 선택을 위한 초기 참고 자료일 뿐입니다. 통신사와 네트워크 경로에 따라 결과가 달라지므로 실제 사무실 위치에서 해당 인스턴스까지 직접 측정해야 합니다.
먼저 실제 인스턴스에 연속 ping을 보내고 패킷 손실과 지터를 확인하세요. 팀원이 여러 지역에 분산되어 있다면 지리적으로 가장 가까운 도시만 고르지 말고 원격 데스크톱을 가장 자주 사용하거나 추론 API를 가장 많이 호출하는 팀원을 기준으로 삼으세요.
모델 가중치, 미디어 파일, 빌드 캐시는 증분 동기화하는 것이 좋습니다. 대량 전송은 사용량이 적은 시간대에 예약하고 실패하면 이어서 전송하세요. VNC 화면이 끊길 때는 백그라운드 동기화가 업로드 대역폭을 모두 사용하고 있지 않은지도 확인하세요.
Thunderbolt 5를 이용한 여러 머신 연결은 실제로 여러 머신 간 협업이 필요하고 애플리케이션 워크플로가 이를 활용할 수 있을 때 적합합니다. 여러 머신을 연결해도 단일 머신의 통합 메모리가 하나의 모델에서 사용할 수 있는 메모리 풀로 자동 병합되지는 않습니다. 구성 전에 소프트웨어 아키텍처를 확인하세요.
인스턴스 또는 주문 문제는 콘솔에서 문의를 제출하세요. 문의 전에 로컬 네트워크, 인스턴스 상태, 접속 방식, 문제가 발생한 시간을 확인하세요. 스크린샷이나 로그에 개인 키, 전체 토큰, 가림 처리되지 않은 민감한 정보를 포함하지 마세요.
콘솔에 로그인해 해당 주문이나 인스턴스에서 점검 자료를 첨부하여 문의를 제출하세요. 아직 주문하지 않은 상태에서 제품 선택에 대해 문의하려면 다음 주소로 이메일을 보내세요: support@xcodeops.com이미 인스턴스를 사용 중이라면 주문과 노드 정보를 함께 확인할 수 있도록 문의를 제출하는 것이 좋습니다.
세 가지 등급의 전용 물리 Mac mini를 일·주·월·분기 단위로 이용할 수 있습니다. 먼저 모델을 선택한 다음 실제 네트워크 측정 결과를 바탕으로 노드를 고르세요. 인스턴스가 인도되면 이 페이지의 접속 안내부터 시작하면 됩니다.