질문 답변을 넘어 실제로 행동을 수행하는 에이전트는 어떻게 테스트하시나요?

요즘 이거 진짜 괜찮더라. https://github.com/SeraphimSerapis/tool-eval-bench 여러 모드도 있고, OpenAI 호환 엔드포인트에 설정하기도 쉽고, 애초에 툴 콜링(tool calling)용으로 만들어짐.

난 이걸 드라이런(dry-run), 게이트런(gated-run), 프로덕션런(production-run) 테스트로 나눌 것 같음. 사이드 이펙트가 있는 작업은 에이전트가 먼저 ID, 권한, 롤백 경로, 사유 코드가 포함된 액션 플랜을 생성하게 하고, 테스트에서는 샌드박스나 픽스처에서 의도한 레코드를 건드렸는지 확인하는 식이지. 프로덕션 환경에선 위험도가 높은 작업은 승인 절차를 거치게 하고, 최종 API 호출뿐만 아니라 결정 과정을 재현할 수 있을 만큼 충분히 로그를 남길 거야.

우리 거 배포하면서 얻은 교훈들 (기술 보고서에 있음):

• 에이전트가 실제 CRM이나 프로덕션 환경을 건드리게 절대 두지 마. 모든 파괴적인 작업은 모킹된 샌드박스 환경 안에 가둬야 함. 샌드박스에서 잘못된 작업은 그냥 로그 한 줄이지만, 프로덕션에선 되돌릴 수 없는 사고가 됨.
• 에이전트가 성공했다고 자화자찬하는 개소리는 완전히 무시해. 테스트할 때 얘가 생성한 설명은 아무 쓸모 없음. 사실은 제대로 실행하지도 못했으면서 깔끔한 성공 메시지를 지어내는 봇이, 진짜로 실행한 봇보다 더 자신감 넘쳐 보이거든...

솔직히 테스트 방식은 에이전트를 얼마나 신뢰하느냐에 달려 있다고 봄. 난 세 단계로 생각함:

1. 유닛 레벨 모의 테스트. 툴을 모킹하고 에이전트에게 알려진 시나리오를 던져서, 올바른 파라미터로 올바른 액션을 선택했는지 확인. 이러면 결정 오류를 싸게 잡을 수 있음.

2. 실제 실행을 포함한 스테이징 E2E. 실제로 이메일을 보내고, CRM을 업데이트한 다음, 스크립트로 결과 상태를 검증함. 이메일이 올바른 수신함에 들어갔는지, 고객 기록이 실제로 바뀌었는지 등.

액션이 되돌릴 수 없는 순간부터 품질 문제가 아니라 안전 문제로 바뀐다는 점에 동의함. 액션 전 단계는 이 스레드에서 잘 다뤄지고 있음(샌드박스, 확인 게이트, 위에서 말한 인텐트 레저 아이디어 등). 내가 덧붙이고 싶은 건 액션 후 단계임: 모든 액션이 구조화된 그라운드 트루스 기록을 남기게 하셈. 무엇을 시도했는지, 어떤 에이전트나 역할이 했는지, 결과는 어떤지(완료/차단/실패/검토 필요)를 기록하고, 모델이 요약한 내용이 아니라 그 기록을 진실의 원천으로 삼으셈.

이메일 전송, CRM 업데이트, 환불 처리, 회의 일정 잡기, 인프라 수정.

이런 걸 에이전트가 언제 할지 스스로 추론하게 할 필요가 있음? 실패 모드를 줄이는 데 가장 도움 되는 건 에이전트를 없애는 거임. 계획 후 실행 스타일 모델을 써서, 계획 에이전트가 구조화된 코드를 내뱉게 하고 그 워크플로우를 코드로 실행하셈.

나도 같은 생각이었음. 결국 어떤 프로세스를 처리하려는지, 그리고 왜 하려는지에 따라 다르지. 예를 들어 아마존 같은 사이트는 AI 에이전트가 존재하기 훨씬 전부터 수백만 건의 환불을 처리해왔음. 사용자가 환불을 요청하면 워크플로우를 통해 처리되는 시스템을 구축했기 때문이지. 그렇다면 지금 당신의 비즈니스에서 AI 에이전트가 직접 환불을 처리해야 하는 시나리오는 대체 무엇인가? 즉, 고객이 고객 지원팀에 환불을 요청하는 이메일을 보냈을 때, 당신은 다음 중 하나를 선택할 수 있음: 1) ...

팀들이 빼먹는 한 단계가 있음: 엔지니어링 팀한테 물어보지 않고도 운영 매니저가 액션 로그를 읽을 수 있어야 함. 그게 안 되면 그건 거버넌스가 아니라 그냥 eval을 배포한 거임.

혹시 human-in-the-loop 방식을 쓰고 있나요? 제가 계속 생각하는 접근법은 신뢰도 점수예요. 에이전트가 행동에 대해 얼마나 확신하는지 점수를 매기고, 중간 정도의 확신을 보이면 실행하는 대신 사람에게 넘기는 거죠. 실제로 그런 핸드오프 경로를 구축했나요? 에이전트는 시키는 대로만 행동하니까요. 확신이 없을 때 어떻게 하라고 알려주지 않으면, 결국 잘못된 행동을 저지를 수밖에 없어요.

"행동은 실제처럼, 결과는 가짜로"라는 프레임워크가 내가 딱 필요했던 거임. 우리는 프로덕션과 똑같은 환경에서 테스트하느라 겁에 질려 있거나, 아니면 전체를 모킹해서 실제 액션 호출을 검증하지 못하고 있었음. 중간 지점(실제 호출, 모킹된 부작용, 파라미터 검증)이 뒤늦게 생각해보니 당연히 맞는 길이었음. 고마움.