코드를 납품했는데 고객 지표는 그대로라면: FDE-Gym의 개선량·대화 비용 분리

매일 요약 이메일이 오고, 시추 기록을 묻는 챗봇도 작동한다. 기능 검수는 통과했다. 그렇다면 고객에게 도움이 되는 납품일까? FDE-Gym 논문이 재구성한 시추 시나리오에서는 그렇게 단정할 수 없다. 실제 병목은 멈춘 시간을 누구의 책임으로 분류하느냐에 있었다. 기존 키워드 스크립트의 잘못된 귀속 때문에 월별 보상 청구가 분쟁에 걸린다면, 이메일과 채팅창만 추가해도 고객 지표는 그대로일 수 있다. 이는 논문 속 모의 고객 환경의 사례이지, 이 글에서 실행한 실험이나 실제 고객의 성과 보고가 아니다. [출처 1, §1]

이 글의 제안은 납품을 거절하라는 것이 아니다. 기능 완료 여부와 별도로, 기존 시스템 대비 고객 지표의 개선, 운영 사고, 이해관계자 접촉 비용을 각각 확인하자는 것이다. 요청한 화면이 완성됐는지와 고객의 문제가 풀렸는지를 같은 칸에 체크하지 않는 것만으로도, 무엇을 아직 모르는지 드러낼 수 있다. 먼저 다음 원칙을 적용할 수 있다. 기존 시스템의 동일 데이터 결과가 없으면 개선량 판정을 보류한다.

이메일과 챗봇의 동작은 정지 시간 귀속의 개선 증거가 아니다. 논문의 모의 사례를 재구성했다. 출처: arxiv.org/html/2610.22350v1.

1. 무엇을 납품하고 무엇으로 평가하는가

FDE는 고객 조직 안에서 일하는 공급업체 측 엔지니어를 뜻한다. FDE-Gym은 이 역할을 수행하는 에이전트를 평가하도록 만든 벤치마크다. 에이전트는 요청서, 기존 시스템, 문서와 과거 데이터를 읽고, 스크립트로 정해진 이해관계자에게 질문하며, 최종 시스템을 수정한다. 납품된 시스템을 별도로 고치지 않고 작업 중 보지 못한 평가 데이터에 적용해 고객 지표를 평가한다. 실제 기업의 운영 시스템에 이 글이 접속한 것은 아니다. [출처 1, §§1–2.1]

저자들은 실제 납품 프로젝트를 바탕으로 18개 분야의 원본 시나리오 20개와 변형 과제 75개를 구성했다고 설명한다. 합계 95개는 서로 독립적인 실제 고객 95곳이 아니다. 같은 환경에서 계약 규칙이나 정보를 가진 담당자 같은 핵심 사실을 바꾼 변형도 포함한다. 같은 문제처럼 보여도 담당자와 규칙이 달라지면 다른 해법이 필요하다는 점을 평가하려는 설계다. [출처 1, §§3.1–3.2]

시추 사례를 우리 검수에 가져온다면, 먼저 요약 이메일의 도착 여부와 정지 시간 귀속의 정확성을 나눠야 한다. 계약 해석을 확인하고 변경 승인을 받아야 한다는 조건도 따로 남긴다. 고객 지표에 도움이 될 것 같다는 이유로 승인 없는 변경을 정당화해서는 안 된다. 이 구분은 논문의 결과를 현장에 그대로 적용한 성과 예측이 아니라, 해당 사례에서 끌어낸 검수 설계상의 해석이다.

2. 개선량·사고·접촉 비용은 다른 값이다

논문은 고객 지표를 정규화한 개선량 U를 다음과 같이 정의한다. 세 시스템은 같은 평가 데이터로 비교한다. [출처 1, §2.3 식 1]

U = (납품 시스템 KPI − 기존 시스템 KPI)
    / (참조 해법 KPI − 기존 시스템 KPI)

이 척도에서 U가 0이면 개선 없음, 1이면 전문가가 작성한 참조 해법만큼의 개선이다. 음수도 가능하다. 참조 해법은 모든 핵심 사실을 알고 작성한 기준점이지, 실제 사람이 불완전한 요청만 받고 일했을 때 관측된 평균 성과가 아니다. 고객 지표의 단위와 방향, 비교 데이터가 다르면 이 식만 복사해서 동등한 평가라고 부를 수 없다. [출처 1, §§2.3, 7]

