프롬프트 점수는 올랐는데 서비스는 나빠질 수 있다: DSPy·GEPA 자동 최적화의 함정

 

프롬프트 자동 최적화는 AI가 지시문 후보를 만들고 실행 결과를 평가해 더 나은 후보를 찾는 방법입니다. DSPy와 GEPA는 이 반복을 체계화하지만, 평가 점수 상승이 곧 실제 서비스 품질 향상을 뜻하지는 않습니다. 자동 프롬프트 튜닝의 원리부터 데이터 분리, 평가 함수, 비용과 배포 판단까지 실무 관점에서 살펴봅니다.

 

프롬프트를 사람이 고치는 시대가 끝났다는 이야기는 매력적입니다. 문장을 조금 바꾸고 모델의 답을 읽은 뒤 다시 수정하는 일을 AI에게 넘길 수 있다면, 개발자는 반복 작업에서 벗어날 수 있습니다. 실제로 DSPy와 GEPA를 활용해 이런 개선 루프를 자동화하는 공개 사례가 나오고 있습니다.

 

그런데 여기서 질문이 하나 남습니다. AI가 고친 프롬프트의 점수가 올랐다면, 사용자가 받는 답변도 반드시 좋아졌을까요? 평가가 형식만 보거나, 특정 예제에 지나치게 맞춰져 있거나, 중요한 오류를 평균값에 묻어 버린다면 답은 달라질 수 있습니다. 자동화는 평가 기준을 빠르게 따라가는 능력을 주지만 그 기준 자체의 타당성까지 보증하지는 않습니다.

 

이 글은 2026년 10월 21일 확인한 DSPy 공식 문서, GEPA 논문의 공개 초록, LY Corporation 한국어 기술 블로그와 개인 개발 블로그를 조사해 작성했습니다. 기업의 도입 성과는 해당 저자의 보고로 구분하며, 아래 고객 문의 예시는 설계를 설명하기 위한 가상 사례입니다. 직접 프로그램을 실행해 얻은 벤치마크 결과는 제시하지 않습니다.

먼저 알아둘 핵심

• DSPy는 LLM 기반 프로그램을 구성하고 평가·최적화하는 프레임워크입니다.

• GEPA는 실행 흔적과 자연어 피드백을 활용해 프롬프트 후보를 개선하는 최적화 방법입니다.

• 프롬프트 문구를 바꾸는 작업과 모델 가중치를 학습하는 작업은 구분해야 합니다.

• 탐색과 후보 선택에 사용한 데이터는 최종 성능을 독립적으로 검증하는 데이터와 역할이 다릅니다.

• 자동 최적화의 성과는 점수와 함께 실제 오류, 비용, 지연과 유지보수 부담으로 판단해야 합니다.

읽는 순서

자동 최적화의 원리 → DSPy와 GEPA의 역할 → 공개 사례 해석 → 데이터와 평가 설계 → 고객 문의 적용 예시 → 비용과 배포 → FAQ

프롬프트 엔지니어링이 반복 실험으로 바뀌고 있다

전통적인 프롬프트 조정은 개발자의 관찰과 경험에 많이 의존했습니다. “조건을 앞에 쓰면 낫다”, “예시를 넣으면 안정된다” 같은 가설을 세우고 출력을 확인합니다. 이 방법은 빠르게 시작하기 좋지만, 변경이 쌓이면 어느 문장이 어떤 실패를 줄였는지 추적하기 어려워질 수 있습니다.

 

특히 하나의 규칙을 추가했더니 다른 입력에서 품질이 떨어지는 일이 생깁니다. 간결하게 답하라는 지시는 설명 누락을 만들 수 있고, 모든 예외를 적으라는 지시는 답변을 지나치게 길게 만들 수 있습니다. 좋은 표현을 찾는 일과 요구사항 사이의 균형을 잡는 일이 섞여 있는 것입니다.

 

자동 최적화는 이런 반복을 프로그램으로 구성합니다. 현재 지시문으로 예제를 실행하고, 결과를 점수와 피드백으로 평가하고, 새 후보를 만든 다음 같은 기준으로 비교합니다. 사람이 매번 모든 문장을 직접 바꾸는 대신 탐색할 문제와 성공 기준을 정의하는 쪽에 더 많은 역할을 맡게 됩니다.

이 변화가 프롬프트 엔지니어링의 소멸을 뜻하지는 않습니다. 무엇을 모델에게 맡기고 어떤 입력과 출력을 주며 어떤 제약을 유지할지 정하는 일은 여전히 필요합니다. 문구 작성의 일부가 자동화되는 만큼 업무 정의와 평가 설계의 비중이 커진다고 보는 편이 정확합니다.

 

