수치심의 행진: 우리는 Database-Per-Tenant가 너무 비싸다고 생각했지만, 틀렸습니다

오랫동안 "테넌트 데이터를 어떻게 구조화해야 할까요?"라는 질문에 대한 우리의 기본 답변은 Schema-Per-Tenant였습니다. 이는 다른 옵션들이 나빴기 때문이 아니라, 한 가지 옵션이 반박하기 어려운 비용 문제를 가지고 있었기 때문입니다.

Database-Per-Tenant는 가능한 가장 깨끗한 격리(isolation)를 제공합니다. 각 테넌트는 완전히 분리된 데이터베이스에서 운영됩니다.

공유 자원이 없습니다. 향후 5년 동안 팀이 작성할 모든 쿼리에 대해 WHERE tenant_id = 절을 신뢰해야 하는 문제도 없으며, 법무팀에서 설명을 요구할 때 실제로 통할 수 있는 컴플라이언스(compliance) 근거도 확보됩니다.

솔직히 말해서, 우리도 그 모든 것을 알고 있었다고 생각합니다. 하지만 수백 개의 유휴(idle) 데이터베이스 인스턴스를 실행하는 비용이 실제로 부담스러웠기 때문에 계속해서 사람들이 이 방식에서 멀어지도록 유도했습니다.

Serverless Postgres가 이를 변화시켰습니다. 유휴 데이터베이스의 컴퓨팅(compute)이 0으로 스케일링(scale to zero)됨에 따라, 대부분의 테넌트가 동시에 활성화되지 않는 제품의 경우 Database-Per-Tenant의 비용 모델은 매우 다르게 보입니다. 우리가 계속해서 "결정적 결함(dealbreaker)"이라고 인용했던 요소가 이제는 사용 패턴에 따라 크게 달라지게 되었습니다.

그렇다면 오늘날의 패턴들은 어디에 있을까요?

**Row-Level Security (RLS)를 적용한 공유 테이블 (Shared Tables with Row-Level Security)**은 여전히 많은 팀에게 꽤 견고한 시작점입니다.

RLS 강제 적용은 데이터베이스 엔진 레벨로 내려갔습니다. 제 생각에는 매번 애플리케이션 코드에 의존하여 정확하게 처리하도록 하는 것보다 개선된 방식입니다. 이는 운영하기에 가장 저렴한 옵션이며, 초기 단계에서 추론하기 가장 단순합니다.

트레이드오프(tradeoff)는 자원을 공유한다는 점이며, 규모가 커짐에 따라 노이지 네이버(noisy neighbor) 문제가 실제로 발생하게 됩니다.

Schema-Per-Tenant는 여전히 대부분의 팀이 선택하는 중간 경로로 남아 있습니다. 하나의 데이터베이스 인스턴스 내에서 테넌트별로 별도의 네임스페이스(namespace)를 사용하며, 도구가 성숙해짐에 따라 많은 스키마에 걸쳐 마이그레이션(migration)을 관리하는 운영 측면의 고통이 의미 있게 줄어들었습니다.

심각한 컴플라이언스 압박을 받고 있지 않고 Database-Per-Tenant가 과하다고 느껴진다면, 이 방식은 여전히 기본값으로서 타당합니다.

Database-Per-Tenant는 비용 때문에 거부했다면(저도 그랬습니다) 다시 검토해 볼 가치가 있습니다.

하지만 AI 또는 HealthTech(헬스 테크) 분야에서 제품을 구축하고 있다면, 테넌트 데이터 혼합(tenant data mixing)의 결과가 단순히 고객 지원 문제에 그치지 않는다는 점을 고려할 가치가 있습니다.

AI 제품의 경우, 테넌트 데이터를 어떻게 격리(isolate)하느냐는 모델이 무엇을, 누구로부터 학습하는지에 직접적인 영향을 미칩니다. HealthTech의 경우, 컴플라이언스(compliance, 규제 준수)로 인해 강력한 격리는 선택이 아닌 필수 요구 사항입니다.

우리는 멀티 테넌시(multi-tenancy)에 대해 제작한 영상에서 이 내용을 많이 다루었습니다. 비용에 대한 가설은 변했지만, 핵심 패턴은 변하지 않았다는 점을 말이죠.

만약 현재 공유 스키마(shared schemas)를 사용 중이라면: 그것은 의도적인 선택이었나요, 아니면 단순히 처음에 그렇게 시작했던 것뿐인가요?