고객 티어 권한 모델: 플랜, 한도, 플래그

팀에 권한 모델이 필요한 이유

여러 티어를 판매하면 결국 같은 서포트 티켓을 받게 됩니다: “고객 X가 Pro를 결제했는데 기능 Y에 접근할 수 없습니다.” 명확한 시스템이 없으면 서포트는 직접 고칠 수 없습니다. 단순한 접근 변경이 엔지니어링 작업으로 바뀝니다.

더 큰 문제는 일관성 결여입니다. 접근 규칙이 제품 전반에 흩어집니다: 관리자 화면의 체크박스, API의 하드코딩 검사, 스프레드시트의 메모, 지난 분기에 적용한 일회성 DB 업데이트 등. 고객은 곳곳에서 다른 동작을 보고, 어떤 규칙이 진짜인지 아무도 확신하지 못합니다.

권한 모델은 플랜과 승인된 예외에 기반해 누가 무엇을 할 수 있는지에 대한 단일 출처의 진실을 제공합니다. 티어를 예측 가능하게 유지해(그래서 가격이 신뢰받을 수 있게) 현실적인 상황도 허용합니다: 임시 업그레이드, 쿼터 상향, 특정 계정에 대한 파일럿 기능 등.

“엔지니어링 없이 조정”은 구체적이어야 합니다. 실제로는 다음과 같습니다:

• 서포트는 배포를 요청하지 않고 관리 도구에서 데이터를 편집해 접근을 변경합니다.
• 제품의 모든 부분(백엔드, 웹앱, 모바일)은 동일한 권한 데이터를 읽습니다.
• 예외는 시간 제한이 있고 되돌릴 수 있으며 영구적인 해킹이 아닙니다.
• 변경 사항은 누가, 언제, 왜 했는지 기록됩니다.

예를 들어, 비즈니스 티어의 고객이 바쁜 시즌에 활성 사용자 수 한도에 걸렸다면 서포트는 14일 동안 좌석을 10석 추가로 부여할 수 있어야 하며, 시스템은 기간이 끝나면 자동으로 되돌려야 합니다. 엔지니어링이 관여하는 경우는 완전히 새로운 기능을 추가할 때로 한정되어야 합니다.

기본 구성 요소: 고객, 플랜, 권한

좋은 권한 모델은 몇 가지 명확한 객체와 명확한 소유권으로 시작합니다. 이 기본이 모호하면 서포트는 매주 엔지니어링에 “한 가지 예외만” 요청하게 됩니다.

간단한 빌딩 블록은 다음과 같습니다:

• Customer (account/tenant): 제품을 사용하는 회사나 개인.
• Subscription: 상업적 관계(체험, 활성, 취소)로 보통 결제 시스템과 연결됩니다.
• Plan: 기본 접근을 정의하는 명명된 티어(Free, Pro, Enterprise).
• Entitlement: 플랜과 오버라이드에서 도출된 실제 허용 행동.

권한 평가는 청구와 다릅니다. 청구는 “무엇을 언제 청구할지”에 답하고, 권한은 “이 고객이 지금 무엇을 할 수 있는가”에 답합니다. 고객이 미납이지만 유예 기간에 있을 수 있고, 완납이지만 컴플라이언스 때문에 일시 차단될 수 있습니다. 이 결정들을 분리해 재무가 송장을 고치더라도 제품 접근이 실수로 바뀌지 않도록 하세요.

여러 팀이 이 설정에 의존합니다:

• 제품팀은 플랜의 의미를 정의합니다.
• 서포트는 접근을 안전하게 부여하거나 제거할 수 있는 도구가 필요합니다.
• 세일즈 운영은 딜과 갱신에 대해 일관된 규칙이 필요합니다.
• 재무는 판매된 것과 제공된 접근 간의 신뢰할 수 있는 매핑이 필요합니다.

초기 경계를 정하세요. 플랜 내용과 고객 오버라이드는 구성 가능하게 두어(서포트가 행동할 수 있도록) 핵심 동작은 코드에 두세요. “핵심 동작” 예시는 남은 쿼터 계산 방식, 만료된 체험 처리, 감사가 필요한 액션들입니다.

플래그, 한도, 쿼터: 적절한 유형 선택하기

대부분의 티어링 문제는 권한에 제대로 이름을 붙이면 쉬워집니다. 세 가지 일반 타입이 있고 각각 다른 질문에 답합니다:

• Boolean flags: 켜져 있나 꺼져 있나? 예: export_enabled = true.
• Numeric limits: 한 번에 얼마가 허용되나? 예: max_seats = 10.
• Quotas: 시간 경과에 따라 얼마를 사용할 수 있나? 예: api_calls_per_month = 100000.

