Context Engineering With DSPy

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

DSPy를 활용한 컨텍스트 엔지니어링의 핵심은 과제를 입출력 시그니처로 정의하고, 예시와 평가를 바탕으로 프롬프트·모델·실행 전략을 반복 최적화하는 것이다.

📌 핵심 요점

1. 과제 정의와 구현을 분리한다. DSPy의 타입이 있는 시그니처는 입력과 원하는 출력을 명시한다. 이를 유지하면서 모델이나 추론 전략을 바꿀 수 있지만, 모델별 재최적화와 호환성 확인은 필요하다.
2. 긴 지시문보다 좋은 예시와 평가 기준이 중요하다. 독스트링은 초기 지시문이며 최종 프롬프트로 고정되지 않는다. 도메인 전문가의 지식을 예제로 모으고, 학습·검증 데이터와 최종 홀드아웃을 구분해야 한다.
3. 판정기를 먼저 개선해 정답이 없는 재작성 작업을 평가한다. 실습에서 판정기는 최적화 전 정확도 80%에서 20개 평가 예제 기준 100%로 개선됐다. 휴머나이저의 판정기 통과율은 초기 10%에서 최적화 후 70%로 높아졌다. 두 수치는 서로 다른 지표다.
4. 구조화된 출력과 실행 전략을 함께 다룬다. 출력 타입을 정의하면 파싱 부담을 줄일 수 있고, 모듈에는 모델 호출과 코드 검증을 결합할 수 있다. RLM은 코드와 하위 에이전트로 긴 문맥과 반복 작업을 처리하며, DSPy Flex는 모듈 조합과 작업 분해 방식까지 탐색한다.
5. 같은 평가 체계로 모델·후보 선택의 효과와 비용을 비교한다. 실습에서는 여러 후보 중 선택해 점수가 75%가 됐고, 이어 기존 Gemini 모델을 적용한 예에서는 85%로 높아졌다. 추가 성능의 가치와 비용·지연 시간·운영 신뢰성을 함께 판단해야 한다.

🧩 배경과 문제 정의

• 문체를 규칙으로 설명해도 모델이 따르지 않거나, 작성자가 자신의 습관과 뉘앙스를 빠뜨려 원하는 결과를 얻지 못한다.
• 특정 모델에 맞춰 수작업으로 만든 프롬프트는 모델이 바뀌면 효과가 달라진다. 과제 정의를 유지하면서 모델과 실행 전략을 교체할 수 있는 구조가 필요하다.
• DSPy는 입력·출력과 과제를 코드로 정의하고 실행·최적화를 구성한다. 다만 좋은 예시 데이터와 평가 기준을 마련하는 작업은 여전히 필요하다.
• 실습은 AI 생성 문장을 자연스러운 글로 바꾸고 AI 탐지기로 평가하는 파이프라인을 통해 구조화된 출력의 장점과 초기 성능의 한계를 살핀다.

🕒 시간순 섹션별 상세정리

1. 문체 규칙만으로는 지시 불이행과 숨은 뉘앙스를 해결하기 어렵다

• 규칙이 존재한다고 모델이 반드시 따르는 것은 아니다. Claude가 제목 위에 작은 대문자 제목을 반복해서 붙이는 사례처럼, 원치 않는 표현을 없애기 위해 같은 지시를 여러 번 강조해야 할 수 있다. [01:52]
• 작성자가 자신의 문체를 설명해도 스스로 인식하지 못하는 특징은 빠진다. 이 설명을 받은 사람이 글을 쓰고 다시 수정받는 과정에서는 누락된 뉘앙스를 뒤늦게 찾아 보완해야 한다. [02:26]

2. 모델에 종속된 프롬프트 대신 과제와 주변 기반을 유지한다

• 수작업 프롬프트는 취약한 문자열에 의존한다. GPT 3.5에서 GPT 4로 바뀌었을 때처럼, 이전 모델에서 효과가 있던 규칙과 표현이 새 모델에서는 통하지 않을 수 있다. [04:33]
• DSPy를 사용해도 좋은 프롬프트를 만들기 위해 필요했던 주변 작업은 남는다. 대신 프롬프트 문구를 직접 관리하는 부담을 줄이고, 과제를 수행하는 기반을 모델 사이에서 옮길 수 있다. [04:51]

