나는 프롬프트 작성을 멈추고 파이썬을 쓰기 시작했다

발행: (2026년 4월 9일 오후 06:27 GMT+9)
5 분 소요
원문: Dev.to

Source: Dev.to

프롬프트 혼돈

1년 동안 나는 LLM을 명령줄처럼 다뤘다: 명령을 입력하고, 출력을 기도하며, 문구를 미세 조정하고, “IMPORTANT:”를 추가하고, 마치 의식처럼 문장을 옮겨 놓았다. 그 결과 폴더에는 다음과 같은 프롬프트 파일들이 쌓였다:

v1.txt
v2_final.txt
v2_final_REALLY_final.txt

하지만 왜 작동했는지에 대한 문서는 없었다. 무언가가 깨졌을 때, 문제가 프롬프트인지, 모델인지, 데이터인지 알 수 없었다. 버전 관리도, 테스트도 없었고, 그저 분위기만 있었다.

DSPy 등장

DSPy(Stanford NLP에서 개발)는 모델을 뒤집는다: 프롬프트를 쓰는 것이 아니라 파이썬을 쓴다.

class AnalyzeStartup(dspy.Signature):
    """Analyze a startup pitch."""

    pitch: str = dspy.InputField()
    viability_score: int = dspy.OutputField()
    strengths: list[str] = dspy.OutputField()
    weaknesses: list[str] = dspy.OutputField()
    verdict: str = dspy.OutputField()

그게 전부다—“당신은 전문가 스타트업 분석가입니다…”, “JSON 형식으로 응답하세요…” 같은 프롬프트는 필요 없다. DSPy는 이 시그니처를 프롬프트로 컴파일한다. 더 좋은 프롬프트가 필요하면 옵티마이저를 실행하면 되고, DSPy가 작동하는 예시를 기반으로 프롬프트를 다시 작성한다.

프롬프트 트릭에서 시그니처로

전:

“설명 앞에 예시를 넣으면 더 잘 동작한다. 가끔은. GPT‑4o가 아니면.”

후:
시그니처를 작성한다. DSPy가 최적의 프롬프트 형식을 찾아준다. 프롬프트는 구현 세부 사항이 되고, 나는 입력, 출력, 동작에만 신경 쓴다—문구에는 신경 쓰지 않는다.

테스트 가능한 LLM 코드

전:
출력을 수동으로 확인한다.

후:

def test_startup_analyzer():
    result = startup_analyzer(pitch="We're building AI for dog grooming...")
    assert 1  0
    assert len(result.weaknesses) > 0

실제 테스트는 어설션이 포함된 내 테스트 스위트에 존재한다.

한 줄로 모델 교체하기

전:
각 모델마다 별도의 프롬프트 튜닝이 필요했다(GPT‑4, Claude, Gemini 등).

후:

# Swap models
lm = dspy.LM("openai/gpt-4o-mini")
# lm = dspy.LM("anthropic/claude-3-sonnet")
# lm = dspy.LM("gemini/gemini-2.0-flash")

dspy.configure(lm=lm)

코드는 동일하고 모델만 바뀐다. DSPy가 프롬프트 변환을 담당한다.

옵티마이저가 튜닝을 담당

프롬프트를 직접 손볼 대신, 나는 DSPy에 좋은 출력 예시를 제공하고 최적의 프롬프트를 찾아 달라고 한다:

optimizer = BootstrapFewShot(metric=my_metric, max_bootstrapped_demos=4)
optimized = optimizer.compile(StartupAnalyzer(), trainset=train_examples)

DSPy는 실험을 수행하고, 작동하는 예시를 찾으며, 프롬프트를 만든다. 나는 결과만 검토하면 된다.

패러다임 전환

  • 이전 방식: LLM은 영어로 대화하는 마법 상자이며, 성공은 프롬프트 기술에 달려 있다.
  • DSPy 방식: LLM은 함수 호출이다. 인터페이스만 선언하면 프레임워크가 구현을 담당한다.

이는 코드베이스 전체에 원시 SQL 쿼리를 흩뿌리는 것과 ORM을 사용하는 차이와 같다: 전자는 깨지기 쉽고, 타입이 없으며, 리팩터링이 어렵다; 후자는 구조화되고, 테스트 가능하며, 유지보수가 쉽다.

더 깊이 파고들기

나는 DSPy로 구축하는 전체 가이드를 작성했다—실용적인 장, 실제 코드, 그리고 힘들게 얻은 교훈들. 이 가이드는 Harmless DSPy 라는 이름이며, 1장은 무료이니 당신에게 맞는지 확인해 볼 수 있다.

DSPy는 Omar Khattab와 Stanford NLP 팀이 개발했으며, 오픈 소스이고 활발히 유지보수되고 있다. 이 도구는 내가 LLM을 활용하는 방식을 진정으로 바꾸어 놓았다.

0 조회
Back to Blog

관련 글

더 보기 »