에이전트 테스트는 실제 트래픽(Real traffic) 하에서의 실패로부터 시작되어야 합니다.

팀들은 에이전트를 테스트하기 위해 트레이스(Trace) 내의 정확한 실패 상황을 재실행하기를 원합니다. 스크린샷이나 대시보드 페이지, 혹은 "지켜보자"라고 동의하는 사람들의 Slack 스레드가 아니라, 하나의 테스트 케이스(Test case)가 필요합니다.

그것이 바로 AI 에이전트 테스트가 나아가고 있는 방향입니다. 유용한 학습 단위는 더 이상 금요일 오후의 벤치마크 점수(Benchmark score)가 아닙니다. 그것은 실제 실행에서 얻은 트레이스(Trace)이며, 검증기(Verifier)로 변환되어 팀이 소유하고 릴리스 경로(Release path)에 연결된 것입니다.

AI 에이전트 테스트에서 신비주의가 더 이상 사라지지는 않을 것으로 보이지만, LangChain이 Eval Engineering Skill을 출시하며 보여준 흥미로운 단계는 워크플로우(Workflow)가 이제 리포지토리(Repo)를 읽고, 에이전트 출력(Agent output)을 검사하며, 트레이스(Traces)를 읽고, 작업을 수행한 사람을 인터뷰하여 Harbor 평가(Evals)를 생성한다는 점입니다. 에이전트는 품질에 대한 의견을 생성하는 것이 아닙니다. 시스템이 실행할 수 있는 태스크(Task)를 생성하는 것입니다. 흥미로운 점은 에이전트가 더 이상 작업만 수행하는 것이 아니라는 점입니다. 에이전트는 다음 작업을 실행할 엔진을 개선하는 데 도움을 줍니다.

저는 몇 달 전에 이렇게 썼습니다: 실제 에이전트 동작에서 수집된 트레이스(Traces collected from live agent behavior)는 개인이 관찰된 실패로부터 하네스(Harness)의 변경까지 루프를 닫을 때에만 하네스 재작성을 위한 기반이 됩니다. 이는 단순히 트레이스(Trace)를 저장하는 것, 즉 이상한 에이전트 동작을 모아놓은 예쁜 박물관과는 근본적으로 다릅니다. 테스트 스위트(Test suite)로서는 끔찍하지만, 관람용 쇼로서는 좋습니다.

점수는 취약한 소유자입니다

에이전트에 대한 평가는 너무 많은 감정적 무게를 담아왔습니다. 모델 점수와 인간 점수(평가 용어로 "판사(Judge)")가 정의상 얻게 되는 단순한 숫자가 있습니다. 여기에 여기저기 몇 점씩 점수가 변하는 벤치마크 스위트(Benchmark suite)를 덧붙이면, 모두가 그 점수가 실제 트래픽 하에서 에이전트가 실제로 어떻게 행동할지와 단순한 방식으로 일치하는 것처럼 가장합니다.

그렇지 않습니다.

실제 트래픽 하에서의 실패에는 이름이 있습니다: 에이전트가 잘못된 도구 (tool)를 선택했습니다. 리트리버 (retriever)가 에이전트에게 오래된 정책 텍스트를 반환했습니다. 서브에이전트 (subagent)가 오류를 잘못 측정했습니다. 워크플로우 (workflow)가 필수적인 인간 참여 (human in the loop)를 포함하는 데 실패했습니다. 에이전트가 타임아웃 (timeout) 이후에 쓰기를 시도했고, 그 결과 쓰기의 부수 효과 (side effect)가 중복되었습니다.

에이전트의 성능 지표 (performance metric)는 벤치마크 (benchmark) 설정에서는 개선될 수 있지만, 실제 트래픽 (live traffic) 상황은 여전히 혼란스러울 수 있습니다. 반대로, 점수만으로는 무엇이 고장 났는지 알 수 없습니다. 트레이스 (trace)는 무엇이 왜 실패하고 있는지를 말해줍니다.

이러한 차이는 중요합니다. 왜냐하면 책임 소재 (ownership)는 실패 모드 (failure mode)에서 시작되기 때문입니다. 예를 들어, LangChain의 IssueBench 기술 문서는 Engine이 트레이스 배치를 처리한 다음, 정상 실행 (clean runs)과 문제 실행 (issue runs)을 분리하고, 각각을 카테고리별로 분류하여 관련 트레이스를 열려 있는 이슈 (open issues)에 첨부하거나 새로 감지된 실패에 대해 새로운 이슈 카드 (issue cards)를 생성하는 과정을 설명합니다. 이런 방식으로 Engine 입력값 (traces)의 주요 기능은 사용 가능한 엔지니어링 작업 스트림으로 전환됩니다.

