What are AI agent tools? 9 types, examples and how to choose

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AI 에이전트 도구는 언어 모델을 외부 정보와 실행 기능에 연결하며, 목적에 맞는 도구 선택과 선택적 검색, 명확한 설계, 보안 통제 및 성능 평가가 안정적인 운영을 좌우한다.

📌 핵심 요약

• AI 에이전트 도구는 언어 모델이 외부 시스템을 조회하거나 조작하도록 하는 정의된 함수다. 필요한 정보만 검색하면 제한된 컨텍스트 창의 과부하와 API 비용을 줄일 수 있다.
• 도구는 웹 검색·추출, RAG 검색, 코드 실행, 데이터베이스, 커뮤니케이션, 브라우저 자동화, 관측 가능성, 메모리, 보안의 9개 범주로 나뉜다.
• Firecrawl은 웹 기능을, Firecrawl Alexandria는 외부 데이터 제공자 연결을 담당한다. Composio, Zapier MCP, Pipedream Connect, Merge Agent Handler는 SaaS 앱 연결, E2B는 코드 실행, Cerbos는 권한 설정, Mastra는 에이전트 호스팅을 맡는 플랫폼으로 소개된다.
• 신뢰할 수 있는 도구 사용에는 명확한 매개변수 이름, 수정 방법을 알려주는 오류 메시지, ReAct 또는 계획 후 실행 방식이 중요하다. 코드 실행에는 샌드박스를, 운영 데이터베이스에는 읽기 전용 연결과 매개변수 검증을 적용하고, 보안에는 인증·인가·호출 제한·감사 로그 등을 함께 사용하도록 권고한다.
• 운영 규모를 확대하기 전에 도구 선택 정확도, 지연 시간, 작업당 비용, 실패 유형을 평가해야 한다. 관측 가능성 도구로 호출과 매개변수, 실행 시간, 토큰 소비, 오류를 추적하면 중복 호출과 예상 밖의 동작을 파악할 수 있다.

🧩 주요 포인트

1. 선택적 검색은 대량 정보를 통째로 입력하는 부담을 줄인다 → 웹·RAG·데이터베이스·메모리 도구를 필요한 맥락만 반환하도록 설계하는 것이 효율의 공통 기반이다.
2. 플랫폼마다 담당 기능이 다르고 브라우저 자동화는 API 호출보다 느리고 취약하다 → 제품 선택은 필요한 작업과 API 제공 여부를 기준으로 판단할 필요가 있다.
3. 결정적 함수와 비결정적 모델이 결합하면 호출 시점과 조합이 예상과 달라질 수 있다 → 오류 복구, 권한 경계, 관측 가능성을 정확도·지연 시간·비용 평가와 함께 다뤄야 한다.

🧠 상세 정리

1. 도구의 정의와 선택적 검색의 필요성

글은 1969년 Doug Engelbart의 시연을 도구가 인간과 컴퓨터의 상호작용을 바꾼 사례로 제시하고, AI 에이전트에도 비슷한 전환이 일어나고 있다고 설명한다. 도구는 언어 모델이 외부 시스템의 정보를 가져오거나 작업을 실행하게 하는 정의된 기능으로, 도구가 없는 모델은 학습된 지식으로 추론할 수 있지만 최신 사실 확인이나 외부 행동에는 한계가 있다. 도쿄의 우산 필요 여부를 묻는 예시에서는 일반적인 기후 설명과 달리, 날씨 도구를 사용하면 강수 확률 80%, 기온 18°C, 풍속 15km/h 같은 현재 정보를 바탕으로 답할 수 있다고 보여준다. 또한 Liu 등의 「Lost in the Middle」 연구를 인용해 긴 컨텍스트 중간에 묻힌 정보를 모델이 잘 찾지 못할 수 있다고 설명한다. 연락처 10,000개를 모두 프롬프트에 넣는 대신 search_customers 같은 도구로 필요한 결과만 반환하면 컨텍스트 낭비와 API 비용을 줄일 수 있다는 것이 핵심 논리다.

2. 웹 검색·추출과 변경 감지

