모델 교체 워크숍: GPT-5.5·Kimi·DeepSeek·Mistral 비교 — Pamela Fox (Microsoft)

메타데이터

• 채널/발행처: AI Engineer
• 영상 ID: UGjk3Uk0MxM
• 원문 URL: https://www.youtube.com/watch?v=UGjk3Uk0MxM
• 원제: The Model Swap Workshop: GPT-5.5 vs Kimi vs DeepSeek vs Mistral — Pamela Fox, Microsoft
• 원본 업로드일: 2026-10-19 (yt-dlp 메타데이터의 업로드 날짜)
• 길이: 51분 37초 (3,097초)
• 처리일: 2026-10-20 (Asia/Seoul)
• 발표자: Pamela Fox, Microsoft
• 자막: 영어 자동 자막을 기준으로 전체 흐름을 정리하고 모델명·맥락상 오인식은 교정했다.

---

📌 핵심 질문 / 이 워크숍이 답하는 질문

==모델 교체의 안전성은 공개 벤치마크 순위가 아니라, 실제 서비스의 근거·도구·다국어 조건을 재현한 평가로 검증해야 한다.==

• 모델은 같은 질문에서도 계산, 근거 준수, 이미지 인식, 도구 선택과 실행 효율에서 서로 다르게 실패한다.
• 프롬프트 수정으로 개선되는 문제와 모델의 본질적 기능 차이를 구분해야 한다.
• LLM-as-judge와 ASSERT는 평가를 자동화하고, DSPy와 GEPA는 검증 가능한 제약을 만족하는 프롬프트를 찾는다.

Pamela Fox는 Microsoft Foundry에 배포한 GPT-5.5, Kimi K2.6, DeepSeek V4 Flash, Mistral Large 3을 동일한 과제에 투입한다. 단순한 단일 호출부터 RAG, 이미지 입력, 도구 호출, 에이전트 루프, 평가 체계, 프롬프트 최적화까지 직접 실행하며 결과를 비교한다. 전체 실험의 목적은 어느 모델이 보편적으로 최고인지 정하는 것이 아니라, 모델을 바꿔도 제품이 작동하도록 각 모델의 실패 양상을 파악하고 평가 절차를 만들어 두는 것이다.

---

1. 모델을 바꿔 쓸 수 있도록 실제 시나리오를 평가한다

1.1. 공개 벤치마크보다 서비스별 테스트가 중요하다

1. 일반 벤치마크의 한계
   1. 모델 벤치마크·안전성 점수·가격·처리량은 대략적인 성능을 가늠하는 데 도움이 된다.
   2. 그러나 같은 모델도 사용 방식이 다양하므로 일반 벤치마크만으로 특정 앱에서의 결과를 예측할 수 없다.
2. 모델 교체 가능성이 필요한 이유
   1. 새 모델이 계속 나오고, 정부 정책이나 제공자 사정으로 특정 모델에 대한 접근이 갑자기 끊길 수도 있다.
   2. AI 애플리케이션은 다른 모델을 가리켜도 계속 작동하거나, 실패한 부분을 개선할 수 있어야 한다.
3. 워크숍의 평가 방식
   1. 하나의 추상 점수 대신 계산, 검색 근거, 이미지, 함수 호출, 에이전트 등 구체적인 작업을 차례로 시험한다.
   2. 결과의 정답 여부뿐 아니라 호출 횟수·병렬성·근거 준수처럼 운영상 중요한 축도 관찰한다.

1.2. 실습 환경과 네 모델

1. 참가자 실습 준비
   1. Python과 UV가 있는 참가자는 저장소를 복제하고 uv sync를 실행한 뒤 환경 파일을 준비하면 예제를 실행할 수 있다.
   2. 로컬 개발 환경이 없으면 브라우저 안의 VS Code 환경인 GitHub Codespaces를 사용할 수 있다. 예제와 필요한 환경 변수는 저장소 README 및 배포된 환경 파일에서 안내한다.
2. Foundry 배포·용량 제한
   1. 공유 환경 변수는 Microsoft Foundry 프로젝트에 배포된 모델들에 접근하게 하지만, 토큰 용량이 한정되어 있어 참가자 수에 따라 429 rate-limit 오류가 날 수 있다.
   2. Fox는 워크숍 승인을 비교적 늦게 받아 사용할 수 있는 용량을 최대한 확보했다고 말하고, 저장소에는 다른 배포 환경을 선택할 수 있는 변수와 Anthropic 전용 프로젝트 설정도 있다고 안내한다.
   3. 동료 Cedric은 실습 중 참가자들을 도와주기로 했으며, 화면의 설정 링크를 놓친 사람은 Cedric의 휴대전화 사진도 참고할 수 있다.
3. 비교 대상
   1. GPT-5.5는 Fox가 평소 사용하는 기준 모델이다.
   2. Kimi K2.6은 비교적 최근 모델로 Fox가 좋은 성능을 보인다고 평가한다.
   3. DeepSeek V4 Flash와 Mistral Large 3도 같은 Foundry 프로젝트에서 비교한다.
   4. UV를 쓰는 사람보다 Python을 쓰는 사람이 더 많다는 현장 질문이 오가고, Fox는 청중이 화면을 촬영할 시간을 준다.

