영상 링크: DSPy: The End of Prompt Engineering - Kevin Madura, AlixPartners
채널명: AI Engineer
DSPy: 프롬프트 엔지니어링의 종말 - Kevin Madura, AlixPartners 핵심 요약
- DSPy는 대형 언어 모델(LLM)을 활용한 모듈형 파이썬 프로그램을 빠르고 선언적으로 작성할 수 있게 해주는 프레임워크임
- 프롬프트를 직접 세세히 만들고 반복적으로 튜닝하는 대신, “signature(시그니처)” 및 “module(모듈)” 구조로 의도를 설정하고 로직을 분해할 수 있도록 설계됨
- DSPy는 구조화된 입력/출력 타입 보장, 다양한 어댑터(예: JSON, BAML), 캐싱, 멀티모달(텍스트·이미지·PDF 등) 처리 등으로 실무 활용성을 높임
- 프롬프트 파싱/출력 변환 등의 반복적인 작업을 자동화, 코드 수준에서 LLM 통합이 용이
- 자체 옵티마이저(optimizer)와 수치 기반 메트릭(metric)를 활용, 프로그램 자동 최적화 및 파라미터·프롬프트 튜닝 가능
- 모델 전환/파라다임 변화(예: GPT-4 → Nano모델 등)에 로직 재구축 없이 손쉽게 대응, 성능 저하시 자동으로 재최적화 진행 가능
- 튜토리얼/데모 코드에서는 감정 분류기, PDF 구조화, 이미지를 활용한 규칙 확인, 툴(툴 콜링) 연동, 옵티마이저 적용 등 다양한 실전 예시 제공
- 실제 코드에서는 Pydantic 기반 타입 구조, 첨부파일 라이브러리, 캐시와 사용량 트래킹, 툴 에이전트 및 멀티 LLM 라우팅 등 실질적인 LLM 기반 업무 자동화 방법 시연
- 최적화 결과는 “모듈+최적화된 프롬프트” 형태로 직렬화되어 재사용 또는 신규 프로젝트에 손쉽게 적용 가능
- 비용 문제/대용량 컨텍스트 최적화에 대한 팁, 실시간 및 지연 피드백 통합 등 실무 질문에 대한 구체적 현장 경험 제공
세부 요약 - 주제별 정리
DSPy는 선언적 로직 해석과 LLM 통합을 통해 프롬프트 엔지니어링을 구조적으로 대체함
- DSPy의 목적은 기존의 직접적인 프롬프트 조립 및 반복 튜닝이 아닌, 모듈 구성 기반 파이썬 코드로 LLM 활용 프로그램을 설계함
- 사용자는 함수 서명(signature) 형식으로 입력값·출력값을 타입·설명과 함께 선언하고, LLM이 내부적으로 해석·구현하도록 위임
- 각 “signature”는 Pydantic class 혹은 간결한 dict 형태로 정의 가능하며, 필드 이름 자체가 프롬프트 일부 역할 수행
- 전체 로직은 “module”로 캡슐화해 복잡한 비즈니스 로직, 분기, 외부 함수, 데이터 흐름을 체계적으로 관리
- “adapter”는 signature와 실제 LLM 호출 간 인터페이스로, 데이터를 내부 구조 및 여러 포맷(JSON/BAML/XML 등)으로 변환
- 여러 LLM, 다양한 모델 버전(GPT, Claude, Gemini 등) 혼합 적용 및 추상화 레이어 활용 가능
“프롬프트 엔지니어링”이 아닌 “프로그램 구조 설계”로 초점을 옮길 수 있음
- DSPy는 prompt engineer의 숙련된 프롬프트를 포함하거나, 기존 prompt를 dockstring 등에 삽입해 활용할 수 있게 지원
- 텍스트 파싱, JSON 구조 파괴, 출력 변환 등 번거로운 작업을 추상화하여 개발자가 본질적 비즈니스 로직에 집중할 수 있음
- 구조적 선언과 모듈 구분으로 “프롬프트-프로그램-로직”의 분리가 이뤄지며, 코드 재사용, 수정, 구성이 쉬워짐
- 새로운 LLM 등장, 모델 교체 등 변화에도 signature(입출력 및 의도)만 유지하면 프로그램 로직 자체는 재활용 가능
주요 구성요소(Primitives) - Signature, Module, Tool, Adapter, Optimizer, Metric 설명 및 역할
- Signature: 입력/출력 타입·의도·설명 등 함수 서명 선언, 프롬프트의 주요 텍스트적 요소 역할
- ex) Sentiment 분류기:
text: str입력,sentiment: int출력 - 클래스 기반 또는 한 줄 요약식 정의 가능, 필드명 및 설명이 LLM 최적화에 중요
- ex) Sentiment 분류기:
- Module: Signature 기반으로 구성되는 논리적 프로그래밍 단위
- 여러 시그니처·파이썬 로직·LLM 호출 결합, 비즈니스 로직 분해 및 재사용에 최적화
- 내장 module(Dspi.predict, chain of thought, react 등)과 커스텀 module 모두 지원
- Tool: DSPI의 툴은 일반 파이썬 함수이며, React 등의 에이전트 호출 구조에 등록 가능
- LLM이 외부 함수(calling tool) 호출, 예시로 웹검색, 날씨조회 등 통합
- Adapter: 시그니처-LLM간 데이터 변환 레이어. JSON/BAML 등 다양한 포맷에 맞춰 자동 변환
- 어댑터 변경만으로 프롬프트 출력포맷 변경 및 LLM의 성능·토큰 효율 개선 가능 (BAML 사용시 최대 5~10% 효율 향상 사례)
- Optimizer: 프로그램 내 성능 향상을 위한 프롬프트 튜닝 및 자동 최적화 수행
- 옵티마이저가 프롬프트 반복 수정, metrics에 따라 성능 개선, 모델별/데이터별 최적화 가능
- Jeepa, GRPO 등 기존 fine-tuning 못지않은 성능 달성 가능 (CS224N Chris Potts 논문 소개)
- Metric: 성능 기준 및 성공 정의 지표. Equals(값 일치), LLM 판정(judge), 커스텀 룰 등 유연하게 작성
- 옵티마이저가 metric 결과로 피드백 루프를 구축, 성능 개선 경로 탐색
시연 코드: 멀티 모델 혼합, 감정분류, 캐시, 트래킹, 구조 추출 등 실용적 사례
- 오픈라우터 API로 Claude, Gemini, 4.1 mini 등 멀티 LLM 접속 및 쿼리 혼합 실행
- pyantic literal을 활용해 답변 범위를 강제(예: 조직명 분류)
- 첫 호출 외에는 캐싱 활용, 결과 반환 속도 향상, 실질 테스팅 및 트윅에 활용
- 감정분류: “This hotel stinks”→음수 “I’m feeling pretty happy”→정수 8 등 실시간 실행, 결과 사용량·토큰 소비량까지 트래킹 가능
첨부파일(attachments) 라이브러리 및 멀티모달 처리 예시로 LLM 입력 확장
- Maxim의 Attachments 라이브러리로 PDF, 이미지, 오디오 등 다양한 파일을 DSPI/LLM에서 바로 인식·활용
- 예시: 4-Form SEC PDF에서 이미지/텍스트 OCR 추출 후 “총 주식 매도량” 등 질의-응답
- 아웃풋 구조는 그대로 유지하며, 문서 기반 RAG(거의 Pre-RAG 수준)도 쉽고 빠르게 실현
어댑터(JSON/BAML 등)별 LLM 성능 차이 실험 및 최적 포맷 도출
- JSON 어댑터 대비 BAML 어댑터가 더 간결·인간 친화적 구조 제공 및 일부 LLM에서 성능 이득
- JSON 어댑터: 복잡한 데이터일수록 프롬프트 길이 증가, 토큰 낭비
- 어댑터 교체만으로 다양한 모델별 실험과 테스트 용이
툴 콜링, React, Tool 에이전트로 LLM과 외부 함수 연동, 결과 추정 과정 시각화
- 파이썬 함수(get_weather, search_web 등)를 LLM tool로 등록, React agent가 필요한 순서대로 실행
- 추론 결과 및 과정(trajectory) 기록, 디버깅과 검증에 활용
- 분기적 로직, 데이터 활용 예시(재직기간 10년 이상 여부 등)로 실질적 비즈니스 문제 자동화
고도화된 문서·이미지 분류, 구조 추출, 도큐먼트 세부 구간 자동탐지 및 요약
- 다양한 문서(pdf, 이미지 혼합) 샘플을 분류: 계약서, SEC filing, 도시 인프라 이미지, 기타
- 주어진 파일을 자동으로 첨부파일→이미지 리스트→문서 타입 분류→구간별 요약→서브 도큐먼트(스케줄 등) 구분까지 일관적 파이프라인으로 처리
- 약 13페이지 분량 계약서 PDF, 각 section(본문, schedule1~3 등)의 시작·끝 페이지까지 자동 탐지 및 요약 구현
- 복수 이미지 기반 정교한 구간탐지 알고리즘(분류→경계 탐지→구간별 추출), 코드 일부 공개
옵티마이저(Jeepa 등) 적용: 대형→경량 모델로 성능 이전, 비용 절감 및 프롬프트 최적화 실증
- 옵티마이저로 LLM의 프롬프트 반복 최적화(LLM→피드백→프롬프트 튜닝→재실행 등 루프)
- 모델 전환시(예: 4.1→nano) 성능 저하를 프롬프트 재최적화로 극복(예: 70%→87%)
- 옵티마이저 결과는 모듈+최적화 프롬프트 형태로 저장, 필요시 신규 프로젝트·다른 팀에서도 공유 및 전이 학습 가능
코드 객체/옵티마이저 결과는 모듈화되어 ‘허깅페이스’ 스타일 공유 및 재활용이 가능
- DSPIHub 프로젝트: 최적화된 프로그램 객체를 저장·다운로드해 다양한 고객사/업무에 재적용, 재사용 가능
- 최적화된 상태 = signature, 입력/출력 스키마, 최적화 프롬프트 등 전체 포함 (학습된 ML 모델 저장 방식과 유사)
- 특정 도큐먼트 분류기나 문서 요약 객체 등은 별도 배포 및 전이 학습 기반으로도 활용 가능
메트릭 및 옵티마이저 적용 방식은 “자체 데이터셋” 품질, 실질적 비즈니스 목적에 밀접하게 연결됨
- 데이터셋이 충분히 잘 설계되어 있다면(예: 입력
출력 10100 예시), 옵티마이저로도 큰 성능/정확도 개선 가능(예: 타임엔트리 수정기 86%→89%) - 각 메트릭별 성능개선 폭도 분해 가능(메트릭 교체, 세분화 등 추가 개선의 근거 제공)
- LLM을 “판정자”로 활용하는 주관적 메트릭과, 일치여부 등 객관적 메트릭 병행 지원
실시간/지연 피드백, 대용량 컨텍스트·비용 문제 현장 경험 공유
- 사용자 피드백(thumbs up/down 등) 등 지연된 평가 결과는 추가 데이터셋으로 축적 후, 오프라인 최적화 및 주기적 리프레시 방식 채택
- 실시간 온라인 튜닝도 이론상 가능하나 현업에서는 ML+DSPI 하이브리드, 라우터·컨텍스트 압축·어댑터 개선 병행 권장
- DSPI 자체가 비용을 높이지는 않으며, 대규모 호출·비효율적 컨텍스트 설계·불필요한 반복 실행 등에서만 비용 이슈가 발생 가능
- 어댑터 및 로직 수정, 모듈 트리밍 등 다양한 비용 절감 및 대용량 관리 방법 공유
Q&A 및 워크샵 진행 경험: DSPI의 한계, 타 ML방법과의 병행, 팀 내 역량 향상 방향 등 솔직한 의견 제시
- DSPy는 LLM 활용 개발 “프로그래밍 패러다임”에 가깝고, ML classifier 등 전통적 방법과도 병행 가능
- 구조적 구성과 자동화, 추상화 레이어가 강점이나, 케이스에 따라 기존 방식이 더 적합할 수도 있음
- 최적화된 모듈은 회사/팀 간 지식 전파, 재사용, 전이학습 등에 매우 유리, 코드 실습 병행으로 학습 효율 제고
- 대규모 워크플로, 파이프라인, 데이터처리, 문서구조 자동화 등 업무 자동화에 적합함
(본 요약에는 영상 내 시연 코드, 실습 예시, 주요 라이브러리, 인물(오마르 등), 인용 자료(Chris Potts, Jeepa, Attachments, Pashant 등), 수치 및 실무 근거가 모두 반영됨)