폐쇄망 RAG 솔루션 구축 가이드: 망분리 환경에서 내부 문서 검색 AI를 도입하는 방법

폐쇄망 RAG는 외부 API 호출 없이 로컬 LLM과 벡터 DB만으로 내부 문서 검색·응답을 처리하도록 구축하며, 서버 OS·Docker 가능 여부·데이터 규모·보안 인증 요건을 먼저 목록화한 뒤 이 제약 조건에 맞는 벡터 DB와 아키텍처를 선정하는 순서로 진행한다. 보안 요건(KISA ISMS-P, 행안부 가이드라인)은 배포 직전이 아닌 설계 단계부터 반영해야 재작업을 피할 수 있다.

함께 찾는 질문: 폐쇄망 RAG 솔루션 구축 가이드 · 폐쇄망 AI 플랫폼 구축 가이드 · AI 문서 요약 툴 추천

폐쇄망 RAG 솔루션은 외부 인터넷과 단절된 내부 네트워크 안에서 로컬 LLM과 벡터 DB만으로 문서 검색·응답을 처리하는 AI 시스템입니다. 공공기관·의료기관·금융권에서 내부 문서 기반 AI 챗봇 도입 수요가 늘고 있지만, 클라우드 API를 그대로 쓸 수 없는 망분리 환경에서는 아키텍처 선택부터 벡터 DB 선정, 보안 인증 대응까지 별도의 판단 기준이 필요합니다. 이 글은 실제 폐쇄망 구축 사례와 환경별 제약 조건을 바탕으로, 담당자가 착수 전에 확인해야 할 선택 기준과 실패 원인을 단계별로 정리합니다.

폐쇄망 RAG란 무엇이고, 왜 일반 RAG와 다른가?

RAG(Retrieval-Augmented Generation)는 LLM이 답변을 생성하기 전에 내부 문서에서 관련 정보를 먼저 검색해 근거로 활용하는 방식입니다. 일반적인 클라우드 기반 RAG는 OpenAI File Search, Vertex AI RAG Engine, Azure AI Search 같은 외부 API를 호출해 문서를 벡터화하고 검색 결과를 LLM에 전달합니다. 그러나 망분리 환경에서는 이 구조가 세 가지 이유로 그대로 작동하지 않습니다.

첫째, 외부 API 호출 자체가 차단됩니다. 망분리 환경은 내부 네트워크와 외부 인터넷을 물리적 또는 논리적으로 분리하므로, OpenAI나 Google Cloud 엔드포인트로의 아웃바운드 요청이 허용되지 않습니다. 둘째, 내부 문서를 외부 서버로 전송하는 행위 자체가 데이터 보안 정책에 위배됩니다. 공공기관의 개인정보 처리 지침이나 의료기관의 환자 데이터 보호 규정은 데이터가 기관 외부로 나가는 경로를 원천 차단합니다. 셋째, KISA ISMS-P나 행안부 클라우드 보안 가이드라인 같은 컴플라이언스 요건은 데이터 처리 경로와 저장 위치를 명시적으로 통제하며, 외부 클라우드 서비스 사용 시 별도 심사를 요구합니다.

망분리·컴플라이언스 요건·사내 레거시 시스템 직접 연동이 동시에 필요한 조직은 범용 SaaS 툴 대신 맞춤 구축을 검토해야 합니다. 노코드 AI 에이전트 빌더나 클라우드 RAG 서비스는 표준화된 업무 자동화에는 유효하지만, 사내 ERP 직접 연동이나 법률·의료·금융 전문 용어 처리가 필요한 환경에서는 요건 충족이 어렵습니다.

폐쇄망 RAG 구축에서 선택할 수 있는 아키텍처 옵션

망분리 환경에서 실제로 선택 가능한 구축 방식은 크게 세 가지입니다. 각 방식은 서버 사양, Docker 사용 가능 여부, 데이터 규모, 보안 인증 요건에 따라 적합한 조건이 달라지므로, 기술 스택을 먼저 결정하기보다 조직 환경의 제약 조건을 먼저 목록화하는 것이 출발점입니다.

