AI 리서치2026년 9월 15일5분 읽기

3편. 폐쇄망에서 AI를 굴린다는 것

Jay

SSM USA - AI 박사

인터넷이 끊기는 순간, 다운로드는 물류가 되고 업데이트는 프로젝트가 된다 폐쇄망 AI 구축의 어려움은 모델 실행 자체보다 반입, 의존성, 버전 관리, 보안 검토와 운영 절차에 있습니다. 인터넷 환경에서는 몇 분이면 끝나는 패키지 설치와 모델 변경이 폐쇄망에서는 별도의 승인과 반입 절차가 됩니다. 컨테이너와 오프라인 리허설, Release Bundle, 라이선스·CVE 관리, RAG 접근권한과 감사 추적까지 실제 프로젝트에서 놓치기 쉬운 폐쇄망 AI 구축의 핵심을 정리합니다.

3편. 폐쇄망에서 AI를 굴린다는 것 — 인터넷이 끊기는 순간 달라지는 것들

국내에서 AI 구축을 하다 보면 제일 자주 듣는 말이 있습니다.

"저희는 망분리라서요."

짧은 한마디인데 이 말이 나오면 프로젝트의 성격이 달라집니다.

인터넷이 되는 환경에서는 pip install 한 줄이면 끝날 일이 반입 신청이 되고, 컨테이너 레지스트리에서 이미지를 한 번 받아오면 끝날 일이 보안 검토 대상이 됩니다.

모델 가중치 하나를 바꾸는 것도 단순한 파일 교체가 아니라 변경관리 절차가 될 수 있습니다.

그런데 제안서에는 보통 이렇게 한 줄로 적힙니다.

폐쇄망 환경 지원

문제는 이 한 줄 뒤에 들어 있는 일이 너무 많다는 것입니다.

폐쇄망에서 AI를 굴린다는 것은 단순히 **"인터넷 없이 설치한다"**는 뜻이 아닙니다.

개발, 설치, 모델 반입, 패치, 라이선스 검토, 취약점 대응, 로그 관리, 버전 변경까지 AI 소프트웨어 공급망 전체를 오프라인 방식으로 다시 설계한다는 뜻에 가깝습니다.

이번 편에서는 그 한 줄 뒤에 실제로 무엇이 숨어 있는지 이야기해보겠습니다.

먼저, 규제는 실제로 움직였습니다

금융권을 기준으로 보면 망분리 제도는 분명히 변하고 있습니다.

금융위원회는 2024년 8월 **「금융분야 망분리 개선 로드맵」**을 발표하면서 생성형 AI 활용, SaaS 이용 확대, 연구·개발 환경 개선을 단계적으로 추진하겠다고 밝혔습니다.

그리고 2026년 4월 20일부터 「전자금융감독규정 시행세칙」 개정이 시행되면서 금융회사와 전자금융업자는 일정한 보안통제를 전제로 내부 업무망에서 SaaS를 활용할 수 있게 됐습니다.

다만 표현을 정확히 볼 필요가 있습니다.

"망분리가 풀렸다"는 뜻은 아닙니다.

아무 SaaS나 연결해도 된다는 의미도 아닙니다.

금융당국이 발표한 제도에서는 침해사고 대응기관의 평가를 거친 SaaS 이용, 접속 단말 보호대책, 정보보호통제 이행 등이 요구됩니다.

또 이용자의 고유식별정보나 개인신용정보를 처리하는 경우에는 일반적인 SaaS 망분리 예외 대상에서 제외되며, 가명정보 활용에도 별도 절차가 적용됩니다.

생성형 AI도 방향은 완화 쪽으로 움직이고 있습니다.

2024년 로드맵에서는 혁신금융서비스를 통해 생성형 AI 활용을 허용하기 시작했고, 2026년에는 생성형 AI 모델 변경 절차 간소화와 보안 목적 AI 활용을 위한 추가적인 망분리 완화 조치까지 이어졌습니다.

즉 방향은 다음과 같습니다.

과거

망을 끊어 놓는다
      ↓
보안을 확보한다

