지난 글까지의 이야기는 대체로 한 번의 요청 안에서 끝나는 일이었다. 사용자가 묻고, 에이전트가 몇 걸음 돌고, 답이 나온다. 길어야 몇 분이다.
그런데 실무에서 값이 큰 일은 그것보다 길다. 서류 8천 건을 훑어 분류하는 일, 밤새 돌면서 데이터를 옮기는 일, 사람의 결재를 기다렸다가 이어서 하는 일. 몇 시간에서 며칠이 걸리고, 그 사이에 프로세스가 죽고 서버가 재시작되고 API가 잠깐 막힌다.
이 길이가 되면 문제의 성격이 바뀐다. 짧은 일에서는 실패하면 그냥 다시 하면 됐다. 여기서는 다시 하는 것 자체가 몇 시간이다.
대화 기록은 상태가 아니다
가장 먼저 무너지는 것이 이것이다. 짧은 일에서는 「어디까지 했는가」가 대화 기록에 그냥 남아 있었다. 걸음이 서른을 넘어가면 그 방식이 두 가지 이유로 안 된다.
하나, 넘친다. 걸음마다 도구 결과가 붙으므로 문맥은 단조롭게 커진다. 창을 넘으면 앞부분부터 잘리고, 무엇이 잘렸는지 모르는 채로 계속 돈다. 「아까 확인했다」던 것이 문맥에서 사라졌는데 에이전트는 그것을 모른다.
둘, 프로세스와 함께 사라진다. 대화 기록이 메모리에만 있으면 재시작 한 번에 전부 없어진다. 몇 시간짜리 일에서 이건 언젠가 반드시 일어나는 일이지 예외가 아니다.
그래서 오래 도는 에이전트에서는 상태를 밖에 둔다. 작업 기록을 데이터베이스나 파일에 두고, 매 걸음 그것을 읽어 이번에 필요한 만큼만 문맥에 담고, 걸음이 끝나면 결과를 다시 그쪽에 적는다. 대화 기록은 상태가 아니라 이번 걸음의 작업 공간이 된다.
작업 기록에 담기는 것은 대체로 이런 것들이다.
| 담는 것 | 예 |
|---|---|
| 어디까지 했는가 | 처리한 항목의 마지막 번호, 남은 목록 |
| 무엇을 알아냈는가 | 확인된 사실. 대화 원문이 아니라 정리된 형태로 |
| 무엇이 실패했는가 | 실패한 항목과 이유. 다시 시도할지의 표시 |
| 지금 어떤 상태인가 | 진행 중·사람 승인 대기·중단됨 |
| 얼마나 썼는가 | 걸음 수, 토큰, 비용 |
문맥 요약과 기억에서 다룬 요약 기법이 여기서 쓰이지만, 목적이 조금 다르다. 거기서는 문맥을 줄이는 것이 목적이었고 여기서는 프로세스가 죽어도 남는 것을 만드는 것이 목적이다.
체크포인트를 어디에 남기는가
상태를 밖에 뒀다면 자연스럽게 따라오는 것이 재개다.
체크포인트를 남길 자리를 고르는 기준은 하나다. 되돌리기 어려운 일을 하기 직전과 직후. 파일을 쓰기 직전, API로 무언가를 보낸 직후, 결제를 마친 직후. 그 사이에서 죽는 것이 가장 아프기 때문이다.
간격은 다시 하는 비용이 정한다. 한 걸음에 30초에 몇 백 원이면 세 걸음마다 남겨도 되고, 한 걸음이 10분짜리면 걸음마다 남긴다. 체크포인트 자체는 싸다 — 몇 킬로바이트를 쓰는 일이다. 아껴서 이득 볼 것이 별로 없다.
그리고 체크포인트에는 다음에 무엇을 할 차례인지가 함께 적혀 있어야 한다. 「7번 항목까지 처리했다」만 있으면 다시 시작할 때 8번부터 하면 되는지, 7번을 하다 만 것인지 알 수 없다. 「7번 완료」와 「8번 시작함」은 다른 기록이다.
같은 걸음을 두 번 밟아도 괜찮은가
재개가 있으면 반드시 따라오는 질문이다. 죽기 직전에 하던 걸음이 정말 안 됐는지 됐는데 기록만 안 남은 것인지 알 수 없는 경우가 있다. API 호출을 보냈고 응답이 오기 전에 죽었다면, 그 호출은 서버 쪽에서 성공했을 수도 있다.
그래서 오래 도는 에이전트가 부르는 도구는 되도록 같은 것을 두 번 불러도 결과가 같아야 한다. 이 성질을 멱등성(idempotency)이라고 부른다 — 한 번 하나 두 번 하나 세상에 남는 결과가 같다는 뜻이다.
만드는 방법은 대체로 셋이다.
- 호출마다 고유한 키를 붙인다. 같은 키로 다시 들어온 요청은 서버가 앞의 결과를 그대로 돌려준다. 결제 API가 이 방식을 쓴다
- 「만들라」 대신 「이 상태로 맞춰라」로 짠다. 「행을 추가한다」는 두 번 부르면 두 줄이 되지만, 「이 아이디의 행을 이 값으로 둔다」는 몇 번을 불러도 한 줄이다
- 하기 전에 확인한다. 보내기 전에 이미 보냈는지 조회한다. 조회와 실행 사이에 틈이 있어 완전하지는 않지만, 위의 둘이 안 되는 자리에서는 이것이라도 한다
되돌릴 수 없고 멱등으로도 못 만드는 동작은 따로 다룬다. 메일 발송이 대표적이다. 그런 것은 실행 직전에 「보냄」을 먼저 기록하고 나서 보낸다 — 두 번 보내는 것보다 한 번도 안 보낼 위험을 택하는 쪽이고, 대신 안 보낸 것이 남아 있는지 나중에 확인하는 절차를 둔다. 어느 쪽 위험을 택할지는 일마다 다르고, 그 선택을 미리 해 두는 것이 설계다.
중간에 사람을 기다릴 때
오래 도는 일에는 사람의 결재가 끼어드는 경우가 많다. 여기서 흔한 실수는 기다리는 동안 프로세스를 살려 두는 것이다. 승인이 세 시간 뒤에 오면 세 시간 동안 무언가가 떠 있어야 하고, 그 사이 재시작 한 번이면 끝이다.
기다리는 것은 상태로 표현한다. 「사람 승인 대기」라고 작업 기록에 적고 프로세스는 내려간다. 승인이 들어오면 그 기록을 읽어 다음 걸음부터 다시 시작한다. 이렇게 두면 며칠을 기다려도 아무것도 떠 있을 필요가 없다.
이때 함께 정할 것이 둘이다. 얼마나 기다릴 것인가(기한이 지나면 취소인지 자동 진행인지), 그리고 기다리는 동안 세상이 바뀌면 어떻게 할 것인가. 승인 요청을 올릴 때 본 재고와 승인이 떨어진 뒤의 재고가 다를 수 있다. 이어서 하기 전에 전제를 다시 확인하는 걸음을 하나 두는 편이 안전하다.
멈추는 조건을 미리 적어 둔다
오래 도는 에이전트가 조용히 돈다는 것은 아무도 안 보는 채로 값을 쓰고 있다는 뜻이기도 하다. 상한을 코드로 걸어 둔다.
- 전체 걸음 수 — 넘으면 지금 상태를 남기고 멈춘다
- 비용과 토큰 — 예산의 8할에서 알리고, 넘으면 멈춘다
- 같은 실패의 반복 — 같은 오류가 세 번 연속이면 재시도가 아니라 보고다
- 진척 없음 — 다섯 걸음 동안 작업 기록의 「어디까지」가 안 움직이면 돌고 있는 것이다
- 벽시계 시간 — 여섯 시간이 지나면 끝났든 아니든 일단 멈추고 사람이 본다
넷째가 특히 자주 빠진다. 에이전트는 오류 없이도 제자리를 돌 수 있다 — 같은 검색을 조금씩 바꿔 가며 계속 하는 식이다. 오류 횟수만 세면 이 상태를 못 잡는다. 진척을 재는 자를 따로 두어야 한다.
그리고 멈출 때는 다시 시작할 수 있는 상태로 멈춘다. 상한에 걸려 멈춘 작업이 재개 불가능하면 상한을 건 의미가 절반이다.
보이게 만든다
마지막으로, 여섯 시간짜리 작업은 사람이 들여다볼 수 있어야 한다. 최소한 이 셋은 밖에서 읽을 수 있어야 한다.
지금 무엇을 하고 있는가 — 「8,412건 중 3,190건 처리 중」 정도의 한 줄. 얼마나 썼는가 — 지금까지의 비용과 남은 예산. 무엇이 실패했는가 — 건너뛴 항목의 목록. 이 셋이 작업 기록에 이미 들어 있으므로 화면 하나만 붙이면 된다. LLM 운영 관측에서 다룬 것과 같은 이야기이고, 오래 도는 일에서는 선택이 아니다.
그리고 취소 버튼을 둔다. 잘못 시작한 여섯 시간짜리 작업을 멈추는 방법이 서버 재시작뿐이면, 사람은 그 작업을 시작하기를 두려워하게 된다.
정리
- 몇 시간짜리 일에서는 프로세스가 죽는 것이 예외가 아니라 전제다
- 대화 기록은 상태가 아니다. 어디까지 했는가는 밖의 작업 기록에 적고 문맥은 이번 걸음 것만 담는다
- 체크포인트는 되돌리기 어려운 일의 직전과 직후에 남긴다. 간격은 다시 하는 비용이 정한다
- 「7번 완료」와 「8번 시작함」은 다른 기록이다. 다음 차례가 함께 적혀 있어야 재개된다
- 도구는 되도록 멱등으로 만든다 — 고유 키, 「이 상태로 맞춰라」 형태, 하기 전 확인
- 멱등으로 못 만드는 동작은 어느 쪽 위험을 택할지 미리 정해 둔다
- 사람을 기다리는 것은 상태로 표현하고 프로세스는 내린다. 이어서 할 때 전제를 다시 확인한다
- 상한은 걸음 수·비용·반복 실패·진척 없음·벽시계 다섯을 각각 건다
- 진척을 재는 자가 없으면 오류 없이 제자리를 도는 상태를 못 잡는다
- 진행·비용·실패를 밖에서 볼 수 있게 하고, 취소 버튼을 둔다
읽어주셔서 감사합니다. 😊