이번 주에는 개발자 수로 맥 CI 비용을 똑같이 나누지 말고, PR 검증·정식 배포·정기 회귀 테스트·임시 증설별로 실제 자원 비용을 구분하세요. GitHub Actions 플랫폼 요금과 맥 호스트 비용도 별도 장부로 관리해야 합니다.
여러 제품 팀의 맥 CI를 관리하는 FinOps 담당자는 감사 가능한 비용 귀속 기준을 세울 수 있습니다.
GitHub Actions와 자체 호스팅 러너를 맡은 플랫폼 팀은 작업 기록과 인프라 청구를 연결할 수 있습니다.
원격 맥 예산을 관리하는 IT 담당자는 일상 사용량과 배포 시점의 증설 비용, 유휴 용량의 책임을 구분할 수 있습니다.
플랫폼 청구와 맥 자원 비용은 별도 항목입니다
GitHub Actions에서 자체 호스팅 러너를 사용한다고 해서 러너가 실행되는 맥 호스트까지 무료가 되는 것은 아닙니다. GitHub의 Actions 청구 안내는 플랫폼 요금의 범위를 설명합니다. 실제 기업 장부에서는 플랫폼 사용료, 맥 자원 비용, 운영 인력 투입, 유휴 용량을 각각 분리해야 합니다.
비용 귀속표에는 다음 세 가지 연결고리가 필요합니다.
- 작업 귀속: 저장소, 워크플로, 요청 팀, 비용 센터
- 자원 사용: 러너 식별 정보, 작업 점유 기록, 노드 상태
- 청구 근거: GitHub 청구 자료, 맥 구매 또는 임대 청구서, 운영 비용 장부
GitHub의 청구 및 사용량 안내와 청구 보고서 문서를 확인하면 플랫폼 쪽 사용 자료를 별도 검토할 수 있습니다. 이 자료를 맥 호스트 비용과 합쳐 하나의 금액으로 만들면, 플랫폼 청구와 인프라 지출을 이중으로 계산하거나 어느 한쪽을 빠뜨리기 쉽습니다.
02작업과 비용을 이어 주는 기록이 없으면 특정 팀에 비용을 배정하지 마세요. 먼저 공용 미분류 항목으로 남기고, 저장소·러너·청구 자료의 연결을 보완한 뒤 정산하는 편이 감사 추적에 유리합니다.
PR 검증은 실제 작업 점유량으로 귀속합니다
PR 검증은 여러 팀이 공용 러너를 자주 사용하는 대표적인 상황입니다. 팀별 개발자 수가 아니라 실제로 어떤 저장소의 어떤 워크플로가 어느 러너를 사용했는지를 근거로 삼으세요. GitHub의 워크플로 작업 기록 API는 작업과 러너 정보를 확인하는 데 쓸 수 있습니다.
월별 비용 계산은 아래 변수로 표현할 수 있습니다.
팀별 PR 비용 = PR 작업별 맥 자원 비용의 합
PR 작업별 맥 자원 비용 = 확인된 점유량 × 합의된 자원 단가
여기서 점유량과 단가는 실제 러너 기록과 기업 청구 자료에서 가져와야 합니다. 확인되지 않은 단가나 시간을 임의로 채우면 안 됩니다. GitHub Actions의 사용량 지표 안내도 함께 확인해 수집 가능한 작업 정보를 점검하세요.
실무 기록에는 저장소, 워크플로, 요청 팀, 러너 라벨, 작업 식별 정보, 시작·완료 기록을 연결합니다. 작업이 실행되지 않은 노드 유휴 시간이나 노드 장애로 사용할 수 없었던 시간은 유효한 빌드 점유량에 섞지 않습니다. 다만 해당 용량의 비용 부담 주체는 별도 규칙으로 정해야 합니다.
03정식 배포는 전용 서명 용량과 공용 풀을 나눕니다
배포 작업이 전용의 신뢰할 수 있는 노드에서 실행된다면 해당 자원 비용을 PR 검증 작업에 자동으로 나누지 마세요. 배포를 위해 미리 확보한 용량은 공용 풀과 목적이 다릅니다. 해당 용량을 요청한 팀이나 서비스가 정한 전용 서비스 규칙에 따라 귀속해야 합니다.
정산 자료에는 프로젝트, 배포 작업, 러너 또는 노드, 요청자, 비용 센터를 남기세요. 이후 감사 과정에서 배포 기록에서 비용까지 거슬러 올라갈 수 있어야 합니다. 서명 정보와 배포 권한을 관리하는 경우에는 GitHub Actions 보안 사용 지침에 따라 접근 권한도 함께 검토하세요.
공유 배포 용량을 여러 팀이 이용한다면 사전에 배분 원칙을 합의해야 합니다. 실제 사용량을 기준으로 할지, 확보해 둔 전용 용량을 기준으로 할지 정하지 않은 상태에서 배포가 끝난 뒤 비용을 나누면 예상하지 못한 이견이 생깁니다.
04정기 회귀 테스트는 작업과 대기 용량을 구분합니다
야간이나 주기적으로 실행하는 회귀 테스트는 특정 팀의 업무일 수도 있고, 플랫폼이 관리하는 공통 품질 작업일 수도 있습니다. 실행 시각만으로 책임 팀을 판단하지 마세요. 작업이 속한 프로젝트와 워크플로를 먼저 확인하고, 정기 작업의 소유자를 명시해야 합니다.
비용 항목은 실제 작업 비용과 작업 사이의 대기 용량으로 나눕니다. 캐시 유지, 기본 노드 확보, 유휴 시간도 실제 맥 자원 지출에 영향을 주지만, 특정 테스트 작업이 점유한 시간과 같은 방식으로 배분할 항목은 아닙니다. 다음 원칙을 먼저 정하세요.
- 플랫폼 공용 회귀 테스트라면 공용 플랫폼 예산에서 부담합니다.
- 팀 전용 회귀 테스트라면 확인된 작업 사용량을 해당 팀에 귀속합니다.
- 예비 용량은 중앙 풀에서 맡을지, 이를 요청한 팀들이 나눌지 사전에 합의합니다.
- 노드가 사용할 수 없었던 시간은 작업 사용량에서 빼고, 원인과 책임은 운영 기록으로 남깁니다.
임시 증설은 요청과 비용 책임을 함께 기록합니다
배포 집중 기간이나 긴급 회귀 테스트, 단기 프로젝트 때문에 맥 용량을 늘린다면 신청자와 업무 이유, 사용 기간, 비용 센터를 함께 남기세요. 월말에 증설 비용만 발견되고 요청 기록이 없으면 이를 특정 팀의 소비로 입증하기 어렵습니다.
임시 용량을 플랫폼이 공통 예산으로 마련할 때는 회수 기준을 미리 정해야 합니다. 특정 팀이 독점적으로 요청한 증설은 해당 팀에 배정할 수 있습니다. 여러 제품 팀이 함께 쓰는 탄력 용량은 정한 규칙에 따라 공용 예산으로 처리할 수 있습니다.
월별 임시 증설 비용 = 팀에 귀속한 증설 비용 + 공용 탄력 용량 비용
각 항목은 실제 청구 자료와 증설 승인 기록에서 확인하세요. 계산식은 비용을 분류하는 틀이며, 단가나 절감 효과를 대신 증명하지 않습니다.
06정산 방식은 사용량 기준과 보유 용량 기준으로 고릅니다
팀에 실제 작업을 귀속할 수 있다면 사용량 기준이 적합합니다. 전용 노드나 예약 용량을 유지하는 일이 목적이라면 보유 용량 기준을 적용할 수 있습니다. 두 기준을 섞어 쓰려면 어떤 비용 항목에 어떤 기준을 적용하는지 사전에 문서화해야 합니다.
| 선택 기준 | 실제 사용량으로 배분 | 보유 용량으로 배분 |
|---|---|---|
| 적합한 상황 | 작업과 러너 기록을 팀별로 연결할 수 있음 | 팀을 위해 전용 또는 예비 용량을 계속 확보함 |
| 배분 근거 | 확인된 작업 점유량과 실제 자원 비용 | 합의한 예약 용량과 해당 청구 자료 |
| 유휴 시간 | 작업 사용량과 분리해 공용 항목으로 처리 | 예약 용량 규칙에 따라 비용 책임을 정함 |
| 주의할 점 | 누락되거나 잘못 연결된 작업은 억지로 귀속하지 않음 | 사용하지 않은 용량의 책임 주체를 미리 합의함 |
사용량과 예약 용량을 한 기준으로 무리하게 통일하지 마세요. PR 검증에는 실제 작업량을 적용하고, 배포를 위한 전용 서명 노드에는 합의한 용량 기준을 적용하는 식으로 비용의 성격에 맞출 수 있습니다.
07월간 대조는 추적 가능성부터 검증합니다
도입 초기에는 비용을 청구하는 방식보다 팀별 사용 내역을 보여 주는 방식으로 시작하세요. 팀별 비용 구성과 미분류 항목을 확인한 뒤, 재무와 플랫폼 운영 기준에 합의했을 때만 실제 청구에 반영하는 것이 안전합니다.
- GitHub Actions 작업 기록에서 저장소, 워크플로, 러너 연결을 확인합니다.
- 자체 호스팅 러너 기록에서 노드 사용과 상태 정보를 대조합니다.
- 맥 구매 또는 임대 청구서와 운영 비용 장부를 확인합니다.
- 작업별 근거와 비용 센터가 일치하는지 월별로 검토합니다.
- 자료 누락은 임의 배분하지 않고 미분류 항목으로 보고합니다.
- 비용 담당자, 이의 제기 절차, 재검토 조건을 문서로 남깁니다.
GitHub Actions 자체 호스팅 러너와 원격 맥 팀 예산을 함께 관리하더라도, 모든 비용을 한 가지 규칙으로 나눌 필요는 없습니다. PR, 배포, 정기 테스트, 임시 증설의 성격을 반영하고 근거 자료를 보존해야 다음 달에도 같은 기준으로 정산할 수 있습니다.
08팀 비용 분담에서 자주 확인하는 내용
자체 호스팅 맥 러너 비용은 어느 팀에 배정하나요?
작업을 요청한 팀을 기준으로 하되, 저장소와 워크플로, 러너 기록을 함께 확인해야 합니다. 공용 러너를 사용했다는 사실만으로 특정 팀의 비용이라고 단정하지 마세요. 실제 점유량으로 배분할 수 없는 공용 대기 용량은 사전에 정한 중앙 예산이나 공동 부담 규칙으로 처리합니다. 근거가 빠진 비용은 확인 전까지 미분류로 유지합니다.
실행 시간과 프로젝트 인원 중 어느 기준이 나은가요?
실제 점유 기록을 확보할 수 있다면 작업 사용량이 프로젝트 인원보다 자원 소비를 직접적으로 보여 줍니다. 인원수는 이용 가능 인원에 관한 정보일 뿐, 누가 맥 자원을 얼마나 사용했는지 설명하지 못합니다. 다만 전용 용량을 확보한 계약이라면 사용량과 별개로 예약 용량의 비용을 배정할 수 있습니다. 기준과 예외를 함께 공개하세요.
러너의 유휴 시간과 예비 용량은 팀 비용인가요?
유휴 시간은 팀의 유효 작업 사용량과 분리해 기록해야 합니다. 그렇다고 노드 유지에 드는 비용까지 없어진 것은 아닙니다. 플랫폼 공용 용량으로 운영할지, 용량을 요청하거나 예약한 팀에 배정할지 먼저 정하세요. 예비 용량과 노드 장애 시간도 따로 기록하면 실제 빌드 비용, 대기 비용, 사용 불가 비용이 서로 섞이지 않습니다.
플랫폼 요금과 맥 호스트 비용은 어떻게 구분하나요?
GitHub Actions 청구 자료는 플랫폼 사용 내역의 근거로 사용하고, 맥 호스트 비용은 맥 자원의 실제 구매 또는 임대 청구와 운영 장부에서 확인합니다. 러너 작업 기록은 작업과 노드를 연결하는 데 씁니다. 월별로 자료를 대조해 중복 청구와 미기록 비용을 확인하세요. 작업 기록이 비용 센터까지 연결되지 않으면 임의로 팀에 배정하지 말고 확인이 끝날 때까지 보류합니다.
09기존 맥 운영과 탄력 용량을 함께 비교합니다
자체 장비를 구매하면 초기 지출과 장비 교체·운영 부담이 생기고, 사용량이 적은 기간에도 보유 용량이 남을 수 있습니다. 반면 원격 맥 임대는 필요한 기간에 맞춰 용량을 검토할 수 있지만, 장기간 일정한 부하를 계속 처리하거나 물리 장비와 직접 연결해야 한다면 자체 장비가 더 적합할 수 있습니다.
현재의 자체 호스팅 러너 기록과 구매 또는 임대 청구 자료를 먼저 대조한 뒤, 부족한 임시 빌드 용량만 별도로 비교하세요. VpsMesh의 원격 맥 주문 정보를 확인하고, 팀의 접속 위치가 서울이라면 서울 지역 맥 노드 정보도 함께 검토해 실제 이용 기간과 제공 조건에 맞는지 살펴보세요. 맥의 물리적 사용이나 장기간의 고정 부하가 중요한 팀이라면 구매 장비를 유지하고, 단기 프로젝트나 배포 집중 기간에만 추가 용량이 필요한 팀이라면 원격 맥을 보완 수단으로 살펴보세요.