Runtime Burden Allocation for Structured LLM Routing in Agentic Expert Systems: A Full-Factorial Cross-Backend Methodology

이 논문은 구조화된 LLM 라우팅을 프롬프트 엔지니어링 문제가 아닌 시스템 수준의 부하 분배 문제로 재정의하고, 48 가지 배포 구성과 15,552 개의 요청에 대한 풀-팩토리얼 벤치마크를 통해 백엔드별 상호작용 효과가 성능을 결정하므로 단일 최적 방식은 존재하지 않으며 이질적인 백엔드 환경에서 정확성, 비용, 지연 시간의 균형을 위한 실용적 배포 프레임워크를 제시합니다.

핵심

🍽️ 비유: "요리사 (AI) 와 주문서 (시스템)"의 관계

이 논문이 다루는 주제는 다음과 같습니다:

• 고객의 주문 (질문): "오늘 저녁 뭐 먹지?"
• 요리사 (AI): 주문을 듣고 메뉴를 추천하는 거대한 두뇌.
• 주문서 (구조화된 출력): 요리사가 작성해야 하는 최종 지시서. (예: "메뉴: 김치찌개, 테이블: 3 번, 주방: A 구역")

기존에는 "요리사 (AI) 가 얼마나 똑똑한가?"만 중요하게 여겼습니다. 하지만 이 논문은 **"요리사가 주문서를 쓰는 방식과 그 주문서를 전달받는 방식"**이 훨씬 더 중요하다고 말합니다.

🔍 핵심 발견: "하나의 정답은 없다"

이 연구는 3 가지 다른 요리사 (OpenAI, Gemini, Llama) 에게 같은 주문을 시켰고, 주문서를 작성하는 4 가지 다른 방식을 실험했습니다. 결과는 놀라웠습니다.

"어떤 방식이 가장 좋은지는 요리사 (AI) 가 누구냐에 따라 완전히 달라집니다."

1. 상황별 최적의 전략 (비유)

• A 요리사 (Gemini, OpenAI):

  • 이 요리사들은 **정확한 주문서 (JSON)**를 직접 작성하는 것을 가장 잘합니다.
  • 전략: "요리사에게 직접 완벽하게 적어달라." (직접 JSON 출력)
  • 결과: 실수가 거의 없고, 시스템이 안정적입니다.

• B 요리사 (Llama):

  • 이 요리사는 **짧은 메모 (압축된 코드)**만 적어주는 것은 잘하지만, 그것을 다시 완벽한 주문서로 바꾸는 과정에서 혼란을 겪습니다.
  • 전략: "요리사에게 짧은 메모만 적게 하고, 우리가 그걸 주문서로 만들어라." (압축 후 로컬 재구성)
  • 결과: 속도는 매우 빠르고 비용은 싸지만, 실수가 폭증합니다. (예: "김치찌개"를 "김치볶음밥"으로 잘못 적음)

2. 중요한 교훈: "속도보다 정확성이 먼저다"

많은 회사가 "비용을 아끼고 속도를 내자!"라고 해서 AI 가 짧은 메모만 적게 하거나 (압축), 실시간으로 글자를 하나씩 띄워주게 (스트리밍) 합니다.

하지만 이 논문은 말합니다:

"시스템이 멈추지 않으려면, 주문서가 완성될 때까지 기다려야 합니다."

• 스트리밍 (실시간 출력): 요리사가 "김치... 찌개..."라고 하나씩 말해도, 주방은 "김치찌개"라는 전체 주문서가 완성되기 전에는 요리를 시작할 수 없습니다. 따라서 실시간으로 보여주는 것은 고객에게는 편할지 몰라도, 시스템 운영에는 큰 도움이 되지 않습니다.
• 비용 절감의 함정: Llama 같은 모델은 짧은 메모를 쓰게 하면 비용이 70% 이상 줄지만, 실수율이 60% 이상 폭등합니다. 결국 잘못된 주문으로 인해 다시 요리해야 하는 비용이 더 듭니다.

💡 이 논문이 주는 3 가지 실전 조언 (Deployment Rules)

이 연구를 바탕으로 시스템 설계자들이 따라야 할 3 가지 규칙을 제안합니다.

1. 정확성이 생명이라면, "완벽한 주문서"를 요구하세요.

   • (OpenAI, Gemini 사용 시) AI 에게 직접 깔끔한 주문서 (JSON) 를 작성하게 하세요. 비용이 좀 더 들더라도 실수를 막을 수 있습니다.

2. 속도와 비용을 아끼려면, "호환성"을 먼저 확인하세요.

   • (Llama 등 오픈소스 모델 사용 시) AI 가 짧은 메모만 적게 하려면, 그 모델이 그 방식으로도 실수 없이 작동하는지 반드시 테스트해야 합니다. 무작정 적용하면 시스템이 망가집니다.

3. 실시간 출력 (스트리밍) 에 집착하지 마세요.

   • 시스템이 다음 작업을 시작하려면 완전한 주문서가 필요합니다. 글자가 하나씩 나타나는 것을 보여준다고 해서 시스템이 빨라지지 않습니다.

