글로벌 SaaS가 일정 규모를 넘기면 성능보다 먼저 부딪히는 문제가 있습니다. “어느 나라 데이터가 어디에 저장되고, 누가 접근할 수 있는가"입니다. 초기에 멀티리전을 지연 시간 최적화 관점으로만 설계하면, 나중에 데이터 주권 요구(금융·공공·헬스케어, 기업 고객 보안 조항)가 들어왔을 때 아키텍처를 다시 뜯어고치게 됩니다.

핵심은 간단합니다. 리전 확장은 인프라 복제가 아니라 데이터 경계(boundary) 설계입니다. “모든 데이터를 글로벌로 공유"와 “모든 데이터를 리전 격리” 사이 어딘가에서, 법·리스크·운영 비용을 수치로 맞추는 것이 실무의 본질입니다.

이 글에서 얻는 것

  • 데이터 레지던시 요구를 기능 요청이 아니라 아키텍처 제약조건으로 해석하는 기준을 얻습니다.
  • 어떤 데이터는 리전에 고정하고, 어떤 데이터는 글로벌 집계로 올릴지 분류 체계 + 의사결정 우선순위를 가져갈 수 있습니다.
  • 리전 분리 도입 시 필요한 실무 기준(지연, RPO/RTO, 접근통제, 감사 로그)을 숫자·조건 중심으로 적용할 수 있습니다.

핵심 개념/이슈

1) 데이터 레지던시는 “저장 위치"가 아니라 “처리 경로” 문제다

많은 팀이 “DB를 서울/프랑크푸르트에 따로 두면 끝"이라고 생각합니다. 실제로는 아래 4가지를 같이 봐야 합니다.

  1. 저장 위치: 원본 PII가 어느 리전에 저장되는가
  2. 처리 위치: 배치/ML/검색 인덱싱이 어디서 실행되는가
  3. 전송 경로: 리전 간 복제/로그/백업이 넘어가는가
  4. 접근 주체: 운영자/지원팀/서드파티가 어느 경로로 조회하는가

즉 DB 한 대 위치만 맞춰도, 로그 파이프라인이나 BI 적재가 리전 경계를 넘으면 정책 위반이 됩니다. 이 지점은 멀티 리전 액티브-액티브 전략과 데이터 보존·삭제 아키텍처를 같이 보면 더 분명해집니다.

2) 데이터는 3계층으로 나눠야 운영이 단순해진다

실무에서 가장 재사용성이 높은 분류는 다음 3계층입니다.

  • L1: Strict Local(강한 지역 고정)
    주민번호, 결제식별자, 의료/인사 민감정보. 원본과 백업 모두 리전 고정.
  • L2: Local + Global Derived(로컬 원본 + 글로벌 파생)
    원본은 리전 고정, 익명화·집계값만 글로벌 전송.
  • L3: Global(글로벌 공용)
    문서 템플릿, 퍼블릭 메타데이터, 비식별 제품 카탈로그.

팀이 흔히 실패하는 이유는 분류 자체보다 “예외 규칙"을 안 정해서입니다. 예를 들어 L2 데이터라도 k-anonymity < 20이면 글로벌 전송 금지처럼 조건을 걸어야 정책이 살아 있습니다.

3) 제어 평면(Control Plane)과 데이터 평면(Data Plane)을 분리해야 한다

리전 분리에서 효과가 큰 구조는 아래처럼 역할을 나누는 것입니다.

  • Control Plane(글로벌): 테넌트-리전 매핑, 정책 버전, 배포/관측 설정
  • Data Plane(리전별): 요청 처리, 트랜잭션 데이터 저장, 로컬 감사 로그

이렇게 나누면 글로벌 운영팀이 정책은 통제하되, 민감 데이터 자체는 리전 경계를 안 넘습니다. 리전 라우팅 키 설계는 샤딩 키/리샤딩 플레이북의 원칙(안정 키, 확장성, 재분배 비용)을 그대로 적용할 수 있습니다.

4) 아키텍처 선택은 법무 문구가 아니라 SLO+비용+리스크 점수로 결정한다

권장하는 초기 의사결정 우선순위는 다음입니다.

  1. 정책 위반 가능성 최소화(규제·계약 위반 비용)
  2. 서비스 연속성(리전 장애 시 복구 가능성)
  3. 운영 단순성(온콜/디버깅 난이도)
  4. 성능/비용 최적화

실무 기준 예시:

  • L1 데이터의 리전 외 전송 허용률: 0%
  • 리전 장애 시 L1 서비스 목표: RTO 60분, RPO 15분 이하
  • 리전 간 동기 호출 비율: 전체 요청의 5% 미만
  • 글로벌 집계 지연 허용: p95 10분 이내
  • 정책 위반 탐지 후 격리까지 시간: 5분 이내

숫자를 먼저 박아두면, 아키텍처 논쟁이 “좋아 보이는 설계"에서 “목표를 만족하는 설계"로 바뀝니다.

실무 적용

1) 참조 패턴: Tenant Pinning + Regional Data Plane + Derived Global Pipeline

