팀 작업을 위한 전용 빌드 환경

대기 중인 빌드 파이프라인을
전용 Mac 한 대로 옮기세요

Apple Silicon M4 Mac mini 전체를 고객 한 곳에서 단독으로 사용합니다. PR 검사, 야간 아카이브, 원격 Xcode 작업을 동일하게 관리되는 툴체인에서 실행하고, 다른 고객과 CPU를 나눠 쓰지 마세요.

macOS 빌드 노드 대여 이전 3단계 보기

M4 구성 2종 · 하루 $20부터 · 전용 물리 머신, 가상 머신 아님

팀 전용 빌드 환경
  1. PR커밋 검사
  2. Test빌드 및 단위 테스트
  3. Archive아카이브 및 배포

전용으로 제공되는 것은 머신 전체입니다. 팀 내부의 작업 동시 실행 수와 우선순위는 runner 설정에 따라 달라집니다.

먼저 작업을 나누고 리소스를 배분하세요

네 가지 작업 유형을 빌드 환경에 배치하세요

먼저 머신의 주된 용도를 정한 다음 메모리와 스토리지를 선택하세요. 개발 작업, 릴리스 아카이브, 모델 실험은 같은 유형의 노드를 사용할 수 있지만, 제한 없이 한 머신의 리소스를 함께 쓰는 방식은 적합하지 않습니다.

시나리오 1 · PR 검사

커밋마다 빌드와 단위 테스트 실행

단일 프로젝트 CI, 소규모 SwiftUI 앱, 사무실 빌드 머신을 먼저 이전하려는 팀에 적합합니다. PR이 생성될 때마다 코드를 체크아웃하고 의존성을 복원한 뒤 단위 테스트를 실행해 결과를 기존 CI 플랫폼으로 전달합니다.

Merge M4 S부터 시작하세요. Apple Silicon M4, 16GB RAM / 256GB SSD 구성입니다. 머신 전체를 한 고객이 사용하므로 빌드 작업이 다른 고객과 코어를 나눠 쓰지 않습니다. 다만 여러 빌드가 동시에 메모리를 과도하게 점유하지 않도록 팀 자체 작업의 동시 실행 수를 제한하세요.

첫 번째 파이프라인은 세 가지 작업만

  • 저장소 커밋, 의존성 잠금 파일, Xcode 버전을 고정하세요.
  • 먼저 하나의 scheme으로 빌드와 단위 테스트를 실행하세요.
  • 대기, 빌드, 테스트 시간을 각각 기록해 병목을 파악하세요.

구성 선택 기준: 타깃이 여러 개이거나 시뮬레이터 병렬 테스트로 메모리 사용량이 크게 늘어날 때 24GB 구성을 검토하세요. 팀원 수만으로 필요한 머신 수를 산정하지 마세요.

Merge M4 S 대여
시나리오 2 · 일일 릴리스

야간 아카이브는 릴리스 전용 노드에서

테스트 빌드를 매일 생성하거나, 예약 아카이브를 실행하거나, Fastlane으로 빌드를 자동화하는 팀에 적합합니다. 기존 lane을 유지하면서 아카이브, 내보내기, TestFlight 업로드를 하나의 릴리스 작업으로 연결하세요.

Merge M4 L을 권장합니다. Apple Silicon M4, 24GB RAM / 512GB SSD 구성입니다. 기본 구성보다 메모리와 로컬 스토리지가 넉넉해 여러 프로젝트의 의존성과 필요한 시뮬레이터 런타임을 보관하기 좋습니다. 실제 빌드 성능은 프로젝트와 캐시 상태에 따라 달라집니다.

릴리스 작업에 별도 실행 조건을 설정하세요

  • 별도의 runner 태그를 사용해 일반 PR 작업이 아카이브 시간을 차지하지 않도록 하세요.
  • CI 비밀 저장소를 통해 인증서, 프로비저닝 프로파일, 배포 자격 증명을 주입하세요.
  • 아카이브가 완료되면 로그와 산출물을 저장한 뒤 정해진 규칙에 따라 로컬 파일을 정리하세요.

구성 선택 기준: 노드는 365일 연중 정상 운영됩니다. 예약 작업의 실행 여부와 업로드 성공 여부를 확인할 수 있도록 CI 플랫폼에서 실패 알림과 재시도를 설정하세요.

