Field note · 2026-04-25
에이전트는 실패하지 않는다. 다만, 틀린 방향으로 성공한다.
어느 날 아침, 운영팀 주간 보고서에는 이런 내용이 적혀 있었다. AI 에이전트 처리 성공률 98%. 평균 응답 시간 3.2초. 전주 대비 개선. 담당자는 그 수치를 슬라이드에 옮겼고, 임원 보고에서 별다른 질문은 없었다. 모두가 잘 돌아가고 있다고 생각했다. 그런데 며칠 뒤, 고객사에서 연락이 왔다. 에이전트에게 맡겼던
에이전트는 실패하지 않는다. 다만, 틀린 방향으로 성공한다.
0. 보고는 정상이었다
어느 날 아침, 운영팀 주간 보고서에는 이런 내용이 적혀 있었다.
AI 에이전트 처리 성공률 98%. 평균 응답 시간 3.2초. 전주 대비 개선.
담당자는 그 수치를 슬라이드에 옮겼고, 임원 보고에서 별다른 질문은 없었다. 모두가 잘 돌아가고 있다고 생각했다.
그런데 며칠 뒤, 고객사에서 연락이 왔다. 에이전트에게 맡겼던 파일 정리 작업에서 필요한 파일 일부가 삭제되었다는 것이다. 에이전트는 "중복으로 판단된 파일"을 스스로 지웠다. 자신의 기준으로는 완벽하게 임무를 수행한 셈이었다. 시스템 로그 어디에도 오류는 없었다. 보고서는 여전히 98%를 가리키고 있었다.
이것은 에이전트가 실패한 게 아니었다. 에이전트는 성공했는데, 우리가 원한 방향이 아니었다.
이런 상황이 무서운 이유는 한 가지다. 우리는 그 순간 그것이 일어나고 있다는 사실을 몰랐다.
1. 질문이 달라져야 할 시스템이 왔다
지금껏 IT 운영은 크게 두 종류의 시스템을 다뤄왔다.
첫 번째는 규칙 기반 시스템(Programmatic System) 이다. 코드가 시키는 대로 움직이고, 같은 입력에는 항상 같은 결과가 나온다. 무언가 잘못되면 에러 코드가 뜨고, 로그에 흔적이 남고, 원인을 찾아 고치면 된다. 이 시스템을 운영할 때 우리가 묻는 질문은 단순하다. "지금 시스템이 살아있는가?"
두 번째는 AI·머신러닝 시스템이다. 코드는 멀쩡한데 예측 결과가 조용히 나빠지는 시스템이다. 에러 코드가 없기 때문에 알아채기 어렵다. 이 시스템을 운영하려면 질문이 달라져야 했다. "모델이 여전히 정확한가?"
그리고 이제 세 번째 시스템이 왔다. Agentic AI다.
이 시스템은 LLM이 매 순간 스스로 다음 행동을 결정한다. 단일 요청 하나가 수십 개의 중간 판단으로 이어지고, 외부 시스템을 직접 건드리며, 같은 요청이더라도 실행할 때마다 전혀 다른 경로를 탄다. 이 시스템에서 물어야 할 질문은 또 달라진다.
"에이전트가 지금 올바른 방향으로 추론하고 있는가?"
질문이 달라진다는 건 단순히 모니터링 도구를 바꾼다는 게 아니다. 운영 전체의 언어와 기준이 바뀐다는 뜻이다. 그런데 많은 조직이 아직 첫 번째 질문의 언어로 세 번째 시스템을 바라보고 있다.
2. 에이전트가 조용히 실패하는 방식
전통적인 시스템이 문제를 일으킬 때는 신호가 온다.
서버가 죽으면 알림이 울린다. 배치 작업이 실패하면 다음 날 아침 로그에 흔적이 남는다. HTTP 에러는 대시보드에 빨간 불로 뜬다. 담당자가 달려가서 원인을 파악하고, 수정하고, 원래대로 돌려놓으면 된다.
AI 에이전트의 실패는 다른 방식으로 온다. 아니, 표면적으로는 오지 않는 것처럼 보인다.
에이전트는 실패했을 때 에러를 던지는 대신 완료 신호를 보낸다. 성공률은 정상이고, 처리 시간도 정상이다. 보고서는 깨끗하다. 하지만 실제로 일어난 일은 우리가 원한 것과 달랐다.
연구자들은 이를 "잘못된 성공(Wrong Success)"이라 부른다. 에이전트가 자신의 목표는 달성했지만, 사용자의 원래 의도와는 어긋난 결과를 만들어내는 현상이다. "파일을 최신 버전으로 업데이트해 달라"고 했더니 원본을 지우고 새로 썼다거나, "중복 항목을 정리해 달라"고 했더니 필요한 레코드까지 날려버리는 식이다. 에이전트 입장에서는 완수된 작업이다. 하지만 우리가 원한 것이 아니다.
여기서 진짜 문제가 드러난다. 이 실패는 보고서에 나타나지 않는다. 우리가 보는 수치가 정상이기 때문에, 뭔가 잘못됐다는 사실을 인지하는 시점이 항상 늦다.
3. 기존 방식으로 잡히지 않는 이유
왜 기존 모니터링으로는 이런 실패를 감지하기 어려울까.
전통적인 모니터링은 결과를 확인한다. 응답이 왔는가, 에러가 있는가, 처리 속도는 어떤가. 이 방식은 결과가 명확히 잘못됐을 때만 작동한다.
Agentic AI에서는 결과가 표면적으로 정상일 수 있다. 잘못은 결과가 아니라 과정 중에 숨어 있다. 에이전트는 하나의 요청을 처리하면서 수십 개의 중간 판단을 내리는데, 초반의 작은 판단 착오가 이후 단계 전체에 누적된다. 각 단계의 성공률이 99%라 해도, 100단계짜리 처리 흐름에서는 전체 성공률이 63%까지 떨어질 수 있다는 계산이 나온다.
재현도 어렵다. 전통 시스템에서는 같은 입력으로 같은 실패를 언제든 재현할 수 있다. 에이전트는 매번 다른 경로를 타기 때문에, 어제 발생한 문제를 오늘 다시 만들어내는 것 자체가 불가능할 수 있다.
롤백은 더 까다롭다. 에이전트가 이메일을 발송하고, 데이터베이스를 수정하고, 외부 API를 호출한 뒤에 문제를 발견했다면, 이미 일어난 일은 되돌리기 어렵다. 코드를 이전 버전으로 되돌리는 것과는 차원이 다른 문제다.
요약하면 이렇다. Agentic AI의 실패는 늦게 발견되고, 재현하기 어려우며, 되돌리기도 쉽지 않다. 이 세 가지가 겹치면, 조직 입장에서는 대응할 여지 자체가 좁아진다.
4. 경영진이 먼저 짚어야 할 세 가지
Agentic AI를 도입한다는 것은 기술 스택 하나를 추가하는 일이 아니다. 운영의 기준을 다시 세우는 일이다. 그 기준은 기술팀만의 몫이 아니고, 경영진이 먼저 방향을 정해야 아래로 내려갈 수 있다.
첫째, '성공'의 정의를 함께 써야 한다.
지금 우리 조직에서 에이전트의 "성공"은 어떻게 정의되어 있는가. 완료 신호가 오면 성공인가, 처리율이 높으면 성공인가. 그 정의가 실제로 우리가 원하는 결과와 일치하는가.
에이전트를 도입하기 전에, 혹은 이미 운영 중이라면 지금이라도, 이 질문에 먼저 답해야 한다. 그 답이 명확하지 않으면 보고서에 찍히는 숫자는 우리가 원하는 것을 측정하지 않을 수 있다.
둘째, 되돌릴 수 없는 행동에는 사람이 끼어 있어야 한다.
이메일 발송, 데이터 삭제, 외부 연동 시스템 변경, 권한 조정. 이런 행동들은 에이전트가 아무리 확신하더라도 인간의 확인을 거치는 절차가 필요하다. 에이전트를 불신해서가 아니라, 한 번 실행되면 되돌리기 어려운 행동의 결과는 결국 조직이 감당하기 때문이다.
EU AI Act는 고위험 AI 시스템에 대해 "human-on-the-loop"를 법적으로 요구하고 있다. 인간이 언제든 개입하고 멈출 수 있는 구조. 이것은 규제 대응의 문제이기도 하지만, 그 전에 운영 상식의 문제다.
셋째, 보이지 않는 것을 신뢰하기는 어렵다.
2026년 현재, 경영진의 45%가 에이전틱 AI 통합에서 가장 큰 장애물로 "가시성 부족"을 꼽는다. (IBM IBV 2025) 에이전트가 무엇을 했고, 왜 그 판단을 내렸는지를 사후에 추적할 수 있어야 한다. 그 추적이 가능해야 비로소 신뢰가 생긴다.
5. 실제로 들여다봐야 할 것들
지연시간, 에러율, 처리량. 이 숫자들은 에이전트 운영에도 여전히 필요하다. 하지만 이것만으로는 부족하다.
Agentic AI 운영에서 추가로 가시화해야 할 것들이 있다.
에이전트가 처리 과정에서 사용자의 원래 의도를 유지했는가(Intent Preservation). 적절한 도구와 행동을 선택했는가(Tool Selection Accuracy). 추론의 흐름이 논리적으로 이어졌는가(Reasoning Quality). 에이전트가 멈춰야 할 지점에서 실제로 사람에게 넘겼는가(HITL Trigger Rate).
이 지표들은 대시보드에서 자동으로 생성되는 숫자가 아니다. "이 에이전트에게 우리가 기대하는 것이 무엇인가"를 조직이 먼저 정의해야 비로소 측정할 수 있는 것들이다. 측정 이전에 기준을 세우는 일이 선행된다.
6. 아직 업계도 답을 내놓지 못한 영역들
한 가지는 솔직하게 말해두고 싶다.
이 분야는 아직 정해진 답이 없다.
에이전트가 실제로 믿을 만한지 일관되게 평가하는 표준이 없다. 여러 에이전트가 협력할 때 전체 상태를 한눈에 파악하는 기술도 완성되지 않았다. 에이전트가 잘못된 판단을 내렸을 때 책임이 어디에 귀속되는지에 대한 법적·제도적 틀도 형성 중이다.
이것을 "아직 이르다"는 신호로 읽을 필요는 없다. 오히려 지금 도입하는 조직일수록 거버넌스를 처음부터 함께 설계해야 한다는 의미로 받아들이는 게 맞다. 기술이 먼저 들어오고 기준이 나중에 따라오는 방식이 아니라, 기준과 기술이 같이 움직여야 한다.
7. 마지막으로, 한 가지 질문
에이전트를 이미 운영하고 있거나 도입을 검토 중이라면, 기술팀에 이 질문을 한번 던져보길 권한다.
"에이전트가 지금 이 순간 잘못된 방향으로 성공하고 있다면, 우리는 그것을 알 수 있는가?"
이 질문에 자신 있게 "알 수 있다"고 답할 수 있다면, 그 조직은 Agentic AI를 운영하고 있는 것이다.
답이 막힌다면, 우선 어디서부터 가시성을 확보해야 하는지 짚어보는 것이 먼저다. 에이전트의 가능성은 분명하다. 다만 그 가능성을 안전하게 쓰려면, 우리가 무엇을 보고 있는지를 먼저 알아야 한다.
참고 자료
- IBM Institute for Business Value (2025) — 경영진의 45%가 에이전틱 AI 가시성 부족을 주요 장애물로 꼽음
- Partnership on AI (2025) — Prioritizing Real-Time Failure Detection in AI Agents
- MintMCP — AI Agent Monitoring vs Observability: What Enterprise Teams Get Wrong
- aiceberg.ai — Why Intent-Action Alignment is Key for Agentic AI Security
- IAPP — AI Governance in the Agentic Era
- EU AI Act Article 14 — 고위험 AI의 Human-on-the-Loop 의무
2026-04-25 | 근거: evidence/agentic-ai-monitoring/ | v2 리라이팅: 한국어 자연화 + 한국식 비즈니스 정서 반영