GitLab의 무료 게스트는 권한표를 잘 만나야 한다

요약

• GitLab Premium에서는 Guest도 유료 좌석에 포함된다. Ultimate에서는 조건을 충족하는 Guest가 좌석을 쓰지 않아, 같은 협업 인원도 요금제와 역할 구성에 따라 청구 대상 인원이 달라진다.
• Ultimate의 Guest에 코드 열람 권한만 추가한 예외는 무료지만 다른 권한은 유료 좌석으로 이어질 수 있다. 이미 산 빈 좌석이 있는지, 구독 기간의 최대 사용량을 넘기는지가 실제 추가 비용을 가른다.

구매 버튼은 권한 설정 화면에도 있다

소프트웨어 구매 회의에서는 사용자당 단가를 꼼꼼히 비교한다. 정작 그 사용자 수를 누가 정하는지는 회의가 끝난 뒤에야 드러나곤 한다. GitLab에서는 프로젝트에 사람을 초대하고 역할을 부여하는 운영자가 그 숫자를 바꿀 수 있다. 가격표를 보지 않고 누른 권한 선택이 이미 구입한 좌석을 하나 더 채우는 셈이다.

이 구조가 특히 선명하게 보이는 곳이 게스트다. GitLab의 좌석 관리 문서에 따르면 Premium에서는 Guest가 과금 대상이다. Ultimate에서는 다른 유료 역할 없이 Guest로 참여하는 이용자가 좌석을 차지하지 않는다. 같은 초대 인원에게 더 높은 요금제를 적용했는데도 청구 대상 인원은 줄어들 수 있는 구조다.

따라서 상위 요금제의 경제성은 기능 목록에만 있지 않다. 개발자가 아닌 참여자를 얼마나 넓게 들일 수 있는지에도 있다. 요구사항을 확인하는 담당자, 논의에 의견을 보태는 동료, 코드 내용을 살펴봐야 하는 관계자의 일이 모두 같은 권한을 요구하지는 않는다. 실제 업무에 맞춰 이들을 구분할 수 있어야 게스트 예외가 구매 계산에 들어간다.

물론 Guest라는 이름은 단순한 손님 분류가 아니다. 시스템이 정한 권한 묶음이다. 역할별 권한 안내에서 기본 Guest는 이슈와 에픽에 참여할 수 있지만, 일반적인 비공개 저장소의 코드 접근 권한은 갖지 않는다. 코드를 볼 수 있는 Reporter는 과금 대상이다. 읽기만 하는 사람이라고 해서 자동으로 무료가 되는 것은 아니다.

코드 한 번 보게 해주는 데에도 정확한 선이 있다

Ultimate에는 흥미로운 예외가 하나 더 있다. 사용자 지정 역할을 Guest에 기반해 만들고, 추가 권한을 read_code 하나로 제한하면 좌석을 소비하지 않는다. 필요한 사람이 비공개 코드를 볼 수 있도록 하면서도 전체 개발자 권한을 줄 필요가 없어진다.

이 예외를 모든 읽기 권한에 적용하면 계산이 틀어진다. Guest 안내는 그 밖의 권한을 추가하면 해당 역할이 유료 좌석을 차지한다고 설명한다. 무료로 코드를 읽는 역할과 추가 업무까지 수행하는 역할 사이에 상업적 경계가 그어져 있는 것이다.

기업 입장에서는 쓸모 있는 선택지다. 단순 열람에 더 넓은 역할을 줄 이유가 줄어든다. 동시에 “이 기능도 열어 달라”는 요청을 처리할 때 업무상 필요와 좌석 효과를 함께 살펴야 한다. 설정 몇 개를 더 허용한 것처럼 보여도 그 사람이 구독에서 차지하는 자리는 달라질 수 있다.

여기서 무료 역할을 무조건 고집하면 엉뚱한 비용이 생긴다. 필요한 권한이 없는 이용자는 동료에게 일을 대신 부탁하고, 확인을 기다리고, 같은 내용을 다른 경로로 전달받게 된다. 좌석 수는 적어도 업무는 비싸질 수 있다. 적절한 구매 판단은 그 사람이 수행해야 할 일을 먼저 정한 뒤, 거기에 맞는 권한을 부여하는 데서 시작한다.

