장비 인수부터 개발 시작까지

장비에 연결할 수 없나요?
여기서 먼저 확인하세요

전용 클라우드 Mac 연결 및 개발 환경 가이드입니다. 먼저 콘솔에 표시된 인수 정보를 확인한 다음 도구 체인과 작업 설정을 점검하세요. 고객님 장비는 가상 머신이 아닌 전용 물리 장비이며, 그래픽 인터페이스와 명령줄을 모두 사용할 수 있습니다.

콘솔에 로그인해 연결 정보 확인 아직 이용 전인가요? 지금 대여

기존 주문이 있다면 인스턴스 상세 정보를 확인하세요. 호스트 주소, 사용자 이름, 포트 및 현재 인수 상태는 콘솔에 표시되는 최신 정보를 기준으로 합니다.

첫 연결

연결 정보를 확인하고 접속 방법을 선택하세요

원격 데스크톱은 시스템 점검, Xcode 설정, 그래픽 인터페이스 디버깅에 적합하고, SSH는 코드 가져오기, 빌드 실행, 로그 확인에 적합합니다. 두 방법 모두 같은 장비에 연결하므로 프로젝트를 두 벌 복사할 필요가 없습니다.

그래픽 인터페이스

화면 공유 / VNC

콘솔의 인스턴스 상세 정보에서 원격 데스크톱 주소와 인증 정보를 확인하세요. macOS 클라이언트에서는 화면 공유를 사용할 수 있고, 다른 시스템에서는 VNC 호환 클라이언트를 사용하세요. SSH 암호와 별도 VNC 인증 정보를 혼동하지 마세요.

  1. 호스트 주소, 원격 데스크톱 포트, 사용자 이름을 복사하고 앞뒤에 공백이 붙지 않았는지 확인하세요.
  2. 클라이언트에 주소와 포트를 입력하세요. VNC 기본 포트는 5900이지만, 실제 포트는 콘솔에 표시된 값을 입력해야 합니다.
  3. 인수 안내에 따라 인증을 완료하세요. 인증에 실패하면 먼저 사용자 이름과 인증 정보 유형을 확인한 후 다시 시도하세요.
  4. 데스크톱에 접속한 뒤 초기 시스템 암호를 변경하세요. 별도 원격 데스크톱 인증 정보를 사용하는 경우 인스턴스 안내에 따라 갱신하고 안전하게 보관하세요.

데스크톱 반응이 느리면 먼저 화질을 낮추고 불필요한 애니메이션을 끄세요. 네트워크 문제와 그래픽 세션 문제를 구분할 수 있도록 SSH 연결도 하나 열어 두세요.

명령줄

SSH

시스템 터미널이나 신뢰할 수 있는 SSH 클라이언트를 사용하세요. SSH 기본 포트는 22입니다. 인수 정보에 다른 포트가 지정된 경우 연결 명령에 해당 -p 옵션을 포함해야 합니다.

  1. 인스턴스 상세 정보에서 호스트 주소, SSH 포트, 사용자 이름을 확인하고 기본 계정을 임의로 추측해 사용하지 마세요.
  2. 다음 명령으로 ssh -p PORT USER@HOST 접속하고, 대문자로 표시된 항목을 인수 정보의 값으로 바꾸세요.
  3. 처음 호스트 지문 안내가 표시되면 신뢰할 수 있는 인스턴스 정보를 먼저 확인하세요. 지문이 갑자기 바뀌면 접속을 중단하고 지원 요청을 제출하세요.
  4. 처음 로그인한 뒤 passwd 를 실행해 초기 암호를 변경하고, 본인의 SSH 공개 키를 등록하세요.

공개 키 로그인에 성공한 것을 확인한 다음 암호 로그인 정책을 조정하세요. 변경 전에 로그인된 세션을 유지해 장비에 다시 접속하지 못하는 상황을 방지하세요.

