멀티테넌트란, 기획자가 알아야 할 데이터 격리 수준

 

예약 시스템 기획을 시작하고 얼마 지나지 않아 "이 서비스는 멀티테넌트 구조예요"라는 말을 들었습니다.
용어는 알겠는데, 기획자인 제가 이걸 얼마나 알아야 하는지가 애매했어요.
개발 방식은 개발자가 정하는 영역이니까 몰라도 되나 싶었지만, 몇 번 이야기를 나누다 보니 이 구조가 정책 질문과 직접 이어진다는 걸 알게 됐습니다.
오늘은 제가 이해한 만큼, 기획자 눈높이에서 데이터 격리 수준을 정리해보려고 해요.
기술적으로 엄밀한 설명은 아니라서, 정확한 구현은 개발자와 꼭 확인하셔야 합니다.

 

하나의 서비스를 여러 고객(테넌트)이 함께 쓰되, 서로의 데이터는 섞이지 않게 하는 구조입니다.
아파트에 비유하면 이해가 쉬워요.
건물은 하나인데 집마다 현관문이 있고, 다른 집의 내부는 볼 수 없죠.
건물을 같이 쓰니까 관리비는 나눠 내고, 집 안은 각자 꾸밉니다.

반대로 업장마다 별도의 서비스를 만들어 주는 방식이 있다면, 그건 단독주택을 하나씩 짓는 것과 비슷해요.
튼튼하고 자유롭지만 짓는 비용과 관리 부담이 큽니다.
멀티테넌트는 그 사이에서 "얼마나 나눠 쓰고 얼마나 분리할 것인가"를 정하는 일이라고 생각하면 됩니다.

 

흔히 데이터를 나누는 방식을 세 단계로 설명합니다.

 

첫 번째는 공유 DB, 공유 스키마입니다.
모든 테넌트의 데이터가 같은 표 안에 들어가고, 각 행에 "이 데이터는 어느 테넌트 것"이라는 표시만 붙어 있어요.
아파트로 치면 한 집을 칸막이로만 나눠 쓰는 셈입니다.
가장 저렴하고 관리가 쉽지만, 조회 조건을 하나라도 빠뜨리면 다른 테넌트의 데이터가 보일 위험이 있어요.

두 번째는 스키마 분리입니다.
같은 데이터베이스 안에서 테넌트마다 별도의 공간을 갖습니다.
집마다 방을 따로 두는 느낌이에요.
분리 정도가 높아지는 대신 테넌트가 늘어날 때 관리할 대상도 같이 늘어납니다.

세 번째는 DB 분리입니다.
테넌트마다 아예 다른 데이터베이스를 쓰는 방식입니다.
분리와 보안은 가장 강하지만 비용과 운영 부담이 가장 크고, 새 테넌트를 열 때도 준비할 게 많아요.
실제 서비스에서는 이 셋을 섞어 쓰는 경우도 있다고 해요.
기본 요금제는 공유 방식으로, 큰 고객에게는 분리 방식을 제공하는 식입니다.

 

비용, 보안, 커스터마이징, 이 세 축으로 생각하면 기획자도 판단에 참여할 수 있습니다.

비용은 테넌트 한 곳을 추가할 때 드는 부담입니다.
공유 방식이면 새 업장이 가입해도 추가 비용이 적어서 저렴한 요금제를 만들기 좋아요.

보안은 데이터가 섞일 위험과, 문제가 생겼을 때의 영향 범위입니다.
분리가 강할수록 사고가 나도 한 테넌트에 그치기 쉽습니다.

커스터마이징은 테넌트마다 다르게 해줄 수 있는 범위예요.
공유 구조에서는 모두 같은 틀 위에서 설정값만 바꿀 수 있는 경우가 많고, 분리 구조에서는 더 다른 모양을 허용할 여지가 생깁니다.

