AI 에이전트가 실패하는 구조적 이유

앞선 장에서 프롬프트, 컨텍스트, 하네스가 서로 다른 설계 층이라는 점을 살펴봤다. 이제 한 걸음 더 들어가 보자. 실무에서 에이전트가 실패할 때 우리는 흔히 이렇게 말한다. "환각했네." 물론 틀린 말은 아니다. 하지만 실제 운영 환경에서 더 자주 문제를 일으키는 것은, 사실이 틀린 답변 그 자체보다도 잘못된 행동이다. 엉뚱한 도구를 호출하고, 끝나야 할 작업을 끝내지 못하고, 오래된 문서를 근거로 실행하고, 과도한 권한으로 위험한 작업을 수행하고, 검증 없이 결과를 외부에 반영하는 일이 더 비싸고 더 위험하다.

그래서 이 장의 출발점은 단순하다. 에이전트의 실패를 개별 실수로 보지 말고 구조적 현상으로 보자는 것이다. 실패 유형을 구조적으로 이해해야 어떤 안전장치가 필요한지도 정확해진다.

실패는 모델의 성격이 아니라 시스템의 구조에서 나온다

많은 팀이 에이전트 품질 문제를 처음에는 모델 문제로 받아들인다. 같은 질문에 답이 흔들리면 모델이 불안정하다고 느끼고, 결과가 엉뚱하면 프롬프트를 더 길게 써 넣는다. 그러나 운영 현장에서 반복되는 실패를 자세히 보면, 원인은 대개 더 바깥에 있다.

에이전트는 단순히 문장을 생성하는 존재가 아니다. 지시를 해석하고, 컨텍스트를 읽고, 도구를 고르고, 실행 결과를 다시 받아 다음 행동을 결정한다. 즉, 실패도 한 지점에서만 생기지 않는다. 입력이 흐려도 실패하고, 도구 인터페이스가 애매해도 실패하고, 종료 조건이 없으면 실패하고, 권한 경계가 느슨해도 실패한다.

이 말은 중요하다. 에이전트 실패는 한 번의 오답이 아니라, 여러 설계 층이 어긋나며 생기는 연쇄 반응인 경우가 많다. 따라서 "왜 틀렸는가"만 묻는 것으로는 부족하다. "어떤 구조가 이 실패를 가능하게 했는가"를 함께 물어야 한다.

환각보다 위험한 것은 실행 실패다

환각은 모델이 근거 없이 그럴듯한 내용을 만들어내는 현상이다. 분명 중요한 문제다. 하지만 에이전트 시대에는 환각보다 더 실무적인 실패가 있다. 바로 실행 실패다. 말이 아니라 행동이 틀리는 경우다.

예를 들어 일정 관리 에이전트가 회의실 예약 규정을 잘못 설명한 것은 환각에 가깝다. 반면 잘못된 시간대에 실제 회의를 예약해버린 것은 실행 실패다. 두 경우 모두 문제지만, 후자는 즉시 운영 비용과 신뢰 손실로 이어진다. 고객 지원 에이전트가 환불 정책을 부정확하게 요약한 것도 문제지만, 승인 없이 환불을 실행했다면 위험의 크기가 완전히 달라진다.

실행 실패가 무서운 이유는 세 가지다.

• 시스템 바깥의 실제 상태를 바꾼다.

• 나중에 되돌리기 어려운 경우가 많다.

• 한 번의 실수가 사용자 신뢰와 조직 리스크로 바로 연결된다.

그래서 제품 수준의 에이전트를 설계할 때는 "틀린 말을 줄이기"만으로는 충분하지 않다. "틀린 행동이 일어나지 않게 하기"가 더 중요해진다.

도구 호출 오류는 왜 반복해서 발생할까

에이전트가 도구를 잘못 쓰는 장면은 생각보다 다양하다. 틀린 도구를 고르기도 하고, 맞는 도구를 골랐는데 파라미터를 잘못 넣기도 하며, 실행 결과를 오해하기도 한다. 어떤 경우에는 실패한 호출을 성공으로 착각하기도 한다.

