평가 주도 개발(EDD): AI 기능을 테스트하며 다듬기

평가 주도 개발이란

프롬프트는 짧을수록 빠르고 싸고 관리하기 쉽다. 하지만 너무 짧으면 모델이 좋은 결과를 낼 맥락·지시·예시가 모자란다. 평가 주도 개발(evaluation-driven development, EDD)은 이 간결함과 효과 사이의 균형을 체계적으로 찾는 방법이다. 작고 확신 있는 단계로 출력을 개선하고, 회귀를 잡고, 모델 행동을 사용자·제품 기대에 계속 맞춘다.

AI의 불확실성에 맞춘 TDD라고 보면 된다. 차이는 정답이다.

	TDD	EDD
기대 출력	하나로 정해져 있다	좋은 출력도 나쁜 출력도 예상 못 한 모양으로 나온다
검사	단언(assert)으로 하드코딩	결정적 검사 + 주관적 품질 평가
테스트를 쓰는 효과	기능 동작이 분명해진다	평가 기준을 정하며 모호한 과제가 구체화된다
루프	Red → Green → Refactor	정의 → 기준선 → 평가 → 최적화 → (반복)

flowchart LR
  p["문제 정의"] --> b["기준선 프롬프트"] --> s["평가 체계"] --> e["평가"]
  e --> o["최적화"]
  o --> e
  logs["운영 로그·사용자 피드백"] --> tc["새 테스트 케이스"] --> s

결정적 테스트에 익숙해도 좋은 AI 경험에는 감각이 필요하다. 사용자에 대한 공감, 어조와 명료함에 대한 민감도, 모델을 창작 협업자로 대하는 태도가 프롬프트를 낫게 만든다. TDD의 사이클 자체는 프론트엔드에서의 TDD에 있다.

1. 문제 정의

문제를 API 계약처럼 적는다.

항목	블로그 제목 생성기의 값
입력 타입	블로그 글 초안
출력 형식	제목 3개를 담은 JSON 배열
제약	128자 미만, 친근한 어조

그리고 예시 입력을 모은다. 이상적인 예와 함께 실제의 지저분한 입력, 변형과 가장자리 경우(이모지가 든 글, 중첩 구조, 코드 조각이 많은 글)를 넣어 다양성을 확보한다.

2. 기준선

첫 프롬프트는 제로샷으로 쓴다. 명확한 지시, 출력 형식, 입력 자리 표시자만 넣는다. 구성 요소와 기법은 평가 결과를 보고 하나씩 더한다(프롬프트 작성법 치트시트).

3. 평가 체계

생성형 AI에는 맞춰 볼 정답이 없으니 평가 루프에 더 공을 들인다. 측정 도구도 여러 개가 필요하다.

지표

결정적 지표: 정답이 있다. JSON이 유효한가, 개수가 맞나, 길이 제한을 지켰나.
주관적 지표: 대부분의 시간은 여기에 쓴다. 품질, 유용성, 어조, 창의성. 넓은 목표로 시작해, 구체적인 문제를 만날 때마다 지표를 다듬는다. 제목이 특정 표현을 반복해 기계적으로 느껴진다면 "다양성"과 "상투 구조 회피" 지표를 새로 만든다. 시간이 지나면 핵심 지표가 안정된다.
MMLU-Pro, SEED-Bench 같은 공개 벤치마크에 기대지 않는다. 모델 선택의 첫 신호일 뿐, 우리 사용자를 대표하지 않는다.
무엇이 좋은지 아는 도메인 전문가와 함께 정한다. 글쓰기 도우미라면 편집자와 짝을 이룬다.

심판 고르기

