Databricks가 Temporal과 Lakebase로 내구성 있는 에이전트를 구축하는 방법을 보여주지만, 데모는 어려운 부분을 드러낸다

Databricks는 9월 8일, 워커 충돌, 재시도, 며칠에 걸친 검토 상황에서도 Temporal과 Lakebase로 내구성 있는 에이전트를 구축하는 방법을 보여주는 레퍼런스 구현을 공개했다. 이 시스템은 완료된 검사 하나를 잃는 것만으로도 의사결정 이력이 손상될 수 있는 개인 대출 심사에 이 아키텍처를 적용한다.

중요한 변화는 또 하나의 에이전트 프레임워크나 더 큰 모델이 아니다. Databricks와 Temporal은 서로 다른 책임을 맡는 두 시스템에 에이전트 상태를 나눠 배치했다. Temporal은 제어 흐름을 보존하고, Lakebase는 애플리케이션, 검토자, 분석가가 질의할 수 있는 운영 데이터를 제공한다.

이 분리는 동시에 핵심적인 긴장도 만든다. 내구성 있는 실행은 기록된 작업을 복구할 수 있지만, 모든 외부 효과를 정확히 한 번만 발생시키지는 못한다. 애플리케이션에는 여전히 안정적인 식별자, 보호된 데이터베이스 쓰기, 정책 버전 규칙, 그리고 구성 요소 간 불일치가 발생했을 때의 조정이 필요하다.

Databricks, 에이전트 내구성을 검증 가능한 시스템으로 전환

이 레퍼런스 구현은 에이전트를 일시적인 채팅 세션이 아니라 장기 실행 비즈니스 프로세스로 다룬다.

레퍼런스 구현은 증거 수집부터 사람의 최종 결정까지 대출 요청을 따라간다. 에이전트는 신용, 소득, 총부채상환비율, 대출 심사 정책 검사를 각각 별도 작업으로 수행한다.

이 예제는 모의 신청자와 제공업체를 사용하므로 실제 대출 신청을 처리하지 않는다. 이 선택은 대출 모델 성능이 아닌 실행 동작에 실험의 초점을 맞춘다.

한 샘플 신청자의 신용 점수는 665점이며, 중대하지 않은 연체 플래그가 하나 있다. 에이전트는 증거를 수집하고 용도별 정책 임계값을 평가한 뒤 추천안을 생성한다. 하지만 최종 대출 결정을 내릴 수는 없다.

심사 담당자는 승인, 거절 또는 추가 정보 요청을 해야 한다. 마지막 선택지는 이전 증거와 검토자 근거를 보존한 채 동일한 사례를 또 다른 에이전트 턴으로 확장한다.

이 시나리오는 단일 모델 요청보다 의도적으로 더 어렵게 설계됐다. 여러 검사가 끝난 뒤 워커가 중단될 수 있다. 완료 사실이 Temporal에 전달되기 전에 데이터베이스 쓰기가 커밋될 수 있다. 검토자가 며칠 동안 사례를 열어 둘 수도 있다.

오래된 브라우저가 사례가 진행된 뒤에도 구버전 명령을 제출할 수 있다. 그 사이 대출 심사 정책은 애플리케이션 배포 없이 변경될 수 있다.

이런 상황은 복구, 통제된 재시도, 내구성 있는 대기, 운영 가시성, 런타임 거버넌스, 감사 이력이라는 여섯 가지 실무 요건을 만든다. 대화 기록만으로는 이를 충족할 수 없다.

대화 기록은 메시지를 남기지만, 반드시 완전한 제어 흐름을 기록하지는 않는다. 어떤 작업이 완료됐는지, 어떤 결과가 수용됐는지, 어떤 명령이 프로세스를 진행시켰는지를 자동으로 보여주지 않는다.

따라서 구현은 각 대출 실행에 Temporal Workflow를 부여한다. Workflow는 기록된 이력을 통해 다른 워커가 상태를 재구성할 수 있게 하는 내구성 있는 제어 흐름이다.