초기 도입에서 실패가 적은 패턴은 다음 흐름입니다.

  1. 테넌트 생성 시 home_region을 결정하고 immutable 정책으로 저장
  2. API Gateway/Service Mesh에서 tenant_id -> home_region 라우팅
  3. 리전 내부에서 트랜잭션 처리 및 원본 데이터 저장
  4. 글로벌 분석이 필요하면 비식별 파생 이벤트만 중앙 파이프라인으로 전송
  5. 운영자 조회도 리전 프록시를 통해 정책 검사 후 접근

이때 로깅/추적은 리전별 보관 원칙이 필요합니다. 구조화 로깅과 비밀정보 관리를 붙여 토큰/식별자 마스킹 규칙을 통일해 두면 감사 대응이 쉬워집니다.

2) 의사결정 기준(숫자·조건·우선순위)

(a) 리전 고정 대상 선정 기준

아래 조건 중 2개 이상 만족하면 L1로 분류하는 것이 안전합니다.

  • 법·계약상 국외 이전 금지 또는 사전 동의 필요
  • 유출 시 재무/법적 손실이 높은 식별 데이터
  • 고객 보안 심사에서 데이터 경계 증적을 요구
  • 삭제 요청 SLA가 엄격(예: 30일 내 완전 삭제 증적 제출)

(b) 동기/비동기 경로 선택 기준

  • 리전 간 RTT p95가 150ms 초과면 동기 호출 대신 비동기 이벤트로 전환
  • 리전 간 실패율이 1% 초과 5분 지속이면 cross-region read fallback 차단
  • 글로벌 대시보드 데이터는 실시간보다 5~10분 지연 허용으로 비용 최적화

(c) 장애 대응 우선순위

  1. 정책 위반 가능 경로 즉시 차단(egress rule tighten)
  2. L1 쓰기 가용성 복구
  3. L2 파생 파이프라인 재처리
  4. L3 캐시/검색 재동기화

즉, “전체 기능 정상"보다 “위반 없는 최소 기능"을 먼저 복구하는 것이 맞습니다.

3) 6주 도입 로드맵

1~2주차: 데이터 분류와 정책 선언

  • 테이블/토픽 단위로 L1/L2/L3 태깅
  • 리전 외 전송 허용 조건 문서화
  • 운영/보안/법무 승인 라인 확정

3주차: 라우팅 고정

  • tenant pinning 도입
  • 리전 라우팅 미스 요청 차단 규칙 추가
  • 리전 간 직접 조회 API 최소화

4주차: 파생 파이프라인 분리

  • 비식별·집계 이벤트만 글로벌로 적재
  • 익명화 검증 실패 시 드롭 + 경보

5주차: DR·복구 리허설

  • 리전 단절 시나리오에서 RTO/RPO 측정
  • 정책 우회 경로(운영자 쿼리, 백업 복원) 점검

6주차: 운영 지표 고정

  • 레지던시 위반 시도, cross-region 호출률, 삭제 SLA 준수율 대시보드화
  • 월간 정책 리뷰 루틴 설정

4) 운영 지표 최소 세트

  • residency_policy_violation_attempts (일/주 단위)
  • cross_region_request_ratio (요청 비율)
  • local_write_p95_latency (리전별)
  • derived_pipeline_lag_minutes (L2 집계 지연)
  • deletion_sla_breach_count (삭제 요청 위반 건수)

이 다섯 개만 있어도 “정책 준수 vs 제품 속도"의 균형이 숫자로 보입니다.

트레이드오프/주의점

  1. 아키텍처가 복잡해진다
    리전별 데이터 평면을 두면 배포/모니터링/온콜 체계가 늘어납니다. 초기에 공통 템플릿 없으면 팀별 편차가 커집니다.

  2. 분석 민첩성이 떨어질 수 있다
    원본 데이터를 한곳에 모으지 못하므로, 데이터팀이 익숙한 “전체 원본 덤프” 방식은 쓰기 어렵습니다. 대신 파생 데이터 계약을 설계해야 합니다.

  3. 운영자 편의와 정책 준수가 충돌한다
    장애 시 운영자가 글로벌에서 바로 조회하고 싶어집니다. 이때 예외 권한이 상시화되면 정책은 무너집니다.

  4. 리전 확장은 비용 절감 수단이 아니다
    규제 대응을 위해 분리한 리전은 일반적으로 단기 비용이 올라갑니다. 비용 KPI를 앞세우면 다시 중앙집중으로 회귀하기 쉽습니다.

체크리스트 또는 연습

체크리스트

  • 데이터 자산이 L1/L2/L3로 분류되어 있고 소유 팀이 명시돼 있다.
  • 테넌트의 home_region 결정 규칙과 변경 승인 절차가 문서화돼 있다.
  • 리전 외 전송은 파생 데이터만 허용되고 검증 실패 시 차단된다.
  • 정책 위반 시 자동 격리(runbook + alert + owner)가 정의돼 있다.
  • 리전 장애 리허설에서 RTO/RPO 목표를 분기별로 검증한다.

연습 과제

  1. 현재 서비스의 주요 테이블 10개를 L1/L2/L3로 분류하고, 분류 근거를 법/계약/운영 관점으로 1줄씩 적어보세요.
  2. tenant_id 기반 리전 고정 라우팅이 없는 API 3개를 찾아, 리전 경계 위반 가능성을 평가해 보세요.
  3. 최근 30일 로그에서 cross-region 동기 호출 상위 엔드포인트를 뽑고, 비동기 전환 시 예상 지연/비용/리스크를 비교해 보세요.

관련 글