10개의 에이전트를 위해 더 나은 모델이 필요하다고 생각했지만, 사실 정말 필요했던 것은 큐(Queue)였다

만약 당신이 10개 이상의 에이전트 (agents)를 동시에 실행하고 있다면, 병목 현상의 원인은 대개 모델의 품질이 아닙니다.

그것은 공유된 실행 용량 (shared execution capacity) 때문입니다.

조직 수준의 API 제한 (API limits). 브라우저/런타임 경합 (Browser/runtime contention). 대화 2개까지는 괜찮아 보이다가 6~8개부터 이상해지기 시작하는 채팅 스타일의 구독 (Chat-style subscriptions).

해결책은 대개 지루합니다: 큐잉 (queueing), 워커 격리 (worker isolation), 재시도 (retries), 그리고 명시적인 동시성 제어 (explicit concurrency control).

저는 팀들이 매우 특정한 방식으로 설정이 실패하기 시작할 때, _에이전트를 위한 최고의 모델_을 찾는 것을 계속 보게 됩니다:

하나의 에이전트가 작업 중간에 멈춤
하나의 스레드 (thread)는 계속 진행되는 반면 다른 하나는 침묵함
Telegram 토픽이 ?를 보내기 전까지는 죽은 것처럼 보임
그러다 갑자기 아무 일도 없었다는 듯이 깨어나서 계속 진행함

이것은 모델 품질의 문제처럼 보이지 않습니다.

이것은 스케줄링 (scheduling) 문제처럼 보입니다.

이 실패 모드를 완벽하게 설명하는 Reddit 스레드

저는 r/openclaw에서 대부분의 세련된 아키텍처 포스트보다 이 상황을 더 잘 설명하는 스레드를 발견했습니다:

https://reddit.com/r/openclaw/comments/1ufd864/how_to_run_10_agents_at_the_same_time_while/

설정은 매우 구체적이었습니다:

10개의 토픽 스레드 (topic threads)
앱당 하나씩
OpenClaw를 통해 실행
Telegram 슈퍼그룹 내부
16 GB Hetzner VPS 상에서

그리고 증상은 고통스러울 정도로 익숙했습니다:

동시 대화 수가 증가함에 따라, 가끔 에이전트가 일부 토픽에서 완전히 응답을 멈추는 것을 발견했습니다. 제가 다른 메시지(단순히 '?'라도)를 보낼 때까지 계속되지 않다가, 그 후에 갑자기 대화를 다시 이어갑니다.

그 버그는 많은 것을 말해줍니다.

대부분의 사람들은 그것을 보고 모델을 탓합니다:

아마 Claude가 불안정해졌나
아마 GPT-5가 과부하 상태인가
아마 Qwen이 더 나을 수도 있겠다
아마 Llama라면 다르게 행동했을 것이다

제 생각은 이렇습니다: 대부분의 경우, 그 진단은 틀렸습니다.

멈춤 현상이 단서다

이것이 흥미로운 점은, 눈에 보이는 실패가 마치 "모델이 생각을 멈춘 것"처럼 보인다는 것입니다.

하지만 대개 더 깊은 문제는 너무 많은 것들이 하나의 병목 현상 (bottleneck)을 공유하고 있다는 점입니다.

같은 스레드의 한 댓글 작성자는 이렇게 말했습니다:

Claude CLI (즉, max sub)를 사용하고 있다면, 기본적으로 동시에 작동하는 에이전트가 약 6~8개로 제한됩니다. 그 이상이 되면 서로를 멈추게 하거나 다른 작업이 끝나기를 기다리게 됩니다.

저는 6-8이라는 숫자를 어떤 보편적인 법칙으로 취급하지는 않겠습니다.

하지만 그 패턴만큼은 전적으로 믿습니다.

채팅 구독 (Chat subscriptions) 서비스는 인간이 몇 개의 대화를 여는 용도로 만들어졌습니다.

그것들은 실행 시스템 (execution systems)이 아닙니다.

일단 진정한 병렬성 (parallelism)의 단계로 넘어가면, 질문은 다음과 같이 바뀝니다:

에이전트를 위한 최적의 모델은 무엇인가?

가 아니라,