모델, 데이터베이스, 대출 심사 도구 호출은 Activities로 실행된다. Activity는 결과를 Workflow의 Event History에 기록할 수 있는 재시도 가능한 작업이다.

검토자 응답은 열려 있는 Workflow에 전달되는 비동기 명령인 Signals로 도착한다. Temporal은 며칠 동안 워커 프로세스를 점유하지 않고도 이 대기를 유지할 수 있다.

React와 FastAPI는 사용자 대면 애플리케이션을 처리한다. 실행을 시작하고, 증거를 표시하고, 사례를 나열하며, 검토 결정을 제출한다. Temporal Cloud는 실행 이력을 저장하고 워커에 작업을 배정한다.

Lakebase Postgres는 애플리케이션 대면 프로젝션을 보관한다. 프로젝션은 실행 중 생성된 업데이트를 기반으로 구축된 현재 워크플로 상태의 질의 가능한 표현이다.

Unity Catalog는 대출 심사 규칙의 소스로 남는다. 연속 동기화 테이블은 해당 규칙을 Lakebase를 통해 사용할 수 있게 하므로, 워커는 코드 배포 없이 업데이트된 정책을 읽을 수 있다.

이 아키텍처는 에이전트의 실패 동작을 가시화하고 재현 가능하게 만든다. 내구성을 일반적인 약속에서 구체적인 복구 및 일관성 계약의 집합으로 전환한다.

하지만 데모는 이러한 계약을 하나의 데이터베이스로 통합하지 않는다. Temporal과 Lakebase는 별도 시스템으로 유지되며, 그 사이의 간극이 더 어려운 엔지니어링 질문을 낳는다.

에이전트 메모리는 실행 상태가 아니다

내구성 있는 에이전트에는 저장된 메시지나 검색된 메모리뿐 아니라 제어 흐름에 관한 기록된 결정이 필요하다.

많은 에이전트 시스템은 영속성을 메모리로 설명한다. 대화를 저장하거나, 이전 문서를 검색하거나, 중간 결과를 데이터베이스에 넣는다. 이러한 기능은 모델이 맥락을 복구하도록 돕지만 실행을 재구성하지는 못한다.

가령 워커가 신용 검사를 마친 뒤 종료된다고 가정해 보자. 대체 워커는 결과가 기록됐는지, 다른 시도가 안전한지, 다음에 어떤 작업을 실행해야 하는지를 판단해야 한다.

이는 제어 흐름 문제다. 여기에는 예약된 Activities, 완료된 결과, 타이머, 수용된 사람의 명령, 재시도 횟수, 현재 검토 라운드가 포함된다.

Temporal은 이 정보를 순서가 있는 Event History에 저장한다. 리플레이 중 워크플로 코드는 기록된 이벤트를 소비하고 증거, 토큰 사용량, 검토 상태와 같은 변수를 재구축한다.

기록된 Activity 결과는 다시 실행되는 대신 리플레이 중 반환된다. 따라서 완료된 신용 검사나 기록된 모델 응답은 해당 워크플로 실행 동안 고정된 상태로 유지된다.

기록되지 않은 완료는 다른 경우를 제시한다. 모델 제공업체가 워커의 연결이 끊기기 직전에 요청 처리를 마칠 수 있다. Temporal이 결과를 받지 못하면 다른 시도를 예약할 수 있다.

이 제한은 모델 호출이 부작용에서 자유롭지 않고 결정적 결과를 보장하지도 않기 때문에 중요하다. 입력이 동일하더라도 두 번째 응답은 첫 번째와 달라질 수 있다.

이 데모는 개별 작업 유형에 재시도 정책을 할당한다. 모델 Activities는 3분의 schedule-to-close 기간 안에 최대 네 번의 시도를 허용한다.

도구 Activities는 60초 start-to-close 제한 시간으로 최대 세 번의 시도를 허용한다. Lakebase Activities는 15초 start-to-close 제한 시간으로 최대 다섯 번의 시도를 허용한다.

