이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
장시간 실행되는 개인 대출 심사 Agent는 Worker 장애, 외부 도구 재시도, 며칠간의 인간 검토 대기를 견디면서 증거와 실행 상태를 보존해야 합니다. Temporal은 Workflow Event History에 Activity 결과와 제어 흐름을 기록해 다른 Worker가 완료된 작업을 재실행하지 않고 이어가며, Signal과 wait_condition으로 검토 대기를 Worker 점유 없이 유지합니다. Lakebase Postgres는 현재 상태, 증거, 메시지, 검토 결정, 재시도와 지표를 SQL로 조회할 수 있는 애플리케이션용 상태 저장소로 쓰이고, 결정론적 ID와 보호된 상태 전이로 Activity 재시도의 중복 쓰기를 막습니다. Unity Catalog 정책은 synced table을 통해 읽고, Change Data Feed를 켜면 운영 변경을 Delta 이력 테이블로 보낼 수 있지만, 실제 환경에서 기능을 활성화하고 종단 간 동작을 검증하는 작업은 남아 있습니다.
섹션별 상세
장시간 실행되는 Cloud Agent는 최초 요청을 처리한 Worker나 컨테이너보다 오래 살아남을 수 있어 완료된 작업뿐 아니라 다음 단계를 결정하는 제어 흐름까지 보존해야 합니다. 개인 대출 심사에서는 증거 수집, 정책 적용, 추천 생성 뒤 며칠간 사람의 검토를 기다릴 수 있으므로 복구, 재시도, 장기 대기, 운영 가시성, 정책 변경, 감사 이력이 함께 필요합니다. 대화 transcript만 저장하면 어떤 작업이 예약됐고 무엇을 기다리는지 복원할 수 없어 실행 재개에 필요한 상태가 빠집니다.
Temporal의 Workflow는 한 번의 Agent 실행을 위한 내구성 있는 제어 흐름이고 Activity는 모델, 도구, 데이터베이스 호출과 그 결과를 기록하는 단위입니다. Temporal은 Activity 결과, 타이머, Signal을 Event History에 저장한 뒤 새 Worker가 Workflow 코드를 재생하도록 하며, 이미 기록된 결과는 외부 호출 없이 반환합니다. 예시에서는 모델 호출 Activity가 최대 4회, 도구 호출 Activity가 최대 3회, Lakebase Activity가 최대 5회 시도되며 각각 3분, 60초, 15초의 시간 제한을 둡니다.
Temporal의 Event History와 Lakebase의 운영 상태는 서로 다른 소비자를 위해 분리됩니다. Event History는 replay와 실행 의미를 보존하고, Lakebase Postgres는 현재 run 상태, 메시지, 증거, 검토 상태, 도구 결과와 지표를 정규화된 테이블로 제공해 FastAPI와 UI가 SQL로 조회하게 합니다. 두 시스템은 하나의 트랜잭션을 공유하지 않으므로 Activity 재시도에 맞춰 결정론적 ID, 고유 제약, upsert, 보호된 상태 전이를 함께 사용해야 합니다.
Lakebase 쓰기는 Worker가 Activity 완료를 보고하기 전에 커밋될 수 있어 같은 Activity가 재시도되면 동일한 논리 쓰기가 다시 도착할 수 있습니다. run_id, message_id, tool_call_id, event_id, review_id, decision_id를 안정적인 식별자로 사용하고, terminal 상태에는 다시 started를 쓰지 못하도록 조건을 둡니다. PostgreSQL이 0개 행을 반영한 경우에도 무조건 성공으로 처리하지 말고 저장된 terminal 상태를 확인해 예상된 no-op인지 충돌인지 판별해야 합니다.
개인 대출 심사 흐름은 credit_check, income_verification, debt_to_income_calc, policy_lookup 순서로 신용 점수, 소득과 고용 증거, 부채비율, 정책별 임계값을 수집합니다. 경계 사례의 값은 신용 점수 665, 검증된 연소득 76,000달러, 월 부채 2,400달러, 비중요 연체 플래그 하나이며, 정책 결과에는 규칙, 임계값, 실제 값, 통과 여부, 출처, 추천 근거가 함께 남습니다. 모델은 추천만 만들고 승인·거절·추가 정보 요청은 underwriter가 Signal로 결정하므로 자동 결정과 인간 판단의 경계가 보존됩니다.
검토 대기는 Temporal Workflow가 AWAITING_REVIEW 상태에 도달한 뒤 wait_condition으로 유지되며, 이때 Worker 프로세스를 계속 점유하지 않습니다. API는 Lakebase에서 현재 review_id와 대기 상태를 먼저 확인한 뒤 Signal을 보내고, Workflow도 자체 상태를 다시 검증해 오래된 브라우저 명령이나 중복 결정을 무시합니다. 승인과 거절은 run을 종료하고 추가 정보 요청은 reviewer rationale을 사용자 메시지로 저장한 뒤 새 turn과 새 review_id로 Agent 흐름을 재개합니다.
Unity Catalog의 목적별 대출 정책은 Lakebase synced table인 agent_policy.underwriting_policy_limits에서 읽으므로 정책 변경에 Worker나 API 배포가 필요하지 않습니다. policy_lookup은 동기화된 Postgres 복사본을 조회하고 적용한 임계값과 규칙 결과, 정책 출처를 운영 상태에 기록하며, 행이 없을 때 fixture_fallback을 사용할지 fail closed할지는 애플리케이션이 명시적으로 결정해야 합니다. agent_ops에 Change Data Feed를 활성화하면 삽입·수정·삭제가 lb__history 형식의 Unity Catalog 관리 Delta 이력 테이블로 전달되지만, 이 저장소는 실제 종단 간 실행을 아직 검증하지 않았습니다.
운영 환경에서는 React와 FastAPI가 실행 시작, 증거 표시, 사례 목록과 검토 결정을 담당하고 Temporal Cloud가 Event History와 Task를 관리하며 별도 Worker가 Workflow와 Activity를 실행합니다. API 복제본은 요청 부하에 따라, Worker는 Workflow와 Activity Task backlog 및 동시성 설정에 따라 확장하고 Lakebase는 프로젝트 한도 안에서 데이터베이스 컴퓨트를 자동 조정합니다. OAuth 토큰과 생성된 데이터베이스 자격 증명은 만료되므로 SQLAlchemy connection pool을 한 시간 만료 전에 갱신해야 장시간 실행 Worker의 예측 가능한 연결 장애를 피할 수 있습니다.
검증 결과에는 Workflow 순서, 검토 동작, OAuth 연결 구성, 멱등성 저장, 지표 계약, API의 Workflow 시작과 Worker 설정을 다룬 21개 통과 테스트가 포함됩니다. 별도의 crash-recovery 스크립트는 결정론적 provider를 사용해 프로세스 장애를 재현하지만 Lakebase를 비활성화한 상태에서 실행돼 Temporal 복구만 분리해 검증합니다. 따라서 실제 대출 모델, 규제 준수, 운영 보안, 지역 가용성, 대규모 성능과 Change Data Feed의 배포 후 동작은 이 구현의 검증 범위에 들어가지 않습니다.
이미지 분석
Diagram
다이어그램은 User 또는 reviewer의 요청이 React와 FastAPI를 거쳐 Temporal Cloud와 Temporal Worker, 모델·도구 호출로 이어지는 실행 경로를 보여줍니다. Worker가 교체되면 Event History replay로 실행을 복원하고, Lakebase Postgres는 멱등성 쓰기와 SQL 조회를 통해 상태를 제공하며 Unity Catalog는 synced table로 정책을 공급하고 Change Data Feed로 이력을 받습니다. 본문의 핵심인 실행 제어, 애플리케이션용 운영 상태, governed data의 분리를 한 화면에 연결합니다.
Temporal의 실행 경로, Lakebase Postgres의 운영 상태, Unity Catalog의 정책과 이력 경로를 세 층으로 나눈 아키텍처 다이어그램입니다.
용어 해설
- 내구성 있는 실행(Durable Execution)
- — 작업을 수행하던 Worker나 컨테이너가 중단돼도 실행 이력과 완료된 작업 결과를 바탕으로 다른 Worker가 중단 지점부터 이어가는 실행 방식입니다. Temporal은 Workflow Event History에 Activity 결과와 대기 상태를 기록해 재실행 때 이미 끝난 작업을 반복하지 않도록 합니다.
- Workflow 이벤트 이력(Workflow Event History)
- — Workflow에서 Activity 실행, 결과, 타이머, Signal 같은 제어 흐름 이벤트를 순서대로 기록하는 저장 구조입니다. 새 Worker는 이 기록을 재생해 현재 turn, 수집한 증거, 대기 중인 검토 상태를 복원하며, 기록된 Activity 결과는 외부 호출 없이 재사용합니다.
- 멱등성(Idempotency)
- — 같은 요청이 여러 번 실행돼도 동일한 논리 레코드와 최종 상태만 남도록 만드는 성질입니다. 이 구현은 결정론적 ID, PostgreSQL 기본 키와 고유 제약, 상태 전이 조건을 결합해 Worker 장애 뒤 재시도되는 Lakebase 쓰기가 중복 부작용을 만들지 않게 합니다.
- 변경 데이터 피드(Change Data Feed)
- — 데이터베이스의 삽입, 수정, 삭제 변화를 추적해 다른 저장소로 전달하는 기능입니다. Lakebase에서는 PostgreSQL 쓰기 전 로그의 변경을 배치로 수집해 Unity Catalog가 관리하는 Delta 이력 테이블에 기록하며, 이 글의 구현에서는 약 15초 주기로 반영되는 Public Preview 기능으로 다뤄집니다.
- 동기화 테이블(Synced Table)
- — Unity Catalog의 원본 테이블을 Lakebase Postgres에서 조회할 수 있도록 복제·동기화한 테이블입니다. Underwriting 정책의 목적별 임계값을 읽기 전용 Postgres 테이블로 제공하므로 Worker나 API를 배포하지 않고도 이후 실행에서 변경된 정책을 읽을 수 있습니다.
기술
- Temporal
- Lakebase Postgres
- Unity Catalog
- FastAPI
- React
- PostgreSQL
- Temporal Cloud
- SQLAlchemy
- Kubernetes
- Delta
- Change Data Feed
활용 사례
- 개인 대출 심사 Agent
- 며칠간 인간 검토를 기다리는 장기 실행 Agent
- Worker 장애 뒤 실행 복구
- 정책 변경을 반영하는 governed Agent
- 운영 상태와 감사 이력을 함께 관리하는 Agent 시스템
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 09. 09.수집 2026. 09. 09.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
