DSPy로 LLM 프롬프트 자동 최적화하기

목차

1. 개요
2. DSPy의 설계 철학과 기존 방식의 한계
3. 핵심 구성 요소 — 시그니처, 모듈, 프로그램
4. 컴파일러와 최적화 알고리즘 작동 원리
5. 실전 적용 — RAG 파이프라인 최적화
6. 성능 특성과 대안 기술 비교
7. 운영 환경 적용 시 고려사항
8. 맺음말

개요

문제 배경

LLM을 실제 프로젝트에 적용할 때 가장 많은 시간이 들어가는 작업은 모델 선택이나 파인튜닝이 아닙니다. 의외로 프롬프트 튜닝입니다. "더 자세히 설명해라", "단계적으로 생각해라", "JSON 형식으로 출력해라" 같은 문구를 조금씩 바꿔 가며 원하는 출력을 얻으려는 반복 과정이 전체 개발 공수의 상당 부분을 차지합니다. 더 큰 문제는 이 작업의 결과물인 프롬프트가 특정 모델, 특정 데이터 분포에 강하게 종속된다는 점입니다. 모델을 교체하거나 입력 분포가 바뀌면 처음부터 다시 튜닝해야 합니다.

DSPy(Declarative Self-improving Python)는 스탠퍼드 대학교 NLP 그룹이 공개한 프레임워크로, 이 문제를 프로그래밍 방식으로 해결합니다. 개발자가 태스크의 입출력 명세와 평가 지표만 정의하면, DSPy의 컴파일러가 프롬프트와 퓨샷 예제를 자동으로 생성·최적화합니다. 이는 PyTorch가 역전파를 통해 가중치를 최적화하는 방식과 개념적으로 유사합니다. 이 글에서는 DSPy의 작동 원리부터 실제 RAG 파이프라인에 적용하는 방법, 그리고 운영 환경에서 마주치는 현실적인 제약까지 다룹니다.

기존 방식의 한계

수동 프롬프트 엔지니어링이 갖는 근본적인 문제는 재현성 부재입니다. 프롬프트가 왜 잘 동작하는지 설명하기 어렵고, 따라서 수정이나 개선도 경험적 직관에 의존할 수밖에 없습니다. LangChain이나 LlamaIndex 같은 오케스트레이션 프레임워크는 파이프라인 구성을 편하게 해 주지만, 프롬프트 자체를 최적화하는 기능은 제공하지 않습니다. 결국 개발자가 "지시문을 어떻게 쓰느냐"와 "어떤 예제를 퓨샷으로 넣느냐"를 여전히 수작업으로 결정해야 합니다.

DSPy의 설계 철학과 기존 방식의 한계

선언적 프로그래밍 패러다임 전환

DSPy의 핵심 아이디어는 LLM 파이프라인을 가중치가 있는 신경망처럼 취급하는 것입니다. 파이프라인을 구성하는 각 모듈은 학습 가능한 파라미터(프롬프트 지시문, 퓨샷 예제)를 가지고 있고, 컴파일 단계에서 이 파라미터들이 최적화됩니다. 개발자는 "어떻게 최적화할 것인지"가 아니라 "무엇을 원하는지"만 선언합니다.

이 패러다임 전환은 유지보수성과 이식성에서 큰 차이를 만들어 냅니다. 프롬프트를 코드베이스 곳곳에 하드코딩하는 대신, DSPy 프로그램은 구조화된 모듈의 조합으로 표현됩니다. 모델을 gpt-4o에서 claude-3-5-sonnet으로 교체할 때 코드를 수정할 필요가 없고, 재컴파일만 하면 새 모델에 맞는 최적 프롬프트가 자동으로 생성됩니다. 동일한 프로그램 구조로 서로 다른 모델에 최적화된 두 버전을 생성하고 A/B 테스트를 할 수도 있습니다.

수동 접근법에서는 평가와 수정이 반복되며 개발자 판단에 전적으로 의존합니다. DSPy는 이 루프를 컴파일러가 자동으로 수행합니다.

프롬프트와 코드의 결합 문제

기존 LLM 애플리케이션 개발에서 프롬프트는 코드 속에 문자열로 묻혀 있습니다. 이는 몇 가지 구조적 문제를 만듭니다. 첫째, 프롬프트의 변경 이력을 추적하기 어렵습니다. Git으로 버전 관리는 할 수 있지만, "왜 이 문구가 추가되었는지" 같은 의도는 기록되지 않습니다. 둘째, 파이프라인의 어느 단계에서 성능이 저하되는지 진단하기 어렵습니다. 여러 프롬프트가 연결된 복잡한 파이프라인에서 오류가 발생하면 전체를 다시 검토해야 합니다.