이 수치는 보편적인 프로덕션 기본값이 아니라 예제 구성에 대한 설명이다. 팀은 제공업체 동작, 지연 시간 목표, 실패 모드, 다운스트림 영향에 따라 재시도 한도를 설정해야 한다.

Temporal의 내구성 있는 실행 모델은 리플레이에 필요한 이력을 보존해 프로세스 복구를 처리한다. 하지만 결제, 이메일, 데이터베이스 변경, 모델 요청을 자동으로 반복해도 안전하게 만들지는 않는다.

각 외부 작업에는 멱등성 계약이 필요하다. 멱등성이란 반복 시도가 중복 효과를 만들어 내는 대신 하나의 의도된 결과로 수렴한다는 뜻이다.

대출 데모는 결정론적 식별자로 이 계약을 구성한다. 실행, 메시지, 도구 호출, 이벤트, 검토 라운드, 검토자 결정에는 각각 안정적인 식별자가 부여된다.

Postgres 기본 키와 고유 제약 조건은 재시도가 무제한 사본을 만들지 못하도록 막는다. Upsert는 반복 시도가 동일한 논리적 행을 대상으로 하게 한다.

보호된 업데이트는 한 단계 더 추가한다. 예를 들어 대기 중인 도구 호출을 종료된 레코드를 다시 열지 않고 완료 상태로 옮기는 것처럼, 유효한 상태 전이만 허용한다.

하지만 보호된 업데이트조차 신중한 해석이 필요하다. PostgreSQL은 대상이 이미 종료 상태에 도달한 경우 오류를 발생시키지 않고도 0개 행에 영향을 줄 수 있다.

Databricks 글은 현재의 Activity 래퍼가 이 0행 결과를 항상 실패로 처리하지는 않는다고 인정한다. 프로덕션 코드는 이를 무해한 것으로 간주하기 전에 저장된 상태를 검사해야 한다.

이 세부 사항은 유용한 엔지니어링 레퍼런스와 완성된 프로덕션 패턴을 구분한다. 내구성 있는 오케스트레이션은 복구 메커니즘을 제공하지만, 애플리케이션 개발자는 여전히 안전한 비즈니스 의미론을 정의해야 한다.

동일한 원칙은 대출 심사 외에도 적용된다. 결제 제공업체에는 멱등성 키가 필요하고, 이메일 시스템에는 안정적인 메시지 식별자가 필요하며, 지원되지 않는 도구에는 조정 레코드가 필요하다.

내부 에이전트를 구축하는 팀에는 검색 가능한 증거 계층도 필요하다. 구조화된 엔지니어링 지식 베이스는 사람들이 이러한 워크플로 주변의 문서, 결정, 기술적 맥락을 검토하는 데 도움이 될 수 있다.

더 큰 교훈은 명확하다. 메모리는 모델이 기억하도록 돕고, 내구성 있는 실행은 시스템이 계속 작동하도록 돕는다. 프로덕션 에이전트에는 대개 둘 다 필요하지만, 이 둘은 서로 대체할 수 없다.

책임 분리를 통해 Temporal과 Lakebase로 내구성 있는 에이전트 구축

이 설계가 작동하는 이유는 Temporal과 Lakebase가 서로 다른 소비자를 위해 서로 다른 종류의 진실을 보유하기 때문이다.

Temporal은 실행의 진실을 소유한다. 그 이력은 어떤 작업이 완료됐는지, 어떤 타이머가 실행됐는지, 어떤 Signals가 도착했는지, 리플레이하는 워커가 다음에 무엇을 해야 하는지를 결정한다.

Lakebase는 현재 애플리케이션 뷰를 소유한다. 관계형 테이블에 실행 상태, 메시지, 도구 증거, 검토 기록, 운영 이벤트, 추천 메타데이터, 재시도 지표를 저장한다.

이 분리를 통해 사용자 인터페이스는 일반적인 SQL 패턴으로 현재 사례를 질의할 수 있다. 검토자는 대기 중인 사례를 찾고, 하나의 추천안을 검토하거나, 실행 전반의 운영 측정값을 비교할 수 있다.

