최근 한 X 게시물은 Microsoft가 품질 점수를 매기는 LLM judge 프롬프트를 조정하는 데 DSPy와 GEPA를 사용했다고 전했다.1
이 소식에서 더 중요한 포인트는 특정 회사의 사용 사례 자체가 아니다. 이제는 답변을 생성하는 프롬프트뿐 아니라, 답변을 평가하는 judge 프롬프트도 최적화와 관리의 대상이 되고 있다는 점이다.
LLM judge는 모델 답변을 채점하는 또 다른 LLM이다. 그런데 judge 프롬프트가 모호하면 품질 점수도 흔들린다. “정확성”, “안전성”, “간결성” 같은 기준을 어떻게 해석할지 명확하지 않으면 같은 답변도 다르게 평가될 수 있다.
따라서 LLM 품질 관리는 단순히 좋은 생성 프롬프트를 작성하는 문제를 넘어선다. 평가 기준을 담은 프롬프트까지 실험하고, 측정하고, 개선하는 체계가 필요하다. DSPy와 GEPA는 이 흐름을 이해하는 데 좋은 출발점이다.
DSPy: 프롬프트를 코드처럼 다루기
DSPy는 생성형 AI 에이전트를 프로그램 방식으로 정의하고 최적화하는 프레임워크다.2
핵심은 프롬프트 엔지니어링을 수작업 문장 수정이 아니라, 성능 지표에 맞춘 최적화 문제로 바꾸는 데 있다.
예를 들어 질문 답변, 요약, RAG 같은 작업을 모듈로 나누고 입력과 출력의 역할을 명확히 정의한다. 이후 DSPy는 지정된 지표에 맞춰 더 나은 프롬프트나 파이프라인을 찾는다.2
이 접근이 LLM judge에도 중요한 이유는 분명하다. judge 프롬프트 역시 평가 작업을 수행하는 하나의 프로그램처럼 볼 수 있기 때문이다. 사람이 감으로 기준 문장을 계속 고치는 대신, 평가 결과를 기준으로 judge 프롬프트를 개선할 수 있다.
GEPA: 실패 이유를 반영해 프롬프트를 고치기
GEPA는 프롬프트 같은 텍스트 구성요소를 반복적으로 개선하는 반성 기반 최적화 방식이다.3
단순히 점수가 높은 후보를 고르는 데 그치지 않고, 실행 결과와 피드백을 바탕으로 “왜 실패했는지”를 읽고 새로운 지시문을 만든다.
이 방식은 LLM judge 프롬프트에 특히 잘 맞는다. judge의 역할은 정답을 생성하는 것이 아니라 기준을 일관되게 해석하고 적용하는 것이다. 따라서 점수만 보는 최적화보다, 실패 사례에서 기준의 모호함을 찾아내고 설명을 보강하는 방식이 실용적이다.
예를 들어 judge가 간결한 답변을 과도하게 선호해 중요한 근거가 빠진 답변에도 높은 점수를 준다면, GEPA식 최적화는 그런 실패 패턴을 반영해 평가 지시문을 더 구체화할 수 있다. 중요한 것은 “좋아 보이는 문장”을 쓰는 것이 아니라, 실제 평가 데이터에서 더 일관된 판단을 하도록 만드는 것이다.
MLflow로 보는 실무 적용 흐름
이 흐름은 MLflow에서도 확인할 수 있다. MLflow의 mlflow.genai.optimize_prompts() API는 평가 지표와 학습 데이터를 사용해 프롬프트를 자동 개선한다.4
MLflow는 Databricks AI Research Team이 연구·검증한 GepaPromptOptimizer를 통해 GEPA 최적화 알고리즘을 지원하며, 사용자 지정 스코어러와 집계 함수도 사용할 수 있다.4
다만 이 기능은 현재 베타이고, optimize_prompts API는 MLflow 3.5.0 이상이 필요하다.4
따라서 처음부터 운영 환경의 핵심 평가 체계에 바로 적용하기보다는, 작은 평가 세트에서 judge 프롬프트의 일관성을 검증하는 방식으로 시작하는 편이 현실적이다.
실무적으로는 다음 질문부터 점검할 수 있다.
judge가 평가할 기준은 명확히 분리되어 있는가?
사람이 기대하는 점수와 judge 점수의 차이를 확인할 평가 데이터가 있는가?
점수 평균뿐 아니라 실패 사례를 분석할 수 있는가?
judge 프롬프트도 생성 프롬프트처럼 버전 관리되고 있는가?
결론: 평가 프롬프트도 제품 품질의 일부다
LLM 품질 관리는 더 이상 “좋은 프롬프트 하나 작성하기”가 아니다. 생성 프롬프트, 평가 프롬프트, 점수 기준을 함께 관리하고 개선해야 한다.
DSPy는 프롬프트와 AI 파이프라인을 최적화 가능한 프로그램처럼 다루게 해준다. GEPA는 점수뿐 아니라 실패 이유와 피드백을 활용해 프롬프트를 반복적으로 개선한다. MLflow의 프롬프트 최적화 기능은 이런 흐름이 실험 단계를 넘어 도구화되고 있음을 보여준다.
핵심은 간단하다. LLM judge를 쓴다면 judge 프롬프트도 신뢰성의 일부다. 그리고 그 신뢰성은 감으로 유지하는 것이 아니라, 데이터와 지표, 반복적인 최적화로 관리해야 한다.
1Microsoft Uses DSPy And GEPA To Optimize LLM Judge Prompts
2Build generative AI apps using DSPy on Databricks
4MLflow Prompt Optimization (beta) - Azure Databricks | Microsoft Learn
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.