AI 에이전트는 좀처럼 다운되지 않는다. 조용히 실패하며, 연구는 그 이유를 보여 준다

대규모 언어 모델 에이전트는 이제 고객 지원 요청에 답하고, 데이터베이스를 조회하며, 여행을 계획한다. 문제가 생겨도 대개 확신에 찬 답변과 성공 코드를 반환한다. 이러한 실패를 알아차리기 어려운 이유와 엔지니어링 팀이 이를 측정하는 방법을 배워 가는 과정을 설명하는 연구가 점점 늘고 있다.

성공처럼 보이는 실패

기존 소프트웨어는 대체로 요란하게 실패한다. 함수에서 예외가 발생하고, 서버는 오류 코드를 반환하며, 모니터링 대시보드는 빨간색으로 바뀐다. AI 에이전트는 다르게 작동한다. AI 에이전트는 언어 모델이 프롬프트를 읽고, 검색 API나 데이터베이스 같은 도구를 호출할지 결정하고, 결과를 읽은 다음, 다음에 할 일을 정하는 순환 과정이다. 이 과정의 모든 네트워크 요청이 성공하더라도 각 단계에서는 문제가 생길 수 있다.

흔히 일어나는 상황을 생각해 보자. 날씨 도구가 실패해, 그 밖에는 정상적인 응답에 “서비스를 사용할 수 없습니다”라는 문구를 반환한다. 모델은 이 문구를 읽고 정중하게 사과하거나, 더 나쁘게는 학습 데이터에 기반해 그럴듯한 예보를 작성한다. 사용자는 매끄러운 답변을 받는다. 서버 로그에는 정상적인 지연 시간과 함께 요청이 성공한 것으로 기록된다. 기존 모니터링 체계에는 무언가 잘못됐다는 기록이 전혀 남지 않는다.

모델 제공업체들도 자체 문서에서 같은 문제를 설명한다. Google의 Gemini API 안내서는 모델이 “함수 자체를 실행하지 않는다”고 밝힌다. 모델은 함수 이름과 인수를 제안할 뿐이며, 실제 호출은 개발자의 애플리케이션이 수행한다. 따라서 시스템에서 실제 결과를 확인할 수 있는 부분은 애플리케이션뿐이다. 에이전트 구축에 관한 Anthropic의 엔지니어링 안내서도 이와 관련해, 에이전트가 자신의 진행 상황을 판단하려면 도구의 결과와 같이 각 단계에서 환경으로부터 “실제 정답”을 얻어야 한다고 설명한다. 도구가 실패를 일반 텍스트로 알리면 그 실제 정답은 잘못된 것이 되고, 에이전트는 이를 알아차릴 방법이 없다.

이는 새로운 유형의 문제가 아니라, 오래된 문제가 한층 더 뚜렷해진 것이다. 2015년, D. Sculley가 이끄는 Google 엔지니어들은 머신러닝 시스템의 “숨겨진 기술 부채”를 설명했다. 이들은 실제 운영 환경의 머신러닝 시스템에서 위험의 대부분은 모델 코드가 아니라 데이터 의존성, 구성, 연결 코드에 있다고 주장했다. 에이전트는 이 목록에 새로운 요소를 더한다. 프롬프트와 도구 설명은 코드 변경 없이도 시스템의 동작을 바꿀 수 있는 구성 요소다.

작은 수정, 큰 영향

프롬프트를 조금 바꾸는 것만으로 얼마나 큰 차이가 생길 수 있을까? ICLR 2024에서 발표된 논문에서, University of Washington의 Melanie Sclar와 동료들은 퓨샷 프롬프트의 형식, 즉 구분자, 간격, 대소문자 표기만 바꿨다. 의미는 그대로였다. 그런데도 LLaMA-2-13B의 동일 과제 성능은 최대 76 정확도 포인트까지 달라졌다. 모델을 더 크게 만들거나 예시를 추가하거나 지시 튜닝을 해도 이러한 민감성은 사라지지 않았다.

저자들은 하나의 수치만 제시하기보다, 그럴듯한 여러 프롬프트 형식에서 나타나는 성능 범위를 보고할 것을 권한다. 엔지니어링 팀이 얻을 실질적인 교훈은 더 간단하다. 프롬프트 수정은 코드 변경이다. 버전 이력이 필요하고, 사용자에게 제공하기 전에 테스트해야 한다.

