AI가 검색도 하고, 계산도 하고, 메일도 보내고, 일정도 잡는 모습을 처음 보면 대단해 보인다. 마치 모델이 갑자기 손과 발을 얻은 것처럼 느껴진다. 하지만 실제로는 조금 다르다. 모델이 직접 외부 시스템을 만지는 것은 아니다. 모델은 그저 어떤 도구를 어떤 형식으로 써야 할지 제안하고, 애플리케이션이 그 제안을 검증하고 실행한 뒤, 결과를 다시 모델에게 보여준다. 즉 도구는 마법 지팡이라기보다, AI와 소프트웨어 세계 사이를 잇는 정교한 인터페이스다.1
이 관점을 이해하면 중요한 사실이 보인다. 도구는 단지 기능 목록이 아니다. 도구의 이름, 설명, 매개변수, 반환 형식, 실행 결과, 실패 메시지까지 모두 모델이 읽는 컨텍스트다. 다시 말해 도구를 잘 붙이는 일은 API 연결 작업이면서 동시에 문서 작성 작업이고, 정보 설계 작업이기도 하다.
도구가 붙는 순간, AI는 답변 기계에서 행동 시스템이 된다
도구가 없는 모델은 입력을 읽고 텍스트를 생성한다. 여기까지는 똑똑한 설명가다. 하지만 검색, 계산, 데이터베이스 조회, 이메일 전송, 캘린더 수정, 코드 실행 같은 도구가 붙으면 이야기가 달라진다. 이제 모델은 "무슨 말을 할까?"만 고민하지 않는다. "지금은 말보다 행동이 필요한가?"까지 판단한다.
LangChain은 에이전트의 기본 루프를 아주 단순하게 설명한다. 모델을 호출하고, 모델이 요청한 도구를 실행하고, 그 결과를 다시 모델에게 넘기는 일의 반복이다.2 이 단순한 루프가 쌓이면 리서치 에이전트가 되고, 문서 작성기나 코딩 에이전트가 되고, 일정 조율 비서가 된다.
핵심은 하나다. 도구를 붙였다고 해서 AI가 자동으로 유능해지는 것은 아니다. 어떤 도구가 있는지, 언제 써야 하는지, 무엇을 입력해야 하는지, 결과를 어떻게 읽어야 하는지가 모델에게 명확해야 한다. 도구를 설계하지 않으면, 모델은 손발을 얻는 대신 서랍 가득한 정체불명의 공구함을 받게 된다.
모델은 도구를 어떻게 이해하는가
도구 호출을 처음 접하면 모델이 함수나 API를 "이해한다"고 생각하기 쉽다. 실제로는 훨씬 소박하다. 모델은 도구 정의를 읽고, 그 안에서 패턴을 배운다. 이름이 무엇인지, 설명이 무엇인지, 어떤 인수가 필요한지, 어떤 값만 허용되는지를 보고 다음 행동을 추론한다.1
흐름은 보통 다음과 같다.
사용자 요청이 들어온다.
시스템은 사용 가능한 도구 목록과 설명을 함께 모델에 준다.
모델은 도구를 쓸지, 쓴다면 무엇을 쓸지 결정한다.
모델은 구조화된 인수를 만든다.
애플리케이션이 이를 검증하고 실행한다.
실행 결과나 오류를 다시 모델의 컨텍스트에 넣는다.
모델은 그 결과를 바탕으로 답하거나, 다음 도구를 또 고른다.12
여기서 특히 중요한 대목은 마지막 두 단계다. 도구의 결과도 컨텍스트라는 점이다. 검색 결과든, 계산 결과든, 메일 전송 실패 메시지든, 일단 모델에게 다시 들어오면 그것은 다음 추론의 재료가 된다. 즉 도구 설계는 호출 전만의 문제가 아니라 호출 후의 정보 설계까지 포함한다.
어떤 순간에 도구가 필요한가
실무에서는 모든 요청에 도구가 필요한 것이 아니다. 오히려 도구를 불필요하게 남용하면 느려지고 비싸지고 자주 틀린다. 그래서 먼저 질문해야 한다. 이 작업은 모델의 내부 지식과 텍스트 생성만으로 충분한가, 아니면 외부 세계와 연결되어야 하는가?
도구가 특히 필요한 순간은 크게 세 가지다.
최신 정보가 필요할 때: 웹 검색, 사내 문서 검색, 데이터베이스 조회
정확한 계산이나 변환이 필요할 때: 계산기, 코드 실행기, 포맷 변환기
실제 행동이 필요할 때: 이메일 전송, 캘린더 일정 생성, 티켓 발행, 결제 요청
예를 들어 "이번 분기 매출 추세를 요약해줘"는 문서 검색과 데이터 조회 도구가 필요할 수 있다. "부가세 포함 총액 계산해줘"는 계산 도구가 더 안전하다. "다음 주 화요일 오후에 고객 미팅 잡아줘"는 캘린더 조회와 일정 생성 도구가 필요하다.
중요한 점은 검색 도구와 행동 도구를 같은 수준에서 다루지 않는 것이다. 검색은 대체로 읽기이고, 이메일 전송이나 일정 생성은 쓰기다. 읽기 도구는 틀리면 답이 나빠질 가능성이 크고, 쓰기 도구는 틀리면 현실 세계에 사고가 난다. 둘을 같은 마음가짐으로 연결하면 안 된다.
좋은 도구 설명은 짧은 광고 문구가 아니라 행동 규칙이다
많은 팀이 도구 성능이 안 나올 때 모델 탓부터 한다. 그런데 실제 문제는 도구 설명이 너무 인간 친화적이거나, 반대로 너무 개발자 친화적이어서 모델이 쓸 수 없는 경우가 많다. 최근 연구도 산업 현장에서 도구가 많아질수록, 그리고 문서가 사람용으로만 쓰일수록 모델과 도구 문맥 사이의 불일치가 커진다고 지적한다.3
좋은 도구 설명은 "무엇을 하는가"만 말하지 않는다. 언제 써야 하는지, 언제 쓰지 말아야 하는지, 어떤 인수가 필요한지, 인수 값은 어떤 범주인지까지 알려준다.1
예를 들어 이런 설명은 약하다.
send_email: 이메일을 보냅니다.
짧고 멋져 보이지만, 모델 입장에서는 모른다. 초안만 보낼 수 있는지, 실제 발송인지, 첨부가 가능한지, 사용자의 명시적 승인이 필요한지 알 수 없다.
반대로 이런 설명은 훨씬 낫다.
send_email: 사용자가 수신자와 목적을 명확히 확인한 뒤 이메일을 실제 발송할 때 사용한다. 초안 작성에는 draft_email을 사용한다. 제목, 본문, 수신자는 필수이며, 대량 발송에는 사용하지 않는다.
이 짧은 차이가 실전에서는 아주 크게 작용한다. 모델은 설명 속 경계선을 읽고 행동한다.
도구 설명을 설계할 때는 다음 원칙이 유용하다.
이름은 역할이 드러나게 짓는다.
query_orders가do_task_1보다 낫다.비슷한 일을 하는 도구는 경계를 분명히 나눈다.
search_customer와update_customer는 섞지 않는다.자유 입력보다 제한된 선택지를 선호한다. 가능한 값은
enum처럼 좁혀 준다.필요 없는 인수는 빼고, 필수 인수는 분명히 적는다.
설명에 사용 시점과 금지 조건을 함께 넣는다.1
특히 선택지가 제한된 값은 반드시 제한하는 편이 좋다. 날짜 형식, 온도 단위, 상태 값, 우선순위 값 같은 것들이다. 사람에게는 융통성처럼 보이는 자유도가 모델에게는 혼란의 여지가 된다.
도구의 매개변수는 모델에게 주는 문제집이다
모델은 도구를 호출할 때 인수를 만들어 낸다. 이 단계에서 생각보다 많은 실수가 발생한다. 숫자를 문자열로 넣거나, 필수 값을 빠뜨리거나, 존재하지 않는 필드를 지어내거나, 날짜를 애매하게 해석하는 일이 흔하다.1
그래서 도구 호출 시스템에는 반드시 중간 검증층이 필요하다. 모델이 낸 인수를 그대로 실행하지 말고, 다음을 확인해야 한다.
타입이 맞는가
필수 필드가 모두 있는가
허용되지 않은 추가 필드가 들어왔는가
권한 범위를 벗어나지 않았는가
실행 전 사용자 확인이 필요한가
이 검증층은 모델을 불신해서가 아니라, 역할을 나누기 위해 필요하다. 모델은 계획자이고, 실행기는 집행자다. 계획자는 유연해야 하지만 집행자는 엄격해야 한다. 이 구분이 없으면 AI 시스템은 똑똑해 보이는 순간보다 사고 나는 순간이 더 빨리 온다.
흥미로운 점은 검증 실패도 쓸모 있는 컨텍스트라는 사실이다. 예를 들어 모델이 user_id에 이름 문자열을 넣었다면, 시스템은 "user_id는 정수여야 한다"는 오류를 다시 모델에게 줄 수 있다. 그러면 모델은 인수를 고쳐 재시도할 수 있다.15 잘 만든 에이전트는 한 번에 완벽한 시스템이 아니라, 실수를 수정할 수 있는 시스템이다.
도구 결과를 어떻게 다시 넣느냐가 성능을 가른다
많은 사람이 도구 호출의 핵심을 "무슨 도구를 고르느냐"라고 생각한다. 하지만 실제 사용성은 그 다음 단계에서 갈린다. 도구가 돌려준 결과를 어떤 형식으로 다시 컨텍스트에 넣느냐가 중요하다.1
예를 들어 데이터베이스 조회 결과를 그대로 300줄 JSON으로 던져 주면 어떨까. 모델은 필요한 정보보다 잡음이 더 많은 응답을 읽게 된다. 그러면 집중력이 흐트러진다. 여기서 우리가 앞 장들에서 본 컨텍스트 과잉 문제가 다시 나타난다.
좋은 도구 결과는 대체로 다음 세 가지 중 하나다.
다음 도구 호출에 바로 쓸 구조화된 데이터
사용자에게 설명하기 좋은 요약된 문자열
구조화 데이터와 짧은 요약을 함께 담은 응답
실무에서는 세 번째가 자주 유용하다. 예를 들어 캘린더 조회 도구는 내부적으로는 이벤트 ID, 시작 시각, 종료 시각, 참석자 목록을 반환하되, 모델이 바로 이해할 수 있도록 "다음 주 화요일 14:00~15:00만 비어 있음" 같은 짧은 요약을 함께 주면 좋다. 반대로 코드 실행 도구는 중간 로그 전체보다 핵심 결과와 에러 요약을 먼저 주는 편이 낫다.
한마디로 말해, 도구는 결과를 가져오는 장치이고, 컨텍스트 엔지니어링은 그 결과를 읽히는 정보로 바꾸는 일이다.
검색, 계산, 이메일, 캘린더, 코드 실행은 각각 다르게 다뤄야 한다
도구라는 이름 아래 다 묶여 있지만, 실은 성격이 서로 꽤 다르다.
검색 도구: 최신성과 근거를 가져오는 장치
검색 도구는 모델의 기억이 아니라 외부 세계를 참고하게 만든다. 웹 검색, 사내 위키 검색, 파일 검색, FAQ 검색이 여기에 들어간다. 이런 도구는 "무엇을 찾을지"를 잘 설명해야 한다. 검색 쿼리의 품질, 범위 제한, 최신성 기준, 출처 표시 여부가 핵심이다.
검색 도구는 보통 읽기 전용이라 비교적 안전하지만, 그 대신 관련성 문제가 중요하다. 잘못 찾으면 모델은 틀린 근거 위에서 그럴듯한 답을 한다. 그래서 검색 결과 수를 너무 많이 주지 말고, 질문과 직접 관련된 조각만 넣는 편이 낫다.
계산 도구: 모델의 자신감을 꺾는 장치
수치 계산, 통계, 날짜 차이 계산, 단위 변환, 표 정렬 같은 일은 계산 도구가 훨씬 낫다. 이 도구의 철학은 간단하다. "추측하지 말고 계산해라."
계산 도구는 설명보다 입력 형식이 중요하다. 숫자 단위, 소수점 처리, 시간대 같은 함정을 미리 막아야 한다. 계산기는 말이 짧을수록 좋지만, 그 짧음은 모호함이 아니라 엄격함이어야 한다.
이메일·캘린더 도구: 현실 세계에 흔적을 남기는 장치
이메일 전송, 일정 생성, 수정, 취소는 가장 조심해야 하는 도구다. 잘못 보내면 되돌리기 어렵기 때문이다. 이 부류에는 항상 미리보기와 확정 단계를 분리하는 패턴이 잘 어울린다.5
예를 들어 다음처럼 쪼개는 편이 안전하다.
draft_email: 초안 작성preview_event: 일정 후보 생성send_email: 실제 발송create_event: 실제 일정 등록
이렇게 나누면 모델은 먼저 초안과 제안을 만들고, 사람이나 별도 정책 엔진이 마지막 실행을 승인할 수 있다. 도구를 하나로 합쳐 두면 편해 보이지만, 실제로는 위험도와 디버깅 비용이 같이 올라간다.
코드 실행 도구: 가장 강력하고 가장 위험한 장치
코드 실행은 데이터 분석, 파일 처리, 자동화에서 대단히 유용하다. 하지만 동시에 가장 위험하다. 파일 접근, 네트워크 접근, 비밀값 노출, 무한 실행 같은 문제가 따라온다. 그래서 코드 실행은 가능하면 샌드박스 환경에서 제한된 권한으로 돌아가야 한다.5
코드 실행 도구를 줄 때 모델에게 필요한 것은 자유가 아니라 울타리다. 실행 시간 제한, 메모리 제한, 파일 시스템 제한, 네트워크 차단 같은 제약이 있어야 한다. 강한 도구일수록 설명보다 실행 환경 설계가 중요하다.
도구가 많아질수록 성능이 떨어지는 이유
초기에는 도구를 많이 붙일수록 만능 비서에 가까워질 것처럼 보인다. 그러나 실제로는 반대다. 도구 수가 늘어나면 모델은 더 자주 헷갈린다. 비슷한 이름의 도구를 혼동하고, 불필요한 도구까지 함께 고려하느라 집중력이 흐려진다. 큰 도구 목록은 토큰 비용과 지연 시간도 키운다.45
최근 연구와 실무 보고는 공통적으로, 대규모 도구 카탈로그에서는 모든 도구를 한 번에 넣지 말고 관련 도구만 먼저 좁히는 계층형 선택이 중요하다고 말한다.34 쉽게 말해 도구도 검색해야 한다는 뜻이다.
이때 많이 쓰는 패턴은 두 가지다.
먼저 도메인을 고른 뒤 그 도메인의 도구만 노출한다.
tool_search같은 검색 도구로 관련 도구 몇 개만 동적으로 불러온다.
이 방식은 생각보다 큰 차이를 만든다. 모델에게 공구 창고 전체를 보여주는 대신, 지금 작업에 필요한 서랍만 열어 주는 셈이기 때문이다.
안전한 도구 설계를 위한 세 가지 원칙
도구를 잘 쓰게 만드는 것과 안전하게 쓰게 만드는 것은 같은 일이다. 다음 세 가지는 특히 중요하다.
최소 권한: 읽기만 필요한 에이전트에게 쓰기 권한을 주지 않는다.
확인 가능한 단계 분리: 초안과 실제 실행을 분리하고, 민감한 작업은 승인 단계를 둔다.
관찰 가능성 확보: 어떤 도구를 왜 썼고, 어떤 인수와 결과가 오갔는지 로그를 남긴다.5
예를 들어 "내일 회의 잡아 줘"라는 요청 하나에도 실제 시스템은 꽤 많은 맥락을 알아야 한다. 사용자의 시간대, 선호 시간, 참석자 권한, 외부 참석자 허용 여부, 회의실 예약 정책, 중복 일정 충돌 여부가 필요하다. 이런 런타임 정보는 모델에게 전부 자연어로 설명하는 것보다, 도구가 읽을 수 있는 권한·정책 맥락으로 주는 편이 낫다. LangChain도 모델 컨텍스트만이 아니라 도구가 접근하는 상태와 런타임 컨텍스트를 별도로 통제하는 일이 중요하다고 설명한다.2
즉 안전은 "하지 마"라고 길게 쓰는 데서 나오지 않는다. 할 수 있는 범위를 구조적으로 제한하는 데서 나온다.
실전에서는 도구 하나보다 도구 사이의 연결이 더 중요하다
실무 업무는 보통 단일 도구 호출로 끝나지 않는다. "고객 미팅 잡아 줘"만 해도 참석자 이메일 찾기, 캘린더 가용 시간 조회, 일정 후보 제안, 초대 메일 작성, 최종 일정 생성이 이어진다. 이럴 때 중요한 것은 각 도구가 혼자 똑똑한가가 아니라, 서로 넘겨주는 정보가 깔끔한가다.
좋은 도구 체인은 이런 느낌을 가진다.
검색 도구가 고객 정보를 찾고, 그 결과에서 필요한 ID와 이메일만 남긴다. 캘린더 도구는 그 이메일을 받아 가용 시간을 반환한다. 요약기는 후보 시간 세 개만 뽑아 사용자에게 묻는다. 사용자가 확정하면 그때 일정 생성 도구와 메일 발송 도구가 실행된다.
반대로 나쁜 도구 체인은 중간 결과가 지나치게 길고, 형식이 제각각이고, 무엇이 확정 정보인지 불분명하다. 결국 모델은 매 단계에서 다시 읽고 다시 해석하느라 힘을 낭비한다.
여기서 기억해야 할 문장은 하나다. 도구는 기능의 집합이 아니라 워크플로의 문장 부호다. 어떤 결과를 다음 단계로 넘길지 정리해 주어야 문장이 매끄럽게 이어진다.
도구를 설계할 때 자주 하는 실수
마지막으로, 현장에서 정말 자주 만나는 실수를 짚어 보자.
첫째, 도구 이름이 너무 추상적이다. process_data, handle_request, run_task 같은 이름은 사람에게도 모호하고 모델에게는 거의 수수께끼다.
둘째, 사람용 문서를 그대로 붙인다. 장황한 API 문서는 개발자에게는 친절하지만 모델에게는 핵심이 흐려질 수 있다. 모델은 긴 설명보다 경계가 뚜렷한 설명을 더 잘 쓴다.3
셋째, 결과를 너무 많이 돌려준다. 원본 로그 전체, DB 로우 전체, HTML 전체를 넣으면 모델은 필요한 정보보다 잡음을 더 많이 읽는다.
넷째, 실패를 숨긴다. 도구 오류를 그냥 삼키면 모델은 성공했다고 착각한다. 차라리 짧고 구조화된 실패 메시지를 주는 편이 낫다.
다섯째, 행동 도구를 너무 쉽게 연다. 보내기, 삭제하기, 결제하기 같은 도구는 언제나 한 번 더 멈춰 세울 장치가 필요하다.
도구 설계의 본질은 모델에게 '버튼'이 아니라 '판단 가능한 인터페이스'를 주는 일이다
도구는 AI를 더 똑똑하게 보이게 만드는 장식이 아니다. 도구는 모델이 외부 세계와 접촉하는 표면이다. 그 표면이 거칠고 모호하면 모델은 자꾸 미끄러진다. 반대로 이름이 분명하고, 입력이 엄격하고, 결과가 읽기 좋고, 위험한 행동이 분리되어 있으면 AI는 훨씬 안정적으로 일한다.
이 장의 핵심을 한 문장으로 줄이면 이렇다.
도구를 추가하는 일은 기능을 늘리는 일이 아니라, 모델이 행동할 수 있도록 이해 가능한 컨텍스트를 설계하는 일이다.
이제 다음 단계로 넘어가 보자. 도구는 강력하지만, 공짜가 아니다. 도구 설명도 토큰을 먹고, 도구 결과도 컨텍스트 윈도우를 차지한다. 결국 중요한 질문은 다시 돌아온다. 이 많은 정보를 모델의 작업 기억 안에 어떻게 담고, 어떻게 관리할 것인가.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.