실제로 결과물을 만들어내는 에이전트: 왜 지루함이 자율성보다 나은가

2026년 6월, 에이전트 하이프 사이클(hype cycle)은 더 명확한 답을 내놓았습니다. 프로덕션 에이전트(production agents)로 승리하고 있는 팀들은 자율적인 군집(autonomous swarms)을 구축하고 있지 않습니다. 그들은 지루한 시스템을 구축하고 있습니다.

지난 한 달 동안 프로덕션 환경에서 실제로 무엇이 작동하는지 지켜보았고, 그 패턴은 명확합니다. 수익을 창출하거나 엔지니어링 시간을 절약하는 에이전트는 끝없는 루프 사이클(loop cycles)과 거창한 자율성을 가진 에이전트가 아닙니다. 그들은 기본적으로 관찰 가능하며(observable by default), 설계 단계부터 경계가 정해져 있고(bounded by design), 인간의 판단이 필요한 시점을 명확히 하는(explicit about when they need human judgment) 에이전트들입니다.

이것이 중요한 이유는 에이전트 플랫폼과 인프라를 평가하는 방식을 바꾸기 때문입니다.

프로덕션 에이전트의 실제 모습

구체적으로 말씀드리겠습니다. 현재 프로덕션 환경에서 에이전트를 사용하는 팀들은 압도적으로 다음 사항들에 의존하고 있습니다:

• 수동 프롬프트 구성 (Manual prompt construction) (학습되거나 미세 조정(fine-tuned)된 것이 아님)
• 기성 모델 (Off-the-shelf models) (커스텀 가중치(custom weights)가 아님)
• 제한된 실행 (Bounded execution) (인간의 개입이 필요하기 전까지 10단계 이하로 제한)

이것은 한계가 아닙니다. 그것은 엔지니어링 규율(engineering discipline)입니다.

데모(demo)의 서사와 비교해 보십시오. 다단계 추론 루프(multi-step reasoning loops), 자기 수정 에이전트(self-correcting agents), 작업 완료 시까지의 완전한 자율성. 데모는 작동합니다. 하지만 실제로 결과물을 내놓는(shipping) 에이전트는 그렇게 생기지 않았습니다.

그렇다면 대신 어떤 모습일까요?

명시적인 게이트(explicit gates)를 가진 에이전트. 고객 서비스 에이전트는 3~5단계를 처리한 후 에스컬레이션(escalate)합니다. 코딩 에이전트는 테스트를 실행하고 PR(Pull Request)을 생성하지만, 리뷰 없이 머지(merge)하지는 않습니다. 데이터 에이전트는 쿼리(query)를 생성하고 실행 전 인간에게 승인을 요청합니다. 이것은 실패가 아니라, 실제로 작동하는 아키텍처적 선택(architectural choices)입니다.

제한된 범위 (Bounded scope). 프로덕션에서 살아남는 에이전트들은 좁고 반복 가능한 문제를 해결합니다: 반품 처리, 지원 티켓 분류(triage), 주간 보고서 생성, 내부 데이터베이스 업데이트, 컴플라이언스(compliance) 이슈 플래그 표시. 좁은 범위는 예측 가능한 실패 모드(failure modes), 더 쉬운 디버깅(debugging), 그리고 실제로 의미 있는 인간 루프 지점(human loop points)을 의미합니다.

시작부터 관찰 가능해야 합니다 (Observable from the start). 에이전트를 확장하는 팀들은 관찰 가능성 (observability)을 사후 고려 사항이 아닌, 프로토타입 개발 첫날부터 최우선 요구 사항 (first-class requirement)으로 성공적으로 취급합니다. 모든 도구 호출 (tool call)은 추적 (trace)됩니다. 모든 결정은 기록됩니다. 모든 실패는 사용자가 보고하기 전에 가시화됩니다. 코딩 에이전트를 구축할 때는 수정된 파일, 실행된 테스트, 변경된 사항, 추론 (reasoning) 과정을 추적합니다. 고객 지원 에이전트를 구축할 때는 시도한 내용, 신뢰 수준 (confidence levels), 에스컬레이션 (escalation) 사유를 로그 (log)로 남깁니다. 데이터 에이전트를 구축할 때는 생성된 쿼리 (queries), 액세스한 데이터, 승인 상태를 기록합니다.

인프라의 문제는 자율성이 아니라, 가시성 + 제어력입니다

솔직히 말씀드리자면, 에이전트를 출시할 때 어려운 점은 에이전트를 더 똑똑하게 만드는 것이 아닙니다. 에이전트를 가시화하고 통제 가능하게 (governable) 만드는 것입니다.

저는 팀들이 이 벽에 반복적으로 부딪히는 것을 보았습니다. 테스트 단계에서는 아주 잘 작동하는 에이전트를 출시한 뒤, 다음과 같은 상황을 겪습니다:

• 무언가 잘못되었을 때 에이전트가 무엇을 했는지 설명할 수 없음
• 어떤 실행 경로 (execution path)가 잘못된 결과로 이어졌는지 추적할 수 없음
• 팀별 비용 한도 (cost boundaries)를 설정할 수 없음
• "이 도구는 사용 전 승인이 필요함"과 같은 규칙을 강제할 수 없음
• 결정을 이해하기 위해 세션을 재현 (replay)할 수 없음

