DSPy를 도입하기 전에, LM 프로그램에 계약(Contract)이 있는지 증명하세요

DSPy는 과소평가되기 쉽습니다. 만약 이를 "프롬프트를 작성하는 더 나은 방법"이라고 설명한다면, 아마도 잘못된 것을 테스트하게 될 것입니다.

더 나은 첫 번째 테스트는 이것입니다: 당신의 언어 모델 (Language Model) 워크플로우를 선언된 입력(Inputs), 선언된 출력(Outputs), 측정 가능한 예시(Measurable examples), 그리고 비즈니스 경계(Business boundary)를 변경하지 않고도 프롬프트를 변경할 수 있는 최적화 도구(Optimizer)를 갖춘 작은 프로그램으로 표현할 수 있는가?

그 지점이 바로 DSPy가 의미를 갖기 시작하는 지점입니다.

상위 README는 DSPy를 파운데이션 모델 (Foundation models)을 위한 프롬프팅 (Prompting)이 아닌 프로그래밍 (Programming)을 위한 프레임워크로 정의합니다. 현재 Doramagic의 stanfordnlp/dspy 프로젝트 팩 또한 동일한 시작 명령어를 가리키고 있습니다: pip install dspy. 오늘 제가 확인한 패키지 메타데이터는 name="dspy", 버전 3.3.0b1, 그리고 Python >=3.10,<3.15를 선언하고 있습니다. GitHub API 스냅샷에 따르면 해당 저장소는 여전히 활발하며, 2026-07-05에 푸시(Push)가 있었고, 빈 평가 세트(Empty evaluation sets), 문서 포맷팅(Document formatting), 그리고 GEPA 추적 속성(GEPA trace attribution)에 관한 최근 풀 리퀘스트 (Pull requests)가 있었습니다.

그러한 활동은 유용하지만, 그것이 도입의 증거는 아닙니다. 증거는 당신의 작업이 세 가지 분리(Separations)를 견뎌낼 수 있는지 여부입니다.

1. 작업 계약(Task contract)을 프롬프트로부터 분리하기

DSPy 용어로 말하자면, 읽어볼 가치가 있는 첫 번째 결과물은 영리한 프롬프트가 아닙니다. 바로 시그니처 (Signature)입니다.

시그니처 (Signature)는 무엇이 입력되고 무엇이 반드시 출력되어야 하는지를 말해줍니다. 모듈 (Module)은 해당 계약을 호출 가능한 무언가로 감쌉니다. 어댑터 (Adapter)는 계약을 제공자(Provider)가 직면하는 프롬프트 형식으로 변환하고, 모델의 응답을 다시 필드(Fields)로 파싱(Parse)합니다.

이것은 당신에게 실질적인 검토 질문을 던집니다:

누군가 문구 조절(Tuning wording)을 시작하기 전에, 팀이 출력 필드(Output fields)의 이름을 정할 수 있는가?

만약 대답이 '아니오'라면, DSPy는 워크플로우를 구원하지 못할 것입니다. 당신은 여전히 작업 그 자체를 협상하고 있는 중이기 때문입니다. 첫 번째 단계는 아주 작은 계약이어야 합니다: 입력 텍스트, 필요한 경우 검색된 컨텍스트 (Retrieved context), 답변, 인용 (Citations), 신뢰도 (Confidence), 또는 제품이 실제로 필요로 하는 필드들입니다. 에이전트 (Agents), 도구 (Tools), 또는 다단계 파이프라인 (Multi-stage pipelines)부터 시작하지 마세요.

2. 컴파일(Compilation)과 런타임(Runtime) 정답성(Correctness)의 분리

DSPy 옵티마이저 (Optimizers)는 모듈 (Module)을 위한 프롬프트 (Prompts)나 가중치 (Weights)를 개선할 수 있습니다. 이는 강력한 기능이지만, 실패 모드 (Failure mode)를 변화시킵니다.

위험한 버전은 다음과 같습니다: "옵티마이저가 더 나은 프롬프트를 찾았으니, 그대로 배포하자."

더 안전한 버전은 다음과 같습니다: "옵티마이저가 후보 (Candidate)를 생성했으니, 이제 이를 고정된 개발 세트 (Devset)와 비교하고, 트레이스 (Traces)를 검사하며, 롤백 (Rollback) 경로를 유지하자."