DSPy는 프롬프트를 시그니처라는 추상화로 분리합니다. 시그니처는 모듈의 입출력 명세를 선언하는 구조체로, 실제 프롬프트 문자열과 분리되어 있습니다. 컴파일러가 시그니처를 기반으로 프롬프트를 생성하므로, 개발자는 프롬프트 문자열 대신 태스크의 의미론적 명세에 집중할 수 있습니다.

핵심 구성 요소 — 시그니처, 모듈, 프로그램

시그니처: 태스크 명세의 선언

**시그니처(Signature)**는 DSPy에서 가장 기초적인 빌딩 블록입니다. 모듈이 LLM에게 무엇을 입력받아 무엇을 출력해야 하는지 선언하는 구조체입니다. 시그니처는 짧은 문자열 형식으로 정의할 수도 있고, 파이썬 클래스로 상세히 정의할 수도 있습니다. 짧은 형식인 "question -> answer"는 "질문을 받아서 답변을 생성하라"는 뜻이고, 클래스 형식에서는 각 필드에 타입 힌트와 설명을 추가해 더 구체적인 명세를 표현할 수 있습니다.

시그니처의 핵심 역할은 컴파일러에게 맥락을 제공하는 것입니다. 필드 이름과 설명이 LLM이 태스크를 어떻게 이해해야 하는지 안내하고, 컴파일러는 이 정보를 활용해 적절한 지시문을 자동으로 생성합니다. 예를 들어 context: str = dspy.InputField(desc="관련 문서 내용") 이라고 정의하면, 컴파일러는 이 필드가 RAG의 검색 결과임을 이해하고 그에 맞는 지시문을 생성합니다.

시그니처에서 출발해 컴파일된 프로그램이 생성되기까지의 계층 구조입니다. 각 레이어는 명확한 역할 분리를 가집니다.

모듈: 추론 패턴의 구현체

**모듈(Module)**은 시그니처를 구현하는 컴포넌트입니다. DSPy는 다양한 추론 패턴을 위한 내장 모듈을 제공합니다. dspy.Predict는 가장 기본적인 모듈로 단순 입출력 변환을 수행합니다. dspy.ChainOfThought는 답변 전에 중간 추론 과정을 생성하도록 유도합니다. dspy.ReAct는 에이전트 패턴으로 도구 호출과 관찰을 반복합니다. dspy.MultiChainComparison은 여러 추론 경로를 병렬로 실행하고 비교합니다.

중요한 점은 모듈이 학습 가능한 파라미터를 가진다는 것입니다. ChainOfThought의 경우, 어떤 퓨샷 예제를 포함할지, 중간 추론 과정을 어떤 방식으로 유도할지가 컴파일 시 최적화됩니다. 개발자는 어떤 추론 패턴이 이 태스크에 적합한지만 선택하고, 세부 튜닝은 컴파일러에게 위임합니다.

추론 복잡도에 따른 모듈 선택 기준입니다. 태스크 특성에 맞는 모듈을 선택하는 것이 최적화 효율을 결정합니다.

프로그램: 모듈의 조합과 데이터 흐름

**프로그램(Program)**은 여러 모듈을 조합해 복잡한 태스크를 처리하는 클래스입니다. dspy.Module을 상속받고 __init__에서 모듈들을 선언한 뒤 forward 메서드에서 데이터 흐름을 정의합니다. PyTorch의 nn.Module과 구조가 동일하며, 이 유사성은 의도적 설계입니다.

프로그램 내에서 모듈은 파이썬 코드로 자유롭게 연결할 수 있습니다. 조건 분기, 반복, 병렬 실행이 모두 가능합니다. DSPy는 실행 중에 각 모듈의 호출 이력을 추적하고, 이 정보가 컴파일 시 최적화에 활용됩니다. 복잡한 파이프라인에서도 어느 모듈이 성능 병목인지 식별할 수 있는 이유가 이 추적 메커니즘 덕분입니다.

컴파일러와 최적화 알고리즘 작동 원리

컴파일 프로세스의 전체 흐름

