에이전트의 도구(Tool)와 세 층의 평가 — 선택·실행·결과

지난 글에서 workflow는 철길, agent는 사거리, 하네스는 그 사거리의 신호등과 가드레일이라고 정리했습니다. 그런데 한 가지 질문이 남습니다. 그 신호등은 대체 어디에, 무엇을 기준으로 세우는 걸까요?

이번 글의 답은 이렇습니다. 사거리에서 에이전트가 실제로 하는 일은 도구(tool)를 고르고 쓰는 것이고, 신호등은 바로 그 도구 사용의 세 지점 — 선택, 실행, 결과 — 에 세웁니다. Anthropic의 Writing effective tools for agents를 바탕으로, 도구가 무엇인지부터 그 평가까지 정리해보겠습니다.

도구란 결정적 시스템과 비결정적 에이전트 사이의 계약이다

먼저 도구가 무엇인지부터 짚어야 합니다. Anthropic의 정의가 정확합니다.

전통적인 소프트웨어는 결정적(deterministic) 시스템 사이의 계약입니다. getWeather("NYC")라는 함수를 호출하면, 언제 호출하든 똑같은 방식으로 뉴욕 날씨를 가져옵니다. 같은 입력에 항상 같은 출력. 예측 가능합니다.

그런데 에이전트는 비결정적(non-deterministic) 시스템입니다. 같은 시작 조건에서도 다른 응답을 낼 수 있습니다. 그래서 도구는 새로운 종류의 소프트웨어입니다. 결정적 시스템(도구의 실제 구현)과 비결정적 에이전트(도구를 호출하는 주체) 사이의 계약인 셈이죠.

이 차이가 왜 중요할까요? 사용자가 “오늘 우산 챙겨야 할까?”라고 물었을 때, 에이전트는 날씨 도구를 호출할 수도 있고, 일반 지식으로 답할 수도 있고, 위치를 먼저 되물을 수도 있습니다. 심지어 도구를 잘못 쓰거나, 어떻게 쓰는지 파악하지 못할 수도 있습니다. 도구 자체는 결정적으로 동작하지만, 그 도구를 언제 어떻게 부를지는 에이전트가 비결정적으로 판단합니다.

여기서 지난 글의 철길/사거리 비유와 정확히 연결됩니다.

• 도구를 결정적으로 쓴다 = 개발자가 “이 단계에선 이 도구를 이렇게 쓴다”를 미리 코드로 정해둔다 = 철길(workflow).
• 도구를 비결정적으로 쓴다 = 에이전트가 입력을 보고 어떤 도구를 어떤 파라미터로 쓸지 스스로 정한다 = 사거리(agent).

Agent는 결국 입력에 따라 원하는 결과를 이루기 위해, 주어진 도구들 중에서 스스로 고르고 조합하는 시스템입니다. 이 “스스로 고른다”가 유연함의 원천이자, 동시에 통제가 필요한 이유입니다.

사거리에서 무엇이 잘못될 수 있는가

에이전트가 도구를 스스로 고르게 두면, 잘못될 수 있는 지점이 명확히 나뉩니다. Anthropic은 이렇게 정리합니다. 에이전트는 잘못된 도구를 부르거나, 맞는 도구를 잘못된 파라미터로 부르거나, 너무 적게 부르거나, 도구 응답을 잘못 처리할 수 있습니다.

이 실패 지점들을 곱씹어보면, 도구 사용은 사실 세 개의 단계로 나뉘고 각 단계마다 다른 종류의 실패가 있습니다.

1. 선택: 이 상황에서 맞는 도구를 골랐는가?
2. 실행: 고른 도구를 제대로(유효한 파라미터로) 실행했는가?
3. 결과: 실행 결과가 실제로 쓸 만했는가?

그리고 이 세 지점이 바로 하네스가 신호등을 세우는 자리이자, 평가가 측정해야 하는 자리입니다. 둘은 같은 실패를 보지만 시점이 다릅니다. 평가는 도구를 고치기 위해 오프라인에서 측정하고, 하네스는 실제 실행 중에 그 실패를 막거나 되돌립니다. 이제 각 층을 평가라는 관점에서 보겠습니다.

세 층의 평가

