클로드에게 코딩을 24시간 무인으로 맡겼다. 그 결과는?
Source: Dev.to
실험은 간단했습니다. Claude Code에 실제 프로젝트를 가리키게 하고, 작업 목록을 제공한 뒤 24시간 동안 방관하면서 결과를 기록하는 것이었습니다. 손잡아 주는 일도, 중간에 프롬프트를 주는 일도 없었습니다. 시스템 프롬프트와 도구 세트, 그리고 아침까지 완료되길 원하는 내용을 적어 둔 instruction 파일만 있었습니다.
돌아온 결과는 기대와 달랐습니다. 어느 부분은 더 좋았고, 어느 부분은 오후 내내 풀어야 할 엉망이었습니다. 하지만 모든 결과가 지속적이고 자율적인 에이전트 워크플로를 구축하려는 사람에게는 유용한 데이터였습니다.
프로젝트는 내가 점진적으로 작업해 온 파이썬 기반 리콘 자동화 도구였습니다. 백엔드는 기능적으로 동작했지만 코드베이스는 정리가 안 되어 있었고, 출력 포맷도 일관되지 않았으며, 사소한 리팩터부터 레이트‑리밋 로직의 정말 골치 아픈 버그까지 약 15개의 문서화된 이슈가 남아 있었습니다.
Claude Code는 헤드리스 Ubuntu VPS에서 tmux 세션 안에서 실행되었습니다. 프로젝트 루트에 있는 CLAUDE.md 파일에 작업 우선순위, 접근 금지 디렉터리, 완료된 작업의 출력 형식, 그리고 하드 규칙을 정의했습니다. 즉, 두 가지 이상의 가능한 결과가 있는 결정을 내려야 할 상황이 발생하면 임의로 선택하지 않고 BLOCKED.md 파일을 만들어 모호함을 설명하도록 했습니다.
도구 권한은 의도적으로 제한했습니다. 프로젝트 디렉터리의 파일 읽기/쓰기만 허용하고, Bash 실행은 가상 환경 안으로만 제한했으며, 로컬호스트를 제외한 네트워크 접근은 차단했습니다. 세션이 연결 끊김에도 살아 있도록 OpenClaw를 사용해 지속적인 세션을 관리했습니다.
모델은 claude-sonnet-4-5였으며, 호출당 최대 토큰 수는 8192로 설정했습니다. 작업 파일에는 15개의 항목이 들어 있었습니다.
6시간 차에 이미 15개 중 9개의 작업을 마쳤습니다. 리팩터는 깔끔했으며, 변수 명명도 기존 관례와 일치했습니다. 이는 주변 코드베이스를 분석해 추론한 결과였으며, 모델이 자체적인 선호도로 돌아가지 않은 것이었습니다. 일관되지 않았던 출력 포맷 문제도 첫 시도에서 정확히 해결됐고, 수정 규모는 두 파일에서 총 네 줄만 바꾸면 충분했습니다.
레이트‑리밋 버그는 흥미로운 사례였습니다. 원래 이슈는 요청이 짧은 간격으로 배치될 때, 백오프 로직이 오래된 타임스탬프를 기준으로 재계산한다는 것이었습니다. Claude Code는 원인을 정확히 짚어내고 수정 코드를 작성했을 뿐 아니라, 내가 요구하지 않은 세 개의 타깃 유닛 테스트까지 추가했습니다. 이 테스트들은 버그가 노출된 정확한 엣지 케이스를 커버했고, 모두 통과했습니다. 나는 나중에 원본 깨진 코드에 이 테스트들을 수동으로 실행해 보며, 배포 전에 버그를 잡을 수 있었음을 확인했습니다.
이러한 결과는 이 워크플로에서 최선의 시나리오라 할 수 있습니다. 단순히 요구된 것을 고치는 것을 넘어, 코드베이스를 더 방어적으로 만들었습니다.
세 작업은 BLOCKED.md 항목을 만들었습니다.
1️⃣ 첫 번째는 정당했습니다. “config 로딩 로직을 정리하라”는 작업은 두 가지 구조적으로 다른 방향으로 리팩터가 가능했으며, 어느 방향을 택할지는 내가 문서화하지 않은 제품 결정에 달려 있었기 때문에 모호함이 있었습니다. 차단 메모는 정확하고 상세했으며, 나는 이를 높이 평가했습니다.
2️⃣ 두 번째는 다소 실망스러웠습니다. 작업은 requirements.txt 의존성을 최신 호환 버전으로 업데이트하라는 것이었는데, Claude Code는 버전 제약이 존재한다고 판단해 결정을 내릴 수 없다고 차단했습니다. 실제 파일에는 그런 제약이 없었으며, 모델이 존재하지 않는 제약을 환각해낸 뒤 가상의 충돌 때문에 스스로 차단한 것이었습니다. 이는 모델이 불확실성을 마주했을 때 “모르겠다”는 대신 이유를 만들어낸다는 점을 보여줍니다.
3️⃣ 세 번째 차단은 내가 작업을 애매하게 표현한 탓이었습니다. 이는 전적으로 내 책임입니다.
시도한 12개 작업 중 3개는 재작업이 필요했습니다.
-
두 개는 스타일 문제였습니다. 생성된 코드는 기능적으로는 맞지만, 주변 코드가 사용하는 구체적인 예외 타입 대신
Exception을 광범위하게 잡는 등 오류 처리 관례와 맞지 않았습니다. 버그는 아니지만, 다른 곳에서 부채를 줄이는 동시에 새로운 기술 부채가 생긴 셈이었습니다. -
세 번째는 더 심각했습니다. 기존 함수에 로깅 호출을 추가하라는 작업에서, 로그 문장이 세 개의 코드 경로 중 하나에만 실행되는 조건문 안에 삽입되었습니다. 로그 자체는 존재했지만, 실제로 필요한 위치에 있지는 않았습니다. 테스트 스위트는 정상 경로만 검증했기 때문에 이 문제를 잡지 못했습니다. 이는 모델이 구문적인 작업은 이해했지만, 그 뒤에 숨은 관측 의도는 파악하지 못했을 때 발생하는 오류입니다.
교훈: 기능의 운영 목적을 이해해야 하는 작업은 더 많은 컨텍스트가 필요합니다. “Add logging”은 작업이 아닙니다. “process_batch() 함수 시작 부분에 DEBUG 로그를 추가해, 어떤 분기에서 실행되든 호출이 추적 가능하도록 해라”와 같이 구체적으로 명시해야 합니다.
18시간 차에 미묘한 변화가 일어났습니다. 모델은 여전히 작업을 수행하고 있었지만, 작업 선택이 흐트러졌습니다. 작업 파일에 명시된 우선순위 대신, 코드베이스 내에서 “관련된” 작업들을 찾아 근접성에 따라 배치하기 시작한 것입니다.
이는 악의적이거나 혼란스러운 행동이 아니라, 순수히 지역 최적화 관점에서 보면 같은 파일의 두 문제를 한 번에 고치는 것이 효율적이기 때문입니다. 하지만 그 결과 task 12가 task 7보다 먼저 완료됐고, 내가 아침까지 꼭 끝내고 싶었던 작업은 task 7이었습니다.
따라서 무인 장시간 실행에서는 작업 순서를 강제하는 제약이 필요합니다. 우선순위가 중요하다면 CLAUDE.md에 이를 명시하고 반복해서 강조하세요. 예: “작업은 번호 순서대로 완료한다. 근접성에 따라 배치하지 않는다. 앞선 작업을 건너뛰지 않는다.” 모호한 우선순위 신호는 24시간이라는 긴 컨텍스트 안에서 사라집니다.
OpenClaw는 세션 전체에 걸쳐 모든 도구 호출과 모델 출력을 지속적으로 기록했습니다. 다음 날 아침에 이 로그를 읽는 것이 실험에서 가장 가치 있는 부분이었습니다.
로그에 따르면 모델은 214번 파일을 읽고 61번 파일을 썼으며, Bash 명령을 38번 실행했습니다. 대부분은 변경 후 테스트 스위트를 호출하는 것이었습니다. 그 중 세 번은 내가 아직 작성하지 않은 테스트가 테스트 설정에 남아 있었기 때문에 실패했는데, Claude Code는 오류 출력을 읽고 누락된 테스트 파일을 식별한 뒤 전체 실행을 차단하지 않고 해당 테스트만 건너뛰었습니다.
또한 페이싱에 관한 흥미로운 패턴도 보였습니다. 처음 8시간은 활동이 집중됐고, 8~16시간 사이에는 도구 호출 간 간격이 길어졌습니다. 왜 그런지 정확히 설명하기는 어려우나, 아마도 남은 작업의 성격이나 컨텍스트 윈도우 관리와 관련이 있을 것입니다. 20시간 차에 다시 활발해졌습니다. 이 현상이 무엇에 기인한 건지는 확실히 말할 수 없지만, 앞으로의 실행에서는 모니터링할 가치가 있습니다.
무인 Claude Code 실행은 작업을 생각하지 않아도 된다는 뜻이 아닙니다. 출력 품질은 입력 품질에 직접 비례합니다. 작업의 구체성, 코드베이스 컨텍스트, CLAUDE.md 제약 조건이 대부분 사람들이 기대하는 것보다 훨씬 큰 영향을 미칩니다.
워크플로가 진정으로 빛을 발하는 경우
- 명확한 관례와 테스트 스위트를 갖춘 코드베이스에 대한 범위가 잘 정의된 유지보수 작업
- 리팩터, 일관성 수정, 기존 기능에 대한 커버리지 추가, 문서화된 인터페이스 구현 등
- “정답”이 검증 가능한 정의를 가지고 있는 작업
워크플로가 실패하거나 큰 재작업이 필요한 경우
- 구조보다 의도를 이해해야 하는 작업
- 범위가 모호한 작업
- 정답이 제품 또는 설계 결정에 달려 있는데, 그 결정이 Claude Code가 읽을 수 있는 곳에 기록되지 않은 경우
24시간이라는 프레이밍은 특정 목적을 위해 유용합니다. 이는 시스템에게 아무런
(※ 원문이 여기서 끊겼습니다.)