isorai Archives Office
Go back

에이전트 평가 체크리스트 5개, 답변보다 실행을 먼저 보자

Edit page

도입부

에이전트를 써 보면 금방 알게 됩니다. 잘 쓴 답변 하나가 곧 좋은 에이전트를 뜻하지는 않습니다. 마지막 문장은 그럴듯한데, 중간에 엉뚱한 자료를 읽고도 넘어가고, 파일을 바꿔 놓고 다시 확인하지 않고, 실패한 툴 호출을 조용히 묻어버리는 경우가 생각보다 많습니다.

그래서 이제 질문을 바꿔야 합니다. “이 모델이 말을 잘하나?”보다 “이걸 내 업무에 어디까지 맡길 수 있나?”를 먼저 물어야 합니다. 최근 AWS가 Agent-EvalKit 글에서 에이전트 평가를 체계화하려는 흐름을 내놓은 것도 같은 맥락으로 보입니다. 평가 단위를 답변 한 줄이 아니라 실행 과정 전체로 옮기자는 신호입니다.

왜 지금 중요한가

지금은 에이전트가 단순 채팅창을 넘어 검색, 파일 수정, 테스트 실행, 브라우저 조작까지 묶어서 일하는 시기입니다. GitHub의 microsoft/playwright-mcp 같은 도구가 살아 있다는 사실만 봐도, 에이전트의 가치가 점점 “무슨 말을 하느냐”보다 “실제로 어디를 건드릴 수 있느냐”로 이동하고 있음을 보여 줍니다.

동시에 로컬 LLM이나 사내 문서 기반 자동화처럼 바깥으로 크게 드러나지 않는 작업도 늘고 있습니다. Ollama 같은 로컬 실행 도구가 계속 쓰이는 이유도 비슷합니다. 눈에 보이는 최종 답변보다, 내부 데이터와 툴을 어떻게 다루는지가 품질을 가르기 시작했기 때문입니다.

결국 지금 중요한 이유는 단순합니다. 에이전트가 답변형 소프트웨어에서 실행형 소프트웨어로 넘어가는 중이기 때문입니다. 이 단계에서 평가를 여전히 문장 품질 중심으로만 하면, 실제 운영 사고를 너무 늦게 발견하게 됩니다.

실제 업무에 맡길 수 있는 범위

실무에서는 맡길 수 있는 일과 아직 사람이 붙어 있어야 할 일이 생각보다 분명합니다. 자료 후보 수집, 초안 뼈대 작성, 특정 파일 탐색, 테스트 실행과 요약처럼 반복 가능하고 검증 가능한 일은 에이전트에게 꽤 잘 맞습니다. 결과보다 과정 확인이 쉬워서, 잘못돼도 사람이 빠르게 되짚을 수 있기 때문입니다.

반대로 발행, 배포, 삭제, 권한 변경, 외부 고객에게 바로 나가는 메시지처럼 되돌리기 비용이 큰 일은 아직 사람이 승인 경계를 잡고 있어야 합니다. 여기서는 답변의 유창함보다, 중간 검증과 멈춤 지점이 더 중요합니다.

정리하면 이렇습니다.

핵심 기준은 하나입니다. 결과를 칭찬하기 쉬운 일보다, 과정을 검증하기 쉬운 일부터 맡겨야 한다는 점입니다.

운영 체크리스트

실무에서 바로 써먹으려면 아래 5가지만 먼저 봐도 됩니다.

  1. 최종 답변 말고 실행 로그가 남는가
    어떤 검색을 했고, 어떤 파일을 읽었고, 어떤 툴이 실패했는지 남아야 합니다. 로그가 없으면 잘한 것도 재현이 안 되고, 못한 것도 고칠 수 없습니다.

  2. 검증 단계가 말이 아니라 실행으로 들어가 있는가
    파일 수정 후 재읽기, 테스트 실행, diff 확인, 재시도 같은 단계가 실제 행동으로 이어져야 합니다. “확인했습니다”라는 문장만으로는 부족합니다.

  3. 툴 선택이 과업과 맞는가
    단순 검색이면 검색으로 끝내야 하고, 브라우저 조작이 필요한 일만 브라우저형 에이전트를 써야 합니다. 툴을 많이 쓴다고 좋은 에이전트가 되는 것은 아닙니다.

  4. 고위험 액션 앞에 승인 경계가 있는가
    발행, 배포, 커밋, 삭제처럼 되돌리기 어려운 단계는 사람 승인 지점이 있어야 합니다. 잘하는 능력보다 멈출 수 있는 구조가 먼저입니다.

  5. 실패를 다시 돌려볼 수 있는가
    같은 입력에서 같은 실수를 재현할 수 있어야 평가가 쌓입니다. “가끔 이상하다”는 운영 감상이지 평가 데이터가 아닙니다.

이 체크리스트의 장점은 거창하지 않다는 데 있습니다. 혼자 돌리는 자동화든, 작은 팀의 콘텐츠 파이프라인이든, 일단 이 다섯 가지만 보면 어디서부터 맡길 수 있을지 감이 빨리 잡힙니다.

한계와 확인 필요 사항

물론 실행 중심 평가가 만능은 아닙니다. 로그를 많이 남긴다고 곧바로 좋은 시스템이 되지는 않습니다. 오히려 읽히지 않는 로그만 쌓이면 중요한 실패 신호를 더 놓칠 수 있습니다. 체크리스트도 결국 실제 업무 시나리오와 연결되어야 의미가 있습니다.

또 하나 확인할 점은, 외부 평가 프레임워크가 우리 팀의 실패 패턴을 그대로 설명해 주지는 않는다는 사실입니다. AWS Agent-EvalKit 같은 흐름은 좋은 출발점이지만, 실제 운영에서는 우리 업무의 승인 단계, 재시도 습관, 민감 정보 처리 기준을 따로 얹어야 합니다.

그래서 이 글의 결론은 “평가 도구를 새로 도입하자”가 아닙니다. 더 정확히는 에이전트를 똑똑한 답변기로 볼지, 검증 가능한 실행 시스템으로 볼지부터 정해야 한다는 쪽입니다. 이 관점이 정리돼야 자동화 범위도 함께 선명해집니다.

함께 보면 좋은 글 또는 내부 링크 후보

참고한 출처

Edit page
Next Post
Claude Code, Cursor, Codex를 어디까지 맡길 수 있나