전문 용어 없이 풀어낸 멀티테넌시: 창업자를 위한 안내서

소프트웨어 제품을 만드는 어느 시점이 되면, 개발자는 당신에게 "멀티테넌트"라는 말을 꺼내고는 당신의 표정을 살핀 뒤 이해했으리라 짐작합니다. 아마 당신은 고개를 끄덕였을 것입니다. 대부분의 창업자가 그렇습니다. 그러나 이것은 얼마나 빠르게 성장할 수 있는지, 얼마나 저렴하게 운영할 수 있는지, 그리고 고객이 자기 것이 아닌 데이터를 보게 된다면 일이 얼마나 잘못될 수 있는지를 조용히 결정해 버리는 초기 결정 중 하나입니다. 나중에 다시 손대기란 매우 비싸므로, 지금 10분의 주의를 기울일 가치가 있습니다.

저는 비개발자 창업자분들을 무척 많이 마주해 왔습니다. SaaS 제품에 대한 날카로운 아이디어가 있되 데이터베이스에는 별 관심이 없는 분들이지요. 다행스러운 점은, 이 결정을 잘 내리기 위해 코딩을 배울 필요는 없다는 것입니다. 필요한 것은 명료한 사고의 틀과 짧은 질문 목록뿐입니다. 이 안내서가 바로 그것입니다. 유행어도, 다시는 들여다보지 않을 아키텍처 다이어그램도 없이, 첫 줄을 쓰기 전에 당신이 이해해 주기를 개발자가 바라는 바로 그것만 담았습니다.

한 가지만 가져가신다면 이것으로 하십시오. 멀티테넌시는 나중에 덧붙이는 기능이 아닙니다. 그것은 토대입니다. 집은 다시 칠할 수 있지만, 벽이 세워진 뒤에는 그것이 딛고 선 기초를 쉽게 바꿀 수 없습니다.

"멀티테넌트"가 실제로 뜻하는 것

아파트 건물을 떠올려 보십시오. 각 입주자는 자기 집을 가집니다. 자기 열쇠, 자기 가구, 자기 현관문이지요. 하지만 모두가 같은 구조를 공유합니다. 기초, 배관, 지붕, 엘리베이터 말입니다. 관리인은 쉰 채의 별도 주택이 아니라 하나의 건물을 유지하며, 그것이 임대료를 감당할 만하게 만듭니다. 멀티테넌트 소프트웨어도 정확히 이렇게 작동합니다. 하나의 애플리케이션이 여러 고객, 곧 "테넌트"를 떠받치고, 그 아래에서 모두가 같은 공유 시스템 위에서 돌아가는데도 각자는 그것을 자기만의 사적 공간으로 경험합니다.

반대 접근은 싱글테넌트입니다. 고객마다 소프트웨어의 별도 사본을 주는 것으로, 한 사람 한 사람에게 새 단독 주택을 짓는 셈입니다. 더 사적이고 더 맞춤할 수 있지만, 구축과 운영과 갱신이 극적으로 더 비쌉니다. 이제는 하나의 건물이 아니라 쉰 채의 집을 유지하는 셈이기 때문입니다.

당신이 매일 쓰는 거의 모든 제품이 멀티테넌트입니다. 이메일, 회계 도구, 예약 시스템, 영업팀이 종일 들어가 사는 CRM. 당신과 다른 천 개의 회사가 같은 기반 소프트웨어를 공유하지만, 누구도 서로를 보지 못합니다. 그 보이지 않음, 그 깔끔한 분리가 멀티테넌시의 기술 전부입니다.

이 결정이 사업 전체에 닿는 이유

이것을 "개발자가 알아서 처리하는 기술적 세부"로 치워두고 싶어집니다. 그러나 당신이 고른 모델은 당신이 정말로 신경 쓰는 사업의 부분들로 곧장 파고듭니다. 매달의 호스팅 청구서, 새 기능을 모두에게 얼마나 빨리 내보낼 수 있는지, 긴장한 대기업 구매자에게 무엇을 약속할 수 있는지, 그리고 하나의 버그가 얼마나 큰 피해를 줄 수 있는지로 말입니다.

