AX LABS
← 블로그 AX Ops 방법론

장기 작업은 상태를 찢어야 산다

재개와 폐기는 같은 저장소에서 풀 수 없다

AX LABS 9분 읽기

현장에서 장기 에이전트 작업을 붙이면 같은 장면이 반복된다. 첫 실행은 그럴듯하다. 두 번째부터 꼬인다. 사람이 중간 승인한 내용, 모델이 내부적으로 이어가야 할 추론 단서, 나중에 감사팀이 봐야 할 실행 기록이 한 덩어리 대화 로그 안에 섞인다. 장애가 나면 재개할지, 처음부터 다시 돌릴지, 특정 구간만 폐기할지 판단하지 못한다.

이 문제는 프롬프트 문제가 아니다. 상태 저장 정책 문제다. OpenAI의 Responses API는 reasoning items를 턴과 tool call 사이에서 이어 쓰는 방식을 공식 가이드에서 설명하고, 수동 context 관리 시 reasoning item을 후속 입력에 포함해야 한다고 문서화한다. LangGraph도 graph state를 step마다 checkpoint로 저장해 HITL, time travel debugging, fault-tolerant execution에 쓴다고 설명한다. 핵심은 하나다. 긴 작업은 대화가 아니라 실행체다. (cdn.openai.com)

하나의 로그는 운영 정책이 아니다

많은 조직이 “전체 대화 저장”을 안전장치로 착각한다. 전체 저장은 복구 단위가 아니다. 무엇을 재개해야 하는지, 무엇을 폐기해야 하는지, 무엇을 증거로 남겨야 하는지 구분하지 못하면 저장량만 늘어난다.

persisted reasoning checkpoint의 목적은 많이 저장하는 것이 아니라, 다시 시작해도 같은 업무 책임선을 유지하는 것이다.

AX Ops에서는 장기 작업 상태를 세 평면으로 나눈다.

평면 저장 대상 재개 시 용도 폐기 기준
reasoning state reasoning item, compacted summary, plan cursor 모델이 이어서 판단할 최소 단서 모델 변경, 정책 변경, 중대한 오류 발견
대화 state 사용자 요청, 승인, 피드백, 산출물 버전 사람과 시스템의 합의 복원 업무 종료, 개인정보 보존기한 도래
감사 로그 tool call, 권한, 입력·출력 해시, trace id 사후 설명과 책임 추적 원칙적으로 별도 보존 정책 적용

세 평면을 나누면 운영 질문이 선명해진다. “어디서 멈췄나”는 checkpoint가 답한다. “누가 무엇을 승인했나”는 대화 state가 답한다. “왜 이 도구가 호출됐나”는 감사 로그가 답한다.

reasoning state는 원문 사고가 아니라 재개 토큰이다

reasoning state를 모델의 내부 사고 전문으로 취급하면 바로 막힌다. 보안, 비용, 벤더 정책, 설명 책임이 충돌한다. 운영에서 필요한 것은 내부 사고의 전시가 아니다. 다음 실행이 같은 업무 맥락에서 이어질 수 있는 재개 단서다.

따라서 reasoning checkpoint에는 네 가지를 남긴다.

  1. 현재 목표와 완료 조건
  2. 선택된 실행 계획의 위치
  3. 이미 검증한 가정과 폐기한 경로
  4. 다음 tool call 전 필요한 승인 조건

OpenAI 문서는 encrypted reasoning item을 통해 ZDR 조건에서도 reasoning item 재사용을 지원한다고 설명한다. 이는 reasoning state를 일반 대화 로그와 다르게 취급해야 한다는 신호다. Google Cloud의 Agent Executor 발표도 장기 agent workflow의 취약성을 지적하며 event log와 snapshotting 기반 재개를 핵심 기능으로 제시했다. (cdn.openai.com)

대화 state는 합의의 원장으로 남겨야 한다

대화 state는 모델을 위한 메모리가 아니다. 업무 합의의 원장이다. 사용자가 어떤 조건으로 진행을 허용했는지, 어느 산출물을 반려했는지, 어느 버전을 기준으로 다음 단계를 열었는지가 남아야 한다.

여기서 금물은 대화 state를 reasoning summary로 덮어쓰는 일이다. 요약은 재개에는 유용하지만 분쟁에는 약하다. 승인 문장, 첨부 파일 버전, 업무 규칙 변경은 원문과 참조 ID를 유지한다. 반대로 단순 잡담, 중복 설명, 모델의 중간 표현은 compact 대상이다.

Anthropic은 장기 agent harness에서 shift를 넘겨받는 엔지니어 비유로 context 인수인계 문제를 설명한다. 이 비유가 맞다. 다음 실행 주체는 이전 대화를 모두 읽는 사람이 아니라, 이어받을 수 있게 정리된 업무 상태를 받아야 한다. (anthropic.com)

감사 로그는 재개 입력으로 쓰지 않는다

감사 로그를 context에 다시 넣는 순간 로그가 오염된다. 감사 로그는 모델을 돕기 위한 메모리가 아니라 사람이 나중에 검증할 증거다. tool 호출, 권한 위임, 외부 시스템 응답, 실패, 재시도, 사용자 승인, 모델·프롬프트 버전, checkpoint id를 append-only로 남긴다.

OpenTelemetry는 GenAI semantic conventions를 통해 LLM call, tool invocation, agent span을 관측 가능한 구조로 다루는 방향을 제시한다. OpenAI도 API Platform Audit Log API를 조직의 보안·컴플라이언스 가시성을 위한 immutable, auditable log로 설명한다. 감사 로그는 재개 저장소가 아니라 증거 저장소다. (opentelemetry.io)

운영 정책은 단순해야 한다. 재개는 reasoning checkpoint와 대화 state만 읽는다. 감사 로그는 읽지 않는다. 폐기는 reasoning state부터 한다. 대화 state는 업무 보존 정책을 따른다. 감사 로그는 보안·감사 기준을 따른다.

AX Ops는 상태 수명주기를 먼저 설계한다

장기 작업을 운영하려면 모델 선택보다 먼저 상태 수명주기를 합의해야 한다. 언제 checkpoint를 찍는가. 어떤 checkpoint가 재개 가능 상태인가. 어떤 오류가 나오면 reasoning state를 폐기하는가. 어떤 승인 이후에는 이전 분기로 돌아가지 못하게 잠그는가.

AX Ops의 기본 원칙은 세 가지다.

  1. checkpoint는 업무 단계 경계에서만 신뢰한다.
  2. reasoning state는 짧게, 대화 state는 정확하게, 감사 로그는 변조 불가능하게 남긴다.
  3. 재개·폐기·감사는 서로 다른 권한으로 실행한다.

이렇게 설계하면 장기 에이전트는 “대화가 길어진 챗봇”이 아니라 운영 가능한 업무 실행체가 된다. 다음 PoC에서는 모델 성능표보다 상태 분리표를 먼저 그려야 한다. Persisted reasoning checkpoint는 기술 옵션이 아니라 운영 책임선이다. AX LABS는 이 책임선을 AX Ops 안에서 설계하고 현장 운영으로 붙인다. AX Ops 방법론 →

참고