기능이 부분적으로 동작하면 안 되는 경우 플래그가 적합합니다. export가 꺼져 있으면 버튼을 숨기고 엔드포인트도 차단하세요. 한도는 좌석, 프로젝트, 저장된 뷰처럼 리셋되지 않는 용량에 적합합니다.

쿼터는 시간이 중요하기 때문에 추가 주의가 필요합니다. 리셋 규칙이 관리자 UI에 명확히 기록되어 있으면 서포트 티켓이 급감합니다.

범위(scope)도 혼란을 막는 또 다른 결정입니다. “SAML SSO enabled” 같은 플래그는 보통 계정 수준입니다. “Max projects”는 워크스페이스 수준일 수 있고, “Can run reports”는 역할 기반 애드온을 판매하면 사용자 수준일 수 있습니다.

쿼터의 경우 하나의 리셋 규칙을 선택하고 지키세요:

• Never (평생 크레딧)
• Monthly (달력월)
• Rolling window (최근 30일)
• Per billing period (청구 주기와 일치)

리셋 규칙이 플랜에 따라 달라진다면 그 규칙 자체를 권한의 일부로 취급하세요. 암묵적 지식으로 두지 마세요.

권한을 위한 실용적 DB 스키마

서포트 친화적 권한 모델은 보통 단순한 형태가 가장 잘 작동합니다: 몇 개의 테이블, 명확한 키, 감사 가능한 시간 기반 레코드. 목표는 관리자가 데이터를 편집해 접근을 바꿀 수 있게 하고 코드 배포가 필요하지 않게 하는 것입니다.

네 가지 핵심 테이블로 시작하세요: plans, plan_entitlements, customers, customer_overrides.

• Plans는 티어(Free, Pro, Enterprise)를 설명합니다.
• Plan entitlements는 각 플랜이 포함하는 항목을 설명합니다.
• Customers는 플랜을 가리킵니다.
• Overrides는 모든 사람에게 플랜을 바꾸지 않고 단일 고객에 대한 예외를 다룹니다.

잘 작동하는 간결한 관계형 구조 예시:

• plans: id, name, description, is_active
• plan_entitlements: id, plan_id, key, type, value, unit, reset_policy, effective_from, effective_to, created_by
• customers: id, name, plan_id, status, created_at
• customer_overrides: id, customer_id, key, type, value, unit, reset_policy, effective_from, effective_to, created_by

권한 필드는 테이블 간에 일관되어야 합니다. seats, api_calls, sso_enabled 같은 안정적인 key를 사용하세요. type은 평가를 단순하게 합니다(예: flag, limit, quota). unit을 명시적으로 저장하세요(예: users, requests, GB). 쿼터의 경우 reset_policy를 명확히(monthly, daily, never) 하세요.

오버라이드는 날짜가 있는 허용 목록(allowlist)처럼 동작해야 합니다. 고객에게 활성 오버라이드로 sso_enabled=true가 있으면 플랜 값보다 우선하며 effective_from과 effective_to 범위 내에서만 적용되어야 합니다. 이렇게 하면 “14일 동안 10석 추가”가 한 줄의 변경으로 자동 만료되는 것이 가능합니다.

권한 평가(Entitlement evaluation) 방식

권한 평가는 “이 고객이 지금 이걸 할 수 있나?”라는 질문에 답하는 작은 코드 조각(또는 서비스)입니다. 이 부분이 예측 가능하면 나머지 운영이 훨씬 쉬워집니다.

명확한 우선순위를 사용하고 벗어나지 마세요: 고객 오버라이드 \u003e 플랜 값 \u003e 시스템 기본값. 이렇게 하면 서포트가 플랜을 건드리지 않고 임시 예외를 부여할 수 있고, 아무것도 설정되지 않았을 때 엔지니어링은 안전한 기본값을 가질 수 있습니다.

실용적인 평가 흐름:

• 인증된 세션에서 고객/계정을 식별하세요(요청 본문에서 가져오지 마세요).
• 고객의 활성 플랜과 활성 오버라이드를 로드하세요.
• 주어진 키에 대해 오버라이드가 있으면 반환하고, 없으면 플랜 값을 반환하고, 그래도 없으면 시스템 기본값을 반환하세요.
• 키가 어디에도 없으면 접근 검사에서는 닫힌 실패(fail closed)로 처리하고(“허용되지 않음”), 표시용 UI에는 합리적 기본값을 사용하세요.
• 키가 등록되어 있지 않으면 구성 오류로 처리하고 닫힌 실패로 처리한 뒤 후속 조치를 위해 로깅하세요.

