Claude Code 모범 사례는 감독에서 시스템으로 옮겨가는 중이다

Lydia Hallie는 자신을 Anthropic의 Claude Code 팀 소속이라고 소개하면서, "최근 모델들이 정말 좋아졌다"는 관찰로 강연을 열었다. 그는 Opus 5.5를 자신이 매일 쓰는 가장 좋아하는 모델이라고 했고, 같은 주에 Fable 5.2가 출시됐다고 말했다. 그에 따르면 이 모델들은 장시간 작업과 코드베이스 이해에 매우 뛰어나며, 특히 Fable은 자신이 낸 결과물을 검증하는 데 강하다.

그는 모델이 나아지면서 Claude Code에서 사람들이 모델과 일하는 방식도 함께 바뀐다고 덧붙였고, 이것이 강연 나머지 부분의 전제가 됐다.

Hallie는 올해 초의 세션 모습을 설명했다. 그에 따르면 Opus 4.5는 당시 기준으로 매우 좋은 모델이었고 자신도 그 모델과 일하는 것이 즐거웠다. 하지만 오늘날의 모델과 비교하면 더 일찍 멈추고 더 짧게 작업했기 때문에, 개발자들은 계속 바로잡고 할 일을 상기시켜야 했다. 일부는 CLAUDE.md 파일에 "중요" 같은 단어나 느낌표를 붙였다. 아직 자동 모드가 없었기 때문에 사용자는 모든 동작을 수동으로 승인하거나, 더 위험한 방법인 dangerously-skip-permissions 옵션을 쓰는 수밖에 없었다. 그의 표현대로라면 사람이 여전히 루프 안에서 거의 모든 것을 직접 챙기던 시기였다.

모델이 더 큰 작업을 잘 처리하게 되면서 세션의 모습도 바뀌었다고 그는 말했다. 그에 따르면 Anthropic 내부에서는 지금 수십 개의 세션이 몇 시간씩 동시에 돌아가고, 각 세션이 중간에 스스로 결과를 검증하며, 일부 세션은 다른 세션을 조율하기도 한다. 그는 개발자의 역할이 거의 모든 단계에 개입하며 한두 개의 세션을 돌리던 위치에서, 수십 개의 세션을 관리하는 매니저 쪽으로 옮겨갔다고 설명했다.

그는 Anthropic이 10월에 올린 블로그 글도 인용했다. 그 글에 따르면 회사의 하루 변경 건수는 5월 약 2,500건에서 9월에는 3만 건 이상으로 늘었다. 그는 이를 개발자가 무엇에 집중할지 다시 생각해야 한다는 신호로 봤다.

Hallie는 개발자가 이제 무엇에 집중할지 다시 생각해야 한다고 말했다. 이전의 모범 사례는 주로 세션을 조종하고, 명령을 승인하고, 특정 행동을 거부하거나 Claude가 할 수 있는 일을 제한하고, 결과를 확인하고, 세션을 시작하는 것에 관한 것이었다. 그는 개발자가 그 루프에서 빠져나올 때마다 다른 무언가가 그 역할을 맡아야 하며, 그 무언가는 모델, 하네스, 혹은 모델이 돌아가는 환경 중 하나라고 설명했다.

그는 이로부터 나오는 두 가지 질문을 던졌다. 여러 세션을 동시에 돌리면서 사람이 모든 명령을 승인하지 않는다면 코드 품질을 어떻게 보장할 것인가? 세션이 몇 시간씩 감독 없이 돌아간다면 안전하게 돌아가도록 어떻게 보장할 것인가? 그리고 나머지 강연에서는 오래된 세션 하나를 예로 들어 무엇을 바꿔야 하는지 보여주겠다고 밝혔다.

Hallie는 새 세션이 지금 쓰는 기본값부터 시작했다. 그는 이 기본값에 대해 개발자가 크게 신경 쓸 필요가 없어야 한다고 말했다. 그는 모델을 Opus 4.5에서 Opus 5.5로 바꾸고, 권한 설정을 수동 승인에서 자동 모드로 바꿨다. 그에 따르면 Opus 5.5는 사용자의 의도와 코드베이스를 훨씬 잘 이해하므로 세션 중에 덜 조종해도 된다. 자동 모드는 8월부터 기본 권한 모드였기 때문에, 이제 개발자는 명령마다 승인할 필요가 없다.