3. 타입이 있는 시그니처로 과제와 구현을 분리한다

• DSPy의 인터페이스는 ChatGPT 이전에 만들어진 뒤에도 크게 바뀌지 않았다. 타입이 있는 입력과 출력으로 과제를 정의하는 시그니처는 긴 Markdown 문서나 문자열보다 읽기 쉽고, 컨텍스트 엔지니어링 개념을 코드로 표현하기에도 적합하다. [06:00]
• 2년 전에 작성한 프로그램도 모델을 바꾸고 다시 최적화하면서 사용할 수 있었다. 과제 정의는 유지하고 그 아래 구현을 바꾸는 방식이다. [06:14]

4. Compound는 실행·최적화·버전 비교를 관리하는 기반을 준비한다

• Compound는 Dropbox, Shopify, Figma 등 DSPy를 사용하는 기업과 협업하며, 시그니처를 유지한 채 새로운 추론 전략, 도구 사용, 제공업체별 프롬프트 캐싱 등을 지원하는 방향으로 DSPy를 발전시키고 있다. [07:08]
• 프로그램을 플랫폼에 올려 호출하고 실행을 확인하며, 최적화로 생성한 새 버전을 기존 버전과 비교한 뒤 승격 여부를 결정하는 제품을 준비하고 있다. 관련 내용을 향후 4~6주 안에 공유할 계획이다. [07:34]

5. 모델 설정과 API 연결을 간단한 호출로 추상화한다

• dspy.LM을 이용한 간단한 설정으로 API 키와 제공업체가 요구하는 호출 형식을 연결한다. 모델을 교체할 때는 모델을 지정하는 문자열을 바꾸는 방식으로 기반 코드의 부담을 줄인다. [10:18]
• 방송 기준 전날 LiteLLM 의존성을 제거해 DSPy가 더 가벼워졌다는 설명이 나온다. 설정한 모델은 전역으로 지정하거나 직접 호출할 수 있다. [10:50]

6. 독스트링은 과제를 정의하는 출발점이며 최적화를 대신하지 않는다

• dspy.Signature를 상속한 클래스의 독스트링은 수행할 과제를 설명하는 초기 지시문이다. 최적화 과정에서 달라질 수 있으므로, 처음 작성한 문구가 최종 프롬프트로 고정되는 것은 아니다. [11:57]
• 기존의 긴 문서가 있다면 instructions 매개변수로 넣어 시작할 수도 있다. 짧은 독스트링과 워크플로를 상세히 담은 긴 설명을 비교한 특정 실험에서는 양쪽 모두 최적화가 필요했고, 긴 설명만으로 평가 기준이 충분히 반영되지는 않았다. [13:10]

7. 입력·출력 필드로 변환 과제와 탐지 과제를 명시한다

• 문장 변환 시그니처는 AI 생성 텍스트 하나를 입력받고 변환한 텍스트 하나를 출력한다. InputField와 OutputField로 이를 선언하면 목적과 데이터 흐름을 쉽게 읽을 수 있어 스크립트나 CLI 구성에도 유용하다. [14:33]
• 독스트링 안에서 프롬프트 문구를 지나치게 조정하고 있다면 접근을 점검할 신호다. 필요한 정보를 먼저 넣고, 이후 결과를 통해 더 알아가는 방식으로 시작할 수 있다. [14:57]

8. 모듈은 예측 호출과 코드 검증을 결합한 실행 전략이다

• 시그니처가 입력과 출력의 명세라면 Predict는 입력에서 출력을 생성하는 기본 모듈이다. ChainOfThought 같은 모듈로 추론 전략을 추가할 수도 있으며, 실습자의 경험상 상당수 작업은 기본 Predict만으로도 구성할 수 있다. [17:01]
• 모듈에는 프롬프트뿐 아니라 코드도 포함할 수 있다. 예를 들어 생성한 SQL이 실제 데이터베이스에서 유효한지 코드로 확인하는 절차까지 하나의 실행 시점 전략으로 묶을 수 있다. [17:30]

9. 좋은 예시를 모으고 도메인 지식을 제어 흐름과 분리한다

