VDI 사용자당 $40에서 $7로 핀테크가 ML 환경 데이터 유출을 막은 3계층 설계도

민감 데이터 ML 환경, 왜 기존 방식은 무너졌나

데이터 사이언티스트에게 민감 데이터를 쥐어주면서 동시에 유출은 막아야 한다는 요구는, ML 플랫폼 팀에게 영원한 숙제입니다. 핀테크 기업 iBusiness도 같은 벽에 부딪혔어요.

초기에는 온프레미스 에어갭(Air-gap) 환경을 제공했습니다. 물리적으로 격리된 망에서만 데이터를 만지게 하는 방식이죠. 하지만 재택근무가 표준이 되면서 이 방식은 사실상 유지 불가능해졌어요. 이후에는 보안 가상 데스크톱(VDI)을 디바이스 관리 정책으로 잠그고, 감시자(Proctor)까지 붙여서 통제했죠.

문제는 세 가지였습니다.

비용: 임시 접근이든 상시 접근이든 사용자당 전용 VDI가 필요했고, 사용자당 월 $40 이상이 나갔습니다.
운영 부담: Jupyter, ML 라이브러리, 보안 패치를 잠긴 환경마다 유지보수하는 건 지옥이었어요.
확장성: DS 팀이 커질수록 이 구조는 선형적으로 비용과 복잡도가 폭발합니다.

결국 iBusiness는 Amazon SageMaker Studio(완전관리형 웹 기반 ML 개발 환경)로 방향을 틀었고, 여기에 3계층 보안 아키텍처를 얹어서 데이터 유출 방지와 생산성을 동시에 잡았습니다. 이 글에서는 그 설계를 계층별로 분해해서, 여러분 환경에 어떻게 이식할 수 있는지 정리해볼게요.

원문은 AWS Architecture Blog의 근거자료에서 확인할 수 있습니다.

3계층 방어선, 각 레이어가 막는 것

핵심은 "한 겹으로 막지 말고, 서로 다른 공격 표면을 각각 봉쇄하라"입니다. iBusiness가 실제로 구성한 구조를 계층별로 뜯어보겠습니다.

Layer 1 — WorkSpaces Secure Browser로 접근 경로 자체를 잠근다

Amazon WorkSpaces Secure Browser는 관리형 Chromium 기반 브라우저입니다. 사용자는 로컬 PC에서 이 브라우저로만 환경에 접속할 수 있어요.

핵심 설정은 이렇습니다.

Secure Browser를 전용 VPC/서브넷에서 실행하고, 아웃바운드는 NAT Gateway를 경유시킵니다.
데이터 사이언스 계정 쪽 IAM 정책에서 NAT Gateway의 Elastic IP 또는 AWS 서비스 발신 요청만 허용합니다.
브라우저에서 파일 다운로드/업로드, 클립보드, 인쇄를 전부 비활성화합니다.

이렇게 하면 "로컬로 데이터를 빼가는" 가장 흔한 경로가 물리적으로 막힙니다.

// IAM 정책 예시: NAT Gateway EIP에서 온 요청만 허용
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnlessFromNATGatewayEIP",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": "203.0.113.10/32"
        },
        "Bool": {
          "aws:ViaAWSService": "false"
        }
      }
    }
  ]
}

Layer 2 — URL 화이트리스트 + VPC 엔드포인트로 계정 간 이동 차단

브라우저가 잠겨 있어도, 웹을 통해 데이터를 밀어낼 구멍은 남아 있습니다. iBusiness는 URL 얼로우리스트로 이를 막았어요.

허용: *.aws.amazon.com, 특정 SageMaker AI 도메인
차단: 이메일, 외부 스토리지, 그 외 전부

그다음 계정 간 유출을 막기 위해 다음을 구성합니다.

AWS Management Console과 IAM Identity Center용 VPC 엔드포인트 생성 (인터넷 노출 없이 VPC 내부에서 라우팅)
엔드포인트 정책으로 특정 AWS 계정만 허용
Route 53 Private Hosted Zone으로 console.aws.amazon.com, *.console.aws.amazon.com, signon.aws.amazon.com을 VPC 엔드포인트로 리다이렉트
Route 53 Resolver DNS Firewall로 비승인 도메인 DNS 쿼리 차단 (DNS 기반 유출 방지)

