어떤 조사에 따르면, 9개 모델 × 9개 벤치마크로 2만 회 이상의 에이전트 시도를 수행할 경우 검증 비용만 약 4만 달러가 소요되며, 동일한 평가를 8회 반복하면 성적이 60%에서 25%까지 떨어지는 구성조차 있다고 한다. AI 에이전트의 "능력"은 지난 1~2년 사이 충분히 향상되었다. 그럼에도 구현 현장에서는 "정말로 의도한 대로 작동하는가"를 확인하는 검증 비용이 부담이 되기 쉽다. Microsoft가 2026년 6월에 공개한 OSS 평가 프레임워크 "ASSERT"는 자연어로 작성한 "거동 사양(Behavior Specification)"을 그대로 테스트로 변환한다는 발상으로 이 검증 비용 문제에 도전한다. 판정역으로 LLM 자체를 사용하는 LLM-as-a-Judge가 토대이며, LLM을 API로 한 번이라도 호출해 본 적이 있다면 남의 일이 아니다.

ASSERT의 설계 사상은 한마디로 말할 수 있다. "거동 사양은 평가의 일급 입력(First-class input)이어야 한다"는 것이다. 거동 사양이란 제품 요구사항이나 정책 문서 등 "AI가 이렇게 행동하기를 바란다"라고 적어둔 것을 가리킨다. 유용성이나 유해성과 같은 범용적인 평가 지표로는 높은 점수를 받더라도 자신의 앱 고유의 거동 경계까지는 측정할 수 없는 상황이 발생할 수 있다. ASSERT는 이 사양을 입력으로 테스트를 생성한다(사양 주도 평가, Specification-driven evaluation). LiteLLM(여러 LLM API를 통합 호출하는 도구)을 통해 100개 이상의 모델을, OpenInference(AI의 거동 기록을 통일된 형식으로 남기는 규격)를 통해 33개 이상의 프레임워크를 지원한다. 공개된 지 얼마 되지 않아 독립 기업의 본 프로덕션 사례는 아직 없다. 현재는 CrewAI(AI 에이전트를 구성하는 프레임워크), Arize AI, LiteLLM 등이 통합 및 검증 단계의 파트너로 참여하고 있으며, Arize AI를 실행 로그의 기록처로, LiteLLM을 모델 평가의 입구로 사용하는 사례가 있다. CrewAI의 OSS 리드인 Lorenze Jay 씨는 "관심 있는 거동을 YAML로 작성하여 에이전트에 흘려보내면 판정 이유까지 돌아온다. 모든 것을 로컬에서 검사할 수 있어 블랙박스처럼 느껴지지 않는다"라고 증언한다.

ASSERT는 거동 사양을 4가지 스테이지를 통해 실행 가능한 테스트로 변환한다.

• 체계화(Systematization): 모호한 개념을 패턴이나 에지 케이스(Edge case)를 가진 "개념 사양"으로 구체화한다.
• 테스트 세트 생성(Test Set Generation): 개념 사양을 거동 분류로 변환하고, 개발자가 지정한 관점에 따라 편향 없이 케이스를 생성한다.
• 추론(Inference): 생성된 케이스를 대상 시스템에 실행하고, 도구 호출(Tool call)까지 포함된 완전한 트레이스(Trace, 실행 기록)를 남긴다.
• 채점(Scoring): 각 트레이스를 거동 분류 및 정책에 비추어 판정한다. 합격/불합격뿐만 아니라 판정 이유(Rationale)와 정책 조문의 인용까지 출력한다.

공식 리포지토리에는 LangGraph(에이전트의 처리를 그래프로 구성하는 OSS)로 만든 여행 플래너를 평가하는 예시가 있다. 설정 파일의 골격은 다음과 같다.

suite: travel-planner-langgraph-v1
behavior: # 일급 입력: 거동을 자연어로 작성
name: travel_planner_eval
...

실행은 명령어 하나로 가능하다.

assert-ai run --config eval_config.yaml

실행하면 taxonomy.json (개념 사양), test_set.jsonl (테스트 케이스), inference_set.jsonl (트레이스), scores.jsonl (판정), metrics.json (집계)이 로컬에 생성된다. scores.jsonl은 판정 이유와 정책 인용까지 남긴다. 다음은 개념도(간략화된 도식이며, 실제 필드명은 참고문헌 3의 공식 예시에서 확인할 수 있다).

# scores.jsonl의 한 줄 (개념도): pass/fail 뿐만 아니라 근거와 인용이 남음
case_id : tc-014
dimension : policy_violation # judge의 평가 차원
...

공식 예시에서는 동일한 시나리오로부터 "과잉 거부 40%", "정책 위반 60%"라는 두 가지 숫자가 별도로 나온다. 단일 스코어로 뭉뚱그리지 않기 때문에, 정반대 방향으로 동시에 실패하고 있는 상황도 놓치지 않고 파악할 수 있다.