반대로 편의를 위해 모두에게 넓은 역할을 주는 방법도 공짜는 아니다. 당장의 문의는 줄일 수 있어도, 실제로 사용하지 않는 능력까지 구독 인원에 반영할 수 있다. 좁은 권한은 보안 담당자만의 취향이 아니다. 업무를 방해하지 않는 범위에서는 구매 단위도 더 정확하게 만든다.

다른 프로젝트에서 쓰는 모자까지 세어야 한다

한 프로젝트의 회원 목록에서 Guest라고 표시되는 것만 보고 무료 인원으로 분류하기도 어렵다. GitLab.com에서는 해당 구독의 네임스페이스 범위 안에 있는 다른 역할을 함께 봐야 한다. 그 안의 다른 프로젝트나 하위 그룹에서 더 높은 유료 역할을 갖고 있다면, 한쪽의 Guest 표시는 좌석 면제 증명이 되지 못한다.

Self-Managed에서는 범위가 인스턴스 전체로 넓어진다. GitLab은 Ultimate로 올리기 전에 게스트에게 다른 역할이 있는지 확인하라고 명시한다. GitLab.com의 개인 네임스페이스와 구독 그룹의 관계를 이 규칙에 그대로 대입하면 안 된다. 어느 제공 방식인지에 따라 살펴볼 경계가 달라진다.

그렇다고 프로젝트마다 같은 사람의 요금이 중복되는 것은 아니다. 하나의 구독을 가진 최상위 그룹 아래 여러 그룹과 프로젝트에 속한 이용자는 한 번만 계산된다. 회원 목록의 행 수를 전부 더하는 방식도, 가장 낮은 역할 하나만 보는 방식도 실제 청구 대상을 잘못 셀 수 있다.

이 대목에서 구매팀의 인원표와 운영팀의 권한표가 만난다. 누구에게 접근을 줄지는 업무 책임자의 판단이어야 한다. 그 판단이 이미 산 좌석의 사용인지, 추가 좌석 수요인지 알려면 실제 역할을 같은 범위로 모아 봐야 한다. 부서별로 각자 만든 숫자를 합친다고 구독 경계가 저절로 맞아 주지는 않는다.

사람이 줄어도 최고 기록은 남는다

게스트가 유료 역할로 바뀌었다고 곧바로 새 청구서가 나오는 것은 아니다. 구입해 둔 좌석이 비어 있다면 그 안에 들어갈 수 있다. GitLab.com은 구매 수량을 넘지 않는 한 구독 기간 중 이용자를 바꿔 쓰는 것도 허용한다. 한 해 동안 거쳐 간 모든 사람을 누적해서 한 명씩 더 파는 구조로 읽을 이유는 없다.

문제는 구매한 수량을 넘을 때다. 과금에는 해당 기간의 최대 사용 인원이 중요하다. 이후 권한을 줄이거나 사람을 빼서 현재 인원을 낮춰도, 이미 기록한 최고 사용량까지 지워지는 것은 아니다. 최신 화면이 깔끔해졌다는 사실과 그 기간의 추가 비용은 따로 확인해야 한다.

초과 좌석 과금 안내는 분기 정산과 연간 추가 정산을 구분한다. 분기 정산은 분기 중 최대 수량과 남은 구독 기간에 대한 안분 규칙을 사용하고, 연간 방식은 해당 연도에 추가된 이용자에 대해 연간 구독료를 적용한다. 모든 고객이 분기 정산 대상인 것도 아니다. 구매 좌석 자체를 줄이려면 구독 갱신 절차에서 다음 기간의 수량을 조정해야 한다.

이 때문에 비용 검토 시점도 달라진다. 갱신 직전에만 계정을 정리하면 앞으로의 수량은 고칠 수 있어도, 이미 발생한 최고 사용량은 뒤늦게 발견하게 된다. 유료 역할로 바꾸는 순간에 남은 좌석을 확인하는 편이 구매 관리와 더 직접적으로 연결된다.

현재 공개 가격표의 Premium은 연간 결제 기준 사용자당 월 29달러이고, Ultimate는 개별 견적을 요구한다. 실제 Ultimate 견적과 유료 역할이 필요한 인원 구성이 없으면 어느 쪽이 싼지 계산할 수 없다. 다만 비교해야 할 것은 분명하다. 단가만 놓고 싸우는 동안, 권한표가 곱셈의 다른 쪽 숫자를 바꾸고 있다.