Hacker News 의견

• 여러 tool call을 스트리밍할 때 context 사용량을 줄이는 방법을 찾고 있음
  일부 처리를 툴 자체로 오프로드해 200k 토큰짜리 markdown을 요약 구조로 반환하게 하지만, 이런 방식도 메인 모델의 context를 빠르게 채워버리는 경우가 있음

• Programmatic Tool Calling은 자연스러운 다음 단계라고 생각함
  LLM이 코드를 언어처럼 다루는 방향으로 가고 있으므로, 그 언어 정의가 중요함
  하지만 tool search는 불필요한 오버헤드라고 봄. 필요한 툴을 context에 미리 넣는 게 더 효율적임
  결국 함수 정의처럼 간결한 tool definition language가 필요하며, 객체를 context에 넣고 타입과 호출 가능한 메서드를 인식하게 하고 싶음

  • 이런 복잡한 구조 대신 .d.ts 같은 선언 파일을 주면 됨
    유지보수나 테스트도 쉽고, 필요하면 export * as Foo from '@foo/foo' 식으로 가져오면 됨
    LLM이 코드 작성도 잘하니, 쓰기 권한을 주면 스스로 툴을 만들거나 가져올 수 있음
    나중에는 Jupyter/Pluto/Mathematica 같은 인터랙티브한 AI↔인간 협업 플랫폼이 더 적합할 것 같음
    음성 입력을 붙이고, 세션 간 협업도 가능하게 하면 거의 Skynet 수준의 시스템이 될 것 같음
  • 왜 굳이 새로운 언어가 필요한지 모르겠음
    내가 만든 에이전트는 Python SDK의 일부 기능과 커스텀 함수만으로 충분히 동작함
    이런 pseudo-RPC 구조는 불필요한 의식처럼 느껴짐
  • 최신 MCP 사양(2025-06-18+) 은 Structured Content와 Output Schema를 지원함
    Smolagents가 이를 활용해 툴 출력을 객체(dict)로 다룸
    이런 접근이 내가 말한 방향과 비슷한지 궁금함
    자세한 내용은 Hugging Face 블로그 글에 있음

• MCP 서버가 툴 정의에 사용 예시를 포함할지 궁금함
  만약 그렇다면 코드 예시도 넣어 코드 생성 단계를 생략할 수 있을 텐데, 아마 보안 문제 때문에 막은 것 같음
  제3자가 제공한 코드를 실행하는 건 위험하니까 이런 설계가 이해됨

• Python을 래퍼로 쓴 게 아쉬움
  Bash를 썼다면 언어 간 호환성이 더 높고, Python을 쓰지 않는 워크플로에도 맞았을 것임

  • 나는 오히려 Python이 더 낫다고 생각함
    외부 툴 실행 능력도 Bash 못지않음
  • 그들은 사람들이 실제로 쓰는 언어가 Python이라는 걸 알고 그 방향으로 간 것 같음

• “수백~수천 개의 툴을 모델이 매끄럽게 다룰 미래”라는 방향은 잘못된 것 같음
  오히려 적은 툴 + 더 나은 활용 능력이 맞는 방향이라고 봄
  극단적으로는 ShellTool 하나로도 충분할 수 있음

  • 물론 모델이 모든 걸 처음부터 할 수도 있지만, 이미 검증된 툴이 있다면 그걸 쓰는 게 낫다고 생각함
    모델이 스스로 툴을 만들고 테스트해 신뢰할 수 있게 학습하는 방식이 이상적임
  • 나도 비슷하게 생각함
    커넥터 생태계는 이해하기 쉽고 마케팅하기 좋지만, 근본적으로는 잘못된 패러다임 같음

• 작은 로컬 오케스트레이터 모델이 있으면 좋겠다고 생각함
  전체 워크플로를 프로그램적으로 조율하기엔 비효율적인 경우가 많음
  context 오염을 줄이고 속도를 높이려면 programmatic > tiny local LLM > frontier LLM 구조가 이상적임
  작은 모델은 context를 자주 초기화하고, 필요한 결과만 큰 모델에 전달하면 됨

• AI 어시스턴트를 쓰다 보면 반복되는 패턴이 있음
  비효율적인 방법을 직접 개선하면, 몇 달 뒤 새 툴이 나와서 내 작업이 무의미해짐
  최신 기술을 쫓는 대가라고 생각함

• 언젠가 웹 전체가 수십억 개의 툴로 구성될 것 같음
  Google이 이를 인덱싱하고, Gemini가 동적으로 선택해 세상에서 행동을 수행하게 될 것임
  사실 이런 걸 Gemini 3에서 기대했음

• 여기서 말한 기능 #2는 최근 화제가 된 “툴을 직접 호출하지 않고 코드를 작성해 호출”하는 개념의 구현임
  Python sandbox에서 동작하며, API로도 접근 가능하고, 툴 호출을 일반 API 호출처럼 노출함
  Batch tool calling은 이미 우리 제품의 AI 어시스턴트 속도를 크게 높였고, 이번 기능은 그 진화형처럼 보임

• 우리 agentic builder는 단 하나의 툴만 씀 — 바로 GraphQL임
  에이전트가 쿼리를 작성해 실행하고, introspection으로 필요한 정보를 얻음
  최소한의 데이터만 받아 토큰 절약이 가능함
  50개 이상의 툴을 로드할 필요도 없고, REST API의 N+1 문제도 해결됨
  GraphQL typed schema 덕분에 에이전트가 더 나은 코드를 작성함
  예전엔 GraphQL을 좋아하지 않았지만, MCP의 현 상태를 보면 AI 에이전트에 가장 적합한 기술 중 하나라고 생각함
  자세한 내용은 이 글에 정리했음

  • 나도 비슷한 접근을 씀
    내 에이전트는 SPARQL 쿼리 하나만 수행하고, 상태는 그래프 DB뿐임
    대부분의 온톨로지가 공개되어 있어서 schema introspection이 거의 필요 없음
    구조화된 출력 덕분에 유효한 RDF만 생성하도록 제약할 수 있음
    GraphQL에서도 비슷한 방식이 가능할 듯함
  • 하지만 모든 사용 사례에 맞진 않음
    나는 웹 검색, 로컬 API 호출, Slack 통합 등 다양한 작업을 해야 해서 GraphQL 하나로는 부족함
  • GraphQL introspection은 정의가 너무 길어져 토큰 낭비가 생기거나, 여러 번 호출해야 하는 문제가 있음
  • 그래도 이건 정말 좋은 GraphQL 활용 예시임
    권한, 캐싱, mutation 문제는 있지만 선택적 context 로딩에는 큰 영향이 없음
  • 우리도 Exograph에서 같은 접근을 취함 (exograph.dev)
    LLM이 schema에 맞는 GraphQL 쿼리를 꽤 잘 작성함
    실수하더라도 에러 메시지를 잘 주면 금방 수정함
    관련 reasoning은 이 블로그 글에 있음