ICML 2026 Paper Review · Korean Technical Web Report

Measuring Agents
in Production

생산 환경 AI 에이전트는 연구실의 완전 자율 에이전트가 아니라, 제한된 워크플로우·인간 검증·시스템 레벨 가드레일 위에서 운영되는 신뢰성 중심 소프트웨어 시스템이다.

논문의 중심 명제

MAP는 실제 배포팀의 1차 데이터를 통해 “생산 에이전트가 어떻게 만들어지고 평가되며, 어디에서 실패하는가”를 정리한 첫 대규모 실증 연구로 구성된다.

01

생산성 중심 채택

배포 목적의 최상위 동인은 생산성 향상과 인간 작업시간 절감이다. 위험 완화나 전문지식 대체처럼 장기 검증이 필요한 효과는 현재 배포에서 상대적으로 드물다.

02

단순성과 통제성 우선

연구에서 주목받는 RL·자율 계획보다 오프더셸프 프런티어 모델, 수동 프롬프트, 정적 워크플로우가 더 흔하다. 이유는 낮은 정교함이 아니라 운영 안정성이다.

03

인간 검증은 임시 장치가 아니다

Human-in-the-loop는 부족한 자동평가를 보완하는 차원을 넘어, 생산 에이전트 아키텍처의 핵심 설계 원칙으로 자리 잡는다.

“배포 가능한 에이전트”의 핵심은 모델의 최대 자율성이 아니라, 실패가 증폭되기 전에 시스템·사람·정책이 개입할 수 있는 경계 설계다.MAP의 13개 finding을 관통하는 운영 원리

연구 방법론

논문은 인터뷰와 설문을 결합해 정성·정량 증거를 동시에 확보한다.

데이터 수집 #1: 심층 사례 연구

ML·소프트웨어 엔지니어 팀을 대상으로 30-90분 반구조화 인터뷰를 수행했다. 사례는 14개 생산 배포와 6개 파일럿으로 구성되며, 스타트업부터 대기업까지 조직 성숙도와 지리적 범위를 넓혔다.

snowball samplinggrounded theory coding3+ human coders

데이터 수집 #2: 공개 온라인 설문

47문항 설문을 Qualtrics 동적 분기 방식으로 설계했다. 306개 유효 응답 중 생산 또는 파일럿 단계의 86개 시스템을 메인 분석 대상으로 필터링했다. 범주형 비교에는 1,000회 bootstrap 기반 95% 신뢰구간을 사용했다.

306 responses86 deployed agents26 domains

RQ별 핵심 결과

논문은 응용, 모델·아키텍처, 평가, 배포 난제를 네 축으로 분해한다.

F1

생산성 향상이 주 동기

자동화를 통한 생산성 향상과 인간 작업시간 절감이 채택을 주도한다.

F2

도메인은 넓어지는 중

금융, 기술, 기업 서비스가 선도하지만 총 26개 도메인으로 확산된다.

F3

인간 사용자가 중심

배포 시스템의 93%는 사람을 주 사용자로 두며 직접 감독을 가능하게 한다.

F4

분 단위 지연 허용

비동기 업무 자동화에서는 분 단위 응답도 인간 기준보다 충분히 빠르다.

F5

프런티어 폐쇄형 모델 우세

20개 사례 중 17개가 폐쇄형 모델을 사용하며, 오픈소스는 비용·규제 제약에서 선택된다.

F6

멀티모델은 기능+운영 문제

비용·모달리티뿐 아니라 모델 업그레이드 취약성 때문에 여러 모델을 병행한다.

F7

후학습은 드물다

대부분은 SFT/RL보다 프롬프트 엔지니어링과 오프더셸프 모델을 선택한다.

F8

프롬프트는 사람이 만든다

79%가 수동 또는 수동+LLM 방식이고, 자동 최적화는 9% 수준이다.

F9

자율성은 의도적으로 제한된다