정확히 무엇이 무엇과 용량을 공유하고 있는가?

로 바뀝니다.

바로 이 지점에서 대부분의 에이전트 스택 (agent stacks)이 무너집니다.

실제로 무엇이 공유되고 있는가?

보통 한 가지가 아닙니다. 세 가지입니다.

1. 제공자 측의 속도 제한 (Provider-side rate limits)

OpenAI의 속도 제한 (rate limits)은 채팅창 단위가 아니라 조직 (organization) 및 프로젝트 (project) 수준에서 적용됩니다. 일부 모델 제품군 (model families) 또한 제한을 공유합니다.

이는 사람들이 예상하는 것보다 훨씬 더 중요합니다.

만약 에이전트 A가 GPT-5.4를 몰아치고 있고 에이전트 B가 조용히 로그를 요약하고 있다면, 두 요청이 동일한 조직 수준의 할당량 (bucket)을 사용한다면 여전히 서로 간섭할 수 있습니다.

외부에서 보기에는 무작위처럼 보입니다.

내부적으로는 그저 공유된 할당량 (quota)일 뿐입니다.

간단한 예시:

# 에이전트 1은 무거운 추출 (extraction) 작업을 수행 중
# 에이전트 2는 아주 작은 요약 작업을 수행 중
# 둘 다 여전히 동일한 조직/프로젝트 제한에 걸림

배압 (backpressure) 제어가 없다면, 소란스러운 작업자 하나가 시스템의 나머지 부분을 불안정하게 만들 수 있습니다.

2. 로컬 런타임 경합 (Local runtime contention)

Reddit의 답변들은 또 다른 명백한 주범을 지목했습니다: 바로 기계 그 자체입니다.

만약 공유된 Chromium 상태, 긴 전사 (transcripts), 도구 호출 (tool calls), 그리고 여러 활성 세션이 있는 상태에서 16GB VPS로 OpenClaw를 실행하고 있다면, 멈춤 현상을 겪기 위해 제공자의 서비스 중단 (outage)까지 기다릴 필요도 없습니다.

그저 다음과 같은 것들이 충분하기만 하면 됩니다:

메모리 압박 (memory pressure)
이벤트 루프 경합 (event loop contention)
I/O 대기 (I/O wait)
브라우저 상태 비대화 (browser state bloat)
세션 오버헤드 (session overhead)

한 댓글 작성자가 적절한 질문을 던졌습니다:

모든 주제가 새로운 세션인가요? 제가 발견한 에이전트가 멈추는 유일한 이유는 메모리 오버헤드 (memory overhead)가 한계에 도달했기 때문입니다. 특히 VPS 환경에서요.

이것은 화려한 이유는 아니지만, "모델이 혼란을 느꼈다"는 말보다 아마 진실에 더 가까울 것입니다.

3. 채팅 세션 아키텍처 (Chat-session architecture)

이것은 교묘한 부분입니다.

채팅 구독 (chat subscription)은 수많은 스레드 (threads)를 열 수 있기 때문에 마치 실행 환경 (execution environment)처럼 느껴집니다.

하지만 눈에 보이는 스레드가 다음과 같은 것들과 동일한 것은 아닙:

큐 (queue)
워커 풀 (worker pools)
재시도 정책 (retry policies)
데드 레터 처리 (dead-letter handling)
수락 제어 (admission control)
명시적 동시성 제한 (explicit concurrency caps)

대화가 2개일 때는 그 차이가 거의 중요하지 않습니다.

대화가 12개일 때는 매우 중요해집니다.

n8n이 동일한 벽에 부딪히는 이유

이것은 단지 OpenClaw만의 문제가 아닙니다.

이것은 아키텍처 (architecture) 문제입니다.

n8n은 문서에서 이를 매우 명확하게 밝히고 있습니다: 일반 모드에서 너무 많은 동시 실행 (concurrent executions)을 허용하면, 이벤트 루프 (event loop)를 과부하시켜 인스턴스를 응답 불능 상태로 만들 수 있습니다.

이 문장은 신선할 정도로 매력적이지 않지만, 또한 정확히 맞습니다.

실제로 일어나는 일은 다음과 같습니다:

하나의 워크플로 (workflow)가 바빠짐
또 다른 웹훅 (webhook)이 들어옴
그다음 또 다른 웹훅이 들어옴
CPU와 메모리가 소란스러워짐 (noisy)
이벤트 루프가 두들겨 맞음 (hammered)
갑자기 "AI가 신뢰할 수 없다"라고 결론 내림

아니요.

당신의 스케줄러 (scheduler)가 신뢰할 수 없는 것입니다.

n8n의 해답은 "더 똑똑한 모델로 교체하라"가 아니었습니다.

그것은 동시성 제어 (concurrency control)와 큐 모드 (queue mode)였습니다.

예를 들어:

export N8N_CONCURRENCY_PRODUCTION_LIMIT=20

이 환경 변수 하나가 많은 것을 말해줍니다.

성숙한 워크플로 시스템은 반드시 수락 게이트 (admission gate)가 있어야 한다고 가정합니다.

왜냐하면 모든 것이 즉시 실행될 수 있다면, 결국 아무것도 제대로 실행되지 않기 때문입니다.

아키텍처의 전환: 채팅 스레드 vs 큐에 쌓인 작업

명확한 분기점은 큐 (queue)입니다.

n8n 큐 모드에서는:

메인 인스턴스가 트리거 (triggers)와 웹훅 (webhooks)을 수락합니다.
Redis가 대기 중인 실행 건들을 저장합니다.
워커 인스턴스 (worker instances)가 용량이 확보되었을 때 작업을 가져옵니다 (pull jobs).

이것은 다음과 같은 모델과는 완전히 다릅니다:

나는 10개의 텔레그램 대화를 열어두고 OpenClaw, Chromium, Claude, 그리고 내 VPS가 알아서 해결해주기를 바랐다.

설정(config)을 보면 그 차이가 명확해집니다:

export EXECUTIONS_MODE=queue

그 다음 명시적인 동시성 (concurrency) 설정을 사용하여 워커 (worker)를 실행합니다:

n8n worker --concurrency=10

이것은 지루한 인프라 (infrastructure) 작업입니다.

하지만 바로 그 점 때문에 제대로 작동하는 것입니다.

빠른 비교

접근 방식	부하 발생 시 발생하는 현상
채팅 구독 워크플로우 (Chat subscription workflow)	공유된 대화형 세션 (interactive-session) 제한, 큐잉 (queueing) 및 재시도 (retries)에 대한 약한 제어력, 1~2개의 대화에는 간단하지만 병렬 에이전트 부하가 걸리면 정체되기 시작함
...

그 중간 행이 바로 많은 팀이 "아하" 모먼트를 경험하는 지점입니다.

그들은 자신들이 지능 (intelligence)을 쇼핑하고 있다고 생각합니다.

하지만 실제로는 처리량 규율 (throughput discipline)을 쇼핑하고 있는 것입니다.

짜증 나는 부분: API 아키텍처는 더 나아졌지만, 청구서가 끔찍해질 수 있다

여기서부터 진짜 문제가 시작됩니다.

노트북에서 에이전트 하나를 테스트할 때는 토큰당 가격 책정 (per-token pricing)이 괜찮게 느껴집니다.

하지만 동시성 (concurrency)을 고정하고 워커 (worker)들이 실제로 하루 종일 돌아가기 시작하면 느낌이 완전히 달라집니다.

그것이 바로 함정입니다.

마침내 시스템을 올바르게 구축했는데, 이제 토큰 청구서가 두 번째 장애 (outage)처럼 작동하기 시작합니다.

따라서 결정의 기준은 단순히 다음과 같이 바뀌지 않습니다:

어떤 모델이 가장 똑똑한가?

대신 다음과 같이 변합니다:

무엇이 품질을 보장하는가?
무엇이 안정적인 처리량 (throughput)을 제공하는가?
무엇이 예측 가능한 비용을 제공하는가?

이것이 바로 이 카테고리가 흥미로워지고 있는 이유입니다.

많은 팀이 API 스타일의 제어를 원합니다:

OpenAI 호환 엔드포인트 (endpoints)
실제 큐 (queues) 및 워커 (workers)
재시도 (retries) 및 백프레셔 (backpressure)
기존 SDK 지원