Merge M4 L 대여
시나리오 3 · 원격 개발

로컬 Mac 없이도 Xcode 사용

VNC 화면 공유로 macOS 그래픽 인터페이스에 접속해 Xcode에서 프로젝트를 확인하고 빌드 오류를 해결하거나 시뮬레이터를 실행하세요. SSH로 명령줄 빌드, 파일 동기화, runner 관리를 수행할 수 있습니다.

Xcode, 시뮬레이터, 의존성 도구를 동시에 사용해야 한다면 Merge M4 L을 우선 검토하세요. 그래픽 인터페이스와 CI 작업이 동일한 물리 머신의 리소스를 사용하므로 대화형 디버깅과 자동 아카이브는 시간대를 나누거나 별도 노드에서 실행하는 것이 좋습니다.

먼저 연결을 확인한 뒤 전체 프로젝트를 옮기세요

  • 콘솔에서 인스턴스 연결 정보를 확인하고 SSH와 VNC 접속부터 테스트하세요.
  • 원격 화면 해상도를 낮춘 뒤 입력과 창 조작이 원활하게 반응하는지 확인하세요.
  • 작은 프로젝트로 Xcode와 시뮬레이터를 테스트한 다음 정식 프로젝트를 동기화하세요.

지원 범위: 클라우드 환경은 빌드, 코드 서명, 시뮬레이터 테스트에 적합하지만 가까이에 있는 iPhone에 직접 접속할 수는 없습니다. 실제 기기를 로컬로 연결해야 하는 작업은 별도로 유지하세요.

SSH 및 VNC 연결 안내 보기
시나리오 4 · AI 실험

MLX 실험에 리소스 예산을 설정하세요

Apple Silicon에서 MLX 로컬 추론을 실행해 양자화 모델과 소형 모델 미세 조정 작업을 검증하세요. 먼저 작은 모델로 실행 가능한 기준을 만든 뒤 컨텍스트 길이, 배치 크기, 학습 데이터 규모를 단계적으로 늘리세요.

Merge M4 L에 +2TB SSD 옵션을 추가해 모델 가중치, 데이터셋, 체크포인트를 저장하는 구성을 권장합니다. 24GB RAM은 실행 메모리 예산이고, 추가 SSD는 파일 저장 용량입니다. 서로 대체할 수 없습니다.

모델 파일 크기뿐 아니라 최대 사용량도 확인하세요

  • 모델 로드, 추론, 미세 조정 단계별 메모리 최대 사용량을 기록하세요.
  • 다운로드, 압축 해제, 체크포인트에 필요한 여유 디스크 공간을 확보하세요.
  • 같은 머신에서 실행되는 CI 작업을 일시 중지해 리소스 경쟁으로 실험 결과가 달라지지 않도록 하세요.

구성 선택 기준: 모델을 메모리에 올릴 수 있는지는 양자화 정밀도, 컨텍스트, 실행 방식에도 좌우됩니다. +2TB SSD 옵션은 메모리를 늘려 주지 않으며 모든 모델의 실행을 보장하지 않습니다.

Merge M4 L 및 추가 스토리지 구성

머신을 단독으로 사용한다고 해서 작업을 무제한으로 동시에 실행할 수 있는 것은 아닙니다.먼저 머신별 동시 실행 수를 제한하고 메모리 최대 사용량, 디스크 여유 공간, 작업 대기 시간을 살펴보세요. 릴리스 작업에 안정적인 실행 시간이 필요하다면 모든 작업을 한 큐에 몰아넣기보다 runner의 역할을 나누세요.

의존성 순서에 따라 이전을 진행하세요

환경을 재현한 뒤 파이프라인을 전환하세요

