에이전트에 도구를 많이 붙인다고 해서 곧바로 일을 잘하게 되는 것은 아니다. 공구함이 가득 찼다고 집이 저절로 지어지지 않는 것과 비슷하다. 실무에서 에이전트가 자주 실패하는 이유는 대개 도구가 없어서가 아니라, 어떤 상황에서 어떤 도구를 먼저 써야 하는지 규칙이 없어서다. 검색을 먼저 할지, 내부 문서를 먼저 읽을지, 계산은 자연어로 할지 코드로 검증할지, 브라우저를 열어도 되는지, 파일을 어디까지 읽게 할지, 언제 사람에게 멈춰 서야 하는지가 정해져 있지 않으면 에이전트는 그때그때 그럴듯한 선택을 한다. 그리고 바로 그 "그럴듯함"이 사고의 시작점이 된다.12
도구 선택은 능력의 문제가 아니라 순서의 문제다
좋은 도구 선택 설계는 "무슨 도구를 쓸 수 있나"보다 "어떤 순서로 좁혀 가나"에서 시작한다. 에이전트는 가능한 한 가장 좁고, 가장 값싸고, 가장 되돌리기 쉬운 수단부터 써야 한다. 이것이 기본 질서다.13
실무에서는 다음 순서가 잘 작동한다.
먼저 사용자 입력, Skill 지침, 이미 제공된 파일과 내부 참고자료만으로 해결 가능한지 판단한다.
부족한 정보가 있으면 외부 웹보다 먼저 내부 시스템이나 연결된 업무 도구에서 확인한다.
계산, 변환, 검산이 필요할 때만 코드 실행을 붙인다.
검색이나 API로 해결되지 않고 실제 화면 상호작용이 필요할 때만 브라우저를 연다.
쓰기, 발송, 삭제, 상태 변경처럼 되돌리기 어려운 작업은 반드시 승인 단계를 거친다.
이 순서는 단순해 보이지만 강력하다. 에이전트가 처음부터 웹을 뒤지지 않고, 필요하지도 않은 브라우저를 열지 않으며, 코드 실행을 "생각을 대신하는 도구"가 아니라 "검증 도구"로 쓰게 만들기 때문이다.
검색 도구는 언제 쓰고, 언제 참아야 하는가
검색 도구는 매우 유용하다. 하지만 유용하다는 말과 먼저 써야 한다는 말은 다르다. 검색은 외부 사실, 최신 정보, 시장 동향, 공개 자료 비교가 필요할 때 적합하다. 반대로 회사 문체, 내부 정책, 승인 규칙, 기존 보고서 형식, 이미 제공된 원문 같은 것은 검색보다 내부 자료가 우선이다.
예를 들어 사용자가 "우리 회사 형식에 맞는 주간 보고서를 써 달라"고 했는데, 에이전트가 먼저 웹 검색을 시작한다면 벌써 방향이 틀어진 것이다. 이 경우 필요한 것은 최신 웹 정보가 아니라 사내 보고서 템플릿, 팀장이 선호하는 톤, 지난주 보고서의 구조다. 검색은 오히려 잡음을 늘린다.
반대로 "이 정책과 관련된 최신 규제 변경이 있는지 확인해 달라"는 요청이라면 내부 자료만으로는 부족할 수 있다. 이때는 검색이 필요하다. 중요한 것은 무엇이 기준 문서인지 먼저 정하는 것이다. 조직의 규칙은 내부 자료가 기준이고, 외부 세계의 최신 사실은 검색 결과가 기준이 된다.
좋은 설계는 검색 도구에 이런 식의 문장을 붙인다.
내부 문서나 제공된 파일로 답할 수 있는 내용은 먼저 내부 자료를 확인한다. 검색은 최신성 확인, 외부 사실 검증, 공개 자료 수집이 필요할 때만 사용한다.
이 한 줄이 있으면 에이전트는 "모르면 일단 검색"이라는 습관에서 벗어난다.
검색의 우선순위는 "열린 웹"보다 "가까운 근거"다
에이전트가 정보를 찾을 때는 출처의 화려함보다 업무와의 거리를 봐야 한다. 가까운 근거일수록 보통 더 정확하고, 더 관련성이 높고, 더 설명 가능하다.
예를 들어 출판 기획서를 쓰는 상황을 생각해 보자. 이미 사용자가 시장 가설, 독자층, 기존 초안 목차를 제공했다면 그것이 가장 가까운 근거다. 이 상태에서 검색을 먼저 해 버리면 외부 정보가 내부 의도를 덮어쓴다. 반대로 경쟁 도서의 최근 출간 동향이나 플랫폼별 판매 흐름을 보강할 때는 검색이 좋은 도구가 된다.
즉, 검색은 시작점이 아니라 보강점일 때 가장 강하다. 에이전트가 내부 맥락을 먼저 붙잡고, 그다음 외부 근거를 덧댈 때 결과가 흔들리지 않는다.
코드 실행은 계산기이자 검증기다
실무에서 많은 사람이 코드 실행 도구를 과대평가한다. 코드 실행은 마치 똑똑한 비서의 두 번째 뇌처럼 느껴진다. 하지만 설계 관점에서 보면 코드 실행은 판단 도구가 아니라 결정적 처리 도구다. 다시 말해, 코드 실행은 생각을 더 잘하게 만드는 수단이 아니라 계산, 변환, 검산, 파싱, 테스트를 더 정확하게 하게 만드는 수단이다.2
그래서 코드 실행은 다음처럼 한정하는 편이 좋다.
수치 계산과 통계 요약
포맷 변환과 데이터 정리
CSV, 로그, JSON 같은 구조화 데이터 파싱
정규식 검사, 스키마 검증, 중복 제거
표 생성, 단위 변환, 간단한 시뮬레이션
반대로 이런 것은 코드 실행으로 밀어 넣지 않는 편이 낫다. 예를 들면 고객 응대의 어조를 정하는 일, 승인 필요 여부를 판단하는 일, 어느 자료가 조직 기준에 더 맞는지 해석하는 일이다. 이런 것은 계산 문제가 아니라 정책과 맥락의 문제다.
쉽게 말해 코드 실행은 계산기와 같다. 계산기는 덧셈을 믿을 만하게 해 주지만, 무엇을 더해야 하는지까지 결정해 주지는 않는다. 그 결정은 Skill의 지침과 업무 규칙이 맡아야 한다.
코드 실행은 "결과 생성"보다 "결과 검증"에서 더 빛난다
에이전트가 자연어로 표를 예쁘게 만들 수는 있다. 하지만 행 수가 맞는지, 합계가 맞는지, 날짜 형식이 모두 같은지, 파일 인코딩이 깨지지 않았는지는 자연어만으로 종종 흐트러진다. 바로 이 지점에서 코드 실행이 빛난다.
예를 들어 리서치 결과를 정리한 뒤, 최종 표의 출처 개수와 본문 각주 수가 일치하는지 확인하거나, 재무 보고서 초안의 합계가 원자료와 맞는지 검산하거나, 로그 분석 결과의 이상치 기준이 일관되게 적용됐는지 다시 검사할 수 있다. 이런 설계를 해 두면 에이전트는 "말을 잘하는 시스템"에서 "검증 가능한 시스템"으로 한 단계 올라간다.
좋은 규칙은 보통 이렇게 적힌다.
코드 실행은 계산, 변환, 검증에만 사용한다. 정책 판단, 승인 판단, 대외 메시지의 최종 책임 판단은 코드에 맡기지 않는다.
브라우저는 실제 화면이 필요할 때만 꺼내는 도구다
브라우저 자동화는 강력하다. 웹사이트를 열고, 버튼을 누르고, 폼을 채우고, 스크린샷을 찍고, 단일 페이지 앱을 탐색하고, 사람이 직접 확인해야 할 UI 흐름을 대신 걸어 볼 수 있다.4 하지만 바로 그 강력함 때문에 브라우저는 가장 쉽게 과용된다.
브라우저가 필요한 경우는 비교적 분명하다. 검색 결과만으로 부족하고, 실제 렌더링된 화면을 봐야 하거나, 로그인 이후 화면처럼 정적인 문서 수집으로는 접근할 수 없는 영역이 있거나, 멀티스텝 폼 제출·스크린샷 캡처·UI QA처럼 상호작용 자체가 업무의 본질인 경우다.
반대로 기사 한 편의 핵심 사실을 알고 싶은데도 브라우저부터 열어 모든 페이지를 돌아다니는 것은 좋지 않다. 그 경우는 검색이나 문서 fetch가 더 빠르고, 더 싸고, 더 안전하다. 브라우저는 대체로 가장 무겁고, 가장 느리고, 가장 많은 부작용을 낳을 수 있는 도구이기 때문이다.14
브라우저를 열어야 한다면 단계도 나누는 편이 좋다. 처음에는 읽기 전용 정찰 단계로 시작한다. 페이지를 열고, 구조를 파악하고, 필요한 정보가 정말 그 화면에 있는지 확인한다. 클릭, 입력, 제출은 그다음이다. 이 단계를 건너뛰면 에이전트는 화면을 보자마자 성급하게 행동하기 쉽다.
브라우저 자동화에서 위험이 커지는 순간
브라우저는 단순 조회에서 갑자기 고위험 작업으로 넘어갈 수 있다. 같은 브라우저 안에서 "가격표 보기"와 "결제 버튼 누르기"가 몇 번의 클릭 차이밖에 나지 않기 때문이다. 그래서 브라우저 작업에는 특히 명확한 금지선이 필요하다.
위험이 커지는 대표적인 순간은 세 가지다. 첫째, 로그인과 인증이 개입될 때다. 둘째, 제출, 발송, 예약, 구매처럼 외부 상태가 바뀌는 버튼이 등장할 때다. 셋째, CAPTCHA나 예상치 못한 팝업처럼 자동화가 불안정해지는 장애물이 나타날 때다. 이런 순간에는 에이전트가 혼자 계속 밀고 나가게 두면 안 된다.
좋은 Skill은 브라우저 사용 시 이렇게 적어 둔다.
브라우저는 탐색, 확인, 스크린샷, 데이터 추출에는 사용할 수 있다. 로그인 이후 제출·발송·구매·예약·삭제가 포함되면 실행 전에 사용자 확인을 받는다. 예상치 못한 인증, CAPTCHA, 약관 동의 화면이 나타나면 중단하고 지시를 구한다.
이 문장 하나만 있어도 브라우저는 모험 도구가 아니라 관리 가능한 도구가 된다.
파일 시스템은 넓게 열수록 똑똑해지는 것이 아니라 위험해진다
파일 시스템 접근도 흔히 오해를 부른다. 많은 팀이 "어차피 로컬 파일을 읽을 수 있으면 생산성이 올라가겠지"라고 생각한다. 맞는 말이지만, 절반만 맞다. 파일 시스템 도구는 매우 유용하지만, 동시에 가장 쉽게 권한 과다 상태로 흘러가는 도구이기도 하다.
원칙은 단순하다. 가장 작은 범위만 허용한다. 필요한 폴더만 열고, 가능하면 읽기 전용으로 시작하고, 민감한 파일 형식은 제외하고, 너무 큰 파일은 제한하고, 프로젝트와 무관한 개인 폴더는 처음부터 권한 밖에 둔다.56
예를 들어 보고서 자동화 Skill이 필요한데 바탕화면 전체와 문서 폴더 전체를 열어 둘 이유는 없다. 해당 프로젝트 폴더와 템플릿 폴더 정도면 충분할 가능성이 크다. 더 나아가 .md, .txt, .csv처럼 필요한 확장자만 허용하면 사고 범위가 크게 줄어든다.6
중요한 것은 "읽을 수 있다"와 "읽어야 한다"를 구분하는 것이다. 사용자가 이미 본문을 붙여 넣었다면, 에이전트가 굳이 폴더를 뒤져 원본 파일까지 다시 찾으러 갈 필요는 없다. 파일 시스템 접근은 기본값이 아니라 필요 시 선택되는 옵션이어야 한다.
파일 시스템 권한은 업무 경계와 함께 설계해야 한다
도구 권한은 기술 설정처럼 보이지만, 실제로는 업무 경계의 선언이다. 어느 폴더까지가 이 에이전트의 작업장인지 먼저 정해야 한다. Claude Code의 MCP 구성도 로컬, 프로젝트, 사용자 범위처럼 어디서 어떤 도구가 로드될지를 나눠 관리하게 한다.5 이 개념은 중요하다. 에이전트가 매 프로젝트마다 같은 권한을 가져야 하는 것은 아니기 때문이다.
개인 메모와 고객 계약서와 배포 스크립트가 한꺼번에 열려 있는 환경은 편해 보일 수 있다. 하지만 에이전트 입장에서는 너무 많은 방에 마스터키를 쥐여 주는 셈이다. 좋은 설계는 항상 "이번 일에 필요한 방만 연다"는 태도를 가진다.
승인 규칙은 도구 뒤에 붙는 장식이 아니라 핵심 설계다
도구 선택 설계를 이야기할 때 많은 팀이 "어떤 도구를 붙일까"에만 집중한다. 하지만 실제 운영에서 더 중요한 것은 언제 멈추게 할까다. 특히 사람 승인 규칙이 빠지면 에이전트는 단지 빠른 자동화가 아니라 빠른 사고 처리기가 된다.13
승인이 필요한 작업은 명확하다. 발송, 게시, 삭제, 구매, 일정 확정, 고객 상태 변경, 권한 변경, 외부 시스템 기록 저장처럼 결과가 남고 되돌리기 어려운 작업들이다. 반대로 읽기, 검색, 초안 작성, 계산, 스크린샷 촬영 같은 작업은 보통 저위험으로 분류할 수 있다.
여기서 중요한 것은 "승인받을까요?"라고 막연히 묻지 않는 것이다. 좋은 확인 문구는 반드시 네 가지를 담는다. 무엇을 하려는지, 어떤 대상에 대해 하려는지, 어떤 영향이 생기는지, 승인하지 않으면 어떻게 되는지다.
예를 들면 이런 식이다.
현재 고객 12명에게 초안 메일을 발송하려고 합니다. 첨부파일 1건이 포함되어 있으며, 발송 후에는 회수할 수 없습니다. 승인하면 발송하고, 승인하지 않으면 초안만 저장합니다.
이 문장은 사용자가 판단할 재료를 준다. 좋은 승인 설계는 속도를 늦추는 것이 아니라, 사고 비용을 줄인다.
중단 조건을 미리 정하면 에이전트가 덜 무모해진다
승인만큼 중요한 것이 중단 조건이다. 에이전트는 종종 실패했을 때 더 열심히 움직이려는 이상한 성향을 보인다. 잘 안 되면 도구를 한 번 더 부르고, 브라우저를 새로 열고, 파라미터를 바꾸고, 다른 파일을 읽어 보려 한다. 사람 눈에는 집요함처럼 보이지만, 운영 관점에서는 위험 신호다.
좋은 도구 선택 설계는 다음 상황에서 멈추게 해야 한다.
대상이 모호할 때. 예를 들어 같은 이름의 고객이 여러 명일 때다.
내부 자료와 외부 자료가 충돌할 때다.
인증 오류, 권한 오류, CAPTCHA, 예상 밖의 약관 동의 화면이 나타날 때다.
같은 종류의 실패가 반복될 때다.
삭제, 발송, 상태 변경 같은 고위험 작업으로 넘어가기 직전인데 승인 정보가 없을 때다.
중단 조건은 에이전트의 무능을 드러내는 장치가 아니다. 오히려 실무형 시스템의 성숙도를 보여 주는 장치다. 멈춰야 할 때 멈출 줄 아는 에이전트가 오래 쓴다.
복구 절차가 있으면 실패가 덜 아프다
현실의 도구는 실패한다. 네트워크가 끊기고, 토큰이 만료되고, UI가 바뀌고, 파일 경로가 달라지고, 외부 서비스가 느려진다. 그래서 좋은 설계는 항상 복구 절차를 함께 가진다.
복구 절차는 거창할 필요가 없다. 다만 몇 가지는 반드시 있어야 한다. 초안이나 중간 산출물은 버리지 않고 남길 것, 마지막으로 성공한 단계가 어디인지 기록할 것, 읽기 작업과 쓰기 작업의 재시도 정책을 다르게 둘 것, 고위험 쓰기 작업은 자동 재시도하지 않을 것, 실패 시 대체 경로를 안내할 것이다.
예를 들어 웹 폼 제출이 실패했다면 다시 제출 버튼을 자동으로 누르게 하는 것보다, 입력한 내용은 임시 저장하고 "현재 제출 직전에 오류가 발생했습니다. 재시도하면 중복 제출 위험이 있을 수 있습니다"라고 알리는 편이 훨씬 낫다. 반대로 검색 API가 일시적으로 실패한 경우라면 제한된 횟수 안에서 재시도해도 괜찮다.
이 차이를 가르는 기준은 단 하나다. 실패한 작업이 조회인지, 상태 변경인지다.
바로 써먹을 수 있는 도구 선택 정책 템플릿
실무에서는 장황한 철학보다 짧은 규칙이 더 잘 작동한다. 다음과 같은 정책 블록을 Skill에 넣으면 많은 문제가 줄어든다.
## Tool Selection Policy
1. 사용자 입력, SKILL.md, references/만으로 해결 가능하면 외부 도구를 사용하지 않는다.
2. 외부 정보가 필요해도 조직 규칙과 내부 문서는 검색보다 우선한다.
3. 검색은 최신성 확인, 공개 자료 수집, 외부 사실 검증에만 사용한다.
4. 코드 실행은 계산, 변환, 검증에만 사용한다.
5. 브라우저는 렌더링된 화면 확인, 폼 상호작용, 스크린샷, UI 테스트가 필요할 때만 사용한다.
6. 파일 시스템은 허용된 경로 안에서만 접근하고, 필요 없는 폴더는 읽지 않는다.
7. 발송, 삭제, 제출, 구매, 상태 변경 전에는 반드시 사용자 승인을 받는다.
8. 대상이 모호하거나 인증·권한 문제가 발생하면 실행을 중단하고 확인을 요청한다.이 템플릿의 좋은 점은 도구를 제한하는 데 있지 않다. 도구 사용의 이유를 분명하게 만드는 데 있다.
결국 좋은 에이전트는 도구를 덜 쓰는 것이 아니라 덜 헤맨다
도구 선택 설계의 목표는 에이전트를 소극적으로 만드는 것이 아니다. 오히려 더 안정적으로 움직이게 만드는 것이다. 검색은 필요한 때만 정확하게 쓰고, 코드 실행은 계산과 검증에 집중시키고, 브라우저는 화면이 본질인 순간에만 꺼내고, 파일 시스템은 최소 범위만 열고, 위험 작업은 승인과 중단 조건 위에서 움직이게 해야 한다.
그러면 에이전트는 더 적게 행동하는 것이 아니라, 더 덜 헤매고 더 덜 사고 치면서 행동하게 된다. 이것이 바로 실무형 에이전트의 차이다. 똑똑한 모델은 많은 답을 낼 수 있다. 하지만 오래 살아남는 에이전트는, 어떤 도구를 지금 쓰지 말아야 하는지까지 안다.
참고
1에이전트 AI 시스템의 설계 패턴 선택 - Google Cloud
2Writing effective tools for AI agents—using AI agents - Anthropic
3A practical guide to building AI agents - OpenAI
5Connect Claude Code to tools via MCP
6How to Connect Claude to Your Local Files Using an MCP Server
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.