DSPy의 컴파일은 전통적인 소프트웨어 컴파일과 다릅니다. 입력은 프로그램 구조, 소수의 학습용 예제, 평가 메트릭입니다. 출력은 최적화된 파라미터(프롬프트 지시문, 퓨샷 예제 집합)가 채워진 프로그램입니다. 이 과정이 텔레프롬프트(teleprompter) 또는 공식 명칭으로 **옵티마이저(Optimizer)**가 수행하는 작업입니다.

컴파일 과정의 첫 번째 단계는 **부트스트랩(Bootstrap)**입니다. 옵티마이저가 제공된 학습 예제로 프로그램을 실행하면서 중간 단계의 입출력 쌍을 수집합니다. ChainOfThought를 사용하는 경우, 어떤 추론 과정이 올바른 최종 답변으로 이어졌는지 기록됩니다. 이 기록이 퓨샷 예제 후보 풀이 됩니다.

컴파일은 단순히 예제를 넣는 것이 아니라, 성공한 실행 흔적을 분석해 최적의 퓨샷 조합을 찾는 탐색 과정입니다.

주요 옵티마이저 알고리즘

DSPy는 여러 옵티마이저를 제공하며, 각각의 적용 조건이 다릅니다.

BootstrapFewShot은 가장 기본적인 옵티마이저입니다. 학습 예제로 프로그램을 실행하고, 평가 지표를 통과한 실행의 흔적을 퓨샷 예제로 사용합니다. 구현이 단순하고 LLM 호출 횟수가 적어 비용이 낮습니다. 학습 데이터가 20~50개 수준으로 적을 때도 잘 동작합니다. 단, 프롬프트 지시문 자체는 최적화하지 않고 퓨샷 예제 선택에만 집중한다는 제한이 있습니다.

**MIPRO(Multi-prompt Instruction PRoposal Optimizer)**는 베이지안 최적화를 사용해 프롬프트 지시문까지 함께 최적화합니다. LLM에게 더 나은 지시문 후보를 제안하게 하고, 베이지안 최적화로 후보 조합을 효율적으로 탐색합니다. BootstrapFewShot보다 훨씬 많은 LLM 호출이 필요하지만, 지시문까지 최적화해 성능 향상 폭이 큽니다.

BootstrapFinetune은 최적화된 퓨샷 예제와 추론 흔적을 실제 파인튜닝 데이터로 변환해 소규모 모델을 파인튜닝합니다. 추론 비용을 크게 낮출 수 있어 운영 비용이 중요한 경우에 효과적입니다.

평가 메트릭의 역할

컴파일 품질은 평가 메트릭에 완전히 의존합니다. 메트릭은 파이썬 함수로 (example, prediction, trace=None) -> float 형태를 가집니다. 반환값은 0~1 사이의 점수이거나 불리언입니다. 메트릭이 태스크의 실제 성공 기준을 얼마나 잘 반영하느냐가 컴파일 결과를 결정합니다.

메트릭을 잘못 설계하면 컴파일러가 메트릭을 해킹하는 방향으로 최적화될 수 있습니다. 예를 들어 정답 포함 여부만 확인하면 답변 전체가 아닌 특정 토큰만 맞추는 방향으로 최적화될 수 있습니다.

메트릭 설계에서 흔히 사용하는 전략은 LLM-as-a-judge 패턴입니다. 강력한 모델(예: GPT-4o)을 평가자로 사용해 생성된 답변의 품질을 채점하도록 합니다. 이 방식은 정밀도 지표를 만들기 어려운 생성 태스크에 특히 유용하지만, 평가 비용이 증가하는 트레이드오프가 있습니다.

실전 적용 — RAG 파이프라인 최적화

RAG 파이프라인 설계

RAG(Retrieval-Augmented Generation)는 DSPy를 적용하기에 가장 효과적인 태스크 중 하나입니다. 검색 단계와 생성 단계 각각에 최적화가 필요하고, 두 단계를 통합하는 방식도 중요하기 때문입니다. 전통적인 RAG 구현에서는 검색 쿼리를 어떻게 구성할지, 검색된 문서를 컨텍스트로 어떻게 제시할지, 답변 생성 지시문을 어떻게 작성할지를 모두 수동으로 결정합니다.

DSPy로 구현하면 이 세 가지 결정을 모두 컴파일러에게 위임할 수 있습니다. 특히 멀티홉 RAG처럼 여러 번 검색하며 답변을 구성하는 복잡한 파이프라인에서 DSPy의 장점이 극대화됩니다. 각 검색 단계의 쿼리를 이전 단계의 결과를 고려해 자동으로 최적화하기 때문입니다.

