Azure Pipelines macOS-14 종료: 2026년 기업 마이그레이션 선택

Azure Pipelines macOS-14 종료: 2026년 기업 마이그레이션 선택

기존 파이프라인은 오늘도 성공하지만, 브라운아웃이 시작되면 macOS-14 고정 작업이 의도적으로 실패할 수 있습니다.

승자는 작업별 이중 운영입니다. 무상태 PR 빌드는 지원되는 호스팅 이미지로 옮기고, 고정 Xcode, 사설망 의존성, 생산 서명이 필요한 작업은 자체 관리 맥으로 분리해야 합니다. 실제 빌드와 서명 검증을 끝내기 전에는 모든 작업을 macOS-latest로 바꾸지 않는 편이 안전합니다.

이 글은 macOS-14를 계속 사용하는 Azure Pipelines 관리자에게 적합합니다. 기업 IT 담당자, 기술 책임자, Xcode 도구 체인 관리자, 서명과 배포를 맡은 보안 팀도 대상입니다.

macOS-14 종료가 만드는 첫 번째 실패 지점

공식 일정 기준으로 macOS-14 호스팅 이미지는 2026년 10월 브라운아웃을 거친 뒤 2026년 11월 2일 제거될 예정입니다. 일정과 이미지 상태는 공식 호스팅 에이전트 문서에서 다시 확인해야 합니다.

브라운아웃은 단순한 경고가 아닙니다. 특정 시간대에 기존 이미지 선택이 실패하면서 다음 문제가 드러날 수 있습니다.

  • YAML의 vmImage가 제거 대상 태그를 직접 지정합니다.
  • Xcode 버전은 바뀌지 않았지만 시뮬레이터 런타임이 달라집니다.
  • 설치 스크립트가 새 이미지에서 사라진 패키지나 경로를 참조합니다.
  • 아카이브는 성공해도 인증서, 키체인, 배포 단계에서 실패합니다.
  • 사설 저장소나 고정 출구 주소가 필요한 작업이 호스팅 환경에서 멈춥니다.

먼저 저장소별 작업 자산을 기록해야 합니다.

pool:
  vmImage: macos-14

variables:
  xcodeVersion: "고정 버전"
  simulatorRuntime: "사용 중인 런타임"
  signingMode: "생산 서명"

이 목록에는 이미지 태그, Xcode 버전, 시뮬레이터 런타임, 게시 작업, 담당자, 차단 요인을 함께 적습니다. 이미지 제거와 일반적인 빌드 오류를 같은 문제로 취급하면 원인 분석이 늦어집니다.

일반 PR 빌드는 호스팅 이미지로 이동

무상태 컴파일, 단위 테스트, 정적 검사는 지원되는 호스팅 이미지로 옮기기 쉽습니다. 다만 에이전트가 실행된다는 사실만 확인해서는 부족합니다. 이미지마다 사전 설치 도구, 기본 경로, CPU 아키텍처, 캐시 수명이 다를 수 있습니다.

후보는 공식 이미지 표에서 확인합니다. macOS-15와 macOS-26의 지원 여부, 포함된 Xcode, 시뮬레이터 구성은 공식 이미지 저장소의 최신 목록과 Azure Pipelines 문서를 대조해야 합니다. latest 태그는 편리하지만 도구 체인이 자동으로 변할 수 있습니다.

검증은 같은 커밋을 두 환경에서 동시에 실행하는 방식이 적합합니다.

  1. 현재 macOS-14 작업을 성공 기준으로 보존합니다.
  2. 후보 이미지에서 의존성 잠금 파일을 그대로 사용합니다.
  3. 컴파일과 단위 테스트 결과를 비교합니다.
  4. 시뮬레이터 테스트와 아카이브를 실행합니다.
  5. 로그, 산출물 해시, 실패 원인을 기록합니다.
  6. 차이가 있으면 이미지 변경과 코드 변경을 분리합니다.

호스팅 에이전트는 매 작업마다 새 환경에 가까운 상태로 시작합니다. 따라서 로컬에서만 존재하는 캐시나 설치물을 전제로 만든 작업은 실패할 수 있습니다. 캐시 복원 여부도 성공률이 아니라 실제 로그와 산출물로 확인해야 합니다.

고정 도구 체인은 자체 관리 맥으로 보존

오래된 SDK, 특정 시뮬레이터 런타임, 고정 Xcode 소규모 버전, 사내 플러그인을 사용하는 작업은 최신 이미지로 바로 옮기기 어렵습니다. macOS-14 종료가 곧바로 도구 체인 업그레이드를 뜻하지는 않습니다.