• DSPy가 데이터 준비를 대신 해결해 주지는 않는다. 합성 데이터를 생성할 수도 있지만, 좋은 예시를 찾거나 직접 작성하고 도메인 전문가와 함께 확보하는 작업이 여전히 필요하다. [18:47]
• 도메인 전문가가 지식을 반영하려고 코드와 프롬프트를 직접 수정하면 코드 충돌과 구현 개입이 늘어날 수 있다. 전문가가 예시를 자유롭게 작성하는 공간을 프로그램의 논리·제어 흐름과 분리하는 접근이 유용하다. [19:37]

10. 구조화된 출력으로 파싱 부담을 줄이고 복잡한 스키마를 다룬다

• 변환기에 입력 텍스트를 전달하면 시그니처에 정의한 출력 필드로 결과를 받는다. 원하는 객체 형식을 얻기 위해 별도 최적화부터 작성하기보다, 출력 타입과 기본 클래스를 정의하는 것만으로 처리할 수 있다는 장점이 있다. [22:06]
• 실습에서는 변환한 텍스트를 추출하기 위한 정규식이나 파싱 코드, 특정 접두사를 붙이라는 지시가 필요하지 않았다. 에이전트가 직접 프로그램을 작성하는 상황에서도 이런 파싱 작업을 줄이는 것이 DSPy를 사용할 이유가 된다. [22:40]

11. 결정 모델은 출력 타입 조건을 충족하면 같은 시그니처로 교체할 수 있다

• TypeSafe의 결정 모델은 텍스트를 생성한 뒤 파싱하는 단계를 건너뛰고 구조화된 결과를 직접 제공하는 방식으로 드러난다. DSPy에서도 이러한 결정 모델을 사용할 수 있다. [25:18]
• 다만 출력은 해당 모델의 부동소수점 기반 출력과 호환돼야 한다. 불리언이나 선택형 출력은 가능하지만 문자열 출력을 함께 요구하면 작동하지 않는다. 호환되는 시그니처는 일반 언어 모델에도 사용할 수 있어, 결정 모델의 성능이 부족하면 모델 문자열을 바꿔 비교할 수 있다. [25:52]

12. 속도와 비용의 변화는 시도할 과제의 범위를 넓힌다

• TypeSafe와 같은 접근이 빠르고 저렴하다는 인식을 얻으면서, 작은 AI 함수를 실제 제품에 넣으려는 관심이 커졌다. 비슷한 작업을 이전에도 DSPy로 할 수 있었더라도, 이를 시도하게 만드는 계기가 달라졌다는 해석이다. [26:15]
• 좋은 모델의 징후로 사용자의 목표 수준을 높이고 이전에는 고려하지 않던 작업을 시도하게 한다는 기준이 드러난다. AI 다큐멘터리 제작도 새 모델을 시험한 뒤 기존 Opus로 가능했음을 발견한 사례다. [27:01]

13. 초기 변환 결과는 탐지기를 통과하지 못한다

• 예시 문장들을 변환한 뒤에도 AI 탐지 결과가 모두 참으로 나와, 초기 문장 변환기는 아직 탐지기를 통과할 만큼 잘 작동하지 않는다. 적은 코드로 파이프라인을 구성한 것과 원하는 품질을 얻는 것은 별개다. [27:48]
• 생성에 적합한 모델과 판정에 적합한 모델을 각각 바꿔 다시 실행할 수 있다. 다만 이 시점에는 다른 모델로 문제가 해결됐다는 결과가 제시되지는 않는다. [27:59]

14. 생성된 프롬프트를 확인할 수 있으며 기본 형식도 바뀐다

• 실행 이력을 검사하면 DSPy가 생성한 시스템 메시지와 프롬프트 형식을 직접 확인할 수 있고, 형식도 변경할 수 있다. [28:26]
• 기존 채팅 형식은 예시 기반 최적화를 하던 시기에 XML의 많은 태그와 JSON의 정확한 토큰 생성을 모델이 어려워했던 배경에서 선택됐다. XML을 기본 형식으로 전환하는 변화는 몇 주 뒤 나올 3.5 버전에 포함될 예정으로 드러난다. [28:56]