이 문제를 단순히 모델의 판단 미스로 보면 해결이 어렵다. 도구 호출 오류는 보통 다음과 같은 구조에서 생긴다.

첫째, 도구의 역할 경계가 흐릴 때다. 비슷한 이름의 함수가 여러 개 있거나, 읽기와 쓰기 기능이 한 인터페이스에 섞여 있으면 에이전트는 선택을 잘못하기 쉽다. 사람도 서랍에 라벨이 없으면 잘못 집는다. 모델도 마찬가지다.

둘째, 도구 설명이 사용자의 언어가 아니라 개발자의 언어로만 쓰여 있을 때다. "updateTaskStatus"라는 함수 이름은 개발자에게는 익숙하지만, 에이전트에게는 언제 써야 하는지 충분히 설명되지 않을 수 있다. 무엇을 바꾸는지, 어떤 조건에서 금지되는지, 실패하면 어떤 응답을 주는지가 분명해야 한다.

셋째, 실행 전후 상태가 명확하지 않을 때다. 에이전트는 현재 무엇이 이미 완료되었는지, 어떤 리소스가 존재하는지, 방금 호출이 실제로 반영되었는지 확실히 알아야 한다. 그런데 많은 시스템은 이 상태 정보를 친절하게 주지 않는다. 그러면 에이전트는 추측으로 빈칸을 메우고, 그 추측이 도구 오용으로 이어진다.

결국 도구 호출 오류는 "모델이 도구를 잘못 골랐다"는 결과가 아니라, 도구 인터페이스와 상태 표현이 모호한 시스템에서 자연스럽게 발생하는 실패다.

무한 루프와 목표 이탈은 왜 생길까

에이전트가 일을 시키면 바쁘게 움직이기는 하는데, 정작 끝내지 못하는 경우가 있다. 비슷한 검색을 반복하고, 같은 파일을 다시 읽고, 실패한 작업을 이유 없이 재시도한다. 겉으로 보면 성실해 보이지만, 실제로는 목적지 없이 계속 걷고 있는 셈이다.

이런 루프는 흔히 모델이 끈질기게 문제를 해결하려다 생긴다고 생각하기 쉽다. 하지만 구조적으로 보면 대개 종료 조건의 부재다. 즉, 언제 멈춰야 하는지, 언제 사람에게 넘겨야 하는지, 언제 현재 전략을 포기해야 하는지가 시스템에 정의되어 있지 않은 것이다.

목표 이탈도 비슷하다. 처음에는 "버그 원인 찾기"를 하던 에이전트가, 어느 순간 관련 없는 코드 정리나 문서 수정까지 손대는 일이 생긴다. 이유는 목표가 작업 단위로 충분히 쪼개져 있지 않기 때문이다. 에이전트는 큰 목표를 받으면 그 안에서 스스로 하위 목표를 만든다. 이때 성공 기준이 모호하면, 행동은 많아지지만 진전은 줄어든다.

특히 다음 조건이 겹치면 루프가 쉽게 생긴다.

• 실패했을 때 멈추는 규칙이 없다.

• 같은 시도를 몇 번까지 반복할지 제한이 없다.

• 완료 여부를 판정하는 기준이 없다.

• 중간 산출물을 점검하는 체크포인트가 없다.

즉, 루프는 의지의 문제가 아니라 구조의 문제다. 일을 오래 한다고 일이 끝나는 것은 아니다. 하네스는 에이전트가 열심히 일하게 만드는 장치가 아니라, 적절한 순간에 멈추고 방향을 수정하게 만드는 장치여야 한다.

컨텍스트 오염은 정보 부족만큼 위험하다

