소프트웨어 라이선스 시트 트래커: 시트와 갱신 모니터링

시트(사용자 라이선스)가 이렇게 금세 엉켜버리는 이유

시트 라이선스는 거의 '한 번 설정하고 끝'이 되지 않습니다. 사람이 들어오고, 팀이 바뀌고, 새 도구를 시험해보고, 프로젝트용 임시 접근이 생기면 사용량이 서서히 늘어납니다. 몇 달 후면 어떤 시트가 필수인지, 어떤 게 남아도는지, 어떤 갱신이 다가오는지 아무도 모르게 됩니다.

보통 무해하게 시작합니다: 매니저가 "혹시 몰라" 몇 개 시트를 추가하거나, 계약자가 제거되지 않거나, 파일럿 그룹이 조용히 영구 워크플로로 바뀝니다. 이런 일이 열두 개 앱에 겹치면 회사가 거의 사용하지 않는 도구에 비용을 지불하게 됩니다.

문제가 생기면 세 군데에서 드러납니다:

• 비용: 갱신과 트루업이 사용량 확인 전에 청구됩니다.
• 접근: 잘못된 사람이 관리자 권한을 유지하거나, 필요한 사람이 접근하지 못합니다.
• 책임 추적: 감사와 내부 검토가 누가 어떤 접근을 했는지 증명하려는 소동으로 변합니다.

팀마다 느끼는 영향은 다릅니다. 재무팀은 갱신에 놀라고 지출을 예측하기 어렵다고 느낍니다. IT/운영은 "오늘 시트 하나 더 추가" 같은 긴급 요청을 받고, 접근 문제로 비난을 받습니다. 팀 리드는 승인 추적에 쫓기고, 직원들은 소유권이 불명확한 도구들 사이를 옮겨 다닙니다.

그래서 시트 트래커는 단순한 잡무가 아닙니다. 누가 무엇을 쓰는지, 무엇이 미사용인지, 언제 무엇을 갱신해야 하는지 통제하는 시스템입니다. 예를 들어 지원팀이 채팅 도구에 40좌석을 지불하는데 이번 달 실제 로그인한 사람은 28명뿐이라면, 청구서가 도착한 뒤에 다투는 대신 갱신 전에 시트를 회수하고 싶을 것입니다.

시트, 소유자, 날짜가 한곳에 있으면 갱신은 놀라움이 아니라 결정이 됩니다.

핵심 용어: 시트, 갱신, 트루업

초기에 용어를 명확히 해두면 많은 논쟁을 피할 수 있습니다. 벤더는 비슷한 단어를 쓰지만 의미는 다를 수 있습니다.

“시트”는 한 사람이 제품을 사용할 권리입니다. 대부분의 도구는 특정 사람(예: [email protected])에게 할당된 명명된 사용자 시트를 판매합니다. 동시 접속형(concurrent) 시트는 다릅니다: 더 많은 계정이 있어도 동시에 로그인할 수 있는 인원을 제한합니다.

보통 세 가지 모델을 마주치게 됩니다:

• 명명된 사용자: 한 사람당 한 시트, 사용 여부와 관계없이 과금
• 동시 사용자: 활성 세션 수로 상한 설정, 시트를 공유
• 역할 기반 또는 모듈 기반: 기능이나 티어별로 가격 책정

갱신(renewal)과 트루업(true-up)은 자주 혼동됩니다. 갱신은 가격과 조건이 리셋될 수 있는 계약 날짜(월간, 연간, 복수 년)입니다. 트루업은 지불한 것보다 더 많은 사용자를 추가했을 때 중도나 갱신 시점에 청구되는 정산 비용입니다.