권한은 자주 확인되므로 캐싱이 중요합니다. 고객별로 해석된 권한을 짧은 TTL과 명시적 버전 번호로 캐시하세요. 다음이 변경될 때 무효화하세요: 플랜 할당, 플랜 정의, 고객 오버라이드, 고객 상태(체험, 유예, 차단). 간단한 패턴은 “customer_id + entitlements_version으로 캐시”하는 것입니다. 서포트 편집이 버전을 올리면 변경이 빠르게 반영됩니다.

멀티테넌시 안전성은 필수입니다. 모든 쿼리는 현재 고객/계정 id로 필터링되어야 하고, 모든 캐시 항목은 해당 id로 키되어야 합니다. 이메일, 도메인, 플랜 이름만으로 권한을 조회하지 마세요.

단계별: 서포트가 접근을 조정하기 쉬운 워크플로

서포트 친화적 워크플로는 모델을 유연하게 유지하되 모든 예외가 엔지니어링 문제로 바뀌지 않도록 합니다. 목표는 변경을 안전하게 수행하고 흔적을 남기며 고객 경험을 확인하는 것입니다.

안전한 서포트 흐름

먼저 올바른 고객 레코드를 찾고 그들이 무엇을 요청하는지, 왜 요청하는지 확인하세요. “일주일 동안 좌석 2개 더 필요”는 “우리가 상위 티어로 계약을 변경했다”와 다릅니다. 좋은 관리자 UI는 현재 플랜, 고객 상태, 활성 오버라이드를 한 화면에서 쉽게 볼 수 있게 해야 합니다.

무언가를 변경하기 전에 현재 사용량을 관련 한도나 쿼터와 비교해 확인하세요. 많은 요청은 계정이 실제로 한도에 도달하지 않았거나(예: 사용 추적이 업데이트되지 않음) 문제의 원인이 다른 곳임을 확인하면 사라집니다.

조정이 필요할 때는 플랜을 편집하기보다 명시적 오버라이드를 선호하세요. 오버라이드는 좁게(한 가지 플래그 또는 한도), 소유자와 이유를 포함하고 만료일을 기본으로 하세요. 임시 예외는 흔하고 잊기 쉽기 때문에 만료일을 필수로 두세요.

관리 도구 내의 간단한 체크리스트는 보통 충분합니다:

• 고객 신원, 현재 플랜, 요청 사유 확인.
• 관련 상한선 대비 현재 사용량 검토.
• 범위가 좁은 오버라이드를 적용하고 만료일 설정.
• 메모와 티켓/사례 참조 추가.
• 임시 계정이나 임프슨네이션으로 제품 UI에서 결과 확인.

항상 고객이 경험할 방식으로 변경을 검증하세요. 임프슨네이션 기능을 제공하면 활성화 여부를 명확히 표시하고 로깅하세요.

업그레이드, 다운그레이드, 체험, 유예 기간

대부분의 권한 문제는 변경 시에 발생합니다: 고객이 사이클 중간에 업그레이드하거나 카드 결제가 실패하거나 체험이 주말에 끝나는 경우 등. 규칙이 모호하면 서포트는 추측하게 되고 엔지니어링이 호출됩니다.

업그레이드는 단순하게 유지하세요: 접근은 보통 즉시 변경되고 금전 세부사항은 청구에 남깁니다. 권한 모델은 “플랜 변경” 같은 청구 이벤트를 듣고 새 플랜 권한을 즉시 적용해야 합니다. 청구가 정산(proration)을 처리한다면 좋지만, 권한에 정산 수학을 집어넣지 마세요.

다운그레이드는 놀라움이 생기기 쉬운 부분입니다. 명확한 다운그레이드 동작을 선택하고 서포트에게 보이게 하세요:

• 유예 기간(Grace): 유료 기간 종료까지 상위 접근 유지.
• 읽기 전용(Read-only): 데이터 조회/내보내기 허용하되 새 쓰기 차단.
• 즉시 차단(Hard stop): 기능을 즉시 차단(위험한 기능에 권장).
• 한도 초과 행동: 사용은 허용하지만 생성은 차단.
• 데이터 보존: 데이터는 보관하되 접근을 비활성화.

체험은 고객의 불리한 영향을 줄이려면 단순한 플랜으로 취급하는 것이 좋습니다. 체험 플랜에 명확한 플래그와 한도, 자동 만료 규칙을 두고 체험 종료 시 기본 플랜(보통 “Free”)으로 이동시키며 정의한 다운그레이드 동작을 적용하세요.

