SITE SEARCH

검색

사이트 전체 글을 빠르게 찾을 수 있습니다.

RSS FEED

RSS 구독

RSS 리더에서 Project Research의 새 글을 바로 받아볼 수 있습니다.

EMAIL SUBSCRIBE

이메일 구독

새 글을 이메일로 받아봅니다. RSS는 별도 RSS 아이콘을 눌러 동일한 크기의 패널에서 열 수 있습니다.

이메일로 블로그 구독하기

이 블로그를 구독하고 이메일로 새글의 알림을 받으려면 이메일 주소를 입력하세요







사내 지식자산을 RAG로 만드는 법 — 망분리 환경에서 토큰 비용 0으로 시작하는 6단계

시리즈

지난 글에서는 제 개인 노트를 앱 없이 검색하는 도구를 공개했습니다. 이번엔 한 걸음 더 들어갑니다 — 회사의 업무지식 전체를 “물어보면 근거와 함께 답하는” 사내 검색으로 바꾸는 일입니다.

개인 노트와 회사 지식은 무게가 다릅니다. 단가·원가·특허·인사 같은 민감 정보가 섞여 있고, 아무 데서나 검색되면 안 됩니다. 그래서 핵심은 세 가지 — 데이터를 밖으로 보내지 않기, 권한대로만 보이기, 출처를 남기기입니다.

Claude Code 사용 분석 시리즈 — 한 제조 상장사의 사내 지식 RAG화 PoC에서 실제로 돌려본 6단계를, 클라이언트 식별정보를 빼고 방법론만 일반화했습니다.

바쁜 분을 위한 3줄 요약

사내 지식 RAG의 어려움은 검색 기술이 아니라 ‘보안과 권한’입니다 — 민감 정보는 외부 AI로 보낼 수 없으니, 임베딩(의미 좌표)을 로컬에서 토큰 비용 0으로 만들고, 문서마다 권한 등급(S0~S3)을 붙여 권한대로만 회수합니다.
실전은 6단계입니다 — 정제 → 첨부 해체 → 보안 태깅 → 한국어 하이브리드 색인 → 관계 그래프 → 품질 게이트. 화면 3천여·첨부 3백여 문서를 색인하고 조직별 20문항 × 8 = 160문항으로 검증했습니다.
직접 짜기 전에 따져보세요. 이미 있는 코드는 재사용하고, 일반 등급은 관리형 검색을 사고, 민감 등급만 직접 만드는 게 가장 쌉니다. 작은 조직에선 관리형 대규모 언어모델(LLM)이 GPU 상시 보유보다 5~15배 저렴합니다.

들어가며

회사의 지식은 ‘흩어져’ 있고, 사람과 함께 ‘떠납니다’

“그 자료, 누가 갖고 있더라?” — 회사에서 가장 자주 낭비되는 시간입니다. 자료는 분명 어딘가에 있는데, 폴더와 메신저와 담당자의 머릿속에 흩어져 있죠. 그리고 그 사람이 자리를 옮기면, 맥락까지 같이 사라집니다.

사내 지식 검색(RAG)은 이 두 문제를 동시에 겨냥합니다 — 흩어진 지식을 한곳에서 묻게 하고, 사람이 떠나도 지식은 남게 합니다. 그런데 막상 시작하려면 곧바로 벽에 부딪힙니다. “이걸 외부 AI에 올려도 되나?”

안 됩니다. 단가표, 원가, 특허 전략, 고객 이슈, 이력서 — 이런 자료는 외부 서비스에 업로드하는 순간 사고입니다. 그래서 사내 지식 RAG의 진짜 과제는 “똑똑한 검색”이 아니라 “새지 않는 검색”입니다.

이 글이 답하는 것
  1. 세 가지 원칙 — 망분리(로컬·토큰 0), 권한 등급, 근거 추적
  2. 실전 6단계 — 무엇을 어떤 순서로
  3. 한국어 검색의 심장 — BM25 + 로컬 임베딩 + RRF를 왜 섞나
  4. 품질 증명·비용 진실·직접 짜기 전에 따져볼 것
Part 1 · 세 가지 원칙

똑똑함보다 먼저, 새지 않게

사내 지식 RAG를 설계할 때 저는 세 가지를 못 박고 시작합니다. 이 셋이 흔들리면 나머지는 의미가 없습니다.