멀티홉 RAG에서 DSPy는 각 ChainOfThought 모듈의 퓨샷 예제와 지시문을 독립적으로 최적화합니다.

다음은 기본 RAG 파이프라인을 DSPy로 구현하는 예제입니다. 검색 모듈과 답변 생성 모듈을 조합하는 구조를 보여 줍니다.

import dspy

# LLM과 검색기 설정
lm = dspy.LM("openai/gpt-4o-mini", api_key="...")
dspy.configure(lm=lm)

# 시그니처 정의: 질문 + 컨텍스트 → 답변
class GenerateAnswer(dspy.Signature):
    """제공된 컨텍스트를 기반으로 질문에 답변합니다."""
    context: list[str] = dspy.InputField(desc="검색된 관련 문서 목록")
    question: str = dspy.InputField(desc="사용자 질문")
    answer: str = dspy.OutputField(desc="간결하고 정확한 답변")

# RAG 프로그램 정의
class RAGProgram(dspy.Module):
    def __init__(self, retriever, k=3):
        self.retriever = retriever
        self.generate = dspy.ChainOfThought(GenerateAnswer)  # 중간 추론 포함

    def forward(self, question):
        docs = self.retriever.search(question, k=3)
        context = [d.text for d in docs]
        # ChainOfThought가 답변 전 추론 과정을 생성
        pred = self.generate(context=context, question=question)
        return dspy.Prediction(answer=pred.answer, reasoning=pred.reasoning)

# 컴파일: 학습 데이터 20개, 정확도 메트릭 기준으로 최적화
optimizer = dspy.BootstrapFewShot(metric=answer_exact_match, max_bootstrapped_demos=4)
compiled_rag = optimizer.compile(RAGProgram(retriever), trainset=trainset)
# 결과: 모듈별 최적 퓨샷 예제가 자동으로 선택됨
# compiled_rag.generate.demos → 선택된 퓨샷 예제 리스트

핵심 포인트는 ChainOfThought(GenerateAnswer) 한 줄이 추론 패턴 선택과 시그니처 연결을 동시에 처리한다는 점입니다. forward에서는 데이터 흐름만 정의하면 되고, 어떤 프롬프트를 사용할지는 컴파일러가 결정합니다.

최적화 실행과 결과 저장

컴파일이 완료된 프로그램은 JSON 형식으로 저장하고 불러올 수 있습니다. compiled_rag.save("rag_optimized.json")으로 저장하면 모든 모듈의 최적화된 퓨샷 예제와 지시문이 직렬화됩니다. 나중에 new_rag.load("rag_optimized.json")으로 불러오면 재컴파일 없이 바로 사용할 수 있습니다. 이 직렬화 기능 덕분에 컴파일은 오프라인에서 한 번만 수행하고, 서빙 환경에서는 저장된 파라미터를 로딩해 사용하는 패턴이 가능합니다.

컴파일과 서빙을 분리하면 서빙 환경에서는 추가 LLM 호출 오버헤드가 없습니다.

멀티홉 추론으로의 확장

단순 RAG를 넘어 여러 번 검색하며 증거를 축적하는 멀티홉 추론은 DSPy가 특히 강점을 보이는 영역입니다. dspy.Retrieve 모듈을 여러 번 호출하고, 각 단계의 쿼리를 이전 단계 결과로 정제하는 구조를 파이썬 코드로 자연스럽게 표현할 수 있습니다. 중요한 점은 각 검색 쿼리 생성 단계가 독립적인 모듈로 추상화되므로, 컴파일러가 첫 번째 쿼리 생성과 두 번째 쿼리 생성을 별도로 최적화한다는 것입니다. 동일한 태스크에서 각 단계가 다른 퓨샷 예제 세트를 가질 수 있어 단계별 성능을 세밀하게 제어할 수 있습니다.

성능 특성과 대안 기술 비교

DSPy 최적화의 실제 성능 향상