Hallie는 새 모델이 의도를 더 잘 이해하므로 코드베이스의 지시문도 다시 점검해야 한다고 말했다. 이전 모범 사례를 따랐던 개발자는 CLAUDE.md에 "중요", "절대 하지 말 것" 같은 문구나 느낌표를 여전히 갖고 있을 수 있다. 그는 오늘날의 모델에는 이런 것들이 불필요하며, 오히려 모델을 엉뚱한 방향으로 이끌어 도구 호출이 늘고 전체 결과가 나빠질 수 있다고 말했다.

그가 현재 권하는 방식은 CLAUDE.md에 Claude가 코드에서 볼 수 없는 것만 담는 것이다. 예를 들어 어딘가 여전히 레거시 소스를 쓰지만 코드에서 직접 참조하지 않는 서비스가 있다면 그것은 남겨야 한다. 프로젝트가 어떤 스택을 쓰는지나 어디를 보면 되는지 같은 정보는 더 이상 필요 없다. 그는 CLAUDE.md와 스킬을 점검해 새 모델에 더 이상 필요 없는 것을 찾아내는 doctor prompt audit이라는 명령을 언급했고, 이것으로 특정 모델에 맞게 환경을 최적화하기 쉽다고 말했다.

Hallie는 자동 모드가 프로젝트 안의 파일 읽기와 편집을 제외하면 거의 모든 동작에 대해 별도의 분류기를 돌리는 권한 모드라고 설명했다. 테스트 실행이나 의존성 설치처럼 안전하다고 알려진 명령은 자동으로 허용하고, 안전한지 확신이 없는 명령은 차단한다. 그는 이것이 보통 올바른 동작이라고 말했다.

Hallie는 Claude에게 무언가를 스테이징에 배포하라고 요청하는 예를 들었다. 배포 저장소로의 push는 원래 승인됐을 명령이지만, 기본 설정에서 자동 모드는 현재 폴더와 저장소만 신뢰하기 때문에 이 명령을 차단하고 개발자를 다시 루프 안으로 끌어온다. 그는 자동 모드에서도 여전히 많은 명령을 승인해야 한다면 가장 먼저 설정을 확인하라고 했다. 자동 모드는 일반 영어로 설정할 수 있다. 그 텍스트는 분류기로 전달되어, 특정 명령을 거부할지 허용할지 판단하는 데 쓰인다. 개발자는 신뢰하는 저장소, 버킷, 도메인을 나열하고 무엇을 항상 허용하고 무엇을 절대 하지 말아야 하는지 적을 수 있다.

그는 오늘날의 기본값을 쓰는 것만으로도 루프 안의 작업 대부분이 이미 제거된다고 정리했다. 모델이 조종을 맡고, 자동 모드가 승인을 맡는다는 것이다. 더 어려운 질문은 매 단계에 사람이 함께 있지 않아도 괜찮도록 만드는 방법이었고, 그것이 안전성과 검증이라는 주제로 이어졌다고 말했다.

Hallie는 대부분의 경우 자동 모드가 사용자가 지시한 대로 행동하지만 그것이 보장은 아니라고 말했다. 그는 Anthropic이 8월에 발표한 연구를 인용했다. 이 연구는 자동 모드를 실제 사람이 루프에 있는 상태와 비교했다. 그 연구에서 분명히 위험한 명령을 알아챈 사람은 약 14%에 그쳤고, 자동 모드는 그 명령의 89%를 차단했다. 그는 이 점에서 자동 모드가 사람보다 훨씬 낫지만, 그래도 그런 명령 가운데 약 10분의 1은 통과했다고 말했다.

그의 결론은 진짜 보장은 하네스 안에서만 강제할 수 있다는 것이었다.

Hallie는 이런 이유로 권한에 관한 오래된 모범 사례도 여전히 중요하다고 말했다. 프로젝트에 특정 도구 호출에 대한 거부 규칙이 있다면, Claude Code는 자동 모드 분류기가 그 호출을 보기도 전에 그 규칙을 먼저 확인한다. 도구 호출이 거부 규칙에 걸리면 분류기는 그것을 전혀 보지 못한다. 그는 그래서 Claude가 어떤 일을 절대 하지 않도록 보장하는 가장 좋은 방법은 여전히 거부 규칙이라고 말했다.