68%는 인간 개입 전 10단계 미만만 실행한다.

F10

커스텀 구현 선호

사례 연구의 85%는 프레임워크보다 직접 API 기반 내부 구현을 택한다.

F11

표준 벤치마크 부족

75%는 공식 벤치마크 없이 A/B 테스트, 사용자 피드백, 운영 모니터링에 의존한다.

F12

평가는 인간 판단 중심

인간 검증 74%, LLM-as-a-judge 52%로 자동평가는 보완재에 가깝다.

F13

신뢰성이 최대 병목

핵심 기술 성능, 특히 신뢰성·강건성·확장성이 배포의 최상위 난제다.

정량 결과 대시보드

논문 주요 그림의 수치를 HTML/CSS 기반 시각요약으로 재구성했다.

에이전트를 만드는 이유 N=66

생산성 향상
80.3%
인간 작업시간 절감
72.7%
고객 만족도 향상
37.9%
새로운 작업 가능
33.3%
전문지식 의존 감소
18.2%
빠른 실패 대응
18.2%
위험 완화
12.1%

응용 도메인 N=69

Technology
47.8%
Finance & Banking
43.5%
Corporate Services
42.0%
Legal & Compliance
17.4%
Research & Development
11.6%
Healthcare Services
10.1%
Other
14.5%

지연시간 허용도 N=53

Subsecond
7.5%
Seconds
26.4%
Minutes
41.5%
Hours
5.7%
> 1 day
1.9%
No limit
17.0%

평가 방법 N=31

Human-in-the-loop
74.2%
LLM-as-a-judge
51.6%
RAG/KG Cross-reference
41.9%
Rule-based check
38.7%
None
3.2%

생산 에이전트 아키텍처

논문은 연구 프로토타입의 고자율 에이전트와 생산 배포의 제한된 에이전트가 구조적으로 다르다고 분석한다.

Task abstraction ↔ Agent control

User Input
TaskSubtask ASubtask BSubtask N
Output
Agent Loop
ReAct-style
Workflow
graph / chain
Orchestration
multi-agent

논문 부록 E의 terminology: task, subtask, step은 실행 아키텍처와 독립적으로 정의된다.

운영에서 선택되는 구조

설계 선택관찰 결과해석
정적 워크플로우20개 사례 중 16개가 구조화된 워크플로우 사용고수준 목표와 도구 순서를 제한해 예측 가능성 확보
짧은 자율 실행68%가 인간 개입 전 10단계 미만 실행복잡도·비결정성·지연·실패 증폭을 제한
커스텀 구현사례의 85%가 외부 프레임워크보다 직접 구현 선호보안·유연성·내부 인프라 통합·의존성 최소화 때문
멀티모델 운영59%가 여러 모델을 조합비용 라우팅, 모달리티, 모델 업데이트 리스크 관리

모델·프롬프트·프레임워크

생산 배포팀은 최신 연구에서 선호되는 복잡한 학습보다 빠른 반복과 유지보수 안정성을 중시한다.

모델 선택

폐쇄형 프런티어 모델 사용이 17/20 사례로 우세하다. 오픈소스는 고빈도 추론비용 또는 민감데이터 규제 때문에 선택된다.

후학습

14/20 사례는 SFT/RL을 사용하지 않는다. 후학습은 구현 부담, 모델 버전 변경 시 재학습 비용, 표본 효율 문제로 인해 제한적으로 쓰인다.

프롬프트

Manual+AI 44.6%, Fully manual 33.9%로 사람이 중심이다. 자동 프롬프트 최적화는 아직 생산 단계에서 희소하다.

프롬프트 구성 방식 N=53

Manual + AI
44.6%
Fully manual
33.9%
Prompt optimizer
8.9%
Predefined template
3.6%
Fully autonomous
3.6%

배포 난제 상위 순위 N=29