DSPy 논문과 커뮤니티 벤치마크에서 일관되게 보고되는 패턴이 있습니다. 복잡한 다단계 추론 태스크에서 최적화 전 대비 10~40% 성능 향상이 관찰됩니다. 단순한 분류나 정보 추출 태스크에서는 향상 폭이 작지만, 멀티홉 QA나 코드 생성처럼 여러 단계가 연결된 태스크에서 특히 효과적입니다. 작은 모델에서 효과가 더 두드러지는 경향도 있습니다. gpt-4o 같은 강력한 모델은 이미 지시 따르기 능력이 뛰어나 개선 여지가 상대적으로 적지만, gpt-4o-mini나 오픈소스 모델에서는 퓨샷 최적화의 효과가 큽니다.

태스크 복잡도가 높을수록 DSPy 최적화의 효과가 크게 나타납니다.

대안 기술과의 비교

LangChain/LlamaIndex와 DSPy는 목적이 다릅니다. LangChain은 파이프라인 오케스트레이션에 집중하고 프롬프트 최적화는 다루지 않습니다. 두 프레임워크는 경쟁 관계가 아니라 상호 보완적입니다. LangChain으로 파이프라인 구조를 구성하고, 각 단계의 프롬프트를 DSPy로 최적화하는 조합도 가능합니다.

OpenAI Evals와의 비교에서는 역할이 명확히 갈립니다. Evals는 프롬프트가 얼마나 잘 동작하는지 측정하는 평가 도구이고, DSPy는 더 잘 동작하는 프롬프트를 자동으로 찾아 주는 최적화 도구입니다.

자동 프롬프트 최적화(APE) 방식, 즉 LLM에게 더 좋은 프롬프트를 제안하게 하는 접근법과 비교할 때 DSPy의 차별점은 파이프라인 수준의 최적화입니다. APE는 단일 프롬프트를 개선하지만, DSPy는 여러 모듈이 연결된 프로그램 전체를 최적화합니다.

어떤 상황에서 DSPy를 선택할 것인가

DSPy가 가장 효과적인 조건은 세 가지로 요약됩니다. 첫째, 태스크에 명확한 평가 메트릭이 있어야 합니다. 정확도, F1, 사실 포함 여부처럼 자동으로 측정 가능한 지표가 없으면 컴파일러가 최적화 방향을 알 수 없습니다. 둘째, 학습 예제를 수집할 수 있어야 합니다. 최소 20~50개의 입출력 예제가 필요합니다. 셋째, 파이프라인이 반복적으로 사용되어야 합니다. 컴파일에 투자하는 LLM 호출 비용을 회수하려면 최적화된 프로그램이 충분히 많이 실행되어야 합니다.

운영 환경 적용 시 고려사항

컴파일 비용과 캐싱 전략

DSPy 컴파일은 비용이 있습니다. MIPRO 옵티마이저를 사용하면 수백 번의 LLM 호출이 발생할 수 있고, 강력한 모델을 사용할수록 비용이 커집니다. 이를 제어하는 가장 중요한 설정이 max_bootstrapped_demos와 num_candidates입니다. 값을 낮추면 탐색 공간이 줄어 비용이 감소하지만 최적화 품질도 낮아질 수 있습니다. 처음에는 낮은 값으로 시작해 점진적으로 올리는 전략이 현실적입니다.

DSPy는 dspy.cache를 통해 LLM 호출을 캐싱합니다. 개발 과정에서 동일한 입력으로 여러 번 실험할 때 캐시 덕분에 반복 호출 비용을 크게 줄일 수 있습니다. 단, 캐시된 결과를 실제 최적화 평가에 사용하면 잘못된 측정이 될 수 있으므로, 최종 평가 시에는 캐시를 초기화하거나 비활성화하는 것이 바람직합니다.

개발과 서빙 단계를 명확히 분리해 컴파일 비용이 서빙 비용으로 이어지지 않도록 관리해야 합니다.

흔한 실수와 함정

데이터 누수가 가장 흔한 실수입니다. 컴파일 시 사용하는 학습 예제와 최종 성능 평가에 사용하는 테스트 예제가 겹치면 과적합된 결과를 얻습니다. 학습/검증/테스트를 엄격히 분리해야 합니다. 특히 부트스트랩 단계에서 수집된 예제 중 일부가 평가셋에 포함되는 상황을 주의해야 합니다.

메트릭 과신도 주의가 필요합니다. 자동 메트릭을 통과하더라도 실제 사용자 관점에서 답변 품질이 떨어질 수 있습니다. 특히 LLM-as-a-judge 패턴은 평가 LLM의 편향을 그대로 이어받습니다. GPT-4가 생성한 답변을 GPT-4가 평가하면 GPT-4의 선호 스타일로 최적화될 수 있으므로, 인간 평가와 병행하는 것이 안전합니다.

