▲

LLM 함수 호출은 확장되지 않는다; 코드 오케스트레이션이 더 간단하고 효과적임

 (jngiam.bearblog.dev)
6P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • LLM이 툴 호출 결과 전체를 처리하는 방식은 느리고 비용이 크며 확장에 불리함
  • 대신, 출력 스키마 기반으로 구조화된 데이터를 코드로 처리하도록 LLM이 오케스트레이션하게 하는 방식을 제안
  • 이 접근은 코드를 통한 함수 체이닝과 변수 기반 메모리 관리로 대량 데이터 처리에 적합
  • 코드 실행 기반 데이터 처리 방식은 LLM이 직접 데이터를 복원하지 않으므로 정확성과 확장성이 뛰어남
  • 보안이 확보된 AI 런타임 환경 구축이 새로운 과제로 부상 중이며, 지속 가능하고 상태 유지가 가능한 실행 환경이 필요함

LLM function calls don't scale; code orchestration is simpler, more effective.

툴 호출 결과를 LLM에 다시 전달하는 기존 방식의 한계

  • MCP(Machine Context Protocol) 툴을 사용할 때 보통 LLM에게 툴 출력 결과를 메시지로 전달하고 다음 조치를 유도함
  • 실제 사용 사례에서 Linear와 Intercom의 MCP 서버는 JSON 형식의 커다란 응답을 반환함
  • JSON은 API와 유사하나 정의된 출력 스키마가 없어 LLM이 전체 텍스트를 파싱해야 하는 부담이 발생함
  • 예를 들어 Linear의 이슈 목록 조회 결과는 50개 항목에 70,000자, 약 25,000토큰으로 매우 큼
  • 많은 id 필드는 의미는 없지만 토큰을 소모하고, LLM이 이를 그대로 재현하려면 비용과 오류가 커짐

데이터 처리와 오케스트레이션의 분리 필요

  • 현재 방식은 데이터 처리와 오케스트레이션을 한 채팅 세션에 혼합하고 있음
  • 일부는 이를 위해 "에이전트"로 다른 스레드를 생성하나, JSON이 구조화되어 있는 경우엔 비효율적
  • 보다 나은 방식은 구조화된 데이터를 코드로 직접 처리하는 것임
    • 예: 이슈 정렬은 LLM이 출력 생성하는 대신 코드로 sort 실행 후 결과 배열만 반환

코드 실행 기반의 데이터 처리

  • 코드 실행을 통한 AI 연산은 이미 다양한 AI 인터프리터에서 사용 중
  • 이 방식은 LLM이 직접 데이터를 출력하지 않고 도구 사용 방식만 결정하면 되는 간결한 구조를 가능케 함

주요 개념

  • 변수를 메모리로 활용: 값 할당 = 저장, 출력 = 조회, 함수 호출 시 인자로 전달
  • 함수 체이닝 지원: 여러 함수 호출을 병렬/순차로 조합, 의존성은 코드 내 자연스러운 흐름으로 표현
  • 확장 가능한 대량 데이터 처리: NumPy, pandas 등과 결합해 수천~수만 건의 데이터도 쉽게 처리 가능
  • 다른 LLM 호출도 가능: LLM이 작성한 코드 내에서 또 다른 LLM을 호출해 비정형 데이터 처리도 가능

MCP는 준비되어 있는가?

  • MCP 사양은 이미 입력 스키마를 정의하고 있으며, 최근엔 출력 스키마 PR도 제출됨
  • 출력 스키마가 보편화되면 다음과 같은 활용이 가능해짐:
    • 이슈 현황 대시보드
    • 주간 완료 티켓 리포트
    • 정체된 티켓을 AI가 모니터링하고 푸시

코드 실행 환경의 과제

  • 보안이 핵심 이슈: AI/사용자가 생성한 코드를 실행하므로 API 키와 데이터 노출 방지 설계 필요
  • Lutra의 경우, 실행 환경은 샌드박스 방식으로 구성하며, 모델에게는 API 호출 문서만 제공
  • 상태 유지형 실행 환경(Jupyter 등)은 고비용이며, 장기 세션을 위해선 상태 없음(stateless) + 지속성(persistent) 특성 필요
  • 이는 새로운 형태의 AI 런타임(runtime) 이라는 카테고리를 형성하며, 아직 설계가 활발히 진행 중임

결론

  • 툴 호출 결과를 LLM에 넣어 처리시키는 기존 방식은 비용과 정확성에서 한계가 있음
  • 코드 기반 오케스트레이션은 간결하면서도 확장 가능하고 정확한 처리를 가능하게 함
  • AI 코드 실행 환경은 보안, 지속성, 확장성을 갖춘 차세대 런타임으로 주목받고 있음