📝 한 줄 요약

"인공지능을 시스템의 지시자로 쓸 때는, '어떤 AI 가 가장 똑똑한가'보다 '어떤 AI 에게 어떤 방식으로 지시서를 전달하는가'가 훨씬 중요합니다. AI 모델마다 최적의 지시 방식이 다르니, 무작정 따라 하지 말고 실험을 통해 맞는 조합을 찾아야 합니다."

이 논문은 단순히 AI 성능을 비교한 것이 아니라, 실제 비즈니스 현장에서 AI 를 어떻게 안정적으로 운영할지에 대한 구체적인 설계 도구를 제공한 것입니다.

기술 요약

1. 연구 배경 및 문제 정의 (Problem)

대규모 언어 모델 (LLM) 이 에이전트 기반 AI 시스템의 핵심 제어 구성 요소로 사용됨에 따라, 단순한 텍스트 생성이 아닌 **구조화된 라우팅 (Structured Routing)**의 신뢰성이 중요해졌습니다.

• 기존 접근법의 한계: 구조화된 라우팅을 주로 프롬프트 엔지니어링 문제로 간주하거나, 모델 자체의 성능 비교에 집중하는 경향이 있습니다.
• 핵심 문제: 실제 배포 환경에서 라우팅의 정확성 (Correctness), 지연 시간 (Latency), 구현 비용 (Cost) 사이의 균형은 모델의 정체성뿐만 아니라 **생성 스택 전반에 걸쳐 구조적 작업이 어떻게 분배되는지 (Runtime Burden Allocation)**에 의해 결정됩니다.
  • 예: 모델이 최종 구조화된 데이터를 직접 생성하는지, 압축된 중간 코드를 생성 후 로컬에서 재구성하는지, 스트리밍을 사용하는지 등에 따라 성능이 크게 달라집니다.
• 연구 목표: 구조화된 라우팅을 '모델 성능' 문제가 아닌 '런타임 부하 분배 (Runtime Burden Allocation)' 시스템 설계 문제로 재정의하고, 이의 최적화가 백엔드 (Backend) 에 따라 어떻게 달라지는지 규명하는 것입니다.

2. 방법론 (Methodology)

이 연구는 새로운 알고리즘을 제안하는 것이 아니라, **전체 요인 실험 (Full-Factorial Benchmark)**을 통해 시스템 설계 원리를 검증하는 방법론적 프레임워크를 제시합니다.

2.1 런타임 부하 분배 프레임워크

구조적 작업을 모델과 주변 소프트웨어 간에 어떻게 분배하는지를 정의하는 세 가지 차원을 제시합니다.

1. 직렬화 부하 (Serialization Burden): 모델이 최종 기계 판독 가능 구조 (JSON 등) 를 직접 생성해야 하는지, 아니면 간략한 중간 코드를 생성하고 로컬 소프트웨어가 이를 재구성하는지.
2. 전송 의미론 (Transport Semantics): 스트리밍 (Streaming) 또는 비스트리밍 방식 사용 여부.
3. 구조 실현 위치 (Locus of Structure Realization): 최종 아티팩트가 모델에 의해 직접 생성되는지, 아니면 로컬 결정론적 소프트웨어에 의해 재구성되는지.

2.2 실험 설계 (Full-Factorial Benchmark)

• 범위: 3 개의 백엔드 (OpenAI, Gemini, Llama) × 4 가지 런타임 모드 × 2 가지 제약 조건 × 2 가지 전송 설정 = 48 가지 배포 조합.
• 데이터: 총 15,552 개의 요청 (각 조합당 324 개).
• 런타임 모드:
  • MJ (Minimal JSON): 모델이 직접 JSON 생성 (저예산).
  • SJ (Standard JSON): 모델이 직접 JSON 생성 (고예산).
  • MJS (JSON + Stream): 모델이 직접 JSON 생성 + 스트리밍.
  • MCLR (Compressed Local Reconstruction): 모델이 압축된 텍스트 생성 후 로컬에서 JSON 재구성.
• 평가 지표: 형식 준수 (FC), 라우팅 정확도 (RA), 상태 유지 (SR), 지연 시간 (LAT), 토큰 소비 (TOK). 또한, 워크플로우 하한 완료율 (WLC) 을 파생 지표로 사용하여 실제 운영 가치를 추정했습니다.

3. 주요 기여 (Key Contributions)

1. 시스템 설계 관점의 전환: 구조화된 라우팅을 프롬프트 튜닝이 아닌 '부하 분배' 시스템 문제로 재정의했습니다.
2. 백엔드 - 모드 호환성 원칙 (Compatibility Principle): "어떤 런타임 패키지가 절대적으로 최선이다"라는 보편적 결론은 존재하지 않으며, **백엔드와 런타임 모드 간의 상호작용 (Interaction)**이 성능을 결정하는 1 차 요인임을 입증했습니다.
3. 배포 가능한 방법론: 이질적인 백엔드 환경 하에서 구조화된 라우팅의 정확성 - 비용 - 지연 시간 프론티어를 분석할 수 있는 평가 방법론과 실용적인 배포 가이드라인을 제공합니다.

