SaaS 서비스 운영 중 아찔한 제보가 들어옵니다. "A사 관리자 화면에서 B사 데이터가 보여요." 한편 신규 고객사 온보딩은 수동이라 3일이 걸리고, 해지한 고객의 계정이 아직 살아 있습니다. "Enterprise 플랜 기능을 Basic 고객이 쓰고 있다"는 버그도 있습니다. PM·인프라인 당신은 멀티테넌트·권한 용어를 알아야 이 문제들의 심각도와 방향을 판단합니다. 이 사전은 SaaS·멀티테넌트·권한 용어를 빠르게 해독합니다.
- 1멀티테넌트의 데이터 격리 과제와 방식을 설명할 수 있다
- 2RBAC·ABAC·권한 모델로 접근 제어를 구분할 수 있다
- 3프로비저닝·디프로비저닝으로 테넌트/계정 생명주기를 이해할 수 있다
- 4기능 플래그·화이트라벨로 테넌트별 차등 제공을 설명할 수 있다
테넌트 · 격리
여럿이 공유하되 서로 안 보이게
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Tenant / Multi-Tenant / Single Tenant | 고객사 단위 / 공유 / 전용 | 격리가 핵심 | ★★★ |
| Tenant Isolation / Data Isolation | 테넌트/데이터 격리 | 실패=보안사고 | ★★★ |
| Company ID / Member ID / User ID | 회사/회원/사용자 식별 | 쿼리에 tenant 조건 강제 | ★★★ |
| Organization / Account Sync / Department Code / Mapping Table | 조직 동기화·매핑 | 외부 조직 연동 | ★★ |
| Provisioning / Deprovisioning | 생성 / 정리 | 온보딩·해지 자동화 | ★★ |
| Tenant Config | 테넌트별 설정 | 커스터마이징 | ★★ |
핵심: 멀티테넌트의 1순위 위험은 격리 실패(A사가 B사 데이터를 봄)입니다. 모든 쿼리에 tenant_id 조건을 강제하거나 스키마/DB 분리로 격리합니다. 격리 누락은 단순 버그가 아니라 치명적 보안 사고입니다([[db-security-basics]]).
권한 — 인증·인가·모델
누구인지, 무엇을 할 수 있는지
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Authentication / Authorization | 인증(누구) / 인가(권한) | 401 vs 403 → [[glossary-api-auth]] | ★★★ |
| Role / Permission | 역할 / 권한 | RBAC의 기본 | ★★ |
| RBAC / ABAC | 역할기반 / 속성기반 접근제어 | RBAC로 시작 | ★★ |
| Admin Role / Super Admin | 관리자 / 최상위관리자 | 권한 분리 → [[db-security-basics]] | ★★ |
| Access Control | 접근 제어 | 최소권한 원칙 | ★★ |
핵심: 인증(Authentication)은 '누구인지', 인가(Authorization)는 '무엇을 할 수 있는지'입니다 — 401(미인증)과 403(권한없음)의 구분과 같습니다([[glossary-api-auth]]). RBAC으로 역할에 권한을 묶고, 최소 권한 원칙(필요한 것만)을 지킵니다.
차등 제공 — 플래그·화이트라벨
테넌트·플랜마다 다르게
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Feature Flag / Config Flag / Option Flag | 기능 / 설정 / 옵션 토글 | 플랜별 차등 → [[release-strategy]] | ★★ |
| White Label / Customizing | 고객 브랜드로 제공 / 맞춤 | 테넌트별 UI | ★★ |
| Standard Feature / Custom Menu | 표준 기능 / 맞춤 메뉴 | 공통 vs 개별 | ★ |
핵심: 기능 플래그로 플랜(Basic/Pro/Enterprise)·테넌트별 기능을 켜고 끕니다([[release-strategy]]). "Basic 고객이 Enterprise 기능 사용" 버그는 보통 플래그/권한 체크 누락 — 플래그 평가에 테넌트 플랜이 반영되는지 확인합니다.
격리·권한 점검 — 직접 확인
SaaS의 가장 위험한 두 가지 — 격리와 권한 — 를 점검합니다.
1) 데이터 격리: 모든 조회 쿼리에 tenant_id(회사) 조건이 있나?
→ 한 곳이라도 빠지면 타 테넌트 데이터 노출 위험
2) 권한 체크: 화면/API마다 역할(RBAC) 검증이 있나?
→ URL 직접 호출로 권한 우회 가능한지(서버측 검증 필수)
3) 기능 플래그: 플랜별 기능이 테넌트 플랜으로 평가되나?
→ Basic이 Pro 기능 못 쓰는지
점검 결과 예:
주문 조회 쿼리에 tenant_id 조건 누락 1건 → 즉시 수정(격리 사고 직전)
관리자 API가 클라이언트 측만 권한 체크 → URL 직접 호출로 우회 가능
Enterprise 기능 플래그가 플랜 무시하고 ON → Basic도 사용 중
→ 격리·서버측 권한·플래그 평가 모두 보강 필요
echo '쿼리 tenant 조건 + 권한 매트릭스 + 플래그 평가 확인'- 모든 데이터 조회에 tenant_id(회사) 조건이 강제되는지 — 한 쿼리라도 빠지면 타 테넌트 노출. 격리는 "기본값으로 막고 예외만 열기"
- 권한 체크가 클라이언트(화면)에만 있고 서버에 없으면 URL 직접 호출로 우회 가능 → 인가는 반드시 서버측에서([[db-security-basics]])
- 기능 플래그가 테넌트 플랜을 반영하는지 — "Basic이 Pro 기능 사용"은 플래그 평가에 플랜 누락 신호([[release-strategy]])
- 해지(디프로비저닝) 후에도 계정·토큰이 살아 있으면 보안 위험 → 해지 시 접근 즉시 차단·정리되는지 확인
상황: 새 기능의 조회 쿼리 하나에 WHERE tenant_id = ? 조건을 빠뜨려, A사 사용자에게 B사 데이터가 보이는 심각한 격리 사고가 발생합니다.
원인: 테넌트 격리를 개별 쿼리에 수동 의존했습니다. 모든 쿼리에 일일이 tenant 조건을 넣다 보면 한 곳은 반드시 빠집니다 — 사람이 매번 기억해야 하는 구조 자체가 위험합니다.
진단:
# tenant_id 조건 없는 조회 쿼리 흔적(코드 스캔)
grep -rnE "SELECT .* FROM (orders|users|documents)" src/ | grep -vi "tenant"
해결: (1) 즉시 누락 쿼리 수정 + 영향 범위(누가 무엇을 봤나) 조사·공지. (2) 구조적 방어 — ORM/프레임워크 레벨에서 tenant 조건을 자동 주입(전역 필터·RLS Row-Level Security)해 '깜빡해도 안전'하게. PostgreSQL RLS나 ORM 글로벌 스코프가 대표적. (3) 격리 테스트를 CI에 추가([[test-strategy]]) — "A 토큰으로 B 데이터 조회 시 0건"을 자동 검증. 멀티테넌트 격리는 사람의 주의가 아니라 시스템으로 보장해야 합니다([[db-security-basics]]).
인프라/플랫폼으로서 멀티테넌트 격리는 아키텍처 결정입니다 — Row-Level Security·스키마 분리·전역 필터로 '구조적 격리'를 설계하고([[db-security-basics]]), 프로비저닝/디프로비저닝을 자동화합니다. PM은 격리 실패가 '버그'가 아니라 '치명적 보안 사고'임을 인지하고, 요구사항([[requirements-prd]])에 테넌트 격리·권한·플랜별 기능을 인수 기준으로 명시합니다. SaaS에서 신뢰의 근간은 "내 데이터가 남에게 안 보인다"이며, 이는 한 줄의 쿼리 누락으로도 무너지므로 시스템적 방어가 필수입니다.
다음 용어사전에서는 문서·전자서명 서비스 도메인 용어를 정리합니다.