청구 실패에 대한 유예 기간도 유용합니다. 짧은 “연체” 창(예: 3~7일)은 결제를 수정할 시간을 주어 작업 중 접근을 잃지 않게 합니다. 유예 기간은 시간 기반 오버라이드로 처리하세요, 커스텀 플랜 이름으로 처리하지 마세요.

실용적인 팁: 권한을 마케팅 티어 이름(예: “Pro”, “Enterprise”)에 직접 묶지 마세요. 내부적으로 안정적인 플랜 ID(예: plan_basic_v2)를 사용해 티어 이름을 바꿔도 규칙이 깨지지 않게 하세요.

감사와 안전 통제

서포트가 엔지니어링 없이 접근을 바꿀 수 있다면 변경 흔적이 필요합니다. 좋은 권한 모델은 모든 변경을 기록된 결정으로 취급합니다.

모든 오버라이드에 대해 행위자(actor), 비즈니스 이유, 타임스탬프를 캡처하세요. 조직이 필요하면 민감한 변경에 승인 단계를 추가하세요.

변경 시 기록할 항목

기록은 실무에서 실제로 사용되도록 단순하게 유지하세요:

• created_by와 created_at
• approved_by와 approved_at(선택 사항)
• reason(짧은 텍스트, 예: “paid add-on” 또는 “incident credit”)
• previous_value와 new_value
• expires_at

안전 통제는 실수를 프로덕션에 도달하기 전에 막습니다. 관리자 UI와 DB에 가드레일을 두세요: 최대값 제한, 음수 값 차단, 큰 변경 시 만료일 요구(예: API 호출을 10배로 올릴 때) 등.

롤백 및 감사 준비

서포트는 실수를 합니다. 고객 수준 오버라이드를 지우고 할당된 플랜으로 계정을 되돌리는 단일 “플랜 기본값으로 되돌리기” 동작을 제공하세요.

감사를 위해 고객과 날짜 범위별로 기록을 내보내기 쉽게 하세요. 이유와 승인자를 포함한 기본 CSV 내보내기가 대부분의 질문에 답합니다.

예: Pro 고객이 일주일 행사로 30석을 추가로 필요로 하면 서포트는 seats_override=60과 expires_at을 다음 금요일로 설정하고 이유에 “event”를 적고 관리자 승인을 받습니다. 만료 후 시스템은 자동으로 30으로 돌아가며 청구 분쟁 시 필요한 전체 기록이 남습니다.

권한을 어렵게 만드는 흔한 실수들

권한 모델을 망치는 가장 빠른 방법은 의도치 않게 성장을 허용하는 것입니다. 초기의 몇 가지 편법은 수개월간의 서포트 티켓과 “왜 이 고객이 저 기능을 쓸 수 있지?”라는 소방전으로 이어집니다.

한 가지 흔한 문제는 기능 검사를 여러 곳에 흩트리는 것입니다. 앱의 다른 부분이 서로 다른 방식으로 접근을 결정하면 모순이 생깁니다. 권한 평가는 하나의 함수나 서비스로 중앙화하고 모든 UI와 API가 이를 사용하게 하세요.

또 다른 함정은 청구 상태를 접근과 섞어 버리는 것입니다. “유료”는 “허용됨”과 같지 않습니다. 청구에는 재시도, 환불, 체험, 나중에 정산되는 송장 등이 있습니다. 청구 이벤트를 명확한 규칙(유예 기간 포함)으로 권한으로 번역해 엣지 케이스가 사용자를 잠그거나 영구적으로 접근을 허용하지 않도록 하세요.

단일 티어 문자열(예: “basic”, “pro”)만을 진실의 원천으로 삼지 마세요. 티어는 시간이 지나며 변경되고 예외가 발생합니다. 명시적 플래그와 한도를 저장해 서포트가 한 기능만 부여해도 해당 티어의 모든 것을 실수로 부여하지 않게 하세요.

오버라이드는 필요하지만 가드레일 없는 무제한 오버라이드는 보이지 않는 부채가 됩니다. 소유자, 이유, 티켓 참조를 요구하세요. 만료일 또는 검토일을 권장하세요. 오버라이드는 좁게(한 키씩) 유지하고 감사를 쉽게 하세요.

쿼터는 리셋 규칙이 모호할 때도 잘못됩니다. “월별”이 달력월인지 롤링 30일인지, 업그레이드 시 어떻게 되는지, 사용하지 않은 쿼터가 이월되는지 등을 정의하세요. 이러한 규칙은 UI가 아니라 백엔드 로직으로 시행해 웹과 모바일 간 일관성을 유지하세요.