더 복잡한 부분은 무엇이 과금 대상 시트인지입니다. 어떤 도구에서는 초대된 사용자(invited user)도 로그인 여부와 상관없이 과금 대상인 반면, 다른 도구는 활성화된 사용자만 센다. 이 때문에 벤더 포털과 스프레드시트가 달라지기 쉽습니다: 포털은 오늘의 할당을 반영하지만, 스프레드시트는 지난달 팀 목록, 오래된 이메일, 중복을 그대로 담고 있을 수 있습니다. 별칭(alias) 같은 작은 문제도 숫자를 부풀려 갱신을 깜짝 놀라게 만들 수 있습니다.

추적할 항목(필수 데이터)

시트 트래커는 두 가지 질문에 빠르게 답할 수 있어야 유용합니다: 현재 누가 각 시트를 사용하고 있는가, 갱신이나 트루업 때 얼마를 내야 하는가. 그 밖의 항목은 선택사항입니다.

최소로 캡처할 필드

모든 앱에 대해 필드를 일관되게 유지하세요. 얻기 어려운 항목이 있으면, 유지관리 가능한 더 단순한 버전을 사용하세요.

• 앱 기본 정보: 앱 이름, 내부 소유자, 좌석당 비용, 계약 시작일, 계약 종료일
• 시트 할당: 사용자, 팀, 역할(또는 라이선스 티어), 시트 상태(활성, 제거 대기, 미할당)
• 사용 신호: 마지막 활동 날짜(또는 마지막 로그인)와 그 수치의 출처
• 청구 설정: 청구 주기(월간, 연간), 자동 갱신 여부, 통지 기간(일수)
• 증빙: 각 핵심 필드의 신뢰 가능한 출처(SSO 디렉터리, 관리자 내보내기, 인보이스)

이 정도만 있어도 사람들이 실제로 묻는 질문에 답할 수 있습니다: "어떤 팀이 40좌석을 보유하고 있나?", "미할당된 좌석은 몇 개인가?", "다음 달에 무엇이 갱신되나?"

증빙(출처)은 완벽함보다 더 중요합니다

트래커에 신뢰가 무너지면 누가 수치를 가져왔는지 알 수 없을 때입니다. 간단한 증빙 메모를 추가하세요. 예를 들어 "Okta export from Jan 12"나 "Invoice PDF, line item 3"처럼요. 재무와 IT가 나중에 불일치를 겪을 때 신속히 해결할 수 있습니다.

예: 디자인 도구에 활성 시트가 15개로 보이는데 그중 절반은 마지막 활동이 비어 있다면, 증빙에 "관리자 콘솔이 마지막 로그인 노출을 하지 않음"이라고 적혀 있으면 그 간극이 문제의 원인임을 알 수 있습니다. 그러면 다음 결정이 명확해집니다: SSO 로그에서 신호를 뽑을지, 수동 검토 단계를 유지할지.

AppMaster에서 구축한다면 이 필드를 단순한 테이블로 모델링하는 것부터 시작하세요. 기본이 정확해진 뒤 자동화를 추가하세요.

데이터 출처와 신뢰성 유지 방법

트래커는 그 안에 들어가는 데이터만큼만 좋습니다. 대부분의 팀은 네 가지 출처를 끌어오며, 각 출처는 다른 질문에 답합니다: 누가 여기서 일하는가, 누가 로그인할 수 있는가, 누가 시트에 할당되었는가, 우리가 무엇을 지불하고 있는가.

일반적인 출처는 HR(직원 명단과 입사/퇴사일), SSO/IdP(로그인 가능한 계정), 벤더 관리자 콘솔(시트 할당과 역할), 인보이스 또는 계약 기록(갱신일, 수량, 가격)입니다. 핵심은 일관성입니다: 같은 필드에 대해 출처를 섞지 마세요.

깨끗한 기준선은 보통 다음과 같습니다:

• 인물과 고용 상태: HR 명부
• 이메일/로그인 신원: SSO/IdP
• 시트 할당과 플랜 레벨: 벤더 관리자 콘솔
• 비용, 계약 기간, 갱신일: 인보이스나 계약 기록
• 팀 소유권: 선택한 조직 규칙(부서, 비용 센터, 또는 매니저 등)

