Multi-Stream LLMs: 프롬프트, 사고, 입출력을 병렬 스트림으로 분리하는 새 논문

TL;DR Highlight

현재 LLM이 입력·사고·출력을 순차적으로만 처리하는 구조적 한계를 지적하고, 각 역할을 별도의 병렬 스트림으로 분리해 동시에 처리할 수 있는 Multi-Stream 방식을 제안한 논문이다. 에이전트의 효율성·보안·모니터링 가능성을 모두 개선할 수 있다는 점에서 주목받고 있다.

Who Should Read

LLM 기반 에이전트나 도구 호출(tool calling) 시스템을 개발하고 있는 백엔드·AI 엔지니어, 또는 추론 속도와 에이전트 아키텍처 개선에 관심 있는 ML 연구자.

Core Mechanics

현재의 모든 LLM 에이전트는 ChatGPT 시절부터 이어진 단일 메시지 스트림 구조에 묶여 있다. 사용자, 시스템, 도구, 모델 자신(chain-of-thought)이 전부 하나의 순차적 흐름 안에서 처리된다.
이 단일 스트림 구조 때문에 '읽는 동안은 출력 불가', '쓰는 동안은 새 입력에 반응 불가', '생각하는 동안은 행동 불가' 같은 근본적인 병목이 생긴다. 사람으로 비유하면 멀티태스킹이 아예 불가능한 뇌와 같다.
이 논문은 각 역할(사용자 입력, 시스템 프롬프트, chain-of-thought, 출력 등)을 별도의 병렬 스트림으로 나누는 Multi-Stream 방식을 제안한다. 모델의 각 forward pass에서 여러 입력 스트림을 동시에 읽고, 여러 출력 스트림에 동시에 토큰을 생성한다.
학습 방식도 바꿔야 한다. 기존 sequential instruction-tuning 데이터 포맷 대신, multi-stream 포맷으로 instruction-tuning을 다시 해야 이 기능이 작동한다. 즉 아키텍처보다는 데이터·학습 방식의 변화가 핵심이다.
데이터 준비 과정에서 80B 규모의 모델을 사용해 기존 sequential instruction 데이터를 multi-stream 포맷으로 변환했다. 다만 논문 자체는 비교적 소규모 모델로 실험했고, 현대 대규모 instruction 데이터나 RLHF 같은 다단계 후처리에는 아직 미치지 못한다고 저자 스스로 인정한다.
보안 측면에서도 이점이 있다. 스트림이 분리되면 '관심사 분리(separation of concerns)'가 가능해져 시스템 프롬프트와 사용자 입력, 도구 출력을 서로 완전히 격리할 수 있다. 프롬프트 인젝션 같은 공격을 구조적으로 차단할 수 있다.
모니터링 가능성도 개선된다. 생각(thinking) 스트림, 행동(action) 스트림, 출력 스트림이 별도로 존재하므로, 모델이 무엇을 생각하고 무엇을 출력하는지 스트림별로 독립적으로 추적하거나 평가할 수 있다.
논문은 Max Planck Institute for Intelligent Systems에서 나왔으며, 코드도 공개되어 있다. 저자들은 현재 결과가 소규모 실험에 불과하고 대규모로 검증하는 것이 미래 과제라고 밝힌다.

Evidence

