사내 LLM RAG 구축 ① 개략도와 시작 전 주의사항 8가지
작년 말 PC 한 대로 사내 AI를 띄워 봤습니다. 맞는 문서는 100% 찾았지만, 문서 내용으로 답한 비율은 0%였습니다. 그 뒤 전체 구조를 다시 설계했고, 지금은 설계 완료·구축 착수 전 단계입니다.
목표는 사내 규정·매뉴얼·공지를 물으면 근거와 함께 답하게 만드는 것입니다. 이 방식을 RAG(검색 증강 생성)라고 부릅니다. AI가 답하기 전에 회사 문서에서 관련 부분을 먼저 찾아 읽게 하는 구조입니다.
연재 순서: ① 개략도와 주의사항 · ② 로컬 시험 실패기 · ③ 실패 뒤에 한 공부 · ④ 문서 처리와 검색(예정) · ⑤ 챗·MCP 연결과 운영(예정)
먼저 결론
- 지금은 설계까지 마쳤고, 구축은 착수 전입니다.
- PC 시험에서 막힌 곳은 단계마다 결과를 따로 볼 수 없다는 점이었습니다.
- 기능 수보다 검색 정확도, 출처 표시, 권한 통제 세 가지가 중요합니다.
- 모든 설정은 평가 질문 30개로 잰 점수로 정하기로 했습니다.
문서는 찾았는데 내용을 못 읽었다
설계부터 하기 전에, 저는 작년 말 PC 한 대로 사내 AI를 직접 띄워 봤습니다. 화면과 RAG 기능은 Open WebUI, AI 모델 실행은 Ollama가 맡았습니다. 문서에서 글자를 뽑는 일은 Apache Tika가 했습니다.
모델은 한국어 LLM(EXAONE 3.5)과 다국어 임베딩 모델(BGE-M3)을 썼습니다. 그래픽카드는 RTX 4060(8GB)이었습니다. 사내 규정 PDF 몇 개를 넣고 질문해 봤습니다.
| 항목 | 목표 | 결과 |
|---|---|---|
| 관련 문서 찾기 | 90% | 100% — 맞는 PDF를 정확히 찾음 |
| 문서 내용으로 답하기 | 90% | 0% — "문서에 해당 내용이 없습니다" |
| 응답 속도 | 빠르게 | 답변 하나에 50~60초 |
| 그래픽카드 메모리 | 8GB 이내 | 약 84% 사용 |
문서는 찾는데 내용을 못 읽었습니다.
처음에 저는 문서를 자르는 단위(청크)가 작아서 제목과 본문이 떨어졌다고 봤습니다. 청크 크기를 1,000자에서 2,000자로, 가져오는 개수를 5개에서 10개로 늘려 다시 올렸습니다. 결과는 같았습니다.
그래서 단계를 나눠 확인했습니다. 문서 변환기(Tika)로 PDF를 직접 글자로 바꿔 보니 본문 한글은 제대로 뽑혔습니다. 글자를 꺼내는 데까지는 됐는데, 화면 도구 안의 RAG가 그 본문을 답에 쓰지 못한 것입니다.
변환·자르기·검색·답변이 한 도구 안에 묶여 있었습니다. 어느 단계에서 끊겼는지 따로 볼 방법이 없었고, 시험은 원인을 확정하지 못한 채 멈췄습니다.
여기서 두 가지를 배웠습니다. RAG는 문서 변환부터 답변까지 단계마다 결과를 따로 꺼내 볼 수 있어야 합니다. 그리고 문서가 제대로 변환됐는지 사람이 직접 확인하는 단계가 필요합니다. 이후 설계는 이 경험에서 출발했습니다.
문서 원본 하나에서 창구 세 개가 나온다
쓰는 사람 입장에서 본 개략도입니다.
관리자가 문서를 한 번 올림
(PDF · Word · PPT · Excel, 보안등급 지정)
│
▼
┌──────────────────┐
│ 사내 지식 저장소 │
└────────┬─────────┘
┌────────────┼────────────┐
▼ ▼ ▼
📖 찾아본다 💬 물어본다 🔌 연결한다
사내 위키 AI 챗 내가 쓰는 AI(MCP)
규정·매뉴얼 답변 + 출처 Claude 등에서
폴더·검색 클릭하면 원문 사내 문서 검색
- 찾아본다: 규정·매뉴얼을 원본 파일이 아니라 읽기 좋은 웹 문서로 보고 검색합니다.
- 물어본다: "OO 지원금 지급 조건 알려줘"처럼 물으면 답과 함께
운영규정 > 지원금 > 제3조같은 출처가 붙습니다. - 연결한다: MCP(AI가 외부 도구를 쓰는 표준 방식)로 평소 쓰는 AI에 사내 지식을 붙여, 보고서나 안내문 초안에 활용합니다.
밖으로 나가는 것은 답변 LLM 하나뿐이다
만드는 사람 입장에서 보면, 문서가 올라온 뒤 아래 과정을 자동으로 거쳐 검색과 챗에 반영됩니다.
[문서 등록] 업로드 + 보안등급(공개 / 사내일반 / 대외비 / 개인정보)
│
▼
[문서 처리] 글자·표·목차 추출 → 문서 유형 분류 → 조항·문답 단위로 자르기
│ → 의미 벡터 만들기(서버 안에서 처리) → 색인
▼
[검색] 키워드 검색 + 의미 검색 결합 → 다시 순위 매기기
│ (부서·등급 권한 필터는 검색 단계에서 적용)
▼
[서비스] 사내 위키 · AI 챗 · MCP · 관리자 화면
│
└──→ 외부로 나가는 것은 하나뿐: 답변을 만드는 LLM API
(공개·사내일반 문서의 발췌만 전송)
회사 AI가 다루는 데이터는 처음부터 두 갈래로 나눴습니다.
회사 AI
┌─────────┴─────────┐
문서 지식 실시간 업무 데이터
(규정·매뉴얼·공지·FAQ) (실적·수수료·인원 현황)
│ │
RAG 검색 업무 시스템 API 조회
"지난달 우리 본부 실적은?" 같은 질문은 문서를 뒤져서 답할 일이 아닙니다. 숫자는 업무 시스템에 직접 물어봐야 정확합니다.
바꾸기 가장 어려운 검색 엔진부터 정했다
| 영역 | 결정 | 이유 |
|---|---|---|
| 검색 엔진 | 키워드 검색과 의미 검색을 한 엔진(OpenSearch)에서 | 나중에 바꾸기 가장 어려운 부분이라 처음부터 제대로. 운영할 시스템 수도 줄어듦 |
| 문서 처리 | 표·목차 구조를 살리는 변환기(Docling) | PC 시험에서 막힌 곳이 바로 여기 |
| 자르는 단위 | 규정은 조항, FAQ는 문답, 매뉴얼은 소제목 | 같은 길이로 자르면 답이 중간에 끊김. 조각마다 "문서 > 장 > 조" 경로를 붙임 |
| 의미 벡터 | 다국어 모델(BGE-M3)을 서버 CPU로 | 사내에 GPU 서버가 없음. 문서 내용이 밖으로 나가지 않게 서버 안에서 처리 |
| 답변 생성 | 외부 LLM API는 답을 만드는 데만 | 대외비·개인정보 문서는 검색 단계에서 빠져 전송 자체가 안 됨 |
| 서버 | 클라우드 서버 1대로 시작 | 파일럿 규모에 맞춤. 저장소·큐·임베딩은 나중에 하나씩 바꿀 수 있게 경계를 나눠 둠 |
시작 전에 짚은 주의사항 8가지
1. 문서 변환이 첫 관문이다
글자가 깨지거나 표가 무너지면, 뒤에서 좋은 모델을 써도 답이 안 나옵니다. PC 시험에서 겪었듯 어느 단계에서 끊겼는지 모르면 고칠 수도 없습니다.
그래서 문서를 올리기 전에 변환 결과를 사람이 직접 열어 보는 단계를 꼭 둡니다. 처음부터 "표 안의 표까지 완벽"을 노리지 않습니다. 본문, 제목, 목차, 일반 표, 페이지 번호부터 확보합니다.
2. 의미 검색만 쓰면 안 된다
업무 질문에는 규정 번호, 제도 이름, 코드처럼 글자 그대로 찾아야 하는 말이 많습니다. 이런 말은 의미 검색보다 키워드 검색이 잘 찾습니다. 두 가지를 섞고(하이브리드), 상위 결과를 한 번 더 정렬하는 구성을 기본으로 둡니다.
3. 권한은 검색 단계에서 막는다
검색한 다음에 권한 없는 결과를 지우는 방식은 쓰지 않습니다. 걸러진 만큼 답이 비고, 실수 한 번이면 볼 수 없는 문서가 답에 섞입니다.
"이 사람이 볼 수 있는 문서 안에서만 검색"하도록 권한 조건을 검색어와 함께 넣습니다. 이 조건을 만드는 곳은 한 군데로 모읍니다.
4. "서버 안에서 처리한다"가 "밖으로 안 나간다"는 뜻은 아니다
의미 벡터를 사내에서 만들어도, 답변을 만들 때는 찾은 문서 일부가 외부 LLM으로 갑니다. MCP로 외부 AI에 연결하면 더 그렇습니다.
그래서 문서마다 보안등급을 붙이고, 파일럿에는 공개·사내일반 등급 문서만 넣습니다. 대외비 이상은 회사 승인과 사내 인프라 이전 뒤에 다룹니다. 외부 API를 쓰는 것 자체도 회사 승인 대상으로 정리해야 합니다.
5. 실시간 숫자는 RAG로 답하지 않는다
실적, 수수료, 인원 현황을 문서로 만들어 넣으면 금방 낡은 숫자로 답합니다. 이런 질문은 업무 시스템 API로 바로 조회하게 하고, 문서 검색과 분리합니다.
6. 평가 질문부터 만든다
인터넷에서 좋다는 모델을 그대로 고르지 않기로 했습니다. 우리 문서로 평가 질문 30개(질문, 정답, 정답 문서, 정답 위치)를 먼저 만듭니다.
기준은 "상위 5개 안에 정답 문서가 있는 비율 80% 이상"으로 잡았습니다. 모델 선택, 자르는 단위, 재정렬 사용 여부를 모두 이 점수로 정합니다.
7. 처음부터 다 하지 않는다
대상 문서를 세어 보니 한글(HWP) 파일은 10% 미만이었습니다. 그래서 가장 어려운 HWP 변환은 뒤로 미루고 PDF·Word·PPT·Excel부터 합니다.
문서 자동 분류, 다른 사이트에 붙이는 챗봇, 업무 데이터 연결도 기본기가 안정된 뒤에 합니다. 첫 목표는 하나입니다. "우리 회사 문서를 물어보면 근거와 함께 정확하게 답하는가."
8. 비용과 속도는 미리 계산하고, 실제로 잰다
설계 단계에서 잡은 추정치는 이렇습니다(2026년 9월 기준 가격, 실측 전).
| 항목 | 추정 |
|---|---|
| 서버 1대 (16GB) | 월 약 12만원 |
| 답변 1건 LLM 비용 | 약 22원 |
| 파일럿 (10명, 하루 5건) | 월 약 14만원 |
| 부서 확산 (50명, 하루 8건) | 월 약 32만원 |
| 질문 1건 응답 시간 | 재정렬 1 |
비용이 커지는 가장 흔한 원인은 대화 기록을 끝없이 붙여 보내는 것입니다. 그래서 최근 몇 번의 대화만 보내고, 사용자별 하루 질문 수에 상한을 둡니다. 답변마다 사용한 토큰을 기록해 관리자 화면에서 실제 비용을 보게 합니다.
반대로 비용을 아끼려고 검색 단계를 빼지는 않기로 했습니다. 검색이 나빠지면 같은 질문을 여러 번 하게 되어 오히려 더 비싸지기 때문입니다.
PC 시험에서 가장 크게 남은 것은 중간 결과를 볼 수 없으면 고칠 수도 없다는 점이었습니다. 2편에서는 그 PC 한 대 시험을 자세히 풉니다. 무엇을 했고, 어디서 막혔고, 왜 원인을 찾지 못했는지입니다.