에이전트 실패를 감지하고 수정하는 방법

원래 three.dev에서 게시되었습니다.

점점 더 많은 기업들이 AI 에이전트를 출시하고 있습니다. 어떤 회사들은 이미 존재하던 경험을 개선합니다. 예를 들어, 인간이 확인하기 전에 대부분의 티켓에 답변하는 지원 어시스턴트 같은 경우입니다. 또 다른 회사들은 아무도 수동으로 하고 싶어 하지 않았던 일을 대신 수행합니다. 예를 들어, 모든 영업 통화를 읽고 나중에 CRM(Customer Relationship Management)을 채우는 에이전트 같은 경우입니다.

하지만 실제로 이러한 에이전트들이 어떻게 작동하는지 모니터링하는 기업은 훨씬 적습니다. 대부분의 팀이 가진 관측 가능성(observability) 도구들은 트레이스(traces)를 보여줍니다: 모든 요청, 그 지연 시간(latency), 토큰 수(token count), 비용(cost) 같은 것들입니다. 하지만 이 도구들은 에이전트가 저지른 실수나, 그것들이 얼마나 자주 발생하는지는 알려주지 않습니다. 이를 알기 위해서는 대화들을 하나하나 읽어야 하는데, 아무도 일주일에 만 개의 대화를 다 읽을 수는 없습니다.

따라서 대부분의 기업에서 볼 수 있는 에이전트 실패 감지 및 완화 프로세스는 다음과 같습니다:

1. 고객이 보고하거나 개발자가 에이전트 트레이스를 수동으로 검토하여 실패가 감지됩니다.
2. 개발자가 코딩 에이전트(coding agent)에게 이를 수정하도록 요청합니다.
3. 수정 사항을 한두 가지 예시에서 검증한 후 배포합니다.

이 과정에는 몇 가지 문제가 있습니다.

첫째, 실패 감지가 선제적이지 못합니다. 이는 고객이 실패를 겪고 보고하는 것에 의존하거나, 개발자가 우연히 그 실패가 나타난 트레이스를 열어보는 것에 의존합니다.

둘째, 실패를 수정하는 것이 보이는 것보다 어렵습니다. 모든 실패는 고유한 특성을 가지고 있습니다: 언제 발생하는지, 어떤 형태인지, 그리고 모델이 왜 그러한 경로를 따르는지 말입니다. 이 글에서 보게 될 것처럼, 깊이 있는 문맥(in-depth context) 없이 실패 수정을 요청받은 코딩 에이전트는 문제를 찾을 수는 있지만, 그 수정 사항은 증상만 다루고 근본적인 행동 방식은 그대로 남겨둡니다.

마지막으로, 수정된 부분이 모니터링되지 않습니다. 검사했던 몇 가지 예시에서는 작동하는 수정이라도 실제 운영 환경(production)에서 일반화에 실패할 수 있고, 심지어 이전에 본 적 없는 새로운 실패 양식(failure modes)을 도입할 수도 있습니다. 우리는 둘 다 발생한 것을 목격했습니다.

three.dev는 이러한 프로세스를 간소화하기 위해 구축되었습니다. 이 글에서는 하나의 AI 에이전트가 첫 대화부터 최종 수정까지 거치는 과정을 추적하고, 한 회사가 three.dev를 사용하여 에이전트의 실패를 자동으로 감지하고 적절하게 수정하는 방법을 보여줍니다.

사용 사례: 지원 어시스턴트

three.dev 통합을 통해 무엇이 가능한지 보여주기 위해, 저희는 스마트 홈 기기를 판매하고 3가지 플랜으로 클라우드 구독 서비스를 제공하는 가상의 회사인 Nimbus Home을 위한 지원 어시스턴트를 구축했습니다. 이 어시스턴트는 정책 질문에 답하고, 고객의 주문, 구독 및 장치를 조회하며, 반품 절차를 시작하고, 플랜을 변경하고, 상담이 인간의 개입이 필요한 경우 적절한 팀에 티켓을 열어줍니다.

그 후 저희는 이 어시스턴트가 반품, 취소, 플랜 변경, 청구 분쟁, 보증 청구 및 계정 복구를 다루는 183건의 대화를 처리하도록 했습니다.

실패 감지하기

이 어시스턴트는 three.dev와 통합되었고, 이 통합을 통해 얻은 첫 번째 이점은 자동 실패 감지였습니다. 어시스턴트가 제공하는 모든 응답은 그 지침과 이용 가능한 컨텍스트를 기준으로 점수가 매겨졌으며, 실패는 정의, 개수, 그리고 해당 응답으로 구성된 이름이 지정된 실패 모드(failure modes)로 그룹화되었습니다.

Step 1, scoring a response: the AI Judge checks one reply against each instruction and flags that the assistant looked up the order before verifying the customer.

Step 2, grouping failures together: 529 of 1,447 responses had a defect, grouped into 18 failure modes led by account access before verification (99).

두 단계: AI Judge가 각 응답을 지침과 비교하여 점수를 매긴 다음, 실패를 이름이 지정된 실패 모드로 그룹화합니다.