현실과 맞는 업데이트 주기를 설정하세요. 시트 할당은 빠르게 변하므로 주간 업데이트가 보통 충분합니다. 비용과 계약은 덜 자주 변하니 월간 확인으로도 괜찮습니다. 한 번만 갱신할 수 있다면 온보딩과 오프보딩 직후에 하세요.

팀 매핑은 트래커가 부패하기 쉬운 지점입니다. 재조직을 견딜 수 있는 규칙(예: "팀 = 비용 센터" 혹은 "팀 = 직속 매니저")을 선택하여 문서화하고 일관되게 적용하세요.

마지막으로 기본적인 신뢰성 체크 하나를 추가하세요: HR에서 퇴사 처리된 사람이 SSO나 벤더 콘솔에서 여전히 활성으로 나오면 검토 대상으로 표시하세요. 이 한 규칙만으로도 많은 잘못된 데이터를 갱신 전에 잡을 수 있습니다.

단계별: 시트 트래커 기초 만들기

트래커는 지루하고 일관되게 시작할 때 가장 효과적입니다. 목표는 세 가지 질문에 빠르게 답할 수 있는 단일 장소를 만드는 것입니다: 누가 시트를 가지고 있는가, 어떤 앱인지, 다음 금전적 결정은 언제인가.

1) 두 개의 간단한 테이블 만들기

Apps 테이블(도구별로 한 행)과 Seats 테이블(할당된 각 시트별로 한 행, 보통 사용자당 앱별 한 행)을 만드세요. 사람이 팀을 바꾸거나 이메일이 바뀌어도 깔끔하게 유지됩니다.

Apps에는 중복시키고 싶지 않은 사실들(벤더, 플랜, 청구 주기, 갱신일, 비용 메모)을 집중시키고, Seats는 할당 정보(사용자, 팀, 역할/티어, 할당일, 사용 신호)를 중심으로 하세요.

2) 상태를 처음부터 표준화하세요

상태는 나중에 논쟁을 막아줍니다. 의미가 명확한 소수의 상태를 사용하세요:

• Active: 비용이 발생하는 시트, 해당 사람이 필요함
• Inactive: 최근 사용하지 않아 검토 필요
• Pending removal: 소유자가 제거를 승인했으나 시점 대기 중
• Removed: 시트 회수됨, 날짜 기록

3) 행동을 촉발하는 갱신 및 트루업 필드 추가

각 앱에 대해 갱신일, 통지 기간(예: 30일), 그리고 이름이 적힌 갱신 책임자(사람 이름, "IT" 같은 일반 명칭이 아님)를 추적하세요. 트루업이 적용된다면 트루업 날짜와 과금 기준에 대한 메모를 추가하세요.

4) 실제로 쓸 세 가지 뷰 만들기

실제 업무에 맞는 뷰를 만드세요: 팀별(매니저용), 앱별(IT/재무용), 다가오는 갱신(통지 창 기준으로 정렬).

예: 영업이 CRM 좌석 25개를 보유하고 있다면 팀별 뷰는 즉시 어떤 좌석이 Inactive인지, 갱신 통지 기간에 들어왔는지 보여줘야 합니다. 이것이 신뢰받는 보고의 기초입니다.

이것을 스프레드시트 대신 내부 도구로 운영하고 싶다면 AppMaster가 이러한 테이블과 뷰를 간단한 웹 앱으로 전환해주고, 폼과 승인 흐름을 추가하며 프로세스가 바뀔 때 확장할 수 있습니다.

워크플로를 깨지 않고 미사용 시트를 찾는 방법

"미사용"은 정의하기 전에는 단순해 보이지만 실제로는 복잡합니다. 사람이 휴가 중이거나 역할이 바뀌었거나 월말에만 로그인하는 경우에도 시트가 유휴로 보일 수 있습니다. 도구별로 명확한 신호를 사용해 필요한 접근을 실수로 제거하지 마세요.

도구에 맞게 “미사용”을 정의하세요

