Bitbucket Pipelines macOS Runner: 2026년 기업 출시 기준

러너가 연결된 뒤 첫 번째 작업이 전역 도구를 설치했다고 가정해 보겠습니다. 다음 작업은 같은 호스트의 변경된 경로, 남은 프로세스, 캐시, 키체인 상태를 물려받을 수 있습니다. 앞선 작업이 성공했어도 뒤의 빌드가 다른 이유로 실패할 수 있습니다.

맥 러너는 호스트에서 명령을 실행하므로, 개발자가 생각하는 “새 작업”과 실제 운영 환경의 “깨끗한 작업”이 다를 수 있습니다. 작업 스크립트가 저장소 디렉터리 밖에 쓸 수 있는지, 전역 패키지를 설치할 수 있는지, 백그라운드 서비스를 시작할 수 있는지를 먼저 확인해야 합니다.

주의: 삭제 스크립트 하나를 격리 장치로 간주하면 안 됩니다. 신뢰할 수 없는 저장소나 외부 기여 코드는 전용 저권한 노드로 보내고, 배포 서명 작업은 별도 노드 풀에 고정해야 합니다.

승인 증거는 다음 네 가지로 남깁니다.

• 실행 전과 실행 후의 파일·프로세스·키체인 차이
• 파이프라인 로그와 러너 로그
• 잘못된 태그를 넣었을 때의 라우팅 결과
• 실패 시 노드를 중지하거나 격리한 기록

작업 공간 정리는 저장소 파일 삭제보다 넓게 정의해야 합니다. 최소한 다음 항목을 별도로 검사합니다.

• 소스 코드와 생성된 빌드 산출물
• 파생 데이터와 테스트 결과
• 의존성 및 빌드 캐시
• 임시 파일과 로그
• 전역 설치 패키지와 수정된 환경 설정
• 남아 있는 셸·빌드·시뮬레이터 프로세스
• 키체인 항목과 임시 인증서
• 작업 종료 뒤에도 열려 있는 네트워크 서비스

Bitbucket Cloud가 자동으로 처리하는 범위와 팀이 직접 관리해야 하는 범위도 구분해야 합니다. 자동 정리가 있다고 가정하지 말고, 실제 실행 뒤 변경 전 목록 → 작업 실행 → 변경 후 목록 순서로 증거를 수집합니다.

작업이 호스트의 임의 경로에 쓰는지 확인하려면 승인용 시험 저장소에 다음과 같은 동작을 넣을 수 있습니다.

runs-on:
  - self.hosted
  - macos
  - trusted-build

위 설정 자체가 격리를 제공하는 것은 아닙니다. 태그는 작업을 보낼 대상을 고르는 표지일 뿐입니다. 작업이 전역 경로를 수정하거나 상주 프로세스를 남긴다면, 정리 성공 여부와 관계없이 공유 풀에서 제외하는 편이 안전합니다.

Repository Runner와 Workspace Runner는 호출 범위가 다릅니다. 저장소 단위 러너는 승인된 저장소에 범위를 좁히기 쉽습니다. 작업 영역 단위 러너는 여러 저장소에서 호출될 수 있으므로, 권한이 넓은 작업 영역 러너를 모든 빌드에 사용하면 오염 반경도 커집니다. 등록 범위는 Bitbucket 러너 등록 공식 문서에서 현재 화면과 요구 조건을 함께 확인해야 합니다.

태그 설계는 기능 이름보다 신뢰 경계를 반영해야 합니다.

• untrusted-test: 외부 기여와 검증 전용
• trusted-build: 내부 코드의 일반 빌드
• release-signing: 서명과 배포 전용
• arm64: 애플 실리콘 노드가 필요한 작업
• xcode-pinned: 특정 엑스코드 기준을 유지하는 노드

실제 파이프라인 설정에서는 작업 성격과 하드웨어 요구를 모두 표시합니다.

runs-on:
  - self.hosted
  - macos
  - arm64
  - release-signing

공식 YAML 라우팅 문서가 설명하는 태그 조건을 기준으로 다음 세 가지를 시험합니다.

1. 존재하지 않는 태그를 넣었을 때 작업이 실행되지 않는지 확인합니다.
2. 대상 러너가 바쁠 때 작업이 대기 상태로 남는지 확인합니다.
3. 일반 빌드 태그로 서명 전용 노드에 들어가지 않는지 확인합니다.