15. 기본 형식 변경은 폭넓은 평가와 성능 유지가 전제다

• XML을 기본값으로 바꾸는 결정은 DSPy Bench의 여러 평가에 걸쳐 검증한다. 기존보다 성능이 떨어지지 않아야 한다는 기준을 두었고, 그 기준에 도달했다는 설명이다. [29:34]
• 과거에는 Markdown 코드 블록이나 부가 설명 없이 일관된 JSON만 받는 것 자체가 어려운 문제였다. 구조화된 출력과 형식 처리를 프레임워크가 맡는 가치는 이런 수작업 지시 부담을 줄이는 데 있다. [29:59]

16. 사람·AI 텍스트 데이터와 학습·평가 분리

• 사람이 작성한 텍스트와 AI 생성 텍스트를 담은 CSV를 pandas 데이터프레임으로 불러온다. 예제와 데이터는 책의 공개 저장소에서도 확인할 수 있다. [30:22]
• 데이터프레임의 열을 DSPy 예제 형식으로 변환하고, text를 입력 필드로 지정한다. [30:46]

17. 정답 기반 점수와 오류 설명을 함께 활용

• 평가 설계 자체는 어렵지만, 이 데이터에는 실제 AI 작성 여부가 표시되어 있어 판정이 맞으면 1점을 주는 명확한 지표를 사용할 수 있다. [32:02]
• 데이터에 포함된 메모는 어떤 표현이 AI 작성의 단서인지 보여준다. 최적화 과정에 오답의 이유까지 전달하는 피드백은 선택 사항이지만 도움이 된다. [32:52]

18. 판정기를 먼저 학습해 주관적 작업을 평가

• 휴머나이저는 입력 텍스트를 사람처럼 다시 쓰지만, 새로 생성한 문장의 품질을 매번 사람이 평가하기는 어렵다. 최적화·평가 패턴은 이 주관적 판단을 맡길 판정기부터 학습한다. [33:23]
• 판정기는 작성 주체가 알려진 데이터로 정확성을 검증할 수 있다. 사람과 AI의 텍스트를 충분히 잘 구분하게 되면 원래 재작성 작업을 학습시키는 대리 평가자로 사용한다. [34:20]

19. 추론 출력 제한과 Bedrock 연결의 호환성

• ChainOfThought는 모델에 추론 설명을 요청하는 방식이며, 추론 모델이 등장하기 전부터 사용되었다. 일부 Anthropic 모델에서는 추론 공개 요청에 대한 제한이 강화되어 이 방식이 실패하는 호환성 문제가 제기된다. [35:40]
• Bedrock 모델은 사용하는 라우팅 라이브러리를 통해 연결할 수 있다. API 키 인증은 기본적으로 작동하며, 인증된 클라이언트를 사용하는 경우에는 별도 연결 예제가 필요하다. [36:46]

20. 판정기 기준 성능과 데이터 점검

• Evaluate에 데이터셋과 정답 일치 지표를 전달해 판정기의 기준 성능을 측정한다. 예시에서는 네 개를 동시에 평가하고 진행 상황과 결과 표를 출력한다. [37:27]
• 결과 표의 정답, 판정 이유, 예측, 점수를 함께 보면 오분류와 잘못된 데이터를 찾을 수 있다. 이런 점검은 데이터 수정이나 파이프라인 개선의 근거가 되며, HTML 시각화나 좌우 스와이프 방식으로 검토할 수도 있다. [38:18]

21. 휴머나이저의 초기 성공률은 10%

• 휴머나이저가 새로 만든 문장에는 미리 정해진 정답이 없으므로, 정확도 80%인 판정기를 사용해 사람처럼 보이는지를 평가한다. [40:08]
• 초기 휴머나이저가 판정기를 속인 비율은 10%다. 판정기의 분류 정확도와 휴머나이저의 성공률은 서로 다른 지표이며, 이 결과에서는 재작성 작업의 개선 여지가 크다. [40:42]

22. 실패를 반영한 프롬프트 최적화로 판정기 개선

