파이프라인은 그대로, 실행 머신만 교체

이제 클라우드 Mac 한 대에서 실행하는 파이프라인

macOS가 필요한 빌드와 테스트 단계만 전용 물리 Mac mini로 옮기세요. 네이티브 iOS, Flutter, Unity, MLX는 각각 다른 리소스 병목이 있습니다. 먼저 명령과 사전 조건을 확인한 뒤 메모리, 캐시, 동시 작업 수에 맞춰 플랜을 선택하세요. 실제로 적용할 수 있는 워크플로를 소개하며, 실행 시간 벤치마크는 아닙니다.

가상 머신이 아닌 전용 물리 머신입니다. 하루 단위로 대여할 수 있으며 시작 가격은 $20.5/일입니다. 실제 이용 가능 여부는 콘솔에서 실시간으로 확인하세요.

워크로드별로 찾아보기

총 5개 시나리오가 모두 펼쳐져 있습니다. 카테고리를 선택하면 관련 시나리오가 강조되고 해당 위치로 이동합니다. 다른 콘텐츠는 숨겨지지 않습니다.

트리거부터 검수 결과물까지

실행 단계를 찾아보세요

아래 명령은 노드 안에서 실행합니다. 프로젝트 의존성을 먼저 설치한 뒤 해당 환경 변수를 설정하세요. 경로는 본인의 프로젝트와 구성 파일을 가리켜야 합니다. 복사 버튼은 명령만 복사하며 작업을 실행하지 않습니다.

네이티브 iOS · 야간 빌드

Git 푸시로 archive를 만들고, 업로드는 fastlane에 맡기세요.

클라우드 Mac을 GitHub Actions self-hosted runner, GitLab Runner 또는 Jenkins agent로 등록하세요. 릴리스 브랜치에 푸시되면 고정된 커밋을 체크아웃한 뒤 Release archive와 IPA를 생성합니다. TestFlight 업로드는 별도 단계로 실행해 빌드 실패와 업로드 실패를 각각 재시도할 수 있습니다.

먼저 준비할 항목 3가지

  • 다음을 설정하세요: WORKSPACE, SCHEME 및 EXPORT_OPTIONS는 각각 워크스페이스, 공유 scheme, 내보내기 구성 파일을 가리켜야 합니다.
  • 현재 빌드 사용자에 서명 인증서와 프로비저닝 프로파일을 설정하세요. fastlane match로 관리할 수 있으며, 복호화 자격 증명은 CI 시크릿으로 주입하세요.
  • 다음을 설정하세요: ASC_API_KEY_JSON은 fastlane에서 사용할 App Store Connect API 키 JSON 파일을 가리켜야 합니다. 키를 코드 저장소에 넣지 마세요.

검수할 항목

아카이브 build/App.xcarchive, 내보낸 IPA, 커밋 식별자, Xcode 버전을 확인하세요. 해당 빌드가 TestFlight에 접수되었는지도 확인해야 합니다. 빌드 명령이 성공적으로 끝났다고 업로드까지 완료된 것은 아닙니다.

추천 이유: Host M4 Plus의 24GB 통합 메모리는 여러 타깃을 일상적으로 빌드하기에 적합합니다. 먼저 순차 실행으로 워크플로를 안정화한 뒤 메모리 압력과 DerivedData 사용량을 확인해 동시 실행 여부를 결정하세요.

archive → export → upload
set -euo pipefail
: "${WORKSPACE:?Set WORKSPACE}"
: "${SCHEME:?Set SCHEME}"
: "${EXPORT_OPTIONS:?Set EXPORT_OPTIONS}"
: "${ASC_API_KEY_JSON:?Set ASC_API_KEY_JSON}"

mkdir -p build
xcodebuild -version
xcodebuild \
  -workspace "$WORKSPACE" -scheme "$SCHEME" \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  -archivePath build/App.xcarchive archive

xcodebuild -exportArchive \
  -archivePath build/App.xcarchive \
  -exportPath build/export \
  -exportOptionsPlist "$EXPORT_OPTIONS"

IPA_PATH="$(find build/export -type f -name '*.ipa' -print -quit)"
test -n "$IPA_PATH"
bundle exec fastlane pilot upload \
  --ipa "$IPA_PATH" \
  --api_key_path "$ASC_API_KEY_JSON"
사용 플랜: Host M4 Plus · M4 / 24GB / 512GB 추천 노드: 일본(도쿄)
Host M4 Plus 대여하기

크로스 플랫폼 · Flutter

Android는 Linux에서 계속 실행하고 iOS 단계만 옮기세요.

양쪽 플랫폼의 파이프라인 전체를 옮길 필요는 없습니다. Linux runner는 Android 작업을 맡고, 클라우드 Mac은 CocoaPods, Xcode 컴파일, IPA 내보내기를 처리합니다. 양쪽에서 같은 커밋 식별자를 사용하고 결과물을 마지막에 취합하세요. 한쪽이 실패하면 해당 작업만 다시 실행하면 됩니다.