작업 영역 러너를 사용한다면 저장소별 호출 권한, 비밀 변수 접근 범위, 캐시와 산출물의 재사용 여부를 별도 기록해야 합니다. 서로 다른 저장소가 같은 노드를 호출할 수 있는 구조라면, 신뢰 수준이 낮은 저장소와 배포 저장소를 한 풀에 두지 않는 것이 기본값입니다.

아이오에스 CI/CD의 실패 원인은 코드보다 노드 변경에서 시작되는 경우도 많습니다. 운영 기준에는 다음 환경 항목을 고정해 기록해야 합니다.

• 맥 운영체제와 아키텍처
• 엑스코드와 SDK
• 명령 도구와 패키지 관리자
• 실행 계정과 권한
• 의존성 해석 방식
• 캐시 생성 및 삭제 정책
• 시뮬레이터와 장치 테스트 의존성

특정 엑스코드 버전이나 노드 성능을 문서에 고정해서 쓰기보다, 배포 당일 설치된 값을 증거로 남겨야 합니다. 엑스코드 명령 도구의 실제 사용 범위는 애플의 엑스코드 명령 도구 참고 문서와 현장 노드의 명령 결과를 함께 확인합니다.

반복 빌드는 같은 커밋으로 두 번 이상 실행하되, 숫자 자체보다 차이의 원인을 확인합니다.

• 의존성이 같은 방식으로 해석되는가
• 캐시가 없어도 빌드가 완료되는가
• 캐시가 있을 때 결과가 달라지지 않는가
• 정리 뒤 다시 실행해도 동일한 산출물 조건을 만족하는가
• 로그에 노드 경로와 도구 버전이 남는가

리눅스용 파이프라인 설정을 맥 러너에 그대로 복사하면 안 됩니다. 경로, 셸, 키체인, 서명 도구, 시뮬레이터 접근 방식이 다릅니다. 플랫폼에서 지원하지 않는 기능은 별도 스크립트나 승인된 외부 절차로 대체하고, 그 대체 절차를 배포 승인 범위에 포함해야 합니다.

아이오에스 배포 노드는 일반 빌드 노드보다 높은 권한을 가집니다. 그러므로 러너 등록 정보, 소스 코드 접근 자격, 애플 서명 자료, 배포 권한을 하나의 변수 묶음으로 관리하지 않아야 합니다.

Bitbucket의 변수와 비밀 정보 관리 문서를 기준으로 저장 위치와 노출 범위를 정합니다. 저장소에 인증서, 개인 키, 프로비저닝 프로필을 직접 커밋하거나 공용 스크립트에 문자열로 넣는 방식은 승인 대상에서 제외해야 합니다.

검수 항목은 다음과 같습니다.

• 등록 자격과 소스 접근 자격을 서로 다른 수명 주기로 관리하는가
• 일반 빌드 태그가 서명용 키체인에 접근할 수 없는가
• 다른 저장소의 변수와 캐시를 읽을 수 없는가
• 작업 종료 뒤 임시 키체인과 인증서가 삭제되는가
• 자격 증명 사용·교체·철회 기록을 남기는가
• 이상 징후가 있을 때 즉시 배포 권한을 취소할 수 있는가

코드 서명 인증서의 구조와 보호 범위는 애플의 서명 인증서 기술 문서를 참고합니다. 배포 방식별 서명 산출물은 애플의 배포용 서명 안내와 현재 아이오에스 프로젝트의 요구 조건을 함께 검토해야 합니다.

운영 경험: 서명 작업이 성공했다는 로그만으로는 보안 검수가 끝나지 않습니다. 성공 직후 키체인, 환경 변수, 임시 파일을 확인하고 삭제 실패 시 해당 노드를 자동으로 신뢰 풀에서 제외해야 합니다.

무인 운영을 승인하려면 정상 실행보다 실패 상태를 먼저 재현해야 합니다.

복구 시험 순서