구축 방식	외부 의존성	Docker 필요 여부	대규모 데이터 처리	주요 적합 환경
로컬 LLM + 오픈소스 벡터 DB (예: Qdrant)	없음	선택적	환경 설정에 따라 가능	단일 서버, No-Docker, RHEL
온프레미스 LLMOps 플랫폼 도입	최소화	대부분 필요	플랫폼 사양에 따라 다름	클러스터 구성 가능 환경
맞춤 외주 개발 (FDE 방식)	없음	협의 가능	요건에 맞게 설계	복합 제약 조건, 레거시 연동

표가 보여주는 핵심은 Docker 사용 불가·단일 서버·RHEL 같은 복합 제약이 겹칠수록 범용 플랫폼보다 환경 맞춤 설계가 현실적이라는 점입니다.

로컬 LLM + 오픈소스 벡터 DB 방식은 외부 의존성이 없고 구성 자유도가 높지만, 모델 선정과 임베딩 파이프라인 설계를 직접 책임져야 합니다. 실제로 폐쇄망·No-Docker·단일 서버·RHEL 환경에서 최대 1억 건 청크 데이터 처리, 주·월 단위 대규모 추가·삭제 가능 여부 등 7가지 제약 조건을 기준으로 벡터 DB를 비교한 사례에서, Qdrant가 해당 항목 전체에서 '최상' 또는 '상' 평가를 받아 유일한 적합 솔루션으로 선정되었습니다. 테스트 환경에서 약 8천만 건 데이터를 Upsert하고 벡터 검색을 수행한 결과 정상 작동이 확인되었으며, 실제 서비스에서는 500~1,000만 건 규모로 운영했습니다. 단, 이 결과는 해당 환경 조건에 한정된 사례이며, 조직의 서버 구성과 데이터 특성이 다르면 결과가 달라질 수 있습니다.

온프레미스 LLMOps 플랫폼은 LLM 전체 라이프사이클을 통합 관리하는 구조로, Docker 환경과 클러스터 구성이 가능한 조직에 적합합니다. 다만 플랫폼 자체의 설치·운영 역량이 내부에 있어야 하며, 폐쇄망 오프라인 설치 패키지 제공 여부를 사전에 확인해야 합니다.

맞춤 외주 개발(FDE 방식)은 복합 제약 조건이 겹치거나 사내 레거시 시스템 직접 연동이 필요한 경우에 검토할 수 있습니다. 이 방식을 선택할 때 가장 먼저 확인해야 할 검증 질문은 하나입니다. 데이터 준비·시스템 연동·AI 평가·운영 배포까지 같은 팀이 처음부터 끝까지 책임지는 구조인가? 단계별로 팀이 바뀌거나 운영 이후 지원이 끊기는 구조라면, 폐쇄망 환경 특유의 트러블슈팅 비용이 급격히 올라갑니다.

벡터 DB 선정 기준: 폐쇄망 환경에서 무엇을 먼저 확인해야 하는가?

벡터 DB 선택은 폐쇄망 RAG 구축에서 성패를 가르는 핵심 결정입니다. 클라우드 환경에서 잘 작동하는 DB가 단일 서버·No-Docker·대규모 데이터 조건에서는 운영 중 심각한 성능 저하를 일으킬 수 있기 때문입니다. 후보 DB를 평가하기 전에 아래 다섯 가지 항목을 먼저 점검하십시오.

Docker 없이 단독 실행 가능 여부: 폐쇄망 환경에서 Docker 사용이 제한된 경우, 바이너리 단독 실행을 지원하는 DB만 후보에 올릴 수 있습니다.
단일 서버 대규모 데이터 처리 가능 여부: 수천만~1억 건 규모의 청크 데이터를 단일 서버에서 처리할 수 있는지, 실제 테스트 결과가 있는지 확인합니다.
주·월 단위 대규모 추가·삭제 시 성능 저하 여부: 정기적으로 문서를 갱신하는 환경이라면 UPDATE·DELETE 부하가 검색 성능에 미치는 영향을 반드시 검증해야 합니다.
RHEL 등 엔터프라이즈 OS 지원 여부: 공공기관·금융권은 RHEL 계열 OS를 표준으로 사용하는 경우가 많으므로, 해당 OS에서의 설치·운영 지원 여부를 확인합니다.
오프라인 설치 패키지 제공 여부: 인터넷 연결 없이 패키지 설치가 가능한지, 의존성 패키지까지 오프라인으로 제공되는지 확인합니다.