원칙 무엇 왜 중요한가
① 망분리·로컬 문서의 ‘의미 좌표(임베딩)’를 외부 API 없이 내 컴퓨터에서 계산 본문이 회사 밖으로 안 나감 · 토큰 비용 0 · 오프라인 가능
② 권한 등급 문서마다 등급(공개/사내/민감/기밀)을 붙이고, 검색하는 사람의 권한 이하만 회수 ‘새는 검색’ 방지 · 한 시스템에서 전사 운영 가능
③ 근거 추적 답에 항상 출처(어느 문서·어느 줄)를 같이 제시 환각(지어내기) 방지 · 사람이 검증·책임질 수 있음
핵심 한 가지 — 로컬 임베딩
의미 검색을 하려면 문장을 숫자 벡터로 바꿔야 하는데, 보통 외부 임베딩 API를 씁니다(= 데이터 전송 + 토큰 비용). 저는 model2vec(정적 임베딩)을 씁니다 — GPU도 외부 API도 없이 CPU에서 도는 작은 모델이라, 회사 데이터를 한 글자도 밖으로 보내지 않고 의미 좌표를 만듭니다. 이 한 수가 망분리를 “기본값”으로 만듭니다.
Part 2 · 실전 6단계

원본에서 ‘믿을 수 있는 검색’까지, 여섯 걸음

지식 시스템 한 벌(export)을 받아서, 다음 순서로 흘려보냅니다. 각 단계는 앞 단계의 결과만 입력으로 받기 때문에, 중간에 끊겨도 그 지점부터 다시 돌릴 수 있습니다.

단계 하는 일 왜 / 무엇을 조심
정제·정규화 불필요한 자료를 거르고 글자코드를 통일. 한글은 자모 분리(NFD)로 깨지기 쉬워 NFC 정규화 필수.
첨부 해체 PDF·엑셀·워드·PPT 첨부를 텍스트로 풀고 본문에 제목을 주입. 스캔 PDF는 글자가 없어 별도 OCR 대상.
보안 태깅 키워드 규칙으로 등급(S0~S3) 부여. 애매하면 더 높은 등급으로(보수적). 이 단계가 ‘새지 않음’을 만든다.
한국어 색인 정확매칭(BM25) + 의미(로컬 임베딩)를 한 순위로 묶는다(RRF). Part 3 참조.
관계 그래프 문서끼리의 내부 링크·첨부 관계를 그래프로. “이 문서가 참조하는 다른 문서”까지 같이 회수.
품질 게이트 대표 질의로 회수 정확도·출처·권한누출을 채점. 기준 미달이면 배포 금지(빌드가 아니라 관문).

이 PoC에서는 화면 문서 3천여 건과 첨부 3백여 건을 색인했고, 전체를 처음부터 다시 만드는 데 약 34초가 걸렸습니다. 일상 운영에서는 ‘바뀐 문서만’ 다시 처리하면 되므로 훨씬 빠릅니다.

Part 3 · 한국어 검색의 심장

정확매칭과 의미검색을 ‘한 순위’로 묶다

한국어 검색이 까다로운 이유는 조사·어미 변화가 심해서입니다(“원가가/원가를/원가는”). 그래서 한 가지 방식만으로는 부족하고, 두 검색을 합칩니다.

  • BM25 (정확매칭) — 단어가 실제로 들어 있는 문서를 잘 찾습니다. 품번·약어·고유명사에 강합니다.
  • 로컬 임베딩 (의미검색) — 글자가 달라도 뜻이 가까운 문서를 찾습니다(“불량”↔”품질 이슈”). model2vec로 외부 전송 없이.
  • RRF (순위 융합) — 두 검색이 매긴 순위를 하나로 합칩니다. 어느 한쪽이 놓친 것을 다른 쪽이 끌어올립니다.

RRF(상호 순위 융합)는 점수의 절대값을 섞지 않고 ‘순위’만 섞습니다. 그래서 BM25 점수와 의미검색 점수의 단위가 달라도 공정하게 합쳐집니다. 두 검색의 장점만 취하는, 단순하지만 튼튼한 방법입니다.

Part 4 · 품질을 어떻게 증명하나

‘골든룰’로 묻고, 게이트로 거른다

“잘 되는 것 같다”는 증거가 아닙니다. 그래서 조직별 표준 질의셋(골든룰)을 미리 만들어 회귀 검증에 씁니다.

  • 조직별 20문항 × 8개 조직 = 160문항 — 영업·연구·생산·품질·경영지원 등 실제 조직 구조에서 나올 법한 질문을 미리 작성합니다.
  • 채점 3축 — 회수 적합도(관련 문서를 가져왔나), 출처 정확도(근거를 맞게 달았나), 권한 누출 0(권한 밖 문서가 새지 않았나).
  • G1 게이트 — 적합도 0.70 이상 그리고 권한 누출 0이어야 통과. 미달이면 배포하지 않습니다.

