필사 모드: 데이터 레지던시는 드롭다운이 아니라 복제 토폴로지다

• 들어가며 — 리전 드롭다운이 답하지 못하는 질문
• 한 회사가 자기 복제 토폴로지를 통째로 공개했다
• 데이터가 사는 곳은 하나가 아니라 일곱 군데다
• 가용성을 택하면 잔류성을 잃는다
• 관할은 위치가 아니라 법인에 붙는다
• 마이그레이션을 어떻게 다루는지도 정보다
• 벤더에게 실제로 물어야 하는 것
• 같은 질문을 우리 시스템에 돌려보면
• 참고 자료

들어가며 — 리전 드롭다운이 답하지 못하는 질문

보안 검토서에 "고객 데이터는 EU 내에 저장됩니다"라고 한 줄 적어 본 적이 있을 겁니다. 그리고 그 문장을 뒷받침하는 근거는 대개 벤더 콘솔의 리전 드롭다운에서 EU를 골랐다는 사실 하나입니다.

그 문장이 참인지 확인하려면 최소한 일곱 개의 질문에 답해야 합니다. 주 사본은 어디 있는가. 복제본은. 백업은. 전역에서 참조되는 메타데이터는. 로그는. 결제와 지원에 쓰이는 서드파티는. 그리고 EU 리전이 죽었을 때 여러분의 클라이언트는 어디에 접속하는가.

2026년 8월 3일 Fastmail이 EU 데이터 리전을 공개하면서 쓴 글이 유용한 이유는, 이 일곱 개에 전부 답을 적어 두었기 때문입니다. 그것도 마케팅에 불리한 답까지 포함해서 말입니다.

이 글은 Fastmail을 추천하는 글이 아닙니다. 그 문서를 벤더 실사의 기준선으로 쓰자는 글입니다.

한 회사가 자기 복제 토폴로지를 통째로 공개했다

먼저 이 회사의 구성부터. Fastmail은 클라우드를 빌리지 않고 자체 하드웨어를 콜로케이션에 넣어 운영합니다. 원문 표현으로 "각 머신에 들어가는 디스크 모델까지 지정"하며, 기존 필라델피아와 세인트루이스에 더해 암스테르담에 같은 기준으로 서버를 설치했다고 씁니다.

복제 정책도 그대로 적혀 있습니다. 오랫동안 "모든 사용자의 메일 사본을 주 위치의 서로 다른 서버에 최소 두 벌, 지리적으로 분리된 위치에 최소 한 벌 더" 유지해 왔다고 합니다.

이 한 문장에 이미 답이 들어 있습니다. 지리적 분리 사본을 유지하는 정책과 데이터가 한 지역에만 머무는 정책은 동시에 성립할 수 없습니다. 내구성 요구가 그 자체로 소재지를 둘 이상으로 만듭니다.

그래서 EU 리전을 여는 회사가 정직하게 말할 수 있는 문장은 "여러분 데이터는 EU에 있습니다"가 아니라 "주 사본이 EU에 있습니다"입니다. Fastmail은 실제로 그렇게 씁니다.

데이터가 사는 곳은 하나가 아니라 일곱 군데다

원문에서 EU 리전 계정에 해당하는 항목을 정리하면 이렇습니다.

리전 드롭다운이 바꾸는 것은 이 표의 첫 줄 하나입니다. 나머지 여섯 줄은 그대로입니다.

특히 네 번째 줄이 중요합니다. 원문은 전역 복제 대상을 구체적으로 열거합니다. 이메일 주소를 포함한 사용자와 고객 메타데이터, 웹사이트 및 독립 파일 기능용 저장소, 연결된 서드파티 서비스의 세부 정보입니다. 즉 "모든 사람 데이터의 일부는 유럽과 미국 양쪽에 있다"고 명시합니다.

여러분의 시스템에도 이 범주가 반드시 있습니다. 계정 조회 테이블, 라우팅 규칙, 기능 플래그, 요금제 정보. 지연 시간 때문에 전역에 두는 것들이고, 리전 분리 설계에서 가장 늦게 발견되는 것들입니다.