• GEPA 최적화에는 작업 수행 모델과 별도로 더 강한 LLM을 사용한다. 이 모델은 실패 사례를 보고 프롬프트를 수정하며, 작업 모델이 더 나은 결과를 내도록 지시를 개선한다. [42:29]
• 판정기, 학습 데이터, 검증용 홀드아웃과 프롬프트 수정용 LLM을 전달하면 예측 결과를 평가하고 지시문을 반복해서 바꾼다. 해당 실행은 약 15분이 걸렸고 API 비용은 약 1달러였다는 추정이다. [43:45]

23. 모델별 특성과 검증된 지시문을 저장

• 모델마다 효과적인 프롬프트의 특성이 다를 수 있다. 여러 실험의 우승 프롬프트가 모두 “good luck”으로 끝났다는 사례처럼, 사람이 예상하기 어려운 표현도 최적화 결과에 포함될 수 있다. [45:00]
• 최적화 결과는 저장해 재사용할 수 있다. 다른 판정기나 더 저렴한 모델로 다시 최적화하는 것도 가능하지만, 필요한 지시와 성능은 모델에 따라 달라질 수 있다. [45:39]

24. 후보 탐색 구조와 맥락 초기화로 최적화 정체 완화

• GEPA는 성능이 좋은 프롬프트에서 여러 변형을 만들고 유전적 탐색과 파레토 전선 구조로 시험한다. 이러한 맥락 관리와 평가 구조가 비용과 도달 가능한 성능에 유리하며 새로운 아이디어를 찾는 데 도움이 된다는 주장이다. [46:43]
• 긴 작업이나 최적화에서는 모델이 한 해결책에 과도하게 집중해 다른 방향의 더 좋은 해결책을 놓칠 수 있다. 맥락을 지우는 ‘flushing’이나 ‘forgetting’은 이 관성을 끊는 방법이다. [47:40]

25. 최적화한 판정기로 휴머나이저를 70%까지 개선

• 100%라는 판정기 점수는 특정 데이터셋에서 사람의 라벨과 모두 일치했다는 뜻이며, 항상 이런 점수를 얻는 것은 아니다. 충분히 신뢰할 만한 판정기를 확보하면 정답이 없는 원래 작업의 평가 기준으로 사용할 수 있다. [49:14]
• 같은 최적화 구조에서 평가 지표를 최적화된 판정기로 교체하고, 강한 LLM이 이번에는 휴머나이저의 작업 프롬프트를 수정하게 한다. [49:50]

26. 에이전트 실패 감지 프로그램의 재학습과 이식

• DSPy의 구성 방식은 반복 루프나 작업 이탈처럼 작은 모델이 빠질 수 있는 실패 상태를 감지하는 결정 모델에도 적용된다. 이 사례에서는 에이전트 실패 유형을 담은 학습 데이터를 사용한다. [51:17]
• 실패를 구분하는 질문과 판단 기준을 최적화한 뒤, 완성된 프로그램을 코딩 에이전트로 다른 구현에 옮긴다. 학습 데이터가 추가되면 DSPy 쪽에서 다시 최적화하고 변환해 배포할 수 있다. [52:10]

27. 운영 환경에서 후보 선택과 개인화 평가에 활용

• 학습한 평가기는 노트북 실험을 넘어 실제 서비스의 결과 선택에도 사용할 수 있다. 텍스트를 여러 번 재작성한 뒤 판정기가 가장 좋은 후보를 고르는 방식이며, 열 개의 후보를 생성하는 예가 드러난다. [52:48]
• 회의 기록에서 참석자와 결정 사항을 추출하거나, 시의회 회의록에서 개인적으로 관심 있는 사안을 찾는 작업에도 평가 최적화를 적용 중이다. 겉보기에는 지루한 내용도 사용자에게 중요할 수 있어, 후자는 특히 평가가 어렵고 지속적인 피드백이 필요하다. [53:30]

28. 모델 교체 효과를 비용과 함께 비교

• 여러 후보 중 최선을 고르는 방식으로 점수가 75%가 되었고, 이어 Gemini 모델을 적용한 예에서는 85%로 높아졌다. 사용한 Gemini는 새로 출시된 모델이 아니라 기존 모델이다. [54:14]
• 더 높은 점수에 추가 비용을 지불할 가치가 있는지, 운영에 필요한 신뢰성 수준이 어느 정도인지 판단해야 한다. 같은 평가 체계는 모델 선택과 작업의 투자 대비 효과를 논의하는 근거가 된다. [54:40]

