멀티테넌시

소프트웨어를 CD나 설치 파일로 팔던 시절에는 고객사 한 곳을 받을 때마다 그 회사 서버에 제품을 한 벌씩 깔았습니다. 고객이 100곳이면 세상에 우리 제품이 100벌 돌아가고 있었고, 그 100벌은 시간이 지나면서 제각각으로 갈라졌습니다. 어떤 곳은 2년 전 버전에 머물렀고, 어떤 곳은 그 회사 사정에 맞춰 코드를 조금 고쳐 둔 상태였습니다.

그래서 고객 지원 전화는 늘 같은 질문으로 시작했습니다. "그 버튼이 화면에 없는데요" 라는 문의를 받으면 담당자가 먼저 묻는 말이 "지금 쓰시는 버전이 몇인가요" 였습니다. 버그 하나를 고쳐도 담당자가 현장에 가서 설치를 해야 했으니, 급한 수정 하나가 전체 고객에게 퍼지는 데 반년이 걸렸습니다.

브라우저만으로 쓸 만한 제품을 만들 수 있게 되면서 SaaS, 그러니까 설치 없이 구독해 쓰는 형태가 자리를 잡았습니다. 다만 웹으로 옮긴다고 앞의 문제가 저절로 풀리지는 않았습니다. 고객사마다 서버를 한 벌씩 띄워 주면 설치 장소만 우리 쪽으로 옮겨 왔을 뿐 관리할 벌 수는 그대로였습니다. 멀티테넌시는 여기서 한 걸음을 더 간 구조입니다. 한 벌만 돌리고 그 안에서 고객사를 갈라 두기로 정한 것입니다.

고객 수가 늘어도 운영해야 할 시스템은 한 벌로 묶어 두는 문제를 풉니다. 풀리는 항목은 셋입니다.

1. 원가입니다. 고객사 300곳이 같은 서버 무리를 나눠 쓰면 한 회사가 쉬는 시간대의 여유를 다른 회사가 씁니다. 그래서 고객이 열 배 늘어도 서버 비용은 열 배가 되지 않습니다. SaaS 회사가 매출총이익률 70~80퍼센트를 내는 바탕이 여기 있습니다.
2. 배포입니다. 새 버전을 한 번 올리면 그날로 300곳이 같은 화면을 봅니다. 고객사마다 다르게 내보내야 할 것이 있으면 코드를 가르지 않고 피처 플래그로 켜고 끕니다.
3. 운영입니다. 느려진 화면을 찾을 때도, 오류를 뒤질 때도 볼 곳이 한 곳입니다.

그러면 데이터는 무엇으로 가르느냐가 남습니다. 흔한 방식은 모든 데이터 한 줄마다 어느 고객사 것인지를 적은 번호를 붙여 두고, 데이터를 꺼내는 모든 조회에 그 번호 조건을 거는 것입니다. 문제는 이 조건을 사람이 손으로 붙인다는 데 있습니다. 조회문 수백 개 가운데 하나에서 조건이 빠지면 A사 문서가 B사 화면에 뜹니다.

그래서 조건을 사람 손에 맡기지 않는 장치를 함께 씁니다. 행 수준 보안은 데이터베이스가 직접 줄 단위로 접근 권한을 확인하는 기능입니다. 조회문에 조건을 적는 것을 잊어도 데이터베이스가 자기 고객사 줄 외에는 내주지 않습니다.

고객에게 제품을 주는 모양은 셋이 더 있고, 회사 하나가 여럿을 동시에 쓰는 일도 흔합니다.

1. 싱글 테넌시는 고객사마다 서버와 데이터베이스를 따로 띄워 주는 구조입니다. 우리 데이터가 남의 데이터와 같은 저장소에 있으면 안 된다는 조건을 건 금융사나 공공기관을 받으려면 필요합니다. 대신 고객 100곳이면 환경 100벌을 운영하고 배포도 100번 해야 해서, 보통 값을 몇 배로 매긴 별도 요금제에 붙입니다.
2. 온프레미스는 고객사 자기 서버에 설치해 주는 방식입니다. 외부 인터넷과 끊어 둔 망에서만 일하는 조직에는 이 방법밖에 없습니다. 계약 한 건이 크다는 점이 끌리지만, 설치형 시절의 버전 파편화가 그대로 따라옵니다.
3. 화이트라벨은 만든 쪽 이름을 지우고 고객사 브랜드를 달아 내보내는 방식입니다. 서버를 어떻게 놓느냐가 아니라 누구 이름으로 파느냐의 문제라서, 멀티테넌시 위에 얹어 둘 수 있습니다.

실제로는 중간 지점을 고르는 경우가 많습니다. 애플리케이션 서버는 모두가 나눠 쓰되 데이터베이스만 큰 고객사 몇 곳에 따로 떼어 주는 식입니다.

"저희는 멀티테넌시라서 고객사별 기능 변경은 설정값 범위에서만 됩니다."

코드를 갈라 고쳐 드리는 방식은 하지 않는다는 뜻입니다.

"그 고객사는 데이터 분리 조건이 걸려 있어서 멀티테넌시로는 못 받습니다."

보안 요건 때문에 별도 환경을 띄워야 하는 건이라는 말입니다.

"테넌트 아이디 조건 빠진 조회문 없는지 배포 전에 한 번 더 봐 주세요."

고객사 구분 조건이 빠지면 데이터가 새니 점검하자는 요청입니다.

페이지덱에서는 수아가 직원 2천 명 규모의 고객사를 가져오면서 보안 심사 문항표를 같이 들고 왔습니다. 문항 가운데 하나가 "당사 데이터가 다른 고객사 데이터와 동일한 데이터베이스에 저장되는가" 였고, 페이지덱의 답은 그렇다였습니다.

태오가 자리에서 설명한 것은 같은 저장소를 쓰되 줄마다 고객사 번호가 붙고 데이터베이스가 그 경계를 직접 지킨다는 구조였고, SOC 2 보고서로 그 통제가 외부 감사를 거쳤다는 것까지 보였습니다. 그래도 계약서에 분리 보관을 적어야 한다는 답이 오면 남는 선택지는 하나입니다. 규원이 값을 세 배로 매긴 별도 요금제를 열지 말지를 정합니다.

같은 데이터베이스를 쓴다는 말을 데이터가 섞여 있다는 말로 읽는 경우가 가장 많습니다. 함께 쓴다는 표현이 칸막이가 없다는 인상을 주니 자연스러운 오해입니다. 실제로는 줄마다 붙은 고객사 번호, 조회문에 걸리는 조건, 데이터베이스가 직접 확인하는 권한까지 경계가 층층이 있습니다. 다만 위험이 없다고 말하는 것도 사실과 다릅니다. 경계가 코드로 만들어져 있으니 실수 하나가 전면 노출로 이어질 수 있고, 그래서 사람 손을 덜 타는 장치를 겹쳐 두는 것입니다. 이 구분을 못 하면 영업 자리에서 "안전합니다" 라는 말만 반복하게 되고, 심사표는 그 답을 근거로 받아 주지 않습니다.

고객사별 요구를 아예 못 받는다고 읽는 것도 흔합니다. 한 벌의 코드를 쓰니 그렇게 들리지만, 로고와 권한 구성, 승인 단계 같은 것은 설정값으로 얼마든지 다르게 둘 수 있습니다. 받기 어려운 것은 특정 고객사만을 위해 코드 흐름을 가르는 요구입니다. 그 요구를 한 번 받으면 다음 배포마다 그 분기를 같이 확인해야 하고, 그런 분기가 열 개 쌓이면 한 벌로 묶어 두려던 처음 목적이 사라집니다.