모델이 프롬프트의 일부로 읽는 도구 설명에도 같은 원칙이 적용된다. Anthropic의 안내서는 도구 정의에도 기본 프롬프트만큼이나 “프롬프트 엔지니어링에 세심한 주의를 기울여야 한다”고 권고한다. 이 안내서는 상대 경로를 계속 잘못 사용하는 코딩 에이전트의 사례를 소개한다. 도구가 절대 경로를 요구하도록 바꾸자 모델은 오류 없이 도구를 사용했다. 모델은 바뀌지 않았다. 모델이 읽는 설명만 바뀌었다.

성공 한 번만으로는 알 수 있는 것이 거의 없다

두 번째 연구 흐름은 일관성을 살펴본다. Sierra의 Shunyu Yao와 동료들이 발표하고 ICLR 2025에서 소개한 τ-bench 벤치마크는 에이전트가 도구를 사용하고 업무 규칙을 따라야 하는 고객 서비스 대화를 시뮬레이션한다. 저자들은 pass^k라는 지표를 도입했다. 이는 에이전트가 동일한 과제를 k번 시도해 매번 정확하게 해결할 확률이다.

결과는 우려스러웠다. GPT-4o 에이전트는 소매업 과제를 한 번 시도했을 때 약 61%를 해결했다. 같은 과제를 8번 연속 성공해야 하는 조건에서는 성공률이 약 25%로 떨어졌다. 한 번 작동하는 시연만으로는 시스템이 천 번째 실행에서 어떻게 작동할지 거의 알 수 없다.

다중 에이전트 시스템은 어디서 무너지는가

많은 팀이 이제 여러 에이전트를 연결해 하나는 계획을 세우고, 다른 하나는 실행하며, 세 번째는 결과를 검토하게 한다. UC Berkeley의 2025년 연구인 “다중 에이전트 LLM 시스템은 왜 실패하는가?”는 널리 쓰이는 다중 에이전트 프레임워크 7개에서 주석이 달린 실행 추적 1,600건 이상을 분석했다. Mert Cemri가 이끈 저자들은 시스템 설계 문제, 에이전트 간의 불일치, 과제 검증이라는 세 그룹에 걸쳐 14개의 실패 유형을 분류한 MAST 분류 체계를 만들었다.

저자들의 핵심 발견은 많은 실패가 기반 모델의 한계뿐 아니라 시스템 설계 방식에서 비롯된다는 것이다. 에이전트는 부여된 역할을 무시하고, 대화 내용을 놓치거나, 결과를 확인하지 않은 채 과제가 끝났다고 선언한다. 이런 실패는 오류 기록을 남기지 않는다. 누군가 각 에이전트가 실제로 한 일을 확인할 수 있을 때만 드러난다. Unite.AI가 다룬 다중 에이전트 역설도 아키텍처 측면에서 비슷한 점을 지적한다. 에이전트를 추가하면 초기 오류를 상쇄하기보다 증폭할 수 있다는 것이다.

보이지 않는 문제를 드러내기

이 문제에 대한 엔지니어링 차원의 대응은 분산 시스템에서 아이디어를 가져왔다. 분산 시스템에서는 오래전부터 추적이라는 기법을 사용해 여러 서비스에 걸친 요청의 흐름을 따라왔다. 이를 에이전트에 적용하면 사용자 요청 하나가 하나의 트레이스가 되고, 모델 호출이나 도구 호출은 그 안의 하나의 ‘스팬’이 된다. 스팬에는 입력과 출력, 사용된 토큰 수, 처리 시간이 기록된다. 이 분야의 산업 표준화 기구인 OpenTelemetry는 생성형 AI 스팬에 적용할 공통 규약을 마련하고 있다. 2026년 현재 이 규약은 아직 개발 중으로 표시되어 있어 속성명이 바뀔 수 있다.

Langfuse, Arize Phoenix, AcruxCore 같은 여러 오픈 소스 프로젝트는 이미 이 아이디어를 적용하고 있다. 소스 코드가 공개되어 있어 팀은 트레이스가 어떻게 저장되는지 살펴보고 자체 서버에서 소프트웨어를 실행할 수 있다. 이들 프로젝트는 모델 호출과 도구 호출을 하나의 트레이스에 속한 스팬으로 기록하고, 팀이 각 스팬에 품질 점수를 매길 수 있게 한다. 어떤 도구를 선택하는지는 한 가지 세부 사항보다 중요하지 않다. 도구 스팬에는 네트워크 요청이 성공했는지만이 아니라 도구가 실제로 반환한 내용이 기록되어야 한다. 그렇지 않으면 앞서 설명한 날씨 도구의 실패는 드러나지 않는다.

