에이전트를 위한 도구 구축 — 에이전트와 함께

Prompt Engineering 구독자 190,000명

요약

이 영상은 에이전트 기반 시스템에서 도구 구현 방식이 어떻게 변화하는지 짚어보고, 효과적인 도구를 설계·운영하기 위한 핵심 원칙을 제시합니다. 작업에 맞는 도구 선택부터 도구 그룹화, 컨텍스트 관리, 토큰 효율화, 프롬프트 엔지니어링에 이르기까지 실용적인 인사이트를 다룹니다. 마지막으로 실제 진화(evolve) 테스트 사례를 통해 에이전트와 협업하며 도구를 반복 개선하는 방법을 설명합니다.

주요 키워드

Agentic System Tool Implementation Context Engineering Prompt Engineering Token Efficiency Namespace Evolution Test Browser Automation Real-world Test Cases Stagehand

하이라이트

🔑 에이전트 성능은 모델 지능뿐 아니라 도구 설계에 달려 있다: 작업 맥락을 고려한 도구가 에이전트의 의사결정을 효율적으로 돕는다.
⚡ 전통적 함수형 도구와 달리 자연어 질의를 입력으로 받는 에이전트 도구는 실행 단계마다 다른 계획을 세워 유연한 대응이 가능하다.
🌟 4단계 프로세스(프로토타입→진화 테스트→코딩 에이전트 협업→재측정)를 통해 반복적으로 도구를 개선해야 실사용 환경에서 안정적인 결과를 얻을 수 있다.
📌 작업에 맞는 도구를 선택하고 여러 기능을 하나의 도구로 묶어 컨텍스트 창에 불필요한 정보가 쌓이지 않도록 관리해야 한다.
🚀 도구 반환값은 고신호(high-signal) 정보 위주로, 포맷(XML·JSON 등)은 모델별 특성에 따라 결정해 에이전트가 이해하기 쉽게 제공한다.
🔍 네임스페이싱으로 비슷한 기능의 도구를 그룹화하면 에이전트가 혼란 없이 올바른 도구를 호출할 확률이 높아진다.
⚙️ 토큰 효율성을 위해 페이징·범위 지정·필터링 같은 전략을 도입해 컨텍스트 창에 필요한 만큼만 정보를 넣어야 한다.
✍️ 도구 설명에 대한 프롬프트 엔지니어링을 통해 입출력 변수 이름, 기능 사양, 전문 용어 정의를 명확히 제시해 에이전트의 오작동을 예방한다.
🔄 복잡한 실제 업무 흐름을 반영한 진화 테스트(evolve set)를 구성하고, 에이전트 루프를 통해 피드백으로 도구를 지속 개선해야 한다.

용어 설명

Agentic System

에이전트 기반 시스템: 스스로 계획을 세워 도구 호출·추가 질문 등을 수행하는 지능형 시스템

Context Window

컨텍스트 창: LLM에 입력할 수 있는 대화·도구 결과의 최대 토큰 범위

Prompt Engineering

프롬프트 엔지니어링: 에이전트가 도구를 선택·사용하도록 유도하는 최적의 지시문 작성 기법

Namespace

네임스페이싱: 비슷한 도구를 그룹화해 이름 앞뒤에 접두·접미사를 붙여 구분하는 방법

Token Efficiency

토큰 효율성: 컨텍스트 창에 유의미한 정보만 적절한 양으로 채워 모델 비용을 절감하는 전략

에이전트 성능이 단순히 모델 능력만이 아니라 도구 설계에 크게 좌우된다는 점을 강조합니다. 자연어 질의를 처리하고 계획·실행 단계를 거치는 에이전트 시스템의 기본 작동 방식을 소개합니다.

[00:00] 에이전트를 위한 더 나은 도구 구축의 중요성을 강조하며, 에이전트의 효과성은 사용 가능한 도구들과 모델의 지능에 크게 의존한다고 설명합니다.

[00:21] Anthropic의 블로그 포스트 '에이전트로 에이전트를 위한 효과적인 도구 구축'에서 영감을 받은 내용임을 소개하며, 주요 발견점과 실용적 통찰을 살펴보겠다고 합니다.

전통적 함수형 도구가 입력→출력의 결정론적 시스템이라면, 에이전트 기반 도구는 계획에 따라 다양한 단계를 동적 실행함을 설명합니다. 기존 스택에서 어떻게 재구성해야 할지 짚어봅니다.

[00:37] 전통적인 소프트웨어 엔지니어링과 에이전틱 시스템의 차이점을 설명합니다. 전통적인 방식은 결정론적 시스템으로 예측 가능한 결과를 제공하지만, 에이전틱 시스템은 자연어 쿼리를 입력받아 매번 다른 단계로 작동합니다.

① 초기 프로토타입 구현 ② 진화(evolve) 테스트 실행 ③ 코딩 에이전트 협업 ④ 성능 재측정의 반복 구조를 제시합니다. 측정 없이는 개선이 불가능하므로 테스트 셋 구성의 중요성을 강조합니다.

