DSPy(Declarative Self-improving Python) 찍먹해보기

최근 LLM 개발 흐름을 보면
“프롬프트 엔지니어링 → 파이프라인 설계 → 자동 개선”
이라는 방향으로 점점 진화하고 있다.

이런 흐름을 대표하는 도구 중 하나가 DSPy(Declarative Self-improving Python) 이다.

DSPy는 어떤 프레임워크인가?

DSPy는 스탠포드・애플・워싱턴대 연구자들이 함께 개발한 프레임워크로,
기본적인 개념과 구조는 아래 논문에서 제시된다.

DSPy: Compilers for Self-Improving Systems with Foundation Models
(Stanford, 2024)
https://arxiv.org/pdf/2310.03714

 

논문의 핵심 아이디어는 다음과 같다.

• 프롬프트를 “문자열”로 직접 쓰는 방식은 유지보수가 어렵다
• 대신 입력/출력 구조(Signature) 를 코드로 정의하고
• 여러 LLM 단계(Module)를 파이프라인처럼 조립하고
• metric 기반으로 few-shot 예제/지시문을 자동 최적화하면
  시스템 자체가 점점 개선되는 구조를 만들 수 있다

따라서 DSPy는 대규모 LLM 시스템을 구축할 때
“프롬프트 엔지니어링을 코드화하고 자동화하는 방식”을 제안하는 도구라고 볼 수 있다.

내가 DSPy에 관심을 가지게 된 이유

나는 지금 파인튜닝용 학습데이터셋(RAFT 스타일의 SFT 데이터셋) 을 만드는 중이고, 문맥 기반으로 reasoning·질문을 자동 생성하는 과정에서 프롬프트 실험이 반복되는 점이 늘 불편했다.

그래서 다음과 같은 기대를 갖고 DSPy를 살펴보기 시작했다.

• few-shot 예제 자동 최적화 기능이
  데이터 생성 품질을 높이는 데 도움이 되지 않을까?
• reasoning 스타일이나 질문 품질을
  metric 기반으로 선택할 수 있지 않을까?

그런 관점에서 DSPy를 가볍게 실습해보며
어떤 점이 맞고 어떤 점이 맞지 않는지 직접 확인해봤다.

1. DSPy 첫 실습

아래 코드는 DSPy의 기본 구성인
Signature → Module → Few-shot 최적화 → 실행
을 경험해보기 위해 만든 아주 간단한 QA 예제다.

 

import dspy
from dspy.teleprompt import BootstrapFewShot
import os
from dotenv import load_dotenv

load_dotenv()

lm = dspy.LM('openai/gpt-4o-mini')
dspy.settings.configure(lm=lm)

class BasicQA(dspy.Signature):
    """질문에 대해 간결하고 명확한 단답형 답변을 하세요."""
    question = dspy.InputField(desc="사용자의 질문")
    answer = dspy.OutputField(desc="짧고 명확한 대답")

generate_answer = dspy.ChainOfThought(BasicQA)

train_examples = [
    dspy.Example(question="대한민국의 수도는 어디인가요?", answer="서울").with_inputs('question'),
    dspy.Example(question="1더하기 1은?", answer="2").with_inputs('question'),
    dspy.Example(question="사과의 색깔은?", answer="빨간색").with_inputs('question'),
    dspy.Example(question="지구에서 가장 큰 바다는?", answer="태평양").with_inputs('question'),
]

print("프롬프트 최적화 중 ...")
teleprompter = BootstrapFewShot(metric=dspy.evaluate.answer_exact_match)
compiled_program = teleprompter.compile(generate_answer, trainset=train_examples)
print("컴파일 완료\n")

my_question = "미국의 수도는 어디인가요?"
pred = compiled_program(question=my_question)

print(f"Q:{my_question}")
print(pred.answer)

print("-" * 30)
print("생성된 Reasoning:")
print(pred.reasoning)

lm.inspect_history(n=1)

실행해보면 DSPy가 내부적으로 few-shot 프롬프트를 구성하고,
학습 예제와 metric을 기반으로 가장 성능이 잘 나오는 형태를 선택한다.

2. 실습하면서 느낀 DSPy의 장단점

장점

● Signature 기반 구조

입력/출력 규칙이 코드로 명확하게 정리된다.
여러 LLM 모듈을 조합해 파이프라인을 만들 때 구조적 안정성이 생긴다.