DSPy 공식 최적화 안내도 모델마다 같은 지시문에 대한 반응이 다르고 업데이트로 동작이 달라질 수 있다는 점에서 출발합니다. 자동 탐색은 이런 변화를 비교하는 도구가 될 수 있습니다. 다만 새 모델에 최적화를 다시 실행할 수 있다는 사실과 그 결과를 바로 운영에 넣어도 된다는 판단은 별개의 문제입니다.

DSPy는 무엇을 하고 GEPA는 어디에 들어가는가

DSPy에서는 Signature로 작업의 입력과 출력, 의도를 표현하고 Module로 프로그램의 동작을 구성할 수 있습니다. 예를 들어 문맥과 질문을 받아 답을 만드는 작업, 검색 결과를 정리한 뒤 최종 응답을 만드는 작업을 각각의 구성 요소로 다룰 수 있습니다.

 

Signature를 선언했다고 필요한 사실과 업무 규칙이 저절로 생기는 것은 아닙니다. 입력 필드의 의미, 원하는 결과와 제약을 설명해야 합니다. 출력을 구조화하는 장치가 있더라도 값의 정확성까지 자동으로 확보되는 것도 아닙니다. 형식과 의미를 따로 확인해야 합니다.

 

Metric은 개별 예측이 얼마나 좋은지 평가하는 함수입니다. 정답과 비교하거나, 코드로 확인 가능한 조건을 검사하거나, 다른 LLM에게 평가를 맡기는 방법을 조합할 수 있습니다. DSPy 공식 Metrics 문서는 최적화에 앞서 “더 좋다”의 의미와 기준선 평가가 필요하다고 설명합니다.

 

Optimizer는 그 평가를 사용해 프로그램을 개선하는 역할을 합니다. DSPy에는 예시를 선택하는 방식, 자연어 지시를 고치는 방식과 모델 미세조정에 관여하는 방식 등 여러 접근이 있습니다. 따라서 “DSPy를 쓴다”는 말만으로 어떤 부분이 바뀌는지는 알 수 없습니다.

 

이번 글에서 다루는 GEPA 기반 프롬프트 최적화는 자연어 지시를 후보로 만들고 평가해 선택하는 흐름입니다. 여기서 좋아지는 것은 특정 작업과 모델에 맞춘 지시 구성일 수 있으며, 모델의 기본 지식 전체가 새로 학습됐다고 해석하면 안 됩니다. 모델 가중치를 바꾸는 파인튜닝과 구분해서 설명해야 합니다.

 

실제 구현에서는 Signature와 모듈, 평가 함수와 최적화 설정을 함께 버전 관리하는 편이 좋습니다. 완성된 프롬프트 문자열만 남기면 어떤 데이터와 기준으로 그 문구를 골랐는지 복원하기 어렵습니다. 자동 탐색의 장점은 결과뿐 아니라 비교 과정까지 관리할 때 커집니다.

GEPA는 점수만 보는 대신 실패의 설명을 활용한다

GEPA 논문은 자연어 리플렉션을 적극 활용하는 프롬프트 최적화 방법을 제안합니다. 공개 초록에 따르면 추론과 도구 호출, 도구 출력 같은 실행 궤적을 살펴보고 문제를 진단하며, 프롬프트 업데이트를 제안하고 시험합니다. 이름은 Genetic-Pareto에서 왔습니다.

 

핵심은 단순히 “이번 후보는 0.6점이었다”에서 끝나지 않는다는 점입니다. 어떤 예제에서 무엇이 빠졌는지, 어떤 조건을 잘못 적용했는지 같은 자연어 피드백이 다음 지시문을 바꾸는 재료가 됩니다. 숫자는 후보를 비교하고 설명은 수정 방향을 찾는 데 쓰일 수 있습니다.

가령 “응답이 부정확함”이라는 평가보다 “주어진 문서의 시행일 이후에 적용되는 규정을 이전 주문에 사용했다”는 피드백이 더 구체적입니다. 후자는 기간을 확인하는 지시가 필요한지 검토할 수 있게 합니다. 좋은 피드백은 오류의 위치와 이유를 분명히 합니다.

 

그렇다고 리플렉션 모델의 진단이 항상 맞는 것은 아닙니다. 잘못된 평가 이유를 받으면 실제 원인과 관계없는 규칙을 추가할 수 있습니다. 설명이 길고 설득력 있어 보인다는 사실만으로 원인 분석이 정확하다고 인정하면 안 됩니다. 수정 후보도 실행과 비교를 거쳐야 합니다.

 