[01:25] 좋은 도구를 구축하는 4단계 프로세스를 소개합니다: 초기 프로토타입 구현, 평가 실행, 코딩 에이전트와의 협업을 통한 개선, 그리고 반복적인 평가 과정입니다.

① 작업에 맞는 도구 선택 ② 도구 그룹화 ③ 컨텍스트 엔지니어링 ④ 프롬프트 엔지니어링 ⑤ 소규모 개선의 힘을 다섯 가지 원칙으로 요약해 전반적 흐름을 안내합니다.

[02:33] 도구 구현의 핵심 원칙들을 제시합니다: 올바른 도구 선택, 도구 그룹화를 통한 에이전트의 선택 개선, 그리고 이후에 다룰 컨텍스트 엔지니어링과 프롬프트 엔지니어링의 중요성을 언급합니다.

브라우저 자동화 플랫폼 Browserbase를 통해 Puppeteer·Playwright를 호스팅하는 방식을 설명합니다. 오픈소스 Stagehand 프레임워크로 자연어 명령만으로 브라우저 작업을 실행하는 예시를 보여줍니다.

[02:58] 효과적인 프롬프트 엔지니어링을 통해 LLM이 적절한 도구를 선택할 수 있도록 돕는 방법과 더 많은 도구가 반드시 더 나은 결과를 의미하지 않는다는 점을 설명합니다.

[03:16] 에이전트 작업 플로우의 구조를 소개하며, 도구의 입출력이 모델의 컨텍스트 윈도우에 미치는 영향과 유용한 정보만 보존해야 하는 중요성을 강조합니다.

[03:49] 브라우저 베이스라는 AI 에이전트용 웹 브라우징 도구를 소개하며, Puppeteer와 Playwright를 호스팅하는 클라우드 플랫폼으로서의 기능을 설명합니다.

[04:18] 스테이지 핸드라는 오픈소스 AI 브라우저 자동화 프레임워크의 특징을 설명하며, 자연어를 통한 브라우저 상호작용과 커스텀 스키마를 통한 데이터 스크래핑 기능을 소개합니다.

[05:46] 첫 번째 원칙으로 작업에 적합한 도구 선택의 중요성을 제시하며, 단순히 기존 소프트웨어 기능을 도구로 래핑하는 일반적인 오류에 대해 경고합니다.

단순히 모든 API를 래핑해 도구로 제공하는 것이 아니라, 에이전트가 컨텍스트 창을 낭비하지 않도록 단일 도구에 연속 작업을 캡슐화해야 합니다. 주소록 검색 예시를 통해 유의미 결과만 반환하는 설계를 제안합니다.

[06:12] 에이전트용 도구 설계 시 LLM의 컨텍스트 윈도우를 고려해야 합니다. 하나의 도구는 여러 작업의 연쇄를 가질 수 있으며, 에이전트가 활용할 수 있는 의미 있는 결과를 생성해야 합니다.

[06:27] 주소록 검색 예시를 통해 설명하면, 전통적인 소프트웨어 엔지니어링에서는 모든 연락처를 메모리에 로드하고 반복하여 일치하는 결과를 반환합니다.

[06:45] 에이전틱 시스템에서는 여러 도구를 작성할 수 있지만, 500개 연락처를 모두 반환하면 각 연락처가 50토큰이라 가정했을 때 약 25,000토큰이 소모되어 컨텍스트 윈도우를 쓸모없는 정보로 채우게 됩니다.

[07:17] 좋은 접근 방법은 전통적인 소프트웨어 엔지니어링 설정을 사용해 검색하고, 의미 있는 연락처의 작은 하위 집합만 반환하는 도구를 만드는 것입니다. 단순한 RAG 시스템일 수 있으며, 에이전트는 보통 하나나 두 개의 연락처만 찾고 있기 때문입니다.

[07:45] 도구를 설계할 때는 인간이 도구와 상호작용하는 방식을 고려해야 합니다. 검색 메커니즘을 사용하되 탐색하지 않고, 필터링하되 스캔하지 않으며, 탐색하되 반복하지 않아야 합니다.

비슷한 기능·서버 기반 도구를 이름 공간으로 묶어 접두·접미사를 붙이면, 에이전트가 적절한 도구를 선택하기 쉬워집니다. 접두·접미사 위치에 따른 성능 차이를 실험해 볼 것을 권장합니다.

[08:00] 실제 예시로는 사용자 목록, 이벤트 목록, 이벤트 생성 같은 세 개의 분리된 도구 대신, 가용성을 찾고 이벤트를 일정에 추가하는 일정 이벤트 도구를 구현하여 여러 단계를 하나의 도구에 래핑하는 것입니다.

[08:17] 또 다른 예로는 로그 읽기 도구 대신 관련 로그와 주변 텍스트만 반환하는 검색 도구를 구현하는 것입니다. 다시 강조하면, 검색하되 스캔하지 마세요.