최근의 업스트림 (Upstream) 활동은 이러한 경계를 가시화합니다. 최근의 한 PR (Pull Request)은 나눗셈 오류 (Division error)에 빠지는 대신, 빈 개발 세트 (Devset)에 대해 기술적인 ValueError를 발생시키도록 수정되었습니다. 또 다른 PR은 예측기 식별자 (Predictor identity)를 통해 GEPA 트레이스 귀속 (Trace attribution) 문제를 해결했습니다. 이것들은 마케팅용 세부 사항이 아닙니다. 이는 실제 운영 표면 (Operating surface)을 가리킵니다. 최적화 (Optimization)에는 예시 (Examples), 트레이스 (Traces), 그리고 귀속 (Attribution)이 필요합니다. 이것들이 없다면, 여러분은 가시성이 낮은 상태에서 단순히 프롬프트 텍스트를 이리저리 옮기고 있는 것에 불과합니다.

저의 첫 번째 수락 테스트 (Acceptance test)는 의도적으로 지루하게 구성할 것입니다:

• 새로운 Python 3.10+ 환경에 설치하기;
• 저렴한 모델 하나를 설정하기;
• 하나의 시그니처 (Signature)와 하나의 모듈 (Module) 정의하기;
• 아주 작은 고정 개발 세트 (Fixed devset) 실행하기;
• 컴파일된 프로그램 (Compiled program)과 이력/트레이스 (History/traces) 출력하기;
• 사람이 점수뿐만 아니라 동작을 비교할 수 있도록 전/후 결과 저장하기.

만약 이 과정이 너무 무겁게 느껴진다면, DSPy는 아마도 해당 작업에 적합한 첫 번째 추상화 (Abstraction)가 아닐 것입니다.

3. 검색 품질 (Retrieval quality)과 답변 품질 (Answer quality)의 분리

DSPy는 종종 RAG (Retrieval-Augmented Generation) 작업에 도입되지만, RAG의 실패는 최종 답변에서 시작되는 경우가 드뭅니다. 실패는 더 앞 단계에서 시작됩니다: 청킹 (Chunking), 검색 (Retrieval), 메타데이터 (Metadata), 문서 포맷팅 (Document formatting), 또는 누락된 부정적 예시 (Negative example) 등입니다.

따라서 저는 "질문에 답을 하는가?"라는 질문으로 DSPy를 평가하지 않을 것입니다.

대신 다음과 같은 사항들을 평가할 것입니다:

• 모듈이 올바른 검색 기록 (Retrieved records)을 받았는가?
• 생성 (Generation) 전에 검색된 기록을 검사할 수 있는가?
• 출력 계약 (Output contract)이 인용 (Citations)이나 근거 (Evidence) 필드를 강제하는가?
• 개발 세트 (Devset)에 검색이 실패해야 하는 케이스가 포함되어 있는가?
• 옵티마이저 (Optimizer)가 검색 퇴보 (Retrieval regression)를 숨기지 않으면서 답변을 개선할 수 있는가?

Doramagic의 DSPy 매뉴얼은 프로젝트를 Signatures (시그니처), Modules (모듈), Adapters (어댑터), LM clients (LM 클라이언트), optimization/compilation (최적화/컴파일), tools (도구), streaming (스트리밍), retrieval (검색), 그리고 utilities (유틸리티)로 분류합니다. 이는 팀이 최종 답변만을 유일한 테스트 대상(object under test)으로 취급하는 것을 방지해주기 때문에 훌륭한 도입 지도 (adoption map)가 됩니다.

DSPy가 적합한 위치

DSPy는 팀이 이미 반복 가능한 LM 태스크를 보유하고 있으며, 프롬프트 레이어 (prompt layer)를 프로그래밍 가능하고, 검사 가능하며, 최적화 가능하게 만들고 싶을 때 가장 강력한 힘을 발휘합니다.

반면, 팀이 아직 제품의 동작을 탐색하는 단계이거나, 예시가 없거나, 혹은 무엇이 올바른 출력인지 정의할 수 없는 경우에는 적합성이 떨어집니다. 그런 경우에는 일반적인 코드, 작은 평가 (eval) 파일, 그리고 수동 트레이스 (manual traces)로 시작하세요. 계약 (contract)이 최적화할 수 있을 만큼 충분히 안정화된 후에 DSPy를 추가하십시오.

제가 사용할 실질적인 규칙은 다음과 같습니다:

프롬프트를 변경하는 것이 프로그램을 컴파일하는 것처럼 취급되어야 할 때 DSPy를 사용하십시오. 프롬프트를 변경하는 것이 여전히 제품 설계 (product design) 단계라면 DSPy를 건너뛰십시오.

확인된 출처: Doramagic DSPy 프로젝트/매뉴얼 페이지, Doramagic PROJECT_PACK, 업스트림 README, 업스트림 pyproject.toml, GitHub API 리포지토리 및 릴리스 스냅샷.

태그: DSPy, LLM, RAG, prompt-optimization, agent-engineering, evaluation, Python, open-source, AI-engineering, observability, retrieval, GEPA