잘 만들어진 멀티테넌트 제품에서 버그를 고치거나 기능을 출시하면, 모든 고객이 한 번에 그것을 받습니다. 단 하나의 업데이트로요. 싱글테넌트 세계라면 그 변경을 쉰 개의 별도 설치본에 배포하게 되는데, 이제 그것들은 저마다 조금씩 달라져 있을 수 있습니다. 한쪽은 화요일 오후 일입니다. 다른 쪽은 프로젝트입니다. 이를 수년의 업데이트에 걸쳐 곱해 보면, SaaS 업계가 왜 멀티테넌시 위에서 돌아가는지 알 수 있습니다.

뒤집어 보면, 인프라를 공유한다는 것은 분리의 무게를 키웁니다. 아파트 건물에서 배관 고장은 한 집 이상에 영향을 줄 수 있습니다. 멀티테넌트 소프트웨어에서는 테넌트를 갈라 두는 방식의 실수가 한 고객에게 불편을 줄 뿐 아니라 모두의 데이터를 한 번에 노출시킬 수 있습니다. 이것은 멀티테넌시를 피할 이유가 아닙니다. 전에 해 본 사람과 함께 제대로 짓는 이유입니다.

테넌트를 갈라 두는 세 가지 방법

개발자들이 멀티테넌시를 두고 다툴 때, 대개는 각 테넌트의 데이터가 얼마나 분리되어야 하는지를 다투는 것입니다. 흔한 접근은 세 가지이며, "최대 공유, 최저 비용"에서 "최대 분리, 최고 비용"까지 이어진 눈금 위에 놓입니다. 당신이 직접 하나를 고를 필요는 없지만, 개발자가 당신을 대신해 내리는 절충은 이해해 두어야 합니다.

1. 공유 데이터베이스, 공유 테이블

모두의 데이터가 같은 데이터베이스의 같은 테이블에 있고, 어느 행이 누구의 것인지 표시하는 숨은 꼬리표, 곧 "테넌트 ID"가 붙어 있습니다. 소프트웨어는 항상 그 꼬리표로 걸러낼 책임을 지며, 그래서 고객 A는 오직 고객 A의 행만 봅니다. 이것은 가장 저렴하고 가장 잘 확장되는 모델로, 대부분의 초기 SaaS 제품이 씁니다. 함정은, 분리가 코드 안에 살기에 한 번의 걸러내기 누락이 곧 데이터 유출이라는 점입니다. 세심하고 규율 있는 작업이 요구됩니다.

2. 공유 데이터베이스, 분리된 칸막이

하나의 데이터베이스이지만, 각 테넌트가 그 안에 자기만의 둘러막힌 구역을 가집니다(개발자들은 이를 "스키마"라 부릅니다). 첫 모델보다 분리가 강하고, 여전히 그런대로 효율적이며, 이를테면 한 고객의 데이터를 깔끔하게 내보내거나 삭제하기도 더 쉽습니다. 절충은, 수백·수천 테넌트로 커 가면서 관리할 움직이는 부품이 늘어난다는 것입니다.

3. 테넌트마다 별도 데이터베이스

고객마다 자기 전용 데이터베이스를 가집니다. 애플리케이션은 여전히 공유하면서도 각자에게 사적인 집을 주는 데 가장 가까운 방식입니다. 이것은 가장 강한 격리이며, 보안에 민감한 대기업 구매자에게 들려주기 가장 쉬운 이야기입니다. 동시에 운영과 운용이 가장 비싸므로, 가치가 높은 고객, 규제 산업, 또는 데이터가 뒤섞이면 치명적인 제품에 한정되는 경향이 있습니다.

결코 그르쳐서는 안 되는 부분: 격리