증거는 Workflow가 종료되기 전에 나타난다. 정책 조회가 끝나면 구조화된 결과는 임계값, 실제 값, 규칙 결과, 근거, 정책 소스와 함께 사용할 수 있게 된다.

이는 사람이 검토하는 시스템에서 중요하다. 검토자는 추천안의 근거가 되는 증거를 보기 위해 전체 프로세스가 끝날 때까지 기다려서는 안 된다.

애플리케이션은 두 개의 Lakebase 스키마를 사용한다. agent_ops 스키마는 운영 레코드를 보관하고, agent_policy는 거버넌스가 적용된 대출 심사 정책의 읽기 전용 사본을 포함한다.

모든 Activity는 Workflow와 정렬된 식별자를 사용해 행을 쓴다. 따라서 데이터베이스 프로젝션이 따라잡는 동안 재시도는 동일한 논리적 레코드를 업데이트할 수 있다.

Lakebase는 Temporal 리플레이의 일부가 되지 않는다. 이 경계는 일반 애플리케이션 쿼리가 워크플로 실행을 결정하지 못하게 하지만, 동시에 두 시스템 전반에서 업데이트가 원자적이지 않음을 의미한다.

Lakebase 프로젝션이 일시적으로 뒤처진 상태에서도 Temporal 이벤트는 기록될 수 있다. 데이터베이스 쓰기가 Temporal이 해당 Activity 완료를 기록하기 전에 커밋될 수도 있다.

이 아키텍처는 이 간극을 수용하고 최종 일관성을 사용한다. 최종 일관성이란 별도 뷰가 잠시 불일치할 수 있지만 재시도와 결정론적 쓰기를 통해 수렴한다는 뜻이다.

이는 대시보드와 사례 목록에는 합리적인 설계다. 데이터베이스 뷰를 비즈니스 상태에 영향을 주는 명령 검증에 사용할 때는 더 큰 주의가 필요하다.

Lakebase는 익숙한 Postgres 액세스와 애플리케이션 지향 인덱싱을 제공한다. 운영 데이터베이스 모델은 에이전트 메모리, 현재 상태, 피처 서빙 워크로드도 지원한다.

컴퓨팅은 구성된 한도 내에서 자동 확장할 수 있다. Scale-to-zero는 유휴 컴퓨팅을 중지할 수 있지만, 비활성 상태 이후 첫 번째 쿼리에는 활성화 지연 시간이 발생할 수 있다.

이러한 데이터베이스 기능은 불규칙한 에이전트 트래픽에 도움이 된다. 하지만 용량 계획, 연결 한도, 풀 구성, 복구 테스트의 필요성을 없애지는 않는다.

정책 경로도 그에 못지않게 중요하다. Unity Catalog는 신용 및 총부채상환비율 규칙을 포함한 목적별 임계값을 저장한다. 지속적으로 동기화되는 테이블은 이러한 값을 Lakebase 내에서 제공한다.

정책 소유자는 worker나 API를 재배포하지 않고도 소스를 업데이트할 수 있다. 이후 조회에서는 Postgres에서 전파된 규칙을 읽을 수 있다.

이 방식은 모든 비즈니스 임계값을 애플리케이션 코드에 하드코딩하는 일을 피한다. 동시에 오케스트레이션 계층이 명시적으로 답해야 할 정책 적용 시점의 문제도 제기한다.

진행 중인 케이스는 시작 시점에 적용된 규칙을 유지해야 할까, 아니면 이후 턴에서 더 최신의 정책을 채택해야 할까? 어느 선택이든 일관성, 감사 가능성, 고객 처리 방식에 영향을 미친다.

데모는 권고안과 함께 적용된 임계값과 출처를 기록한다. 이 증거를 통해 검토자는 특정 결과에 어떤 정책이 반영되었는지 재구성할 수 있다.

Lakebase를 사용할 수 없을 때 샘플은 fixture 정책을 사용하고 그 대체 경로를 기록할 수 있다. 이 글은 규제 대상 워크플로라면 대신 fail closed를 선택할 수도 있다고 적절히 지적한다.

