byteforce

CPN 한국어 자습서 · 러닝패스 2 / 4 — Building with the Claude API

프롬프트 평가

프롬프트 평가

Prompt evaluation

새 주제로 넘어갑니다. 프롬프트를 잘 쓰는 기법(프롬프트 엔지니어링)과, 그 프롬프트가 잘 동작하는지 측정하는 방법(프롬프트 평가)입니다. 이 섹션은 평가에 집중합니다 — 프롬프트를 한두 번 테스트하고 끝내는 함정 대신, 객관적 점수로 검증하는 평가-우선 접근을 봅니다.

전체 내레이션영상 나레이션 한국어 번역 (전체)

Stephen Grider · Anthropic 기술 스태프

Claude에 접근하는 법을 익혔으니, 이제 초점을 옮겨 두 가지 새 주제를 봅니다 — 프롬프트 엔지니어링과 프롬프트 평가입니다. 둘 다 Claude에게서 최선의 출력을 끌어내는 프롬프트를 쓰기 위한 것입니다. 프롬프트 엔지니어링은 프롬프트를 쓰거나 고칠 때마다 쓰는 기법 모음으로, Claude가 요청을 이해하고 원하는 방식으로 답하도록 돕습니다. 프롬프트 평가는 다릅니다 — 프롬프트를 자동으로 테스트해, 그 프롬프트가 효과적인지 알려 주는 객관적 지표를 얻는 것입니다.

이 섹션은 주로 프롬프트 평가에 집중합니다. 프롬프트의 효과를 측정하는 법을 익힌 뒤, 프롬프트 엔지니어링 기법을 살펴봅니다.

먼저 프롬프트 평가가 전체 프롬프트 작성 과정의 어디에 들어가는지 봅시다. 프롬프트를 처음 쓰고 나면 보통 세 갈래 길이 있습니다. 옵션 1은, 만든 프롬프트를 한두 번 테스트해 보고 "production에 써도 충분하다"고 판단하는 것입니다. 옵션 2는, 직접 만든 입력으로 몇 번 테스트하고, 눈에 띈 모서리 케이스 한두 개를 손보는 것입니다.

분명히 해두면, 옵션 1과 2는 거의 모든 엔지니어가 — 저 자신을 포함해 — 빠지는 함정입니다. 진지한 애플리케이션에 쓸 프롬프트를 쓰면서도 충분히 테스트하지 않는 거죠.

그래서 프롬프트를 쓸 때는 옵션 3를 강력히 권합니다. 프롬프트를 평가 파이프라인에 통과시켜 객관적 점수를 얻고, 그 점수를 보며 프롬프트를 반복해서 개선하는 것입니다. 그러면 프롬프트가 최대한 잘 동작하도록 다듬을 수 있습니다.

이 장에서 배우는 것What you'll learn

약 3분
1

프롬프트 엔지니어링 = 작성·수정 기법, 평가 = 효과 측정

2

이 섹션은 주로 프롬프트 평가에 집중한다

3

작성 후 3경로 — ①대충 테스트 ②커스텀 입력 약간 ③평가 파이프라인

4

옵션 1·2는 거의 모두 빠지는 함정 — 테스트 부족

5

옵션 3 = 평가-우선, 객관적 점수로 반복 개선

6

측정 → 약점 사전 발견 → 신뢰도 높은 앱

먼저 짚고 갈 용어
prompt engineering (프롬프트 엔지니어링)
효과적인 프롬프트를 작성·수정하는 기법 모음. Claude의 이해와 응답 방식을 돕는다.
prompt evaluation (프롬프트 평가)
자동화된 테스트로 프롬프트의 효과를 객관적 지표로 측정하는 것.
evaluation pipeline (평가 파이프라인)
여러 테스트 케이스로 프롬프트를 돌려 점수를 내는 자동화 흐름.
metric (지표)
프롬프트 성능을 나타내는 객관적 수치(점수).

두 가지 새 주제

Engineering vs evaluation

프롬프트로 Claude의 출력을 끌어올리는 데는 두 축이 있습니다. 잘 쓰는 기법과, 잘 쓰였는지 측정하는 방법입니다.

Prompt Engineering

프롬프트 엔지니어링

효과적인 프롬프트를 작성·수정하는 기법 모음. Claude가 요청을 잘 이해하고 원하는 방식으로 답하도록 돕습니다.

  • 군더더기 줄이기
  • XML 태그로 구조화
  • 그 외 여러 모범 사례
Prompt Evaluation

프롬프트 평가

작성법이 아니라 효과 측정에 집중. 자동화된 테스트로 객관적 지표를 얻습니다.

  • 기대 출력과 비교
  • 프롬프트 버전 비교
  • 오류 여부 점수화

이 섹션은 주로 프롬프트 평가를 다룹니다. 측정하는 법을 먼저 익히고, 이후 프롬프트 엔지니어링 기법으로 넘어갑니다.

작성 후 3가지 경로

Three paths after writing a prompt

프롬프트를 처음 쓰고 나면 보통 세 갈래 길이 있습니다. 어떤 길을 택하는지가 프롬프트의 신뢰도를 가릅니다.

프롬프트 작성 후 3가지 경로 · 눌러서 비교
프롬프트 초안 작성

옵션 1·2는 거의 모든 엔지니어가 빠지는 함정입니다. 충분히 테스트하지 않은 프롬프트는 실제 사용자 입력 앞에서 쉽게 무너집니다. 옵션 3로 가세요.

평가-우선 접근

The evaluation-first approach

옵션 1·2가 함정인 이유는 단순합니다. production에 올리면 사용자는 우리가 상상도 못 한 방식으로 입력합니다. 제한된 테스트에서 멀쩡해 보이던 프롬프트가 실제 입력의 다양성 앞에서 무너집니다.

옵션 3가 주는 것
  • 약점을 미리 발견 — production 이슈가 되기 전에.
  • 프롬프트 버전을 객관적으로 비교.
  • 측정 가능한 개선에 근거해 자신 있게 반복.
  • 신뢰할 수 있는 AI 애플리케이션.
트레이드오프

평가 파이프라인은 시간·도구에 선투자가 필요합니다. 대신 최종 앱의 신뢰성과 견고함으로 돌려받습니다. 핵심은 사용자가 겪기 전에 개발 단계에서 문제를 잡는 것입니다.

정리 & 점검

Recap & check
핵심 정리
  • 엔지니어링은 프롬프트를 잘 쓰는 기법, 평가는 효과를 객관적으로 측정.
  • 작성 후 3경로 중 옵션 1·2(대충/약간 테스트)는 함정.
  • 옵션 3 = 평가 파이프라인으로 점수화 → 반복 = 권장.
  • 측정은 약점을 사전에 드러내고, 버전 비교와 자신 있는 반복을 가능하게 한다.

Q1프롬프트 엔지니어링과 프롬프트 평가의 차이는?

Q2프롬프트를 한두 번만 테스트하고 production에 올리면?

Q3권장되는 접근(옵션 3)은?

MEMBER SESSION REQUIRED · REGISTRATION IS FREE

여기부터는 등록한 분에게 열립니다.

전 코스는 계속 무료입니다. 등록하면 이 코스의 남은 76개 레슨을 끝까지 읽을 수 있습니다.

등록하고 이어서 읽기

이미 등록하셨다면 그때 쓰신 이메일을 넣어 주세요.