---

2. 문자 세기 실험은 모델별 기본 능력과 프롬프트 효과를 보여준다

2.1. 한 번의 LLM 호출에서 같은 문장을 세다

1. 실험 조건
   1. OpenAI Python SDK로 Microsoft Foundry 엔드포인트의 Responses API를 호출한다.
   2. “the elderly gentleman eagerly entered the elevator”라는 문장에서 문자 e가 몇 번 나오는지 세게 한다.
   3. Fox는 코드에서 모델 변수를 바꾸고 같은 프롬프트를 순서대로 각 모델에 보낸다.
2. 첫 결과
   1. GPT-5.5는 정답인 13을 말한다. Fox는 동료들이 금융 계산 벤치마크를 돌릴 때 GPT-5.5가 머릿속 계산을 잘한다고 언급한다.
   2. Kimi K2.6도 13으로 맞힌다.
   3. DeepSeek V4 Flash는 6, Mistral Large 3은 8이라고 답해 모델 간 차이가 단순한 문제가 아니라도 드러난다.

2.2. Mistral에 단계별 풀이를 요구한다

1. 프롬프트 변경
   1. Fox는 문장을 단어별로 나누고, 각 단어의 e를 센 다음 합산하고 풀이를 보이라고 지시한다.
   2. 철자 실수도 함께 고치지만 Fox는 그 수정 자체가 결과를 바꾼 핵심은 아니라고 말한다.
2. 관찰과 해석
   1. Mistral은 바뀐 지시에서 정답을 얻는다.
   2. 단어별 분해와 단계적 계산처럼 프롬프트가 약점을 보완하는 경우가 있다.
   3. 이후 실험의 핵심은 프롬프트로 해결할 수 있는 실패와 모델이 해당 입력을 실제로 이해하지 못하는 실패를 구분하는 것이다.

---

3. RAG에서는 답을 아는 것보다 출처 범위를 지키는지가 중요하다

3.1. 목수벌 자료로 꿀벌 정보까지 답할 수 있는지 시험한다

1. 질문과 근거
   1. 데이터셋에는 목수벌(carpenter bee)의 둥지 정보만 있다.
   2. 질문은 꿀벌(honeybee)과 목수벌이 둥지를 짓는 방식의 주요 차이를 묻는다.
   3. 이상적인 답은 자료에서 확인되는 목수벌 정보만 말하고, 꿀벌에 관한 자료가 없다고 인정하는 것이다.
2. 모델별 반응
   1. GPT-5.5는 자료에 꿀벌의 둥지 건설 정보가 없다고 답한다. Fox는 GPT-5.5가 모르는 것을 모른다고 말하는 데 강하다고 본다.
   2. Kimi도 이 과제에서 좋은 결과를 보였지만 시간 때문에 화면에서 매번 모든 모델을 반복 실행하지는 않는다.
   3. DeepSeek V4 Flash도 제공된 출처에 정보가 없다고 답해 자료 경계를 지킨다.
   4. Mistral은 자료에 없는 꿀벌 정보를 자체 학습 가중치에서 가져와, 제공된 맥락의 내용인 것처럼 답한다.

3.2. 출처 표기를 강제해도 사실을 덧붙일 수 있다

1. Mistral을 위한 프롬프트 조정
   1. Fox는 답변의 각 정보가 어느 출처에서 왔는지 연결하고, 자료에 근거가 없으면 “출처가 제공되지 않았다”고 표시하라고 지시한다.
   2. 이는 모델이 답변 속 꿀벌 주장을 목수벌 자료와 연결할 수 없는 점을 스스로 알아차리게 하려는 시도다.
2. 부분 개선과 RAG 선정 기준
   1. Mistral은 꿀벌 정보에 “출처가 제공되지 않았다”고 붙이지만, 출처 없는 정보 자체는 여전히 답변에 남긴다.
   2. 근거 없는 주장을 숨기지 않게 만든 점은 개선이지만, RAG의 요구사항을 완전히 충족하지는 못한다.
   3. Fox는 자신이 가장 많이 다루는 분야가 RAG라고 밝히며, 모델을 고를 때 모르는 것을 인정하는지와 학습 지식으로 빈칸을 메우는 빈도를 먼저 평가하라고 강조한다.

---

4. 이미지 입력은 프롬프트보다 모델의 시각 능력 차이가 크게 작용한다

4.1. 세 가지 이미지 과제와 모델별 결과

1. 이미지 자료
   1. 첫 이미지는 유니콘이 아니라 오록스(aurochs)의 사진이다.
   2. 둘째는 Fox가 코스타리카에서 보고 무서워했던 악어 사진이며, 주둥이를 보고 crocodile과 alligator를 구분하는 문제다.
   3. 셋째는 작은 글씨로 식물 가격이 적힌 표의 스크린샷에서 가장 싼 식물을 찾는 과제다.