[08:29] 도구 네임스페이싱의 중요성도 있습니다. 현재 수십 개의 MCP를 가지고 있고 각각이 유사한 기능을 구현할 수 있어, 에이전트가 도구 선택 시 혼란스러워할 가능성이 높습니다.

[08:53] 여러 MCP 서버가 각각 검색, 생성, 업데이트, 삭제 등을 구현하고 있을 때, MCP 서버 기준으로 그룹화하지 않으면 유사한 이름 때문에 에이전트가 혼란스러워합니다. 하지만 슬랙 메시지용 네임스페이스와 지라 특화 도구들로 그룹화하면 이러한 문제를 해결할 수 있습니다.

[09:18] 도구에 네임스페이스 접두사나 접미사를 추가하면 에이전트가 작업에 맞는 도구를 더 잘 선택할 수 있습니다. 시스템이 발전해도 작은 뉘앙스 변화에 영향받을 수 있어 실험이 필요합니다.

무턱대고 많은 정보를 반환하기보다 에이전트가 이해하기 쉬운 필드(이름·이미지 URL 등) 위주로 고신호 정보를 제공해야 합니다. XML·JSON 등 포맷은 모델 특성에 맞춰 선택합니다.

[10:09] 도구에서 정보를 반환할 때는 모든 정보보다는 높은 신호 정보만 선별하는 것이 중요합니다. UUID 같은 기술적 식별자보다는 자연어 이름이나 설명적 필드를 사용하는 것이 효과적입니다.

[11:11] 반환 형식은 모델 훈련에 따라 달라집니다. Claude는 XML을, OpenAI 모델들도 XML을 선호하는 경향이 있어 사용 모델에 맞는 형식을 선택해야 합니다.

컨텍스트 창의 양뿐 아니라 질도 중요합니다. 페이징·범위 지정·필터링을 통해 필요한 토큰만 반환하도록 하고, 다수 도구 호출 시 누적 토큰 비용을 관리하는 전략을 다룹니다.

[12:05] 토큰 수 측면에서 도구 응답을 최적화하는 것이 중요합니다. 컨텍스트 관리는 품질뿐만 아니라 양적 측면에서도 신경써야 할 부분입니다.

[12:23] 에이전트가 토큰 효율적인 전략을 사용하도록 권장하는 방법들을 소개합니다. 작고 타겟된 검색을 통해 단일 광범위 검색보다 효과적으로 정보를 찾을 수 있습니다.

[12:42] 도구 설명을 위한 프롬프트 엔지니어링의 중요성을 강조합니다. 에이전트가 도구를 선택할 때 설명과 입출력을 보므로, 명확하고 상세한 정보 제공이 필수입니다.

도구가 수행할 기능, 입출력 변수명, 전문 용어 정의 등을 신입 개발자에게 문서화하듯 명확히 작성해야 합니다. 애매모호함을 제거해 에이전트의 오작동을 방지합니다.

[13:15] 새 인턴을 훈련시키는 것처럼 에이전트에게도 명확한 정보를 제공해야 합니다. 특수 쿼리 형식, 전문 용어, 리소스 간 관계를 명시적으로 설명하여 모호함을 제거해야 합니다.

[13:48] 의사소통이 좋은 에이전트 시스템과 실패한 시스템을 구분하는 핵심 요소입니다. 도구 선택에서의 혼란을 방지하려면 명확한 커뮤니케이션이 중요합니다.

진짜 사용 사례를 반영한 진화 테스트 셋(evolve set)을 구성하고, 에이전트 루프를 통해 피드백 기반으로 도구를 지속 개선하는 워크플로우를 제안합니다. 복합 시나리오 테스트의 중요성을 강조합니다.

[14:01] 에이전트로 도구를 개선하는 방법을 설명합니다. 초기 구현 후 실제 세계 평가 테스트 케이스를 만드는 것이 핵심입니다.

[14:13] 합성 예제의 문제점을 지적합니다. 실제 사용 사례와 관련 없는 합성 테스트에서는 성공하지만 실제 환경에서는 실패하는 경우가 많습니다.

[14:43] 에이전트와 도구를 반복 개선하기 위해서는 충분한 문서와 정보를 제공해야 합니다. 복잡한 시나리오에서 여러 도구를 조합하여 테스트하는 것이 중요합니다.

[15:12] 현실적인 테스트 사례의 예를 제시합니다. 단순한 '미팅 잡기' 대신 'Jane과 미팅 잡고, 프로젝트 노트 첨부하고, 회의실 예약하기' 같은 복합적인 작업이 더 현실적입니다.

[15:57] 복잡한 실제 세계 테스트의 중요성을 재강조합니다. 간단한 평가로는 실제 복잡성을 다룰 수 없어 시스템이 실패할 수 있습니다.

[16:11] 에이전트 루프를 통한 지속적 개선 방법을 설명합니다. 평가 세트로 테스트하고, 피드백을 수집하여 에이전트와 함께 도구를 개선하는 과정입니다.

