DSPy, 왜 아직도 현장에서 안 쓰일까? — LLM 프로그래밍 프레임워크의 이상과 현실

프롬프트 엔지니어링의 한계를 넘으려는 시도

LLM 기반 애플리케이션을 만들어본 분이라면 한 번쯤 느꼈을 겁니다. 프롬프트를 한 글자 바꿨더니 출력이 완전히 달라지고, 모델을 GPT-4에서 Claude로 교체하면 기존 프롬프트가 제대로 동작하지 않는 경험 말입니다. 이 문제를 근본적으로 해결하겠다고 나온 것이 스탠포드에서 만든 DSPy입니다.

DSPy의 핵심 아이디어는 단순합니다. 프롬프트를 수작업으로 작성하는 대신, 입력과 출력의 시그니처(signature)를 선언적으로 정의하고, 옵티마이저가 최적의 프롬프트를 자동으로 찾아주는 것입니다. 마치 PyTorch에서 신경망 레이어를 쌓고 옵티마이저로 학습시키듯, LLM 파이프라인도 같은 방식으로 다루자는 철학이죠. 학술적으로 매우 우아한 접근이고, 논문도 많은 인용을 받았습니다. 그런데 정작 프로덕션 현장에서는 DSPy를 쓰는 팀을 찾기가 어렵습니다. 왜 그럴까요?

이론적 우아함과 현실의 간극

DSPy가 현장 채택에 어려움을 겪는 가장 큰 이유는 추상화 수준과 디버깅의 어려움 사이의 긴장입니다. DSPy에서는 프롬프트가 옵티마이저에 의해 자동 생성되기 때문에, 무언가 잘못됐을 때 "왜 이런 출력이 나왔는지"를 추적하기가 매우 까다롭습니다. 수작업 프롬프트 엔지니어링에서는 최소한 내가 작성한 지시문을 보면서 어디가 문제인지 감을 잡을 수 있지만, DSPy에서는 옵티마이저가 생성한 중간 프롬프트를 일일이 꺼내봐야 합니다.

두 번째 문제는 평가 데이터셋의 필요성입니다. DSPy의 옵티마이저가 동작하려면 "좋은 출력"이 무엇인지 판단할 수 있는 메트릭과 예시 데이터가 필요합니다. 그런데 많은 LLM 애플리케이션은 명확한 정답이 없는 open-ended 태스크입니다. 고객 문의에 대한 응답이 "좋은 응답"인지 판단하는 메트릭 자체를 만드는 것이 또 하나의 프로젝트가 되어버립니다. 결국 DSPy를 제대로 쓰려면 상당한 사전 투자가 필요한데, 빠르게 MVP를 만들어야 하는 스타트업 환경에서는 이 비용이 부담스럽습니다.

세 번째는 엔지니어링 패턴의 부재입니다. 프레임워크가 학술 연구에서 출발했기 때문에, 실제 프로덕션에서 어떻게 구조를 잡아야 하는지, 테스트는 어떻게 작성해야 하는지, CI/CD 파이프라인에는 어떻게 통합해야 하는지에 대한 모범 사례가 부족합니다. 원본 글에서도 이 부분을 지적하며 실무에서 적용 가능한 엔지니어링 패턴들을 제안하고 있습니다.

그럼에도 DSPy가 가치 있는 지점

그렇다고 DSPy를 완전히 무시하기도 어렵습니다. DSPy가 실제로 빛을 발하는 영역이 있습니다. 구조화된 데이터 추출, 분류 태스크, RAG 파이프라인의 질의 최적화 같이 입출력이 비교적 명확하고 평가 메트릭을 정의하기 쉬운 태스크에서는 수작업 프롬프트보다 일관되고 좋은 결과를 보여줍니다.

특히 모델을 자주 교체해야 하는 환경에서 DSPy의 가치가 커집니다. GPT-4o에서 Claude Sonnet으로, 혹은 오픈소스 모델로 전환할 때 프롬프트를 처음부터 다시 작성하는 대신 옵티마이저를 다시 돌리면 되니까요. 비용 절감을 위해 더 작은 모델로 마이그레이션하는 시나리오에서도 마찬가지입니다.

경쟁 생태계와 비교

현재 LLM 애플리케이션 프레임워크 시장은 상당히 혼잡합니다. LangChain은 범용성과 거대한 커뮤니티를 무기로 사실상의 표준 자리를 차지하고 있고, LlamaIndex는 RAG 특화 도구로 자리매김했습니다. 최근에는 Anthropic의 Claude Agent SDK나 OpenAI의 Agents SDK처럼 모델 제공업체가 직접 프레임워크를 제공하는 추세도 있습니다.

DSPy가 이 경쟁에서 차별화되는 부분은 "프로그래밍 모델" 자체를 제안한다는 점입니다. LangChain이 체인과 에이전트라는 메타포를 쓴다면, DSPy는 "모듈과 옵티마이저"라는 머신러닝 연구자에게 익숙한 메타포를 사용합니다. 이것이 강점이자 약점입니다. ML 연구 경험이 있는 팀에게는 자연스럽지만, 일반 백엔드 개발자에게는 진입 장벽이 됩니다.

최근에는 Instructor나 Outlines 같은 더 가벼운 라이브러리들도 주목받고 있습니다. 이들은 DSPy처럼 전체 패러다임을 바꾸려 하지 않고, 구조화된 출력이라는 한 가지 문제를 깔끔하게 해결합니다. "적은 것이 더 많은 것"이라는 Unix 철학이 프레임워크 선택에서도 통하는 셈입니다.

한국 개발자에게 주는 시사점

국내에서도 LLM 기반 서비스를 만드는 팀이 급증하고 있습니다. 대부분은 LangChain이나 직접 API를 호출하는 방식으로 시작하는데, 프로젝트가 커지면서 프롬프트 관리가 점점 고통스러워지는 경험을 하게 됩니다. 이 시점에서 DSPy의 접근법을 참고할 가치가 있습니다.

당장 DSPy를 프로덕션에 도입하지 않더라도, "프롬프트를 코드처럼 관리하고 자동으로 최적화한다"는 사고방식은 가져갈 수 있습니다. 예를 들어, 프롬프트 변경의 영향을 측정하기 위한 평가 파이프라인을 먼저 구축하고, 그 위에서 프롬프트를 반복 개선하는 워크플로우를 만드는 것이죠. DSPy를 직접 쓰지 않더라도 이 원칙은 적용 가능합니다.

정리

DSPy는 "프롬프트 엔지니어링은 소프트웨어 엔지니어링이 아니다"라는 정확한 문제 인식에서 출발했지만, 현실의 복잡성 앞에서 아직 채택의 벽을 넘지 못하고 있습니다. 기술 자체의 문제라기보다는 생태계 성숙도와 엔지니어링 패턴 부족의 문제에 가깝습니다. 여러분의 팀에서는 LLM 프롬프트를 어떻게 관리하고 계신가요? 수작업 프롬프트 엔지니어링의 한계를 느끼고 계신 분이 있다면, 어떤 대안을 검토하고 계신지 궁금합니다.