10월 21일 수요일
모델을 바꾸는 일은 이름 한 줄을 교체하는 작업이 아니다. 실제 입력의 평가, 컨텍스트의 선별, 장기 실행 하네스, 출력 계약을 각각 검증 가능한 경계로 나눠야 한다.
모델 스왑을 배포 전략으로 바꾸는 평가 스택
단일 벤치마크 순위 대신 실제 입력, 근거 준수, 도구 추적, 사람 보정을 계층화해야 교체 가능성이 생긴다.

순위표를 버리고 제품 경로를 복제한다
모델 교체의 첫 테스트는 추상 점수가 아니라 서비스가 실제로 통과하는 경로여야 한다. 워크숍은 같은 네 모델을 문자 계산, 검색증강생성(RAG), 이미지 입력, 함수 호출, 에이전트 루프에 차례로 넣었다. 단순 문자 세기에서 GPT-5.5와 Kimi K2.6은 13을 냈지만 DeepSeek V4 Flash는 6, Mistral Large 3은 8을 냈고, Mistral은 단어별 분해를 지시한 뒤 정답에 도달했다. 이 작은 사례가 구분해야 할 두 실패를 보여준다. 지시를 구조화하면 회복되는 문제와, 입력 양식이나 모델 능력 때문에 프롬프트만으로 고치기 어려운 문제다. 따라서 교체 게이트는 정답률 하나가 아니라 제품 입력의 언어·이미지·근거·도구 조건을 고정하고, 모델별 실패가 어느 층에서 발생했는지 기록해야 한다.
근거 경계와 도구 스키마도 테스트 대상이다
RAG 과제에는 목수벌 정보만 있었고 꿀벌 정보는 없었다. GPT-5.5와 DeepSeek는 자료 부재를 인정했지만 Mistral은 학습 지식으로 빈칸을 채웠다. 출처 표기를 강제하자 출처 없음이라고 표시했어도 그 주장을 답변에서 제거하지는 않았다. 형식상 인용과 실제 근거 준수를 같은 지표로 보면 안 되는 이유다. 함수 호출에서도 모델은 함수 자체를 실행하지 않고 이름과 인수를 제안하며, 애플리케이션이 실행을 맡는다. 일정 생성 예제에서 요청하지 않은 참석자나 기대와 다른 장소 값이 들어간 결과는 모델 오류인 동시에 JSON Schema의 이름·타입·설명이 모호하다는 신호였다. 평가 세트는 최종 문장뿐 아니라 근거 밖 주장 비율, 선택된 도구, 인수 계약, 수정한 스키마의 회귀 여부를 함께 검사해야 한다.
에이전트는 답보다 실행 추적으로 판정한다
같은 정답도 실행 비용은 다르다. 계산 과제에서 GPT-5.5는 한 번의 도구 호출로 답했고 DeepSeek는 네 번 호출했다. 여행 계획에서는 GPT-5.5가 독립적인 항공편·호텔 검색을 병렬로 시작한 뒤 예산과 활동을 확인했지만, Kimi는 순차 실행과 추가 예산 검사로 호출이 두 번 더 들었고 Mistral은 예산 검사와 활동 추천 전에 멈췄다. 이 결과는 워크숍의 한 과제에서 관찰된 실행이지 보편 순위가 아니다. 운영 평가는 최종 출력만 저장하지 말고 도구 정의, 호출 순서, 인수, 응답, 병렬화 가능성, 완료 조건을 추적으로 남겨야 한다. 함수명·인수처럼 결정론적으로 비교할 수 있는 항목은 직접 검사하고, 경로 품질처럼 열린 판단은 질문·응답·원문 맥락과 전체 추적을 판정 모델에 주되 도메인 전문가 라벨로 판정기 자체를 보정한다.
평가를 코드와 운영 주기로 분리한다
평가 스택은 빠른 계약 검사와 비용이 큰 의미 평가를 분리해야 한다. 워크숍은 RAG 평가가 200개 이상, 때로 약 800개 사례가 될 수 있어 LLM 호출 평가를 일반 단위 테스트나 매 커밋 CI에 모두 넣지 말라고 조언한다. 이 규모는 발표자가 든 운영 예시이지 권장 최소치가 아니다. 실제 사용자 입력에서 날짜, 다국어, 속어 같은 사례를 계속 추가하고, 앱의 응답·검색 맥락을 저장해 앱 변경과 평가기 변경을 독립적으로 비교하는 편이 낫다. ASSERT는 명세에서 허용·위반 행동과 합성 시나리오를 만들고, DSPy와 GEPA는 선언한 제약을 만족하는 프롬프트를 탐색한다. Mistral 대상 데모의 약 6분 최적화 역시 한 실험의 소요 시간일 뿐이다. 프롬프트를 생성 산출물로 다루려면 명세, 평가 기록, 제공자별 API 차이까지 버전 관리해야 교체를 되돌릴 수 있다.
긴 실행의 신뢰성은 무엇을 기억하고 어디서 계속 돌릴지에 달렸다
컨텍스트 정리와 하네스 운영을 한 문제로 뭉치지 말고, 정보 품질·상태 복구·권한·비용을 서로 다른 책임으로 설계한다.
장기 에이전트에서 모델의 컨텍스트와 제품 하네스는 각각 무엇을 책임져야 하는가?
긴 작업이 흔들릴 때 컨텍스트 창을 더 크게 하거나 시스템 프롬프트를 더 길게 쓰는 처방만으로는 부족하다. 컨텍스트는 현재 단계에 필요한 사실·지시·도구 결과를 선별하는 작업 메모리이고, 하네스는 그 작업이 어느 런타임에서 계속되는지, 상태를 어떻게 복구하는지, 어떤 도구와 권한을 허용하는지 관리하는 시스템 경계다. 컨텍스트 실패는 틀린 메모가 사실로 굳는 포이즈닝, 긴 이력이 현재 판단을 끄는 디스트랙션, 도구가 너무 많아지는 컨퓨전, 낡은 정보와 정정이 충돌하는 클래시로 나뉜다. 반면 하네스가 맡을 문제는 중단·재개, 이벤트 구독, 다중 에이전트 조정, 최소 권한, 비용과 속도의 관측이다. 두 층을 분리해야 모델 업데이트로 불필요해진 보정은 제거하면서도 운영 안전장치는 보존할 수 있다.
- 01
기록 전 검증, 길어지면 압축
잘못 읽은 데이터베이스 드라이버 문서를 근거로 ‘자동 재시도된다’는 메모를 남기면 정상 재시도 코드를 연쇄 삭제할 수 있다. 메모를 쓰기 전에 문서와 짧은 연결 시험으로 검증하고, 긴 메시지 이력은 현재 목표와 진행 상태만 남겨 압축한다. 압축은 손실 변환이므로 상세 기록은 컨텍스트 밖의 영속 파일에 두고 필요할 때 다시 불러온다. 원문이 인용한 18개 프런티어 모델의 신뢰성 저하는 큰 창에서 관찰됐다는 요약이며, 연구 조건 전체가 제공된 것은 아니므로 모든 작업의 동일한 저하율로 일반화할 수 없다.
- 02
도구는 큐레이션하고 대체된 상태는 제거
도구 정의도 컨텍스트를 차지하고 선택지를 늘린다. 원문이 든 한 벤치마크에서는 46개 도구 조건에서 실패한 모델이 19개 조건에서 같은 작업을 통과했다. 이는 한 벤치마크의 조건 비교이지 도구 수의 보편 임계값은 아니다. 시작 시 필요한 도구만 노출하고 나머지는 지연 제공하며, 정정된 사실이 생기면 낡은 메모를 함께 남기지 말고 제거한다. 새 창을 열 때는 수정된 현재 상태만 옮겨 모순을 차단한다.
- 03
런타임은 컨텍스트 밖의 연속성을 책임진다
작업이 분에서 시간·일 단위로 늘면 잠들 수 있는 개인 노트북과 한 번의 대화창은 안정적인 실행 기반이 되기 어렵다. 하네스는 실행 루프, 상태 저장과 재개, 외부 시스템 연결을 유지하고, 조정자와 작업자 에이전트가 장기 업무를 나누도록 오케스트레이션한다. 버그 분류, 클라우드 수정, 전후 영상 검증, 배포 후 감시를 잇는 메타 하네스 사례는 최종 코드 생성보다 단계 사이의 인계와 증거가 제품 책임임을 보여준다.
- 04
가드레일은 관찰 가능하고 제거 가능해야 한다
모델이 코드 탐색이나 테스트 습관을 익히면 그 행동을 반복 강제하던 프롬프트는 줄일 수 있다. 그러나 비밀 키 접근, 돌이킬 수 없는 행동, 과도한 API 비용을 막는 최소 권한과 승인 경계는 별개다. 임시 보정 장치는 중앙의 shim으로 기록하고 호출 로그를 남겨, 새 모델에서 더는 쓰이지 않을 때 제거 후보로 만들 수 있다. 하네스 연구에서 점수가 비슷해도 과업당 비용이 달랐다는 발표의 요약처럼, 품질 지표와 캐시·토큰·모델 조합의 운영 효율도 분리해 측정해야 한다.
실무 경계는 명확하다. 모델에 보여 줄 현재 정보는 검증·압축·큐레이션·정리하고, 오래 지속되어야 할 상태와 권한은 하네스가 맡는다. 임시 프롬프트 보정과 영구적인 보안 통제를 같은 층에 묶지 말고 각각 사용 로그, 제거 조건, 실패 복구 절차를 둔다. 그래야 모델이 좋아질 때 하네스를 가볍게 만들면서도 장기 실행의 신뢰성은 잃지 않는다. 발표자가 제시한 ‘6개월 안에 작업의 90%가 노트북 밖에서 실행된다’는 수치는 관측 결과가 아니라 전망이므로 용량 계획의 확정값으로 사용해서는 안 된다.
문장을 생성할 것인가, 결정을 반환할 것인가
출력의 소비자가 사람인지 코드인지에 따라 범용 생성과 제한형 판단의 계약·검증·비용 구조가 달라진다.
범용 생성형 모델사람이 읽을 설명과 복잡한 추론에 적합하지만, 코드가 단일 라벨을 원하면 구조화 출력 스키마와 파싱·예외 처리가 필요하다.
제한형 판단 모델영상에서 소개된 Jev는 선택·점수·예/아니오 확률처럼 미리 정한 형태만 반환해 후속 코드가 바로 분기하도록 설계됐다.
범용 생성형 모델자유로운 작성, 긴 설명, 복잡한 계산처럼 열린 출력 공간이 필요한 일에 남겨 둔다.
제한형 판단 모델같은 리뷰의 감성·열정·배송 지연을 서로 독립적으로 동시에 판정하는 식으로 대량 분류, 라우팅, 실시간 선택에 맞춘다.
범용 생성형 모델출력 모양과 내용 정확성을 모두 검사하고, 선택형 응답이 필요하면 허용값 밖 문자열과 파싱 실패를 다룬다.
제한형 판단 모델선택지 밖 문장을 만들지 않는다고 의미상 정답이 보장되지는 않는다. 신뢰도·확률을 기록하고 숫자·날짜 비교는 결정론적 코드나 다른 모델로 분리한다.
범용 생성형 모델같은 입력과 같은 판단 과제를 기준으로 지연시간, 정확도, 총 입출력 비용을 다시 측정해야 비교 기준이 맞는다.
제한형 판단 모델영상의 약 200배 속도와 400배 비용 절감은 개별 지연시간·벤치마크 조건·비용 산식이 공개되지 않은 소개 주장이다. 입력 백만 토큰당 약 4센트와 출력 무료라는 제시값도 실제 워크로드에서 검증해야 한다.
둘 중 하나를 전면 선택하기보다 출력 계약으로 라우팅하는 구성이 현실적이다. 설명과 복합 추론은 생성형 모델에, 반복되는 닫힌 선택은 판단 모델에 맡긴다. 그 뒤 같은 데이터셋에서 정확도, 확률 보정, 지연, 총비용을 측정해야 전용 판단 모델의 이점이 실제 제품에서도 유지되는지 알 수 있다.
아직 못 읽은 북마크
북마크를 고르는 중…