요약

  • GitLab.com의 호스팅 빌드 작업은 최상위 네임스페이스의 허용량을 소비합니다. 따라서 별개의 프로젝트와 하위 그룹이 동일한 잔여 한도에 의존할 수 있습니다.
  • 추가 구매한 컴퓨트 미니트는 포함된 쿼터를 보완하며 미사용 팩은 다음 해로 이월되지만, 그룹 간에 이전할 수는 없습니다. 명시된 12개월 유효기간은 영구적인 가용성을 약속하는 것이 아니며, 현재는 만료가 강제되지 않고 있습니다.
  • 허용량 소진, 러너 가용성, 안전한 실행 권한은 서로 다른 조건입니다. 건전한 구매 결정은 세 가지를 모두 고려하되, 테스트를 줄이거나 격리를 약화시키는 것을 절감으로 취급하지 않아야 합니다.

미터가 붙은 조직도

두 팀이 서로 다른 프로젝트를 관리하고, 서로 다른 릴리스 일정을 유지하며, 서로 다른 예산 책임자에게 보고하면서도 하나의 GitLab.com 컴퓨트 허용량을 공유하는 상황이 가능합니다. 하나의 최상위 그룹 아래에 제품 프로젝트와 사내 도구 프로젝트가 배치되어 있다고 상상해 보십시오. 어느 팀도 상대 팀의 코드를 변경하지 않습니다. 그러나 한 팀의 호스팅 빌드 활동이 다른 팀이 사용할 수 있는 허용량을 줄입니다.

이것은 특정 고객 사고가 아니라 설명을 위한 가상의 구성입니다. 소프트웨어 작업을 조직화할 때 거의 무심코 만들어질 수 있는 선택을 드러냅니다. 공용 자원 풀은 어디서 시작하고 어디서 끝나야 할까요? 협업을 편리하게 만드는 그룹 구조가 곧 어떤 워크로드가 공통의 상업적 한계 지점을 공유하는지를 결정하는 데 도움을 줍니다.

GitLab의컴퓨트 미니트 문서는 작업 사용량을 해당 작업이 실행되는 프로젝트의 최상위 네임스페이스에 귀속시킵니다. 누군가 버튼을 눌렀다는 이유만으로 기여자의 개인 네임스페이스에 과금되지 않습니다.네임스페이스 모델은 그룹이 자체 설정을 가진 하위 그룹을 포함할 수 있도록 합니다. 그러나 이 행정적 구분이 모든 하위 그룹에 별도의 최상위 허용량을 만들어 주지는 않습니다.

풀링에는 합리적인 목적이 있습니다. 한가한 프로젝트의 미사용 여유분은 별도 구매 없이도 다른 프로젝트의 바쁜 시기를 흡수할 수 있습니다. 그러나 풀링은 수요의 시점 자체를 공유사로 만듭니다. 프로젝트 소유권이 분리되어 있다는 것이 예산이 격리되어 있다는 뜻은 아닙니다. 구매자는 이 풀을 소비할 수 있는 사람들이 우선순위에 대한 공통 이해를 가지고 일하는지를 판단해야 합니다.

같은 것을 재지 않는 미니트

단위의 이름은 오해를 부르는 비교를 유도합니다. 개발자는 파이프라인이 끝나기까지 걸린 시간을 봅니다. 허용량은 실행된 작업 전반에 걸친 가중치가 적용된 실행량을 기록합니다. 문서화된 공식에 따라 작업의 실행 시간(초)을 60으로 나누고 비용 계수를 곱하며, 생성 및 대기 시간은 제외됩니다.

의도적으로 단순화한 예로, 계수 1로 동시에 실행되는 세 개의 독립적인 10분짜리 작업은 실행이 10분 안에 겹쳐 이루어지더라도 30 컴퓨트 미니트를 사용합니다. 이 산수는 추가 작업이나 오버헤드가 없다는 가정을 전제로 하며, 성능 벤치마크도 고객 청구액의 예측도 아닙니다.

빠른 피드백이 그만한 소비를 감수할 가치가 있을 수 있습니다. 그러나 기계를 병렬로 늘리는 대신 중복 작업을 제거해서도 얻을 수 있습니다.파이프라인 효율 가이드는 임계 경로, 의존성, 기계 크기 조정, 준비 작업을 구분합니다. 임계 경로가 짧아진 것과 쿼터 차감이 작아진 것은 별개의 성과이며, 하나가 다른 하나를 증명하지 않습니다.