현재

필요한 외부 기술을 활용한다
      ↓
위험을 평가한다
      ↓
통제한다
      ↓
결과에 책임진다

금융당국이 제시한 방향 역시 **"자율보안-결과책임"**에 가깝습니다.

하지만 여기서 또 하나의 오해가 생깁니다.

"그럼 앞으로 온프레미스 AI는 필요 없는 것 아닌가?"

그렇지는 않습니다.

협업도구나 일반 업무 SaaS는 외부 서비스를 활용할 수 있는 길이 넓어질 수 있지만, 핵심 업무 데이터와 민감정보를 사용하는 AI까지 모두 외부로 나간다는 의미는 아닙니다.

금융뿐 아니라 공공, 국방, 제조 보안구역 등에서도 조직별 정책과 업무 성격에 따라 폐쇄 또는 강하게 통제된 환경은 계속 존재합니다.

결국 폐쇄망이 없어지는 것이 아니라 워크로드가 나뉘는 것에 가깝습니다.

밖으로 나가도 되는 AI와
안에서 돌아야 하는 AI를 구분하는 시대입니다.

폐쇄망 프로젝트가 어려운 이유는 모델이 아닙니다

처음 폐쇄망 AI 프로젝트를 접하면 이런 질문을 많이 합니다.

"인터넷 없이 LLM이 돌아가나요?"

물론 돌아갑니다.

모델 가중치와 추론 엔진, 필요한 라이브러리가 준비되어 있다면 인터넷 연결 자체가 추론의 필수조건은 아닙니다.

진짜 어려운 것은 그 환경을 만들고 계속 유지하는 과정입니다.

일반적인 개발환경에서는 개발자가 의식하지 못하는 순간에도 인터넷에 계속 의존합니다.

OS 패키지를 내려받습니다.
Python 패키지를 설치합니다.
컨테이너 이미지를 Pull 합니다.
Model Hub에서 모델과 Tokenizer를 받습니다.
취약점 데이터베이스를 업데이트합니다.
라이선스 정보를 조회합니다.
모니터링 Agent를 설치합니다.
보안 패치를 내려받습니다.

인터넷 환경에서는 몇 초에서 몇 분짜리 작업입니다.

폐쇄망에서는 이 모든 것이 반입 대상이 됩니다.

그래서 폐쇄망의 본질적인 차이는 네트워크 속도가 아닙니다.

온라인에서는 Dependency이고,
폐쇄망에서는 Supply Chain입니다.

파일 하나 때문에 3주가 사라지는 구조

가상의 프로젝트를 하나 보겠습니다.

1주차
보안팀과 반입 절차 협의
→ 반입 목록과 보안검토 자료 요청

2주차
반입 파일 취합
→ Container Image
→ Model Weight
→ Python Wheel
→ OS Package
→ GPU 관련 Package

3주차
1차 보안 검토 및 반입

4주차
설치 시작

→ 특정 Library 누락 발견
→ CUDA / Driver 조합에서 필요한 Package 1개 미포함

외부망이라면?
→ 몇 분 안에 Download

폐쇄망이라면?
→ 재반입 신청

5~6주차
2차 보안 검토 및 승인

7주차
파일 반입
→ 설치 재개

파일 하나 때문에 3주가 사라집니다.

그리고 이건 단순히 개발자가 실수해서 발생하는 문제라고 보기 어렵습니다.

현대 AI 애플리케이션의 의존성은 생각보다 깊습니다.

AI Application
├─ LLM Runtime
│  ├─ CUDA Library
│  ├─ PyTorch
│  ├─ Attention Library
│  └─ Tokenizer
├─ Embedding Model
├─ Reranker
├─ Vector DB Client
├─ API Framework
├─ Monitoring Agent
└─ OS Library

이 중 하나만 빠져도 설치가 멈출 수 있습니다.

그래서 폐쇄망 프로젝트에서 가장 비싼 오류는 코드 버그가 아니라

"반입하지 않은 파일"

일 때가 있습니다.

원칙 1. 의존성을 완전히 동결합니다

