테넌트와 테넌시란 무엇일까요?

하나의 계정으로 여러 회사의 업무 공간을 오가는 서비스를 떠올려 보겠습니다. 로그인은 한 번 했는데, 회사를 바꾸면 보이는 문서도 쓸 수 있는 기능도 달라집니다. 같은 계정이니 같은 사람이라는 것은 알 수 있습니다. 그런데 그것만으로는 지금 어느 회사의 일을 하고 있는지 알 수 없습니다.

이 상황을 설명하는 말이 테넌트와 테넌시입니다. 테넌트는 서비스를 사용하는 고객 단위이고, 테넌시는 그 고객들이 서비스를 사용하는 구조입니다. 둘은 이어져 있지만 같은 결정이 아닙니다. 글은 문서 협업 서비스를 예로 들어 아래 질문들을 차례로 풉니다.

• 고객과 사용자는 어떻게 다른가: 로그인하는 사람은 여럿이어도 고객 환경은 회사 하나일 수 있습니다
• 한 사람이 A사에서는 관리자, B사에서는 읽기 전용일 때: 계정과 테넌트 사이에 소속 관계를 두고, 요청마다 테넌트 컨텍스트를 들고 갑니다
• 싱글테넌시: 고객마다 전용 환경을 두면 무엇이 쉬워지고, 프로비저닝·배포·고객별 버전 관리에서 무엇이 늘어나는가
• 멀티테넌시: 같은 앱을 함께 쓰면서 데이터 경계를 지키는 논리적 격리. 테넌트 ID를 붙이는 것만으로는 접근이 막히지 않습니다
• 앱을 공유해도 DB는 따로 고를 수 있습니다: DB 분리, 스키마 분리, 테이블 공유와 그에 따라 달라지는 백업·복구
• 샤딩은 저장 위치를 나누는 일이지 접근 권한을 보장하는 일이 아닙니다
• 인증과 인가, 그리고 테넌트 접근 판단. 브라우저가 보낸 tenantId를 그대로 믿으면 안 되는 이유와, 캐시·첨부 파일·비동기 작업에서도 같은 구분이 필요한 이유
• 시끄러운 이웃 문제와, 공유 환경과 전용 환경을 고르는 기준

"우리 서비스는 멀티테넌시입니다"라는 말만으로는 구조를 알 수 없습니다. 앱은 공유하고 DB는 고객마다 나누는 식으로, 어느 계층을 함께 쓰고 어느 계층을 나누는지까지 말해야 구조가 분명해집니다. 그리고 그 전에 정해야 할 것이 있습니다. 우리 서비스가 무엇을 하나의 고객 환경으로 볼지입니다.

전문은 블로그에서 이어집니다 👇

▶ 테넌트와 테넌시란 무엇일까요? (전문 보기)

다른 글도 블로그에서 이어집니다 · 전체 목차 보기