다음 조건이 하나라도 있으면 자체 관리 macOS Agent를 우선 검토할 수 있습니다.

  • 프로젝트가 특정 Xcode 소규모 버전에 고정되어 있습니다.
  • 필요한 시뮬레이터 런타임이 후보 이미지에 없습니다.
  • 내부 Git 또는 산출물 저장소가 사설망에만 있습니다.
  • 빌드가 고정 출구 주소나 내부 인증서를 요구합니다.
  • 생산 서명에 사용하는 키체인과 인증서를 별도로 보호해야 합니다.
  • 재현 가능한 빌드 환경을 장기간 유지해야 합니다.

자체 관리 에이전트는 실제 맥 호스트에 설치되지만, 에이전트 풀에 넣었다고 보안 경계가 자동으로 생기지는 않습니다. 공식 macOS 에이전트 운영 문서는 계정과 호스트 권한을 별도로 검토하도록 안내합니다.

생산 서명 노드는 일반 빌드 노드와 분리해야 합니다. 여러 프로젝트가 같은 키체인과 실행 계정을 공유하면 한 작업의 권한이 다른 작업으로 확장될 수 있습니다.

주의: 서명 파일을 변수에 넣는 것만으로는 격리가 증명되지 않습니다. 에이전트 계정, 키체인 접근 권한, 풀 사용 권한, 산출물 저장 위치를 함께 확인해야 합니다.

Apple Silicon과 Xcode 27은 검증 대상으로 다룬다

Apple Silicon이 필요하다고 해서 모든 작업을 즉시 Arm 기반 노드로 바꿔야 하는 것은 아닙니다. Microsoft-hosted 이미지, 사용량 기반 호스팅 Agent, 자체 관리 Apple Silicon Mac은 환경 제어 범위와 되돌림 방식이 서로 다릅니다.

Xcode 27 Arm64 이미지의 설치 소프트웨어와 상태는 공식 Xcode 27 Arm64 이미지 설명에서 확인해야 합니다. 해당 문서에 표시된 상태가 미리 보기라면 실제 프로젝트의 운영 기본값으로 간주하지 않아야 합니다.

검증 기준은 다음과 같습니다.

  • 네이티브 Arm 의존성이 실제 빌드에 존재하는가
  • 시뮬레이터 테스트가 같은 결과를 내는가
  • 바이너리와 아카이브 서명이 유지되는가
  • 플러그인과 패키지 관리자가 새 아키텍처를 지원하는가
  • 실패 시 macOS-14 또는 기존 자체 관리 노드로 되돌릴 수 있는가

새 이미지가 에이전트 풀에 등록되는 것과 생산 배포가 검증되는 것은 다른 사건입니다. Xcode 27을 사용해야 한다면 먼저 별도 검증 풀을 만들고, PR 한 건과 실제 배포 한 건을 각각 통과시켜야 합니다.

사설망과 생산 서명은 별도 노드로 분리

기업 환경에서 가장 큰 전환 변수는 컴파일 속도가 아니라 신뢰 경계입니다. 내부 저장소, 사내 패키지 서버, 고정 출구, 키체인, 생산 인증서가 포함되면 호스팅 이미지의 편리함보다 접근 통제가 중요해집니다.

권장 흐름은 다음과 같습니다.

소스 저장소
   ├─ 일반 PR 검사 → 호스팅 이미지
   ├─ 사설 의존성 빌드 → 자체 관리 맥 풀
   └─ 생산 아카이브·서명 → 제한된 서명 풀
                         └─ 배포 저장소

각 풀에는 별도의 실행 계정과 권한을 사용합니다. 파이프라인이 어느 풀을 선택할 수 있는지 제한하고, 운영 계정이 일반 PR 작업에서 호출되지 않도록 해야 합니다. 공식 파이프라인 보안 안내는 에이전트와 파이프라인 권한을 최소 범위로 설정하는 방식을 설명합니다.

점검 결과는 다음 항목으로 남길 수 있습니다.

  • 일반 PR이 서명 풀을 호출할 수 없는가
  • 서명 풀에서 사설 저장소 접근 기록을 확인할 수 있는가
  • 키체인 잠금과 인증서 사용 기록이 남는가
  • 작업 종료 뒤 임시 파일과 토큰이 삭제되는가
  • 에이전트 재시작 뒤 대기 작업이 정상 복구되는가
  • 장애 시 예비 노드로 작업을 되돌릴 수 있는가

이 과정은 에이전트의 실행 방식과 보안 설명과 함께 검토하는 것이 좋습니다.

FAQ: 작업별 이중 운영을 어떻게 검증할까