첫 번째 원칙은 단순합니다.

버전을 고정합니다.

폐쇄망 프로젝트에서 가장 위험한 표현 중 하나가 이것입니다.

"최신 버전으로 설치하겠습니다."

최신 버전은 날짜에 따라 달라집니다.

외부 개발환경에서 오늘 설치된 최신 버전과 한 달 뒤 고객사에 반입되는 최신 버전이 다르면 이미 동일한 환경이 아닙니다.

그래서 최소한 다음 항목은 고정하는 것이 좋습니다.

OS Version
GPU Driver Version
Container Runtime Version
NVIDIA Container Toolkit Version
CUDA Runtime Version
Python Version
Inference Engine Version
Framework Version
Model Version
Tokenizer Version
Embedding Model Version
Reranker Version
Vector DB Version
Application Version

컨테이너 이미지도 가능하면 latest 태그를 사용하지 않습니다.

my-ai-runtime:latest

보다는

my-ai-runtime:1.4.2
sha256:xxxx...

처럼 실제 반입한 이미지가 무엇인지 재현할 수 있어야 합니다.

모델 역시 마찬가지입니다.

"Qwen 모델"

이라고 적는 것이 아니라,

Model
Version
Quantization
Tokenizer
Source
Hash

까지 관리해야 합니다.

"컨테이너로 싸면 끝나는 것 아닌가요?"

여기서 자주 나오는 이야기가 있습니다.

"Docker 이미지로 통째로 가져가면 되는 것 아닌가요?"

맞습니다.

폐쇄망 구축에서 컨테이너는 매우 좋은 방법입니다.

Application과 Python Library, CUDA User-space Library 등을 이미지에 포함시키면 현장에서 외부 저장소를 호출해야 하는 가능성이 크게 줄어듭니다.

하지만 중요한 점이 있습니다.

컨테이너가 모든 의존성을 없애주는 것은 아닙니다.

GPU 환경에서는 특히 Host와 Container의 경계가 중요합니다.

구조를 단순화하면 다음과 같습니다.

[ Host ]

Linux Kernel
NVIDIA Driver
Container Runtime
NVIDIA Container Toolkit

        │
        ▼

[ Container ]

CUDA Runtime
PyTorch
vLLM / SGLang 등
Application
Model Runtime

컨테이너 내부를 완벽하게 동결했더라도 Host의 GPU Driver와 Runtime 조합이 맞지 않으면 애플리케이션이 정상적으로 시작하지 못할 수 있습니다.

NVIDIA의 Container Toolkit도 GPU 컨테이너를 실행하려면 Host에 호환 가능한 NVIDIA Driver가 필요하다고 명시하고 있습니다.

즉 폐쇄망 반입 단위는 단순히

docker-image.tar

파일 하나가 아닙니다.

Host + Driver + Runtime + Image + Model

전체 조합이 하나의 배포 단위입니다.

그래서 저는 폐쇄망 GPU 구축에서 Compatibility Matrix를 별도 산출물로 두는 편을 권합니다.

원칙 2. 외부에 동일 환경을 만들고 인터넷을 끊습니다

두 번째 원칙은 리허설입니다.

폐쇄망과 최대한 동일한 환경을 외부에 먼저 만듭니다.

동일 OS
동일 GPU
동일 Driver
동일 Container Runtime
동일 Container Image
동일 Model
동일 Configuration

그리고 설치를 처음부터 끝까지 한 번 완주합니다.

여기까지 하는 프로젝트는 많습니다.

그런데 저는 한 단계 더 해야 한다고 봅니다.

네트워크를 끊고 다시 설치해 보는 것입니다.

이 과정이 중요합니다.

설치 스크립트를 다 만들었다고 생각했는데 실행 중 갑자기 인터넷 저장소에 접근하는 경우가 있습니다.

apt repository
pip repository
npm registry
container registry
model hub
license server
CVE database

평소에는 너무 자연스럽게 동작하기 때문에 개발자도 외부 연결이 발생했다는 사실을 인지하지 못할 수 있습니다.

