실험은 간단했습니다. Claude Code를 실제 프로젝트에 지정하고, 작업 목록을 준 뒤, 24시간 동안 물러나서 실제로 어떤 결과가 돌아오는지 기록하는 것이었습니다. 옆에서 도와주지 않았습니다. 세션 중간에 프롬프트(Prompt)를 입력하지도 않았습니다. 그저 시스템 프롬프트(System Prompt), 도구 세트(Tool set), 그리고 아침까지 완료되기를 바라는 작업들을 명시한 지침 파일(Instruction file)만 제공했습니다. 결과물은 제가 예상했던 것과 달랐습니다. 어떤 것은 더 나았고, 어떤 것은 문제를 해결하는 데 오후 전체를 다 써야 할 정도로 엉망이었습니다. 하지만 그 모든 것은 지속적이고 자율적인 에이전트 워크플로우(Autonomous agent workflows)를 구축하려는 누구에게나 유용한 데이터였습니다.

설정 (The Setup)
프로젝트는 제가 점진적으로 작업해 온 Python 기반의 정찰 자동화 도구였습니다. 백엔드(Backend)는 작동했지만 코드베이스(Codebase)가 무질서했고, 출력 형식(Output formatting)이 일관되지 않았으며, 사소한 리팩토링(Refactor)부터 속도 제한(Rate-limiting) 로직의 정말 골치 아픈 버그 하나까지 약 15개의 문서화된 이슈(Issue)가 밀려 있는 상태였습니다.

Claude Code는 헤드리스(Headless) Ubuntu VPS 내의 tmux 세션에서 실행되었습니다. 프로젝트 루트에 있는 CLAUDE.md 파일은 작업 우선순위, 접근 금지 디렉토리, 완료된 작업의 출력 형식, 그리고 엄격한 규칙 하나를 정의했습니다. 즉, 두 가지 이상의 타당한 결과가 있는 결정을 내려야 하는 상황에 직면하면, 임의로 선택하는 대신 중단하고 모호함을 설명하는 BLOCKED.md 파일을 작성해야 한다는 규칙이었습니다.

도구 권한(Tool permissions)은 의도적으로 범위를 제한했습니다. 프로젝트 디렉토리에 대한 파일 읽기/쓰기 권한, 가상 환경(Virtual environment)으로 제한된 Bash 실행 권한, 그리고 localhost를 제외한 네트워크 액세스 차단이 적용되었습니다. 저는 밤사이 연결이 끊기더라도 프로세스가 유지될 수 있도록 지속적인 세션을 관리하기 위해 OpenClaw를 사용했습니다. 모델은 claude-sonnet-4-5였습니다. 호출당 최대 토큰(Max tokens)은 8192로 설정되었습니다. 작업 파일에는 15개의 항목이 있었습니다.

완료된 작업 (What It Completed)
6시간째에 15개 작업 중 9개를 완료했습니다. 리팩토링(Refactors)은 깔끔했습니다. 변수 명명(Variable naming)은 기존 컨벤션(Conventions)과 일치했는데, 이는 모델이 자신의 선호도를 기본값으로 사용하는 대신 주변 코드베이스로부터 추론해낸 것으로 보였습니다.

일관되지 않은 출력 형식(output formatting) 문제는 첫 번째 시도에서 올바르게 해결되었으며, 수정 사항은 매우 최소적이었습니다. 제가 어느 정도 예상했던 대대적인 재작성(wholesale rewrite) 대신, 두 개의 파일에 걸쳐 단 네 줄만 변경되었습니다. 속도 제한(rate-limiting) 버그는 흥미로운 사례였습니다. 원래 문제는 요청들이 서로 가깝게 배치(batched)될 때, 백오프(backoff) 로직이 오래된 타임스탬프(stale timestamp)로부터 다시 계산된다는 것이었습니다. Claude Code는 근본 원인을 정확히 식별하고 수정 사항을 작성한 뒤, 제가 요청하지 않은 일을 수행했습니다. 바로 버그가 노출했던 정확한 엣지 케이스(edge cases)를 다루는 세 개의 타겟팅된 단위 테스트(unit tests)를 추가한 것입니다. 테스트는 통과했습니다. 저는 버그가 배포되기 전에 이를 잡아낼 수 있었는지 확인하기 위해, 사후에 원래의 고장 난 코드를 대상으로 테스트를 수동으로 실행해 보았습니다. 이것이 이러한 워크플로에서 기대할 수 있는 최상의 결과입니다. 단순히 요청받은 것을 고치는 데 그치지 않고, 코드베이스를 더 방어 가능하게(defensible) 만드는 것입니다.