이로부터 어떤 항목을 규칙으로 만들고 어떤 항목은 모델에 맡겨도 되는지가 질문으로 떠올랐다. 그의 기준은 Claude가 한 번 잘못했을 때 그 실수를 되돌릴 수 있는지였다. 잘못된 코드는 되돌릴 수 있으니 모델에 맡겨도 된다. 커밋되지 않은 변경을 버리거나, 키를 읽어서 그것이 대화 기록에 남는 일은 되돌릴 수 없으니 규칙으로 막아야 한다. 예로 그는 Claude가 특정 .env 파일을 읽는 것을 절대 원하지 않는다고 말했다. 자동 모드는 기본적으로 그 읽기를 허용하므로 거부 규칙을 추가해야 하며, 그렇게 하면 cat 같은 명령으로 파일을 여는 것도 막힌다고 설명했다.

Hallie는 명령에 부수 효과가 있기 때문에 권한 설정만으로는 문제가 단순하게 해결되지 않는다고 말했습니다. npm test는 자동 모드가 실행하는 평범한 명령이지만, 그 스크립트는 의존성이나 Claude가 무언가를 확인하려고 즉석에서 만든 짧은 스크립트처럼 개발자가 직접 작성하지 않은 코드를 실행합니다. 이들 중 하나가 침해되면 .env 파일이나 SSH 키를 열어 개발자가 들어 본 적도 없는 서버로 보낼 수 있습니다.

그녀는 사람이 모든 것을 여전히 승인하고 있었더라도 이 명령이 수상해 보이지 않으니 아마 허용을 눌렀을 것이라고 덧붙였습니다. 그녀의 요지는 권한이 결정하는 것은 도구 호출이 실행될지 여부뿐이며, 일단 실행되고 나면 무엇에 접근할 수 있는지는 제한하지 못한다는 것이었습니다. 테스트 실행은 Claude가 자신의 작업을 검증하는 일부이므로, 답은 npm test를 막는 것이 아니라 그것이 도는 환경을 제한하는 데 있다고 말했습니다.

Hallie는 로컬이나 자신의 기기에서 실행할 때 명령을 샌드박스 안에서 돌릴 수 있다고 말했습니다. 샌드박스는 명령이 어떤 파일을 읽을 수 있는지, 어떤 폴더에 쓸 수 있는지, 어떤 호스트에 접근할 수 있는지를 제어하며, 이 제한은 운영체제가 강제합니다. 제한은 자식 프로세스를 포함해 명령이 시작한 모든 것에 적용됩니다. 거부 규칙은 명령 실행 전에 Claude가 확인하지만, Claude는 "npm test"만 보고 스크립트가 결국 어떤 파일을 열지는 알지 못합니다. 샌드박스가 켜져 있으면 이 규칙이 운영체제로 전달되므로, 의존성이 .env 파일을 열려고 해도 운영체제가 허용하지 않습니다.

그녀는 기본 설정에서는 샌드박스가 기기의 대부분을 여전히 읽을 수 있으므로, 개발자가 SSH 키를 신경 쓴다면 별도의 규칙이 필요하다고 짚었습니다. 또한 승인되지 않은 호스트에는 접근할 수 없습니다. 다만 샌드박스가 다루는 범위는 Claude가 실행하는 셸 명령과 그것이 시작한 프로세스에 한정됩니다. Claude 자체의 파일, MCP 서버, 모든 훅은 샌드박스 밖에서 실행되므로 세션의 나머지 부분은 여전히 개발자의 기기에서 돌아갑니다. 그녀가 이상적으로 여긴 것은 이런 것이 아예 존재하지 않는 곳에서 전체를 실행하는 것이었고, 그것이 바로 클라우드 세션이라고 말했습니다.

Hallie는 클라우드 세션을 자체 기기에서 저장소의 새 사본을 받아 실행하고, 노트북을 닫아도 계속 돌아가는 세션으로 설명했습니다. 몇 시간씩 이어지는 긴 세션에는 이 점이 중요하다고 강조했습니다. 이 구성에서는 .env 파일 문제가 사라지는데, 그 파일이 git에 들어 있지 않기 때문입니다. SSH 키와 GitHub 토큰도 기기에 없습니다. 세션에 여전히 API 키가 필요하면 네트워크 시크릿으로 추가할 수 있습니다. 세션은 중간에 API 키가 없다는 사실을 표시하고, 키가 모델에 전달되지 않은 채로 사용할 수 있습니다.