네트워크를 차단하고 설치해 보면 숨은 의존성이 바로 드러납니다.

폐쇄망에 넣기 전에 인터넷을 끊고 처음부터 끝까지 설치해봅니다.

저는 이 과정을 사실상 Air-gap Acceptance Test라고 봅니다.

현장에서 처음 설치해 보는 것은 리허설이 아니라 도박에 가깝습니다.

원칙 3. 반입 묶음을 하나의 산출물로 관리합니다

반입 파일을 개발자가 필요할 때마다 하나씩 모으면 빠지는 것이 생깁니다.

그래서 처음부터 Release Bundle을 정의하는 것이 좋습니다.

1차 반입 체크리스트 예시

Application Container Image
LLM Inference Engine Image
모델 가중치
Tokenizer / Config
Quantization 관련 파일
Embedding Model
Reranker Model
Vector DB 설치 패키지
OS Package Offline Repository
Python Wheel Archive
GPU Driver 설치 파일
NVIDIA Container Toolkit
Monitoring / Logging Agent
초기 Configuration
DB Schema
오픈소스 라이선스 목록
모델 라이선스 원문
SBOM
파일별 SHA-256
설치 절차서
Rollback 절차서
Compatibility Matrix

중요한 것은 이 목록을 개발자의 개인 체크리스트로 두지 않는 것입니다.

WBS에 넣어야 합니다.

M1. 외부 개발환경 구성
M2. Version Freeze
M3. Offline Installation Rehearsal
M4. Release Bundle 생성
M5. 보안성 검토
M6. 1차 반입
M7. 폐쇄망 설치
M8. 설치 검증

"환경 구성"

이라는 한 줄 아래 숨겨 놓으면 관리되지 않습니다.

반입 자체가 프로젝트의 마일스톤이어야 합니다.

폐쇄망 안에도 저장소가 필요합니다

폐쇄망이라고 해서 모든 서버에 설치파일을 하나씩 옮기는 방식으로 운영하면 두 번째 업데이트부터 힘들어집니다.

규모가 있다면 폐쇄망 내부에도 최소한의 Software Supply Chain을 만드는 것이 좋습니다.

예를 들면 다음과 같습니다.

[ 인터넷 가능 구간 ]

Source / Package / Model
        ↓
검증용 Staging
        ↓
Vulnerability Scan
License Review
Malware Scan
Checksum 생성
        ↓
승인된 반입 절차

============================

        ↓

[ 폐쇄망 ]

Private Container Registry
Offline Package Repository
Internal Model Repository
        ↓
Dev / Test / Prod

즉 외부에서 가져온 파일을 바로 운영서버에 설치하는 것이 아니라,

검증 → 승인 → 반입 → 내부 저장 → 배포

라는 파이프라인을 만드는 것입니다.

이 체계가 한번 만들어지면 두 번째 AI 프로젝트부터 난이도가 크게 낮아집니다.

실제로 첫 번째 폐쇄망 AI 프로젝트에서 구축해야 하는 중요한 자산 중 하나는 모델이 아니라 이 배포 체계 자체입니다.

모델 파일도 Software Supply Chain입니다

LLM을 단순한 하나의 파일로 보면 또 문제가 생깁니다.

하나의 모델에도 여러 구성요소가 붙습니다.

Model Weight
Tokenizer
Configuration
Generation Config
Quantization Config
Custom Code
License
Model Card

경우에 따라 모델 저장소의 별도 코드를 실행하는 구조가 포함될 수도 있습니다.

따라서 모델도 일반 소프트웨어와 마찬가지로 출처, 버전, Hash와 라이선스를 관리해야 합니다.

OWASP의 GenAI Security Top 10에서도 Supply Chain과 Sensitive Information Disclosure를 주요 위험으로 다루고 있습니다.

AI 공급망에는 일반적인 오픈소스 라이브러리뿐 아니라 사전학습 모델과 데이터, 외부 구성요소까지 포함됩니다.

그래서 모델 반입 목록도 최소한 이렇게 관리하는 것이 좋습니다.

