AI Agent 상태 관리: 작업 진행과 실제 산출물을 어떻게 일치시킬까

AI 깊이 이해하기 · 13편 | 작업 상태, 영속화, 불변 조건

보고서 파일은 만들어졌는데 작업 목록은 아직 “진행 중”이다. 다시 실행하면 같은 보고서를 하나 더 만들 수 있다. 반대로 작업 목록에는 “완료”라고 적혔는데 파일이 없으면, 사용자는 결과를 받지 못한다. Agent의 작업 상태를 문장으로만 관리하면 이런 어긋남을 발견하기 어렵다.

이번 편은 공개 문서 변경 보고 Agent의 교육용 설계다. 실제 운영 시스템의 장애 기록이 아니다. 12편에서 확보한 읽기 증거를 출발점으로, 어떤 관측과 산출물이 있어야 작업 상태를 바꿀 수 있는지 정한다. 범위는 원문을 읽고 로컬 보고서를 만드는 작업이다. 외부 전송이나 원문 수정은 포함하지 않는다.

1. 세 가지 상태를 따로 놓기

상태의 종류	예시	판정의 근거
외부 문서 상태	문서 A의 v8	문서 읽기 응답과 관측 메타데이터
작업 진행 상태	입력 확보, 작성, 검증, 완료	허용된 전이와 저장된 작업 기록
산출물 상태	report-001 파일과 그 내용	실제 저장 결과, 다시 읽은 파일, 내용 해시

진행 상태 하나로 원문과 산출물의 상태를 대신하지 않는다.

Context는 모델이 다음 답변을 만들 때 보는 입력이다. 작업 상태는 재시작 뒤에도 어떤 단계까지 검증됐는지 판단하는 기록이다. “보고서를 작성했다”는 대화 문장을 Context에 넣었다고 해서 해당 파일의 존재나 일치 여부가 검증되지는 않는다. 기록과 외부 효과 사이에는 확인 단계가 필요하다.

2. 상태 이름보다 전이 조건이 중요하다

상태 머신(state machine)은 현재 상태와 입력 조건에 따라 다음 상태를 정하는 모델이다. AWS Step Functions 문서는 워크플로가 상태들로 구성되고 각 상태가 작업이나 분기 등을 표현한다고 설명한다. 아래는 그 서비스를 사용한 구현이 아니라 이 예제에 맞춰 별도로 설계한 상태 흐름이다.

NEW
  ↓ 읽기 증거 확보
OBSERVED
  ↓ 비교·보고서 후보 작성
DRAFTED
  ↓ 후보 검증
VALIDATED
  ↓ 로컬 저장 및 다시 읽기
COMPLETED

어느 단계에서든 필수 근거 부족 → BLOCKED
저장 결과를 확정할 수 없음 → RECONCILE

NEW에서 COMPLETED로 바로 바꾸는 동작은 허용하지 않는다. VALIDATED는 내용 검증을 통과했다는 뜻이고, COMPLETED는 이번 실행 계약의 산출물 저장과 재확인까지 끝났다는 뜻이다. 상태의 의미를 이렇게 정하면 “생성 함수가 반환됐다”와 “사용 가능한 결과가 남았다”를 구분할 수 있다.

RECONCILE은 실패 판정이 아니다. 저장 요청 뒤 응답을 못 받았거나, 파일 저장 후 진행 기록을 남기기 전에 프로세스가 멈춰 결과를 아직 확정할 수 없는 상태다. 여기서는 먼저 정해진 산출물 식별자로 파일을 찾아 확인한다. 상세한 재시도·중복 방지 설계는 17편에서 다룬다.

3. 완료 상태에 붙일 불변 조건

불변 조건(invariant)은 특정 상태에서 반드시 성립해야 하는 관계다. 이 예제에서는 아래 네 조건을 모두 확인한 경우에만 COMPLETED로 전이하도록 정한다. 모델이 그럴듯하게 완료를 선언하는 대신 실행 코드가 검사할 수 있는 조건을 만든다.

보고서가 참조하는 source_id와 입력 증거의 source_id가 일치한다
보고서의 input_digest가 이번 비교에 사용한 스냅샷 해시와 일치한다
report_ref가 가리키는 실제 파일을 다시 읽을 수 있고, 다시 계산한 파일 해시가 기록값과 일치한다
해당 실행의 검증 결과가 통과이며 필수 미확인 항목이 남아 있지 않다

해시는 동일한 바이트를 비교하는 도구다. 해시가 맞아도 요약이 원문을 왜곡했거나 처음부터 다른 문서를 읽었다면 내용은 틀릴 수 있다. 그래서 문서 식별자, 입력 연결, 내용 검증과 저장 확인을 분리한다. 어느 하나가 나머지를 대신하지 않는다.

4. 합성 사례: 기록은 완료, 파일은 이전 버전

문서 A의 v8을 입력으로 썼고 그 스냅샷의 해시 라벨을 H8이라고 하자. H8은 설명용 표기이며 실제 해시값이 아니다. 작업 기록에는 input_digest=H8, state=COMPLETED가 있다. 그러나 남아 있는 보고서는 v7 입력의 H7을 가리킨다.

확인 항목	기록 / 실제 산출물	판정
입력 연결	H8 / H7	불일치
파일 존재	report-001 있음	존재만 확인
완료 결론	COMPLETED라고 기록됨	근거 불충분, 재조정 필요

파일이 있다는 사실만으로 이번 입력에 대한 작업 완료를 증명할 수 없다.

