LLM과 RAG란 무엇인가
AI에게 우리 문서를 읽히는 방법

1. LLM은 사실 거대한 숫자 표입니다

LLM은 Large Language Model의 약자로, 우리말로는 대규모 언어모델이라고 합니다. ChatGPT, Claude, Gemini가 모두 여기에 해당합니다.

많은 분들이 LLM을 거대한 도서관처럼 상상합니다. 어딘가에 글이 저장되어 있고 질문하면 찾아서 보여 준다고 생각하는 것입니다. 실제로는 전혀 그렇지 않습니다.

LLM은 수십억 개의 숫자로 이루어진 표에 가깝습니다. 이 숫자 하나하나를 가중치 또는 파라미터라고 부릅니다.

학습 과정에서 모델은 인터넷 문서, 책, 코드 등 어마어마한 분량의 글을 읽습니다. 그런데 그 글을 그대로 보관하지는 않습니다. 글에서 발견한 규칙과 경향만 뽑아내어 숫자 값에 반영합니다. 학습이 끝나면 원본 글은 버려지고 숫자만 남습니다.

// 학습에 사용한 글 (수조 개 분량)
"파리는 프랑스의 수도..."
"태양은 별의 일종..."
          ↓  학습
// 남는 것은 숫자뿐
W[0] =  0.0023
W[1] = -0.0178
...  (수십억 개)

여기서 중요한 결론이 나옵니다. LLM은 사실을 기억하는 것이 아니라 경향을 압축해 두고 있을 뿐입니다. 그래서 자주 접한 내용은 정확하게 말하지만, 어렴풋이 배운 내용은 그럴듯하게 지어냅니다.

이렇게 사실이 아닌 내용을 자신 있게 말하는 현상을 할루시네이션이라고 합니다. 우리말로는 환각이라고 옮기기도 합니다. 이 시리즈에서 계속 등장할 용어이니 기억해 두시기 바랍니다.

숫자를 어떤 형식으로 저장하는가

Qwen3 8B 모델은 약 80억 개, GPT-4는 수천억 개의 가중치를 가진 것으로 알려져 있습니다. 이 많은 숫자를 어떤 형식으로 저장하느냐에 따라 모델이 차지하는 메모리 크기와 계산 속도가 달라집니다.

요즘 가장 널리 쓰이는 것은 BF16입니다. FP32와 비교하면 소수점 아래를 표현하는 자릿수는 줄었지만, 다룰 수 있는 값의 범위는 똑같습니다. 실험 결과 이 정도 정밀도로도 성능 차이가 거의 없다는 것이 확인되어 사실상 표준이 되었습니다.

모델 설명에서 "BF16으로 배포"라는 문구를 보시면, 모델 파일 안의 숫자들을 이 형식으로 저장했다는 뜻이라고 이해하시면 됩니다.

2. LLM 혼자서는 답할 수 없는 것들

LLM이 숫자 표라는 사실을 이해하면, 한계도 자연스럽게 따라 나옵니다.

• 지식 컷오프 — 학습이 끝난 시점 이후의 일은 전혀 모릅니다. 어제 발표된 내용을 알 방법이 없습니다.
• 할루시네이션 — 모르는 것도 자신 있게 지어냅니다. "모르겠습니다"라고 말하도록 따로 훈련하지 않으면 계속 지어냅니다.
• 사내 데이터 부재 — 우리 회사 내부 문서는 학습된 적이 없습니다. 애초에 인터넷에 없는 자료입니다.
• 분량 제한 — 한 번에 읽을 수 있는 글의 양에 한계가 있습니다. 사내 문서 전체를 통째로 넣을 수는 없습니다.

실제로 물어보면 이렇게 됩니다.

두 번째 경우가 특히 위험합니다. 답이 그럴듯해서 틀렸다는 사실을 알아채기 어렵기 때문입니다.

그러면 우리 문서로 다시 학습시키면 되지 않나요

가능은 합니다. 이것을 파인튜닝이라고 부릅니다. 그런데 실무에서는 잘 쓰지 않습니다. 이유는 세 가지입니다.

첫째, 비용이 큽니다. GPU를 오래 돌려야 하고 전문 인력이 필요합니다. 둘째, 규정 한 줄이 바뀔 때마다 다시 학습시켜야 합니다. 셋째, 학습을 시켜도 어느 문서를 근거로 답했는지 밝힐 수 없습니다. 다시 숫자 속에 녹아들어 버리기 때문입니다.

사내 문서를 다루는 시스템에서 출처를 밝히지 못한다는 것은 치명적입니다. 그래서 다른 방법을 씁니다.

