OpenAI의 O1, Devin 또는 맞춤형 기업 추론 에이전트 등 최근 고급 AI 에이전트를 사용해 본 적이 있다면 아마도 본 적이 있을 것입니다. 정확히 60초 동안 회전하는 물레. 빈 화면이 이어집니다. 그 뒤에는 **“504 게이트웨이 시간 초과”**라는 무서운 메시지가 표시됩니다.
코드의 버그가 아닙니다. 서버충돌은 아닙니다. 이는 우리가 구축한 인터넷(Web 2.0)과 우리가 구축 중인 인터넷의 워크로드(Agentic AI) 사이의 근본적이고 구조적인 비호환성입니다.
현대 웹은 타임아웃 위기에 직면해 있으며 이를 해결하려면 웹이 “빠르다”는 핵심 가정을 무너뜨려야 합니다.
기존 계약: REST와 30초 규칙
지난 20년 동안 웹은 응답성이라는 한 가지 목적으로 최적화되었습니다. 지배적인 패러다임은 REST(Representational State Transfer)입니다. 클라이언트와 서버 간의 계약은 동기식이며 간단합니다.
- 요청: 클라이언트가 데이터를 요청합니다(예: “사용자 프로필 가져오기”).
- 프로세스: 서버가 데이터를 검색합니다(데이터베이스 쿼리: ~50ms).
- 응답: 서버가 데이터를 다시 보냅니다.
2단계가 30초(일부 클라우드에서는 60초) 이상 소요되면 인프라 패닉이 발생합니다. 로드 밸런서(NGINX, AWS ALB, Cloudflare)는 서버가 죽었거나, “좀비화”되었거나, 무한 루프에 갇혀 있다고 가정합니다. 시스템을 보호하기 위해 연결을 끊습니다. 이는 버그가 아닌 기능이었습니다. 중단된 프로세스가 RAM 및 CPU 스레드를 소모하는 것을 방지했습니다. 그것은 “빠른 실패” 규율을 시행했습니다.
Agentic AI의 시작: 시간을 초월하는 워크로드
고전적으로 컴퓨터는 빨랐습니다. 쿼리에 5분이 걸렸다면 SQL이 잘못된 것입니다. 하지만 에이전트 AI는 단순한 ‘질의’가 아닙니다. 그것은 “생각”이다.
“O1” 클래스 추론 모델 또는 Agentic Workflow는 단지 데이터를 조회하는 것이 아닙니다. 그것:
- 프롬프트를 계획으로 분해합니다.
- 웹을 탐색합니다(10개 사이트 스크랩).
- 작성 코드를 작성합니다.
- 샌드박스에서 코드를 실행합니다.
- 오류 로그를 분석합니다.
- 코드를 리팩터링합니다.
- 반복.
이 프로세스는 밀리초 단위로 측정되지 않습니다. 분 단위로 측정됩니다. 때로는 몇 시간. 5분짜리 사고 과정을 30초짜리 REST 파이프에 강제로 적용하면 파이프가 터집니다. Client(브라우저)는 아직 대기 중이지만 Middleman(Load Balancer)은 이미 전화를 끊었습니다. 에이전트는 4분 후에 작업을 마쳤지만 대화할 사람이 없습니다. 그 결과 작업 손실, 사용자 좌절, 컴퓨팅 크레딧 낭비가 발생합니다.
아키텍처 변화: 동기식에서 이벤트 중심으로
Agentic 시대에서 살아남기 위해 우리는 SOAP/XML이 사라진 이후 가장 중요한 아키텍처 변화를 목격하고 있습니다. 동기식 요청/응답에서 **비동기식 이벤트 기반 아키텍처(EDA)**로 전환하고 있습니다.
“티켓” 시스템
새로운 패러다임에서는 AI에게 “웹 사이트를 만들어주세요”라고 요청하면 서버가 응답하지 않습니다.
- 요청: 클라이언트가 프롬프트를 보냅니다.
- 확인: 서버가 즉시(HTTP 202 승인됨) 응답합니다. “알겠습니다. 티켓 ID #1234입니다. 작업 중입니다. 안녕히 계세요.”
- 연결 끊기: HTTP 연결이 닫힙니다. 브라우저는 다른 작업을 자유롭게 수행할 수 있습니다.
- 처리 중: 에이전트가 백그라운드에서 작동합니다(분/시간).
- 알림: 완료되면 서버는 신호를 보냅니다.
신호 프로토콜: 브라우저는 어떻게 알 수 있나요?
우리는 5단계를 처리하기 위한 프로토콜 전쟁을 보고 있습니다.
- 폴링: 브라우저는 5초마다 “아직 완료되었나요?”라고 묻습니다. (간단하지만 리소스 집약적)
- 웹후크: 완료되면 서버가 특정 URL을 호출합니다(서버 간에는 적합하고 브라우저에는 적합하지 않음).
- 서버 전송 이벤트(SSE): 서버가 업데이트(“스캔 중…”, “코드 작성 중…”, “완료”)를 푸시하는 단방향 영구 채널입니다. 이는 LLM 토큰 스트리밍의 표준이 되고 있습니다.
- WebSocket: 완전한 양방향 통신. 대부분의 텍스트 생성에는 과잉이지만 실시간 음성/영상 에이전트에는 필요합니다.
내구성 있는 실행 폭발
타임아웃 위기로 인해 Temporal, Inngest, Hatchet과 같은 Durable Execution 플랫폼이 폭발적으로 증가했습니다.
표준 Python/노드 스크립트에서 에이전트가 작업을 시작한 지 4분 동안 서버가 다시 시작되거나 충돌하면 해당 4분의 작업이 손실됩니다. AI에는 “기억상실증”이 있습니다. 내구성 실행 엔진은 영구 로그를 도입합니다. 모든 단계에서 함수의 “상태”를 저장합니다.
- 1단계: 계획 생성(저장).
- 2단계: Google 스크랩(저장됨).
- 충돌(서버 재부팅).
- 복구: 서버가 깨어나서 2단계가 완료된 것을 확인하고 3단계에서 즉시 재개합니다.
AI는 비결정적이고 비싸기 때문에 이는 매우 중요합니다. 포드가 다시 시작되었다는 이유만으로 $2.00 API 호출을 다시 실행할 여유가 없습니다. 내구성 있는 실행을 통해 에이전트가 시작되면 완료가 보장됩니다.
미래: A2A(Agent-to-Agent)
우리는 인터넷 트래픽의 대부분이 인간 대 서버가 아닌 **에이전트 대 에이전트(A2A)**인 세상에 빠르게 다가오고 있습니다. 이러한 에이전트는 “로드 스피너” 또는 “인식된 대기 시간”에 관심이 없습니다. 그들은 신뢰성과 정확성에 관심을 갖습니다.
에이전트가 장기간에 걸쳐 서로를 발견하고 대화할 수 있도록 특별히 설계된 새로운 프로토콜(예: MCP - 모델 컨텍스트 프로토콜)이 탄생하고 있습니다. ‘인스턴트 웹’ 시대가 끝났다. “사려깊은 웹”이 시작됩니다. 시간 초과를 멈추면됩니다.
출처 (4)
- temporal.io Durable Execution
- platform.openai.com OpenAI: Optimizing Latency
- aws.amazon.com Asynchronous Patterns
- inngest.com Event-Driven Systems
🦋 Bluesky 토론
Bluesky에서 토론하기