먼저 콘솔에서 연결 정보를 확인하고 SSH 또는 화면 공유 연결을 테스트하세요. 실제 작업 순서에 따라 파일 전송, 빌드 실행, 만료 전 데이터 보관 방법을 안내합니다.
이미 대여하셨나요? 호스트 이름, 포트, 사용자 이름, 만료일은 로그인 후 콘솔에 표시된 정보를 기준으로 확인하세요. 이 문서의 예시 정보는 실제 접속 정보가 아닙니다.
명령줄 작업에는 SSH를 사용하세요. macOS 그래픽 인터페이스를 조작할 때는 화면 공유를, 프로젝트와 빌드 결과물을 전송할 때는 SSH를 이용하면 됩니다. 포트를 추측해 반복해서 접속하지 마세요.
콘솔에서 해당 인스턴스를 열어 호스트 이름, SSH 포트, 사용자 이름을 확인하세요. 로컬 터미널에서 아래 명령을 실행하고 대문자로 표시된 값을 인스턴스의 실제 정보로 바꾸세요.
ssh -p SSH_PORT USER@HOSTSSH의 기본 포트는 22이지만 인스턴스마다 외부에 공개된 포트가 다를 수 있습니다. 처음 연결하기 전에 호스트 키 지문을 확인하세요. 지문이 바뀌었다면 경고를 무시하지 말고 먼저 원인을 확인하세요.
연결 시간이 초과되면 호스트 이름, 네트워크, 포트를 확인하세요. 권한 거부 오류가 나면 사용자 이름과 인증 방식을 점검하세요. 비밀번호와 개인 키를 공개 로그에 남기지 마세요.
콘솔에서 화면 공유 주소, 포트, 인증 정보를 확인하세요. 로컬 화면 공유 앱이나 호환되는 VNC 클라이언트에 입력하고 SSH 포트를 대신 사용하지 마세요.
VNC의 기본 포트는 5900이지만 실제 외부 포트는 인스턴스에 표시된 정보를 기준으로 확인하세요. 화면 공유 인증 정보가 스크린샷이나 팀 공용 문서에 노출되지 않도록 하세요.
보안이 적용된 연결 방식을 우선 사용하세요. SSH 터널이 필요하면 로컬의 5901 을 인스턴스의 VNC 서비스로 포워딩한 다음 로컬 주소에 연결하세요.
ssh -N -L 5901:127.0.0.1:VNC_PORT -p SSH_PORT USER@HOST위 포트 포워딩은 해당 인스턴스에서 VNC 서비스가 수신 대기 중이고 SSH 포워딩이 허용된 경우에만 사용할 수 있습니다. 검은 화면과 인증 실패는 서로 다른 문제이므로 지원 티켓에 각각 설명하세요.
먼저 SSH 로그인이 되는지 확인하세요. 파일 전송도 SSH 포트를 사용하므로 별도의 파일 전송 서비스를 열 필요가 없습니다. 작은 파일에는 scp를, 프로젝트 디렉터리를 반복해서 동기화할 때는 rsync를 사용하세요.
scp -P SSH_PORT ./build.zip USER@HOST:~/
rsync -av -e "ssh -p SSH_PORT" ./project/ USER@HOST:~/project/scp의 포트 옵션은 대문자 -P를 사용하고 SSH는 소문자 -p를 사용합니다. rsync 원본 경로 끝의 슬래시는 디렉터리 안의 내용을 동기화한다는 뜻입니다.
처음 동기화할 때는 자동 삭제 옵션을 사용하지 마세요. 대량 파일을 전송하기 전에 대상 경로와 파일 수를 확인하세요. 다운로드가 끝나면 진행 표시줄만 확인하지 말고 압축 파일이 정상인지 검증하세요.
다음은 서로 다른 세 단계를 구분하기 위한 예시 기록입니다. 예시 호스트 이름으로는 실제 서비스에 연결할 수 없으며, 출력도 실시간 작업 상태가 아닙니다.
$ ssh admin@jp-0417.node.vpskeep.com
Welcome to your dedicated Mac mini.
$ xcodebuild -scheme App archive
** ARCHIVE SUCCEEDED **
$ fastlane beta
Successfully uploaded package to App Store Connect.원격 세션에 접속했다는 뜻이지 프로젝트 환경 설치가 완료됐다는 뜻은 아닙니다. 이어서 sw_vers 와 xcodebuild -version을 실행해 시스템 및 도구 버전을 기록하세요.
ARCHIVE SUCCEEDED 아카이브 단계가 통과됐다는 뜻입니다. 예시의 App은 scheme 이름입니다. 실제 프로젝트에서는 workspace 또는 project, 대상 플랫폼, 출력 경로도 지정해야 합니다. 아카이브 성공이 내보내기나 배포 완료를 의미하지는 않습니다.
beta 는 프로젝트에서 직접 정의하는 lane이므로 서명 및 배포 인증을 먼저 설정해야 합니다. 업로드가 성공해도 플랫폼의 처리 결과를 확인하세요. 로컬 명령이 종료됐다고 바로 테스트할 수 있는 것은 아닙니다.
문제 해결을 위해 실패한 명령, 종료 코드, 오류 전후의 로그를 보관하세요. 마지막 줄의 ‘실패’만으로는 환경, 서명, 네트워크 문제를 파악하기 어렵습니다.
같은 프로젝트라도 로컬과 원격에서 서로 다른 버전을 사용하면 의존성 해석이나 빌드 결과가 달라질 수 있습니다. 먼저 버전을 기록하고 하나씩 조정하세요. 도구 체인과 프로젝트 의존성을 동시에 업데이트하지 마세요.
아래 두 명령으로 버전을 확인하세요. 머신에 Xcode가 여러 개 설치되어 있으면 시스템 기본 경로를 전환할 수 있습니다. 현재 작업에만 적용하려면 프로세스 환경 변수에서 DEVELOPER_DIR를 설정하는 방법을 우선 사용하세요.
xcode-select -p
xcodebuild -version
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer xcodebuild -version경로는 실제로 설치된 앱과 일치해야 합니다. 대상 버전이 미리 설치되어 있는지는 인스턴스 환경에 따라 다릅니다. 새 버전이 필요하면 정식으로 사용 권한을 확보한 설치 패키지를 사용하고, 먼저 디스크 여유 공간을 확인하세요.
Xcode 설정의 플랫폼 또는 구성 요소 관리 메뉴에서 프로젝트에 맞는 런타임을 설치하세요. 메뉴 이름은 버전에 따라 다를 수 있습니다. 설치 후 사용 가능한 기기를 확인하고 테스트 대상을 선택하세요.
xcrun simctl list runtimes
xcrun simctl list devices available
df -h시뮬레이터, DerivedData, 아카이브는 모두 저장 공간을 사용합니다. 대량 테스트 전에 기기 하나로 검증하고 나서 동시 작업 수를 늘리세요. 시뮬레이터 테스트는 실제 iOS 기기 테스트와 같지 않습니다.
승인된 서명 인증서와 해당 개인 키, 프로비저닝 프로파일을 보안 채널을 통해 인스턴스로 전송하세요. 인증서를 가져온 키체인과 프로비저닝 프로파일을 사용 중인 Xcode 버전의 요구 사항에 맞게 설치한 다음 Team, Bundle ID, 인증서 유효 기간, 배포 유형을 확인하세요.
security find-identity -v -p codesigningCI에는 별도의 빌드 키체인을 사용하고 비밀번호는 접근이 제한된 시크릿 변수에 저장하세요. 비대화형 작업에서는 키체인 잠금 해제 상태와 서명 도구의 접근 권한도 확인해야 합니다. 그래픽 인터페이스에서 인증서가 보인다는 이유만으로 설정이 끝났다고 판단하지 마세요.
인스턴스를 사용한 뒤에는 더 이상 필요하지 않은 서명 개인 키, 토큰, 프로비저닝 프로파일을 삭제하세요. 지원 티켓에는 인증서 이름과 오류 내용만 제공하고 개인 키, 비밀번호, 전체 인증 정보를 보내지 마세요.
Keep M4 L 구성은 M4 / 24GB / 512GB이며 여러 브랜치를 빌드하는 시작점으로 활용할 수 있습니다. 동시 실행 수는 프로젝트에서 직접 테스트해 정하세요. CPU 코어 수만으로 동시에 실행할 수 있는 UI 테스트 수를 추정해서는 안 됩니다.
저장소 또는 조직 설정의 Actions 러너 페이지에서 등록 절차를 시작하고 macOS와 해당 아키텍처를 선택한 다음 페이지에 표시된 명령으로 다운로드하고 등록하세요. 등록 토큰은 필요한 시간 동안만 사용하고 저장소에 기록하지 마세요.
인스턴스에 macos 및 arm64 와 팀 용도를 나타내는 명확한 라벨을 추가하세요. 워크플로에서 라벨로 머신을 선택해 서명 작업이 인증서가 없는 환경에서 실행되지 않도록 하세요.
runs-on: [self-hosted, macOS, ARM64]먼저 러너를 직접 시작해 테스트 작업을 실행한 다음 러너와 함께 제공되는 서비스 스크립트로 상시 실행 서비스를 설치하세요. 실행 계정은 프로젝트 디렉터리, Xcode, 빌드 키체인에 접근할 수 있어야 합니다.
인스턴스 아키텍처에 맞는 GitLab Runner를 설치하고 프로젝트 또는 팀 관리 화면에서 등록 정보를 확인한 뒤 gitlab-runner register를 실행하세요. 기본 Xcode 도구 체인이 필요하면 팀 보안 요구 사항에 따라 shell executor를 선택할 수 있습니다.
shell executor는 머신에서 작업을 직접 실행합니다. 신뢰할 수 있는 프로젝트만 받도록 하고, 어떤 브랜치와 작업이 서명 키에 접근할 수 있는지 제한하세요. 신뢰할 수 없는 기여자의 코드를 프로덕션 인증 정보가 있는 인스턴스에서 실행하지 마세요.
gitlab-runner --version
gitlab-runner verify등록과 작업 할당이 정상인지 먼저 확인한 다음 설치 방식에 맞춰 서비스를 설정하세요. 빌드, 캐시, 로그 출력 디렉터리는 팀 인수인계 문서에 기록해야 합니다.
macOS의 상시 실행 프로세스는 일반적으로 launchd에서 관리합니다. 사용자 수준 LaunchAgent와 시스템 수준 LaunchDaemon은 시작 조건이 다릅니다. 서비스가 그래픽 세션이나 사용자 키체인에 의존한다면 시스템 수준 시작 설정을 그대로 적용할 수 없습니다.
GitHub Actions 러너의 진단 파일은 일반적으로 설치 디렉터리의 _diag 에 있습니다. 작업 단계별 로그는 파이프라인 페이지에서 확인하세요. GitLab Runner의 서비스 출력 위치는 설치 및 시작 방식에 따라 다릅니다. 직접 launchd 설정을 만들 때는 StandardOutPath 와 StandardErrorPath를 명시적으로 설정하고 공통 시스템 로그 파일이 있다고 가정하지 마세요.
러너 이름, 실행 계정, Xcode 버전, 작업 디렉터리, 로그 경로를 기록하세요. 동시 작업에는 각각 별도의 DerivedData 및 결과물 디렉터리를 사용하세요. 같은 이름의 출력 파일이 서로 덮어쓰면 간헐적인 실패가 머신 문제처럼 보일 수 있습니다.
Keep M4 Pro 구성은 M4 Pro / 64GB / 2TB입니다. 통합 메모리는 시스템, 모델, 다른 프로세스가 함께 사용하므로 전체 용량을 모델 가중치에 할당할 수는 없습니다. 아래 수치는 가중치만 추정한 것으로 속도 테스트나 실행 가능성을 보장하지 않습니다.
| 모델 파라미터 수 | 4비트 가중치 추정 | 8비트 가중치 추정 | 로드 전 확인 사항 |
|---|---|---|---|
| 약 7B 파라미터 | 약 3.3 GiB | 약 6.5 GiB | 설치, 모델 형식, 짧은 문맥 생성을 먼저 확인하기에 적합합니다. |
| 약 14B 파라미터 | 약 6.5 GiB | 약 13.0 GiB | 대량 작업을 검토하기 전에 단일 요청의 최대 메모리를 측정하세요. |
| 약 32B 파라미터 | 약 14.9 GiB | 약 29.8 GiB | 긴 문맥과 동시 요청은 KV cache 사용량을 크게 늘릴 수 있습니다. |
계산식: 파라미터 수 × 비트 수 ÷ 8 ÷ 2³⁰. 결과는 GiB 단위로 소수점 첫째 자리까지 표시합니다. 양자화 그룹, 스케일 계수, 비양자화 계층, KV cache, 런타임 버퍼 때문에 실제 사용량은 더 커집니다. 모델 파일 크기와 최대 메모리 사용량은 같지 않습니다.
먼저 사용하는 MLX 패키지에 맞는 Python 버전인지 확인한 뒤 가상 환경을 만드세요. 설치 패키지와 모델 파일에 접근할 수 있어야 하며 모델 사용 권한도 확보해야 합니다. 다운로드 전에 디스크 공간을 확인하세요.
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install mlx mlx-lm
python -m mlx_lm.generate --model ./models/model --prompt "Explain unified memory." --max-tokens 128./models/model 은 준비된 호환 모델 디렉터리를 가리켜야 합니다. 첫 실행은 짧은 입력과 적은 출력으로 검증한 뒤 문맥 길이를 단계적으로 늘리세요. 결과를 재현할 수 있도록 모델 버전, 양자화 방식, 입력 길이, 최대 메모리 사용량을 기록하세요.
메모리 압박이 계속되거나 스왑 사용량이 빠르게 늘면 먼저 문맥 길이, 배치 크기, 동시 요청 수를 줄이세요. SSD를 추가하면 저장 공간은 늘어나지만 통합 메모리는 늘어나지 않으며 적절한 모델 메모리 계획을 대신할 수 없습니다.
일간, 주간, 월간, 분기별은 선택할 수 있는 네 가지 결제 주기입니다. 만료일을 작업 일정의 마감으로 생각하고 마지막 빌드가 끝날 때까지 데이터 이전을 미루지 마세요. 노드는 연중 365일 운영되며, 이용 기간과 제공 상태는 해당 주문에 표시된 내용을 기준으로 합니다.
콘솔에 로그인해 해당 인스턴스 또는 구독의 만료일을 확인한 다음 갱신을 진행하세요. 결제 전에 모델, 노드, 선택한 주기, 추가 옵션, 최종 결제 금액을 확인하세요. 주기 변경 적용 시점과 추가 결제 여부는 해당 주문에 표시된 규정과 견적을 기준으로 합니다. 결제 후 새 만료일이 반영됐는지 확인하세요.
에셋 공간이 더 필요하면 +1TB SSD 또는 +2TB SSD를 확인하세요. Thunderbolt 5 연결이 필요하다면 먼저 워크플로와 기기의 지원 여부를 확인하세요. 추가 옵션을 선택해도 원래 모델의 통합 메모리는 바뀌지 않습니다. 콘솔에서 선택 가능한 옵션, 이용 주기, 제공 요건을 확인한 뒤 구성을 변경하세요. 디스크나 작업을 조정해야 한다면 먼저 백업하고 관련 쓰기 작업을 중지하세요.
코드, 에셋, 빌드 결과물, 필요한 설정을 내보내 직접 관리하는 저장 공간에 다운로드한 뒤 복구 테스트를 진행하세요. 러너와 자동 작업을 중지하고 단기 접근 토큰을 폐기한 다음 서명 개인 키와 더 이상 필요하지 않은 인증 정보를 삭제하세요. 원격 디렉터리를 압축했다는 이유만으로 백업이 끝났다고 판단하지 마세요.
만료 후 데이터가 보관될 것이라고 가정해 백업을 대신하지 마세요. 보관 기간, 삭제 진행 상태, 복구 가능 여부는 주문의 데이터 처리 안내에서 확인하세요. 내용이 명확하지 않다면 미리 지원 티켓으로 문의하세요. 삭제가 완료된 데이터는 복구할 수 있다고 가정하지 말고 중요한 자료는 만료 전에 이전하세요.
콘솔에 로그인해 지원 티켓을 제출하면 주문 정보와 함께 확인할 수 있습니다. 한 가지 문제에는 티켓 하나를 사용하고, 후속 테스트 결과는 기존 티켓에 추가해 맥락이 흩어지지 않도록 하세요.
보관 번호 또는 주문 번호, 모델, 실제 사용 중인 노드(싱가포르, 일본(도쿄), 한국(서울), 홍콩)를 알려주세요. 로그인 비밀번호나 개인 키는 첨부하지 마세요.
시작 시각과 시간대를 적고 문제가 계속 발생하는지, 마지막으로 정상 사용한 시각은 언제인지 알려주세요. SSH 시간 초과, 인증 실패, VNC 검은 화면, 특정 빌드 명령 오류 중 어떤 문제인지 설명하세요.
최소 재현 단계, 시스템 및 도구 버전, 전체 오류 내용, 이미 수행한 점검을 적어주세요. 스크린샷에서는 인증 정보를 가리고 로그에서는 토큰, 인증서 비밀번호, 기타 민감한 항목을 삭제하세요.
주문 번호, 금액, 결제 채널을 알려주세요. USDT-TRC20 및 Visa / Mastercard / Amex(Stripe)만 지원하며 모든 결제는 USD로 처리됩니다. 실제 이용 가능한 결제 게이트웨이는 백엔드 응답을 기준으로 합니다. USDT 결제는 거래 해시를, 카드 결제는 영수증 번호를 제공하고 카드 번호 전체는 보내지 마세요.
콘솔에 로그인할 수 없다면 다음 주소로 이메일을 보내세요: support@vpskeep.com본문에 계정 이메일 주소와 주문 번호를 적어주세요. 연결 인증 정보는 이메일로 보내지 않아도 됩니다.
자동화를 시작하기 전에 연결, 단일 빌드, 결과물 다운로드까지 먼저 완료하세요. 아직 머신을 선택하지 않았다면 세 가지 구성과 네 가지 이용 주기부터 살펴보세요.