하지만 자동화 (automations)를 추가할 때마다 토큰당 비용 때문에 불안해하고 싶지는 않습니다.

그것이 바로 Standard Compute가 목표로 하는 격차 (gap)입니다.

Standard Compute는 에이전트 및 자동화 워크로드 (workloads)를 위해 OpenAI 호환 API를 제공하지만, 사용량 기반의 토큰 과금 대신 고정된 월간 가격을 제공합니다.

따라서 여러분은 실제로 원하는 아키텍처를 구축할 수 있습니다:

API 기반 실행 (execution)
명시적인 동시성 제어 (concurrency control)
장기 실행 자동화 (long-running automations)
예측 가능한 비용

n8n, Make, Zapier, OpenClaw 또는 커스텀 워커 시스템 (custom worker systems)에서 에이전트를 실행하면서, 불안정한 채팅 구독 (chat subscriptions)과 무시무시한 토큰 비용 (token bills) 사이에서 갈등하는 것에 지쳤다면 이는 매우 중요한 문제입니다.

더 자세한 내용은 여기에서 확인하세요:

https://standardcompute.com

10개 이상의 에이전트를 위해 내가 할 일

진정한 동시성 (concurrency)이 필요하다면, 제가 선택할 설정은 다음과 같습니다.

1. 유입 (intake)과 실행 (execution)을 분리하세요

들어오는 작업이 현재 실행 중인 작업과 즉시 경쟁하게 두지 마세요.

큐 (Queue)를 사용하세요.

예시:

n8n 큐 모드 (queue mode)
BullMQ
Celery
SQS
RabbitMQ

BullMQ를 사용한 예시:

import { Queue, Worker } from 'bullmq';

