관련 콘텐츠 ▶ 모델 검증: LLM 모델 성능 평가 및 테스트 데이터 구축 사례
업무에 AI 에이전트를 도입하면 자동화 범위를 크게 넓힐 수 있을 것처럼 보입니다. 질문을 이해하고, 필요한 자료를 찾고, 도구를 호출하고, 다음 행동까지 이어갈 수 있기 때문입니다. 하지만 실제로 도입을 검토하는 단계에 들어가기 전에 먼저 고민해봐야 할 것이 있습니다. 이 에이전트가 어디까지 스스로 판단해도 되는지, 어떤 상황에서는 멈춰야 하는지, 실패했을 때 무엇을 남겨야 하는지를 정하는 것입니다.
최근 공개된 SciAgentArena 연구도 이 지점을 잘 보여줬습니다. 이 연구는 과학 연구에 가까운 복합 과제를 바탕으로 AI 에이전트를 평가하는 벤치마크를 제안했습니다. 핵심은 단순 정답률보다 단계별 판단, 실행 과정, 실패 양상을 함께 봐야 한다는 점입니다. 기업이 AI 에이전트 평가를 준비할 때도 같은 관점이 필요합니다. 모델이 똑똑한지보다, 실제 업무 흐름 안에서 안정적으로 판단하고 멈출 수 있는지를 먼저 봐야 합니다.
최근 연구가 보여준 변화
SciAgentArena 연구진은 AI 에이전트가 복잡한 과학 연구 과제를 어느 정도 수행할 수 있는지 평가했습니다. 이를 위해 약 200개 과제로 구성된 벤치마크를 만들고, 약물 발견, 단일세포 오믹스, 공간 오믹스, 전자의무기록, 유전학처럼 성격이 다른 과학 연구 영역을 함께 다뤘습니다. 평가도 단순 정답 여부에만 머물지 않았습니다. 에이전트가 문제를 이해하고, 데이터를 분석하고, 최적화나 발견 과제를 수행하고, 제시된 과제가 실제로 가능한지 판단하는 과정을 단계별로 살펴봤습니다.
연구진이 특히 신경 쓴 부분은 에이전트를 단순한 정답을 맞히는 챗봇으로 보지 않았다는 점입니다. 한 번의 답변이 맞았는지보다, 과제 수행 과정에서 어떤 판단을 했는지, 어느 단계에서 실패했는지, 복잡한 문제를 끝까지 다룰 수 있는지를 함께 보려고 했습니다. 그래서 이 연구의 핵심은 "어떤 에이전트가 가장 높은 점수를 받았는가"보다, 현재 에이전트가 어떤 업무에서는 쓸 만하고 어떤 업무에서는 아직 불안정한지를 나눠 보여준 데 있습니다.
그 과정에서 도출되는 결론은 분명합니다. 현재 AI 에이전트는 구조가 명확하고 평가 기준이 분명한 데이터 분석형 업무에서는 비교적 효과적으로 기여할 수 있었습니다. 반면 새로운 인사이트를 만들어내거나, 스스로 탐색을 이어가거나, 열린 연구 질문에 대해 안정적인 해결책을 세우는 일에서는 성능이 고르지 않았습니다.
논문은 공통적인 실패 양상도 함께 정리했습니다. 비슷한 방법만 반복해서 선택하거나, 스스로 탐색을 충분히 이어가지 못하거나, 검증 없이 과제를 수행하려는 경향이 나타났습니다. 결국 AI 에이전트 평가는 하나의 종합 점수나 최종 답변만으로 설명하기 어렵습니다. 과제 유형, 수행 단계, 도구 사용 여부, 실패 지점에 따라 평가해야 할 항목이 달라집니다.
이 결과를 기업 업무에 그대로 일반화할 수는 없습니다. 다만 업무 자동화에 에이전트를 쓰려는 팀이 무엇을 먼저 준비해야 하는지는 분명하게 시사합니다. 에이전트가 잘했는지, 못했는지보다 ‘어느 단계에서 어떤 조건 때문에 흔들렸는가’를 확인할 수 있어야 하고, 이를 위해 업무 범위, 성공 조건, 실패 조건, 검수 기준을 먼저 정리해야 합니다.
기업 실무에서 고민해봐야 할 점
업무 자동화에서 에이전트는 단순 챗봇보다 더 넓은 역할을 맡습니다. 답변만 하는 것이 아니라 조회, 분류, 문서 검색, 도구 호출, 후속 안내 같은 행동까지 이어질 수 있습니다. 그래서 AI 에이전트 평가는 ‘답변이 맞았는가’만으로 끝나면 부족합니다. 다음 항목을 함께 봐야 합니다.
필요한 정보를 정확히 찾았는가
업무 절차에 맞는 순서로 행동했는가
도구 호출 실패나 정보 부족 상황을 감지했는가
사람이 확인해야 하는 구간에서 멈췄는가
실패한 경우 원인과 로그가 남았는가
평가 구간 | 확인 질문 | 필요 데이터 | 실패 시 리스크 |
의도 파악 | 사용자 요청 유형을 | 요청 유형 샘플, | 잘못된 업무 |
근거 탐색 | 필요한 문서나 데이터를 정확히 찾았는가 | 근거 문서, | 그럴듯하지만 |
도구 호출 | 필요한 도구를 올바르게 선택하고 실행했는가 | 도구 명세, | 잘못된 조회 |
예외 처리 | 멈춰야 할 상황을 | 실패 케이스, | 무리한 자동 처리 |
결과 검수 | 최종 답변과 중간 행동을 함께 확인했는가 | 평가 루브릭, | 원인 파악이 어려운 품질 저하 |
특히 실무에서는 에이전트가 틀린 답을 내는 것만큼이나, 멈춰야 할 때 계속 진행하는 일이 위험합니다. 고객 응대, 내부 승인, 데이터 조회, 계약 관련 업무처럼 사람의 판단이 필요한 구간에서는 자동화 범위를 좁게 정의하는 편이 더 안전합니다.
도입 전 준비해야 할 평가 기준
AI 에이전트 평가를 시작하기 전에 먼저 정리해야 할 것은 모델 목록이 아니라 업무 기준입니다.
첫째, 업무 시나리오를 작게 나눠야 합니다.
‘문의 응대 자동화’처럼 큰 이름만 붙이면 테스트가 어렵습니다. 자주 들어오는 요청, 필요한 문서, 조회가 필요한 조건, 사람에게 넘겨야 하는 상황을 유형별로 나눠야 합니다.
둘째, 성공 조건과 실패 조건을 함께 정의해야 합니다.
정상 시나리오만 있으면 데모는 잘 보일 수 있습니다. 하지만 정보가 부족한 요청, 서로 충돌하는 조건, 도구 응답 지연, 권한이 없는 요청 같은 실패 케이스가 빠지면 운영 리스크를 확인하기 어렵습니다.
셋째, 중간 판단을 기록해야 합니다.
최종 답변만 보면 에이전트가 우연히 맞춘 것인지, 올바른 문서를 찾고 적절한 절차를 따른 것인지 알기 어렵습니다. 의도 분류, 문서 선택, 도구 호출, 예외 처리 같은 중간 단계를 함께 검수해야 합니다.
TEXTNET의 관점에서 보면
TEXTNET 관점에서 AI 에이전트 평가는 업무 구조화와 데이터 설계에서 시작합니다. 에이전트가 수행할 업무를 먼저 정의하고, 각 단계별 판단 기준과 실패 케이스를 데이터로 만들어야 합니다. 예를 들어 고객 응대형 에이전트라면 다음 순서가 필요합니다.
자주 들어오는 문의를 유형별로 분류합니다.
각 문의 유형에 필요한 근거 문서와 판단 조건을 연결합니다.
자동 처리 가능한 요청과 사람에게 넘겨야 하는 요청을 분리합니다.
실패하기 쉬운 상황을 테스트 시나리오로 만듭니다.
응답 결과뿐 아니라 중간 행동 로그까지 검수합니다.
이 구조가 있어야 에이전트 도입 후에도 품질을 설명할 수 있습니다. 성공률이 낮을 때 무엇을 고쳐야 하는지, 모델 문제인지 데이터 문제인지, 업무 기준이 모호한 문제인지 구분할 수 있기 때문입니다. AI 에이전트를 바로 붙이는 것보다, 먼저 평가 가능한 업무 데이터로 바꾸는 과정이 더 중요할 때가 많습니다. TEXTNET은 이런 흐름에서 업무 시나리오 데이터, 테스트 케이스, 평가 기준표, 검수 기준 설계를 지원할 수 있습니다.
📄
마무리하며
AI 에이전트는 업무 자동화를 더 넓은 범위로 확장할 수 있는 기술입니다. 다만 실제 운영에서는 모델 성능만으로 성공 여부를 판단하기 어렵습니다. 최근 연구가 보여준 방향도 비슷합니다. 에이전트는 한 번의 답변보다 여러 단계의 판단과 행동을 함께 평가해야 합니다. 기업 실무에서는 이 관점을 업무 시나리오, 실패 케이스, 검수 기준으로 옮겨야 합니다. AI 에이전트 도입을 검토하고 있다면, 먼저 자동화할 업무를 평가 가능한 단위로 나눠보는 것이 좋습니다. 그 기준이 있어야 이후 PoC, 구축, 운영 검수도 훨씬 현실적으로 진행할 수 있습니다.
Share article