'병렬 스트림 내에서 모순된 토큰이 생성되면 어떻게 되냐'는 질문이 나왔다. 예를 들어 Contemplating Stream에서는 'y op z = 3', Thinking Stream에서는 'y op z = 5'가 동시에 나올 수 있는데, 이 경우를 어떻게 처리하는지 논문에서 충분히 다루지 않는다는 지적이었다.
병렬 도구 호출(parallel tool calling)에 회의적인 실사용 경험도 공유됐다. 커스텀 GPT 4.5 harness에서 parallel tool calls를 비활성화했더니 결과 품질이 극적으로 향상됐다는 경험담이 있었다. 속도는 느려지지만 정확도가 훨씬 높아졌다는 것으로, 병렬화가 항상 좋은 건 아니라는 반론이다.
데이터 준비 방식에 대한 우려가 있었다. 80B 모델로 sequential 포맷을 multi-stream 포맷으로 변환하는 과정에서 정보가 '누출(leak)'되거나 결과가 오염될 수 있다는 지적이다. 이를 검증하려면 RL(강화학습) 기반의 추가 실험이 필요했는데 논문에 없다는 아쉬움도 표현됐다.
멀티 스트림을 기존 소프트웨어 엔지니어링의 비동기 스트림 패턴과 동일선상에서 보는 시각도 있었다. 도구 호출은 원래 비동기로 처리할 수 있고, 서브에이전트 태스크 분해도 같은 방식으로 모델링 가능하다는 의견이다. LLM 레벨이 아닌 시스템 레벨에서 이미 해결할 수 있는 문제 아니냐는 뉘앙스였다.
스트림 분리로 인해 컨텍스트 윈도우가 사실상 줄어드는 거 아니냐는 질문도 나왔다. 전체 컨텍스트가 여러 스트림으로 나뉘면 각 스트림이 볼 수 있는 컨텍스트가 짧아진다는 우려인데, 논문에서 이 부분을 어떻게 처리하는지 명확하지 않다는 지적이었다.

How to Apply

에이전트 시스템에서 tool calling을 구현 중이라면, 당장 모델 아키텍처를 바꾸기 전에 시스템 레벨에서 비동기 병렬 처리를 먼저 도입해볼 수 있다. 도구 호출 결과를 priority queue로 관리하고 응답이 오는 순서대로 처리하면 Multi-Stream의 일부 효과를 지금 당장 얻을 수 있다.
프롬프트 인젝션이나 시스템 프롬프트 노출이 걱정되는 서비스라면, 이 논문의 '관심사 분리(separation of concerns)' 개념을 참고해 입력 소스별로 명확히 구분된 컨텍스트 구조를 설계하는 것이 좋다. 완전한 Multi-Stream이 아니더라도 시스템 프롬프트와 사용자 입력의 경계를 더 엄격히 관리하는 방향으로 적용 가능하다.
논문 코드가 공개되어 있으므로, 소규모 모델을 직접 multi-stream 포맷으로 instruction-tuning 해보고 싶은 경우 arXiv 논문 페이지에서 코드 링크를 통해 실험해볼 수 있다. 다만 저자 스스로 소규모 실험임을 인정하고 있어 프로덕션 적용보다는 연구·탐색 목적에 적합하다.
에이전트가 실행 중에 새 정보에 반응하지 못하는 문제를 겪고 있다면, 모델을 주기적으로 중단시키고 현재 목표와 진행 상황을 다시 주입하는 방식이 실용적 대안이 될 수 있다. 한 커뮤니티 개발자가 'is that the best you can do?'처럼 주기적으로 개입했을 때 성능이 크게 올랐다고 공유했는데, Multi-Stream이 상용화되기 전까지 쓸 수 있는 현실적인 우회책이다.

Terminology

instruction-tuning사전학습된 LLM에 '사용자 질문→모델 답변' 형태의 예시 데이터를 추가로 학습시켜 지시를 따르도록 만드는 과정. ChatGPT 같은 채팅 모델이 이 방식으로 만들어진다.

chain-of-thought모델이 최종 답변 전에 중간 추론 과정을 순서대로 텍스트로 작성하게 하는 기법. 사람이 수학 문제 풀 때 풀이 과정을 적는 것과 비슷하다.

forward pass입력 데이터가 신경망의 앞에서 뒤로 한 번 통과하면서 출력을 계산하는 과정. LLM에서는 매 토큰을 생성할 때마다 한 번씩 일어난다.

separation of concerns서로 다른 역할과 책임을 가진 부분들을 독립적으로 분리해 설계하는 소프트웨어 원칙. 코드에서 UI와 비즈니스 로직을 분리하는 것과 같은 개념을 LLM 스트림에 적용한 것이다.

autoregressive이전에 생성한 토큰들을 입력으로 받아 다음 토큰을 하나씩 예측하는 방식. 현재 대부분의 LLM이 이 방식으로 텍스트를 생성한다.

RLHF인간 피드백을 통한 강화학습(Reinforcement Learning from Human Feedback). 사람이 모델 출력에 점수를 매기고 그 점수를 바탕으로 모델을 더 잘 응답하도록 추가 학습시키는 기법이다.