신뢰할 수 있게 측정 가능한 신호 1~2개로 시작하세요: 마지막 로그인 날짜, 마지막 의미 있는 활동(티켓 생성, 리포트 실행, 코드 푸시 등), 또는 사용자가 여전히 활성 프로젝트에 접근 가능한지 여부 등.

실무에서 쓸 수 있는 첫 정의는 "60일 동안 로그인 없음, 90일 동안 의미 있는 활동 없음"입니다. 간단하게 시작하고 오탐이 많으면 조정하세요.

빠른 기준을 원하면 다음을 출발점으로 삼으세요:

• 30일: 일일 사용 도구(채팅, 지원 인박스)
• 60일: 주간 사용 도구(디자인, 분석)
• 90일: 가끔 사용하는 도구(재무, 컴플라이언스)
• 장기: 계절적 또는 분기별 시스템

검토 큐로 안전하게 접근 제거하기

자동 제거 대신 검토 큐를 만들고 매니저가 확인하도록 하세요. 워크플로를 보호하고 "누가 내 계정을 잠궜나?"라는 불만을 피할 수 있습니다.

경량 프로세스 예시는 다음과 같습니다:

• 기준에 따라 후보자를 표시
• 간단한 사유(예: 90일 동안 로그인 없음)와 함께 매니저에게 알림
• 세 가지 선택지 제공: 유지, 다운그레이드, 회수
• 기한 설정(5~10 영업일)
• 최종 결정과 날짜 기록

비즈니스에 중요한 한 가지 지표를 추적하세요: 회수한 시트 수와 추정 월간 절감액. 작은 숫자라도 작업의 가치를 증명하는 데 도움이 됩니다.

AppMaster로 내부 툴을 만든다면 큐와 승인 기능을 같은 화면에 두어 결정이 빠르고 감사를 남기기 쉽게 하세요.

실제로 놀라움을 막는 갱신 및 트루업 알림

갱신 경고가 늦게 오면 놀라움이 발생합니다. 갱신 일주일 전에 달력 알림이 오면 사용량을 검토하고 승인을 받고 조달을 완료할 시간이 충분하지 않습니다.

실제 리드 타임에 맞는 알림 단계(ladder)를 설정하세요:

• 90일: 책임자, 계약 조건, 통지 기간 확인
• 60일: 시트 사용량 검토 및 플랜 결정(감소, 유지, 증가)
• 30일: 목표 좌석 수 확정 및 조달 서류 시작
• 14일: 변경 사항 적용 확인 및 갱신 준비 완료

날짜를 정하기 전에 계약서를 읽으세요. 취소나 다운그레이드에 30일 통지 기간이 있다면 30일 알림은 이미 늦은 셈입니다. 조달에 2~3주가 걸린다면 그 시간을 마감일에 포함하세요.

트루업에도 별도의 체크포인트가 필요합니다. 계약 중간(계약 기간의 절반 지점)에 한 번, 갱신 30일 전에도 한 번 추가해 느린 시트 증가를 잡으세요.

모든 알림은 행동으로 이어져야 합니다. 유용한 알림에는 책임자, 플랜, 수량(구매 vs 배정 vs 활성), 통지 기한, 그리고 "12좌석 회수"나 "견적 요청" 같은 명확한 다음 단계가 포함되어야 합니다.

AppMaster로 구축하면 단일 기록 업데이트에서 알림을 트리거해 항상 최신 수치와 다음 행동을 전달할 수 있습니다.

흔한 실수와 함정

대부분의 시트 추적 실패는 데이터 부족 때문이 아니라 습관에서 옵니다. 습관이 쌓여 숫자가 청구서와 맞지 않게 됩니다.

가장 큰 문제는 소유권이 불명확한 것입니다. SaaS 도구에 소유자가 없으면 시트 요청, 오프보딩, 갱신에서 아무도 마무리하지 않습니다. 각 앱에 대해 주요 책임자와 백업을 지정하세요. 조달이 비용을 지불하더라도 책임자가 필요합니다.