▲
GN⁺ 1일전  [-]
Hacker News 의견
  • 지난 2년간 "충분히 고도화된 에이전트는 DSL과 구분이 불가능"하다고 주장한 경험 공유. 에이전트가 알고리즘을 내재화하게 요구하기보다는 API를 가르치고, 그 API를 활용한 알고리즘 설계를 요청해 유저 스페이스에서 실행하는 쪽이 훨씬 적합하다는 의견. LLM 내부에 알고리즘을 집어넣는 것은 극히 일부 상황(비용이나 정확도 측면에서) 외에는 비효율적이라는 생각. 개발자에게 함수 실행을 머릿속으로 하라고 요구하는 것과 같은 맥락이라는 비유
    • ASI(인공 일반 지능)로 가는 길은 LLM의 기능 확장에 있지 않고, 오히려 외부에서 자기 개선 알고리즘을 심볼릭 애플리케이션 형태로 추출하고 컴파일하는 과정에 있다는 증거로 해석
    • 2년 전부터 이 맥락에서 'agent'라는 용어를 널리 썼다는 근거나 사례 공유 요청
  • 나의 이커머스 비즈니스에서 agentic 시스템 직접 구축 경험. smolagents를 평가해봤는데, 우아하고 매력적이지만 시스템 복잡성을 크게 높이는 단점 존재. 다이나믹 리포팅처럼 스키마 없이 데이터를 정렬·집계하는 환경엔 완벽하지만, 대부분의 작업에는 오버킬. Gemini, OpenAI가 파이썬 인터프리터 기능을 제공해서 코드 에이전트의 상당 부분 업무를 커버할 수 있음. 끝없이 툴 호출 메시지를 스택에 쌓는 식의 접근은 확장성 낮아 추천하지 않음. 실제 agentic 워크플로우는 수명이 짧고, 구조와 규율로 복잡성을 관리. 기존 소프트웨어 개발의 교훈, 즉, 함수 호출의 스케일 관리와 혼란 방지는 예나 지금이나 동일. 좋은 시스템 구축의 핵심은 개발자의 인지적 부담 관리에 있으며, 단순하지만 충분히 동작하는 솔루션이 성능 좋은 기교적인 방식보다 우위. 함수 호출 조합은 이러한 단순 솔루션의 예이며, 구조화된 데이터 처리도 전통적인 파싱·변환 방법으로 충분. 구조가 미지수일 땐 저렴한 모델도 훌륭한 파싱 성능 발휘. agentic 시스템의 복잡성 관리는 결국 어플리케이션 상태를 치밀하게 관리하는 문제로 요약. 메시지 스택 조작으로 모델에 입력할 활성 컨텍스트를 유연하게 구성할 수 있으며, 이는 제약된 환경에서의 메모리 관리와 유사
    • Agentic 시스템의 트레이드오프를 정확히 짚어낸 요약. 우리도 이커머스 대화형 제품 검색 솔루션(IsarTech) 구축하며 같은 문제 고민. 함수 조합과 구조화 데이터는 복잡성 제어의 핵심. 경험상, 명확한 타입 스키마 기반 출력이 도구 호출의 확장성을 실질적으로 끌어올림. 타입 스키마 덕분에 인지 부하와 시스템 복잡성 모두 관리 가능. 가능한 결정적 동작에 의존하고, 스키마 없는 데이터나 모호성이 있을 때만 LLM 활용. 모호한 요청 → 결정적 시스템 매핑에 LLM이 매우 효과적. 다만, 고엔트로피(비정형) 입력에서 복잡성 제거와 도구 호출 연쇄를 통한 복잡성 증가 간에 균형이 필요. 실제 커머스 환경에선 하나의 방식만 쓰기 힘들고, 구조화 출력은 모호한 의도에선 한계가 있어 추가 전략 필요
  • 문제는 함수 호출 자체가 아니라 MCP 디자인 및 사용 방식이라는 지적. 대부분의 MCP는 API 복제이며 무의미한 데이터 방출 문제 존재. JSON 포맷을 반복적으로 중첩해 불필요하게 많은 입력 컨텍스트 소모, 비관련 정보가 다수 포함. 데이터 플래트닝과 필요 없는 필드 삭제 등 최적화 필요. MCP SaaS는 결국 API 게이트웨이 역할에 불과. 현재 MCP는 노이즈 발생의 주범이며 충분히 최적화되지 않음
    • GraphQL이 바로 이런 목적에 최적화된 기술. 필요한 필드만 선택할 수 있도록 설계됨. 여러 GraphQL 쿼리를 하나의 MCP 서버로 변환해주는 오픈소스 Gateway를 개발
    • 모델이 복잡한 JSON 스키마를 제대로 따르지 않는 것이 문제 아닌지에 대한 의문 제기
    • MCP는 도움이 되지 않으나 무조건 필터링도 최선책 아님. 때로는 에이전트가 대량 데이터 처리가 필요. 이럴 땐 간단한 데이터 평가와 스키마 설명이 포함된 코드 실행이 더 확장성 좋은 접근. 물론, 시스템이 너무 커지면 비슷한 문제가 발생. 궁극적 해결책은 인간의 결정적 사고 수준의 정밀도를 코드로 재현하고, 이 결정 시스템을 LLM이 호출하는 구조. 이론상 쉽지만 실제 구현은 매우 어렵다는 점 강조
    • ChatGPT로 문자열 뒤집기 테스트 시 LLM이 단순한 결과만 제공하게 만들기가 매우 힘들었고 신뢰도도 낮다고 느낌. 이 경험 이후 항상 여러 LLM에 검증시키는 습관. 이 페이스대로라면 단순 문자열 내 문자 개수 세기를 위해 자체 GPU 데이터센터 준비해야 할지도 모른다는 농담
  • Shopify 팀에서 최근 Roast를 오픈소스로 공개. 거대한 코드베이스 자동화에 비결정적 LLM 작업을 워크플로 내에 삽입할 수 있는 도구. 복잡한 업무 자동화에 필수
    • Roast에 깊은 인상. 결정성과 비결정성의 조화가 매우 돋보임. LLM이 여러 도구 호출을 어떻게 오케스트레이션하고, 호출 순서를 결정할 수 있는지 약간 헷갈림. 리팩토링 지시 때 동작하는 것 같긴 하지만 "개선→테스트 반복"과 같은 복합 작업에는 적합한지 궁금증
    • Ruby가 AI 시대에도 꾸준히 의미 있게 작동한다는 점이 신선하게 느껴짐
    • 문서만 읽어도 지적 자극이 있는 훌륭한 방식. LLM의 기능을 선언적(declarative)으로 패키징한 점이 인상적
    • Shopify 내부에서 실제로 어떻게 이런 워크플로가 쓰이는지, 구체적 사례 공유 요청
    • Claude Code Research Preview와 ChatGPT 4.5 Pro Deep Research를 모두 크래시시킨 경험이 있고(증거도 있음), 확실하게 동작하는 도구를 찾는 중
  • 최적의 답은 극단적 한 쪽이 아닌 하이브리드에 있음. 결정적 접근으로 가능한 한 많이 해결하고, LLM은 스펙화나 결정적 기술이 힘든 복잡 부분에 활용하는 방식이 가장 낫다는 생각
    • LLM을 활용해 결정적 솔루션(코드) 생성에 집중하고, 그 코드가 검증되면 앞으로는 결정적 코드로 재사용하는 전략이 흥미로운 접근
    • 워크플로 내 LLM 사용을 최소화하는 것이 지향점이라는 주장
  • 1년 넘게 업계를 떠난 사이에 이런 복잡한 실험이 일반화됐는지 놀람
    • 실제론 아직 소수가 실험 중이며, 혁명적 사례는 없지만 일부 유용한 사례는 있음
    • 지금 이런 작업을 하지 않으면 오히려 곧 업계를 다시 떠나게 된다는 견해도 나옴
    • 자신의 일상 업무가 이미 LLM 기반 AI 에이전트 설계 자동화에 치중되어 있음. 원해서가 아니라 자기도 모르게 그렇게 됨
  • LLM을 구조화 데이터 정렬에 쓰는 이유가 궁금
    • 목표는 대시보드 구축, 이슈 티켓 자동 파악, 분기별 리뷰 등 더 복잡한 데이터 처리가 주된 목적. 정렬 자체는 단순한 예시일 뿐, 문제의 크기를 이해하기 쉽게 보여주는 소소한 사례
  • huggingface smolagent는 이런 접근의 대표 사례이지만, 실제 동작 실패 시 롤백이나 복구가 매우 까다로워지는 문제점 동반. 실행 블록 전체를 분산 트랜잭션으로 감싸는 등 원론적 해결 가능하나, 실제론 LLM이 견고한 코드를 만들려다 이 패턴과 맞지 않아 오류 추적 및 실패 원인 파악이 어려워짐
    • smolagent의 기본 아이디어는 좋지만, 실행 및 에러 처리 현실이 문제라는 공감. 예를 들어, 코드 실행이 중단되었을 때 해당 상태로부터 바로 이어갈 수 있길 원함. LLM이 상태 복구 코드를 잘 작성하는 것은 확인했으며, 현재는 이러한 기능이 실제 제품(Lutra)에서 꽤 잘 동작 중
  • 또 다른 접근법으로, LLM이 MCP를 함수처럼 호출하는 코드(Python 스크립트 형태)를 작성하도록 유도. 예시 코드 공유
    • 이 방식 실전 적용한 사례로 Lutra.ai 소개. 핵심은 코드 런타임을 얼마나 잘 설계하느냐에 달려 있음
  • LLM이 특히 JSON, 특히 대용량 JSON 처리에 취약하다는 사실. 엔드포인트가 굳이 JSON이 아닌 다른 포맷으로 데이터를 반환해도 무방. LLM은 xml에 훨씬 강점을 보이기도 하며, 템플릿으로 내러티브 텍스트로 만들어주는 방법도 가능
    • XML은 내재적 의미 정보를 가진 포맷이라 LLM 기본값으로 널리 쓰지 않는 게 의외. 필요한 경우, XML을 결정적으로 JSON으로 변환해 파이프라인에 투입하면 효과적
    • LLM에 데이터를 반환할 때 마크다운 테이블을 사용해 꽤 좋은 효과를 본 경험
    • XML이 더 성능이 좋은 것이 LLM 학습 데이터에서 더 자주 등장해서인지, 텍스트 토큰 수가 많기 때문인지 궁금증. 텍스트 덩어리가 오히려 LLM에 더 많은 문맥 제공 가능성 언급
답변달기