[00:00] 에이전트를 위한 더 나은 도구를

[00:01] 구축하는 방법에 대해 이야기해보죠.

[00:03] 에이전트의 효과는 실제로

[00:05] 사용 가능한 도구들과

[00:07] 모델의 지능에 크게 의존합니다.

[00:10] 그래서 이를 분석해보고

[00:12] 실용적인 통찰을 살펴보겠습니다.

[00:13] 마지막에는 도구 구현에 대한

[00:16] 여러분의 사고방식을

[00:18] 다시 생각하게 만들 것입니다.

[00:21] 이 영상의 아이디어는

[00:22] Anthropic에서 작성한

[00:25] 에이전트로 에이전트를 위한 효과적인 도구 구축이라는

[00:28] 블로그 포스트에서 나왔습니다.

[00:30] 주요 발견점들과 실용적인 통찰을

[00:33] 살펴보겠습니다. 하지만 그 전에

[00:35] 에이전틱 시스템과 함께

[00:37] 소프트웨어 엔지니어링이

[00:40] 어떻게 변화하는지 생각해봐야 합니다.

[00:42] 전통적인 소프트웨어 엔지니어링에서는

[00:44] 도구의 핵심 기능을 함수로

[00:47] 감싸서 구현합니다.

[00:49] 이들은 결정론적 시스템이죠.

[00:51] 입력을 제공하면 결정론적인

[00:54] 응답을 기대합니다.

[00:56] 하지만 도구들은 실제로

[00:59] 변화하고 있습니다. 일반적으로 입력은

[01:02] 자연어 쿼리입니다.

[01:04] 그러면 에이전트는 자체 계획에 따라

[01:06] 취할 단계들을 결정합니다.

[01:08] 도구를 호출하거나, 내부 지식을

[01:11] 사용하거나, 심지어 후속 질문을

[01:13] 할 수도 있습니다.

[01:15] 같은 질문을 할 때마다

[01:18] 에이전트가 내놓는 단계들은

[01:20] 다르게 나타납니다.

[01:22] 일반적으로 이러한 에이전틱 시스템들은

[01:25] 전통적인 소프트웨어

[01:27] 엔지니어링 스택의 일부입니다.

[01:30] 그래서 이러한 시스템을 구현하는 방식을

[01:33] 다시 생각해봐야 합니다.

[01:35] 블로그 포스트는

[01:38] 좋은 도구를 구축하는

[01:41] 4단계 프로세스에 대해 이야기합니다.

[01:43] 우리의 초점은 주로

[01:45] 더 나은 도구 작성의

[01:48] 핵심 원칙이 무엇인지에 있습니다.

[01:50] 하지만 완성도를 위해

[01:53] 먼저 핵심 기능을 구현하는

[01:55] 초기 프로토타입부터 시작하고 싶습니다.

[01:58] 그 다음 구현한 도구에서

[02:01] 평가를 실행하고자 합니다.

[02:03] 그 다음 코딩 에이전트와

[02:05] 협업하고자 합니다.

[02:07] 기본적으로 코딩 에이전트의

[02:10] 지능을 활용해서

[02:12] 도구 설명과 도구 구현을

[02:15] 개선하도록 도와주는 것이죠.

[02:17] 마지막에는 평가를 실행합니다.

[02:20] 측정할 수 없으면

[02:21] 개선할 수 없기 때문이죠.

[02:23] 이것은 일반적으로 반복적인 과정이지만

[02:26] 도구 자체의 구현에 있어서는

[02:28] 제가 염두에 두기를 권하는

[02:31] 핵심 원칙들이 있습니다.

[02:33] 첫 번째는 구현할

[02:35] 올바른 도구를 선택하는 것입니다.

[02:38] 걱정하지 마세요,

[02:41] 이 모든 것들에 대한 세부사항을

[02:43] 이야기할 예정입니다.

[02:46] 그리고 서로 다른 도구들을

[02:48] 함께 그룹화할 수 있는지

[02:50] 확인하세요.

[02:53] 이것은 에이전트가 더 나은 도구를

[02:56] 선택하는데 도움이 됩니다.

[02:58] 효과적인 프롬프트 엔지니어링 도구

[03:00] 설명을 작성하는 방법에 대해 말씀드리겠습니다

[03:02] 이는 LLM이 적절한 도구를 선택하는데

[03:04] 도움이 될 것입니다. 그리고 더 많은 도구가

[03:07] 항상 더 나은 결과로 이어지는 것은 아닙니다.

[03:10] 전통적인 소프트웨어

[03:11] 엔지니어링과 마찬가지로, 작은 개선이

[03:14] 극적인 향상을 가져다줍니다.

[03:16] 이제 이 각각에 대해

[03:17] 더 구체적이고 자세한

[03:20] 정보를 가지고 이야기해보겠습니다. 하지만

[03:22] 이 플로우를 보시기 바랍니다. 예를 들어

[03:25] 에이전트에게 제공되는 작업이 있다고 해봅시다.