공유 그룹에서 유용한 질문은 어느 팀이 가장 짧은 파이프라인을 만드느냐가 아닙니다. 어떤 변경이 공통 허용량 대비 수행 작업의 가치를 높이느냐입니다. 더 길지만 필요한 테스트를 가진 프로젝트가, 테스트를 덜 해서 대시보드만 빨라 보이는 프로젝트에게 자동으로 밀려서는 안 됩니다.

소진은 정의된 절차를 따른다

그룹 경계가 가장 뚜렷해지는 시점은 허용량이 고갈될 때입니다. GitLab의쿼터 강제 규칙은 잔여량이 25% 미만, 5% 미만, 0인 시점에 경고를 제공합니다. 네임스페이스 소유자에게 이메일 알림이 발송되고 앱 내 배너가 표시됩니다. 경고를 받는 사람이 다른 프로젝트의 작업 수를 결정하는 사람일 필요는 없습니다.

해당 허용량이 고갈되면 인스턴스 러너는 새 작업 처리를 중단합니다. 이미 시작된 파이프라인에서 그런 러너를 필요로 하는 대기 중이거나 재시도 중인 작업은 삭제됩니다. 실행 중인 작업은 네임스페이스의 총 사용량이 쿼터를 1,000 컴퓨트 미니트 초과할 때까지 계속될 수 있으며, 이 유예 경계를 넘으면 남은 실행 중 작업도 삭제됩니다. 프로젝트 및 그룹 러너는 이 특정 쿼터의 영향을 받지 않습니다.

1,000분이라는 수치는 모든 프로젝트에 부여되는 예비분이 아닙니다. 실행 중인 파이프라인이 끝까지 완료된다는 보장도 아닙니다. 여러 워크로드가 같은 총 한계 여유분을 동시에 소비하고 있을 수 있습니다. 이를 믿을 수 있는 비상 예산으로 취급하면 그 범위와 목적을 모두 오해하게 됩니다.

이 중 어느 것도 GitLab 장애를 의미하지 않습니다. 서비스는 문서대로 정상 작동하면서도 고객의 작업이 영향받은 러너에서 진행되지 못할 수 있습니다. 이 구분은 대응 방식을 바꿉니다. 인프라 장애는 서비스 복구를 요구하고, 고갈된 허용량은 승인된 구매 또는 워크로드 결정을 요구합니다. 둘을 혼동하면 긴급한 문제를 해결 권한이 없는 사람에게 보내게 됩니다.

그룹 경계 너머의 돈

추가 팩을 구매하는 것과 반복 월 배분을 늘리는 것은 같지 않습니다. GitLab의구매 문서에 따르면 추가 미니트는 포함된 쿼터가 소진된 후에 사용됩니다. 미사용 구매 미니트는 이월되지만, 팩은 매월 갱신되는 권리가 아니라 일회성 구매입니다.

중요한 공간적 규칙은 구매한 미니트가 그룹 간에 이전될 수 없다는 점입니다. 따라서 한 회사가 어떤 그룹에 미사용 팩을 갖고 있으면서 다른 그룹에서 허용량 부족을 겪는 일이 가능합니다. 이것은 명시된 규칙이 만들어내는 가능성이지, 특정 회사가 지출을 좌초시켰다는 증거가 아닙니다. 사내 통합 스프레드시트만으로 권리를 옮길 수는 없습니다.

시간도 하나의 단서를 더합니다. 구매한 미니트는 구매 시점부터 12개월의 유효기간이 명시되어 있습니다. 만료는 현재 강제되지 않지만, GitLab은 그 날짜 이후의 유효성을 보장하지 않습니다. 따라서 12개월 후에도 여전히 보이는 잔액은 보장된 영구 예비분과 다릅니다. 이와 달리 구독 등급을 변경하더라도, Free 티어로의 이동을 포함해 구매한 미니트는 계속 사용할 수 있습니다.

이런 구분들은 정확한 구매 기록, 즉 수신 그룹, 구매일, 포함 배분량, 잔여 추가 잔액을 유지하도록 만듭니다. 그렇다고 더 저렴해 보이는 총액만 좇아 저장소를 재편하는 것을 정당화하지는 않습니다. 접근 권한, 협업, 운영 의존성도 프로젝트 조직을 따라가며, 이 근거만으로는 프로젝트 이전의 모든 결과를 확정할 수 없습니다.

허용량은 예약이 아니다