이때 기존 파일을 바로 지우거나 덮어쓰는 것은 성급하다. 먼저 기록과 파일을 보존한 채 불일치 이유를 확인한다. 다른 실행의 파일인지, 잘못된 경로를 가리키는지, 이전 검증 결과를 재사용했는지 구분해야 한다. 복구할 행동은 그 확인 뒤에 정한다.

5. 영속화는 “메모를 남겼다”보다 좁고 구체적인 약속이다

프로세스 메모리에만 작업 상태를 두면 종료 후 사라질 수 있다. 영속화(persistence)는 다시 시작할 때 읽을 수 있는 저장소에 상태를 남기는 일이다. 그렇다고 저장 호출을 한 번 했다는 사실만으로 모든 장애에서 보존된다고 말할 수는 없다. 저장소의 트랜잭션과 동기화 설정, 파일시스템·장치의 보장 범위를 확인해야 한다.

SQLite의 원자적 커밋 문서는 트랜잭션의 변경 사항이 전부 반영되거나 전혀 반영되지 않는 것처럼 보이게 하는 절차와 그 전제를 설명한다. 이는 SQLite가 관리하는 데이터에 대한 설명이다. 별도의 파일에 보고서를 쓰고 SQLite 행에 완료를 기록하는 두 작업이 자동으로 하나의 트랜잭션이 되는 것은 아니다.

작은 교육용 예제에서는 보고서 본문과 상태를 같은 데이터베이스 트랜잭션 안에 저장하는 설계를 검토할 수 있다. 파일을 별도로 유지해야 한다면 파일 저장, 재읽기 확인, 상태 기록 사이에서 중단됐을 때 어떻게 대조할지 정해야 한다. 어느 쪽도 실제 실행·장애 주입 검증 없이 복구가 입증됐다고 말해서는 안 된다.

6. 다른 실행과 부딪힐 때 확인할 버전

작업 기록을 읽을 때 revision=4였는데 저장 시점에는 다른 실행이 revision=5로 바꿨을 수 있다. 확인 없이 값을 덮어쓰면 더 최근의 결과가 사라질 수 있다. 이를 줄이기 위한 설계 중 하나가 현재 revision이 4일 때만 전이를 기록하고, 맞지 않으면 다시 읽어 판단하는 방식이다.

조건을 확인하는 읽기와 갱신은 저장소가 보장하는 하나의 원자적 연산이나 적절한 트랜잭션 안에서 처리돼야 한다. 읽고 나서 일반 쓰기를 따로 호출하는 것만으로는 그 사이의 경쟁을 막지 못한다. PostgreSQL 문서는 격리 수준에 따라 어떤 스냅샷을 보고 어떤 동시 실행 현상이 가능한지 달라짐을 설명한다. 여기서는 특정 격리 수준 하나가 모든 문제를 해결한다고 주장하지 않는다.

7. 상태 전이 표를 테스트 목록으로 바꾸기

교육용 입력 상황	허용할 처리	막아야 할 처리
후보 검증 실패	BLOCKED에 이유 기록	COMPLETED로 전이
저장 응답 불명확	RECONCILE에서 실제 파일 대조	실패로 단정하고 즉시 새 파일 생성
파일과 입력 해시 불일치	근거 보존 후 원인 확인	파일 존재만 보고 완료 인정
기록 revision 충돌	최신 기록 다시 읽기	오래된 값으로 덮어쓰기

이 표는 테스트 설계다. 실제 저장소·동시 실행·장애 복구 시험 결과가 아니다.

테스트는 정상 경로 하나가 끝나는지만 보면 부족하다. 각 전이를 허용하는 근거가 없을 때 그 전이가 거부되는지도 봐야 한다. 특히 “완료라고 기록된 채 잘못 끝나는 경우”와 “완료했지만 아직 완료로 기록하지 못한 경우”를 서로 다른 사례로 남겨야 한다.

8. 이번 편의 산출물: 완료를 증명하는 관계

보고서 한 개를 만드는 작업에도 입력의 버전, 내용 검증 결과, 실제 저장된 산출물, 진행 기록의 revision이 연결된다. 완료는 이 관계를 확인한 뒤 부여하는 상태다. 외부 문서가 그 뒤 바뀌었다면 이전 작업의 완료 기록을 거짓으로 바꾸기보다 새 관측에 대한 후속 작업을 구분해 시작할 수 있다. 단, 계약이 최신 상태의 지속 유지를 요구한다면 그 요구에 맞는 별도 감시·재검증이 필요하다.

이번 편에서 준비할 것은 저장소 선택 목록보다 작은 상태 전이 표 한 장이다. 각 화살표 옆에 필요한 증거를 적고, 그 증거가 사라진 상황을 만들어 본다. 다음 편에서는 입력이나 조건이 바뀌었을 때 기존 계획의 어느 부분을 다시 계산해야 하는지 이어간다.

이어 읽기

참고 자료

AWS Step Functions: Workflow states: 상태로 구성하는 워크플로
SQLite: Atomic Commit 및 Transaction: 트랜잭션과 원자성의 범위
PostgreSQL: Transaction Isolation: 스냅샷과 동시 실행의 격리

자료 확인: 2026-10-03. 상태 이름·해시 라벨·전이 규칙은 교육용 설계다. 운영 배포, 동시 실행 시험, 실제 장애 복구 또는 모델 성능 검증을 수행했다는 주장이 아니다.