💻 computer science

AiFlow: Token-Native Reactive Orchestration with Bounded Backpressure for Streaming LLM Applications

이 논문은 LLM 제공업체 간의 차이를 유향 스트리밍 그래프 내의 타입화된 이벤트로 정규화하고, 제한된 백프레셔와 로컬 동시성을 강제하기 위해 노드 가디언(Node Guardian)을 활용함으로써, 기존의 집계 기반 방식에 비해 애플리케이션의 첫 부분 토큰 생성 시간(time-to-first-partial-token)과 큐 깊이를 크게 줄이는 토큰 네이티브 반응형 오케스트레이션 프레임워크인 AiFlow를 소개한다.

원저자: Qunhui Zhang

게시일 2026-08-04

📖 5 분 읽기🧠 심층 분석

CC BY 4.0

원저자: Qunhui Zhang

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

당신이 복잡한 요리를 단어 하나하나씩 만들어내는 마법의 셰프(대규모 언어 모델)가 있는 바쁘고 첨단 기술을 갖춘 주방을 운영하고 있다고 상상해 보십시오. 옛날에는 주방 직원들이 요리 전체가 완성될 때까지 기다렸다가 접시에 담거나, 맛을 보거나, 알레르기 성분을 확인했습니다. 이 방식은 고객이 첫 입을 떼기까지 너무 오래 기다리게 만들었습니다. 하지만 이제는 셰프가 요리를 하는 즉시, 한 단어씩 음식을 내놓습니다. 문제는 주방 직원들(앱의 다른 부분들)이 이 빠른 속도를 따라갈 준비가 되어 있지 않다는 것입니다. 어떤 직원들은 매우 빠르지만, 매운 재료를 확인하거나 음식을 목소리로 바꾸는 것과 같은 업무를 수행하는 직원들은 훨씬 느립니다. 만약 빠른 직원들이 느린 직원들이 처리하는 속도보다 더 빠르게 접시를 카운터에 쌓아 올린다면, 카운터는 넘쳐나고 주방은 혼란에 빠지며 시스템 전체가 다운될 것입니다. 이것이 바로 "스트리밍(streaming)" AI 애플리케이션의 세계이며, 여기서의 목표는 정보가 도착하는 즉시 처리하되, 주방이 폭발하지 않도록 흐름을 조직적으로 유지하는 것입니다.

여기에, 이 마법의 셰프들을 위한 궁극적인 주방 매니저로 설계된 새로운 시스템인 AiFlow가 등장했습니다. AiFlow는 정리되지 않은 임시방편의 규칙으로 직원들이 혼란을 해결하게 두는 대신, 처음부터 엄격하고 스마트한 컨베이어 벨트 시스템을 구축합니다. 이 시스템은 셰프가 내뱉는 모든 단어(또는 "토큰")를 지정된 경로를 따라 이동하는 특별하고 라벨이 붙은 패키지로 취급합니다. 논문에서는 벨트의 각 스테이션마다 "노드 가디언(Node Guardian)"을 배치했습니다. 이는 대기 줄에 얼마나 많은 패키지가 머물 수 있는지, 한 번에 얼마나 많은 작업자가 이를 처리할 수 있는지, 그리고 줄이 너무 길어질 경우 어떻게 할 것인지(예: 가장 오래된 항목을 버리거나 셰프를 잠시 멈추는 것)를 결정하는 작고 매우 엄격한 문지기입니다. 연구진은 이 시스템을 사용함으로써 첫 번째 처리된 단어가 고객에게 도달하는 시간이 기존의 "끝날 때까지 기다리는" 방식에 비해 약 71%에서 95%까지 극적으로 감소한다는 것을 발견했습니다. 하지만 그들은 AiFlow가 셰프를 더 빨리 요리하게 만드는 것이 아니라, 단지 주방을 매우 원활하게 운영하여 음식이 테이블에 훨씬 더 빨리 도착하게 만드는 것임을 분명히 하고 있습니다.

문제점: 주방의 혼란

당신이 당신에게 말을 거는 로봇 비서를 만들고 있다고 상상해 보십시오. 당신이 질문을 하면, 로봇은 단순히 최종 답변을 주는 것이 아니라 단어를 하나씩 생성하며 자신의 생각을 밖으로 내뱉습니다. 현대적인 앱에서는 이러한 단어들이 나타나는 동안 다음과 같은 여러 가지 일을 하고 싶을 수 있습니다:

