LLM 앱에서 프롬프트는 코드만큼 중요하지만, 코드만큼 체계적으로 관리되지는 못했습니다. 모델을 바꾸면 잘 작동하던 프롬프트가 흔들리고, 개발자는 다시 수작업으로 문구를 고칩니다. DSPy가 주목받는 이유는 이 과정을 감이 아니라 데이터, 메트릭, 최적화의 문제로 바꿔주기 때문입니다.
DSPy는 프롬프트 개선을 실험으로 바꾼다
DSPy는 언어 모델용 프롬프트를 알고리즘 방식으로 최적화하도록 설계된 프레임워크입니다.1 핵심은 프롬프트 문장을 직접 오래 다듬는 것이 아니라, 입력과 출력의 구조를 정의하고, 평가 데이터와 메트릭을 통해 더 나은 프롬프트를 찾는 데 있습니다.
이는 전통적인 머신러닝의 사고방식을 프롬프트 개선에 적용하는 접근입니다. 훈련 데이터, 평가 데이터, 메트릭, 최적화 같은 개념을 사용해 프롬프트가 실제로 좋아졌는지 확인합니다.1 특히 LLM 애플리케이션에서는 모델을 바꾸면 기존 프롬프트도 함께 조정해야 하는 경우가 많기 때문에, 이런 반복 가능한 개선 구조가 중요해집니다.1
Haystack의 DSPy 예제는 이 흐름을 잘 보여줍니다. RAG 파이프라인에서 “정확하고 간결한 답변”을 목표로 삼고, DSPy 프로그램을 작성한 뒤, 데이터와 메트릭을 정의해 프롬프트를 최적화합니다.1 예제의 초기 파이프라인은 InMemoryBM25Retriever, ChatPromptBuilder, OpenAIChatGenerator로 구성되며, 검색기는 BM25 기반으로 상위 3개 문서를 반환하도록 설정됩니다.1 사용 데이터는 PubMedQA_instruction 데이터셋의 첫 1000개 행입니다.1
중요한 점은 DSPy가 “좋은 프롬프트를 자동으로 써주는 도구”라기보다, 특정 모델과 작업에 맞는 프롬프트를 체계적으로 찾게 해주는 프레임워크라는 것입니다.1
Datasette Agent 사례: 실제 환경에서 평가해야 보이는 문제
Datasette Agent 실험은 DSPy를 읽기 전용 SQL 질의응답 시스템 프롬프트 평가와 개선에 적용한 사례입니다.2 이 사례가 흥미로운 이유는 평가가 추상적인 벤치마크가 아니라 실제 실행 환경에 가깝게 구성됐기 때문입니다.
평가 하니스에서 DSPy 에이전트는 Datasette Agent의 실제 도구 구현과 프롬프트를 호출했고, 평가는 라이브 인프로세스 Datasette를 대상으로 수행됐습니다.2 또한 자동 생성된 골드스탠더드 데이터셋과 커스텀 메트릭을 사용했습니다.2 테스트에는 GPT-4.1 mini와 GPT-4.1 nano가 사용됐습니다.2
이런 구성이 중요한 이유는 프롬프트의 문제가 문장만 읽어서는 잘 드러나지 않기 때문입니다. 예를 들어 기존 프롬프트는 이미 정보를 알고 있다면 describe_table을 호출하지 말라고 지시했습니다. 하지만 스키마 목록에는 테이블 이름만 있고 컬럼 이름은 없었습니다. 결과적으로 모델은 컬럼명을 추측했고, SQL 오류가 난 뒤 다시 시도하는 흐름이 발생했습니다.2
즉, 프롬프트는 그 자체로만 평가할 수 없습니다. 실제 도구가 어떤 정보를 제공하는지, 모델이 어떤 순서로 도구를 호출하는지, 실패했을 때 어떻게 복구하는지까지 함께 봐야 합니다.
최적화보다 먼저 필요한 것은 좋은 평가다
Datasette Agent 사례가 주는 가장 실용적인 교훈은 “DSPy를 쓰면 프롬프트가 자동으로 좋아진다”가 아닙니다. 핵심은 프롬프트 개선을 측정 가능한 실험으로 만들 수 있다는 점입니다.
다만 측정 구조가 부실하면 최적화도 잘못된 방향으로 갈 수 있습니다. Datasette 실험에서도 일부 실패는 모델 자체의 문제가 아니라 채점 기준의 문제였습니다.2 따라서 프롬프트를 최적화하기 전에 다음 질문을 먼저 점검해야 합니다.
실제 운영 환경과 비슷한 조건에서 평가하고 있는가?
모델이 호출하는 도구와 프롬프트가 실제 구현과 일치하는가?
골드 데이터가 작업의 성공 기준을 충분히 반영하는가?
커스텀 메트릭이 원하는 행동을 제대로 측정하는가?
훈련 점수뿐 아니라 보류 테스트에서도 성능이 유지되는가?
마지막 질문은 특히 중요합니다. Datasette Agent 실험에서 GPT-4.1 nano는 GEPA 최적화 후 훈련 점수는 올랐지만, 보류 테스트에서는 오히려 떨어졌습니다.2 작은 데이터와 강한 기준선에서는 프롬프트 최적화도 과적합될 수 있다는 뜻입니다.
DSPy를 적용할 때의 현실적인 기준
DSPy는 프롬프트 엔지니어링을 없애는 도구가 아닙니다. 오히려 프롬프트 엔지니어링을 더 공학적인 작업으로 바꿉니다. 감으로 문장을 고치는 대신, 목표를 정의하고, 데이터를 만들고, 메트릭을 설계하고, 실제 시스템에서 평가하게 만듭니다.
운영 중인 LLM 앱에 DSPy를 적용하려면 먼저 “좋아 보이는 프롬프트”가 아니라 “측정 가능한 프롬프트”를 목표로 삼아야 합니다. 모델을 바꿀 때마다 프롬프트가 흔들리는 팀이라면, DSPy의 가치는 자동화 자체보다 반복 가능한 평가와 개선 루프를 만드는 데 있습니다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.