이 선택을 재시도 라이브러리에 맡길 수는 없다. 오래된 정책이나 대체 정책이 법적·운영상 허용 가능한지 여부는 제품 책임자, 컴플라이언스 팀, 엔지니어가 정의해야 한다.

제안된 반환 경로는 Lakebase Change Data Feed를 사용한다. 활성화되면 데이터베이스 변경을 캡처해 Unity Catalog가 관리하는 Delta 히스토리 테이블에 게시할 수 있다.

Databricks는 이 피드가 약 15초마다 변경 사항을 배치 처리한다고 설명한다. 이 간격은 사후 감사와 분석에 적합하며, 애플리케이션은 Lakebase에서 현재 상태를 직접 읽는다.

다만 리포지토리는 이 경로를 위한 스키마만 준비한다. 대상 환경에서 관찰된 엔드투엔드 피드 실행 결과는 포함하지 않는다.

따라서 Temporal과 Lakebase로 내구성 있는 에이전트를 구축하려면 실행의 진실, 운영의 진실, 거버넌스가 적용된 분석 이력이라는 세 가지 경계를 명확히 해야 한다.

이 패턴은 이러한 경계가 명시적일 때 가치가 있다. 팀이 “durable”이라는 말이 모든 구성 요소가 언제나 일치한다는 뜻이라고 가정할 때는 위험해진다.

인간 검토가 일관성의 트레이드오프를 드러낸다

언더라이터 대기는 내구성에 명령 식별성, 오래된 상태의 거부, 독립적인 Workflow 검증이 포함되어야 하는 이유를 보여준다.

모델이 권고안을 생성한 뒤 Workflow는 실행과 현재 턴을 기반으로 검토 식별자를 만든다. 보류 중인 검토를 Lakebase에 기록하고 AWAITING_REVIEW 상태로 진입한다.

그런 다음 Temporal은 worker를 점유하지 않은 채 조건을 기다린다. 사람이 응답하는 데 시간이 걸리는 동안에도 열린 Workflow는 프로세스 교체를 견딜 수 있다.

API는 승인, 거절 또는 추가 정보 요청을 받는다. 먼저 Lakebase에 관련 검토가 여전히 보류 상태로 표시되는지 확인한다.

또한 제출된 검토 식별자를 현재 검토 라운드와 비교한다. 일치하지 않으면 명백히 오래된 결정을 전달하는 대신 충돌을 발생시킨다.

이 데이터베이스 사전 검사는 사용자 경험을 개선하지만, 권위 있는 판단 기준은 아니다. 특히 Activity가 재시도되는 동안 Lakebase 프로젝션은 Temporal보다 지연될 수 있다.

따라서 API는 명령을 Signal로 전송하고, Workflow는 이를 실행 상태와 다시 대조해 검증한다. 중복되거나 오래된 결정은 내구성 있는 제어 흐름 내부에서 무시된다.

이 두 번째 검사는 필수적이다. 다른 검토자가 케이스를 진행하는 동안 브라우저 탭이 열려 있을 수 있고, 새 검토 라운드가 시작된 뒤 이전 요청이 도착할 수도 있다.

HTTP 202 응답은 Temporal이 Signal을 수신했음을 확인할 뿐이다. Workflow가 비즈니스 결정을 수락했다는 의미는 아니다.

클라이언트는 결과 상태를 확인하기 위해 Lakebase 뷰를 새로고침해야 한다. 이 구분은 전송 확인이 대출 승인으로 오인되는 일을 방지한다.

Workflow가 결정을 수락하면 멱등성을 갖춘 Lakebase Activity가 이를 영속화한다. 승인 또는 거절은 실행을 완료한다.

추가 정보 요청은 실행을 재개한다. 검토자의 근거는 새 사용자 메시지가 되고, 턴이 진행되며, 다음 권고안에는 새 검토 식별자가 부여된다.

