AI 에이전트 평가의 새로운 틀: Agent Behavior 표준이 말하는 것

왜 지금 Agent Behavior인가

오늘날 AI 에이전트는 수백 번의 판단을 거쳐 장시간 실행되는 경우가 많아졌어요. 그런데 기존 평가 방식은 최종 결과 하나로 성패를 가르는 경우가 대부분이라, 어떤 경로로 그 결과에 도달했는지, 중간에 잘못된 판단은 없었는지, 오류가 나면 어떻게 복구했는지를 알기 어려웠어요. Agent Behavior는 이 ‘과정’ 자체를 평가 대상으로 만드는 표준 포맷이에요.

배경: 결과 중심 평가의 한계

기존 harness와 eval이 잘 작동하던 영역은 단일 작업의 정확성 비교까지예요. 하지만 세금 조사, 재무 결과 검증, 고객 지원 분류처럼 여러 단계가 이어지고 실패 복구가 필요한 작업에서는, 최종 점수만 높아도 위험한 경로를 거쳤을 수 있어요. 반대로 결과는 평범해도 문제 상황을 잘 관리한 실행일 수 있죠.

실제로 운영 중인 agentic 시스템을 떠올려보세요. 사용자가 내린 요청이 A라는 결과로 끝났을 때, 그 사이에 잘못된 정보를 참고했거나, 불필요한 도구 호출이 반복되거나, 실패한 단계를 건너뛴 경우가 있을 수 있어요. 이런 정보는 단일 스코어에는 담기지 않아서, 모델을 업그레이드해도 같은 잘못을 반복하기 쉬워요.

핵심 구조: BEHAVIOR.md

Agent Behavior의 핵심은 .agents/behaviors/<name>/BEHAVIOR.md 파일 하나로, 이름·설명·Markdown 본문으로 구성돼요. 본문은 Intent, Evidence, Decision, Execution, Recovery, Failure modes라는 여섯 가지 선택 라벨로 쓰도록 제안해요. 강제 형식이 적어서 팀 상황에 맞게 자유롭게 확장할 수 있지만, 여러 작업에 공통으로 적용해야 할 행동을 먼저 정의하는 게 목표예요.

예를 들어 비용이 드는 작업 전 확인을 위한 행동 스펙이라면, “가격 비교를 위해 어떤 소스를 확인해야 하는지”, “재고 부족 시 어떤 경로로 재확인할지”, “환불 조건이 다를 때 어떻게 복구할지”를 BEHAVIOR.md에 적어둘 수 있어요. README는 스펙을 에이전트가 반복해서 보여야 할 행동을 적어 둔 기록으로 설명해요. 제 해석으로는 시스템 프롬프트나 스킬은 행동을 구현하는 쪽이고, eval은 그 행동이 나타났는지 측정하는 쪽이며, 트레이스는 실제로 한 일의 기록이에요. Agent Behavior는 그 사이에서 ‘무엇을 좋은 행동으로 볼 것인가’ 를 정의하는 계층으로 읽혀요.

평가와의 관계

가장 큰 특징은 특정 스코어러나 평가 방식을 강제하지 않는 점이에요. 사람이 트레이스를 직접 리뷰하거나, 루브릭으로 채점하거나, 자동 eval을 돌려도 같은 BEHAVIOR.md를 기준으로 삼을 수 있어요. README에서 확인되는 CLI 명령은 agentbehavior validate 하나로, 구조를 검증하는 용도예요. 내용의 품질은 사람이나 별도 모델이 판단해야 한다고 저는 읽었어요.

README의 실행 예제는 기록된 트레이스에 true/false/na 판정 방식을 적용해요. 다만 이것을 유일한 채점 방식으로 고정한다는 설명은 보지 못했어요. 사람이 리뷰하거나 루브릭 평가와 결합하는 건 제 생각이에요. 즉 포맷은 같아도 평가 정책은 팀마다 다르게 적용할 수 있다는 뜻이에요.

실무에서의 활용 시점

이 표준은 매 실행마다 프롬프트에 불러넣는 구조가 아니에요. README는 트레이스 검토와 eval 설계를 위한 "단일한 문서화된 기준"으로 쓰는 용도를 말해요. 예시로는 validate-rendered-deck과 primary-source-tax-research가 나와요. 이 표준을 운영 규정으로 쓸 수 있다는 건 제 해석이에요.

