Confluence는 25명인데, 앱 청구서는 왜 100명을 세나

요약

• Atlassian은 Confluence Cloud 사용자 25명의 앱이 Teamwork Collection으로 이동하면서 같은 사이트의 Jira 사용자 100명에 맞춰 청구되는 예를 제시한다.
• Collection은 포함된 제품 사이에서 같은 사용자를 한 번만 세지만, Marketplace 앱에는 별도의 라이선스 기준이 적용된다. 묶음 상품의 사용자 중복 제거와 앱의 과금 인원 확대가 동시에 일어날 수 있다.
• Enterprise의 인스턴스별·다중 인스턴스 과금과 Forge의 사용자별 과금 설계는 서로 다른 범위를 다룬다. 현재 구매 가능한 방식과 실제 견적을 맞춰 봐야 비용 비교가 성립한다.

앱을 쓰는 팀은 그대로인데, 청구서가 옆 부서 사람까지 세기 시작한다. Atlassian이 공개한 Marketplace 앱 과금 안내에 그 장면이 있다. 사용자 25명의 Confluence Cloud에 앱을 설치한 뒤, 같은 사이트에 Jira 사용자 100명이 있는 Teamwork Collection으로 구독을 옮기면 그 앱에 100명 가격이 적용된다.

공식 문서가 든 예시다. 새로운 사용자가 그 앱의 기능을 열심히 익혔다는 조건은 붙어 있지 않다. 기존 구독이 들어간 범위가 바뀌고, 앱이 요금을 계산하는 인원도 바뀐다.

25명에서 100명으로 늘면 인원은 네 배다. 금액은 해당 앱의 가격표와 구간, 할인에 달려 있다. 여기서 확인할 일은 묶음 상품이 얼마나 매력적으로 보이느냐보다 구체적이다. 제품을 한데 모은 뒤 기존 앱들은 누구를 기준으로 견적을 내는가.

중복을 지우는 계산 옆에 인원을 늘리는 계산이 있다

Collection 과금 설명은 포함된 제품의 사용자 수를 합칠 때 같은 사람을 한 번만 센다고 설명한다. 포함 앱 가운데 하나 이상에 접근할 수 있는 사람이 청구 대상이며, 여러 앱을 써도 중복해서 세지 않는다. Teamwork Collection에서는 Jira, Confluence, Loom 등의 개별 구독이 하나의 묶음 상품 항목으로 정리된다.

여러 제품을 오가는 직원이 많은 조직에는 이해하기 쉬운 제안이다. 회사는 같은 사람을 제품마다 새 구매 대상으로 취급하는 복잡함을 줄이고 싶다. 관리 화면과 계약 설명도 간결해진다.

기존 Marketplace 앱은 자신의 라이선스를 들고 함께 이동한다. Atlassian은 앱과 부가 기능의 과금이 라이선스 및 설치된 제품과의 연결 방식에 달려 있으며, Collection으로 옮기면 가격에 영향이 생길 수 있다고 설명한다. 포함 제품에서 중복 사용자를 줄이는 계산이 외부 앱의 과금 범위까지 동일하게 줄여 주지는 않는다.

그래서 같은 구매가 두 방향으로 움직일 수 있다. 포함된 제품의 사용자는 합리적으로 정리되고, 특정 팀의 도구는 더 큰 인원을 바탕으로 청구된다. 구매 담당자가 전체 비교표에서 기존 앱을 빠뜨리면 한쪽의 절감만 보게 된다.

새 기능을 추가한 기억이 없는데 앱 비용을 다시 설명해야 하는 상황은 이 지점에서 생길 수 있다. 제품을 묶는 일은 기술적인 정리이면서 라이선스가 닿는 사람들의 범위를 다시 정하는 일이기도 하다. 이사한 방은 비슷해도 관리비를 나누는 건물이 커진 셈이다.

쓰는 사람보다 사용 자격을 파는 범위가 넓다

Atlassian의 Forge 과금 모델 문서는 표준 과금에서 호스트 인스턴스의 모든 사용자에게 요금을 매긴다고 설명한다. 실제로 Marketplace 앱을 쓰는 사람이 몇 명인지는 이 인원 기준을 줄이지 않는다.

문서의 예에는 Jira 사용자 500명과 앱을 실제로 쓰는 50명이 등장한다. 예시 단가가 월 1인당 2달러이면 500명을 기준으로 월 1000달러가 된다. 이 가격은 과금 구조를 설명하기 위한 공식 예시에 쓰인 수치다. 중요한 숫자는 사용자가 50명이어도 계산 대상이 500명이라는 차이다.

전문 도구를 고르는 작은 팀에는 이 차이가 구매 문턱이 된다. 자기 팀의 보고서나 문서 작업을 개선하고 싶은데, 구매 범위는 더 큰 업무 환경을 따라간다. 팀의 이익만으로 더 넓은 인원의 구매를 정당화해야 할 수 있다.

반대로 많은 사람이 공유할 도구라면 넓은 라이선스가 편할 수도 있다. 누구에게 필요한지 매번 정하고 권한 목록을 따로 관리하는 일을 줄일 수 있기 때문이다. 핵심은 구매할 사용 자격과 도구가 실제로 필요한 범위를 함께 보자는 것이다. 최근 로그인이나 클릭 수만으로는 계약이 어떤 집단을 세는지 알 수 없다.