이 메커니즘은 모든 검토 라운드에 안정적인 경계를 제공한다. 동시에 핵심 트레이드오프도 분명히 드러낸다. 반응성 높은 애플리케이션 상태는 권위 있는 실행 상태와 별개다.

팀은 일시적인 불일치를 전제로 설계해야 한다. 인터페이스는 보류 중인 명령, 충돌, 지연된 프로젝션, 거부된 오래된 작업을 명확히 알려야 한다.

운영 대시보드 역시 의도적인 대기와 장애를 구분해야 한다. 언더라이터를 기다리는 케이스는 정상인 반면, 재시도에 멈춰 있는 Activity는 개입이 필요하다.

데모는 Workflow, 턴, Activity 시도 수준의 메트릭을 노출한다. 운영자는 Temporal 이력을 검사하고, Lakebase 상태를 조회하며, worker 환경을 별도로 확인할 수 있다.

이 분리는 지연이 인간 검토, 모델 가용성, 데이터베이스 인증 또는 실패한 도구 중 어디에서 비롯되었는지 진단하는 데 도움이 된다.

동시에 운영 관리 영역도 넓어진다. 팀은 Temporal, Lakebase, worker 배포, 연결 풀, 동기화 작업, 그리고 이들을 연결하는 계약을 모니터링해야 한다.

인증은 또 다른 장기 실행 관련 과제를 제기한다. Lakebase 클라이언트는 머신 간 OAuth를 사용하며, 임시 데이터베이스 자격 증명이 만료되기 전에 연결 풀을 갱신한다.

자격 증명을 순환 갱신하지 않으면 Workflow가 복구 가능하게 유지되더라도 worker는 예측 가능한 주기에 실패할 수 있다. 내구성 있는 제어 흐름이 만료된 연결을 사용할 수 있게 하지는 않는다.

따라서 내구성 있는 에이전트 프레임워크를 비교하는 개발자는 체크포인트 지원을 넘어 살펴봐야 한다. 명령이 어떻게 식별되는지, 부수 효과가 어떻게 중복 제거되는지, 권위 있는 상태가 어디에 존재하는지를 물어야 한다.

오래된 상호작용도 의도적으로 테스트해야 한다. 두 개의 검토 세션을 열고 하나를 진행한 다음, 이전 결정을 제출해 본다.

올바른 구현이라면 해당 명령을 거부하거나 안전하게 무시해야 한다. 또한 이후 결과를 설명할 수 있을 만큼의 증거를 보존해야 한다.

대출 사례가 유용한 이유는 이런 세부 사항을 중대한 의사결정과 연결하기 때문이다. 인간의 승인은 모델 호출 사이에 놓인 장식적인 일시 정지가 아니다.

이는 식별성, 권한 부여, 정책 맥락, 감사 요건을 갖춘 상태 전환이다. 따라서 오류 후 재시작하는 대화형 어시스턴트보다 더 엄격한 내구성 테스트가 된다.

데모가 프로덕션 준비 상태를 입증하지는 않는다

Databricks는 신뢰할 만한 아키텍처를 제시하지만, 자체 증거만으로는 대출 컴플라이언스, 규모, 완전한 데이터 루프 검증이 여전히 해결되지 않았다.

리포지토리는 Workflow 순서, 검토 동작, OAuth 구성, 멱등적 영속화, 메트릭 계약, API 시작, worker 설정을 다루는 21개의 통과 테스트를 보고한다.

장애 복구 실험은 결정론적 provider를 사용한다. worker 실행을 중지하고 프로세스가 복귀한 후 기록된 진행 상황이 유지되는지 확인한다.

이 테스트들은 제한적인 내구성 주장을 뒷받침한다. 선택된 장애 상황에서 예제의 제어 흐름과 영속화 계약이 의도대로 동작함을 보여준다.

하지만 에이전트가 대출 시스템으로서 유효하다는 점을 검증하지는 않는다. 신청자 기록과 provider 응답은 fixture이며, 기본 스크립트 provider는 라이브 모델 의존성을 피한다.