이 PoC는 160문항 전부에서 관련 문서를 회수했고, 권한 누출 0으로 게이트를 통과했습니다. 핵심은 숫자가 좋다가 아니라, 다음에 무엇을 바꿔도 이 기준으로 다시 잴 수 있다는 점입니다.

어느 회사에나 있는 부서로 만든 골든룰 예시

특정 회사를 떠나, 거의 모든 조직에 공통으로 있는 부서·업무 유형으로 예시를 들어 봅니다. 아래 질문들이 “내 회사 자료로 답이 나오는가”가 곧 골든룰입니다. 권한 등급은 회사 정책에 따라 조정합니다.

부서 골든룰 예시 질문 권한 등급
영업·마케팅 “지난 분기 거래처별 매출 추이는?” · “경쟁사 대비 우리 제품 포지셔닝 자료는?” S2
인사(HR) “직급별 승진 기준과 평가 절차는?” · “신입 온보딩 체크리스트는?” (이력서·개인정보는 더 높은 등급) S2~S3
재무·회계 “월 마감 결산 절차와 담당은?” · “전표 승인 권한 체계는?” S2
구매·조달 “특정 원자재 공급사 단가 이력은?” · “구매 발주 승인 한도 규정은?” S2
생산·운영 “라인별 표준 작업 절차(SOP)는?” · “설비 보전 이력과 다음 점검 일정은?” S2
품질 “최근 고객 클레임 원인분석(RCA) 사례는?” · “검사 기준서 최신본은?” S2
연구개발(R&D) “특정 과제의 시험 결과와 다음 마일스톤은?” (특허·배합비는 기밀) S2~S3
법무·컴플라이언스 “표준 계약서 템플릿과 검토 체크리스트는?” · “개인정보 처리방침 최신본은?” S2
경영지원·총무 “출장비 정산 규정은?” · “사내 보안 정책 문서는?” S1

※ 한 부서당 20문항 정도(쉬운 것 → 까다로운 것 → 권한이 갈리는 것)를 만들면, 부서별 검색 품질을 일정하게 비교할 수 있습니다.

Part 5 · 직접 짜기 전에

빌드 vs 재사용 vs 구매 — 솔직한 교훈

이 작업을 마치고 스스로 가장 크게 반성한 지점입니다. 데이터는 격리하되, 코드는 재사용했어야 했습니다.

선택지 언제 판단
재사용(코드) 먼저 임베더·하이브리드 검색·증분 색인은 이미 검증된 코드가 있으면 그대로 가져온다. 데이터만 격리하면 충분 — 알고리즘까지 새로 짤 이유는 없다.
구매(관리형) 일반 등급 공개·사내(S0/S1) 자료는 관리형 검색 서비스가 더 빠르고 싸다. 단 민감·기밀(S2/S3)은 외부 업로드 금지라 부적합.
직접(custom) 민감 등급 망분리·한국어 토크나이저·권한 ACL·내부 링크 그래프가 필요한 민감 등급에서만 직접 짠다. 여기선 직접이 정답.
한 줄 교훈 — “클라이언트 데이터 격리”를 “코드까지 새로 짜기”로 확대 해석하지 마세요. 데이터·실행 폴더는 분리하되, 임베더·검색·평가 모듈은 import하는 게 유지비용을 크게 줄입니다.
Part 6 · 비용의 진실

작은 조직에선, 관리형 LLM이 GPU보다 쌉니다

사내 RAG를 검토하면 흔히 “GPU 서버를 사야 하나?”부터 묻습니다. 임직원 전용 사내 검색의 실제 부하는 동시 사용자 십수 명·하루 수백 질의 수준으로 매우 작습니다. 이 규모에서 비용을 가르는 건 처리량이 아니라 LLM을 어떻게 쓰느냐입니다.

  • 관리형 LLM API — 이 규모면 월 수만 원~수십만 원대(approx).
  • GPU 상시 보유 — 볼륨과 무관하게 월 100만 원대 이상(approx). 5~15배 비쌈.

결론은 명확합니다 — GPU 상시 보유는 “망분리가 법적으로 강제될 때”나 “주기적 미세조정(파인튜닝)” 때만 정당합니다. 그 외엔 일반 등급은 관리형 API로, 민감 등급만 필요할 때 온디맨드 GPU로 도는 게 가장 경제적입니다. (임베딩은 어차피 로컬·토큰 0이라 이 계산에서 빠집니다.)

Part 7 · 기술 스택