[03:27] 에이전트는 각각의 하위 작업에 대해

[03:29] 다양한 도구들을 선택할 수 있습니다. 이제

[03:32] 도구의 입력과 출력이

[03:36] 모델이나 LLM, 또는 에이전트의

[03:39] 컨텍스트 윈도우에 추가될 것이고, 우리는

[03:42] 이 컨텍스트 윈도우에서

[03:44] 유용한 정보만을 보존하는 방법을

[03:47] 신중히 생각해야 합니다. AI 에이전트를 위한

[03:49] 좋은 도구의 정말 좋은 예가 바로 브라우저 베이스입니다.

[03:53] 이들은 AI 에이전트와 애플리케이션을 위한

[03:56] 웹 브라우징 기능을 제공합니다. 그러니까

[03:59] 이들을 Puppeteer나

[04:01] Playwright와 같은 도구들을 호스팅할 수 있는

[04:04] 클라우드 플랫폼으로 생각해보세요. 이들은 AI

[04:06] 에이전트와 상호작용할 수 있고, 또한

[04:09] 오늘 영상의 스폰서이기도 합니다.

[04:11] 이는 매우 확장 가능하고 빠르며 안전한

[04:14] 플랫폼으로, 브라우저 자동화를 위한

[04:16] 자신만의 커스텀 에이전트를 만들 수 있게 해줍니다.

[04:18] 이들은 기존 브라우징 도구들을 가지고 있습니다.

[04:21] 워크플로우 자동화를 가능하게 하고

[04:23] 웹사이트에서 데이터를

[04:26] 웹 스크래핑할 수도 있게 해줍니다. 하지만 제가

[04:28] 가장 좋아하는 기능은 스테이지 핸드라고 불립니다.

[04:31] 이것은 이들의 오픈소스 AI 브라우저

[04:34] 자동화 프레임워크입니다. 이것은 액션을 정의하고

[04:37] 에이전트에게 작업을 할당함으로써

[04:41] 브라우저 자동화를 가능하게 합니다. 그리고

[04:43] 이것은 여러분이 자신의

[04:47] 애플리케이션에서 사용하기 시작할 수 있는

[04:49] 매우 강력한 SDK와 함께 제공됩니다. 이 SDK는

[04:52] 컴퓨터 사용 에이전트를 포함한

[04:55] 다양한 기존 에이전트들을 가지고 있고

[04:57] Playwright와 완전히 호환됩니다. 그래서 브라우저

[05:00] 자동화가 스테이지 핸드로

[05:03] 매우 쉬워집니다. 이것은

[05:05] 자연어를 통해 Playwright와 상호작용할 수 있게 해줍니다.

[05:08] 예를 들어, 웹 페이지에 가려면

[05:11] 이것이 사용할 명령입니다.

[05:13] 또는 어떤 액션을 취하고 싶다면

[05:15] 자연어로 그것을 설명하기만 하면 됩니다.

[05:18] 또한 컴퓨터 사용 에이전트를 가능하게 합니다. 그리고

[05:20] 가장 좋은 부분은 어떤 웹사이트에서든

[05:23] 데이터를 스크래핑하고 싶다면

[05:25] 자신만의 커스텀 스키마를 정의할 수 있다는 것입니다.

[05:28] 에이전트가 가서 그 데이터를 추출하고

[05:30] 여러분에게 반환해줄 것입니다. 이것은

[05:33] 웹 브라우저와 상호작용할

[05:36] 에이전트들을 위한 매우 유용한

[05:38] 도구입니다. 꼭 확인해보세요.

[05:41] 링크는 영상 설명에 있을 것입니다.

[05:44] 이제 영상으로 돌아가서, 첫 번째 원칙은

[05:46] 작업에 적합한 도구를 선택하는 것입니다.

[05:48] 이제 더 많은 도구가 더 나은

[05:50] 결과를 얻는다는 의미는 아닙니다. 실제로 그들은

[05:54] 사람들이 단순히 기존 소프트웨어

[05:56] 기능이나 API를

[05:57] 도구로 래핑해서

[06:00] 에이전트에게 도구로 제시하는 일반적인 오류를

[06:04] 보았다고 말합니다. 이것은 도구를

[06:07] 구현하는 방법에 대해 생각하는

[06:09] 올바른 방식이 아닙니다. 여러분은

[06:12] LLM의 컨텍스트 윈도우를 고려해야 합니다. 하나의 도구는

[06:16] 여러 다른 작업들의 연쇄를 가질 수 있고

[06:18] 에이전트가 사용할 수 있는 의미 있는 결과를

[06:21] 생성하기를 원합니다. 자, 여기 주소록

[06:24] 검색의 매우 간단한 예시가 있습니다.

[06:27] 전통적인 소프트웨어 엔지니어링에서는

[06:30] 모든 연락처를 메모리에 로드하는

[06:31] 시스템을 구현할 수 있습니다. 그런 다음

[06:33] 각 연락처를 반복하고 일치하는 것이 있으면

