멀티테넌시의 데이터 격리 방식과 선택 기준

저장 방식을 고르는 건 데이터를 어디서 나눌지만 정하는 게 아니다. 장애가 났을 때 어느 단위로 복구하고, 스키마를 바꿀 때 어느 단위로 적용할지도 같이 정해진다. 그래서 데이터 민감도, 복구 요구, 성능 영향, 운영 자동화를 한 표에 놓고 본다. 비교 축은 Azure의 저장소·데이터 설계 안내와 같다.

세 가지 저장 방식

방식	격리 경계	복구와 운영	스키마 변경 부담
행 분리	같은 테이블에서 테넌트 키와 접근 정책으로 구분	테넌트 단위 복구를 따로 설계해야 한다	한 번 적용하지만 모든 테넌트에 영향을 준다
스키마 분리	같은 데이터베이스 안의 테넌트별 스키마	테넌트별 복구의 의존 객체와 절차를 확인해야 하고 DB 자원은 공유한다	모든 스키마에 적용하고 실패를 추적해야 한다
데이터베이스 분리	테넌트별 데이터베이스	테넌트별 백업·복구와 접근 자격을 나누기 쉽다	DB마다 변경·검증·버전을 맞춰야 한다

셋이 모든 축에서 같은 순서로 좋아지진 않는다. DB를 나눠도 서버와 클러스터는 같이 쓸 수 있어 물리 자원까지 따로 가는 건 아니고, 행 분리도 DB 정책으로 접근을 막을 수 있다.

스키마 분리가 요구하는 것

스키마 분리는 테이블 이름에 접두사를 붙이는 것과 다르다. PostgreSQL의 스키마는 이름 공간일 뿐이라 권한과 search_path를 같이 설계해야 한다. 둘이 예상과 다르면 스키마를 만들었어도 옆 테넌트의 테이블에 닿을 수 있다.

행 분리에서는 PostgreSQL의 row-level security로 행 정책을 둘 수 있다. 다만 테이블 소유자와 BYPASSRLS 역할은 기본적으로 정책을 우회하니, 애플리케이션이 어떤 역할로 접속하는지까지 봐야 한다. 모든 경로가 같은 테넌트 범위를 타야 한다는 원칙 자체는 멀티테넌시에서 무엇을 격리해야 하는가에 있다.

복구 단위와 변경 단위가 선택을 가른다

A사가 어제 상태로 되돌려 달라고 할 때 B사의 오늘 데이터는 그대로여야 한다. 공유 테이블이면 A사 행만 골라 복구하는 경로를 따로 만들어야 하고, DB를 나누면 대상은 분명해지지만 실제로 그 단위의 복구를 지원하는지는 DBMS와 관리형 서비스에 달려 있다.

반대로 모든 테넌트에 컬럼 하나를 추가할 때는 공유 테이블이 한 번에 끝나고, 스키마나 DB를 나눴으면 대상마다 적용 여부를 추적해야 한다.

그래서 기준은 테넌트 수가 아니라 이 넷이다. 테넌트별 복구가 필요한가. 한 테넌트의 부하를 저장소 분리로 막아야 하는가, 요청량 제한이면 되는가. 전체 마이그레이션의 자동화와 실패 추적이 준비돼 있는가. 접근 규칙을 코드·DB 정책·권한 중 어디서 강제할 것인가. 복구와 스키마 변경은 설계 문서로는 확인이 안 되고 실제로 한 번 돌려 봐야 한다.

연관된 노트

• 테넌트 초기화는 누가 언제 어디까지 맡는가