3. 에이전트의 도구(Tool)란 무엇인가?

에이전트 도구의 이해와 기획자의 역할

지난 글에서 에이전트의 5가지 핵심 구성 요소(Goal, Context, Tool, Judge, Sandbox)를 개념 수준에서 짚어봤다면, 이번 편은 기획자가 가장 머리를 싸매야 하는 '도구(Tool)'를 설명할 예정이다.

단순한 챗봇과 능동적인 에이전트를 가르는 결정적인 차이가 이 도구를 사용하느냐, 마느냐로 갈릴 만큼 도구란 에이전틱한 경험을 제공하기 위해 반드시 이해해야 하는 개념이다.

LLM에게 손과 발이 생긴다는 것

우리가 만드는 에이전트의 엔진은 LLM이다. 하지만 엔진만 있어서는 아무것도 할 수 없다. 이력서를 분석해서 "이 지원자에게 합격 메일을 보내야겠다"라고 판단할 순 있어도, LLM이 직접 우리 서비스의 메일 전송 버튼을 누를 수는 없기 때문이다.

이때 LLM에게 쥐여주는 손과 발이 바로 '도구(Tool)'다.

기술적으로 Tool은 우리가 이미 만들어둔 API 또는 함수라고 할 수 있다. 과거 '펑션 콜(Function Call)'이라 불리던 개념의 진화형이다. 에이전트에게 "메일 발송 API를 사용할 수 있는 도구"가 있다고 LLM에게 알려주면, LLM은 스스로 판단해 필요할 때 그 API를 호출해 달라고 요청한다. 이를 통해 텍스트만 뱉던 LLM이 실제 서비스의 기능을 자율적으로 조작할 수 있게 된다.

에이전트는 도구를 어떻게 사용할까?

말로만 설명하면 와닿지 않으니, 실제 에이전트가 도구를 활용해 사용자의 요청을 해결하는 연쇄적인 흐름을 시퀀스 다이어그램으로 살펴보자. (Spring AI 공식 문서의 Tool 레퍼런스를 참고한 구조다.)

도구 호출 흐름 ©작가편집

이 시퀀스의 핵심은'사고-행동-피드백'의 루프(ReAct 패턴)다.

LLM은 한 번에 정답을 뱉는 것이 아니다. 사용자의 요청이 들어오면 LLM은 자신에게 쥐여진 도구 목록을 쭉 훑어보고 "아, 이 요청을 해결하려면 Tool 1(예: 이력서 조회 API)이 필요하겠군"이라고 판단해 호출을 지시한다.

우리 시스템이 API를 실행하고 그 결괏값을 다시 LLM에게 던져주면, LLM은 그 새로운 정보를 바탕으로 다시 사고한다. "이력서를 확인했으니, 이제 Tool 2(예: 평가 척도 등록 API)를 써야겠다"며 다음 행동을 결정하는 식이다.

채용 설정 에이전트 예시

이론적인 설명만으로는 감이 잘 오지 않을 테니, 실제 제품에 들어가는 '채용 설정 에이전트'를 예로 들어보자. 이 에이전트는 다음과 같은 사내 API들이 '사용 가능한 도구'로 쥐여져 있다.

평가 척도 조회, 평가 척도 생성, 평가 척도 삭제

지원서 템플릿 조회, 지원서 템플릿 등록, 지원서 템플릿 수정, 지원서 템플릿 복제, 지원서 템플릿 삭제

이때 사용자가 채팅창에 이렇게 입력했다고 가정해 보자.

"최근에 등록한 지원서 템플릿의 이름을 알려줘. 아, 그리고 새로운 '기획자' 채용 시 사용할 평가 척도를 하나 만들 건데, '7점 리커트 척도'를 기준으로 제안해줘."

단순한 챗봇(LLM)이라면 "저는 외부 시스템에 접근할 권한이 없어 템플릿 이름을 알 수 없습니다. 7점 척도는 다음과 같이..."라는 답을 줄 것이다. 하지만 도구를 쥔 에이전트는 아래 다이어그램과 같은 시퀀스로 사고하고 행동한다.

도구 호출 예시 ©작가편집

이 흐름을 보면 에이전트가 어떻게 동작하는지 알 수 있다.

1. 목적에 맞는 도구 선택

8개의 도구 목록 중, 사용자의 첫 번째 질문을 해결하기 위해 정확히 지원서 템플릿 조회 도구를 골라낸다.

2. 데이터 활용

조회 도구로 알아낸 사내 데이터(템플릿 이름)와 LLM 본연의 지능(7점 리커트 척도 생성 능력)을 매끄럽게 합쳐서 하나의 답변으로 구성한다.

3. 다음 액션 유도 (AX 경험)

제안에서 끝나는 것이 아니라 "바로 생성해 드릴까요?"라고 물으며 자연스럽게 평가 척도 생성 도구의 사용을 유도한다. 사용자가 승인하면, 에이전트는 기획자가 미리 만들어둔 생성 API를 찔러 실제 서비스에 데이터를 저장한다.

이처럼 하나의 프롬프트 안에서 조회(Read)와 생성(Create)을 넘나들며 사용자 경험이 끊임 없이 연결된다. 이것이 기존 UI 클릭 기반의 경험을 에이전트 경험(AX)으로 전환할 때 그릴 수 있는 이상적인 그림이다.

도구가 많을 수록 좋은 건 아니다.

이런 구조를 이해하고 나면 보통은 신이 난다. "사내에 있는 조회, 생성 API를 전부 도구로 붙여버리면 끝나는 거 아니야?"라는 생각이 먼저 들기 때문이다.

우리 채용 서비스로 치면 이력서 조회, 채용 공고 수정, 면접관 문자 알림, 일정 등록 API 등을 모조리 에이전트의 손에 쥐여주는 식이다.

하지만 실제 결과를 보다보면 이것 또한 쉽지 않다. 에이전트에게 쥐여준 도구의 개수가 늘어날수록 크게 아래와 같은 문제가 발생한다.

1. 추론 정확도의 하락

LLM이 수십 개의 도구 정의를 읽다가 헷갈려 하기 시작한다. '지원자 이력서 조회'와 '지원자 목록 조회'처럼 비슷한 목적의 도구가 있으면 엉뚱한 도구를 호출하거나, 필수 파라미터를 빼먹는 등 할루시네이션 빈도가 늘어난다.

2. 비용 증가와 속도 저하

에이전트가 도구를 쓰려면 시스템 프롬프트 안에 도구들의 스펙(이름, 설명, 파라미터 형식)이 텍스트로 전부 들어가 있어야 한다. 도구가 많아질수록, 특히 '조회' 도구를 최적화하지 않을 수록 매번 LLM을 호출할 때마다 어마어마한 인풋 토큰을 소모하게 되고, 이는 곧 비용 증가와 응답 속도 저하로 직결된다.

결국 PM이 해야 할 일은 존재하는 모든 API를 무작정 에이전트에게 던져주는 것이 아니다.

LLM이 도구를 오해 없이 정확하게 선택할 수 있도록 에이전트의 프롬프트 및 도구의 이름과 설명을 뾰족하게 다듬어야 하고, 사용자의 의도에 따라 필요한 도구 목록만 동적으로 주입하는 식의 정교한 가지치기가 필요하다.

이론적인 개념은 여기까지다. 이어지는 다음 글에서는 이 도구들을 실무에서 어떻게 기획하고 연결하는지, 프론트엔드·백엔드와 기존 기능을 에이전트 경험(AX)으로 기획 프로세스를 풀 예정이다.

ⓒ 2026. 327roy All rights reserved.