프롬프트 — 같은 질문인데 답이 달라지는 이유 (LLM 비결정성과 프롬프트 민감도 실전 대응법)

어제 완벽했던 프롬프트가 오늘은 엉뚱한 답을 내놓습니다. 원인은 대개 둘 중 하나인데, 둘의 처방이 정반대입니다. 하나는 내가 손댈 수 없는 서버 쪽 무작위성이고, 다른 하나는 내가 만든 프롬프트의 문제입니다.

---

배경 / 왜 지금 이 주제인가

생성형 AI를 며칠만 써보면 반드시 겪는 일이 있습니다. 같은 질문을 두 번 던졌는데 답이 다릅니다. 어제 잘 돌아가던 프롬프트를 오늘 그대로 붙여넣었는데 결과물의 톤이 바뀌어 있습니다. 팀원과 똑같은 문장을 넣었는데 서로 다른 답을 받습니다.

많은 사용자가 이를 "AI가 원래 그렇지"라며 넘기지만, 업무에 AI를 붙이기 시작하면 이야기가 달라집니다. 답이 매번 흔들리면 검수 기준을 세울 수 없고, 자동화 파이프라인을 신뢰할 수 없으며, 문제가 생겼을 때 재현이 안 됩니다. 앞선 할루시네이션 편이 "AI가 틀리는 문제"였다면, 이번 편은 "AI가 일정하지 않은 문제"입니다.

2025년 이후 이 현상의 원인이 상당 부분 규명됐습니다.

결론부터 말하면 흔들림에는 두 개의 서로 다른 원인이 있고, 사용자가 통제할 수 있는 쪽은 그중 하나입니다. 이 글은 그 구분법과 대응법을 다룹니다.

---

핵심 데이터 & 현황

• temperature 0에서도 결과가 갈린다: 동일 프롬프트를 1,000회 실행한 결과 80종의 서로 다른 출력이 나왔고, 첫 102개 토큰까지는 완전히 동일하다가 103번째 토큰에서 갈라짐 (Thinking Machines Lab, 2025)
• API 모델이 더 흔들린다: temperature 0.0 조건에서 gpt-4o-mini는 실행의 약 24%가 서로 다른 출력을, 로컬 구동한 llama3.1-8b는 약 9%를 기록 (arXiv 2601.19934, 2026)
• 형식만 바꿔도 성능이 뒤집힌다: 내용은 그대로 두고 프롬프트의 서식(구분 기호, 줄바꿈 등)만 바꿨을 때 최대 76점의 정확도 차이 발생 (Sclar 외, ICLR 2024)
• 모델 순위조차 뒤집힌다: 같은 과제에서 서식만 달리 하자 모델별 성능이 약 10점씩 요동쳤고, Qwen1.5-7B는 서식에 따라 정확도가 22.9% ~ 51.2% 사이에서 움직임 (Hugging Face, 2024)

? 해석: 세 번째와 네 번째 수치가 특히 중요합니다. 내용이 아니라 서식만 바꿨는데 성적이 76점까지 벌어졌다는 것은, 우리가 "프롬프트를 잘 썼다"고 믿는 근거의 상당 부분이 사실은 운 좋은 서식이었을 수 있다는 뜻입니다. 반대로 말하면, 답이 나쁠 때 내용을 뜯어고치기 전에 형식부터 손보는 것이 더 빠른 해법일 수 있습니다.

---

심층 분석

1) 먼저 구분해야 할 두 가지 '다름'

이 글에서 가장 중요한 구분입니다.

구분	무작위성(Nondeterminism)	구분 민감도(Sensitivity)
조건	같은 프롬프트, 다시 실행	조금 다른 프롬프트
원인	샘플링 + 서버 인프라	프롬프트 설계·형식
통제 가능성	사용자가 거의 통제 불가	사용자가 대부분 통제 가능
대응	형식 고정, 반복 실행, 통계적 판단	프롬프트 수정·표준화

