- 공유 링크 만들기
- X
- 이메일
- 기타 앱
요즘 주변 개발자들이랑 이야기하다 보면 AI 바이브 코딩 이야기가 정말 자주 나와요. 나도 뭐, 남 이야기하듯 할 처지는 아니고요. 퇴근하고 커피 한 잔 내려놓고 앉아서 GPT API로 업무 자동화 도구도 만들어보고, 작은 사이드 프로젝트도 끄적거리고 있습니다. 재미있어요. 확실히 예전이랑 개발하는 감각이 달라졌거든요.
그런데 하다 보니 자꾸 걸리는 게 하나 있더라고요. 바로 프롬프트 최적화예요. 처음에는 “프롬프트 좀 잘 쓰면 되겠지” 싶었는데, 이게 생각보다 만만하지 않습니다. 같은 작업인데도 모델 버전이 바뀌면 결과가 달라지고, 입력 문장이 조금만 길어져도 답변 톤이 흔들리고, 예외 케이스 하나 들어오면 갑자기 엉뚱한 말을 하기도 하고요. 솔직히 말하면, 프롬프트 파일 열어놓고 한 줄 고쳤다가 다시 돌리고, 또 고치고, 또 돌리는 그 시간이 은근히 사람을 지치게 하더라고요.
그러다가 알게 된 게 DSPy였습니다. 스탠포드 쪽에서 나온 프레임워크인데, 느낌을 쉽게 말하면 이래요. 사람이 프롬프트를 손으로 계속 다듬는 대신, 프로그램처럼 정의해두고 DSPy가 알아서 더 나은 프롬프트 구조와 예시를 찾아주는 방식입니다. 프롬프트를 그냥 문장으로 보는 게 아니라, 어느 정도 소프트웨어 구성 요소처럼 다루는 거죠.
20년 가까이 개발을 해오면서 이런저런 도구를 많이 써봤잖아요. 처음엔 다 좋아 보이다가 막상 실무에 넣으면 “아, 이건 데모용이었구나” 싶은 것들도 많았고요. 그런데 DSPy는 직접 써보니 생각보다 꽤 현실적이었습니다. 오늘은 그걸 좀 편하게 이야기해보려고 해요. 문서 요약 수준 말고, 제가 실제로 어디서 막혔고, 어떻게 써봤고, 뭐가 좋았고, 뭐가 살짝 귀찮았는지 그런 쪽으로요.
내가 DSPy에 관심을 갖게 된 진짜 이유
사실 처음에는 좀 삐딱하게 봤습니다. “프롬프트 엔지니어링을 프레임워크로 한다고? 그게 되나?” 이런 마음이었어요. 저도 그동안 LangChain, LlamaIndex로 RAG 시스템도 만들어봤고, 사내 문서 검색 봇도 붙여봤고, 고객 문의 자동 분류 같은 것도 해봤거든요. 그러다 보니 프롬프트가 얼마나 예민한지 몸으로 알고 있었습니다.
예를 들어 고객 리뷰를 요약하는 기능 하나만 봐도 그래요. “좋은 요약”이라는 기준이 생각보다 애매합니다. 어떤 사람은 짧게 한 줄이면 좋다고 하고, 어떤 사람은 불만 포인트를 꼭 포함해야 한다고 하고, 운영팀은 CS 처리용으로 감성 분류까지 같이 보고 싶다고 합니다. 그러면 개발자는 프롬프트에 이런저런 조건을 계속 붙이게 돼요.
처음에는 이런 식이죠.
다음 고객 리뷰를 긍정, 부정, 중립 중 하나로 분류하고 핵심 내용을 한 줄로 요약해줘. 응답은 JSON 형식으로 반환해줘.
여기까지는 괜찮아 보입니다. 그런데 실제 리뷰가 들어오면 슬슬 문제가 생겨요.
가격은 저렴해서 좋았는데 마감이 조금 아쉽네요. 배송은 빨랐어요.
이런 문장은 긍정일까요, 부정일까요, 중립일까요? 사람도 약간 고민하잖아요. 모델도 마찬가지입니다. 어떤 날은 긍정이라고 하고, 어떤 날은 중립이라고 하고, 프롬프트에 “단점이 있으면 부정으로 분류해”라고 써두면 또 너무 쉽게 부정으로 몰아갑니다. 뭐랄까, 프롬프트가 점점 누더기처럼 변해가는 느낌이 들어요.
DSPy는 이 지점에서 꽤 재미있는 접근을 합니다. “프롬프트 문장을 네가 직접 완벽하게 쓰려고 하지 말고, 입력과 출력의 좋은 예시를 주고, 평가 기준을 정해. 그러면 내가 조합을 찾아볼게.” 이런 느낌이에요. 개발자 입장에서는 훨씬 익숙합니다. 테스트 케이스 만들고, metric 정하고, optimizer 돌리는 흐름이니까요.
처음 예제 코드를 돌렸을 때 살짝 웃겼어요. “어? 이게 진짜 되네?” 싶은 기분이었거든요. 막 대단한 마법이라기보다는, 우리가 원래 개발할 때 하던 방식을 LLM 프롬프트 쪽으로 끌고 온 느낌이었습니다. 그래서 더 마음에 들었고요.
실제로 해본 예제, 쇼핑몰 리뷰 감성 분석과 요약
제가 최근에 손댔던 건 쇼핑몰 리뷰 감성 분석과 리뷰 요약을 같이 처리하는 작은 파이프라인이었습니다. 운영팀에서 리뷰를 빠르게 훑어보고 싶어 했고, 특히 부정 리뷰는 빨리 캐치해서 CS 쪽으로 넘기고 싶어 했어요. 흔한 요구사항이죠. 흔한데, 막상 만들면 은근히 손이 많이 갑니다.
처음에는 그냥 GPT-4 터보에 직접 프롬프트를 던졌습니다. 대충 이런 식이었어요.
리뷰를 읽고 감성을 긍정, 부정, 중립 중 하나로 분류해줘.
그리고 핵심 내용을 20자 이내로 요약해줘.
반드시 JSON 형식으로 응답해줘.
리뷰: {review}
처음 몇 개는 잘 나옵니다. 그래서 “오, 이 정도면 되겠는데?” 싶죠. 그런데 실제 데이터는 늘 사람을 배신합니다. 짧은 리뷰, 비꼬는 리뷰, 장점과 단점이 같이 있는 리뷰, 오타가 많은 리뷰, 감탄사만 있는 리뷰가 섞여 들어와요.
| 리뷰 예시 | 수동 프롬프트에서 자주 나온 문제 | 내가 기대한 처리 |
|---|---|---|
| 배송은 빠른데 제품 마감이 별로예요. | 긍정 또는 부정으로 들쭉날쭉 | 중립 또는 부정에 가까운 중립 |
| 음... 그냥 그래요. | 긍정으로 분류하는 경우 있음 | 중립 |
| 싸서 샀는데 싼 이유가 있네요. | 농담처럼 해석해서 중립 처리 | 부정 |
| 재구매합니다. 말 다 했죠. | 요약이 너무 장황해짐 | 재구매 의사 있음 |
이런 케이스가 쌓이면 프롬프트에 조건을 계속 추가하게 됩니다. “비꼬는 표현은 부정으로 처리해라”, “장단점이 섞이면 전체 톤을 판단해라”, “요약은 명사형으로 끝내라” 같은 식으로요. 그런데 그렇게 길어진 프롬프트는 또 다른 문제를 만들어요. 토큰도 늘고, 응답도 무거워지고, 유지보수하기도 싫어집니다. 나중에는 내가 쓴 프롬프트인데도 읽기 싫어져요.
그래서 이걸 DSPy로 바꿔봤습니다. 흐름은 생각보다 단순했어요.
- 데모 데이터를 직접 만들었습니다. 리뷰, 감성 라벨, 요약이 들어간 예시를 10개 정도 준비했어요.
- DSPy Module을 정의했습니다. 저는 중간 추론이 도움이 될 것 같아서
dspy.ChainOfThought를 썼습니다. - optimizer를 돌렸습니다. 처음에는 무난하게
BootstrapFewShotWithRandomSearch를 사용했어요. - 결과를 저장해두고, 같은 테스트셋으로 기존 수동 프롬프트와 비교했습니다.
아래는 핵심만 남긴 코드입니다. 실제 프로젝트에서는 로깅, 예외 처리, JSON 파싱 검증 같은 걸 더 붙였고요. 여기서는 흐름만 보시면 됩니다.
import dspy
from dspy.teleprompt import BootstrapFewShotWithRandomSearch
# GPT-4 터보 설정
lm = dspy.OpenAI(model='gpt-4-turbo', max_tokens=200)
dspy.settings.configure(lm=lm)
# 모듈 정의
class ReviewAnalyzer(dspy.Module):
def __init__(self):
super().__init__()
self.chain = dspy.ChainOfThought("review -> sentiment, summary")
def forward(self, review):
return self.chain(review=review)
# 학습 데이터
trainset = [
dspy.Example(
review="배송이 생각보다 빨랐고 상품도 괜찮아요.",
sentiment="긍정",
summary="배송과 상품 만족"
).with_inputs("review"),
dspy.Example(
review="가격은 저렴한데 마감이 별로예요.",
sentiment="중립",
summary="저렴하지만 마감 아쉬움"
).with_inputs("review"),
dspy.Example(
review="싸서 샀는데 싼 이유가 있네요.",
sentiment="부정",
summary="품질 불만"
).with_inputs("review"),
# 실제로는 총 10개 정도 사용
]
# 옵티마이저 실행
teleprompter = BootstrapFewShotWithRandomSearch(
metric=dspy.evaluate.answer_exact_match
)
compiled_program = teleprompter.compile(
ReviewAnalyzer(),
trainset=trainset
)
# 최적화된 모듈 저장
compiled_program.save("optimized_reviewer.json")
코드만 보면 별거 없어 보이죠. 그런데 이게 은근히 기분이 묘합니다. 예전에는 내가 프롬프트 문장을 계속 붙잡고 씨름했다면, 이제는 “이런 입력에는 이런 출력이 맞아”라는 기준을 예시로 정리하고, 나머지는 optimizer에게 맡기는 식이거든요. 개발자로서 훨씬 마음이 편했습니다.
테스트는 리뷰 100개 정도로 해봤습니다. 아주 엄밀한 논문식 평가는 아니고, 실무에서 이 정도면 쓸 수 있겠다는 기준으로 봤어요. 그래도 차이는 꽤 분명했습니다.
| 비교 항목 | 수동 프롬프트 | DSPy 최적화 후 |
|---|---|---|
| 감성 분류 정확도 | 약 82% | 약 90% |
| 중립 리뷰 처리 | 흔들림이 꽤 있음 | 훨씬 안정적 |
| 프롬프트 길이 | 약 500 토큰 | 약 300 토큰 |
| 초기 개발 시간 | 거의 하루 | 약 2시간 |
| 유지보수 느낌 | 프롬프트 문장 수정 중심 | 예시와 metric 관리 중심 |
정확도가 8% 정도 오른 것도 좋았지만, 저는 사실 다른 부분이 더 마음에 들었어요. 중립 리뷰처럼 애매한 케이스에서 답변이 덜 흔들린다는 점이었습니다. 실무에서는 평균 성능도 중요하지만, 애매한 구간에서 얼마나 이상한 소리를 덜 하느냐가 더 중요할 때가 많거든요.
써보면서 느낀 DSPy의 진짜 장점
DSPy를 써보면서 제일 좋았던 건, 프롬프트 작업을 약간 더 개발답게 할 수 있다는 점이었습니다. 이 표현이 좀 이상하게 들릴 수도 있는데, 정말 그래요. 기존에는 프롬프트를 긴 글짓기처럼 다뤘다면, DSPy에서는 입력, 출력, 예시, 평가 기준을 분리해서 생각하게 됩니다.
그러니까 머릿속이 조금 정리됩니다. “이 문장을 어떻게 더 예쁘게 쓸까?”가 아니라, “내가 원하는 결과를 평가할 기준은 뭐지?”, “대표 예시는 충분히 다양하게 들어갔나?”, “이 케이스는 중립으로 보는 게 맞나?” 같은 질문을 하게 돼요. 저는 이게 꽤 큰 차이라고 봅니다.
프롬프트를 감으로 만지는 시간이 줄어듭니다
예전에는 프롬프트 하나 수정하면 결과가 좋아진 건지 나빠진 건지 애매할 때가 많았습니다. 몇 개 샘플에서는 좋아졌는데 다른 샘플에서는 망가지고, 그러다 보면 결국 감으로 결정하게 돼요. “음, 이 정도면 괜찮겠지” 하고요.
DSPy를 쓰면 적어도 optimizer가 어떤 기준을 보고 개선하려고 했는지가 남습니다. 물론 완벽하진 않아요. 그래도 사람이 직접 문장 바꿔가며 감으로 튜닝하는 것보다는 훨씬 낫습니다.
팀 작업에 더 잘 맞습니다
이 부분도 은근히 중요합니다. 혼자 사이드 프로젝트 할 때는 프롬프트가 좀 지저분해도 그냥 넘어갈 수 있어요. 그런데 팀에서 같이 쓰는 기능이면 이야기가 달라집니다. 누가 프롬프트를 수정했는지, 왜 수정했는지, 어떤 케이스를 개선하려고 했는지 추적이 되어야 하거든요.
DSPy 방식으로 가면 최소한 이런 식으로 나눌 수 있습니다.
- Signature: 입력과 출력 구조 정의
- Module: 태스크 처리 방식 정의
- trainset: 대표 예시 관리
- metric: 평가 기준 관리
- compiled program: 최적화 결과 저장
이렇게 나눠두면 코드 리뷰할 때도 대화가 편해집니다. “프롬프트 문장이 좀 애매한데요”가 아니라 “이 예시가 실제 운영 데이터랑 맞나요?”, “metric이 요약 품질을 제대로 반영하나요?” 같은 이야기를 하게 되거든요. 훨씬 건강한 논의가 됩니다.
DSPy 쓰면서 삽질한 부분과 내 나름의 꿀팁
물론 처음부터 매끄럽게 된 건 아닙니다. 저도 꽤 삽질했어요. 특히 문서만 보고 따라 할 때는 “아, 이 정도면 되겠지” 하고 대충 넘어갔다가 결과가 이상하게 나오는 경우가 있었습니다. 몇 가지는 꼭 알고 시작하면 좋겠습니다.
데모 데이터는 많다고 좋은 게 아니더라고요
처음에는 욕심이 나서 예시를 많이 넣고 싶었습니다. 개발자 마음이 그렇잖아요. 케이스 많이 넣으면 더 잘하겠지 싶고요. 그런데 실제로 해보니 꼭 그렇지는 않았습니다. 너무 비슷한 예시를 많이 넣으면 오히려 특정 패턴에 끌려가는 느낌이 있었습니다.
제 기준으로는 10개에서 15개 정도가 시작하기 좋았습니다. 대신 다양해야 합니다. 긍정, 부정, 중립을 골고루 넣고, 애매한 문장도 꼭 섞어야 해요. 특히 실무에서 자주 사고 치는 모서리 케이스를 넣는 게 중요합니다.
| 데모 데이터 유형 | 예시 | 넣는 이유 |
|---|---|---|
| 명확한 긍정 | 배송 빠르고 제품도 마음에 들어요. | 기본 패턴 학습 |
| 명확한 부정 | 받자마자 고장 나서 반품합니다. | 불만 표현 인식 |
| 장단점 혼합 | 가격은 좋은데 품질은 아쉬워요. | 중립 또는 복합 감성 처리 |
| 비꼬는 표현 | 와, 이 가격에 이 품질이라니 놀랍네요. | 문맥 판단 보강 |
| 짧은 리뷰 | 별로. | 짧은 입력 대응 |
사실 좋은 데모 데이터 만드는 일이 살짝 귀찮습니다. 그런데 이건 피할 수 없는 비용 같아요. 이상한 프롬프트를 붙잡고 세 시간 고민하는 것보다, 좋은 예시 10개를 차분히 만드는 게 훨씬 생산적이었습니다.
optimizer는 무조건 센 걸 고를 필요가 없었습니다
DSPy에는 여러 optimizer가 있습니다. 대표적으로 BootstrapFewShot, BootstrapFewShotWithRandomSearch, MIPROv2 같은 것들이 있어요. 이름만 보면 뭔가 제일 최신이고 강해 보이는 걸 쓰고 싶잖아요. 저도 처음에는 그랬습니다.
그런데 데이터가 작고 태스크가 단순하면 너무 복잡한 optimizer가 꼭 필요하진 않았습니다. 제 리뷰 분석 케이스에서는 BootstrapFewShotWithRandomSearch가 가장 무난했습니다. 속도도 괜찮고, 비용도 크게 부담스럽지 않았어요.
| optimizer | 내가 느낀 용도 | 주의할 점 |
|---|---|---|
| BootstrapFewShot | 가볍게 시작할 때 좋음 | 복잡한 케이스에서는 개선 폭이 작을 수 있음 |
| BootstrapFewShotWithRandomSearch | 작은 데이터셋에서 꽤 균형 좋음 | 여러 번 돌리면 API 비용이 늘어남 |
| MIPROv2 | 지시문까지 더 적극적으로 최적화하고 싶을 때 | 시간과 비용이 더 들어감 |
제가 느끼기에는, 처음부터 거창하게 가지 않아도 됩니다. 작은 trainset으로 가볍게 돌려보고, 성능 차이가 보이면 그때 optimizer를 바꿔보는 게 낫습니다. 괜히 처음부터 크게 잡으면 기다리다가 지치고, 비용 보고 마음이 식을 수도 있어요.
metric을 대충 잡으면 DSPy도 대충 최적화합니다
이건 정말 중요합니다. DSPy가 똑똑해 보여도 결국 내가 준 metric을 보고 움직입니다. metric이 허술하면 결과도 허술해져요. 감성 분류처럼 정답이 명확한 태스크는 answer_exact_match 같은 방식으로 시작해도 괜찮습니다. 그런데 요약 품질까지 같이 보려면 이야기가 달라집니다.
예를 들어 요약이 “배송 만족”이어도 맞고, “빠른 배송”이어도 맞을 수 있잖아요. 그런데 exact match만 쓰면 둘 중 하나는 틀렸다고 판단될 수 있습니다. 그래서 저는 감성 라벨은 정확히 맞는지 보고, 요약은 키워드 포함 여부를 같이 보는 간단한 커스텀 metric을 만들었습니다.
def review_metric(example, pred, trace=None):
sentiment_ok = example.sentiment == pred.sentiment
expected_keywords = example.summary.split()
summary_ok = any(keyword in pred.summary for keyword in expected_keywords)
return sentiment_ok and summary_ok
물론 이 코드가 완벽하다는 건 아닙니다. 실제 운영에서는 더 정교하게 봐야 합니다. 그래도 처음 실험할 때는 이 정도만 해도 exact match 하나만 쓰는 것보다는 훨씬 현실에 가까웠습니다. 뭐랄까, 모델에게 “내가 진짜 중요하게 보는 게 이거야”라고 알려주는 느낌이었어요.
기존 방식이랑 비교하면 뭐가 다를까
저도 LangChain이나 LlamaIndex를 안 써본 게 아닙니다. 둘 다 여전히 좋은 도구고, 특히 RAG 구성할 때는 많이 쓰게 됩니다. 다만 프롬프트 최적화 관점에서는 DSPy가 조금 다른 결을 가지고 있습니다.
LangChain은 체인을 구성하고, 각 단계에 프롬프트를 넣고, 흐름을 연결하는 데 강합니다. 사람이 설계한 파이프라인을 잘 실행하게 해주는 쪽에 가깝죠. 반면 DSPy는 “이 태스크를 이렇게 정의했으니, 어떤 프롬프트와 예시 조합이 좋은지 찾아보자”에 더 가깝습니다.
| 구분 | 기존 수동 프롬프트 방식 | DSPy 방식 |
|---|---|---|
| 작업 중심 | 프롬프트 문장 작성 | 입출력 구조와 예시 정의 |
| 개선 방식 | 사람이 직접 수정 | optimizer로 탐색 |
| 평가 기준 | 대체로 수동 확인 | metric 기반 평가 |
| 팀 협업 | 프롬프트 수정 의도 공유가 어려움 | 예시와 metric 중심으로 논의 가능 |
| 초기 진입 | 쉽게 시작 가능 | 개념을 조금 익혀야 함 |
비유하자면 이렇습니다. 수동 프롬프트 방식은 여행지에서 맛집을 찾을 때 블로그 글을 계속 뒤지는 느낌이고, DSPy는 내가 좋아하는 취향을 몇 개 알려주고 추천 알고리즘을 돌리는 느낌입니다. 물론 추천 알고리즘도 틀릴 때가 있죠. 그래도 매번 처음부터 검색하는 것보다는 훨씬 편합니다.
단점도 있습니다. DSPy는 처음 배울 때 약간 낯설어요. 특히 기존에 프롬프트를 그냥 문자열로만 다뤘다면 Signature, Module, Optimizer, Metric 같은 개념이 처음에는 조금 번거롭게 느껴질 수 있습니다. 그리고 최적화 과정에서 API 호출이 발생하니 비용도 생각해야 합니다.
제가 테스트했을 때는 10개 정도의 데모 데이터로 한 번 최적화하는 데 GPT-4 터보 기준으로 대략 0.5달러에서 1달러 정도 나왔습니다. 물론 설정과 반복 횟수에 따라 달라질 수 있고요. 엄청 큰돈은 아니지만, 아무 생각 없이 여러 번 돌리면 은근히 쌓입니다. 특히 회사 계정이 아니라 개인 카드 물려놓고 실험할 때는 마음이 조금 예민해집니다. 하하.
내가 실제 프로젝트에 적용할 때 정한 기준
모든 프롬프트를 DSPy로 바꿀 필요는 없다고 봅니다. 단순히 문장 하나 바꿔주는 정도, 예를 들면 “이 문장을 더 공손하게 바꿔줘” 같은 기능은 그냥 일반 프롬프트로도 충분합니다. DSPy가 빛나는 건 반복적으로 쓰이고, 결과 품질이 중요하고, 예외 케이스가 자주 나오는 작업이었어요.
저는 대충 이런 기준으로 판단합니다.
- 같은 태스크를 계속 반복해서 호출하는가
- 입력 데이터의 형태가 다양하고 예외 케이스가 많은가
- 정답 또는 좋은 답변의 기준을 어느 정도 정의할 수 있는가
- 프롬프트 변경 후 성능이 좋아졌는지 측정하고 싶은가
- 팀 단위로 프롬프트를 관리해야 하는가
이 중에서 세 개 이상 해당되면 DSPy를 검토해볼 만하다고 봅니다. 특히 분류, 추출, 요약, 질의응답, RAG 후처리 같은 작업에는 잘 맞았습니다. 반대로 창의적인 카피 작성처럼 정답 기준이 흐릿하고 사람 취향이 크게 들어가는 작업은 metric 설계가 더 어렵기 때문에 조금 조심해야 하고요.
이런 개발자라면 DSPy 한 번 써봐도 좋습니다
솔직히 말하면, AI 바이브 코딩을 하는 개발자라면 DSPy는 한 번쯤 만져볼 만합니다. 막 “이거 안 쓰면 뒤처진다” 이런 식으로 말하고 싶진 않아요. 그런 말은 좀 피곤하잖아요. 다만 프롬프트를 계속 손으로 고치면서 찜찜함을 느껴본 사람이라면, 꽤 반가운 도구가 될 가능성이 큽니다.
특히 이런 분들에게 잘 맞을 것 같아요.
- 여러 개의 프롬프트를 관리하다가 파일 이름만 봐도 피곤해지는 개발자
- 프롬프트 수정 전후 성능을 감이 아니라 숫자로 보고 싶은 개발자
- 고객 리뷰, 문의, 문서 같은 비정형 텍스트를 자주 다루는 개발자
- 팀에서 공통으로 쓸 프롬프트 파이프라인을 만들고 싶은 개발자
- LLM 기능을 실험 수준이 아니라 제품 기능으로 조금 더 안정화하고 싶은 개발자
저는 요즘 새로 만드는 LLM 기능에는 DSPy를 기본 후보에 올려두고 봅니다. 예전에는 “프롬프트 엔지니어링은 감각의 영역이다”라는 말에 어느 정도 동의했어요. 그런데 지금은 생각이 조금 바뀌었습니다. 감각도 필요하지만, 그 감각을 계속 유지보수 가능한 구조로 바꾸는 게 더 중요하다고 봅니다. 말하자면 프롬프트 엔지니어링도 결국 소프트웨어 공학 쪽으로 가고 있다는 느낌입니다.
물론 DSPy가 모든 걸 해결해주진 않습니다. 좋은 예시는 여전히 사람이 만들어야 하고, metric도 고민해야 하고, 비용도 봐야 합니다. 그래도 프롬프트를 혼자 붙잡고 “왜 오늘은 또 이상하게 나오지?” 하고 중얼거리는 시간을 줄여주는 건 분명합니다. 그 정도만 해도 저는 꽤 큰 가치가 있다고 봐요.
이 글은 프롬프트를 조금 더 체계적으로 관리하고 싶은 개발자, AI 바이브 코딩을 하면서 결과 품질 때문에 고민해본 개발자, 그리고 LLM 기능을 실무에 넣으려는 분들이 읽으면 특히 도움이 될 것 같습니다. 저도 아직 계속 실험 중이지만, DSPy는 적어도 “한번 써보고 판단해도 늦지 않은 도구”라고 말하고 싶어요. 써보면 아마 이런 생각이 들 겁니다. 아, 프롬프트도 이제 그냥 문장이 아니라 코드처럼 다뤄야 하는 시대가 왔구나, 하고요.
댓글
댓글 쓰기