[06:36] 그 결과가 반환됩니다. 이제 에이전틱

[06:39] 시스템과 함께 사용하고 싶다면

[06:42] 여러 다른 도구들을 작성할 수 있습니다.

[06:45] 예를 들어 연락처 목록을 보여주는

[06:47] 도구가 하나 있습니다. 이 도구는

[06:49] 모든 500개의 연락처를 반환합니다.

[06:51] 그런데 생각해보면 각 연락처가

[06:54] 50개의 토큰이라고 하면

[06:57] 약 25,000개의 토큰을 보게 됩니다.

[06:59] 그러면 에이전트가 각각을 토큰별로

[07:02] 살펴보거나 토큰별로 살펴보는

[07:05] 다른 도구를 가질 수 있습니다.

[07:07] 결국 에이전트의 컨텍스트 윈도우를

[07:09] 쓸모없는 정보로 채우게 됩니다.

[07:12] 이것 대신에 좋은 접근 방법은

[07:14] 전통적인 소프트웨어 엔지니어링 설정을 사용해

[07:17] 검색하고 의미 있다고 생각되는

[07:20] 연락처의 매우 작은 하위 집합만

[07:24] 반환하는 도구입니다. 단순한

[07:26] RAG 시스템일 수 있고 그 결과를

[07:29] 에이전트에게 전달합니다. 왜냐하면

[07:32] 에이전트는 단지 하나나 두 개의

[07:34] 연락처를 찾고 있기 때문입니다.

[07:37] 도구를 설계할 때 생각하는 방식은

[07:40] 인간이 그 도구들과 어떻게

[07:42] 상호작용하는지를 생각해야 한다는 것입니다.

[07:45] 예를 들어, 검색 메커니즘을 원하지

[07:47] 탐색을 원하지 않고, 필터링을 원하지

[07:49] 스캔을 원하지 않으며, 탐색을 원하지

[07:51] 반복을 원하지 않습니다.

[07:52] 여기 더 많은 예시들이 있습니다.

[07:55] 사용자 목록, 이벤트 목록, 이벤트 생성 같은

[07:57] 세 개의 서로 다른 도구를 구현하는 대신,

[08:00] 가용성을 찾고 이벤트를 일정에 추가하는

[08:03] 일정 이벤트 도구 구현을 고려해보세요.

[08:05] 본질적으로 여러 다른 단계를

[08:07] 하나의 도구 안에 래핑하는 것입니다.

[08:09] 또 다른 예는 로그 읽기 도구를

[08:12] 구현하는 대신 관련 로그와

[08:14] 주변 텍스트만 반환하는

[08:17] 검색 도구 구현을 고려하는 것입니다.

[08:19] 다시 말하지만, 검색하되 스캔하지 마세요.

[08:21] 또 다른 아이디어는 도구에

[08:24] 네임스페이스를 적용하는 것입니다.

[08:26] 비슷한 도구들을 함께 그룹화하고 싶습니다.

[08:29] 현재 우리는 에이전트가 접근할 수 있는

[08:32] 수십 개의 MCP를 가지고 있고

[08:34] 각각이 매우 유사한 기능을

[08:37] 구현하고 있을 수 있습니다.

[08:39] 에이전트가 어떤 도구를 선택할지

[08:42] 결정해야 할 때, 혼란스러워할

[08:44] 가능성이 높습니다. 자, 여기 매우

[08:46] 간단한 표현이 있습니다.

[08:48] 다양한 MCP 서버들이 있다고 합시다.

[08:51] 각각이 검색, 생성, 업데이트, 삭제 등을

[08:53] 구현하고 있습니다. 그런데

[08:54] MCP 서버를 기준으로 그룹화하지 않으면

[08:56] 유사한 이름을 사용할 때

[08:58] 에이전트가 혼란스러워할 것입니다.

[09:00] 하지만 함께 그룹화하면, 예를 들어

[09:03] 슬랙 메시지를 위한 네임스페이스가 있고

[09:06] 지라에 특화된 도구들이 있다면

[09:09] 에이전트가 혼란스러워하지 않을 것입니다.

[09:11] 함께 그룹화하면, 예를 들어

[09:13] 슬랙 메시지를 위한 네임스페이스가 있고

[09:16] 지라에 특화된 도구들이 있습니다.

[09:18] 각 도구에 이런 접두사를 추가하면

[09:21] 에이전트가 어떤 작업에

[09:24] 어떤 도구를 사용할지

[09:26] 결정하는 데 정말 도움이 될 거예요.

[09:28] 그들은 매우 흥미로운

[09:31] 통찰을 가지고 있습니다.

[09:33] 접두사나 접미사를 사용할 때

[09:37] 에이전트의 도구 사용 평가에

[09:39] 차이가 있는 것 같아요. 맞죠?

[09:41] 그래서 아마 둘 다 실험해보고 싶을 거예요.

[09:45] 네임스페이스를 도구 이름

[09:46] 앞이나 뒤에 두고

[09:49] 그것이 도구 사용이나