대부분의 사용자가 겪는 좌절은 이 둘을 섞어서 보기 때문에 발생합니다. 서버 쪽 흔들림을 프롬프트 탓으로 돌리면 고쳐지지 않는 것을 붙잡고 시간을 쓰게 되고, 반대로 프롬프트 문제를 "AI가 원래 그래"로 넘기면 고칠 수 있는 것을 방치하게 됩니다.

2) 무작위성 ① — 애초에 '뽑기'로 만들어진 구조

언어모델은 다음에 올 단어를 하나로 확정하지 않습니다. 가능한 후보 전체에 확률을 매긴 뒤, 그중 하나를 뽑습니다. 이 뽑기의 성격을 조절하는 값이 temperature(온도)와 top-p입니다.

• temperature가 높을수록 낮은 확률의 후보까지 뽑힐 여지가 커집니다 → 다양하지만 불안정
• temperature가 0에 가까울수록 가장 확률 높은 후보만 선택됩니다 → 일관되지만 단조로움

챗봇 서비스 대부분은 답변이 딱딱해지지 않도록 0이 아닌 값을 기본으로 씁니다. 즉 일반 사용자가 쓰는 환경은 애초에 매번 다른 답이 나오도록 설정돼 있습니다.

3) 무작위성 ② — temperature를 0으로 해도 흔들리는 진짜 이유

여기가 최근에야 밝혀진 대목입니다. 온도를 0으로 두면 항상 1등 후보만 고르니 결과가 고정돼야 할 것 같지만, 실제로는 그렇지 않습니다.

Thinking Machines Lab이 2025년 9월 공개한 분석에 따르면, 주된 원인은 GPU의 무작위성이나 부동소수점 자체가 아니라 '배치 불변성(batch invariance)의 붕괴' 입니다. 서버는 여러 사용자의 요청을 묶어서 한 번에 처리하는데, 이 묶음(배치)의 크기는 그 순간의 서버 부하에 따라 달라집니다. 그런데 연산 커널은 배치 크기에 따라 덧셈의 순서가 바뀌고, 부동소수점 연산은 순서가 바뀌면 결과가 미세하게 달라집니다.

평소에는 이 미세한 차이가 무시됩니다. 문제는 1등 후보와 2등 후보의 확률이 거의 붙어 있을 때입니다. 소수점 아래의 오차가 순위를 뒤집는 순간, 그 뒤의 문장 전체가 다른 길로 갑니다. 실제 실험에서 "리처드 파인만에 대해 알려줘"라는 프롬프트를 1,000번 실행하자 992번은 "퀸스, 뉴욕"이, 8번은 "뉴욕시"가 선택됐고, 그 지점부터 답변이 갈라졌습니다.

필자 의견: 이 대목이 실무적으로 가장 중요합니다. 즉, 내 답변이 흔들린 이유가 그 순간 서버에 몰린 다른 사람들의 트래픽일 수 있다는 뜻입니다. 아무리 프롬프트를 다듬어도 이 부분은 사용자 쪽에서 제거할 수 없습니다. 연구팀은 커널을 배치 불변으로 재작성해 완전한 재현성을 얻었지만, 약 2배의 성능 손해를 감수해야 했습니다. 속도와 재현성이 맞바꿈 관계에 있는 셈입니다.

 

4) 민감도 — 쉼표 하나에 성적이 바뀐다

무작위성이 통제 불가 영역이라면, 민감도는 정확히 그 반대입니다.

ICLR 2024에 발표된 연구는 프롬프트의 의미는 그대로 두고 서식만 바꿔가며 성능을 측정했습니다. 구분 기호를 콜론에서 대시로 바꾸거나, 줄바꿈 위치를 옮기거나, 공백을 넣는 수준의 변화였습니다. 그 결과 LLaMA-2-13B 기준 최대 76점의 정확도 차이가 나타났고, 연구진은 "모델 간 성능 비교조차 고정된 하나의 서식으로는 타당하지 않다"고 결론지었습니다(Sclar 외, 2024).

의미가 같은 문장으로 바꿔 물었을 때의 민감도를 측정한 후속 연구(ProSA, EMNLP Findings 2024)는 한 걸음 더 나아갑니다. 민감도는 과제에 따라 크게 달랐는데, 수학·추론 과제에서 가장 크고 단순 상식 질문에서는 작았습니다.

