DSPy 채택은 더딘데, 팀들은 왜 같은 LLM 패턴을 다시 만들까

Hacker News 토론과 If DSPy is So Great, Why Isn't Anyone Using It?는 DSPy를 둘러싼 기대와 현실을 함께 보여준다. 이 HN 스레드는 2026년 3월 23일 UTC에 올라왔고, 집계 시점 기준 119점과 74개 댓글을 기록했다. 링크된 글에서 Skylar Payne이 강조하는 핵심은 모든 팀이 지금 당장 DSPy를 도입해야 한다는 주장이 아니다. 대신 AI 시스템이 커질수록 많은 팀이 DSPy가 이미 정리한 설계 패턴을 뒤늦게, 그리고 더 불편한 방식으로 다시 만든다는 주장에 가깝다.

글은 단순한 회사명 추출 예시를 통해 이런 진화를 단계적으로 설명한다. 처음에는 단일 API 호출로 시작하지만, 곧 배포 없이 프롬프트를 바꾸기 위한 prompt versioning이 필요해진다. 그 다음에는 Pydantic 같은 도구를 통한 structured outputs가 들어오고, 일시적 실패를 버티기 위한 retries가 붙는다. 여기에 모델이 외부 지식이 필요해지면 RAG를 더하고, 변경이 실제로 나아졌는지 확인하려고 evals를 마련하며, 마지막에는 GPT-4와 Claude 같은 모델을 큰 리팩터링 없이 시험할 수 있도록 model-swapping 계층을 원하게 된다는 설명이다. Payne의 요지는 이것이 특별한 마법이 아니라, 처음에는 미뤄 두었던 소프트웨어 엔지니어링의 기본 원칙이 AI 제품에서 늦게 다시 등장하는 과정이라는 점이다.

• prompt versioning과 프롬프트 분리
• structured outputs와 typed I/O
• retries와 실패 처리의 중앙화
• RAG 기반 문맥 보강
• evals를 통한 회귀 점검
• pipeline을 다시 쓰지 않는 model-swapping

글이 보는 adoption 지연의 이유도 분명하다. DSPy의 abstraction은 익숙하지 않고, 경계도 모호하다. 프롬프트는 코드이면서 데이터처럼 다뤄지고, 출력은 확률적이어서 일반 코드처럼 디버깅하기 어렵다. 제품 팀은 빨리 ship해야 하니, inline prompt와 임시 로직이 먼저 들어간다. DSPy는 signatures, modules, evaluation loop 같은 구조를 초기에 생각하게 만들기 때문에 학습 곡선이 가파르게 느껴진다. 하지만 글은 바로 그 upfront 설계 부담을 미루는 대가가 몇 달 뒤 더 큰 복잡도로 돌아온다고 본다.

HN 토론은 이 주장을 그대로 받아들이기보다 어디가 핵심인지 더 날카롭게 따졌다. 일부 댓글은 typed I/O, retries, 프롬프트 분리 자체는 이미 많은 팀의 기본기라고 보고, DSPy의 진짜 차별점은 prompt optimization에 있다고 말했다. 또 여러 댓글은 open-ended AI 제품에서는 안정적인 eval metric을 만들기 어렵다고 지적했다. 이런 반응은 DSPy의 아이디어에 공감하더라도, 실제 도입은 데이터 라벨링과 평가 설계 비용에 크게 좌우된다는 점을 보여준다.

결론은 단순하다. 이 글과 HN 토론이 완전히 같은 결론에 도달한 것은 아니지만, 둘 다 LLM 시스템이 복잡해질수록 prompt 관리, typed interface, retrieval, evaluation, model abstraction이 사실상 선택 사항이 아니게 된다는 점은 보여준다. 차이는 그 패턴을 DSPy로 바로 받아들일지, 아니면 각 팀이 나중에 스스로 다시 만들지를 두고 생긴다.