이 모든 과정에 저희의 입력은 전혀 필요하지 않았습니다. 저희는 평가(evals)를 작성하지 않았고, three.dev에게 무엇을 찾아야 한다고 지시하지도 않았으며, 단 하나의 대화 내용도 읽지 않았습니다. 실패 모드들은 대화 자체에서 나타났는데, 그중에는 저희가 결코 확인해 보지 않았을 만한 것들까지 포함되어 있었습니다.

점수화된 1,447개의 응답 중 529개에 하나 이상의 결함이 발견되었는데, 이는 삼 분의 일 이상에 해당합니다. 이들은 18가지가 다른 실패 모드로 분류되었습니다. 다음은 다섯 가지 예시입니다:

• 검증 전 계정 접근 (Account access before verification) (99건). 고객이 신원 확인 절차를 거치기 전에, 어시스턴트가 주문이나 기기와 같은 계정 기록을 조회했으며, 일부 사례에서는 아직 검증되지 않은 고객에게 해당 기록 내용을 알려주기도 했습니다.
• 지식 기반 없이 정책 언급 (Policy stated without the knowledge base) (86건). 어시스턴트가 그 내용이 담긴 문서를 읽거나 인용하지 않고도 정책, 가격 또는 적격성 규칙을 언급했습니다.
• 근거 없는 고객 약속 (Unsupported promises to customers) (71건). 어시스턴트가 응답 시간, 확인 이메일, 환불, 수수료 면제 또는 티켓 처리 결과 등 근거가 되지 않는 약속들을 했습니다.
• 미응답 고객 요청 (Unanswered customer requests) (69건). 어시스턴트가 고객이 요청한 내용의 일부를 다루지 않았거나, 부분적으로만 답변했습니다.
• 이메일 주소 요청 누락 (Missing email request) (60건). 어시스턴트가 고객 계정을 찾기 위해 필요한 이메일 주소를 묻는 과정 없이 바로 진행했습니다.

이것이 표준적인 실패 감지 프로세스가 제공할 수 없는 것입니다. 고객 보고서나 수동으로 열어본 추적(trace)은 한 번에 하나의 실패만을 보여줄 뿐, 그것이 일회성인지 패턴인지를 판단할 방법이 없습니다. 반면 여기서는 모든 실패 모드가 그 규모와 그 뒤의 응답들과 함께 제시되었기 때문에, 이를 수정해야 하는 사람이 정확히 어떻게 발생하는지 확인할 수 있었습니다.

우리는 목록에서 첫 번째 실패 모드인 인증 전 계정 접근 문제를 수정하기로 했습니다. 이 문제는 고객이 본인임을 증명하기도 전에 어시스턴트가 계정에 접근하는 경우를 다룹니다. 즉, 신원 확인 절차가 아직 보류 중이거나 전혀 시작되지 않은 상태에서 주문을 조회하거나, 장치 기록을 읽거나, 진단을 실행하는 경우입니다. 이 문제는 99번 발생하여 가장 빈번한 실패 모드였고, 실제 보안 위험을 내포하고 있었습니다.

신원 확인 실패 수정하기

우리는 대부분의 팀이 공통적으로 가지고 있는 두 가지 제약 조건 하에 이 실패를 수정했습니다. 첫째, 지식 기반(knowledge base)은 여전히 단일 진실 공급원(single source of truth)으로 유지됩니다. 정책을 코드나 도구 반환값에 복사하지 않기 때문에 동기화해야 할 두 번째 사본이 생길 일이 없습니다. 둘째, 모델은 그대로 유지됩니다. 대부분의 사용 사례에서 더 큰 모델로 전환하는 것은 실현 가능하지 않은데, 그 이유는 응답당 비용이 더 많이 들고 생산량이 그 차이를 증폭시키기 때문입니다.

three.dev 통합으로 어떤 변화가 생겼는지 확인하기 위해, 우리는 동일한 코드베이스를 사용하여 같은 간결한 지침(brief)을 가지고 두 번의 별도 코딩 에이전트 세션에서 실패 수정 작업을 진행했습니다:

제 지원 챗봇 기능에 현재 문제가 발생하고 있습니다. 사용자의 신원을 확인하기 전에 내부 액션을 수행했던 사례가 트레이스에서 발견되었습니다. 이것을 고칠 수 있나요?

첫 번째 세션에는 코드베이스만 제공되었고 다른 것은 없었습니다. 이는 에이전트가 도구가 허용하는 것을 볼 수는 있지만, 어시스턴트가 실제 고객과 어떻게 상호작용하는지는 알 수 없는 표준 설정이었습니다. 두 번째 세션에서는 MCP 서버를 통해 three.dev가 어시스턴트에 대해 수집한 모든 것(실패 모드, 그리고 각 실패 모드에 대한 플래그 지정된 응답 및 그 배경 대화)에 접근할 수 있었습니다.

표준 수정 방법

