13- 여기서 f_p는 프롬프트 p를 적용한 모델, \hat{y}_i = f_p(x_i)는 모델 출력이다.
14- 즉 프롬프트 개선은 "글을 더 잘 쓰는 일"이 아니라 \text{Score}(p)를 올리는 최적화 문제로 다시 정의된다.
152. Why — 평가 없이 고치면 무엇이 무너지는가
16(1) 회귀(regression)는 조용히 일어난다
17- 고객 문의 분류 프롬프트에 "환불 요청은 꼭 refund로 분류하라"는 한 줄을 추가했다고 하자.
18- 환불 사례 정확도는 오르지만, "환불 규정이 궁금하다"는 단순 문의까지 refund로 끌려간다.
19- 개발자는 자기가 방금 본 실패 사례만 다시 확인하므로 이 손실을 관측조차 하지 못한다. 이것이 프롬프트 회귀다.
20- 규칙을 하나 추가할 때마다 다른 구간이 깎이는 현상은 프롬프트가 모델 전체 행동에 작용하는 전역 수정이기 때문이다.
21(2) '진짜 개선'과 '우연한 개선'의 구별
22- 표본이 작으면 점수 변화의 상당 부분은 표본 잡음이다. 정확도 p를 n개 사례로 추정할 때 표준오차는 다음과 같다.
23
\text{SE} = \sqrt{\frac{p(1-p)}{n}}
24- 예: p = 0.8, n = 20이면 \text{SE} \approx 0.089. 즉 정확도 8~9%p 변동은 아무 의미 없는 흔들림이다.
25- 20개 사례에서 16개 → 18개로 늘었다고 "개선했다"고 말하는 것은 동전 던지기를 개선이라 부르는 것과 같다.
26- 같은 p=0.8에서 n = 500이면 \text{SE} \approx 0.018로, 그제야 2~3%p 차이를 논할 수 있다.
27(3) 사람의 기억은 평가 셋을 대체하지 못한다
28- 프롬프트를 열 번 수정하면 비교해야 할 조합은 열 개이고, 각 버전의 실패 유형은 사람이 기억할 수 없다.
29- 평가 셋은 버전 간 비교 가능성을 보존하는 유일한 수단이며, 이 원칙은 대규모 LLM 평가 체계인 HELM에서도 "동일 조건·동일 지표로 전 모델을 재측정한다"는 형태로 강조된다 (Liang et al., 2022).
303. How — 실제 현장에서 어떻게 쓰이는가
31(1) 프로덕션 RAG 파이프라인의 정확도 추적
32- 검색 증강 생성(RAG)에서는 검색기·프롬프트·모델 버전이 각각 바뀌므로, 한 곳만 고쳐도 최종 답변 품질이 흔들린다 (Lewis et al., 2020).
33- 실무에서는 100~1000개 질문·근거·정답 묶음을 고정 평가 셋으로 두고, 배포 전마다 정확도·근거 인용률·환각률을 자동 측정한다.
34- 핵심은 절대 점수가 아니라 이전 버전 대비 델타다. 델타가 음수인 항목이 회귀 후보다.
35(2) 고객지원 챗봇 프롬프트의 A/B 테스트
36- 오프라인 평가 셋에서 통과한 두 후보 프롬프트 p_A, p_B를 실제 트래픽에 나눠 태운다.
37- 지표는 해결률·상담원 이관율·재문의율처럼 비즈니스 결과로 잡고, 오프라인 점수와 온라인 지표가 어긋나는지 확인한다.
38- 오프라인에서만 이긴 프롬프트는 평가 셋에 과적합된 것이므로, 평가 셋을 갱신해야 한다는 신호다.
39(3) 평가 우선(evaluation-first) 원칙
40- OpenAI·Anthropic의 프롬프트 엔지니어링 가이드는 공통적으로 "프롬프트를 쓰기 전에 성공 기준과 평가 셋을 먼저 정의하라"를 1번 항목에 둔다.
41- 이유는 단순하다. 무엇을 좋은 출력이라 부를지 정의하지 않으면, 개선 여부를 판정할 수 없고 개선 작업은 취향 논쟁으로 퇴화한다.
42- 라벨 만들기가 비싼 개방형 과제에서는 모델이 두 응답을 비교 채점하는 LLM-as-a-judge 방식이 널리 쓰이며, 인간 선호와 약 80% 수준으로 일치한다고 보고되었다 (Zheng et al., 2023). 다만 위치 편향·장문 선호 같은 편향이 있어 순서를 섞어 두 번 채점하는 보정이 권장된다.
434. 평가 없는 수정이 위험한 이유 — 정리
44- 측정 불가: 개선 폭을 모르니 언제 멈춰야 할지도 모른다.
45- 회귀 은폐: 고친 사례만 보므로 깎인 구간이 배포 후 사용자 클레임으로 드러난다.
46- 잡음 추종: 표본이 작아 우연한 성공을 규칙으로 굳혀버린다.
47- 롤백 불가: 어느 버전이 최고였는지 근거가 없어 되돌릴 기준점이 사라진다.
48- 책임 분산 실패: 여러 명이 프롬프트를 만지는 팀에서는 공통 점수판이 없으면 변경 승인 기준 자체가 존재하지 않는다.
495. 이 레슨에서 앞으로 다룰 흐름
501) 평가 셋 설계 — 무엇을 몇 개, 어떤 분포로 모을 것인가
512) 지표 선택 — 정확 일치, 루브릭 채점, 모델 채점의 쓰임새
523) 반복 개선 루프 — 가설 → 수정 → 측정 → 채택/폐기
534) 회귀 방지 — 고정 셋 + 실패 사례 누적 셋의 이중 구조
54- 이 네 단계는 모두 앞에서 정의한 \text{Score}(p)를 신뢰할 수 있게 만드는 장치라는 하나의 목적으로 묶인다.