멀티테넌트 회원·인증 설계 6편 – 우리 서비스에 정말 멀티테넌트가 필요한가?

🧬 개요

1~5편에서는 멀티테넌트 회원·인증 구조를 단계적으로 살펴봤다.

• 1편 – tenant / user / tenant_user 도메인 패턴
• 2편 – JWT + Redis 기반 인증 구조
• 3편 – 멀티테넌트 RBAC 설계
• 4편 – 여러 서비스가 입점하는 회원 플랫폼 적용기
• 5편 – B2B SaaS에서 테넌트 분리·스케일링 전략

이 시점에서 자연스럽게 떠오르는 질문이 하나 있다.

“지금 만들고 있는 이 서비스에, 정말 멀티테넌트까지 필요할까?”

이 글에서는:

• 멀티테넌시가 필수에 가까운 상황과
• 오히려 과한 설계가 되기 쉬운 상황을 나눠 보고,
• 도입 전 체크리스트와
• 구현 단계에서 피하고 싶은 안티패턴을 정리한다.

---

✨ TL;DR

• 멀티테넌시는 “멋진 설계”라기보다
  비즈니스 구조와 운영 방식을 반영한 선택지에 가깝다.
• 다음에 해당하면 멀티테넌트를 적극 고려할 만하다.
  • 여러 브랜드/서비스/고객사가 같은 회원·인증 시스템을 공유해야 할 때
  • 테넌트마다 가입 조건·약관·권한·요금제·트래픽 정책이 달라질 가능성이 클 때
  • 중장기적으로 B2B/B2B2C 플랫폼으로 확장할 가능성이 있을 때
• 반대로, 다음에 가깝다면 단일 테넌트로 출발해도 충분한 경우가 많다.
  • 하나의 서비스만 운영하고, 다른 서비스가 붙을 계획이 거의 없을 때
  • 팀 규모나 운영 여력이 멀티테넌시 복잡도를 감당하기 어려울 때
• 도입 시 자주 나오는 안티패턴:
  • tenant_id가 들어가야 할 테이블에 빠져 있는 경우
  • 테넌트별 예외를 if/else로만 처리하는 if (tenant == 'X') 코드 남발
  • 메뉴/권한/API 책임이 섞여 구조가 흐릿해지는 경우
  • 토큰/컨텍스트에 너무 많은 정보를 실어 넣어, 변경 여지를 막는 설계

---

1. 멀티테넌시가 “필수에 가까운 선택”이 되는 상황

아래 질문들 중 여러 개가 “그렇다”에 가깝다면,
처음부터 멀티테넌트를 전제로 설계하는 편이 오히려 단순해질 수 있다.

1.1 비즈니스 관점 질문

• 중장기적으로 여러 서비스/브랜드가
  같은 회원·인증 시스템을 공유할 가능성이 있는가?
• “고객”이 개인뿐 아니라
  • 학원, 교회, 회사, 프랜차이즈 지점, 파트너사 등
    조직 단위까지 포함되는가?
• 조직/서비스별로:
  • 가입 조건, 약관, 동의 항목,
  • 요금제, 사용량 제한(Quota),
  • 관리자/운영자/일반 사용자 역할
    이 달라질 수 있는가?

1.2 기술·운영 관점 질문

• 조직/서비스별로:
  • 트래픽/부하,
  • 데이터 용량,
  • SLA(가용성/성능),
  • 배치/정산 로직
    을 별도로 관리해야 할 가능성이 있는가?
• 시간이 지나면서,
  • 일부 테넌트는 매우 큰 B2B 고객이 되고,
  • 일부는 소규모 고객으로 남을 수 있는 구조인가?

이런 질문들에 “그럴 수 있다”가 많이 나온다면,

tenant를 1급 도메인으로 세우고
tenant / user / tenant_user 패턴으로 시작하는 쪽이
장기적인 유지보수 비용을 줄이는 방향이 될 수 있다.

---

2. 멀티테넌시가 “과한 설계”가 되기 쉬운 상황

반대로, 아래에 가깝다면
처음부터 멀티테넌트 풀옵션으로 가지 않아도 되는 경우가 많다.

2.1 서비스 스코프가 명확히 하나인 경우

• 앱/웹이 단일 커뮤니티/단일 조직만을 대상으로 한다.
• 다른 조직/고객사에 그대로 판매하거나 제공할 계획이 없다.