기존 빌드 머신을 처음부터 없애지 마세요. 데이터, 툴체인, CI 연동 순서로 이전하고 새 환경과 기존 환경에서 동일한 커밋을 각각 실행하세요. 산출물과 로그를 확인한 뒤 정식 작업을 전환하세요.

  1. 01 · 데이터

    프로젝트, 서명 자료, 캐시를 따로 옮기세요

    저장소에서 프로젝트와 서브모듈을 다시 체크아웃하고 의존성 잠금 파일을 유지하세요. 로컬 작업 디렉터리 전체를 복사해 재현 가능한 환경으로 간주하지 마세요.

    • 인증서와 프로비저닝 프로파일은 통제된 채널로 전송하고, 암호는 CI 비밀 저장소에 보관하세요.
    • Xcode 버전, 의존성 잠금 파일, 아키텍처별로 캐시 키를 구분하세요.
    • 재사용이 확인된 캐시만 이전하고, 기존 DerivedData는 필수 입력으로 취급하지 마세요.

    검수 기준:지정한 커밋을 체크아웃할 수 있고, 서명 파일을 확인할 수 있으며, 민감 정보가 저장소에 포함되지 않아야 합니다.

  2. 02 · 툴체인

    버전을 기억에 맡기지 말고 기록하세요

    Xcode, Homebrew, Ruby, CocoaPods 버전을 맞추세요. 먼저 프로젝트에 이미 버전 파일이 있는지 확인하고, 이전 과정에서 의존성까지 함께 업그레이드해 문제 원인이 뒤섞이지 않도록 하세요.

    xcodebuild -version
xcode-select -p
uname -m
ruby --version
bundle exec pod --version

    검수 기준:arm64 환경, 선택한 Xcode 경로, 의존성 버전을 확인한 뒤 하나의 scheme으로 로컬 명령줄 빌드를 완료하세요.

  3. 03 · CI 연동

    테스트 작업부터 연결한 뒤 정식 릴리스를 연동하세요

    기존 플랫폼에 self-hosted runner 또는 agent를 등록하고 노드에 알아보기 쉬운 태그를 지정하세요. GitHub Actions에서는 아래 작업 태그를 사용할 수 있으며, 다른 플랫폼은 해당 플랫폼의 스케줄링 설정을 따르세요.

    runs-on:
  - self-hosted
  - macOS
  - ARM64
  - macos-m4

    검수 기준:동일한 태그로 실제 등록하고, 테스트 브랜치가 새 노드에서 실행되며, 로그와 산출물을 가져올 수 있어야 합니다. 정식 전환 전에는 기존 runner로 되돌릴 수 있는 설정을 유지하세요.

등록 토큰과 서명 자료를 예제 명령이나 공개 로그에 입력하지 마세요. 노드를 변경한 뒤 CI 플랫폼에서 runner 온라인 상태, 작업 태그, 실행 조건을 확인하고 세 항목이 모두 올바른 경우에만 팀 사용을 허용하세요.

runner 연동 및 문제 해결 보기

이전 결과를 검증 가능하게 유지하세요

팀 회의에서 동일한 커밋을 비교하세요

동일한 입력끼리만 빌드 시간을 비교하세요. 캐시 적중과 캐시 미적중 결과를 구분해 한 번의 다운로드, 재시도, 테스트 범위 변경을 하드웨어 성능 차이로 오해하지 않도록 하세요.

팀 회의에서 빌드 로그와 이전 기록을 검토하는 노트북 개발 협업 장면
개발 협업 장면을 보여 주는 이미지입니다. 빌드 비교에는 팀 자체 CI 로그를 사용하세요. 이미지는 고객 사례나 성능 증거가 아닙니다.

입력 고정

커밋 해시, Xcode 버전, scheme, 테스트 기기, 의존성 잠금 파일을 기록하세요. 비교 전에 테스트 범위가 바뀌지 않았는지 확인하세요.

소요 시간 분리

대기, 의존성 다운로드, 빌드, 테스트, 아카이브, 산출물 전송 시간을 각각 확인하세요. 머신을 단독으로 사용하면 다른 고객과의 리소스 경쟁은 사라지지만 네트워크 전송은 없어지지 않습니다.

기존 환경 유지

기존 runner 태그와 파이프라인 설정을 저장하세요. 새 환경이 반복 실행 가능한지 확인한 뒤 기존 노드의 정식 작업을 중단하세요.

작업에 맞춰 구성 선택

PR 검사에는 16GB부터 시작하세요. 타깃이 여러 개거나 시뮬레이터와 릴리스 아카이브를 함께 사용한다면 24GB를 검토하세요. 요금제 페이지에서 구성 비교표, 4가지 결제 주기, 스토리지 추가 옵션을 확인한 뒤 팀 전용 빌드 환경을 마련하세요.

구성 비교표 보기 클라우드 Mac 대여