이것이 에이전트 엔지니어링 (agentic engineering)을 위한 더 건강한 방향입니다. 산출물 (artifact)은 라우팅 (route)되어야 합니다. 환각 (hallucination), 조용한 도구 오류 (silent tool error), 누락된 기능 (missing feature), 잘못된 복구 경로 (bad recovery path)는 각각 서로 다른 담당자에게 속합니다. 만약 평가 (eval)가 이를 보존하지 못한다면, 팀은 작업 대신 소음 (noise)만을 떠안게 될 것입니다.

에이전트 실패는 티켓을 생성해야 합니다 (Agent Failures Should Open Tickets)에서 우리는 이 규칙의 티켓팅 버전을 작성했습니다: 반복되는 라이브 시스템 실패는 소유권이 있는 작업이 되어야 한다는 것입니다. 즉, 트레이스 (trace) + 가설 (hypothesis) + 회귀 테스트 (regression check)입니다. 새로운 점은 티켓이 실패에 의해 생성된 실행 가능한 평가 (executable eval)를 가리켜야 한다는 것입니다.

평가는 리포지토리 객체입니다

"평가 (eval)"라는 용어는 여전히 스프레드시트 (예: 대차대조표), 프롬프트 (예: 토론 프롬프트), 심사 설정 (예: Harbor 작업에 대한 평가 설정) 등을 의미하는 데 널리 사용됩니다. 따라서 이 모든 것이 상당히 모호하고 막연하게 느껴질 수 있습니다.

Harbor 아티팩트 (artifacts)에 대해 명심해야 할 핵심적인 차이점은 그것들이 지루한 형태를 띠고 있다는 점입니다. 공식 Harbor 작업 문서 (Harbor task documentation)는 instruction.md, task.toml, 컨테이너 환경 (container environment), 솔루션 파일 (solution files), 그리고 테스트 (tests)를 포함하는 작업 디렉토리를 설명합니다. Harbor 핵심 개념 문서 (core concepts documentation for Harbor)에서도 대략적으로 동일한 내용, 즉 지침 (instruction), 컨테이너 환경 (container environment), 그리고 테스트 스크립트 (test script)를 언급하고 있습니다.

의미 있는 에이전트 실패 (agent failure)는 다음과 같은 구체적인 요소로 변환되어야 합니다: 실패를 재현하기 위한 지침 (instruction), 실패가 발생한 환경 (environment), 에이전트가 가졌던 도구 (tools)와 제약 사항 (constraints), 피스처 (fixture) 또는 트레이스 링크 (trace link), 검증기 (verifier), 그리고 테스트를 통과시키기 위해 어떤 변경이 허용될지 결정하는 소유자 (owner)입니다.

Flow diagram showing a live trace becoming a failure cluster, an owned issue, a Harbor eval, a harness change, a rerun, and a release gate.

트레이스 (trace)는 그것이 전달 루프 (delivery loop) 내에서 실행 가능한 아티팩트 (executable artifact)가 될 때 중요해집니다.

이 지점이 바로 주요 AI 에이전트 워크플로 (ai agent workflow) 논의가 구체화되어야 하는 부분이며, 그 구체적인 내용은 다음과 같습니다: 소프트 경로 (soft path; 에이전트 실행, 에이전트 답변, 팀이 웹 UI의 대시보드 관찰) 대 유용한 경로 (useful path; 라이브 트레이스가 실패 클러스터 (failure cluster)로 변하고, 이것이 소유된 이슈 (owned issue)로, 다시 Harbor 평가 (Harbor eval)로, 다시 하네스 변경 (harness change)으로, 다시 재실행 (rerun)으로, 최종적으로 릴리스 게이트 (release gate)로 이어지는 과정).

벤치마크는 하네스 (harness)를 변경해야 합니다

Deep Agents 팀도 벤치마크를 유사하게 다루고 있습니다. Deep Agents를 벤치마킹하는 방법 (How We Benchmark Deep Agents)에서 LangChain은 더 오래 실행되는 작업에 대해 엔드 투 엔드 (end-to-end) Harbor 평가 (evals)로 나아가는 과정을 설명하며, 그 결과를 사용하여 todo-list 미들웨어 (middleware)를 제거하거나 시스템 프롬프트 (system prompt)를 축소하는 것과 같은 하네스 조정 (harness tweaks)에 반영한다고 기술합니다.

그것이 적절한 추상화 수준입니다. 평가(evaluation)가 모델 리더보드를 장식하는 용도가 아니라, 평가가 하네스를 조종하도록 하기 위해 평가가 존재하는 것입니다.

