이번 주 자료에서 가장 눈에 남은 장면은 배송 문제가 해결되지 않았는데 상담 티켓을 닫아버린 에이전트였습니다.

필요한 정보를 조회했고, 도구도 여러 번 호출했습니다. 얼핏 보면 꽤 많은 일을 했습니다. 그런데 마지막에 남긴 상태가 틀렸습니다.

이번 주에는 이 문제와 연결해서 볼 만한 도구도 몇 가지 나왔습니다. 애매한 판단을 다른 모델에게 넘기는 기능, 모델이 실패한 일을 새 학습 과제로 만드는 방법입니다.

각각은 분명 쓸모가 있어 보입니다. 다만 이런 장치를 하나씩 붙이다 보면 다른 질문도 생깁니다.

무엇을 확인하면 다음 단계로 넘어가도 될까요?

먼저 이번 주에 볼 만했던 세 소식을 소개합니다.

조사 범위는 한국 시간 기준 2026년 10월 2일~7일 작성 시점까지입니다. 세 항목 모두 PROOF LEVEL 03 · 공식 확인이며, 공개 자료를 확인한 수준입니다. 실행 환경이나 성능을 직접 재현한 결과는 아닙니다.

ThinkingBox — 도구를 아홉 번 썼는데 티켓은 잘못 닫혔다

배송이 지연된 고객의 문의를 받은 에이전트가 주문과 배송 상태를 확인하고 정책을 찾은 뒤 상담 티켓을 만듭니다.

여기까지는 별다른 문제가 없어 보입니다.

그런데 아홉 번의 도구 호출 끝에 에이전트는 티켓을 ‘해결됨’으로 닫습니다. 배송 문제는 여전히 남아 있었고, 요구된 상태는 ‘보류’였습니다.

Microsoft와 Hugging Face가 10월 3일 공개한 ThinkingBox 게시물에 나온 합성 평가 사례입니다. 실제 고객 사고는 아닙니다. ThinkingBox 연구 자체는 8월에 먼저 공개됐고, 이번 게시물에서는 평가 결과와 Hugging Face·OpenEnv를 통해 직접 실행할 수 있는 경로를 소개했습니다. 공식 공동 게시물

ThinkingBox가 보는 것은 도구를 정상적으로 불렀는지만이 아닙니다.

작업이 끝난 뒤 데이터가 요구된 상태가 됐는지, 필요하지 않은 변경까지 일어나지는 않았는지를 함께 확인합니다. 공개 환경에서도 각 시도를 별도의 초기 상태에서 시작하고 최종 상태와 부수 효과를 평가합니다. 환경 문서

업무 507개를 각각 20회 평가했다는 점도 볼 만합니다. 여기서 한 번이라도 성공한 업무와 20회 모두 성공한 업무를 따로 보여줍니다.

데모를 고른다면 전자가 더 눈에 들어올 수 있습니다. 하지만 같은 일을 계속 맡기려 한다면 후자의 숫자가 더 궁금해집니다.

물론 20번 성공했다고 해서 21번째 실행도 성공한다는 보장은 없습니다.

그래도 ‘한 번 해낼 수 있는 일’과 ‘반복해서 맡길 만한 일’의 차이는 드러납니다. 같은 일을 계속 맡기려는 팀에는 평균 점수와 함께 볼 숫자입니다.

Vercel — 애매한 답에는 모델을 한 번 더 부른다

모델이 애매한 답을 냈을 때 더 큰 모델에게 한 번 더 물어보면 어떨까요.

Vercel은 10월 6일 AI Gateway에 decision fallback을 추가했습니다. 어떤 답을 다른 모델에게 다시 물을지 개발자가 조건을 정할 수 있습니다.

첫 번째 요청이 정상적으로 끝났더라도 조건에 해당하면 재판단을 요청합니다. 오류가 났을 때 작동하던 기존 fallback도 그대로 유지됩니다. 현재는 베타 기능입니다. 공식 변경 기록

처음부터 모든 요청을 더 비싼 모델로 처리하고 싶지 않은 팀이라면 한 번쯤 살펴볼 만합니다.

다만 설정해야 할 것은 두 번째 모델의 이름만이 아닙니다.

무엇을 ‘애매한 답’이라고 볼지도 정해야 합니다.

Choice·Score 질문은 confidence 조건을 사용하고, Boolean 질문은 확률 구간을 사용합니다. 예를 들어 ‘참’일 확률이 아주 낮다면 그것은 불확실한 답이라기보다 분명한 ‘거짓’일 수 있습니다.

숫자가 낮다고 전부 fallback 대상으로 보내면 안 되는 이유입니다. Vercel 역시 문서에 나온 임계값은 예시일 뿐 운영 환경의 권장값이 아니라고 설명합니다. 공식 해설

두 번째 모델은 첫 답을 채점하지 않습니다. 원래 상태와 질문 전체를 다시 받아 판단하고, 두 번째 응답이 첫 결과를 대체합니다. 두 단계 모두 비용이 발생합니다.

그래서 이 기능을 시험할 때 볼 숫자도 단순히 ‘fallback이 몇 번 발생했는가’에서 끝나기 어렵습니다.

첫 모델이 틀린 답을 얼마나 고쳤는지, 반대로 처음에는 맞았는데 재판단 이후 틀어진 경우는 없었는지도 같이 봐야 합니다.

Vercel도 첫 번째 모델만 사용했을 때와 전체 fallback 정책을 적용했을 때의 최종 정확도를 비교하도록 안내하고 있습니다.

AutoSynthData — 틀린 답을 넣어서 채점기를 시험한다

AI 학습용 문제를 많이 만들 수 있어도, 그 문제가 실제로 풀 수 있는 문제인지와 답을 제대로 채점할 수 있는지는 별개의 이야기입니다.

