에이전트 실패는 티켓을 생성해야 합니다 | Focused Labs

에이전트 트레이스(Agent traces)는 업무(work)를 생성해야 합니다. AI 에이전트 워크플로(workflow)는 두 번 실패할 수 있습니다. 따라서 만약 두 번 실패한다면, 담당자와 연결된 증거가 포함된 티켓을 생성해야 하며, 이를 통해 팀이 나중에 회귀(regression) 여부를 확인할 수 있어야 합니다. 대신, AI의 프로세스를 추적(tracing)하고 출력을 검토하는 것은 보기 좋고 검색 가능할 수는 있지만, 실수의 연속을 반복해서 재생하는 것 외에는 본질적으로 아무런 가치가 없을 수 있습니다. 저는 이것을 "재생 가능한 후회(replayable regret)"라고 부르기 시작했는데, 이는 비용이 많이 들고 지켜보기에 고통스럽습니다. 이번 주 LangChain은 도구(tooling)의 결정적인 격차를 확인했습니다. AI 에이전트 작업의 트레이스는 추적 및 검토가 가능하지만, 오류 식별과 그에 따른 병합된 수정(merged fix)은 여전히 수동적이고 느립니다. Harrison Chase 또한 이번 주에 이 점을 지적하며, LangChain이 "이슈 벤치(issue bench)"를 구축하고 있으며 이미 내부적으로 사용 중이지만, 이러한 종류의 도구로는 아직 초기 단계라고 언급했습니다. 이 문구가 중요한 이유는 업무의 단위가 변하기 때문입니다. 트레이스는 실패 후 모두가 응시하는 결과물(artifact)이 아니게 됩니다. 반복되는 실패가 팀이 개선해 나가야 할 결과물이 됩니다.

트레이스는 Slack에서 사장되어서는 안 됩니다. 일반적인 실패 루프는 상당히 어리석습니다. 일반적인 실패 루프를 처리하기 위한 1단계는 다음과 같습니다: 워크플로에서 에이전트가 실패하면, 누군가 해당 작업 항목의 트레이스를 열고, 팀은 트레이스 단계에서 실패를 확인할 수 있습니다. 도구 호출(tool call)이 시간 초과되었습니다. 플래너(planner)가 이상한 분기를 선택했습니다. 검색(Retrieval)이 오래된 컨텍스트를 가져왔습니다. 평가기(evaluator)가 작동했습니다. 사용자가 부정적인 피드백을 남겼습니다. 이 모든 과정은 트레이스 링크가 Slack에 추가되고 그 위에 "흥미롭네(interesting)"라는 말 한마디가 붙는 순간 무너집니다. 한 마디로, 그것은 업무가 아니라 느낌(vibes)일 뿐입니다. 트레이스는 좋습니다! 저는 최근에 왜 에이전트 워크플로의 트레이스가 MCP 경계를 넘어야 하는지에 대해 글을 쓴 적이 있습니다. 그리고 트레이스를 가시화하는 것이 여기에서의 업무 중 절반입니다. 트레이스는 가시성을 통해 "이런 일이 일어났다"라고 말해주기 때문에 좋습니다. 하지만 그 트레이스, 혹은 트레이스 세트는 또한 "이러한 실패 유형(failure family)은 담당자가 지정되었고, 수정되었으며, 테스트가 완료되었고, 재발이 차단되었다"라고 말할 수 있어야 합니다.

그 두 번째 절반이 바로 사람들이 계속해서 건너뛰고 있는 AI 에이전트 워크플로 (AI agent workflow)입니다. 최근 Engine 스레드에서 LangChain 팀은 AI 에이전트 워크플로에 들어가는 적절한 입력값들을 식별했습니다: 도구 호출 실패 (tool call failures) 및 타임아웃 (timeouts), 온라인 평가 (online eval) 실패, 트레이스 이상 (trace anomalies), 부정적 피드백 (negative feedback), 그리고 비정상적인 동작 (unusual behavior)입니다. 오늘날 이러한 입력값들은 대시보드 위젯으로서 관찰해야 할 흥미로운 패턴으로 취급됩니다. 대신, 이들은 작업 큐 (queue of work)를 위한 신호로 취급되어야 하며, 각 신호는 심각도 (severity), 연결된 트레이스 (linked traces), 의심되는 경계 (suspected boundary), 그리고 릴리스 조건 (release condition)을 가진 명명된 이슈 (named issue)가 될 자격이 있어야 합니다. 트레이스 (trace)는 증거입니다. 이슈 루프 (issue loop)는 이를 엔지니어링 작업으로 전환합니다. 바람직한 버전은 매우 직관적이고 기계적입니다: 트레이스 이상이 이슈로 전환되고, 새로운 트레이스들이 그와 함께 클러스터링 (clustered)되며, 담당자가 지정됩니다. 지정된 담당자는 변경 사항을 만들고, 이는 결과적으로 새로운 평가기 (evaluator)를 추가하거나 기존의 것을 업데이트합니다. 변경 사항은 특정 릴리스 게이트 (release gate)를 통해 배포되며, 이는 다시 해당 새로운 평가기를 실행합니다. 만약 회귀 (regressions)가 발생한다면, 해당 이슈는 다시 오픈됩니다. 격식은 필요 없습니다. 그저 루프 (loop)일 뿐입니다. 티켓에는 형태가 필요합니다. 에이전트 이슈는 제목에 "LLM 불안정 (LLM flaky)"라고 적힌 Jira 카드 같은 것이 아닙니다. 그런 카드는 (적어도 도덕적으로) 금지되어야 합니다. 이슈는 프로덕션 결함 (production defect)과 동일한 명확한 경계 (hard edges)를 가져야 합니다.

