# AI 인프라 망분리 설계, 금융권 폐쇄형 서버를 감사 가능한 구조로 만드는 기준

> 원문: https://test1234.teon.kr/ai-infrastructure-network-separation-design-finance-auditable-closed-server-stan · 발행 2026-08-03 · 테온

## 인터넷을 끊는 것만으로는 금융권 AI 서버가 완성되지 않습니다
“인터넷 연결 없이 CUDA와 주요 모듈을 어떻게 설치하고 업데이트합니까?” 내부 보안 감사관의 이 질문에 답하지 못하면, 고가 GPU 서버를 들여놓고도 프로젝트는 멈춥니다. 문제는 네트워크 단절 자체가 아니라 단절된 환경에서 필요한 파일과 관리 행위를 어떻게 통제하고 증명할지에 있습니다.

결론부터 말하면 금융권 AI 인프라는 세 층으로 설계해야 합니다. 첫째, 업무망·관리망·반입검증망을 분리합니다. 둘째, 패키지와 컨테이너 이미지를 보관하는 내부 아카이브 미러를 둡니다. 셋째, 가상 IP 매핑과 물리 포트 화이트리스트로 허용된 흐름만 열고 모든 변경 이력을 남깁니다.

금융위원회의 망분리 개선 로드맵은 생성형 AI와 클라우드 활용 범위를 확대하는 방향을 제시했습니다. 따라서 ‘무조건 폐쇄’만 주장하는 설계보다, 어떤 데이터가 어느 구간을 통과하고 누가 승인했는지를 설명하는 구조가 감사 대응과 운영 지속성을 함께 확보합니다.

## 논리적 망분리와 물리적 망분리는 심사 대상이 다릅니다
논리적 망분리는 방화벽, VLAN, 보안그룹, 라우팅 정책으로 하나의 물리 인프라 안에서 통신 영역을 나누는 방식입니다. 물리적 망분리는 장비·스위치·케이블·인터페이스를 분리해 경로 자체를 나누는 방식입니다. 두 개념은 같은 말이 아닙니다.

AI 학습 서버의 GPU 사용망과 운영자 접속망을 논리적으로 나누더라도, 관리 인터페이스와 스위치가 공유되면 감사관은 공유 지점을 별도 통제 대상으로 봅니다. 반대로 물리적으로 장비를 나눠도 허가되지 않은 USB, 콘솔 포트, 이동식 저장장치가 열려 있으면 반입·반출 통제가 끊깁니다.

이 구분을 생략하면 설계자는 ‘망분리 완료’라고 보고하지만 감사 문서에는 통제 경계가 모호하게 남습니다. 그 결과 재설계, 추가 장비 구매, 승인 지연이 한꺼번에 발생합니다. 금융권 AI 인프라에서는 논리적 구간과 물리적 접점을 각각 자산 목록과 통제 항목으로 기록해야 합니다.

## 폐쇄형 AI 서버의 핵심은 내부 패키지 공급망입니다
외부 저장소에 접근하지 못하는 서버에는 OS 패키지, GPU 드라이버, CUDA 관련 구성요소, Python 패키지, 컨테이너 이미지가 필요합니다. 이 파일들을 담당자의 노트북에서 그때그때 복사하면 설치는 되더라도 출처와 무결성을 설명하기 어렵습니다.

권장 구조는 반입검증 구간과 내부 아카이브 미러를 분리하는 방식입니다. 외부에서 받은 파일은 검증 구간에서 악성코드 검사, 해시 확인, 라이선스 확인, 승인 기록을 거칩니다. 승인된 파일만 내부 미러에 등록하고, AI 서버는 외부 저장소 대신 이 미러를 조회하게 합니다.

NVIDIA의 컨테이너 도구 문서도 GPU 드라이버 설치와 컨테이너 런타임 설정을 별도 단계로 다룹니다. 따라서 ‘CUDA 버전만 맞추면 된다’는 식으로 관리하면 드라이버·런타임·이미지의 연결 관계가 빠집니다. 설치 파일 묶음마다 지원 OS, 드라이버 조건, 이미지 식별자, 등록일을 함께 관리해야 합니다.

## 감사에서 반복해서 막히는 운영 실수 네 가지
첫째, 운영자 PC를 임시 다운로드 창구로 쓰는 실수입니다. 급한 장애를 해결하려는 행동이지만 파일 출처와 검증 결과가 남지 않아 같은 패키지를 다시 확인하게 됩니다. 장애 시간과 감사 대응 시간이 동시에 늘어납니다.

둘째, 서버의 모든 이더넷 포트를 연결해두고 방화벽 규칙만으로 통제하는 경우입니다. 정책 파일이 바뀌거나 관리 도구가 예외를 만들면 물리적으로 열린 경로가 남습니다. 사용하지 않는 포트는 비활성화하고, 필요한 포트만 자산번호와 목적을 부여해야 합니다.

