Microsoft가 공개한 ASSERT(Adaptive Spec-driven Scoring for Evaluation and Regression Testing)는 AI 평가의 초점을 조금 다른 곳으로 옮긴다. 모델이 일반적으로 얼마나 안전하고 유능한지를 재는 것이 아니라, 특정 제품 안에서 기대한 방식으로 행동하는지를 반복해서 확인하려는 프레임워크다.
작동 방식은 개발자에게 익숙한 테스트 자동화에 가깝다. 개발자는 “문서 리서치 에이전트는 회사 외부로 이메일을 보내면 안 된다”, “기밀 정보는 C-level 임원에게만 제공해야 한다”, “이전 맥락을 고려해 간결하게 요약해야 한다” 같은 정책을 자연어로 입력한다. ASSERT는 이 설명을 허용 가능한 행동과 허용 불가능한 행동의 구조로 바꾸고, 문제 시나리오와 테스트 케이스를 생성한 뒤 대상 AI 시스템을 실행해 점수를 매긴다.
중요한 차이는 평가의 맥락이다. Stanford HELM이나 MLCommons AILuminate 같은 벤치마크는 모델을 넓은 기준에서 비교하는 데 유용하다. 하지만 실제 AI 제품은 회사별 정책, 사용자 흐름, 연결된 도구, 권한 제약을 갖는다. 같은 모델이라도 문서 검색 에이전트, 고객지원 챗봇, 내부 업무 자동화 도구 안에서는 전혀 다른 기준으로 평가되어야 한다.
ASSERT가 중간 action과 tool call 경로를 기록할 수 있다는 점도 눈에 띈다. AI 시스템이 잘못된 답을 냈을 때 단순히 결과만 보는 것이 아니라, 어떤 중간 행동과 도구 호출을 거쳐 실패가 발생했는지 추적할 수 있다. 이는 특히 여러 도구를 사용하는 에이전트형 시스템에서 디버깅과 책임 소재를 파악하는 데 중요하다.
다만 자연어로 정책을 적는다고 평가 품질이 자동으로 보장되는 것은 아니다. 정책 문장이 모호하거나, 시스템 컨텍스트와 도구 제약이 충분히 제공되지 않으면 테스트 역시 빈틈을 가질 수 있다. ASSERT는 완성된 안전장치라기보다, 제품별 AI 행동을 테스트 가능한 대상으로 바꾸는 출발점에 가깝다.
AI 제품팀에게 이 흐름은 의미가 크다. 앞으로는 모델 선택만큼이나 배포 전 검증, 배포 후 모니터링, 모델·프롬프트 변경 이후의 회귀 테스트가 중요해진다. Microsoft의 ASSERT는 AI 애플리케이션 운영이 기존 소프트웨어의 테스트 파이프라인과 점점 더 닮아가고 있음을 보여준다.