RUDA DIRECTOR · AI 깊이 이해하기 — 자율 시스템 설계까지 · CHAPTER 06
질문: 같은 Prompt와 Model을 써도 답변이 달라지는 이유는 무엇인가?
같은 질문을 반복해도 AI의 답은 달라질 수 있다. 문장을 이어갈 여러 후보 중 하나를 고르는 과정인 Sampling이 한 가지 이유다. Temperature는 후보에 확률이 얼마나 집중되는지를 조절한다. 실제 서비스에서는 대화 맥락, 모델 버전, 도구 결과도 답에 영향을 준다. 이 글에서는 합성 숫자와 Python 예제로 Sampling의 작동 원리를 확인하고, Temperature를 낮춰도 정확성이나 완전한 재현성이 보장되지 않는 이유를 살펴본다.
Logit·Probability·Sampling은 서로 다른 단계다
Logit은 Vocabulary의 각 Token 후보에 대해 Model이 내놓은 실수 점수다. 합이 1일 필요도 없고 음수일 수도 있다. Softmax를 적용하면 합이 1인 조건부 확률분포가 된다. 이 분포는 “현재 Context 다음에 어떤 Token이 이어질 가능성이 높은가”를 표현하지, 문장의 사실 여부를 검증한 확률은 아니다.
| 개념 | 하는 일 | 하지 않는 일 |
|---|---|---|
| Logit | Token 후보의 상대 점수를 제공 | 정규화된 확률·진실 점수 아님 |
| Temperature | 분포의 집중도를 조절 | 새 지식·근거를 추가하지 않음 |
| top-p / top-k | Sampling 후보 집합을 제한 | 남은 후보의 정확성을 보장하지 않음 |
| Decoding policy | Greedy 또는 Sampling으로 선택 | Model 학습 자체를 바꾸지 않음 |
Temperature가 T일 때 자주 쓰는 변환은 softmax(logit / T)다. T가 1보다 작으면 점수 차이가 확대되어 높은 후보에 확률이 몰리고, 1보다 크면 차이가 줄어 낮은 후보도 선택될 여지가 커진다. T=0은 이 식에 그대로 넣을 수 없다. 제품과 Library는 보통 Greedy decoding 같은 별도 동작으로 처리하므로, API 문서의 정의를 확인해야 한다.
현재 Context ↓ Model forward pass ↓ 다음 Token의 Logits ↓ Temperature 조정 → top-k / top-p 필터 ↓ 조건부 확률분포 ↓ Greedy 선택 또는 Sampling ↓ 선택 Token을 Context에 추가 → 다음 단계 반복
합성 Logit으로 Temperature의 효과를 계산해보자
세 후보 A·B·C의 Logit을 [2.0, 1.0, 0.0]으로 둔다. 가독성을 위해 A는 “근거”, B는 “요약”, C는 “추정”이라고 표시하지만, 실제 Tokenizer의 단어 분할이나 실제 Model 출력은 아니다. Python 표준 라이브러리로 계산한 분포는 다음과 같다.
| Temperature | A / B / C 확률 | 관찰 |
|---|---|---|
| 0.5 | 0.866813 / 0.117310 / 0.015876 | A에 강하게 집중 |
| 1.0 | 0.665241 / 0.244728 / 0.090031 | 원래 점수 차이 반영 |
| 2.0 | 0.506480 / 0.307196 / 0.186324 | B·C 선택 가능성 증가 |
순위는 A > B > C로 그대로지만 확률 간격은 크게 달라진다. Temperature가 높은 경우 C가 더 자주 선택될 수는 있어도 C의 내용이 더 정확하거나 창의적이라는 뜻은 아니다.
top-p는 확률 질량을 기준으로 후보를 잘라낸다
T=1.0의 분포에서 top_p=0.8을 적용해보자. 확률이 큰 순서대로 더하면 A만으로는 0.665241이라 0.8에 못 미친다. B까지 포함하면 누적 0.909969가 되므로 A와 B만 남고 C는 제외된다. 남은 두 후보를 다시 정규화하면 A는 0.731059, B는 0.268941이다. top-k가 후보 개수로 자르는 방식이라면, top-p는 매 단계의 분포 모양에 따라 남는 개수가 달라진다.
OpenAI의 현재 Responses API 문서는 Temperature와 top-p 중 하나만 조정하는 방식을 일반적으로 권한다. 두 값을 동시에 바꾸면 결과가 달라졌을 때 어느 조정이 원인인지 해석하기 어렵기 때문이다. Hugging Face Transformers도 Temperature, top-k, top-p를 Logit과 생성 전략을 조정하는 별도 파라미터로 구분한다.
실행 예제: 같은 분포에서 12번 뽑기
아래 코드는 Model을 호출하지 않는다. 위 합성 Logit에 Softmax를 적용하고, Python의 의사난수 생성기에 seed 42를 준 뒤 12번 Sampling한다.
import mathimport randomlabels = ["근거", "요약", "추정"]logits = [2.0, 1.0, 0.0]def probabilities(temperature): scaled = [x / temperature for x in logits] peak = max(scaled) mass = [math.exp(x - peak) for x in scaled] total = sum(mass) return [x / total for x in mass]probs = probabilities(1.0)rng = random.Random(42)draws = rng.choices(labels, weights=probs, k=12)print([round(x, 6) for x in probs])print(draws)print({label: draws.count(label) for label in labels})
이번 실행에서는 ["근거", "근거", "근거", "근거", "요약", "요약", "요약", "근거", "근거", "근거", "근거", "근거"]가 나왔고, 개수는 근거 9·요약 3·추정 0이었다. 12회는 분포를 평가하기에 작은 표본이며 실제 Model 품질 실험도 아니다. 확인한 것은 확률분포가 같아도 각 추출 결과는 달라질 수 있고, seed를 고정한 이 로컬 코드에서는 실행을 재현할 수 있다는 점뿐이다.
한 Token의 차이가 전체 답변으로 확대되는 이유
자기회귀 생성에서는 선택된 Token이 다음 단계의 입력 Context에 붙는다. 첫 단계에서 A와 B가 갈리면 다음 Logit도 달라지고, 이후에는 서로 다른 분포에서 다시 선택한다. 따라서 초반의 작은 차이가 문장 구조, 근거 배치, 결론까지 확대될 수 있다. “같은 질문인데 문장 몇 개만 다르다”가 아니라, 매 단계가 다음 단계의 조건을 다시 만드는 과정이다.
Greedy decoding은 매 단계 가장 높은 후보를 선택하므로 고정된 Logit과 같은 tie-breaking 조건에서는 같은 경로를 따른다. 그러나 실제 API의 완전한 재현성은 별개다. Anthropic의 현재 Messages API 문서는 Temperature 0도 완전한 결정성을 보장하지 않는다고 명시하며, 최신 모델에서는 Temperature·top-p·top-k 지원 자체가 달라졌다. OpenAI도 Model과 reasoning 설정에 따라 Temperature·top-p가 지원되지 않을 수 있다고 안내한다. Model snapshot, backend, Prompt, Tool 결과가 바뀌면 Decoding 설정만 같아도 출력이 달라질 수 있다.
문서 변경 보고 시스템에서 Sampling을 어디까지 허용할까
가상의 공개 문서 변경 보고 시스템을 보자. 제목 후보나 설명 문장의 어순을 여러 개 만드는 단계에는 Sampling을 허용할 수 있다. 그러나 “기한이 바뀌었는가”, “어떤 문단이 근거인가”, “파일을 저장해도 되는가” 같은 판정까지 Sampling에 맡기면 같은 입력이 다른 사실·권한 결과로 이어질 수 있다.
- 후보 생성: 여러 표현을 만들 수 있으나 원문 근거 ID를 함께 보존한다.
- 사실 검증: 원문 diff와 인용 위치를 deterministic code로 대조한다.
- 선택: 검증을 통과한 후보에서만 가독성 기준으로 선택한다.
- 부작용 실행: 저장·전송·권한 변경은 Schema, permission gate, Approval로 제한한다.
표현의 다양성과 사실 판정의 변동성을 같은 것으로 취급하지 않는 것이 핵심이다. 자율성이 필요한 곳은 모든 결정을 무작위화하는 지점이 아니라, 허용된 후보를 만들고 검증된 상태에서 다음 행동을 고르는 지점이다.
Sampling 설계가 실패하는 다섯 가지 방식
- Temperature를 정확도 다이얼로 본다. 분포의 집중도를 바꾸지만 외부 근거나 진실 판정을 추가하지 않는다.
- Temperature 0을 완전 재현으로 기록한다. Greedy에 가까운 동작과 API 전체의 결정성은 다르다. Model·backend·Tool State까지 고정됐는지 별도로 확인해야 한다.
- top-p와 Temperature를 동시에 크게 조정한다. 후보 집합과 상대 확률이 함께 바뀌어 원인 분석과 회귀 비교가 어려워진다.
- 한 번 잘 나온 답을 설정의 품질로 일반화한다. 반복 횟수, 비교 기준, 실패 분모가 없으면 우연한 Sample을 성능처럼 읽게 된다.
- Tool·권한 결정을 자연어 Sampling에 맡긴다. 변동성이 부작용 실행으로 전파된다. 허용 Tool, Arguments, 권한, 완료 증거는 Runtime에서 검증해야 한다.
품질·비용·운영 Trade-off
- Quality: 여러 후보를 탐색할 수 있지만 낮은 확률 후보의 오류도 함께 늘 수 있다.
- Reliability: 낮은 Temperature나 Greedy는 변동성을 줄여도 사실성을 보장하지 않는다.
- Cost·Latency: 후보를 여러 개 생성하고 검증하면 Token, 호출 수, 응답 시간이 늘어난다.
- Context: 앞에서 뽑힌 Token이 이후 전체 분포를 바꾸므로 긴 출력일수록 경로 차이가 누적된다.
- Observability: Model snapshot, Prompt revision, decoding 설정, seed, Token log probability를 가능한 범위에서 함께 기록해야 비교가 가능하다.
- Security: Sampling 설정으로 permission과 Approval을 대체하지 않는다.
Sampling을 쓰지 않는 편이 나은 경우
- Schema validation, 수치 계산, 권한 판정처럼 code가 정답을 결정할 수 있을 때
- 결과 하나의 차이가 결제·전송·삭제 같은 비가역 행동으로 이어질 때
- 변동성 자체를 평가할 반복 테스트와 기록 체계가 없을 때
- Provider나 Model이 해당 Decoding parameter를 지원하지 않을 때
- 다양한 표현보다 동일한 입력의 일관된 재현이 우선일 때
설계 체크리스트
- 지금 필요한 것은 후보 다양성인가, 사실 정확성인가, 실행 일관성인가?
- Logit을 확률로 바꾸는 설정과 실제 Token 선택 정책을 구분했는가?
- Temperature와 top-p 중 무엇을 바꿨고, 다른 조건은 고정했는가?
- Model·API가 그 파라미터를 현재 지원하는지 확인했는가?
- seed가 있더라도 backend와 Model revision 차이를 기록했는가?
- 반복 Sample의 분모와 실패 기준이 있는가?
- Tool·권한·완료 판정은 deterministic validation으로 분리했는가?
Design Rule: Sampling은 후보를 넓히는 장치다. 사실·권한·완료를 증명하는 장치가 아니다. 변동성을 허용할 지점과 결정적으로 검증할 지점을 먼저 나눈다.
Learning Takeaway
같은 Prompt에서 다른 답이 나오는 핵심 경로는 Logit → 확률분포 → 선택 → 새 Context다. Temperature와 top-p는 분포와 후보 집합을 바꾸고, Sampling은 그 안에서 실제 Token을 뽑는다. 자율 시스템에서는 표현 후보의 다양성은 활용할 수 있지만, 사실·권한·Tool 실행의 변동성은 별도 검증 계층으로 막아야 한다.
이전 · 다음 · 관련 글
- Previous: Pretraining과 Post-training의 차이: 지식·행동·선호는 어디서 바뀌는가
- Next: Reasoning에 계산을 더 쓰면 언제 도움이 되는가
- Series Start: LLM의 학습과 추론: 프롬프트를 고치면 모델도 배우는가
- Related: 토큰과 임베딩: 문장은 어떻게 언어 모델의 입력이 되는가
공식 참고 자료
- OpenAI API — Create a model response: Temperature, top-p, top log probability의 현재 정의.
- OpenAI API — Using the latest models: Model과 reasoning 설정에 따른 Decoding parameter 지원 범위.
- Anthropic — Create a Message: Temperature 0의 비결정성 주의와 최신 Model의 parameter 지원 변화.
- Hugging Face Transformers — Generation: Temperature, top-k, top-p의 생성 설정 정의.
- Holtzman et al. — The Curious Case of Neural Text Degeneration: Nucleus sampling의 문제 설정과 근거.
자료 확인일: 2026-10-01. 표와 Sampling 출력은 Python 표준 라이브러리에 합성 Logit을 넣어 실행한 결과다. 실제 LLM, 유료 API, 제품 성능을 시험한 결과가 아니다. Decoding parameter 지원 여부는 Provider·Model·API 버전에 따라 달라질 수 있다.
이어서 읽기: 답변에 계산 시간을 더 쓰는 효과는 Reasoning Effort와 검증의 차이에서 살펴본다.