셋째, IP 주소를 서버별로 임의 배정하는 방식입니다. 서버 교체 뒤 주소가 바뀌면 방화벽, 모니터링, 접근제어 목록이 함께 흔들립니다. 가상 IP를 서비스 단위로 매핑하고 실제 서버 주소와 변경 이력을 연결하면 교체와 점검의 범위를 줄일 수 있습니다.

넷째, 컨테이너 이미지만 보관하고 실행 설정을 보관하지 않는 실수입니다. 동일한 이미지라도 드라이버, 런타임, 환경변수, 마운트 경로가 다르면 결과가 달라집니다. 이미지 다이제스트와 실행 매니페스트를 한 묶음으로 승인해야 재현 가능한 환경이 됩니다.

## 설계안을 숫자로 검증하는 방법
설명을 위한 제안 기준으로, 초기 아키텍처는 3개 구간으로 나누어 문서화해봅니다. ① 외부 반입검증 구간 ② 내부 패키지·이미지 미러 구간 ③ 학습·추론 및 관리 구간입니다. 각 구간에는 허용 프로토콜, 담당자, 승인 문서, 로그 보존 위치를 한 줄씩 붙입니다.

가상의 예시입니다. 신용평가 모델을 운영하는 조직이 GPU 서버 8대를 도입했다고 가정하겠습니다. 서버마다 외부 통신을 허용하는 대신, 패키지 미러 1곳과 가상 IP 3개만 서비스 경로로 등록합니다. 매월 업데이트 창구는 1회로 고정하고, 반입 목록·해시·검증자·적용 서버를 하나의 변경 티켓에 묶습니다.

이 구조에서 점검할 기준은 ‘설정이 강한가’가 아니라 ‘흐름을 재현할 수 있는가’입니다. 설명을 위한 제안 기준으로, 신규 패키지 1건을 추적할 때 출처·검증 결과·승인자·적용 버전 네 항목이 10분 안에 문서에서 확인되지 않으면 미러 운영 체계가 감사에 취약하다고 판단합니다. 수치 자체는 기관의 보존 정책과 감사 범위에 맞춰 조정해야 합니다.

## 가상 IP와 포트 화이트리스트를 함께 설계해야 하는 이유
가상 IP는 서비스의 고정된 주소입니다. 실제 GPU 서버가 교체되거나 증설되어도 패키지 미러, 모니터링, 관리 서비스가 어떤 경로로 연결되는지 일정하게 유지합니다. 방화벽 규칙을 개별 장비 주소가 아니라 서비스 목적과 구간을 기준으로 관리하기 쉬워집니다.

물리 포트 화이트리스트는 ‘연결할 수 있는 장치’를 제한합니다. 관리망 NIC, 저장장치 반입용 단말, 콘솔 포트, USB 포트를 목록화하고 미승인 장치는 비활성화합니다. 네트워크 정책과 물리 통제를 한 문서에서 연결해야 특정 담당자의 예외 설정이 전체 구조를 우회하지 못합니다.

① 서버 교체가 잦고 관리 서비스가 여러 대라면 가상 IP 매핑을 우선합니다. ② 데이터 반입과 장비 이동이 잦거나 물리 감사가 엄격하다면 포트 화이트리스트를 먼저 고정합니다. ③ 두 조건이 모두 해당하면 서비스 주소와 물리 접점을 하나의 변경 승인 흐름으로 묶는 방식이 적합합니다.

## 감사 통과를 준비하는 최종 질문 네 가지
Q. 폐쇄형 AI 서버에 인터넷을 잠시 연결해 업데이트해도 됩니까? A. 예외 연결을 전제로 설계하면 폐쇄 구간의 통제 목적이 약해집니다. 반입검증 구간에서 파일을 확인한 뒤 내부 미러로 등록하고, 서버는 승인된 내부 경로만 조회하는 방식이 문서화와 재현성에 유리합니다.

Q. CUDA와 Python 패키지는 한 번에 설치하면 됩니까? A. 드라이버, GPU 런타임, 컨테이너 런타임, 프레임워크, 애플리케이션 패키지를 계층별로 기록해야 합니다. 설치 순서와 검증 명령, 성공 로그까지 보관해야 장애 때 같은 환경을 복원할 수 있습니다.

Q. 가상 IP만 적용하면 물리 포트 통제는 생략해도 됩니까? A. 생략할 수 없습니다. 가상 IP는 논리적 서비스 흐름을 관리하고, 포트 화이트리스트는 장치와 물리 경로를 제한합니다. 서로 다른 통제 대상을 한 정책으로 대신하면 사각지대가 남습니다.

Q. 설계 승인 전에 무엇부터 확인해야 합니까? A. 먼저 데이터 분류와 구간별 통신 목록을 확정하십시오. 그다음 패키지 반입 절차, 가상 IP 표, 물리 포트 목록, 로그 보존 위치를 연결하면 보안 담당자와 인프라 담당자가 같은 설계도를 보게 됩니다.