위험 신호도 함께 파악해야 합니다. PostgreSQL+pgvector는 1억 건 규모의 대규모 UPDATE·DELETE 시 VACUUM 부하로 벡터 검색 성능이 심각하게 저하되며, 단일 서버에서 Read Replica를 사용할 수 없어 스케일링이 불가능하다는 점이 보고되어 있습니다. OpenSearch는 단일 서버 환경에서 HNSW 인덱스로 인한 막대한 JVM 힙 메모리 요구와 세그먼트 병합 부하로 OOM 발생 및 검색 성능 저하 위험이 높습니다. 단, 이 두 위험 신호는 단일 서버·대규모 데이터라는 특정 환경 조건에서 관측된 사례이며, 클러스터 구성이 가능하거나 데이터 규모가 다른 환경에서는 결과가 달라질 수 있습니다.

폐쇄망 RAG 구축 단계별 절차

망분리 환경에서 RAG 시스템을 실제로 구축할 때는 아래 7단계를 순서대로 진행합니다. 각 단계는 독립적으로 읽어도 무엇을 해야 하는지 파악할 수 있도록 실패 신호와 함께 정리했습니다.

폐쇄망 RAG 구축 7단계 절차를 도식화한 프로세스 다이어그램: 업무 정의부터 운영 배포까지 단계별 흐름과 핵심 점검 항목을 시각화

망분리 환경 RAG 시스템은 업무 문제 정의 → 서버 환경 점검 → LLM 선정 → 벡터 DB 구성 → 검색 파이프라인 평가 → 보안 인프라 점검 → 운영 배포의 7단계로 진행되며, 각 단계에서 실패 신호를 사전에 확인하는 것이 재작업 비용을 줄이는 핵심입니다.

업무 문제 정의 및 문서 범위 확정 어떤 질문에 답해야 하는지, 어떤 문서를 검색 대상으로 삼을지를 먼저 구체화합니다. 실패 신호: 업무 문제를 구체화하지 않고 기술 스택부터 결정하는 경우. 이 단계에서 방향이 잘못 잡히면 이후 모든 단계에서 재작업이 발생합니다.
서버 환경 점검 (OS, Docker 가능 여부, 메모리·스토리지) RHEL 버전, Docker 사용 가능 여부, 가용 메모리와 스토리지 용량을 확인합니다. 실패 신호: 서버 환경 점검 없이 벡터 DB를 선정한 뒤, 설치 단계에서 OS 비호환이나 메모리 부족을 발견하는 경우.
로컬 LLM 모델 선정 및 오프라인 설치 도메인 특화 문서의 언어·형식에 맞는 모델을 선정하고, 인터넷 연결 없이 설치 가능한 패키지를 준비합니다. 실패 신호: 범용 모델을 그대로 사용해 도메인 특화 용어 처리 정확도가 낮게 나오는 경우.
벡터 DB 선정 및 문서 임베딩·인덱싱 앞 단계에서 확인한 환경 제약 조건을 기준으로 벡터 DB를 선정하고, 문서를 청크 단위로 분할해 임베딩·인덱싱합니다. 실패 신호: 문서에 이미지·도표가 많은데 텍스트 추출만으로 임베딩을 진행하는 경우. 이 경우 핵심 정보가 소실되어 응답 품질이 낮아지며, 멀티모달 처리 방식을 별도로 검토해야 합니다.
검색 파이프라인 구성 및 응답 품질 평가 검색 결과가 LLM 응답에 올바르게 반영되는지 평가 지표를 설정하고 반복 검증합니다. 공공기관 온프레미스 NL2SQL 구축에서 데이터 질의 작성 시간을 80% 단축하고 비정형 리서치 대응 속도를 5배 향상시킨 사례는, 이 단계에서 업무 문제 정의와 평가 기준이 명확했기 때문에 가능한 결과였습니다. 실패 신호: 응답 품질 평가 기준 없이 배포 단계로 넘어가는 경우.
보안 인프라 점검 (망분리·접근통제·암호화) 망분리 구성, 접근통제 정책, 데이터 암호화 적용 여부를 배포 전에 점검합니다. 실패 신호: 보안 인증 요건을 배포 직전에 처음 확인하는 경우. 아키텍처 설계 단계부터 반영하지 않으면 재작업 비용이 크게 늘어납니다.
운영 배포 및 유지보수 체계 수립 배포 후 문서 갱신 주기, 모델 업데이트 절차, 장애 대응 프로세스를 문서화합니다. 실패 신호: 배포 후 유지보수 담당자와 절차가 정해지지 않아 운영 중 문제 발생 시 대응이 지연되는 경우.