Microsoft는 내부 검증 결과도 공개했다. 비교 대상은 HELM이나 METR와 같은 범용 벤치마크 (Benchmark)가 아니라, 동일한 의도에서 직접 테스트를 생성한 사내 베이스라인 (Baseline)이다. "모델 간의 분리 (Separation between models)"란 동일한 테스트에서 강한 모델과 약한 모델의 성적이 얼마나 벌어지는지를 나타내는 지표로, 사내 베이스라인 대비 4배 이상 강해졌으며, 모든 모델이 동일한 동작을 보이는 "포화 (Saturated)" 케이스는 약 절반으로 줄었다고 보고되었다. 다만 절대값이나 그 차이가 우연에 의한 것이 아니라고 말할 수 있는지 여부는 비공개이므로, 사내 비교를 위한 참고 지표로 받아들이고 싶다.

채점 그 자체는 최종적으로 LLM이 판정하는 LLM-as-a-Judge에 의존한다. Microsoft 스스로 한계를 공개했는데, 10개가 넘는 행동 개념으로 검증한 결과 LLM judge와 인간 평가자의 판정 일치율은 대체로 80~90%였으며, 인간 사이의 일치율은 약 90%였다. 판정 순서에 따라 결과가 바뀌는 위치 편향 (Position Bias, 동일한 답변이라도 먼저 채점되는지 나중에 채점되는지에 따라 결과가 달라지는 편향)이나, 긴 답변을 높게 평가하는 경향이 있는冗長性 (Redundancy) 편향이 있다는 지적도 있다. 실무에서는 종합 점수보다 실패 트레이스 (Failure Trace)를 통해 "어느 부분을 수정해야 하는가"를 읽어내는 방식이 현실적이다.

ASSERT의 주안점은 자연어 사양 (Specification)을 4단계의 실행 가능한 테스트로 변환하는 사양 주도 평가 (Specification-driven evaluation)라는 설계 그 자체에 있다. 서두에 언급한 검증 비용은 범용 벤치마크를 유용하는 것만으로는 좀처럼 낮아지지 않는다. ASSERT는 사양을 일급 입력 (First-class input)으로 삼고, 애플리케이션 고유의 동작 경계에 초점을 맞춤으로써 헛수고를 줄일 수 있는 가능성을 가진다. 다만 채점은 LLM-as-a-Judge에 의존하며, 인간과의 일치율이 80~90% 수준에 머문다는 점은 사용 시 주의해야 할 점이다. 종합 점수를 과신하지 않고 실패 트레이스를 해독하는 도구로 사용함으로써, 품질 보증은 감각에 의존하는 조정에서 회귀 가능한 검증 공정으로 다가간다. 다음에 자신의 에이전트 (Agent)를 검증할 때, 무엇을 "일급 입력"으로 삼을지 한 번 고민해 보고 싶다.

• Microsoft Command Line - Turn specs into evals for any agent with ASSERT - https://commandline.microsoft.com/assert-written-intent-executable-evals/

• GitHub - responsibleai/ASSERT(공식 리포지토리·README) - https://github.com/responsibleai/ASSERT

• GitHub - responsibleai/ASSERT: examples/travel_planner_langgraph/eval_config.yaml(개념 코드의 YAML·CLI 대조에 사용) - https://github.com/responsibleai/ASSERT/blob/main/examples/travel_planner_langgraph/eval_config.yaml

• Microsoft for Developers (Foundry) - Build 2026: the open trust stack for AI agents(발표·파트너) - https://devblogs.microsoft.com/foundry/build-2026-open-trust-stack-ai-agents/

• Hugging Face Blog (evaleval) - Evaluation is the new compute bottleneck - https://huggingface.co/blog/evaleval/eval-costs-bottleneck

• Microsoft Tech Community - Evaluating AI agents: can LLM-as-a-judge evaluators be trusted?

• https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/evaluating-ai-agents-can-llm-as-a-judge-evaluators-be-trusted/4480110

• arXiv 2508.18076 - LLM-as-a-judge의 타당성 및 편향(Bias)에 관한 연구 - https://arxiv.org/pdf/2508.18076

• TechCrunch - 개발자가 텍스트 설명을 사용하여 AI 동작 테스트를 생성할 수 있게 해주는 Microsoft의 새로운 도구 (HELM/AILuminate/METR의 업계 문맥) - https://techcrunch.com/2026/06/02/new-microsoft-tool-lets-devs-spin-up-ai-behavior-tests-using-text-descriptions/

• LiteLLM Docs - LiteLLM × Microsoft ASSERT 통합 - https://docs.litellm.ai/blog/litellm-microsoft-assert