AWS CodeBuild macOS 예약 용량은 몇 대일까? 2026 기업 비용 모델

증상 → 가장 빠른 해결: 빌드는 자주 실행되지 않는데 예약 노드 비용은 계속 발생합니다. 개발자 수가 아니라 피크 도착률, 빌드 점유 시간, 허용 대기 시간, 장애 여유로 보장 용량을 다시 계산해야 합니다.

이 글은 안정적인 고사용량에는 최소 예약 Fleet를, 변동이 큰 팀에는 원격 Mac 또는 혼합 용량을 검증하라는 기준을 제시합니다.

누가 이 판단표를 사용해야 하나요

AWS CodeBuild macOS 예약 Fleet 예산을 신청하면서 노드 수와 비용 근거를 설명해야 하는 기업 IT 및 FinOps 담당자에게 적합합니다.

여러 iOS 프로젝트의 공유 용량과 생산 서명 격리를 함께 관리하는 연구 개발 효율 담당자, 고정 Fleet와 탄력적인 원격 Mac 사이에서 선택해야 하는 기술 총괄도 사용할 수 있습니다.

AWS 공식 문서는 macOS 빌드에 예약 용량 Fleet가 사용되며, Fleet 용량이 동시에 처리할 수 있는 빌드 수를 결정한다고 설명합니다. 또한 노드는 설정된 상태로 유지되는 동안 비용 대상이 될 수 있습니다. 이 기본 조건은 AWS CodeBuild 공식 요금 안내와 예약 용량 Fleet 속성 문서에서 먼저 확인해야 합니다.

먼저 확인할 입력값과 보장 용량

개발자 열 명이 있다고 노드 열 대가 필요한 것은 아닙니다. 한 개발자가 여러 빌드를 동시에 만들 수도 있고, 여러 프로젝트가 같은 시간대에 조용할 수도 있습니다. 용량은 다음 입력값으로 산정합니다.

기본 모델은 다음처럼 변수로 둡니다.

보장 노드 수 = 피크 동시 작업 수 + 재시도 여유 + 장애 여유

피크 동시 작업 수 = 시간대별 도착률 × 해당 작업의 평균 점유 시간

이 식은 평균값만 보는 모델이 아닙니다. 평균 이용률이 낮아도 특정 시간에 PR 검증, 야간 회귀, 출시 빌드가 겹치면 큐가 길어질 수 있습니다. 따라서 평균 점유율과 최고 동시 작업 수를 별도로 기록해야 합니다.

AWS CodeBuild 프로젝트 환경과 실행 설정은 프로젝트 환경 구성 문서에서 확인합니다. 실제 계산에는 이 문서의 예시 숫자를 복사하지 말고, 네 CI 기록에서 추출한 값을 넣어야 합니다.

비용 모델은 고정 용량과 피크 용량을 나누어야 합니다

AWS CodeBuild macOS의 예약 용량은 실제 빌드가 실행된 시간만 따로 사는 방식으로 단순화하기 어렵습니다. 예약 Fleet가 구성된 시간, 적용되는 최소 사용 조건, 선택한 환경의 요금 규칙을 함께 봐야 합니다. 따라서 다음처럼 비용을 분리하면 예산 설명이 쉬워집니다.

여기서 금액을 미리 정해 넣으면 안 됩니다. AWS 요금은 지역과 Fleet 설정에 따라 달라질 수 있으므로, 공식 요금표의 현재 조건과 네 청구서를 같은 시점에 대조해야 합니다.

주의: 작업 폴더를 삭제했다고 해서 Mac 노드가 깨끗해지는 것은 아닙니다. 전역 캐시, Keychain, 인증서, 환경 변수, 사전 설치 도구가 다음 작업에 남을 수 있으므로 공유 가능 여부는 파일 정리만으로 판단하면 안 됩니다.

첫 단계: 일상 빌드와 출시 피크를 분리합니다

일상 PR 검증은 짧고 자주 실행될 수 있습니다. 야간 회귀는 실행 시간이 길 수 있고, TestFlight 업로드와 정식 출시 작업은 서명과 업로드 단계에서 별도 권한을 요구합니다.

다음 기록을 시간대별로 나누어 추출합니다.

• PR 검증 요청과 실제 시작 시간
• 야간 회귀의 동시 실행 수와 점유 시간
• TestFlight 및 정식 출시 작업의 시작 시각
• 실패 후 재실행된 작업과 실패 원인
• 큐에 머문 시간과 노드가 비어 있던 시간

