플랫폼 팀은 이미 macOS 빌드를 위해 GitHub Actions, GitLab Runner, 또는 Jenkins를 쓰고 있지만, 큐 통합·리포 간 비용 가시성·VPS처럼 SSH 친화적인 전용 장비 운영에는 여전히 어려움이 있습니다. 이 글은 iOS/macOS 실행을 전용 원격 Mac으로 옮기려는 팀을 대상으로, Buildkite 도입을 망치는 일곱 가지 숨은 가정, Elastic CI 관련 네 가지 관점 비교표, 설치·토큰·태그·훅·헬스·동시성을 담은 6단계 인수인계 런북, 그리고 GitHub Actions 런너, GitLab Runner, Jenkins SSH 에이전트 기사와의 교차 링크를 제공합니다.
Buildkite 컨트롤 플레인은 큐와 권한을 잘 드러내지만, macOS는 여전히 Xcode + 키체인 + 디스크 쓰기 증폭의 세계입니다. 아래 일곱 항목으로 «에이전트만 붙이면 된다»는 말을 서명 가능한 운영 계약으로 바꾸고, 재현 가능한 빌드 및 SwiftPM/Pods 디스크 거버넌스와 맞춥니다.
Elastic CI를 무한 동시성과 혼동: 탄력성은 장비가 일을 받을지의 문제이지, 한 호스트가 여러 xcodebuild RAM 스파이크나 NVMe 경합을 견디는지를 보장하지 않습니다. 병렬 상한을 명시하세요.
큐·태그 의미를 무시: Buildkite는 태그로 작업을 라우팅합니다. 모든 iOS 작업이 한 태그로 몰리면 무거운 설치와 가벼운 스모크가 서로 밟습니다. 러너 가이드의 프로파일링 접근을 반영하세요.
훅을 «아무 셸 조각»으로 취급: 환경 주입, 시크릿 마스킹, 정리는 에이전트 사용자 하의 명시적 훅 경로에 있어야 하며, 대화형 프로필에 두면 안 됩니다.
한 사용자 아래 여러 buildkite-agent 프로세스: 기본 DerivedData를 공유하면 불안정한 컴파일이 늘어납니다. 사용자를 나누거나 BUILDKITE_BUILD_PATH 버킷을 강제하세요.
«git clone만 되면 된다»만 검증: 서명·공증 경로를 건너뛰면 릴리스 주에 깜짝 이슈가 납니다. 공증 CI 체크리스트와 수용 기준을 합치세요.
제공사 SSH 정보를 채팅에 흩뿌림: 포트, 배스천, 허용 IP, 유지보수 창은 하나의 내부 런북에 모읍니다.
«디스크 워터마크 → 스케줄 중지» 정책 없음: 안전 여유 공간 아래에서 큐만 채우면 git/Xcode 상태가 반쯤 쓰인 채로 남습니다. 짧은 대기보다 비쌉니다. 엔터프라이즈 빌드 풀과 같은 철학입니다.
공통 원인은 원격 Mac을 «날것의 연산»이 아니라 Xcode 핑거프린트와 키체인 경계를 가진 노드로 보지 않는 것입니다. Buildkite는 누가 얼마나 일할지·왜 실패했는지를 드러내지만, 디스크 계약·동시성 상한·정리 SLO는 플랫폼 엔지니어링이 제공해야 합니다. Jenkins 대비 Groovy 비대는 줄지만, 에이전트의 솔직한 환경은 그대로 노출됩니다. VPS처럼 사고하는 팀이 받아들이는 트레이드오프입니다.
GitLab도 쓴다면 GitLab Runner 글의 resource_group 사고를 Buildkite에 옮겨, 뮤텍스를 큐나 클러스터로 표현하세요. 물리적 한계는 결국 «이 Mac이 동시에 몇 개의 xcodebuild를 감당하는가»로 수렴합니다.
네 번째 CI 방언을 또 도입할지 논쟁한다면, 먼저 세 가지 SLA를 쓰세요: 큐 P95, 설명 가능한 실패, 시크릿 로테이션 비용. 이벤트는 이미 GitHub/GitLab에 묶여 있는데 큐 통합과 팀 간 비용 가시성이 없다면, Buildkite가 또 하나의 래퍼 스크립트가 아니라 실제 병목을 겨냥하는 경우가 많습니다.
만능처럼 보이는 선택은 없습니다. 파이프라인 정의가 어디에 두이는지, 누가 큐와 권한을 소유하는지, macOS 워커를 장기적으로 전용으로 둘지가 갈립니다. 표로 리뷰를 고정하고 로고 논쟁을 피하세요.
| 차원 | Buildkite + 에이전트 | GitHub Actions 셀프호스트 | GitLab Runner(shell) | Jenkins SSH 에이전트 |
|---|---|---|---|---|
| 컨트롤 플레인 | Buildkite UI/API; 저장소의 pipeline.yml이 단계 선언 | 워크플로 YAML이 PR 이벤트에 강하게 결합 | GitLab 프로젝트/MR + .gitlab-ci.yml | 컨트롤러 플러그인과 Job DSL — 유연하나 드리프트 취약 |
| 탄력성 | Elastic 에이전트 / 큐 라우팅; 태그 중심 | 러너 등록 + 자체 관리 동시성 | 러너 동시성 + resource_group 패턴 | 라벨 + 스로틀 플러그인 — 성숙하나 장황 |
| 시크릿·감사 | Buildkite 시크릿 + 훅; 로테이션 런북은 자체 책임 | GitHub Secrets + 강한 OIDC 패턴 | 마스크/보호 플래그의 CI/CD 변수 | 자격 영역이 컨트롤러 폭발 반경에 묶임 |
| 적합 사례 | SSH 우선 전용 Mac으로 멀티 리포 큐 | GitHub 중심 PR 배송 | GitLab 중심 MR 파이프라인 | 온프렘 아티팩트, 승인, 혼합 Git 호스트 |
Buildkite 말로 Mac을 «VPS처럼» 빌린다는 것은 곧 라우팅 가능한 에이전트 프로파일을 사는 일입니다. 고정 SSH, 예측 가능한 디스크 티어, Xcode 핑거프린트를 태그로 박는 능력이 그 안에 포함됩니다.
GitHub에 올인했지만 적은 수의 macOS 풀을 사업 부서 간에 나눠 써야 한다면 흔한 절충은 PR 검사는 Actions, 무거운 아카이브·공증·긴 통합은 Buildkite 큐가 같은 원격 Mac을 향하게 하는 것입니다. 두 스택의 디스크 루트와 시크릿 도메인은 격리해야 하며, 서로 무작위로 섞이면 안 됩니다.
Apple 관리 분과 우리의 Xcode Cloud 대 전용 원격 Mac 매트릭스를 비교해 보세요. Apple 네이티브 통합이 여전히 중요할 때 참고하면 됩니다. 이 글은 macOS 실행면을 소유하기로 한 전제입니다.
전용 노드 대여에 전념했다면 모든 오케스트레이션을 임시 스크립트에 넣기보다 Buildkite를 큐·시각화 층으로 두고, 구매 대 임대 TCO로 용량 근거를 맞춥니다.
순서가 중요합니다. 정체와 디렉터리가 먼저, 설치와 토큰이 그다음, 동시성은 마지막입니다. «핑 된다»며 축배 들다 컴파일이 들쭉날쭉해지지 않도록 SSH 대 VNC 체크리스트와 같은 SSH 기준을 쓰세요.
전용 CI 사용자와 작업 루트 만들기: 예시 /Users/ci/buildkite, SSH는 키만, 개인 데스크톱 세션과 혼합하지 않기.
buildkite-agent 설치: macOS에서는 공식 인스톨러 또는 Homebrew 권장. 바이너리 버전이 문서와 맞고 launchd 아래 실행 가능한지 확인.
buildkite-agent.cfg 작성: token, tags(예: queue=ios,arch=m4), 빠른 NVMe의 build-path 설정.
훅과 환경 정의: 환경 훅에서 DERIVED_DATA_PATH(또는 빌드별 경로)를 export. 대화형 셸 rc에 의존하지 않기.
첫 헬스 체크 스텝: xcodebuild -version, sysctl hw.memsize, df -h 출력하고 로그를 에이전트 수용 증명으로 저장.
파이프라인에 동시성·타임아웃 인코딩: 무거운 설치는 전용 큐로; 거대한 xcresult 번들에는 합리적 timeout_in_minutes과 아티팩트 보존 설정.
steps:
- label: ":iphone: iOS compile smoke"
agents:
queue: "ios"
arch: "m4"
command:
- xcodebuild -version
- df -h
- xcodebuild -scheme "App" -configuration Debug -destination "platform=iOS Simulator,name=iPhone 16" build
timeout_in_minutes: 45
팁: 파이프라인이 match를 배포·사용한다면 Fastlane + CI를 읽고 App Store Connect API 키를 Buildkite 시크릿 로테이션 리듬에 맞추세요.
에이전트 업그레이드일에는 같은 커밋으로 캔리 배포 후 xcodebuild -version 출력과 빌드 시간 분포를 비교합니다. GitHub 캐시 계층이 없으면 Buildkite는 엄격 무효화 규칙의 지속 로컬 캐시에 더 의존합니다. 그렇지 않으면 «캐시 히트»가 곧바로 «캐시 오염»이 됩니다.
다중 리전 플릿이면 에이전트 이름·태그에 리전을 넣고 아티팩트 경로를 라벨링해 대역 간 대용량 전송을 컴파일 실패로 오독하지 않게 하세요. 다중 리전 프로비저닝과 짝을 이뤄 지연·이그레스가 재무 모델에 일찍 들어가게 합니다.
흔한 실수는 «모든 Buildkite 큐가 녹색»을 건강한 여유 용량으로 읽는 것입니다. pod install, SPM resolve, 컴파일 스파이크는 서로 다른 단계에 걸립니다. 뮤텍스 자원이면 별도 큐나 상호 배제 스텝을 쓰세요. SwiftPM/Pods 거버넌스 글과 같은 이야기입니다.
시뮬레이터 UI 테스트는 컴파일 전용 파이프라인과 다른 동시 모델이 필요합니다. XCTest와 시뮬레이터 샤딩 글을 읽고 전용 태그나 풀로 격리하세요.
아티팩트와 로그 보존 예산을 명시하세요. Buildkite가 로그를 묶어도 큰 xcresult 업로드는 상행 링크를 포화시킬 수 있습니다. 플랫폼 정책에 실패 시에만 보존과 크기 상한을 박습니다. 엔지니어 간 약속으로 두지 마세요.
주의: 디스크가 안전 워터마크 아래일 때 큐를 계속 채우지 마세요. 스케줄을 멈추고 먼저 정리합니다.
전용 Mac 한 대에 다른 CI 스택까지 공존하면 «시차 스케줄이 도와줄 것»이라 믿기보다 유닉스 사용자나 루트를 분리하세요. 정리 철학은 골든 이미지 대 장수 노드 글과 맞춥니다.
Elastic CI의 이득을 구독료만으로가 아니라 «큐에서 절약한 분수» 더하기 «릴리스 주 사고 회피»로 재무에 연결해야 예산이 따라옵니다.
아래 불릿을 내부 합의에 쓰고, 리포 크기와 병렬도에 맞게 임계값을 조정하세요.
buildkite-agent --version, xcodebuild -version, CocoaPods 시 Ruby/Bundler, 디스크 모델 기록; 변경 후 캔리 파이프라인 실행.사무실 전용 Mac은 절전·지터·툴체인 드리프트가 있습니다. 리눅스는 애플 공식 iOS 툴체인 호스트가 될 수 없습니다. Buildkite를 큐·시각화 층에 두고 macOS 실행을 전용이며 항상 켜져 SSH로 닿는 원격 노드에 두면 «파이프라인 진실 단일 근거»가 계약이 됩니다. 즉석으로 구매한 장비에는 숨은 전력·부품·온콜 비용이 있고, 취약한 가상화 Xcode 스택은 서명·시뮬레이터·격리에서 반복해서 깨집니다. SSH 엔드포인트·디스크 티어·재현 가능한 에이전트 프로파일이 명확한 한 NodeMini Mac Mini 클라우드 대여가 iOS CI/CD와 자동화에 통상 더 강한 플랫폼 전략입니다. 사양은 Mac Mini 대여 가격과 비교하고, 온보딩은 헬프 센터로 마무리하세요.
이 런북을 내부 툴체인 변경 등급에 묶으세요. Xcode 패치·마이너·메이저는 승인 범위·캔리 범위·캐시 무효화 정책이 달라집니다.
Buildkite는 오케스트레이션과 큐를 저장소 밖에서 다루고, Actions는 PR 이벤트에 YAML을 강하게 묶습니다. 둘 다 macOS 워커에서 Xcode 핑거프린트와 디스크 버킷이 필요합니다. 하드웨어 티어는 Mac Mini 대여 가격에서 비교하세요.
보통 장비당 하나의 에이전트 프로세스에 병렬도는 한도와 큐 태그로 표현합니다. 여러 프로세스는 키체인과 DerivedData 경합을 키웁니다. 온보딩 질문은 헬프 센터를 참고하세요.
SSH 우선 전용 Mac을 실행면으로 유지하면서 리포 간 가시성과 단일 큐가 필요할 때입니다. GitLab MR이나 Jenkins 승인에 완전히 기대고 있다면 이전 비용이 중요합니다. GitLab Runner 및 Jenkins + 원격 Mac 글을 이어서 읽으세요.