불가능한 문제를 계속 만들거나 틀린 답에 보상을 준다면 데이터가 많아져도 도움이 되기 어렵습니다.

ServiceNow CoreAI가 10월 2일 설명한 AutoSynthData는 이 부분까지 함께 다룹니다.

대상 모델이 실패하고 더 강한 교사 모델이 성공한 업무를 분석한 뒤, 부족한 능력을 연습할 새로운 과제를 만듭니다. 생성되는 과제에는 요청 문장뿐 아니라 시스템 조건과 성공 여부를 판단하는 검증기도 함께 포함됩니다. 공식 기술 게시물

여기서 특히 눈에 들어오는 부분은 검증기 자체를 다시 시험한다는 점입니다.

먼저 의도한 해결 과정을 실행해 통과하는지 확인합니다. 그다음 예상 결과 일부를 일부러 틀리게 바꿔봅니다. 그런데도 통과한다면 검증기가 잘못된 결과를 걸러내지 못한 것입니다.

예를 들어 예약 한 건이 존재한다는 사실만 확인하는 검증기가 있다고 생각해볼 수 있습니다.

날짜가 틀렸거나, 잘못된 사람의 예약이 만들어졌거나, 같은 예약이 두 번 생성돼도 통과한다면 이 검증기가 확인한 것은 우리가 기대한 ‘예약 성공’과는 다릅니다.

AutoSynthData는 EnterpriseOps Gym의 Hybrid·ITSM 환경에서 합성 데이터 학습 실험 결과도 함께 보고했습니다.

다른 회사의 운영 환경에서도 같은 효과가 나온다고 볼 수는 없습니다.

다만 합성 데이터를 단순히 ‘얼마나 많은 문장을 만들었는가’가 아니라 실행할 수 있고, 결과까지 판정할 수 있는 과제인가라는 관점에서 다룬다는 점은 참고할 만합니다.

확인 장치가 늘어나면 무엇을 믿어야 할까

ThinkingBox는 평가 환경이고, Vercel은 요청을 다른 모델로 넘기는 제품 기능이며, AutoSynthData는 학습 데이터를 만드는 방법입니다.

서로 직접 연결된 기술은 아닙니다.

그런데 이번 주에 이 세 가지를 함께 보다 보니 한 가지 질문이 남았습니다.

모델 바깥에 확인 장치를 붙이기 시작하면, 이제는 그 확인 장치들을 어떻게 믿어야 할까요.

이런 상황을 가정해보겠습니다. 첫 번째 모델은 확신하지 못합니다. 그래서 두 번째 모델에게 넘겼고, 두 번째 모델은 진행해도 된다고 판단했습니다. 별도의 검증기도 통과했습니다.

그런데 운영자가 살펴보니 필요한 입력 하나가 처음부터 빠져 있었습니다. 기록에는 재판단도 검증도 통과했다고 남았지만, 그 기록만으로 실행을 허용하기는 어렵습니다.

여러 단계가 통과했다고 해서 서로 다른 근거로 확인한 것은 아닐 수 있습니다. 같은 정보 누락을 모델과 검증기가 함께 놓쳤다면, 확인 횟수가 늘어도 그 빈틈은 남습니다. 앞 단계에서 생긴 의심이 마지막의 ‘통과’ 표시 하나에 가려질 수도 있습니다.

이것은 이번 발표들이 실제로 입증한 결과가 아니라, L-Proof가 이런 구조를 운영 환경에 적용할 때 예상하는 실패 가능성입니다.

그래서 앞으로 에이전트 제품에서 보고 싶은 것은 확인 기능의 개수만은 아닙니다.

왜 이 결과를 받아들였는지, 무엇을 확인했고 무엇은 아직 확인하지 못했는지.

확인 단계가 많아질수록 오히려 사람이 마지막에 읽어야 할 내용은 더 단순하고 명확해야 할지도 모르겠습니다.

자동화의 경계는 평균 점수와 다른 곳에 있을 수 있다

조금 더 나아가면 자동화 범위를 정하는 기준도 다시 생각해볼 수 있습니다.

두 작업이 있다고 해보겠습니다.

하나는 거의 항상 맞지만, 틀렸을 때 그 사실을 알아내기 어렵습니다.

다른 하나는 더 자주 틀리지만, 실행하기 전에 잘못을 찾아내고 멈출 방법이 있습니다.

성공률만 본다면 첫 번째 업무를 먼저 자동화해야 할 것처럼 보입니다.

하지만 오류의 영향과 복구 가능성까지 같이 본다면 두 번째 업무가 오히려 먼저 자동화하기 쉬울 수도 있습니다.

L-Proof는 여기서 모델 점수와 자동화 범위가 어긋날 수 있다고 봅니다. 더 잘하는 모델로 바꿔도, 남은 오류를 발견할 방법이 없다면 사람의 확인을 빼기는 어려울 수 있습니다.

물론 반대쪽 문제도 있습니다.

검증기가 너무 자주 멈추거나, 애매할 때마다 사람에게 넘긴다면 자동화를 도입한 의미가 줄어듭니다.

모델이 좋아져서 아낀 시간을 검증 과정에서 다시 써버릴 수도 있습니다.

그래서 ‘더 많이 확인하자’만으로는 충분하지 않습니다.

놓친 오류가 얼마나 줄었는지와 함께, 정상적인 작업을 괜히 멈춘 횟수도 봐야 합니다.

이번 소식들 다음으로 L-Proof가 궁금한 숫자는 그래서 두 가지입니다.

사람이 다시 확인해야 하는 일은 실제로 줄었는가. 그러면서도 놓친 오류는 줄었는가.

L-Proof는 다음 발표에서 이 두 질문에 대한 답을 보고 싶습니다.