Anthropic이 권하는 평가 방법론은, 뜯어보면 정확히 이 세 층을 측정합니다. 원문은 이걸 딱 세 단계로 번호 매기진 않지만, 제안하는 지표들을 재배열하면 이 구조가 드러납니다.

① 도구 선택 평가 — 맞는 도구를 골랐나

첫 번째 신호등은 “에이전트가 각 도구의 목적을 제대로 이해하고 올바른 도구를 골랐는가”입니다. Anthropic은 각 평가 작업에 대해 에이전트가 호출하리라 기대되는 도구를 명시해두고, 실제로 그 도구를 잘 골랐는지 측정하라고 권합니다.

다만 여기엔 함정이 있습니다. 하나의 작업을 푸는 올바른 경로가 여러 개일 수 있으므로, 특정 전략에 과하게 맞추거나 도구 호출을 과하게 못 박지 말라고 경고합니다. 신호등은 “이 길로만 가라”가 아니라 “위험한 길로는 가지 마라”여야 한다는 것이죠.

이 층을 개선하는 핵심 수단이 네임스페이싱과 도구 설명(description) 프롬프트 엔지니어링입니다. 수십 개의 MCP 서버, 수백 개의 도구가 붙으면 에이전트는 어떤 걸 써야 할지 헷갈립니다. asana_search, jira_search처럼 서비스별로 접두어를 붙여 경계를 명확히 하면 선택 정확도가 올라갑니다. 도구 설명도 마찬가지입니다. Anthropic은 새로 온 팀원에게 설명하듯 도구를 서술하라고 권합니다. 실제로 Claude가 웹 검색 도구의 query 파라미터에 불필요하게 2025를 붙여 결과를 망치던 문제를, 도구 설명을 고쳐 바로잡은 사례를 듭니다.

선택 실패의 원인은 설명만이 아닙니다. 도구를 너무 많이, 겹치게 만드는 것도 선택을 망칩니다. list_users + list_events + create_event처럼 API를 그대로 감싸기보다, schedule_event처럼 실제 작업 단위로 묶는 편이 에이전트에게 더 자연스럽습니다. 도구 카탈로그를 키우는 일보다, 목적이 겹치지 않는 도구를 남기는 일이 선택 평가의 출발점입니다.

② 실행 에러 평가 — 제대로 실행됐나

두 번째 신호등은 “도구가 에러 없이 실행됐는가”입니다. Anthropic은 정확도 외에도 도구 에러, 개별 도구 호출의 실행 시간, 총 도구 호출 수, 토큰 소비량 같은 지표를 함께 수집하라고 권합니다.

특히 이 지표들은 진단의 실마리가 됩니다. 유효하지 않은 파라미터로 인한 에러가 많다면 → 도구 설명이나 예시가 부족하다는 신호입니다. 중복된 도구 호출이 많다면 → 페이지네이션이나 토큰 한도 파라미터를 조정해야 한다는 신호입니다.

그리고 에러가 났을 때의 처리도 중요합니다. 불투명한 에러 코드나 traceback을 던지지 말고, 무엇을 어떻게 고치면 되는지 구체적으로 알려주는 에러 메시지를 설계하라고 권합니다. 에러 응답조차 에이전트를 더 나은 방향으로 유도하는 신호등이 되는 것이죠.

③ 결과 품질 평가 — 그 결과가 쓸 만했나

세 번째 신호등은 “도구가 에러 없이 돌았다고 끝이 아니라, 그 결과가 실제로 작업에 쓸모 있었는가”입니다. 실행 성공과 결과 품질은 다른 문제니까요.

Anthropic은 각 평가 프롬프트를 검증 가능한 응답·결과와 쌍으로 만들라고 합니다. 검증기는 단순한 문자열 비교부터, Claude를 심판(judge)으로 세워 응답의 품질을 판정하는 방식까지 다양합니다. 다만 형식이나 구두점 같은 사소한 차이로 정답을 오답 처리하는 지나치게 엄격한 검증기는 피하라고 합니다.

