LangGraph 체크포인트가 다일(Multi-Day) 에이전트에게 제공하지 못하는 네 가지 것

본 기사의 더 긴 버전은 towow.ai에서 확인할 수 있습니다.

에이전트가 3일째 되는 날 흐름을 놓치면, 다른 런타임도 이를 고쳐주지 못할 때가 많습니다. LangChain 자체 비교 페이지는 LangGraph, Temporal, Inngest를 모두 동일한 그룹인 '런타임(runtimes)'에 배치하고 있으며, 이들의 역할은 지속적인 실행(durable execution), 스트리밍(streaming), 인간 개입 루프(human-in-the-loop) 및 영속성(persistence)입니다 (docs). LangGraph 체크포인터는 각 슈퍼 스텝(super-step)마다 그래프 상태의 스냅샷을, 쓰레드별로 저장합니다 (docs). 그 상태에 무엇이 포함될지, 그리고 그것이 진실인지 여부는 사용자에게 달려 있습니다.

아래는 저희가 며칠에 걸쳐 에이전트 작업을 실행하면서 발견한 네 가지 격차입니다. 각 항목은 증상(symptom), 해결책(fix), 그리고 저희 자체 기록에서 확인된 내용을 담고 있습니다. 이 기록들은 저희가 진행하는 납품 작업에 사용하는 에이전트 하네스인 Flowness에서 가져온 것입니다. 코드 블록은 라이브러리 API나 Flowness 코드가 아닌, 가상의 태스크 및 파일 이름으로 작성된 스케치입니다. 리플레이(replay) 스케치는 커서 작성물 속의 유사 코드(pseudo-code)를 따르며, 배포(deploy) 스니펫은 LangGraph 자체 예시를 사용했습니다.

1. 인계 (Handoffs)

증상. 새로운 세션이 시작되는데, 오래된 정보에 의존하거나 이전 세션이 아직 가지고 있는 작업을 중복 처리합니다.

해결책. 그래프 상태나 스토어에 인계 기록을 유지하고 (persistence docs), 새로운 세션이 흐름을 이어받을 때 가장 먼저 실행되는 노드에서 다음과 같은 체크를 호출해야 합니다. 이는 라이브러리 API가 아닌 스케치입니다:

handoff = {
    

**우리의 기록(Our record).** 우리의 인계 시트에는 진행 중인 작업(in-flight tasks), 담당자(owners), 산출물(artifacts), 장애 요소(blockers) 및 다음 단계가 기다리는 사항이 나열되어 있으며, 수신자는 모든 참조를 먼저 확인합니다 ([write-up, in Chinese](https://towow.net/articles/harness-long-task-handover)). 2026년 9월 2일 재구축 검토에서 32개 작업 중 29개가 성공적으로 기록되었으나, 한 요구사항은 작업을 통해 끝까지 전달되지 못했습니다 ([write-up, in Chinese](https://towow.net/articles/flowness-goal-across-handoffs)). 이 시트는 작업을 유지하지만, 목표(goal)는 자체 객체가 필요하며 모든 단계에서 상속되어야 합니다.

## 2. “완료(Done)” 주장

**증상.** 한 단계가 성공을 출력하고, 종료 코드 0을 반환하며, 대상은 변경되지 않습니다.

**해결책.** 체크포인트는 노드가 반환되었다고 기록합니다. 이 체크포인트는 해당 노드가 변경했다고 주장하는 저장소(repository), 서비스 또는 파일을 볼 수 없습니다. 외부 효과가 있는 각 단계에 대해 무엇을 관찰하고 어디서 관찰할지 선언한 다음, 변경을 만든 프로세스가 아닌 대상으로부터 다시 읽어와야 합니다:

effect = Effect(target=

수정 사항. 모든 단계가 두 번 실행된다고 가정하세요. LangGraph의 문서에 따르면 재실행(replay)은 선택된 체크포인트 이후 노드를 다시 실행하므로, LLM 호출과 API 요청이 다시 발생합니다(time travel). 인터럽트(Interrupts)는 자신의 노드를 재실행하므로, 인터럽트 이전의 부작용은 이상적(idempotent)이어야 합니다(interrupts). exit 내구성 모드에서는 중간 상태가 저장되지 않으므로, 실행 도중 충돌이 발생해도 복구할 수 없습니다(checkpointers).

사용자 정의 부작용의 경우, 결과와 중복 제거 증거(dedup evidence)를 하나의 원자적 쓰기(atomic write)로 저장하고, 진행 표시자(progress marker)는 가장 마지막에 업데이트하세요:

pending, end = read_after_cursor()
with lock():
    state = load()
...

우리의 기록. 합성 오프셋 40, 80, 120을 사용하여 커서가 이동하기 전에 충돌이 발생하면 카운트는 2로 남습니다. 재시작 시 세 개의 신호를 다시 읽고 2 + 0 + 0 + 1 = 3으로 끝나지만, 단순하게 더하면 2 + 3 = 5가 됩니다. 이 글은 고정되고 추가 전용(append-only) 로컬 파일, 협력하는 작성자 간의 잠금 장치(lock), 그리고 프로세스 종료로부터의 복구에 관한 것이며, 전원 손실과는 다릅니다(write-up, in Chinese).

4. 일시 중지 및 배포(Pauses and deploys)

증상. 시스템을 일시 중지했는데도 작업이 계속 도착합니다. 또는 수정 사항을 배포했더니 진행 중인 실행(in-flight runs)의 동작이 변경됩니다.

수정 사항. 일시 중지가 무엇을 멈추게 하는지 기록하세요: 새로운 디스패치, 진행 중인 작업, 검토 및 수정 레인, 그리고 코디네이터 순찰은 별도로 설정됩니다. 재개 시에는 아무것도 다시 시작하기 전에 일시 중지 기간 동안 도착한 것을 읽으세요. 모든 것을 한 번에 재개하면 이미 누군가가 가지고 있는 작업을 다시 시작할 수 있습니다.

배포(deploys)의 경우, LangGraph의 하위 호환성 가이드에 따르면 최신 그래프가 체크포인트에서 재개되는 스레드를 포함하여 모든 스레드에 적용됩니다. 반면 일부 워크플로우 엔진은 실행을 시작 코드 버전에 고정합니다. 스레드가 멈춰 있는 노드의 이름을 변경하거나 제거하면 재개가 깨집니다. 가이드에서는 스레드 시작 시 상태(state)에 행동 버전(behavioral version)을 표시하고 이를 기준으로 분기할 것을 권장합니다 (docs):

def intake(state):
    return {"flow_version": state.get("flow_version", 2)}  # new threads are stamped 2

...

우리의 기록. 지난 9월 15일 중단 시, 두 개의 진행 중이던 실행기(executors)가 현재 섹션을 완료했고, 새로운 디스패치(dispatch)는 0으로 갔으며, 검토 및 수정 레인(review and fix lanes)은 유지되었습니다 (write-up, in Chinese).

어떤 간격에 어떤 도구를 사용할 것인가 (Which tool for which gap)

LangChain의 페이지는 LangGraph와 함께 Temporal 및 Inngest를 런타임(runtimes)으로, Deep Agents SDK와 Claude Agent SDK를 하네스(harnesses)로 나열합니다. 이 그룹화는 LangChain의 것이며, 본 게시물은 이를 테스트하지 않습니다. 위의 네 가지 수정 사항은 상태(state), 인계(handoffs), 검사(checks)를 어떻게 설계하는지에 관한 것이므로 모든 런타임에 적용됩니다.

AI 지원을 받아 작성되었으며, 프로젝트 기록을 기반으로 사실 확인 후 게시되었습니다.