많은 팀이 실패 원인을 정보 부족에서만 찾는다. 그래서 문서를 더 넣고, 기록을 더 붙이고, 검색 결과를 더 많이 넘겨준다. 그런데 에이전트는 정보가 부족해서만 실패하지 않는다. 오히려 너무 많은, 혹은 잘못 섞인 정보 때문에 실패하는 경우가 많다. 이것이 컨텍스트 오염이다.

컨텍스트 오염은 단순히 문장이 길어지는 문제가 아니다. 서로 다른 시점의 정보가 섞이고, 관련 없는 기록이 들어오고, 우선순위가 다른 지침이 한 화면 안에 공존하면서 모델의 판단 기준이 흐려지는 현상이다.

예를 들어 오래된 사내 정책과 최신 정책이 함께 들어 있으면, 에이전트는 둘 중 무엇이 현재 기준인지 헷갈릴 수 있다. 고객 A의 기록과 고객 B의 기록이 검색 과정에서 함께 섞이면, 개인화된 응답을 해야 하는 상황에서 완전히 엉뚱한 답을 낼 수 있다. 회의 초안, 수정본, 최종본이 구분 없이 주어지면, 어느 것이 진짜 승인된 문서인지 판단하기 어려워진다.

문제는 모델이 이런 혼합 상태를 항상 스스로 정리해주지 않는다는 점이다. 사람도 책상 위에 종이가 너무 많으면 일을 못 한다. 에이전트도 마찬가지다. 중요한 것은 많은 정보가 아니라 정렬된 정보다.

컨텍스트 오염은 특히 세 종류로 나타난다.

• 오래된 정보와 최신 정보가 섞이는 시간 오염

• 관련 없는 정보가 끼어드는 범위 오염

• 서로 충돌하는 지침이 함께 들어오는 규칙 오염

이 세 가지는 모두 판단을 흐리게 만든다. 그래서 컨텍스트 설계의 핵심은 더 많이 보여주는 것이 아니라, 지금 이 작업에 맞는 정보만 선별해 보여주는 데 있다.

메모리 왜곡은 편리함의 그림자다

에이전트에게 메모리를 주면 훨씬 똑똑해 보인다. 사용자의 선호를 기억하고, 이전 대화의 맥락을 이어가며, 반복 업무에서 효율을 높일 수 있다. 하지만 메모리는 편리함과 함께 왜곡 가능성도 가져온다.

가장 흔한 문제는 대화 기록과 업무 상태를 구분하지 않는 것이다. 사용자가 예전에 아이디어처럼 던진 말을 확정된 설정으로 기억해버리거나, 이미 바뀐 선호를 오래된 기억으로 덮어쓰는 일이 생긴다. 더 심각한 경우에는 일회성 예외를 일반 규칙으로 저장한다.

예를 들어 사용자가 "이번 주만 예외적으로 오후 미팅은 다 거절해줘"라고 했는데, 에이전트가 그것을 장기 선호로 저장하면 다음 주에도 계속 거절할 수 있다. 겉으로는 기억을 잘하는 것 같지만, 실제로는 기억의 범위와 유효기간을 구분하지 못한 것이다.

메모리 문제는 종종 컨텍스트 문제와 겹친다. 잘못 저장된 정보가 이후 컨텍스트에 반복 주입되면, 에이전트는 같은 실수를 점점 더 확신 있게 반복한다. 한 번의 오염이 습관이 되는 셈이다.

그래서 메모리는 "무엇을 저장할까"보다 "무엇을 저장하지 말아야 할까"가 더 중요하다. 기억이 많을수록 똑똑한 것이 아니라, 잘 구분된 기억이 있을수록 안정적이다.

권한 과다는 똑똑함이 아니라 위험의 확대다

실무에서 많은 팀이 빠르게 자동화를 보여주기 위해 에이전트에 넓은 권한을 준다. 파일 읽기와 쓰기, 메일 발송, 일정 생성, 데이터 수정, 외부 API 호출까지 한 번에 열어두면 분명 데모는 시원하게 돌아간다. 하지만 이 구조는 에이전트가 잘할 때만 좋아 보인다. 실수하는 순간 위험이 폭발적으로 커진다.