29. 평가 자산의 재사용과 비개발자의 접근성

• 구축한 평가 체계는 새 모델이나 구현이 나올 때마다 반복 적용할 수 있는 자산이다. 작업의 가치를 정의하고 성능 개선을 수치로 확인하면 고객이나 팀에 개선 효과를 구체적으로 설명할 수 있다. [55:11]
• 책은 학술적인 문서의 진입 장벽을 낮추려는 목적에서 출발했다. 평가와 최적화를 중심으로 맥락을 구조화하는 방식은 DSPy 외의 하네스나 프레임워크에도 옮겨 적용할 수 있다는 관점이다. [55:35]

30. 적은 예제로도 최적화를 시작할 수 있다는 경험

• 필요한 표본 수에 대한 질문에, 예제 수를 최대한 줄여 최적화한다는 경험이 드러난다. GEPA를 한 차례만 실행해도 직접 작성하려던 것보다 나은 프롬프트를 얻는다는 판단이며, 특정 최소 표본 수를 보장하는 설명은 아니다. [59:50]

31. 적은 예제로 시작하되 실패 사례를 지속 가능한 평가 자산으로 만든다

• 앞선 예시는 약 20개로 시작했으며, 수작업보다 빠르고 좋은 결과를 낼 가능성이 있다는 설명이다. 약 50개를 넘기면 효과를 얻기 좋은 구간이라는 경험칙이 있지만, 정확한 데이터 대응이 필요한 작업에서는 100~200개가 필요할 수도 있다. 문서 활용 능력을 개선한 초기 사례에는 약 40개가 쓰였다는 회고도 있어, 필요한 수는 작업에 따라 달라진다. [1:00:02]
• 관찰한 실패 유형을 유발할 만한 입력을 합성한 뒤 직접 라벨을 붙이면 평가 데이터를 보강할 수 있다. 실제로 발견한 실패를 출발점으로 삼는 방식이다. [1:01:02]

32. RLM은 코드와 하위 에이전트로 긴 문맥과 반복 작업을 처리한다

• RLM은 입력을 Python REPL 안의 변수로 제공하고, 지정한 시그니처를 수행할 코드를 작성하게 하는 추론 시점 전략이다. 책의 각 장을 하위 에이전트가 요약하고 마지막에 결과를 합치는 식으로 작업을 유연하게 분해할 수 있다. [1:02:29]
• RLM은 정확도 측면에서 능가하기 어려운 범용 전략이라는 평가를 받지만, 비용과 지연 시간에는 상당한 개선 여지가 있다. [1:03:03]

33. DSPy Flex는 입출력 정의를 유지하면서 실행 구조를 탐색한다

• RLM이 반복해서 작성하는 함수를 미리 만든 도구로 제공하면 실행 방식을 더 고정할 수 있다. DSPy Flex는 이 접근을 확장하며, RLM에서 시작해 시그니처에 가장 잘 맞는 추론 전략을 찾도록 한다. [1:04:57]
• 최적화기는 모듈 조합, 추론 전략, 작업 분해 방식을 탐색한다. 미리 만든 도구를 사용하는 RLM이 선택될 수도 있고, 휴리스틱 코드로 먼저 처리한 뒤 언어 모델 호출을 대체 수단으로 사용하는 구조가 선택될 수도 있다. [1:05:28]

34. 비정형 피드백에서 평가 지표와 데이터셋을 학습하는 연구가 진행 중이다

• 개발 중인 최적화기는 예제에 대한 비정형 피드백으로 평가 지표와 사용할 데이터셋을 학습하는 것을 목표로 한다. 아직 진행 중인 연구이며, 곧 제공할 것이라는 전망이 드러난다. [1:06:58]
• 평가 지표 설계는 AI 엔지니어링에서 어려운 작업 중 하나다. 이 연구가 진전되면 시스템이 작업 수행 방법을 학습할 수 있도록 유용한 피드백을 확보하는 일이 더 중요해질 수 있다. [1:07:20]