출시 피크가 반복되고 평일에도 높은 이용률이 유지된다면 예약 Fleet 증설을 검토할 수 있습니다. 반대로 특정 출시 창에서만 작업이 몰리면 그 피크를 위해 노드를 계속 보유하는 구조가 비효율적일 수 있습니다. 이 경우 사전에 용량을 늘리는 방법, 예약 노드를 유지하는 방법, 원격 Mac을 임시로 연결하는 방법을 비교합니다.

원격 Mac을 검토할 때는 단순히 빌드가 시작되는지만 보지 마십시오. Xcode 설치 상태, 인증서 전달, 서명 권한, 아티팩트 업로드, 작업 종료 후 정리까지 같은 흐름으로 확인해야 합니다. 원격 Mac 용량과 요금 조건을 확인하는 안내는 이 PoC의 사전 점검 자료로 사용할 수 있습니다.

두 번째 단계: 공유 Fleet와 전용 Fleet의 경계를 정합니다

여러 iOS 프로젝트가 하나의 Fleet를 공유하면 고정 용량의 이용률을 높일 수 있습니다. 그러나 공유로 절약되는 노드 비용만 계산하면 안 됩니다. 캐시 오염, 인증서 노출, 프로젝트 간 장애 전파, 정리와 감사 작업이 추가됩니다.

다음 조건이면 공유 검증 풀을 고려할 수 있습니다.

• 프로젝트가 같은 신뢰 등급에 속합니다.
• 생산 인증서와 배포 권한을 사용하지 않습니다.
• 의존성과 캐시를 작업 단위로 재현할 수 있습니다.
• 작업 종료 후 환경 검사를 자동으로 통과합니다.

다음 조건이면 전용 풀로 되돌립니다.

• 생산 서명 또는 배포 권한이 필요합니다.
• 내부 저장소나 비공개 서비스에 접근합니다.
• 프로젝트마다 다른 전역 도구와 Keychain 상태가 필요합니다.
• 실패한 작업이 다른 프로젝트의 결과나 캐시에 영향을 줄 수 있습니다.

공유 계정과 역할 권한은 CodeBuild IAM 접근 제어 문서를 기준으로 검토합니다. VPC와 내부 의존성이 있는 빌드는 관리형 프록시의 제한 사항도 확인해야 합니다.

세 번째 단계: 사설 의존성과 생산 서명을 별도 용량으로 계산합니다

일반 검증 풀과 신뢰 가능한 출시 풀을 같은 숫자로 계산하면 안 됩니다. 사설 저장소, 내부 API, 비밀 저장소, 서명 인증서, 배포 권한이 필요한 작업은 접근 경계 자체가 용량 조건이 됩니다.

각 풀에 대해 다음을 따로 기록합니다.

• 최소 동시 실행 수
• 허용 대기 시간
• 서명과 업로드 점유 시간
• 권한 취소와 키 교체에 걸린 시간
• 노드 장애 시 대체 경로
• 복구 훈련에서 실제로 확인된 처리 시간

생산 서명 풀의 노드가 비어 있는 시간이 길더라도, 일반 프로젝트를 보내 이용률을 높이는 선택은 위험할 수 있습니다. 비용 절감보다 권한 경계와 감사 가능성을 우선해야 하는 경우가 분명히 존재합니다.

네 번째 단계: 장애와 지역 조건을 비용에 넣습니다

성공한 빌드 시간만으로 용량을 정하면 시작 대기, 이미지 준비, 노드 불가, 네트워크 복구 시간을 놓칩니다. CodeBuild의 지역과 컴퓨팅 유형은 공식 Fleet 문서에서 확인하고, 사용 가능한 실행 환경은 런타임 문서와 대조해야 합니다.

단일 노드 Fleet는 유지 보수와 지속 배포를 동시에 만족시키기 어렵습니다. 이때 선택지는 세 가지입니다.

• 예약 Fleet에 장애 여유 노드를 둡니다.
• 별도 지역 또는 별도 실행 경로를 재해 복구용으로 검증합니다.
• 짧은 피크나 복구 기간에는 원격 Mac을 대체 용량으로 사용합니다.

복구 시간이나 가용성을 임의의 숫자로 약속하면 안 됩니다. 기업 장애 보고서, 공식 문서, 복구 훈련 또는 실제 원격 Mac 검증 기록이 있는 값만 예산 모델에 넣어야 합니다.

조건별 선택: 예약, 원격 Mac, 혼합 용량

다음 조건 목록으로 첫 결정을 내립니다.