1. 러너 프로세스를 종료합니다.
2. 작업 실행 중 네트워크 연결을 끊습니다.
3. 작업이 끝나기 전에 맥을 재시동합니다.
4. 실행 중인 작업을 취소합니다.
5. 러너가 다시 연결될 때까지 상태와 로그를 확인합니다.
6. 재연결 뒤 새 작업을 받아도 이전 작업의 파일과 프로세스가 남지 않는지 검사합니다.

러너가 오프라인이면 작업이 어떻게 대기하거나 실패하는지 확인해야 합니다. 공식 동시 실행과 대기열 문서를 기준으로 현재 대기 상태와 실행 제한을 확인하고, 실제 로그에서 같은 동작이 나타나는지 비교합니다.

복구 시간, 처리량, 동시 작업 수는 일반적인 하드웨어 설명으로 대체할 수 없습니다. 해당 값은 배포할 구성과 실제 파이프라인으로 측정해야 합니다. 이 글에서는 검증되지 않은 복구 시간이나 성능 수치를 제시하지 않습니다.

맥 빌드 용량은 개발자 수만으로 산정하면 안 됩니다. 다음 값을 실제 작업 기록에서 수집해야 합니다.

• 일반 빌드의 소요 시간
• 아카이브와 서명 작업의 소요 시간
• 피크 시간대의 대기 작업 수
• 러너가 유지보수나 오류로 빠지는 시간
• 재시도와 캐시 미스 비율
• 장애 시 남아 있는 대체 노드 수

계산의 핵심은 광고된 칩 성능이 아니라 유효 생산량입니다. “노드 한 대가 몇 명을 담당하는가”보다 “피크 대기열을 승인된 시간 안에 처리하는가”를 봐야 합니다. 서명 전용 노드는 일반 테스트 노드와 같은 용량으로 계산하지 않습니다.

구매 또는 임대 결정을 내릴 때는 다음 값을 분리합니다.

• 장기간 일정한 부하와 물리 장치 연결이 필요하면 고정 장비를 검토합니다.
• 프로젝트별 부하가 크게 변하면 원격 맥 용량을 먼저 시험합니다.
• 서명 키를 외부 환경에 둘 수 없다면 전용 노드와 자체 키 관리 조건을 우선 검토합니다.
• 피크 기간에만 추가 용량이 필요하면 장기 구매보다 기간형 확장이 합리적일 수 있습니다.

원격 맥 용량을 비교할 때는 CALMVPS의 한국어 요금 안내에서 현재 제공 조건을 확인하고, 실제 파이프라인 대기열과 함께 비용을 계산해야 합니다. 고정 장비의 구매가는 전기, 장애 대응, 교체, 보안 패치, 유휴 시간까지 포함해 비교해야 합니다.

아래 항목은 설명용 목록이 아니라 배포 결론을 정하는 도구입니다. 각 항목에 증거 링크나 로그를 붙인 뒤 판단합니다.

• [ ] 작업 전후의 파일, 프로세스, 캐시, 키체인 차이를 기록했습니다.
  확인되면 다음 단계로 진행합니다. 잔여 상태가 있으면 해당 노드를 공유 풀에서 제외하고 정리 절차를 다시 검증합니다.

• [ ] 신뢰할 수 없는 저장소와 외부 기여 코드를 별도 러너로 보냈습니다.
  만족하면 일반 빌드 노드를 사용할 수 있습니다. 만족하지 못하면 Workspace Runner를 배포 작업에 사용하지 않습니다.

• [ ] 잘못된 태그가 대상 없는 대기 상태로 남고, 권한이 높은 러너로 우회되지 않습니다.
  통과하면 태그 라우팅을 승인합니다. 실패하면 저장소 범위와 태그를 다시 설계합니다.

• [ ] 같은 커밋을 정리 전후와 캐시 유무 조건에서 반복 실행했습니다.
  결과와 도구 환경이 일치하면 빌드 기준을 고정합니다. 차이가 발생하면 엑스코드, SDK, 의존성, 캐시 정책을 먼저 고칩니다.

• [ ] 일반 빌드가 서명 키체인, 다른 저장소 변수, 다른 노드의 산출물에 접근하지 못합니다.
  통과하면 제한된 배포 시험으로 이동합니다. 실패하면 서명 전용 노드를 분리하고 자격 증명을 교체합니다.