이 층에서 도구 설계가 결과 품질에 직접 영향을 줍니다. 에이전트는 컨텍스트가 제한적이라, 주소록에서 연락처를 찾을 때 list_contacts로 전부 받아 토큰 단위로 훑는 건 낭비입니다(책을 첫 장부터 끝까지 읽는 격). 대신 search_contacts처럼 관련 있는 것만 돌려주는 도구가 낫습니다. 또 uuid, mime_type 같은 저수준 식별자보다 name, file_type 같은 의미 있는 값을 돌려줘야 에이전트가 다음 행동을 잘 결정합니다. 결과의 양(토큰 효율)과 질(관련성) 모두가 평가 대상입니다.

실무에서 바로 보는 체크포인트

도구를 설계하거나 에이전트가 이상하게 행동할 때는, 세 층을 한 번에 보지 말고 아래 순서로 원인을 가르는 편이 빠릅니다.

• 선택: 도구 이름이 겹치지 않는가. 설명만 읽고도 “언제 쓰고, 언제 쓰지 말아야 하는지”가 보이는가.
• 실행: 실패 응답이 다음 행동을 알려주는가. 같은 도구를 반복 호출하지는 않는가.
• 결과: 필요 없는 필드가 컨텍스트를 잡아먹지는 않는가. 에이전트가 다음 호출에 쓸 수 있는 식별자를 돌려주는가.

평가는 이 세 층을 숫자로 남기는 작업입니다. 하네스는 같은 세 층에서, 위험한 호출을 막거나 사람에게 넘기는 작업입니다. 측정 없이 가드레일만 늘리면 원인을 못 찾고, 평가 없이 도구만 추가하면 선택이 더 어려워집니다.

정리 — 그리고 내가 다음에 채워야 할 것

세 개념이 이렇게 맞물립니다.

• 도구는 결정적 시스템과 비결정적 에이전트 사이의 계약이다.
• 에이전트는 입력에 따라 원하는 결과를 이루려 스스로 도구를 고른다 — 이것이 사거리의 자유다.
• 그 자유에 세우는 신호등이 세 층의 평가다: 맞는 도구를 골랐나(선택), 제대로 실행됐나(실행), 결과가 쓸 만했나(결과).

여기서 개인적인 이야기를 덧붙이자면, 저는 여러 에이전트가 협업하는 멀티에이전트 시스템은 만들어봤고, 지난 글에서 말한 사업계획서 검증처럼 일부 도구 판단을 LLM에 맡긴 지점도 있었습니다. 다만 여러 도구 카탈로그 안에서 선택을 체계적으로 측정하고, 그 결과로 도구를 고치는 평가 루프를 돌려본 경험은 아직 없습니다. 경로가 정해진 철길 쪽에 더 익숙했던 셈입니다.

그래서 이번에 정리한 “도구 선택과 그 평가”는 저에게 지식의 정리인 동시에, 다음에 실전으로 채워야 할 영역입니다. 사거리를 만들어보긴 했지만, 그 사거리에 신호등을 평가 기준으로 세워본 경험은 이제부터 쌓아야 하는 것이죠. Anthropic이 반복해 강조하는 평가 주도(evaluation-driven) 방식 — 도구를 만들고, 현실적인 작업으로 평가하고, 그 결과로 도구를 개선하는 반복 — 이 그 출발점이 될 것 같습니다.

workflow에서 agent로, 그리고 도구와 그 평가로. 이 흐름을 따라오다 보니, 결국 좋은 에이전트를 만든다는 건 자유를 주는 기술만큼이나 그 자유를 검증하는 기술의 문제라는 게 분명해집니다.

---

📚 시리즈: AI 에이전트, 만들고 평가하기

1. Workflow와 Agent, 그리고 하네스 — LLM에게 얼마만큼의 자유를 줄 것인가
2. 에이전트의 도구(Tool)와 세 층의 평가 — 선택·실행·결과 ← 지금 글
3. 멀티에이전트의 두 숙제 — 토큰 비용과 안정성, 그리고 평가라는 해법
4. ReAct와 Plan-and-Execute를 LangGraph로 직접 구현하며 배운 것
5. 그래서 Agent에 데이터를 어떻게 입히나요? — 데이터가 작을 때의 온톨로지 설계
6. 제조업 AI 에이전트 프로젝트 1차 회고 — 평가, 저장소, 코드 정리에 대한 세 가지 교훈
7. AI 에이전트의 예시 데이터는 어떻게 다룰까 — 컨텍스트 엔지니어링부터 파인튜닝 준비까지