또 다른 함정은 잘못된 단위를 추적하는 것입니다. 어떤 도구는 초대된 사용자(invites)를 기준으로 과금하고, 어떤 도구는 활성 사용자를 기준으로 하며, 또 어떤 도구는 사용 여부와 관계없이 유료 시트로 과금합니다. 트래커가 초대를 따르는데 재무는 청구 대상이 되는 시트를 기준으로 지불하면 잘못된 문제를 쫓게 됩니다.

오프보딩도 공유 계정이나 서비스 사용자를 확인하지 않고 시트를 제거하면 역효과가 납니다: support@ 같은 메일박스, API 사용자, 챗봇 계정, 키오스크 로그인 등이 피해를 볼 수 있습니다. 이런 경우 긴급하게 다시 활성화해야 할 수 있습니다.

갱신은 예방 가능한 놀라움이 발생하는 지점입니다. 팀이 통지 기간과 자동 갱신 조항을 놓치면 30~90일 전에 취소나 감소를 해야 했던 걸 너무 늦게 알아차립니다. 통지 마감일을 갱신일뿐 아니라 트래커에도 넣으세요.

데이터 위생 함정

팀 이름 표기가 조금 달라지는 건 사소해 보이나 보고를 망칩니다. "Sales", "Sales Ops", "Revenue"가 같은 그룹일 수도 있고 다른 세 그룹일 수도 있습니다. 이름 규칙을 정하고 지키세요.

드리프트를 줄이려면 몇몇 필드를 표준화하고 자유 형식 텍스트를 제한하세요:

• 앱 소유자(주 담당자와 백업)
• 청구 단위(청구 대상 시트 vs 활성 사용자 vs 초대)
• 시트 유형(유료, 무료, 서비스)
• 팀 이름(고정 목록에서 선택)
• 통지 마감일(갱신일만 적지 말 것)

예: 회사가 갱신 전에 비활성 시트 15개를 제거했는데 그중 5개가 자동화에 연결된 서비스 사용자였다면 문제가 됩니다. AppMaster로 트래커를 구축하면 "service user" 체크박스와 간단한 이유 필드를 필수로 만들어 제거 전에 빠른 검토를 강제할 수 있습니다.

간단한 월간 체크리스트

트래커는 정기적으로 확인해야 효과가 있습니다. 간단한 월간 검토는 갱신의 놀라움을 줄이고, 소리 없이 새어나가는 비용을 줄이며, 트루업을 덜 스트레스 받게 만듭니다.

매달 같은 날에 같은 순서로 점검하세요. 변경 사항과 누가 제거나 이동을 승인해야 하는지 짧게 메모하세요.

15분짜리 월간 검토

• 다음 60~90일 내 갱신을 스캔하고 책임자, 갱신일, 통지 마감일, 현재 좌석 가격을 확인하세요.
• 사용량이 임계값 이하인 앱을 표시하고 해당 사용자가 여전히 접근이 필요한지 확인하세요.
• 지난달 채용된 사람들을 검토하여 각 사람을 팀과 매니저에 매핑했는지 확인하세요.
• 퇴사한 직원의 시트를 재할당하거나 제거하고 공유 메일박스나 서비스 계정을 다시 확인하세요.
• 할당된 시트와 계약 상 한도(캡)를 비교하여 트루업 위험을 조기에 발견하세요.

그 다음에는 "알 수 없는 항목"에 대해 한 번 빠르게 점검하세요: 일반 사용자명, 중복, 이메일 별칭 등. 이런 작은 문제들이 나중에 청구 분쟁으로 번질 수 있습니다.

트래커가 여전히 스프레드시트라 해도 이 루틴은 유용합니다. 자동화할 준비가 되면 AppMaster를 사용해 좌석과 갱신을 데이터베이스에 저장하고 소유권을 정리하며 알림과 승인을 자동화할 수 있습니다.