권한 과다의 본질은 단순히 보안 문제가 아니다. 판단의 불확실성과 실행의 영향력이 맞지 않는 상태다. 모델은 여전히 확률적으로 판단하는 시스템인데, 그 판단에 너무 강한 실행 권한을 붙여놓는 것이다.

예를 들어 읽기 전용으로 충분한 작업에 수정 권한까지 주면, 잘못된 추론이 실제 데이터 손상으로 이어질 수 있다. 메일 초안 작성만 하면 되는 작업에 발송 권한까지 주면, 검토되지 않은 메시지가 외부로 나갈 수 있다. 이때 문제는 모델이 틀렸다는 사실 자체보다, 틀렸을 때의 피해 반경이 너무 크다는 데 있다.

권한 문제는 늘 이렇게 물어야 한다. "이 에이전트가 가장 나쁜 실수를 했을 때, 어디까지 망가질 수 있는가?" 이 질문에 답하지 못하면, 권한 설계는 아직 시작도 하지 않은 것이다.

검증 없는 자동화는 작은 오류를 큰 사고로 만든다

에이전트가 낸 결과가 완벽할 것이라고 기대하는 순간, 시스템은 급격히 취약해진다. 실제로는 좋은 에이전트도 틀린다. 문제는 틀리는 사실보다, 틀린 결과가 그대로 다음 단계로 넘어가는 구조다.

검증 없는 자동화는 특히 연쇄 작업에서 위험하다. 검색 결과를 요약하고, 그 요약을 바탕으로 메일을 만들고, 그 메일을 바탕으로 티켓 상태를 바꾸는 식의 흐름에서는, 초반의 작은 오해가 뒤로 갈수록 더 큰 실행 오류로 불어난다. 첫 단추가 조금 어긋났을 뿐인데, 마지막에는 완전히 다른 작업이 완료되어 있을 수 있다.

여기서 중요한 것은 검증을 마지막에만 두면 늦는다는 점이다. 에이전트 작업은 중간 산출물이 많다. 무엇을 찾았는지, 무엇을 근거로 판단했는지, 지금 하려는 행동이 무엇인지, 그 행동이 정책에 맞는지 중간중간 확인할 수 있어야 한다. 그래야 작은 흔들림이 사고로 커지기 전에 잡힌다.

검증 없는 자동화는 흔히 속도를 위해 선택된다. 하지만 실제로는 반대다. 검증이 없으면 사고 수습에 훨씬 더 많은 시간이 든다. 빠른 자동화와 안전한 자동화는 적이 아니다. 제대로 된 검증 구조가 있어야 비로소 자동화를 안심하고 더 넓게 쓸 수 있다.

실패 유형은 따로 오지 않고 서로 엮여 온다

현장에서는 실패가 깔끔하게 한 종류로만 나타나지 않는다. 도구 오용은 종종 컨텍스트 오염과 함께 온다. 무한 루프는 검증 부재와 함께 길어진다. 권한 과다는 작은 도구 호출 실수를 큰 보안 사고로 바꾼다. 메모리 왜곡은 오래된 정책을 계속 불러오게 만들어 실행 실패를 반복시킨다.

예를 들어 고객 지원 에이전트를 생각해보자. 오래된 환불 정책이 컨텍스트에 섞여 들어왔다. 에이전트는 그것을 최신 기준으로 오해했다. 그다음 환불 도구를 호출하는데, 읽기 전용이어야 할 작업에 쓰기 권한이 열려 있었다. 그리고 결과를 검토하는 승인 단계도 없었다. 이 경우 문제는 환각 하나가 아니다. 컨텍스트 설계, 권한 설계, 검증 설계가 동시에 느슨했던 것이다.

그래서 실패를 분석할 때는 "무엇이 마지막에 잘못되었는가"만 보면 안 된다. "그 마지막 오류가 가능해지기까지 어떤 설계 빈틈이 이어졌는가"를 역으로 따라가야 한다. 이 관점이 있어야 재발 방지가 가능하다.