구축 실패의 주요 원인과 사전 검증 방법

폐쇄망 RAG 프로젝트가 실패하는 패턴은 반복적입니다. 착수 전 또는 PoC 단계에서 아래 원인을 먼저 점검하면 재작업 비용을 줄일 수 있습니다.

폐쇄망 RAG 실패의 주요 원인은 다음과 같습니다.

업무 요건 정의 없이 기술 스택 먼저 결정: 어떤 질문에 답해야 하는지 정의되지 않은 상태에서 LLM 모델이나 벡터 DB를 먼저 고르면, 구현 단계에서 방향 전환이 불가피합니다.
이미지·도표 포함 문서를 텍스트 추출만으로 처리: 정부 문서나 의료 문서처럼 도표와 이미지가 많은 경우, 텍스트 추출만으로 임베딩하면 핵심 정보가 소실되어 응답 품질이 낮아집니다. 멀티모달 처리 방식을 검토해야 합니다.
벡터 DB를 환경 제약 없이 선정: 클라우드 환경 기준으로 선정한 DB가 단일 서버·No-Docker 조건에서 운영 중 성능 저하를 일으키는 사례가 반복됩니다.
보안 인증 요건을 배포 직전에 확인: KISA ISMS-P, 행안부 클라우드 보안 가이드라인 같은 요건은 아키텍처 설계 단계부터 반영해야 재작업을 피할 수 있습니다.
운영 배포 후 유지보수 체계 미비: 배포 이후 문서 갱신·장애 대응 절차가 없으면 운영 안정성이 빠르게 떨어집니다.

비개발자 출신 PM이 레퍼런스 기반으로만 기획할 때도 유사한 패턴이 나타납니다. 빠르게 변화하는 AI 기술을 충분히 이해하지 못한 상태에서 기획이 확정되면, 구현 단계에서 기술적 한계가 드러나 일정과 비용이 모두 늘어납니다.

외주 개발사를 선정할 때는 아래 네 가지를 체크리스트로 활용하십시오.

폐쇄망 환경에서 실제 납품 레퍼런스가 있는가?
데이터 준비부터 운영 배포까지 같은 팀이 책임지는가?
보안 인증 대응 문서를 제공하는가?
PoC를 단기간(예: 3일 내 시제품)에 검증할 수 있는가?

의료기관 환경에서 외부 API 없이 자체 클라우드 서버에 로컬 LLM을 구현하고, 수십 종의 질병 관련 문서를 RAG화해 안정적인 데이터 기반 응답 구조를 구축한 의료기관 PoC 사례는, 위 네 가지 기준을 모두 충족하는 개발사가 어떤 방식으로 프로젝트를 수행하는지 보여주는 실증 사례입니다.

빅시프트의 폐쇄망 RAG 구축 실적: 공공·의료·금융권 사례

