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

왜 지금 Agent Behavior인가

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

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

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

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

핵심 구조: BEHAVIOR.md

Agent Behavior의 핵심은 .agents/behaviors/<name>/BEHAVIOR.md 파일 하나로, 이름·설명·Markdown 본문으로 구성돼요. 본문은 의도, 확인할 증거, 판단 기준, 실행 방법, 복구 절차, 실패 유형 순으로 작성하는 방식을 권장해요. 강제 형식이 적어서 팀 상황에 맞게 자유롭게 확장할 수 있지만, 여러 작업에 공통으로 적용해야 할 행동을 먼저 정의하는 게 목표예요.

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

평가와의 관계

가장 큰 특징은 특정 스코어러나 평가 방식을 강제하지 않는 점이에요. 사람이 트레이스를 직접 리뷰하거나, 루브릭으로 채점하거나, 자동 eval을 돌려도 같은 BEHAVIOR.md를 기준으로 삼을 수 있어요. agentbehavior validate, list, explain CLI는 형식 검증과 탐색만 담당하고, 내용의 품질은 사람이나 별도 모델이 판단하도록 의도적으로 분리돼 있어요.

실제 예제를 보면, 기록된 트레이스를 행동 스펙과 비교해 true/false/na로 판정하는 평가 흐름을 제시하지만, 이것이 유일한 채점 방식은 아니에요. 조직에 맞게 사람이 개입하는 리뷰나, 정성적 루브릭 평가와 결합해 쓰는 게 일반적이에요. 즉 포맷은 같아도 평가 정책은 팀마다 다르게 적용할 수 있다는 뜻이에요.

실무에서의 활용 시점

이 표준은 매 실행마다 프롬프트에 불러넣는 구조가 아니에요. 주로 트레이스 검토, eval 설계, 프롬프트 감사, 행동 회귀 디버깅 같은 시점에 불러와 기준 문서로 사용돼요. 고가의 작업 전 확인, 재무 결과 검증, 1차 자료 우선 사용 정책 같은 예시도 제공돼서, 단순히 개발 실험뿐 아니라 실제 운영 규정으로도 쓸 수 있음을 보여줘요.

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

제한과 보완점

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

추가로 생각해볼 점은, 행동 스펙 자체가 오래되면 오히려 모델의 변화를 따라가지 못하는 문제예요. 그래서 정기적으로 트레이스와 비교해 스펙을 갱신하는 워크플로우가 필요해요. Agent Behavior는 그 갱신 주기를 어떻게 잡을지에 대한 정답은 제시하지 않지만, CLI 도구가 형식을 유지해주는 덕분에 문서 자체의 신선도 유지 부담은 줄어든 편이에요.

참고 링크

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