LLM은 문장을 통째로 외워 두었다가 꺼내는 검색창이 아닙니다. 입력을 작은 토큰으로 나누고, 앞뒤 맥락의 관계를 계산한 뒤, 다음에 올 토큰의 확률을 한 개씩 선택해 답변을 만듭니다. 이 구조 덕분에 요약·번역·분류·코드 작성처럼 표현을 바꾸는 일에는 강하지만, 최신 사내 규정의 정확한 문장을 보장하거나 데이터베이스의 현재 값을 조회하는 일은 별도의 장치가 필요합니다.
이 글에서 말하는 LLM 위키는 특정 제품이나 표준 이름이 아니라, 대규모 언어 모델을 처음 접한 사람이 원리·학습·활용·한계를 한 번에 찾아볼 수 있도록 정리한 참고 문서 형식입니다. 핵심은 “LLM이 무엇인가”에서 멈추지 않고, RAG가 언제 필요한지와 LLM 단독이 더 나은 경우까지 같은 기준으로 판단하는 데 있습니다.
- 정의모델·챗봇·에이전트·RAG를 서로 다른 층위의 개념으로 구분합니다.
- 생성토큰화·어텐션·확률적 디코딩이 한 토큰씩 답을 만드는 과정을 봅니다.
- 학습사전학습에서 지시 조정과 정렬까지 목적이 어떻게 바뀌는지 확인합니다.
- 선택최신성·권한·출처·지연 시간·운영 비용에 따라 LLM과 RAG를 나눕니다.
- 검증환각과 검색 실패를 전제로 사람·코드·로그를 함께 사용합니다.
이 글에서 LLM이라고 부르는 것
언어 모델(language model)은 지금까지 주어진 토큰 다음에 어떤 토큰이 올 가능성이 큰지 추정하는 모델입니다. **대규모 언어 모델(LLM)**은 이 작업을 매우 큰 매개변수와 많은 학습 데이터로 수행해, 특정 한 작업만 하도록 만들어지지 않은 범용 모델을 가리킵니다. GPT-3 연구는 큰 사전학습 모델이 별도의 가중치 업데이트 없이도 몇 개의 예시만으로 여러 언어 작업을 수행할 수 있음을 보였지만, 모든 작업에서 같은 수준으로 잘하지는 않는다는 한계도 함께 보고했습니다.
다음 개념은 서로 바꿔 부르면 안 됩니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| 모델 | LLM | 텍스트를 입력받아 다음 토큰을 예측하고 출력을 생성하는 학습된 가중치입니다. | 특정 회사가 제공하는 여러 모델 중 하나 |
| 제품 | 챗봇 | LLM에 대화 화면, 시스템 지시, 안전 정책, 파일·도구 기능을 묶은 애플리케이션입니다. | 웹 대화 서비스나 사내 상담 화면 |
| 구성 | RAG | 질문과 관련된 외부 문서를 검색해 LLM 입력에 넣는 애플리케이션 패턴입니다. | 사내 규정 검색 후 답변과 문서 위치를 함께 제시 |
| 실행 주체 | 에이전트 | LLM이 도구를 선택하고 여러 단계를 반복하며 외부 시스템의 작업까지 수행하는 구조입니다. | 일정 조회 후 승인 요청을 보내는 업무 자동화 |
따라서 “LLM이 검색을 한다”는 말은 보통 모델 자체가 웹 색인을 가진다는 뜻이 아니라, 챗봇이나 에이전트가 검색 도구를 호출했다는 뜻입니다. 이 구분을 먼저 해 두면 모델을 바꿀 때와 검색 파이프라인을 고칠 때의 책임 범위가 섞이지 않습니다.
답변은 토큰을 한 개씩 고르는 과정이다
OpenAI의 토큰 안내처럼 모델이 처리하는 텍스트는 사람이 보는 단어와 정확히 일치하지 않는 토큰 단위로 쪼개집니다. 한국어 한 음절, 영어 단어의 일부, 공백과 문장 부호가 서로 다른 토큰이 될 수 있고, 입력과 출력 토큰 수는 비용과 컨텍스트 길이에 영향을 줍니다.
Transformer 구조는 토큰 사이의 관계를 한 번에 계산하는 셀프 어텐션을 핵심으로 사용합니다. 원 논문은 순환이나 합성곱 없이 어텐션만으로 시퀀스를 처리하고, 병렬 학습이 가능한 구조를 제안했습니다. 실제 모델은 이 블록을 여러 층 쌓아 토큰의 위치·문법·의미 관계를 표현합니다.
LLM은 문장을 검색 결과로 복사하지 않고, 토큰 관계를 계산해 다음 토큰을 반복 생성합니다.
개념적으로는 다음 루프입니다.
입력 문장
→ 토큰화
→ 토큰 벡터와 위치 정보
→ 여러 층의 셀프 어텐션
→ 다음 토큰 확률 분포
→ 한 토큰 선택 후 입력에 추가
→ 종료 토큰이 나올 때까지 반복
여기서 “확률이 가장 높은 토큰만 고른다”로 단순화하면 실제 동작과 어긋납니다. 디코딩 설정에 따라 가장 높은 후보를 고르거나, 후보 일부에서 무작위로 선택할 수 있기 때문에 같은 입력에도 표현과 세부 내용이 달라질 수 있습니다. 확률이 높다는 것은 문맥상 그럴듯하다는 뜻이지, 사실이라는 보증이 아닙니다.
학습은 사전학습·지시 조정·정렬로 나뉜다
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는 무엇이 다른가
두 방식을 비교할 때 “정확도” 하나만 보지 말고, 어떤 실패를 감수할 수 있는지와 운영 부담을 함께 적어야 합니다.
RAG는 모델을 바꾸는 기술이 아니라, 추론 시점에 외부 문서를 컨텍스트로 공급하는 구성입니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| 지식 | LLM 단독 | 학습이 끝난 시점의 매개변수 기억과 현재 대화 컨텍스트를 사용합니다. | 일반 개념 설명, 문장 변환, 창작 초안 |
| 지식 | RAG | 질문마다 외부 인덱스에서 찾은 문서를 추가 컨텍스트로 사용합니다. | 변경되는 사내 규정, 제품 매뉴얼, 계약 조항 |
| 운영 | LLM 단독 | 검색 인덱스·청킹·임베딩 파이프라인이 없어 지연과 구성 요소가 적습니다. | 작은 팀의 초안 도우미 |
| 운영 | RAG | 문서 수집·권한 필터·검색 품질·출처 연결을 지속적으로 관리해야 합니다. | 부서별 접근 권한이 있는 지식 상담 |
| 검증 | LLM 단독 | 그럴듯한 오답과 오래된 정보를 별도 검증 없이 구분하기 어렵습니다. | 최신 정책을 묻는 질문에는 부적합 |
| 검증 | RAG | 문서가 검색됐다는 사실과 답변이 문서에 충실하다는 사실을 각각 검증해야 합니다. | 검색 누락·잘못된 청크·근거 밖 추론 점검 |
Microsoft의 RAG 설계 가이드도 준비·청킹·임베딩·검색·최종 답변을 나눠 평가하라고 설명합니다. 즉 RAG를 붙이면 자동으로 정확해지는 것이 아니라, 검색 실패라는 새로운 실패면이 생깁니다.
RAG보다 LLM 단독이 유리한 경우
“RAG보다 좋다”는 보편적인 순위가 아니라, 검색을 추가할 때 얻는 이득보다 복잡성이 커지는 상황을 뜻합니다.
- 지식이 작고 안정적일 때: 제품 설명이 짧고 자주 바뀌지 않으면 긴 인덱스보다 시스템 지시와 소수의 예시가 단순합니다.
- 문장 변환이 목표일 때: 요약·번역·톤 변경은 외부 문서를 찾는 것보다 입력과 출력의 스타일 계약을 지키는 일이 핵심입니다.
- 낮은 지연 시간이 중요할 때: 검색 왕복과 재순위화 단계를 없애면 요청 경로를 짧게 만들 수 있습니다. 단, 모델 호출 시간과 출력 토큰 비용은 별도로 남습니다.
- 외부 저장소에 질문을 보내면 안 될 때: 로컬 모델이나 승인된 입력 경계를 사용하면 검색 서비스로 민감한 질문을 전송하지 않는 설계를 할 수 있습니다. 실제 보안 수준은 모델·로그·호스팅 정책까지 확인해야 합니다.
- 실패해도 사람이 검토하는 초안일 때: 카피 초안이나 회의 요약처럼 최종 승인자가 있고 최신 근거가 필수가 아니라면 먼저 단순한 LLM 흐름으로 시작할 수 있습니다.
반대로 “사내 문서를 학습시켜야 최신 내용을 안다”는 요구만으로 파인튜닝을 선택할 필요는 없습니다. 문서가 자주 바뀌고 인용이 필요하면 RAG가 데이터 갱신과 출처 표시를 더 직접적으로 다루는 경우가 많습니다.
RAG가 더 유리한 경우와 RAG의 대가
다음 조건이 하나라도 중요하면 RAG 또는 선택적 검색을 먼저 검토하세요.
- 답이 오늘의 가격·재고·법·정책처럼 변경 시점에 민감하다.
- 답변마다 어떤 문서의 어느 부분을 사용했는지 출처를 제시해야 한다.
- 사용자·부서별로 볼 수 있는 문서가 달라 권한 필터가 필요하다.
- 모델이 학습하지 않은 사내 용어와 절차를 정해진 문서 안에서만 설명해야 한다.
다만 RAG는 다음 비용을 함께 가져옵니다.
- 문서를 작게 자르는 청킹 기준이 틀리면 필요한 문장이 검색에서 빠집니다.
- 임베딩·키워드·재순위 모델 선택과 인덱스 갱신을 운영해야 합니다.
- 검색 지연과 컨텍스트 토큰이 늘어 호출 비용이 커질 수 있습니다.
- 권한 필터가 검색 단계에서 빠지면 모델이 답변에서 숨기더라도 민감한 정보가 프롬프트에 들어갈 수 있습니다.
- 관련 없는 문서가 섞이면 LLM이 오히려 혼란스러운 근거를 따라갈 수 있습니다.
따라서 RAG의 성공 기준은 “검색 결과가 있다”가 아니라 필요한 근거를 권한에 맞게 찾고, 답변이 그 근거를 벗어나지 않는가입니다.
LLM의 장점과 단점
LLM 단독을 선택할 때도 장점만 보고 도입하지 않도록 다음 네 축을 함께 기록하세요.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| 장점 | 범용성 | 한 모델이 요약·분류·생성·코드 등 여러 언어 작업을 같은 인터페이스로 처리합니다. | 작업마다 별도 모델을 연결하지 않는 초기 제품 |
| 장점 | 적은 예시로 전환 | 프롬프트의 지시와 예시만 바꿔 새 작업을 빠르게 시도할 수 있습니다. | 분류 라벨이 바뀐 내부 초안 |
| 단점 | 환각과 오래된 지식 | 자연스러운 문장을 사실 확인으로 착각할 수 있고 학습 이후의 변화는 자동으로 반영되지 않습니다. | 최신 규정·가격·통계 답변 |
| 단점 | 비결정성과 비용 | 같은 입력의 표현이 달라질 수 있고 긴 컨텍스트와 출력 토큰이 비용을 늘립니다. | 정확한 재현이 필요한 배치 처리 |
| 단점 | 권한·감사 공백 | 모델만 호출하면 어떤 원문을 근거로 했는지와 사용자 권한을 설명하기 어렵습니다. | 감사 가능한 사내 지식 답변 |
장점을 살리는 방법은 모델을 만능 데이터베이스처럼 쓰지 않는 것입니다. 계산은 계산기나 코드로, 현재 값은 시스템 API로, 권한은 원본 서비스로 확인한 뒤 LLM에는 결과를 설명하고 형식을 맞추는 역할을 맡기면 실패 범위를 줄일 수 있습니다.
같은 질문을 두 방식으로 설계해 보기
다음은 특정 서비스의 성능을 측정한 결과가 아니라, 설계 차이를 보여 주는 개념 예시입니다.
질문: “이번 달 환불 가능 기간과 예외 조건을 알려 줘.”
- 고정된 공개 FAQ를 짧게 정리하는 기능이면 LLM 단독에 정책 요약 프롬프트를 넣고, 원문 링크를 화면에 정적으로 붙일 수 있습니다.
- 환불 규정이 매달 바뀌거나 고객 등급별 예외가 다르면 RAG가 최신 정책 문서와 고객 등급 데이터를 조회한 뒤, 답변 문장마다 근거를 연결해야 합니다.
- 두 조건이 섞이면 먼저 정책 API로 현재 값을 확인하고, LLM은 검색된 조항을 고객이 이해하기 쉬운 순서로 바꾸는 하이브리드가 적합합니다.
선택 로직을 코드로 옮길 때의 출발점은 다음과 같습니다.
if 최신성 or 사용자별 권한 or 인용이 필수:
검색·권한 필터·근거 기록을 포함한 RAG
elif 문장 변환 or 일반 설명 or 작고 안정적인 지식:
LLM 단독
else:
질문별로 검색 여부를 결정하는 하이브리드
이 분기는 최종 답을 자동으로 보장하지 않습니다. 검색하지 않기로 한 질문이 실제로 최신 정보였는지, 검색한 문서가 질문의 모든 조건을 덮었는지를 로그와 샘플 검토로 확인해야 합니다.
선택 기준은 모델의 유행보다 지식의 변화 속도, 권한 경계, 출처 요구, 지연·운영 비용입니다.
LLM을 서비스에 붙이기 전 체크리스트
- 이 기능의 답이 틀렸을 때 가장 큰 피해는 무엇인가?
- 최신성·권한·인용 중 반드시 지켜야 할 조건은 무엇인가?
- 모델이 해도 되는 일과 코드·API·사람이 해야 하는 일을 분리했는가?
- 입력·출력·검색 문서에 개인정보와 비밀이 섞일 때 보존·마스킹 정책이 있는가?
- 정상 질문뿐 아니라 답이 없는 질문과 권한 밖 질문을 준비했는가?
- 같은 사례를 여러 버전과 설정으로 다시 실행할 수 있는가?
- 평균 점수 뒤에 숨은 치명적 실패를 별도 기준으로 막는가?
LLM 앱은 모델 호출 하나로 끝나지 않습니다. 프롬프트, 검색, 도구, 출력 파서, 권한, 사용자 인터페이스가 함께 만든 결과입니다. 어느 한 부분의 “성공”을 전체 품질로 확장하지 않는 것이 운영의 첫 안전장치입니다.
자주 묻는 질문
LLM은 학습한 문서를 그대로 기억하나요?
일부 문구가 재현될 수는 있지만, 일반적인 답변은 매개변수에 압축된 패턴과 현재 컨텍스트를 바탕으로 새 토큰을 생성합니다. 원문을 정확히 찾아 인용해야 한다면 원본 저장소나 RAG를 함께 사용하세요.
RAG를 붙이면 환각이 사라지나요?
아닙니다. 문서가 검색되지 않거나, 잘못된 청크가 들어오거나, 모델이 근거 밖 내용을 덧붙일 수 있습니다. 검색 품질·근거 충실도·답변 완전성을 각각 평가해야 합니다.
파인튜닝과 RAG 중 무엇을 먼저 해야 하나요?
말투·출력 형식·반복 작업의 행동을 바꾸려면 파인튜닝을 검토하고, 자주 바뀌는 사실·사내 문서·인용을 다루려면 RAG를 먼저 검토하는 식으로 목적을 나눕니다. 둘을 함께 쓸 수도 있지만, 데이터 갱신 문제를 파인튜닝만으로 해결하려고 하면 재학습 주기가 운영 부담이 됩니다.
더 큰 모델이면 항상 더 정확한가요?
크기는 능력의 한 요소일 뿐입니다. InstructGPT 연구처럼 사용자 의도에 맞춘 조정이 크기보다 중요한 경우가 있고, 작은 모델과 정확한 검색·코드 검증을 조합하는 편이 전체 시스템에는 더 나을 수 있습니다.
LLM이 데이터베이스를 대신할 수 있나요?
아닙니다. 데이터베이스는 현재 값, 제약 조건, 트랜잭션, 권한을 결정적으로 보존합니다. LLM은 그 값을 설명하거나 자연어를 쿼리 초안으로 바꾸는 인터페이스로 사용하는 편이 안전합니다.
공식 문서
- Attention Is All You Need — arXiv
- Language Models are Few-Shot Learners — arXiv
- Training language models to follow instructions with human feedback — arXiv
- What are tokens and how to count them? — OpenAI
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — arXiv
- Design and Develop a RAG Solution on Azure — Microsoft
- Does ChatGPT tell the truth? — OpenAI
LLM을 이해하는 가장 실용적인 방법은 모델을 숭배하거나 불신하는 것이 아니라, 답변에 필요한 지식과 책임을 분해하는 것입니다. 언어를 바꾸는 일은 LLM에, 현재 사실과 권한은 원본 시스템과 검색에, 최종 판단은 사람과 검증 코드에 맡기면 RAG를 선택할 때도 선택하지 않을 때도 이유를 설명할 수 있습니다.