배포 전 빠른 체크리스트

권한 모델을 롤아웃하기 전에 매일 사용할 팀들(서포트, CS, 온콜 담당자)과 마지막 점검을 하세요.

각 기능이 하나의 안정적인 권한 키에 매핑되고 명확한 소유자가 있는지 확인하세요. reports_enabled와 reporting_enabled 같은 중복 키를 피하세요. 출시하는 키마다 플랜에 대한 명시적 기본값이 있는지 확인하세요. 키가 없으면 안전하게 실패(보통 접근 거부)하고 내부적으로 경고해 수정되도록 하세요.

운영 측면에서 워크플로가 실제로 사용 가능한지 확인하세요:

• 서포트는 SQL 없이도 유효 권한(플랜 기본값 + 오버라이드)을 볼 수 있어야 합니다.
• 오버라이드는 누가 언제 무엇을 변경했는지, 왜 했는지, 언제 만료되는지 기록됩니다.
• 쿼터는 가시적인 리셋 규칙과 현재 사용량을 보여주는 명확한 방법이 있어야 합니다.

현실 테스트: 서포트가 단일 고객에게 14일짜리 애드온을 부여한 뒤 제거하도록 해보세요. 2분 이내에 자신 있게 할 수 있다면 거의 완료된 것입니다.

예시 시나리오: 임시 예외가 있는 티어

세 가지 티어를 제공하고 각 티어가 백엔드에서 시행되는 몇 가지 명확한 권한을 설정한다고 상상해보세요.

• Free: 1개 프로젝트, 3명 사용자, 월 200회 내보내기, 기본 API 속도 제한, 7일 감사 로그.
• Team: 10개 프로젝트, 25명 사용자, 월 2,000회 내보내기, 더 높은 API 속도 제한, 30일 감사 로그.
• Business: 무제한 프로젝트, 200명 사용자, 월 10,000회 내보내기, 최고 API 속도 제한, 180일 감사 로그, SSO 활성화.

이제 Team 고객이 “이번 달에 8,000건의 내보내기를 해야 하는데 30일 동안 도와줄 수 있나요?”라고 요청한다고 합시다. 이럴 때 임시 오버라이드가 플랜 이동보다 낫습니다.

서포트는 고객 레코드를 열고 export_monthly_limit = 8000과 같은 오버라이드를 추가하고 expires_at을 오늘로부터 30일 후로 설정합니다. 메모에 “Alex(영업) 승인, 분기 보고용 30일 예외”라고 적습니다.

고객 입장에서는 두 가지가 일어나야 합니다:

• UI가 새 한도를 반영합니다(사용량 미터와 “남은 내보내기” 라벨이 업데이트됨).
• 월 8,000건에 도달할 때까지 내보내기가 계속 작동합니다.

초과하면 명확한 메시지가 보입니다: “내보내기 한도 도달(8,000/월). 지원에 문의하거나 업그레이드하세요.”

만료일 후에는 오버라이드가 자동으로 중지되고 고객은 아무도 수동으로 끄지 않아도 Team 플랜 한도로 되돌아갑니다.

다음 단계: 서포트를 늦추지 않고 구현하고 반복하세요

먼저 “기능”을 작은 권한 카탈로그로 전환하세요. 각 항목에 명확한 키, 타입(플래그 vs 한도 vs 쿼터), 플랜별 기본값을 부여하세요. 이 카탈로그는 제품, 서포트, 엔지니어링 간의 공통 언어가 되므로 이름을 구체적이고 안정적으로 유지하세요.

어디에서 강제할지 결정하세요. 안전한 규칙은: 데이터 변경이나 비용이 발생하는 모든 항목은 API에서 강제하고, 한도를 초과할 때 장기 작업을 중지하려면 백그라운드 작업을 사용하며, UI는 사용자 안내(비활성화된 버튼, 도움 메시지)로 처리하되 유일한 관문으로는 삼지 않는 것입니다.

첫 버전은 작게 유지하세요. 가장 많은 질문을 생성하는 권한에 집중하고, 위험이 큰 동작에 체크를 추가하고, 고객, 플랜, 오버라이드, 이력을 한 곳에 보여주는 관리자 뷰를 출시하세요.

핸드코딩 없이 관리자 패널과 기본 로직을 빠르게 만들고 싶다면 AppMaster (appmaster.io)가 이러한 작업에 실용적입니다: 플랜과 오버라이드를 데이터로 모델링하고, 비즈니스 프로세스로 검사를 구현하며, 백엔드와 앱 전반에서 일관된 서포트 UI를 배송할 수 있습니다.