분류하기: 이것이 로봇의 추론 과정인가, 아니면 최종 답변인가?
필터링하기: 이 단어에 위험한 내용이 포함되어 있는가?
스피커로 보내기: 텍스트를 즉시 음성으로 변환한다.
로그 남기기: 나중에 확인하기 위해 추론 과정을 저장한다.

과거에는 개발자들이 이러한 단계들을 연결하기 위해 지저도하고 맞춤화된 코드를 직접 작성해야 했습니다. 그들은 각 단계 사이에 "대기 줄(큐, queues)"을 수동으로 만들어야 했고, 각 단계에 몇 명의 작업자를 고용할지 결정해야 했으며, 스피커가 너무 느려 따라오지 못할 경우 어떻게 할지도 고민해야 했습니다. 만약 실수를 한다면, 대기 줄은 무한히 늘어나 컴퓨터의 메모리를 모두 잡아먹거나 단어들의 순서가 뒤섞일 수 있었습니다. 그것은 마치 중앙 계획 없이 서로에게 소리만 지르는 혼란스러운 주방을 관리하려는 것과 같았습니다.

해결책: AiFlow와 "노드 가디언"

이 논문의 저자는 혼돈을 잘 조직된 조립 라인으로 바꾸는 시스템인 AiFlow를 만들었습니다. AiFlow를 모든 기계가 특정 규칙 책을 가지고 있는 공장의 청사진이라고 생각하십시오.

1. 토큰 네이티브 오케스트레이션 (Token-Native Orchestration):
문장이 끝날 때까지 기다리는 대신, AiFlow는 모든 단어를 "일등 시민"으로 취급합니다. 셰프가 단어를 생성하자마자, 그 단어에는 라벨(예: "추론" 또는 "답변")이 붙고 즉시 올바른 경로로 보내집니다. 이는 셰프가 50번째 단어를 생성하고 있는 동안에도 "답변" 브랜치가 첫 번째 단어에 대해 작업을 시작할 수 있음을 의미합니다.

2. 노드 가디언 (The Node Guardian):
이것이 핵심입니다. 조립 라인의 모든 스테이션에는 "노드 가디언"이 있습니다. 이 가디언은 설계자가 선언한 규칙을 집행하는 엄격한 관리자입니다:

큐 경계 (Queue Bounds): "여기에는 8개의 아이템만 대기할 수 있다." 만약 줄이 가득 차면, 가디언은 상류의 기계가 더 이상 보내지 못하도록 차단합니다. 이를 **백프레셔(backpressure)**라고 합니다. 이는 메모리 과부하로 인한 시스템 충돌을 방지합니다.
작업자 수 (Worker Count): "이 스테이션에는 3명의 작업자가 있다."
오버플로우 정책 (Overflow Policy): "줄이 가득 차면 가장 오래된 항목을 버린다" 또는 "멈춰서 기다린다."
순서 (Ordering): "단어들이 만들어진 정확한 순서대로 나오도록 보장한다."

논문은 이러한 규칙을 설정하면 시스템이 사용하는 메모리 양이 절대 폭발하지 않는다는 것을 수학적으로 증명합니다. 메모리는 안전하고 예측 가능한 범위 내에 머뭅니다.

결과: 연구 결과

연구진은 시뮬레이션 테스트와 DeepSeek 모델의 실제 데이터를 혼합하여 AiFlow를 테스트했습니다. 그들은 AiFlow를 다음 세 가지 방식과 비교했습니다:

Aggregate (집계): 아무것도 하기 전에 전체 답변이 나올 때까지 기다리는 방식 (기존의 느린 방식).
Stream Callback (스트림 콜백): 규칙 없이 단어가 들어오는 대로 처리하는 방식 (정리되지 않은 방식).
LangGraph: 스트리밍을 처리하지만 개발자가 수동으로 큐를 관리해야 하는 인기 있는 기존 도구.

수치는 다음과 같이 나타났습니다:

속도: AiFlow는 모델의 단어 생성 속도 자체를 빠르게 만들지는 않았습니다 (테스트에서 "모델 TTFT"는 약 101ms로 동일하게 유지됨). 그러나 AiFlow는 애플리케이션이 첫 번째 처리된 결과를 전달하는 속도를 훨씬 빠르게 만들었습니다. "Aggregate" 방식과 비교했을 때, AiFlow는 첫 번째 처리된 토큰을 얻는 시간을 70.9%에서 94.7%까지 단축했습니다. 예를 들어, 한 테스트에서 시간은 10초 이상에서 단 210밀리초로 줄어들었습니다.
메모리 안전성: 이것이 큰 승리입니다. "느린" 부분(예: 텍스트를 음성으로 변환하는 작업)이 따라오지 못할 때, "백프레셔가 없는(No Backpressure)" 시스템들은 대기 줄이 231개 이상으로 늘어나 충돌 위험을 초래했습니다. 반면, 노드 가디언을 가진 AiFlow는 줄을 엄격하게 8개로 유지하여 메모리 오버플로우를 방지했습니다.
신뢰성: 인터넷 속도가 불규칙하고 Ollama와 같은 다양한 모델을 사용하는 실제 환경에서도 테스트했을 때, AiFlow는 낮은 메모리 사용량과 높은 속도를 유지했습니다.

이것이 당신에게 의미하는 것

이 논문은 더 빠른 컴퓨터 칩이나 더 똑똑한 AI 두뇌를 발명했다고 주장하는 것이 아닙니다. 대신, "교통 체증" 문제를 해결했습니다. 프로그램이 실행되기 전에 데이터가 어떻게 흐를지에 대한 규칙을 선언(간단한 언어나 JSON 파일 사용)함으로써, 개발자들이 더 빠르고 안전하며 수정하기 쉬운 AI 앱을 구축할 수 있음을 보여주었습니다.

만약 당신이 개발자라면, 더 이상 큐와 작업자를 관리하기 위해 복잡한 코드를 작성할 필요가 없습니다. 그저 규칙을 선언하기만 하면 "노드 가디언"이 나머지를 처리합니다. 만약 당신이 사용자라면, 당신의 AI 챗봇이 대화를 나누는 동안 자신의 단어를 필터링하고 목소리로 내뱉는 과정이 거의 즉각적으로 이루어지며, 대화가 길어져도 앱이 멈추거나 메모리가 부족해지는 일 없이 사용할 수 있음을 의미합니다. 이 시스템은 AI가 말이 많고 사용자가 읽는 속도가 느리더라도 주방이 깨끗하게 유지되고 음식이 계속 제공되도록 견고하게 설계되었습니다.

기술 요약: AiFlow - 스트리밍 LLM 애플리케이션을 위한 토큰 네이티브 반응형 오케스트레이션

1. 문제 정의

대규모 언어 모델(LLM) 애플리케이션은 검색(retrieval), 도구 호출(tool calls), 안전 필터, 다중 에이전트 조율을 통합하는 스트리밍 워크플로로 빠르게 변화하고 있습니다. 현대적인 프레임워크(예: LangChain, LangGraph)는 프로바이더의 델타(토큰 단위 출력)를 노출하지만, 생성 과정을 애플리케이션 그래프 내의 거친 요청-응답 단계로 취급하는 경우가 많습니다. 결과적으로 큐 관리, 워커 할당, 토큰 순서 지정, 백프레셔(backpressure)와 같은 핵심 운영 사항들이 개발자가 구현하는 임시적인 콜백 코드로 전락하게 됩니다.

이러한 "콜백 로컬(callback-local)" 접근 방식은 다음과 같은 문제를 야기합니다:

무제한 메모리: 다운스트림 소비자가 느릴 때 시스템이 무제한 버퍼를 암묵적으로 축적할 수 있습니다.
운영적 불투명성: 큐 깊이, 워커 동시성, 오버플로 정책이 숨겨져 있어 검증과 튜닝이 어렵습니다.
취약성: 수동 와이어링(manual wiring)의 버그는 토큰 순서 재배치, 중단 이벤트 누락 또는 메모리 고갈을 초래할 수 있습니다.
지연 시간 불일치: 집계(aggregation) 전략은 전체 모델 응답이 생성될 때까지 모든 다운스트림 처리를 지연시켜, 애플리케이션의 첫 번째 처리 토큰 도달 시간(TTFPT)을 증가시킵니다.