항목관리 내용Model ID정확한 모델명VersionRevision / ReleaseSource원본 출처License사용 조건HashSHA-256 등QuantizationFP16 / FP8 / INT8 등반입일승인·반입 일자적용환경Dev / Test / Prod

"30B 모델 반입"

정도로 적는 것은 부족합니다.

어떤 Artifact가 들어갔는지가 재현 가능해야 합니다.

라이선스는 반입 전에 끝내야 합니다

오픈웨이트 모델이라고 해서 모두 같은 조건으로 사용할 수 있는 것은 아닙니다.

최소한 다음은 확인해야 합니다.

상업적 이용이 가능한가
특정 사용자 규모나 매출 관련 조건이 있는가
모델 수정 또는 파생 모델 생성이 가능한가
재배포 조건은 무엇인가
출력물 이용에 별도 제한이 있는가
표시 또는 고지 의무가 있는가

그리고 LLM만 보는 것으로는 부족합니다.

LLM
Embedding Model
Reranker
Vector DB
OCR Engine
Inference Engine
Monitoring Tool
Application Library

전체 Stack을 봐야 합니다.

PoC에서는 넘어갔던 라이선스 이슈가 운영 전환 단계에서 발견되면 모델이나 솔루션을 바꾸는 상황도 생길 수 있습니다.

그래서 라이선스 검토 역시 마지막 법무 검토가 아니라 반입 Gate 앞의 필수 절차로 보는 것이 좋습니다.

폐쇄망에서는 패치도 하나의 프로젝트입니다

인터넷 환경에서는 패치가 상대적으로 단순합니다.

Repository를 업데이트하고 Package 또는 Image를 올립니다.

폐쇄망에서는 다음과 같은 과정을 거칠 수 있습니다.

CVE 확인
↓
영향도 분석
↓
대상 Package 확인
↓
외부 환경에서 Patch Test
↓
신규 Image 생성
↓
보안 검토
↓
반입
↓
폐쇄망 적용
↓
Regression Test

즉 패치 한 번이 작은 구축 프로젝트가 됩니다.

그래서 계약서에 단순히

"1년 유지보수"

라고 적는 것만으로는 부족할 수 있습니다.

최소한 다음 정도는 정해야 합니다.

항목결정할 내용정기 취약점 점검월/분기/반기CVE 영향도 분석수행 주체Critical Patch대응 기준Container 재빌드유지보수 포함 여부Model Version 변경패치 또는 변경개발 여부GPU Driver 업데이트수행 범위재반입비용과 절차보안 검증담당 조직Rollback기준과 책임

폐쇄망은 외부 연결을 제한해 공격 표면을 줄일 수 있지만,

한 번 반입된 취약한 구성요소가 자동으로 업데이트되는 환경도 아닙니다.

따라서

"인터넷이 없으니 안전하다"

보다는

"외부 연결이 적은 대신 변경과 패치를 계획적으로 관리해야 한다"

라고 보는 편이 맞습니다.

감사 추적은 선택이 아닙니다

규제 산업의 AI에서는 "답이 맞았는가"만큼 중요한 질문이 있습니다.

"왜 그 답이 나왔는가?"

사고가 발생하거나 감사가 들어오면 결국 이 질문으로 돌아옵니다.

누가 질문했는가
↓
어떤 문서를 검색했는가
↓
어떤 Chunk가 전달됐는가
↓
어떤 Prompt를 사용했는가
↓
어떤 Model Version이 답했는가
↓
최종 응답은 무엇이었는가

그래서 폐쇄망 RAG 시스템이라면 최소한 다음 정도는 추적 가능해야 합니다.

사용자 또는 Session 식별정보
질의 시간
질의 내용
참조 문서 ID
Chunk ID와 원문 위치
Retrieval Score
Prompt Version
Model Version
Embedding Version
Index Version
최종 응답
오류 및 예외 로그

물론 질의와 응답 자체에 개인정보나 민감정보가 포함될 수 있으므로 무조건 모든 내용을 무기한 저장하는 것 역시 답은 아닙니다.

