빌드는 끝났다. 빌린 Mac의 하루는 남았다

요약

• EC2 Mac은 전용 호스트를 과금 단위로 삼고 최소 배정 기간을 24시간으로 정한다. 짧은 빌드를 실행해도 구매한 시간까지 짧아지는 것은 아니다.
• 중지나 종료 뒤의 호스트 정리 시간에는 과금이 일시 정지된다. 그동안 같은 호스트에서 다음 인스턴스를 시작할 수도 없어, 비용 절감과 빠른 출시가 서로 다른 선택이 될 수 있다.

개발팀은 빌드 시간을 줄였다고 보고한다. 구매팀은 하루치 최소 주문을 본다. 두 보고서는 모두 맞을 수 있다. EC2 Mac에서 컴파일러가 끝낸 일과 회사가 구매한 것은 크기가 다르기 때문이다.

AWS의 EC2 FAQ는 초 단위 과금과 전용 호스트의 최소 24시간 배정을 함께 설명한다. AWS는 이 최소 기간을 Apple의 macOS 소프트웨어 사용권 계약에 맞추기 위한 조건이라고 밝힌다. 첫 배정의 최소 기간을 지난 뒤 호스트를 해제하면 추가 호스트 사용 약정을 끝낼 수 있다.

초 단위라는 말은 계산자의 정밀도다. 주문서의 최소 크기는 하루다. 성능 개선으로 빌드가 빨라져도 이 두 숫자의 관계까지 바뀌지는 않는다. 클라우드 구매에서 가장 작은 단위는 화면에 가장 크게 보이는 단위와 다를 수 있다.

버튼 뒤에 있는 한 대

EC2 Mac 사용 문서에 따르면 과금 단위는 Dedicated Host다. 그 위의 인스턴스에는 별도의 인스턴스 요금이 붙지 않는다. 호스트 하나에 Mac 인스턴스 하나를 배치하는 베어메탈 방식이며, Apple 플랫폼용 앱을 개발하고 빌드하고 테스트하고 서명하는 데 쓸 수 있다.

호스트가 계정 화면 안에 들어왔다고 물리적 제약까지 사라지는 것은 아니다. 같은 AWS 조직의 계정이나 조직 단위 사이에 호스트를 공유할 수 있지만, 공유 권한이 한 호스트에서 여러 Mac 인스턴스를 동시에 실행할 수 있는 능력을 만들어 주지는 않는다.

그래서 비용을 나눌 때는 실행 시간만 볼 수 없다. 새 호스트 배정을 불러온 작업과 이미 확보된 호스트의 빈 시간을 사용한 작업은 구매에 미친 영향이 다르다. 둘이 똑같이 짧았다는 이유로 같은 비용을 배정하면, 새 하루를 주문한 결정이 통계 속으로 사라진다.

전용 호스트 가격 안내는 EC2 Mac의 최소 호스트 배정 및 과금 기간을 24시간으로 적고 있다. 다른 전용 호스트의 일반적인 60초 최소 조건을 가져와 Mac 계산서에 붙일 수 없다. 인스턴스의 중지, 종료, 호스트 해제는 각각 다른 행동이다. 작업을 끝냈다는 사실만으로 마지막 행동까지 실행되지는 않는다.

요금이 쉬는 동안 일정도 기다린다

이 서비스의 흥미로운 부분은 최소 기간만이 아니다. 비용 최적화 담당자에게 반가운 무료 시간이, 출시 담당자에게는 기다림이 될 수 있다.

AWS의 중지·종료 안내는 Mac 인스턴스를 중지하거나 종료하면 호스트 정리가 시작된다고 설명한다. 내부 SSD를 지우고, 지속적으로 저장된 NVRAM 변수를 초기화하고, 펌웨어를 갱신하는 과정이다. 호스트는 pending 상태로 들어가며 측정과 과금이 일시 정지된다. 정리 시간에는 요금이 붙지 않는다.

동시에 그 호스트의 멈춘 인스턴스를 다시 시작하거나 새 인스턴스를 띄울 수 없다. 정리가 끝나 호스트가 available 상태로 돌아와야 한다. 청구서에서는 빠진 시간이 작업 일정에서는 그대로 남는 셈이다.

문서에 제시된 정리 시간은 x86 Mac에서 최대 50분, 펌웨어 갱신이 필요하면 최대 3시간이다. Apple silicon Mac은 최대 4.5시간이 걸릴 수 있다. 매 작업마다 그만큼 기다린다는 평균값이 아니다. 다만 다음 작업의 시작 시각을 무조건 중지 버튼 바로 뒤에 놓을 수 없다는 근거는 된다.

여기서 절약 금액을 멋대로 계산하면 이야기가 틀어진다. 최소 24시간 규칙과 정리 중 과금 정지는 모두 문서에 있지만, 특정 정리 시간을 최소 청구액에서 차감하는 계산 사례는 이번 자료에 없다. 그 관계는 실제 상태 기록과 청구서로 확인해야 한다. 무료라는 설명을 지우는 것도, 4.5시간을 하루에서 자동 공제하는 것도 구매 판단을 흐린다.

정리 작업 자체에는 목적이 있다. 프로젝트 이름을 바꿨다고 이전 사용의 저장 장치와 설정이 저절로 사라지지는 않는다. 구매자가 관리할 것은 이 경계를 없애는 방법이 아니라, 필요한 교체 시간이 일정에 들어가도록 하는 방식이다.

빠른 기계와 바로 쓸 수 있는 기계

AWS가 제공하는 이미지로 인스턴스를 시작해 연결 가능한 상태가 되기까지는 약 6~20분이 걸린다고 문서는 설명한다. EBS 크기, 시작 스크립트, 자체 이미지에 설치한 소프트웨어는 시간을 늘릴 수 있다. 빌드 로그가 재는 실행 시간에는 이러한 준비가 전부 드러나지 않는다.

이 때문에 두 팀이 모두 ‘짧은 빌드’를 한다고 해서 같은 서비스를 원한다고 볼 수 없다. 한 팀은 순서를 기다릴 수 있다. 다른 팀은 출시 결정을 내리자마자 준비된 환경이 필요하다. 앞의 팀에는 작업을 묶는 방식이 적합할 수 있고, 뒤의 팀에는 사용 준비를 유지하는 용량이 가치가 있을 수 있다.

호환 가능한 작업을 같은 배정 안에 모으면 추가 호스트 주문을 줄일 여지가 생긴다. 반대로 환경과 격리 요구가 다른 작업을 무리하게 합치면, 이용률을 높이는 대신 실행 조건을 망가뜨린다. 꽉 찬 호스트라는 숫자만으로 좋은 운영이라고 판단하기 어려운 이유다.

EC2 Mac은 On-Demand로 제공되며 Spot이나 Reserved Instances 대상이 아니다. Savings Plans로 지출을 낮출 수는 있다. 가격 할인으로 정리 중인 호스트가 즉시 준비되는 것은 아니다. 가격표와 준비 상태는 여전히 별개의 변수다.

실제 작업의 도착 간격, 호스트 점유, 가격, 대기 손실이 있어야 유지와 해제를 비교할 수 있다. 실행 시간을 줄인 성과는 소중하다. 다만 다음 구매 결정까지 하려면 누가 새 배정을 열었고, 누가 준비된 상태를 필요로 했는지를 함께 봐야 한다. 회사가 사는 것이 ‘몇 분의 계산’인지 ‘지금 시작할 권리’인지부터 분명해야 한다.