리포지토리는 대출 모델의 품질, 규제 준수, 프로덕션 보안, 지역별 가용성 또는 대규모 성능을 입증하지 않는다. Databricks도 이러한 한계를 직접 밝힌다.

로컬 장애 실험 역시 Lakebase를 비활성화한 상태에서 실행되었다. 이는 Temporal 복구를 분리해 검증하지만, 완전히 통합된 데이터 경로 전반의 복구를 확인하지는 않는다.

마찬가지로 Change Data Feed 경로는 여전히 활성화 및 배포 과제에 머물러 있다. 예제는 테이블을 준비하지만, 이력이 엔드투엔드로 도착하는 관찰 결과는 제시하지 않는다.

이 글이 게시되었을 당시 Change Data Feed는 Public Preview 상태였다. 성숙한 지원 약정이나 검증된 지역별 지원 범위를 요구하는 팀에는 Preview 상태가 중요하다.

데이터베이스와 Workflow는 트랜잭션을 공유하지 않는다. 안정적인 식별자와 재시도는 수렴을 제공하지만, 장기적이거나 예기치 않은 불일치에 대해서는 여전히 조정이 필요하다.

프로덕션 조정 프로세스는 일치하는 프로젝션이 없는 Workflow를 찾아야 한다. 또한 Activity 결과가 Event History에 기록되지 않은 채 커밋된 데이터베이스 효과도 탐지해야 한다.

정책 동기화 역시 같은 수준의 검토가 필요하다. 이후 실행은 배포 없이 업데이트된 정책을 사용할 수 있지만, 진행 중인 실행에는 문서화된 정책 버전 규칙이 필요하다.

대체 동작은 또 다른 위험을 만든다. 데모는 Lakebase가 비활성화되었거나 정책 행을 사용할 수 없을 때 fixture 정책으로 대체할 수 있다.

이 동작은 로컬 개발에는 도움이 되지만, 조용한 대체는 많은 규제 환경에서 허용될 수 없다. 시스템은 대체를 기록하지만, 실행을 계속할지 여부는 정책 소유자가 결정해야 한다.

공개된 증거에서는 성능이 아직 테스트되지 않았다. 에이전트 워크로드는 쓰기 폭주, 긴 이력, 대용량 트랜스크립트, 불균등한 검토 대기열을 만들 수 있다.

Temporal 이력 보존 기간, 재시도 규모, 모델 지연 시간, worker 동시성, 데이터베이스 연결 제한, 프로젝션 업데이트는 모두 시스템 동작에 영향을 미친다.

Lakebase 자동 확장은 수요에 대응할 수 있지만, 새 연결과 워밍업된 데이터 역시 중요하다. scale-to-zero는 유휴 상태 효율성과 기동 지연 시간 사이의 트레이드오프를 만들 수도 있다.

보안 요건은 TLS와 임시 자격 증명을 넘어선다. 실제 언더라이팅 플랫폼에는 엄격한 권한 부여, 민감 데이터 통제, 보존 규칙, 감사 접근 경계가 필요하다.

모델의 권고안에도 독립적인 거버넌스가 필요하다. 증거와 정책을 기록하면 추적 가능성은 개선되지만, 권고안의 공정성이나 정확성이 입증되는 것은 아니다.

완전한 평가는 불리한 조치의 근거, 누락된 증거, 상충하는 provider 데이터, 정책 변경, 도구 입력 조작 시도를 테스트해야 한다.

또한 구성 요소 경계를 넘나드는 운영 사고도 테스트해야 한다. 예로는 정책 동기화 불가, 지연된 프로젝션, 부분적인 자격 증명 순환 갱신, 사용 불가능한 외부 provider가 있다.

따라서 이 아키텍처는 프로덕션 형태를 갖춘 것으로 읽어야지, 프로덕션 인증을 받은 것으로 해석해서는 안 된다. 이러한 구분은 남은 작업을 가시화한다는 점에서 레퍼런스를 강화한다.

Databricks는 오케스트레이션, 운영 스토리지, 거버넌스가 적용된 데이터 사이에 책임을 배분하는 방법을 보여주었다. 그러나 실제 부하 환경에서 모든 계약을 검증해야 할 필요성을 없애지는 않았다.