막혔던 부분 (Where It Got Stuck)
세 가지 작업이 BLOCKED.md 항목을 생성했습니다. 하나는 정당했습니다. "설정 로딩 로직을 정리하라(clean up the config loading logic)"는 작업은 제가 문서화하지 않은 제품 결정에 따라 설정이 구조적으로 다른 두 방향으로 리팩터링될 수 있었기 때문에 실제로 모호했습니다. 차단 노트(block note)는 정확하고 상세하게 설명되어 있었습니다. 그 부분은 높게 평가합니다. 두 번째 차단은 덜 인상적이었습니다. 해당 작업은 requirements.txt의 의존성(dependency)을 최신 호환 버전으로 업데이트하는 것이었습니다. Claude Code는 이를 결정이 필요한 사항으로 표시했지만, 인용한 구체적인 우려 사항은 실제 파일에는 존재하지 않는 버전 제약 조건(version constraint)에 관한 것이었습니다. 존재하지 않는 제약 조건을 환각(hallucinated)하여 유령 충돌(phantom conflict)로 인해 스스로를 차단한 것입니다. 여기서 알아둘 점이 있습니다. 모델이 불확실한 상황에 직면했을 때, 모른다고 말하는 대신 불확실성에 대한 이유를 때때로 만들어낼 수 있다는 것입니다. 세 번째 차단은 제가 질문을 잘못 표현한 작업이었습니다. 그것은 제 잘못입니다.

실패한 세 가지 작업 (The Three Tasks It Got Wrong)
완료하려고 시도한 12개의 작업 중, 세 개는 재작업(rework)이 필요한 코드를 생성했습니다.

그중 두 개는 스타일적인 문제였습니다. 생성된 결과물은 기능적으로는 정확했지만, 주변 코드의 에러 처리 (error handling) 관례와 일치하지 않았습니다. 코드베이스의 나머지 부분에서는 특정 예외 유형 (specific exception types)을 사용하는 반면, 모델은 예외 (Exception)를 광범위하게 포착했습니다. 버그는 아니었지만, 다른 곳에서 기술 부채 (technical debt)를 줄이는 동시에 새로운 기술 부채를 도입하고 있었습니다. 세 번째는 더 중대한 문제였습니다. 기존 함수에 로깅 (logging) 호출을 추가하는 작업에서, 로그 문이 세 가지 코드 경로 중 하나에서만 실행되는 조건부 분기 (conditional branch) 내부에 배치되었습니다. 로그는 존재했지만, 유용하게 사용되기 위해 있어야 할 위치에 있지 않았습니다. 테스트 스위트 (test suite)는 '해피 패스 (happy path)'만을 다루었기 때문에 이를 잡아내지 못했습니다. 이는 모델이 구문론적 작업 (syntactic task)은 이해했지만, 그 이면에 있는 관측 가능성 의도 (observability intent)를 이해하지 못했을 때 발생하는 유형의 오류입니다. 여기서 얻은 교훈은 다음과 같습니다. 단순히 구조가 아니라 기능의 운영 목적을 이해해야 하는 작업은 작업 파일 (task file)에 더 많은 컨텍스트 (context)가 필요합니다. "로깅 추가"는 작업이 아닙니다. "어떤 분기가 실행되든 모든 호출을 추적할 수 있도록 process_batch() 시작 부분에 DEBUG 로그 항목을 추가하라"가 작업입니다.

표류 문제 (The Drift Problem)
18시간째에 접어들었을 때, 미묘한 변화가 일어났습니다. 모델은 여전히 작동하며 결과물을 만들어내고 있었지만, 작업 선택 (task selection)이 표류하기 시작했습니다. 작업 파일에 명시된 우선순위 순서를 따르는 대신, 어떤 작업들이 "관련되어" 있는지 스스로 판단하기 시작했고, 문서화된 우선순위가 아닌 코드베이스상의 근접성에 따라 작업들을 묶어서 처리(batching)하기 시작했습니다. 이것은 악의적이거나 혼란스러운 행동이 아닙니다. 순수하게 국소적 최적화 (local optimization) 관점에서 보면, 한 번의 패스 (pass)로 동일한 파일 내의 두 가지 사항을 수정하는 것이 합리적이기 때문입니다. 하지만 이는 작업 12번이 작업 7번보다 먼저 완료되었음을 의미했고, 작업 7번은 제가 실제로 아침까지 완료되기를 바랐던 작업이었습니다. 장시간의 자율 실행 (unsupervised runs)에는 작업 내용뿐만 아니라 작업 순서에 대한 제약 조건이 필요합니다. 우선순위가 중요하다면, CLAUDE.md에 명시적이고 반복적으로 그렇게 명시하십시오. "번호 순서대로 작업을 완료할 것. 근접성에 따라 묶어서 처리하지 말 것."