웹 도구는 학습 데이터 이후의 최신 정보에 접근하게 하며, 검색은 관련 출처를 발견하고 추출은 특정 페이지에서 사용할 수 있는 내용을 가져오는 역할을 한다. 글은 웹사이트가 자주 바뀌고 정보 구조도 일정하지 않아 직접 스크래핑 기반을 구축하기 어렵다고 설명하며, Firecrawl이 추출의 복잡성을 처리해 Markdown이나 구조화된 JSON을 제공한다고 소개한다. 활용 예시로는 항공사 웹사이트의 항공편 정보 수집, 전자상거래 상품 모니터링, 뉴스 집계, 학술 자료 수집을 든다. Firecrawl의 /monitor는 자연어로 감시 대상을 지정하고 의미 있는 변경이 생기면 서명된 웹훅을 보내는 기능으로 설명된다. 변경이 없는 페이지나 잡음에 해당하는 차이에는 알림을 보내지 않으므로 에이전트가 처리할 정보를 줄이며, 토큰 사용을 최대 90% 절감할 수 있다는 제품 측 주장이 제시된다.

3. RAG 검색과 데이터 준비

RAG 검색 도구는 공개 웹에 없는 회사 정책이나 지원 티켓처럼 내부 지식에 에이전트를 연결한다. 글은 문서를 벡터 임베딩으로 변환해 데이터베이스에 저장하는 방식을 설명하면서, 그 전에 문서를 수집하고 정제하고 구조화하는 데이터 준비 단계가 필요하다고 강조한다. 이 단계를 생략하거나 부실하게 수행하는 것이 많은 RAG 시스템의 실패 원인이라는 것이 저자의 주장이다. 검색 단계에서는 의미 기반 검색으로 관련 구절을 찾되, 문서 전체를 반환하기보다 핵심 정책 문장과 그 주변 맥락만 제공하는 설계를 권한다. 이는 답변에 필요한 근거를 확보하면서 불필요한 토큰 소비를 줄이는 접근이며, 앞서 설명한 대량 컨텍스트 주입의 한계를 내부 지식 검색에도 동일하게 적용한 것이다.

4. 코드 실행과 데이터베이스 접근

코드 실행 도구는 복잡한 계산을 텍스트 추론에 맡기는 대신 Python 등의 프로그램을 생성하고 실행한 결과를 활용하게 한다. 계산과 데이터 분석을 위한 인터프리터뿐 아니라 버전 관리와 상호작용하는 개발 도구, 대규모 데이터 처리 도구도 이 범주에 포함된다. 저자는 운영 환경에서 에이전트가 만든 코드를 민감한 시스템과 분리하기 위해 샌드박스를 사용하고, 파일 접근·네트워크 요청·실행 시간 제한의 경계를 정해야 한다고 권고한다. 또한 리스트가 필요한 함수에 문자열이 전달됐다는 식으로 수정 방향이 드러나는 오류 메시지가 에이전트의 자체 복구를 돕는다고 설명한다. 데이터베이스 도구는 전체 데이터셋을 불러오는 대신 질문에 필요한 SQL을 실행해 결과를 반환하며, 운영 시스템에서는 데이터 유출 방지와 무결성 유지를 위해 읽기 전용 연결과 모든 매개변수의 검증을 명시적으로 적용하도록 권한다.

5. 커뮤니케이션과 브라우저 자동화

커뮤니케이션 도구는 Slack, Teams, 이메일 같은 협업 수단에 에이전트를 연결하고, 일정 도구와 작업 도구는 가용 시간 확인이나 티켓 생성·업무 배정을 수행한다. 글은 사이트를 수집하고 이전 버전과 비교한 뒤 변경 시 Gmail 알림을 보내는 n8n 경쟁사 모니터링 사례를 통해 여러 작업을 하나의 흐름으로 묶을 수 있다고 설명한다. 브라우저 자동화는 사람이 하듯 클릭하고 양식을 입력할 수 있지만, API 호출보다 느리고 화면 변화에 취약해 스크립트 수정이나 추가 토큰 소비가 필요하다는 한계가 있다. 그럼에도 정부 양식, 오래된 내부 도구, API가 없는 외부 서비스에서는 사실상 유일한 선택일 수 있다고 인정한다. 저자는 자신의 구축 경험을 근거로 Firecrawl의 프로그램 방식 데이터 추출이 브라우저 자동화가 필요했을 사례의 약 80%를 대체한다고 주장하지만, 이를 모든 환경에 적용되는 검증된 비율로 제시하지는 않는다.

6. 관측 가능성과 메모리