오류 메시지부터 확인하고 장비를 반복해서 초기화하지 마세요
증상 먼저 확인할 항목 지원 요청에 첨부할 정보
연결 시간 초과 인스턴스 인수가 완료되었는지, 주소와 포트가 올바른지, 로컬 네트워크나 방화벽에서 아웃바운드 연결을 허용하는지 확인하세요. 다른 네트워크에서도 비교해 보세요. 노드, 장비 번호, 연결 방법, 오류 발생 시간과 시간대
인증 실패 사용자 이름이 정확한지, 올바른 인증 정보를 사용했는지, 암호를 변경했는지 확인하세요. 로그나 스크린샷에 암호를 노출하지 마세요. 전체 오류 문구, 사용한 클라이언트와 인증 방법. 암호나 개인 키는 첨부하지 마세요.
SSH는 되지만 데스크톱 화면이 검게 나옴 그래픽 세션을 종료한 뒤 다시 연결하고 클라이언트 호환성을 확인하세요. 실행 중인 빌드나 테스트 작업은 우선 종료하지 마세요. 클라이언트 버전, 검은 화면 스크린샷, SSH 정상 여부, 최근 변경한 시스템 설정
호스트 지문 변경 장비 교체나 시스템 초기화가 확인된 기록이 있는지 확인하세요. 확인 전에는 로컬 지문 기록을 바로 삭제하지 마세요. 이전 및 새 지문, 장비 번호, 최근 인수 알림
첫날 준비

약 4분이면 시작 전 기본 점검을 마칠 수 있습니다

아래 예상 시간은 환경 인수가 완료되고 저장소가 작으며 네트워크가 정상인 경우를 기준으로 합니다. 대형 프로젝트 다운로드, Xcode 설치, 의존성 컴파일은 포함되지 않습니다. 먼저 확인한 뒤 진행하고, 보안 설정을 건너뛰어 시간을 단축하지 마세요.

  1. 01

    암호 변경 및 방화벽 확인

    약 1분

    초기 암호를 변경하고 인증 정보를 저장하세요. macOS 방화벽 규칙을 활성화하거나 확인하고, 사용 중인 원격 연결 서비스를 허용하는지 점검하세요. 연결을 확인하지 않은 채 모든 접근을 한꺼번에 차단하지 마세요.

  2. 02

    Xcode 및 명령줄 도구 확인

    약 2분

    그래픽 인터페이스에서 Xcode 버전을 확인한 다음 xcode-select -p 와 xcodebuild -version을 실행하세요. 프로젝트에서 특정 버전을 요구하면 먼저 해당 도구 체인으로 전환한 뒤 빌드하세요.

  3. 03

    저장소 가져오기 및 간단한 작업 실행

    약 1분

    최소 권한으로 저장소에 접근할 수 있는 인증 정보를 설정하고 코드를 가져오세요. 전체 파이프라인을 시작하기 전에 작은 범위의 빌드나 테스트를 실행해 의존성, 경로, 쓰기 권한을 확인하세요.

점검 완료 기준: 다시 로그인할 수 있고, 도구 체인 버전이 프로젝트 요구 사항에 맞으며, 코드에 접근할 수 있고, 빌드 출력 디렉터리에 쓸 수 있어야 합니다. 하나라도 통과하지 못하면 해당 단계에서 멈추고 해결하세요.

이전 및 CI

데이터를 옮기고, 도구 체인을 구성한 뒤, 작업을 연결하세요

세 단계로 나누어 이전하면 문제 원인을 더 쉽게 파악할 수 있습니다. 로컬 캐시, 이전 아키텍처용 바이너리 의존성, 현재 사용하는 서명 인증 정보를 한꺼번에 복사하지 마세요. 장비에는 안정적인 개발 환경을 유지할 수 있지만 작업 권한은 직접 설정해야 합니다.

01 / DATA

데이터

rsync나 외장 클라우드 드라이브로 프로젝트와 리소스를 이전하세요. 먼저 대상 디스크의 여유 공간을 확인한 뒤 프로젝트, 에셋, 아카이브를 나누어 복사하세요. 다시 생성할 수 있는 빌드 산출물과 캐시는 처음부터 옮길 필요가 없습니다.

rsync를 처음 실행할 때는 --dry-run 을 추가해 미리 확인하는 것이 좋습니다. 소스 경로 끝의 슬래시 유무에 따라 복사되는 디렉터리 구조가 달라질 수 있습니다. 대상 내용을 확인하기 전에는 대상 파일을 삭제하는 옵션을 사용하지 마세요.

완료 기준: 프로젝트 디렉터리 구조가 온전하고, 주요 리소스를 읽을 수 있으며, 파일 수나 체크섬이 예상과 일치해야 합니다.

02 / TOOLS

도구 체인

Homebrew, Xcode, SDK, 프로젝트 의존성의 버전을 확인하세요. Apple Silicon에서 Homebrew의 일반적인 경로는 /opt/homebrew입니다. 로컬 컴퓨터의 절대 경로를 그대로 사용하지 마세요.