여기서 중요한 건, 이 모든 게 "사용자 몰래" 이루어져야 한다는 점입니다. DS 입장에서는 그냥 콘솔 열고 작업하는 것처럼 보여야 해요.

Layer 3 — SageMaker AI VPC에서 인터넷을 아예 뽑아버린다

마지막 계층은 개발 환경 자체를 격리합니다. SageMaker AI는 터미널과 IDE 접근을 제공하기 때문에, 여기가 뚫리면 앞의 두 계층이 무의미해집니다.

SageMaker AI VPC에서 NAT Gateway와 인터넷 라우트를 완전히 제거
필요한 AWS 서비스는 전부 VPC 엔드포인트로만 접근
엔드포인트 정책은 조직 소유 리소스로만 제한 (예: 특정 S3 버킷에만 s3:PutObject 허용)

# 네트워크 구성 요약
SageMaker AI VPC
 ├─ Internet Gateway: 없음 (제거)
 ├─ NAT Gateway: 없음 (제거)
 ├─ Route Table: 인터넷 라우트 없음
 └─ VPC Endpoints: S3, Athena, Lake Formation, CloudWatch, ...

이 구조의 미덕은 **"AWS 서비스는 정상 동작, 외부 인터넷은 원천 차단"**이라는 겉보기 모순을 만족한다는 점입니다.

Cloud architect configuring AWS VPC endpoints and SageMaker AI network isolation in console Dev Environment Setup

결과와 주의사항, 그리고 한국 개발 생태계 맥락

실제 성과

VDI 사용자당 월 $40+ → $7 (약 80% 비용 절감)
프로비저닝 2일 SLA → 자동 몇 분 내 셋업
데스크톱 유지보수 오버헤드 제거

숫자만 보면 화려하지만, 이 아키텍처는 "공짜 점심"이 아닙니다.

이 기술의 한계와 주의사항

운영 복잡도는 이전됩니다. VDI 유지보수 부담이 사라진 대신, VPC 엔드포인트 정책·DNS Firewall·Route 53 Private Zone을 관리해야 합니다. 초기 설계 난이도가 상당히 높아요.
URL 얼로우리스트의 함정. AWS 도메인을 *.aws.amazon.com으로 열어두면, 그 안에 포함된 SaaS나 문서 페이지를 통해 우회 경로가 생길 수 있습니다. 정기적인 감사가 필수입니다.
개발자 경험(DX) 저하. 파일 업로드/다운로드, 클립보드가 막히면 DS들이 "왜 이렇게 불편해?"라고 합니다. Slack으로 데이터 스니펫 하나 붙여넣지 못하는 환경이에요. 별도 협업 채널(내부 위키, 사내 메신저 연동)을 반드시 함께 설계해야 합니다.
DNS Firewall은 만능이 아님. DoH(DNS over HTTPS) 같은 우회 프로토콜까지 막으려면 별도 정책이 필요합니다.
조직 규모에 대한 종속성. 소규모 팀에는 과잉 엔지니어링일 수 있습니다. 사용자 10명 미만이면 그냥 VDI 한 대 띄우는 게 나을 수도 있어요.

한국 개발 생태계에서의 적용 맥락

국내 SI·금융권 환경에서는 이 아키텍처가 특히 유효합니다. 금융위·금감원 가이드라인상 망분리 요구사항이 있는 조직이라면, 온프레미스 망분리를 클라우드 기반 3계층 통제로 대체하는 근거로 활용할 수 있습니다.

다만 주의할 점은, 국내 규제는 "물리적 망분리"를 명시하는 경우가 여전히 많다는 겁니다. 클라우드 전환 시 규제 해석을 사전에 법무·컴플라이언스 팀과 정렬해두지 않으면, 아키텍처는 멀쩡한데 감사에서 걸리는 상황이 발생합니다.

또 하나, 국내 SI 특유의 다중 협력사 환경에서는 IAM 정책이 복잡해지기 쉽습니다. 엔드포인트 정책에 "조직 소유 리소스만 허용"을 걸어두면, 협력사 계정에서의 정당한 접근까지 막힐 수 있어요. 협력사별 예외 정책을 어떻게 관리할지 미리 설계해야 합니다.