• 피크 동시 작업 수가 반복되고, 예약 노드의 이용률도 높다면 최소 예약 Fleet를 유지합니다.
• 일상 작업은 안정적이지만 출시 창에서만 큐가 길다면 예약 용량과 원격 Mac을 함께 검증합니다.
• 작업 빈도가 낮고 비어 있는 시간이 길다면 예약 노드 증설을 멈추고 원격 Mac PoC를 먼저 진행합니다.
• 생산 서명과 사설 의존성이 있으면 일반 검증 풀과 서명 풀을 분리합니다.
• 대기 목표를 지키려면 추가 노드가 필요하지만 비용 근거가 부족하면 한 달치가 아니라 충분한 연속 CI 기록을 먼저 수집합니다.
• 복구 훈련에서 대체 경로가 검증되지 않았다면 원격 Mac을 비용 절감 수단이 아니라 재해 복구 후보로 따로 평가합니다.

MacDate의 원격 Mac 임대 PoC와 용량 검증 자료를 사용할 때도 AWS Fleet를 곧바로 대체한다고 가정하면 안 됩니다. 실제 Xcode 버전, 서명 흐름, 사설 네트워크, 아티팩트 전달 조건을 같은 작업으로 비교해야 합니다.

자주 묻는 질문

AWS CodeBuild macOS는 왜 실제 빌드 시간만큼만 결제할 수 없나요?

macOS 빌드는 예약 용량 Fleet를 기준으로 운영됩니다. 따라서 실행이 없는 시간에도 설정된 노드와 최소 사용 조건에 따라 비용이 발생할 수 있습니다. 실제 요금과 적용 조건은 지역 및 Fleet 설정을 포함해 AWS 공식 요금표에서 확인해야 합니다.

CodeBuild macOS 예약 용량은 어떻게 계산하나요?

개발자 수를 노드 수로 바꾸지 말고, 시간대별 도착률과 빌드 점유 시간을 곱해 동시 작업 수를 계산합니다. 여기에 재시도 여유, 장애 여유, 허용 대기 시간을 반영합니다. 평균 이용률만 보면 출시 피크의 긴 큐를 놓칠 수 있습니다.

여러 iOS 프로젝트가 하나의 CodeBuild Mac Fleet를 공유할 수 있나요?

공유할 수 있지만 모든 프로젝트에 적합하지는 않습니다. 일반 검증 작업은 공유 풀에 넣을 수 있지만, 생산 서명과 비공개 의존성이 있는 작업은 전용 풀로 분리하는 편이 안전합니다. Keychain과 전역 캐시까지 초기화되는지 별도로 검증해야 합니다.

출시 피크에는 예약 노드를 늘려야 하나요, 원격 Mac을 써야 하나요?

출시 피크가 반복되고 평소에도 높은 이용률이 유지되면 예약 노드가 적합할 수 있습니다. 특정 기간에만 작업이 몰리고 나머지 시간에 노드가 비어 있다면 원격 Mac을 붙이는 혼합 용량을 검증하는 편이 낫습니다. 서명과 업로드까지 포함한 PoC가 필요합니다.

유휴율이 높으면 언제 용량 방식을 바꿔야 하나요?

유휴율 하나만으로 결정하지 말고 큐 대기, 장애 여유, 격리 요구, 유지 비용을 함께 보아야 합니다. 대기 목표를 지키면서도 예약 용량이 반복적으로 비어 있다면 고정 Fleet를 줄이고 원격 Mac 또는 혼합 구성을 시험할 신호입니다.

분기마다 다시 계산해야 하는 조건

다음 변화가 생기면 기존 노드 수를 그대로 유지하지 말고 모델을 다시 실행합니다.

• 큐 대기 목표가 반복해서 무너집니다.
• 예약 Fleet의 빈 시간이 계속 늘어납니다.
• 새 프로젝트가 공유 풀에 들어옵니다.
• 생산 서명 권한이나 내부 네트워크 접근 범위가 바뀝니다.
• Xcode 또는 실행 환경을 업그레이드합니다.
• 장애 복구 경로를 새로 만들거나 기존 경로를 폐기합니다.
• AWS의 macOS 요금, 최소 사용 조건, 지원 지역, Fleet 기능이 바뀝니다.

가장 먼저 해야 할 일은 한 달치 CodeBuild 큐와 빌드 기록을 내보내는 것입니다. 그 값을 일상, 출시 피크, 공유, 서명 격리, 재해 복구 시나리오에 나누어 넣으십시오. 고정 용량이 대부분의 시간에 비어 있다면, MacDate의 원격 Mac을 실제 Xcode와 서명 흐름으로 검증하는 혼합 용량 PoC가 더 현실적인 다음 단계가 될 수 있습니다. 반대로 안정적인 고사용량과 엄격한 사설 의존성이 확인되면 예약 Fleet를 유지하되, 장애 여유와 전용 서명 풀을 비용 모델에 포함해야 합니다.