GEPA는 여러 후보의 강점을 유지하며 탐색하는 관점을 포함합니다. Pareto라는 표현을 “모든 사업 지표가 동시에 좋아진다”는 뜻으로 읽어서는 안 됩니다. 예제별로 강점이 다른 후보를 다루는 선택 방식과 서비스의 비용·속도·정확도를 동시에 만족하는 제품 판단은 구분해야 합니다.

 

논문의 초록은 비교 실험에서 강화학습 방법과 다른 프롬프트 최적화 방법보다 좋은 결과를 보고합니다. 하지만 연구에서 선택한 작업과 모델, 예산과 평가 조건의 결과입니다. “GEPA가 모든 파인튜닝보다 우수하다”거나 “어떤 업무에서도 비용이 줄어든다”는 보편적 결론은 아닙니다.

실행 모델·평가 모델·리플렉션 모델을 나눠 생각하기

자동 최적화에는 서로 다른 역할의 모델이 등장할 수 있습니다. 실행 모델은 실제 작업의 답을 만듭니다. 평가 모델은 그 답이 기준을 만족하는지 판단합니다. 리플렉션 모델은 실행 결과와 피드백을 보고 지시문 후보를 바꿉니다. 같은 모델을 여러 역할에 쓸 수 있어도 역할의 차이는 남습니다.

 

평가를 반드시 LLM이 해야 하는 것은 아닙니다. 금액 합산이나 날짜 범위, 필수 항목과 정답 레이블을 확인할 수 있다면 코드와 정답 비교가 더 직접적인 신호를 줄 수 있습니다. 반대로 설명의 적절성처럼 하나의 정답으로 표현하기 어려운 부분은 별도의 평가 기준이 필요합니다.

 

실행 모델보다 강한 모델을 리플렉션에 사용하는 구성도 가능합니다. DSPy 공식 안내는 이런 사용을 소개합니다. 다만 실제 비용은 호출 횟수와 입력 길이, 후보 평가 규모에 따라 달라지므로 큰 모델을 일부 단계에만 쓴다는 이유로 비용을 무시하면 안 됩니다.

 

세 역할이 비슷한 가정과 오류를 공유할 가능성도 고려해야 합니다. 생성 모델이 근거 없는 답을 만들고 평가 모델이 문체만 보고 높은 점수를 주면 리플렉션도 잘못된 방향으로 개선할 수 있습니다. 역할 분리 자체가 독립적 검증을 보장하지는 않습니다.

 

실무에서는 어떤 판단을 코드로 확인하고 어떤 판단을 LLM에 맡겼는지 기록하는 편이 좋습니다. 평가 모델의 버전과 평가 프롬프트가 바뀌면 점수의 기준도 달라질 수 있습니다. 실행 프롬프트의 변화와 평가 기준의 변화를 구분해야 개선 결과를 해석할 수 있습니다.

공개 기술 블로그의 성과에서 함께 읽어야 할 부분

LY Corporation의 한국어 기술 블로그는 Yahoo! JAPAN Search의 AI 응답을 소재로 DSPy와 GEPA를 적용한 사례를 소개합니다. 저자는 수동 튜닝에 수일에서 수주 걸리던 조정 작업을 약 한 시간으로 줄였다고 보고합니다. 이 수치는 해당 과제와 구성에 대한 보고이며 모든 팀의 소요 시간을 뜻하지 않습니다.

이 사례에서 더 눈여겨볼 부분은 사람이 맡는 역할입니다. 글은 평가 관점과 우선순위의 정의, 결과의 정성적 검토, 평가 누락의 발견과 최종 릴리스 판단을 사람의 범위로 둡니다. 자동 최적화 시간을 줄였다는 말이 전체 검증과 제품 출시가 한 시간에 끝났다는 뜻은 아닙니다.

 

비용 측면의 변화도 함께 공개돼 있습니다. 해당 글은 프롬프트가 5,521자에서 8,561자로 약 55% 늘어났다고 설명합니다. 자동 개선이 항상 더 짧고 저렴한 지시문을 만들어 주는 것은 아니라는 사례입니다. 이 값은 문자 수이며 실제 토큰 수나 요금 증가율과 동일하게 해석하면 안 됩니다.

 

또 글은 여러 평가 축을 하나의 점수로 합치면 개별 축의 문제가 묻힐 수 있고, LLM 평가의 일관성에도 한계가 있다고 짚습니다. 성과를 소개하는 글 안에도 남은 과제가 존재합니다. 도입 판단에는 개선 수치만이 아니라 이런 제약을 함께 읽는 태도가 필요합니다.

 