마스킹 대상, 저장 범위, 보존기간과 로그 접근권한을 함께 설계해야 합니다.

벡터 DB에 넣는 순간 권한이 사라질 수 있습니다

RAG를 구축할 때 제가 특히 중요하게 보는 부분이 있습니다.

문서 접근권한입니다.

가상의 사내 AI를 생각해보겠습니다.

Vector DB 하나에 다음 자료를 넣었습니다.

사내 규정
인사 규정
급여 테이블
임원 회의록
재무자료
영업자료

검색은 아주 잘 됩니다.

그런데 일반 직원이 이렇게 질문합니다.

"우리 팀장 직급의 급여 테이블이 어떻게 되죠?"

검색 단계에서 접근권한을 확인하지 않는다면 급여 테이블의 Chunk가 검색될 수 있습니다.

그리고 그 Chunk가 LLM Context에 들어가면 모델은 아주 친절하게 요약해서 답할 수 있습니다.

이것은 Hallucination이 아닙니다.

정확하게 답해서 발생한 정보유출 사고입니다.

이 문제를 System Prompt 하나로 막으려고 해서는 안 됩니다.

"급여 정보는 답변하지 마세요."

이 문장은 보조적인 통제는 될 수 있지만 Access Control은 아닙니다.

권한은 검색 단계에서 먼저 적용되어야 합니다.

사용자 인증
↓
사용자 조직 / Role 확인
↓
Retrieval Query
+
ACL Metadata Filter
↓
권한이 있는 문서만 검색
↓
LLM Context 구성
↓
Answer

상황에 따라 아예 인덱스를 분리할 수도 있습니다.

일반규정 Index
인사 Index
경영진 Index
감사 Index

또는 문서 Metadata에 권한정보를 포함합니다.

department = "HR"
security_level = 3
allowed_role = ["HR_MANAGER"]

핵심은 간단합니다.

LLM에게 비밀을 지키라고 부탁하는 것이 아니라
애초에 볼 수 없는 문서를 LLM에게 전달하지 않는 것입니다.

이것이 RAG 보안에서 중요한 원칙입니다.

개발망에서 운영망으로 어떻게 넘어갈지도 설계해야 합니다

폐쇄망 프로젝트에서는 최초 설치에만 관심을 갖기 쉽습니다.

하지만 개발 결과물이 운영망으로 이동하는 과정도 처음부터 설계해야 합니다.

[ 외부 또는 개발 환경 ]

개발 / Build
↓
Offline Test
↓
Version Freeze
↓
Security Scan
↓
Release Bundle

======================
보안 승인 / 반입
======================

↓
[ 내부 검증 환경 ]

설치
↓
Integration Test
↓
Security Test
↓
운영 이관 승인

↓
[ 운영 환경 ]

Production

폐쇄망에서는 개발자가 운영서버에서 직접 git pull 하는 형태로 운영하기 어렵습니다.

코드 이동 자체가 Release Process가 됩니다.

따라서 Agile 개발 주기와 반입 주기도 맞춰야 합니다.

개발팀은 매주 Sprint를 끝내는데 보안 반입에 2주가 걸린다면 애플리케이션 개발 방식도 거기에 맞게 조정해야 합니다.

제안 단계부터 보안 Gate를 일정에 넣어야 합니다

폐쇄망 프로젝트 일정이 자주 밀리는 이유 중 하나는 일반 시스템 구축과 동일한 WBS를 사용하기 때문입니다.

분석
↓
설계
↓
개발
↓
테스트
↓
오픈

폐쇄망이라면 이것으로 부족합니다.

보안정책 확인
↓
반입절차 합의
↓
Architecture 확정
↓
Version Freeze
↓
Offline Rehearsal
↓
보안성 검토
↓
1차 반입
↓
환경 구축
↓
통합 테스트
↓
추가 반입
↓
보안 검증
↓
운영 이관

특히 1차 반입일을 프로젝트의 공식 마일스톤으로 두는 것이 중요합니다.

그러면 개발팀도 그 날짜를 기준으로 Version Freeze를 할 수 있습니다.