2. GPT-5.5와 Kimi K2.6
   1. GPT-5.5는 첫 사진이 유니콘이 아니라고 판단하고, 오록스가 아닌 이미지도 악어의 주둥이를 근거로 crocodile이라고 맞힌다.
   2. GPT-5.5는 글씨가 작은 가격 표에서도 최저가 식물을 찾는다.
   3. Kimi K2.6도 오록스를 알아보고, 악어 사진을 crocodile이라고 분류하며, 식물 가격 표의 최저가를 찾는다.
3. DeepSeek와 Mistral
   1. DeepSeek V4 Flash는 텍스트만 받는 모델이어서 이 이미지 비교에서 제외된다.
   2. Mistral은 사진이 유니콘이 아니라는 점은 알지만 오록스라는 종은 식별하지 못한다.
   3. Mistral은 crocodile 사진을 alligator라고 답하고, 최저가인 1.58달러 대신 2.30달러짜리 식물을 고른다.

4.2. 시각 과제의 도메인·언어 조건을 따로 검증한다

1. 프롬프트 엔지니어링의 한계
   1. Fox는 이미지 과제에서 모델이 이미지를 읽을 수 있는지 여부가 우선이며, 텍스트 프롬프트만으로 시각적 능력 차이를 없애기 어렵다고 본다.
   2. 특정 도메인의 그래프라면 읽는 방법을 알려주는 힌트가 도움이 될 수 있지만, 실제 사용 이미지에서 모델이 제대로 작동하는지 별도 평가해야 한다.
2. 스페인어에서 생기는 혼동
   1. 영어로는 crocodile과 alligator를 구분하던 모델이 스페인어로 caimanes와 cocodrilos 중 무엇인지 물으면 두 표현을 혼동해 오답을 낸다.
   2. Fox는 caiman이라는 단어의 지역적 의미와 영어 단어 대응까지 겹쳐 모델이 혼란스러워하는 현상을 흥미로운 실패로 짚는다.
   3. 캘리포니아 앱은 스페인어 사용자도 지원하는 경우가 많으므로, 영어 결과만 보고 다국어 제품의 이미지 능력을 판단하지 말아야 한다고 말한다.

---

5. 함수 호출은 스키마 설명도 프롬프트의 일부라는 점을 드러낸다

5.1. 캘린더 일정 생성 도구를 정의한다

1. 도구 스키마
   1. Fox는 JSON Schema로 create_calendar_event 함수를 정의하고, 제목과 설명 문자열 등 도구가 받을 인수를 지정한다.
   2. 모델은 함수 정의와 사용자 요청을 읽고 어떤 함수를 어떤 인수로 부를지 제안한다.
   3. 모델이 함수 자체를 실행하는 것은 아니며, 애플리케이션이 반환된 함수명과 인수를 받아 실제 실행을 담당한다.
2. 사용자 요청
   1. 플랫폼 팀 싱크 일정을 만들고 Sarah(Engineering), Marcus, 새 PM Priya를 참석자로 추가해 달라고 한다.
   2. 일정은 6월 29일 월요일을 기준으로 “내일” 오후 1시 30분이며, 장소는 Microsoft Teams를 이용한 가상 회의다.
   3. 시스템에는 오늘 날짜와 “캘린더 비서” 역할, 사용 가능한 도구를 함께 전달한다.

5.2. 잘못된 인수는 스키마의 모호성을 찾는 단서다

1. 모델 출력의 차이
   1. GPT-5.5는 참석자 목록에 Fox 자신을 추가했지만 나머지는 대체로 기대에 가까웠다.
   2. DeepSeek는 요청자의 사용자 자신을 참석자에 넣고, 장소를 요청 형식과 다르게 “virtual (Microsoft Teams)”로 표현한다.
   3. 이 결과는 같은 기능을 호출했더라도 참석자 규칙과 위치 표현에 대한 기대를 모델이 다르게 해석할 수 있음을 보여준다.
2. 스키마와 설명을 개선한다
   1. Fox는 “나 또는 너를 참석자로 넣지 말고, 이름이 지정된 참석자만 포함하라”처럼 설명을 구체화할 수 있다고 말한다.
   2. 잘못된 함수 인수는 모델만 탓할 문제가 아니라, JSON Schema의 이름·타입·설명이 충분히 명확한지 다시 검토할 신호다.
   3. 수정 뒤에는 여러 입력 사례를 다시 실행해 어느 모델에서도 원하는 도구와 인수가 나오는지 확인한다.

---

6. 에이전트 루프에서는 정답과 함께 도구 호출 효율을 측정한다

6.1. 계산 도구를 반복 호출하는 과제

1. 테스트 구성
   1. calculate 도구는 수식 문자열을 받아 계산 결과를 돌려준다.
   2. 세 벌의 셔츠를 사고 세금까지 포함했을 때 총액이 얼마인지 묻는 문장형 문제를 사용한다.
   3. 시스템 프롬프트는 “머릿속으로 계산하지 말라”는 한 줄이며, 모델이 계산기를 어떻게 활용하는지를 관찰한다.
