문서를 학습시키면 사내 지식을 알게 될까?
사내 문서를 LLM에 활용하려고 할 때 흔히 다음 선택지를 마주친다.
- 문서를 검색해 질문과 함께 전달하는 RAG
- 업무 데이터로 모델을 추가 학습하는 파인튜닝
- 필요한 문서를 긴 컨텍스트에 한꺼번에 넣는 방식
세 방법은 모두 모델에 필요한 정보를 제공하는 것처럼 보이지만 해결하려는 문제가 다르다. 최신 규정을 찾아 답해야 하는데 출력 말투를 학습시키거나, 매번 같은 보고서 전체를 보내느라 비용과 지연이 커질 수도 있다.
이번 글에서는 세 가지 가상 업무를 기준으로 선택 방법을 정리한다. 특정 제품의 성능 비교나 실제 구축 결과는 아니며, 구체적인 한도와 비용은 사용하는 모델과 배포 환경에서 확인해야 한다.
1. 세 방법은 무엇을 바꿀까?
가장 먼저 모델의 가중치, 요청할 때 전달하는 입력, 외부에 보관한 지식 저장소를 구분하자.
| 방법 | 주로 바꾸는 것 | 요청할 때 일어나는 일 |
|---|---|---|
| RAG | 외부 문서 저장소와 검색 과정 | 질문과 관련된 문서를 찾아 모델 입력에 추가 |
| 파인튜닝 | 모델 또는 Adapter의 가중치 | 추가 학습된 행동과 패턴으로 답변 생성 |
| 긴 컨텍스트 | 한 요청에 전달하는 입력의 양 | 필요한 문서를 직접 모델 입력에 포함 |
RAG는 Retrieval-Augmented Generation의 약자다. 질문에 관련된 자료를 검색한 뒤 그 내용을 모델에 제공해 답변의 근거로 사용한다. Hugging Face의 RAG 설명
파인튜닝은 사전 학습된 모델을 특정 업무나 도메인의 데이터로 이어서 학습하는 방식이다. 전체 가중치를 조정할 수도 있고, LoRA 같은 PEFT 방식으로 일부 추가 파라미터만 학습할 수도 있다. Hugging Face PEFT 개요
긴 컨텍스트 방식은 별도의 검색 단계 없이 분석할 자료를 요청 안에 직접 넣는다. 컨텍스트 윈도우는 모델이 한 요청에서 처리할 수 있는 입력과 출력의 범위를 뜻한다. 긴 입력을 지원한다고 해서 모든 정보를 같은 정확도로 활용한다는 보장은 없으며, 모델별 한도와 실제 평가가 필요하다. Google의 Long Context 설명
2. 최신 사내 규정을 답하려면: RAG
첫 번째 사례는 규정 질의응답이다.
직원이 “현재 출장 숙박비 한도는 얼마인가요?”라고 물으면 최신 규정과 개정일을 근거로 답한다.
이 업무에서는 지식이 변경될 수 있고 출처가 중요하다. RAG는 원본 문서를 별도로 관리하면서 질문할 때 관련 부분을 찾아 전달할 수 있다.
flowchart LR
A[사용자 질문] --> B[검색 질의 생성]
B --> C[권한이 있는 문서 검색]
C --> D[관련 문서 조각과 출처]
D --> E[LLM 답변 생성]
E --> F[답변과 근거 표시]
규정이 개정되면 문서 저장소와 검색 색인을 갱신할 수 있다. 모델을 다시 학습하지 않아도 최신 문서를 답변에 사용할 수 있다는 점이 장점이다.
하지만 RAG를 붙였다는 이유만으로 답변이 정확해지는 것은 아니다. 검색이 오래된 문서를 가져오거나, 필요한 조항을 문서 분할 과정에서 잘라버리면 모델은 잘못된 문맥을 받는다.
RAG에서는 최소한 다음 단계를 나눠 평가한다.
| 평가 대상 | 확인할 내용 |
|---|---|
| 검색 | 정답 근거가 상위 검색 결과에 포함되는가 |
| 문맥 구성 | 조항 제목·적용 범위·개정일이 함께 전달되는가 |
| 답변 | 전달된 근거와 일치하며 출처를 표시하는가 |
| 권한 | 사용자가 열람할 수 있는 문서만 검색되는가 |
문서 접근 권한은 답변을 만든 뒤 가리는 것보다 검색 전에 적용해야 한다. 권한 없는 문서가 모델 입력이나 로그에 포함되면 이미 정보가 처리된 뒤이기 때문이다.
3. 반복되는 행동을 익히게 하려면: 파인튜닝
두 번째 사례는 반복되는 분류와 응답 방식이다.
민원 내용을 정해진 유형으로 분류하고, 조직에서 사용하는 표현과 출력 형식으로 결과를 작성한다.
충분한 예시와 정답이 있고, 프롬프트만으로 원하는 행동이 안정적으로 나오지 않는다면 파인튜닝을 검토할 수 있다. 모델이 특정 입력 패턴에 어떤 방식으로 응답할지 조정하는 문제에 가깝다.
파인튜닝은 다음과 같은 목표에 사용할 수 있다.
- 조직의 분류 기준에 맞춘 일관된 라벨 선택
- 특정 형식과 문체로 답변하는 행동
- 반복되는 전문 용어나 입력 패턴에 대한 적응
- 긴 설명 없이도 수행할 수 있는 업무 패턴 학습
반면 자주 바뀌는 규정 원문을 모델 가중치에 넣어 문서 저장소처럼 사용하는 것은 관리가 어렵다. 어느 학습 데이터에서 나온 답인지 확인하기 어렵고, 규정이 바뀔 때 재학습과 재평가가 필요하다. 파인튜닝으로 새로운 지식이나 도메인 패턴을 학습할 수 없다는 뜻은 아니다. 갱신과 출처 관리가 중요한 지식을 전달하는 주된 수단으로 적합한지를 따져야 한다.
LoRA는 기본 모델의 가중치를 고정하고 작은 저랭크 행렬을 학습하는 대표적인 PEFT 방법이다. 전체 모델을 학습하는 것보다 학습·보관 비용을 줄일 수 있지만, 적은 파라미터가 항상 같은 성능을 보장하는 것은 아니다. Hugging Face LoRA 설명
파인튜닝 전에는 다음 순서가 현실적이다.
- 명확한 프롬프트와 몇 개의 예시로 기준 성능을 측정한다.
- 구조화된 출력과 코드 검증으로 해결할 수 있는지 확인한다.
- 실패 사례가 반복되는 패턴인지 분석한다.
- 학습·검증·테스트 데이터를 분리해 파인튜닝 전후를 비교한다.
앞선 구조화된 출력 글처럼 JSON Schema와 업무 검증으로 해결할 문제를 학습으로 대신하지 않는다. 올바른 형식과 올바른 값은 파인튜닝 후에도 따로 검증해야 한다.
4. 한 번 분석할 긴 자료라면: 긴 컨텍스트
세 번째 사례는 사용자가 올린 보고서 분석이다.
하나의 긴 감사 보고서를 읽고 주요 지적 사항과 근거 페이지를 요약한다.
자료가 한 요청 안에 들어가고 별도 지식 저장소로 계속 운영할 필요가 없다면 문서 전체를 컨텍스트에 넣는 방식이 단순할 수 있다. 검색 색인과 문서 분할을 먼저 구축하지 않고 원문의 넓은 범위를 함께 볼 수 있다.
긴 컨텍스트가 잘 맞는 경우는 다음과 같다.
- 사용자가 업로드한 문서를 한 번 분석하는 작업
- 여러 장에 걸친 관계를 함께 봐야 하는 요약과 비교
- 대상 문서 수가 적고 요청마다 자료가 달라지는 작업
- 검색 시스템을 운영할 만큼 반복 사용하지 않는 초기 검증
긴 컨텍스트도 비용 없이 모든 문제를 해결하지는 않는다. 입력 토큰이 많으면 일반적으로 첫 토큰까지의 시간이 늘고, 매 요청에 같은 자료를 다시 보내면 입력 처리 비용이 반복된다. 관련 없는 내용이 많아지면 모델이 필요한 근거를 찾는 문제도 남는다.
긴 문서를 사용할 때는 문서와 질문을 구분하고 출처 메타데이터를 유지한다. Anthropic은 긴 문서 입력을 앞에 두고 질문을 뒤에 배치하며, 답변 전에 관련 인용문을 찾도록 하는 방식을 안내한다. Anthropic의 Long Context Prompting 가이드
반복해서 같은 긴 자료를 사용하는 경우에는 제공자가 지원하는 Context Caching을 검토할 수 있다. 다만 캐싱은 긴 입력의 저장·처리 비용을 줄이는 기능이지, 관련 문서를 골라내는 검색 품질 문제를 대신 해결하는 기능은 아니다.
5. 세 가지 사례로 선택해보기
같은 사내 문서 활용이라는 표현 아래에서도 선택은 달라진다.
| 업무 상황 | 우선 검토할 방법 | 이유 |
|---|---|---|
| 계속 개정되는 규정 질의응답 | RAG | 최신 문서와 출처를 별도로 관리하기 쉬움 |
| 반복되는 민원 분류와 일정한 응답 방식 | 프롬프트 평가 후 파인튜닝 | 예시로 행동 패턴을 조정하는 문제에 가까움 |
| 사용자가 올린 긴 보고서 한 건 분석 | 긴 컨텍스트 | 별도 검색 시스템 없이 원문을 직접 분석 가능 |
| 많은 문서에서 근거를 찾아 정해진 형식으로 답변 | RAG + 구조화된 출력, 필요시 파인튜닝 | 지식 검색과 응답 행동을 분리할 수 있음 |
| 같은 대형 문서를 여러 번 질의 | 긴 컨텍스트 + 캐싱 또는 RAG 비교 | 요청 빈도와 질문 범위에 따라 비용 구조가 달라짐 |
선택할 때는 “문서가 몇 장인가?”만 묻지 말고 다음 질문을 함께 본다.
- 정보가 얼마나 자주 바뀌는가?
- 답변에 출처와 개정 이력을 보여줘야 하는가?
- 같은 자료를 얼마나 반복해서 사용하는가?
- 모델이 배워야 하는 것은 지식인가, 행동 방식인가?
- 검색 누락과 긴 입력 중 어느 위험을 관리하기 쉬운가?
- 지연, 토큰 비용, 학습·운영 비용을 어떻게 측정할 것인가?
6. 실제로는 함께 사용하는 경우가 많다
세 방법은 서로 배타적인 선택지가 아니다.
flowchart LR
A[업무 질문] --> B[RAG로 최신 근거 검색]
B --> C[검색 문서를 컨텍스트에 포함]
C --> D[업무 방식에 맞게 조정된 모델]
D --> E[구조화된 답변과 출처]
예를 들어 최신 규정은 RAG로 검색하고, 민원 유형 분류와 답변 형식은 파인튜닝한 Adapter가 담당할 수 있다. 검색한 여러 문서 조각은 결국 모델의 컨텍스트로 전달된다. 즉 RAG를 사용해도 컨텍스트 설계는 사라지지 않는다.
조합이 늘어나면 실패 지점도 늘어난다. 답변이 틀렸을 때 검색 실패인지, 모델의 근거 해석 실패인지, 파인튜닝으로 생긴 행동 변화인지 분리할 수 있도록 단계별 기록과 평가가 필요하다.
7. 작은 기준선부터 비교하기
처음부터 벡터 데이터베이스와 파인튜닝 파이프라인을 모두 구축할 필요는 없다. 대표 문서와 질문으로 작은 평가 세트를 만들고 다음 순서로 비교할 수 있다.
- 기본 모델에 지시문과 예시만 제공한다.
- 문서가 한 번에 들어가면 긴 컨텍스트 방식으로 측정한다.
- 문서가 많거나 갱신·권한 관리가 필요하면 RAG를 비교한다.
- 형식과 행동의 반복 오류가 남으면 파인튜닝 후보를 만든다.
- 조합한 뒤에도 각 단계의 단독 기준선과 비교한다.
평가표에는 다음 항목을 넣을 수 있다. 아래는 측정 결과가 아닌 예시다.
| 항목 | 확인할 내용 |
|---|---|
| 정답 정확도 | 업무 질문에 필요한 사실과 조건이 맞는가 |
| 근거 정확도 | 인용한 문서가 실제 답변을 뒷받침하는가 |
| 최신성 | 개정된 문서를 우선 사용하고 폐기 문서를 배제하는가 |
| 미답변 처리 | 근거가 없을 때 추측하지 않는가 |
| 지연과 비용 | 입력 길이, 검색, 모델 호출, 학습·운영 비용이 어떤가 |
| 접근 통제 | 사용자 권한 밖의 문서가 검색·입력·로그에 노출되지 않는가 |
RAG는 검색과 답변을 따로 평가하고, 파인튜닝은 학습에 쓰지 않은 테스트 데이터로 평가한다. 긴 컨텍스트는 문서 길이와 문서 수, 근거 위치를 바꿔가며 확인한다. 한두 개의 성공 사례만으로 운영 방식을 선택하면 경계 사례를 놓치기 쉽다.
지식과 행동을 분리해서 생각하기
최신 문서를 찾아 근거와 함께 답해야 한다면 RAG가 자연스러운 출발점이다. 일정한 분류와 응답 방식을 반복해서 수행해야 한다면 프롬프트와 검증을 먼저 평가한 뒤 파인튜닝을 고려할 수 있다. 일회성으로 긴 자료 전체를 분석한다면 긴 컨텍스트가 가장 단순할 수 있다.
핵심은 모델에 무엇을 “알게 할지”라는 한 문장에 모두 묶지 않는 것이다. 변하는 지식, 반복할 행동, 이번 요청에서 읽을 자료를 나누면 어떤 방법을 선택하고 무엇을 평가해야 하는지가 선명해진다.