이 지점이 바로 "AI 에이전트 워크플로우 자동화 (ai agent workflow automation)"라는 용어를 사용하기 까다로워지는 부분입니다. 자동화라는 단어는 더 많은 것들이 자동으로 실행되는 이미지를 떠올리게 합니다. 하지만 실제로는 피드백 루프 (feedback loop)를 자동화하는 것입니다 (에이전트 실패 $\rightarrow$ 트레이스 (trace) 획득 $\rightarrow$ 평가 실패 $\rightarrow$ 메인에서 수정 (프롬프트, 도구, 라우팅, 컨텍스트, 미들웨어, 모델 선택 등에 대한 패치 등) $\rightarrow$ 그리고 빌드를 통해 수정 사항이 유지되었음을 증명).

Deep Agents는 하네스 (harness) 자체가 제품의 표면이기 때문에 유용한 예시입니다. 할 일 목록 (todo-list) 미들웨어는 평가를 통해 그것이 최신 모델의 주의를 분산시키거나 컨텍스트 (context)를 소모한다는 사실이 드러나기 전까지는 무해해 보입니다. 더 긴 시스템 프롬프트 (system prompt)는 벤치마크를 통해 그것이 작업 지침을 밀어낸다는 사실이 드러나기 전까지는 안전해 보입니다. 최종 답변만 확인하는 검증기 (verifier)는 트레이스를 통해 에이전트가 필수 도구를 건너뛰었다는 사실이 드러나기 전까지는 괜찮아 보입니다.

릴리스 후에도 평가를 계속 실행해야 하는 이유는, 릴리스 전 평가에 사용된 데이터는 팀이 인코딩(encode)하는 것을 기억해낸 것들만 잡아내기 때문입니다. 반면 라이브 평가(live evaluation)의 트레이스는 사용자와 도구, 권한, 그리고 기이한 상태 전이 (state transitions)가 계획이 현실에 부딪힌 후 어떤 영향을 미치는지 잡아냅니다. 짜증 나는 일이지만, 그것이 우리가 할 일입니다.

루프에 상태(state)가 있을 때 그래프가 도움이 됩니다

하지만 테스트의 경우, 그래프 형태의 에이전트 시스템은 이야기를 따라가기 더 쉽게 만듭니다. LangChain의 그래프 엔지니어링 에세이는 LangGraph를 결정론적 경로 (deterministic paths)와 에이전트적 단계 (agentic steps)의 혼합으로 설명하며, 작업(work)을 위한 노드 (nodes)와 다음에 일어날 일을 위한 엣지 (edges)로 구성된다고 기술합니다. LangGraph Graph API는 그래프 상태 (graph state)로부터 라우팅되는 조건부 엣지 (conditional edges)와 런타임 (runtime)에만 알 수 있는 작업을 확산시키는 Send를 보여줍니다.

그것이 중요한 이유는 에이전트의 실패가 전이 (transitions) 과정 전반에서 발생하기 때문입니다. 에이전트가 첫 번째 단계는 올바르게 수행했지만, 그 다음 잘못된 것을 재시도할 수 있습니다. 올바른 문서를 찾았지만 잘못된 전문가에게 보낼 수도 있습니다. 형제 브랜치 (sibling branch)가 계속 작성하는 동안 승인을 요청할 수도 있습니다. 혹은 도구 오류 (tool error)로부터 복구하는 과정에서 원래의 의도를 잃어버릴 수도 있습니다.

단순한 최종 답변 평가 (flat final-answer eval)는 이러한 점을 포착하지 못합니다. 트레이스 (trace)와 연결된 작업은 에이전트가 거친 전이를 단언 (assert)할 수 있으며, 검증기 (verifier)는 생성된 결과물 (artifact), 이슈 카테고리, 승인 상태, 부작용 (side effect)의 부재, 또는 경로 형태 (route shape)를 확인할 수 있습니다. 이것이 실제 트래픽 환경에서 에이전트 기반 AI 워크플로우 (agentic AI workflows)가 깨지는 방식에 더 가깝습니다.

Anatomy diagram of an agent eval artifact with instruction, task config, environment, verifier tests, trace fixture, expected result, owner, and release gate.

평가 (eval)가 파일, 피스처 (fixtures), 검증기 (verifier), 그리고 소유자 (owner)를 갖출 때 비로소 유용해집니다.