2. 모델별 호출 수
   1. GPT-5.5는 전체 계산을 하나의 긴 식으로 묶어 한 번의 도구 호출로 정답을 얻는다.
   2. DeepSeek V4 Flash는 단계별로 계산해 네 번 호출하지만 최종 정답에는 도달한다.
   3. Kimi는 대체로 GPT-5.5와 비슷하게 잘 작동하지만, Fox가 다른 실행에서 본 사례에서는 첫 호출에 이미 맞힌 뒤에도 확인을 위해 네 번 더 계산했다.

6.2. 호출 횟수는 실제 응답 시간과 비용으로 이어진다

1. 정답만으로는 부족하다
   1. 도구 호출 하나하나는 추가 네트워크 요청이므로 같은 최종 답을 내도 왕복 횟수에 따라 사용자 대기 시간과 자원이 달라진다.
   2. 모델 평가에는 최종 답의 정확성뿐 아니라 목표에 도달하는 속도와 필요한 도구 호출 수를 포함해야 한다.
2. 초기 실험에서 에이전트 평가로 확장한다
   1. Fox는 단일 함수 호출과 반복 호출을 거쳐, 목표를 달성할 때까지 도구를 쓰는 에이전트 예제로 진행한다.
   2. 여기서도 반복 호출을 왜 하는지, 계산을 묶을 수 있는지처럼 효율 차이가 중요한 평가 대상이다.

---

7. 여행 계획 에이전트는 병렬 도구 호출과 하네스 차이를 비교한다

7.1. 같은 에이전트를 세 프레임워크에서 준비한다

1. 선택한 프레임워크
   1. 저장소에는 LangChain v1, Pydantic AI, Agent Framework로 만든 유사한 에이전트 예제가 있다.
   2. 청중에게 시연 프레임워크를 고르게 하자 LangChain이 선택된다.
   3. Fox는 코드가 비슷해졌고 프레임워크 사이의 차이보다 공통점이 더 많다고 보는 편이지만, 각 프레임워크의 도구 호출 루프는 서로 다를 수 있다고 설명한다.
2. 여행 계획 요청과 도구
   1. 사용자는 다음 달 샌프란시스코에서 뉴욕으로 가서 3박을 하고, 총예산 600달러 안에서 직항과 활동 한 가지를 원한다.
   2. 에이전트는 항공편 검색, 호텔 검색, 예산 확인, 남은 예산을 고려한 활동 검색 도구를 쓸 수 있다.
   3. 시스템 지침은 항공편과 호텔을 모두 찾고, 직항을 선호하며, 반드시 예산을 확인하고, 남은 금액에 맞춰 마지막에 활동을 추천하라는 순서다.

7.2. 병렬 실행과 완료 단계에서 모델이 갈린다

1. GPT-5.5의 흐름
   1. 첫 턴에 독립적인 항공편 검색과 호텔 검색을 병렬로 요청한다.
   2. 두 결과를 받은 뒤 예산 확인을 하고, 남은 예산으로 활동을 검색한다.
   3. 이 과제에서는 불필요한 대기와 도구 호출을 줄이는 가장 효율적인 경로다.
2. Kimi와 DeepSeek의 흐름
   1. Kimi는 항공편과 호텔을 서로 다른 턴에 순차 검색해 처음의 병렬 실행을 하지 않는다.
   2. Kimi는 여러 후보를 확인하려고 예산 도구를 두 차례 부르고, GPT-5.5 경로보다 호출이 두 번 더 든다.
   3. DeepSeek는 병렬화하지 않고 네 번 호출하지만, Fox는 이 정도면 비교적 합리적인 효율이라고 평가한다.
3. Mistral의 조기 종료
   1. Mistral은 항공편과 호텔 검색까지만 하고 예산 확인이나 활동 검색을 이어가지 않는다.
   2. 에이전트가 마지막 단계까지 실행하지 못한 사례로, 원래 지시를 다시 상기시키는 중간 개입이 필요할 수 있다.
   3. 대화가 길어져 컨텍스트가 차면 에이전트가 초기 지시를 놓치고 점점 덜 꼼꼼해질 수 있다는 점도 함께 언급된다.

7.3. 모델과 에이전트 하네스를 함께 평가한다

1. 에이전트 평가가 어려운 이유
   1. 올바른 도구를 골랐는지, 올바른 인수를 썼는지, 불필요한 도구를 호출하지 않았는지, 병렬화할 수 있는 일을 병렬로 했는지를 모두 살펴야 한다.
   2. 프레임워크가 제공하는 하네스와 도구 루프가 다르면 같은 모델도 다른 행동을 보이므로 모델만 바꾸는 비교로 끝내면 안 된다.