에이전트 이슈는 프로덕션 결함 (production defect) 이슈와 동일한 특성을 가져야 합니다:

실패 명칭 (Failure name): “정책 확인 전 환불 흐름이 결제 API를 호출함"
워크플로우 (Workflow): 환불, 플랜 업그레이드, 인시던트 트리아지 (incident triage), 리서치 합성 (research synthesis)
심각도 (Severity): 고객 영향, 데이터 리스크, 재무 리스크, 운영 저해 (operational drag)
증거 (Evidence): 연결된 트레이스 (traces), 실패한 평가 실행 (failed eval runs), 사용자 피드백, 도구 응답
경계 (Boundary): 프롬프트 (prompt), 도구 계약 (tool contract), 컨텍스트 소스 (context source), 모델 경로 (model route), 권한 (permission), 다운스트림 API (downstream API)
소유자 (Owner): 팀 또는 서비스 소유자, “AI”가 아님
수정 상태 (Fix status): 제안됨 (proposed), 병합됨 (merged), 되돌려짐 (reverted), 차단됨 (blocked)
회귀 테스트 커버리지 (Regression coverage): 벤치마크 평가 (benchmark eval), 커버리지 평가 (coverage eval), 릴리스 게이트 (release gate)
재오픈 규칙 (Reopen rule): 이슈를 다시 열고 큐 (queue)에 다시 넣게 만드는 정확한 신호

에이전트 실패는 입력값, 테스트 중인 브랜치, 그리고 에이전트가 실패하기 전에 사용한 도구에 따라 다르게 나타나기 때문에 테스트하기 어렵습니다. 이슈 명칭이 없다면, 모든 실패 트레이스는 프로덕션 테스트가 제거해야 할 '실패군 내의 또 다른 데이터 포인트'가 되는 대신, 디버깅해야 할 새로운 이슈가 되어버립니다. 만약 LangSmith Engine이 issue.created 및 issue.trace.added 이벤트를 방출한다면, 안정적인 이벤트 ID를 통해 중복 제거 (dedupe)를 처리할 수 있고, 심각도 (severity)를 이벤트와 함께 전달할 수 있으며, 공유된 요청 ID (request ID)를 통해 동일한 상위 액션에서 발생한 전달 사항들을 그룹화할 수 있습니다. 이것이 필요한 전부입니다. 종교적인 접근은 필요 없습니다. 기존의 웹훅 (webhook) 형태를 사용하여 실패 사례를 큐, 보드, 그리고 CI 작업으로 가져오십시오. 지루한 웹훅 핸들러 (webhook handler)는 다음 네 가지를 수행해야 합니다:

1. 이벤트 ID를 기준으로 중복 제거 (Dedupe).
2. 요청 ID를 기준으로 관련 전달 사항을 그룹화.
3. 클러스터가 이미 존재하는 경우, 기존 이슈에 트레이스 증거를 첨부.
4. 적절한 이유에 대해 적절한 소유자 워크플로우를 트리거 (즉, 심각도와 재발 빈도가 해당 워크플로우의 비용을 정당화해야 함).

이것은 작은 작업입니다. 또한 에이전트 품질 작업이 화요일에 허무하게 사라지는 것을 방지하는 방법이기도 합니다.

벤치마크는 동일한 문제를 가리키고 있습니다.
장기적 관점의 에이전트 (Long-horizon agent) 작업은 엔지니어링 작업과 유사한 방식으로 실패합니다.