다음 단계 학습 방향

VPC 엔드포인트 정책(Endpoint Policy) — 리소스 단위 세밀 제어 방법을 익히세요.
Route 53 Resolver DNS Firewall — 도메인 기반 유출 방지의 실전 패턴.
AWS Lake Formation — 데이터 공유 자체를 통제하는 계층. 이 아키텍처와 결합하면 시너지가 큽니다.
IAM 조건 키(Condition Keys) — aws:SourceVpce, aws:SourceVpc, aws:ViaAWSService 같은 키를 자유자재로 다루는 게 핵심입니다.

Data scientist accessing sensitive ML datasets through locked-down browser with URL allowlisting Developer Related Image

정리: "막는 것"보다 "경로를 없애는 것"이 먼저다

이 사례의 진짜 교훈은 특정 AWS 서비스 조합이 아닙니다. **데이터 유출 방지는 "차단 기능을 붙이는 일"이 아니라 "유출 경로 자체를 설계에서 제거하는 일"**이라는 관점이에요.

로컬로 나가는 경로(다운로드/클립보드/인쇄) → 없앰
외부로 나가는 경로(URL/DNS) → 얼로우리스트로 좁힘
계정 간 이동 경로(VPC 엔드포인트) → 정책으로 봉쇄
개발 환경의 인터넷 경로(NAT/IGW) → 물리적으로 제거

각 계층이 서로 다른 공격 표면을 담당하기 때문에, 한 겹이 뚫려도 전체가 무너지지 않습니다. 이게 "심층 방어(Defense in Depth)"의 실전형이에요.

여러분 조직에 적용할 때는 다음 순서를 추천합니다.

현재 데이터 접근 통제를 감사하세요. 어떤 경로로 데이터가 나갈 수 있는지 목록화합니다.
컴플라이언스 요구사항을 먼저 확정하세요. 규제가 "물리적 격리"를 요구하는지, "논리적 통제"로 갈음 가능한지 확인해야 합니다.
Layer 3부터 적용하세요. 개발 환경 격리가 가장 큰 임팩트를 냅니다.
DX 저하를 보상할 협업 채널을 함께 설계하세요. 이걸 빼먹으면 DS들이 그림자 IT를 만들기 시작합니다.

VDI 사용자당 $40에서 $7로 핀테크가 ML 환경 데이터 유출을 막은 3계층 설계도

민감 데이터 ML 환경, 왜 기존 방식은 무너졌나

3계층 방어선, 각 레이어가 막는 것

Layer 1 — WorkSpaces Secure Browser로 접근 경로 자체를 잠근다

Layer 2 — URL 화이트리스트 + VPC 엔드포인트로 계정 간 이동 차단

Layer 3 — SageMaker AI VPC에서 인터넷을 아예 뽑아버린다

결과와 주의사항, 그리고 한국 개발 생태계 맥락

실제 성과

이 기술의 한계와 주의사항

한국 개발 생태계에서의 적용 맥락

다음 단계 학습 방향

정리: "막는 것"보다 "경로를 없애는 것"이 먼저다

함께 보면 좋은 글

공유하기

이 포스트가 유익했나요?
작성자에게 큰 힘이 됩니다!

구독하기

RSS / Atom 피드

실시간 소식 알림

댓글 0

민감 데이터 ML 환경, 왜 기존 방식은 무너졌나

3계층 방어선, 각 레이어가 막는 것

Layer 1 — WorkSpaces Secure Browser로 접근 경로 자체를 잠근다

Layer 2 — URL 화이트리스트 + VPC 엔드포인트로 계정 간 이동 차단

Layer 3 — SageMaker AI VPC에서 인터넷을 아예 뽑아버린다

결과와 주의사항, 그리고 한국 개발 생태계 맥락

실제 성과

이 기술의 한계와 주의사항

한국 개발 생태계에서의 적용 맥락

다음 단계 학습 방향

정리: "막는 것"보다 "경로를 없애는 것"이 먼저다

함께 보면 좋은 글

공유하기

이 포스트가 유익했나요?작성자에게 큰 힘이 됩니다!

구독하기

RSS / Atom 피드

실시간 소식 알림

댓글 0

이 포스트가 유익했나요?
작성자에게 큰 힘이 됩니다!