Apache 2.0 오픈소스로 공개된 Agent-EvalKit의 정체

AI 에이전트가 내놓은 결과물이 정교할수록 내부에서 어떤 논리적 비약이나 환각이 일어났는지 찾아내기 어렵다. 특히 도구가 빈 결과를 반환했음에도 에이전트가 이를 무시하고 가짜 데이터를 채워 넣었을 때, 최종 응답만으로는 이를 구분할 방법이 없다. Agent-EvalKit은 최종 결과값만 확인하는 기존 방식을 넘어 에이전트가 정답에 도달하기까지 거친 실행 경로 전체를 추적하는 인프라를 제공한다.

이 도구는 Apache 2.0 라이선스의 오픈소스로 공개되었으며, Claude Code, Kiro CLI, Kilo Code 같은 AI 코딩 어시스턴트와 통합해 사용할 수 있다. 별도의 평가 플랫폼을 구축하는 대신 개발자가 사용하는 코딩 환경 내에서 평가 워크플로를 바로 수행한다. AI 어시스턴트가 에이전트의 소스코드를 읽고 도구 정의와 시스템 프롬프트를 분석해 동작 모델을 세우므로, 평가 과정이 개발 사이클과 분리되지 않고 하나로 통합되어 작업 효율을 높인다.

평가의 핵심은 도구 호출 내역, 반환 데이터, 최종 응답의 일치 여부를 검증하는 것이다. 도구 호출 시 전달된 파라미터가 정확했는지, 반환된 데이터가 최종 응답에 충실하게 반영되었는지를 개별적으로 측정해 결과물 아래에 숨겨진 환각과 필수 검증 단계의 누락을 탐지한다. 이를 통해 실행 경로의 결함을 정량적 수치로 식별하고, 코드 베이스의 어느 지점을 수정해야 하는지 결정하는 실무적 근거를 제공한다.

/evalkit 명령어로 수행하는 6단계 평가 라이프사이클

Agent-EvalKit은 개발자가 사용하는 AI 코딩 어시스턴트 내에서 슬래시 명령어로 작동한다. `/evalkit.plan`이나 `/evalkit.data` 같은 명령어를 입력하고 자연어로 가이드를 주면 어시스턴트가 직접 평가 엔진 역할을 수행한다. 어시스턴트는 에이전트의 소스코드와 시스템 프롬프트, 프레임워크 설정을 분석해 도구 정의와 동작 방식을 파악하며, 개발 환경 내에서 평가와 수정을 동시에 진행한다.

전체 워크플로는 소스코드 분석, 계획, 데이터 생성, 인스트루먼테이션, 실행, 보고서 작성의 6단계 라이프사이클로 구성된다. 각 단계의 결과물은 프로젝트 내부의 `eval/` 디렉토리에 저장되어 다음 단계의 입력값으로 쓰인다. `/evalkit.plan`에서 측정 지표를 설계하면, `/evalkit.data`에서 테스트 케이스를 생성한다. 인스트루먼테이션 단계에서는 OpenTelemetry 호환 트레이싱 기술을 적용해 도구 호출 내역과 중간 상태를 수집한다. 이후 실행 단계에서 각 테스트 케이스를 구동하며 구조화된 트레이스를 기록해 프로세스 누락이나 데이터 왜곡 지점을 찾아낸다.

최종 보고서에서는 수집된 트레이스와 지표를 바탕으로 코드 베이스의 특정 위치를 참조하는 우선순위 기반 개선 권고안을 내놓는다. 개발자가 특정 품질 차원에 집중하도록 명령하면 테스트 케이스 생성부터 지표 선택, 보고서 강조 패턴까지 조정된다. 예를 들어 도구 결과가 비어 있을 때 발생하는 환각 현상을 집중 분석하도록 설정하면, 보고서는 해당 패턴이 나타나는 코드 지점을 정확히 짚어내어 어떤 파일의 몇 번째 줄을 수정해야 하는지 구체적인 지침을 제공한다.

기존 방식과 달라진 지점

기존의 방식은 출력값이 기대치와 일치하는지만 확인하는 출력 수준 테스트(Output-level testing)에 의존했다. 이 방식은 결과가 맞으면 성공으로 처리하므로, 논리적 근거를 갖춘 정답과 운 좋게 맞춘 오답을 구분하지 못하는 한계가 있다.

Agent-EvalKit은 실행 경로 전체를 추적하는 방식을 택했다. 에이전트가 도구를 호출할 때 입력한 파라미터의 정확성과 도구가 반환한 실제 데이터가 최종 응답에 반영된 충실도를 개별적으로 측정한다. 특히 도구가 빈 결과를 반환했음에도 에이전트가 가짜 정보를 지어내는 환각 현상을 잡아내는 데 집중한다. 최종 응답이 그럴싸하더라도 도구 반환 데이터와의 일치도가 낮다면 이를 프로세스 실패로 판정해, 숨어 있던 프로세스 누락이나 잘못된 도구 사용 패턴을 식별한다.