관측 가능성 도구는 에이전트가 실제로 어떤 작업을 하는지 확인하게 하며, 로깅은 도구 호출과 매개변수를 기록하고 추적은 답변에 이르는 실행 흐름을 보여주는 역할로 설명된다. 저자는 예상하지 못한 동작이나 원인을 알기 어려운 실패를 디버깅하려면 상세한 기록이 필수적이라고 강조한다. Anthropic의 도구 평가 안내를 인용하면서 정확도, 실행 시간, 토큰 소비, 도구 오류를 추적하면 불필요한 반복 호출 같은 패턴을 발견할 수 있다고 덧붙인다. 메모리 도구는 현재 대화의 맥락을 유지하는 단기 메모리와 선호 언어·진행 중인 프로젝트 정보를 세션 사이에 보존하는 장기 메모리로 구분된다. 메모리도 전부 불러오기보다 현재 주제와 관련된 내용만 검색해야 효율적이며, 코드 리뷰 요청에서는 과거의 코딩 선호만 가져오는 사례가 제시된다.

7. 보안과 에이전트 행동의 경계

보안 도구는 에이전트가 수행할 수 있는 행동의 경계를 정하는 범주로, 사용자 역할과 상황에 따라 요청된 작업을 수행할 권한이 있는지 확인한다. 정책 집행은 에이전트의 행동이 업무 규칙과 규정을 따르게 하는 기능으로 설명된다. 글은 자율 시스템의 행동이 현실에 영향을 줄 수 있다는 점을 근거로 인증, 인가, 호출 제한, 감사 로그를 여러 겹으로 적용하는 접근을 권고한다. 또한 정책 도구가 지출 한도를 강제하거나 위험도가 높은 작업에 사람의 승인을 요구할 수 있다고 제시한다. 이는 도구가 단순히 정보를 제공하는 기능을 넘어 외부 시스템에 실제 변화를 일으킬 수 있다는 앞선 설명과 연결되며, 유용한 실행 능력을 제공하는 동시에 허용 범위를 통제해야 한다는 논지다.

8. 플랫폼 선택과 설계·평가 기준

글은 2026년의 주요 플랫폼을 하나의 만능 제품으로 묶기보다 각 작업을 담당하는 도구로 소개하며, 이 분류는 2026년 1월 처음 작성되고 10월 갱신됐다고 밝힌다. Firecrawl은 웹 검색·스크래핑·브라우저 상호작용을, Firecrawl Alexandria는 외부 데이터 제공자 연결을 담당하고, Composio·Zapier MCP·Pipedream Connect·Merge Agent Handler는 SaaS 앱을 연결하는 제품으로 제시된다. E2B는 코드 실행, Cerbos는 권한 설정, Mastra는 에이전트 호스팅을 맡는다고 요약한다. 서두의 설계 지침은 모호하지 않은 매개변수 이름, 수정 방법을 설명하는 오류 메시지, ReAct 또는 계획 후 실행 방식이 적절한 도구 선택을 좌우한다고 강조한다. 평가 기준으로는 도구 선택 정확도, 지연 시간, 작업당 비용, 실패 유형을 제시하며 운영 규모 확대 전에 측정하도록 권한다. 다만 제공된 본문은 플랫폼 비교 도입부에서 끊기므로, 이후의 상세 제품 비교나 설계·평가 절차까지 확인할 수는 없다.

🧾 핵심 주장 / 시사점

• 웹 검색, RAG, 데이터베이스, 메모리는 서로 다른 정보원을 다루지만, 필요한 정보만 반환해 컨텍스트 사용을 줄인다는 공통 설계 원리를 가진다.
• 브라우저 자동화는 유연성이 있어도 속도와 유지보수 부담이 있으므로, API나 직접 추출의 이용 가능성과 실제 작업 요구를 함께 고려해야 한다.
• 도구의 신뢰성은 기능 자체뿐 아니라 모델이 도구를 선택하고 오류에서 회복하는 과정, 권한 통제, 실행 기록을 함께 관찰해야 판단할 수 있다.

✅ 액션 아이템

• 웹 검색·추출, RAG 검색, 코드 실행 등 9개 범주를 기준으로 필요한 기능과 플랫폼의 담당 작업을 대조.
• 명확한 매개변수 이름과 오류 메시지를 점검하고, 샌드박스·읽기 전용 연결·매개변수 검증 등 실행 경계를 확인.
• 운영 규모 확대 전에 도구 선택 정확도, 지연 시간, 작업당 비용, 실패 유형을 측정하고 관측 가능성 도구로 중복 호출을 분석.

❓ 열린 질문

• 현재 작업에 필요한 기능은 9개 범주 중 어디에 해당하며, 이를 담당할 플랫폼은 무엇인가?
• 브라우저 자동화가 필요한 작업에 API가 제공되며, 속도와 취약성을 고려해도 브라우저 자동화를 선택할 이유가 있는가?
• 도구 선택 정확도, 지연 시간, 작업당 비용, 실패 유형을 기준으로 운영 규모 확대를 판단할 때 허용 가능한 수준은 무엇인가?