• [ ] 프로세스 종료, 네트워크 중단, 맥 재시동, 작업 취소 뒤 러너가 무인 복구됩니다.
  통과하면 제한 생산을 검토합니다. 실패하면 생산 배포를 막고 복구 자동화 또는 수동 전환 절차를 보완합니다.

• [ ] 피크 대기열과 장애 시 대체 용량을 실제 작업 기록으로 확인했습니다.
  통과하면 프로젝트별 노드 증설을 승인합니다. 부족하면 추가 노드를 확보하거나 배포 작업 시간을 분산합니다.

최종 결론은 네 가지 중 하나로 남깁니다.

1. 시험 운영: 비생산 저장소에서만 실행합니다.
2. 제한 생산: 승인된 저장소와 태그만 허용합니다.
3. 정식 배포: 보안·복구·용량 증거가 모두 충족되었습니다.
4. 수정 후 재검토: 하나라도 실패해 해당 노드를 격리했습니다.

각 노드와 노드 풀마다 다음 내용을 기록합니다.

• 러너 범위와 호출 가능한 저장소
• 허용된 태그와 금지된 태그 조합
• 맥 운영체제, 엑스코드, SDK, 실행 계정
• 작업 전후 파일·프로세스·키체인 검사 결과
• 실패한 라우팅과 대기열 시험 결과
• 네트워크 중단과 맥 재시동 뒤의 복구 결과
• 서명 자료의 주입·사용·삭제·교체 기록
• 피크 작업을 사용한 용량 시험 결과
• 시험 운영, 제한 생산, 정식 배포, 수정 후 재검토 중 최종 결론

현재 방식이 개발자별 맥북이나 단일 사내 맥 미니에 의존한다면, 장비가 물리적으로 고정되어 원격 작업과 피크 확장이 어렵고, 장애 시 대체 노드가 부족하며, 서명 키체인과 작업 공간의 오염 범위를 추적하기도 어렵습니다. 이런 구조를 장기 표준으로 두기보다, CALMVPS의 원격 맥을 격리된 시험 노드나 프로젝트별 추가 용량으로 배치해 실제 복구와 빌드 결과를 먼저 검증하는 편이 낫습니다. 조건이 맞으면 CALMVPS의 맥 이용 신청 페이지에서 필요한 기간과 접근 방식을 확인할 수 있습니다.

Bitbucket Pipelines에서 맥 러너를 설정할 때는 러너 등록, 범위 선택, 태그 지정, 시험 작업 순서로 진행합니다. 등록 완료만으로 승인하지 말고 대상 없는 태그, 바쁜 러너, 권한이 다른 노드에 대한 라우팅을 모두 확인해야 합니다.

Bitbucket 맥 러너는 아이오에스 배포에 사용할 수 있지만, 엑스코드 명령 도구와 서명 인증서, 프로비저닝 프로필, 키체인 권한을 별도로 검증해야 합니다. 빌드 성공은 배포 권한의 안전성을 의미하지 않습니다.

Workspace Runner를 여러 저장소에서 호출한다면 저장소별 신뢰 수준을 먼저 나눠야 합니다. 외부 기여 코드는 저권한 노드로 보내고, 배포 서명 작업은 별도 러너 풀과 전용 태그를 사용해야 합니다.

작업 뒤에는 작업 디렉터리뿐 아니라 파생 데이터, 캐시, 임시 파일, 전역 설치 항목, 잔여 프로세스와 키체인을 확인합니다. 정리 실패가 발견되면 해당 노드는 즉시 격리하고, 실패 기록이 남은 상태로 다시 배포에 투입하지 않습니다.

자체 관리 맥 러너가 오프라인이면 프로세스 종료, 네트워크 단절, 재시동, 작업 취소를 각각 재현합니다. 재연결 뒤 새 작업을 받을 수 있는지와 이전 작업의 상태가 남지 않는지를 확인한 뒤에만 무인 운영을 승인합니다.

마지막으로, 바로 생산 배포를 옮기지 마십시오. 먼저 격리된 맥 노드에서 비생산 파이프라인 한 개를 실행하고, 작업 공간 정리·서명 자료 제거·재시작 복구를 감사 가능한 기록으로 남기십시오. 세 항목과 대기열 용량이 모두 확인된 뒤에만 고정 노드 또는 원격 맥 용량을 프로젝트별로 늘리는 순서가 안전합니다.