에이전트 서비스를 만들면 왜 갑자기 인프라가 어려워질까
챗봇 데모를 만들 때는 참 쉬워요. API를 한 번 호출하고 응답을 화면에 뿌리면 끝이거든요. 그런데 이걸 실제 서비스로 올리는 순간 문제가 달라져요. 에이전트는 한 번 일을 시작하면 몇 분, 길게는 몇 시간씩 돌아가요. 중간에 도구를 호출하고, 사용자 승인을 기다리고, 그동안 쌓인 대화 기록과 작업 상태도 계속 들고 있어야 하죠.
Rivet은 바로 이 지점을 겨냥한 오픈소스 프로젝트예요. YC W23 출신 팀이 만들고 있고, 이번에 '에이전트를 S3 위에서 확장하고 오케스트레이션한다'는 메시지를 내걸었어요. 오케스트레이션이 뭐냐면, 여러 작업을 언제 어디서 실행할지 지휘하는 일이에요. 오케스트라 지휘자를 떠올리면 딱 맞아요.
핵심 개념은 액터예요
Rivet의 중심에는 액터(Actor)라는 개념이 있어요. 이게 뭐냐면, 자기 상태를 직접 들고 있는 작은 프로그램 단위예요. 보통 웹 서버는 요청이 끝나면 아무것도 기억하지 않아요. 그래서 요청이 올 때마다 DB에서 데이터를 읽고 다시 저장하죠. 식당으로 치면 손님이 부를 때마다 새 직원이 와서 장부를 처음부터 뒤져 보는 셈이에요.
액터는 반대예요. 테이블마다 전담 직원이 붙어서 주문 내용을 기억하고 있는 거죠. 에이전트 세션 하나, 사용자 한 명, 문서 하나마다 액터를 하나씩 두면 상태가 코드 바로 옆 메모리에 있으니까 읽기가 빨라요. 액터는 들어온 메시지를 차례대로 처리하는 모델이라서, 같은 데이터를 두 곳에서 동시에 고치다가 꼬이는 문제도 훨씬 단순해지고요.
Rivet은 여기에 상태 저장, WebSocket 같은 실시간 통신, 예약 작업, 그리고 쓰지 않을 때 잠들었다가 요청이 오면 깨어나는 기능을 묶어서 제공해요. TypeScript 라이브러리에서 actor({ state, actions }) 같은 형태로 상태와 동작을 정의하는 방식이에요.
이 중에서 잠드는 기능이 에이전트에 특히 중요해요. 에이전트는 LLM 응답이나 사용자 승인을 기다리며 노는 시간이 정말 길거든요. 그 시간 내내 프로세스를 붙잡아 두면 돈만 나가요. 상태를 저장하고 잠들었다가 필요할 때 이어서 실행하면 낭비를 크게 줄일 수 있어요.
왜 하필 S3일까
S3는 원래 파일 창고 같은 저장소예요. 싸고 튼튼하고 용량 걱정이 거의 없는 대신, DB처럼 빠르지는 않아요. 그런데 최근 몇 년 사이 'S3를 저장소의 중심에 두자'는 설계가 인프라 업계의 큰 흐름이 됐어요. Kafka 호환 스트리밍을 S3 위에 올린 WarpStream, 오브젝트 스토리지 기반 벡터 검색 turbopuffer, 스토리지와 컴퓨트를 분리한 Neon이 대표적이에요.
이게 가능해진 기술적 배경도 있어요. AWS가 2024년에 S3에 조건부 쓰기를 추가했거든요. '이 파일이 아직 없을 때만 써라' 같은 조건을 걸 수 있어서, 별도의 락 서버 없이도 여러 서버가 충돌을 피하며 협력하기가 쉬워졌어요. 지연 시간이 짧은 S3 Express One Zone 같은 선택지도 생겼고요.
에이전트 상태를 S3에 두면 장점이 분명해요. 세션이 수백만 개로 늘어나도 잠든 세션은 저장 비용만 내면 되고, 컴퓨트 서버는 언제든 갈아 끼울 수 있거든요. 다만 Rivet이 S3를 정확히 어떤 구조로 쓰는지, 캐시나 쓰기 묶음 처리를 어떻게 하는지는 저장소 문서에서 직접 확인해 보시길 권해요. S3는 요청 건수로도 과금되고 지연도 있어서, 이 부분 설계가 실제 비용과 속도를 좌우하거든요.
비슷한 도구들과 뭐가 다를까
가장 가까운 비교 대상은 Cloudflare Durable Objects예요. 개념은 매우 비슷한데, Durable Objects는 Cloudflare 플랫폼 안에서 쓰는 기능이에요. Rivet은 오픈소스라 직접 호스팅할 수 있다는 점이 가장 큰 차이죠.
Temporal, Restate, Inngest 같은 내구성 실행(durable execution) 도구도 자주 비교돼요. 내구성 실행은 프로세스가 죽어도 마지막 단계부터 이어서 실행해 주는 기술인데요, 이쪽은 '워크플로를 끝까지 완주시키는 것'이 중심이에요. 반면 액터는 '오래 살아 있으면서 실시간으로 대화하는 객체'에 가까워요. 정해진 단계를 밟는 작업이면 워크플로 엔진이, 사용자와 계속 주고받는 세션형 에이전트라면 액터가 잘 맞는 편이에요.
한국 개발자에게 주는 시사점
당장 전부 갈아엎을 필요는 없어요. 에이전트 기능이 요청 한 번에 끝나는 수준이라면 Redis와 Postgres로 충분하거든요. 하지만 아래 증상이 보이면 액터 모델을 공부해 볼 때예요.
- 긴 작업이 배포 때마다 끊겨서 처음부터 다시 돌아요.
- 세션 상태를 Redis에 넣고 빼는 코드가 점점 늘어나요.
- WebSocket 서버와 작업 큐를 따로 운영하느라 구조가 복잡해졌어요.
마무리
한 줄로 정리하면, 에이전트 시대의 백엔드는 '요청을 처리하는 서버'에서 '상태를 품고 잠들었다 깨어나는 객체'로 옮겨 가고 있어요. 여러분 팀은 에이전트의 긴 작업과 세션 상태를 지금 어떻게 관리하고 계신가요? Redis, 워크플로 엔진, 액터 중 어떤 방식이 가장 잘 맞았는지 경험을 나눠 주세요.
🔗 출처: Hacker News