걱정을 쏟을 한 곳이 있다면 바로 여기입니다. 테넌트 격리는 고객 A가 어떤 상황에서도 고객 B의 데이터를 보거나, 고치거나, 그 존재를 감지하는 것조차 결코 할 수 없다는 보증입니다. 당연해 보입니다. 그러나 이것은 멀티테넌트 제품에서 심각한 버그의 가장 흔한 원천이기도 합니다. 실패가 조용하기 때문입니다. 누군가 보고서를 열어 낯선 이의 고객이 그 안에 보이는 그날까지, 모든 것이 멀쩡해 보입니다.

이런 일이 일어나는 이유는 구조적입니다. 가장 저렴한 모델에서는 모든 단일 데이터베이스 요청이 테넌트로 걸러내기를 기억해야 합니다. 만 번을 옳게 하고 한 번을 그르치면, 유출입니다. 그래서 노련한 팀은 개발자의 기억에 기대지 않습니다. 격리를 토대에 박아 넣어, 잊는 일이 단지 드문 게 아니라 불가능해지게 합니다. 당신은 그들이 어떻게 하는지 이해할 필요가 없습니다. 그들이 그렇게 하는지 물어야 합니다.

이 문제에는 더 조용한 사촌도 있습니다. "시끄러운 이웃"입니다. 테넌트가 인프라를 공유하기에, 어떤 고객이 무거운 일—거대한 가져오기, 폭주한 보고서—을 하면 나머지 모두에게 시스템이 느려집니다. 한 집이 수도꼭지를 다 틀면 건물 전체의 수압이 떨어지는 것과 같습니다. 좋은 멀티테넌트 설계는 한도와 공정한 분배로 이에 대비합니다. 특히 아주 큰 고객 몇몇을 예상한다면 물어볼 가치가 있습니다.

싱글테넌트가 실제로 옳은 선택일 때

멀티테넌시는 SaaS의 기본값이지만 종교는 아닙니다. 고객에게 자기 별도 사본을 줄 정당한 이유들이 있고, 좋은 조언자는 모든 것을 공유 모델에 밀어 넣는 대신 그런 경우에 다다랐을 때 당신에게 알려 줍니다.

• 규제 산업의 고객—의료, 금융, 정부—으로, 컴플라이언스 규정이 사실상 그 데이터가 입증 가능하게 분리된 어딘가에 놓이기를 요구하는 경우.
• 전용 구성이 그만한 값어치를 할 만큼 충분히 지불하는 한 명의 대형 고객으로, 나머지 모두의 경험으로 새어 나가게 하고 싶지 않은 깊은 맞춤을 원하는 경우.
• 테넌트 간 유출의 대가가 사업을 끝장낼 만큼 민감한 데이터여서, 최대 격리가 추가 비용의 값어치를 하는 경우.
• 소프트웨어가 당신의 클라우드가 아니라 고객 자신의 담장 안에서 돌아가야 하는 온프레미스 요구.

그 패턴에 주목하십시오. 싱글테넌트는 의도적으로 손을 뻗는 예외이며, 대개 특정한 가치 높은 고객을 위한 것이지 사업 전체를 짓는 기본값이 아닙니다. 개발자가 첫날부터 당신의 표준 제품에 싱글테넌트를 제안한다면, 그 이유를 차근차근 설명해 달라고 하십시오. 대개는 훨씬 높은 운영 비용과 느린 업데이트를 뜻하며, 당신은 그것이 사고가 아니라 선택이기를 바랄 것입니다.

누군가 코드를 쓰기 전에 던질 질문들

당신이 아키텍처를 설계할 필요는 없습니다. 설계하는 사람이 옳은 것들을 충분히 생각해 두었는지 확인하면 됩니다. 비개발자 창업자가 그 첫 대화에 가져갔으면 하는 짧은 목록이 여기 있습니다. 인쇄하고, 묻고, 얼마나 자신 있게 답하는지 지켜보십시오.

1. 1
   테넌트의 데이터를 어떻게 분리해 두실 건가요?

   "조심하겠습니다"가 아니라 시스템이 강제한다는 구조적인 답을 들어야 합니다. 이것이 타협할 수 없는 하나입니다.