캐시 무효화 조건 설정

  • Flutter, Ruby, CocoaPods, Xcode 버전을 고정하고 다음 파일을 유지하세요: pubspec.lock, Podfile.lock 및 Gemfile.lock.
  • Pub 및 CocoaPods 다운로드 디렉터리를 캐시하세요. 캐시 키에는 최소한 도구체인 버전과 의존성 잠금 파일의 해시를 포함해야 합니다.
  • 여러 동시 작업이 같은 프로젝트 디렉터리에 쓰지 않도록 하세요. 작업마다 DerivedData와 출력 디렉터리를 분리해 캐시가 서로 섞이지 않게 하세요.

검수할 항목

다음 경로에 있는 build/ios/ipa 의 서명된 IPA, 빌드 로그, 의존성 잠금 파일을 보관하세요. 먼저 기기에 설치하거나 후속 테스트 작업으로 결과물을 검증한 뒤 빌드 결과를 릴리스 가능 상태로 표시하세요.

추천 이유: Host M4 Lite는 단일 작업으로 시작하기에 적합합니다. 시뮬레이터를 열고 테스트와 패키징을 동시에 진행한다면 먼저 메모리 사용량의 최고치를 측정하세요. 동시 작업을 무작정 늘리기보다 필요할 때 Host M4 Plus를 고려하세요.

Flutter · iOS 작업
set -euo pipefail
: "${EXPORT_OPTIONS:?Set EXPORT_OPTIONS}"

flutter --version
xcodebuild -version
flutter doctor -v
bundle check || bundle install
flutter pub get

(
  cd ios
  bundle exec pod install --deployment
)

flutter build ipa \
  --release \
  --export-options-plist="$EXPORT_OPTIONS"

find build/ios/ipa -type f -name '*.ipa' -print
사용 플랜: Host M4 Lite · M4 / 16GB / 256GB 추천 노드: 싱가포르
Host M4 Lite 대여하기

게임 · iOS 패키지

Unity에서 내보낸 프로젝트를 가져와 서명, 패키징, 용량 검사를 진행하세요.

Unity 리소스 처리와 Xcode 컴파일은 별개의 단계입니다. 먼저 프로젝트의 자체 내보내기 절차로 Xcode 프로젝트를 만든 뒤 클라우드 Mac에서 archive와 export를 실행하세요. 패키지 용량을 비교할 때는 같은 리소스 설정을 사용해야 변화가 리소스, 컴파일 옵션, 내보내기 방식 중 어디서 비롯됐는지 판단할 수 있습니다.

내보내기 경계를 명확히 하세요

  • UNITY_IOS_DIR 은 내보낸 iOS 프로젝트 디렉터리를 가리켜야 합니다. 아래 명령은 Xcode 단계부터 시작하며 프로젝트의 Unity 빌드 스크립트를 대신하지 않습니다.
  • 플러그인에서 workspace가 생성되면 UNITY_WORKSPACE를 설정하고, 그렇지 않으면 Unity-iPhone.xcodeproj를 사용하세요. 두 진입점을 함께 사용하지 마세요.
  • 서명 구성과 EXPORT_OPTIONS를 준비하세요. App Thinning 보고서가 필요하면 내보내기 구성에서 해당 보고서 옵션을 활성화하세요.

검수할 항목

IPA 파일 크기, 내보내기 로그, 리소스 변경 사항을 확인하세요. IPA 압축 용량은 사용자가 실제로 다운로드하거나 설치하는 용량과 다릅니다. 릴리스 결정 시 내보내기 보고서와 배포 처리 결과도 함께 확인해야 합니다.

추천 이유: Host M4 Pro는 64GB 통합 메모리와 2TB SSD를 제공해 대규모 리소스 프로젝트와 아카이브 캐시에 적합합니다. 리소스 가져오기, 컴파일, 내보내기 각 단계의 사용량을 먼저 기록한 뒤 작업 큐를 구성하세요.

Unity export → Xcode
set -euo pipefail
: "${UNITY_IOS_DIR:?Set UNITY_IOS_DIR}"
: "${EXPORT_OPTIONS:?Set EXPORT_OPTIONS}"

mkdir -p build
if [ -n "${UNITY_WORKSPACE:-}" ]; then
  xcodebuild -workspace "$UNITY_WORKSPACE" \
    -scheme Unity-iPhone -configuration Release \
    -destination 'generic/platform=iOS' \
    -archivePath build/Game.xcarchive archive
else
  xcodebuild \
    -project "$UNITY_IOS_DIR/Unity-iPhone.xcodeproj" \
    -scheme Unity-iPhone -configuration Release \
    -destination 'generic/platform=iOS' \
    -archivePath build/Game.xcarchive archive