[09:51] 도구 호출 성능에

[09:53] 어떤 영향을 미칠지 확인해보세요.

[09:55] 이런 시스템들이

[09:58] 점점 똑똑해지고 있지만

[10:00] 이런 아주 작은

[10:02] 뉘앙스 변화에

[10:04] 넘어질 수 있어요.

[10:06] 좋습니다. 다음 패턴은

[10:09] 도구에서 정보를 반환하는 것에 대해

[10:11] 어떻게 생각하느냐 하는 것입니다.

[10:14] 도구 호출이 있을 때마다

[10:17] 결과를 얻게 됩니다.

[10:19] 그런데 정확히 무엇을

[10:21] 그 결과에 추가할 것인가요?

[10:23] 일반적인 논리는

[10:25] 가능한 한 많은 정보를 추가하는 것이지만

[10:28] 그것은 실제로 역효과를 낼 수 있습니다.

[10:31] 그들은 도구 구현이

[10:35] 에이전트에게 높은 신호 정보만

[10:38] 다시 반환하도록 관리해야 하며

[10:41] 그 정보가 실제로

[10:44] 의미가 있는지 확인하고 싶어한다고 말합니다.

[10:46] UUID나

[10:48] 암호화된 이미지 URL과 같은

[10:51] 저수준 기술적 식별자를 반환하는 대신

[10:53] 이름, 이미지 URL과 같이

[10:56] 더 설명적인 필드를

[10:58] 반환하고 싶어합니다.

[11:00] 이제 어떤 경우에는

[11:02] 그런 저수준 기술적 식별자도

[11:05] 도움이 될 수 있습니다.

[11:08] 그래서 저수준과

[11:11] 고수준 세부 정보를 모두 보존하는

[11:14] 구조화된 출력이나

[11:17] 구조화된 형식을 반환하고 싶어합니다.

[11:20] 그들에 따르면 에이전트는

[11:24] 자연어 이름, 용어, 식별자를

[11:25] 암호화된 식별자보다

[11:27] 훨씬 더 성공적으로

[11:29] 다루는 경향이 있습니다.

[11:31] 이제 또 다른 질문은

[11:34] XML 형식, JSON, 마크다운 중

[11:36] 어떤 것으로 반환해야 하는가입니다.

[11:38] 지금은 정말

[11:39] 모델이 어떻게 훈련되었는지에 따라 다릅니다.

[11:42] 예를 들어 Claude는

[11:44] XML 형식을 좋아하고

[11:46] OpenAI 모델들도

[11:48] 이제 XML을 좋아하는 경향이 있습니다.

[11:52] 예전에는 JSON을

[11:54] 꽤 잘 했었죠, 맞나요?

[11:56] 그래서 실제로

[11:58] 사용하고 있는 모델을 살펴보고

[12:01] 그것을 기반으로 반환 데이터 형식이

[12:05] 무엇이 될지 결정해야 합니다.

[12:07] 다음으로, 반환하는

[12:10] 토큰 수 측면에서

[12:13] 도구 응답을 최적화하는 것에 대해

[12:15] 생각해보고 싶을 겁니다.

[12:17] 다시 말하지만 컨텍스트 관리가

[12:20] 중요할 것입니다.

[12:23] 몇 가지 전략이 있습니다. 예를 들어

[12:25] 에이전트가 더 토큰 효율적인 전략을 추구하도록

[12:28] 직접적으로 권장할 수 있습니다.

[12:30] 작고 타겟된 검색을 수행하는 것처럼

[12:32] 지식 검색 작업에서 단일 광범위 검색 대신 말이죠.

[12:35] 이전에 이야기했던 컨텍스트 북 예제와

[12:37] 매우 유사합니다.

[12:40] 마지막으로 중요한 것은

[12:42] 도구 설명을 위한 프롬프트 엔지니어링입니다.

[12:44] 이는 사람들이 종종 간과하는 부분이지만

[12:47] 더 많은 주의가 필요하다고 생각합니다.

[12:50] 이를 생각하는 방식은 에이전트가

[12:52] 도구를 선택할 때

[12:54] 주로 도구의 설명과

[12:56] 입출력이 무엇인지 살펴본다는 것입니다.

[13:00] 도구가 수행해야 할 작업에 대해

[13:03] 세심한 주의를 기울여야 합니다.

[13:06] 또한 입력 변수와

[13:08] 도구의 출력을 기능 사양과 함께

[13:12] 적절히 명명해야 합니다.

[13:15] 이를 쉽게 생각하는 방법은

[13:17] 새 인턴을 고용한다면

[13:20] 그들이 당신의 시스템이나

[13:23] 설정에 대해 전혀 모른다고 가정할 때

[13:26] 어떤 정보가 필요한지 생각해보는 것입니다.

[13:28] 이를 염두에 두고

[13:30] 특수한 쿼리 형식, 전문 용어 정의,

[13:32] 기본 리소스 간의 관계를

[13:35] 명시적으로 만들어야 합니다.