무엇으로 만들었나 — 기술·오픈소스 한눈에

이 6단계를 떠받친 도구와 개념을 모았습니다. 대부분 오픈소스이거나 공개 표준이라, 그대로 따라 만들 수 있습니다. 무거운 프레임워크 없이 가볍게 시작하는 게 핵심입니다.

기술 / 도구 역할 · 설명 링크 · 유형
byeori (벼리) 앱·GPU·클라우드 없이 마크다운을 검색하는 헤드리스 하이브리드 RAG 엔진. 본 파이프라인의 검색 코어 계열(개인용 공개판). byeori 소개 글(CC-5) · 오픈소스 Apache-2.0
Sillok (실록) 조선왕조실록의 감사(audit) 거버넌스를 빌려온 한국형 LLMOS 하네스 — 프롬프트·검색·평가를 운영 규율로 묶는 통제 계층. 소개 글(Z-1) · 내부 하네스
model2vec GPU·torch 없이 CPU에서 도는 정적 임베딩. 문장을 의미 벡터로 — 외부 전송 0, 토큰 비용 0의 핵심. github.com/MinishLab/model2vec · 오픈소스 MIT
potion-multilingual-128M 본 PoC가 쓴 다국어 임베딩 모델(256차원). 한국어·교차언어를 로컬에서 처리. huggingface.co/minishlab/potion-multilingual-128M
BM25 고전 정확매칭 랭킹 함수(Okapi BM25). 품번·약어·고유명사에 강한 어휘 검색. Okapi BM25 (Wikipedia) · 공개 알고리즘
RRF 상호 순위 융합 — 정확매칭과 의미검색의 ‘순위’만 합쳐 둘의 장점을 취함(Cormack et al., SIGIR 2009). RRF 원논문(PDF) · 공개 방법론
유니코드 NFC 한글 자모 분리(NFD)로 깨진 텍스트를 통일하는 정규화. 한국어 검색의 숨은 필수. UAX #15 Normalization · 표준
문서 파서 첨부 텍스트화 — PDF(poppler/pdftotext)·엑셀(openpyxl)·워드(python-docx)·PPT(python-pptx). poppler · openpyxl · 오픈소스

관계 그래프(GraphRAG)는 별도 라이브러리 없이 문서 간 내부 링크·첨부 관계를 직접 엮어 만들었습니다 — LLM에 본문을 보내지 않아 망분리에 안전합니다.

시작하기 · 한계

오늘 시작한다면, 이 체크리스트부터

  1. 데이터 등급 정책부터 합의하세요 — S0~S3의 경계가 곧 시스템의 뼈대입니다(이게 비용·구조를 다 정합니다).
  2. 로컬 임베딩으로 시작하세요 — 외부 API 없이 토큰 0으로 PoC를 돌려 보안 논쟁을 우회합니다.
  3. 골든룰 질의셋을 먼저 만드세요 — 조직별 표준 질문이 있어야 개선을 잴 수 있습니다.
  4. 작게 한 대로 시작하고, 사용량이 보이면 키우세요 — 게이트마다 go/no-go.
정직한 한계 — (1) 스캔된 PDF는 글자가 없어 OCR이 따로 필요합니다. (2) 첨부 문서는 화면 문서에 점수가 밀려 직접 검색 상위에 잘 안 뜨는 약점이 있어, 관계 그래프로 보완하고 세분화·재랭킹은 다음 버전 과제로 둡니다. (3) 본 글의 비용 수치는 규모 가정에 따른 근사치로, 실제 도입 시 각 클라우드 계산기로 확정해야 합니다.

사내 지식 RAG는 거창한 인프라 프로젝트가 아닙니다. 등급을 정하고, 로컬로 좌표를 만들고, 골든룰로 검증하는 — 작은 한 바퀴를 먼저 돌려보면, 회사의 지식이 비로소 “물어볼 수 있는 것”이 됩니다.

— 개인 노트용 헤드리스 검색 도구를 다룬 지난 글(byeori)의 회사 버전입니다. 같은 원리(로컬·하이브리드·근거)를 보안 등급과 권한 위에 올렸습니다.

더 읽을거리

기업 RAG를 더 깊이 — 외부 레퍼런스와 시리즈 상호참조

① 기업 RAG 핵심 레퍼런스 (외부)
RAG 사내검색 지식관리 망분리 model2vec BM25 RRF 한국어 Agentic PM
🛠 실전 도구·실측 (Lv3)

Project Research에서 더 알아보기

지금 구독하여 계속 읽고 전체 아카이브에 액세스하세요.

계속 읽기