LLM은 문장을 통째로 외워 두었다가 꺼내는 검색창이 아닙니다. 입력을 작은 토큰으로 나누고, 앞뒤 맥락의 관계를 계산한 뒤, 다음 토큰의 확률 분포를 바탕으로 토큰을 하나씩 선택해 답변을 만듭니다. 이 구조 덕분에 요약·번역·분류·코드 작성처럼 표현을 바꾸는 일에는 강하지만, 최신 사내 규정의 정확한 문장을 보장하거나 데이터베이스의 현재 값을 조회하는 일은 별도의 장치가 필요합니다.
회의 메모 한 장을 주고 요약을 부탁하는 일과, 사내 문서 수천 개에서 답의 근거를 찾게 하는 일은 준비가 다릅니다. 두 작업 모두 LLM을 쓸 수 있지만, 후자에는 필요한 자료를 골라 가져오는 과정이 더해집니다. 이 차이를 이해하면 문서를 붙여 넣는 것으로 충분한지, RAG를 구성해야 하는지 판단하기 쉬워집니다.
이 글에서 LLM이라고 부르는 것
언어 모델(language model)은 지금까지 주어진 토큰 다음에 어떤 토큰이 올 가능성이 큰지 추정하는 모델입니다. **대규모 언어 모델(LLM)**은 이 작업을 매우 큰 매개변수와 많은 학습 데이터로 수행해, 특정 한 작업만 하도록 만들어지지 않은 범용 모델을 가리킵니다. GPT-3 연구는 큰 사전학습 모델이 별도의 가중치 업데이트 없이도 몇 개의 예시만으로 여러 언어 작업을 수행할 수 있음을 보였지만, 모든 작업에서 같은 수준으로 잘하지는 않는다는 한계도 함께 보고했습니다.
다음 개념은 서로 바꿔 부르면 안 됩니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| 모델 | LLM | 텍스트를 입력받아 다음 토큰을 예측하고 출력을 생성하는 학습된 가중치입니다. | 특정 회사가 제공하는 여러 모델 중 하나 |
| 제품 | 챗봇 | LLM에 대화 화면, 시스템 지시, 안전 정책, 파일·도구 기능을 묶은 애플리케이션입니다. | 웹 대화 서비스나 사내 상담 화면 |
| 구성 | RAG | 질문과 관련된 외부 문서를 검색해 LLM 입력에 넣는 애플리케이션 패턴입니다. | 사내 규정 검색 후 답변과 문서 위치를 함께 제시 |
| 실행 주체 | 에이전트 | LLM이 도구를 선택하고 여러 단계를 반복하며 외부 시스템의 작업까지 수행하는 구조입니다. | 일정 조회 후 승인 요청을 보내는 업무 자동화 |
따라서 “LLM이 검색을 한다”는 말은 보통 모델 자체가 웹 색인을 가진다는 뜻이 아니라, 챗봇이나 에이전트가 검색 도구를 호출했다는 뜻입니다. 이 구분을 먼저 해 두면 모델을 바꿀 때와 검색 파이프라인을 고칠 때의 책임 범위가 섞이지 않습니다.
답변은 토큰을 한 개씩 고르는 과정이다
OpenAI의 토큰 안내처럼 모델이 처리하는 텍스트는 사람이 보는 단어와 정확히 일치하지 않는 토큰 단위로 쪼개집니다. 한국어 한 음절, 영어 단어의 일부, 공백과 문장 부호가 서로 다른 토큰이 될 수 있고, 입력과 출력 토큰 수는 비용과 컨텍스트 길이에 영향을 줍니다.
Transformer 구조는 토큰 사이의 관계를 한 번에 계산하는 셀프 어텐션을 핵심으로 사용합니다. 원 논문은 순환이나 합성곱 없이 어텐션만으로 시퀀스를 처리하고, 병렬 학습이 가능한 구조를 제안했습니다. 실제 모델은 이 블록을 여러 층 쌓아 토큰의 위치·문법·의미 관계를 표현합니다.
개념적으로는 다음 루프입니다.
입력 문장
→ 토큰화
→ 토큰 벡터와 위치 정보
→ 여러 층의 셀프 어텐션
→ 다음 토큰 확률 분포
→ 한 토큰 선택 후 입력에 추가
→ 종료 토큰이 나올 때까지 반복
여기서 “확률이 가장 높은 토큰만 고른다”로 단순화하면 실제 동작과 어긋납니다. 디코딩 설정에 따라 가장 높은 후보를 고르거나, 후보 일부에서 무작위로 선택할 수 있기 때문에 같은 입력에도 표현과 세부 내용이 달라질 수 있습니다. 확률이 높다는 것은 문맥상 그럴듯하다는 뜻이지, 사실이라는 보증이 아닙니다.
“검토”가 “확정”으로 바뀌면 요약은 실패입니다
짧은 가상 회의 메모로 생각해 보겠습니다.
원문: 출시일을 10월로 옮기는 안을 검토했다. 최종 결정은 보류했다.
요청: 결정 상태·담당자·기한을 정리해 줘. 원문에 없으면 미정이라고 써 줘.
검수 기준:
- 결정 상태: 출시일 변경 검토, 최종 결정 보류
- 담당자: 미정
- 확정 기한: 미정
“10월 출시 확정, 개발팀이 월말까지 준비”라는 답은 읽기 편해도 세 군데가 틀립니다. 검토를 확정으로 바꿨고, 담당자를 만들었으며, 출시 후보 월을 준비 마감으로 바꿨습니다. 자연스러운 문장인지보다 원문에 없는 결정을 추가했는지가 먼저입니다.
이 사례는 모델 실행 결과가 아니라 독자가 결과를 판정할 기준입니다. 요청에 없는 값을 미정으로 남기라고 적으면 검수하기 쉬워지지만, 지시만으로 오류가 사라지지는 않습니다. 입력과 예시가 출력을 이끄는 방식은 GPT-3 연구에서도 다뤄집니다.
학습은 사전학습·지시 조정·정렬로 나뉜다
LLM을 “인터넷을 읽고 지식을 저장하는 모델”로만 설명하면 왜 대화형 제품이 지시를 따르는지 이해하기 어렵습니다. 일반적인 개발 흐름은 목적이 다른 단계들을 이어 붙입니다.
- 사전학습: 대규모 텍스트에서 다음 토큰을 예측하며 언어의 통계적 패턴, 문체, 사실과 코드의 반복 구조를 학습합니다. 이 단계의 목표는 사용자의 명령을 안전하게 수행하는 것이 아니라 예측 손실을 줄이는 것입니다.
- 지시 조정: 질문·지시와 모범 답변 쌍으로 추가 학습해 “요약해 달라”, “JSON으로 반환하라” 같은 요청 형식을 따르는 능력을 높입니다.
- 정렬: 사람이 선호하는 답변을 비교·평가한 자료를 사용해 유용성, 정직성, 안전성 같은 행동 기준을 조정합니다. InstructGPT 연구는 사람의 시범 답변과 선호 순위를 이용한 미세 조정이 모델 크기만 키우는 것과 다른 개선을 만들 수 있음을 보여 줬습니다.
이 단계들이 있다고 해서 모델이 거짓말을 하지 않는 것은 아닙니다. 학습 데이터의 편향, 모호한 지시, 부족한 근거, 평가 기준의 빈틈이 모두 출력에 영향을 줍니다. 모델의 “말투”와 “사실 확인”은 서로 다른 품질 축으로 점검해야 합니다.
LLM이 잘하는 일과 약한 일
LLM 단독 사용이 잘 맞는지는 지식의 최신성보다 언어 변환과 패턴 일반화가 문제의 중심인지로 판단할 수 있습니다.
잘하는 편인 작업:
- 초안을 요약하고 독자 수준에 맞게 다시 쓰기
- 몇 개의 예시를 보고 분류 기준이나 출력 형식 추론하기
- 자연어 요구사항을 SQL·코드·정규식의 초안으로 변환하기
- 서로 다른 문장을 같은 관점에서 비교하고 선택지 만들기
주의가 필요한 작업:
- 최신 가격·법률·재고·사내 정책처럼 답이 자주 바뀌는 정보
- 긴 숫자 계산, 식별자 복사, 권한 확인처럼 한 글자 오류도 중요한 작업
- 학습 자료에 없거나 질문 자체가 전제한 사실이 틀린 질문
- 근거 문서와 인용 위치를 반드시 남겨야 하는 감사·의료·법무 판단
OpenAI는 사실과 다른 내용을 그럴듯하게 생성하는 현상을 환각(hallucination)으로 설명합니다. 따라서 “답변을 잘 쓴다”와 “주장이 사실이다”를 같은 점수로 합치지 말고, 필요한 경우 검색·계산기·사람 승인을 연결해야 합니다.
LLM·챗봇·RAG의 관계
LLM은 문장을 생성하는 엔진이고, RAG는 그 엔진이 답을 만들기 전에 외부 자료를 찾아 컨텍스트로 넣는 방식입니다. 둘은 대체재라기보다 층위가 다릅니다. RAG도 마지막 문장 생성은 LLM에 의존하고, LLM 단독 앱도 필요할 때 검색 도구를 붙여 하이브리드가 될 수 있습니다.
가장 흔한 RAG 흐름은 다음과 같습니다.
- 사용자의 질문을 검색 쿼리로 정리합니다.
- 문서 저장소에서 키워드·벡터·하이브리드 검색으로 관련 조각을 찾습니다.
- 권한 필터와 출처 정보를 확인한 뒤 컨텍스트를 구성합니다.
- LLM에게 “컨텍스트 안에서만 답하고 근거가 없으면 모른다고 말하라”고 지시합니다.
- 답변과 함께 사용한 문서, 검색 점수, 실패 로그를 저장합니다.
원래 RAG 연구도 사전학습 모델의 매개변수 기억(parametric memory)과 검색 인덱스라는 비매개변수 기억(non-parametric memory)을 결합해 지식 집약적 작업의 근거성과 최신성을 보완하려는 구조로 설명합니다.
LLM 단독과 RAG는 무엇이 다른가
두 방식을 비교할 때 “정확도” 하나만 보지 말고, 어떤 실패를 감수할 수 있는지와 운영 부담을 함께 적어야 합니다.
검색을 추가하면 답변에 쓸 문서를 찾는 부담을 줄일 수 있지만, 문서 수집·분할·권한·검색 품질을 관리할 일이 생깁니다. 문서를 찾았다는 사실과 답변이 그 문서에 충실하다는 사실도 따로 확인해야 합니다. Microsoft의 RAG 설계 가이드는 검색과 최종 답변을 나누어 평가하는 구조를 설명합니다.
최신 자료 한 장을 주는 데도 RAG가 필요할까요?
“이번 달 환불 가능 기간과 예외 조건을 알려 줘”라는 질문을 생각해 보겠습니다. 최신성이 필요하다는 이유만으로 검색 시스템부터 만들 필요는 없습니다. 핵심은 누가 어떤 원문을 골라 모델에 전달하는가입니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| 직접 제공 | 확인할 정책이 한 장이면 | 담당자가 최신 원문을 입력에 넣고 그 범위에서만 요약하도록 합니다. 출처와 조항도 함께 전달합니다. | 짧은 환불 정책을 붙여 넣고 예외 조항 확인 |
| 질문별 검색 | 문서가 많고 필요한 부분이 달라지면 | 사용자에게 허용된 문서 중 질문에 맞는 부분을 찾아 입력에 넣습니다. 검색 누락과 문서 버전도 관리해야 합니다. | 상품·국가·계약별 정책에서 해당 조항 검색 |
| 정확한 값 조회 | 현재 주문 상태가 답을 결정하면 | 인증된 API나 데이터베이스에서 주문일·취소 상태를 읽고 정책 코드가 적용 여부를 판정합니다. LLM은 그 결과를 설명합니다. | 정책 설명과 실제 환불 가능 판정 분리 |
OpenAI의 파일 입력 문서는 파일을 모델 입력으로 직접 제공하는 경로를 설명합니다. 검색 가이드는 질문과 관련된 문서 조각을 찾아 모델의 답변에 활용하는 경로를 다룹니다. 원문 직접 제공과 검색은 모두 외부 근거를 활용하지만, 자료를 고르는 단계가 다릅니다. 파일 업로드 버튼이 있다는 사실만으로 제품 내부가 어느 방식을 쓰는지는 알 수 없습니다.
직접 제공도 오래된 정책을 붙여 넣으면 틀립니다. RAG도 “일반 상품 14일” 조항만 찾고 “주문 제작 상품 제외”를 놓치면 틀립니다. 따라서 기간 숫자가 맞는지만 보지 말고 예외 조항까지 포함됐는지 대조해야 합니다. 원문에 고객의 주문 정보가 없다면 실제 환불 가능 여부는 미확인으로 남깁니다.
문서 수가 적고 매번 사람이 올바른 원문을 고를 수 있다면 직접 제공부터 시작할 수 있습니다. 질문마다 문서를 고르는 부담이 커질 때 검색을 검토하고, 구현 단계는 RAG 구현 가이드로 이어 가면 됩니다.
LLM을 서비스에 붙이기 전 체크리스트
- 이 기능의 답이 틀렸을 때 가장 큰 피해는 무엇인가?
- 최신성·권한·인용 중 반드시 지켜야 할 조건은 무엇인가?
- 모델이 해도 되는 일과 코드·API·사람이 해야 하는 일을 분리했는가?
- 입력·출력·검색 문서에 개인정보와 비밀이 섞일 때 보존·마스킹 정책이 있는가?
- 정상 질문뿐 아니라 답이 없는 질문과 권한 밖 질문을 준비했는가?
- 같은 사례를 여러 버전과 설정으로 다시 실행할 수 있는가?
- 평균 점수 뒤에 숨은 치명적 실패를 별도 기준으로 막는가?
LLM 앱은 모델 호출 하나로 끝나지 않습니다. 프롬프트, 검색, 도구, 출력 파서, 권한, 사용자 인터페이스가 함께 만든 결과입니다. 어느 한 부분의 “성공”을 전체 품질로 확장하지 않는 것이 운영의 첫 안전장치입니다.
자주 묻는 질문
LLM은 학습한 문서를 그대로 기억하나요?
일부 문구가 재현될 수는 있지만, 일반적인 답변은 매개변수에 압축된 패턴과 현재 컨텍스트를 바탕으로 새 토큰을 생성합니다. 원문을 정확히 찾아 인용해야 한다면 원본 저장소나 RAG를 함께 사용하세요.
RAG를 붙이면 환각이 사라지나요?
아닙니다. 문서가 검색되지 않거나, 잘못된 청크가 들어오거나, 모델이 근거 밖 내용을 덧붙일 수 있습니다. 검색 품질·근거 충실도·답변 완전성을 각각 평가해야 합니다.
파인튜닝과 RAG 중 무엇을 먼저 해야 하나요?
말투·출력 형식·반복 작업의 행동을 바꾸려면 파인튜닝을 검토하고, 자주 바뀌는 사실·사내 문서·인용을 다루려면 RAG를 먼저 검토하는 식으로 목적을 나눕니다. 둘을 함께 쓸 수도 있지만, 데이터 갱신 문제를 파인튜닝만으로 해결하려고 하면 재학습 주기가 운영 부담이 됩니다.
더 큰 모델이면 항상 더 정확한가요?
크기는 능력의 한 요소일 뿐입니다. InstructGPT 연구처럼 사용자 의도에 맞춘 조정이 크기보다 중요한 경우가 있고, 작은 모델과 정확한 검색·코드 검증을 조합하는 편이 전체 시스템에는 더 나을 수 있습니다.
LLM이 데이터베이스를 대신할 수 있나요?
아닙니다. 데이터베이스는 현재 값, 제약 조건, 트랜잭션, 권한을 결정적으로 보존합니다. LLM은 그 값을 설명하거나 자연어를 쿼리 초안으로 바꾸는 인터페이스로 사용하는 편이 안전합니다.
LLM을 이해하는 가장 실용적인 방법은 모델을 숭배하거나 불신하는 것이 아니라, 답변에 필요한 지식과 책임을 분해하는 것입니다. 언어를 바꾸는 일은 LLM에, 현재 사실과 권한은 원본 시스템과 검색에, 최종 판단은 사람과 검증 코드에 맡기면 RAG를 선택할 때도 선택하지 않을 때도 이유를 설명할 수 있습니다.
VIEW—
