Skip to content
DigitalNeuron
에이전트·자동화

분석: AI 에이전트가 데모에서 실전으로 넘어갈 때 실제로 바뀐 것

지난 2년의 에이전트 데모는 인상적이었고 대체로 출시 불가였다. 살아남은 배포들은 몇 안 되는 설계 결정을 공유한다 — 그리고 그건 데모가 강조하던 것들이 아니다.

DigitalNeuron Desk2026년 8월 22일 최종 갱신2분 읽기

한 줄 답

AI 에이전트 데모는 되는데 왜 실전 배포는 실패하는가?

데모는 짧은 정상 경로를 사람이 지켜보며 한 번 돈다. 실전은 감독 없이 수천 가지 변형을 돌리고, 거기서는 단계별 오류율이 곱해지며 넓은 권한이 잘못된 판단 하나를 사고로 만든다. 되는 배포는 범위를 좁히고, 각 단계를 싸게 검증하고, 되돌릴 수 없는 행동마다 관문을 둔다.

핵심 요약

  • 성공한 에이전트 배포는 좁다 — 한정된 영역, 몇 개의 도구, 명백한 성공 신호.
  • «검증이 싼가»가 성공을 가장 잘 예측한다 — 그래서 코딩이 먼저였다.
  • 평가는 «느낌»에서 «기록된 궤적을 변경마다 재생»으로 옮겨갔다.
  • MCP 로 도구가 표준화되면서, 통합 작업이 제품마다 짓는 접착제에서 재사용 가능한 서버로 옮겨갔다.

에이전트 프로젝트에는 익숙한 곡선이 있다. 첫 주에 프로토타입이 놀라운 것을 해낸다. 6주쯤 되면 아무도 예상하지 못한 입력에서 그럴듯한 헛소리를 내놓고, 팀은 모델을 하나 더 붙일지 접을지를 놓고 다툰다.

반대편으로 빠져나온 프로젝트들은 더 좋은 모델을 찾은 게 아니다. 문제의 모양을 바꿨다.

데모를 죽이는 산수

각 단계를 95% 정확히 해내는 작업을 생각해 보자. 판단이 들어가는 열린 단계로는 좋은 수치다.

3단계를 이으면 약 86% 의 실행이 성공한다. 20단계면 3분의 1 정도. 50단계면 8% 다.

데모는 5단계짜리를 한 번 보여줬고, 잘못된 두 번은 사람이 조용히 다시 돌렸다. 실전은 20단계짜리를 아무도 안 보는 채로 1만 번 돌린다.

이후의 모든 것은 이 산수에 대한 대응이다.

살아남은 배포들의 공통점

좁은 영역. "운영을 처리하라"가 아니라 "이 두 청구 시스템을 대사하라". 분기가 적고, 도구가 적고, 틀릴 방법이 적다. 실전을 견딘 에이전트는 거의 예외 없이 그것을 정당화했던 데모보다 덜 야심적이다.

싼 검증. 단일 예측 변수로 가장 강력하다. 코딩 에이전트가 먼저 된 이유는 테스트가 객관적·자동 신호를 주기 때문이다 — 사람 없이 시도하고 확인하고 다시 할 수 있다. 검증이 비싼 곳(법률 의견, 가격 결정)에서는 사람이 결과를 검토해야 하고, 그러면 레버리지에 상한이 생기며 사업 논거가 달라진다.

모델 «바깥»의 권한 경계. 읽기는 넓게, 쓰기는 좁게. 돈·고객 연락·삭제·배포에는 승인 관문. 이것은 프롬프트 속 지시가 아니라 런타임에서 강제된다. 신뢰할 수 없는 콘텐츠를 읽는 에이전트는 지시가 오염될 수 있는 에이전트다.

예산. 최대 단계 수, 최대 실행 시간, 최대 토큰. 잘못된 도구 응답에 갇혀 도는 에이전트는 끝이 없는 과금 사고다.

재생 가능한 로그. 모든 호출과 결과를 저장한다. 문제가 났을 때 «실제로 무엇을 했는가»가 즉시 답해져야 한다 — 고치기 위해서도, 점점 늘어나는 감사 요구를 위해서도.

평가가 어른이 됐다

가장 눈에 덜 띄면서 가장 중요한 변화다. 초기 에이전트 작업은 «지켜보며» 평가했다. 그건 확장되지 않고 회귀를 잡지 못한다.

지금의 실무는 궤적(trajectory) 을 기록하는 것이다 — 실제 실행의 단계·도구 호출·결과 전체를 저장하고, 프롬프트·모델·도구 구성이 바뀔 때마다 재생한다. 각 궤적에는 «올바른 실행은 이런 모양»이라는 단언이 붙는다. 새 모델 버전은 공개 벤치마크 점수가 좋아서가 아니라, 기록된 궤적 집합을 깨뜨리지 않아서 채택된다.

