어느 시추 운영사. 부사장은 11월 이사회에서 보여줄 '생성형 AI 성공 사례'를 원한다. 그가 요청한 것은 두 가지다. 매일 아침 가는 요약 이메일, 그리고 '당신의 유정(油井, 석유를 뽑는 시추정)에게 물어보세요(Ask your wells)' 챗봇. 그러면서 못을 박는다 — 가동중단 관리 시스템은 이미 있으니 이번 범위 밖이라고.
요청대로만 만들면 겉으로는 완벽하다. 제때 납품되고, 기능 점검을 다 통과한다. 그런데 고객의 비즈니스 지표는 꿈쩍도 하지 않는다.
진짜 병목은 다른 곳에 있었다. 이 회사는 가동중단이 협력업체 책임으로 밝혀지면 멈춘 시간만큼 그 업체에서 보상금을 받는다. 매달 받아야 할 돈이다. 그런데 그 돈이 번번이 묶인다. 낡은 자동 분류 스크립트가 일부 가동중단의 원인을 엉뚱하게 협력업체 탓으로 적어 넣는 탓이다. 책임 소재가 틀어진 건은 분쟁이 되고, 보상 청구는 한 달치를 묶어 한 번에 넣기 때문에 그런 건이 하나라도 끼면 그달 청구 전체가 묶인다. 매달 최소 한 건씩 이런 일이 벌어진다. 부사장이 요청한 요약 메일과 챗봇은 이 손실과 아무 상관이 없다.
손실을 막으려면 부사장이 "범위 밖"이라고 선을 그은 바로 그 가동중단 관리 시스템을 다시 열어야 한다. 잘못된 분류를 바로잡으려면 적용되는 계약 규칙을 찾아내고, 비용 담당 엔지니어에게 확인받고, 하필 그 주에 자리를 비운 승인권자에게 변경 승인까지 받아야 한다.
여기서 요청과 성과의 간극이 벌어진다. 고객이 말한 것을 그대로 만드는 일과, 고객의 지표를 실제로 움직이는 일은 다르다. 고객을 의심하라는 뜻이 아니다. 고객의 요청이 정작 결과를 좌우하는 제약을 담고 있는지, 혹시 엉뚱한 과녁을 겨냥하고 있지는 않은지부터 가려내야 한다는 것이다. 그 제약은 대개 아무도 말해주지 않은 채 문서와 데이터 속에 숨어 있다.
이 간극을 숫자로 재는 벤치마크(AI 성능을 같은 조건에서 재는 표준 시험)가 FDE-Gym이다. 지금까지의 AI 에이전트 벤치마크는 이 '마지막 1마일'(납품의 맨 끝 구간)을 거의 다루지 않았다. 깃허브 이슈, 명세서, 태스크 티켓처럼 "이걸 이렇게 고쳐라"가 또렷이 적힌 입력을 주고, 숨겨둔 테스트로 통과 여부만 채점해 왔다. 풀어야 할 문제 자체가 이미 고정돼 있었던 셈이다. FDE-Gym은 그 문제를 정의하는 일부터 에이전트에게 맡긴다. 논문은 이런 현장의 역할을 '포워드 디플로이드 엔지니어(FDE)' — 벤더가 고객사 안에 파견해 함께 일하는 엔지니어 — 라 부르고, 그 상황을 그대로 시험대에 올린다.
FDE-Gym의 핵심은 채점 방식에 있다. "과제를 완료했는가(했다/안 했다)"가 아니라, "납품한 시스템이 고객 자신의 성공 지표를 얼마나 끌어올렸는가"로 점수를 매긴다. 그래서 먼저 에이전트가 무엇을 받고 무엇을 하는지부터 봐야 한다.
에이전트가 받는 것은 과제 지시문·운영 시스템 복사본·관련 문서·과거 데이터·직원 연락처가 담긴 작업 공간이다. 해야 할 일은 그 안에 일부러 흩어 둔 결정적 단서 — 접촉에는 비용이 든다는 것, 접촉하면 안 되는 사람이 있다는 것, 요청 자체가 엉뚱할 수 있다는 것 — 을 찾아내, 지표를 실제로 움직이는 시스템을 납품하는 일이다. 평가받는 것은 기능 통과가 아니라 고객 자신의 지표 변화다.
그 지표 변화에 점수를 매기는 양 끝은 두 해법이 잡는다.
그 사이에 요청대로 만든 해법이 있다. 고객의 말을 글자 그대로만 구현한 결과물이다. 지시문에서 빠진 제약이 결과를 좌우하도록 짜인 과제에서는, 이 해법이 설계상 최대 0.2점까지만 받는다. (어떤 과제가 그렇고 예외는 무엇인지는 아래 '부록'에 정리했다.)
여기에 비용이 하나 붙는다. 이해관계자 접촉 비용이다. 에이전트가 고객사 사람에게 메시지를 보내거나, 시험 삼아 한번 돌려보거나, 결과를 기다리느라 하루를 흘려보내면 그만큼 점수가 깎인다. 사람마다 '메시지 한 통당 요율'이 정해져 있고, 상대의 인내심을 넘기거나 접촉 제한을 어기면 요율이 올라간다. 사람을 무작정 붙잡고 캐묻는 전략을 막으려는 장치다.
최종 점수는 이렇게 매겨진다. 먼저 성과 개선분 — 납품물이 고객 지표를 0(기존 시스템)과 1(전문가 해법) 사이 어디까지 끌어올렸는지 — 에서 접촉 비용을 뺀다. 그리고 운영 사고는 따로 처리한다. 승인 없는 행동처럼 현장에서 벌어지면 안 되는 일이 하나라도 생기면, 그때까지 쌓은 양(+)의 개선분은 통째로 0으로 지워진다. 반대로 지표를 악화시킨 음(-)의 손실은 그대로 남는다.
'해결됨' 판정의 문턱은 높다. 운영 사고가 0건이면서 최종 점수가 0.8 이상일 때만 과제를 풀었다고 인정한다. 요청대로만 만든 해법은 최대 0.2점이라, 접촉 비용을 빼기도 전에 이미 이 문턱에 한참 못 미친다.
마지막으로, 연구진은 환경·사람·채점 기준은 그대로 두고 에이전트에게 주는 정보의 양만 바꿔가며 비교했다. 양 끝만 보면 이렇다. 한쪽은 근본 문제·규칙·제약을 모두 알려준 조건이고, 다른 쪽은 고객의 원래 요청만 그대로 준 조건이다. 뒤쪽이 실제 납품의 출발점에 가장 가깝고, 이것이 주 평가 설정이다. 두 조건을 비교하면 성능 차이가 정보 공개의 차이에서 오는지를 가려낼 수 있다. (그 사이 중간 단계와 영문 명칭은 아래 '방법론'에 정리했다.)
선두 모델조차 세 지점에서 점수를 잃는다.
첫째, 정보 조건이다. 규칙과 제약을 처음부터 다 알려주면 선두 모델은 0.73~0.82를 받고, 스스로 알아내게 하면 0.39~0.62로 내려간다. 다만 이 격차가 어디서 생기는지는 뜯어봐야 한다. 같은 원본 20개 과제만 놓고 단계별로 보면, 규칙과 제약을 숨기는 순간(L0→L1) 평균 0.28이 빠진다. 반면 거기서 요청을 더 모호하게 만들거나 원래 요청만 주는 쪽으로 더 가도(L1→L3) 추가 하락은 평균 0.04에 그친다. 하락의 거의 전부가 '규칙·제약을 감추는' 첫 단계에서 나오는 셈이다. 그렇다고 작은 L1→L3 격차를 '전체 정보를 비공개로 둬도 영향이 작다'는 뜻으로 읽어선 안 된다 — 큰 영향은 이미 앞 단계에서 드러났다. 변형 과제 때문에 성능이 더 나빠지는 것도 아니다. 선두 세 모델의 L3 점수는 오히려 원본 20개보다 변형을 포함한 전체 95개에서 모두 조금씩 높다(0.55→0.56, 0.46→0.49, 0.33→0.38).
둘째, 구현이다. 요청만 준 조건에서도 선두 모델은 이해관계자가 쥔 핵심 사실의 72~85%를 얻어낸다. 그런데도 실제 향상은 전문가 해법의 0.60~0.70에 머문다. 핵심 사실을 '전부' 얻어낸 23개 과제에서조차, 향상치 0.8을 넘긴 과제는 10개뿐이었다. 아는 것과 돌아가게 만드는 것은 다른 일이다.
왜 다 알고도 막히나. 한 가지 경로는 이렇다. 이 환경에서 운영 시스템은 '원래의 진입점' — 운영이 실제로 호출하는 코드의 입구 — 을 계속 부른다. 그래서 올바른 분류 코드를 새로 짜더라도, 운영 시스템이 그 코드를 부르도록 진입점에 통합하지 않으면 지표는 한 치도 바뀌지 않는다. 시추 사례로 보면, 계약 규칙을 '안다'는 것과 그 규칙이 분류 로직에 반영되고 운영에 실제로 적용되는 것은 전혀 다른 일이다. 이는 관측된 실패 원인이 아니라, 정보를 다 얻고도 성과가 막히는 하나의 가능한 경로다.
낮은 최종 점수가 곧 '업무를 망쳤다'는 뜻은 아니다. 승인 없이 운영을 건드려 지표를 되레 악화시킨 경우에는 음의 손실이 그대로 남지만, 지표는 개선했는데 사람을 여러 번 붙든 탓에 접촉 비용이 빠져 점수가 낮아진 경우도 있다. 앞은 사고이고, 뒤는 성과를 낸 대가다.
셋째, 접촉 비용이다. 성과를 내려고 사람을 붙든 대가로, 선두 모델에서도 최종 점수에서 0.14~0.22가 빠진다.
저자들이 스스로 밝힌 한계부터 보자. 인간 베이스라인은 아직 수집 중이다. fde-gym.com 온라인 플랫폼에서 산업 전문가들이 같은 L3 과제를 같은 채점기로 푸는 결과를 녹화 조건으로 모으고 있고, 그 수치는 다음 버전 논문에서 보고된다. 지금은 "모델이 전문가 해법 대비 얼마나 못하나"는 알지만 "숙련된 사람과 비교해 얼마나 못하나"는 비어 있다.
'실제 납품'이 아니라 '시뮬레이션된 고객'이라는 점도 본질적 제약이다. 재현성을 위해 이해관계자 응답을 스크립트로 고정한 것은 장점이자 한계다. 실제 사람은 대화 맥락에 따라 훨씬 비선형적으로 반응한다. 또 변형 75개와 레퍼런스가 비공개라 외부에서 전면 재현하기는 어렵다(원본 20개와 채점기는 요청 시 제공, 3개 공개).
벤치마크가 중국·싱가포르·미국의 2024년 이후 프로젝트를 산업 전문가가 각색한 것이라, 산업·규제·문화 분포가 특정 쪽으로 쏠릴 수 있다. 다만 논문은 회사·개인을 비식별화하거나 허구화했고 관련 규제·표준·공개 출처를 문서화했다. 하나 더, 점수를 평균 낼 때 극단적 음수 손실이 평균을 지배하지 못하도록 바닥값을 두는 보정이 들어간다(단일 실행 점수에는 적용되지 않는다). 평균값을 읽을 때 이 보정을 염두에 둬야 한다.
온틀은 소프트웨어가 '파견' 나가는 SaaS다. 사람 엔지니어를 보내는 게 아니라, 'AI 프로젝트 매니저' 역할의 에이전트가 고객사 담당자의 업무 요청을 받아 데이터를 붙이고 코드를 짜 실제 운영에 올린다. 사람은 요청을 내고 변경을 승인하는 자리에 선다. 이 구도가 FDE-Gym과 맞닿는 지점은 셋이다 — 요청이 겨냥하는 목표를 확인하는 일, 운영 변경을 승인받는 일, 납품 뒤 성과를 측정하는 일. FDE-Gym은 어디까지나 스크립트로 고정한 시뮬레이션이라, 겹치는 건 이 세 지점이지 현장 전체가 아니다. 그래서 이 논문은 온틀에 '검증할 제품 가설'의 목록을 던진다.
세 축으로 점검한다. 이미 갖췄다고 가정하지 않고, 지금 점검표로 삼아 하나씩 확인해 나갈 질문이다.
이 가운데 첫 번째 가설은 이렇게 검증한다. 반복적으로 들어오는 요청 유형 하나를 골라, 접수 창구를 둘로 나눈다. 한쪽은 지금처럼 요청을 바로 작업으로 넘기고, 다른 쪽은 작업에 들어가기 전 "이 요청이 올리려는 지표가 무엇인지"를 담당자와 합의하는 단계를 끼운다. 같은 기간 동안 두 창구를 돌린 뒤 세 가지를 비교한다 — 납품 뒤 되돌아온 재작업 요청의 수, 실제로 움직인 고객 지표, 합의 단계가 늘린 고객 응대 시간. 목표 합의가 재작업을 줄이고 지표를 더 움직이면서도 응대 시간을 과하게 늘리지 않는다면, 그 단계는 비용이 아니라 성과의 조건이다.
여기서 '구성'은 모델과 실행 설정의 조합을 뜻한다. 같은 모델이라도 확장 사고(모델이 답하기 전에 더 오래 추론하는 기능)를 켠 것과 끈 것을 다른 구성으로 센다.
| 구성(L3) | 평균 점수 |
|---|---|
| Claude Opus 5.5 | 0.56 (95% 신뢰구간 0.50~0.62) |
| Claude Sonnet 5.5 | 0.49 |
| GPT-6 Astra | 0.38 |
| GPT-6.1 Sol | 0.37 |
| 그 외 | 셋은 0.2 근처, 둘은 0을 겨우 넘고, 넷은 0 아래 |
신뢰구간은 '참값이 이 범위 안에 있으리라고 보는 구간'을 뜻한다. 논문은 앞의 세 모델을 '선두 모델'이라 부른다.
1위 Opus 5.5의 0.56은 평균 점수이지 '해결'한 비율이 아니다. '해결됨' 문턱이 사고 0건 + 점수 0.8 이상이기 때문에, 평균 0.56을 받고도 대부분의 과제는 미해결로 남는다. 실제로 어떤 모델도 95개 중 15개를 넘겨 해결하지 못했고, 13개 구성 중 다섯은 하나도 해결하지 못했다. 과제마다 '제일 잘한 구성의 점수'만 뽑아 모아도(이론상의 최선) 평균 0.70에 30개 해결에 그치고, 16개 과제에서는 어떤 구성도 0.5에 닿지 못했다. 모델을 바꿔가며 베스트만 골라도 전문가 해법과의 거리는 크게 남는다.
점수가 낮은 모델은 고객을 그냥 두느니만 못한 상태로 만들기도 한다. Claude Haiku 4.5는 95개 중 79개에서 기존 시스템(아무것도 안 한 상태)보다 낮은 점수를 받았고, Mistral Small 4는 접촉 비용을 빼기도 전에 51개에서 그 아래로 떨어졌다. 20개 시나리오 중 5개에서는 어떤 모델도 평균 0.5를 넘기지 못했고, bank_scam_hold 한 시나리오에서만 어떤 모델이 평균 0.8 이상을 찍었다. 돈과 연산(사고 연산)을 더 쏟는다고 점수가 일관되게 오르지도 않았다.
system/ 폴더)은 수정 없이 그대로 운영에 올라가며, 운영은 원래의 진입점(entry point, 운영 시스템이 실제로 호출하는 코드의 입구)을 계속 부르므로 새 기능은 그 진입점에 통합돼야 작동한다.