Claude Code를 7일 동안 무인으로 실행했을 때 깨진 3가지 패턴

API Error: 400 messages.N.content.M: 최신 assistant 메시지의 `thinking` 블록은 수정할 수 없습니다. 이 블록들은 원래 응답에 있던 그대로 유지되어야 합니다.

그 에러는 제가 지켜보고 있지 않던 세션을 종료시켰습니다.

168시간. 47번의 세션. 제가 잠을 자고, 여행을 하고, 다른 일을 하는 동안 Claude Code는 실제 고된 작업(grinds)을 수행하고 있었습니다.

일주일 동안 세 가지 패턴이 깨졌습니다. 그중 어느 것도 제가 시작할 때 예상했던 실패는 아니었습니다.

여기서 제가 얻은 가장 강력한 교훈이 있습니다.

요란한 충돌(crashes)은 제가 걱정했던 실패였습니다. 하지만 그것들이 타격을 주는 경우는 드물었습니다.

실제로 타격을 준 것은, 조용히 작업을 파괴하거나 대기열(queue)을 정체시키면서 마치 앞으로 나아가고 있는 것처럼 보이는 모습이었습니다.

저는 DACH(독일, 오스트리아, 스위스) 기업 배포 환경 전반에서 이와 같은 자동화를 생업으로 운영하고 있으며, 동일한 세 가지 형태가 계속해서 나타납니다. 이들에게 이름을 붙이는 것이 해결책의 대부분입니다.

패턴 1. 스스로를 독살하는 턴 (The turn that poisons itself)

이것은 예상치 못한 것이었습니다.

확장된 사고(extended thinking) 기능이 켜져 있으면, 모든 assistant 턴은 다음 요청 시 모델로 바이트 단위까지 동일하게 되돌아와야 하는 사고 블록(thinking block)을 포함합니다.

잘못된 순간에 해당 턴을 중단하거나, 자동 압축(automatic compaction)이 히스토리를 재구축하게 두면, 블록이 변경된 상태로 돌아옵니다.

그러면 서버는 전체 요청을 거부합니다. 당신의 턴은 죽습니다. 당신의 실행은 중단됩니다.

저를 놀라게 했던 점은 제 도구 중 그 어떤 것도 이를 잡아낼 수 없었다는 것입니다.

그 에러는 턴이 이미 실패한 후, 전송 계층(transport layer)에서 반환됩니다.

제 훅(hooks)은 도구(tools)와 세션(sessions) 주변에서 실행됩니다. 실패한 API 요청 주변에서는 절대 실행되지 않습니다.

따라서 이를 잡아내고 재시도하는 가드(guard)를 작성하려는 본능은 막다른 길입니다. 가드를 걸 수 있는 이벤트가 존재하지 않기 때문입니다.

진짜 해결책은 이렇습니다. 이것은 스크립트로 해결할 수 있는 문제가 아닙니다. 이것은 규율(discipline)의 문제입니다.

생각하는 도중에 중단된 턴을 재개하지 마십시오. 계속하기 전에 히스토리를 깨끗하게 재구축하거나, 새로 시작하십시오.

그 밑바닥에 깔린 더 저렴한 교훈을 새기십시오. 가장 비용이 많이 드는 실패 중 일부는 자동화로 우회할 수 없습니다. 오직 피할 수 있을 뿐입니다.

패턴 2. 83퍼센트에서의 절벽 (The cliff at 83 percent)

이 두 번째 패턴은 실제 작업량 측면에서 가장 큰 손실을 초래했습니다.

가장 길게 진행했던 작업은 커밋 (commit)을 좀처럼 하지 않았습니다. 몇 시간 동안 실행된 후에야 겨우 체크포인트 (checkpoint) 하나가 생성되었습니다.

실행 중에는 괜찮게 느껴집니다. 하지만 그것은 함정입니다.

작업 중간에 속도 제한 (rate-limit) 상한선에 도달했을 때, 재개 지점 (resume point)은 실제 진행 상황보다 몇 시간 뒤처져 있었습니다.

800개 이상의 항목을 처리하던 한 작업은 83퍼센트에서 멈췄습니다. 작업량의 약 17퍼센트는 제가 수동으로 다시 확보해야 했던 추진력이었습니다.

수치를 계산해 보면 명확합니다. 몇 시간마다 한 번씩 커밋을 하면, 3시간째에 발생하는 어떤 중단이라도 몇 시간의 작업을 지워버립니다.

이 해결책은 기계적입니다. 얼마나 자주 커밋할 것인가는 루프 (loop)의 속성이 되어야 하며, 루프가 스스로 처리하여 사용자가 기억할 필요가 없도록 만들어야 합니다.

