전용 Mac을 이미 이용 중이라면 지금 막힌 단계부터 확인하세요. 연결, 툴체인, 코드 서명, 파이프라인을 각각 점검해 한 번의 성공적인 빌드를 반복 가능한 배포로 이어가세요.
주소, 포트, 사용자 이름 및 제공 상태는 콘솔의 인스턴스 상세 정보를 기준으로 합니다. 명령어의 환경 변수는 실제 설정에 맞게 바꿔 사용하세요. 실제 접속 정보는 포함되어 있지 않습니다.
‘연결’, ‘Xcode’, ‘runner’, ‘결제’ 등을 검색해 보세요. 검색어를 지우면 전체 가이드를 다시 볼 수 있습니다.
SSH는 명령줄과 자동화에, VNC는 그래픽 인터페이스에 사용합니다. 두 연결 모두 같은 전용 물리 머신을 이용하지만 접속 정보는 각각 확인해야 합니다.
콘솔에서 해당 인스턴스를 열고 호스트 주소, SSH 포트, 사용자 이름을 확인하세요. 먼저 로컬에서 개인 키 경로를 확인한 뒤 연결합니다. SSH 명령에 VNC 포트를 입력하지 마세요.
chmod 600 "$SSH_KEY"
ssh -i "$SSH_KEY" -p "$SSH_PORT" "$NODE_USER@$NODE_HOST"처음 연결할 때 호스트 지문을 확인하세요. 확인할 수 없다면 호스트 검증을 끄지 말고 먼저 지원 티켓을 제출하세요. 시간 초과가 발생하면 로컬 네트워크와 포트 연결 여부를 확인하고, 권한 거부가 발생하면 사용자 이름, 키, 인스턴스의 공개 키 설정을 확인하세요.
머신을 재설치하거나 교체하면 지문이 바뀔 수 있습니다. 인스턴스가 실제로 변경된 것을 확인한 후 로컬 기록을 업데이트하세요.
콘솔에 표시된 원격 데스크톱 정보로 연결한 뒤 주소, 포트, 비밀번호를 확인하세요. 처음 접속하면 직접 사용할 비밀번호를 설정해 여러 사람이 같은 접속 정보를 장기간 공유하지 않도록 하세요.
데스크톱은 Xcode 설정, 키체인 확인, 시뮬레이터 모니터링에 적합합니다. 지속적인 빌드는 SSH나 runner로 실행하세요. SSH는 정상인데 데스크톱에 문제가 있다면 클라이언트 오류와 인스턴스 상태를 기록하고 원격 데스크톱부터 점검하세요. 먼저 머신을 반복해서 재시작하지 마세요.
SSH 터널로 접속해야 한다면 실제 VNC 포트로 포트 포워딩을 설정하고, 클라이언트에서 로컬 포트에 연결하세요:
ssh -N -L 5901:127.0.0.1:"$VNC_PORT" \
-p "$SSH_PORT" "$NODE_USER@$NODE_HOST"터널 연결을 계속 유지해야 합니다. 사용 여부와 포트는 인스턴스 설정 및 팀의 접속 정책을 따르세요.
노드는 싱가포르, 도쿄, 서울, 홍콩, 미국 동부의 5곳에 있습니다. 데스크톱을 직접 조작한다면 주요 사용자의 위치와 가까운 노드를 선택하세요. 자동 빌드는 코드 및 의존성 다운로드 경로도 고려해야 합니다. 여러 지역에 팀원이 있다면 각자 가까운 빌드 머신을 지정하고 runner 레이블로 작업을 분배하세요. 모든 팀원이 같은 데스크톱에 원격 접속할 필요는 없습니다.
노드를 비교할 때는 같은 클라이언트, 네트워크, 시간대에 연결 왕복 시간, 저장소 가져오기 시간, 전체 빌드 시간을 기록하세요. 네트워크 지연 시간과 컴파일 시간은 다르므로 네트워크 환경이 다른 결과를 그대로 비교하지 마세요.
먼저 버전을 기록하고 서명 자산을 이전하세요. 데스크톱에서 빌드된다고 해서 runner의 사용자 세션도 준비된 것은 아닙니다.
Xcode 버전별로 이름을 지정해 응용 프로그램 폴더에 설치하세요. 아래의 Stable과 Next는 직접 지정한 앱 이름이므로 실행 전에 실제 머신의 이름으로 바꾸세요. 처음 실행하고 라이선스에 동의한 뒤 필요한 플랫폼 구성 요소를 설치한 다음 파이프라인에 연결하세요.
xcode-select -p
xcodebuild -version
xcrun --sdk iphoneos --show-sdk-version
sudo xcode-select --switch \
/Applications/Xcode-Stable.app/Contents/Developer전역 버전을 바꾸면 툴체인을 명시하지 않은 작업에도 영향을 줍니다. 여러 브랜치를 동시에 빌드한다면 작업별로 환경 변수를 설정하세요. 다른 파이프라인이 현재 사용 중인 기본 버전을 바꾸는 일을 방지할 수 있습니다.
export DEVELOPER_DIR=/Applications/Xcode-Next.app/Contents/Developer
xcodebuild -version실제로 빌드를 실행하는 macOS 사용자 계정에서 코드 서명 인증서와 해당 개인 키를 가져오세요. 현재 Xcode 버전의 코드 서명 설정에 맞춰 프로비저닝 프로파일도 설치해야 합니다. 인증서만 있고 개인 키가 없으면 코드 서명을 완료할 수 없습니다.
security find-identity -v -p codesigning
xcodebuild -list -workspace App.xcworkspace프로젝트의 팀 식별자, Bundle Identifier, 서명 방식, 프로비저닝 프로파일 적용 범위를 확인하세요. 먼저 같은 사용자 계정으로 archive를 수동 실행한 다음 CI에서 같은 명령을 실행하면 프로젝트 설정 문제와 runner 세션 권한 문제를 구분할 수 있습니다.
자동화에는 전용 키체인과 관리되는 키 주입 절차를 사용하는 것이 좋습니다. 비대화형 세션에서 서명 인증서에 접근할 수 있는지 확인하세요. 키체인 비밀번호, 인증서 내보내기 비밀번호, 개인 키를 저장소에 올리거나 빌드 로그에 출력하지 마세요.
아래 예시는 workspace와 공유 scheme을 사용합니다. 프로젝트 이름, scheme, 내보내기 설정을 실제 값으로 바꾸세요. 내보내기 설정은 프로젝트의 서명 및 배포 요구 사항에 맞게 준비해야 합니다. 성공 메시지만 저장하지 말고 종료 코드, 툴체인 버전, 결과물 경로도 함께 기록하세요.
xcodebuild archive \
-workspace App.xcworkspace \
-scheme App \
-configuration Release \
-destination 'generic/platform=iOS' \
-archivePath "$HOME/builds/App.xcarchive"
xcodebuild -exportArchive \
-archivePath "$HOME/builds/App.xcarchive" \
-exportPath "$HOME/builds/export" \
-exportOptionsPlist ExportOptions.plist전용 머신 한 대를 고객 한 명만 사용하더라도 작업 간 충돌이 저절로 방지되는 것은 아닙니다. 빌드 사용자, 디렉터리, 큐 운영 규칙을 팀에서 정해야 합니다.
저장소나 조직의 runner 설정에서 Apple Silicon에 맞는 설치 패키지와 등록 명령을 가져와 전용 디렉터리에 압축을 푸세요. 해당 페이지에서 발급된 임시 토큰으로 저장소 또는 조직에 등록하고 토큰을 스크립트에 저장하지 마세요.
./config.sh \
--url "$RUNNER_URL" \
--token "$RUNNER_TOKEN" \
--labels pushmac,macos,arm64
./svc.sh install
./svc.sh start
./svc.sh status워크플로의 runs-on 은 등록한 레이블과 일치해야 합니다. 먼저 코드 서명 자산을 사용하지 않는 테스트 작업을 실행해 툴체인, 작업 디렉터리, 권한을 확인한 뒤 배포 작업을 추가하세요. 코드 서명 자산을 사용하는 runner는 신뢰할 수 있는 코드에만 허용하세요.
서비스 명령은 runner 설치 디렉터리에서 실행해야 하며, 작업 사용자와 서비스 사용자는 동일하게 유지하세요.
팀의 GitLab 인스턴스 안내에 따라 호환되는 runner를 설치한 뒤 인스턴스에서 제공한 인증 정보로 등록하세요. macOS 네이티브 빌드에는 shell 실행기를 사용할 수 있습니다. 이 경우 작업이 로컬 사용자 권한으로 실행되므로 작업을 실행할 수 있는 프로젝트와 브랜치를 제한하세요.
mkdir -p "$HOME/ci"
gitlab-runner register
gitlab-runner install --working-directory "$HOME/ci"
gitlab-runner start
gitlab-runner status안내에 따라 팀 인스턴스 주소, 토큰, 레이블, 실행기를 입력하세요. 구성 파일에 인증 정보가 들어 있을 수 있으므로 접근 권한을 제한하세요. 로그에는 작업 번호와 오류 스택만 남기고 환경 변수에 저장된 비밀 값은 출력하지 마세요.
설치 명령의 옵션은 설치된 runner 버전과 일치해야 합니다. 실행 전에 로컬 도움말을 확인하세요.
macOS 사용자 수준 서비스는 일반적으로 사용자 로그인 세션에 의존합니다. 서비스를 설치해도 로그아웃 상태에서 코드 서명 작업이 실행된다는 보장은 없습니다. runner가 사용하는 launchd 서비스 유형, 로그인 조건, 키체인 사용 가능 여부를 확인하세요. 자동 실행을 위해 팀의 접근 제어 정책을 우회하지 마세요.
관리 가능한 시간에 머신을 재시작한 뒤 서비스 상태와 전체 빌드 한 번을 확인하세요. Fastlane은 프로젝트에서 고정한 의존성을 사용해 실행합니다. 예를 들면 bundle exec fastlane ios build이며, lane 이름은 프로젝트 정의를 따릅니다. 시간대가 다른 팀이 작업을 이어받는다면 동시 실행 수와 큐 규칙을 명확히 정해 두 archive가 같은 결과물 디렉터리에 동시에 쓰지 않도록 하세요.
의존성 확인, 컴파일, 코드 서명, 내보내기에 걸리는 시간을 각각 기록하세요. 같은 커밋과 툴체인에서 캐시가 실제로 작동하는지 확인하려면 캐시가 없는 빌드와 캐시를 활용하는 빌드를 비교해야 합니다.
전용 머신에서는 대여 기간 동안 DerivedData, SPM 다운로드 파일, CocoaPods 캐시를 보관할 수 있습니다. 모든 브랜치가 같은 디렉터리에 무분별하게 쓰지 않도록 하세요. 프로젝트, 툴체인, 작업 유형별로 경로를 나누고 의존성 잠금 파일을 유지하세요.
xcodebuild archive \
-workspace App.xcworkspace \
-scheme App \
-destination 'generic/platform=iOS' \
-derivedDataPath "$HOME/ci-cache/App/stable/DerivedData" \
-clonedSourcePackagesDirPath "$HOME/ci-cache/App/stable/SPM" \
-archivePath "$HOME/builds/App.xcarchive"Flutter와 React Native 프로젝트는 각 도구 버전과 iOS 의존성 잠금 상태도 맞춰야 합니다. 문제가 생기면 먼저 실패 로그를 보존한 뒤 관련 캐시만 정리하세요. 매번 빌드할 때마다 모든 캐시를 삭제하면 캐시를 활용한 빌드의 이점을 잃게 됩니다.
Push M4 S는 M4 / 16GB / 256GB 구성으로 단일 앱의 일상적인 CI에 적합합니다. Push M4 L은 M4 / 24GB / 512GB 구성으로 메모리 사용량이 많거나 여러 타깃을 빌드하는 경우에 적합합니다. 병렬 실행 가능 여부는 프로젝트에서 측정한 실제 최대 사용량을 기준으로 판단하세요.
+1TB SSD는 의존성 캐시, 여러 툴체인, 과거 결과물이 쌓여 시스템 디스크가 부족해지는 경우에 적합합니다. +2TB SSD는 프로젝트 캐시와 archive를 더 많이 보관해야 하는 워크플로에 적합합니다. 저장 공간 추가는 통합 메모리를 늘리거나 용량에 비례해 컴파일 속도를 높이지 않습니다.
df -h
du -sh "$HOME/ci-cache" "$HOME/builds"먼저 마운트 경로를 확인한 뒤 캐시를 이전하고 파이프라인 변수를 변경하세요. 저장 공간 추가는 백업을 대신하지 않습니다. archive, 심볼 파일, 중요한 설정은 팀 정책에 따라 별도 사본으로 보관하세요.
결제 주기, 노드, 결제 상태는 콘솔에 표시된 정보를 기준으로 합니다. 지원 티켓을 제출할 때는 주문 번호를 포함하고 비밀번호, 개인 키, 카드 정보를 전체 그대로 보내지 마세요.
일, 주, 월, 분기 단위로 이용할 수 있습니다. Push M4 S는 일 $19.2, 주 $51.8, 월 $95.9, 분기 $260.8이며, Push M4 L은 일 $39.7, 주 $107.2, 월 $198.5, 분기 $539.9입니다. 콘솔에서 인스턴스 만료 시간, 갱신 메뉴, 이용 가능한 주기를 확인하세요. 일 요금에 날짜를 곱한 금액을 다른 주기의 표시 요금으로 간주하지 마세요.
배포 전에 대여 기간이 빌드와 검수 일정을 모두 포함하는지 확인하세요. 주기를 변경하려면 콘솔에서 해당 작업과 실제 청구 내역을 확인하세요. 이미 결제한 요금이 다른 주기로 자동 전환된다고 가정하지 마세요.
노드를 변경하면 네트워크 접속 정보와 머신 환경이 바뀌므로 지역 레이블만 수정하는 것과는 다릅니다. 먼저 콘솔에서 지원 티켓을 제출해 처리 방법을 확인한 뒤 코드, 서명 자산, runner 설정, 필요한 결과물을 백업하세요. 로컬 파일, 캐시, 로그인 정보가 자동으로 이전된다고 가정하지 마세요.
이전이 끝나면 호스트 지문, runner 레이블, 코드 서명 권한을 다시 확인하고 빌드를 한 번 검증한 뒤 이전 환경으로 작업이 배정되지 않도록 하세요.
USDT-TRC20 및 Stripe를 통한 Visa / Mastercard / Amex 카드 결제만 지원하며, 모든 요금은 미국 달러(USD)로 결제됩니다. 실제 이용 가능한 결제 게이트웨이는 서버 응답을 기준으로 합니다. 온체인 결제는 해당 주문에 표시된 네트워크, 수취 정보, 금액을 확인해 진행하고 이전 주문 정보를 재사용하지 마세요.
결제 후 먼저 주문 상태를 확인하세요. 확인이 필요하면 지원 티켓에 주문 번호, 결제 시간, 트랜잭션 해시 또는 결제 참조 번호를 적으세요. 상태를 갱신하려고 다시 결제하지 마세요.
물리 노드는 연중 365일 운영되며 데이터센터에서 전원, 네트워크, 냉각을 관리합니다. 연속 가동은 프로젝트 백업을 대신하지 않으며 클라이언트 네트워크의 연결 중단을 방지하지도 않습니다. 원격 세션 연결이 끊기면 먼저 인스턴스 상태와 다른 연결 방식을 확인한 뒤 머신 문제인지 판단하세요.
대여 기간이 끝나면 다음 고객에게 제공하기 전에 머신을 완전히 초기화합니다. 대여 종료 전에 필요한 코드, 결과물, 설정을 내보내고 runner 등록을 해제한 뒤 관련 액세스 토큰을 폐기하세요. 인스턴스를 유일한 보관 장소로 사용하지 마세요.
이 페이지에서는 바로 실행할 수 있는 작업을 다룹니다. 이전, 캐시 설계, 시간대별 업무 분담은 기술 문서 목록에서 자세히 확인하세요.
실제로 게시된 글에서 주제를 선택해 자세한 절차와 적용 조건을 확인하세요. 툴체인을 이전하거나 캐시 디렉터리를 변경하기 전에 현재 설정을 기록하고 롤백 방법을 마련한 뒤 하나씩 검증하세요.
이 가이드의 명령어는 작업 방법을 설명하기 위한 것입니다. 기술 문서의 방법도 저장소 구조, 코드 서명 정책, 팀 권한을 고려해 적용해야 합니다.
아시아 태평양과 북미의 팀원이 같은 문제를 이어서 해결할 때는 단순히 ‘연결이 안 됨’이라고 쓰기보다 발생 시간과 노드를 명확히 적으면 다음 단계로 이어가기 쉽습니다.
주문 또는 인스턴스 번호, 사용 중인 노드, 발생 시각과 시간대를 적으세요. 팀원이 서로 다른 네트워크를 사용한다면 각자의 접속 위치도 기재하세요.
클라이언트 오류, 빌드 명령, 종료 코드, Xcode 버전, 관련 로그의 마지막 부분을 첨부하세요. 스크린샷이나 텍스트를 제출하기 전에 비밀 정보를 삭제하세요.
SSH와 VNC가 각각 작동하는지, 문제가 재현되는지, 최근 어떤 설정을 변경했는지 적어 다음 담당자가 같은 점검을 반복하지 않도록 하세요.
콘솔에 로그인해 지원 티켓을 제출하고 인스턴스 및 주문 문제를 문의하세요. 로그인할 수 없다면 다음 주소로 이메일을 보내세요: support@pushmac.com 계정 이메일 주소와 문의 내용을 적어 주세요.