프로젝트의 잠금 파일을 사용해 의존성을 다시 구성하세요. 서명 인증서, 해당 개인 키, 프로비저닝 프로파일을 각각 확인하세요. 그래픽 인터페이스에서 사용할 수 있다고 해서 GUI 없는 CI 프로세스에도 서명 권한이 있는 것은 아닙니다.

완료 기준: 버전 확인 명령이 정상 실행되고, 로컬 환경에서 빌드가 통과하며, 인증서와 프로비저닝 프로파일이 현재 프로젝트에 맞아야 합니다.

03 / CI

CI 설정

GitHub Actions 또는 GitLab Runner 셀프 호스팅 실행기를 등록하세요. 전용 시스템 사용자와 최소 권한 토큰을 사용하고 실행기 레이블을 프로젝트 작업에 정확히 연결하세요.

코드 읽기만 하고 서명은 하지 않는 검증 작업부터 실행한 다음 테스트와 배포를 연결하세요. 실행기 프로세스의 PATH, 작업 디렉터리, 키체인 접근 권한을 확인하세요. 대화형 터미널에서만 검증하지 마세요.

완료 기준: 작업이 실행기에 할당되고 로그가 모두 기록되며, 실행기를 재시작한 뒤에도 예상대로 연결되어야 합니다.

실행기가 접근할 수 있는 저장소의 코드는 실행기에서도 접근할 수 있습니다. 신뢰할 수 없는 출처의 작업이 배포 서명과 같은 실행 환경을 공유하게 하지 마세요. 여러 사람이 협업한다고 해서 하나의 시스템 계정을 함께 사용해야 하는 것은 아닙니다.

Xcode 및 서명

인증서는 장비에, 권한은 프로세스에 설정해야 합니다

서명 오류가 발생하면 인증서, 개인 키, 프로비저닝 프로파일, 프로세스 권한을 먼저 확인하세요. 같은 파일을 반복해서 가져오거나 개인 키를 코드 저장소나 지원 요청 첨부 파일에 넣지 마세요.

인증서를 가져왔는데도 서명 ID를 찾을 수 없는 이유는 무엇인가요?

먼저 키체인 접근에서 인증서에 해당하는 개인 키가 있는지 확인하세요. 인증서 파일만 있고 개인 키가 없으면 서명을 완료할 수 없습니다. 개인 키가 포함된 내보내기 파일을 사용했다면 내보내기 암호와 가져올 키체인을 확인한 뒤 인증서 유효 기간도 점검하세요.

그런 다음 security find-identity -v -p codesigning 을 실행해 현재 사용자가 사용할 수 있는 서명 ID를 확인하세요. 명령 결과가 그래픽 인터페이스와 다르면 장비 모델을 바로 바꾸기보다 실행 사용자와 키체인 검색 목록을 먼저 확인하세요.

인증서는 사용할 수 있는데 빌드에서 프로비저닝 프로파일이 일치하지 않는다고 나오는 이유는 무엇인가요?

프로젝트의 Bundle Identifier, 팀 식별자, 빌드 유형, 프로비저닝 프로파일 유효 기간을 확인하세요. 개발 및 테스트용과 배포용 프로파일은 다를 수 있습니다. 기기 테스트를 한다면 대상 기기가 해당 설정에 포함되어 있는지도 확인하세요.

먼저 명확한 빌드 구성 하나를 선택해 검증하세요. Target이 여러 개인 프로젝트는 서명 설정을 각각 확인해 기본 앱과 확장 기능에 서로 다른 팀이나 만료된 프로파일이 지정되지 않았는지 점검하세요.

터미널에서는 서명되는데 CI에서는 실패하는 이유는 무엇인가요?

CI는 다른 사용자, 다른 환경 변수 또는 GUI 없는 세션에서 실행될 수 있습니다. CI가 실제로 사용하는 키체인이 잠금 해제되어 있는지, 서명 ID가 포함되어 있는지, 서명 도구가 개인 키에 접근할 수 있는지 확인하세요.

필요한 인증 정보는 CI의 보호된 비밀 설정에 저장하고 스크립트 본문에는 작성하지 마세요. 실행기 사용자로 최소한의 서명 테스트를 실행해 실패 단계를 기록하세요. 지원 요청에는 민감 정보를 가린 오류만 제공하고 키체인 암호, 내보내기 암호, 개인 키는 보내지 마세요.