Core technical focus
37.9%
Data & model integrity
20.7%
System integration & validation
20.7%
Compliance & user trust
17.2%
Transparency & governance
3.4%

평가 체계: 자동화보다 인간 검증

생산 환경에서 평가의 핵심 문제는 “정답을 자동으로 알 수 없는 실제 업무”가 많다는 점이다.

01 · Baseline gap
  • 39%만 비에이전트 기준선과 비교한다.
  • 26%는 의미 있는 기준선이 없다고 응답한다.
  • 실제 기준선은 인간 절차, 레거시 소프트웨어, 문서 시스템의 혼합인 경우가 많다.
02 · Benchmark scarcity
  • 사례 연구의 75%는 공식 benchmark set 없이 평가한다.
  • 규제 도메인에서는 공개 데이터 부족과 전문가 라벨링 비용이 병목이다.
  • 클라이언트별 도구·업무가 달라 재사용 가능한 벤치마크 구축이 어렵다.
03 · Human review hub
  • 인간 검증은 개발 단계와 운영 단계 모두에서 사용된다.
  • LLM-as-a-judge는 confidence scoring, 저신뢰 사례 라우팅, 샘플링 검증의 보조 도구로 사용된다.
  • 문맥적 적절성, 정책 준수, 도메인 전문성 판단은 규칙 기반 검사만으로 어렵다.

신뢰성 병목과 시스템 레벨 대응

논문이 관찰한 핵심 역설은 “신뢰성이 가장 큰 병목인데도 에이전트가 이미 배포되고 있다”는 점이다. 해법은 모델 자체보다 제약된 운영 환경에 있다.

Read-only modeSRE 에이전트처럼 버그 리포트와 계획만 생성하고, 운영 시스템 변경은 인간 엔지니어가 실행한다.
Sandbox verification코드 변경·마이그레이션은 미러링된 샌드박스에서 먼저 테스트하고, 검증 후 병합한다.
Wrapper API생산 도구의 내부 세부사항을 숨기는 추상화 계층을 두어 에이전트의 행동면을 제한한다.
RBAC mirroring에이전트 권한을 사용자 권한과 정렬한다. 다만 도구·문서 권한 충돌은 여전히 어려운 문제다.
Human gate외부 고객·고위험 도메인에서는 중요 액션 전 전문가 승인과 고정 행동 순서를 둔다.

데이터 처리 방식 N=27-29

Database
89.7%
Confidential data
69.0%
Live user data
65.5%
Live non-user data
51.7%
Public online data
34.5%

지연시간 문제성 N=27

배포 차단 수준
14.8%
문제는 있지만 배포 가능
59.3%
문제 없음
25.9%

실시간 음성 에이전트는 예외적으로 latency가 핵심 병목으로 보고된다.

멀티모달 확장 방향

현재 배포는 텍스트 중심이지만, 향후 성장은 이미지·비디오·시공간·과학 데이터 등 비텍스트 모달리티에 집중된다.

현재 지원 vs 향후 지원 계획 N=29

모달리티현재 지원향후 지원 계획해석
Natural language text93.1%39.1%이미 성숙한 기본 입력 형태
Machine generated text / logs82.8%60.9%운영·DevOps·분석 도메인과 강하게 연결
Tabular data65.5%43.5%업무 자동화의 핵심 데이터 구조
Code41.4%34.8%검증 신호가 비교적 강한 도메인
Images37.9%47.8%향후 증가 여지 큼
Geospatial temporal20.7%52.2%시공간 추론과 관측 데이터 처리 수요 증가
Scientific data13.8%26.1%AI4Science/규제 분석에서 확대 예상
Videos6.9%30.4%정확성 신호·인프라 비용이 큰 개척 영역

부록까지 반영한 문서 구조

본문뿐 아니라 부록의 보충 분석, 수집 데이터, 전체 설문 결과, 용어 정의, 관련 연구 범주화, 설문 문항까지 웹페이지 구조에 반영했다.

