AI 에이전트를 서비스에 붙인 뒤 어려워지는 지점은 모델 호출 자체가 아닐 때가 많다. 사용자의 대화 맥락, 진행 중인 작업, 도구 실행 결과, 여러 클라이언트의 접속 상태를 어느 단위로 보관하고, 프로세스가 멈췄을 때 어디부터 다시 시작할지 정하는 문제가 남는다.
Rivet은 에이전트·사용자·세션·테넌트마다 장기 실행 액터를 둘 수 있는 오케스트레이션 방식을 제시한다. 액터에는 메모리 상태, SQLite 기반 저장소, WebSocket 연결, 스케줄링과 수명주기 훅이 결합된다. 따라서 도입 판단의 중심은 “더 빨리 실행되는가”가 아니라, 우리 workload가 상태를 오래 유지하고 많은 독립 실행 단위를 동시에 다루며, 각 단위의 실패 영향을 좁혀야 하는가에 둬야 한다.
반대로 이 조건이 약하면 액터 기반 구조는 새 운영 개념과 상태 설계 부담을 추가할 수 있다.
먼저 분리할 문제: 모델 추론 대기와 에이전트 실행 상태
에이전트는 추론 결과를 기다리는 동안에도 이전 메시지, 도구 호출 계획, 사용자의 접속 여부, 작업 진행 단계를 관리해야 한다. 이때 모든 처리를 요청마다 새로 시작하는 방식으로 만들면, 다음 요청에서 필요한 상태를 다시 읽고 조립하는 코드가 늘어난다.
Rivet Actors는 액터별 인메모리 변수와 영속 데이터베이스를 구분한다. 문서상 인메모리 변수는 재시작 뒤에도 남는 저장 상태가 아니라 실행 중에만 쓰는 상태다. 반면 데이터베이스에 저장한 기록은 액터가 잠들거나 다시 깨어나는 흐름에서도 접근할 수 있다.
이 구분은 제품 선택보다 설계 선택에 가깝다. 다음 질문에 “예”가 많다면 액터 모델을 검토할 이유가 생긴다.
- 한 사용자 또는 한 업무 건의 대화·작업 맥락이 여러 요청에 걸쳐 이어지는가.
- 같은 에이전트의 상태를 웹, 관리자 화면, 다른 내부 서비스가 함께 보고 갱신해야 하는가.
- 에이전트가 긴 작업 중간에 멈춰도 처음부터 다시 실행하지 않고, 저장된 단계에서 재개해야 하는가.
- 테넌트나 사용자별 상태가 서로 섞이면 안 되며, 실행 단위별로 문제 범위를 좁혀야 하는가.
반대로 질문과 답변이 한 번으로 끝나고, 상태를 기존 데이터베이스에서 읽어 응답한 뒤 종료해도 되는 서비스라면 액터를 새로 도입할 근거는 약하다. 이 경우에는 현재 API 서버, 작업 큐, 데이터베이스 조합이 요구사항을 더 적은 변화로 충족하는지 먼저 확인하는 편이 낫다.
높은 동시성은 액터 수가 아니라 상태의 독립성으로 평가한다
Rivet은 많은 수의 액터를 하나의 노드 프로세스에서 공유할 수 있고, 유휴 액터가 잠들었다가 요청 시 깨어나는 구조를 설명한다. 또한 S3 기반 저장과 액터의 낮은 메모리 사용량, 콜드 스타트 지연 시간 수치를 제시한다. 다만 이 수치는 해당 제품이 제시한 조건의 측정값이지, 각 조직의 에이전트 응답 시간이나 전체 운영비를 보장하는 값은 아니다.
의사결정자는 “동시 사용자 수가 많다”는 말보다 아래 세 가지를 따로 세어야 한다.
-
동시에 살아 있어야 하는 상태의 수
단순 요청 수가 많아도 각 요청이 상태를 남기지 않으면 액터가 꼭 필요하지 않을 수 있다. 반면 수천 개의 장기 세션이 각자 대화 기록, 작업 단계, 연결 상태를 유지한다면 상태 단위가 핵심이 된다. -
동일 상태에 접근하는 주체의 수
한 에이전트가 사용자 한 명에게만 답하는 경우와, 여러 사용자가 같은 에이전트 출력과 진행 상태를 실시간으로 보는 경우는 다르다. Rivet의 연결 및 이벤트 모델은 후자처럼 액터가 여러 클라이언트에 상태 변화를 전달해야 하는 상황에서 검토 대상이 된다. -
유휴 시간의 길이와 재개 빈도
오랫동안 아무 요청이 없다가 다시 이어지는 업무라면, 유휴 상태를 계속 실행 프로세스로 유지할지 잠들게 한 뒤 복구할지 결정해야 한다. 이때 깨어난 뒤 필요한 데이터가 무엇인지, 메모리에만 있던 값이 사라져도 되는지부터 정의해야 한다.
여기서 흔한 실패는 접속 수만 보고 액터 수를 추정하는 일이다. 실제로는 세션이 얼마나 오래 살아 있는지, 재접속 시 어느 상태를 복원해야 하는지, 한 상태를 누가 동시에 바꾸는지가 더 직접적인 판단 재료다.
실패 복구는 플랫폼 기능보다 업무 단계 설계에서 갈린다
액터 기반 시스템은 실패 복구를 다루기 좋은 모델이 될 수 있다. 신뢰성 있는 액터와 재시도 오케스트레이션을 다룬 연구는 실패한 호출의 재시도, 완료된 호출의 중복 방지, 실패 전후 호출 순서 보존 같은 성질이 복구 설계에 중요하다고 설명한다. 복잡한 작업을 더 작은 복구 가능 단계로 나누면 재실행 범위를 줄이는 데도 도움이 될 수 있다.
그러나 액터를 도입한다고 외부 API 호출, 결제, 이메일 발송, 파일 생성이 자동으로 안전해지는 것은 아니다. 특히 에이전트가 도구를 호출한 직후 프로세스가 중단되면, 호출이 실제로 완료됐는지와 상태 기록이 남았는지를 별도로 판정해야 한다.
Rivet 문서에는 생성, 기동, 수면, 재시작, 크래시, 연결, 액션 호출에 따른 수명주기 훅이 정의돼 있다. 이는 복구 지점을 코드로 다룰 여지를 준다. 하지만 팀이 다음을 문서화하지 않으면 훅이 많아도 운영 판단은 흔들린다.
- 어떤 데이터가 재시작 뒤에도 남아야 하는가.
- 도구 호출 전후에 어느 상태를 저장할 것인가.
- 같은 작업 요청이 다시 도착했을 때 재실행, 무시, 상태 조회 중 무엇을 할 것인가.
- 종료 훅이 호출되지 않는 상황에서도 잃으면 안 되는 정보는 무엇인가.
특히 종료나 수면 시 실행되는 정리 코드에 핵심 저장을 의존하면 위험하다. Rivet 문서도 크래시나 강제 종료 상황에서는 수면 훅이 항상 호출된다고 보장하지 않는다. 중요한 작업 결과와 외부 효과의 기록은 정상 종료 시점이 아니라 업무 단계가 확정되는 시점에 남기는 쪽으로 설계해야 한다.
실행 격리가 필요한 팀과 필요하지 않은 팀
Rivet이 제시하는 에이전트 구조에는 에이전트의 상태와 제어 루프를 액터에 두고, 코드 실행처럼 위험 범위가 큰 작업은 도구를 통해 별도 샌드박스로 보내는 방식이 포함된다. 에이전트가 생성하거나 실행하는 코드와, 사용자 맥락 및 장기 메모리를 관리하는 제어 영역을 나누려는 팀에는 검토 가치가 있다.
다만 “에이전트가 코드를 쓴다”는 사실만으로 샌드박스와 액터의 조합이 정답은 아니다. 결정은 실행하는 코드의 성격에 따라 달라진다.
- 격리 요구가 높은 경우: 에이전트가 신뢰할 수 없는 입력을 바탕으로 코드를 실행하거나, 사용자별 실행 결과가 다른 사용자 상태에 영향을 주면 안 되는 경우다. 이때는 제어 상태와 코드 실행 환경의 경계를 요구사항으로 명시해야 한다.
- 상태 공유가 중요한 경우: 여러 사용자가 하나의 작업 공간에서 에이전트의 진행 상황과 결과를 함께 보는 경우다. 액터별 연결 관리와 이벤트 전달이 설계 후보가 될 수 있다.
- 배치 중심인 경우: 입력을 모아 정해진 시간에 처리하고, 실시간 연결이나 세션별 장기 상태가 중요하지 않은 경우다. 기존 배치 처리나 큐 기반 작업 구조와 비교해야 한다.
- 짧은 질의 응답 중심인 경우: 사용자별 지속 상태와 중간 복구가 중요하지 않다면, 액터 수명주기와 상태 모델을 운영할 이유가 줄어든다.
여기서 확인할 질문은 “에이전트를 얼마나 많이 띄울 것인가”가 아니다. “이 에이전트가 가진 상태, 연결, 실행 권한 중 무엇을 같은 프로세스에 두고 무엇을 분리해야 하는가”다.
벤치마크 대신 실패 시나리오로 PoC를 설계하라
Rivet 검토를 시작한다면, 짧은 응답 시간 비교만 하는 PoC는 충분하지 않다. 하나의 대표 업무를 골라 상태와 실패를 의도적으로 넣어보는 편이 더 많은 답을 준다.
예를 들어 사용자별 에이전트 하나를 만들고, 대화 기록과 작업 단계를 영속 저장소에 남긴다. 동시에 두 클라이언트가 연결됐을 때 상태 변경이 어떻게 전달되는지 확인한다. 이어서 추론 호출 중단, 액터 재시작, 유휴 상태 전환 뒤 재접속처럼 운영에서 일어날 수 있는 흐름을 시험한다.
CTO나 개발 리드는 이 검증에서 다음 결과를 받아야 한다.
- 재시작 뒤 복원되는 정보와 사라지는 정보를 팀이 명확히 설명할 수 있는가.
- 외부 도구 호출이 중복됐을 때 업무상 허용 가능한 처리 규칙이 있는가.
- 액터 하나의 책임 범위가 사용자, 세션, 문서, 테넌트 중 무엇인지 합의됐는가.
- 연결이 끊긴 사용자가 다시 들어왔을 때 보여줄 상태를 정의했는가.
- 수명주기 훅과 저장소 구조를 운영할 담당자가 있는가.
이 질문에 답하지 못한다면 제품의 콜드 스타트나 메모리 수치가 좋아도 도입 근거는 약하다. 반대로 장기 상태, 다중 접속, 복구 가능한 업무 단계, 실행 경계가 한 workload 안에 함께 존재한다면 Rivet 같은 액터 기반 오케스트레이터는 인프라 최적화 도구가 아니라 애플리케이션 상태를 관리하는 핵심 선택지가 될 수 있다.
PoC의 통과 기준은 “가장 빠른 응답”이 아니라 “중단된 업무가 어떤 상태로 돌아오며, 누가 그 상태를 설명하고 복구할 수 있는가”로 정하는 편이 낫다.