평가 도구는 코드 기반 평가자와 LLM-as-judge(거대언어모델 기반 평가자) 중 선택하거나 혼합해 사용할 수 있다. 코드 기반 평가자는 미리 정의된 정답셋과 비교해 재현성이 높고 빠르지만, 표현의 차이를 인정하지 못하는 유연성 부족 문제가 있다. 반면 LLM-as-judge는 문맥과 뉘앙스를 파악해 정교하게 평가할 수 있지만, 추가 추론 비용이 발생하고 프롬프트 설계 부담이 따른다. 따라서 단순 수치나 고유 명사 일치는 코드 기반으로, 응답의 전체적인 품질이나 논리적 흐름은 LLM-as-judge에게 맡겨 비용과 정확도의 균형을 잡는 전략이 효과적이다.

여행 리서치 에이전트 사례: 충실도 32.3%의 충격

Strands Agents SDK와 Amazon Bedrock 기반으로 구축한 여행 리서치 에이전트 사례는 실행 경로 검증의 필요성을 보여준다. 이 에이전트는 웹 검색, 항공 정보, 기후 데이터, 환율 변환, 예산 계산의 다섯 가지 도구를 사용한다. 개발팀은 에이전트가 내놓는 숫자들이 지나치게 정교하다는 점에 의문을 가졌으나, 구체적인 발생 빈도와 원인을 파악하지 못한 상태였다.

Agent-EvalKit은 세 가지 핵심 지표를 설정하고 100개의 멀티턴 테스트 세션을 수행했다. 응답 품질(Response Quality)은 최종 답변의 명확성을, 도구 파라미터 정확도(Tool Parameter Accuracy)는 호출 파라미터의 정확성을, 충실도(Faithfulness)는 도구 반환 데이터와 최종 응답의 일치 여부를 측정했다.

측정 결과, 응답 품질은 83.9%로 높게 나타나 사용자가 보기에 매우 유용한 조언을 제공하는 것처럼 보였다. 도구 파라미터 정확도는 64.5%로 적절한 도구 선택 능력은 갖췄으나 입력값의 정밀함이 떨어졌다. 가장 심각한 문제는 충실도가 32.3%에 그쳤다는 점이다. 웹 검색 도구가 빈 결과를 반환했을 때, 에이전트는 환율이나 기온, 관광지 정보를 스스로 지어내어 마치 도구에서 가져온 사실인 것처럼 제시했다.

결과적으로 83.9%라는 높은 응답 품질 수치는 오히려 사용자에게 거짓 정보를 확신시키는 위험한 장치가 되었다. 개발자는 이제 느낌상 불안하다는 직관 대신 충실도 32.3%라는 정량적 수치를 판단 기준으로 삼아, 도구 결과가 비어 있을 때 이를 솔직하게 공지하도록 시스템 프롬프트를 수정하고 오류 처리 로직을 강화하는 개선 우선순위를 정할 수 있게 됐다.

한국 AI 실무자가 Agent-EvalKit을 도입할 때의 판단 기준

자체 평가 인프라를 구축하려면 테스트 케이스 설계부터 관측성 도구 연결까지 막대한 인력이 투입되어야 한다. Agent-EvalKit은 Apache 2.0 오픈소스로 제공되어 이러한 초기 구축 비용을 낮춘다. 내부 인력이 부족한 팀에게는 코딩 어시스턴트에 통합된 툴킷을 도입해 직관적인 불안함을 충실도 같은 정량적 수치로 치환하는 것이 현실적인 대안이다.

평가 단계가 배포 후의 사후 검증이 아니라 개발 환경 내부의 반복 프로세스로 통합된다는 점이 핵심이다. 개발 단계에서 평가 라이프사이클을 돌리며 즉각적으로 수정하고 다시 검증하는 루프를 형성한다. 평가 결과는 단순한 숫자가 아니라 코드 베이스의 특정 위치를 참조하는 개선 권고안으로 연결되어, 개발자가 문제가 된 코드 라인을 정확히 찾아내 즉시 수정할 수 있게 돕는다.

도입 시 고려해야 할 실질적인 비용은 라이선스가 아니라 추가적인 추론 비용이다. LLM-as-judge 방식을 선택하면 평가 모델에 대한 API 호출 비용과 프롬프트 설계 시간이 투입되어야 한다. 반면 코드 기반 평가자는 비용이 없지만 유연성이 낮다. 실무적으로는 두 방식을 혼합하여 단순 일치 여부는 코드로 확인하고 복잡한 맥락은 LLM이 판단하게 하여 비용과 정확도의 균형을 잡아야 한다.

AI 에이전트가 내놓은 결과물이 그럴싸해 보일 때 느끼는 막연한 불안함은 대개 실행 경로의 불투명함에서 온다. Agent-EvalKit은 `/evalkit.plan` 명령어로 도구 호출부터 반환 데이터, 최종 응답의 일치 여부까지 전 과정을 추적해 이 불투명함을 걷어낸다.

이제 느낌상 불안하다는 직관을 충실도 32.3%라는 구체적인 수치로 치환해 시스템 프롬프트를 수정해야 한다는 정량적 판단 기준으로 바꿀 때다. 결국 에이전트의 성능 개선은 개발자의 감이 아니라 실행 경로의 정밀한 검증과 데이터에 기반한 확신으로 결정된다.