4. 실험 결과 (Key Results)

4.1 백엔드 × 모드 상호작용의 지배적 영향

• 통계적 유의성: 라우팅 정확도 (RA), 상태 유지 (SR), 형식 준수 (FC) 에서 **백엔드와 런타임 모드의 상호작용 항 (Interaction Term)**이 매우 큰 효과 크기 (Partial Eta Squared ≈ 0.96) 를 보였습니다. 이는 모델 선택보다 런타임 패키징 방식이 백엔드에 따라 다르게 작용함을 의미합니다.
• 성능 패턴:
  • Gemini & OpenAI: 모델이 직접 JSON 을 생성하는 MJ/SJ 모드가 가장 높은 정확도 (RA 85% 이상) 를 보였습니다. 압축 모드 (MCLR) 는 효율성은 높았으나 정확도가 20~27%p 하락했습니다.
  • Llama: MCLR 모드에서 정확도가 붕괴되었습니다. (RA 22.84%, FC 53.40%). Llama 는 압축된 중간 코드를 신뢰할 수 없게 처리하여 구조적 오류가 발생했습니다. 반면, 직접 JSON 생성 모드 (MJ/SJ) 는 Llama 에서도 82% 이상의 정확도를 유지했습니다.

4.2 효율성과 정확성의 트레이드오프

• MCLR (압축/재구성) 의 효율성: 모든 백엔드에서 토큰 소비와 지연 시간을 크게 줄였습니다 (예: Llama 에서 p50 지연 시간 174ms).
• 대신 비용: 효율성 향상은 백엔드별 정확도 하락과 직결되었습니다. 특히 Llama 의 경우, 효율성을 위해 정확성을 희생하면 시스템이 작동하지 않을 수준 (WLC 0%) 에 도달했습니다.

4.3 스트리밍과 제약 조건의 영향

• 스트리밍 (Streaming): 제어 태스크에서는 전체 응답이 완료되어야 하므로, 스트리밍은 정확도나 전체 지연 시간에 미미한 영향만 미쳤습니다. (전송 방식은 2 차적 요인).
• 제약 조건 (Budget): 토큰 예산을 늘리는 것만으로는 MCLR 의 정확도 붕괴를 해결하지 못했습니다. 이는 문제의 핵심이 '예산'이 아니라 '압축된 표현과 백엔드의 의미론적 호환성'에 있음을 시사합니다.

4.4 라우트별 취약성 (Route-level Fragility)

• 전체 평균 정확도는 괜찮아 보여도, 특정 전문 라우트 (예: 개발자 도구 호출) 에서는 압축 모드 사용 시 정확도가 0% 로 떨어지는 등 선택적 취약성이 발견되었습니다. 이는 집계된 지표가 실제 운영 위험을 숨길 수 있음을 경고합니다.

5. 의의 및 시사점 (Significance & Implications)

5.1 이론적 의의

• 호환성 이론: "단순한 출력"이 모델에게 항상 쉬운 것은 아니며, 압축된 코드가 특정 백엔드의 의미론적 안정성을 해칠 수 있음을 이론화했습니다.
• 실험적 검증: 추상적인 모델 비교를 넘어, 구체적인 시스템 설계 변수 (부하 분배) 가 성능에 미치는 인과적 영향을 통계적으로 입증했습니다.

5.2 실무적 배포 가이드라인

1. 정확성이 중요한 경우: Gemini 나 OpenAI 와 같이 구조 생성에 강한 백엔드라면, **직접 JSON 생성 (MJ/SJ)**을 기본으로 사용해야 합니다.
2. 효율성이 중요하고 호환성이 검증된 경우: 백엔드별 검증 없이 무조건 압축 모드 (MCLR) 를 적용하지 말고, 해당 백엔드에서 의미론적 안정성이 확인된 경우에만 효율성 향상을 위해 사용해야 합니다.
3. 스트리밍의 한계: 제어 기록이 완료될 때까지 하위 시스템이 실행되지 않는 한, 스트리밍은 제어 태스크에서 큰 가치가 없습니다.
4. 백엔드별 맞춤형 설계: "하나의 모델이 모든 상황에 최선"이라는 가정을 버리고, 백엔드 - 모드 호환성을 기반으로 한 프론티어 최적화를 수행해야 합니다.

결론

이 논문은 에이전트 기반 전문가 시스템에서 구조화된 라우팅이 단순한 모델 성능 문제가 아니라, 모델과 소프트웨어 간의 부하 분배 전략임을 명확히 했습니다. 특히, 백엔드와 런타임 모드 간의 상호작용이 성능을 결정하는 핵심 요소이며, 효율성 향상을 위한 부하 이전 (Offloading) 은 백엔드 특성에 따라 정확성 붕괴를 초래할 수 있음을 실증적으로 증명했습니다. 이는 실제 시스템 아키텍처 설계 시 모델 선택만큼이나 런타임 패키징 전략을 신중하게 고려해야 함을 시사합니다.