콘텐츠로 이동

P1-12.3 프롬프트(prompt)의 한계(limit)와 평가(evaluation)

Section ID: P1-12.3 Version: v2026.07.20

12.1에서는 프롬프트(prompt)가 무엇을 지정하는지 봤습니다. 12.2에서는 지시(instruction), 맥락(context), 예시(example)를 나눠 봤습니다.

이제 중요한 질문이 남습니다.

프롬프트를 잘 쓰면 충분한가?

여기서의 답은 분명합니다.

프롬프트는 모델의 출력을 유도할 수 있지만, 사실성(factuality), 근거성(evidence), 안전성(safety), 일관성(consistency)을 자동으로 보장하지 않는다.

Part 1에서 프롬프트의 한계(limit), 평가(evaluation), 사실성(factuality), 근거성(evidence), 최신성(recency), 환각(hallucination), 재현성(reproducibility)의 입문 구분은 이 절에서 잡습니다. 12.1에서는 프롬프트가 무엇을 지정하는지, 12.2에서는 지시·맥락·예시를 나눴고, 여기서는 좋은 입력을 넣는 일과 좋은 결과를 검토하는 일이 다른 작업임을 분리합니다.

따라서 프롬프트를 다룰 때는 “어떻게 잘 요청할 것인가”와 함께 “무엇을 검토해야 하는가”를 같이 배워야 합니다.

여기서는 프롬프트의 한계와 검토 기준을 다룹니다. RAG(retrieval-augmented generation), 벡터 검색(vector search), 도구 사용(tool use), 에이전트(agent), 하네스(harness)는 자세히 다루지 않습니다. 그런 구조는 바로 다음 장의 P1-13.3과 P1-13.4, 그리고 P1-14.2부터 P1-14.5에서 다시 다룹니다.

한계, 평가, 사실성, 근거성, 환각, 재현성은 초반에 모두 비슷한 검토 항목처럼 들릴 수 있습니다. 우선 각 용어의 역할을 짧게 구분하면 다음과 같습니다.

용어 아주 짧은 뜻 이 절에서의 역할
프롬프트의 한계 입력을 잘 써도 자동으로 해결되지 않는 문제 프롬프트 과신을 막는 기준
평가 출력이 목적에 맞는지 확인하는 절차 감이 아니라 기준으로 보는 단계
사실성 문장이 실제 사실과 맞는가 핵심 정확성 기준
근거성 주장을 뒷받침하는 출처가 있는가 검증 가능성 기준
최신성 지금도 유효한 정보인가 변하는 정보에 필요한 기준
환각 그럴듯하지만 틀린 생성 생성형 AI의 대표 오류
재현성 무엇을 바꿨고 결과가 어땠는지 다시 확인할 수 있는가 프롬프트 실험 기록의 기준

여기서 유지해야 할 최소 구분은 프롬프트는 보장 아님, 평가는 별도 작업, 사실성/근거성/최신성은 다름, 재현성 기록이 필요입니다.

여기서는 다음 질문에 집중합니다.

질문 이 절에서 볼 내용
프롬프트가 보장하지 못하는 것은 무엇인가? 사실성, 근거성, 최신성, 안전성, 일관성
왜 평가가 필요한가? 출력이 그럴듯해도 틀릴 수 있기 때문
어떤 기준으로 검토할 것인가? 목적, 근거, 재현성, 위험, 수정 가능성

또한 여기서는 프롬프트 작성법을 더 늘어놓지 않습니다. 평가와 한계를 분리하고, 왜 다음 장의 RAG, 도구 사용, 에이전트, 하네스 같은 구조가 필요해지는지를 설명하는 데 집중합니다.

좋은 입력과 좋은 결과 검토를 나누는 기준

  • 프롬프트가 결과를 유도하지만 보장하지는 않는다는 점을 설명합니다.
  • 사실성(factuality), 근거성(evidence), 안전성(safety), 일관성(consistency)을 구분합니다.
  • 출력 검토를 “마음에 드는가”가 아니라 “목적에 맞는가”로 바꿔 봅니다.
  • 학습용 책을 작성할 때 필요한 최소 평가 기준을 정리합니다.
  • RAG, 도구 사용(tool use), 에이전트(agent), 하네스(harness)가 왜 다음 단계의 주제가 되는지 예고합니다.

세 가지 기준

여기서는 프롬프트를 포기하자는 쪽이 아니라, 프롬프트만으로 해결되지 않는 한계를 구분하는 데 집중합니다. 아래 세 가지 기준이 잡히면 흐름이 정리됩니다.

기준 왜 중요한가 이 절에서 필요한 이해 수준
프롬프트를 바꿔도 모델 한계가 사라지지는 않는다는 점 입력 설계와 모델 능력을 구분하게 해 줍니다. 더 잘 묻는다고 모든 오류가 없어지지는 않는다고 이해하면 됩니다.
프롬프트 결과는 평가 기준으로 비교해야 한다는 점 감으로 “좋아 보인다”에 머무르지 않게 해 줍니다. 정확성, 일관성, 근거 같은 기준을 함께 봐야 한다고 알면 됩니다.
기록 없는 프롬프트 수정은 재현하기 어렵다는 점 이후 하네스, 평가, 실험 기록 흐름과 연결됩니다. 무엇을 바꿨고 결과가 어땠는지 남겨야 한다고 이해하면 됩니다.

