Rethinking Claude Code Best Practices — Lydia Hallie, Anthropic

한 줄 핵심

Claude Code 같은 코딩 에이전트가 더 똑똑해질수록 사람은 세세한 지시와 승인에서 물러나고, 모델·하네스·환경·CI로 안전성과 검증을 떠넘기는 방식으로 작업 흐름을 재설계해야 한다.

시간별 요약

1. 0:00
   모델이 좋아지면서 바뀐 작업 방식 Opus 55와 Fable 52처럼 더 강력한 모델은 더 오래 작업하고 코드베이스를 더 잘 이해하며, 스스로 결과를 검증한다. 그 결과 예전처럼 사람이 거의 모든 단계에 개입하는 방식 대신, 한 사람당 여러 세션을 동시에 관리하는 방식으로 작업 구조가 바뀐다.
2. 2:00
   프롬프트를 줄이고 환경을 다시 설계하기 이제는 Cloud MD에 과한 강조나 금지 문구를 넣기보다, 모델이 코드에서 볼 수 없는 정보만 남기는 편이 낫다. auto mode와 `doctor prompt audit` 같은 도구를 활용해 모델이 이미 아는 것은 덜 주고, 승인 부담은 설정으로 옮겨야 한다.
3. 5:00
   안전은 승인보다 하네스가 중요함 위험한 명령을 사람보다 더 잘 막더라도, 완전한 보장은 하네스의 deny rule에서 나온다. `.env`처럼 절대 읽히면 안 되는 파일은 규칙으로 막아야 하고, `npm test`처럼 정상 명령의 부작용은 샌드박스와 실행 환경 격리로 통제해야 한다.
4. 9:00
   장시간 세션을 위한 안전한 실행 환경 Cloud session은 새 머신과 깨끗한 저장소 복사본에서 돌아가므로, 노트북을 닫아도 장시간 작업을 이어갈 수 있다. 다만 커밋, 커넥터 메시지, 네트워크 비밀처럼 밖으로 나가는 것은 여전히 관리해야 하며, 그래서 deny rule과 비밀 전달 방식을 함께 설계해야 한다.
5. 11:00
   검증 포인트를 세워 결과를 확인하기 배경에서 오래 일하는 세션은 끝에서 한 번에 검토하면 놓치는 부분이 많으므로, 테스트·빌드·스크린샷 같은 중간 검증 지점을 넣어야 한다. 프롬프트로 작업 정의를 명확히 하고, 반드시 강제해야 하는 검사는 hooks로 연결해 실패 시 다시 고치게 만드는 것이 효과적이다.
6. 14:01
   CI와 오케스트레이터로 사람의 개입 줄이기 각 세션이 PR을 만들면 CI가 동일한 기준으로 검증하고, 필요하면 auto-fix와 merge when ready로 사람의 리뷰 부담을 줄일 수 있다. 더 나아가 하나의 오케스트레이터 세션이 하위 세션을 분배·검증하는 구조로 가면, 사용자는 여러 세션을 직접 관리하지 않고도 결과만 점검하게 된다.

실무 인사이트

• Claude Code를 잘 쓰는 핵심은 더 좋은 프롬프트를 쓰는 것보다, 모델·권한·샌드박스·CI를 각자 맡을 역할에 맞게 분리하는 것이다.
• 절대 하면 안 되는 것은 deny rule로 막고, 결과만 검토하면 되는 것은 모델과 검증 절차에 맡기는 식으로 위험도를 기준으로 통제 범위를 나누는 것이 실무적으로 가장 효율적이다.
• 장시간 자율 실행을 목표로 한다면, 세션 시작 전에 네트워크 접근·비밀 주입·테스트 트리거·PR 검증까지 한 번에 설계해야 중간에 사람이 다시 붙는 일을 크게 줄일 수 있다.