35. 자동화가 확대될수록 원하는 결과를 명확히 정의하는 일이 중요해진다

• “이제 내가 무엇을 원하는지 알아야 한다”는 표현은 DSPy가 드러내는 요구사항 정의의 어려움을 압축한다. 도입 과정의 어려움에는 해결하려는 문제와 원하는 결과를 명확히 정하기 어렵다는 문제가 섞여 있을 수 있다. [1:07:50]
• DSPy와 평가는 여전히 저평가되어 있으며, AI가 기존 문제를 해결하면서 사람들이 다른 일로 이동할 때 새로운 일자리의 원천이 될 수 있다는 전망이다. 관련 역량을 배우면 더 큰 영향을 낼 기회가 생길 수 있다는 기대가 마지막 논지로 계속된다. [1:08:46]

🧾 결론

• DSPy는 프롬프트 문구를 직접 관리하는 부담을 줄이지만, 원하는 결과를 정의하고 데이터를 준비하는 일을 대신하지는 않는다.
• 실패 사례를 임시 금지 지시로 쌓기보다 라벨이 있는 예제로 남기면, 모델과 구현이 바뀌어도 반복 활용할 평가 자산이 된다.
• GEPA로 실패를 반영하고 판정기와 작업 모델을 번갈아 최적화할 수 있다. 다만 특정 평가셋의 개선과 새로운 입력에서의 성능은 구분해야 한다.
• 컨텍스트 엔지니어링의 범위는 초기 프롬프트를 넘어 예시, 피드백, 평가, 맥락 관리와 실행 구조의 설계까지 이어진다.

📈 투자·시사 포인트

• AI 도입의 투자 대비 효과는 같은 평가 체계에서 확인한 품질 개선과 추가 비용을 함께 비교할 때 구체적으로 설명할 수 있다.
• 예시와 평가 체계는 새 모델이나 구현을 검토할 때 재사용할 수 있다. 모델 교체가 잦을수록 이 자산의 활용 범위가 넓어진다.
• 빠르고 저렴한 결정 모델은 작은 AI 기능을 제품에 적용할 동기를 높인다. 다만 지원하는 출력 타입과 실제 성능을 확인해야 한다.
• 발표자는 평가·최적화 역량이 새로운 일과 영향력을 만들 기회가 될 수 있다고 전망한다. 자동화가 확대될수록 무엇을 원하는지 정의하고 유용한 피드백을 확보하는 역할이 중요해진다는 관점이다.

⚠️ 불확실하거나 확인이 필요한 부분

• 판정기 정확도 100%는 해당 실행의 20개 평가 예제에서 얻은 결과다. 일반적인 탐지 정확도나 다른 데이터에서의 성능을 보장하지 않는다.
• 휴머나이저의 70%와 후속 75%·85%는 판정기를 기준으로 한 점수다. 실제 독자가 느끼는 자연스러움과 얼마나 일치하는지는 별도 확인이 필요하다.
• 약 15분·API 비용 약 1달러는 소개된 최적화 실행의 추정치다. 모델, 데이터, 탐색 범위가 달라질 때의 비용과 시간은 제시되지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 적용할 과제 하나를 골라 입력, 원하는 출력, 성공 조건을 시그니처와 평가 기준으로 명시한다.
• 실제 실패 사례와 도메인 전문가의 좋은 예시를 모아 라벨을 붙이고, 프로그램의 제어 흐름과 분리해 관리한다.
• 학습·검증 데이터를 나누고, 최적화에 사용하지 않는 최종 홀드아웃을 확보한다. 필요한 예제 수는 작업별로 판단한다.
• 최적화 전 기준 성능을 측정하고 오분류·라벨 오류를 검토한다. 판정기 정확도와 작업 모델의 판정기 통과율은 별도로 기록한다.

❓ 열린 질문

• 판정기 통과율이 실제 독자의 자연스러움 판단과 충분히 일치하는지 어떻게 검증할 것인가?
• 해당 과제에서 더 높은 점수를 얻기 위해 지불할 수 있는 추가 비용과 지연 시간은 어느 정도인가?
• 적은 예제로 얻은 개선이 새로운 입력과 다른 모델에서도 유지되는가?