이런 경우에는:

• 우선 단일 테넌트 기준으로 도메인 모델을 깔끔하게 잡고,
• 정말 필요해졌을 때,
  • 로그인/권한/데이터 모델을 tenant 축으로 한 번 감싸는 리팩토링을 고려하는 선택지도 있다.

2.2 팀/운영 역량을 고려해야 하는 경우

멀티테넌시는 단순히 컬럼 하나를 더 넣는 문제가 아니라:

• 테스트 케이스가 테넌트 축으로 늘어나고,
• 로그/메트릭/대시보드에 항상 tenant_id가 붙고,
• 데이터 마이그레이션·정산·배치·모니터링이 모두 한 축 더 생긴다는 뜻이다.

초기 팀 규모가 1~2명 수준이면,
이 복잡도를 모두 감당하는 건 꽤 부담스러울 수 있다.

---

3. 멀티테넌트 도입 전 체크리스트

간단한 체크리스트 형태로 정리하면 다음과 같다.

3.1 단일 테넌트로 충분한지 확인

[ ] 현재 하나의 서비스만 존재한다.
[ ] 1~2년 안에 다른 브랜드/서비스가 붙을 가능성은 낮다.
[ ] 주요 고객은 거의 "개인 유저"이고, 조직 단위 고객은 없다.
[ ] 파트너사/입점사/기관 단위 제공 계획이 없다.
[ ] 요금제/사용량 정책이 "유저 개인" 기준으로만 정의된다.

위 항목에 대부분 체크가 된다면,
당장은 단일 테넌트 구조로 출발해도 무리가 아닌 경우가 많다.

3.2 멀티테넌시를 고려해야 할 신호들

[ ] 여러 서비스/앱이 하나의 회원 DB를 공유해야 한다.
[ ] 조직/교회/학원/고객사 단위로 가입과 운영을 관리해야 한다.
[ ] 테넌트별 관리자/운영자/일반 사용자 역할이 달라질 수 있다.
[ ] 특정 테넌트만 별도 인프라/요금제로 분리할 가능성이 있다.
[ ] 테넌트별 요금제/Rate Limit/배치 우선순위를 다르게 운영할 여지가 있다.
[ ] 로그/메트릭을 테넌트 단위로 보고 싶다.

이 쪽에 체크가 많다면,
도메인 설계 단계에서부터 tenant 축을 같이 가져가는 편이 자연스럽다.

---

4. 구현·아키텍처 안티패턴

멀티테넌시를 도입하면서 자주 보이는 안티패턴 몇 가지를 정리해 보면 다음과 같다.

4.1 tenant_id가 들어가야 할 곳에 없는 경우

user, order, payment처럼
테넌트에 명확히 종속되는 도메인인데도

• 단일 테넌트로 개발했다는 이유로
  tenant_id가 아예 없는 테이블이 남아 있는 경우가 있다.

이렇게 되면:

• 나중에 테넌트 구조가 필요해졌을 때

  • 데이터 마이그레이션이 어렵고,
  • “이 레코드가 어느 테넌트의 것인지”를 거꾸로 추론해야 한다.

• 일부 테이블만 tenant 기준, 일부는 아닌 상태로 섞이기 쉽다.

초기에 한 번은:

• “이 도메인이 특정 tenant에 종속되는 데이터인지”
• “완전히 공통으로도 의미가 있는 데이터인지”

를 구분해 보고, 종속된다면 tenant_id를 명시적으로 가져가는 편이 안전하다.

4.2 if (tenant == 'X') 조건 분기 남발

테넌트별 요구 사항이 달라지면 가장 먼저 떠오르는 코드는 보통 이렇다.

if ("TENANT_A".equals(tenantCode)) {
    // A 전용 로직
} else if ("TENANT_B".equals(tenantCode)) {
    // B 전용 로직
}

처음엔 쉽지만, 시간이 지나면:

• 코드 곳곳에서 테넌트별 분기가 등장하고,
• 새 테넌트가 추가될 때마다
  여러 파일을 동시에 수정해야 하는 상황이 생긴다.

가능하면:

• 전략 패턴,
• 설정 기반(tenant config),
• feature flag, policy 테이블

같은 구조로 “테넌트별 차이”를 한 레이어로 모으는 편이 관리하기 좋다.

4.3 메뉴/권한/API 책임이 섞여 버리는 구조

