당신의 모든 에이전트는 비동기로 간다 — HTTP 요청-응답이 더 이상 맞지 않는 이유

LLM과 사용자의 상호작용은 프롬프트 입력 → 토큰 스트리밍 응답이라는 채팅 모델로 시작했고, 그 위에 HTTP 요청-응답이 자연스럽게 놓였습니다. Zak Knill(Ably)은 이것이 원래 맞춤한 선택이 아니라 우연이었다고 말합니다. 에이전트가 사람의 동기적 감독 없이 백그라운드에서 일하기 시작하면, 이 토대 자체가 어긋납니다.

원문: All Your Agents Are Going Async — Zak Knill (2026)

핵심 도발

“The interesting thing is what agents can do while not being synchronously supervised by a human.”

흥미로운 일은 사람이 보고 있는 동안이 아니라, 사람이 보고 있지 않은 동안에 일어납니다. 그리고 그 일을 담을 그릇은 HTTP 요청-응답이 아닙니다.

패러다임 전환 — 백그라운드로 간 에이전트

전통적 챗봇 모델:

• 사용자가 입력
• 모델이 토큰 단위로 응답을 흘려보냄
• 연결이 끊기면 끝

새로운 현실:

• 백그라운드 작업, 크론, 웹훅, 스케줄 루틴
• 에이전트가 사람과 시간적·공간적으로 분리
• 사람은 잠들거나 다른 디바이스로 이동해도 작업은 계속

OpenClaw가 WhatsApp 안에서 에이전트를 운영하며 이 분리를 보여준 것이 분기점이었습니다. 이후 업계 전반의 응답:

트랜스포트 미스매치 — HTTP가 깨지는 4가지 장면

Knill의 진단의 핵심. HTTP 요청-응답 모델이 무너지는 시나리오들:

1. 에이전트가 호출자보다 오래 산다

작업이 끝나기 전에 원본 커넥션이 닫힙니다. 결과는 DB에 쌓이고, 누군가가 폴링해야 발견됩니다.

2. 에이전트가 푸시를 시작한다

완료된 작업을 사람에게 능동적으로 알려야 합니다. 지금은 이메일·Slack 같은 외부 채널로 우회 — 트랜스포트 계층이 풀고 있는 문제가 아닙니다.

3. 호출자가 디바이스를 바꾼다

데스크톱에서 시작한 세션을 휴대폰에서 이어받기 — HTTP에는 네이티브 지원이 없습니다. Anthropic은 자체 백엔드 엔지니어링으로 우회.

4. 한 세션에 여러 사람

팀이 같은 세션에 들어와 협업해야 한다면 fan-out 메시징이 필요합니다. HTTP는 서버가 여러 클라이언트에 push하는 모델이 없습니다.

OpenClaw가 우아하게 푼 지점: “에이전트 작업 수명” 과 “커넥션 수명” 을 분리한 것.

업계의 두 가지 응답

Anthropic — 호스티드 일원화

세션 상태, 대화 이력, 추론을 Anthropic의 호스팅 플랫폼 안에 중앙집중시켜 Routines와 Remote Control로 풀었습니다. 자기 인프라가 아닌, 그들의 인프라 위에서 비동기성을 누리는 모델.

Cloudflare — 상태 API + 메일

• Sessions API — HTTP로 접근 가능한 세션/대화 저장소
• Email for Agents — 비동기 알림용

자기 인프라 위에서 쓸 수 있는 빌딩 블록을 제공.

공통점: 둘 다 durable state를 우선시합니다.

핵심 분리 — Durable State vs Durable Transport

Knill이 도입하는 결정적 어휘:

Anthropic과 Cloudflare는 state는 잘 풀지만 transport는 폴링(또는 HTTP polling)에 의존합니다. 그 결과 art of the possible에 못 미치는 경험이 나옵니다 — 디바이스 전환, 다중 참여자, 능동 푸시 같은 시나리오에서.

현재 솔루션의 절반 문제

“현재 솔루션은 세션과 트랜스포트를 단일 HTTP 요청-응답 사이클 안에 녹여 둔다.”

state durability는 개선됐지만 transport durability는 그대로. 그리고 self-host 가능한 OpenClaw-스타일 채널 모델의 엔터프라이즈 등가물은 아직 없습니다.

Knill의 제안 — 세션을 1급 프리미티브로

Knill은 자신이 Ably에서 에이전트용 durable transport 솔루션을 만들고 있다고 밝힙니다. 토대는 Ably의 기존 리얼타임 메시징 인프라. 핵심 명제:

“AI와의 ‘세션’은 사람과 에이전트가 언제든 접속하고 끊을 수 있는 무언가여야 한다.”

세션이 가져야 할 속성:

• 네트워크 중단을 투명하게 견딘다
• 다중 디바이스·다중 사용자 접근을 네이티브 지원
• 대화 상태에 접근 가능
• 사람 ↔ 에이전트 양방향 알림

접근 방식: 세션 상태와 대화 이력을 양방향·내구성·실시간 메시징 인프라 위에 얹는다 — state와 transport 두 절반을 동시에 다룬다.

아키텍처 패턴 비교

새 어휘 정리

• Durable state — 끊김을 견디는 영속 에이전트 데이터
• Durable transport — 단일 커넥션과 무관하게 견디는 메시지 전달
• Async agents — 사람의 동기적 감독에서 분리된 백그라운드 AI
• Session — 사람과 에이전트의 영속 연결을 표현하는 1급 프리미티브

실행 체크리스트

• 우리 시스템에서 에이전트 작업 수명 ≠ 커넥션 수명 인 시나리오를 목록화
• 비동기 결과 전달이 외부 채널(이메일/Slack)에 우회되고 있는지 식별 — 트랜스포트 결함의 신호
• 디바이스 전환·다중 참여자·서버 푸시가 필요한 사용 사례를 분리 평가
• State 솔루션과 Transport 솔루션을 따로 선택 — 한 박스에 묶지 말 것
• 벤더 호스티드 모델을 쓸 때 이식성 비용을 명시적으로 계산

왜 이 글이 중요한가

대부분의 에이전트 인프라 논의는 모델 품질, 도구 호출, 메모리 에 머무릅니다. Knill의 글은 트랜스포트 계층의 가정을 직접 겨눕니다.

1. 역사적 진단 — HTTP 채택은 우연이지 적합성이 아니다
2. 명확한 분리 — durable state와 durable transport는 다른 문제
3. 현재 솔루션의 빈자리 — 절반만 풀고 있는 업계의 현 상태
4. 새 1급 프리미티브 — 세션을 양방향 메시징 인프라 위에 두는 방향

인프라의 선택은 아키텍처의 가능성을 결정한다.

핵심 결론

• 에이전트는 동기 챗봇에서 비동기 백그라운드 워커로 이동했다
• HTTP 요청-응답은 이 전환의 최소 4가지 장면에서 깨진다(생존, 푸시, 디바이스 전환, 다자 참여)
• Durable state와 Durable transport는 다른 절반의 문제이며, 두 절반을 같이 풀어야 art of the possible에 닿는다
• Anthropic·Cloudflare는 state에 강하지만 transport는 폴링에 의존
• 미래 모양: 세션이 1급 프리미티브, 양방향 리얼타임 메시징이 토대
• 자기 호스팅 가능한 OpenClaw 등가물은 아직 시장의 빈 자리 — Ably/유사 플레이어가 채우는 중

당신의 에이전트는 비동기로 가고 있는데, 그 통신은 여전히 동기 시대의 그릇 안에 남아 있는가.