2. 루프를 더 적극적으로 유도한다
   1. Fox는 Jeff Huntley가 만든 Ralph Loop를 언급하며, 기본 에이전트 루프보다 에이전트를 더 적극적으로 움직이게 하는 방법으로 소개한다.
   2. 운영 중에는 초기 지시를 보강하는 프롬프트나 루프 제어를 사용해 마지막 단계 누락을 막을 수 있다.

---

8. 평가 자동화는 간단한 일치 검사에서 전체 실행 추적으로 확장된다

8.1. 문자열 기반 평가와 운영 중 테스트 케이스 보강

1. 도구 인수를 직접 비교한다
   1. 캘린더 함수처럼 기대되는 도구와 값이 명확한 경우에는 반환된 함수명과 인수를 문자열·목록 비교로 검사할 수 있다.
   2. 예를 들어 장소 값이 “virtual”이어야 하는지, 요청에 나온 참석자만 포함됐는지를 자동으로 확인한다.
2. 실사용 입력을 평가 세트에 반영한다
   1. Fox는 날짜 계산, 모호한 기간, 스페인어 입력, “Yo, can you book the big comp room?” 같은 속어 표현을 테스트 사례로 든다.
   2. 윤년은 모델이 계산하기 어려운 대표 사례라며 날짜 계산 도구를 제공하라고 농담 섞인 조언을 한다.
   3. 제품 출시 뒤 실제 사용자가 입력한 새 표현을 계속 테스트에 추가해야 평가 데이터가 사용자 행동에서 벗어나는 drift를 막을 수 있다.

8.2. 평가 프레임워크에 관한 청중 질문

1. “문자열 비교보다 우아한 프레임워크가 있나요?”
   1. 한 참석자가 직접 만든 문자열 검사가 아니라 평가를 더 편하게 구성할 프레임워크가 있는지 묻는다.
   2. Fox는 LangFuse, LangSmith, Arize 등 관측성 제품의 평가 기능과 Microsoft Foundry의 평가 도구, Azure AI Evaluation SDK, OpenAI Evals, DeepEval, JavaScript용 Promptfoo를 언급한다.
   3. 청중은 “Vali”라고 들리는 도구도 제안하고 철자를 V-A-L-L-Y로 말하며, Fox는 이름을 되묻고 받아 적는다.
2. 검사 수준에 따라 도구를 선택한다
   1. 도구 호출 인수처럼 참·거짓을 직접 비교할 수 있는 초반 사례는 반드시 대형 평가 프레임워크로 감싸지 않아도 된다.
   2. 병렬 실행이나 전체 에이전트 경로처럼 문자열 하나로 판정하기 어려운 평가는 더 풍부한 평가 방식이 필요하다.

8.3. 비용이 큰 평가를 일반 테스트 스위트에서 분리한다

1. 지연과 비용
   1. LLM을 부르는 평가는 느리고 비용이 들기 때문에, 모든 테스트를 일반 PyTest나 매 커밋 CI에서 반복하지 말라고 Fox는 조언한다.
   2. RAG 평가에서는 200개 이상의 사례, 때로는 800개가량을 돌릴 수 있어 호출 수가 커진다.
2. 평가 대상과 빈도를 설계한다
   1. 여러 모델을 매 실행마다 모두 비교하기보다, 보통은 현재 모델을 이전 실행 결과와 비교하는 식으로 운영할 수 있다.
   2. 답변·검색 맥락을 미리 저장해 두면 앱과 평가기를 독립적으로 바꾸어 평가기 자체가 잘못됐는지 확인하기 쉽다.

---

9. LLM-as-judge는 맥락과 추적을 읽되 사람의 보정이 필요하다

9.1. 판정 모델에 무엇을 전달하는가

1. 판정 출력
   1. GPT-5.5를 판정자로 설정하고, 평가 대상이 통과인지 실패인지와 그 이유를 JSON으로 반환하게 한다.
   2. 입력 질문, 모델 응답, RAG의 원문 맥락을 함께 전달해 판단 근거를 제공한다.
2. 에이전트 평가는 전체 실행을 포함한다
   1. 도구 사용이 효율적이었는지 평가하려면 도구 정의와 각 도구 호출의 순서·응답까지 판정기에 보여야 한다.
   2. 최종 입력과 출력만으로는 적절한 도구를 골랐는지, 병렬 호출이 가능했는지, 불필요하게 반복했는지 평가할 수 없다.

9.2. 판정기 자체가 틀릴 수 있다

1. 실험 결과
   1. 카펜터비 RAG의 groundedness 평가에서 대부분 모델은 3점 중 2점을 받는다.
   2. Mistral은 3점 중 1점으로 근거 준수에서 더 많은 개선이 필요한 결과를 보인다.
2. 평가기를 검증하는 절차
   1. 평가 실패가 앱의 문제인지, 평가자의 기준이 잘못된 것인지 먼저 분리해야 한다.
   2. 도메인 전문가가 정답 라벨을 검토하고 사람의 판단과 LLM 판정이 일치하는지 보정해야 한다.
   3. Fox는 Hamel.dev의 평가 글과 강의를 추천하고, 평가기 작성이 어렵다는 데 웃으며 동의한다.