CELL AI DEVLOG의 실습 글은 작은 질의응답 자료에서 출력 형식과 답의 보존을 개선하는 과정을 보여줍니다. 중간 후보가 이전 후보보다 점수가 낮아지는 사례도 소개합니다. 규칙을 더 강하게 적는 것이 언제나 좋은 결과로 이어지지 않는다는 흐름을 이해하는 데 유용합니다.

 

다만 개인 실습의 작은 검증 자료와 점수는 서비스 전체의 일반화 성능을 입증하지 않습니다. 형식 오류를 줄여 점수가 오른 것과 사실 추론 능력이 향상된 것도 구분해야 합니다. 이 글에서는 해당 사례를 자동 탐색 과정의 예로 참고하고, 보고된 점수를 보편적인 성능 수치로 인용하지 않습니다.

가장 위험한 착각: 검증셋 점수가 높으니 새 입력에도 강하다

최적화는 예제를 여러 번 봅니다. 어떤 예제를 수정 재료로 쓰고 어떤 예제를 후보 선택에 썼는지에 따라 결과를 해석해야 합니다. 후보를 반복해서 선택하는 데 사용한 데이터는 더 이상 완전히 독립된 최종 시험지가 아닙니다.

 

DSPy 공식 GEPA 안내는 trainset을 리플렉션을 통한 지시문 업데이트에 사용하고, valset을 후보 평가와 최종 프로그램 선택에 사용한다고 설명합니다. 그리고 이 두 과정에 영향을 주지 않은 별도의 test set을 남기라고 안내합니다. 세 데이터의 이름보다 역할의 구분이 중요합니다.

 

정해진 만능 분할 비율은 없습니다. 업무의 분포를 대표하고 비교에 필요한 안정성을 확보해야 하며, 평가 자료가 커질수록 같은 예산에서 탐색할 수 있는 후보 수가 줄어들 수 있습니다. 데이터가 적을 때는 점수의 불확실성도 함께 인정해야 합니다.

 

같은 원문에서 만든 유사 질문을 무작위로 나누는 것만으로는 충분하지 않을 수 있습니다. 학습 쪽에 있는 문서의 표현과 수치를 바꾼 문제가 테스트 쪽에 들어가면, 새로운 문서나 고객을 만났을 때의 성능과 다른 결과를 볼 수 있습니다. 문서·고객·기간 같은 분리 단위를 검토해야 합니다.

 

특히 오답을 보면서 테스트 자료를 계속 수정 기준으로 쓰면 테스트도 개발 자료가 됩니다. 문제가 발견되면 개선에 활용할 수 있지만, 그 뒤에도 같은 자료의 점수를 최종 독립 검증처럼 보고하면 안 됩니다. 새 평가를 위한 자료와 절차를 마련해야 합니다.

공식 안내는 valset을 생략하면 선택에 trainset을 재사용하는 동작도 설명합니다. 현재 예제 자체의 최선 결과를 찾는 탐색에는 의미가 있을 수 있지만, 보지 못한 데이터의 일반화 성능을 기대하는 작업과는 목적이 다릅니다. 설정을 간단히 했다는 이유로 이 차이를 놓치지 않아야 합니다.

평가 함수가 서비스 목표를 대신하지 못할 때

최적화기는 사람이 원하는 추상적인 “좋은 서비스”보다 실제로 계산된 점수를 따라 후보를 고릅니다. 따라서 평가 함수가 놓친 조건은 개선 과정에서도 충분히 보호되지 않을 수 있습니다. 측정 가능한 항목이 제품의 모든 가치와 같은 것은 아닙니다.

 

예를 들어 간결함과 친절함만 평가하면 필요한 근거가 빠진 짧은 답변이 높은 점수를 받을 수 있습니다. 반대로 설명의 상세함만 평가하면 사용자가 원하지 않는 장황한 답변이 유리해질 수 있습니다. 응답 길이를 품질 자체로 취급하지 말고 작업 성공에 어떤 역할을 하는지 봐야 합니다.

 

형식 검사도 중요하지만 충분하지 않습니다. JSON으로 파싱되고 필수 필드가 있어도 금액과 통화가 틀릴 수 있습니다. 정확한 문자열 일치만 평가하면 의미가 같은 유효한 표현을 오답으로 처리할 수도 있습니다. 어떤 오류를 잡고 어떤 오류를 놓치는지 평가 함수의 범위를 설명할 수 있어야 합니다.

 