업계 설문조사에 따르면 트레이싱은 이제 보편화됐지만, 테스트는 그에 미치지 못하고 있다. LangChain의 State of Agent Engineering 보고서는 2025년 말 실무자 1,340명을 대상으로 설문조사를 진행했다. 응답자의 32%가 에이전트를 프로덕션 환경에 도입하는 데 가장 큰 걸림돌로 품질을 꼽았다. 조직의 89%는 에이전트에 어떤 형태로든 관측 가능성을 적용하고 있다고 답했으며, 62%는 개별 단계와 도구 호출을 상세히 추적하고 있었다. 테스트 세트를 이용해 오프라인 평가를 실시한 비율은 52.4%에 그쳤고, 실제 트래픽을 평가한 비율은 37.3%였다. 대부분의 팀은 에이전트가 무엇을 했는지 확인할 수 있다. 하지만 그 결과가 정확했는지 확인하는 팀은 더 적다.

대규모로 답변 평가하기

트레이스는 무슨 일이 있었는지 보여준다. 하지만 답변이 좋았는지는 알려주지 않는다. 모든 대화를 사람이 일일이 읽는 방식은 규모를 키우기 어렵기 때문에, 팀은 점점 더 두 번째 모델을 평가자로 활용하고 있다. 이를 LLM 심사자 방식이라고 한다. Lianmin Zheng과 동료들이 발표한 NeurIPS 2023 논문에 따르면 GPT-4 같은 강력한 모델은 인간의 선호와 80% 넘게 일치했다. 이는 인간끼리 서로 동의하는 비율과 거의 같은 수준이다.

같은 논문은 이 방식의 약점도 기록했다. 평가 모델은 먼저 제시된 답변과 더 긴 답변을 선호하며, 스스로 작성한 텍스트에 더 높은 점수를 줄 수도 있다. 따라서 평가 모델의 점수는 추정치다. 많은 양의 답변을 평가하는 데 유용하지만, 답변 순서를 무작위로 바꾼 뒤 사람이 라벨링한 소규모 예시 집합과 대조해 확인해야 한다.

실무에서 정책으로

이러한 측정 작업은 거버넌스 차원의 기대 사항으로도 자리 잡고 있다. 미국 국립표준기술연구소는 2023년 1월 AI 위험 관리 프레임워크를 발표했다. 네 가지 핵심 기능 가운데 하나인 ‘측정’은 조직이 AI 위험을 정량화하고, 추적하며, 시간의 흐름에 따라 문서화하도록 요구한다. 에이전트의 경우 트레이스와 평가 점수가 바로 이 기능에서 요구하는 근거다.

팀이 지금 할 수 있는 일

이는 이 플랫폼에서 제기된 에이전트형 AI의 진정한 시험대는 신뢰성이라는 주장과도 맞닿아 있다. 앞서 살펴본 연구는 그 주장을 뒷받침하는 측정의 세부 사항을 보여준다. 신뢰성은 한 번 관찰하고 끝낼 수 있는 속성이 아니라, 계속 측정해야 하는 범위다.

연구 결과는 몇 가지 핵심적인 실천 방안을 제시하며, 주요 모델 제공업체들도 이 가운데 상당수를 권고한다. OpenAI의 에이전트 구축 실용 가이드는 최적화에 앞서 “성능 기준선을 설정할 수 있도록 평가를 마련하라”고 팀에 권한다. 또한 에이전트가 정해진 횟수 이상 실패를 반복하거나 위험도가 높은 작업에 직면하면 제어권을 사람에게 넘기라고 한다. Anthropic은 에이전트가 자율적으로 작동하기 전에 “샌드박스 환경에서 충분히 테스트할 것”을 권고한다.

실제로는 몇 가지 구체적인 조치를 취하면 된다. 프롬프트와 도구 설명을 코드처럼 버전 관리한다. 각 프롬프트 변경 사항을 고정된 데이터 세트로 테스트하고, 하나의 숫자가 아니라 결과의 범위를 예상한다. 한 번의 실행으로는 일관성 부족이 드러나지 않으므로 각 테스트 사례를 여러 차례 실행한다. 도구의 출력을 트레이스에 기록해 도구가 실패했을 때 성공 코드 뒤에 숨지 못하게 한다. 자동 평가 모델의 점수는 추정치로 간주하고, 사람의 평가와 대조해 확인한다.

이러한 실천 방안은 어느 것도 모델 성능의 획기적인 발전을 필요로 하지 않는다. 필요한 것은 AI 에이전트를 있는 그대로, 즉 측정해야 하는 확률적 시스템으로 대하는 일이다. 에이전트는 자신의 실패를 거의 알리지 않기 때문이다.