AI 에이전트 실패 진단과 처방 매핑 아키텍처

실패를 같은 처방으로 다루면 개선이 쌓이지 않는다

에이전트 실패 뒤에는 모델 교체, 프롬프트 수정, 도구 스펙 변경이라는 선택지가 흔히 따라온다. 하지만 컨텍스트가 잘려 앞선 결정을 잊은 상황에서는 모델을 바꿔도 문제가 재현될 수 있다. 도구 파라미터 스키마가 잘못된 경우라면 프롬프트만 다듬어도 다음 실행에서 다른 형태의 실패가 이어진다.

처방을 선택하기 전에 원인을 가르는 일이 필요한 이유다. 서로 다른 원인에 대응하는 조치를 무작위로 반복하면 개선 곡선은 평평해진다. 실패 분류 체계가 개선 속도를 좌우하는 배경도 여기에 있다.

2026년 들어 현장의 관점은 “더 나은 모델을 쓰면 해결된다”는 기대에서, 실패를 원인별로 나누고 각각에 맞는 처방을 적용하는 운영 체계로 이동하고 있다. Microsoft의 에이전트 실패 유형 화이트페이퍼, Anthropic의 컨텍스트 엔지니어링 가이드, Google의 세션·메모리 백서는 원인 분류 없이는 개선을 축적하기 어렵다는 문제의식과 맞닿아 있다.

Microsoft Security Blog가 정리한 에이전트형 AI 시스템 실패 유형 분류(2026년 6월)는 레드팀 활동 1년의 결과물이다. alphaXiv에 공개된 “Model or Harness?” 연구는 실패의 국지화(localization)를 모델 한계와 하네스(harness), 즉 컨텍스트·도구·오케스트레이션 계층의 결함으로 구분하는 일을 핵심 질문으로 둔다. 실행 궤적에서 복구되지 않은 최초 실패 지점에 원인 라벨을 붙이는 “root-cause view” 역시 같은 방향이다. 실패는 여러 증상으로 이어질 수 있지만, 처방은 그 연쇄가 시작된 지점을 겨냥해야 한다.

실행 궤적에서 원인을 분리하는 방법

여러 연구와 벤더 문서가 2026년 시점에 수렴하는 실패 분류축은 컨텍스트 결함, 도구 오류, 모델 능력 한계, 계획·목표 관리 실패로 정리할 수 있다.

컨텍스트 결함: 컨텍스트 손실(context loss), 컨텍스트 손상(context rot), 검색 실패, 최근 정보 과대가중
도구 오류: 도구 오용(잘못된 파라미터·잘못된 시점 호출), 스키마 오류(잘못된 형식의 JSON), 타임아웃 연쇄
모델 능력 한계: 추론 실패, 환각(존재하지 않는 사실·도구 호출), 장기 추론에서의 반복·순환
계획·목표 관리 실패: 목표 표류(goal drift), 순환 추론(circular reasoning), 과잉 거부(over-refusal)

이 축을 공통 태그 체계로 두면 실패 로그를 처리할 때 애매한 사례를 줄일 수 있다.

⤢✕

컨텍스트 결함은 세션이 길어질수록 드러나는 경우가 많다. 세션 턴 수가 늘면서 컨텍스트 유지 정확도가 떨어지거나, 확정한 결정을 다시 묻고 완료한 단계를 반복하는 패턴이 나타난다. 검색 증강 구성에서는 관련 문서가 순위 밖으로 밀려나는 현상도 신호가 된다. Anthropic의 컨텍스트 엔지니어링 관점에서 컨텍스트는 “추론 시점에 에이전트가 볼 수 있는 정보를 큐레이션하고 유지하는 작업”이다. 이 관점에서 보면 컨텍스트 결함은 무엇을 남기고 압축·삭제할지 정한 규칙이 없거나 제대로 작동하지 않은 큐레이션 실패다.

도구 오류는 존재하는 도구를 잘못된 파라미터 또는 시점에 호출할 때 발생한다. 응답이 스키마를 위반해 파싱이 깨지거나, 한 도구 호출의 지연이 이후 단계 전체를 재촉하거나 생략시키는 연쇄도 여기에 속한다. 동일한 컨텍스트를 유지한 채 도구 스펙만 수정했을 때 재현이 사라지는지 확인하는 방식이 컨텍스트 결함과 구분하는 실무 기준이 된다.

모델 능력 한계는 컨텍스트와 도구가 정상이라는 가설을 먼저 배제한 뒤에 좁혀야 한다. 존재하지 않는 사실이나 도구 호출을 만들어내는 환각, 동일한 2~3단계를 맴도는 순환 추론이 대표적인 신호다. 이 확인 없이 모델 교체부터 시도하면 가장 비싼 처방이 습관적으로 선택되고, 실제 원인은 남아 있을 수 있다.

재현 가능한 실패 기록이 처방의 검증 단위가 된다

실패를 분류했다면 발생 조건도 함께 보존해야 한다. 입력, 컨텍스트 상태, 도구 응답을 재현할 수 없으면 처방을 적용한 뒤 무엇이 달라졌는지 검증할 수 없다.

원인별 처방과 측정 지표를 연결하면 담당자가 바뀌어도 대응 방향이 흔들리지 않는다.