이것들은 모델의 문제가 아닙니다. 인프라의 문제입니다. 그리고 에이전트 플랫폼이 이를 최우선 과제로 다루지 않는다면, 이를 해결하는 데 막대한 비용이 듭니다.

하나의 런타임 (runtime)에서 하나의 에이전트를 실행할 때는 관리할 수 있습니다. 하지만 여러 팀, 여러 런타임 (Claude Managed Agents, Bedrock, Cursor, 커스텀), 여러 모델을 사용하면서 비용 제약과 컴플라이언스 (compliance) 요구 사항을 충족해야 할 때는, 처음부터 이를 위해 구축된 인프라가 필요합니다.

이것이 에이전트 플랫폼 평가에 의미하는 바

프로덕션 에이전트를 위한 플랫폼이나 게이트웨이 (gateway)를 선택하고 있다면, 평가 기준이 바뀌어야 합니다.

"동시 요청을 얼마나 처리할 수 있는가?" 대신 "모든 에이전트의 결정과 추적을 볼 수 있는가?"라고 물으십시오.

"라우팅 (routing) 속도가 얼마나 빠른가?" 대신 "팀별 비용 제한을 설정하고 이를 강제할 수 있는가?"라고 물으십시오.

대신에 "내가 좋아하는 모델을 지원하는가?"라고 묻지 말고, "에이전트가 여러 런타임 (runtimes)에서 실행되더라도 내가 한 곳에서 여전히 관리할 수 있는가?"라고 물으십시오.

"에이전트가 얼마나 자율적일 수 있는가?"라고 묻지 말고, "내가 어떤 명시적인 인간 관문 (human gates)을 추가할 수 있으며, 이를 수정하기가 얼마나 쉬운가?"라고 물으십시오.

지루한 정답은 이것입니다: 승리하는 인프라 (infrastructure)는 **관찰 (observation) + 거버넌스 (governance) + 제한된 자율성 (bounded autonomy)**을 제공하는 인프라입니다. 가공되지 않은 속도도, 최대의 자율성도, 영리한 자기 수정 루프 (self-correction loops)도 아닙니다.

예시: 실제 사례에서는 어떤 모습인가

여러 런타임에서 지원 에이전트 (support agents)를 실행하고 있다고 가정해 봅시다. 어떤 것은 Claude Managed Agents이고, 어떤 것은 Bedrock에서 실행되며, 어떤 것은 커스텀 (custom)입니다.

당신에게 필요한 것은 다음과 같습니다:

• 그들을 호출할 단 한 곳. 세 개의 콘솔을 전환하는 것이 아닙니다. 각 에이전트가 어떤 API 형식을 사용하는지 외우는 것도 아닙니다. 단 하나의 API가 필요합니다.
• 그들이 무엇을 했는지 볼 수 있는 단 한 곳. 세션 (sessions)이 유지됩니다. 무슨 일이 일어났는지 다시 재생 (replay)할 수 있습니다. 도구 호출 (tool calls)을 추적 (trace)할 수 있습니다. 왜 에스컬레이션 (escalated)되었는지 볼 수 있습니다. 왜 실패했는지 이해할 수 있습니다.
• 경계 (boundaries)를 강제할 단 한 곳. 에이전트당 비용 제한. 에이전트당 도구 접근 권한. 속도 제한 (rate limits). 민감한 도구 호출에 대한 인간 관문 (human gates).
• 행동을 수정할 단 한 곳. 세 개의 별도 시스템을 재배포하지 않고도 프롬프트 (prompt)를 변경하고, 도구 권한을 변경하고, 비용 제한을 변경할 수 있어야 합니다.

그러한 인프라는 매력적이지 않습니다. 밀리초 미만의 게이트웨이도 아닙니다. 최첨단 자율성 연구도 아닙니다. 그것은 컨트롤 플레인 (control plane)입니다. 그리고 그것이 금요일 오후에도 신뢰성을 유지하는 에이전트와 새벽 3시에 운영 환경 (production)을 망가뜨리는 에이전트를 가르는 차이점입니다.

진정한 변곡점

운영 팀 (production teams)은 "에이전트를 구축할 수 있는가?"라고 묻는 단계를 지났습니다. 그들은 "어떻게 에이전트를 안정적으로 운영할 것인가?"를 묻고 있습니다. 그리고 "운영 (operate)"한다는 것은 관찰, 거버넌스, 제한, 에스컬레이션, 감사 (audit), 비용 추적 (cost-track)을 의미합니다.

자율성과 가공되지 않은 역량을 중심으로 구축된 플랫폼들은 가시성 (visibility)과 제어 (control)를 중심으로 구축된 플랫폼들에게 패배하고 있습니다.

지루한 인프라가 승리합니다.

Paul Twist는 베를린에 기반을 둔 AI 인프라 엔지니어입니다. 그는 에이전트의 데모 (demonstrations)와 수익을 창출하는 배포 (deployments) 사이의 간극에 대해 글을 씁니다.