여러 항목을 평균내면 심각한 실패가 가려질 수 있습니다. 근거 정확성에서 실패한 답이 문체와 길이에서 높은 점수를 받아 전체 평균을 통과할 수 있습니다. 업무상 절대 허용하면 안 되는 조건은 별도 통과 기준으로 두는 방안을 검토할 수 있습니다.

 

LLM-as-a-Judge를 쓸 때는 평가 이유와 점수를 함께 저장하고 사람의 판정과 비교해 봅니다. 동일한 내용을 표현만 바꿨을 때 점수가 크게 흔들리는지, 모델이 길고 자신감 있는 답을 선호하는지 확인할 수 있습니다. 평가 모델의 의견을 사실 검증의 대체물로 취급해서는 안 됩니다.

 

최적화가 진행될수록 평가기의 약점에 맞는 후보가 선택될 수도 있습니다. 이것이 반드시 모델의 의도적인 속임수라는 뜻은 아닙니다. 반복 선택이 측정 기준에 유리한 표현을 남기는 결과일 수 있습니다. 독립 자료와 실제 오류 검토가 필요한 이유입니다.

피드백은 정답을 복사하는 통로가 아니라 원인을 설명해야 한다

자연어 피드백은 GEPA의 중요한 재료지만 내용의 품질이 중요합니다. “답이 마음에 들지 않음”이나 “더 정확하게 작성” 같은 말은 무엇을 바꿔야 하는지 충분히 알려주지 못합니다. 실패한 조건과 근거를 특정하는 피드백이 수정 방향을 판단하는 데 유용합니다.

 

가상의 정책 질의응답이라면 “문서에 없는 환불 기간을 생성했다”, “기간의 시작점을 주문일 대신 수령일로 잘못 적용했다”, “근거가 부족한데 확정적으로 답했다”처럼 구체화할 수 있습니다. 이런 피드백은 지시문에 필요한 일반 원칙을 찾는 데 도움이 됩니다.

 

반대로 특정 고객의 이름과 답을 그대로 지시문에 붙이는 방식은 예제 암기로 이어질 수 있습니다. 필요한 소수 예시는 유용할 수 있지만, 개별 기록을 계속 추가하면 길이와 정보 노출 범위가 커집니다. 어떤 정보를 후보 프롬프트에 남길지 확인해야 합니다.

 

리플렉션 모델이 읽는 자료도 데이터 처리의 일부입니다. 운영 대화와 문서, 도구 결과를 외부 모델에 전달하는 구성이라면 사용 가능한 범위와 제거할 정보를 먼저 정해야 합니다. 실행 모델이 보던 자료라고 다른 평가·개선 서비스에도 무조건 전달해도 되는 것은 아닙니다.

피드백이 잘못된 원인을 지목할 때를 대비해 후보의 변경점과 출력 변화를 함께 봅니다. 사실 오류를 고치려다 답변을 모두 회피하는 지시가 생길 수 있습니다. 오류가 줄었더라도 유용한 답을 내는 비율이 크게 낮아졌다면 업무의 목적을 다시 확인해야 합니다.

가상 사례: 고객 문의 답변을 자동 튜닝한다면

온라인 서비스의 문의 초안을 만드는 프로그램을 가정해 보겠습니다. 입력은 고객 질문과 적용 가능한 정책 문서이고, 출력은 답변과 근거, 추가 확인이 필요한 항목입니다. 처음에는 실제 환불이나 계정 변경을 하지 않고 초안 생성만 다룬다고 범위를 정합니다.

 

기준선 프롬프트는 정책에서 확인한 사실만 사용하고, 필요한 정보가 없으면 추가 확인을 요청하도록 작성합니다. 이 상태에서 현재 오류를 기록합니다. 근거를 잘못 찾는지, 문서의 날짜를 놓치는지, 표현이 불친절한지와 출력 형식이 깨지는지를 구분합니다.

 

데이터에는 정상 문의뿐 아니라 정보 부족, 정책 충돌과 적용 기간이 다른 사례도 포함할 수 있습니다. 실제 분포를 반영하되 중요한 예외도 놓치지 않도록 구성합니다. 구체적인 수량과 분할 비율은 이용량과 오류 유형, 검토할 수 있는 자원에 따라 정해야 합니다.

 

평가에서는 답의 근거 일치, 적용 조건의 정확성, 미확인 정보의 표시와 사용자에게 필요한 다음 행동을 봅니다. 필드와 날짜 형식처럼 코드로 확인할 수 있는 부분은 자동 검사하고, 설명의 적절성은 기준을 갖춘 별도 판정으로 보완할 수 있습니다.

 