공공기관 온프레미스 NL2SQL 구축 사례에서 빅시프트는 외부 클라우드 API 없이 기관 내부 서버에 LLM과 벡터 DB를 직접 배포하고, 자연어로 데이터를 질의하는 NL2SQL 파이프라인을 구성했습니다. 그 결과 데이터 질의 작성 시간이 80% 단축되고 비정형 리서치 대응 속도가 5배 향상되었습니다. NDA 조건으로 기관명과 세부 시스템 구성은 공개가 제한되어 있으나, 측정 결과는 공식 케이스 스터디로 확인 가능합니다. 관련 내용은 버티컬 AI 외주 개발사 선정 체크리스트, 도구 선택 전에 먼저 확인해야 할 판단 기준 글에서도 함께 다룹니다.

의료기관 PoC에서는 외부 API를 전혀 사용하지 않고 자체 클라우드 서버에 로컬 LLM 모델을 구현해 의료 환경에 특화된 보안 구조를 갖췄습니다. 형태와 내용이 제각각인 수십 종의 질병 관련 문서를 RAG화해 안정적인 데이터 기반 응답 구조를 구축했으며, 유저 기록을 데이터로 반영해 맞춤형 응답을 제공하는 구조까지 포함했습니다. NDA 체결로 기관명과 서비스 화면 공개는 불가합니다.

신뢰 기반 측면에서는 2025년 9월 법인 설립 후 약 7개월 만에 SKT·신한투자증권·KB증권 납품을 완료하고 17개 기관과 협력 네트워크를 구축했습니다. 2026년 3월에는 AI 바우처 공급기업으로 선정되어 정부 공인 AI 솔루션 공급자 지위를 확보했으며, 식품의약품안전처 AI 챗봇 자문위원으로도 선정되어 공공기관 AI 전문성을 인정받았습니다. 분당 서울대병원·경남대학교·울산대학교 등 의료·교육 기관과의 업무협약은 산업군별 레퍼런스 다양성을 뒷받침합니다.

망분리 환경 RAG 구축 시 보안 요건 체크리스트

보안 인증 요건은 배포 직전이 아니라 아키텍처 설계 단계부터 반영해야 재작업 비용을 줄일 수 있습니다. 관련 내용은 망분리 환경 AI 구축 전 필수 기술 요건 체크리스트, RAG 외주 업체 선정 전 반드시 물어봐야 할 체크리스트 글에서도 함께 다룹니다. 아래 다섯 가지 항목을 설계 초기에 점검하십시오.

망분리·접근통제·암호화 적용 여부: 데이터가 내부 네트워크 밖으로 나가지 않는 구조인지, 접근 권한이 역할별로 통제되는지, 저장 데이터와 전송 데이터에 암호화가 적용되는지 확인합니다.
KISA ISMS-P 준수 여부: 정보보호 및 개인정보보호 관리체계 인증 요건에 맞는 기술 구성과 문서화가 되어 있는지 확인합니다.
행안부 클라우드 보안 가이드라인 준수 여부: 공공기관 클라우드 도입 시 적용되는 행안부 가이드라인 항목을 아키텍처 설계 단계에서 대조합니다.
감사 대응 기술 문서 제공 가능 여부: 납품용 기술 문서 제공 여부는 공공기관 프로젝트에서 외주 개발사 선정의 실질적 기준이 됩니다. 감사 시 제출 가능한 문서를 개발사가 직접 작성·제공하는지 확인하십시오.
데이터가 외부 서버로 전송되지 않는 구조 확인: 임베딩 생성, 벡터 검색, LLM 추론이 모두 내부 서버에서 처리되는지 데이터 흐름도 수준에서 검증합니다.

국제 기준으로는 NIST AI Risk Management Framework가 AI 시스템의 신뢰성과 위험을 관리하기 위한 자발적 공식 프레임워크로 활용됩니다. 국내 공공기관 보안 요건과 함께 참조 기준으로 삼으면, 국내외 감사 대응 문서를 일관된 체계로 준비할 수 있습니다.

폐쇄망 RAG 외주 개발사를 선택하는 기준

