LLM이 문장을 만드는 과정을 “질문을 이해한 뒤 정답을 꺼낸다”라고 설명하면 실제 동작을 놓치기 쉽습니다. 텍스트 생성 모델의 기본 흐름은 입력을 토큰 단위로 바꾸고, 사용 가능한 컨텍스트를 계산에 반영해 다음 토큰의 점수를 만든 뒤, 제품이 허용하는 생성 설정과 디코딩 절차로 출력 토큰을 고르는 과정에 가깝습니다.
제품 문서와 기술 논문을 대조한 기준일은 2026년 9월 15일입니다. Transformer와 자기회귀 생성은 널리 쓰이는 설명 틀이지만, 현재 상용 모델의 토크나이저·어텐션 변형·추론 단계·디코딩 후처리는 공급사와 모델 버전에 따라 다르며 상당 부분 공개되지 않습니다. 따라서 아래 흐름을 모든 LLM의 동일한 내부 설계도라고 단정하지 않습니다.
먼저 보는 전체 흐름
생성 과정은 다음 단계로 나눌 수 있습니다.
- 입력 텍스트와 메시지 구조가 해당 모델의 토크나이저를 거쳐 토큰 ID로 바뀝니다.
- 모델은 컨텍스트에 들어온 토큰 표현과 위치·관계 정보를 계산에 반영합니다.
- 현재까지의 컨텍스트를 조건으로 다음 토큰 후보들의 점수 또는 확률 분포를 만듭니다.
- 모델과 API가 지원하는 디코딩·샘플링 설정에 따라 출력할 토큰을 고릅니다.
- 선택된 토큰이 컨텍스트에 더해지고, 중지 조건을 만날 때까지 생성이 이어집니다.
이 순서는 독자가 관찰할 수 있는 생성 개념을 정리한 것입니다. 공급사의 비공개 추론 과정, 안전 필터, 도구 호출, 서버 측 라우팅까지 모두 나타낸 것은 아닙니다.
1. 토큰화: 단어가 아니라 모델의 처리 단위로 바꾼다
토큰은 반드시 단어나 “의미 있는 최소 단위”와 같지 않습니다. 한 글자, 구두점, 공백이 포함된 조각, 단어 일부 또는 더 긴 문자열이 토큰이 될 수 있습니다. 어떤 조각을 하나의 토큰으로 삼는지는 토크나이저의 어휘와 규칙에 달려 있습니다. SentencePiece 논문도 원문 문자열에서 서브워드 단위를 학습하고 분할하는 한 가지 방식을 설명합니다.
따라서 안녕하세요, 안녕 하세요, 안녕하세요!가 같은 수의 토큰이 된다고 미리 가정할 수 없습니다. 언어가 다르거나 띄어쓰기·구두점이 바뀌면 분할 결과도 달라질 수 있고, 같은 문장도 모델 계열이 바뀌면 토큰 수가 달라질 수 있습니다. Google은 Gemini 토큰 이해·계산 문서에서 텍스트뿐 아니라 이미지 등 비텍스트 입력도 모델별 방식으로 토큰화되며, 실제 입력 토큰은 count_tokens와 응답의 사용량 메타데이터로 확인하도록 안내합니다.
토큰 ID는 그 자체로 뜻을 담은 사전 정의 번호가 아닙니다. 모델은 학습된 임베딩을 통해 ID를 벡터 표현으로 바꾸고 다음 계산에 사용합니다. 토큰 분할과 임베딩은 이어지는 단계지만 서로 같은 개념은 아닙니다.
2. 컨텍스트와 어텐션: 관계를 계산하지만 완벽한 기억은 아니다
컨텍스트는 현재 요청에서 모델이 계산에 사용할 수 있도록 제공된 입력과 이전 출력 등의 범위입니다. 제품에 따라 시스템 지시, 대화 기록, 도구 결과, 이미지와 파일 표현도 포함될 수 있습니다. 컨텍스트 윈도우는 이 범위의 상한과 관련되지만, 긴 입력이 들어간다는 사실이 모든 세부 내용을 같은 정확도로 활용한다는 보장은 아닙니다.
원 Transformer 논문은 어텐션을 질의(query)와 키·값(key-value) 집합을 출력에 매핑하는 방식으로 설명합니다. 쉽게 말하면 각 위치의 표현을 만들 때 다른 위치의 정보를 서로 다른 가중치로 결합하는 계산입니다. “중요한 단어에 집중한다”는 비유는 입문 설명에는 도움이 되지만, 모델이 사람처럼 중요성을 이해하거나 특정 어텐션 가중치 하나가 답변 이유를 그대로 보여 준다는 뜻은 아닙니다.
또한 2017년 논문의 encoder-decoder 구조가 모든 최신 LLM의 구현과 동일한 것은 아닙니다. 현재 모델은 decoder-only 구성, 로컬·희소 어텐션, grouped-query attention, 메모리 및 캐시 최적화 등 서로 다른 변형을 사용할 수 있습니다. 공급사가 세부 구조를 공개하지 않았다면 제품 문서와 모델 카드에 없는 내부 구조를 단정하지 않아야 합니다.
3. 다음 토큰 예측: 후보마다 조건부 점수를 만든다
자기회귀 텍스트 생성 모델을 설명할 때는 “지금까지 주어진 토큰을 조건으로 다음 토큰 후보들의 점수를 계산한다”가 핵심입니다. 점수는 정규화 과정을 거쳐 후보 분포로 해석할 수 있고, 디코더는 그 분포와 생성 설정을 이용해 다음 토큰을 선택합니다. 선택된 토큰을 뒤에 붙여 같은 절차를 반복하면 여러 토큰으로 된 출력이 만들어집니다.
여기서 확률이 높다는 것은 학습과 현재 컨텍스트 아래에서 이어질 가능성이 높다는 뜻이지, 그 문장이 사실이거나 사용자의 의도를 정확히 이해했다는 보증이 아닙니다. 모델은 그럴듯하지만 틀린 내용을 만들 수 있으므로 외부 사실은 출처로 검증해야 합니다.
생성은 종료 토큰, 길이 제한, 중지 문자열, 안전 정책, 도구 호출 같은 조건으로 끝날 수 있습니다. 실제 제품은 내부 추론 토큰이나 여러 후보 생성·재평가, 서버 측 후처리를 사용할 수도 있으므로 화면에 보이는 문장이 단순히 한 번의 공개 확률표에서 바로 나온 것이라고 단정할 수 없습니다.
4. 샘플링 설정: 출력 후보를 고르는 방식에 영향을 준다
가장 높은 점수의 후보를 매번 고르는 방식을 흔히 그리디 디코딩이라고 합니다. 샘플링은 후보 분포에서 확률적으로 토큰을 고릅니다. temperature는 일반적으로 후보 분포의 상대적 날카로움에 영향을 주고, top_p는 누적 확률 질량 안에 들어오는 후보 집합을 제한하는 nucleus sampling에 쓰입니다. 이 설정은 표현의 변동 가능성에 영향을 줄 수 있지만 정확성·창의성·재현성을 각각 보장하는 스위치는 아닙니다.
예를 들어 가상의 다음 토큰 후보 A·B·C의 확률이 각각 0.60·0.30·0.10이고 top_p=0.80이라고 가정해 보겠습니다. 확률이 큰 A 하나의 누적값은 0.60이라 기준에 못 미치지만 B까지 더하면 0.90이므로 A와 B가 후보 집합에 남습니다. C는 이 예에서 제외됩니다. 이는 실제 모델의 확률이나 출력 결과가 아니라 계산을 설명하기 위한 가상 분포입니다. Transformers 생성 설정 문서는 top-p에서 기준 이상의 누적 확률을 갖는 최소 후보 집합을 남기는 방식을 설명합니다.
OpenAI Responses API 문서는 지원되는 요청에서 temperature 또는 top_p 중 하나만 조정할 것을 권장합니다. Gemini 생성 설정 문서는 모델별 기본값과 top-k 지원 여부가 다를 수 있다고 명시하며, Gemini 프롬프트 전략은 일부 현행 모델에서 기본 설정 유지를 권장합니다. Anthropic의 모델 지원 중단 안내는 일부 현행 모델에서 temperature·top_p·top_k의 비기본값을 더 이상 받지 않는 사례를 보여 줍니다.
즉 “온도를 낮추면 모든 모델이 항상 같은 정답을 낸다”거나 “온도를 높이면 더 창의적이고 더 좋은 답이 나온다”고 일반화하면 안 됩니다. 먼저 사용 중인 정확한 모델 버전의 API 참조에서 지원 여부와 기본값을 확인해야 합니다. 소비자용 채팅 화면처럼 해당 설정을 노출하지 않는 제품도 있습니다.
| 설정·조건 | 일반적인 개념 | 단정하면 안 되는 것 | 확인 방법 |
|---|---|---|---|
| temperature | 후보 분포의 상대적 차이에 영향 | 낮으면 항상 동일·정확 | 해당 모델 API의 지원 범위 |
| top_p | 누적 확률 기준으로 후보 집합 제한 | 값 하나가 품질 등급을 결정 | 모델별 기본값과 권장 조합 |
| top_k | 상위 후보 개수를 제한하는 방식 | 모든 API에서 지원 | 요청 스키마와 모델 문서 |
| 최대 출력 길이 | 생성 가능한 출력의 상한 | 반드시 그 길이까지 생성 | 종료 이유와 사용량 메타데이터 |
| 같은 입력 | 비교 실험의 출발점 | 매번 같은 출력 보장 | 모델 버전·설정·도구까지 기록 |
5. 코드 없이 해보는 재현 실험
아래는 독자가 자신의 제품에서 직접 채우는 실험 절차입니다. 날짜, 모델 이름과 버전, 계정 화면에 보이는 설정을 함께 기록해야 비교 의미가 생깁니다.
실험 A: 토큰 수가 입력 표면형에 따라 달라지는지 확인
- 공급사가 제공하는 토큰 계산기, API 콘솔 또는
count_tokens기능을 엽니다. 안녕하세요,안녕 하세요,안녕하세요!를 각각 별도 입력합니다.- 모델과 토크나이저를 바꾸지 않은 채 입력 토큰 수를 기록합니다.
- 다른 모델로 바꿨다면 새 실험으로 구분하고 모델 이름을 적습니다.
| 입력 | 모델·토크나이저 | 확인된 입력 토큰 수 |
|---|---|---|
안녕하세요 |
— | — |
안녕 하세요 |
— | — |
안녕하세요! |
— | — |
— 표시는 아직 채워지지 않은 값입니다. 사용 중인 모델의 토크나이저로 각 입력을 직접 실행해 숫자를 적습니다. 결과가 같을 수도, 다를 수도 있습니다. 확인 전에는 특정 숫자를 예상값으로 쓰지 않습니다.
실험 B: 생성 설정과 출력 변동을 분리해 관찰
- 모델 버전을 고정하고 새 대화를 엽니다.
비 오는 날을 표현하는 한 문장을 작성해 주세요.라는 같은 입력을 여러 번 실행합니다.- 기본 설정에서 나온 문장과 종료 이유를 순서대로 기록합니다.
- API가 temperature 또는 top_p 변경을 지원할 때만 하나를 바꿔 다시 실행합니다. 둘을 동시에 바꾸지 않습니다.
- 문장 차이, 사실 오류 여부, 길이만 기록하고 “더 창의적” 같은 평가는 별도의 기준을 정한 뒤 붙입니다.
| 실행 조건 | 출력 | 달라진 표현 | 오류·중단 여부 |
|---|---|---|---|
| 기본 설정, 실행 1 | — | 기준 | — |
| 기본 설정, 실행 2 | — | 직접 비교 | — |
| 지원되는 설정 하나 변경 | — | 직접 비교 | — |
— 표시는 실행 후 직접 채우는 값입니다. 채팅 제품이 모델 버전이나 샘플링 설정을 공개하지 않는다면 이 실험은 통제된 샘플링 실험이 아닙니다. 그 경우에는 “같은 화면에서 관찰한 출력 변동”으로만 기록하고 내부 파라미터 효과라고 결론 내리지 않습니다.
6. 설명이 맞는지 확인하는 순서
- 제품 화면이 아니라 해당 모델 버전의 모델 카드와 API 요청 스키마를 먼저 확인합니다.
- 토큰 수는 추정 공식 대신 공식 계산 엔드포인트나 응답의 사용량 메타데이터로 확인합니다.
- 컨텍스트 윈도우와 최대 출력 토큰을 서로 다른 한도로 구분합니다.
- temperature·top_p·top_k는 지원되는 모델에서만 문서의 기본값과 범위를 확인합니다.
- 종료 이유, 도구 호출, 안전 필터가 결과에 개입했는지 응답 메타데이터를 봅니다.
- 공급사가 공개하지 않은 어텐션 구조나 내부 추론 절차는 추정으로 표시하거나 설명 범위에서 뺍니다.
로컬 모델에서는 VRAM과 KV 캐시가 실제 컨텍스트 운용에 영향을 줄 수 있습니다. 관련 기준은 GPU VRAM과 로컬 LLM 선택 기준에서 확인할 수 있습니다. 생성형 AI의 더 넓은 개념은 생성형 AI란 무엇인가에서 이어집니다.
핵심 정리
토큰화→컨텍스트 계산→다음 토큰 후보 분포→디코딩·샘플링→반복이라는 흐름은 자기회귀 텍스트 생성을 이해하는 유용한 개념 모델입니다. 다만 어텐션은 사람의 이해와 같지 않고, 확률이 높다는 사실은 진실을 뜻하지 않으며, 샘플링 설정의 지원과 효과도 모델마다 다릅니다. 정확한 동작을 확인하려면 공급사가 공개한 모델 버전·토크나이저·API 스키마·응답 메타데이터를 기준으로 작은 실험을 반복해야 합니다.