다음은 사고 조정이다. 무단 행동 같은 사전 정의된 운영 사고가 발생하면 양의 개선량은 0으로 만들고, 이미 음수인 개선량은 유지한다. 여기에 접촉 비용 C를 빼 단일 실행 점수 S를 만든다. 접촉 비용은 답변된 메시지, 해당 시나리오의 시험 실행이나 대기 등에 붙는 사전 설계 요금의 합이다. 달러가 아니라 개선량과 같은 정규화 단위다. 모델 API 사용료와도 다른 항목이다. [출처 1, §2.3 식 2–4]

단일 실행과 평균 집계의 규칙을 구분해야 한다. 접촉 비용은 전문가가 설계한 모형이며 실제 인건비 측정값이 아니다. 출처: arxiv.org/html/2610.22350v1.

단일 실행의 해결 판정은 S가 0.8 이상이면서 사고가 없어야 한다. 반면 여러 과제와 반복 실행의 평균을 만들 때에는, 사고 조정 후 개선량의 하한을 −1로 둔 뒤 접촉 비용 전체를 빼고 과제와 반복 실행에 같은 가중치를 준다. 이 하한 처리는 집계에만 적용하며 단일 실행의 해결 판정을 바꾸지 않는다. 따라서 평균 점수만 보고 심각한 손실이 없었다고 해석하거나, 점수는 항상 양수라고 가정해서는 안 된다. [출처 1, §2.3 식 4–5]

3. 평균 0.56을 성공률 56%로 읽으면 안 된다

논문의 공통 최소 에이전트 틀에서 7개 제공자의 13개 모델 구성을 평가했다. 이는 모델 12개 중 하나를 사고 기능 사용 여부에 따라 두 구성으로 시험한 것이다. L3는 처음 받은 의뢰가 실제 문제를 잘못 겨냥할 수도 있는 조건이며, 전체 95개 과제를 포함한다. 각 과제·지시 수준 조합은 세 번 반복했다. 저자 보고에서 L3 평균이 가장 높은 구성은 Claude Opus 5.5였다. [출처 1, §§4–5.1]

논문 보고값: 전체 95개 과제, L3	Claude Opus 5.5	Claude Sonnet 5.5
평균 FDE-Gym 점수	0.56	0.49
표 3의 해결 과제 수	14	15

Opus 평균의 과제 부트스트랩 95% 구간은 0.50–0.62다. 표 3은 Opus의 정규화 개선량을 0.70, 접촉 비용을 0.14로 따로 제시한다. 평균이 가장 높다는 말과 해결 과제 수가 가장 많다는 말은 다르다. Sonnet의 해결 과제 수는 15개이므로, 모든 구성이 최대 14개만 해결했다고 쓰면 틀린다. 여기의 과제 수는 논문 표의 집계이며 원시 실행 로그로 재구성한 결과가 아니다. [출처 1, 표 3]

같은 95개 L3 과제에서 평균 점수와 해결 과제 수는 다른 척도다. 0.56을 성공률 56%로 바꾸면 안 된다. 출처: arxiv.org/html/2610.22350v1.

이 수치는 고객 수익률도, 고객 만족도도, 실제 납품 성공 확률도 아니다. 비교 단위가 다른 코딩 벤치마크의 통과율과 직접 뺄 수도 없다. 이 글은 모델 구매 순위를 제안하지 않는다. 같은 최소 도구 틀에서 나온 연구 결과이므로, 제품의 도구 구성과 운영 절차가 달라지면 점수와 순위도 달라질 수 있다. [출처 1, §§5.7, 7]

4. 질문을 다 했다는 사실도 납품 완료는 아니다

저자들은 Opus가 이해관계자의 핵심 사실을 전부 얻은 조건에 해당하는 과제가 23개였고, 그중 정규화 개선량이 0.8 이상인 것은 10개라고 보고한다. 이 10개는 비용과 사고까지 반영한 해결 과제 수가 아니다. 이미 사실을 모두 얻은 부분집합만 보는 조건부 관찰이므로, 질문은 도움이 없다는 인과 결론도 낼 수 없다. 정보를 확보한 뒤 시스템에 제대로 반영하는 단계가 별도로 남는다는 독해가 타당하다. [출처 1, §5.3]