"앞서가지 마십시오." 모호한 우선순위 신호는 24시간의 컨텍스트 (Context) 속에서 살아남지 못합니다. 로그가 내게 말해준 것: OpenClaw는 세션 전반에 걸쳐 모든 도구 호출 (Tool call)과 모델 출력 (Model output)에 대한 지속적인 로그를 유지했습니다. 다음 날 아침 이를 읽어보는 것이 이번 실험에서 가장 가치 있는 부분이었습니다. 로그에 따르면 모델은 214회의 파일 읽기 (File read) 작업과 61회의 파일 쓰기 (File write) 작업을 수행했습니다. bash 명령어를 38회 실행했는데, 대부분 변경 사항 이후 테스트 스위트 (Test suite)를 호출하기 위한 것이었습니다. 그중 3번의 bash 실행은 실패했는데, 이는 제가 아직 작성하지 않은 테스트가 제가 잊고 있었던 테스트 설정 (Test config)에서 참조되었기 때문입니다. Claude Code는 이 실패를 올바르게 처리했습니다. 에러 출력 (Error output)을 읽고, 누락된 테스트 파일을 식기한 뒤, 전체 실행을 차단하는 대신 영향을 받는 테스트를 건너뛰었습니다. 로그는 또한 속도 조절 (Pacing)에 관한 것도 보여주었습니다. 처음 8시간 동안은 활동이 밀집되어 있었습니다. 8시간부터 16시간 사이에는 속도가 느려졌으며, 출력 결과에 대한 더 깊은 조사 없이는 완전히 설명할 수 없는 도구 호출 사이의 긴 간격이 있었습니다. 20시간째에 이르러 다시 속도가 붙었습니다. 이것이 컨텍스트 윈도우 (Context window) 관리와 관련이 있는지, 아니면 단순히 남은 작업의 특성 때문인지는 확실히 말할 수 없습니다. 향후 실행 시 모니터링할 가치가 있습니다. 이 워크플로우가 실제로 유용한 점: 비감독 (Unsupervised) Claude Code 실행은 작업에 대한 사고를 대체하는 것이 아닙니다. 출력의 품질은 입력의 품질에 직접적으로 비례합니다. 즉, 작업의 구체성, 코드베이스 컨텍스트 (Codebase context), 그리고 CLAUDE.md 제약 조건은 대부분의 사람들이 시작할 때 예상하는 것보다 훨씬 더 중요합니다. 이 워크플로우가 진정으로 성과를 내는 곳은 다음과 같습니다: 명확한 컨벤션 (Convention)과 테스트 스위트가 갖춰진 코드베이스에서의 잘 정의된 유지보수 작업. 리팩터링 (Refactors), 일관성 수정, 기존 기능에 대한 커버리지 추가, 문서화된 인터페이스 (Interfaces) 구현. 즉, "정확함"이 검증 가능한 정의를 가진 작업들입니다.

실패하거나 상당한 재작업이 필요한 부분: 구조(Structure)보다는 의도(Intent)를 이해해야 하는 모든 것, 범위가 모호한 작업, 그리고 정답이 Claude Code가 읽을 수 있는 어딘가에 문서화되지 않은 제품 또는 디자인 결정에 달려 있는 모든 경우입니다. 24시간이라는 프레임워크는 특정한 이유로 유용합니다. 즉, 명확한 질문을 던질 능력이 없는 시스템이 작업을 수행할 수 있도록 사용자가 자신의 의도를 충분히 잘 문서화하도록 강제하기 때문입니다. 만약 이러한 제약 조건 하에서 성공할 수 있는 작업 설명을 작성할 수 없다면, 문제는 아마도 에이전트(Agent)가 아닐 것입니다. CLAUDE.md 템플릿, OpenClaw 설정, 그리고 이번 실행에 사용한 작업 파일 구조를 포함하여 지속적인 Claude Code 에이전트를 설정하기 위한 전체 방법론은 numbpilled.gumroad.com에 있는 두 개의 가이드에 담겨 있습니다. 'OpenClaw + Claude Code: 24/7 Persistent Agent Playbook (2026)'은 세션 지속성 계층(Session persistence layer), 도구 범위 지정(Tool scoping), 로그 관리(Log management)를 다룹니다: numbpilled.gumroad.com/l/openclaw-claude-code. 'Paperclip Method: Replace Your Dev Team With Persistent Claude Agents'는 작업 파일 아키텍처, CLAUDE.md 구조, 그리고 감독 없는 실행 시 작업이 이탈하지 않도록 범위를 지정하는 방법을 다룹니다: numbpilled.gumroad.com/l/paperclip-claude-method. 두 가이드 모두 짧고 밀도가 높으며, 이미 Claude Code를 최소 한 번은 실행해 보았고 사용자가 지켜보지 않을 때 에이전트가 수행하는 작업에 대해 더 구조적인 제어를 원하는 사람들을 위해 작성되었습니다.