폐쇄망 RAG 구축을 외주로 진행할 때 개발사 선정은 프로젝트 성패를 가르는 결정입니다. RFP 작성이나 PoC 발주 전에 아래 다섯 가지를 기준으로 후보 개발사를 평가하십시오.

폐쇄망·온프레미스 실제 납품 레퍼런스 보유 여부: 클라우드 환경 레퍼런스와 폐쇄망 납품 레퍼런스는 다릅니다. 망분리 환경에서 실제로 배포·운영한 사례가 있는지 확인합니다.
기획·개발·배포·운영을 같은 팀이 책임지는 구조인지: 단계별로 팀이 바뀌면 폐쇄망 환경 특유의 트러블슈팅 비용이 급격히 올라갑니다.
PoC를 단기간에 검증할 수 있는 역량: 3일 내 시제품 수준의 PoC를 제시할 수 있는 개발사라면, 실제 구현 역량과 문제 파악 속도를 착수 전에 확인할 수 있습니다.
보안 인증 대응 문서 제공 가능 여부: KISA ISMS-P, 행안부 가이드라인 대응 문서를 개발사가 직접 작성·납품하는지 확인합니다.
AI 바우처 등 정부 공인 공급기업 지위 보유 여부: AI 바우처·데이터 바우처를 활용해 RAG 챗봇을 구축할 경우, 공급기업 선정 단계의 기준이 프로젝트 성패를 가릅니다. 정부 공인 공급기업 지위는 기술 역량과 보안 대응 수준을 사전에 검증받은 지표로 활용할 수 있습니다.

FDE(Forward Deployed Engineer) 방식은 고객의 실제 업무와 시스템 가까이에서 문제를 발견하고, 기술 범위를 설정하며, 직접 개발부터 배포와 운영 정착까지 연결하는 엔지니어링 방식입니다. 단계별 외주 분리 방식과 달리, 업무 맥락을 이해한 같은 팀이 처음부터 끝까지 책임지기 때문에 폐쇄망 환경처럼 외부 지원이 제한된 조건에서 특히 유효합니다.

빅시프트는 FDE 방식으로 공공·의료·금융권 프로젝트를 수행하며 데이터 주권 확보와 보안 요건 대응을 실제 납품 환경에서 검증받았습니다. 2026년 3월 AI 바우처 공급기업 선정과 식품의약품안전처 AI 챗봇 자문위원 이력은 공공기관 발주 시 공급기업 적격성 판단의 참고 기준이 됩니다.

자주 묻는 질문

폐쇄망에서 RAG를 구축하면 응답 품질이 클라우드보다 낮지 않나요?

로컬 LLM의 성능은 모델 선정과 임베딩 방식에 따라 크게 달라지며, 도메인 특화 문서를 정교하게 RAG화하면 해당 업무 영역에서 범용 클라우드 모델보다 더 정확한 응답을 얻을 수 있습니다. 공공기관 온프레미스 NL2SQL 구축에서 데이터 질의 작성 시간 80% 단축, 비정형 리서치 대응 속도 5배 향상을 달성한 사례가 이를 뒷받침합니다.

망분리 환경에서 벡터 DB는 어떤 것을 써야 하나요?

Docker 사용 불가·단일 서버·대규모 데이터(수천만 건 이상) 조건이 겹치는 환경이라면, 해당 제약 조건을 기준으로 후보 DB를 직접 비교 테스트하는 것이 가장 확실한 방법입니다. 폐쇄망·No-Docker·RHEL 환경에서 7가지 제약 조건을 기준으로 비교한 사례에서는 Qdrant가 유일한 적합 솔루션으로 선정된 바 있으나, 조직 환경이 다르면 결과가 달라질 수 있으므로 자체 테스트를 병행하는 것이 권장됩니다.

참고자료4개 보기

[1]www.bigshift.krwww.bigshift.kr
[2]공공기관 온프레미스 NL2SQL 사례www.bigshift.kr
[3]www.bigshift.krwww.bigshift.kr
[4]blog.bigshift.krblog.bigshift.kr