---

10. ASSERT는 명세로부터 행동 범주와 합성 평가 세트를 만든다

10.1. YAML 명세로 평가 조건을 설정한다

1. 도구의 성격
   1. Fox가 소개하는 ASSERT는 Microsoft Research의 새로운 도구로, 발표 시점에는 공개된 지 얼마 되지 않았다고 설명한다.
   2. 개발자는 에이전트의 목적·맥락·지원할 사용자와 원하는 행동을 명세하고, ASSERT가 명세를 구체적인 평가 차원과 테스트 케이스로 확장하도록 한다.
2. 평가 명세와 실행 추적
   1. 예제는 YAML로 작성되며, Fox는 YAML을 좋아하지 않지만 이 용도에는 다른 형식보다 낫다고 농담한다.
   2. 예산 압박처럼 중요한 차원을 충분한 예산, 빠듯한 예산, 실행 불가능한 예산 등으로 층화(stratify)하거나 ASSERT가 층화를 생성하게 할 수 있다.
   3. YAML을 작성하도록 돕는 에이전트 스킬도 제공되며, 평가는 LangChain 여행 계획 에이전트의 모든 도구 호출 추적을 읽는다.

10.2. 합성 시나리오가 출시 전 평가의 빈칸을 채운다

1. 행동 범주와 시나리오 생성
   1. ASSERT는 예산 불가능성, 직항 선호 위반, 필수 도구 누락 같은 허용·위반 행동 범주를 만든다.
   2. 명세를 바탕으로 “scenario 65”와 같은 합성 시나리오 제목, 프롬프트, 사용자 상황을 생성한다.
   3. Fox는 일부 제목이 LLM이 만든 티가 난다고 농담하면서도, 출시 전 테스트 세트를 마련하기 어려운 문제를 부트스트랩하는 데 유용하다고 말한다.
2. 여행 계획 에이전트 비교
   1. DeepSeek, Kimi, GPT-5.5를 같은 ASSERT 테스트 세트로 평가한다.
   2. 이 실험에서는 위반 횟수가 낮을수록 좋으며, GPT-5.5가 가장 적은 위반으로 우승한다.
   3. Kimi가 앞선 여러 과제에서 강했기 때문에 Fox도 이 결과에 놀랐다고 말하며, 모델 순위는 과제와 평가 축에 따라 달라짐을 보여준다.
3. 기본 유창성 평가를 경계한다
   1. 기본 coherence·fluency 평가는 보통 실행하지 말라고 Fox는 강하게 말한다. LLM은 일관성 있게 말하는 데 능하기 때문이다.
   2. RAG에서는 groundedness나 relevance 지표가 유용할 수 있지만, 일반 제공 평가기보다 앱에 맞춘 커스텀 평가기가 필요하다.

---

11. DSPy와 GEPA는 프롬프트를 직접 작성하는 대신 제약을 코드화한다

11.1. 프로그램 명세와 프롬프트의 역할을 뒤집는다

1. 프롬프트 수정의 반복 비용
   1. 모델을 바꿀 때마다 어떤 프롬프트가 먹히는지 다시 추측하고 평가하는 일은 번거롭다.
   2. 각 모델의 작동 방식을 모두 미리 아는 것도 어렵다.
2. DSPy의 접근
   1. 개발자는 입력과 기대 결과, 프로그램의 제약 조건을 선언한다.
   2. DSPy는 평가와 최적화 과정을 거쳐 그 제약을 만족하는 프롬프트를 생성한다.
   3. 프롬프트는 더 이상 애플리케이션 코드에 직접 작성한 상수가 아니라, 명세에서 만들어지는 산출물이 된다.
3. GEPA 최적화
   1. Fox는 GEPA(Genetic-Pareto 계열 알고리즘)를 사용해 다음에 시험할 프롬프트 후보를 탐색한다고 설명한다.
   2. 알고리즘이 평가 결과를 보고 개선 후보를 반복하는 과정은 언덕 오르기(hill climbing)에 비유된다.

11.2. Mistral용 제약 프롬프트를 찾는다

1. 실험 문제
   1. 각 줄의 단어 수가 정확한 번호 목록을 만들고, 각 줄의 첫 글자가 지정된 단어를 철자하도록 요구한다.
   2. 개발자는 출력의 단어 수와 첫 글자 조건이 맞는지 검사하는 테스트를 명세에 넣는다.
2. 실행 결과와 구조적 비용
   1. Fox는 이전 과제에서 가장 어려움을 보였던 Mistral을 학습 대상 모델로 골랐다.
   2. GEPA는 약 6분 동안 최적화해 해당 제약을 만족시키는 시스템 프롬프트를 생성한다.
   3. 이 접근은 일반 앱 코드를 그대로 쓰는 것보다 프로그램 구조를 명세 중심으로 다시 설계해야 한다는 비용이 있다.