여러 사람이 한 대의 물리 장비를 사용할 때 권한을 어떻게 분리하나요?

각 구성원에게 별도의 시스템 사용자를 만들고 역할에 따라 디렉터리 및 키체인 권한을 부여하세요. 자동화 작업에는 별도의 실행기 사용자를 사용하세요. 인수인계할 때 그래픽 세션을 사용 중인 사람이 있는지 확인해 다른 사람의 빌드 중에 도구 체인을 바꾸거나 공유 디렉터리를 정리하지 않도록 하세요.

이러한 조치로 실수는 줄일 수 있지만, 같은 장비의 사용자는 CPU, 메모리, 디스크를 공유합니다. 강한 격리가 필요한 프로젝트, 서로 신뢰할 수 없는 작업, 안정적인 병렬 배포에는 노드를 따로 사용하세요.

성능 및 디스크

병목부터 찾고 필요한 업그레이드를 결정하세요

컴파일이 느리다고 해서 반드시 칩이 원인인 것은 아닙니다. 먼저 활성 상태 보기에서 메모리 압력과 CPU를 확인한 다음 디스크 여유 공간, 의존성 다운로드, 동시 실행 작업 수를 점검하세요. 같은 프로젝트와 빌드 설정으로 비교하세요.

시뮬레이터와 빌드 캐시로 디스크가 가득 찼다면 어디부터 정리해야 하나요?

먼저 df -h 를 실행해 여유 공간을 확인한 다음 Xcode에서 사용하지 않는 시뮬레이터 런타임과 빌드 아카이브를 점검하세요. DerivedData는 다시 생성할 수 있지만 정리 후 다음 빌드에서는 캐시를 다시 만들어야 합니다. 사용 중인 프로젝트는 작업을 일시 중지한 뒤 정리하세요.

다음 명령으로 xcrun simctl list devices 기기를 확인하세요. 더 이상 필요하지 않은 기기임을 확인한 뒤 xcrun simctl delete unavailable 을 실행해 사용할 수 없는 기기를 정리하세요. 기기를 삭제하면 시뮬레이터의 테스트 데이터가 사라질 수 있으므로 중요한 데이터는 먼저 내보내세요.

+1TB SSD 또는 +2TB SSD는 언제 고려해야 하나요?

프로젝트, 여러 시뮬레이터 런타임, 컨테이너 이미지, 에셋을 장기간 보관해야 하고 다시 생성할 수 있는 캐시를 정리한 뒤에도 디스크 용량이 계속 부족할 때 확장을 고려하세요. +1TB SSD는 $2.2/일, +2TB SSD는 $4.4/일입니다. 다른 대여 기간의 가격은 주문 설정에서 확인하세요.

디스크를 추가하면 용량 문제는 해결할 수 있지만 메모리 부족을 대신 해결해 주지는 않습니다. 여러 작업을 동시에 실행해 메모리 압력이 계속 높다면 먼저 병렬 작업을 줄이거나 더 적합한 요금제를 검토하세요.

빌드 및 추론 작업에는 세 가지 모델 중 어떤 것이 적합한가요?

Hold 16은 M4, 16GB 메모리, 256GB SSD 구성으로 가벼운 빌드와 단일 프로젝트 CI에 적합합니다. Hold 24는 M4, 24GB 메모리, 512GB SSD 구성으로 일상적인 Xcode 개발, 여러 시뮬레이터, UI 테스트에 여유를 제공합니다.

Hold Pro 64는 M4 Pro, 64GB 메모리, 2TB SSD 구성으로 대형 프로젝트와 MLX 실험에 적합합니다. 모델 실행 가능 여부는 모델 크기, 양자화 방식, 컨텍스트 요구 사항에 따라 달라지므로 모델명만으로 판단하지 말고 직접 테스트하세요.

Thunderbolt 5 연결 구성은 어떤 작업에 적합한가요?

여러 노드를 보유하고 있고 소프트웨어 워크플로가 노드 간 협업을 지원하는 경우에 적합합니다. 추가 옵션은 노드당 $1.5/일입니다. 설정 전 참여 노드 수, 데이터 교환 방식, 애플리케이션 요구 사항을 알려 주시면 지원팀이 적용 가능 여부를 확인합니다.

연결 구성만으로 여러 장비가 메모리가 더 큰 Mac 한 대처럼 동작하거나 일반 빌드 작업이 자동으로 분산되지는 않습니다. 애플리케이션이 협업 실행을 지원하는지 먼저 확인한 후 설정을 결정하세요.

