툴 로트(Tool Rot) 역설: 개발 단계에서 에이전트 스킬 50개 이상 설치하면 운영 환경에서 무너지는 이유
Tool Rot Paradox: Why installing 50+ agent skills in development breaks down in production
핵심 요약
에이전트에게 너무 많은 스킬을 정적으로 설치하면 컨텍스트 윈도우가 오염되고 성능이 저하되므로, 동적 레지스트리를 통한 도구 호출 방식이 필요함.
- 툴 로트 역설 — 에이전트 스킬 과다 설치로 인한 성능 저하와 유지보수 부채 발생함.
- 컨텍스트 오염 — 수십 개의 도구 스키마가 모델의 지시 이행 능력을 저하시키고 오류를 유발함.
- 동적 레지스트리 — 정적 설치 대신 필요할 때 도구를 검색하고 주입하는 방식으로 확장성을 확보함.
- 런타임 최적화 — 에이전트 하네스를 경량화하여 시스템 프롬프트를 간결하게 유지하고 환각을 줄임.
슬슬 복잡한 에이전트 워크플로우를 짜기 시작하면, 본능적으로 도구나 스킬을 npm 패키지처럼 다루게 됨. 에이전트가 새로운 걸 해야 할 때마다 새 스킬을 설치하고, 래퍼(wrapper)를 짜고, 프롬프트나 스키마를 업데이트해서 컨텍스트 윈도우에 쑤셔 넣는 식이지.
근데 에이전트 스택을 좀 굴려보고 유지보수하다 보면, 이 방식은 곧바로 한계에 부딪힘.
- 도구 비대화로 인한 컨텍스트 윈도우 오염
수십 개의 도구 스키마를 한꺼번에 노출하면 모델의 지시 이행(instruction_following) 성능이 씹창남. 모델이 엉뚱한 도구를 고르거나, JSON 스키마를 잘못 해석하거나, 스킬 간 경계가 겹치면 뇌정지 오는 경우가 허다함.
- 유지보수 및 보안 부채
에이전트 런타임에 직접 박아 넣은 모든 정적 스킬은 즉시 기술 부채가 됨:
구식 API 스키마는 실행 도중에 조용히 터져버림.
검증 안 된 서드파티 커뮤니티 스킬은 프롬프트 인젝션이나 데이터 유출 같은 심각한 보안 구멍을 만듦.
스킬 로직을 수정하려면 로컬 코드베이스를 다 건드리고 하네스(harness)를 다시 배포해야 함.
패러다임의 전환: 정적 설치에서 동적 탐색으로
에이전트에 거대한 기능 라이브러리를 하드코딩하는 대신, 실무에서 훨씬 잘 먹히는 방식은 동적 레지스트리와 결합된 단일 라우팅/메타 스킬을 쓰는 거임.
시스템 프롬프트에 50개가 넘는 도구 스키마를 때려 박는 대신:
에이전트는 딱 하나의 기본 도구만 들고 있음: discover_and_execute_capability.
사용자 요청이 들어오면, 에이전트는 그 의도를 레지스트리로 넘김.
레지스트리는 동적으로 인덱싱되고 보안 검증까지 마친 기능 데이터베이스에서 작업을 평가하고, 딱 필요한 스키마만 가져와서 해당 턴에 맞춰 즉시 실행하거나 주입함.
결론
네 에이전트 하네스(lyzr control plane이나 google azure foundry 같은 거)는 설치된 의존성 덩어리가 되면 안 됨.
필요할 때마다 도구를 동적으로 가져오는 가벼운 런타임이어야 함. 그래야 시스템 프롬프트도 깔끔하게 유지되고, 도구 호출 환각도 줄어들고, 기능 업데이트를 로컬 애플리케이션 로직이랑 분리할 수 있음.