기본적으로 클라우드 세션의 네트워크 접근은 패키지 레지스트리와 GitHub 같은 대상으로 제한됩니다. 다른 호스트는 환경에 명시적으로 추가해야 합니다.

Hallie는 클라우드 세션에서는 노트북을 닫은 채로도 장시간 세션이 계속 진행될 수 있고, 자체 환경에서 실행되므로 안전하다고 말했습니다. 다만 기기는 일회용이지만 기기 밖으로 나가는 것은 그렇지 않다고 경고했습니다. 푸시되는 커밋이나 커넥터를 통해 보내는 메시지가 그 예입니다. 그녀는 여전히 거부 규칙을 둔 자동 모드로 세션을 실행하며, 커밋은 저장소에 들어가므로 그 뒤로도 이어지기 때문에 강제 푸시나 커밋에 포함된 비밀 값 같은 것을 검사로 잡아낼 수 있다고 말했습니다.

Hallie는 안전 외에도 개발자가 Claude가 올바른 일을 하고 있는지 확인해야 한다고 말했습니다. 루프 안에서는 사람이 모든 변경을 보고 승인했기 때문에 결과물이 좋다는 것을 알았습니다. 이제 Claude는 몇 시간씩 백그라운드에서 일하고, 개발자는 마지막에도 모든 파일을 읽지 않을 것입니다.

그녀는 코드를 새 API로 옮기는 작업을 예로 들었습니다. Claude는 원하는 것을 잘 이해하지만 여전히 작은 결정을 많이 내립니다. 정확히 같은 프롬프트로도 한 번은 코드를 옮기고 이전 API는 그대로 두고, 다른 번은 새 로그인에만 적용하고, 또 다른 번은 옮기되 모든 사용자를 로그아웃시킬 수 있습니다. 모두 합리적으로 보이기 때문에, 중간중간 검증 지점을 두는 것이 도움이 된다고 말했습니다. 테스트, 빌드, 스크린샷처럼 통과 또는 실패를 반환하는 것이면 모두 해당됩니다. 체크포인트를 검토하는 것은 마지막에 전체 변경을 검토하는 것보다 훨씬 짧습니다. 그녀의 예에서 모든 사용자를 로그아웃시키는 버전은 첫 번째 검사에서 실패했고, 다른 방법을 찾아야 했습니다.

Hallie는 검증을 설정하는 가장 쉬운 방법은 프롬프트에 있다고 말했습니다. 완료가 어떤 상태인지 명시하고, Claude에게 작업을 각자 테스트를 갖는 과제로 나누도록 요청하며, 개발자가 옆에서 지켜보지 못했으므로 실제 출력을 보여 달라고 요청하라는 것입니다. 다만 프롬프트가 모델이 그렇게 한다는 보장은 아니라고 강조했습니다. 반드시 실행되어야 하는 검사에는 훅을 권장했습니다. 훅은 Claude Code가 특정 시점에 실행하는 스크립트입니다. 훅을 쓰면 개발자가 언제 실행할지, 무엇을 실행할지, 무엇을 확인할지를 정할 수 있으므로 통제가 가능합니다.

그녀의 예는 이렇습니다. Claude가 파일을 편집할 때마다 린터를 실행하고, 작업을 완료로 표시할 때마다 바꾼 부분에 해당하는 테스트를 실행합니다. 인증 코드를 건드렸다면 인증 테스트를 통과해야 합니다. 세션이 모두 끝나면 전체 테스트 스위트를 실행합니다. 검사가 실패하면 Claude는 통과할 때까지 돌아가 문제를 고칩니다. 그녀는 한 가지 주의점을 덧붙였습니다. 테스트가 실패하면 대부분의 도구는 종료 코드 1로 끝나지만, Claude Code는 종료 코드 1이어도 작업을 완료로 표시한다는 것입니다. 따라서 Claude가 실제로 돌아가 문제를 고치게 하려면 스크립트가 종료 코드 2로 끝나도록 해야 합니다.