원인 범주	대표 처방	효과 측정 지표
컨텍스트 결함	컨텍스트 편집(규칙 기반 가지치기), 메모리 도구 도입, 도구 호출 후 잔여 용량 피드백	세션 길이별 정확도 유지율, 반복 단계 발생률
도구 오류	스키마 강화, 파라미터 검증 레이어, 타임아웃 격리	도구 호출 성공률, 스키마 위반율
모델 능력 한계	모델 교체·업그레이드, 프롬프트 내 추론 스캐폴딩 강화	환각률, 순환 추론 발생률
계획·목표 관리 실패	목표 재확인 체크포인트, 거부 임계값 재조정	목표 이탈까지 걸린 단계 수, 과잉 거부율

분류 결과도 고정된 정답으로 취급할 수는 없다. 같은 실패 로그를 다른 시점에 다시 태깅했을 때 결과가 일치하는지로 재현성을 확인하고, 처방 이후에도 같은 태그의 실패가 재발하는지로 태그 유효성을 점검해야 한다. 태그가 자주 바뀌거나 처방이 반복적으로 효과를 내지 못한다면, 분류축을 다시 설계해야 한다는 신호다.

운영 체계에 분류를 정착시키는 순서

분류보다 앞서는 조건은 관찰 가능성(observability)이다. 프롬프트, 도구 호출과 응답, 컨텍스트 변화까지 포함한 실행 궤적(trajectory)이 자동으로 남아야 사후에 원인을 구분할 수 있다. 프로덕션에서 이 기록이 빠지면 분류 체계는 판단 근거를 잃는다.

그다음에는 조직의 도메인에 맞춰 분류축을 좁히거나 세분화한다. 스키마 오류나 타임아웃처럼 규칙 기반으로 명확하게 잡히는 신호는 자동 판별기로 넘길 수 있다. 목표 표류나 환각처럼 맥락 판단이 필요한 신호는 초기 단계에서 사람의 사후 분석 대상으로 남겨두는 편이 현실적이다.

원인별 처방 책임도 미리 배정해야 한다. 컨텍스트 결함은 프롬프트·컨텍스트 엔지니어링 담당이, 도구 오류는 통합 담당이, 모델 능력 한계는 모델 선정 담당이 맡는 식이다. 각 담당자가 어떤 지표로 효과를 보고할지도 함께 합의해야 처방이 무작위로 순환하지 않는다.

분류축은 새로운 실패 패턴에 따라 개정해야 한다. 개정 주기를 정기화(예: 분기별)하고, 제안과 승인 주체를 명시하면 실제 실패 분포와 동떨어진 낡은 체계를 피할 수 있다.

대응 방식이 달라지면 운영 비용도 달라진다

모델 교체를 우선하는 대응은 처음에는 빠르고 단순하다. 다만 컨텍스트나 도구 문제까지 모델 탓으로 돌리면 새 모델에서도 같은 실패가 재현되고 비용만 누적될 수 있다. 원인 분류 기반 대응은 로깅과 태깅 체계를 만드는 초기 투자가 필요하지만, 반복되는 동일 원인에 처방을 재사용할 수 있어 재현성과 장기 비용 측면에서 차이가 난다.

자동 판별은 처리량에 강점이 있지만, 정확도는 신호가 얼마나 명확한지에 좌우된다. 스키마 오류처럼 규칙으로 잡히는 실패는 자동화하기 적합하다. 반면 목표 표류처럼 맥락 의존적인 신호까지 자동화하면 오분류가 누적되고 처방 매핑표도 오염될 수 있다. 명확한 신호부터 자동화하고, 애매한 범주는 사람이 주기적으로 샘플을 검토하는 하이브리드 구조가 필요한 이유다.

개별 실패를 급하게 봉합하고 종료하면 당장의 운영 부담은 줄어든다. 대신 반복 패턴을 발견할 기회를 잃는다. 실패 사례를 축적하고 재현 시나리오로 보존하면 초기 부담은 늘지만, 여러 사례에 반복되는 원인을 찾아 처방의 우선순위를 데이터로 정할 수 있다. 실패를 테스트 케이스로 바꾼 조직이 반응형 루프에서 벗어나 개발 속도가 빨라진다는 관찰도 이 축적의 가치를 뒷받침한다.

전통적인 IT 서비스 관리에서 장애 관리(Incident Management)와 문제 관리(Problem Management)를 나누는 방식은 이 구조와 대응한다. 장애 관리는 개별 실패를 빠르게 봉합하고, 문제 관리는 축적된 사례에서 반복 장애의 근본 원인을 찾아 재발을 막는다. 에이전트 실패 분류와 처방 매핑은 문제 관리를 에이전트 운영에 적용한 형태다. 재현 시나리오를 회귀 테스트처럼 관리하는 품질 보증(QA) 체계를 결합하면 세 기능은 하나의 파이프라인으로 이어진다.

2026년 이후에는 이 파이프라인을 얼마나 자동화하면서도 오분류 위험을 통제하는지가 운영의 균형점이 될 전망이다. 실패 로그 수집, 분류 기준, 처방 책임, 재현 시나리오 보존을 함께 설계해야 컨텍스트 엔지니어링이 운영 능력으로 자리 잡을 수 있다.