모델은 하나로 묶었는데, 도구는?
LLM으로 서비스를 만들어 봤다면 OpenRouter를 한 번쯤 들어봤을 거예요. Claude, GPT, Gemini, Llama 같은 여러 모델을 API 키 하나와 OpenAI 호환 API 하나로 골라 쓸 수 있게 해 주는 서비스예요. 여러 항공사 표를 한 사이트에서 비교하고 결제하는 여행 예약 사이트 같은 거라고 보면 돼요.
그런데 AI 개발의 중심이 모델 호출에서 에이전트로 옮겨 가면서 새로운 불편이 생겼어요. 에이전트는 혼자 생각만 하는 게 아니라 웹 검색, 웹페이지 스크래핑, 이미지 생성, 코드 실행, 이메일 발송 같은 도구(tool)를 써야 일을 끝낼 수 있거든요. 이번에 공개된 Treg가 겨냥하는 게 바로 이 부분이에요. 스스로를 도구를 위한 OpenRouter라고 소개해요.
지금 도구 연결이 왜 귀찮냐면
에이전트에 도구 10개를 붙인다고 생각해 보세요. 서비스 10곳에 가입하고, API 키 10개를 받고, 문서 10개를 읽고, 제각각인 응답 형식을 맞추고, 결제 수단도 10군데에 등록해야 해요. 그다음 각 도구를 LLM이 이해할 수 있는 함수 스키마(JSON Schema)로 다시 정리해 줘야 하고요. 프로토타입 하나 만들려다가 연동 작업에 하루를 다 쓰는 일이 흔해요.
도구용 라우터는 이걸 한 겹으로 감싸자는 아이디어예요. 엔드포인트 하나와 키 하나로 여러 도구를 호출하고, 도구 정의는 LLM이 바로 쓸 수 있는 통일된 형식으로 주고, 과금도 한 곳에서 관리하는 식이에요. OpenRouter가 모델 사이에서 폴백(한 곳이 죽으면 다른 곳으로 우회)을 해 주듯이, 같은 기능을 하는 도구 공급자를 바꿔 끼우는 것도 기대해 볼 수 있어요. treg라는 이름은 tool registry(도구 등록소)를 떠올리게 하는데요, 어떤 도구를 지원하는지, 과금과 인증은 어떻게 처리하는지는 레포 README에서 직접 확인하는 게 좋아요.
MCP가 있는데 이게 왜 또 필요해?
자연스럽게 떠오르는 질문이에요. MCP(Model Context Protocol)는 Anthropic이 2024년 말에 공개한 규격으로, 흔히 AI를 위한 USB-C라고 불려요. 도구를 어떤 형식으로 연결할지 정한 표준 규격이에요. Treg 같은 라우터는 그 위에서 도구를 모아 공급하는 유통 계층에 가까워요. USB-C라는 규격이 있어도 어떤 케이블을 어디서 살지, 정품이라고 믿어도 될지는 또 다른 문제잖아요.
실제로 MCP 서버는 엄청나게 늘었어요. 하지만 쓸 만한 걸 찾는 문제(발견), 서버마다 로그인과 토큰을 관리하는 문제(인증), 악성은 아닌지 확인하는 문제(신뢰)는 여전히 남아 있어요. 그래서 이 계층을 노리는 곳이 많아요. 공식 MCP Registry, MCP 서버 마켓플레이스인 Smithery, 수백 개 앱 연동과 OAuth 관리를 대신해 주는 Composio, 기존 자동화 연동을 에이전트에게 열어 준 Zapier와 Pipedream이 대표적이에요. Treg는 그중에서도 모델 라우터처럼 단순하게 쓰는 개발자 경험에 초점을 맞춘 시도로 볼 수 있어요.
쓰기 전에 고민할 지점
첫째는 컨텍스트 비용이에요. 도구를 쉽게 붙일 수 있다고 수십, 수백 개의 스키마를 프롬프트에 다 넣으면 토큰이 크게 늘고, 모델이 엉뚱한 도구를 고를 확률도 올라가요. 필요한 도구만 그때그때 찾아 쓰는 도구 검색 같은 장치가 함께 있어야 해요.
둘째는 보안과 신뢰예요. 라우터는 모든 도구 호출이 지나가는 길목이에요. 내 자격 증명을 맡기는 셈이고, 도구 응답에 악성 지시를 숨기는 프롬프트 인젝션의 통로가 될 수도 있어요. 셋째는 단일 장애점과 지연이에요. 중간에 단계가 하나 더 생기니까 라우터가 느려지거나 멈추면 에이전트 전체가 멈춰요. 오픈소스라면 직접 호스팅해서 이 위험을 줄일 수 있는지 확인해 볼 만해요.
한국 개발자에게 주는 시사점
사이드 프로젝트나 해커톤에서 에이전트를 빨리 만들어 보고 싶다면, 이런 도구 라우터로 연동 시간을 크게 줄일 수 있어요. 다만 네이버 검색, 카카오맵, 국내 결제 같은 한국 서비스는 지원이 부족할 가능성이 높아요. 오픈소스라면 오히려 어댑터를 직접 기여해 볼 좋은 기회예요.
회사에서 일한다면 설계 패턴으로 참고할 가치가 커요. 사내 API를 에이전트에게 열어 줄 때 도구 게이트웨이를 하나 두고 인증, 권한, 로깅, 비용 추적을 한곳에서 관리하는 구조는 거의 필수가 되어 가고 있거든요. 모델 라우터, 도구 라우터, 에이전트 프레임워크로 이어지는 계층 구조를 이해해 두면 아키텍처를 그릴 때 훨씬 수월해요.
마무리
한 줄로 정리하면, 모델을 API 하나로 묶던 흐름이 이제 도구로 넘어오고 있고 Treg는 그 신호 중 하나예요. 에이전트에 도구를 붙일 때 MCP 서버를 직접 연결하는 편인가요, 이런 통합 라우터를 쓰는 편인가요? 각자 어떤 기준으로 고르는지 궁금해요.
🔗 출처: Hacker News