단 하나의 잘못된 결과가 아니라, 시간이 흐르면서 서서히 스며드는 일련의 작은 오류들이 발생하여 최종 결과물이 유용하지 못한 상태가 됩니다. RoadmapBench는 장기적 소프트웨어 개발 작업 (Long-horizon software development tasks)을 평가하기 위해 존재하며, 17개의 리포지토리 (Repositories)와 5개의 언어에 걸쳐 115개의 작업으로 구성되어 있습니다. 수정된 작업의 중앙값은 51개 파일에 걸쳐 3,700줄의 코드를 수정하는 것이었습니다. 이 정도 규모의 작업에서 가장 뛰어난 모델은 그중 39.1%를 해결했습니다. 유용한 분석은 생성된 계획 (Plan)이 어디서 잘못되었는지, 작업 내의 어떤 파일이 더 위험해졌는지, 그리고 어떤 요구사항이 고립되었는지(orphaned)를 파악하는 것입니다. LongCLI-Bench를 위한 CLI 프로젝트 파이프라인은 장기적 프로그래밍 작업에 대한 도구 성능을 비교하기 위해 동일한 방식의 점수 산정 방식을 사용합니다: 실패-통과 (fail-to-pass), 통과-통과 (pass-to-pass), 그리고 단계별 진행도 (step-level progress)입니다. 이 방식은 최첨단 (State-of-the-art) 에이전트들의 통과율이 20% 미만이라고 보고합니다. 정체 (Stalls) 측면에서 보면, 최종 작업 목표 달성에 실패하여 뒤늦게 나타나는 빨간색 X와, 도구 루프 (Tool loop), 잘못된 파일, 또는 통과-실패 회귀 (Pass-to-fail regression)를 가리키며 초기에 나타나는 빨간색 X 사이에는 큰 차이가 있습니다. 하드웨어 작업에 대한 파일 수준 동작의 오라클 (Oracle) 위치를 찾는 Phoenix-bench는 해결률을 단 1.4%만 높였습니다. 테스트벤치 (Testbench) 로그로부터 얻은 단 한 번의 피드백 라운드는 해결률을 42%에서 45%로 증가시켰습니다. 인간이 장기적 프로그래밍 작업을 개선할 수 있도록 적절한 일반 영역을 짚어주는 것은 제한적인 가치만을 가진다는 것이 밝혀졌습니다. 대신 고려 중인 작업을 실제로 개선할 수 있는 실행 가능한 피드백 (Actionable feedback)을 제공하는 것이 가치 있습니다. 이것이 바로 벤치마크의 탈을 쓴 '이슈 루프 (Issue-loop)' 논쟁입니다. AI 에이전트를 더 잘 테스트하려면 단순한 테스트 스위트 (Test suite) 이상의 것이 필요합니다. 문제를 노출하고, 수정할 수 있게 하며, 동일한 워크플로 내에서 수정을 검증할 수 있는 워크플로가 필요합니다. 평가 스위트 (Eval suite)는 해결된 이슈들로부터 성장해야 합니다. 종료된 이슈 (Closed issues)는 테스트 스위트로 유입되어야 합니다. LangSmith는 평가자 (Evaluators)를 동일한 워크스페이스 내의 트레이싱 (Tracing) 프로젝트 및 데이터 세트에 연결할 수 있는 워크스페이스 수준의 리소스로 설명합니다.