반대로 반입을

"필요할 때 하면 되는 행정업무"

정도로 생각하면 개발은 계속 바뀌고 반입 파일은 계속 늘어납니다.

결국 설치 직전까지 정확한 Release Bundle을 아무도 모르는 상황이 만들어집니다.

RFP에 한 페이지를 추가한다면

폐쇄망 AI RFP에 제가 한 페이지를 추가할 수 있다면 다음 항목을 넣겠습니다.

구분확인 항목망 구성인터넷망·업무망·개발망·운영망 구조반입반입 절차, 승인 주체, 평균 소요일저장소내부 Git, Container Registry, Package RepositoryGPUDriver 설치·변경 권한 및 담당 조직Model모델 반입·검증 절차보안Malware/CVE/라이선스 검토 방식데이터개인정보·신용정보·기밀정보 처리 범위인증SSO/AD 등 사용자 인증 연계권한문서 ACL과 RAG 권한 연계 방식로그질의·응답·검색·모델 버전 기록 정책운영정기 및 긴급 패치 절차변경Model/Prompt/Index 변경 승인 기준외부연계허용 API 또는 SaaS 범위일정정기 반입 Window와 보안검토 소요기간

이 정보가 비어 있다면 정확한 구축 일정을 제시하기 어렵습니다.

폐쇄망 사업에서는 개발자의 개발속도만큼 조직의 승인속도가 일정에 영향을 주기 때문입니다.

제안서에도 전제조건을 남겨야 합니다

2편에서는 전력과 냉방 조건을 제안서에 남겨야 한다고 이야기했습니다.

폐쇄망도 같습니다.

예를 들어 다음과 같이 쓸 수 있습니다.

[제안서 문구 예시]
본 사업의 폐쇄망 구축 일정은 고객사의 보안성 검토, 소프트웨어·모델·컨테이너 이미지 등 설치 파일의 반입 승인 및 시스템 접근 권한이 계획된 일정에 따라 제공되는 것을 전제로 합니다. 고객사 보안정책에 따른 추가 검토 또는 반입 지연으로 일정 영향이 발생하는 경우 상호 협의를 통해 프로젝트 일정을 조정합니다.

또는 반입 범위를 조금 더 명확히 합니다.

1차 반입 대상은 모델 가중치, 추론 엔진, 컨테이너 이미지, 오픈소스 패키지 및 GPU 관련 설치 파일이며, 상세 반입목록과 파일 Hash는 반입 전 별도 제출합니다.

이 문장은 책임을 피하기 위한 것이 아닙니다.

프로젝트의 실제 Critical Path를 문서에 드러내는 것입니다.

폐쇄망 AI의 핵심은 설치가 아니라 변경입니다

첫 설치가 성공하면 끝날 것 같지만 운영이 시작되면 더 어려운 질문이 생깁니다.

모델을 바꾸면 어떻게 할 것인가?

Embedding Model을 바꾸면 어떻게 할 것인가?

Critical CVE가 발견되면 누가 이미지를 다시 만들 것인가?

Vector Index를 재구축하면 어떤 버전으로 기록할 것인가?

Prompt 하나를 수정하는 것도 운영 변경인가?

결국 폐쇄망 AI를 잘 구축한다는 것은 특정 시점의 시스템을 한번 설치해 놓는 것이 아닙니다.

변경 가능한 시스템을 통제 가능한 방법으로 운영하는 것입니다.

그래서 저는 폐쇄망 AI 운영의 기본 단위를 다음 네 가지로 봅니다.

Artifact
Version
Approval
Trace

무엇이 들어왔고,

어떤 버전이며,

누가 승인했고,

어디에 적용됐는지를 남깁니다.

이 네 가지가 있으면 모델이 바뀌어도 관리할 수 있습니다.

없으면 시간이 지날수록 시스템이 블랙박스가 됩니다.

인터넷이 끊기는 순간 프로젝트 관리 방식이 달라집니다

폐쇄망에서 AI 모델을 실행하는 것 자체는 어렵지 않을 수 있습니다.

