프롬프트는 실체가 아니다: 평가·최적화 파이프라인이 본체

TL;DR Highlight

프롬프트를 손으로 다듬지 않고 pass^k 테스트와 옵티마이저로 자동 개선

Who Should Read

프로덕션 에이전트가 가끔 규칙을 어기거나 스키마를 깨서 프롬프트 수정이 불안한 백엔드 개발자

Core Mechanics

LLM은 가끔 크게 틀린다
- 구조화 출력에서 '제목 80자 이하' 같은 지시도 일부 요청에서 깨진다.
- 가장 똑똑한 모델도 마찬가지고, 입력에 따라 실패 비율이 달라져서 계속 지켜봐야 한다.
필드 이름 바꿔서 고쳤다
- 최근 사례에서 필드명을 "title"에서 "heading"으로 바꾸니 해결됐다.
- 저자는 이런 해결책이 너무 이상해서 언젠가 다시 깨질 거라고 본다.
pass^k로 행동을 측정한다
- 같은 테스트를 여러 번 돌려서 얼마나 일관되게 통과하는지 보는 방식이다(업계 용어 pass^k).
- 누군가 에이전트를 망가뜨리는 변경을 넣었을 때 이걸로 잡는다.
새 프롬프트는 다른 세계에 던져진다
- 기존 지시들의 무게 때문에 새 프롬프트는 테스트했을 때와 다르게 동작하고, 보통 나쁜 쪽이다.
- 그래서 '보이스 팀이 보이스 프롬프트를 소유한다' 패턴은 규모가 커지면 맞지 않는다고 한다.
옵티마이저가 프롬프트를 대신 다듬는다
- Claude에게 스킬을 읽히고 악의적 시나리오와 무해한 시나리오를 생성시켜 pass^k 테스트로 만든다.
- 스킬 유무로 테스트를 돌려 비교한 뒤 GEPA(유전적 파레토) 옵티마이저가 실패 원인을 돌아보며 프롬프트를 반복 수정한다.

Community Reactions

내 AI를 붙이게 하자는 의견
- 회사가 사용자에게 AI를 주기보다 사용자의 AI가 쓸 인터페이스를 제공하는 편이 낫다는 의견이 있었다.
- 그러면 AI의 엉뚱한 동작 문제가 회사 몫이 아니게 된다고 한다.
프로덕션에서 같은 문제를 겪었다는 경험
- LLM으로 신뢰할 만한 결과를 내는 시스템을 만들 때 광범위한 테스트가 필요했다는 경험이 있었다.
- 이해관계자는 잘 된 몇 번만 보고 긴 꼬리의 이상한 결과는 못 본다고 한다.
테스트 비용이 부담이라는 우려
- 통계적으로 의미 있을 만큼 테스트를 돌리려면 실제 돈이 드는데 회사가 버틸지 모르겠다는 의견이 있었다.
- 프롬프트 최적화를 계속 돌리면 고객이 돈을 안 줄 것이고 낭비라는 반응도 있었다.
프롬프트가 여전히 중요하다는 반론
- 좋은 제약도 결국 좋은 프롬프트로 만들어진다며 전문가와 초보자의 차이는 프롬프트라는 의견이 있었다.
- 사실상 프롬프트에 대한 지도학습일 뿐이라는 냉소적인 요약도 있었다.

How to Apply

지금 프롬프트에 pass^k 테스트 만들기
- 오늘 가장 자주 깨지는 규칙 하나를 골라 같은 입력을 20번 돌리는 스크립트를 만들어라.
- 통과율을 기록해 기준선으로 삼아라.
Claude로 적대·무해 시나리오 생성하기
- 새 스킬이나 프롬프트를 Claude에게 읽히고 악용 시나리오와 깨지면 안 되는 일반 시나리오를 각각 만들게 하라.
- 변경 전후로 테스트를 돌려 통과율이 오르는지 확인하라.
홀드아웃 테스트 분리해 두기
- 시나리오의 일부를 옵티마이저와 수동 수정 모두에 보여주지 말고 따로 보관하라.
- 최적화 후 홀드아웃에서 떨어지면 이전 단계로 돌아가라.
프로덕션 실패를 골든 데이터셋으로 쌓기
- 실제 대화를 샘플링해 실패 사례를 라벨링하고 테스트 스위트에 추가하라.
- 브랜드 보이스처럼 판단이 복잡한 항목은 라벨링 데이터로 LLM 심사기를 따로 최적화하라.

Try It

복사해서 바로 해보기

# Claude 또는 ChatGPT에 붙여넣기 (논문 방법의 간이 버전: 테스트 생성 단계만)

아래는 우리 에이전트에 추가하려는 프롬프트(스킬)다.
{{프롬프트}}

이 프롬프트에 대해 다음을 만들어줘.
1. 악의적인 사용자가 이 규칙을 우회하려는 시나리오 10개
2. 이 프롬프트 때문에 깨질 수 있는 정상 사용 시나리오 10개

각 시나리오는 JSON으로 출력해줘: {"input": 사용자 발화, "expected": 기대 행동, "check": 판정 방법(코드로 확인 가능한지, LLM 심사가 필요한지)}

이어서 해 볼 것: 각 시나리오를 20번씩 돌려 통과율(pass^k)을 프롬프트 적용 전후로 비교해 봐.

Terminology

pass^k같은 테스트를 k번 반복해 매번 통과하는지 보는 지표다. 한 번 성공하는 것과 계속 성공하는 것은 다르다는 걸 드러낸다.

GEPALLM이 프롬프트가 테스트에서 왜 잘되거나 못됐는지 돌아보고 스스로 수정하는 프롬프트 옵티마이저다. 코드 리뷰어가 자동으로 패치를 반복하는 것과 비슷하다.

홀드아웃 테스트최적화 과정에서 보여주지 않고 빼 둔 테스트다. 시험 문제를 외웠는지 확인하는 새 문제와 같다.

LLM 심사기(judge)에이전트의 응답이 기준을 지켰는지 판정하는 LLM이다. 채점 담당 직원 역할이다.

골든 데이터셋전문가가 좋은 응답과 나쁜 응답으로 라벨링해 둔 기준 데이터다. 품질을 재는 자 역할을 한다.