const queue = new Queue('agents', {
...

핵심은 간단합니다: 유입 (intake)은 저렴해야 하고, 실행 (execution)은 제한되어야 합니다.

2. 동시성에 엄격한 상한선을 두세요

느낌적인 느낌이 아니라, 숫자로 관리하세요.

사용 중인 서버가 안전하게 8개의 워커 (workers)를 실행할 수 있다면, 8로 설정하세요.

제공업체의 할당량 (quota)이 여유 공간을 포함하여 20개의 활성 요청 (active requests)을 지원한다면, 상한선을 20으로 설정하세요.

예시:

export N8N_CONCURRENCY_PRODUCTION_LIMIT=20

n8n worker --concurrency=10

const MAX_PARALLEL_AGENTS = 8;

목표는 "가능한 최대의 병렬성 (maximum possible parallelism)"이 아닙니다.

목표는 안정적인 처리량 (stable throughput)입니다.

3. 무거운 세션 (heavy sessions)을 격리하세요

모든 에이전트가 동일한 차선에 있을 필요는 없습니다.

Chromium에서 40개의 탭을 여는 스크래핑 에이전트 (scraping agent)가 단 몇 번의 API 호출만 필요한 아주 작은 요약 에이전트 (summarizer)와 실행 용량을 공유해서는 안 됩니다.

리소스 프로필 (resource profile)에 따라 워크로드 (workloads)를 분리하세요:

브라우저 집약적 (browser-heavy)
메모리 집약적 (memory-heavy)
긴 컨텍스트 (long-context)
가벼운 텍스트 변환 (lightweight text transforms)

이것만으로도 많은 "무작위" 불안정성 문제를 해결할 수 있습니다.

4. 재시도 (retries)를 일급 기능 (first-class feature)으로 취급하세요

만약 에이전트가 당신이 ?를 보낸 후에야 다시 재개된다면, 당신은 이미 재시도 시스템을 가지고 있는 것입니다.

다만 재시도 연산자가 인간이기 때문에 나쁜 시스템일 뿐입니다.

다음 항목들에 대해 명시적인 처리 로직을 구축하세요:

타임아웃 (timeouts)
재시도 (retries)
멈춰버린 실행 (stuck executions)
데드 레터 큐 (dead-letter queues)
멱등성 (idempotency)

대략적인 의사 패턴 (pseudo-pattern):

async function runWithRetry(task, maxRetries = 3) {
  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    try {

이것은 Telegram 넛지(poke)가 에이전트를 다시 깨우기를 바라는 것보다 무한히 더 낫습니다.

5. 실제 병목 지점 (bottleneck) 측정하기

무엇이 가장 먼저 포화(saturate)되는지 모른다면, 당신은 계속해서 모델을 탓하게 될 것입니다.

최소한 다음 항목들을 추적하세요:

큐 깊이 (queue depth)
워커 활용도 (worker utilization)
제공자 RPM/TPM 에러 (provider RPM/TPM errors)
메모리 사용량 (memory usage)
CPU 부하 (CPU load)
트랜스크립트 길이 (transcript length)
브라우저/세션 수 (browser/session count)
재시도율 (retry rate)
중단된 작업 수 (stuck job count)

워커들이 풀 가동 중인데 큐 깊이가 상승하고 있다면, 그것은 워커 용량 (worker-capacity) 문제입니다.

워커들은 유휴 상태(idle)인데 요청이 실패하고 있다면, 그것은 아마도 제공자 측의 제한 (provider-side limits)일 것입니다.

메모리 급증이 브라우저 집약적인 작업과 상관관계가 있다면, 그것은 로컬 경합 (local contention) 문제입니다.

이러한 것들은 계측 (instrument)만 한다면 진단이 가능합니다.

구독이 여전히 의미가 있을까요?

물론입니다.

한 사람이 한두 개의 장기적인 채팅을 운영하는 경우라면, Claude Max나 ChatGPT는 매우 훌륭할 수 있습니다.

그것은 실질적인 가치입니다.

하지만 임계점 (breakpoint)은 사람들이 생각하는 것보다 더 빨리 찾아옵니다.

일단 다음과 같은 것들이 필요해지면:

병렬성 (parallelism)
재시도 (retries)
격리 (isolation)
예측 가능한 처리량 (predictable throughput)
비용 제어 (cost control)

…당신은 더 이상 채팅을 하고 있는 것이 아닙니다.

당신은 분산 작업 (distributed work)을 하고 있는 것입니다.

설령 UI가 여전히 Telegram, Discord, 또는 브라우저 탭일지라도 말입니다.

그리고 분산 작업은 막연한 낙관론 (wishful thinking)을 응징합니다.

불편한 진실: 더 나쁜 모델이 승리할 수 있다

이 부분은 사람들이 듣기 싫어하는 내용입니다.

안정적인 워커와 깔끔한 큐 뒤에서 실행되는 약간 더 나쁜 모델이, 공유되고 지연되기 쉬운 채팅 설정 안에 갇혀 있는 더 좋은 모델을 종종 이기곤 합니다.

벤치마크 스크린샷 상에서가 아닙니다.

실제 처리량 (actual throughput)에서.

실제 신뢰성 (actual reliability)에서.

실제 무인 자동화 (actual unattended automation)에서 말입니다.

그것이 OpenClaw 스레드에서 얻을 수 있는 진짜 교훈입니다.

사용자는 근본적으로 "어떤 모델이 더 똑똑한가?"라는 문제를 겪고 있었던 것이 아닙니다.

그들은 모델의 형상을 한 동시성 아키텍처 (concurrency architecture) 문제를 겪고 있었던 것입니다.

그 사실을 깨닫고 나면, 많은 에이전트의 기이한 현상들을 디버깅하기가 훨씬 쉬워집니다.

만약 10번째 에이전트가 3번째 에이전트를 멈추게 만든다면, 마법 같은 프롬프트(magic prompts)를 찾아 헤매는 것을 멈추십시오.

Claude, GPT-5, Qwen, Llama 사이를 오가며 그중 하나가 막힌 큐(Queue)를 구원해주길 바라지 마십시오.

먼저 큐(Queue)를 구축하십시오.

그다음에 모델을 선택하십시오.

만약 토큰 과금(token-billing)에 대한 불안 없이 API 스타일의 제어를 원하신다면, 그것이 바로 Standard Compute가 내세우는 핵심 가치입니다. 에이전트 워크로드(agent workloads)를 위한 OpenAI 호환 API 액세스, 고정된 월간 요금제, 그리고 자동화가 실행되는 동안 모든 토큰을 일일이 관리할 필요가 없는 환경을 제공합니다.