LLM을 처음 공부할 때 가장 먼저 이해하면 좋은 질문이 하나 있습니다. “이 모델은 문장을 도대체 어떻게 만들어 내는 걸까?” 겉으로 보면 답을 한 번에 떠올린 뒤 그대로 말하는 것처럼 보이지만, 실제 동작 원리는 그보다 훨씬 단순하고도 중요합니다.
핵심은 LLM이 보통 완성된 문장을 한 번에 꺼내는 것이 아니라, 지금까지 본 입력을 바탕으로 다음 토큰의 확률을 계산하고 그 과정을 반복한다는 점입니다. 이 아이디어를 이해하면 프롬프트가 왜 중요한지, 같은 질문에도 왜 답이 조금씩 달라지는지, 환각이 왜 생기는지까지 연결해서 보기 쉬워집니다.
이 글에서는 아래 내용을 다룹니다.
- LLM이 실제로 예측하는 것은 무엇인지
- 확률 기반 생성이 왜 중요한지
- temperature와 top-p가 왜 존재하는지
결론부터 말하면 LLM은 “정답 문장”을 통째로 꺼내는 기계라기보다, 문맥 속에서 다음 토큰의 가능성을 계속 계산하며 출력을 이어 붙이는 모델입니다.
LLM이 실제로 예측하는 것은 단어가 아니라 토큰이다
사람들은 흔히 LLM이 “다음 단어를 예측한다”라고 설명합니다. 입문용으로는 괜찮은 표현이지만, 조금 더 정확하게는 다음 토큰을 예측합니다.
토큰은 항상 단어 하나와 같지 않습니다.
- 단어 전체일 수도 있고
- 단어 일부일 수도 있고
- 쉼표나 마침표 같은 기호일 수도 있고
- 공백이 포함된 조각일 수도 있습니다
예를 들어 영어 문장에서는 Hello, ,, world처럼 나뉠 수 있습니다. 즉 모델은 사람이 생각하는 “문장 단위 의미”를 한 번에 완성하는 것이 아니라, 더 작은 조각들의 연속을 다루고 있습니다.
이 점을 이해하면 왜 출력이 조금씩 달라질 수 있는지, 그리고 프롬프트의 작은 표현 차이도 결과를 바꿀 수 있는지 감이 생깁니다.
다음 토큰 예측은 확률 계산이다
LLM은 보통 후보 하나만 떠올리지 않습니다. 현재까지의 문맥을 보고, 다음에 올 수 있는 여러 토큰에 확률을 부여합니다.
예를 들어 아래 문맥이 있다고 해 봅시다.
The capital of France is
이 경우 Paris는 높은 확률을 받을 가능성이 큽니다. 하지만 시스템은 “무조건 Paris”라는 규칙을 그대로 꺼내는 것이 아니라, 여러 후보 중에서 어떤 토큰이 더 그럴듯한지 계산합니다.
이것이 중요한 이유는 LLM이 규칙 기반 프로그램과 다르게 동작하기 때문입니다. 규칙 기반 시스템은 조건이 맞으면 항상 같은 출력을 내지만, LLM은 문맥과 샘플링 설정에 따라 조금씩 다른 결과를 낼 수 있습니다.
이 과정을 반복하면 긴 문장이 된다
LLM의 생성 흐름은 매우 단순하게 요약할 수 있습니다.
- 지금까지의 토큰을 본다
- 다음 토큰 후보들의 확률을 계산한다
- 하나를 선택한다
- 그 토큰을 현재 문맥에 추가한다
- 다시 반복한다
결국 긴 문단도 이 작은 과정을 여러 번 이어 붙인 결과입니다.
입력 문맥 -> 다음 토큰 선택 -> 문맥 갱신 -> 다음 토큰 선택 -> 반복
이 구조를 알고 나면 “왜 같은 질문인데 매번 조금 다를까?”라는 의문이 훨씬 자연스럽게 풀립니다. 매 단계에서 선택의 여지가 있기 때문입니다.
프롬프트가 중요한 이유도 여기서 나온다
프롬프트는 단순한 지시문이 아니라, 다음 토큰 확률 분포를 바꾸는 입력입니다. 질문을 조금 다르게 쓰거나, 예시를 하나 더 넣거나, 출력 형식을 명확히 적는 것만으로도 모델이 다음에 고를 토큰 후보가 달라집니다.
예를 들어 아래 두 요청은 비슷해 보이지만 모델 입장에서는 꽤 다릅니다.
이 문서를 요약해줘.
이 문서를 3개의 불릿으로 요약하고, 각 불릿은 20자 이내로 작성해줘.
두 번째 요청은 출력 길이, 형식, 요약 방식에 대한 힌트를 더 많이 줍니다. 그래서 다음 토큰 확률 분포가 더 좁고 안정적으로 형성될 가능성이 큽니다. 이것이 프롬프트 엔지니어링 가이드가 중요한 이유이기도 합니다.
Temperature와 top-p는 무엇을 조절할까
다음 토큰을 확률로 계산한다면, 그 확률에서 실제로 무엇을 고를지도 중요합니다. 이때 자주 보게 되는 설정이 temperature와 top-p입니다.
Temperature
temperature는 분포를 얼마나 보수적으로 볼지, 혹은 얼마나 다양하게 열어 둘지를 조절합니다.
- 낮을수록: 더 보수적이고 예측 가능한 출력
- 높을수록: 더 다양한 표현과 덜 뻔한 출력
하지만 여기서 자주 하는 오해가 있습니다. temperature를 높인다고 모델이 더 똑똑해지는 것은 아닙니다. 다양성이 늘어날 수는 있어도 정확성이 자동으로 올라가지는 않습니다.
top-p
top-p는 누적 확률이 일정 기준에 도달할 때까지 상위 후보만 남겨 두고 그 안에서 선택하도록 돕는 방식입니다. 쉽게 말해 너무 가능성이 낮은 후보를 초반에 제외해 선택 범위를 좁히는 장치입니다.
둘 다 결국 “다음 토큰을 어떤 방식으로 고를 것인가”를 조절하는 도구라고 보면 됩니다.
왜 답변이 흔들리거나 환각이 생길까
이 원리를 이해하면 환각도 더 현실적으로 보입니다. LLM은 데이터베이스처럼 정답을 그대로 조회하는 시스템이 아닙니다. 문맥에 그럴듯하게 이어지는 토큰을 생성하는 시스템입니다.
그래서 아래 상황에서 문제가 생기기 쉽습니다.
- 질문이 모호할 때
- 근거 문서가 부족할 때
- 프롬프트가 원하는 형식을 분명히 설명하지 않을 때
- 모델이 그럴듯한 표현을 우선 생성할 때
즉 환각은 단순히 “모델이 거짓말을 한다”라기보다, 확률적으로 자연스러운 출력을 만들다 보니 사실 검증이 약한 지점에서 틀릴 수 있는 구조적 특성과 연결됩니다. 그래서 실무에서는 AI 환각 줄이기 가이드나 RAG 가이드 같은 보완 구조가 중요해집니다.
이 개념을 알면 실무에서 무엇이 달라질까
다음 토큰 예측 구조를 이해하면 아래 판단이 훨씬 쉬워집니다.
- 왜 프롬프트가 출력 품질에 큰 영향을 주는지
- 왜 같은 질문에도 답변이 조금씩 달라질 수 있는지
- 왜 temperature를 업무별로 다르게 잡아야 하는지
- 왜 평가 기준이 필요하고, 단순 감상만으로는 부족한지
예를 들어 고객지원 답변처럼 안정성이 중요하면 더 보수적인 설정과 강한 형식 제어가 필요할 수 있습니다. 반대로 아이디어 브레인스토밍처럼 다양성이 중요하면 다소 열린 샘플링이 도움이 될 수 있습니다.
자주 하는 오해
1. 모델이 먼저 완성된 답을 다 만든 뒤 한 글자씩 보여 준다
겉으로는 그렇게 보일 수 있지만, 실제 생성은 다음 토큰 선택을 반복하는 과정에 더 가깝습니다.
2. temperature를 높이면 더 창의적이니 더 좋다
상황에 따라 다릅니다. 창의성은 늘 수 있어도, 업무 정확성이나 형식 준수는 오히려 떨어질 수 있습니다.
3. 틀린 답은 학습 데이터에 정답이 없어서만 생긴다
항상 그렇지는 않습니다. 확률 기반 생성 구조 자체 때문에 그럴듯하지만 틀린 조합이 나올 수 있습니다.
FAQ
Q. 다음 토큰만 예측하는데 어떻게 긴 설명을 만들 수 있을까
작은 예측이 연속해서 이어지면 긴 문단과 구조화된 답변도 충분히 만들어질 수 있습니다.
Q. 토큰은 단어와 완전히 같은가
아닙니다. 단어 조각, 기호, 공백이 포함된 부분 등 더 잘게 나뉠 수 있습니다.
Q. 이 원리를 알면 프롬프트 작성에도 도움이 될까
그렇습니다. 프롬프트가 결국 다음 토큰 확률 분포에 영향을 주는 입력이라는 점을 이해하면, 어떤 지시가 왜 먹히는지 훨씬 직관적으로 보입니다.
Read Next
- 출력 품질을 더 안정적으로 제어하고 싶다면 프롬프트 엔지니어링 가이드를 이어서 읽어보세요.
- 외부 지식을 문맥에 넣는 방식이 궁금하면 RAG 가이드가 자연스러운 다음 단계입니다.
- 생성 결과를 실제로 어떻게 검증할지 보려면 LLM 평가 가이드도 같이 보면 좋습니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: Redis, RabbitMQ, Kafka 중 어디부터 볼까 Redis, RabbitMQ, Kafka가 함께 있는 시스템에서 지금 보이는 장애가 어느 계층에 더 가까운지, 첫 10분 안에 무엇을 확인하고 어떤 글로 들어가야 하는지 정리한 실전 허브 가이드입니다.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Astro 기술 블로그 SEO 체크리스트: 트래픽 기다리기 전에 먼저 고칠 것 Astro 기술 블로그를 위한 실전 SEO 체크리스트입니다. 배포 호스트 확인, robots.txt, sitemap, canonical, hreflang, 구조화 데이터, 페이지별 메타데이터, noindex 판단, 검증 명령까지 우선순위대로 정리합니다.
- 다국어 블로그 canonical과 hreflang 설정 가이드: 무엇을 확인하고 어디서 깨질까 다국어 블로그에서 canonical과 hreflang을 어떻게 설정해야 하는지 실전 기준으로 정리합니다. self-canonical, 상호 연결되는 hreflang 묶음, x-default, 카테고리 페이지, 최종 렌더 HTML 점검, 한 언어 버전이 다른 언어 버전을 눌러버리는 실수까지 다룹니다.
- OpenAI Codex CLI 설치 가이드: 설치, 인증, 첫 작업까지 OpenAI Codex CLI를 실전 기준으로 설치하는 방법을 정리했다. 설치, 로그인, 첫 실행, Windows 주의점, 첫 작업을 어떻게 시작하면 좋은지까지 다룬다.