#일시정지 후 어떻게 작업을 재개하는가 — 신선도 검증

신선도 검증(freshness)

기억은 과거에 무슨 일이 있었는지만 알려줄 뿐, 지금도 여전히 유효하다는 것을 증명하지 못한다. 작업 재개는 이력을 재생하는 것이 아니라 이력을 현재의 현실에 접붙이는 것이다.

#작업 재개 시의 전체 프레임

• 먼저 구조화된 작업 상태를 로드한다
• 그다음 모든 외부 의존의 신선도를 검증한다
• 마지막으로 차이에 따라 결정한다: 계속 / 재계산 / 취소 / 사용자 확인 요청

#1단계: 리소스 상태 재검토 (작업 유형별 분류)

{
  "status": "success",
  "data": { ... },
  "timestamp": 1690848000,
  "version": "v1.2.0"
}

규칙: 도구 반환에는 반드시 timestamp와 version이 있어야 하며, 재개 시 유효 기간을 넘겼으면 다시 조회한다.

#2단계: 권한과 사용자 의도 재검토

• 사용자가 일주일 전에 메일 발송을 인가했다고 해서 오늘도 동의한다는 뜻은 아니다. 관리자 권한이 회수되었을 수도 있고 작업 목표가 바뀌었을 수도 있다
• 고위험 동작: 외부 메일 발송, 데이터 삭제, 환불, 주문 — 「재개 후 반드시 재확인」으로 표기
• 저위험 읽기 전용 작업은 자동으로 계속해도 되지만 재검토 결과는 여전히 기록해야 한다
• 권한이 만료되었을 때 모델의 추측에 맡기면 안 된다

#3단계: 차이에 따른 등급별 처리

외부 상태에 변화 없음 — 계속

일부 변경됨 — 국소 재계산

핵심 전제가 변경됨 — 일시정지하고 사유 설명

Agent가 지난주에 「대상 파일 리팩터링」을 계획했는데 오늘 보니 메인 브랜치가 크게 바뀌어 있다면 → 옛 patch를 그대로 적용하면 안 되고, 파일을 다시 읽고 계획을 갱신한 다음 실행해야 한다. 차이가 계획에 영향을 줄 때는 재계획하거나 확인을 요청한다.

#정리

장기 작업을 목표, 할 일, 증거, 인덱스, 도구 상태, 권한 상태로 저장한다. 재개 시에는 먼저 외부 리소스 버전, 도구 반환 타임스탬프, 사용자 인가 유효성을 검사한다. 차이가 계획에 영향을 주면 재계획하거나 확인을 요청한다. 이렇게 하면 Agent가 진행 상황은 기억하되 낡은 상태를 맹신하지 않는다.

#핵심 통찰

1. 기억 ≠ 인가 — 이 문서에서 가장 핵심적인 구분이다. Agent의 장기 기억은 「과거에 어디까지 했는가」만 증명할 뿐 「지금도 이렇게 해도 되는가」를 증명하지 않는다. 재개 시작점과 실행 허가를 뒤섞는 것이 장시간 작업 Agent의 가장 전형적인 상용 사고 원인이다.
2. 작업이 시간을 넘겼다면 외부 세계가 이미 변했다고 가정해야 한다 — 시간 간격 자체가 신뢰할 수 없는 신호이며, 오류가 날 때까지 기다렸다가 검증할 필요가 없다.
3. 도구 반환에는 타임스탬프와 버전이 반드시 있어야 하며, 그렇지 않으면 신선도 판정이 불가능하다 — 이는 인터페이스 계약에 바로 넣을 수 있는 설계 요구다. timestamp + version은 장시간 작업 Agent의 필수 필드다.
4. 재검토는 작업 도메인별로 분류해야지 범용 health check 하나로 때울 수 없다 — 코드 / 주문 / 지식베이스는 각각의 「핵심 전제」가 다르며, 범용 검사로는 「의존 버전이 바뀜」이나 「인덱스가 갱신되지 않음」을 잡아낼 수 없다.
5. 리스크 등급에 따라 사람의 확인이 필요한지 결정한다 — 고위험(외부 메일 발송, 데이터 삭제, 환불, 주문)은 재개 후 재확인을 강제하고, 저위험 읽기 전용은 자동으로 계속하되 흔적은 남긴다. 이것이 HITL(human-in-the-loop) 비용을 꼭 필요한 곳에 통제하는 표준 방식이다.
6. 차이는 세 등급으로 처리해야지 이진화하면 안 된다 — 「변화 없음 / 일부 변경 / 핵심 전제 변경」이 「계속 / 국소 재계산 / 일시정지」에 대응하며, 「맹목적으로 계속하거나 전체를 다시 하거나」의 딜레마를 피한다.
7. 권한이 만료되었을 때 모델의 추측을 금지한다 — 인가와 관련된 판단은 반드시 결정론적인 시스템 조회를 거쳐야 하며 확률 모델에 넘기면 안 된다. 이것이 보안 경계다.
8. 신뢰성에는 원칙이 아니라 관문 산출물이 있어야 한다 — 「재개 전 재검토 리포트」는 추상적 원칙을 감사 가능하고 프로세스를 막을 수 있는 구체적 납품물로 바꾼다. 이것이 「개념을 안다」에서 「상용에 올릴 수 있다」로 가는 경계선이다.
9. 어떤 방안 변경이든 같은 배치의 회귀 샘플을 돌려야 한다 — Prompt 수정 / 모델 교체 / 검색 전략 교체 / 도구 설명 교체 이 네 종류의 변경은 Agent 시스템에서 모두 등가의 「상용 변경」이며 동등한 회귀 규율이 필요하다.

#엔지니어링 실전 Tips

• 모든 도구 반환에 **TTL(유효 기간)**을 정의하고, 재개 시 now - timestamp > TTL로 재조회 여부를 바로 판정할 것. 감으로 정하지 말 것.
• 「고위험 동작 목록」을 설정화할 것(외부 메일 발송 / 데이터 삭제 / 환불 / 주문). 재개 프로세스가 설정을 읽어 사람 확인 발동 여부를 결정하게 하고, 각 Agent의 Prompt에 흩어놓지 말 것.
• 옛 인가는 절대 자동 연장하지 말 것. 특히 코드, 주문, 자금, 외부 알림 네 종류가 그렇다. 인가 자체에도 만료 시간이 있어야 한다.
• 저위험 읽기 전용 작업도 재검토 결과를 기록할 것 — 차단을 위해서가 아니라 사후에 「그때 외부 상태가 무엇이었는지」 복기할 수 있게 하기 위해서다.
• 상용 회귀 시 네 종류의 변경(Prompt / 모델 / 검색 전략 / 도구 설명)을 동등하게 취급해 같은 배치의 회귀 샘플을 돌리고, 정확률·경로 안전·인용 품질·비용·지연 다섯 지표를 정렬할 것.
• 상용 trace 샘플링 → 새 실패 샘플 → 평가셋 환류를 상시 폐루프로 만들 것. 평가셋은 살아 있는 것이지 한 번 쓰고 끝나는 것이 아니다.
• 변경의 좋고 나쁨은 동종 작업의 전체 안정성으로 판단하고 단일 답변이 매끄러운지로 보지 말 것 — 단일 샘플의 개선은 노이즈이기 쉽다.