진짜 어려운 것은 그 모델 주변의 모든 것을 운영 가능하게 만드는 일입니다.

패키지를 어떻게 가져올지,

모델을 어떻게 검증할지,

취약점을 어떻게 패치할지,

버전을 어떻게 기록할지,

누가 어떤 문서를 검색할 수 있는지,

다음 버전을 어떻게 다시 반입할지를 정해야 합니다.

그래서 폐쇄망 프로젝트의 일정은 기술 난이도만으로 결정되지 않습니다.

절차와 공급망이 결정합니다.

착수 첫 주에 개발자들만 모아 놓고 개발부터 시작하는 것보다 보안 담당자와 인프라 담당자를 불러 다음 세 가지부터 확인하는 편이 낫습니다.

반입은 어떻게 합니까?

평균 며칠 걸립니까?

운영 이후 패치도 같은 절차를 다시 타야 합니까?

이 세 질문의 답을 모른 채 작성한 일정은 아직 완성된 일정이 아닙니다.

1편에서는 GPU 수량을 계산했습니다.

2편에서는 그 GPU를 켤 전기와 열을 이야기했습니다.

3편에서는 그 서버 안으로 소프트웨어와 모델을 어떻게 넣을 것인가를 이야기했습니다.

AI 인프라는 결국 GPU를 사서 끝나는 사업이 아닙니다.

연산 자원을 준비하고,

시설을 준비하고,

소프트웨어 공급망을 준비해야 합니다.

그리고 폐쇄망에서는 마지막 단계가 생각보다 오래 걸립니다.

인터넷이 끊기는 순간, 다운로드는 물류가 되고 업데이트는 프로젝트가 됩니다.

이 문장을 기억하면 폐쇄망 AI 구축의 상당 부분을 이해한 것입니다.

다음 편은 순서 이야기입니다.

4편. 하드웨어와 모델 — 무엇을 먼저 정해야 하는가

GPU를 먼저 사고 모델을 맞춰야 할까요?

모델을 먼저 고르고 GPU를 사야 할까요?

현장에서 계속 반복되는 이 순서 문제를 다음 편에서 다뤄보겠습니다.

참고자료

금융위원회, 「금융분야 망분리 개선 로드맵」, 2024.08.13.
금융위원회·금융감독원, 「4월 20일부터 금융회사는 내부 업무망에서 클라우드 기반 응용소프트웨어(SaaS)를 보다 원활하게 활용할 수 있습니다」, 2026.04.20.
금융보안원, 「내부업무망 SaaS 망분리 예외 적용에 따른 보안 해설서」, 2026.04.20.
금융위원회, 「생성형 AI 활용을 위한 혁신금융서비스 지정 절차가 간소화되었습니다」, 2026.04.15.
금융위원회, 「금융권 AI 전환 본격화! 금융분야 망분리 규제를 완화하여 혁신은 넓게, 보안은 더 단단하게 하겠습니다」, 2026.05.26.
금융위원회, 「보다 다양한 금융회사들이 AI 보안위협에 철저히 대비할 수 있도록 제2차 망분리 규제 긴급 완화 조치를 추진합니다」, 2026.09.03.
NVIDIA, NVIDIA Container Toolkit Documentation 및 Air-Gapped Installation Guidance.
OWASP, Top 10 for LLM and GenAI Applications 2025 — Supply Chain, Sensitive Information Disclosure.
NIST, AI Risk Management Framework 및 SP 800-53 Security and Privacy Controls.

주: 본문의 일정, 반입기간 및 시스템 구성은 폐쇄망 AI 구축의 특성을 설명하기 위한 가정 예시입니다. 실제 프로젝트에서는 해당 기관의 보안정책, 망 구성, 반입절차와 승인 기준에 따라 달라질 수 있습니다.

#AI인프라#폐쇄망#망분리#온프레미스AI#LLM#RAG#GPU#에어갭#보안#AI보안#소프트웨어공급망#생성형AI

Newsletter

이런 노트를 이메일로 받아보세요

새로운 리서치 노트가 발행되면 가장 먼저 알려드립니다.