핵심 문제는 완전한 중간 결과물을 실체화하지 않으면서도 토큰 수준의 이벤트를 지속적으로 소비하는 방법이며, 동시에 노드 로컬 리소스가 유계(bounded) 상태를 유지하고, 출력 순서 제어가 가능하며, 백프레셔가 관찰 및 전파될 수 있도록 보장하는 것입니다.

2. 방법론: AiFlow 모델

AiFlow는 토큰 네이티브 반응형 오케스트레이션 모델을 도입하여, 프로바이더 델타를 방향성 스트리밍 그래프를 통해 전파되는 타입화된 Context<T> 이벤트로 정규화합니다.

2.1. 그래프 모델 및 DSL

시스템은 LLM 애플리케이션을 연산자(operator)가 노드이고 타입화된 이벤트를 엣지가 운반하는 유향 그래프 $G = (N, E, \pi, \tau)$ 로 모델링합니다.

타입화된 이벤트: 이벤트에는 토큰, 청크, 도구 파편, 검색 결과, 안전 라벨, 제어 신호가 포함되며, 각 이벤트는 메타데이터(타임스탬프, 대화 ID, 시퀀스 번호)를 보유합니다.
선언적 정책: 각 노드에는 다음을 정의하는 정책 튜플 $P = (q, k, \rho, \sigma, o, c, r)$ $P = (q, k, ρ, σ, o, c, r)$ 이 할당됩니다:
- $q$ : 큐 용량 (유계).
- $k$ : 워커 동시성.
- $\rho$ : 순서 버퍼 제한.
- $\sigma$ : 상태 안전 모드 (무상태, 파티션화, 직렬화, 트랜잭션).
- $o$ : 오버플로 동작 (차단, 최신 드롭, 오래된 것 드롭, 에러).
- $c, r$ : 취소 전파 및 재시도 정책.
컴파일: AiFlow는 유연한 DSL과 JSON 그래프 형식을 제공합니다. 컴파일러는 런타임 인스턴스화 전에 타입 안전성, 상태 동시성, 사이클 적법성 및 인젝션 호환성을 위해 정적 검증을 수행합니다.

2.2. 노드 가디언 런타임 (Node Guardian Runtime)

런타임 실행은 각 그래프 노드에 대한 **노드 가디언(Node Guardian)**에 의해 관리됩니다. 가디언은 다음을 수행합니다:

입력 큐, 워커 예산 및 순서 버퍼를 소유합니다.
선언된 정책을 강제합니다 (예: 큐가 가득 찼을 때 업스트림 차단, 오래된 토큰 삭제 또는 에러 전파).
도구 호출이나 TTS와 같은 작업을 위한 사이드 이펙트 모드(멱등, 비멱등, 투기적)를 관리합니다.
로컬 버퍼가 용량에 도달하면 업스트림으로 백프레셔 신호를 전파합니다.

2.3. 형식적 보장

본 논문은 유한한 도착률과 고정된 정책 하에서, 런타임이 소유하는 인플라이트(in-flight) 이벤트의 수는 선언된 큐 용량, 워커 수 및 버퍼 제한의 합에 의해 엄격히 제한된다는 **유계 메모리 명제(Bounded-Memory Proposition)**를 제시합니다. 이는 프로바이더 측 버퍼를 제외하고 애플리케이션 계층의 리소스 안전성에 집중합니다.

3. 주요 기여

토큰 네이티브 오케스트레이션: LLM 델타를 타입화된 그래프 이벤트로 취급하여, 전체 응답이 생성되기 전에 의미론적 라우팅(예: 토큰을 "추론"과 "답변"으로 분류)을 가능하게 하는 모델입니다.
선언적 리소스 제어: 개발자가 그래프 수준에서 큐 경계, 워커 수, 오버플로 정책을 지정할 수 있게 하며, 이를 런타임이 강제하는 DSL 및 JSON 형식을 제공합니다.
정적 검증: 타입 안전성, 상태 동시성 및 인젝션 호환성을 검증하여 일반적인 런타임 오류를 방지하는 컴파일 프로세스를 제공합니다.
형식적 유계 메모리 속성: 선언된 정책에 따라 런타임 소유 버퍼가 무제한으로 성장할 수 없음을 보장하는 수학적 명제를 제공합니다.
다단계 경험적 평가: 제어된 벤치마크, 캡처된 트레이스 재생, 라이브 프레임워크 비교를 사용하여 모델 TTFT(프로바이더의 첫 델라 도달 시간)와 애플리케이션 TTFPT(처리된 첫 토큰 도달 시간)를 분리하여 종합적으로 평가합니다.

