중단된 AI 에이전트를 복구하려면, 마지막 대화보다 마지막으로 확인된 실행 상태를 먼저 읽어야 한다. 어디까지 끝났는지, 어떤 입력을 썼는지, 다음 행동을 해도 되는지가 저장되어 있어야 남은 작업을 안전하게 이어 갈 수 있다.
이번 AI Agent Fast Learning은 체크포인트를 다룬다. 앞선 수업의 중복 실행 방지가 한 번의 불확실한 요청을 다뤘다면, 이 글은 여러 단계로 이루어진 작업 전체의 재개 지점을 정한다. 공개 문서 변경 보고 에이전트를 사용한 아래 사례는 학습용 합성 예시다. 상태 구조와 복구 절차는 특정 프레임워크의 필수 규칙이 아니라 설계 제안이다.
1. “요약까지 했음”으로는 재개하기 어렵다
에이전트가 공개 문서 두 개를 읽고 변경 내용을 비교한 뒤, 보고서를 저장하고 지정된 검토자에게 알린다고 가정하자. 저장 단계 직후 실행이 중단됐다. 다음 실행에 “요약까지 완료”라는 메모만 남아 있다면 문제가 생긴다.
- 두 문서의 어느 버전을 비교했는지 알 수 없다.
- 보고서가 메모리에만 있는지, 저장소에도 있는지 구분하기 어렵다.
- 알림을 보내기 전인지, 보냈지만 응답을 못 받은 것인지 모른다.
- 작업이 멈춘 사이 사용자가 범위를 바꾸었는지 확인해야 한다.
체크포인트에는 다시 실행할 때 의사결정에 필요한 정보가 들어가야 한다. 긴 대화를 모두 복사하는 것보다 완료된 단계와 그 근거를 정확히 남기는 일이 우선이다.
2. 체크포인트와 장기 기억의 역할
LangGraph 공식 문서는 체크포인터를 개별 스레드의 그래프 상태를 저장하는 장치로, 스토어를 여러 스레드에 걸친 데이터를 저장하는 장치로 구분한다. 같은 문서는 메모리 기반 저장 방식의 체크포인트가 프로세스 재시작 시 사라질 수 있다고 설명한다. 저장 기능이 있다는 사실과 재시작 후에도 남는다는 보장은 구분해야 한다. LangGraph: Persistence
또한 LangGraph 체크포인터는 super-step 경계에서 상태를 저장한다. 이는 프레임워크가 정의한 실행 단위이며, 임의의 코드 줄에서 중단된 그대로 돌아간다는 뜻은 아니다. 실제 복구 경계는 사용하는 실행 체계의 문서에서 확인해야 한다. LangGraph: Checkpointers
이를 보고서 예시에 적용하면, “독자는 짧은 보고서를 선호한다”는 정보와 “이번 작업의 보고서 버전 3이 저장됐다”는 정보의 쓰임이 다르다. 전자는 여러 작업에 참고할 수 있는 선호다. 후자는 이번 실행의 재개 지점을 정하는 상태다.
3. 복구에 필요한 최소 기록
| 기록 항목 | 합성 값 또는 내용 | 복구 때 확인할 질문 |
|---|---|---|
| 작업과 입력 버전 | task-17, 입력 묶음 v2 | 지금도 같은 요청을 수행하는가? |
| 원문 식별 | 문서 URL, 조회 시각, 저장본 해시 | 어떤 원문을 근거로 비교했는가? |
| 완료 단계와 산출물 | 비교 완료, report-17의 revision 3 | 산출물이 실제로 존재하며 일치하는가? |
| 미확정 외부 작업 | notification-op-8, 결과 미확정 | 이미 일어난 효과를 다시 만들 위험이 있는가? |
| 다음 단계와 선행 조건 | 알림 상태 조회, 보고서 저장 확인 필요 | 무엇을 먼저 확인해야 하는가? |
| 권한 범위와 중단 이유 | 지정 검토자에게 이번 보고서만 전달, 연결 중단 | 권한이 유지되며 대상도 같은가? |
해시는 저장본의 일치 여부를 확인하는 데 도움이 되지만 문서 내용의 진실성을 증명하지는 않는다. 권한 기록 역시 재개 시점의 허가를 자동으로 만들어 주지 않는다. 사용자가 작업을 취소했다면 오래된 체크포인트에 발송 허가가 남아 있어도 실행하면 안 된다.
4. 재개 순서를 고정해 두기
- 작업 정체성 확인: 작업 ID, 요청 범위, 입력 버전을 현재 지시와 비교한다. 다른 작업의 상태를 잘못 불러오지 않았는지 본다.
- 기록과 실물 대조: 저장된 산출물 ID와 버전으로 실제 결과를 읽는다. 체크포인트의 “저장 완료” 문구만 믿지 않는다.
- 미확정 효과 정리: 알림이나 저장 요청의 결과가 불확실하면 해당 상태부터 조회한다. 이때 앞선 수업의 중복 실행 방지 절차를 적용한다.
- 유효한 선행 결과 선택: 바뀐 입력의 영향을 받는 단계만 다시 계산한다. 영향을 받지 않은 검증된 산출물은 보존한다.
- 다음 한 단계 실행: 선행 조건과 권한을 충족한 단계부터 이어 간다. 결과와 근거를 새로운 체크포인트에 기록한다.
여기서 “가장 최근 체크포인트”와 “계속 사용해도 되는 체크포인트”가 같지 않을 수 있다. 예를 들어 비교 대상 문서가 v2에서 v3으로 바뀌었다면, v2 기반 요약은 보존할 수 있어도 새 보고서의 근거로 그대로 사용할 수는 없다. 재개 전에 입력 변경의 영향을 따져야 한다.
5. 저장 경계 사이에 남는 틈
외부 저장소에 보고서를 쓴 다음 체크포인트를 갱신하기 전에 프로세스가 멈출 수 있다. 그러면 외부에는 결과가 있지만 내부 기록에는 없다. 순서를 바꾸어 체크포인트에 먼저 완료를 적으면, 실제 저장 전에 중단되어 반대 문제가 생긴다.
서로 다른 시스템의 두 쓰기를 하나의 원자적 작업으로 묶을 수 없다면, 이런 불일치를 복구 절차가 다뤄야 한다. 제안하는 방법은 실행 의도를 먼저 기록하고, 외부 작업 식별자를 유지하며, 재개 시 실제 결과와 대조해 상태를 확정하는 것이다. 체크포인트 자체만으로 외부 효과의 정확히 한 번 실행을 보장한다고 설명해서는 안 된다.
체크포인트에 비밀번호나 접근 토큰을 넣는 방식도 피해야 한다. 복구에 필요한 참조와 상태를 저장하고, 비밀값은 별도의 승인된 관리 체계로 다룬다. 저장량을 줄일 때에는 복구에 필요한 근거까지 사라지지 않도록 보존 기준을 정한다.
실습: 중단 위치를 바꾸어 복구하기
테스트 환경에서 원문 수집 후, 보고서 저장 요청 후, 결과 확인 후라는 세 지점에서 각각 실행을 멈춰 보자. 매번 같은 곳에서 처음부터 시작한다면 체크포인트가 작업을 충분히 설명하지 못하고 있을 수 있다.
- 이미 검증된 원문과 비교 결과를 재사용했는가?
- 변경된 입력에 의존하는 단계만 다시 실행했는가?
- 외부 저장과 내부 기록이 어긋나도 대조할 수 있는가?
- 프로세스를 실제로 재시작한 뒤에도 기록을 읽을 수 있는가?
- 취소된 작업과 권한이 달라진 작업의 실행을 멈추는가?
복구된 에이전트가 “어디서부터 시작할까요?”라고 묻지 않게 만드는 것만이 목표는 아니다. 무엇을 다시 해도 되는지 근거를 가지고 판단하도록 만드는 것이 목표다. 체크포인트의 품질은 저장한 문장의 길이보다, 재개할 때 줄여 주는 불확실성으로 확인할 수 있다.
공식 자료 확인: 2026년 10월 6일. 이 글의 설계 예시는 별도 실행 검증 결과를 주장하지 않는다.