또한 예시를 하나만 넣어줘도(zero-shot → one-shot) 민감도가 급격히 낮아졌습니다.

 

5) 눈에 안 보이는 변수들

위 두 가지 외에, 사용자가 "같은 조건"이라고 믿지만 실제로는 달라진 것들이 있습니다.

• 대화 컨텍스트 누적: 같은 창에서 오래 대화했다면, 앞의 내용이 전부 입력에 포함됩니다. 같은 질문이 아닙니다.
• 시스템 프롬프트·모델 업데이트: 서비스 제공사가 내부 지침이나 모델 버전을 조용히 바꾸는 경우가 있습니다. 어제와 오늘의 모델이 같다는 보장은 없습니다.
• 검색·도구 사용 여부: 웹 검색이 붙었는지에 따라 근거 자료가 달라지고, 검색 결과 자체가 시시각각 변합니다.
• 사용자 개인화 설정·메모리: 개인화 기능이 켜져 있으면 사람마다 입력이 달라집니다. 팀원과 답이 다른 이유가 대개 이것입니다.

---

실전 대응법 — 흔들림을 다루는 7가지

① 원인부터 3분 만에 진단한다

무작정 프롬프트를 고치기 전에 아래 순서로 확인합니다.

1. 새 대화창을 열고 같은 프롬프트를 3회 실행한다.
2. 3번 모두 방향이 비슷하다 → 민감도 문제. 프롬프트를 고치면 해결된다.
3. 3번의 방향이 제각각이다 → 무작위성 문제. 프롬프트를 아무리 고쳐도 완전히는 안 잡힌다. 형식 고정과 반복 실행으로 관리한다.

② 항상 새 대화에서 검증한다

프롬프트를 테스트할 때는 반드시 빈 대화창을 씁니다. 기존 대화창에서의 성공은 그 대화의 맥락 덕분일 수 있어, 다른 사람이나 내일의 내가 재현할 수 없습니다.

③ 출력 형식을 못 박는다

가장 비용 대비 효과가 큰 조치입니다. 출력 구조를 강제하면 결과의 편차가 눈에 띄게 줄어듭니다. Hugging Face 실험에서도 구조화 출력을 적용했을 때 프롬프트 변형에 따른 표준편차가 감소했습니다(2024).

"결과를 반드시 아래 형식으로만 출력하세요.

1. 결론(한 문장)
2. 근거(3개, 각 1문장)
3. 불확실한 부분 다른 설명이나 서론은 붙이지 마세요."

 

④ 예시를 최소 하나 넣는다

민감도 연구에서 가장 극적인 개선 구간은 예시가 0개에서 1개로 늘어날 때였습니다. 원하는 결과물의 샘플을 하나만 붙여도 흔들림이 크게 줄어듭니다. 긴 지시문 열 줄보다 잘 고른 예시 하나가 효과적인 경우가 많습니다.

 

⑤ 프롬프트를 '자산'으로 관리한다

잘 작동한 프롬프트는 메모장에 통째로 저장하고, 사용한 모델명과 날짜를 함께 적어둡니다. 모델이 업데이트되면 같은 프롬프트의 성능이 달라질 수 있는데, 기록이 없으면 무엇이 바뀌었는지 영원히 알 수 없습니다. API를 쓴다면 temperature와 seed 값도 함께 고정해 기록합니다.

 

⑥ 흔들림을 '진단 도구'로 쓴다

중요한 질문일수록 일부러 3회 이상 반복 실행해 봅니다. 매번 같은 답이 나오는 부분은 모델이 확신하는 영역이고, 매번 달라지는 부분은 모델이 사실상 추측하고 있는 영역입니다. 즉 흔들리는 지점이 곧 검증해야 할 지점입니다. 앞선 할루시네이션 편의 교차 검증과 같은 원리입니다.

 

⑦ 모든 작업에 재현성이 필요한 건 아니다

