Automatic Prompt Engineer (APE)는 언어 모델이 주어진 작업에 대해 최적의 프롬프트를 작성, 테스트 및 선택할 수 있게 하여, 과거 시행착오에 의존하던 기술을 반복 가능한 데이터 기반 탐색으로 전환합니다.
프롬프트 작성이 병목 현상이 된 이유
프롬프트 엔지니어링—모델에게 무엇을 해야 할지 알려주는 정확한 문구를 만드는 작업—은 오랫동안 직관과 운의 조합이었습니다. 실무자들은 단어를 수정하거나 문구를 바꾸고, 모델을 실행한 뒤 결과가 "적절해 보이면" 멈춥니다. 이러한 방식은 시간이 오래 걸리고 엔지니어의 상상력에 의존하며, 성능의 한계를 만듭니다. 실제 서비스 환경에서는 개발 주기가 길어지고, 결과가 불안정하며, 출시 후에야 드러나는 숨겨진 비용이 발생함을 의미합니다.
APE의 3단계 워크플로우
APE는 프롬프트 생성을 탐색 문제로 취급합니다. 사용자가 소수의 입출력 예시 세트를 제공하면, 시스템은 다음 세 가지 자동화 단계를 실행합니다.
- 제안(Propose) – 모델이 예시를 스캔하여 "반대로 답변하라" 또는 "반의어를 작성하라"와 같은 일련의 후보 지침을 생성합니다.
- 점수 산정(Score) – 시스템은 각 후보를 학습에 사용되지 않은 별도의 예시 세트에 실행하여, 예상 출력과 일치하는 답변의 수를 계산하고 가공되지 않은 정확도 수치를 산출합니다. 이 단계에는 인간의 판단이 개입하지 않습니다.
- 선택(Select) – 정확도가 가장 높은 지침이 최종 프롬프트가 됩니다.
이 루프는 반복될 수 있습니다. 선정된 프롬프트는 새로운 시드(seed)가 되고, 모델은 그 변형들을 제안합니다. 보고된 사례에 따르면, 83%의 점수를 기록했던 일반적인 지침이 테스트 세트에서 100%를 달성하는 버전으로 개선되었습니다.
이 방식이 사람보다 강력한 이유
- 커버리지(Coverage) – LLM은 수십 가지의 문구 대안을 몇 초 만에 만들어내며, 이는 사람이 테스트할 수 있는 양보다 훨씬 많습니다.
- 객관성(Objectivity) – 선택은 문구가 얼마나 세련되었는가가 아니라 측정 가능한 정확도에 달려 있습니다. 교과서적인 지침이라 할지라도, 모델이 더 잘 이해하는 간결하고 생소한 형태의 변형에 밀릴 수 있습니다.
점수 산정 기준은 사용자로부터 제공되므로(보통 정확한 일치 확인 또는 유닛 테스트), 코드 생성부터 감성 분석에 이르기까지 모든 다운스트림 요구 사항에 맞춰 시스템을 조정할 수 있습니다.
자동화의 대가
트레이드오프는 컴퓨팅 자원입니다. 모든 후보를 점수화하려면 많은 모델 호출이 필요하므로, 개발 단계에서 상당한 양의 API 사용량이 소모됩니다. APE는 이 비용을 일회성 투자로 간주합니다. 최적의 프롬프트가 식별되면 추가 비용 없이 영구적으로 재사용할 수 있기 때문입니다.
또한 두 가지 전제 조건이 도입을 제한합니다.
- 레이블이 지정된 예시(Labeled examples) – 시스템에는 대표성을 띠는 입력값과 정답 출력값 세트가 필요합니다.
- 점수 산정 함수(Scoring function) – 사용자는 정확한 문자열 일치, 수치 허용 오차 또는 사용자 정의 검증기 등 해당 작업에서 "정확함"이 무엇을 의미하는지 정의해야 합니다.
발생할 수 있는 문제점
초기 예시 세트가 너무 적거나 대표성이 없는 경우, 선택된 프롬프트가 과적합(overfit)되어 실제 환경에서 제대로 작동하지 않을 수 있습니다.
향후 주목할 점
이 도구는 대안을 제시합니다. 몇 가지 예시를 입력하고 모델이 반복하게 하여, 시스템이 시도한 것 중 가장 높은 순위를 기록한 프롬프트를 얻는 방식입니다. 데모는 원문 발표의 링크에서 확인할 수 있으며, 학습 커뮤니티는 Telegram에서 운영되고 있습니다.
핵심 요약: 프롬프트 엔지니어링의 자동화는 추측을 측정 가능한 성능으로 바꿔주지만, 사전에 데이터, 컴퓨팅 자원, 그리고 명확한 성공 기준이 필요합니다.