3. RAG — 찾아서 알려주는 구조

RAG는 Retrieval Augmented Generation의 약자입니다. 우리말로 풀면 검색으로 보강한 생성입니다.

아이디어는 아주 단순합니다. 질문이 들어오면 먼저 관련 문서를 찾아내고, 그 문서를 질문과 함께 LLM에게 건네준 다음 답을 쓰게 합니다.

비유하자면 이렇습니다. 시험을 볼 때 외운 것만으로 답하게 하는 대신, 관련 페이지를 펴서 책상 위에 올려 주고 그것을 보고 답을 쓰게 하는 것입니다. 오픈북 시험에 가깝습니다.

이렇게 하면 역할이 깔끔하게 나뉩니다. 정확한 지식은 문서가 담당하고, LLM은 문장을 만드는 일만 합니다. LLM의 불확실한 기억력에 의존하지 않게 됩니다.

RAG는 두 단계로 나뉩니다

① 준비 단계 — 문서가 바뀔 때만 실행
   문서 → 조각내기 → 숫자로 변환 → 데이터베이스에 저장

② 질문 단계 — 질문할 때마다 실행
   질문 → 숫자로 변환 → 비슷한 조각 검색 → LLM이 답변 작성

①은 미리 해 둡니다. 한 번 해 두면 질문할 때마다 반복할 필요가 없습니다. ②는 사용자가 질문할 때마다 실행되며, 여기 걸리는 시간이 곧 챗봇의 응답 속도가 됩니다.

각 단계가 구체적으로 무엇을 하는지는 2편부터 하나씩 다룹니다. 지금은 미리 준비해 두고, 질문이 오면 찾아 쓴다는 큰 구조만 잡으시면 충분합니다.

답이 어떻게 달라지는가

앞의 질문에 RAG를 적용하면 답이 이렇게 바뀝니다.

RAG를 적용한 답변 — "2024년 3분기 매출은 1,250억원으로 전년 동기 대비 12% 증가했습니다. (출처: Q3_report.pdf, 4쪽)"

숫자가 실제 문서에서 나왔고, 어느 파일 몇 쪽인지까지 밝히고 있습니다. 사람이 직접 열어서 확인할 수 있다는 점이 중요합니다.

마지막 줄이 실무에서 가장 큰 차이를 만듭니다. 규정이 개정되었을 때, 모델을 다시 학습시키는 것과 PDF 한 장을 바꿔 넣는 것은 비교가 되지 않습니다.

시작 전 안내 (보안)

RAG를 만든다는 것은 사내 문서를 어딘가에 올려서 처리한다는 뜻입니다. 외부 AI 서비스나 상용 API를 사용하면 문서 원문이 회사 밖으로 전송됩니다. 회사 문서·도면·소스코드·개인정보가 포함된 자료는 외부 서비스에 입력하지 마세요.

내부 자료를 다뤄야 한다면 필요한 모델을 모두 사내 서버에 설치해 운영해야 합니다. 이 시리즈 4편에서 그 방법을 다룹니다. 공부하며 직접 만들어 보실 때는 뉴스 기사나 공개된 매뉴얼처럼 공개 자료로 실습하시기 바랍니다.

4. 앞으로 만들 시스템의 전체 그림

이 시리즈를 끝까지 읽으면 다음과 같은 구조를 이해하게 됩니다. 지금은 낯선 단어가 많겠지만, 각각을 이어지는 편에서 하나씩 풀어 갑니다.

[준비 단계 — 문서가 바뀔 때만]

  문서 ──▶ 조각내기 ──▶ 숫자로 변환 ──▶ 데이터베이스 저장
          (청킹)        (임베딩)        (벡터 DB)


[질문 단계 — 질문할 때마다]

  질문 ──▶ 어느 길로 보낼지 판단
            │
            ├─ 문서에서 찾기 ─▶ 검색 ─▶ 순위 재정렬 ─▶ 상위 5개
            │                                             │
            └─ 계산이 필요하면 ─▶ 함수 실행 ─▶ 결과 ──────┤
                                                          ▼
                                              LLM이 답변 작성
                                                          │
                                                          ▼
                                              화면에 한 글자씩 출력

1편부터 4편까지 읽으면 챗봇을 만드는 데 필요한 내용은 모두 채워집니다. 5편은 "그런데 애초에 컴퓨터가 어떻게 의미를 파악하는가"가 궁금한 분을 위한 심화 내용이므로 건너뛰셔도 무방합니다.

5. 자주 나오는 질문

다음 편에서는 준비 단계의 첫 두 작업, 즉 문서를 조각내는 일과 글자를 숫자로 바꾸는 일을 다룹니다.