[13:37] 핵심은 에이전트가 추측을 해야 하는

[13:41] 모든 종류의 모호함을 피하는 것입니다.

[13:45] 이는 매우 중요합니다.

[13:48] 의사소통은 정말 좋은 에이전트 시스템과

[13:51] 도구 선택에서 혼란스러운

[13:54] 실패한 에이전트 시스템 사이의

[13:57] 주요 핵심입니다.

[13:59] 나머지 글은 주로

[14:01] 에이전트로 이러한 도구를 개선하는 방법에

[14:04] 초점을 맞춥니다. 아이디어는 매우 간단합니다.

[14:06] 도구의 초기 구현을 만들고

[14:08] 실제 세계 평가 테스트 케이스를

[14:11] 만들어야 합니다.

[14:13] 이는 매우 중요한데

[14:15] 제가 본 많은 경우에

[14:17] 사람들이 실제 현실 세계 사용 사례와

[14:20] 전혀 관련이 없는 합성 예제를

[14:23] 만들기 때문입니다.

[14:26] 그리고 이는 매우 안타까운데

[14:28] 이러한 시스템들이 그 합성 평가에서는

[14:30] 정말 잘 작동하지만

[14:32] 실제 세계 테스트에서는 실패하기 때문입니다.

[14:34] 그 이유는 이러한 테스트 세트나

[14:36] 평가 세트를 구축할 때

[14:39] 실제로 현실 세계 사용 사례를

[14:42] 포착하지 못하기 때문입니다.

[14:43] 모든 권장 사항을 따른다면

[14:46] 에이전트와 함께 그 도구들을

[14:48] 반복하려면 가능한 한

[14:51] 많은 정보를 제공해야 합니다.

[14:52] 여기에는 필요한

[14:53] 모든 문서가 포함됩니다.

[14:56] 아이디어는 에이전트를 테스트할 수 있는

[14:58] 평가 세트를 만드는 것입니다.

[15:01] 또한 도구를 따로따로 테스트하는 대신

[15:05] 여러 다른 도구를 결합하는

[15:06] 복잡한 시나리오에서

[15:09] 테스트하도록 해야 합니다.

[15:12] 예를 들어, 여기 약한 테스트 작업이 있습니다.

[15:16] 도구나 에이전트에게

[15:18] 다음 주에 누군가와 미팅을 잡아달라고

[15:21] 요청한다면 에이전트는

[15:23] 그 도구 하나만 선택해서

[15:25] 미팅을 잡을 수도 있습니다.

[15:28] 하지만 테스트는 이렇게 보여야 합니다:

[15:30] 다음 주에 Jane과 미팅을 잡아서

[15:32] 최신 프로젝트에 대해 논의하고

[15:34] 최신 프로젝트 계획 미팅의 노트를 첨부하고

[15:36] 회의실을 예약해달라고 말이죠.

[15:38] 이제 이것은 에이전트가 계획을 세우고

[15:41] 그 계획을 달성하기 위해

[15:43] 여러 다른 도구를 선택해야 합니다.

[15:46] 이것이 아마도 더 현실적인

[15:48] 실제 세계 테스트 케이스일 것입니다.

[15:51] 평가 데이터 세트에서 매우 간단한

[15:55] 단일 도구 선택 예제를 갖는 것보다 말이죠.

[15:57] 그리고 다시 말하지만 이는 중요합니다.

[15:59] 사람들이 시스템을 구축하면서

[16:02] 간단한 평가 테스트를 실행하는

[16:04] 많은 실패를 봤는데

[16:07] 그런 시스템들은 실제 세계의 복잡성 때문에

[16:09] 실패합니다.

[16:11] 그 후에는 에이전트 루프를 가질 수 있습니다.

[16:14] 기본적으로 주어진 평가 세트로

[16:17] 이를 루프로 실행합니다.

[16:19] 정보를 수집하고 시스템이 생성하는

[16:22] 피드백도 살펴볼 것입니다.

[16:24] 그다음 그 피드백을 에이전트와 함께 사용해서

[16:27] 도구를 개선합니다.

[16:30] 내부 테스트를 기반으로 그들은

[16:33] 에이전트를 사용해서 도구를 개선하면

[16:35] 실질적으로 더 나은 성능을 얻을 수 있다고 보여줍니다.

[16:38] 평가 설정에 대한

[16:40] 더 자세한 비디오를 만들어 달라고

[16:41] 알려주세요.

[16:43] 몇 개의 노트북이 있습니다.

[16:45] 비디오 설명에 넣어두겠습니다.

[16:47] 이 비디오가 유용했기를 바라고

[16:49] 더 나은 시스템 구축에 도움이 필요하시면

[16:52] 저에게 연락하세요.

[16:54] 자세한 내용은 비디오 설명에 있습니다.

[16:56] 어쨌든 이 비디오가 유용했기를 바랍니다.

[16:57] 시청해주셔서 감사하고 항상 그렇듯

[16:59] 다음 영상에서 만나요.