멀티테넌트 플랫폼의 데이터 격리 함정
“한 번 만들어 두고 매장(또는 고객사)만 늘리면 됩니다.”
플랫폼·프랜차이즈·입점몰·B2B 서비스 기획에서 자주 나오는 문장입니다. 멀티테넌트는 하나의 시스템 위에서 여러 조직의 데이터·설정을 나누어 서비스하는 방식입니다.
문제는 데모 화면에서는 잘 나뉘어 보여도, 아래가 빠지면 운영 중 대형 사고로 이어진다는 점입니다.
A 매장 주문이 B 매장 관리자에 노출됩니다. 고객이 다른 입점사 파일·리뷰를 주소 추측으로 엽니다. 통계 화면에 전체 합계가 한 테넌트 화면으로 나옵니다. 알림·결제 통지가 소속 확인 없이 전역으로 돕니다. 백업 복원 시 다른 조직 데이터가 섞입니다.
데이터 격리는 화면 필터가 아닙니다. 모든 읽기·쓰기 경로의 계약입니다.
테넌트가 무엇인지부터 고정합니다
프로젝트마다 “테넌트” 단위가 다릅니다. 모호하면 격리가 흔들립니다.
| 단위 후보 | 적합한 예 | 주의 |
|---|---|---|
| 회사·고객사 | B2B SaaS | 하위 팀·지점 권한 추가 설계 |
| 매장·지점 | 프랜차이즈 주문 | 본사 통합 조회 vs 매장 한정 조회 |
| 입점 판매자 | 마켓플레이스 | 상품·정산·문의 귀속 |
| 브랜드·워크스페이스 | 멀티 브랜드 운영 | 사용자 한 명이 여러 소속 |
문서에 테넌트 식별자가 어떤 표에 필수인지, 본사 역할이 예외적으로 무엇을 볼 수 있는지를 명시합니다.
격리 모델: 과도한 선택과 부족한 선택
실무에서 많이 쓰는 스펙트럼입니다.
- 공유 데이터베이스 + 행마다 소속 키
장점: 운영이 단순하고 비용 효율이 좋습니다.
함정: 조회마다 조건을 빼먹으면 즉시 유출됩니다.
- 스키마·데이터베이스 분리
장점: 격리 강도·고객사별 백업에 유리한 경우가 있습니다.
함정: 이관·모니터링 비용이 커지고, “매장만 추가” 속도와 충돌할 수 있습니다.
- 하이브리드
공통 카탈로그는 공유하고, 주문·회원은 소속 키 필수 등으로 나눕니다.
중소 플랫폼 첫 버전은 1번으로 시작하는 경우가 많습니다. 다만 “컬럼이 있다”와 “항상 필터한다”는 다릅니다. 코드 검토와 테스트로 강제해야 합니다.
데이터가 새는 전형적인 경로
- 목록 조회: 소속 조건 누락, 관리자 “전체” 기본값
- 상세 조회: 번호만으로 조회, 소유 소속 검증 없음
- 파일·이미지 주소: 추측 가능한 경로, 권한 검사 없는 직접 링크
- 검색·내보내기: 전역 검색에 타 소속 문서 포함
- 결제·알림 통지: 주문 소유 검증 없이 상태 변경
- 정기 작업: “오늘 주문 전체” 처리 시 소속 루프 없음
- 캐시 키: 소속 없는 키로 교차 노출
- 지원용 최고 권한 도구: 필터 해제 후 스크린샷·다운로드
플랫폼에서는 모든 대상에 소유 소속 검증이 기본 습관이어야 합니다. 실무 보안 점검 항목과도 겹칩니다.
본사·최고 관리자와 일반 매장 관리자
운영상 본사는 여러 매장을 봐야 합니다. 이때 자주 하는 실수입니다.
- 최고 권한을 매장 계정에 복사
- 화면에서만 매장 선택, 서버는 그대로 신뢰
- 지원 모드에 기록·사유·시간 제한 없음
권장 방향입니다.
- 역할과 테넌트 범위를 동시에 적용
- 본사 조회는 별도 권한과 감사 기록
- 지원 가장 시 열람 기록과 종료 타이머
개발·시험에서 이미 무너지는 경우
- 시험 데이터가 전부 한 소속으로만 존재
- 테스트가 “로그인 성공”만 보고 타 소속 자원 접근을 안 봄
- 시험 환경에 운영 데이터 일부를 그대로 복제
타 소속 자원 접근 거부 테스트를 핵심 기능에 몇 개만이라도 자동화해 두면, 회귀를 줄일 수 있습니다.
계약·개인정보 관점
멀티테넌트 유출은 단순 버그가 아니라 다른 사업자의 고객 정보 문제일 수 있습니다. 입점·가맹 계약, 개인정보 처리 위탁, 로그 보관 범위를 기술 설계와 같이 봅니다.
“개발이 끝나면 법무”가 아니라, 어떤 데이터가 테넌트 경계 밖을 못 나가게 할지를 요구사항에 적습니다. 이 글은 법률 자문을 대신하지 않습니다. 계약·규제 해석은 전문가와 확인하는 것이 좋습니다.
자주 하는 선택이 만드는 결과
- 화면 필터만 구현: 직접 호출·구버전 앱으로 타 매장 데이터 노출
- 캐시·검색 전역 키: 간헐적 교차 노출 → 재현이 어려워 대응 지연
- 테넌트 없이 성장 후 분리: 데이터 이관·중단·재개발에 가까운 비용
- 본사 계정 공유: 사고 시 책임·범위 특정 불가
- 파일 경로 공개: 계약서·신분증 스캔이 섞인 저장소면 치명적
이렇게 준비하면 좋아요
- □ 테넌트 단위(회사·매장·판매자)가 문서와 데이터에 일치하는가
- □ 주문·회원·파일·설정 등 핵심 표에 소유 키가 필수인가
- □ 목록·상세·수정·삭제·내보내기 전부에 서버 측 소속 검증이 있는가
- □ 결제·통지·정기 작업·알림 경로에도 동일 검증이 있는가
- □ 캐시·검색 키에 소속 식별자가 포함되는가
- □ 본사·최고 권한과 매장 권한이 역할·범위로 분리되는가
- □ 타 소속 자원 접근 거부 테스트가 있는가
- □ 파일 주소가 추측·무권한 열람에 안전한가
- □ 백업·복원·이관 절차가 테넌트 경계를 보존하는가
- □ 지원용 열람에 감사 기록이 남는가
LB Contents는 입점·다매장·B2B 플랫폼을 제작할 때 화면 분기만이 아니라, 테넌트 경계가 기능·정기 작업·파일·권한까지 이어지는 구조로 설계합니다. 매장·고객사를 늘릴 계획이 있다면, 격리 모델부터 함께 상담하는 것이 안전합니다.