이 패턴이 유지되는지 보여줄 세 가지 신호

다음 증거는 통합 복구, 정책 일관성, 그리고 통제된 언더라이팅 데모를 넘어선 도입을 검증해야 한다.

첫 번째 신호는 관찰된 엔드투엔드 Change Data Feed 배포다. 공개된 시스템은 운영 테이블을 준비하지만, 피드 활성화와 대상 검증은 완료되지 않은 상태로 남겨 둔다.

성공적인 검증은 도구 증거에서 인간 검토를 거쳐 Unity Catalog가 관리하는 이력까지 하나의 실행을 추적해야 한다. 또한 지연, 중복, 스키마 변경, 중단 후 복구를 문서화해야 한다.

이 결과는 운영 활동이 거버넌스가 적용된 분석 이력으로 돌아갈 수 있다는 주장을 강화할 것이다. 검증되지 않은 경로에 계속 의존한다면 완전한 데이터 루프라는 이야기는 약해질 것이다.

두 번째 신호는 복구 테스트 전반에 Lakebase를 사용한 공개 부하 및 장애 연구다. 여기에는 worker 장애, 데이터베이스 재시도, 자격 증명 순환 갱신, 프로젝션 지연이 포함되어야 한다.

유용한 결과는 완료 동작, 재시도 분포, 오래된 명령 거부, 애플리케이션 상태가 수렴하는 데 걸리는 시간을 보고할 것이다.

이는 Temporal 복구를 분리해서 검증하는 대신, 아키텍처를 결합된 시스템으로 테스트하게 된다. 또한 확장 한계나 운영 병목이 어디에서 나타나는지도 드러낼 것이다.

세 번째 신호는 실제 인간 검토 워크플로에서의 도입이다. 대출은 단지 데모일 뿐이지만, 유사한 요건은 보험금 청구 처리, 조달, 보안 대응, 규제 대상 승인에서 나타난다.

신뢰할 수 있는 배포라면 정책 버전 관리 방식, 상태 조정 방식, 폴백 동작 제어 방식, 그리고 사람의 개입을 감사하는 방식을 설명할 수 있어야 합니다. 이러한 관행은 특정 모델 제공업체보다 더 중요합니다.

이러한 배포에서 나온 증거는 이 글의 핵심 판단을 뒷받침할 것입니다. 내구성 있는 에이전트는 실패를 명시적으로 모델링해야 하는 분산 애플리케이션입니다.

내구성을 대화 체크포인트로 축소하는 배포는 정반대의 결론을 시사합니다. 그렇게 하면 부수 효과, 긴 대기 시간, 그리고 변화하는 정책이 복구 계약의 범위 밖에 남게 됩니다.

개발자에게 당면한 질문은 모든 에이전트에 Temporal과 Lakebase가 필요한지 여부가 아닙니다. 짧고 읽기 전용인 많은 작업은 두 개의 관리형 시스템과 프로젝션 계층을 정당화하지 못합니다.

질문은 에이전트가 워커보다 오래 살아남을 수 있는지, 외부 상태를 변경할 수 있는지, 사람을 기다릴 수 있는지, 또는 독립적으로 변경되는 정책을 적용할 수 있는지입니다. 이러한 특성은 내구성 있는 실행의 필요성을 만듭니다.

이러한 특성이 여러분의 시스템을 설명한다면, agent architecture를 검토하고, 크래시 테스트를 재현하며, 재시도 가능한 모든 부수 효과를 면밀히 검증하세요. 그런 다음 실행의 진실과 운영의 진실이 일시적으로 일치하지 않을 때 어떤 일이 발생하는지 테스트하세요.

이는 Temporal과 Lakebase로 내구성 있는 에이전트를 구축하려는 팀을 위한 실질적인 기준입니다. 하나의 중요한 워크플로부터 시작하고, 각 시스템의 권한을 정의하며, 복구 증거를 제품 검토의 일부로 만드세요.