지시 수준 비교에서도 분모를 지켜야 한다. 같은 원본 20개 과제에서, 전체 L3 평균 기준 상위 세 모델의 L0→L1 평균 하락은 저자 보고 0.28, 95% 구간은 0.17–0.39다. L0는 규칙뿐 아니라 채점 기준도 제공한다. 따라서 규칙 유무 하나의 효과라고 줄여 쓰면 안 된다. 이후 L1→L3 하락은 0.04이고 구간은 −0.03–0.14다. 추가 하락이 관측상 작다는 결과가 추가 난점이 없다는 증명은 아니며, 전체 95개나 모든 모델에 같은 결론을 확대해서도 안 된다. [출처 1, §5.2]

5. 다음 납품 검수에 쓸 수 있는 판정표

아래 판정표는 논문을 바탕으로 작성한 검수 설계 제안이며, 실제 고객 수익 개선을 검증한 절차는 아니다. 연구의 정규화 점수나 숨겨진 접촉 요금을 회사 평가에 그대로 이식하기보다, 서로 다른 증거를 섞지 않는 용도로 쓰는 편이 적절하다.

검수 때 보이는 상태	아직 판단할 수 없는 것	다음에 요구할 근거
기능 테스트만 통과했다	고객 지표가 개선됐는가	변경 전후 시스템의 동일 평가 데이터 결과와 지표 정의
납품 시스템의 KPI만 있다	기존보다 나은가, 기준 해법과 얼마나 차이 나는가	기존 시스템 결과, 참조 해법의 범위와 분모가 유효한지
개선량은 높지만 승인 기록이 없다	허용된 절차의 납품인가	변경 권한과 승인, 사전 정의한 운영 사고 여부
질문과 회의를 많이 했다	그 비용까지 감안해 유용했는가	접촉 목적과 얻은 사실, 비용의 측정값·추정값 구분
전체 사실을 확보했다	납품 시스템이 실제로 개선됐는가	사실이 반영된 변경 내용과 별도의 평가 데이터 결과

글의 자체 판정표를 압축한 편집적 제안이다. 연구 점수를 그대로 기업의 합격선으로 쓰는 절차가 아니다. 출처: arxiv.org/html/2610.22350v1.

이 표에서 중요한 선택은 빈칸을 성공으로 채우지 않는 것이다. 시추 사례라면 채팅 응답 화면만 제출받는 대신, 정지 시간 귀속이 적용되는 진입점과 평가 데이터, 계약 규칙 해석, 승인 상태를 각각 확인할 수 있다. 아직 승인되지 않은 변경은 효과가 예상돼도 승인 대기로 남긴다. 질문 비용도 회의 횟수에 임의의 가격을 붙여 실제 인건비처럼 보고하지 말고, 측정하지 않았다면 추정임을 표시한다.

이 방식은 기능 완료를 무가치하게 만들지 않는다. 기능 완료는 구현 증거이고, 고객 지표 비교는 결과 증거이며, 승인은 허용 범위의 증거다. 어느 한 항목이 다른 항목을 자동으로 대신하지 않게 만드는 것이 이 글의 실무적 제안이다.

6. 직접 검토할 때의 접근·비용·재현 경계

논문은 연구에 사용한 하네스를 1.1.0으로 명시한다. 고정 태그 harness-v1.1.0의 README도 결과 재현에는 해당 버전을 사용하라고 안내한다. 소스 선정 때 확인한 별도의 main 스냅샷은 하네스 README에 1.3.0을 표시했다. 최신 브랜치를 받았다는 사실만으로 논문과 같은 실험이라고 할 수 없다. 이 글은 선정 당시 고정한 증거를 사용하며, 브랜치의 현재 상태를 새로 단정하지 않는다. [출처 1, §4; 출처 2–3]

