Author: dvadmin

인베스트리 투자조합 관리 ERP, Lotus Soft 창업사관학교 플랫폼, Athena 정보보호관리 시스템 — 세 프로젝트 모두 “여러 기업이 하나의 플랫폼을 각자의 공간으로 사용”하는 멀티테넌트 구조입니다. 실제 개발 경험으로 멀티테넌트 설계의 핵심을 정리합니다.

---

멀티테넌트(Multi-tenant)란?

하나의 소프트웨어 인스턴스를 여러 고객(테넌트)이 공유하는 구조입니다. 각 테넌트는 자신의 데이터만 보고 관리하며, 다른 테넌트의 데이터는 볼 수 없습니다.

대표적인 예: Slack, Notion, Salesforce. 같은 소프트웨어인데 삼성 직원은 삼성 워크스페이스만, LG 직원은 LG 워크스페이스만 보입니다.

---

멀티테넌트 DB 설계 3가지 방식

방식 1 — 데이터베이스 완전 분리

테넌트마다 별도의 데이터베이스를 생성합니다.

tenant_a_db
  ├── users
  ├── projects
  └── invoices

tenant_b_db
  ├── users
  ├── projects
  └── invoices

장점: 완벽한 데이터 격리, 테넌트별 독립적 백업/복원 가능, 성능 예측 가능

단점: 테넌트 수가 늘면 DB 수도 늘어 관리 복잡도 증가, 비용 높음

Athena처럼 정보보호 데이터를 다루거나 금융 데이터가 포함된 경우 이 방식이 적합합니다.

---

방식 2 — 스키마 분리

같은 DB, 테넌트별 스키마(네임스페이스)를 분리합니다. PostgreSQL에서 주로 사용합니다.

-- tenant_a 스키마
CREATE SCHEMA tenant_a;
CREATE TABLE tenant_a.users (...);

-- tenant_b 스키마
CREATE SCHEMA tenant_b;
CREATE TABLE tenant_b.users (...);

장점: DB는 하나, 논리적 분리 가능

단점: 스키마 수가 많아지면 마이그레이션 관리가 복잡

---

방식 3 — 행 수준 분리 (Row-Level Security)

같은 테이블에 tenant_id 컬럼으로 구분합니다.

CREATE TABLE users (
  id UUID PRIMARY KEY,
  tenant_id UUID NOT NULL,  -- 테넌트 구분자
  name VARCHAR(100),
  email VARCHAR(255)
);

-- 조회 시 반드시 tenant_id 필터 적용
SELECT * FROM users WHERE tenant_id = 'tenant_a_uuid';

장점: 구조 단순, 비용 낮음, 테넌트 추가 쉬움

단점: 실수로 tenant_id 필터를 빠뜨리면 데이터 노출 위험

인베스트리, Lotus Soft처럼 중간 규모의 B2B SaaS에 적합합니다. 단, 모든 쿼리에 tenant_id 필터를 강제하는 미들웨어 레이어가 필수입니다.

---

권한 관리 (RBAC) 설계

멀티테넌트 SaaS에서 권한 관리는 두 축으로 나뉩니다.

축 1 — 플랫폼 레벨: 슈퍼 어드민(플랫폼 전체 관리), 테넌트 어드민(자사 관리), 일반 사용자

축 2 — 기능 레벨: 읽기, 쓰기, 삭제, 관리

Lotus Soft의 경우:

• 슈퍼 어드민: 전체 창업사관학교와 스타트업 데이터 열람, 시스템 설정
• 서브 어드민(창업사관학교): 자기 소속 스타트업만 관리, 프로그램 등록
• 테넌트(스타트업): 자사 정보와 신청한 프로그램만 확인

이 구조를 DB로 표현하면:

CREATE TABLE roles (
  id UUID PRIMARY KEY,
  name VARCHAR(50),         -- 'super_admin', 'tenant_admin', 'user'
  tenant_id UUID,           -- NULL이면 플랫폼 레벨 역할
  permissions JSONB         -- {"read": true, "write": true, "delete": false}
);

---

빌링(과금) 구조 설계

SaaS의 과금은 테넌트 단위로 이루어집니다. Lotus Soft에서 계정 유료화 버전에 따라 접근 가능한 기능이 달라지는 구조를 구현했습니다.

플랜 테이블:

CREATE TABLE plans (
  id UUID PRIMARY KEY,
  name VARCHAR(50),         -- 'free', 'pro', 'enterprise'
  features JSONB,           -- 플랜별 가능 기능 목록
  price_monthly DECIMAL
);

CREATE TABLE tenant_subscriptions (
  tenant_id UUID REFERENCES tenants(id),
  plan_id UUID REFERENCES plans(id),
  started_at TIMESTAMP,
  expires_at TIMESTAMP
);

기능 제한 체크:

// 미들웨어에서 플랜 기능 확인
const canUseFeature = async (tenantId, feature) => {
  const subscription = await getTenantSubscription(tenantId);
  return subscription.plan.features[feature] === true;
};

---

테넌트 온보딩 자동화

새 고객(테넌트)이 가입했을 때 자동으로 설정이 완료되어야 합니다.

온보딩 프로세스:

1. 테넌트 레코드 생성
2. 어드민 계정 생성 및 이메일 발송
3. 기본 플랜 적용
4. 초기 데이터 세팅 (샘플 데이터 또는 빈 상태)
5. 웰컴 이메일 발송

이 과정을 수동으로 하면 실수가 생기고 시간이 걸립니다. 가입 즉시 자동화되는 파이프라인을 처음부터 설계해야 합니다.

---

실제 개발 시 자주 발생하는 버그

버그 1 — tenant_id 필터 누락: 쿼리에서 tenant_id를 빠뜨려 다른 테넌트 데이터가 노출. 반드시 모든 쿼리에 자동으로 tenant_id를 주입하는 미들웨어 레이어를 만들어야 합니다.

버그 2 — 공유 리소스 캐시 충돌: 레디스 캐시 키에 tenant_id를 포함하지 않으면 A 테넌트 캐시가 B 테넌트에 노출됩니다. 캐시 키는 반드시 {tenant_id}:{resource_type}:{id} 형식으로.

버그 3 — 파일 저장소 분리 미흡: S3처럼 파일을 저장할 때 테넌트별 폴더 구조를 만들지 않으면 파일이 섞입니다. s3://bucket/{tenant_id}/files/{filename} 구조를 처음부터 적용하세요.

---

마치며

멀티테넌트 SaaS는 처음부터 올바르게 설계하지 않으면 나중에 수정하는 비용이 막대합니다. 특히 데이터 격리와 권한 관리는 보안 사고로 이어질 수 있어 더욱 중요합니다.

인베스트리, Lotus Soft, Athena 세 프로젝트를 통해 확인한 것은, “완벽한 멀티테넌트 설계는 없지만, 처음에 어떤 방식을 선택할지 팀 전체가 합의하고 일관되게 지키는 것”이 가장 중요하다는 점입니다.