고객사가 상위 요금제로 업그레이드했습니다. 결제는 성공했는데 분석 기능이 열리지 않습니다. 반대로 계약이 종료됐는데 일부 사용자는 계속 고급 기능을 쓰고 있습니다. 화면 버튼만 요금제에 따라 숨긴 구조라면 이런 불일치가 생기기 쉽습니다. ‘이 고객사가 이 기능을 이용할 수 있는가’와 ‘이 사용자가 이 작업을 할 수 있는가’는 다른 질문입니다.
구독 상태를 기능 접근의 유일한 근거로 쓰지 않는다
구독은 가격, 갱신, 결제 주기와 관련됩니다. 기능 이용권(entitlement)은 조직이 사용할 수 있는 제품 기능의 집합입니다. 사용자 권한은 그 조직 안의 특정 사람이 조회·수정·승인 같은 작업을 할 수 있는지 결정합니다. 예를 들어 회사가 ‘보고서 내보내기’를 구매했어도 일반 직원에게는 내보내기 권한을 주지 않을 수 있습니다. 이 세 상태를 하나의 Boolean 값으로 합치면 정책 변화에 취약합니다.
Stripe의 Entitlements 문서는 고객에게 제품 기능 접근을 언제 부여·회수할지 별도 개념으로 설명합니다. 결제 제공자를 무엇으로 쓰든 제품 내부에는 조직 ID, 기능 코드, 적용 시작·종료, 결정 근거를 표현할 수 있어야 합니다. 요금제 이름을 코드 곳곳에서 비교하는 대신 ‘현재 이 조직에 허용된 기능’으로 판단하는 방식입니다.
기능 코드는 제품 계약처럼 관리한다
‘고급 요금제’라는 이름은 바뀔 수 있지만 ‘보고서 내보내기’라는 제품 기능은 상대적으로 안정적입니다. 기능 코드를 명확하게 정의하고, 요금제·계약·프로모션이 어떤 기능 코드를 부여하는지 매핑합니다. 예외 계약이 생기더라도 if 문을 테넌트별로 늘리지 않고 한 곳에서 확인할 수 있습니다. 다만 기능 코드가 너무 세분화되면 운영이 어려우므로 고객이 이해하는 단위로 나눕니다.
기능 이용권의 원본은 어디인지도 정해야 합니다. 결제 시스템에서 상태가 바뀐 뒤 제품 DB에 반영되는 동안 잠시 차이가 날 수 있습니다. 이벤트 하나를 놓쳤을 때를 위해 주기적 대사와 수동 재동기화 경로를 준비합니다. 이벤트가 중복 도착해도 같은 결과가 나와야 하고, 뒤늦은 오래된 이벤트가 최신 상태를 덮지 않게 버전이나 유효 시각을 확인합니다.
화면과 서버가 같은 판정을 해야 한다
화면에서 버튼을 숨기는 것은 안내일 뿐 보안 경계가 아닙니다. API는 요청마다 조직의 기능 이용권과 사용자의 역할을 확인해야 합니다. 읽기와 쓰기, 설정 변경과 데이터 조회도 분리할 수 있습니다. 두 조건 중 하나가 없으면 적절한 이유를 알려줘야 합니다. ‘요금제에서 제공하지 않음’은 업그레이드 안내가 될 수 있지만, ‘조직에는 있으나 개인 권한 없음’은 조직 관리자에게 요청하도록 안내하는 편이 맞습니다.
한 사용자가 여러 조직에 속해 있다면 현재 조직의 이용권을 기준으로 판단합니다. 이전 조직의 캐시된 권한을 재사용하면 정보가 새거나 유료 기능이 잘못 열릴 수 있습니다. 캐시를 쓴다면 조직·사용자·기능·권한 변경 버전을 키에 포함하고, 변경 후 갱신 시점을 정의해야 합니다.
하향·종료 때는 데이터 정책을 먼저 합의한다
요금제를 낮출 때 기존 보고서를 삭제할지, 읽기만 허용할지, 새 생성만 막을지 정해야 합니다. 일반적으로 데이터 소유권과 기능 접근은 별개의 문제이므로 무작정 데이터를 지우지 않습니다. 결제 실패, 유예 기간, 계약 종료, 관리자의 수동 중지 상태도 명확히 구분해야 고객에게 설명할 수 있습니다. 이 정책은 계약·제품·개발팀이 함께 합의하는 영역입니다.
운영자는 ‘왜 이 조직이 이 기능을 사용할 수 있는가’를 추적할 수 있어야 합니다. 요금제, 적용된 예외, 마지막 동기화 시각, 권한 변경 이력을 보여주면 고객 지원이 빨라집니다. 결제 성공 여부만 보는 화면으로는 접근 불일치의 원인을 찾기 어렵습니다.
검증할 때는 신규 가입, 갱신, 업그레이드, 하향, 결제 실패, 계약 종료를 각각 별도 시나리오로 둡니다. 같은 상황에서 조직 관리자와 일반 사용자가 보는 화면도 비교합니다. 특히 ‘상위 요금제로 결제했지만 개인 권한은 없는 사람’과 ‘개인 역할은 맞지만 조직의 기능 이용권이 없는 사람’을 혼동하지 않아야 합니다. 고객 지원 안내 문구도 이 구분을 따라야 합니다.
설계 체크리스트
- 구독·조직 기능 이용권·사용자 역할을 구분하는가?
- 화면뿐 아니라 API에서도 두 접근 조건을 확인하는가?
- 결제 상태 변경의 중복·지연·누락에 대응하는가?
- 요금제 하향 시 기존 데이터의 이용 범위가 정해져 있는가?
- 고객 지원자가 접근 결정의 이유를 추적할 수 있는가?
#SaaS구독 #Entitlement #기능이용권 #사용자권한 #요금제변경 #B2BSaaS #결제연동 #접근제어 #구독상태 #권한설계
