03-회귀-CI-루프

03. 회귀 CI 루프

프롬프트는 코드처럼 다뤄라

코드 자산	프롬프트 자산
src/auth.ts	prompts/classifier.system.txt
tests/auth.test.ts	evals/classifier.cases.jsonl
npm test	make eval-classifier
커밋	커밋
PR + CI	PR + eval CI
롤백	롤백

이렇게 다뤄야 비로소 프롬프트 엔지니어링이라는 단어가 의미를 가진다. 그렇지 않으면 프롬프트 작문이다.

디렉토리 구조 예시

prompts/
  ticket-classifier/
    system.v3.txt
    schema.json
    examples.jsonl     # few-shot 예시
evals/
  ticket-classifier/
    cases.jsonl        # 입력 + 라벨 + 슬라이스
    judge.system.txt   # LLM-as-judge 프롬프트
    metrics.yml        # 메트릭 정의 + 회귀 기준
    reports/
      v3-2026-04-07.json
      v2-2026-03-15.json

CI 루프

# 로컬
make eval-classifier  # 변경 후 즉시 확인

# CI (PR마다)
1. 변경된 prompt 감지
2. 해당 eval 세트 실행
3. 메트릭 계산 (정확도/parse/비용/지연)
4. 슬라이스별 표 출력
5. 회귀 기준 위반 시 PR 차단
6. 결과를 reports/에 커밋

”평가의 비용”을 줄이는 법

평가는 비싸다. 다음 전략으로 비용을 관리하라.

• 계층화 — 작은 smoke set(5~10개)을 매 푸시마다, 전체 세트(100개+)를 머지 전 한 번
• 캐시 — 같은 입력 + 같은 프롬프트 버전은 결과를 캐시
• 샘플링 — 전체 세트가 너무 크면 슬라이스별 균형 샘플링
• 싼 모델 게이팅 — Haiku로 1차 통과한 케이스만 Sonnet으로 재검증

변경 워크플로우

1. 가설: "예시를 4개에서 6개로 늘리면 abuse 슬라이스가 회복할 것"
2. 브랜치: prompt/classifier/v4-more-abuse-examples
3. 변경: examples.jsonl 편집
4. 로컬 평가: make eval-classifier
5. 표 비교: v3 vs v4
6. PR: 변경 이유 + 표 + 비용 변화 명시
7. CI: 회귀 기준 통과
8. 머지 + reports/v4-...json 커밋
9. 운영 모니터링: 1주일 뒤 운영 로그로 spot-check

운영 모니터링과의 연결

평가 세트만으로는 부족하다. 운영에서 새로 들어오는 입력을 주기적으로 샘플링해 평가 세트에 추가하라. 이것이 데이터 플라이휠이다. 학술 평가가 가르치는 또 한 가지 교훈 — LiveCodeBench가 시간이 지나며 갱신되는 이유다.

자기 검증 금지

본 위키의 빌드 정책(CLAUDE.md §10)과 동일한 원칙: writer가 자신의 평가를 통과시키지 못한다. 평가는 별도 패스(verifier / critic)가 돌리거나, 적어도 별도 sub-agent / 별도 모델 / 별도 프롬프트 버전이 채점한다. 같은 모델·같은 프롬프트가 자신을 채점하면 자기 편향으로 점수가 부풀려진다.