GEPA에는 개선에 사용할 자료와 평가 함수를 제공하고 탐색 예산을 정합니다. 후보를 비교할 때 평균 점수뿐 아니라 환불 문의, 계정 문의와 정보 부족 문의 같은 하위 유형별 결과를 확인합니다. 전체 평균이 좋아져도 특정 유형의 중요한 실패가 늘 수 있기 때문입니다.

 

최종 후보는 탐색에 사용하지 않은 자료로 평가합니다. 이전 프롬프트와 같은 입력에 대한 결과를 비교하고, 서로 다른 결과가 나온 사례를 사람이 읽습니다. 이 과정은 모델의 설명을 다시 믿기 위한 절차가 아니라 실제 변화의 성격을 확인하기 위한 검토입니다.

 

실제 도구를 쓰는 AI 에이전트에 적용한다면 비용과 영향의 범위를 더 명확히 해야 합니다. 반복 탐색 중 결제나 외부 발송을 실제로 실행하도록 두면 검증 자체가 운영 행동이 될 수 있습니다. 재현 가능한 테스트 환경과 대체 도구, 실행 권한을 구성한 뒤 평가하는 편이 적절합니다.

 

이 사례에서 자동화되는 것은 후보 생성과 반복 실행, 평가와 선택의 일부입니다. 어떤 정책을 적용하고 어떤 오류를 허용하지 않을지, 어느 결과를 운영에 넣을지는 여전히 제품의 결정입니다. 자동 최적화가 업무 책임까지 대신하는 것은 아닙니다.

프롬프트로 고칠 문제와 시스템으로 고칠 문제를 나누기

자동 튜닝을 시작하기 전에 실패 위치를 확인해야 합니다. 필요한 정책이 검색되지 않았다면 답변 지시만 고쳐도 해결되지 않을 수 있습니다. 검색 품질과 문서 관리가 문제인지, 주어진 근거를 모델이 잘못 해석하는지 구분해야 합니다.

 

날짜와 금액의 계산은 프로그램으로 처리하는 편이 명확할 수 있습니다. 출력 형식도 모델과 프레임워크가 제공하는 구조화 기능을 검토할 수 있습니다. 이런 문제를 모두 긴 자연어 규칙으로 해결하려 하면 프롬프트가 복잡해지고 유지보수도 어려워질 수 있습니다.

권한 검사와 금액 한도, 접근 가능한 고객 범위 같은 조건은 실행 계층에서 강제해야 합니다. 자동 생성된 프롬프트가 정책을 잘 따르는 듯 보인다고 서버의 검사를 생략할 근거가 생기는 것은 아닙니다. 지시와 강제 가능한 규칙은 서로 다른 역할을 합니다.

 

또 잘못된 원천 자료를 사용하는 경우에는 자료를 수정해야 합니다. 최신 정책과 폐기된 정책이 혼재한 상태를 지시문만으로 계속 보완하면 예외가 늘어납니다. 데이터의 버전과 적용 조건을 정리하는 작업이 최적화보다 먼저 필요할 수 있습니다.

 

따라서 튜닝 도구를 모든 실패에 적용하기보다 기준선에서 원인을 분류하세요. 입력 누락, 검색 누락, 해석 오류와 도구 실행 실패는 다른 개선이 필요합니다. 자동 최적화는 그중 자연어 지시의 변경이 영향을 줄 수 있는 부분을 탐색하는 도구로 사용하는 편이 실용적입니다.

점수 상승의 대가: 탐색 비용과 운영 비용을 함께 계산하기

자동 탐색에는 현재 프로그램 실행, 결과 평가와 리플렉션 호출이 들어갈 수 있습니다. 후보 수가 늘고 평가 데이터가 커지면 호출량도 늘어납니다. 한 번의 모델 요청 가격만 보고 전체 최적화 비용을 예상하기 어렵습니다.

 

비용은 크게 탐색할 때의 일회성 비용과 배포 후 매 요청에서 드는 운영 비용으로 나눠 볼 수 있습니다. 탐색을 통해 작은 실행 모델을 쓸 수 있게 되면 장기적으로 이득일 수 있습니다. 반대로 최종 프롬프트가 크게 길어지면 매 요청의 입력 비용과 지연이 늘 수 있습니다.

 

간단한 예로, 최적화 실험에 10만 원이 들고 운영 요청마다 실제로 2원을 절감한다고 가정하면 비용만으로는 5만 건에서 실험비를 회수합니다. 이는 설명용 산술이며 실제 API 요금이나 도입 성과가 아닙니다. 사람의 검토와 재작업, 인프라 비용까지 포함하면 판단은 달라질 수 있습니다.

 