예시: 분기별 갱신 전 시트 정리

직원 120명 규모 회사가 채팅, 화상회의, CRM, 지원 데스크, 분석, 디자인 소프트웨어, HR 시스템, 패스워드 관리자 등 8개의 핵심 SaaS 도구를 사용한다고 가정해 보세요. 대부분은 분기별 갱신이며 좌석은 팀 확장에 따라 즉흥적으로 추가되었습니다.

다음 갱신 2주 전에 운영팀이 트래커에서 빠르게 점검합니다. 목표는 완벽이 아니라 아무도 사용하지 않는 시트를 지불하지 않도록 하고 트루업의 놀라움을 피하는 것입니다.

지원 데스크 도구의 검토 사이클은 다음과 같습니다:

• 사용자, 팀, 역할, 마지막 로그인, 티어별로 시트 목록을 추출
• 사용하지 않을 가능성이 높은 시트(예: 45일 동안 로그인 없음 또는 초대만 되고 활성화 안 됨)를 표시
• 팀 리드에게 빠른 확인 요청: 누가 여전히 접근이 필요한가, 누가 역할이 바뀌었는가, 누가 떠났는가
• 확인 후 시트를 제거하거나 다운그레이드하고 남은 시트마다 소유자를 문서화
• 갱신 21일 전과 7일 전에 예상 좌석 수와 미해결 질문을 포함한 알림 설정

검토 중 계약 조항에서 계획을 바꿀 요소를 발견할 수도 있습니다: 예를 들어 연간 최소 수량이 있지만 청구는 분기별로 이뤄지는 경우입니다. 현재 최소 수량보다 10좌석 초과 상태이고 다음 달에 지원팀에 18명 합류 예정이라면 트루업 위험이 있습니다.

조기에 발견했기 때문에 해결은 차분합니다. 신규 시트 지급을 48시간 중지하고 팀을 옮긴 사람들로부터 미사용 시트 14개를 회수한 뒤 신규 인원을 위해 6좌석 버퍼를 사전 승인했습니다. 갱신은 더 적은 유료 좌석으로 진행되었고 다음 달 계획도 명확해졌습니다.

결과: 14좌석 회수, 모든 활성 시트에 대한 소유권 명확화, 스트레스 대신 예측 가능한 갱신.

다음 단계: 작게 시작하고 자동화로 확장하세요

가장 비용이 높거나 사용자가 많은 상위 5개 도구부터 시작하세요. 한 달 동안 매주 추적하면 큰 프로젝트로 만들지 않고도 빠른 성과를 얻을 수 있습니다.

유지할 수 있는 루틴:

• 상위 5개 도구의 모든 시트를 사용자 기준(또는 팀 기준)으로 나열
• 도구별 책임자 한 명 지정(변경 승인 권한 있는 사람)
• 첫 알림 창을 갱신 또는 트루업 90일 전으로 설정
• "비활성" 정의(예: 30~60일 로그인 없음) 정하기
• 주 1회 검토 및 조치(10~15분)

대부분 팀이 건너뛰는 부분은 소유권입니다. 누군가 도구를 소유하지 않으면 시트가 쌓일 때 책임지를 사람이 없습니다. 도구 옆에 책임자 이름을 적고 알림이 울릴 때 무엇을 해야 하는지 명확히 하세요.

시트를 제거하기 전에 승인 경로를 합의해 워크플로를 깨지 마세요. 가벼운 규칙이면 충분합니다: 팀 도구는 매니저 승인, 회사 전체 도구는 앱 소유자 승인, 명확한 경우 사용자 본인 확인 등.

스프레드시트를 넘어서고 싶을 때 AppMaster (appmaster.io)는 이를 프로덕션용 내부 앱으로 전환하는 옵션이 될 수 있습니다. 실제 데이터베이스, 역할 기반 접근, 자동 알림 및 승인 기능을 제공해 사람들 쫓아다니지 않고도 프로세스를 유지할 수 있습니다.