싱가포르
동남아시아 팀원이 주를 이룬다면 우선 검토해 보세요. 평소 원격 접속 네트워크와 의존성 다운로드를 함께 테스트하세요.
협업 시간대: UTC+8
주문부터 첫 빌드까지 한 번에 진행하세요. 먼저 전용 Mac을 준비하고, 접속·툴체인·코드 서명을 확인한 다음 같은 명령을 CI에서 실행합니다.
가상 머신이 아닌 전용 물리 Mac mini입니다. Apple M4 전용 Mac 두 가지 사양을 하루 $19.2부터 이용할 수 있으며 연중 365일 운영됩니다.
이미 주문하셨나요? 콘솔에서 접속 정보를 확인한 뒤 이 페이지의 첫 로그인 단계부터 진행하세요.
가입, 설정, 결제, 할당에 각각 약 1분을 예상하면 순조로운 경우 약 4분이면 개통 절차가 끝납니다. 이는 작업 예상 시간이며 고정된 전달 시간이 아닙니다. 이메일 수신, 결제 확인, 시스템 할당 상태는 콘솔에 표시된 내용을 기준으로 확인하세요.
인증 코드를 받을 수 있는 팀 이메일을 준비하고 페이지 안내에 따라 가입한 뒤 비밀번호를 설정하세요. 주문 조회, 갱신, 지원 요청을 담당할 사람이 계속 관리하는 이메일을 사용하세요. 인증 코드를 공개 빌드 로그에 전달하지 마세요.
Push M4 S 또는 Push M4 L을 선택한 뒤 결제 주기와 리전을 고르세요. 단일 앱의 일상적인 CI에는 16GB 사양을, 여러 타깃을 병렬로 archive할 때는 24GB 사양을 고려해 보세요. 실제 이용 가능 여부는 콘솔의 실시간 표시를 확인하세요.
USDT-TRC20을 선택하거나 Visa / Mastercard / Amex로 결제하세요. 카드 결제는 Stripe에서 처리합니다. 결제 페이지에 표시되는 이용 가능한 결제 게이트웨이를 확인하세요. 온체인 송금 시 네트워크, 주소, 금액을 확인하고 콘솔의 결제 확인을 기다리세요. 결제를 시작했다고 개통이 완료된 것은 아닙니다.
시스템에서 전용 Mac을 할당하면 주문 또는 인스턴스 상세 정보에서 노드, 접속 주소, 포트, 로그인 사용자를 확인하고 SSH/VNC 접속 정보를 받으세요. 이후 지원 요청에는 주문 번호만 있으면 됩니다. 로그인 비밀번호나 개인 키는 제공하지 마세요.
5개 리전에서 두 가지 사양의 전용 Mac을 이용할 수 있습니다. 먼저 평소 빌드 머신을 조작할 팀원의 위치를 기준으로 후보를 좁힌 뒤 저장소, 의존성 소스, 산출물 저장소 간 전송 경로를 확인하세요. 시간대가 편리해도 네트워크 지연이 낮다는 뜻은 아닙니다. VNC 조작과 의존성 다운로드는 각각 테스트하세요.
동남아시아 팀원이 주를 이룬다면 우선 검토해 보세요. 평소 원격 접속 네트워크와 의존성 다운로드를 함께 테스트하세요.
협업 시간대: UTC+8
일본 업무일에 주로 작업하는 팀이라면 우선 검토해 보세요. 작업이 다른 노드로 잘못 전달되지 않도록 runner 태그를 고정하세요.
협업 시간대: UTC+9
한국 팀원이 데스크톱을 자주 조작한다면 우선 검토해 보세요. 실제 사무실 네트워크에서 그래픽 인터페이스 응답 속도를 확인하세요.
협업 시간대: UTC+9
중국 남부와 동남아시아 간 협업 경로를 고려할 때 검토해 보세요. 원격 데스크톱과 SSH의 용도를 구분하고 로그는 빌드 시스템에 보관하세요.
협업 시간대: UTC+8
북미 업무 시간에 직접 조작해야 한다면 우선 검토해 보세요. 리전 간 인수인계 시 작업 시간을 UTC로 통일해 기록하세요.
협업 시간대: UTC−5 / UTC−4
미국 동부는 계절에 따라 시차가 달라집니다. 두 지역에서 모두 자주 조작해야 한다면 가까운 노드를 각각 대여하고 CI 대기열로 작업을 조정하세요. 한 대의 전용 Mac에서 여러 무거운 작업을 실행할 때도 동시 실행 수를 제한해야 합니다.
접속 주소, 포트, 사용자는 콘솔에 표시된 정보를 사용하세요. 다른 주문의 접속 정보를 재사용하지 마세요. 아래 명령어는 실제 값을 입력하라는 메시지를 표시합니다. 실행하기 전에 로컬 컴퓨터에 SSH 클라이언트가 있는지 확인하세요.
로컬 터미널에서 실행하세요. 처음 접속할 때 호스트 지문을 확인하세요. 콘솔에서 검증할 정보를 제공하지 않는다면 호스트 신원 확인을 무시하지 말고 먼저 지원 요청으로 확인하세요.
printf '접속 주소: '
read -r MAC_HOST
printf 'SSH 포트: '
read -r MAC_PORT
printf '로그인 사용자: '
read -r MAC_USER
ssh -p "$MAC_PORT" "$MAC_USER@$MAC_HOST"
로그인한 뒤 whoami 와 sw_vers를 실행해 사용자와 시스템 정보를 확인하세요. SSH 키를 설정할 때는 공개 키만 업로드하고 개인 키는 본인 기기나 CI 키 관리 시스템에 보관하세요.
그래픽 인터페이스 권한 작업은 데스크톱에서, 재현 가능한 스크립트 실행은 명령줄에서 처리하세요. 연결 시간이 초과되면 포트, 인스턴스 상태, 로컬 네트워크를 먼저 확인한 뒤 지원 요청을 제출하세요. 비밀번호를 반복해서 바꾸는 것은 네트워크 문제 해결 방법이 아닙니다.
첫 빌드는 툴체인, 프로젝트, 코드 서명, 내보내기의 네 항목을 확인합니다. 아래 명령어 예시는 workspace를 사용하는 iOS 프로젝트용입니다. project만 사용하는 프로젝트라면 -workspace 를 -project로 바꾸고 프로젝트의 실제 파일명을 사용하세요.
앱 디렉터리에 무엇이 설치되어 있는지만 보지 말고 시스템에서 실제로 선택된 Xcode를 확인하세요. 여러 버전이 설치되어 있다면 프로젝트에서 정한 앱 경로로 전환한 뒤 버전과 SDK를 다시 확인하세요.
xcode-select -p
xcodebuild -version
xcodebuild -showsdks
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
읽기 권한이 있는 저장소 주소를 입력하고 SSH 키나 안전한 자격 증명 관리 방식으로 인증하세요. 액세스 토큰을 명령어에 포함하지 마세요. 먼저 프로젝트에서 정한 방식으로 의존성을 준비한 다음 workspace와 scheme을 확인하세요.
printf '저장소 주소: '
read -r REPOSITORY_URL
git clone "$REPOSITORY_URL" app
cd app
git rev-parse HEAD
find . -name '*.xcworkspace' -prune
xcodebuild -list -workspace MyApp.xcworkspace
다음 MyApp.xcworkspace 와 MyApp 를 앞 단계에서 확인한 실제 이름으로 바꾸세요. 기기 서명이 필요한 빌드라면 먼저 해당 인증서와 프로비저닝 프로파일을 안전하게 가져오고, 빌드 프로세스가 키체인에 접근할 수 있는지 확인하세요.
mkdir -p build
xcodebuild \
-workspace MyApp.xcworkspace \
-scheme MyApp \
-configuration Release \
-destination 'generic/platform=iOS' \
-derivedDataPath build/DerivedData \
-archivePath build/MyApp.xcarchive \
archive
ExportOptions.plist 는 프로젝트에서 정한 코드 서명 및 배포 설정을 사용해야 하며 다른 팀의 설정을 그대로 복사해서는 안 됩니다. archive 성공이 내보내기 성공을 의미하지는 않습니다. 두 단계의 종료 상태와 로그를 각각 보관하세요.
xcodebuild -exportArchive \
-archivePath build/MyApp.xcarchive \
-exportPath build/export \
-exportOptionsPlist ExportOptions.plist
test -d build/MyApp.xcarchive
find build/export -maxdepth 1 -type f -print
커밋 SHA, Xcode 버전, 실제 scheme, 산출물 경로를 기록하세요. 첫 실패 시 가장 먼저 나타난 오류부터 확인하세요. 의존성 해석 실패는 네트워크와 버전 고정을, 코드 서명 실패는 인증서와 프로비저닝 프로파일을, 내보내기 실패는 내보내기 설정을 점검하세요. 한 번 재시도하면서 노드, 툴체인, 코드 서명 설정을 동시에 바꾸지 마세요.
같은 빌드 사용자로 먼저 수동 실행을 완료한 뒤 셀프 호스팅 runner를 등록하세요. 연중 계속 운영하면 머신의 전원과 호스팅 상태를 유지할 수 있지만 runner 프로세스의 자동 시작, 인증서 유효성, 대기열 작업 정체는 팀에서 설정하고 점검해야 합니다.
사용하는 CI 플랫폼의 프로젝트 또는 조직 설정에서 macOS ARM64 runner 설치 명령을 확인하세요. 현재 프로젝트에서 발급한 등록 정보를 사용하고 만료된 토큰은 재사용하지 마세요. 태그에는 노드, 아키텍처, 용도를 함께 표시하세요.
처음 연결할 때는 빌드 작업 하나만 실행하세요. 메모리, 디스크, 소요 시간을 확인한 뒤 동시 실행 수를 정하세요. 전용 Mac이라고 해서 모든 archive를 한꺼번에 실행하지 마세요.
GitHub Actions runner는 압축을 풀고 등록을 완료한 뒤 설치 디렉터리에서 패키지에 포함된 서비스 스크립트를 사용할 수 있습니다. 아래는 다운로드나 등록 명령이 아닙니다. 먼저 CI 플랫폼 안내에 따라 앞 단계를 완료하세요.
./svc.sh install
./svc.sh start
./svc.sh status
서비스 스크립트에 실행 중으로 표시되고 CI 플랫폼에서도 runner가 온라인인지 확인하세요. LaunchAgent는 보통 해당 사용자의 로그인 세션에 의존합니다. 로그인하지 않아도 시작되어야 한다면 runner에서 공식 지원하는 방법으로 설정하고 검증하세요. 서비스를 설치했다고 재시작 후 반드시 빌드할 수 있는 것은 아닙니다.
runner를 수동으로 실행한 터미널을 닫고 CI에서 제어된 작업을 한 번 실행하세요. 실행 사용자, 선택된 Xcode, 키체인 접근, 캐시 디렉터리, 산출물 업로드를 확인하세요. 무인 운영할 노드는 복구 후 runner 상태도 확인하세요. 재시작할 때는 다른 작업이 실행 중이지 않은지 먼저 확인하세요.
전용 Mac에는 DerivedData와 의존성 캐시를 보관할 수 있습니다. 캐시 키는 최소한 툴체인, 의존성 잠금 파일, 빌드 설정을 구분해야 합니다. 산출물을 보관하기 전에 정리 규칙을 설정해 캐시가 커져 시스템 디스크를 가득 채우지 않도록 하세요.
접속과 첫 빌드를 확인했다면 노드, 툴체인, 빌드 명령어를 팀 인수인계 문서에 기록하세요. 버전 전환과 캐시 세부 사항은 가이드에서 확인하고 빌드 용량을 늘리려면 먼저 요금제를 살펴보세요.