지연도 함께 봐야 합니다. 프롬프트가 길어지거나 출력 설명이 늘어나면 사용자가 기다리는 시간이 달라질 수 있습니다. 점수만 높은 후보보다 품질 기준을 충족하면서 비용과 응답 시간을 만족하는 후보가 제품에 적합할 수 있습니다.

 

탐색 예산을 정하고 중단 조건을 마련하세요. 추가 호출에 비해 개선 폭이 작아졌는지, 반복 실행에서도 우위가 유지되는지와 실제로 바뀐 오류가 무엇인지 봅니다. 후보를 무한히 늘리는 것이 항상 더 나은 판단은 아닙니다.

모델이 바뀌면 기존 프롬프트도 다시 평가해야 한다

최적화된 프롬프트는 특정 모델과 데이터, 평가 기준 아래에서 선택된 결과입니다. 모델 제공자의 업데이트나 시스템 구성 변경이 있으면 이전 결과가 유지되는지 확인해야 합니다. “자동으로 찾았다”는 이유로 영구적인 최적값이 되는 것은 아닙니다.

 

원래의 기준선과 최적화 후보, 모듈 구성과 모델 버전, 평가 데이터의 버전과 생성 설정을 남기면 비교가 쉬워집니다. 실행 환경에서 사용하는 어댑터와 도구 정의가 바뀌었는지도 확인합니다. 프롬프트 문자열만 동일해도 실제 입력과 동작은 달라질 수 있습니다.

 

운영 반영은 품질 기준을 충족한 뒤 제한된 범위부터 검토할 수 있습니다. 답변만 만드는 기능과 실제 상태를 바꾸는 에이전트는 검증 강도가 다를 수 있습니다. 문제가 생겼을 때 이전 버전으로 되돌릴 수 있도록 결과물과 설정을 함께 보관하는 편이 좋습니다.

사용자의 새 요청과 정책 변경이 쌓이면 평가 자료도 갱신해야 합니다. 다만 새 자료를 최적화에 사용한 순간 이후에는 그것을 독립 시험지로 계속 취급하지 않습니다. 개선용 실패 사례와 최종 판단용 자료의 역할을 관리해야 합니다.

 

자동 최적화 루프의 목표는 사람이 영원히 보지 않는 시스템을 만드는 데만 있지 않습니다. 반복 탐색을 줄이고 사람이 평가 기준과 중요한 실패에 집중할 수 있게 하는 것도 충분한 가치입니다. 어디까지 자동화할지는 업무의 영향과 검증할 수 있는 범위를 기준으로 정해야 합니다.

프롬프트 자동 최적화 FAQ

Q. DSPy와 GEPA는 같은 것인가요?

DSPy는 LLM 프로그램의 구성과 평가·최적화를 지원하는 프레임워크이고 GEPA는 사용할 수 있는 최적화 방법 중 하나입니다. 프레임워크와 특정 탐색 알고리즘의 역할을 구분하면 설정과 결과를 이해하기 쉽습니다.

Q. GEPA를 쓰면 모델 파인튜닝이 필요 없나요?

작업에 따라 다릅니다. 자연어 지시를 바꾸는 최적화와 모델 가중치를 바꾸는 미세조정은 다른 접근입니다. 품질과 비용, 데이터와 운영 제약을 같은 조건으로 비교해야 하며 어느 한 방법이 모든 경우에 우월하다고 단정할 수 없습니다.

Q. 검증 데이터가 적어도 시작할 수 있나요?

작은 자료로 동작과 실패 유형을 탐색할 수는 있습니다. 다만 그 결과만으로 넓은 이용 환경의 성능을 주장하기 어렵습니다. 입력 분포의 대표성과 평가의 불확실성을 함께 보고, 독립 자료로 검증할 계획을 마련해야 합니다.

Q. 평가를 모두 LLM에게 맡기면 더 편하지 않나요?

자동화에는 도움이 될 수 있지만 판정 오류와 편향이 남습니다. 코드로 확인 가능한 조건과 정답 비교를 활용하고, 중요한 판단은 사람의 검토와 대조하는 편이 좋습니다. 평가자의 점수가 서비스의 정답과 동일한 것은 아닙니다.

Q. 점수가 높아졌는데 답변이 길어졌다면 성공인가요?

업무 목표에 따라 판단해야 합니다. 길이 증가로 필요한 근거가 보완될 수도 있고 불필요한 설명이 늘 수도 있습니다. 품질과 비용, 지연과 사용성을 함께 평가하고 프롬프트의 문자 수를 요금 변화와 바로 동일시하지 않아야 합니다.