4. 실험 결과

평가는 제어된 마이크로 벤치마크, 30회 실행의 DeepSeek 트레이스 재생, 라이브 Ollama 실행 및 LangGraph 베이스라인을 활용하였습니다.

애플리케이션 TTFPT 감소: AiFlow는 집계 베이스라인에 비해 애플리케이션 TTFPT를 크게 단축했습니다.
- 의미론적 라우팅: 집계 방식 대비 TTFPT를 79.0%(DeepSeek) 및 94.7%(Ollama) 감소시켰습니다.
- 스트리밍 RAG: 집계 방식 대비 TTFPT를 70.9%(DeepSeek) 감소시켰습니다.
- 참고: AiFlow는 모델 TTFT를 변경하지 않습니다. 개선은 전체 스트림을 기다리는 대신 토큰 도착 즉시 다운스트림 처리(분류, 라우팅, TTS)를 시작함으로써 발생합니다.
유계 백프레셔:
- AiFlow는 런타임 소유 큐 깊이를 선언된 범위(예: $q=8$ ) 내로 유지합니다.
- 무제한 정책과 비교했을 때, AiFlow는 워크로드 전반에 걸쳐 최대 큐 깊이(MaxQ)를 93.7% ~ 96.5% 감소시켰습니다.
- 트레이스 재생 시, 무제한 정책은 큐가 231개 이상의 이벤트로 성장하도록 방치했으나, AiFlow는 이를 8개로 제한했습니다.
지연 시간 vs. 안전성: "백프레셔 없음" 정책은 AiFlow와 유사한 첫 토큰 지연 시간을 제공했지만, 느린 소비자 환경에서 메모리 고갈을 방지하지 못했습니다. AiFlow는 낮은 지연 시간을 유지하면서도 메모리 안전성을 보장합니다.
통계적 유의성: 쌍체 윌콕슨 부호 순위 검정(Paired Wilcoxon signed-rank test)을 통해 TTFPT의 유의미한 감소( $p < 0.001$ )와 매우 큰 효과 크기(Cohen's $d$ 최대 8.12)를 확인하였으며, 이는 집계에서 스트리밍으로의 질적 전환에 기인합니다.

5. 의의 및 주장

본 논문은 AiFlow가 트랜스포머 서빙이나 GPU 스케줄링의 최적화가 아니라, 애플리케이션 계층의 오케스트레이션 모델임을 겸허히 주장합니다. 그 의의는 다음과 같습니다:

명령형에서 선언형으로의 전환: 큐 관리, 워커 할당, 백프레셔를 명령형 콜백 코드에서 선언적 그래프 속성으로 이동시켰습니다.
운영적 관측 가능성: 리소스 정책(큐 경계, 워커 수)과 안전성 보장(유계 메모리)을 워크플로 그래프의 명시적이고 관찰 가능한 속성으로 만들었습니다.
관심사의 분리: 프로바이더 측 지연 시간(Model TTFT)과 애플리케이션 계층의 효율성(Application TTFPT)을 구분하여, 개발자가 후자를 최적화할 수 있도록 합니다.
재사용성 및 안전성: 동일한 스트리밍 동작을 수동으로 작성할 수 있지만, AiFlow는 이러한 동작을 재사용 가능하고, 검증 가능하며, 관찰 가능한 형태로 만들어 침묵하는 메모리 누수 및 토큰 재배치 위험을 줄여줍니다.

저자는 숙련된 비동기 코드를 직접 작성하면 동등한 성능을 낼 수 있지만, AiFlow는 이러한 정책을 체계적으로 검증, 비교 및 튜닝할 수 있는 엔지니어링 규율을 제공한다고 강조합니다.