● 프롬프트 자동 최적화

BootstrapFewShot을 활용하면
매번 프롬프트를 수동으로 고치지 않아도 된다.

● 디버깅을 위한 LM 호출 이력 제공

inspect_history()로 실제 호출된 메시지를 확인할 수 있어
프롬프트 흐름 파악이 조금 더 수월하다.

 

아쉬운 점 (특히 데이터 생성 관점에서)

나는 애초에 DSPy를 파인튜닝용 데이터셋 생성기로 활용하려는 목적이 있었는데,
직접 써보면서 이 부분은 맞는 방향이 아니라는 결론을 내렸다.

● 데이터 생성에는 “일관성”이 중요한데 DSPy는 최적화 과정에서 흔들릴 수 있음

• reasoning 길이
• 문장 스타일
• 특정 형식을 강제하는 부분
  이런 세밀한 통제가 어렵다.

학습데이터는 출력 형태가 정확해야 하기 때문에
오히려 자동 최적화가 방해가 될 때도 있다.

● 프롬프트가 내부적으로 최적화되지만 잘 드러나지 않는다

데이터 생성용 프롬프트는 “명확히 보이고, 계속 같은 형태로 유지되어야” 한다.
DSPy는 최적화 과정이 내부적으로 처리되기 때문에 이와 목적이 충돌한다.

● 단일 템플릿 반복 호출 작업에는 수동 프롬프트 튜닝이 더 단순하고 효율적

데이터 생성 작업에서 DSPy를 쓰기 시작하면 오히려 구조가 더 복잡해지는 느낌이었다.

3. DSPy는 어떤 때 쓰는 게 좋은가?

실습을 통해 느낀 DSPy의 적합한 사용처는 아래와 같다.

DSPy가 어울리는 경우

• 여러 단계로 이루어진 복잡한 LLM 파이프라인
• retrieval → reasoning → answer 같은 구조
• metric 기반으로 프롬프트 조합을 자동 실험하고 싶을 때
• 프롬프트를 코드로 관리하고 싶을 때

DSPy가 굳이 필요 없는 경우

• SFT/RAFT 파인튜닝용 학습 데이터 생성
• 출력 형식을 엄격하게 강제해야 하는 작업
• 아주 간단한 단일 프롬프트 기반 태스크

결국 DSPy는 데이터 생성기라기보다,
LLM을 “시스템 단위”로 설계할 때 나타나는 복잡성을 줄여주는 프레임워크에 가깝다.

3. DSPy는 어떤 때 쓰는 게 좋은가?

실습을 통해 느낀 DSPy의 적합한 용도는 아래와 같다.

DSPy가 어울리는 경우

• 여러 단계로 이루어진 복잡한 LLM 파이프라인
• retrieval → reasoning → answer 같은 구조
• metric 기반으로 프롬프트 조합을 자동 실험하고 싶을 때
• 프롬프트를 코드로 관리하고 싶을 때

DSPy가 굳이 필요 없는 경우

• 파인튜닝용 학습 데이터 생성
• 출력 형식을 엄격하게 강제해야 하는 작업
• 아주 간단한 단일 프롬프트 기반 태스크

결국 DSPy는 데이터 생성 용도에 적합하기보다,
LLM을 “시스템 단위”로 설계할 때 나타나는 복잡성을 줄여주는 프레임워크에 가깝다.

 

4. 정리

DSPy는 “프롬프트 엔지니어링을 코드화하고 자동화한다”는 점에서 흥미로운 도구였고,

Signature 기반 구조는 파이프라인 구성에 분명 장점이 있었다.

다만, 내가 처음 기대했던 학습데이터셋 생성 작업에는 오히려 수동 프롬프트 엔지니어링을 하는 방식이 더 적합하다는 것도 느꼈다.

 

즉, DSPy는

• 간단한 작업보다는
• 규모 있는 LLM 시스템 관리에 강점이 있는 도구라는 점을 확인할 수 있었다.

더 복잡한 파이프라인을 다루게 된다면 DSPy를 다시 활용해볼 가능성은 충분히 있다고 생각한다.

---

 

Reference

1.  https://arxiv.org/pdf/2310.03714

2. https://blog.kbanknow.com/106

프롬프팅 대신 프로그래밍 - DSPy를 활용한 프롬프트 자동 최적화