생성형 AI 시스템의 네트워크를 설계할 때 흔히 “모델 서버를 Private Subnet에 넣으면 충분하지 않을까?”라고 생각합니다. 그러나 실제 LLM 서비스는 사용자 세션, 프롬프트 오케스트레이터, 모델 추론 서버, RAG 지식베이스, Vector DB, 외부 모델 API, MCP 도구, 비신뢰 문서 파서가 연쇄적으로 연결된 시스템입니다.
이 구조에서는 단순한 인터넷망과 내부망의 이분법만으로 위험을 설명하기 어렵습니다. 사용자가 업로드한 PDF 안의 악성 지시가 RAG를 거쳐 도구 호출로 이어질 수 있고, 외부 LLM API로 나가는 HTTPS 트래픽 안에 개인정보나 영업비밀이 포함될 수도 있습니다. 모델 서버가 외부에 노출되지 않았더라도 과도한 도구 권한이나 잘못된 VPC 라우팅 때문에 중요한 데이터가 빠져나갈 수 있습니다.
따라서 생성형 AI의 망 분리는 물리적 또는 논리적 네트워크 분리에만 머물러서는 안 됩니다. 계정, VPC, 서브넷, 서비스 엔드포인트, 애플리케이션 정책, 데이터 등급, 관리자 경로를 하나의 신뢰 경계로 설계해야 합니다.
이 글에서는 AWS 환경을 예로 들어 계정→VPC→서브넷의 3단계 격리, Transit Gateway와 중앙 방화벽, AWS PrivateLink, Model Gateway와 PII DLP, N2SF의 C/S/O 데이터 등급, 관리자 접근 통제까지 연결해 설명합니다.
먼저 구분해야 할 것: 망 분리와 데이터 흐름 통제
전통적인 망 분리는 중요한 시스템을 인터넷에서 떨어뜨려 공격 표면을 줄이는 데 효과적입니다. 하지만 생성형 AI에서는 “어디에 배치했는가”와 함께 “어떤 데이터가 어느 방향으로 이동할 수 있는가”를 봐야 합니다.
사용자 입력
→ AI Application
→ Model Gateway
→ 내부 모델 또는 외부 모델 API
→ RAG Knowledge API
→ MCP Tool Broker
→ 실제 업무 시스템
이 흐름에는 서로 다른 신뢰 수준이 섞여 있습니다.
| 구성 요소 | 주요 위험 | 필요한 통제 |
| 사용자 입력 | 프롬프트 인젝션, 개인정보 입력 | 입력 검증, 데이터 분류, DLP |
| 비신뢰 문서 | 간접 프롬프트 인젝션, 악성 파일 | 전용 문서 검역 환경, 파서 격리 |
| 모델 서버 | 모델 가중치 유출, 추론 API 오용 | 외부 직접 접근 차단, 최소 권한 |
| Vector DB | 개인정보·내부 문서의 과도한 검색 | 테넌트 분리, 문서 ACL, 검색 후 필터 |
| 외부 모델 API | 프롬프트와 응답의 외부 전송 | Model Gateway, 비식별화, 승인 정책 |
| MCP·도구 실행 | 명령 실행, 데이터 변경, 권한 오용 | Sandbox, Tool Broker, 사용자 승인 |
핵심은 망 분리를 “인터넷 연결 유무”로만 판단하지 않는 것입니다. 동일한 내부망 안에서도 모델, 지식, 도구 실행 환경의 권한과 데이터가 다르다면 별도의 신뢰 구간으로 나눠야 합니다.
1단계: AWS 계정으로 관리 권한과 사고 범위를 분리한다
AWS Security Reference Architecture는 Network, Security Tooling, Log Archive 같은 전용 계정을 사용해 네트워크 운영, 보안 통제, 로그 보관의 책임을 분리하는 다중 계정 구조를 권장합니다.
생성형 AI 환경에서는 이 기본 구조에 AI 워크로드의 신뢰 경계를 반영한 계정을 추가할 수 있습니다.
| 계정 | 역할 | 핵심 통제 |
| Network Account | Transit Gateway, 중앙 방화벽, ingress·egress | 워크로드 계정의 임의 라우팅 우회 방지 |
| Security Tooling Account | 탐지·대응, 보안 통합 관리 | GuardDuty, Security Hub, SIEM 연계 |
| Log Archive Account | 감사 로그와 보안 로그의 장기 보관 | 변경 불가능 보관, 운영자 삭제 권한 분리 |
| AI Application Account | 사용자 세션, API, 프롬프트 오케스트레이션 | 세션 격리, API 인증, 요청 정책 |
| Model Account | 내부 모델, GPU, 모델 가중치 | 외부 직접 접근 차단, 추론 API만 공개 |
| Knowledge Account | RAG, Vector DB, 문서 메타데이터 | 데이터 등급·테넌트·문서 ACL 적용 |
| Tool Sandbox Account | MCP 도구, 코드 실행, 브라우저 자동화 | 짧은 수명 환경, 제한된 IAM, egress 차단 |
여기서 Network, Security Tooling, Log Archive 계정은 AWS SRA의 기반 계정입니다. 반면 Model, Knowledge, Tool Sandbox 계정은 모든 조직에 의무적으로 필요한 AWS 공식 계정명이 아니라, 생성형 AI의 위험과 규제 요구에 따라 추가할 수 있는 확장 설계안입니다.
계정 분리의 가장 큰 목적은 비용 구분이 아닙니다. 공격자가 AI Application Account의 권한을 획득하더라도 Model Account의 가중치를 가져가거나 Log Archive의 감사 기록을 삭제하지 못하도록 관리 평면의 경계를 만드는 것입니다.
다만 계정을 지나치게 세분화하면 운영 복잡도와 비용이 증가합니다. 데이터 민감도와 사용자 집단이 같고 IAM 역할로 충분히 통제할 수 있다면 일부 계정을 합칠 수 있습니다. 반대로 개발·검증·운영 환경의 위험이 다르거나 사용자 집단별 데이터 접근 범위가 다르면 계정을 더 나누는 편이 안전합니다.
2단계: VPC로 네트워크 신뢰 영역을 수평 분리한다
계정이 관리 권한과 사고 범위를 나눈다면 VPC는 실제 네트워크 통신 범위를 나눕니다.
Network Account
└─ Inspection VPC
AI Application Account
└─ Application VPC
Model Account
└─ Model VPC
Knowledge Account
├─ Knowledge VPC
└─ Document Inspection VPC
Tool Sandbox Account
└─ Tool Sandbox VPC
Application VPC에는 사용자 API와 프롬프트 오케스트레이터를 배치합니다. Model VPC는 내부 추론 API와 GPU 서버를 포함하지만 인터넷에서 직접 접근할 수 없게 합니다. Knowledge VPC에는 Vector DB와 RAG API를 두고, 문서 원본과 검색 결과에 동일한 접근 정책이 적용되도록 설계합니다.
Document Inspection VPC는 사용자가 업로드한 PDF, Office 문서, 압축 파일처럼 신뢰할 수 없는 콘텐츠를 파싱하는 구간입니다. 파일 형식 검증, 악성코드 검사, 매크로 제거, 텍스트 추출을 여기서 수행하고 검역을 통과한 결과만 Knowledge VPC로 전달합니다.
Tool Sandbox VPC는 MCP 서버나 코드 실행기가 실제 업무 시스템에 무제한 접근하지 못하도록 격리하는 환경입니다. 도구마다 필요한 목적지와 포트만 허용하고, 파일 시스템과 자격증명도 작업 단위로 짧게 유지해야 합니다.
3단계: 서브넷으로 역할과 장애 영역을 구체화한다
VPC 안에서도 모든 워크로드를 같은 Subnet에 넣으면 보안 그룹과 라우팅 정책이 복잡해집니다. 역할에 따라 Subnet을 나누면 장애와 접근 통제의 범위를 더 분명하게 만들 수 있습니다.
Application VPC
├─ Private App Subnet-A
├─ Private App Subnet-B
├─ Endpoint Subnet-A
└─ Endpoint Subnet-B
Knowledge VPC
├─ Knowledge API Subnet
├─ Vector DB Subnet
└─ Data Endpoint Subnet
가용 영역별 Subnet은 장애 격리를 위한 것이며, App·DB·Endpoint Subnet 구분은 역할 격리를 위한 것입니다. 두 기준을 함께 적용해야 합니다.
보안 그룹은 “같은 VPC이므로 허용”하지 않고 서비스 간 계약을 표현해야 합니다. 예를 들어 Application 오케스트레이터는 Knowledge API의 443 포트만 호출하고 Vector DB 포트에는 직접 접근하지 못하게 합니다. Vector DB 접근 권한과 문서 ACL 검사는 Knowledge API에서 강제합니다.
그림: AWS 계정·VPC·서브넷의 역할을 글의 설명 순서에 맞춰 재구성 · AWS Security Reference Architecture
Transit Gateway와 중앙 방화벽은 일반 통신을 통제한다
여러 VPC와 온프레미스 네트워크를 연결할 때는 Transit Gateway를 중심으로 Hub–Spoke 구조를 만들 수 있습니다. Network Account의 Inspection VPC에 AWS Network Firewall이나 검증된 NGFW를 배치하고 다음 트래픽을 검사합니다.
- 인터넷 ingress와 egress
- 일반적인 VPC 간 통신
- 온프레미스와 AWS 사이의 통신
- 관리망과 업무망 사이의 통신
Application VPC ─┐
Model VPC ───────┼→ Transit Gateway → Inspection VPC → 허용된 목적지
Knowledge VPC ───┤
Tool Sandbox VPC ┘
여기서 중요한 것은 Transit Gateway에 연결했다고 자동으로 모든 트래픽이 중앙 방화벽을 통과하는 것은 아니라는 점입니다. TGW Route Table, VPC Route Table, 방화벽 엔드포인트의 가용 영역 배치, 대칭 라우팅을 함께 검증해야 합니다.
워크로드 계정이 Inspection VPC를 우회하는 Internet Gateway, NAT Gateway, 임의 VPC Peering을 만들지 못하도록 Service Control Policy와 AWS Config 규칙을 사용할 수 있습니다. Flow Logs, Network Firewall 로그, DNS 로그는 운영 계정이 아닌 Log Archive Account로 전송합니다.
PrivateLink는 지정된 서비스만 단방향으로 노출한다
Model Gateway, Knowledge API, Tool Broker처럼 소비자 VPC가 제공자 VPC의 특정 서비스만 호출해야 할 때는 VPC 전체를 서로 라우팅하는 것보다 AWS PrivateLink가 적합할 수 있습니다.
Application VPC
└─ Interface VPC Endpoint
↓ 지정된 서비스만 호출
Model VPC
└─ Model Gateway Endpoint Service
PrivateLink는 소비자 VPC에서 제공자 서비스로의 사설 연결을 제공하며, 두 VPC 사이에 전체 IP 라우팅 권한을 만들지 않습니다. IP 주소가 겹치는 환경에서도 사용할 수 있다는 장점이 있습니다.
다만 PrivateLink가 애플리케이션 권한을 대신해 주지는 않습니다. Endpoint Policy, 서비스 인증, mTLS 또는 서명된 요청, 테넌트 검증을 함께 적용해야 합니다. 네트워크에서 도달할 수 있다는 사실과 해당 데이터에 접근할 권한이 있다는 사실은 별개의 문제입니다.
그림: 중앙 네트워크 검사와 서비스 단위 사설 연결을 비교해 재구성 · AWS SRA Network Account
외부 모델 호출은 Model Gateway와 Egress Proxy를 통과시킨다
OpenAI나 Anthropic 같은 외부 LLM API 호출은 TLS로 암호화됩니다. 일반적인 네트워크 방화벽은 목적지 도메인과 연결 정보는 확인할 수 있어도 HTTPS 본문에 들어 있는 프롬프트와 개인정보를 직접 판단하기 어렵습니다.
그래서 외부 모델 호출은 애플리케이션 계층의 Model Gateway 또는 통제된 Egress Proxy를 통과시키는 것이 좋습니다.
AI Application
→ Model Gateway
├─ 사용자·테넌트 인증
├─ 데이터 등급 확인
├─ PII·기밀정보 탐지
├─ 마스킹·가명처리
├─ 모델·지역·계약 정책 확인
├─ Rate Limit·비용 한도
└─ 감사 이벤트 생성
→ 내부 모델 또는 승인된 외부 Enterprise API
Model Gateway는 단순한 HTTP Forward Proxy가 아닙니다. 누가 어떤 업무로 어느 모델을 호출하는지 식별하고, 데이터 등급과 목적에 따라 허용 여부를 결정하는 정책 집행 지점입니다.
주민등록번호, 계좌번호, 건강정보처럼 명확한 패턴은 PII DLP로 탐지할 수 있습니다. 그러나 프로젝트 코드명, 미공개 계약 조건, 설계 문서 같은 조직 고유의 기밀은 정규식만으로 찾기 어렵습니다. 데이터 카탈로그, 문서 라벨, 사용자 업무 속성, 분류 모델을 함께 사용해야 합니다.
감사 로그에는 정책 판단에 필요한 정보가 있어야 하지만 원문 프롬프트 전체를 무조건 저장하면 로그 저장소가 또 다른 개인정보 시스템이 됩니다. 원문 저장 여부, 마스킹, 보존 기간, 접근 권한을 데이터 등급별로 결정해야 합니다.
N2SF의 C/S/O 등급을 AI 사용 정책과 연결한다
국가 망 보안체계인 N2SF는 국가·공공기관의 정보와 정보시스템을 기밀(Classified), 민감(Sensitive), 공개(Open) 등급으로 분류하고 등급에 맞는 통제를 선택하도록 합니다.
이 체계는 모든 민간기업에 동일하게 적용되는 일반 법령이라고 볼 수는 없습니다. 민간기업은 자신의 정보보호·개인정보·산업 규제 체계에 맞춰 사내 데이터 등급을 정의해야 합니다. 다만 C/S/O 방식은 AI 모델 사용 정책을 설계할 때 유용한 참고 틀이 될 수 있습니다.
| 등급 | AI 사용 원칙 | 권장 통제 |
| C: 기밀 | 외부 모델 전송 금지 | 강하게 격리된 내부 모델, 제한된 사용자, 반출 승인 |
| S: 민감 | 내부 모델 우선 | 외부 전송 시 비식별화, 사전 승인, DLP, 접근 기록 |
| O: 공개 | 승인된 외부 Enterprise API 사용 가능 | 기본 로깅, 악성 입력 필터, 비용·Rate Limit |
데이터 등급은 문서가 저장된 위치만으로 결정해서는 안 됩니다. 사용자의 입력, 검색된 RAG 문서, 도구가 조회한 결과, 모델의 응답을 모두 포함해 최종 요청의 유효 등급을 계산해야 합니다.
사용자 입력 등급: O
RAG 검색 문서 등급: S
도구 조회 결과 등급: S
────────────────────
최종 모델 요청 등급: S
공개 질문으로 시작했더라도 RAG가 민감한 내부 문서를 가져왔다면 외부 모델 호출 정책은 S 등급을 기준으로 다시 평가해야 합니다.
그림: Model Gateway 통제와 C/S/O 데이터 등급 결정을 결합해 재구성 · AWS SRA for AI — Secure AI Applications · N2SF 보안 가이드라인 1.0
공공·기업 환경의 망 연계는 세 가지 유형으로 나눠 본다
내부망 전용 AI
외부 연결을 차단한 내부망에서 내부 모델과 내부 지식베이스만 사용합니다. C 등급이나 강한 규제 대상 데이터를 처리할 때 적합하지만 모델 업데이트, 패치, 학습 데이터 반입을 위한 별도의 검증 절차가 필요합니다.
내부업무 AI의 외부망 연계
내부 사용자가 외부 최신 정보나 외부 모델 기능을 이용해야 하는 경우입니다. DMZ 중계 시스템이나 검증된 망 연계 구간에서 허용된 요청만 교환하고, 외부로 나가는 프롬프트는 DLP와 승인 정책을 통과시킵니다.
대민 AI의 내부 데이터 연계
챗봇 같은 대민 서비스는 외부 영역에 두되, 내부 데이터가 필요할 때 망 연계 구간의 Knowledge API를 통해 제한된 데이터만 전달합니다. 사용자가 입력한 비신뢰 콘텐츠가 내부망으로 그대로 들어오지 않도록 악성 파일 검사, 프롬프트 인젝션 방어, 스키마 검증을 적용합니다.
어느 유형이든 “망 연계 장비가 있으므로 안전하다”는 결론을 내려서는 안 됩니다. 파일·API·메시지별 허용 정책, 콘텐츠 검사, 사용자와 서비스 인증, 반출 승인, 감사가 함께 동작해야 합니다.
암호화와 키 관리는 데이터 경계와 분리한다
원시 문서, 임베딩, Vector DB, 학습 데이터, 모델 가중치, 감사 로그는 저장 시 암호화해야 합니다. 전송 구간에는 TLS를 적용하고 중요한 서비스 간 통신에는 mTLS를 고려할 수 있습니다.
암호키는 AWS KMS나 CloudHSM 같은 중앙 관리 체계에서 통제하고, 데이터 관리자와 키 관리자의 권한을 분리합니다. 특히 Log Archive의 암호키와 삭제 권한을 워크로드 운영자가 가지지 않게 해야 침해 후 증거 삭제를 어렵게 만들 수 있습니다.
암호화만으로 접근 통제가 해결되는 것은 아닙니다. 애플리케이션이 복호화 권한을 가지고 있다면 공격자는 애플리케이션을 통해 평문을 읽을 수 있습니다. KMS Key Policy, IAM, Encryption Context, 서비스 역할을 사용해 어떤 워크로드가 어떤 목적으로 복호화할 수 있는지 제한해야 합니다.
관리자 접근은 인터넷에서 목적지로 직접 연결하지 않는다
개인정보 처리 시스템이나 모델 가중치를 관리하는 고위험 환경에서는 일반 인터넷망에서 서버로 직접 SSH 또는 RDP 연결을 허용하지 않는 것이 좋습니다.
관리자 PC
→ MFA가 적용된 ZTNA 또는 Client VPN
→ 관리 전용 VDI 또는 Bastion
→ AWS Systems Manager Session Manager
→ 목적지 시스템
관리자 신원에는 MFA와 역할 기반 접근 제어를 적용하고, 상시 관리자 권한보다 승인된 시간 동안만 권한을 부여하는 Just-in-Time 방식을 고려합니다. 운영, 보안, 데이터, 키 관리 권한도 가능한 한 분리합니다.
Session Manager를 사용하면 인바운드 SSH 포트를 열지 않고도 관리 세션을 만들 수 있습니다. 다만 Session Manager 자체 권한이 과도하면 새로운 우회 경로가 되므로 대상 인스턴스, 실행 가능한 명령, 세션 기록 저장 위치를 제한해야 합니다.
CloudTrail, Session Manager 세션 로그, 운영체제 감사 로그, 데이터베이스 접근 로그는 SIEM 또는 Security Tooling Account로 전송합니다. 관리자가 자신의 작업 기록을 임의로 삭제할 수 없는 구조가 필요합니다.
그림: 관리자 전용 접근 경로와 중앙 감사 구조를 재구성 · AWS SRA for AI
실제 구축 순서
처음부터 모든 계정과 VPC를 한 번에 만들기보다 다음 순서로 진행하는 편이 현실적입니다.
1. 데이터와 흐름을 먼저 분류한다
사용자 입력, RAG 문서, 모델 응답, 도구 결과가 어디서 생성되고 어디로 이동하는지 그립니다. 각 데이터에 C/S/O 또는 사내 등급을 부여합니다.
2. 신뢰 경계를 계정과 VPC에 매핑한다
운영 권한, 데이터 민감도, 사용자 집단, 사고 영향이 다른 구성 요소를 분리합니다. 계정 분리가 필요한지 VPC와 IAM 역할만으로 충분한지도 함께 판단합니다.
3. 허용 흐름을 먼저 정의한다
“무엇을 막을 것인가”보다 “누가 어떤 서비스의 어느 API를 호출할 수 있는가”를 표로 만듭니다. 일반 VPC 라우팅이 필요한 흐름과 PrivateLink가 적합한 흐름을 구분합니다.
4. Model Gateway와 Tool Broker를 정책 집행 지점으로 만든다
외부 모델 호출과 MCP 도구 호출이 각각 우회되지 않도록 단일 통제 경로를 만듭니다. 네트워크 경로뿐 아니라 SDK와 자격증명 배포도 이 통제 지점을 거치게 해야 합니다.
5. 로그와 키를 워크로드 밖으로 분리한다
Log Archive와 KMS 권한을 운영 계정에서 분리하고, 로그 무결성과 보존 정책을 검증합니다.
6. 우회와 실패를 테스트한다
임의 NAT Gateway 생성, VPC Peering 우회, 외부 API 직접 호출, 민감정보 프롬프트 입력, 악성 PDF 업로드, MCP 도구의 과도한 권한, 관리자 계정 탈취 시나리오를 테스트합니다.
구축 점검표
- Network, Security Tooling, Log Archive의 관리 책임이 분리되어 있는가
- 모델, 지식베이스, 도구 실행 환경의 신뢰 경계를 구분했는가
- 워크로드 계정이 중앙 egress와 Inspection VPC를 우회할 수 없는가
- PrivateLink로 노출한 서비스에도 애플리케이션 인증과 권한 검사가 있는가
- 외부 모델 API 자격증명을 Application이 직접 가지지 않는가
- 프롬프트와 응답에 데이터 등급과 DLP 정책이 적용되는가
- RAG 검색 결과의 등급이 최종 모델 호출 정책에 반영되는가
- 비신뢰 문서가 별도 검역 환경에서 파싱되는가
- MCP 도구와 코드 실행 환경이 짧은 수명 Sandbox에서 동작하는가
- HTTP 성공, 모델 정책 차단, 도구 업무 오류를 별도 지표로 보는가
- 로그 원문 저장이 새로운 개인정보 위험을 만들지 않는가
- 관리자 접속에 MFA, 관리 전용 경로, 세션 기록이 적용되는가
- 암호키와 로그 삭제 권한이 워크로드 운영자에게 집중되지 않았는가
정리
생성형 AI 시스템의 망 분리는 모델 서버를 Private Subnet에 넣는 것으로 끝나지 않습니다.
계정 격리
→ 관리 권한과 사고 범위 분리
VPC·서브넷 격리
→ 네트워크 신뢰 경계와 역할 분리
Transit Gateway·Inspection VPC
→ 일반 통신의 중앙 통제
PrivateLink
→ 지정된 서비스만 제한적으로 노출
Model Gateway·DLP
→ HTTPS 안의 프롬프트와 데이터 정책 통제
C/S/O 또는 사내 데이터 등급
→ 모델과 망 연계 방식 결정
ZTNA·VDI·Session Manager
→ 관리자 우회 경로 차단과 감사
가장 중요한 원칙은 네트워크 위치를 신뢰의 근거로 사용하지 않는 것입니다. 내부망의 사용자 입력도 악성일 수 있고, PrivateLink로 연결된 서비스도 잘못된 권한을 가질 수 있으며, 암호화된 HTTPS 요청 안에도 유출되면 안 되는 데이터가 들어갈 수 있습니다.
따라서 생성형 AI의 안전한 망 분리는 계정과 VPC를 나누는 작업이 아니라, 데이터가 생성되고 검색되고 모델과 도구로 전달되는 전체 경로에 동일한 등급·권한·검증·감사 정책을 적용하는 작업입니다.
참고 자료
'일반IT > IT보안' 카테고리의 다른 글
| 패스키는 비밀번호를 어떻게 없앨까 — WebAuthn과 FIDO2의 동작 원리 (1) | 2026.07.31 |
|---|---|
| LLM에서 개인정보를 어떻게 필터링할까 — 입력부터 RAG·출력·로그까지 4단계 설계 (0) | 2026.07.30 |
| OpenAI 에이전트는 어떻게 허깅페이스를 침해했나 — 2026년 7월 AI 보안 사고 정리 (0) | 2026.07.29 |
| 브라우저에 내장된 인증기관 목록은 무엇일까 — Root Store와 HTTPS 신뢰 구조 이해하기 (0) | 2026.07.23 |
| 보안 업무에서 활용 가능한 생성형 AI 사례 — SOC 분석부터 클라우드 보안까지 (0) | 2026.07.23 |
