23. 평가(eval)의 기초 — 좋은 프롬프트인지 어떻게 아는가

이 안내서의 종착점

지금까지 거의 모든 장에 🧪 직접 검증법 콜아웃이 있었습니다. "남이 그렇다더라"가 아니라 당신의 모델에서 직접 확인하라는 것이었죠. 이 장은 그 검증을 체계화합니다. 평가(evaluation, 줄여서 eval)란, 프롬프트가 실제로 잘 작동하는지 측정하는 방법입니다.

📌 핵심: 이 분야의 최종 심판은 권위 있는 가이드도, 이 안내서도 아닙니다. 당신의 작업에서의 측정 결과입니다. 평가는 그 측정을 "느낌"에서 "증거"로 바꿉니다.

왜 "느낌"으로는 부족한가

프롬프트를 고친 뒤 한두 번 돌려보고 "오, 좋아졌네"라고 판단하기 쉽습니다. 하지만 2장의 확률성 때문에, 한두 번의 좋은 결과는 운일 수 있습니다. 또 한 가지 예시에서 좋아 보여도 다른 입력에서는 나빠졌을 수 있습니다. 평가는 이 두 함정 — 운과 표본 편향 — 을 피하게 해줍니다.

flowchart LR
    feel["느낌으로 판단<br/>'좋아진 것 같아'"] --> risk["운/표본 편향에 취약"]
    eval["평가로 판단<br/>'10개 입력 중 9개 개선'"] --> trust["근거 있는 판단"]

    classDef bad fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
    classDef good fill:#dcfce7,stroke:#22c55e,color:#14532d
    class feel,risk bad
    class eval,trust good

가장 가벼운 평가 — 누구나 할 수 있다

평가는 거창한 시스템이 아니어도 됩니다. 비개발자도 지금 시작할 수 있는 최소 형태부터.

1단계: 대표 입력 모으기. 실제로 마주칠 입력 5~10개를 모읍니다. 쉬운 것, 어려운 것, 경계선상의 것을 골고루(7장 대표성과 같은 원칙).

2단계: 기대 결과 적어두기. 각 입력에 대해 "이렇게 나오면 좋다"를 미리 적습니다. 미리 적는 게 핵심입니다 — 결과를 본 뒤 정하면 자기 합리화가 끼어듭니다.

3단계: 돌려서 비교. 프롬프트를 그 입력들에 돌리고, 기대와 얼마나 맞는지 셉니다.

4단계: 한 번에 하나만 바꾸기. 프롬프트를 수정할 때 한 곳만 바꾸고 다시 셉니다(4장에서 본 변수 통제). 그래야 무엇이 효과를 냈는지 압니다.

[가벼운 평가 시트 예]
입력          기대        프롬프트A   프롬프트B
후기1: "최고"  긍정         긍정 ✅     긍정 ✅
후기2: "별로"  부정         부정 ✅     부정 ✅
후기3: "그냥"  중립         긍정 ❌     중립 ✅
...
정확도                     7/10       9/10  ← B가 낫다

💡 팁: 이 단순한 표 하나가 "느낌"을 "증거"로 바꿉니다. 엑셀이나 메모장이면 충분합니다. 중요한 건 도구가 아니라 미리 정한 기대와 비교한다는 원칙입니다.

무엇을 측정하나 — 작업별 지표

⚠️ 흔한 실수·미신: "좋은 글", "자연스러운 답" 같은 주관적 품질은 측정이 어렵다고 평가를 포기하기 쉽습니다. 하지만 기준을 정하면 주관적 품질도 부분적으로 평가할 수 있습니다 — 예: "행동 유도 문구 포함 여부", "전문용어 사용 개수", "요청한 톤 부합(상/중/하)". 완벽히 객관화할 수 없어도, 일관된 기준으로 비교하면 "느낌"보다 낫습니다.

평가의 단짝: 검증과 일관성

평가는 4부의 다른 장들과 한 묶음입니다.

• 18장(환각): "근거로 뒷받침되는 주장 비율"을 평가 지표로
• 20장(검증 가능성): 검증 가능한 출력이라야 평가도 쉬움
• 22장(일관성): "반복 시 변동률"이 곧 일관성 평가

