{"title":"당신의 모든 에이전트는 비동기로 간다 — HTTP 요청-응답이 더 이상 맞지 않는 이유","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/all-your-agents-are-going-async/","section":"posts","date":"2026-04-24T17:18:12+09:00","lastmod":"2026-04-24T17:18:12+09:00","description":"Zak Knill(Ably)이 던지는 인프라 진단 — 챗봇이 HTTP 요청-응답 위에 만들어진 것은 일종의 사고였고, 비동기 에이전트의 시대에는 이 선택이 깨진다. Durable State와 Durable Transport를 분리해서 보면 Anthropic Routines, Cloudflare Sessions API, OpenClaw 채널, Ably의 세션 모델이 어떻게 다른지가 명확해진다.","summary":"LLM과 사용자의 상호작용은 프롬프트 입력 → 토큰 스트리밍 응답이라는 채팅 모델로 시작했고, 그 위에 HTTP 요청-응답이 자연스럽게 놓였습니다. Zak Knill(Ably)은 이것이 원래 맞춤한 선택이 아니라 우연이었다고 말합니다. 에이전트가 사람의 동기적 감독 없이 백그라운드에서 일하기 시작하면, 이 토대 자체가 어긋납니다.\n원문: All Your Agents Are Going Async — Zak Knill (2026)\n핵심 도발 \u0026ldquo;The interesting thing is what agents can do while not being synchronously supervised by a human.\u0026rdquo;\n흥미로운 일은 사람이 보고 있는 동안이 아니라, 사람이 보고 있지 않은 동안에 일어납니다. 그리고 그 일을 담을 그릇은 HTTP 요청-응답이 아닙니다.\n","content":"LLM과 사용자의 상호작용은 프롬프트 입력 → 토큰 스트리밍 응답이라는 채팅 모델로 시작했고, 그 위에 HTTP 요청-응답이 자연스럽게 놓였습니다. Zak Knill(Ably)은 이것이 원래 맞춤한 선택이 아니라 우연이었다고 말합니다. 에이전트가 사람의 동기적 감독 없이 백그라운드에서 일하기 시작하면, 이 토대 자체가 어긋납니다.\n원문: All Your Agents Are Going Async — Zak Knill (2026)\n핵심 도발 \u0026ldquo;The interesting thing is what agents can do while not being synchronously supervised by a human.\u0026rdquo;\n흥미로운 일은 사람이 보고 있는 동안이 아니라, 사람이 보고 있지 않은 동안에 일어납니다. 그리고 그 일을 담을 그릇은 HTTP 요청-응답이 아닙니다.\n패러다임 전환 — 백그라운드로 간 에이전트 전통적 챗봇 모델:\n사용자가 입력 모델이 토큰 단위로 응답을 흘려보냄 연결이 끊기면 끝 새로운 현실:\n백그라운드 작업, 크론, 웹훅, 스케줄 루틴 에이전트가 사람과 시간적·공간적으로 분리 사람은 잠들거나 다른 디바이스로 이동해도 작업은 계속 OpenClaw가 WhatsApp 안에서 에이전트를 운영하며 이 분리를 보여준 것이 분기점이었습니다. 이후 업계 전반의 응답:\n회사 비동기 기능 Anthropic Channels(MCP 기반 비동기 메시징), /loop·/schedule, Routines, Remote Control OpenAI Scheduled Tasks Cursor Cloud Background Agents 트랜스포트 미스매치 — HTTP가 깨지는 4가지 장면 Knill의 진단의 핵심. HTTP 요청-응답 모델이 무너지는 시나리오들:\n1. 에이전트가 호출자보다 오래 산다 작업이 끝나기 전에 원본 커넥션이 닫힙니다. 결과는 DB에 쌓이고, 누군가가 폴링해야 발견됩니다.\n2. 에이전트가 푸시를 시작한다 완료된 작업을 사람에게 능동적으로 알려야 합니다. 지금은 이메일·Slack 같은 외부 채널로 우회 — 트랜스포트 계층이 풀고 있는 문제가 아닙니다.\n3. 호출자가 디바이스를 바꾼다 데스크톱에서 시작한 세션을 휴대폰에서 이어받기 — HTTP에는 네이티브 지원이 없습니다. Anthropic은 자체 백엔드 엔지니어링으로 우회.\n4. 한 세션에 여러 사람 팀이 같은 세션에 들어와 협업해야 한다면 fan-out 메시징이 필요합니다. HTTP는 서버가 여러 클라이언트에 push하는 모델이 없습니다.\nOpenClaw가 우아하게 푼 지점: \u0026ldquo;에이전트 작업 수명\u0026rdquo; 과 \u0026ldquo;커넥션 수명\u0026rdquo; 을 분리한 것.\n업계의 두 가지 응답 Anthropic — 호스티드 일원화 세션 상태, 대화 이력, 추론을 Anthropic의 호스팅 플랫폼 안에 중앙집중시켜 Routines와 Remote Control로 풀었습니다. 자기 인프라가 아닌, 그들의 인프라 위에서 비동기성을 누리는 모델.\nCloudflare — 상태 API + 메일 Sessions API — HTTP로 접근 가능한 세션/대화 저장소 Email for Agents — 비동기 알림용 자기 인프라 위에서 쓸 수 있는 빌딩 블록을 제공.\n공통점: 둘 다 durable state를 우선시합니다.\n핵심 분리 — Durable State vs Durable Transport Knill이 도입하는 결정적 어휘:\n개념 다루는 질문 Durable State 에이전트 상태가 어디에 살고, 재시작 시 어떻게 접근하며, 출력은 어디에 저장되는가 Durable Transport 응답 바이트가 어떻게 사람과 에이전트 사이를 오가고, 끊긴 커넥션·디바이스 전환·fan-out·서버 푸시를 어떻게 다루는가 Anthropic과 Cloudflare는 state는 잘 풀지만 transport는 폴링(또는 HTTP polling)에 의존합니다. 그 결과 art of the possible에 못 미치는 경험이 나옵니다 — 디바이스 전환, 다중 참여자, 능동 푸시 같은 시나리오에서.\n현재 솔루션의 절반 문제 \u0026ldquo;현재 솔루션은 세션과 트랜스포트를 단일 HTTP 요청-응답 사이클 안에 녹여 둔다.\u0026rdquo;\nstate durability는 개선됐지만 transport durability는 그대로. 그리고 self-host 가능한 OpenClaw-스타일 채널 모델의 엔터프라이즈 등가물은 아직 없습니다.\nKnill의 제안 — 세션을 1급 프리미티브로 Knill은 자신이 Ably에서 에이전트용 durable transport 솔루션을 만들고 있다고 밝힙니다. 토대는 Ably의 기존 리얼타임 메시징 인프라. 핵심 명제:\n\u0026ldquo;AI와의 \u0026lsquo;세션\u0026rsquo;은 사람과 에이전트가 언제든 접속하고 끊을 수 있는 무언가여야 한다.\u0026rdquo;\n세션이 가져야 할 속성:\n네트워크 중단을 투명하게 견딘다 다중 디바이스·다중 사용자 접근을 네이티브 지원 대화 상태에 접근 가능 사람 ↔ 에이전트 양방향 알림 접근 방식: 세션 상태와 대화 이력을 양방향·내구성·실시간 메시징 인프라 위에 얹는다 — state와 transport 두 절반을 동시에 다룬다.\n아키텍처 패턴 비교 모델 State Transport 한계 HTTP-SSE 챗봇 클라이언트 또는 임시 단일 커넥션 비동기 에이전트에 부적합 OpenClaw 채널 채팅 플랫폼이 보존 채널이 곧 트랜스포트 자기 호스팅이 어려움 Anthropic 호스티드 중앙집중 폴링/HTTP 벤더 종속 Cloudflare Sessions API 분산 키-밸류 HTTP 트랜스포트는 미해결 Ably 세션 (Knill 제안) 메시지 인프라 위에 얹음 양방향 리얼타임 작업 진행 중 새 어휘 정리 Durable state — 끊김을 견디는 영속 에이전트 데이터 Durable transport — 단일 커넥션과 무관하게 견디는 메시지 전달 Async agents — 사람의 동기적 감독에서 분리된 백그라운드 AI Session — 사람과 에이전트의 영속 연결을 표현하는 1급 프리미티브 실행 체크리스트 우리 시스템에서 에이전트 작업 수명 ≠ 커넥션 수명 인 시나리오를 목록화 비동기 결과 전달이 외부 채널(이메일/Slack)에 우회되고 있는지 식별 — 트랜스포트 결함의 신호 디바이스 전환·다중 참여자·서버 푸시가 필요한 사용 사례를 분리 평가 State 솔루션과 Transport 솔루션을 따로 선택 — 한 박스에 묶지 말 것 벤더 호스티드 모델을 쓸 때 이식성 비용을 명시적으로 계산 왜 이 글이 중요한가 대부분의 에이전트 인프라 논의는 모델 품질, 도구 호출, 메모리 에 머무릅니다. Knill의 글은 트랜스포트 계층의 가정을 직접 겨눕니다.\n역사적 진단 — HTTP 채택은 우연이지 적합성이 아니다 명확한 분리 — durable state와 durable transport는 다른 문제 현재 솔루션의 빈자리 — 절반만 풀고 있는 업계의 현 상태 새 1급 프리미티브 — 세션을 양방향 메시징 인프라 위에 두는 방향 인프라의 선택은 아키텍처의 가능성을 결정한다.\n핵심 결론 에이전트는 동기 챗봇에서 비동기 백그라운드 워커로 이동했다 HTTP 요청-응답은 이 전환의 최소 4가지 장면에서 깨진다(생존, 푸시, 디바이스 전환, 다자 참여) Durable state와 Durable transport는 다른 절반의 문제이며, 두 절반을 같이 풀어야 art of the possible에 닿는다 Anthropic·Cloudflare는 state에 강하지만 transport는 폴링에 의존 미래 모양: 세션이 1급 프리미티브, 양방향 리얼타임 메시징이 토대 자기 호스팅 가능한 OpenClaw 등가물은 아직 시장의 빈 자리 — Ably/유사 플레이어가 채우는 중 당신의 에이전트는 비동기로 가고 있는데, 그 통신은 여전히 동기 시대의 그릇 안에 남아 있는가.\n","wordCount":807,"tags":["AI","에이전트","Async","HTTP","Durable Transport","Durable State","Zak Knill","Ably","Anthropic","Cloudflare","OpenClaw","인프라"],"categories":["AI"],"frameworks":["Durable State vs Durable Transport","Session as First-class Primitive"],"mental_models":["Async Agent Lifecycle","Transport-State Separation","Connection Lifetime ≠ Work Lifetime"],"philosophy_type":"infrastructure-design","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["HTTP 요청-응답은 챗봇의 우연적 선택 — 백그라운드 에이전트 시대에는 Durable Transport가 필요","Durable State(작업 결과 저장)와 Durable Transport(알림·푸시·디바이스 간 이동)의 분리가 핵심 설계","HTTP가 깨지는 4가지 장면: 에이전트가 호출자보다 오래 삶, 푸시 시작, 디바이스 변경, 다중 사용자 세션","Anthropic Routines·Cloudflare Sessions API·OpenClaw 채널·Ably 세션 모델 비교 분석"],"related":["posts/anatomy-of-an-agent-harness","posts/zero-alignment-maggie-appleton","posts/probabilistic-engineering-24-7-employee"]}