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

• 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 코드 실행 환경은 보안, 지속성, 확장성을 갖춘 차세대 런타임으로 주목받고 있음