Engine은 커스텀 평가기 (Custom Evaluators)를 개발할 수 있는 탐지된 문제에 대해 이를 제안할 수 있으며, 이후 문제를 일으킨 근본 원인인 폐쇄된 클러스터 (Closed Clusters)에 대한 트레이스 증거 (Trace Evidence)로 추가할 수 있습니다. Brace Sproul이 구분한 벤치마크 평가 (Benchmark Evals)와 커버리지 평가 (Coverage Evals)의 차이가 여기에 부합합니다. 첫 번째 평가기 세트는 알려진 워크플로 (Workflows)에 대한 빠른 벤치마크용입니다. 두 번째의 더 철저한 평가기 세트는 더 긴 경로, 제품 약속 (Product Commitments), 그리고 생소한 궤적 (Trajectories)을 위한 것입니다. 두 목적 모두에 하나의 스위트 (Suite)를 사용하려고 시도하면, 평가는 아무도 내고 싶어 하지 않는 세금 (Tax)으로 변질됩니다. 해결된 이슈는 하나의 거대한 평가 덩어리 (Eval Blob)가 아니라 적절한 스위트로 전달되어야 합니다. 중요한 워크플로에서의 환불 오류와 같은 Severity-0 해결 이슈는 빠른 벤치마크로 평가되어야 합니다. 긴 다단계 (Multi-hop) 연구 워크플로에서의 드문 에지 케이스 (Edge Case)는 비용이 높고 실행 시간이 길더라도 더 광범위한 커버리지 스위트로 처리하는 것이 아마 더 나을 것입니다. Severity-0 정책 위반은 두 스위트 모두에 속할 수 있습니다. 어떻게 나누든, 이것은 작업 (Work)입니다. 모든 워크플로 변경은 시스템이 이전에 본 적 없는 실패 모드 (Failure Modes)를 도입할 수 있습니다. 수정 사항이 작동했음을 증명하는 테스트는 나중에 발생할 수 있는 회귀 (Regression)에 대해 동일한 문제를 방어하는 테스트와는 다릅니다. 그리고 게이트 (Gate)의 문제가 있습니다. 큐 (Queue)는 에이전시 (Agency)가 실질적으로 구현되는 곳입니다. 더 어려운 훈련은 에이전트가 개선되도록 개발하는 것입니다. 그것은 에이전트가 작업과 워크플로에 적용할 수 있는 능력보다 증명하기가 훨씬 더 어렵습니다. 데모하기 더 어려운 것은 에이전트에 AI 에이전시 (AI Agency)를 구축하는 것입니다. AI 에이전시를 개발하는 것은 항상 그 훈련에 관한 것이었습니다. 그것은 특정한 방식으로 나타납니다. 무언가 실패했을 때, 팀이 그다음에 무슨 일이 일어났는지 설명할 수 있는 것입니다. 실패를 디버깅하는 개발 팀을 위한 좋은 이슈 큐 (Issue Queue)는 다음 질문들에 답할 수 있어야 합니다. 팀은 단일 트레이스 (Trace)만으로는 이 모든 정보를 얻을 수 없습니다. 이 실패는 새로운 것인가, 아니면 재발하는 것인가? 어떤 워크플로의 소유인가? 어떤 트레이스들이 동일한 근본 원인을 가리키는가? 수정 사항이 반영되었는가? 이제 어떤 평가기가 이를 커버하는가? 어떤 릴리스 게이트 (Release Gate)가 회귀를 차단하는가? 이슈가 다시 발생하면 누구에게 페이지 (Paged)가 발송되는가?

다시 말하지만, 이는 일반적인 소프트웨어 개발 과정과 같으나 복잡하고 확률적이며 가변적인 경로를 통해 실패하는 워크플로우 (Workflow)로 인해 더욱 복잡해진 것입니다. 결함은 동일하지만 모습만 다를 뿐입니다. LangChain의 프로덕션 AI 에이전트 (AI Agent) 조사에 따르면, 응답자의 57.3%가 이미 프로덕션 환경에서 에이전트를 사용하고 있는 것으로 나타났습니다. 응답자들이 꼽은 첫 번째 프로덕션 차단 요소는 품질 (Quality)으로, 32%를 차지했습니다. 이는 프로덕션 에이전트에 대한 관측성 (Observability) 도입률 89%와 나란히 위치하며, 오프라인 평가 (Offline Evaluation) 52.4% 및 온라인 평가 (Online Evaluation) 37.3%를 훨씬 앞지르는 수치입니다. 프로덕션 에이전트를 위한 가시성 (Visibility)의 바다는 이미 형성되어 있습니다. 하지만 그 가시성을 해결된 품질 이슈로 전환하는 작업은 아직 겨우 시작된 단계입니다. Honeycomb의 에이전트 관측성을 위한 새로운 조사 기능들은 복잡한 멀티 에이전트 (Multi-agent), 멀티 트레이스 (Multi-trace) 워크플로우를 재구성하기 위해 구축된 Agent Timeline을 통해 동일한 문제를 해결하기 시작했습니다. 그러나 해당 경로를 특정 담당 업무와 다시 연결하고, 그 업무가 제대로 처리되는지 확인하는 것은 여전히 큰 격차로 남아 있습니다. 바로 이 지점에서 이슈 큐 (Issue Queue)가 등장합니다.

루프를 소유하라 (Own the loop)
제가 원하는 AI 에이전트 워크플로우는 화려하지 않습니다. 실패 신호 발생 -> 이슈 생성 -> 증거 추가 -> 담당자 할당 -> 수정 제안 -> 평가자 추가 -> 릴리스 게이트 (Release Gate) 실행 -> 회귀 (Regression) 재발생. 이 워크플로우는 새로운 AI 모델을 발표하는 것보다 매주 덜 흥미로워 보일 수 있습니다. 하지만 환불, 지원 티켓 (Support Tickets), 인프라 변경 또는 계정 데이터에 접근하는 에이전트를 사용하는 구매자에게는, 이것이 바로 매주 중요한 작업입니다. 지난주의 실패는 이번 주의 가드레일 (Guardrail)이 되어야 합니다. 에이전트의 실패는 티켓을 생성해야 합니다. 티켓은 트레이스 (Trace)가 업무가 되는 곳입니다. 업무는 시스템이 개선되는 곳입니다.