Jira 앱의 기준도 단순 합계와 다르다. 공식 안내는 같은 사이트에 Jira 사용자 100명과 Jira Service Management 상담원 80명이 있을 때 앱에 더 큰 쪽인 100명 가격을 적용한다고 한다. 180명을 더해 청구하는 예가 아니다. 100명짜리 Jira 구독을 비활성화하면 다음 청구 주기부터 남은 80명 가격이 적용된다.

어느 호스트 제품이 앱의 인원 기준을 결정하는지 알아야 변화도 읽을 수 있다. 앱 사용자에게 설문을 돌리는 것과 호스트 구독의 인원을 확인하는 것은 서로 다른 정보를 얻는 일이다.

Enterprise에서는 설치 위치도 구매 조건이다

Enterprise 청구 안내에는 Acme라는 예시 조직이 나온다. Jira Enterprise 사용자 8000명이 5000명과 3000명짜리 두 인스턴스에 나뉘어 있다. Marketplace 앱을 5000명 인스턴스에 설치하면 해당 단일 인스턴스 앱 구독은 5000명 기준으로 청구된다.

조직 전체가 크다고 모든 앱이 자동으로 전체 인원을 따라가는 구조로 읽으면 이 선택지를 놓친다. 어디에 설치하는지가 라이선스 범위를 정할 수 있다. 특정 팀의 업무를 위한 도구와 회사 전체의 도구는 서로 다른 설치·구매 구성을 가질 수 있다.

인스턴스를 나누는 일에는 운영도 따라온다. 설정을 유지하고, 사용자에게 접근 방법을 설명하고, 다른 환경의 업무를 이어야 한다. 앱 견적이 낮아진 만큼만 성과로 기록하면 이 일의 비용은 다른 부서로 밀려난다. 설치 범위와 관리 부담을 같이 비교해야 한다.

Atlassian은 Cloud Enterprise의 Jira와 Confluence에 대해 다중 인스턴스 앱 과금도 설명한다. 여러 인스턴스를 조직 수준의 앱 구독 하나에 묶고, 인스턴스들에 걸친 고유 사용자를 구독 시작 시 선택한 사용자 구간에 따라 계산한다. 같은 사람이 여러 인스턴스에 접근해도 한 번만 센다. 구독을 산 뒤에도 기능을 쓰려면 각 인스턴스에 앱을 설치해야 한다.

이 방식은 여러 환경에서 같은 사람이 반복해서 나타나는 문제를 다룬다. 한 인스턴스 안에서 필요한 소수에게만 앱 접근을 허용하고 그 인원에만 요금을 매기는 방식과는 구분해야 한다. 구매자는 어떤 중복을 줄이려는지 먼저 정해야 적합한 옵션을 찾을 수 있다.

지원 문서는 모든 앱이 다중 인스턴스 가격을 제공하게 된다는 부분을 미래형으로 적고 있다. 특정 구매에서는 그 앱이 현재 제공하는 라이선스 옵션이 기준이 된다. 제품 설명에 등장하는 여러 범위를 한꺼번에 자기 계약에 적용할 수는 없다.

작은 팀만 계산하는 모델에도 공급자의 결정이 남는다

Forge의 사용자별 과금 도입 안내는 앱 접근 권한을 받은 사용자 집단을 따로 정하는 설계를 설명한다. 관리자가 접근을 허용한 사람들이 과금 대상이다. 실제 클릭 횟수나 활발하게 쓰는 날의 수를 재는 방식과는 기준이 다르다.

현재 확인한 개발자 문서는 이 기능을 EAP로 표시하고, 비운영 환경에서의 개발·배포·시험을 설명한다. Marketplace 게시와 가격 설정, 앱 개정과 승인은 향후 업데이트에 포함된다고 적고 있다. 같은 안내에 이미 게시된 앱과 운영 전환 조건도 함께 나오므로, 구매자는 대상 앱에서 실제로 활성화된 과금 모델을 확인해야 한다.

설계 자체도 공급자 선택을 포함한다. 파트너가 전환 여부를 고르고, 가격을 조정할 수 있으며, 기존 고객도 해당 앱의 모델 전환을 따르게 된다. Forge 앱을 대상으로 하며 Connect 앱은 Forge로 옮겨야 한다. 고객이 권한 목록을 줄인다는 사실만으로 새로운 구매 조건이 생기는 것은 아니다.

과금 인원이 좁아지면 전문 도구가 큰 조직에 들어가는 문턱을 낮출 여지가 생긴다. 공급자는 그 좁아진 범위에 맞춰 가격을 다시 정할 수 있다. 더 적은 사람을 세는 것과 총비용을 낮추는 것은 견적에서 만나는 두 변수다.

개별 회사의 지출이나 이전 효과를 확정하려면 적용되는 앱 라이선스, 선택한 인원 구간과 공급자의 실제 견적이 필요하다. 공식 예시가 이미 밝혀 준 질문은 단순하다. 묶음 상품으로 이동한 뒤, 기존 앱이 세는 사람이 달라지는가.

제품을 한데 모으는 결정은 협업을 쉽게 만들 수 있다. 구매까지 제대로 묶으려면 따라오는 앱들의 견적도 새 범위로 다시 받아야 한다. 25명의 도구가 100명의 가격표를 만나는 순간은, 앱을 더 열심히 쓰기로 한 회의가 아니라 구독을 어디에 넣을지 정한 회의일 수 있다.