Azure Pipelines에서 Apple Silicon 에이전트를 도입하려는 기업을 위해 작업 유형별 호스팅 경계를 정리합니다. 테스트와 피크 부하는 호스팅 자원으로 보내고, 서명과 내부망 작업은 통제된 셀프 호스팅 맥 풀에 남기는 혼합 운영 방식을 검토합니다.
Azure Pipelines에서 Apple Silicon 에이전트를 도입하려는 기업을 위해 작업 유형별 호스팅 경계를 정리합니다. 테스트와 피크 부하는 호스팅 자원으로 보내고, 서명과 내부망 작업은 통제된 셀프 호스팅 맥 풀에 남기는 혼합 운영 방식을 검토합니다.
빌드 대기열은 짧은 테스트에서도 흔들리고, 배포용 서명 키를 일반 작업과 같은 맥에 둘 수 없습니다.
2026년에는 정식 배포를 아직 프리뷰인 Apple Silicon 호스팅 에이전트로 전부 옮기지 말고, 셀프 호스팅 맥을 고정 기반으로 두면서 호스팅 자원을 피크와 단기 검증에 추가하는 혼합 구성이 가장 안전합니다.
이 글은 다음 담당자를 위한 판단 기준입니다.
Apple은 현재 Xcode 27을 베타로 표시하고 있으며, Apple Silicon 맥에서만 설치하고 실행할 수 있다고 안내합니다. 따라서 기존 인텔 기반 파이프라인은 단순한 버전 변경이 아니라 에이전트 이미지와 캐시, 플러그인, 서명 흐름을 다시 검증해야 합니다. 다만 이 글의 목적은 Xcode 이전 절차가 아니라 작업별 자원 배치입니다. Apple의 Xcode 27 릴리스 노트에서 상태와 실행 조건을 확인해야 합니다.
| 작업 상황 | 권장 풀 | 주된 이유 | 배포 전 확인 증거 |
|---|---|---|---|
| 풀 리퀘스트와 비신뢰 브랜치 | 호스팅 에이전트 | 매번 새 환경을 받아 격리하기 쉬움 | 네트워크 접근, 로그 노출, 재현성 |
| 베타 호환성 검사 | 호스팅 에이전트 | 짧은 기간의 이미지와 도구 검증에 적합 | 이미지 태그, Xcode 버전, 대기 시간 |
| 일반 개발 빌드 | 혼합 풀 | 고정 캐시와 순간적인 병렬 처리를 함께 확보 | 성공률, 평균 대기, 캐시 적중 |
| 정식 서명과 배포 | 전용 셀프 호스팅 맥 | 키체인과 계정, 네트워크를 통제할 수 있음 | 서명 격리, 감사 로그, 복구 절차 |
| 내부 API와 사설 저장소 접근 | 전용 셀프 호스팅 맥 | 출구 허용 목록과 내부 경계를 직접 관리 | 실제 실행 지역, 방화벽, 데이터 흐름 |
| 출시 직전의 대량 빌드 | 셀프 호스팅 기반 + 호스팅 탄력 풀 | 고정 용량과 추가 병렬성을 분리 | 큐 증가 시점, 실패 재실행, 비용 |
여기서 호스팅 에이전트는 전통적인 Microsoft 호스팅 macOS 이미지와 같은 자원이 아닙니다. Microsoft 문서는 Azure Pipelines에서 사용할 수 있는 GitHub 호스팅 에이전트와 기존 Microsoft 호스팅 에이전트를 구분합니다. 또한 조직의 위치만 보고 실제 빌드 실행 지역을 추정해서는 안 됩니다. 호스팅 에이전트의 지역과 네트워크 설명을 배포 전에 확인해야 합니다.
풀 리퀘스트, 외부 기여 브랜치, 일회성 베타 검사는 작업 수명이 짧고 결과를 반복해서 보존할 필요가 적습니다. 이때 매번 제공되는 호스팅 환경은 오래 남은 로그인 세션이나 이전 작업의 임시 파일을 줄이는 방향으로 설계할 수 있습니다. 대신 새 환경이 항상 같은 이미지와 도구를 제공한다고 가정하면 안 됩니다.
특히 확인할 항목은 다음과 같습니다.
호스팅 자원을 쓰는 이유는 단순히 관리할 맥이 없어서가 아닙니다. 신뢰하지 않는 코드를 서명 노드와 분리하기 위해서입니다. Microsoft의 파이프라인 보안 문서도 비밀 정보와 에이전트 권한을 작업 범위에 맞게 제한하도록 안내합니다. Azure Pipelines 보안 권고를 기준으로 프로젝트와 풀의 권한을 나누어야 합니다.
Azure Pipelines의 Apple Silicon 호스팅 에이전트가 정식 배포에 쓸 수 있는지는 프리뷰 상태, 지원 이미지, 지역, 과금 방식과 함께 다시 확인해야 합니다. 프리뷰라는 이유만으로 성능이 부족하다고 단정할 수는 없지만, 정식 배포에 필요한 운영 책임과 지원 조건을 문서로 증명할 수 없다면 고정된 셀프 호스팅 맥을 기준으로 잡는 편이 합리적입니다.
정식 배포 작업에는 다음 자산이 연결됩니다.
이 자산을 일반 테스트 풀과 섞으면 실패 원인을 찾기 어렵고, 자격 증명 철회 범위도 커집니다. 셀프 호스팅 맥은 환경을 고정할 수 있다는 장점이 있지만, 그 대가로 운영 책임이 생깁니다. 에이전트 업데이트, 디스크 정리, 계정 잠금, 키체인 복구, 장애 시 원격 재시작을 담당할 주체가 필요합니다. macOS 셀프 호스팅 에이전트 안내도 에이전트 설치와 운영 범위를 검토하는 출발점으로 사용할 수 있습니다.
Azure DevOps의 셀프 호스팅 맥은 다음 작업에 특히 적합합니다.
단, 한 대의 맥에 모든 프로젝트를 몰아넣는 방식은 피해야 합니다. 프로젝트별 에이전트 풀, 파이프라인 승인, 서비스 계정 권한을 나누고 서명 전용 노드에는 풀 리퀘스트 작업을 배정하지 않아야 합니다. VNCMac의 원격 맥 환경과 지역별 접속 조건을 검토할 때도 단순 접속 가능 여부보다 전용 에이전트 운영과 권한 분리가 가능한지부터 확인해야 합니다.
기업 내부망을 사용하는 파이프라인에서는 Azure DevOps 조직이 어느 지역에 만들어졌는지가 충분한 증거가 아닙니다. 실제 macOS 에이전트가 어느 지역에서 실행되는지, 사설 저장소에 어떤 방식으로 연결되는지, 고정 출구 주소나 허용 목록을 적용할 수 있는지를 별도로 확인해야 합니다.
다음 조건 중 하나라도 문서와 시험 결과로 확인되지 않으면 내부망 작업을 호스팅 풀에서 제외합니다.
이 경우 전용 셀프 호스팅 맥을 별도 풀에 배치하고, 해당 풀을 허용된 프로젝트와 배포 파이프라인에만 연결합니다. 접근 통제 설계가 필요하다면 원격 맥의 서명 자격 증명 격리와 에이전트 풀 권한 설계를 함께 검토하는 편이 좋습니다. 내부망 조건을 충족하지 못하는 호스팅 자원을 억지로 연결하는 것보다, 제한된 전용 노드 하나를 운영하는 편이 감사 대응과 사고 범위 관리에 유리할 수 있습니다.
정식 배포용 셀프 호스팅 맥만으로 피크를 처리하면 평상시에는 유휴 용량이 남습니다. 반대로 모든 빌드를 호스팅으로 보내면 서명, 캐시, 지역, 지원 조건을 매번 확인해야 합니다. 그래서 권장하는 구조는 전용 셀프 호스팅 풀을 기본 용량으로 두고, 비서명 병렬 작업을 호스팅 풀로 보내는 이중 풀입니다.
YAML 템플릿에서 작업 태그나 조건을 사용해 다음처럼 분류할 수 있습니다.
pull-request: 호스팅 풀unit-test: 호스팅 우선, 실패 시 승인된 셀프 호스팅 풀archive: 서명 전용 셀프 호스팅 풀release: 승인된 배포 풀만 허용beta-matrix: 호스팅 풀에서 여러 환경 검증비용은 월 정액 하나로 판단하면 안 됩니다. 기업의 Azure Pipelines Mac Agent 전체 비용은 다음 항목을 같은 기간에 기록해야 합니다.
호스팅과 셀프 호스팅 중 어느 쪽이 항상 저렴하다고 말할 수 없습니다. 실제 큐 기록과 빌드 로그가 있어야 확장 시점을 정할 수 있습니다. 호스팅 에이전트의 과금 및 제공 조건은 Microsoft의 GitHub 호스팅 에이전트 문서에서 현재 값을 다시 확인해야 하며, 공개 문서에 없는 비용은 계산표에서 제외해야 합니다.
Xcode 27은 현재 베타이고 Apple Silicon만 요구하므로, 기존 인텔 파이프라인을 한 번에 교체하는 방식은 위험합니다. 먼저 동일한 커밋을 두 풀에서 빌드하고 결과를 비교해야 합니다. 시범 운영에서는 성능보다 호환성과 통제 가능성을 먼저 봅니다.
수집할 증거는 다음과 같습니다.
판단은 네 가지로 나눌 수 있습니다.
시범 운영을 실제 자원으로 진행하려면 기업용 원격 맥 접속 환경에서 필요한 Apple Silicon 호스트와 접속 방식을 확인한 뒤, 파이프라인 로그와 청구 자료를 따로 보관해야 합니다. 이는 비용 절감 약속이 아니라, 구매와 렌탈 중 어느 쪽이 조직의 고정 용량에 맞는지 판단하기 위한 검증 단계입니다.
2026년 8월 20일 기준으로 Microsoft는 Azure Pipelines용 Apple Silicon macOS 에이전트의 공개 프리뷰 정보를 제공하고 있습니다. 관련 자원은 GitHub 호스팅 에이전트 풀에 포함되며, 전통적인 Microsoft 호스팅 macOS 이미지나 과거에 중단된 macOS 15 ARM64 프리뷰와 같은 자원으로 보면 안 됩니다. 이 상태는 Microsoft의 에이전트 유형 설명으로 확인해야 합니다.
Xcode 27의 정식 버전 공개, Apple Silicon 에이전트의 정식 제공 전환, 이미지 태그 변경, 가격과 지원 지역 변경은 모두 재평가 지점입니다. 정식 배포를 프리뷰 자원에 전부 맡기지 말고, 시범 결과가 통제 조건을 충족할 때만 작업 범위를 넓혀야 합니다.
현재 구성을 이미 보유한 기업이라면 일반 테스트와 서명 작업이 같은 노드에 섞이고, 피크 때 큐가 길어지며, 내부망 예외 규칙이 늘어나는 문제가 생기기 쉽습니다. 반대로 맥을 전부 직접 구매하면 초기 자산과 교체 주기를 떠안고, 사용량이 낮은 기간에도 고정 용량을 유지해야 합니다. VNCMac의 원격 Apple Silicon 맥을 전용 셀프 호스팅 에이전트 시범 노드로 사용하면 구매 전에 실제 빌드, 복구, 큐 데이터를 얻을 수 있습니다. 다만 장기 고정 부하나 물리 포트가 필요한 작업은 직접 보유가 더 적합할 수 있으므로, 실제 기록을 기준으로 렌탈 규모를 정해야 합니다.
핵심은 호스팅과 셀프 호스팅 중 하나를 고르는 일이 아닙니다. 비신뢰 코드와 피크 검증은 호스팅으로 격리하고, 서명과 내부망, 지속 캐시는 통제된 셀프 호스팅 맥에 남기는 것입니다. 먼저 격리된 Apple Silicon 맥으로 시범 풀을 만들고 증거를 모은 뒤, 그 결과에 따라 고정 용량과 탄력 용량의 비율을 결정하는 순서가 안전합니다.