fi

xcodebuild -exportArchive \
  -archivePath build/Game.xcarchive \
  -exportPath build/game-export \
  -exportOptionsPlist "$EXPORT_OPTIONS"

find build/game-export -type f -name '*.ipa' \
  -exec du -h {} \;
사용 플랜: Host M4 Pro · M4 Pro / 64GB / 2TB 추천 노드: 한국(서울)
Host M4 Pro 대여하기

네이티브 iOS · 호환성 회귀 테스트

Xcode 버전을 고정하고 시뮬레이터 테스트 매트릭스를 하나씩 실행하세요.

새 시스템 호환성은 컴파일 성공만으로 확인할 수 없습니다. 주요 탐색 흐름, 권한 팝업, 다크 모드, 핵심 레이아웃을 테스트에 포함하고 Xcode 버전과 시뮬레이터 런타임별로 결과를 보관하세요. 먼저 매트릭스를 순차 실행해 재현성을 확보한 뒤 동시 실행할 가치가 있는 테스트를 정하세요.

버전과 기기를 모두 추적 가능하게

  • xcodes로 여러 Xcode 버전을 관리할 수 있습니다. 각 작업에서 DEVELOPER_DIR 를 설정해 버전을 선택하면 동시 작업 중 시스템 전체의 기본 도구체인이 바뀌는 것을 방지할 수 있습니다.
  • 현재 Xcode에서 사용할 수 있는 시뮬레이터를 확인한 뒤 SIM_A 와 SIM_B 에 서로 다른 기기의 UDID를 설정하세요. 실행 전에 해당 시뮬레이터를 설치해야 합니다.
  • 다음 파일을 보관하세요: .xcresult만 저장하고 터미널의 마지막 줄만 남기지 마세요. UI 스크린샷, 실패한 테스트 케이스, 재시도 기록을 같은 커밋과 연결할 수 있어야 합니다.

검수할 항목

각 대상의 테스트 종료 코드와 결과 번들을 따로 확인하세요. 시뮬레이터 회귀 테스트로는 실제 기기의 주변 기기, 성능, 배포 검증을 대신할 수 없습니다. 이런 작업은 별도로 계획하세요.

추천 이유: Host M4 Plus는 일상적인 회귀 테스트를 시작하기에 적합합니다. 실행 가능한 시뮬레이터 수는 실제 메모리 압력에 따라 결정해야 하며, 24GB가 무제한 동시 실행을 뜻하지는 않습니다.

Xcode · 시뮬레이터 매트릭스
set -euo pipefail
: "${DEVELOPER_DIR:?Set DEVELOPER_DIR}"
: "${WORKSPACE:?Set WORKSPACE}"
: "${SCHEME:?Set SCHEME}"
: "${SIM_A:?Set SIM_A}"
: "${SIM_B:?Set SIM_B}"
export DEVELOPER_DIR

mkdir -p build
xcodebuild -version
xcrun simctl list devices available

RUN_ID="$(date +%s)-$$"
for DEVICE_ID in "$SIM_A" "$SIM_B"; do
  xcodebuild test \
    -workspace "$WORKSPACE" \
    -scheme "$SCHEME" \
    -destination "platform=iOS Simulator,id=$DEVICE_ID" \
    -parallel-testing-enabled NO \
    -resultBundlePath \
      "build/$RUN_ID-$DEVICE_ID.xcresult"
done
사용 플랜: Host M4 Plus · M4 / 24GB / 512GB 추천 노드: 홍콩
Host M4 Plus 대여하기

AI · MLX 추론 실험

모델을 통합 메모리에 올리고 안정적으로 실행되는지 먼저 확인하세요.

Apple Silicon 물리 노드에서 MLX로 호환 모델을 로드하고 생성 속도, 최대 메모리 사용량, 컨텍스트 길이를 기록하세요. 먼저 단일 요청을 검증한 뒤 배치 처리를 테스트하세요. 빌드 작업과 추론 실험은 같은 머신의 리소스를 공유하므로 측정 없이 동시에 최대 부하로 실행하지 마세요.

모델과 리소스 한도부터 확인하세요

  • MODEL_DIR 은 준비된 MLX 호환 모델 디렉터리를 가리켜야 합니다. 모델 출처, 사용 라이선스, 양자화 형식, 의존성 버전을 확인하세요.
  • 64GB는 시스템 전체가 공유하는 통합 메모리입니다. 시스템, 모델 가중치, 캐시, 기타 프로세스가 모두 메모리를 사용합니다. 모델과 컨텍스트 설정에 따라 로드 가능 여부가 달라집니다.
  • 프롬프트와 생성 길이를 고정하고 콜드 스타트와 후속 요청을 기록하세요. 모델 다운로드 시간은 추론 처리량에 포함하지 마세요.

