개발
싱글테넌시 vs 멀티테넌시
| 서론
안녕하세요 팡일입니다.
개발을 하다 보면 언젠가 한 번쯤은 이런 말을 듣는 것 같아요.
“우리 서비스는 멀티 테넌시 구조예요.”
처음 들었을 때는 굉장히 어려운 개념처럼 느껴지죠. 저 역시 처음에는 “그래서 그게 뭔데?“라는 생각밖에 들지 않았어요.
하지만 막상 알고 보면 생각보다 단순했습니다. 그리고 이 개념을 이해하면 왜 서비스마다 권한 처리가 다르고, 왜 tenantId가 필요하며, 왜 데이터 구조가 복잡해지는지 자연스럽게 이해할 수 있게 됩니다.
이번 글에서는 싱글 테넌시와 멀티 테넌시를 아파트 비유와 함께 쉽고 빠르게 알아보려고 합니다.
| 테넌트(Tenant)란?
먼저 테넌트(Tenant)라는 용어부터 알아봅시다.
테넌트는 서비스를 사용하는 하나의 고객사, 조직, 혹은 그룹을 의미합니다.
예를 들어 대학 총학생회 서비스를 만든다고 가정해보면, 각각의 총학생회가 하나의 테넌트가 되는 거죠.
서울대 총학생회
연세대 총학생회
고려대 총학생회
조금 더 익숙한 예시로는 Slack의 워크스페이스(Workspace)나 GitHub의 Organization을 떠올리면 됩니다.
같은 서비스를 사용하더라도 서로의 데이터에 접근할 수 없는 독립적인 조직 단위가 바로 테넌트입니다.
즉, 테넌트 = 서비스를 사용하는 하나의 조직 또는 고객사 정도로 이해하면 충분합니다.
| 싱글테넌시
싱글 테넌시는 테넌트마다 독립된 시스템을 제공하는 구조입니다.
서울대 총학생회 └─ 서버 └─ 데이터베이스연세대 총학생회 └─ 서버 └─ 데이터베이스고려대 총학생회 └─ 서버 └─ 데이터베이스
각 고객사가 완전히 분리된 환경을 사용하기 때문에 데이터뿐만 아니라 권한 역시 자연스럽게 분리되죠.
예를 들어 서울대 총학생회 관리자가 로그인하더라도 애초에 서울대 시스템에만 접근할 수 있기 때문에 고려대 데이터에 접근할 가능성이 없습니다.
즉, “시스템 자체가 분리되어 있기 때문에 권한 관리가 비교적 단순하다.”
| 멀티테넌시
멀티 테넌시는 여러 테넌트가 하나의 시스템을 함께 사용하는 구조입니다.
아파트 1채 101호 - 서울대102호 - 연세대103호 - 고려대
건물은 하나지만 각자의 집은 따로 있습니다. 실제 서비스에서는 서버와 데이터베이스를 함께 사용하지만 데이터는 tenantId 등을 통해 논리적으로 분리되는 것이죠.
여기서 중요한 점은 단순히 데이터를 저장할 때만 tenantId가 필요한 것이 아니라는 점인데요?
1) 사용자가 로그인할 때
{
"userId": 1,
"tenantId": "snu"
}: 현재 어떤 조직 소속인지 확인해야 합니다.
2) 데이터를 조회할 때
SELECT *
FROM notice
WHERE tenant_id = 'snu': 현재 사용자가 접근 가능한 데이터만 보여줘야 합니다.
즉, 멀티 테넌시는 단순한 데이터 분리 구조가 아니라 “하나의 시스템 안에서 사용자별 접근 권한을 어떻게 통제할 것인가” 에 대한 문제이기도 합니다.
| 내가 이미 매일 사용하고 있었다
사실 멀티 테넌시라는 용어는 낯설 수 있지만, 우리는 이미 매일 멀티 테넌시 서비스를 사용하고 있습니다.
1) Slack
예를 들어 회사에서 Slack을 사용한다고 가정해보자. 우리 회사 직원들은 우리 회사의 채널과 메시지만 볼 수 있다. 다른 회사의 채널이나 메시지는 보이지 않는다.그렇다면 Slack은 회사마다 별도의 서버를 운영하고 있을까? 대부분 그렇지 않다.Slack은 하나의 서비스를 여러 회사가 함께 사용하지만, 각 회사의 데이터와 권한을 논리적으로 분리하여 관리한다.
2) Notion
Notion도 마찬가지다. 우리 회사의 문서를 다른 회사 직원이 볼 수 없는 이유는 회사마다 별도의 Notion 서버를 사용해서가 아니라, 같은 서비스를 사용하면서도 데이터 접근 권한이 철저하게 분리되어 있기 때문이다.
3) Github
GitHub 역시 비슷하다. 같은 GitHub 서비스를 사용하더라도 내가 속한 조직(Organization)의 저장소만 접근할 수 있고, 다른 회사의 비공개 저장소는 볼 수 없다.즉, 우리는 이미 수많은 멀티 테넌시 서비스를 사용하고 있었던 셈이다.
어쩌면 “멀티 테넌시”라는 개념이 어려웠던 이유는 처음 듣는 용어였기 때문이지, 실제로는 너무 익숙한 구조였는지도 모릅니다.
| 왜 대부분의 회사는 멀티 테넌시를 사용할까?
다양한 이유가 있겠지만, 대표적으로는 돈 때문입니다.
고객사 100명 = 서버 100개
싱글 테넌시라면 고객사 별 서버를 관리해서 비용이 많이 들게 됩니다.
고객바 100명 = 서버 몇 개
반면, 멀티 테넌시는 고객사마다 서버를 갖는 구조가 아니기에, 이런식으로 운영이 가능해서 훨씬 저렴합니다.
우리가 사용하는 Slack, Notion, Github과 같은 SaaS 서비스들은 대부분 멀티 테넌시입니다.
| 개발자는 왜 이걸 알아야 할까?
사실 서비스를 사용하는 입장에서는 싱글 테넌시인지 멀티 테넌시인지 알 필요가 없습니다만 개발자는 다르다고 생각해요.
서비스 구조가 싱글 테넌시인지 멀티 테넌시인지에 따라 데이터 모델, API 설계, 권한 처리 방식이 모두 달라지기 때문이죠.
예를 들어 어느 날 백엔드 개발자가 이렇게 말할 수 있어요.
“tenantId도 함께 보내주세요.”
처음에는 “그냥 사용자 정보만 보내면 되는 거 아닌가?” 싶을 수 있지만, 멀티 테넌시 환경에서는 하나의 서버와 데이터베이스를 여러 고객이 함께 사용하기 때문에, 현재 요청이 어느 고객의 데이터인지 구분하는 정보가 반드시 필요합니다.
만약 이 구분이 제대로 되지 않는다면 어떻게 될까?-> 서울대 총학생회 관리자가 고려대 총학생회의 공지사항을 조회하거나 수정하는 상황이 발생할 수도 있다. 생각만 해도 아찔하다.
그래서 멀티 테넌시 서비스에서는 데이터를 조회할 때도, 저장할 때도, 수정할 때도 항상 “이 데이터는 누구의 것인가?“를 고려해야 합니다.
결국 개발자가 테넌시 구조를 이해한다는 것은 단순히 새로운 용어를 아는 것이 아니라, “왜 tenantId가 필요한가?”, “왜 권한 처리가 이렇게 복잡한가?”, “왜 모든 API에서 조직 정보를 확인하는가?” 와 같은 질문에 답할 수 있게 된다는 의미에 가깝습니다.
실제로 SaaS 서비스를 만드는 회사에서는 생각보다 자주 등장하는 개념이라, 한 번 이해해두면 여러 시스템을 바라보는 시야가 훨씬 넓어집니다.
| 그래서 뭐가 더 좋은 건데?
여기까지 읽었다면 이런 생각이 들 수 있죠.
“그래서 싱글 테넌시랑 멀티 테넌시 중 뭐가 더 좋은 건데?”
결론부터 말하면, 정답은 없습니다. 서비스의 성격에 따라 적합한 방식이 다르기 때문이죠.
구분 | 싱글 테넌시 | 멀티 테넌시 |
서버 | 고객사별 독립 | 여러 고객사 공유 |
데이터 | 물리적으로 분리 | 논리적으로 분리 |
권한 관리 | 비교적 단순 | 상대적으로 복잡 |
장애 영향도 | 특정 고객사만 영향 | 여러 고객사에 영향 가능 |
운영 비용 | 높음 | 낮음 |
확장성 | 낮음 | 높음 |
대표 사례 | 금융, 공공기관 | SaaS 서비스 |
싱글 테넌시는 고객사마다 독립된 환경을 제공하기 때문에 보안과 안정성 측면에서 유리합니다. 한 고객사의 장애가 다른 고객사에 영향을 주지 않으며, 데이터 역시 완전히 분리된 환경에서 관리할 수 있습니다.
반면 멀티 테넌시는 하나의 시스템을 여러 고객사가 함께 사용하기 때문에 운영 비용을 크게 절감할 수 있습니다. 또한 새로운 고객사가 추가되더라도 별도의 서버를 구축할 필요가 없어 서비스 확장이 훨씬 수월합니다.
그래서 일반적으로는 다음과 같은 선택이 이루어집니다.
보안과 독립성이 최우선이라면 → 싱글 테넌시
비용 효율성과 확장성이 중요하다면 → 멀티 테넌시
실제로 대부분의 SaaS 서비스가 멀티 테넌시를 선택하는 이유도 여기에 있어요. 수백, 수천 개의 고객사를 대상으로 서비스를 제공해야 하는데 고객사마다 서버를 따로 운영하는 것은 현실적으로 비용 부담이 매우 크기 때문이죠.
| 그렇다고 멀티 테넌시가 무조건 좋은 것은 아니다
멀티 테넌시는 비용 효율성과 확장성 측면에서 강력한 장점이 있지만, 그만큼 고려해야 할 부분도 존재합니다.
1) 보안 및 데이터 격리 위험
: 여러 테넌트가 같은 시스템을 사용하기 때문에, 권한 검증이나 쿼리 작성 실수로 다른 테넌트의 데이터가 노출될 수 있습니다.
2) 성능 영향
: 서버 자원을 공유하므로 특정 테넌트의 트래픽 증가가 다른 테넌트의 성능 저하로 이어질 수 있습니다.
3) 구조 변경의 복잡성
: 하나의 코드와 데이터베이스 구조를 공유하기 때문에, 변경 사항이 전체 테넌트에 영향을 줄 수 있습니다.
4) 커스터마이징의 한계
: 특정 고객사만을 위한 기능을 추가하기가 상대적으로 어렵습니다.
결국 멀티 테넌시는 만능 구조가 아니라, 비용 효율성과 운영 편의성을 얻는 대신 일정 수준의 복잡성을 감수하는 구조라고 볼 수 있습니다.
| 결론
싱글 테넌시와 멀티 테넌시의 핵심 차이는 결국 “고객사를 어떻게 분리할 것인가?“에 있습니다. 싱글 테넌시는 고객마다 독립된 공간을 제공하는 방식이고, 멀티 테넌시는 하나의 공간을 공유하되 데이터를 분리하는 방식입니다. 그리고 오늘날 대부분의 SaaS 서비스는 비용 효율성과 운영 편의성 때문에 멀티 테넌시를 선택하고 있습니다.
다음에 누군가 “우리 서비스는 멀티 테넌시 구조예요.“라고 말한다면, 이제는 적어도 “아, 여러 고객사가 하나의 시스템을 함께 사용하는 구조구나.” 정도는 바로 떠올릴 수 있을 것입니다.