가용성을 택하면 잔류성을 잃는다

원문에 이런 문장이 있습니다. "우리는 가용성을 우선한다. 그래서 홈 위치가 다운되면 여러분은 일시적으로 우리의 다른 위치에 접속해 데이터에 계속 접근하게 된다."

이것이 데이터 소재지 설계에서 가장 자주 무시되는 절충입니다.

메일함을 못 여는 것과 데이터가 잠시 대서양을 건너는 것 중 무엇이 더 나쁜가. 대부분의 사용자에게는 전자가 훨씬 나쁩니다. 그래서 대부분의 서비스가 같은 선택을 합니다. 다만 대부분은 그 선택을 문서에 적지 않을 뿐입니다.

계약서에 "데이터는 EU를 벗어나지 않는다"고 쓰는 순간, 여러분은 EU 리전 장애 시 서비스를 중단하겠다는 약속을 함께 한 것입니다. 그 약속을 지킬 준비가 되어 있는지, 그리고 그 절충을 고객에게 그렇게 설명했는지 확인해야 합니다.

메일 라우팅에도 같은 문제가 있습니다. 원문은 자체 도메인에 Fastmail 네임서버를 쓰거나 리전 전용 도메인을 쓰면 수신 메일이 해당 리전 서버로 "우선적으로" 간다고 씁니다. 반대로 리전이 없는 범용 도메인을 쓰면 메일이 어느 쪽으로든 드나들 수 있습니다. 접속 호스트명도 마찬가지여서, 범용 IMAP 호스트명은 내부에서 활성 서버로 프록시되고, 접속 위치를 통제하려면 리전 전용 서버명을 써야 합니다.

설정 화면에서 EU를 골랐다고 프로토콜 경로까지 EU가 되지는 않습니다.

관할은 위치가 아니라 법인에 붙는다

여기가 이 문서에서 가장 솔직한 대목입니다.

Fastmail은 자사가 호주 법인이며, 호주와 다른 국가 사이의 법적 협력 조약을 포함한 호주 법의 적용을 받는다고 밝힙니다. 그리고 이렇게 씁니다. "데이터가 어디에 저장되어 있든, 우리는 관련 당국의 적법한 요청에 동일하게 대응할 것이다."

이어지는 문장이 인용할 가치가 있습니다. "여러분에게 필요한 것이 데이터가 EU에만 남아 있다는 보장이라면, 우리에게는 그것이 없다. 그리고 그렇게 가정하도록 두느니 직접 말하는 편이 낫다."

여기서 데이터 소재지와 데이터 주권이 갈립니다.

• 소재지는 기술적 속성입니다. 디스크가 어느 건물에 있는가. 설정으로 바꿀 수 있습니다.
• 주권은 법적 속성입니다. 누가 그 데이터를 내놓으라고 강제할 수 있는가. 데이터를 통제하는 법인이 어느 나라 법의 적용을 받는지에 달려 있고, 리전 설정으로 바뀌지 않습니다.

암스테르담 데이터센터에 데이터를 두어도, 그 데이터를 운영하는 회사가 다른 나라 법의 적용을 받는다면 그 나라의 적법한 요청은 여전히 유효합니다. 진짜 주권이 필요하다면 필요한 것은 리전이 아니라 관할이 분리된 법인이거나, 사업자가 복호화할 수 없는 종단간 암호화입니다.

마이그레이션을 어떻게 다루는지도 정보다

세부 사항이지만 설계 관점에서 배울 게 있습니다.

Fastmail은 청구지 주소가 유럽이거나 인근인 사용자를 EU 리전으로 미리 선택했고, 발표 이전에 암호화된 사본을 유럽으로 옮겨 두었다가 곧 주 사본으로 승격시킨다고 씁니다. 최근에 가입한 사용자는 미국으로 배정되었고, 설정에서 바꿀 수 있습니다.

그리고 방향에 따라 비용이 다르다는 점을 명시합니다. 미국에서 EU로 옮기는 경우에는 그 지역에 사본이 없으므로 대서양 너머로 모든 메일을 동기화해야 해서 느리고, EU에서 미국으로 되돌아오는 경우에는 이미 미국에 사본이 있으므로 정합만 맞추면 되어 빠릅니다.