A-B. 보충 결과와 심화 분석
사용자 유형, 도메인 정규화, latency 요구사항, 프레임워크 사용, 프롬프트 길이, baseline 비교, 평가 전략 co-occurrence, 보안·프라이버시·latency·모달리티 난제를 확장 분석한다. “Other” 도메인은 chemical, telco, supply chain, construction, automotive, travel, entertainment 등 긴 꼬리 응용을 포함한다.
C. 수집 데이터와 사례 연구 세부사항
설문 응답자의 50.9%는 소프트웨어·ML 엔지니어이고, 31.5%는 기술 임원·관리자다. 시스템 단계는 production 45.0%, pilot 32.4%, prototype 19.8% 등으로 분포한다. 인터뷰 사례는 business operations, communication tech, scientific discovery, software DevOps, software & business operations로 묶인다.
D. 전체 설문 데이터 결과
생산·파일럿만이 아니라 prototype/research까지 포함해도 주요 경향은 유지된다. 다만 비배포 시스템은 autonomous steps와 모델 수가 더 많고, 자동 프롬프트·자동평가 실험 비중이 약간 높다. 배포 단계로 갈수록 bounded autonomy와 human verification이 강해진다.
E. 용어 체계
Task는 사용자의 고수준 목표, subtask는 분해된 하위 목표, step은 에이전트의 개별 실행 단위다. task abstraction은 agent loop, workflow, orchestration 같은 구체 실행 구조와 독립적으로 정의된다.
F. 관련 연구 범주화
관련 연구는 Commercial/Industry, Research Surveys, Application/Demonstration으로 나뉜다. 기존 문헌은 고수준 산업 동향, 개념적 서베이, 단일 시스템 데모에 강하지만, MAP처럼 조직 간 생산 배포의 기술 방법론을 직접 수집한 실증 자료는 부족하다고 정리된다.
G. 설문지와 17개 설계 차원
설문은 프롬프트 길이·구성법, 모델 선택, 모델 수, inference-time 기법, 에이전트 아키텍처, 의존성, 데이터 소스, 모달리티, 프레임워크, 메트릭, 평가·검증, baseline, latency, 기술 난제, 응용 도메인, 시스템 단계 등 17개 설계 차원을 포괄한다.

연구·개발 시사점

MAP의 실증 결과는 에이전트 연구 방향을 “더 자율적인 단일 에이전트”에서 “검증 가능한 생산 시스템”으로 재정렬한다.

1. Post-training의 생산 적합성

모델 업데이트에 견고한 SFT/RL, 소량 샘플로 유지보수 가능한 adaptation, base model 교체 후 성능 보존 기법이 필요하다.

2. Runtime observability

에이전트 실행 중 실패 감지, confidence routing, tool-call audit, human escalation을 표준화하는 관측 가능성 계층이 필요하다.

3. Human-agent workflow

인간 감독을 제거할 대상이 아니라 설계 대상이라고 보고, 승인 인터페이스·역할 분담·bounded autonomy를 연구해야 한다.

4. Real-world benchmarks

도메인별 golden QA, 로그 기반 test set, 전문가 검증, 합성 데이터 생성을 연결하는 benchmark curation 방법론이 중요하다.

5. Multi-model orchestration

비용·성능·모달리티·모델 버전 리스크를 고려한 라우팅, batching, fallback, migration 전략이 생산 환경 핵심 문제가 된다.

6. Multimodal reliability

이미지·비디오·과학 데이터 에이전트는 약한 정답 신호, 비싼 데이터 파이프라인, 복잡한 failure mode를 해결해야 한다.

핵심 결론. 에이전트 엔지니어링은 모델 호출을 연결하는 기술이 아니라, 신뢰성·검증·권한·도메인 절차·인간 감독을 하나의 실행 시스템으로 통합하는 소프트웨어 공학 문제다.