3. 더 작은 모델로 옮길 가능성
   1. Fox는 작은 모델이나 자체 호스팅 모델을 쓰면서도 원하는 결과를 유지할 가능성을 핵심 이점으로 든다.
   2. Dropbox와 Shopify가 DSPy와 GEPA를 이용해 더 큰 모델에서 더 작거나 자체 인프라의 모델로 옮긴 사례를 소개한 발표들이 있다고 언급한다.
   3. 제약을 코드로 관리하면 특정 제공자 모델에 종속되지 않고 비용과 배포 선택지를 넓힐 수 있다.

---

12. 제공자별 API 차이와 최종 운영 메모

12.1. Anthropic의 Messages API와 인용 기능

1. 호출 형식 차이
   1. 워크숍의 대부분은 OpenAI SDK를 사용하지만 Anthropic 배포에는 Messages API가 필요해 호출 코드도 바꿔야 한다.
   2. 따라서 제공자만 바꾸는 것이 항상 모델명 한 줄 수정으로 끝나는 것은 아니다.
2. RAG용 구조화 인용
   1. Anthropic 모델은 문서를 구조화해 제공하고 인용 기능을 켜면 응답에 인용 블록을 돌려준다.
   2. 인용을 프로그램에서 추출할 수 있어 프런트엔드에서 출처 링크를 만드는 작업에 유용하다고 Fox는 평가한다.

12.2. 공유 실습 환경과 로컬 모델

1. 공유 키 회전
   1. 저장소는 워크숍 뒤에도 계속 공개될 예정이지만, 공유 .env의 API 키는 세션 뒤 교체해야 한다고 Fox가 말한다.
   2. 참가자를 신뢰해도 공용 환경에 키를 계속 둘 수는 없다는 말에 동료 Cedric이 이미 실수라고 지적했다고 덧붙이며 농담한다.
2. 로컬 Llama
   1. Fox는 발표 전날 Llama 지원을 추가했다고 말한다.
   2. 로컬 Llama 서버를 쓰려면 예제의 엔드포인트와 모델명을 바꾸면 대부분 동일한 실험을 실행할 수 있다.
   3. 마지막에는 저장소로 계속 실습할 수 있다고 안내한 뒤 청중에게 감사하고 박수와 스티커로 마무리한다.

---

주요 발언 모음

“실제 시나리오에서 써보기 전에는 모델이 여러분의 특정 문제에 얼마나 잘 맞는지 알 수 없다.”
— 모델별 일반 벤치마크의 한계를 설명하며

“LLM은 일관성 있게 말하는 데 능하다. 기본 유창성 평가를 돌리지 말라.”
— 기본 coherence·fluency 평가보다 커스텀 평가를 강조하며

“프로그램의 제약을 선언하면 DSPy가 그 제약을 따르는 프롬프트를 찾아 쓴다.”
— DSPy가 프롬프트 작성 과정을 바꾸는 방식을 설명하며

“더 작은 모델을 쓰더라도 필요한 결과를 얻고 가장 저렴한 모델을 사용할 수 있다.”
— 프롬프트 최적화의 비용·모델 독립성 이점을 설명하며

“컨텍스트 창이 차면 에이전트는 이전 지시를 잊고 원래 단계에 덜 주의를 기울일 수 있다.”
— 긴 에이전트 작업에서 발생하는 실패를 설명하며

“에이전트 평가는 어렵다. 올바른 도구를 부르는지, 효율적인지, 병렬 호출하는지를 모두 봐야 한다.”
— 에이전트 평가의 여러 축을 설명하며

---

핵심 데이터 & 수치

• 영상 업로드: 2026-10-19, yt-dlp의 업로드 메타데이터 기준.
• 영상 길이: 51분 37초, 3,097초.
• 비교 모델: GPT-5.5, Kimi K2.6, DeepSeek V4 Flash, Mistral Large 3.
• 문자 e 세기: 정답 13; GPT-5.5 13, Kimi 13, DeepSeek 6, Mistral 8. 단어별 분해 프롬프트 후 Mistral은 정답을 산출.
• 이미지 가격표: 최저가 1.58달러; Mistral은 2.30달러를 선택.
• 계산 도구 호출: GPT-5.5 한 번, DeepSeek 네 번. Kimi가 다른 실행에서 맞힌 답을 네 차례 더 검산한 사례도 Fox가 소개.
• 여행 에이전트: GPT-5.5는 첫 턴에 항공편·호텔을 병렬 검색; Kimi는 순차 호출과 추가 예산 검사로 두 번 더 호출; DeepSeek는 네 번 호출; Mistral은 검색 후 후속 단계를 생략.
• LLM-as-judge groundedness 결과: 대부분 3점 중 2점, Mistral 1점.
• RAG 평가 규모 예시: 보통 200개 이상, 때로 800개가량의 케이스를 평가할 수 있다고 언급.
• DSPy 최적화: Mistral용 제약 과제의 프롬프트를 찾는 데 약 6분 소요.
• ASSERT 비교: 위반 횟수 기준 GPT-5.5가 DeepSeek와 Kimi보다 낮은 결과를 보여 가장 좋은 점수를 얻음.