4편에서 정리한 것처럼:

• user → role
• role → menu
• menu → API

로 묶어서 권한을 계산하는 패턴은 실무에서 많이 쓰인다.

다만 시간이 지나면:

• “메뉴 구조 == 권한 구조”가 되어 버리거나,
• API 책임이 메뉴 구조에 종속되는 문제가 생길 수 있다.

가능하면:

• API 단위 permission 이름은 도메인 관점으로 유지하고 (예: USER_READ, ORDER_MANAGE)
• 메뉴/화면은 이 permission을 소비하는 레이어로 두는 방식이
  역할을 더 분명하게 나누는 데 도움이 된다.

4.4 토큰/컨텍스트에 너무 많은 정보를 싣는 설계

JWT나 세션 컨텍스트에 처음부터 많은 정보를 담아두면
처음에는 편해 보이지만,

• 토큰 구조를 바꾸고 싶을 때마다
  이미 발급된 토큰과의 호환성을 고려해야 하고,

• permission 전체를 토큰에 넣는 경우,

  • 역할/권한 정책이 바뀌어도 토큰 만료 전까지 반영되지 않는 문제가 생길 수 있다.

그래서:

• 토큰에는 식별자 + 최소한의 역할 정보 정도만 두고,
• 역할 → 권한(permission) 매핑은 서버/캐시에서 관리하는 구성이
  정책 변경에 더 유연하다.

---

5. 이 시리즈에서 가져갈 수 있는 큰 줄기

1~6편 전체를 한 줄로 정리하면 대략 이런 흐름이다.

1. 도메인 모델

   • tenant / user / tenant_user로
     테넌트와 회원·계정 관계를 정리한다.

2. 인증 구조

   • JWT + Redis 기반 Access/Refresh 토큰으로
     멀티테넌트 환경에서의 로그인/세션을 구성한다.

3. 권한(RBAC)

   • 역할/권한 모델을 테넌트 컨텍스트에 맞게 확장한다.

4. 실전 적용

   • 여러 서비스가 입점하는 회원 플랫폼 같은 시나리오에
     위 구조를 실제로 녹이는 방법을 살펴본다.

5. 스케일링

   • B2B SaaS에서 테넌트별 데이터 분리, noisy neighbor, Rate Limit 등을 고려해
     점진적으로 분리하는 전략을 본다.

6. 의사결정

   • 언제 멀티테넌트가 유효한 선택인지,
   • 언제는 단일 테넌트로도 충분한지
     체크리스트와 안티패턴 관점에서 되짚어 본다.

멀티테넌트 회원·인증 구조를 고민할 때 참고할 수 있다.

---

✅ 마무리

정리하자면, 멀티테넌시는

“서비스가 여러 조직/서비스/고객사를 품게 될 때
회원·인증·권한을 어떤 축으로 설계할 것인지”

에 대한 하나의 선택지에 가깝다.

• 비즈니스 확장 방향,
• 팀의 운영 역량,
• 데이터/트래픽 패턴

을 함께 놓고 보면,

• 어떤 서비스에는 단일 테넌트 구조가 더 자연스러울 수 있고,
• 어떤 서비스에는 초반부터 멀티테넌트를 깔아두는 편이
  나중에 훨씬 편해질 수 있다.

이 시리즈(1~6편)에서는 그런 판단을 할 때 참고할 만한
도메인, 인증, 권한, 스케일링 관점을 한 번 정리해 보았다.

이제 여기서 정리한 내용을 바탕으로,

• 여러 서비스·고객사가 공통으로 쓰는 멀티테넌트 인증 서버 예제나
• 교회·학원·소규모 단체를 테넌트로 보는 단체용 SaaS 예제

같은 작은 프로젝트에 하나씩 적용해 보면서,
설계가 실제 코드와 운영 환경에서 어떻게 작동하는지 더 검증해 볼 생각이다.

비슷한 고민을 하는 분들이라면,
각자 서비스 상황에 맞게 이 구조를 변형해서 써 보셔도 좋을 것 같다.

---

참고 문헌

• NIST, Role Based Access Control (RBAC) 프로젝트 자료
• Microsoft Azure Architecture Center, Multitenant SaaS database tenancy patterns
• 다양한 클라우드 벤더 문서의 멀티테넌시/Noisy Neighbor/Rate Limiting 관련 아키텍처 가이드