스스로 도구를 만들어 쓰는 AI 에이전트, Tendril은 무엇이 다른가

도구를 만들어 쓰는 에이전트?

AI 에이전트 이야기가 정말 많이 나오죠. "에이전트"라는 게 뭐냐면, LLM이 그냥 답을 뱉는 게 아니라 여러 도구(tool)를 직접 호출하면서 일을 진행하는 시스템을 말해요. 예를 들어 "우리 회사 매출 보고서 만들어줘" 하면, 데이터베이스에 쿼리를 날리는 도구, 차트를 그리는 도구, PDF로 변환하는 도구를 차례로 부르면서 결과를 만들어내는 거죠.

그런데 여기에는 한 가지 한계가 있어요. 보통 이 "도구"들은 개발자가 미리 다 만들어둬야 한다는 거예요. 새로운 작업이 필요하면 사람이 새 도구를 코드로 작성해서 등록해줘야 합니다. 최근 공개된 Tendril이라는 오픈소스 프로젝트는 이 한계를 흥미로운 방식으로 깨려고 해요. 에이전트가 필요한 도구를 스스로 만들고, 스스로 등록해서 즉시 써먹는다는 컨셉이거든요.

Tendril이 동작하는 방식

serverless-dna 조직에서 공개한 이 프로젝트의 핵심 아이디어는 "자기 확장형(self-extending)"이라는 단어에 다 들어 있어요. 에이전트가 어떤 작업을 하다가 "아, 이걸 하려면 X라는 도구가 필요하네" 하고 판단하면, 그 자리에서 도구의 코드를 생성합니다. 그리고 그 코드를 실행 환경에 등록해서, 다음 단계부터는 마치 처음부터 있던 도구인 것처럼 호출해 쓰는 거예요.

이게 말로만 들으면 신기한데, 실제로는 몇 가지 까다로운 문제를 풀어야 해요. 첫째는 도구의 명세(스키마) 자동 생성이에요. LLM이 도구를 호출하려면 그 도구가 어떤 입력을 받고 어떤 출력을 내는지 정해진 형식으로 알아야 하거든요. Tendril은 새로 만든 함수의 시그니처를 분석해서 LLM이 이해할 수 있는 JSON 스키마로 변환해줍니다.

둘째는 격리와 보안이에요. AI가 자기 마음대로 코드를 짜서 실행한다고 하면 바로 "그거 위험하지 않아?" 싶잖아요. 맞아요, 위험합니다. 그래서 보통 이런 시스템은 샌드박스, 즉 격리된 실행 환경 안에서 코드를 돌려요. 이름에 serverless-dna가 붙어 있는 걸 보면, AWS Lambda 같은 서버리스 환경을 활용해서 도구마다 격리된 실행 컨텍스트를 주는 방향으로 설계된 것으로 보여요. 함수가 잘못 동작해도 메인 시스템에는 영향을 안 주는 구조죠.

셋째는 재사용입니다. 한 번 만든 도구를 매번 다시 만들면 비효율적이잖아요. Tendril은 만들어진 도구를 저장해두고, 비슷한 작업이 들어오면 기존 도구를 다시 호출하도록 합니다. 시간이 지날수록 에이전트가 자신만의 도구 라이브러리를 쌓아가는 셈이에요.

기존 에이전트 프레임워크와 뭐가 다를까

에이전트 프레임워크는 이미 많아요. LangChain, LlamaIndex, CrewAI, AutoGen 같은 것들이 대표적이죠. 이 프레임워크들에서도 "코드 인터프리터" 도구를 통해 에이전트가 즉석에서 파이썬 코드를 짜서 실행할 수 있어요. 그럼 Tendril이랑 뭐가 다르냐고요?

차이는 "일회성 실행"이냐 "영속적 도구화"냐예요. 코드 인터프리터는 그때그때 코드를 돌려서 결과만 가져오고 끝나요. 다음에 같은 일을 또 하려면 또 코드를 짜야 합니다. 반면 Tendril은 한 번 짠 코드를 "이름이 있는 도구"로 시스템에 등록해서, 이후로는 일반 함수 호출처럼 빠르게 부를 수 있게 해요. 에이전트가 시간이 지날수록 점점 똑똑해지고, 같은 작업은 점점 효율적으로 처리하게 된다는 의미예요.

비슷한 컨셉으로는 Voyager라는 마인크래프트 에이전트 연구가 있었어요. 게임 안에서 LLM이 새로운 스킬(코드)을 만들어 라이브러리에 저장하고, 이후 비슷한 상황에서 재사용하는 구조였죠. Tendril은 이 아이디어를 게임이 아니라 일반 업무용 에이전트로 가져왔다고 보면 이해가 빠를 거예요. 또 최근 화두인 MCP(Model Context Protocol)도 도구를 표준화된 방식으로 연결하는 프로토콜인데, Tendril은 거기서 한 발 더 나가서 "도구를 새로 만들어내는" 영역을 건드리는 거예요.

좋은 점과 조심할 점

장점은 명확해요. 개발자가 미리 모든 도구를 만들 수 없는 "롱테일" 작업에 강합니다. 사용자마다 요구사항이 달라서 예측이 어려운 사내 자동화, 데이터 분석, 워크플로우 같은 영역에서 진가를 발휘할 수 있어요.

반면 조심할 점도 있어요. AI가 만든 도구의 품질을 누가 검증하느냐는 어려운 문제예요. 처음 한두 번은 잘 돌아가도, 엣지 케이스에서 이상한 결과를 낼 수 있거든요. 그리고 도구가 점점 늘어나면 LLM이 "어떤 도구를 골라야 하지?" 하고 헷갈리는 도구 선택 문제도 생겨요. 도구가 100개쯤 쌓이면 컨텍스트에 다 못 넣으니까 검색/랭킹 시스템이 필요해지죠.

또 비용 측면도 봐야 해요. 도구를 만들 때마다 LLM이 코드 생성에 토큰을 쓰는데, 한 번 쓰고 버리는 도구라면 차라리 코드 인터프리터가 쌀 수도 있어요. 자주 재사용되는 작업에서만 본전을 뽑는 구조예요.

한국 개발자가 살펴볼 포인트

사내에 자체 에이전트 시스템을 구축 중인 팀이라면 Tendril의 설계를 한 번쯤 들여다볼 가치가 있어요. 직접 도입하지 않더라도, "도구를 영속화하고 재사용하는 패턴" 자체가 에이전트 시스템 설계에 큰 인사이트를 주거든요. 단순히 LangChain 튜토리얼만 따라가다 보면 놓치기 쉬운 부분이에요.

또 서버리스 환경에서 안전하게 동적 코드를 실행하는 방법, 자동 스키마 생성, 도구 레지스트리 관리 같은 주제는 사내 ChatOps나 자동화 봇을 만들 때도 그대로 응용할 수 있어요. 사이드 프로젝트로 작은 규모로 따라 만들어보면 에이전트 시스템에 대한 감이 확 생길 겁니다.

마치며

Tendril은 "AI가 자기 능력을 스스로 확장한다"는 다소 SF 같은 컨셉을 실용적인 코드로 옮긴 시도예요. 완성도보다는 방향성이 흥미로운 프로젝트입니다.

여러분이라면 AI 에이전트가 자기 도구를 스스로 만드는 시스템을 어디에 적용해보고 싶으세요? 그리고 "AI가 만든 코드를 그대로 신뢰해도 될까"라는 질문에는 어떻게 답하시겠어요?