즉 4부 전체가 "믿을 수 있는 출력 → 그것을 측정 → 측정으로 개선"이라는 하나의 순환입니다.

flowchart LR
    build["프롬프트 작성<br/>(1~3부)"] --> measure["평가로 측정<br/>(대표 입력 + 기대)"]
    measure --> improve["약점 겨냥 수정<br/>(한 번에 하나)"]
    improve --> measure
    measure -->|충분| ship["사용/배포"]

    classDef step fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    classDef good fill:#dcfce7,stroke:#22c55e,color:#14532d
    class build,measure,improve step
    class ship good

🔧 개발자 노트: 프로덕션에서는 이 순환을 자동화합니다. ① 테스트 입력 세트(데이터셋)를 고정하고, ② 프롬프트를 바꿀 때마다 자동으로 전체에 돌려 지표를 산출하며(회귀 테스트), ③ 채점은 정답 대조·규칙 기반·또는 다른 모델로 채점(LLM-as-judge) 등을 씁니다. 여러 제공자가 평가 도구·테스트 케이스 생성 기능을 제공합니다. LLM-as-judge는 편리하지만 채점 모델 자체의 편향·오류가 있으니, 사람 검토로 보정하세요. 또한 프롬프트도 코드처럼 버전 관리하고, 모델 스냅샷을 고정해 평가 조건을 일정하게 유지합니다(22장, 6부).

평가는 모델 이전(migration)의 안전망

이 분야가 빠르게 변한다는 점(1장)을 떠올리세요. 새 모델로 갈아탈 때, 기존 프롬프트가 새 모델에서도 잘 작동하는지는 알 수 없습니다. 9장에서 본 것처럼 한 모델의 정답이 다른 모델에선 역효과일 수 있으니까요. 이때 평가 세트가 있으면, 새 모델에 같은 입력을 돌려 객관적으로 비교할 수 있습니다. 평가는 변화의 시대에 가장 든든한 안전망입니다(6부 모델 이전 장에서 상세히).

🧪 직접 검증법: 지금 자주 쓰는 프롬프트 하나를 골라, 대표 입력 5개와 기대 결과를 적어보세요. 그것만으로 이미 최소 평가 세트입니다. 다음에 그 프롬프트를 고치거나 모델을 바꿀 때, 이 세트로 비교해보세요. 한 번 만들어두면 계속 씁니다.

이 장에서 배운 것

• 평가(eval)는 프롬프트가 잘 작동하는지 "느낌"이 아니라 "측정"으로 판단하는 방법으로, 이 안내서 "직접 검증"의 체계화다.
• 한두 번의 좋은 결과는 운·표본 편향일 수 있다. 대표 입력 여러 개 + 미리 정한 기대 + 비교가 이를 막는다.
• 가벼운 평가는 누구나 할 수 있다: 대표 입력 모으기 → 기대 적어두기 → 돌려 비교 → 한 번에 하나만 바꾸기.
• 분류 정확도·형식 준수율·일관성 변동률·사실성·분량 준수율 등을 측정한다. 주관적 품질도 기준을 정하면 부분 평가가 가능하다.
• 평가는 18·20·22장과 한 순환을 이루며, 모델 이전 시 객관적 비교를 가능케 하는 안전망이다.

✍️ 확인 문제

1. 프롬프트를 고친 뒤 "한 번 돌려보니 좋아졌다"고 판단하는 것이 위험한 이유를, 2장의 확률성과 이 장의 표본 편향으로 설명해보세요.

1. "좋은 마케팅 카피인지"처럼 주관적인 품질을, 그래도 부분적으로 평가하려면 어떤 기준들을 세울 수 있을지 3개 제안해보세요.

1. (실습) 당신이 실제로 자주 쓰는 작업 하나를 골라, 대표 입력 5개·각각의 기대 결과·측정할 지표를 담은 최소 평가 시트를 직접 만들어보세요.

다음 → 5부 · 고급·워크플로우 (작성 예정)
이전 ← 22. 일관성과 재현성 높이기 · 목차