운영 환경에서 이 표준을 도입하려면, 우선 반복적으로 쓰이는 핵심 행동 몇 가지부터 BEHAVIOR.md로 작성하는 게 좋아요. 모든 행동을 한 번에 문서화하려다 보면 유지보수 비용만 커지기 쉽거든요. 가장 자주 실패하거나, 사람이 매번 확인해야 하는 구간부터 시작하는 게 실용적이에요.

BEHAVIOR.md를 직접 써 본다면

README의 대표 예시는 validate-rendered-deck이라는 스펙이에요. 이름과 설명을 프런트매터에 두고, 본문에 "배포 전에 현재 덱을 이미지로 렌더링해 눈으로 점검하고, 고친 뒤 다시 확인한다"는 취지의 지침을 적어요. 아래는 그 형식을 바탕으로 제가 만든 가상의 예시예요. 공식 저장소에 있는 스펙이 아니고, 본문 섹션 이름은 README가 제안하는 여섯 가지 라벨을 그대로 가져왔어요.

---
name: verify-price-before-quote
description: 고객에게 가격을 안내하기 전에 1차 출처로 가격을 다시 확인한다.
---

## Intent
고객에게 안내하는 가격이 현재 판매처의 가격과 일치해야 한다.

## Evidence
판매처 상품 페이지 또는 공식 가격 API의 조회 결과. 캐시된 이전 응답은 근거로 쓰지 않는다.

## Decision
조회 결과가 안내하려는 가격과 다르면 안내를 멈추고 차이를 먼저 알린다.

## Recovery
조회에 실패하면 재시도 후에도 확인이 안 될 때 "확인하지 못했다"고 답한다.

## Failure modes
이전 대화에서 본 가격을 그대로 반복한다. 조회 실패를 가격 변동 없음으로 처리한다.

이 형식의 장점은 평가자가 트레이스에서 확인할 대상이 명확해진다는 점이에요. 예컨대 "이 대화에서 에이전트가 가격을 말하기 전에 판매처를 조회했는가"는 true/false/na로 판정하기 쉬워요. 반면 "답변이 도움이 됐는가" 같은 질문은 이 구조로는 판정하기 어려워요. 좋은 BEHAVIOR.md는 트레이스에서 관찰 가능한 행동만 적어야 쓸모가 있다는 뜻이에요.

시스템 프롬프트와 겹치지 않으려면

읽으면서 가장 궁금한 건 이 문서가 시스템 프롬프트와 어떻게 다르냐는 점이에요. 제 해석으로는 시스템 프롬프트는 행동을 구현하는 쪽이고, BEHAVIOR.md는 그 행동이 일어났는지 판정하는 기준이에요. 실제로는 같은 문장을 양쪽에 복사해 두기 쉬워요. 그러면 프롬프트를 고칠 때 스펙이 따라가지 않아서 평가 기준이 어긋나요. 스펙에는 "무엇을 하라"보다 "어떤 증거가 남아야 하는가"를 쓰고, 프롬프트에는 방법을 쓰는 식으로 역할을 나누는 게 이 표준을 살리는 쪽이에요(이 부분은 제 권고이고 저장소에서 확인한 지침은 아니에요).

또 하나는 판정 비용이에요. true/false/na를 사람이 아니라 모델이 매기면 판정 모델의 오류가 스펙 위반 판정에 섞여요. validate는 구조 검증이라서, 스펙의 문장이 모호한지까지는 판단하지 못한다고 보는 게 안전해요. 스펙 수가 늘수록 "이 스펙은 정말 판정 가능한가"를 따로 점검하는 단계가 필요해요.

제한과 보완점

Agent Behavior는 행동의 문서화와 평가 기준까지만 다루고, 실제 실행 환경이나 보안 샌드박스는 다루지 않아요. 평가 방법도 ‘true/false/na’ 판정 예시를 보여줄 뿐, 모든 평가를 이 방식으로 고정하라고 주장하는 건 아니에요. 실무에 도입하려면 팀이 자체 평가 정책과 함께 사용해야 의미가 생겨요.

추가로 생각해볼 점은, 행동 스펙 자체가 오래되면 오히려 모델의 변화를 따라가지 못하는 문제예요. 그래서 정기적으로 트레이스와 비교해 스펙을 갱신하는 워크플로우가 필요해요. 갱신 주기를 어떻게 잡을지는 팀이 정해야 해요. validate는 형식 유지에만 도움이 되고, 내용이 낡았는지는 알려주지 않아요.

참고 링크

• Agent Behavior 공식 저장소
• GeekNews 원문 보기