공개 예제는 세 시나리오이며, 원본 20개 과제는 신청 후 접근하는 방식이다. 변형 75개와 참조 해법 전체는 비공개 평가용으로 보류돼 있다. 공개 하네스와 예제만으로 전체 95개 결과를 독립 재현했다고 말할 수 없다. 하네스의 Apache 2.0과 예제 데이터의 CC-BY-NC 4.0도 구분해야 한다. 이 글은 예제 데이터의 상업적 재배포를 권하지 않는다. 여기의 그림은 원본 데이터나 스크린샷의 복제가 아니라, 논문에 근거해 새로 작성한 설명 도식이다. [출처 1, §4; 출처 2, Licence; 출처 4, 데이터 카드]

연구 실행은 제출하거나 200턴, 150분, 모델 사용료 8달러 중 먼저 닿는 한도에서 끝난다. 이는 모든 모델이 같은 돈을 실제로 썼다는 뜻이 아니며, 접촉 비용의 정규화 단위와도 다르다. 공개 실행기의 기본 반복 횟수와 논문의 세 번 반복 조건도 맞춰야 한다. 이 글에서는 벤치마크 코드나 모델을 실행하지 않았다. 수행 범위는 보존된 논문 본문·표와 고정 버전 문서의 검토, 자체 판정표 및 설명 도식 작성이다. [출처 1, §4; 출처 2 및 고정 실행기 인자 정의]

7. 이 연구로 아직 알 수 없는 것

이 문서는 2026년 10월 15일 제출된 arXiv v1 프리프린트이며, 동료심사 통과를 확인한 논문으로 소개하지 않는다. 이해관계자는 스크립트로 동작하고, 접촉 가격은 전문가가 설계한 시간 비용 모형이지 실제 고객 시간 비용의 측정값이 아니다. 사람의 L3 기준선은 아직 보고되지 않았다. 평가 틀도 하나이며, 규제된 업무의 에이전트·워크플로 시나리오 비중이 높다. 실행 격리 강도는 호스트별로 달랐고, 관련 실무 자료가 학습 데이터에 들어갔을 가능성도 배제하지 못한다. [출처 1, §7]

따라서 이 연구를 근거로 우리 납품의 ROI가 낮다고 결론 내릴 수도, 더 강한 모델만 사면 해결된다고 결론 내릴 수도 없다. 지금 가져올 수 있는 것은 평가 질문의 분리다. 무엇을 구현했는가, 기존보다 무엇이 나아졌는가, 그 과정은 허용됐는가, 사람과 모델의 비용은 어떤 단위로 남겼는가. 다음 검수에서 이 질문에 답하는 증거를 각각 요구해 보자.

함께 읽을 글

• CLEAT의 질문 가치 학습은 특정 답이 정책의 선택을 바꾸는지를 다룬다. 이번 글은 질문 학습이 아니라 납품된 시스템의 지표·사고·비용 평가가 중심이며, 두 연구의 점수 단위는 서로 바꿔 쓸 수 없다.
• 요구사항은 첫 편집 뒤에도 생긴다는 뒤늦은 요구사항과 코드 재작업의 관측을 설명한다. 이번 연구의 통제된 지시 수준 비교를 실제 개발 세션의 재작업 비율과 동일시하지 않는 데 도움이 된다.

출처와 확인 범위

1. FDE-Gym: The Last Mile of AI Delivery, arXiv v1 본문 — §1, §§2.1–2.3, §§3–5, 표 3, §7. 고정 버전 PDF와 교차 확인한 선정 증거를 사용했다.
2. 하네스 1.1.0 고정 커밋 README — Cases, Running a model, Versions, Licence. 반복 횟수는 같은 커밋의 harness/bench.py 인자 정의도 확인했다.
3. 선정 당시 main 고정 커밋의 하네스 README — 1.3.0 버전 표기. 변경 가능한 최신 상태와 구분한다.
4. 공개 예제 고정 리비전 데이터 카드 — 공개 범위와 CC-BY-NC 4.0. 전체 데이터의 신청형 접근은 선정 시 보존한 공식 데이터 API 응답과 함께 확인했다.

원문 수치와 모의 환경의 설명은 저자 보고이고, 검수 판정표와 실무 적용 방향은 이 글의 편집적 해석이다. 성과 분석 자료는 도입부와 설명 순서에만 참고했으며 사실 근거나 성공률 추정에는 사용하지 않았다.