프롬프트는 보장이 아니라 조건이다

프롬프트를 명확히 쓰면 출력이 좋아질 가능성이 커집니다. 하지만 프롬프트는 보증서가 아닙니다.

좋은 프롬프트: 근거가 확인된 내용만 사실처럼 작성해줘. 근거가 약하면 "검증 필요"라고 표시해줘.

가능한 문제: 모델이 실제로 근거를 확인하지 못했는데도 근거가 있는 것처럼 문장을 만들 수 있다.

이 문제는 프롬프트가 나쁘기 때문만은 아닙니다. LLM은 입력 문맥을 바탕으로 그럴듯한 출력을 생성합니다. 그 출력이 실제 세계의 사실과 항상 일치하는지는 별도 검토가 필요합니다.

그래서 여기서는 다음 원칙을 둡니다.

프롬프트는 요청 조건이다. 근거 검토는 사람과 도구가 수행해야 할 별도 작업이다. 출력은 초안이며, 사실 주장은 검증 대상이다.

사실성, 근거성, 최신성은 다르다

프롬프트를 평가할 때 가장 먼저 나눌 것은 사실성(factuality), 근거성(evidence), 최신성(recency)입니다.

기준 질문 예
사실성(factuality) 문장이 실제 사실과 맞는가? 논문 연도, 개념 정의, 사건 설명
근거성(evidence) 그 문장을 뒷받침하는 출처가 있는가? 논문, 공식 문서, 표준 문서, 신뢰 가능한 기사
최신성(recency) 지금도 유효한 정보인가? 제품 기능, 가격, 정책, 법률, 모델 사양

세 기준은 연결되어 있지만 같은 말이 아닙니다.

사실일 수 있지만 출처가 없을 수 있다. 출처가 있지만 오래되어 현재 상황과 다를 수 있다. 최신 자료지만 신뢰도가 낮을 수 있다.

예를 들어 “GPT 계열 모델은 Transformer 기반이다” 같은 설명은 역사와 구조를 다루는 문장입니다. 반면 “어떤 API 모델이 현재 가장 저렴하다” 같은 문장은 가격과 제품 정책에 따라 바뀔 수 있습니다. 두 문장은 검토 방식이 달라야 합니다.

여기서는 안정적인 개념은 교재, 논문, 공식 문서를 우선하고, 바뀔 수 있는 정보는 작성 시점의 공식 문서나 날짜가 있는 자료를 다시 확인합니다.

환각은 그럴듯한 오류다

생성형 AI 문맥에서 환각(hallucination)은 모델이 그럴듯하지만 잘못된 내용을 생성하는 현상을 가리킵니다. NIST의 Generative AI Profile은 confabulation을 자신 있게 제시되지만 잘못되었거나 거짓인 콘텐츠 생성으로 설명하고, hallucination이나 fabrication이라고도 부른다고 정리합니다.

이 절에서 중요한 점은 환각을 “모델이 이상하게 행동하는 예외”로만 보지 않는 것입니다. LLM은 문맥에 맞는 문장을 생성할 수 있지만, 그 문장이 실제 근거를 가진 사실인지까지 자동으로 보장하지 않습니다.

위험한 프롬프트: 이 주장을 설득력 있게 써줘.

더 나은 프롬프트: 이 주장을 검토해줘. 근거가 확인된 내용과 검증이 필요한 내용을 분리해줘. 출처가 없으면 사실처럼 단정하지 마.

두 번째 프롬프트가 더 안전하지만, 그래도 충분하지 않습니다. 실제 출처를 열어 보고, 문장이 출처의 주장과 맞는지 확인해야 합니다.

일관성은 한 번의 답으로 판단하기 어렵다

LLM의 출력은 입력, 모델, 설정, 대화 이력에 따라 달라질 수 있습니다. 같은 요청을 다시 했을 때 표현이 바뀌거나, 일부 판단이 달라질 수 있습니다.

따라서 평가(evaluation)는 한 번 마음에 드는 답을 얻는 일이 아닙니다.

한 번의 출력: 읽기 좋아 보인다.

평가: 여러 입력에서도 같은 기준을 유지하는가? 틀린 주장과 모르는 내용을 구분하는가? Section 경계를 지키는가? 출처가 실제 주장과 연결되는가?

학습용 문서를 작성할 때는 특히 Section 경계가 중요합니다. 예를 들어 12.3에서 RAG의 세부 구조를 길게 설명하면, P1-13의 도메인을 침범합니다. 출력이 좋아 보여도 현재 Section의 중심 질문을 벗어나면 수정해야 합니다.

평가는 목적에 맞춰야 한다