이 비대칭은 복제 토폴로지에서 곧바로 따라 나옵니다. EU 계정의 복제본이 미국에 있기 때문입니다. 토폴로지를 알면 마이그레이션 비용이 예측되고, 토폴로지를 모르면 예측되지 않습니다. 리전 이동이 "설정 한 번"이라고 안내하는 벤더에게 이 질문을 던져 보면 답변의 깊이가 갈립니다.

전환 경로도 문서화되어 있습니다. 설정의 Users & Sharing 아래 Team Settings에서 GDPR 항목 밑에 데이터 소재지 섹션이 있고, 대기, 전송 중, 완료 상태를 볼 수 있으며 이동 중에도 계정은 계속 동작한다고 안내합니다.

벤더에게 실제로 물어야 하는 것

위 내용을 그대로 질문지로 바꾸면 이렇게 됩니다. 상당수 벤더는 앞의 두세 개까지만 답을 준비하고 있습니다.

1. 주 사본은 어디에 저장됩니까. (거의 모든 벤더가 답합니다)
2. 살아 있는 복제본은 어디에 있습니까. 몇 벌입니까.
3. 백업은 어디에 있습니까. 백업 위치가 주 사본과 다른 리전입니까.
4. 리전에 관계없이 전역 복제되는 데이터가 있습니까. 있다면 목록을 주십시오.
5. 로그는 어디에 저장되고, 로그에 개인 식별 정보가 포함됩니까.
6. 결제, 지원, 오류 추적에 쓰는 서드파티가 있습니까. 그들에게 무엇이 전달됩니까.
7. 주 리전 장애 시 요청은 어디로 갑니까. 그때 데이터는 어디로 이동합니까.
8. 귀사는 어느 나라 법인이며, 어느 관할의 적법한 요청에 응합니까.
9. 투명성 보고서가 있습니까.

4번과 5번에서 대화가 멈추는 경우가 많습니다. 그건 벤더가 나빠서가 아니라 그 답을 아는 사람이 영업 조직에 없기 때문입니다. 이 질문은 엔지니어링에 전달되어야 하고, 답을 받는 데 시간이 걸린다는 사실 자체가 정보입니다.

같은 질문을 우리 시스템에 돌려보면

마지막으로 이 질문지를 자기 시스템에 적용해 보길 권합니다. 대개 다음 순서로 무너집니다.

로그가 첫 번째입니다. 애플리케이션 로그를 리전별로 분리해 두는 조직은 드뭅니다. 관측성 도구는 대체로 한 곳에 모으는 것이 기본값이고, 그 로그에는 사용자 식별자, IP, 때로는 요청 본문 일부가 들어갑니다.

백업이 두 번째입니다. 객체 저장소의 교차 리전 복제를 내구성 목적으로 켜 두고 잊어버린 경우가 많습니다. 켜져 있는지 확인해 보세요.

분석과 오류 추적이 세 번째입니다. 프런트엔드에서 직접 외부 SaaS로 이벤트를 보내는 코드는 백엔드 리전 설계를 전부 우회합니다.

관리 접근이 네 번째입니다. 데이터가 EU에 있어도 운영자가 다른 지역에서 접속해 조회한다면, 그 조회는 어떤 규정 하에 이루어집니까. 이 항목은 기술 설정이 아니라 접근 통제와 감사 로그의 문제입니다.

Fastmail의 문서가 좋은 문서인 이유는 EU 리전을 팔면서 "EU에만 있다는 보장은 없다"고 먼저 적었기 때문입니다. 여러분의 보안 검토서도 같은 수준을 목표로 삼을 만합니다. 지키지 못할 문장을 적는 것보다 지킬 수 있는 문장을 정확히 적는 편이 훨씬 낫습니다.

참고 자료

• Fastmail offers EU data region — Bron Gondwana, 2026-08-03 (본문의 인용과 표는 전부 이 문서에서 옮긴 것입니다)
• Choosing your data residency — Fastmail 도움말
• Fastmail 투명성 보고서