예를 들어 이런 가정을 해볼게요.
어떤 업장이 "예약 화면에 우리 전용 입력 항목을 열 개 정도 추가하고 싶다"고 요청했다고 합니다.
공유 구조에서는 이런 요청이 몇 개의 업장에만 해당해도 모든 테넌트의 데이터 구조에 영향을 줄 수 있어서, 일반적인 설정 기능으로 풀어내야 해요.
그러면 기획자는 "이 요청을 개별 대응할 것인가, 설정 기능으로 일반화할 것인가"를 고민하게 됩니다.

또 다른 가정 예시도 있습니다.
어떤 업장이 "우리는 고객 정보가 민감하니 다른 업장과 아예 분리해서 쓰고 싶다"고 요청한다고 해볼게요.
이 요청을 받아줄 수 있는지는 기획자가 혼자 정할 수 없고, 구조가 어디까지 허용하는지에 달려 있습니다.
만약 분리 옵션이 가능하다면 그건 별도의 상위 요금제로 설계할 수 있고, 불가능하다면 "이 서비스는 이런 방식으로 데이터를 보호합니다"라는 설명을 준비해야 해요.
어느 쪽이든 영업 담당이나 운영하는 분들이 같은 질문을 받았을 때 답할 수 있는 문장이 필요합니다.
구조를 알면 약속할 수 있는 것과 약속하면 안 되는 것의 경계가 보이는 셈이에요.

 

데이터 구조를 몰라도 이런 질문은 기획자가 할 수 있습니다.

 

첫째, "한 테넌트의 데이터를 통째로 내보내거나 지울 수 있나요?"
해지한 업장이 데이터를 달라고 할 때, 또는 삭제를 요청할 때를 대비한 질문이에요.
공유 구조에서는 이게 생각보다 번거로울 수 있습니다.

둘째, "특정 테넌트만 먼저 새 기능을 열 수 있나요?"
일부 업장에게만 시험 적용하고 싶을 때 필요해요.

셋째, "한 업장의 사용량이 폭증하면 다른 업장에 영향이 가나요?"
예를 들어 대형 행사로 한 업장의 예약이 몰려도 다른 업장의 응답 속도가 느려지지 않는지 묻는 겁니다.

넷째, "관리자 화면이나 통계에서 테넌트 경계를 넘어 보는 경우가 있나요?"
운영하는 쪽의 전체 통계와 테넌트별 화면은 데이터 범위가 달라서, 권한 설계와 직결됩니다.

다섯째, "테넌트별로 백업과 복구를 따로 할 수 있나요?"
한 업장이 실수로 데이터를 지웠을 때, 그 업장만 되돌릴 수 있는지에 따라 지원 정책이 달라져요.

 

참고로 이런 질문을 던질 때는 "정답이 뭐예요"보다 "지금 구조에서는 이게 쉬운가요, 어려운가요"라고 묻는 편이 대화가 잘 풀렸습니다.
어렵다는 답이 돌아오면 이유와 대안을 같이 묻고, 그 내용을 기획서의 제약 조건으로 적어둡니다.
제약이 문서에 남아 있으면 나중에 요구사항이 늘어날 때 "이건 구조를 바꿔야 해서 규모가 큰 일이다"라는 판단을 함께 할 수 있어요.

 

정리하면서 느낀 건, 격리 수준은 기술 선택이면서 동시에 제품의 약속이라는 점입니다.

어떤 수준을 택하느냐에 따라 요금제, 보안 안내, 커스터마이징 정책, 해지 절차가 모두 달라지니까요.
저는 아직 어느 수준이 맞다고 말할 입장은 아닙니다.

다만 "우리 서비스의 테넌트는 어느 정도까지 분리되어 있나요"를 물을 줄 아는 것만으로도 기획이 한결 단단해진다고 느꼈어요.

다음에는 이 구조 위에서 예약 시스템의 핵심 도메인 모델, 즉 업장과 서비스와 자원과 슬롯의 관계를 줄글로 풀어볼 예정입니다.