---

결론 및 실무 시사점

1. 모델 선택은 전반적인 순위가 아니라 실제 제품 입력, 근거, 언어, 도구 조건을 복제한 평가를 통해 결정한다.
2. RAG에서는 모델이 알고 있는 사실을 말하는지보다 제공된 출처만 근거로 쓰고 모르는 점을 인정하는지를 검증한다.
3. JSON Schema의 설명과 도구 호출 인수도 프롬프트 설계의 일부이며, 오류를 보고 스키마를 명확히 한 뒤 다시 평가한다.
4. 에이전트는 정답률뿐 아니라 호출 효율, 병렬성, 완료 여부, 초기 지시 유지 능력을 추적한다.
5. 간단한 문자열 검사에서 시작하되, 복잡한 에이전트에는 전체 도구 추적을 읽는 맞춤 평가와 사람의 판정 보정이 필요하다.
6. 무거운 LLM 평가를 일반 단위 테스트·매 커밋 CI와 분리하고, 실제 사용자 입력으로 테스트 케이스를 갱신한다.
7. ASSERT 같은 명세 기반 평가로 출시 전 합성 테스트를 마련하고, DSPy와 GEPA로 제약을 만족하는 프롬프트를 탐색한다.
8. 제공자 API 차이를 추상화하고 평가 기록을 쌓아두면 더 저렴한 모델·로컬 모델로 옮길 수 있는 선택지가 커진다.

---

핵심 요약 (20문장)

Pamela Fox는 공개 벤치마크로 모델을 고르지 말고, 실제 서비스의 입력·근거·도구 흐름을 재현한 시나리오별 평가로 모델 교체 가능성을 검증하라고 제안한다.

GPT-5.5와 Kimi K2.6은 문자 e를 13번으로 세었지만 DeepSeek V4 Flash는 6번, Mistral Large 3은 8번으로 답한다.

Mistral은 문장을 단어별로 나누어 세고 합산하라는 프롬프트를 받자 문자 세기 과제의 정답을 산출한다.

목수벌 자료만 주어진 RAG 질문에서 GPT-5.5와 DeepSeek는 꿀벌 정보의 부재를 인정하고 Kimi도 좋은 결과를 보인다.

Mistral은 꿀벌 주장을 출처 없음으로 표시하면서도 답변에 남겨 근거 준수에 실패한다.

GPT-5.5와 Kimi K2.6은 오록스·악어·작은 가격표 이미지를 정확히 읽지만 Mistral은 종 분류와 최저가 찾기에서 틀린다.

DeepSeek V4 Flash는 텍스트 전용 모델이라 이미지 과제에 참여하지 못하고 스페인어 질문은 모델들의 악어 분류를 더 어렵게 만든다.

JSON Schema의 함수 이름과 설명은 캘린더 일정 도구의 선택뿐 아니라 참석자와 장소 인수에도 영향을 준다.

GPT-5.5는 요청하지 않은 자신을 참석자로 넣고 DeepSeek는 요청자와 회의 방식을 인수에 잘못 반영한다.

GPT-5.5는 셔츠 세금 계산을 한 번의 도구 호출로 끝내지만 DeepSeek는 정답까지 네 번 호출한다.

LangChain v1, Pydantic AI, Agent Framework는 같은 여행 계획 문제를 풀 수 있지만 각자의 도구 호출 하네스는 다르게 작동한다.

GPT-5.5는 항공편과 호텔을 병렬 검색한 뒤 예산과 활동을 확인하고 Kimi는 순차 호출로 두 번 더 요청한다.

DeepSeek는 네 번의 호출로 여행 계획을 이어가며 Mistral은 항공편과 호텔을 검색한 뒤 예산 검사와 활동 추천을 생략한다.

긴 에이전트 실행은 컨텍스트가 차면서 초기 지시를 잊을 수 있고 Ralph Loop는 기본 루프보다 적극적인 실행을 유도한다.

문자열 비교 평가는 도구명과 인수를 빠르게 검사하지만 날짜 계산·스페인어·속어 등 실제 입력 사례를 계속 추가해야 한다.

LLM 평가가 느리고 비싸므로 일반 PyTest와 매 커밋 CI에서 분리하고 RAG에서는 수백 건 규모를 고려한다.

LLM-as-judge는 질문·응답·맥락과 도구 추적을 읽어 통과 여부와 이유를 반환하지만 사람의 판정으로 보정해야 한다.

ASSERT는 YAML 명세에서 행동 범주와 합성 테스트를 만들고 여행 계획 평가에서 GPT-5.5가 가장 적은 위반을 기록한다.

DSPy와 GEPA는 명세의 제약을 만족하는 프롬프트를 탐색하며 Mistral용 출력 프롬프트를 만드는 데 약 6분이 걸린다.

Anthropic Messages API의 구조화된 인용과 로컬 Llama 지원은 출처 연결과 저비용 모델 배포를 위한 대안을 제공한다.