Claude Code의 반복적인 쓰기 실패가 화제가 됐다. Theo Browne가 문제를 지적하자, Jarred Sumner는 Claude Code가 “아직 읽지 않은 파일 영역”에 쓰는 것을 막는 제약이 원인일 수 있다고 설명했다.1
이 이슈를 단순한 버그 사례로만 보면 놓치는 것이 있다. Claude Code 같은 에이전트형 코딩 도구에서는 작업을 빠르게 진행하는 능력만큼이나 어디까지 허용하고 어디서 멈출 것인가가 중요해지고 있다.
Claude Code는 더 큰 작업을 맡는 도구가 되고 있다
Claude Code는 단순 자동완성 도구가 아니다. 코드베이스를 읽고, 여러 파일을 수정하고, 테스트를 실행하는 에이전트형 코딩 시스템이다.2 사용자는 “이 함수를 바꿔줘”를 넘어 “이 코드베이스에서 문제를 찾아 고쳐줘”에 가까운 일을 맡기게 된다.
이 흐름은 2026년 5월 28일 공개된 Claude Code의 “동적 워크플로”에서 더 분명해졌다.3 동적 워크플로는 Claude가 사용자의 요청을 하위 작업으로 나누고, 하나의 세션에서 수십~수백 개의 병렬 서브에이전트를 실행한 뒤, 결과를 검증해 하나의 답변으로 통합하는 방식이다.3
목표도 작지 않다. 대규모 버그 탐색, 보안 감사, 코드베이스 전반의 마이그레이션처럼 오래 걸리고 병렬화가 필요한 작업을 겨냥한다.3 실행 중인 작업의 진행 상황은 저장되며, 중단된 작업도 처음부터 다시 시작하지 않고 이어서 진행할 수 있다.3
현재 동적 워크플로는 Claude Code CLI, Desktop, VS Code 확장, Claude API, Amazon Bedrock, Vertex AI, Microsoft Foundry에서 사용할 수 있다.3 Max, Team, Enterprise 플랜에서 제공되며, Enterprise는 출시 시점에 기본 비활성화 상태다.3
즉 Claude Code는 “한 번에 한 파일을 고치는 도구”에서 “여러 에이전트를 동원해 긴 작업을 수행하는 도구”로 확장되고 있다. 그래서 이번 쓰기 실패 사례도 더 넓은 맥락에서 봐야 한다.
안전장치는 문제인가, 필요한 제약인가
읽지 않은 파일 영역에 바로 쓰지 못하게 하는 제약은 불편할 수 있다. 사용자는 “수정하라”고 지시했는데 도구가 멈추거나 실패하면 생산성이 떨어진다고 느낀다.
하지만 제약 자체는 이해할 만하다. 에이전트가 충분한 맥락 없이 파일 일부를 덮어쓰면 더 큰 문제가 생길 수 있다. 특히 대규모 코드베이스에서는 한 줄의 변경도 다른 모듈, 테스트, 설정 파일에 영향을 줄 수 있다.
코딩 에이전트 설정 연구에서도 “무엇을 하라”는 지시보다 “무엇을 하지 말라”는 제약이 더 안전한 방향으로 작동할 가능성이 관찰됐다.4 가드레일은 에이전트의 생산성을 막기 위한 장치라기보다, 잘못된 확신으로 위험한 변경을 하지 못하게 하는 장치에 가깝다.
문제는 “막았는가”보다 “왜 막혔는지 사용자가 이해할 수 있는가”다.
오류 메시지가 불명확하면 사용자는 다음 행동을 알 수 없다. 에이전트는 재시도하고, 사용자는 같은 요청을 조금씩 바꿔 반복한다. 이 과정에서 시간과 토큰이 낭비된다. 동적 워크플로처럼 여러 서브에이전트가 병렬로 움직이는 환경에서는 작은 실패가 더 큰 비용으로 번질 수 있다.
큰 작업일수록 먼저 읽고, 작게 나눠야 한다
Claude Code를 효과적으로 쓰려면 “바로 고쳐줘”보다 “먼저 읽고 계획한 뒤 수정해줘”에 가까운 방식이 낫다. 예를 들어 다음처럼 요청할 수 있다.
관련 파일을 먼저 분석하고, 어떤 파일을 왜 수정해야 하는지 계획을 제시한 뒤 변경을 진행해줘.
이런 요청은 에이전트가 필요한 맥락을 먼저 확보하게 만들고, 읽지 않은 영역에 쓰는 상황을 줄이는 데 도움이 된다. 안전장치와 충돌할 가능성도 낮아진다.
큰 작업은 처음부터 동적 워크플로에 맡기기보다 작은 범위에서 시작하는 편이 좋다. 동적 워크플로는 일반 Claude Code 세션보다 훨씬 많은 토큰을 소비할 수 있으며, Anthropic도 토큰 사용량을 파악하기 위해 작은 작업부터 시작하라고 권한다.3 처음 트리거될 때 Claude Code가 실행 예정 내용을 보여주고 사용자 확인을 요청하는 이유도 여기에 있다.3
실무적으로는 다음 기준이 유용하다.
변경 전에 관련 파일을 먼저 읽게 한다.
한 번에 맡기는 범위를 기능, 디렉터리, 테스트 단위로 제한한다.
수정 계획을 먼저 받고, 그다음 실행을 승인한다.
대규모 작업은 작은 실험으로 토큰 사용량과 실패 양상을 확인한 뒤 확장한다.
실패가 반복되면 같은 명령을 재시도하기보다 읽기 범위와 작업 단위를 조정한다.
좋은 가드레일은 멈추는 이유를 설명해야 한다
이번 이슈의 결론은 Claude Code의 안전장치가 불필요하다는 것이 아니다. 오히려 에이전트가 더 많은 파일을 읽고, 더 오래 작업하고, 더 많은 하위 에이전트를 실행할수록 가드레일은 더 중요해진다.
다만 좋은 가드레일은 조용히 실패하는 장치가 아니어야 한다. 사용자가 왜 막혔는지, 무엇을 먼저 읽어야 하는지, 다음에 어떤 요청을 해야 하는지 알 수 있어야 한다.
Claude Code를 쓰는 사용자의 과제도 분명하다. 에이전트에게 큰 목표를 던지는 것만으로는 부족하다. 먼저 맥락을 읽게 하고, 계획을 확인하고, 작은 단위로 실행하게 해야 한다. 에이전트형 코딩 도구의 생산성은 더 강한 자동화뿐 아니라, 더 명확한 제약과 더 좋은 작업 설계에서 나온다.
2Claude Code | Anthropic's agentic coding system
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.