2. 2
   우리는 어떤 모델을 쓰고, 왜 그런가요?

   공유 테이블, 분리된 칸막이, 또는 테넌트별 DB. 틀린 답은 없지만, 당신의 고객과 예산에 맞는 이유가 있어야 합니다.
3. 3
   나중에 큰 고객에게 전용 격리를 제공할 수 있나요?

   완전 공유로 시작하더라도, 설계는 재구축 없이 한 명의 큰 또는 규제 대상 고객에게 더 강한 분리를 줄 여지를 남겨야 합니다.
4. 4
   한 고객이 거대해지면 어떻게 되나요?

   무거운 테넌트 하나가 나머지 모두를 느리게 하는 것을 시스템은 어떻게 막나요? 시끄러운 이웃 상황이 고려되었다고 듣고 싶을 것입니다.
5. 5
   한 고객의 데이터를 어떻게 깔끔하게 내보내거나 삭제하나요?

   고객은 떠나고, 개인정보법은 요청 시 데이터 삭제를 요구합니다. 이것은 허둥대는 일이 아니라 단순하고 잘 이해된 작업이어야 합니다.

당신은 답의 기술적 세부를 채점하는 게 아닙니다. 이 질문들 가운데 어느 것도 뜻밖으로 다가오지 않는지를 확인하는 것입니다. 멀티테넌트 소프트웨어를 전에 지어 본 팀이라면 다섯 가지 모두에 또렷하고 거의 시큰둥한 답을 내놓습니다. 첫째나 셋째에서의 머뭇거림은 속도를 늦추고 더 파고들라는 신호입니다.

짧고 현실에 가까운 사례

한 창업자가 작은 의원을 겨냥한 일정 관리 도구의 작동하는 시제품을 들고 우리를 찾아왔습니다. 이미 유료 고객이 셋 있었고—그리고 조용한 문제가 있었습니다. 빨리 시장에 내놓으려고, 첫 개발자가 각 의원에게 앱의 별도 사본을 주었던 것입니다. 세 고객, 세 설치본, 조금씩 다른 세 버전. 저마다 도중에 작은 손질을 부탁했기 때문입니다.

셋일 때는 훌륭하게 돌아갔습니다. 창업자의 악몽은 서른이라는 생각이었습니다. 버그 하나를 고칠 때마다 세 곳에 로그인해야 했습니다. 새 기능 하나마다 세 번의 배포와 세 가지 테스트 대상이 따랐습니다. 새 의원 하나를 손으로 셋업하는 데 거의 한 주가 걸렸습니다. 그들을 출시까지 데려온 모델이 이제는 성장을 가로막는 것이 되어 있었습니다. 바로 이 글 전체가 다루는 토대 문제입니다.

우리는 극적인 재작성으로 모든 것을 뜯어내지 않았습니다. 핵심을 시스템 수준에서 격리를 강제하는 공유 멀티테넌트 토대 위로 다시 지었고, 의원별 맞춤은 별도 코드베이스가 아니라 설정 가능한 옵션으로 남겼으며, 기존 세 의원을 병렬로 하나씩 옮겨, 누구도 무서운 전환의 날을 맞지 않게 했습니다. 새 의원 온보딩은 한 주의 수작업에서 셀프서비스 가입으로 바뀌었습니다. 새 기능은 이제 단일 릴리스에서 모든 고객에게 닿습니다.

여기 숫자는 예시일 뿐 약속이 아닙니다—제품마다 다릅니다—그러나 그 모양은 전형적입니다. 재구축에는 실제 비용과 두어 달이 들었고, 손가락 하나 까딱 않고도 갑자기 받아들일 수 있게 된 첫 한 줌의 새 고객 안에서 본전을 뽑았습니다. 창업자가 얻은 교훈은 더 값싼 것이었습니다. 처음에 다섯 가지 질문을 했더라면, 다시 지을 것이 아무것도 없었으리라는 것입니다.

자주 묻는 질문