버전 불일치 문제도 간과하기 쉽습니다. 저장된 파라미터는 컴파일 시점의 프로그램 구조에 종속됩니다. 모듈을 추가하거나 시그니처를 수정하면 기존 저장 파일을 불러올 수 없습니다. 파라미터 파일에는 반드시 프로그램 버전 정보를 포함하고, 구조 변경 시 재컴파일을 의무화하는 절차를 팀 내에서 공유해야 합니다.

모니터링과 재컴파일 시점 판단

프로덕션에서 DSPy 프로그램을 모니터링할 때는 두 가지 지표를 지속적으로 추적해야 합니다. 첫째는 태스크 성능 지표입니다. 컴파일 시 사용했던 메트릭을 프로덕션에서도 샘플링해 측정합니다. 성능이 컴파일 시점보다 유의미하게 떨어지면 재컴파일 신호입니다. 둘째는 입력 분포 변화입니다. 사용자 질문이나 문서 분포가 크게 바뀌면 기존 퓨샷 예제가 더 이상 대표적이지 않을 수 있습니다.

재컴파일 빈도는 서비스 특성에 따라 다르지만, 모델 버전이 업데이트될 때와 운영 데이터를 축적해 더 나은 학습 예제를 구성할 수 있을 때를 재컴파일 트리거로 설정하는 패턴이 일반적입니다. DSPy는 기존 컴파일 결과를 시작점으로 해서 추가 최적화를 하는 점진적 컴파일도 지원합니다.

재컴파일은 비용이 있으므로, 모니터링 → 진단 → 최소 범위 재컴파일 순서로 접근하는 것이 효율적입니다.

확장과 마이그레이션 고려사항

팀에서 DSPy를 처음 도입할 때 가장 현실적인 진입점은 기존 LLM 파이프라인의 일부 모듈만 DSPy로 교체하는 것입니다. 전체를 한 번에 마이그레이션하려 하면 학습 데이터 준비, 메트릭 설계, 컴파일 인프라 구축이 동시에 필요해 부담이 큽니다. 가장 성능이 불안정하거나 튜닝 비용이 많이 드는 모듈부터 시작해 점진적으로 확장하는 방식이 안정적입니다.

여러 서비스에서 동일한 DSPy 프로그램을 공유할 때는 컴파일된 파라미터를 아티팩트 저장소(예: MLflow, Weights & Biases)에서 버전 관리하는 것이 권장됩니다. 파이프라인 버전과 파라미터 버전을 함께 추적해야 어떤 컴파일 결과가 어떤 성능을 냈는지 재현 가능한 이력을 유지할 수 있습니다.

맺음말

핵심 요약

DSPy는 LLM 파이프라인 개발에서 반복적인 프롬프트 수작업을 컴파일러가 자동화하는 접근법입니다. 시그니처로 태스크 명세를 선언하고, 모듈로 추론 패턴을 선택하며, 옵티마이저가 퓨샷 예제와 지시문을 자동으로 최적화합니다. 이 패러다임의 핵심 이점은 세 가지입니다. 첫째, 모델 교체 시 재컴파일만으로 최적 프롬프트를 재생성할 수 있습니다. 둘째, 복잡한 다단계 파이프라인에서 각 모듈을 독립적으로 최적화해 성능 병목을 식별하고 개선할 수 있습니다. 셋째, 최적화 결과를 직렬화해 서빙 환경에서 재컴파일 오버헤드 없이 사용할 수 있습니다.

적용 판단 기준

DSPy가 적합한 프로젝트는 명확한 평가 메트릭, 최소 수십 개의 학습 예제, 반복 실행되는 파이프라인이라는 세 조건을 갖춘 경우입니다. 반면 일회성 프로토타입, 평가 자동화가 어려운 창의적 생성 태스크, 또는 프롬프트 엔지니어링에 이미 충분한 결과를 내고 있는 경우라면 도입 비용 대비 효과가 제한적일 수 있습니다. 멀티홉 RAG, 복잡한 추론 파이프라인, 소규모 모델을 강력한 모델에 근접한 성능으로 활용하고 싶은 상황이라면 DSPy가 현재 시점에서 가장 체계적인 접근법 중 하나입니다. DSPy의 공식 문서와 예제는 https://dspy.ai에서 확인할 수 있습니다.