두 번째 변화는 단계별 채점이다. 종단 통과율은 «뭔가 잘못됐다»를 알려준다. 단계별 점수는 «검색 도구가 월요일마다 오래된 결과를 준다»를 알려준다.

도구가 인프라가 됐다

한동안은 에이전트 제품마다 자체 커넥터를 짰다. Model Context Protocol 이 도구 노출을 표준 인터페이스로 바꿨다. 서버가 제공 목록을 광고하면 호환되는 어떤 클라이언트든 쓸 수 있다. 그 결과 통합 작업이 애플리케이션마다 짓는 접착제에서, 한 번 만들어 유지하는 재사용 서버로 옮겨갔다.

실무적 효과는 밋밋하고 크다. 흥미로운 질문이 «내 에이전트를 이 시스템에 어떻게 연결하나»에서 «내 에이전트가 이 시스템에서 무엇을 하도록 허용해야 하나»로 옮겨갔다. 그건 거버넌스 질문이고, 옳은 질문이다.

되지 않은 것

덜 알려졌으니 분명히 적어둘 값어치가 있다.

  • 장기 자율 운용. 열린 목표를 두고 몇 시간 방치하면 여전히 표류하고, 잘못 든 길의 비용이 조용히 누적된다.
  • 검증이 비싼 작업. 사람이 전체를 읽어야 옳은지 알 수 있다면, 에이전트는 «일»이 아니라 «타이핑»을 아낀 것이다.
  • 변동이 큰 환경. 레이아웃이 바뀌는 웹사이트, 일관성 없는 오류를 뱉는 시스템, 문서화되지 않은 예외가 있는 프로세스.
  • 목적 없는 에이전트 떼. 멀티 에이전트는 하위 작업이 정말 다른 도구와 맥락을 요구할 때 도움이 된다. 단일 에이전트로 되는 일에 적용하면 조율 실패만 늘어난다.

정직한 요약

에이전트는 목표가 분명하고, 영역이 좁고, 결과 확인이 싸고, 폭발 반경이 모델의 선의가 아닌 무언가로 제한될 때 오늘 작동한다. 이는 실재하며 커지는 범주다 — 그리고 제품 발표문의 «에이전틱»이 암시하는 것보다 작은 범주다.

성공적으로 출시한 팀들은, 거의 예외 없이, 그 사실을 먼저 받아들인 쪽이었다.

자주 묻는 질문

실전에서 실제로 돌아가는 에이전트 용례는?
테스트가 있는 소프트웨어 작업, 고객지원 분류와 초안 작성, 자료 조사와 수집, 시스템 간 데이터 대사. 넷 다 결과 검증이 싸다는 공통점이 있다.
실전 에이전트는 얼마나 자율적인가?
마케팅이 시사하는 것보다 훨씬 덜하다. 흔한 형태는 넓은 읽기 권한에, 돈을 쓰거나 고객에게 연락하거나 데이터를 지우는 일에는 승인 관문을 두는 것이다.
가장 큰 기술적 위험은?
에이전트가 읽는 콘텐츠를 통한 프롬프트 인젝션이다. 메일·웹페이지·PR 코멘트를 처리하는 에이전트는 공격자가 통제할 수 있는 텍스트를 처리하는 것이며, 어떤 프롬프트도 이를 확실히 막지 못한다. 완화책은 «에이전트가 할 수 있는 일»을 제한하는 것이다.
멀티 에이전트가 단일 에이전트보다 나은가?
하위 작업이 정말로 다른 도구와 맥락을 필요로 할 때만 그렇다. 그렇지 않으면 조율 오버헤드와 추가 실패 모드가 결과를 오히려 나쁘게 만든다.

출처

  1. Building effective agentsAnthropic
  2. Model Context ProtocolMCP
  3. SWE-bench: Can Language Models Resolve Real-World GitHub Issues?arXiv
태그agentsproductionreliabilityevaluationMCP

함께 읽기

AI 에이전트란 무엇인가 — 챗봇과 무엇이 다른가

AI 에이전트는 호출할 수 있는 도구와 추구할 목표를 받고, 단계마다 사람에게 묻지 않고 여러 걸음을 진행할 권한을 얻은 언어모델이다. 챗봇은 질문에 답하고 멈추지만, 에이전트는 목표가 달성됐다고 판단하거나 예산이 소진될 때까지 계속 행동한다.

갱신 5분 읽기

분석: AI 가격은 계속 떨어지는데 왜 청구서는 오르는가

토큰당 가격은 더 나은 하드웨어, 증류된 소형 모델, 서빙 최적화로 크게 떨어졌다. 그런데 소비가 더 빨리 늘었다 — 길어진 컨텍스트, 답 하나에 훨씬 많은 토큰을 만드는 추론형 모델, 사용자 동작 하나를 수십 번의 모델 호출로 바꾸는 에이전트. 단가 하락과 사용량 증가가 겹치면 청구서는 커진다.

갱신 3분 읽기