Q. AI 에이전트의 도구 선택도 최적화할 수 있나요?

여러 프롬프트를 포함한 프로그램과 실행 궤적을 최적화 대상으로 삼을 수 있습니다. 다만 실제 행동의 성공과 권한, 중복 실행과 실패 복구를 평가할 환경이 필요합니다. 지시문 점수만으로 외부 시스템에서의 실행 안전성이 확인되는 것은 아닙니다.

프롬프트의 미래는 문장보다 평가 설계에 가까워진다

DSPy와 GEPA가 보여 주는 변화는 프롬프트를 감으로 고치는 반복을 체계적인 실험으로 바꿀 수 있다는 점입니다. 실행 결과와 구체적인 피드백을 활용하면 사람이 예상하지 못한 지시 구조를 탐색할 수 있고, 모델 변경에 맞춘 재평가도 더 쉽게 구성할 수 있습니다.

 

동시에 자동 최적화는 평가의 빈틈도 빠르게 확대할 수 있습니다. 형식이 맞는 답과 근거가 맞는 답, 검증 자료에 강한 후보와 새로운 사용자에게 유용한 후보는 다를 수 있습니다. 점수의 의미를 설명할 수 있어야 개선의 의미도 설명할 수 있습니다.

 

시작하려는 팀이라면 작업 하나와 기준선을 정하고, 실패를 분류한 뒤, 지시를 바꾸는 것으로 개선할 수 있는 부분부터 탐색해 보세요. 데이터 분리와 평가 함수를 준비하고 독립 검증, 비용 비교와 운영 판단을 연결하면 자동 튜닝의 효과를 더 정확하게 볼 수 있습니다.

AI가 프롬프트를 작성하는 능력은 계속 발전할 수 있습니다. 하지만 무엇을 좋은 결과로 인정할지 정하는 일은 제품의 핵심 설계입니다. 자동 최적화를 잘 활용하는 팀은 가장 많은 후보를 만든 팀이 아니라, 높아진 점수가 실제 사용자 가치로 이어졌는지 확인하는 팀일 것입니다.

참고 자료와 조사한 한국 기술 블로그

DSPy 공식 문서, Prompt Optimizing with GEPA. 리플렉션 모델과 평가 피드백, 탐색 예산, trainset·valset·test set의 역할 구분을 확인했습니다.

 

https://dspy.ai/current/getting-started/gepa-optimization/

GEPA optimization - DSPy

 

DSPy 공식 문서, Building metrics for evaluation and optimization. 기준선과 평가 함수, 정답 비교·규칙 검사·LLM 평가의 접근을 참고했습니다.

 

https://dspy.ai/current/getting-started/metrics/

Metrics - DSPy

 

Agrawal 외, GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning. arXiv:2507.19457, 최초 공개 2025년 7월 25일, 확인한 v2 수정일 2026년 2월 14일. 공개 초록에서 실행 궤적·리플렉션과 후보 결합의 개념, 비교 실험의 범위를 확인했습니다.

 

https://arxiv.org/abs/2507.19457

GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning

 

LY Corporation Tech Blog, 「프롬프트 튜닝을 수작업에서 AI 튜닝으로: 유전 알고리즘 기반 자동 최적화와 고속화」, 한국어 페이지 표기 2026년 6월 23일. 문제→방법→운영 설계→성과와 제약의 구성을 조사하고, 조정 시간과 프롬프트 길이 변화는 저자의 사례 보고로 구분해 인용했습니다.

 

https://techblog.lycorp.co.jp/ko/techverse2026-60

프롬프트 튜닝을 수작업에서 AI 튜닝으로: 유전 알고리즘 기반 자동 최적화와 고속화

 

CELL AI DEVLOG, 「DSPy + GEPA 로 프롬프트 자동 생성과 개선해보기」, 2026년 7월 28일. 작은 질의응답 실습에서 후보 변경과 출력 비교를 설명하는 방식을 조사했습니다. 해당 글의 점수와 모델 구성은 독립적으로 재현한 결과가 아니므로 보편적인 성능 근거로 사용하지 않았습니다.

 

https://cell-devlog.tistory.com/538

DSPy + GEPA 로 프롬프트 자동 생성과 개선해보기

 

자료 확인일: 2026년 10월 21일. 본문은 공개 자료를 바탕으로 구성한 기술 해설입니다. 실제 사용 시에는 채택한 DSPy 버전과 최적화기의 현재 API, 평가 함수 계약을 확인해야 합니다.