결제 및 갱신

갱신 전에 주문과 기간을 확인하세요

일간, 주간, 월간, 분기별로 대여할 수 있으며 모든 결제는 미국 달러로 처리됩니다. 주문, 만료일, 추가 옵션, 결제 상태는 콘솔 기록을 기준으로 합니다. 결제 후에는 클라이언트 알림만으로 주문이 갱신되었다고 판단하지 마세요.

만료일과 갱신 상태는 어디서 확인하나요?

콘솔에 로그인해 해당 구독의 만료일, 청구 내역, 갱신 메뉴를 확인하고 계정 이메일로 발송되는 만료 알림도 확인하세요. 이메일을 정상적으로 받을 수 있는지 점검하고, 실제 알림 시점에만 의존해 마지막 순간에 갱신하지 마세요.

결제가 완료되면 기존 구독으로 돌아가 새 만료일을 확인하세요. 청구서는 결제되었는데 구독 기간이 갱신되지 않았다면 청구서 번호와 결제 기록을 첨부해 문의하세요. 동일한 청구서를 중복 결제하지 마세요.

갱신 후 연결 정보가 바뀌나요?

같은 인스턴스를 정상적으로 갱신하는 경우 인스턴스 상세 정보에 표시된 현재 연결 정보를 계속 사용하세요. 갱신은 시스템 초기화를 뜻하지 않습니다. 장비 교체, 재구성 또는 기타 인수 변경이 발생하면 콘솔의 새 연결 정보와 서비스 알림을 따르세요.

대여를 중단하고 회수 절차가 시작된 경우 갱신을 데이터 복구 수단으로 여기지 마세요. 만료 전에 프로젝트, 인증서 백업, 다시 만들 수 없는 리소스를 내보내세요. 회수 후 디스크가 삭제되면 새로 주문해도 복구할 수 없습니다.

어떤 결제 수단을 지원하나요?

USDT-TRC20과 Visa / Mastercard / Amex(Stripe)만 지원하며 모든 결제는 미국 달러(USD)로 처리됩니다. 실제 이용 가능한 결제 게이트웨이는 백엔드 응답을 기준으로 합니다.

USDT-TRC20을 사용할 때는 결제 페이지의 네트워크, 주소, 금액을 하나씩 확인하세요. 카드 결제는 결제 게이트웨이의 안내에 따라 인증을 완료하세요. 결제 문의에는 거래 해시나 청구서 번호를 제공할 수 있지만 전체 카드 번호, 보안 코드, 지갑 개인 키는 제공하지 마세요.

요금제를 변경하거나 추가 디스크를 조정하려면 새 주문을 바로 넣어야 하나요?

먼저 현재 인스턴스 번호, 변경하려는 설정, 작업을 중단할 수 있는 시간을 기록한 다음 콘솔에서 지원 요청을 제출하세요. 이전이 필요한지, 기존 연결 정보를 유지할 수 있는지, 변경이 적용되는 시점을 실행 전에 확인해야 합니다.

추가 디스크에는 데이터 경로가 포함되므로 구독을 해지하기 전에 데이터를 옮기고 애플리케이션 설정을 확인하세요. 변경이 즉시 완료되거나 모든 데이터가 자동으로 유지되거나 자동 환불된다고 가정하지 마세요. 구체적인 처리는 주문 규정과 확인 결과를 따릅니다.

아직 해결되지 않았나요? 문제를 명확히 전달하세요

기존 인스턴스에 관한 문제는 콘솔에 로그인해 지원 요청을 제출하세요. 장비 번호, 노드, 오류 발생 시간과 시간대, 마지막으로 정상 사용한 시간, 이미 시도한 조치를 적어 주세요. 민감 정보를 가린 로그를 첨부하면 “연결할 수 없음”이라고만 적는 것보다 문제를 더 쉽게 파악할 수 있습니다.

답변 진행 상황은 콘솔의 지원 요청에서 확인하세요. 응답 시간은 문제의 유형과 점검 범위에 따라 달라지며, 이 페이지에서는 특정 분 단위의 응답 시간을 보장하지 않습니다. 구매 전 문의, 팀 구성, 로그인 불가 문의는 support@vpshold.com으로 연락하세요.

콘솔에 로그인해 지원 요청 제출 문의 및 인수인계 방법 확인