Spanner 큐 출시: 에이전트 워크로드 등을 위한 트랜잭션 메시징

Nitin Sagar
Product Manager
Matthew Mucklo
Engineering Manager & Lead Cloud Spanner Data Streaming
*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.
AI 에이전트는 단순히 쿼리에 답하는 데 그치지 않고 자율적으로 환불을 처리하고, 인벤토리를 관리하며, 다단계 핸드오프를 실행하고, 하위 에이전트를 조정하는 등 복잡한 에이전트 워크플로를 수행할 수 있습니다. 이로 인해 에이전트는 운영 데이터베이스에서 내부 상태를 유지하면서 별도의 메시징 또는 이벤트 큐 시스템을 통해 비동기 작업을 디스패치해야 하는 경우가 많습니다. 하지만 안타깝게도 이러한 애플리케이션을 개발하는 팀 입장에서는, 커밋 시점이 서로 맞지 않는 두 시스템을 관리하면 에이전트형 시스템의 트랜잭션 일관성이 훼손됩니다.
오늘 Google Cloud는 Spanner에 직접 내장된 기본 트랜잭션 메시징인 Spanner 큐의 정식 버전이 출시되었다는 기쁜 소식을 전해드립니다. 신뢰할 수 있는 에이전트 실행을 위해 특별히 설계된 Spanner 큐를 사용하면, 메시지 생성은 트랜잭션 내에서 또 하나의 쓰기 작업을 수행하는 것만큼이나 간단해집니다. 에이전트의 상태 변경과 의도된 다운스트림 작업은 원자적으로 함께 커밋되거나 그렇지 않을 경우 완전히 실패합니다.
기존 방식과 비교해 보겠습니다. 데이터베이스 상태 업데이트는 성공했지만 작업 디스패치에 실패하는 경우, AI 에이전트는 수행할 작업은 결정했으나 실제 실행은 하지 못하는 상태가 됩니다. 메시지 디스패치가 성공했지만 상태 트랜잭션이 롤백되면 에이전트가 잘못된 상태를 기반으로 작업을 실행합니다. 비동기 멀티 에이전트 조정에서 발생하는 재시도, 추측 실행, 경합 상태는 이러한 오류를 더욱 악화시켜, 결국 개발자가 복잡한 아웃박스 패턴, 멱등성 레이어, 조정 작업자를 직접 구축해야만 하며, 이는 에이전트형 아키텍처에 막대한 신뢰성 부담을 안겨줍니다.
에이전트형 아키텍처의 주요 기능
Spanner 큐는 인프라 오버헤드를 발생시키지 않고 이러한 복잡한 비동기 워크플로를 지원하는 몇 가지 핵심 기능을 제공합니다.
원자적 '결정 및 실행' 큐 추가. 단일 Spanner 읽기-쓰기 트랜잭션 내에서 에이전트는 내부 메모리 또는 상태 테이블을 업데이트하고 동시에 피어 에이전트에 태스크를 큐에 추가할 수 있습니다. Spanner의 엄격한 직렬화 가능성과 전역 외부 일관성을 기반으로 상태 변경과 실행 의도가 단일 원자 단위로 커밋됩니다.
예약된 실행 및 지연. 큐 메시지는 커밋 즉시 디스패치되거나 향후 전송되도록 예약할 수 있습니다. 지연된 재시도, 예약된 에이전트 체크인, SLA 에스컬레이션 타이머와 같은 에이전트 패턴은 외부 cron 스케줄러나 폴링 인프라 없이도 메모리 업데이트와 함께 트랜잭션 방식으로 큐에 추가할 수 있습니다.
에이전트 작업자를 위한 스트리밍 SQL 가져오기. 자율 에이전트는 스트리밍 SQL 읽기를 통해 작업을 동적으로 가져와 처리합니다. 에이전트 런타임은 수신되는 작업을 스트리밍하고, 용량이 확보되는 대로 처리하며, 트랜잭션 내에서 작업 완료를 확인하여 엔드 투 엔드 작업 실행 상태의 안정성을 보장합니다.
에피소드 메모리 지속성 및 핸드오프. 장기 에피소드 요약, 반영 상태 전환, 하위 에이전트 간 컨텍스트 핸드오프를 포함한 에이전트 메모리 업데이트는 큐를 통해 비동기적이면서도 트랜잭션 방식으로 유지될 수 있습니다. 이를 통해 에이전트의 내부 메모리가 실시간 대화형 턴을 차단하지 않고도 실행 기록과 완전히 동기화된 상태를 유지할 수 있습니다.
Spanner 큐가 자율 에이전트에 필수적인 이유
트랜잭션 기반의 에이전트 '정확히 한 번' 실행: 에이전트가 도구 호출 결과를 평가할 때 상태 수정, 추론 결과의 지속성 유지, 다운스트림 도구 호출 작업이 하나의 트랜잭션 내에 통합되어 저장됩니다. Google은 적어도 한 번의 전송과 최대 한 번의 ACK를 보장하므로 정확히 한 번 처리를 실현할 수 있습니다.
강력한 멀티 에이전트 조정 및 핸드오프: 멀티 에이전트 시스템(A2A)에서는, 기본 에이전트에서 전문 에이전트로의 상태 핸드오프가 내구성 있고 트랜잭션 방식으로 커밋된 메시지로 표현됩니다. 전문 에이전트 작업자는 에이전트 상호작용의 완전히 감사 가능한 계보를 유지하면서 결과물 메시지를 수신합니다.
기본 기능으로 제공되는 타임아웃 및 휴먼인더루프 워크플로: 에이전트 워크플로는 사람의 승인이나 예약된 후속 조치를 위해 일시중지해야 하는 경우가 많습니다. Spanner 큐는 타임아웃 관리를 기본적으로 처리합니다. 단일 트랜잭션이 대기 중인 승인 상태를 기록하고 자동 에스컬레이션 메시지를 예약하여 먼저 트리거되는 항목을 해결합니다.
에이전트 큐를 위한 SQL 기반 모니터링 가능성: 실행 중인 에이전트 워크로드를 검사하고, 작업 백로그를 모니터링하고, 에이전트 실행 기록을 감사하는 작업을 큐 테이블에 대한 표준 SQL 쿼리로 수행할 수 있으므로 불투명한 메시지 저장소 블랙박스를 피할 수 있습니다.
에이전트 워크플로의 다음 단계
AI 에이전트 외에도 Spanner 큐는 다양한 기존 이벤트 기반 아키텍처에서 유연한 다목적 메시징 플랫폼 역할을 합니다. 소셜 애플리케이션의 실시간 활동 피드 지원, 뉴스 게시를 통한 실시간 소식 제공, 리테일 업종의 주문 처리 및 인벤토리 워크플로 조정, 금융 서비스의 높은 처리량의 비동기 작업 처리 및 트랜잭션 알림 처리 등 어떤 경우든 Spanner 큐는 기본 데이터베이스 내에서 비동기 메시지 전송 및 트랜잭션 이벤트 기반 워크플로를 위한 강력한 기반을 제공합니다.
자세히 들여다보기: Spanner 큐의 트랜잭션 메커니즘
Spanner 큐는 Spanner에서 퍼스트 클래스 관계형 구조로 표현되므로 익숙한 GoogleSQL을 사용하여 큐를 정의, 검사, 관리할 수 있습니다.
1. 큐 정의 및 원자적으로 큐에 추가
에이전트가 고객 환불 승인을 결정하면, 단일 ACID 트랜잭션 내에서 Orders 테이블을 업데이트함과 동시에 OrderAgentTasks 큐로 실행 작업을 디스패치합니다.
이렇게 하면 주문 상태가 REFUND_APPROVED로 성공적으로 전환된 경우에만 EXECUTE_REFUND 작업이 존재하게 됩니다.
2. 시간 기반 예약 및 원자적 취소
관리자의 승인을 최대 72시간 동안 기다린 후 에스컬레이션하는 등 시간에 따라 달라지는 워크플로의 경우 에이전트는 시스템 DeliverTime 열을 채워 메시지 공개 상태를 지연시킵니다.
관리자가 4시간 후에 요청을 승인하면 애플리케이션은 며칠 후에 발생하는 허위 에스컬레이션 알림을 처리할 필요가 없습니다. 단일 트랜잭션에서 표준 SQL DELETE를 사용하여 주문 상태를 업데이트하고 대기 중인 에스컬레이션 작업을 취소합니다.
3. 스트리밍 방식의 소비, 임대 기간 갱신,원자적 확인
다운스트림 에이전트 작업자는 스트리밍 SQL 연결(ExecuteStreamingSql)을 통해 RECEIVE_<QueueName> 테이블 값 함수(TVF)를 사용하여 작업을 가져와 처리합니다. Spanner는 메시지 임대 기간을 자동으로 관리하며, 임대된 각 작업과 함께 고유한 SpannerLeaseToken 및 만료 타임스탬프를 반환합니다.
AI 에이전트 작업은 멀티턴 LLM 추론이나 외부 API 호출처럼 기본 임대 기간보다 오래 걸리는 작업이 포함되는 경우가 많습니다. 이럴 때 작업자는 RENEWLEASE_<QueueName> 함수를 사용하여 임대 기간을 능동적으로 연장할 수 있습니다.
에이전트가 외부 도구 실행을 완료하면(TaskId를 외부 API의 멱등성 키로 전달) 읽기-쓰기 트랜잭션을 열어 최종 상태를 기록하고 ASSERT_ROWS_MODIFIED 1로 메시지를 삭제하여 해당 메시지를 확인(ACK) 처리합니다.
ASSERT_ROWS_MODIFIED 1을 사용하면 임대 기간 만료로 인한 경합 상태로부터 시스템을 보호할 수 있습니다. 네트워크 일시중지로 인해 작업자의 실행이 지연되어 임대 기간이 만료된 경우, 다른 작업자가 이미 해당 작업을 처리하고 삭제했을 수 있습니다. 중단된 작업자가 재개되어 문을 실행하려고 하면 ASSERT_ROWS_MODIFIED 1은 큐 행이 이미 사라진 것을 감지하고 문 수준 오류를 발생시킵니다. 이 오류를 포착하고 트랜잭션을 중단하면 비활성 작업자가 최신 데이터베이스 상태를 덮어쓰지 못하게 됩니다.
Spanner 변경 내역과 Spanner 큐 비교
Spanner 변경 내역은 다운스트림 통합 및 감사를 위해 데이터베이스 데이터 변경사항(삽입, 업데이트, 삭제)을 거의 실시간으로 캡처합니다. 변경 내역과 큐 모두 애플리케이션이 데이터 변경에 반응할 수 있도록 하지만, Spanner 변경 내역은 지속적인 변경 데이터 캡처(CDC)와 다운스트림 분석 또는 스토리지로의 데이터 스트리밍을 위해 설계되었습니다. 반면 Spanner 큐는 트랜잭션 작업 조정을 위해 명시적으로 설계되었으며, 읽기-쓰기 트랜잭션 내에서 기본 메시지 임대 기간 설정, 예약된 전송, SQL 기반 가져오기, 원자적 확인을 지원합니다.
시작하기
Spanner는 엄격한 글로벌 일관성 하에 관계형, 하이브리드 검색, 그래프, 키-값 기능을 결합하여 에이전트형 데이터를 위한 통합 기반을 제공합니다. Spanner 큐는 에이전트가 단일 통합 플랫폼 내에서 데이터에 대한 추론부터 트랜잭션 작업 실행에 이르기까지 전 과정을 원활하게 전환할 수 있게 함으로써 에이전트 루프를 완성합니다. 이제 Spanner 큐를 정식 버전으로 이용하실 수 있습니다.
Spanner 90일 무료 체험판에 가입하고 공개 문서를 확인해 보세요. 지금 바로 Spanner 데이터베이스에 큐 테이블을 생성하여 복원력 있는 '정확히 한 번' 에이전트형 워크로드를 빌드할 수 있습니다.

