망분리 환경에서 RAG PoC 진행하는 법
핵심 요약: 데이터 반출이 불가한 금융권·대기업 환경에서 사내 RAG(문서검색·AI Assistant)를 검증하려면 퍼블릭 API 대신 사내망 안에 소규모 온프레미스 PoC를 구성하는 접근이 현실적이에요. 96GB 메모리 안에 적재 가능한 모델 기준으로 1~4GPU 규모면 검증을 시작할 수 있고, 보안팀·현업·인프라팀의 요구를 하나의 구성으로 조정하는 게 성공의 핵심이에요.
"우리도 사내 문서를 검색해 주는 AI Assistant를 만들어 보자"는 이야기는 이제 어느 조직에서나 나와요. 그런데 금융권이나 대기업에서 실제로 검토를 시작하면 첫 번째 벽에 부딪혀요. 바로 데이터 반출 정책이에요. 사내 규정과 감독 규제상 내부 문서를 외부 API로 전송할 수 없으니, 퍼블릭 LLM API를 붙여서 빠르게 프로토타입을 만드는 일반적인 방법이 처음부터 막히는 거죠.
이 글에서는 데이터 반출이 불가한 조직이 사내 RAG를 검증할 때 실제로 쓰이는 진행 순서를 정리했어요. 소규모 온프레미스 PoC 구성 기준, 조직 간 요구 조정 방법, PoC 단계 정의, 그리고 PoC 이후 확장까지 순서대로 다룰게요.
퍼블릭 API를 쓸 수 없는 이유부터 정리해요
기술 검토에 들어가기 전에, 왜 퍼블릭 API가 선택지에서 빠지는지를 조직 내부에 명확히 문서화해 두는 게 좋아요. 나중에 "그냥 API 쓰면 되지 않느냐"는 질문이 반복되는 걸 막아줘요.
- 데이터 반출 정책: 사내 문서, 고객 정보, 내부 규정집이 RAG의 원천 데이터인데, 이 데이터가 외부 사업자의 서버로 전송되는 순간 반출로 간주돼요. 금융권은 감독 규제상, 대기업은 내부 보안 규정과 영업비밀 보호 관점에서 허용이 어려워요.
- 프롬프트도 데이터예요: RAG는 질문과 함께 검색된 문서 조각(Chunk)을 프롬프트에 담아 모델로 보내는 구조예요. 즉 API 호출 자체가 사내 문서 전송이에요. "질문만 보내니까 괜찮다"는 논리가 성립하지 않아요.
- 감사 추적 요건: 누가 어떤 문서를 조회했고 모델이 어떤 근거로 답했는지 로그를 사내에 보관해야 하는 조직이 많아요. 외부 API는 이 요건을 충족하기 어려운 경우가 있어요.
그래서 결론은 자연스럽게 "모델을 사내망 안으로 가져오자"가 돼요. 다만 처음부터 대규모 장비를 도입하는 게 아니라, 검증 목적에 맞는 소규모 구성으로 시작하는 게 핵심이에요.
소규모 온프레미스 PoC 구성: 96GB 안에서 시작해요
사내 RAG·AI Assistant 용도라면 대부분 96GB 메모리 안에 적재 가능한 모델로 검증을 시작할 수 있어요. 최근 공개 모델들의 성능이 좋아지면서, 양자화를 적용한 중형 모델로도 문서검색·요약·질의응답 품질을 충분히 확인할 수 있거든요.
| 구성 요소 | PoC 기준 | 비고 |
|---|---|---|
| GPU | RTX PRO 6000(96GB GDDR7) 또는 H100(80GB HBM3)급 1~4GPU | 모델 크기와 동시 사용자 수에 따라 결정 |
| 서빙 모델 | 96GB 내 적재 가능한 공개 LLM | 양자화 적용 시 선택 폭이 넓어져요 |
| 임베딩 모델 | 경량 임베딩 모델(동일 서버 탑재 가능) | 검색 품질에 큰 영향을 줘요 |
| Vector DB | 소규모는 단일 노드로 시작 | 확장 단계에서 재검토 |
| 서빙 프레임워크 | vLLM 등 오픈소스 추론 서버 | 동시성·처리량 측정용 |
여기서 GPU 수를 정하는 기준은 두 가지예요. 첫째는 모델 크기(적재에 필요한 메모리), 둘째는 동시 사용자 수예요. 부서 단위 수십 명이 쓰는 PoC라면 1~2GPU로 시작하고, 전사 확산 가능성까지 미리 측정하고 싶다면 4GPU 구성으로 동시성 테스트 여유를 두는 방식이 일반적이에요.
한 가지 주의할 점은, PoC 장비를 "검증 후 버리는 장비"가 아니라 "확장 시 추론 노드로 편입되는 장비"로 설계하는 거예요. 이렇게 하면 PoC 투자가 본사업에서도 그대로 살아있게 돼요.
세 조직의 요구를 하나의 구성으로 조정해요
망분리 환경 PoC에서 기술보다 어려운 게 조직 간 조정이에요. 실제 진행 과정을 익명화한 시나리오로 정리해 볼게요.
한 금융사에서 사내 문서검색 Assistant PoC를 검토할 때, 세 조직의 요구가 서로 부딪혔어요.
- 보안팀: "사내 데이터는 어떤 형태로도 외부로 나갈 수 없습니다. 외부 API, 외부 클라우드 모두 불가합니다."
- 현업(사업부서): "경영진 보고 일정상 3개월 안에 검증 결과가 필요합니다. 절차가 길어지면 과제 자체가 무산됩니다."
- 인프라팀: "유지보수와 지원 체계가 확인된 표준 벤더 장비만 도입할 수 있습니다. 검증 안 된 장비는 사내망에 못 들여옵니다."
각 요구를 따로 보면 서로 모순처럼 보여요. 외부 클라우드로 빠르게 하자니 보안팀이 막고, 정식 대규모 도입 절차를 밟자니 현업 일정이 안 맞고, 아무 장비나 빨리 가져오자니 인프라팀 기준에 걸리죠.
이 경우 해법은 표준 벤더 서버 기반의 소규모 온프레미스 PoC였어요. 멀티벤더(xFusion·KAYTUS·Supermicro·Dell·HPE) 대응이 가능하면 인프라팀의 표준 벤더 요건에 맞는 제품을 고를 수 있고, 소규모 구성이라 도입 절차와 설치 기간이 짧아 현업 일정 안에 들어와요. 그리고 모든 데이터가 사내망 안에 머무르니 보안팀 요건도 충족돼요. 세 조직이 각자 양보한 게 아니라, 구성 자체가 세 요구를 동시에 만족한 거예요.
이런 조정은 장비 스펙보다 먼저 이뤄져야 해요. 저희가 대기업·금융권 프라이빗 AI 상담에서 GPU 모델 이야기보다 조직별 요건 인터뷰를 먼저 하는 이유이기도 해요.
PoC 5단계: 요건 정리부터 확장 판단까지
망분리 환경 PoC는 다음 다섯 단계로 정의하면 관리가 쉬워요.
1단계, 요건 정리. 무엇을 검증할지 합의해요. 대상 문서 범위, 사용자 그룹, 성공 기준(답변 정확도, 응답 시간, 동시 사용자 수)을 문서로 확정해요. 보안팀의 접근통제·로그 요건도 이 단계에서 수집해요.
2단계, 구성 설계. 모델 크기와 동시성 목표에 맞춰 GPU 수량, 서버 사양, Vector DB, 서빙 프레임워크를 설계해요. 인프라팀의 표준 벤더·전력·랙 요건을 여기서 반영해요.
3단계, 사내망 설치·검수. 장비 반입, 망분리 구간 배치, 폐쇄망 환경에서의 소프트웨어 설치(외부 저장소 접근이 안 되므로 오프라인 설치 계획 필수)를 진행해요. GPU 상태 점검과 추론 부하 테스트 같은 검수 항목을 사전에 합의해 두면 인수 과정이 깔끔해져요.
4단계, 운영. 실제 사용자에게 열고 성공 기준 대비 수치를 수집해요. 답변 품질 평가는 현업이, 리소스 사용률과 응답 시간은 인프라팀이 측정하도록 역할을 나누는 게 좋아요.
5단계, 확장 판단. 수집된 수치로 전사 확산 여부를 결정해요. 이때 판단 축은 사용자 규모, 문서 증가 속도, 그리고 GPU 사용률 추이예요. 사용률이 꾸준히 높게 유지된다면 온프레미스 증설이, 변동이 크다면 하이브리드 구성이 후보가 돼요.
PoC 이후 확장: 데이터 플랫폼까지 함께 봐야 해요
PoC가 성공하고 전사 확산 단계로 넘어가면, 병목은 GPU가 아니라 데이터 쪽에서 먼저 생기는 경우가 많아요.
- Vector DB: PoC의 단일 노드 구성은 문서 수십만 건까지는 버티지만, 전사 문서와 첨부파일까지 인덱싱하면 검색 지연과 인덱스 재구축 시간이 문제가 돼요. 확장 단계에서는 고가용성 구성과 인덱스 갱신 파이프라인을 다시 설계해야 해요.
- 운영 DB와의 연계: RAG의 원천 데이터가 문서만이 아니라 업무 시스템의 정형 데이터(고객 정보, 거래 내역, 상품 정보)로 넓어지면, 운영 DB에서 안전하게 데이터를 공급하는 파이프라인과 권한 체계가 필요해요. Oracle DB나 MySQL 기반 운영계와 벡터 검색을 함께 설계하면 데이터 정합성 관리가 훨씬 수월해져요.
- 권한 반영 검색: 전사 확산의 필수 요건이에요. 사용자가 볼 수 없는 문서는 검색 결과에도 나오면 안 되므로, 사내 권한 체계를 Vector DB 검색 필터에 반영하는 설계가 필요해요.
즉 확장 단계의 제안서에는 GPU 증설만이 아니라 데이터 플랫폼, 네트워크, 운영 체계가 함께 들어가야 해요. PoC 때부터 이 그림을 염두에 두고 설계하면 확장 시 재작업이 크게 줄어요.
마치며
망분리 환경의 RAG PoC는 "퍼블릭 API를 못 쓴다"는 제약에서 출발하지만, 접근 순서만 잡으면 오히려 명확하게 진행돼요. 정리하면 이래요.
- 퍼블릭 API가 불가한 이유(데이터 반출, 프롬프트 전송, 감사 추적)를 먼저 문서화해요.
- 96GB 안에 적재 가능한 모델 기준, 1~4GPU 소규모 온프레미스 구성으로 시작해요.
- 보안팀·현업·인프라팀의 요구를 하나의 구성으로 동시에 만족시키는 설계가 기술 스펙보다 먼저예요.
- 요건 정리, 구성 설계, 사내망 설치·검수, 운영, 확장 판단의 5단계로 관리해요.
- 확장 단계에서는 Vector DB와 운영 DB를 포함한 데이터 플랫폼까지 함께 설계해요.
사내 AI 용도와 보안 요건이 정리되어 있다면, 그에 맞는 PoC 구성안 설계부터 도와드릴 수 있어요. 대기업·금융권 프라이빗 AI 페이지에서 자세한 내용을 확인해 보세요.