검수할 항목

모델 버전, 양자화 구성, MLX 환경, 실행 로그를 보관하세요. /usr/bin/time -l 로 프로세스 사용량을 확인하고 시스템 메모리 압력과 함께 살펴 페이지 아웃이 발생하는지 판단하세요.

추천 이유: Host M4 Pro의 64GB 통합 메모리는 더 넉넉한 메모리 공간이 필요한 실험에 적합합니다. 2TB SSD는 모델 파일과 실험 결과물을 저장하는 공간이며, 모델에 사용할 수 있는 메모리를 늘려 주지는 않습니다.

MLX · 로컬 추론
set -euo pipefail
: "${MODEL_DIR:?Set MODEL_DIR}"

python3 -m venv .venv
. .venv/bin/activate
python -m pip install mlx-lm
mkdir -p build

python -m pip freeze > build/mlx-environment.txt
/usr/bin/time -l \
  python -m mlx_lm.generate \
    --model "$MODEL_DIR" \
    --prompt "Explain reproducible builds." \
    --max-tokens 128 \
    > build/mlx-output.txt \
    2> build/mlx-metrics.txt

cat build/mlx-output.txt
cat build/mlx-metrics.txt
사용 플랜: Host M4 Pro · M4 Pro / 64GB / 2TB 추천 노드: 미국 서부
Host M4 Pro 대여하기

명령을 복사한 뒤 본인의 프로젝트 디렉터리에서 변수와 서명 구성을 확인하고 실행하세요.

추천 구성은 성능을 보장하지 않습니다

실제 작업으로 구성을 검증하세요

위 노드는 팀 협업 시간대를 고려해 추천한 것으로, 네트워크 지연 시간을 측정한 결과는 아닙니다. 코드 저장소, 결과물 저장소, 작업자의 위치도 사용 경험에 영향을 줍니다.

01

최대 리소스 사용량 기록

커밋과 의존성 버전을 고정하고 전체 작업을 한 번 실행하세요. 메모리 압력, 캐시 크기, 결과물 크기를 각각 기록해야 합니다. 단 한 번의 컴파일 시간만 보고 플랜을 고르지 마세요.

02

대기열과 실행을 분리하세요

먼저 단일 실행기로 시작하세요. 작업 자체가 안정적으로 실행되는지 확인한 뒤 동시 실행 수를 늘리세요. runner 대기 시간, 의존성 다운로드 시간, 컴파일 시간은 각각 기록해야 합니다.

03

팀 협업 환경과 가까운 노드 선택

싱가포르, 일본(도쿄), 한국(서울), 홍콩, 미국 서부 등 총 5개 노드를 이용할 수 있습니다. 프로젝트 동기화와 원격 연결을 먼저 검증한 뒤 팀의 실행 위치를 고정하세요.

검수 기준을 명확히 하세요

내일 아침 어떤 결과를 원하시나요?

아래 내용은 세 가지 역할별 활용 목표를 예시한 것으로, 고객 후기나 실측 기록이 아닙니다. 한 번 더 빠르게 빌드하는 것만 추구하기보다 목표를 파이프라인 검수 기준에 포함하세요.

“아침에 출근하면 해당 커밋의 아카이브와 테스트 결과, 실패 로그를 확인하고 싶습니다. 사무실 빌드 머신부터 점검하는 일은 이제 그만하고 싶어요.”
iOS 리드 · 야간 빌드 목표
“Flutter 파이프라인에서 iOS 단계만 옮기고 싶습니다. 양쪽 플랫폼에서 같은 커밋을 사용하고, 실패한 작업만 따로 재실행할 수 있으면 전체 파이프라인을 처음부터 다시 만들 필요가 없습니다.”
모바일 아키텍트 · 파이프라인 분리 목표
“모델 버전과 메모리 사용량, 생성 결과를 함께 보관하고 싶습니다. 실험을 재현할 수 있어야 다음 머신을 선택할 때 근거가 생깁니다.”
머신러닝 엔지니어 · 추론 실험 목표

실행 단계를 정한 다음 머신을 선택하세요.

단일 작업으로 시작한다면 Host M4 Lite, 여러 타깃의 일상 빌드와 회귀 테스트에는 Host M4 Plus, 대규모 프로젝트와 메모리 집약적인 실험에는 Host M4 Pro를 고려하세요. 플랜 페이지에서 3가지 구성, 4가지 대여 기간, 추가 옵션을 확인한 뒤 주문할 수 있습니다.

모든 요금은 USD로 결제됩니다. USDT-TRC20 및 Visa / Mastercard / Amex(Stripe)만 지원합니다. 실제 이용 가능한 결제 게이트웨이는 백엔드에서 반환하는 정보를 기준으로 합니다.