Hallie는 한 세션을 믿고 혼자 두어도 된다는 확신이 생기면, 각 세션이 자체 기기를 갖기 때문에 몇 개를 더 시작할 수 있다고 말했습니다. 세션들이 모두 같은 폴더에서 작업하지는 않으며, 개발자가 git worktree를 직접 신경 쓸 필요도 많지 않습니다. 그녀는 여전히 모든 세션을 직접 시작하고 모든 세션을 검토한다고 말했습니다. 그녀는 이것이 이미 꽤 좋은 상태라고 설명했습니다. 무엇을 언제 시작할지, 작업이 언제 완료되었다고 볼지는 사람이 완전히 통제하며, 모든 세션을 직접 시작하고 모두에서 루프 안에 머무르고 있다는 것입니다.

Hallie는 지금 갖춰야 할 가장 중요한 것이 CI라고 말했습니다. 모든 세션은 결국 풀 리퀘스트를 열게 되는데, CI는 세션이 어떻게 설정되었는지, Claude가 과정에서 무엇을 결정했는지와 상관없이 각 풀 리퀘스트에 같은 검사를 실행하기 때문입니다. CI 자동 수정을 켜면 Claude는 이들 검사 중 실패한 것을 확인하고 돌아가 고칠 수 있으므로, 검사가 이미 잡아낼 수 있는 문제에 개발자가 검토 시간을 쓰지 않아도 됩니다.

일부 변경은 준비되면 병합하는 방식을 켤 수 있다고 말했습니다. 모든 검사가 통과하면 GitHub이 풀 리퀘스트를 병합하므로 아무도 검토할 필요가 없습니다. 기본 설정은 아니며 변경의 위험도에 따라 달라진다고 덧붙였습니다. 그녀의 팀에서는 모든 풀 리퀘스트를 먼저 Claude가 검토하는데, 작성한 세션이 아니라 별도로 검토합니다. 이 검토는 새로운 맥락에서 이루어지고, 발견된 각 버그를 따로 이중 확인하는 별도의 에이전트 그룹이 함께 돕습니다. 그 위에 사람이 얼마나 더 검토할지는 위험도에 따라 다릅니다. 문서 문구 같은 작은 변경은 자동 검사가 모두 통과하면 사람이 필요 없고, 일반 제품 변경은 검토자 한 명이 필요할 수 있으며, 위험한 변경은 두 명이 필요할 수도 있습니다.

Hallie는 흐름이 향하는 방향이자 Anthropic이 이미 더 많이 하고 있는 일은, 개발자가 모든 세션을 직접 시작하지 않는다는 것이라고 말했습니다. 그녀는 여러 작업 스레드를 추적하는 데 자신이 서툴다고 인정했습니다. 대신 하나의 메인 세션이 오케스트레이터 역할을 합니다. 개발자가 무엇이 필요한지 말하면, 오케스트레이터가 작업을 나누고 각 과제마다 다른 세션을 시작하며 돌아오는 결과를 관리합니다. 실제로 끝나지 않은 결과가 돌아오면 완료되고 모든 검사를 통과할 때까지 되돌려 보냅니다. 오케스트레이터에는 Fable처럼 판단과 결과 평가에 강한 모델이 필요하고, 작업 스레드에는 Opus 5.5처럼 실제 작업에 강한 모델이 필요하며, 두 모델은 따로 설정할 수 있다고 말했습니다. 그녀는 코드 프로젝트에서는 이제 맥락 관리가 자동으로 이루어지므로 언제 압축하고 비울지 고민할 필요가 없다고 덧붙였습니다.

그녀의 요약은 이렇습니다. 오래된 모범 사례는 모두 여전히 존재하지만 자리를 옮겼습니다. 모델이 이제 방향을 잡고, 자동 모드가 거부 규칙 안에서 승인하며, 환경이 가능한 범위를 제한합니다. 테스트, 훅, CI는 작업을 검사합니다. 그리고 Claude가 세션 자체를 시작할 수도 있습니다. 사람은 이제 주로 첫 세션을 시작하고 그 결과를 검토하는 역할을 맡습니다. 그녀가 제시한 첫 단계는 평소보다 훨씬 큰 작업 하나를 고르고, CI가 중요한 것을 잡아내는지 확인하며, 환경의 네트워크 접근, 시크릿, 설정 스크립트를 구성하고, 클라우드에서 시작한 뒤 세션이 어디서 막히는지, 개발자가 여전히 어디서 루프 안에 있는지 살피는 것이었습니다. 그것이 Claude에게 다음으로 넘겨야 할 부분이기 때문입니다. 그녀는 모범 사례 문서도 함께 읽어 보라고 추천했습니다.