콘솔에 처음 로그인하기
주문에 사용한 이메일로 콘솔에 로그인하고 화면의 안내에 따라 계정을 활성화하거나 로그인하세요. 인스턴스 목록에서 주문한 모델, 노드, 요금 주기를 확인하세요.
결제가 완료되어도 시스템이 준비된 것은 아닙니다. 먼저 인스턴스 제공 상태를 확인하고, 인스턴스 상세 정보에 연결 정보가 표시된 뒤에 연결을 시작하세요. 주문을 찾을 수 없다면 현재 이메일이 주문 시 사용한 이메일과 같은지 확인하세요.
로그인해 인스턴스 확인노드를 받으셨나요? 먼저 데스크톱에 연결하고 비밀번호를 변경한 뒤 빌드 또는 추론 작업을 시작하세요. 아직 주문 전이라면 사용 방법을 먼저 확인하고 적합한 요금제를 선택하세요.
키워드를 입력해 이 페이지의 안내를 필터링하거나, 전체 내용을 살펴보세요.
연결 주소와 인증 정보는 로그인 후 인스턴스 상세 정보에서 확인하세요. 이 페이지에는 인증 정보가 표시되지 않으며 원격 작업도 실행되지 않습니다.
도구 이름이나 더 짧은 증상을 검색해 보세요. 예: “SSH”, “검은 화면”, “디스크”. 검색을 지우고 전체 내용을 보거나, 콘솔에서 오류 전문을 첨부해 지원 티켓을 제출할 수도 있습니다.
아래 순서대로 진행하세요. 먼저 인스턴스와 연결 정보를 확인한 다음 도구 체인을 설정하세요. 연결 문제와 빌드 문제를 한꺼번에 해결하려 하지 마세요.
주문에 사용한 이메일로 콘솔에 로그인하고 화면의 안내에 따라 계정을 활성화하거나 로그인하세요. 인스턴스 목록에서 주문한 모델, 노드, 요금 주기를 확인하세요.
결제가 완료되어도 시스템이 준비된 것은 아닙니다. 먼저 인스턴스 제공 상태를 확인하고, 인스턴스 상세 정보에 연결 정보가 표시된 뒤에 연결을 시작하세요. 주문을 찾을 수 없다면 현재 이메일이 주문 시 사용한 이메일과 같은지 확인하세요.
로그인해 인스턴스 확인준비가 완료된 인스턴스의 상세 정보에서 연결 주소, 사용자 이름, 비밀번호, 포트를 확인하세요. 페이지에 표시된 VNC 및 SSH 정보를 각각 사용하고, 두 연결에 같은 포트가 사용된다고 가정하지 마세요.
SSH에 처음 연결할 때는 호스트 정보를 확인한 뒤 지문을 신뢰하세요. 비밀번호, 개인 키 또는 인증 정보가 포함된 스크린샷을 공개 저장소, 채팅방, 빌드 로그에 올리지 마세요.
플랫폼별 연결 방법 보기먼저 현재 경로와 버전을 확인한 다음 설치 여부를 결정하세요. 프로젝트에 정식 Xcode가 필요하다면 명령줄 도구만으로는 충분하지 않습니다. SDK, 시뮬레이터, 빌드 도구 버전이 프로젝트 요구사항에 맞아야 합니다.
xcode-select -p
xcodebuild -version
xcrun --find clang
조직에서 승인한 설치 패키지를 사용해 Xcode를 설치하거나 버전을 전환하세요. 처음 실행한 뒤 구성 요소 초기화를 완료하고 터미널에서 버전을 다시 확인하세요. 개발자 디렉터리를 바꾸려면 관리자 권한이 필요할 수 있습니다.
확인 항목: 경로, 버전, 컴파일러macOS 사용자 설정에서 현재 사용자 비밀번호를 변경하거나 터미널에서 passwd 를 실행하고 안내에 따라 변경하세요. 다른 서비스에서 쓰지 않는 강력한 비밀번호를 사용하세요.
변경 후 현재 세션을 유지한 채 두 번째 연결로 새 비밀번호를 확인하세요. SSH를 공개 키 인증으로 전환할 때도 새 세션으로 로그인되는지 먼저 확인하세요. 복구 방법이 없다면 기존 인증 방식을 바로 끄지 마세요.
새 연결을 확인한 뒤 기존 세션 종료runner 등록, 실행 사용자 확인, 도구 체인 검증을 먼저 마친 뒤 동시 실행을 최적화하세요. 아래 작업은 사용자의 노드에서 진행하며, 파이프라인 권한은 코드 호스팅 플랫폼에서 관리합니다.
저장소 또는 조직의 Actions 설정에서 self-hosted runner를 추가하고 macOS와 ARM64를 선택하세요. 다운로드 및 등록 명령은 해당 페이지에서 생성된 최신 내용을 사용하고, 등록 토큰을 장기간 사용하는 스크립트에 넣지 마세요.
실제 빌드를 실행할 macOS 사용자로 등록하세요. 이 사용자가 프로젝트 디렉터리를 읽고 빌드에 필요한 키체인에 접근할 수 있는지 확인하세요.
예를 들어 노드에 osxflow-m4 태그를 지정한 다음 테스트 워크플로 하나만 해당 태그로 실행하세요. 이전 runner가 같은 작업을 가져가지 않도록 할 수 있습니다.
먼저 대화형으로 실행해 워크플로가 통과하는지 확인한 뒤 runner에 포함된 서비스 안내에 따라 상시 실행을 설정하세요. 다시 로그인한 후 프로세스와 플랫폼의 연결 상태를 확인하세요.
jobs:
verify:
runs-on: [self-hosted, macOS, ARM64, osxflow-m4]
steps:
- run: |
uname -m
xcodebuild -version
xcrun --find clang
신뢰할 수 없는 외부 기여자가 서명 자료에 접근할 수 있는 runner를 사용하지 못하게 하세요. 테스트 파이프라인이 통과한 뒤 배포 흐름과 비밀 변수를 옮기세요.
프로젝트 또는 그룹 설정에서 생성한 runner 인증 정보로 등록하고 실행기 유형은 shell을 선택하세요. 작업은 노드 사용자 환경에서 직접 실행되며 컨테이너 수준의 격리는 제공되지 않습니다.
여러 서명 작업이나 캐시 쓰기가 서로 간섭하지 않도록 동시 실행 수를 먼저 1로 제한하세요. runner 사용자의 PATH와 개발자 디렉터리, Ruby 환경이 수동 테스트 때와 같은지 확인하세요.
concurrent = 1
[[runners]]
executor = "shell"
shell = "bash"
이 예시는 등록 후 설정 파일에서 관련된 항목만 보여 줍니다. 전체 등록 설정이 아닙니다. 등록 도구가 생성한 주소, 인증 정보 및 기타 항목은 유지하고 이 내용으로 파일 전체를 덮어쓰지 마세요.
runner에 전용 태그를 설정하고 테스트 작업에서 whoami와pwd 및 xcode-select -p를 출력하게 하세요. 터미널에서는 빌드되는데 CI에서 실패한다면 도구를 다시 설치하기보다 사용자, 경로, 환경 변수를 먼저 비교하세요.
팀에서 승인한 절차에 따라 인증서, 개인 키, 프로비저닝 프로파일을 가져오세요. 소스 코드 저장소에 넣지 말고 Fastlane 출력에 암호 해독용 비밀번호를 표시하지 마세요.
전용 물리 머신을 사용하더라도 프로젝트 권한 관리는 별도로 필요합니다. 배포 파이프라인을 수정할 수 있는 사람은 작업을 통해 서명 환경을 읽을 수도 있으므로 저장소 권한도 함께 검토하세요.
상위 모델 사양은 M4 Pro / 64GB / 2TB입니다. 통합 메모리는 시스템과 작업이 함께 사용하므로 64GB 전부를 모델에 할당할 수 있는 것은 아닙니다. 가중치, 컨텍스트, 실행 캐시에 필요한 메모리를 확보하세요.
먼저 Python이 ARM64 아키텍처를 사용하는지 확인한 다음 실험마다 가상 환경을 만드세요. 서로 다른 모델 프로젝트의 의존성을 시스템 환경에 함께 설치하지 마세요.
python3 -c "import platform; print(platform.machine())"
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install mlx-lm
python -m pip freeze > requirements.lock.txt
의존성 목록, Python 버전, 모델 버전을 저장하세요. 실험을 재현할 때는 같은 환경을 먼저 구성한 다음 출력과 리소스 사용량을 비교하세요.
목표: 독립된 환경, 재현 가능한 의존성사용 권한이 있는 MLX 호환 양자화 모델을 선택하고 모델 설명을 먼저 읽으세요. 양자화 비트 수, 컨텍스트 길이, 생성 길이를 기록하고 모델 파일 크기만 비교하지 마세요.
python -m mlx_lm.generate --help
설치된 버전의 도움말에 따라 모델과 프롬프트를 지정하세요. 먼저 한 번 추론을 완료한 뒤 컨텍스트를 점차 늘리세요. 활성 상태 보기를 통해 메모리 압력과 스왑 공간을 확인하고 압력이 계속 높아지면 작업 규모를 줄이세요.
실험을 비교할 때는 프롬프트, 생성 길이, 동시 실행 수를 동일하게 유지하세요. 모델과 양자화 방식이 다르면 결과를 노드 성능 차이로 바로 해석할 수 없습니다.
처리량을 미리 단정하지 않으며 모델이 반드시 메모리에 들어간다고 보장하지 않습니다저장 공간을 늘리려면 주문 구성에서 +2TB SSD를 선택할 수 있습니다. 노드에서 실제 마운트 경로와 사용 가능 용량을 확인한 다음 모델 가중치와 다운로드 캐시를 옮기세요. 모든 노드에서 같은 볼륨 이름을 사용한다고 가정하지 마세요.
이동하기 전에 모델을 읽는 작업을 중지하세요. 복사가 끝나면 파일 수와 크기를 확인한 다음 도구의 모델 경로나 캐시 설정을 변경하세요. 먼저 모델이 정상적으로 로드되는지 확인한 뒤 원본을 삭제하세요.
저장 공간 확장은 백업이 아닙니다. 대여 노드에만 보관하지 않도록 모델 버전, 설정, 중요 결과를 직접 관리하는 위치에 별도로 저장하세요.
저장 공간 확장 및 가격 보기주문, 연결, 지원 티켓에서 같은 정의를 사용합니다. 동일한 용어로 문제를 설명하면 머신, 연결 프로토콜, 요금 설정을 더 빠르게 구분할 수 있습니다.
먼저 오류 원문을 기록한 다음 설정을 변경하세요. 연결된 세션 하나는 유지하고, 테스트를 위해 유일한 액세스 방법을 바로 끄지 마세요.
먼저 인스턴스 상세 정보에서 시스템이 준비된 상태인지 확인한 다음 VNC 주소와 포트를 확인하세요. 연결을 끊고 클라이언트 하나만 사용해 다시 시도하세요. 해상도를 낮추거나 자동 화질 조정을 끄면 클라이언트 표시 문제와 노드 세션 문제를 구분하는 데 도움이 됩니다.
SSH로 계속 연결할 수 있다면 작업 중인 노드를 바로 재시작하지 마세요. 사용한 클라이언트 이름과 버전, 검은 화면이 나타나기 전에 한 작업, SSH 사용 가능 여부를 기록하세요. 지원 티켓에는 인증 정보가 없는 스크린샷을 첨부하세요.
플랫폼별 데스크톱 연결 방법 보기Connection refused 주소, 포트, 서비스 상태를 먼저 확인하세요. 연결 시간이 초과되면 로컬 네트워크, 프록시, 액세스 제한을 먼저 살펴보세요. Permission denied 가 표시되면 사용자 이름과 인증 방식을 먼저 확인하세요. 인증 실패를 네트워크 문제로 잘못 판단하지 마세요.
디버깅할 때는 ssh -v 를 사용해 연결 단계를 확인할 수 있습니다. 전체 디버그 로그를 공개하지 마세요. 공유하기 전에 주소, 사용자 이름, 키 경로, 인증 관련 내용을 가리세요. 개인 키를 사용한다면 파일 권한과 서버 측 공개 키가 서로 맞는지도 확인하세요.
그래픽 데스크톱에 계속 접속할 수 있다면 시스템 설정에서 원격 로그인을 먼저 확인하세요. 원인을 판단하기 어렵다면 오류 원문, 노드 번호, 사용한 포트를 적어 지원 티켓을 제출하세요. 여러 인증 설정을 연달아 변경하지 마세요.
다운로드, 검증, 압축 해제 중 어느 단계인지 먼저 확인하세요. 네트워크 트래픽, CPU, 디스크 활동을 살펴보세요. 네트워크가 잠시 조용해도 디스크가 계속 작동한다면 다운로드가 중단된 것이 아닐 수 있습니다. 같은 설치 작업을 여러 번 시작하지 마세요.
설치 패키지, 압축 해제된 파일, 프로젝트 캐시를 모두 저장할 공간이 대상 디스크에 있는지 확인하세요. 특정 버전을 고정해야 한다면 조직에서 승인한 설치 패키지를 사용하고 무결성을 확인하세요. 설치 후 xcodebuild -version을 다시 실행해 CI와 그래픽 인터페이스에서 같은 버전을 사용하는지 확인하세요.
지원 티켓에는 Xcode 버전, 현재 단계, 남은 디스크 공간, 프록시 사용 여부를 적으세요. “느립니다”라고만 쓰지 마세요.
먼저 볼륨 용량을 확인한 다음 용량을 많이 차지하는 디렉터리를 찾으세요. 아래 명령은 용량만 조회하며 파일을 삭제하지 않습니다. 사용자 디렉터리가 크면 용량 계산에 시간이 걸릴 수 있습니다.
df -h
du -sh "$HOME/Library/Developer/Xcode/DerivedData"
du -sh "$HOME/Library/Caches"
빌드를 일시 중지한 뒤 다시 만들 수 있는 캐시를 정리하세요. 키체인, 서명 자료, 프로젝트 소스 파일, 유일한 모델 사본은 디렉터리째 삭제하지 마세요. 캐시를 비우면 첫 빌드에서 파일을 다시 생성하므로 배포 일정에 필요한 시간을 반영하세요.
계속 늘어나는 모델 가중치와 빌드 산출물은 별도로 용량을 계획하는 편이 좋습니다. +1TB SSD 및 +2TB SSD 추가 옵션을 확인하세요. 기존 주문을 변경하려면 콘솔에서 지원 티켓으로 처리 방법을 먼저 확인하세요. 용량을 추가하면 프로젝트가 자동으로 이동한다고 가정하지 마세요.
SSD 추가 옵션 보기이 페이지에서는 “다음에 무엇을 해야 하는지”를 안내합니다. 빌드 실무, 장비 선택, 데이터 보호에 관한 자세한 내용은 기술 문서 목록에서 확인하세요. 문서 제목, 요약, 게시일은 목록에 표시된 정보를 기준으로 합니다.
이미 구매한 고객은 인스턴스와 연결하기 쉽도록 콘솔에 로그인해 지원 티켓을 제출하는 것이 좋습니다. 비밀번호, 개인 키, 전체 카드 번호 또는 인증 정보가 포함된 스크린샷은 제출하지 마세요.
노드 번호, 주문 번호, 문제가 발생한 대략적인 시각과 시간대를 적으세요. 결제 관련 문제라면 거래 식별 정보만 제공하고 인증 정보는 보내지 마세요.
무엇을 실행했고, 어떤 결과를 예상했으며, 실제로 무엇을 확인했는지 적으세요. 연결 문제에는 클라이언트와 버전을, 빌드 문제에는 도구 체인 버전을 포함하세요.
민감 정보를 가린 오류 원문을 붙이고, 그래픽 데스크톱과 SSH 중 어느 쪽을 사용할 수 있는지, 중단할 수 없는 작업이 실행 중인지 알려 주세요.
콘솔에서 인스턴스와 연결된 지원 티켓을 제출하세요. 구매 전 상담, 이메일 문의, 청구 관련 문제는 문의 안내를 먼저 확인할 수도 있습니다.