문제는 찾기 어렵지 않았다. 주문 취소나 플랜 변경 같은 모든 계정 액션은 이미 인증되지 않은 세션을 거부했지만, 여섯 개의 조회 도구(lookup tools)들은 그렇지 못했다: get_order, get_device, run_diagnostic 등 다른 도구들도 요청하는 누구에게든 기록을 반환했다. 브리프와 코드를 바탕으로 코딩 에이전트는 이 허점을 발견하고 누락된 검사를 추가하여, 이제 인증되지 않은 세션에 대한 조회는 기록 대신 “인증되지 않음(not verified)”을 반환하게 되었다.

이는 올바른 수정이며 데이터 노출을 막는다. 하지만 이는 실패의 원인이 되는 동작 자체를 건드리지 않고 백엔드를 보호할 뿐이다. 코드는 도구들이 무엇을 허용하는지 보여줄 뿐이다. 어시스턴트가 인증하기 전에 계정에 얼마나 자주 접근하는지, 어떤 상황에서 그러는지, 또는 그 주변에서 또 무엇이 잘못되는지는 보여주지 않는다. 그것 없이는 재설계할 것이 아무것도 없고, 단지 잠글 문만 있을 뿐이었다.

three.dev의 수정 사항

three.dev의 MCP 서버와 skills를 통해 두 번째 코딩 에이전트는 브리프에서 시작하지 않았다. 실패 모드에서 시작했다: 1,447개의 응답 중 플래그가 지정된 99개를 그 뒤의 대화와 함께 가져와 하나하나 읽었다. 모델이 규칙을 무시하고 있지 않다는 것을 발견했다. 플래그가 지정된 응답들은 두 가지 주요 클러스터에 속했으며, 각각은 도구들이 허용한 지름길이었다:

• 고객이 가리킨 기록 조회 (58개 응답). 고객이 주문 번호나 기기 일련번호로 대화를 시작했고, 모델은 어떤 인증도 거치지 않고 즉시 이를 조회했다. 그런 다음 어시스턴트는 인증되지 않은 고객에게 조회된 내용을 답변했다.
• 동일 단계에서의 인증 및 조회 (28개 응답). 고객이 전화번호 자릿수와 우편번호를 제공했고, 모델은 인증에 성공할 것이라고 가정하고 verify_identity와 get_order를 함께 호출했다.

남은 13건은 상담원이 고객을 확인하기 전에 계정 소유자의 이름으로 인사하는 것과 같은 더 작은 사례들이었습니다. 이는 첫 번째 클러스터에서 플래그가 지정된 대화 중 하나입니다:

A flagged conversation: the assistant looks up the device and runs a diagnostic, never verifies the customer, then repeats the device details back.

가장 큰 클러스터의 58개 플래그 지정 응답 중 하나: 고객이 본 채팅 내용과 그 이면에 상담원이 수행한 작업. 강조된 부분: 장치 조회 및 상담원이 확인되지 않은 고객에게 반복적으로 전달한 진단 정보.

이러한 심층 분석 끝에, 코딩 에이전트는 무엇을 수정해야 하는지 알게 되었습니다. 이미 해당 행동을 금지하는 프롬프트가 있었기 때문에 프롬프트를 고치는 것이 아니라, 도구들이 열어둔 두 가지 경로를 고쳐야 했습니다. 이에 네 가지 변경 사항을 적용했습니다:

• 누락된 확인 절차(Missing check). 표준 수정과 마찬가지로, 계정 도구에 확인 절차를 추가했습니다. 이제 확인되지 않은 세션에 대한 조회를 수행하면 기록 대신 '계정 미확인'이 반환됩니다.
• 하나의 신원 도구(One identity tool). 두 개의 신원 도구를 verify_customer(email, phone_last4, postal_code)라는 하나의 도구로 병합했으며, 이 도구는 성공 시 고객 ID를 반환합니다.
• 고객 ID가 필요한 조회(Lookups that need the customer id). get_order, get_device 및 run_diagnostic은 이제 해당 고객 ID를 요구합니다. 주문 번호나 일련번호만으로는 더 이상 유효한 호출이 아니며, 고객 ID는 성공적인 확인을 통해서만 얻어지기 때문에, 모델은 확인이 반환될 때까지 조회할 내용이 없습니다.
• 문서화 및 프롬프트(Documentation and prompt). 신원 확인 관련 문서를 업데이트하고 한 교차 참조를 수정하여 새로운 흐름을 설명했으며, 프롬프트의 첫 번째 규칙도 이에 맞게 조정했습니다.

첫 번째 변경 사항은 표준 수정과 마찬가지로 데이터 노출을 막습니다. 다음 두 가지는 더 나아가서 올바른 순서만을 가능하게 만듭니다.

결과를 검토하기

다음으로 각 수정된 어시스턴트가 동일한 183개의 대화를 처리하도록 했습니다. three.dev는 변경 후에도 동일한 실패 모드에 대해 응답 점수를 매겼으며, 이를 통해 수정한 부분이 효과적이었는지 그리고 다른 부분은 어떻게 변화했는지 확인할 수 있었습니다. 모든 응답은 세 가지 버전(기준선(baseline), 표준 수정본(standard fix), three.dev 수정본(three.dev fix))에서 점수가 매겨졌습니다. 표는 각 실패 모드별 응답의 비율을 보여줍니다.