macOS-14 제거 뒤 기존 작업의 영향

macOS-14를 YAML에서 직접 지정한 작업은 브라운아웃과 공식 제거 시점에 실패할 수 있습니다. 먼저 이미지 태그를 찾고, 후보 이미지에서 같은 커밋을 실행해야 합니다. 실패가 발생하면 이미지 문제인지 Xcode, 런타임, 서명 문제인지 나누어 기록해야 합니다.

macOS-15와 macOS-26 선택 기준

더 높은 번호가 항상 더 좋은 선택은 아닙니다. 프로젝트의 Xcode와 시뮬레이터 요구 조건, 패키지 호환성, 되돌림 가능성을 함께 확인해야 합니다. 공식 목록에서 지원 상태를 확인한 뒤 실제 아카이브와 테스트 배포까지 통과한 이미지에만 운영 태그를 부여해야 합니다.

자체 관리 Mac Agent로 옮길 작업

사설망 접근, 오래된 SDK, 고정 Xcode, 생산 인증서가 필요한 작업이 우선 대상입니다. 일반 PR 검사까지 모두 옮기면 호스트 관리와 보안 점검 부담이 커질 수 있습니다. 따라서 일반 빌드 풀과 서명 풀을 분리하고, 풀별 호출 권한을 최소화해야 합니다.

Xcode와 서명 검증 방법

의존성 해결, 컴파일, 테스트, 아카이브, 서명, 배포를 하나의 실제 저장소에서 순서대로 실행합니다. 성공한 작업의 로그와 산출물 해시를 남겨야 합니다. 에이전트를 재시작한 뒤에도 키체인 접근과 작업 복구가 정상인지 확인해야 합니다.

호스팅 맥과 자체 관리 맥의 혼합 운영

호스팅 이미지는 일반 PR과 무상태 검증에 배정하고, 자체 관리 맥은 사설망과 고정 도구 체인, 생산 서명에 배정합니다. YAML의 풀 지정과 권한 정책을 함께 관리해야 합니다. 피크 시간에는 호스팅 풀을 늘리고, 고정 작업은 전용 노드에 남기는 방식이 안정적입니다.

2026년 전환을 닫는 선택 매트릭스

비용은 실제 작업량, 노드 점유 시간, 서명 요구, 장애 복구 방식에 따라 달라집니다. 가격을 임의로 비교하기보다 기업 기록과 PoC 결과를 넣어 총비용을 계산해야 합니다.

작업 조건 호스팅 이미지 자체 관리 맥 혼합 노드 풀
무상태 PR 빌드 우선 선택 관리 부담이 큼 일반 PR에 배정
고정 Xcode와 런타임 후보 검증 뒤 선택 적합 고정 작업에 배정
사설망 의존성 접근 조건 확인 필요 우선 선택 사설 작업만 분리
생산 서명 제한된 경우만 검토 전용 노드 권장 서명 풀을 별도 운영
Apple Silicon 검증 공식 상태 확인 환경 통제 가능 검증과 운영을 분리
macOS-14 되돌림 제거 뒤 사용 불가 기존 노드 보존 가능 예비 용량으로 복구
운영 부담 낮음 직접 관리 필요 역할별 부담 분산

팀은 먼저 실제 PR 하나와 생산 배포 하나를 골라 이중 운영 PoC를 실행해야 합니다. 두 작업 모두 통과하고, 실패 시 되돌림과 에이전트 복구까지 확인한 뒤 macOS-14 종료를 승인하는 순서가 적합합니다.

자체 관리 에이전트의 재시작과 복구 절차가 필요하다면 Azure Pipelines용 원격 맥 운영 환경에서 운영 방식을 먼저 비교할 수 있습니다. 전용 노드의 구매와 임대 조건을 검토하는 기업은 맥 미니 임대 가격 기준도 함께 확인할 수 있습니다.

기존 macOS-14 고정 구성은 당장 성공하더라도 브라운아웃과 제거라는 외부 변수에 노출됩니다. 반대로 자체 관리 맥은 고정 도구 체인과 서명에는 유리하지만 호스트 보안, 교체, 복구, 용량 계획을 직접 부담해야 합니다. 따라서 단기 검증이나 발행 피크에는 SFTPMAC의 주기형 원격 맥 노드를 비교할 수 있지만, 물리 장비 접근이 반드시 필요하거나 장기간 일정한 고부하가 지속되는 조직에는 직접 구매가 더 적합할 수 있습니다. 최종 선택은 가격 하나가 아니라 이미지 변경 위험, 서명 격리, 복구 시간, 실제 점유량을 함께 계산해 결정해야 합니다.