평가 기준은 작업 목적에 따라 달라집니다. 하나의 점수로 모든 출력을 판단하기 어렵습니다.

작업 중요한 평가 기준
개념 설명 정확성, 쉬운 표현, 용어 병기, 과장 금지
근거 검토 출처 신뢰도, 문장과 출처의 연결, 확인 날짜
목차 설계 Section 경계, 학습 순서, 중복 여부
예시 작성 처음 읽는 독자 이해도, 오해 가능성, 재사용 가능성
전망 작성 날짜 있는 근거, 관점 비교, 추측과 사실 구분

Ouyang 등의 InstructGPT 논문은 모델 출력을 평가할 때 단순 자동 점수만이 아니라 human evaluation을 사용하고, 도움됨(helpfulness), 진실성(truthfulness), 해로움 없음(harmlessness) 같은 기준을 다룹니다. 이 책에서 그대로 같은 평가 절차를 구현할 필요는 없지만, LLM 출력 평가는 하나의 기준으로 끝나지 않는다는 점은 참고할 수 있습니다.

여기서는 다음 정도의 검토표가 실용적입니다.

검토 항목 질문
목적 적합성 이 출력이 현재 Section의 질문에 답하는가?
사실성 핵심 사실 주장에 오류가 없는가?
근거성 중요한 주장에 출처가 있는가?
용어 핵심 용어가 한영 병기되고 혼동 없이 쓰였는가?
경계 다음 Section이나 다른 Chapter의 내용을 미리 침범하지 않는가?
위험 법률, 저작권, 보안, 안전 쟁점을 단정하지 않았는가?

프롬프트로 줄일 수 있는 위험과 줄일 수 없는 위험

프롬프트는 일부 위험을 줄이는 데 도움이 됩니다.

줄일 수 있는 위험: - 출력 형식이 흐트러지는 문제 - 독자 수준이 맞지 않는 문제 - Section 경계를 넘는 문제 - 출처 없는 내용을 구분하지 않는 문제

하지만 프롬프트만으로 해결하기 어려운 문제도 있습니다.

프롬프트만으로 해결하기 어려운 위험: - 출처 원문을 실제로 확인하지 않은 사실 주장 - 최신 정책이나 가격 정보의 변경 - 법률 판단이 필요한 저작권 문제 - 긴 문서 전체의 일관성 유지 - 도구 실행 결과와 본문 설명의 불일치

이런 문제는 다음 단계의 구조가 필요합니다.

필요 다음에 이어질 주제
외부 자료를 찾아 넣기 RAG, 벡터 검색(vector search)
계산이나 파일 확인 도구 사용(tool use)
여러 단계 작업 관리 에이전트(agent)
반복 평가와 로그 관리 하네스(harness)

이 표는 예고입니다. 12.3의 핵심은 프롬프트를 넘어서는 구조를 자세히 설명하는 것이 아니라, 왜 그런 구조가 필요해지는지 이해하는 것입니다.

프롬프트 결과를 검토할 때의 최소 절차

학습 문서나 공개 글처럼 프롬프트 결과를 다시 써야 하는 상황에서는 최소한 다음 절차를 거치는 편이 안전합니다.

  1. Section의 중심 질문을 확인한다.
  2. 초안이 그 질문에 답하는지 본다.
  3. 사실 주장과 개인적 해석을 나눈다.
  4. 사실 주장에는 출처가 있는지 확인한다.
  5. 출처가 실제 문장을 뒷받침하는지 확인한다.
  6. 다음 Section의 내용을 미리 길게 설명하지 않았는지 본다.
  7. 검증 필요 항목을 별도 검토 기록에 남긴다.

이 절차는 완전한 품질 보증이 아닙니다. 하지만 입문용 책에서 가장 위험한 문제, 즉 근거 없는 설명이 자연스러운 문장으로 굳어지는 일을 줄이는 데 도움이 됩니다.

체크리스트

  • 프롬프트가 출력 조건을 지정하지만 사실성을 보장하지 않는다고 설명할 수 있다.
  • 사실성(factuality), 근거성(evidence), 최신성(recency)을 구분할 수 있다.
  • 환각(hallucination)을 그럴듯한 오류로 설명할 수 있다.
  • 평가(evaluation)가 한 번의 마음에 드는 답을 고르는 일이 아님을 설명할 수 있다.
  • 작업 목적에 따라 평가 기준이 달라진다고 설명할 수 있다.
  • 프롬프트만으로 줄일 수 있는 위험과 줄이기 어려운 위험을 구분할 수 있다.
  • RAG, 도구 사용(tool use), 에이전트(agent), 하네스(harness)가 왜 다음 단계의 주제가 되는지 설명할 수 있다.
  • 입력 조건, 출력 평가, 근거 확인, 재현성 기록을 나누어 프롬프트 개선과 별도 검토 작업을 설명할 수 있다.
  • 결과가 그럴듯해 보여도 사실성, 근거성, 최신성을 따로 확인해야 함을 설명할 수 있다.

출처와 참고 자료