심판	잘 맞는 것	한계
코드 검사	결정적·규칙 기반 출력: 금칙어, 글자 수, JSON 구조. 버튼·폼 필드처럼 고정 출력 UI	주관적 품질은 못 잰다
사람 피드백	어조, 명료함, 유용성. 초기엔 직접(또는 전문가와) 읽는 게 가장 빠르다	확장이 안 된다. 출시 후 별점 같은 앱 내 신호는 잡음이 많고 섬세하지 않다
LLM 심판(LLM-as-a-judge)	주관적 기준을 규모 있게 채점·비평	순진하게 쓰면 심판 모델의 편향과 지식 공백을 그대로 키운다

양보다 질이다. 예측형 AI에서는 라벨링을 크라우드소싱하는 일이 흔하지만, 생성형 AI 평가에서 크라우드 평가자는 도메인 맥락이 부족하다. 맥락이 풍부한 고품질 평가가 규모보다 중요하다.

4. 평가와 최적화

빨리 시험하고 고칠수록 빨리 기대에 닿는다. 하나 고치고, 평가하고, 다른 걸 시도하는 습관을 들인다.

평가 파이프라인 자동화 (LLMOps)

개발과 운영을 잇는 자동화 인프라를 흔히 LLMOps라고 한다. 외부 플랫폼을 고르기 전에 이상적인 작업 흐름부터 설계한다.

구성 요소	내용
버전 관리	프롬프트·평가 지표·테스트 입력을 코드처럼 저장소에 둔다
자동 배치 평가	프롬프트가 바뀔 때마다 GitHub Actions 같은 워크플로로 평가를 돌리고 비교 보고서를 만든다
프롬프트 CI/CD	결정적 테스트·LLM 심판 점수·가드레일로 배포를 막는다. 품질이 떨어지면 병합을 차단한다
운영 로깅·관측	입력·출력·오류·지연·토큰 사용량을 기록하고 드리프트와 실패 급증을 감시한다
피드백 수집	좋아요·다시 쓰기·이탈 같은 신호를 모아 반복되는 문제를 새 테스트 케이스로 만든다
실험 추적	프롬프트 버전, 모델 설정, 평가 결과를 함께 기록한다

작고 겨냥한 수정

언어부터 다듬는다. 지시를 구체적으로, 의도를 분명히, 모호함을 없앤다.
과적합하지 않는다. 제목이 계속 "완벽 가이드"로 시작한다고 그 구절만 금지하면 다른 상투구가 나온다. 문제를 추상화해 상위 지시를 고친다. 독창성, 다양성, 특정 편집 스타일을 강조해 모델이 예외 하나가 아니라 밑에 깔린 선호를 배우게 한다.
기법을 바꿔 본다. 이 과제가 유추(퓨샷), 단계적 추론(생각의 사슬), 반복 개선(자기 성찰) 중 무엇으로 가장 잘 풀리는지 묻는다.
LLM에게 프롬프트 작성·개선을 맡길 수도 있다(자동 프롬프트 최적화).

출시 후에도 플라이휠은 빨라진다

운영에 들어가면 EDD는 느려지지 않고 오히려 빨라져야 한다. 사용자 입력 로그가 가장 값진 통찰 원천이다. 반복되는 패턴을 평가 세트에 넣고 다음 최적화를 고른다. 사용자 입력을 볼 수 없게 설계한 시스템이라면 다른 형태의 피드백을 찾는다. 로그를 모을 때의 프라이버시 원칙은 책임 있는 AI에 있다.

정리

EDD는 정답 없는 출력을 위한 TDD다. 문제 정의 → 제로샷 기준선 → 평가 체계 → 작은 수정 루프를 돈다.
지표는 결정적 검사와 주관적 품질로 나누고, 주관적 지표는 문제를 만날 때마다 다듬는다. 공개 벤치마크는 대표성이 없다.
심판은 코드 · 사람 · LLM을 섞는다. 평가자는 수보다 도메인 맥락이 중요하다.
프롬프트·지표·테스트 입력은 코드처럼 버전 관리하고 CI에서 회귀를 막는다.
증상 하나를 막는 좁은 규칙보다 상위 지시를 고친다.

버그 제보