LLM이 직접 다 하지 않아도 된다? 코드 오케스트레이션이 답이다

최근 LLM(Large Language Model)을 활용한 자동화 시스템 구축이 빠르게 확산되고 있습니다. 하지만 실제 구현 과정에서 많은 개발자들이 공통으로 겪는 난관이 있습니다. 바로 툴 호출 결과를 LLM이 직접 처리하게 하는 방식의 비효율성과 확장성 문제입니다.

이 블로그에서는 기존 방식이 왜 한계에 부딪히는지 살펴보고, 그 대안으로 부상하고 있는 코드 오케스트레이션 방식이 어떤 장점을 가지는지 소개합니다. 특히 출력 스키마를 기반으로 한 구조화된 데이터 처리, 코드 실행 환경의 중요성까지 함께 살펴보며, 이 새로운 접근법이 어떻게 더 나은 AI 시스템을 설계할 수 있게 돕는지 설명합니다.

반응형

툴 호출 결과를 LLM이 직접 처리하는 방식의 한계

현재 많은 시스템에서는 LLM이 외부 도구를 호출한 뒤, 그 결과를 다시 입력으로 받아 직접 텍스트로 파싱하고 판단합니다. 이 방식은 처음에는 직관적이지만, 실제 운영 환경에서는 여러 가지 문제를 일으킵니다.

첫째, 데이터 양이 커질수록 파싱 비용이 기하급수적으로 증가합니다. 예를 들어 Linear에서 이슈 목록을 조회하면 50개 항목 기준 약 70,000자, 25,000 토큰 수준의 응답이 생성됩니다. LLM은 이 모든 데이터를 일일이 파싱해야 하며, 이는 시간과 비용을 크게 증가시키는 요인입니다.

둘째, JSON 형식의 출력에는 의미 없는 필드(id 등)가 많고, 이들까지 처리하려면 모델에 불필요한 부하가 발생합니다. LLM이 전체 데이터를 그대로 재현하려면 구조적 복잡성도 증가하며, 오류 가능성 역시 커집니다.

코드 오케스트레이션: LLM은 결정만, 실행은 코드가

이러한 문제를 해결하기 위한 대안으로 제안된 것이 코드 오케스트레이션입니다. 이 방식의 핵심은 간단합니다. LLM이 데이터를 직접 출력하거나 재구성하지 않고, 어떤 코드를 실행할지를 판단하는 역할만 수행하는 것입니다.

예를 들어, 이슈 목록을 정렬하는 작업이 필요할 때 기존 방식에서는 모델이 전체 데이터를 읽고, 정렬된 결과를 생성해야 했습니다. 하지만 코드 오케스트레이션 방식에서는 모델이 'sort(issues, key="priority")'와 같은 명령을 작성하고, 실제 정렬은 코드가 처리합니다. LLM은 단지 의사결정을 담당하고, 결과는 처리된 데이터 형태로 전달됩니다.

이 구조는 간결하면서도 훨씬 더 효율적이며, 무엇보다 대규모 데이터에 강한 확장성을 보입니다.

구조화된 데이터의 힘: 출력 스키마 활용

코드 오케스트레이션이 제대로 작동하기 위해서는 데이터가 구조화되어 있어야 합니다. 즉, 출력 스키마가 정의되어 있어야 한다는 뜻입니다. 출력 스키마는 JSON 응답이 어떤 구조를 가지는지, 어떤 데이터가 필수인지 명확하게 정의해줍니다.

출력 스키마가 존재하면 LLM은 전체 응답을 파싱하지 않아도 필요한 데이터만 선택적으로 사용할 수 있습니다. 현재 MCP(Machine Context Protocol) 사양에서도 출력 스키마에 대한 제안이 진행 중이며, 이를 통해 자동화된 분석 및 리포트 작성이 가능해집니다.

예를 들어, 출력 스키마 기반 시스템에서는 다음과 같은 작업이 자동화될 수 있습니다:

• 이슈 현황 대시보드 생성
• 주간 완료 티켓 리포트 작성
• 정체된 티켓 탐지 및 알림 자동화

코드 기반 데이터 처리의 장점

코드 오케스트레이션의 또 다른 장점은 다양한 도구 및 언어와의 결합 가능성입니다. LLM이 작성한 코드를 Python 환경에서 실행하거나, NumPy, pandas 등의 라이브러리와 함께 사용할 수 있습니다.

이 방식은 특히 다음과 같은 기능에서 유리합니다:

• 수천 건 이상의 데이터를 빠르게 처리할 수 있음
• 함수 호출을 체이닝해 복잡한 로직도 간단하게 구현 가능
• 코드 내에서 또 다른 LLM을 호출해 비정형 데이터도 처리 가능

또한 변수의 값을 저장하고 불러오는 방식으로 간단한 메모리 개념도 구현할 수 있어, 상태 기반의 작업 분기나 반복 실행도 가능합니다.

실행 환경의 과제: 보안과 지속 가능성

물론 이 접근에도 해결해야 할 과제는 존재합니다. 가장 대표적인 것이 보안 문제입니다. AI 또는 사용자가 작성한 코드가 실행되는 만큼, API 키나 민감한 데이터가 외부에 노출될 가능성을 철저히 방지해야 합니다.

이와 관련하여 Lutra 등은 샌드박스 방식의 실행 환경을 도입하고, LLM에게는 API 호출 문서만 제공하는 방식으로 보안을 강화하고 있습니다. 또한 지속적인 세션 유지를 위해서는 상태 유지형 환경(Jupyter 등)이 필요하지만, 고비용이기 때문에 무상태(stateless) 환경에 지속성(persistence)을 부여하는 새로운 형태의 AI 런타임 설계가 활발히 논의되고 있습니다.

728x90

더 나은 AI 시스템을 위한 방향

툴 호출 결과를 LLM이 직접 처리하던 기존 방식은 효율성, 비용, 확장성 측면에서 분명한 한계가 존재합니다. 코드 오케스트레이션은 이러한 문제를 해결하기 위한 명확하고 실용적인 대안입니다.

LLM은 판단만 하고, 데이터 처리는 코드가 담당하는 이 구조는 간결함, 효율성, 보안성, 확장성 등 모든 측면에서 더 우수한 시스템 구현을 가능하게 합니다. 앞으로 AI 기반 시스템이 점점 더 복잡하고 대규모로 확장됨에 따라, 이러한 설계 방식은 필수가 될 것입니다.

이제는 LLM에게 모든 걸 맡기는 대신, '무엇을 해야 할지'만 물어보는 것이 더 현명한 선택일 수 있습니다.

https://jngiam.bearblog.dev/mcp-large-data/

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