충분히 자금이 뒷받침된 그룹이라도 적합한 러너가 필요합니다. GitLab의러너 개요는 태그, 범위, 상태, 용량, 능력에 따른 매칭을 설명합니다. 구매 권한이 이 조건들을 무력화하지는 않습니다.

호스팅 러너 문서는 시작 시간 목표를 제시합니다. 작업의 90%가 120초 안에 실행을 시작해야 한다는 것입니다. 이것은 SLO이며, 특정 월에 그 목표가 달성되었다는 진술이 아니고, 구매자의 다음 작업을 위한 예약도 아닙니다. 일반적인 GitLab.com 호스팅 작업은 새 가상 머신을 받으며, 특별한 커뮤니티 기여용 구성은 다른 특성을 가집니다.

구매자가 마주하는 세 가지 질문은 이렇습니다. 허용량이 있는가, 호환되는 실행 환경이 사용 가능한가, 이 작업이 거기서 실행되도록 승인되어 있는가? 하나에 대한 긍정적 답이 다른 두 개를 대신할 수 없습니다. 미니트를 더 사는 것은 쿼터 제약은 해소할 수 있어도, 잘못 짜인 작업 구성이나 대기 시간 문제를 개선하지 못합니다.

프로젝트 분석은 이 구분을 유지하는 데 도움이 됩니다. GitLab의CI/CD 분석은 파이프라인 소요 시간과 결과 지표를 제공합니다. 이것들은 작업의 행동을 설명하고, 네임스페이스 미터는 공통 소비 경계를 설명합니다. 어느 하나만으로 조직이 적시에 올바른 테스트를 수행하고 있는지는 확정되지 않습니다.

지불 주체를 바꾸면 신뢰 결정도 바뀐다

포크 기반 작업에서는 이 경계가 특히 실감됩니다. 포크에서 온 머지 리퀘스트는 보통 그 포크에서 파이프라인을 실행하고 포크의 자원을 사용합니다. 적절한 권한을 가진 멤버는 대신 부모 프로젝트에서 파이프라인을 시작할 수 있으며, 이때 포크 브랜치의 구성을 부모의 실행 컨텍스트와 자원으로 실행합니다. GitLab의머지 리퀘스트 파이프라인 가이드는 그렇게 하기 전 신뢰할 수 없는 코드 검토에 대해 명시적으로 경고합니다.

이 이동은 단지 미니트가 남은 허용량을 찾는 방법이 아닙니다. 누구의 자원이 그 작업을 지탱하는지, 누구의 권한 아래에서 실행되는지를 바꿉니다. 보호된 변수와 러너에는 각자의 제한이 그대로 남아 있으며, 문서는 부모 프로젝트 실행이 모든 시크릿에 접근 권한을 얻는다고 말하지 않습니다.

비슷한 구분이 고객 관리 러너에도 적용됩니다. 프로젝트 또는 그룹 러너는 인스턴스 러너 쿼터 밖에서 계속 처리할 수 있지만, 고객이 그 운영 환경에 대한 책임을 집니다. GitLab의보안 가이드는 공유되고 비휘발성인 실행 환경의 위험을 논의합니다. 소비 미터 하나를 피한다고 해서 호스트 유지관리, 격리, 용량 관리 문제가 사라지는 것은 아닙니다.

이 근거는 "호스팅 빌드는 비싸다"보다 더 좁고 더 유용한 구매 결론을 지지합니다. 그룹 구조가 어떤 작업이 허용량을 공유하고, 구매한 여유분을 어디에서 사용할 수 있는지를 결정합니다. 회사는 그 구조를 의식적으로 선택해야 하며, 보충 결정이 희소성이 대신 결정을 내리기 전에 해당 소유자에게 닿아야 합니다.

출처와 범위

이 분석은 2026년 9월 3일에 검토한 현재 GitLab 문서를 사용합니다:컴퓨트 미니트,쿼터 강제,추가 구매및네임스페이스.

운영상 구분은파이프라인 효율,러너,호스팅 러너,머지 리퀘스트 파이프라인,셀프매니지드 보안및CI/CD 분석에서 나옵니다. 고객 청구서, 비공개 텔레메트리 또는 협상된 계약서는 검토하지 않았습니다. 쿼터 분석은 GitLab.com을 대상으로 하며, 모든 Self-Managed 또는 Dedicated 설치가 동일한 상업적 방식을 따른다는 주장이 아닙니다.