아이디어 발상, 카피 후보 뽑기, 초안 여러 버전 만들기 같은 작업에서는 흔들림이 오히려 자산입니다. 재현성을 요구할 작업(계산, 분류, 추출, 요약)과 다양성을 요구할 작업(창작, 발상)을 나눠 접근하는 것이 현실적입니다.

---

시사점

기업의 생성형 AI 도입 시 최대 우려가 "잘못된 정보 생성 및 결과 신뢰도 부족"(61.3%)으로 조사된 바 있는데(메가존클라우드·파운드리, 2025), 실무에서 이 '신뢰도' 항목에는 정확성뿐 아니라 일관성 문제가 상당 부분 섞여 있는 것으로 보입니다. 사내 도입이 좌초하는 전형적인 장면은 "틀린 답이 나와서"가 아니라 "매번 답이 달라서 결재 라인을 통과하지 못해서"인 경우가 많습니다.

2026년 시행된 인공지능 기본법 아래에서 AI 활용 사실의 고지와 관리 체계 정비가 과제로 부상하고 있다는 점도 함께 볼 필요가 있습니다. 결과의 재현 가능성과 프롬프트 이력 관리는 향후 내부 통제·감사 대응의 기초 자료가 될 가능성이 있습니다.

필자 의견: 조직 단위에서 지금 가장 실효성 있는 조치는 고성능 모델 도입이 아니라 '프롬프트 저장소' 를 만드는 것입니다. 잘 작동한 프롬프트를 개인 메모장이 아니라 팀 공유 문서에 모델명·날짜와 함께 쌓아두는 것만으로, 같은 업무의 결과 편차가 줄고 실패 원인 추적이 가능해집니다. 비용은 사실상 0입니다.

---

전망 & 주목할 변수

• 개선 변수 — 재현 가능한 추론: 배치 불변 커널처럼 결정성을 보장하는 기술이 상용 서비스에 옵션으로 제공될 가능성이 있습니다. 다만 약 2배 수준의 성능 손실이 보고된 만큼, 전면 적용보다는 감사·규제 대응이 필요한 영역에 선택적으로 적용되는 형태가 유력해 보입니다.
• 리스크 변수 — 에이전트의 오차 누적: AI가 여러 단계를 스스로 실행하는 구조에서는 각 단계의 작은 편차가 다음 단계 입력으로 넘어가며 증폭될 수 있습니다. 단발 대화에서는 무시할 만한 흔들림이 10단계 작업에서는 전혀 다른 결과로 이어질 수 있습니다.
• 체크포인트: ① 주요 API의 seed·결정성 옵션 제공 범위 ② 구조화 출력(JSON 스키마 강제) 기능의 기본값 채택 여부 ③ 한국어 프롬프트 민감도에 대한 국내 벤치마크 공개 여부

---

결론

1. '다름'에는 두 종류가 있고, 진단이 먼저다. 새 대화창에서 3회 실행해 보면 서버 쪽 무작위성인지 내 프롬프트 문제인지 대부분 갈립니다.
2. temperature 0도 재현성을 보장하지 않는다. 서버 부하에 따른 배치 크기 변화가 결과를 바꾸며, 이는 사용자가 통제할 수 없는 영역입니다.
3. 통제 가능한 쪽에 집중한다. 새 대화에서 테스트, 출력 형식 고정, 예시 1개 이상, 프롬프트 기록 — 이 네 가지가 개인이 얻을 수 있는 일관성의 대부분입니다. 그리고 남는 흔들림은 없애려 하기보다 검증이 필요한 지점을 알려주는 신호로 쓰는 편이 낫습니다.

참고자료

• Defeating Nondeterminism in LLM Inference — Thinking Machines Lab (2025)
• Quantifying non-deterministic drift in large language models — arXiv 2601.19934 (2026, 프리프린트)
• Quantifying Language Models' Sensitivity to Spurious Features in Prompt Design — Sclar 외, ICLR 2024
• ProSA: Assessing and Understanding the Prompt Sensitivity of LLMs — EMNLP Findings 2024
• Improving Prompt Consistency with Structured Generations — Hugging Face (2024)
• AI 기본법 시행과 그 시사점 — 법률신문