평가 결과물 (eval artifact)에 기록할 가치가 있는 실패가 있는 반면, 나중에 처리해도 되는 실패도 있습니다. 경험 법칙 (rule of thumb)은 고객의 신뢰를 저해하는 실패, 동일한 근본 원인 (root cause)으로 재발하는 실패, 그리고 수정 후에도 팀원들 간에 논쟁이 발생하는 실패를 포착하는 것입니다. 그 외의 모든 것은 아마도 분류 (triage) 단계에 머물러 있어도 괜찮을 것입니다.

승인은 워크플로우의 일부입니다

GitHub의 새로운 이슈 자동화 제어 기능은 우리에게 좋은 인접 신호 (adjacent signal)가 됩니다. GitHub은 최근 Issues에서의 에이전트 자동화에 대한 퍼블릭 프리뷰 (public preview)를 공개했습니다. 이 프리뷰에서는 이슈 UI가 레이블 할당, 필드 할당, 이슈 유형 변경, 종료 및 할당에 대한 근거 (rationale)를 보여줍니다. 중요한 점은, 이러한 모든 승인 패널과 관련 자동화는 단지 워크플로우의 편의를 위한 것이며, 서버 측 보안 제어 (server-side security controls)와는 매핑되지 않는다는 것입니다.

릴리스 게이트(release gate)는 UI가 제안하는 것이 아니라, 시스템이 강제하는 것을 테스트해야 합니다. 만약 승인 패널(approval panel)이 레이블 제안(label suggestion)을 보유하고 있다면, 에이전트가 변경 사항을 직접 적용하는 것과 제안 경로를 따르는 것을 비교하여 테스트하십시오. 권한 경계(permission boundary)를 테스트하십시오. 워크플로우에서 거절(rejection)이 부작용(side effects)이 없음을 의미한다면, 부작용 경계(side-effect boundary)를 테스트하십시오.

따라서 릴리스 여부를 결정하는 질문은, 이전에 실패했던 것과 동일한 상황에서 트레이스(trace), 아티팩트(artifact), 그리고 검증기(verifier)가 제대로 작동했는가 하는 점입니다.

이것이 바로 느낌(vibes)은 평가 전략이 될 수 없는 이유입니다. 사람은 데모를 좋아할 수 있습니다. 대시보드가 멋져 보이고 트렌드가 상승할 수도 있습니다. 평가자(judge)가 최종 답변을 마음에 들어 할 수도 있습니다. 하지만 빌드에는 여전히 특정한 실패 사례(failing case)가 필요하며, 해당 실패 모드(failure mode)가 사라졌을 때 반드시 통과(green) 상태가 되어야 합니다.

루프를 소유하라 (Own the loop)

AI는 단순히 더 큰 엔지니어링 시스템 내의 또 다른 구성 요소일 뿐입니다. Honeycomb의 CTO가 최근 고객들에게 보낸 서신에서 작성했듯이, AI는 존재하는 엔지니어링 시스템을 증폭시킵니다. 좋은 관행은 증폭되고, 나쁜 관행도 증폭됩니다. AI가 인도(delivery) 과정에 들어올 때 엔지니어링의 엄격함(rigor)은 줄어드는 것이 아니라 더욱 중요해집니다.

건강한 인도 시스템을 갖춘 팀은 트레이스를 평가(evals)로 전환할 것입니다 (왜냐하면 조직이 이미 그렇게 생각하기 때문입니다: 트레이스 == 평가). 실패는 테스트를 만듭니다. 테스트는 변경 사항을 보호합니다. 변경 사항은 게이트(gates) 뒤에서 배포됩니다. 게이트는 증거를 생성합니다.

이러한 근력을 갖추지 못한 팀은 단순히 더 나은 대시보드를 원할 뿐입니다. 그들은 때때로 흥미로운 트레이스를 지목하고, 여기저기 카테고리 이름을 바꾸며, 프롬프트(prompt)에 한두 문장을 추가할 것입니다. 그리고 당연하게도, 동일한 실패가 새로운 이름으로, 새로운 슬라이드 덱이나 새로운 Slack 스레드에 차려입고 다시 나타날 것입니다.

엔지니어링 측면에서의 이점은 모든 심각한 에이전트 실패를 빌드 기회 (build opportunity)로 취급하는 것입니다. 트레이스 (trace)를 채굴하십시오. 실패에 이름을 붙이십시오. Harbor 태스크를 생성하십시오. 담당자를 지정하십시오. 릴리스를 차단 (gate)하십시오. 그런 다음 릴리스 프로세스를 사용하여 수정 사항이 유지되었다는 증거를 생성하십시오.

그러면 에이전트 워크플로 (agent workflow)는 단순히 살아남으려고 애써야 하는 대상이 아니라, 실제 트래픽 (real traffic)으로부터 학습하게 됩니다.