재개 비용 (resume cost)을 적은 수의 고정된 항목 수에 결합하십시오. 그러면 상한선 도달이나 충돌 (crash)이 발생하더라도 오직 그 적은 수의 항목만큼만 손실을 보게 됩니다. 여러분의 오후 시간은 안전하게 지켜질 것입니다.

이것은 제가 이제 긴 루프를 시작할 때 반드시 지키는 패턴입니다.

패턴 3. 고스트 락 (The ghost lock)

세 가지 패턴 중 가장 조용하며, 모든 것이 정상인 것처럼 보이는 패턴입니다.

각 워커 (worker)는 락 파일 (lock file)을 사용하여 자신의 슬롯을 예약했습니다. 이는 두 개의 실행이 충돌하는 것을 방지하기 위한 표준적인 관행입니다.

하나의 실행이 강제로 종료되었습니다. 락 파일은 그 안에 죽은 프로세스 ID (process id)를 품은 채 그대로 남았습니다.

그러자 제 큐 (queue)는 지시받은 대로 정확히 동작했습니다. 예약된 상태를 확인하고 기다린 것입니다.

아무것도 실행되지 않았습니다. 아무것도 진행되지 않았습니다. 하지만 대시보드에는 바쁜 것처럼 보였습니다.

오래된 락 (stale lock)이 타이머에 의해 만료될 때까지 약 70분 동안 차단된 상태로 머물러 있었습니다.

락이 보호하는 대상을 인지하게 만들면 이 문제는 사라집니다.

프로세스의 이름을 지정하는 모든 락은 해당 프로세스가 사라지는 즉시 해제되어야 합니다. 시계가 다 돌아가기를 기다리는 것은 느리고 비용이 많이 드는 방식입니다.

사망 시 수확 (Reap on death)하십시오. 타임아웃 (timeout)은 오직 최후의 보루로만 유지하십시오.

하나의 실이 세 가지를 연결한다

세 가지를 함께 살펴보면 공유되는 형태가 명확합니다.

요란한 실패는 선물입니다. 그것을 발견하고, 수정하고, 다음으로 넘어가면 됩니다.

무인 실행 (unattended run) 중 발생하는 위험한 실패는 진행 중인 것처럼 위장합니다.

여러분이 지켜보고 있지 않던 세션을 중단시켜 버리는, 독이 든 한 차례의 회전 (poisoned turn) 말입니다.

첫 번째 중단 시에는 몇 시간의 시간을 돌려받을 정도로 드물게 커밋을 수행하는 작업 (grind)입니다.

두 번째는 이미 죽어버린 작업자 (worker)를 예의 바르게 기다리고 있는 대기열 (queue)입니다.

외부에서 보기에 이 모든 것들은 건강한 시스템처럼 보였습니다.

아무도 지켜보지 않는 상태로 일주일 동안 무언가를 실행했을 때 얻은 진짜 교훈은 다음과 같습니다.

여러분의 모니터링은 소리 높여 외치는 에러들에 맞춰져 있습니다. 하지만 여러분에게 비용을 치르게 하는 것은 미소 짓고 있는 에러들입니다.

여기에 게시하지 않는 것들

저는 각 수정 사항의 버전을 프로덕션 (production) 환경에서 실행합니다. 정확한 계측 (instrumentation), 커밋 간격 (commit-interval) 수치, 그리고 각 실패 형태를 첫 번째 대응으로 매핑하는 런북 (runbook)은 제가 고객 프로젝트에 제공하는 작업물입니다.

이것들을 제외한 것은 의도적인 결정입니다.

구현 방법을 그대로 붙여넣어 버리면, 다음에 이 문제에 부딪히는 사람은 그것을 그대로 복사할 뿐, 그 밑에 깔린 더 깊은 문제를 드러내는 대화는 결코 나누지 않게 될 것입니다.

진정한 피해는 바로 그 대화 속에서 포착됩니다.

패턴 (Pattern)은 선물이고, 레시피 (Recipe)는 작업입니다.

여러분의 차례

여러분도 언젠가 에이전트 (agent)나 긴 작업 (long job)을 감독 없이 실행해 둔 적이 있을 것입니다.

여러분이 보지 않는 사이에 무언가 고장 났을 것입니다.

이 세 가지 중 어떤 것을 경험하셨나요? 그리고 제가 놓친 것이 있다면 무엇이라고 이름을 붙이시겠습니까?

여러분이 목격한 형태를 댓글로 남겨주세요.

우리가 공유하는 실패 모드 (failure modes) 라이브러리는 더 많은 사람이 그 현상을 소리 내어 명명할 때 더욱 날카로워집니다.