실패를 유형별로 이해해야 안전장치도 정확해진다

실패 구조를 이해하는 이유는 비판하기 위해서가 아니라, 안전장치를 정확히 설계하기 위해서다. 원인과 보호 장치가 맞물려야 하기 때문이다.

도구 호출 오류가 많다면 도구 설명, 입력 스키마, 실행 전 확인 단계가 필요하다. 무한 루프가 잦다면 종료 조건, 재시도 한도, 사람에게 넘기는 기준이 필요하다. 컨텍스트 오염이 문제라면 검색 범위 제한, 최신성 표시, 충돌 규칙 정리가 필요하다. 권한 과다가 위험하다면 읽기와 쓰기 분리, 단계별 승인, 최소 권한 원칙이 필요하다. 검증 부재가 문제라면 중간 체크포인트, 자동 테스트, 사람 검토 절차가 필요하다.

즉, 안전장치는 막연한 선의가 아니라 실패 유형에 대응하는 구체적 구조여야 한다. 아무 데나 "주의하라"는 문장을 붙이는 것으로는 부족하다. 에이전트가 어디서 흔들리는지 알아야, 정확한 위치에 울타리를 세울 수 있다.

좋은 하네스는 실패하지 않는 시스템이 아니라, 실패를 통제하는 시스템이다

여기서 중요한 오해 하나를 풀어야 한다. 좋은 하네스를 설계한다는 것은 에이전트가 절대 실패하지 않게 만드는 일이 아니다. 그런 시스템은 없다. 좋은 하네스란 실패가 일어나더라도 그 실패가 작고, 드러나고, 추적 가능하고, 복구 가능한 상태를 만드는 것이다.

다시 말해 목표는 완벽성이 아니라 통제 가능성이다. 도구를 잘못 고를 수는 있다. 하지만 위험한 작업 전에는 멈추게 해야 한다. 오래된 정보를 볼 수는 있다. 하지만 최신성 충돌을 표시하게 해야 한다. 잘못된 초안을 만들 수는 있다. 하지만 검증 없이 외부로 나가지 않게 해야 한다. 루프에 들어갈 수는 있다. 하지만 일정 횟수 이후에는 스스로 실패를 선언하게 해야 한다.

이 관점이 중요하다. 에이전트는 똑똑한 정답 기계가 아니라, 불확실성 속에서 일하는 실행 주체다. 그렇다면 하네스 설계의 일은 그 불확실성을 없애는 것이 아니라, 위험을 관리 가능한 형태로 바꾸는 것이다.

다음 장으로 넘어가기 전에 기억할 질문

이 장에서 살펴본 실패 유형은 앞으로의 모든 설계 논의의 배경이 된다. 실행 환경, 도구, 권한, 메모리, 컨텍스트, 워크플로, 검증, 관측 가능성은 모두 이런 실패를 줄이기 위해 존재한다.

다음 장부터는 개별 설계 요소를 하나씩 다룰 것이다. 그 전에 독자는 세 가지 질문을 붙들고 가면 좋다.

• 이 에이전트는 어디에서 틀린 말을 할 수 있는가가 아니라, 어디에서 틀린 행동을 할 수 있는가?

• 이 실패는 모델의 일시적 실수인가, 아니면 시스템이 반복해서 만들어내는 구조인가?

• 이 실패를 막기 위해 더 긴 프롬프트가 필요한가, 아니면 더 좋은 하네스가 필요한가?

에이전트는 종종 똑똑해서 실패하는 것이 아니라, 너무 많은 것을 믿고 맡겨서 실패한다. 실패 유형을 정확히 보는 순간, 설계는 훨씬 현실적이 된다. 그리고 바로 그 지점에서 하네스 설계는 추상적인 아이디어가 아니라, 제품의 안전성과 신뢰성을 만드는 실무 기술이 된다.