Claude Code를 팀에 도입하려는 리드들이 가장 많이 하는 실수는 '모델 성능 검증'에 시간을 쏟는 것이다. 모델은 이미 충분히 좋다. 진짜 문제는 그 다음이다—컨텍스트를 어떻게 유지할 것인가, 에이전트에게 어떤 도구를 허용하고 어떤 도구를 막을 것인가, 그리고 그 결정을 팀 전체에 어떻게 강제할 것인가.
60일 실전이 증명한 것: 도구 선택이 성과를 결정한다
dev.to에 공개된 한 ERP 개발자의 60일 프로덕션 운영 기록은 이 질문에 구체적으로 답한다. 11만 8천 줄짜리 ERP를 Claude Code로 단독 운영하며 살아남은 도구 목록—12개. 핵심은 '무엇을 살렸는가'보다 '무엇을 왜 버렸는가'에 있다.
가장 먼저 눈에 띄는 건 CLAUDE.md의 ROI다. 프로젝트 루트에 위치한 이 파일은 세션이 열릴 때 자동으로 로드되며, 스택 컨벤션을 에이전트에게 주입한다. 없으면? 에이전트는 매 세션마다 Next.js 16이 훈련 데이터의 버전과 다르다는 사실을 재발견하느라 한 시간을 쓴다. 있으면? 첫 이터레이션부터 Server Components에 onClick 핸들러를 쓰지 않는다. 세션당 절약되는 시간이 하루 5~10 세션에 곱해지면 이건 명백한 팀 인프라다.
훅(hooks) 설계는 더 흥미롭다. deploy-safeguard.sh는 처음에 두 개의 금지 패턴으로 시작했다가, 위장된 명령어가 필터를 우회할 뻔한 사건 이후 여섯 개로 확장됐다. check-workaround-assumed.sh는 v0.2에서 fix와 temp 패턴을 포함했다가 60%의 false positive를 내뿜은 뒤 실제 워크어라운드 어휘에만 집중하도록 좁혔다. 이게 운영이다—처음부터 완벽한 설계는 없고, 실패를 통해 정밀해지는 구조가 있을 뿐이다.
반면 Computer Use MCP는 드롭됐다. 이유는 단순하다. 토큰 비용이 일반 세션의 10배. 세 개의 버튼을 클릭하기 위해 10배를 쓰는 건 팀 예산 문제이기 전에 판단력의 문제다. 도구는 기능이 아니라 비용-편익으로 평가해야 한다.
권한 시스템: 보기보다 훨씬 정교하고, 실수하기도 쉽다
도구를 고르는 것만큼 중요한 게 에이전트에게 그 도구를 어디까지 쓰게 할 것인가다. Claude Code의 권한 시스템은 settings.json 하나로 운영되지만, 작동 방식이 직관을 배반하는 지점이 여러 곳 있다.
dev.to의 권한 시스템 분석에 따르면, 가장 먼저 이해해야 할 원칙은 deny가 항상 이긴다는 것이다. 규칙 평가 순서는 deny → ask → allow 고정이고, CSS나 방화벽 규칙처럼 더 구체적인 규칙이 더 넓은 규칙을 override하지 않는다. 즉, deny: ["Bash(aws *)"]와 allow: ["Bash(aws s3 ls)"]를 동시에 쓰면 aws s3 ls는 차단된다. deny가 먼저 매칭됐기 때문이다. 팀에서 자주 보이는 설정 실수가 바로 이것—'특정 명령은 허용하되 나머지는 막겠다'는 의도로 deny+allow를 섞었다가 의도한 대로 동작하지 않는 경우다.
스코프 설계도 중요하다. 권한 파일은 네 레벨로 나뉜다: 엔터프라이즈 managed → 사용자(~/.claude/settings.json) → 프로젝트(.claude/settings.json) → 로컬(.claude/settings.local.json). 여기서 대부분의 설정은 하위 스코프가 상위 스코프를 override하지만, 권한 규칙은 merge된다. 사용자 레벨의 deny와 프로젝트 레벨의 deny가 동시에 적용된다는 뜻이다. 팀 공통 가드레일은 프로젝트 설정에, 개인 보호는 사용자 설정에 넣고, 두 레이어가 독립적으로 작동한다고 이해하는 게 맞다.
조용히 아무것도 안 하는 규칙도 알아둬야 한다. Write(path), NotebookEdit(path), Glob(path) 형태의 경로 규칙은 JSON이 파싱되고 Claude Code가 정상 실행되지만, 실제로는 참조되지 않는다. v2.1.210 이후 버전에서는 시작 시 경고를 내뱉지만, 이전 버전에서는 규칙이 적용되는 것처럼 보이면서 사실은 아무것도 막지 않는다. 파일 경로를 보호하려면 Edit(...)과 Read(...)를 써야 한다.
팀에 적용할 때 실제로 해야 할 것들
두 소스에서 공통으로 드러나는 패턴은 하나다—운영 구조는 에이전트 성능보다 먼저 설계되어야 한다. 실무적으로 팀 도입 시 우선 순위를 정리하면 이렇다.
첫째, CLAUDE.md를 팀 컨벤션의 단일 진실 공급원으로 만들어라. 에이전트가 매 세션마다 같은 실수를 반복하고 있다면, 그건 모델 문제가 아니라 컨텍스트 주입 실패다. 둘째, 권한 설계는 프로젝트 설정(.claude/settings.json)에 팀이 합의한 가드레일을 명시하는 것부터 시작해라. deny 리스트를 먼저 채우는 게 allow 리스트를 정교하게 만드는 것보다 안전하다. 셋째, 훅은 '무엇을 막을 것인가'가 아니라 '어떤 실패가 실제로 발생했는가'를 기준으로 추가해라. 60일 실전 데이터가 보여주듯, 훅은 사후 학습의 구조화다.
전망: 설계 부채가 먼저 쌓인다
Claude Code는 빠르게 채택되고 있다. 하지만 빠른 채택이 낳는 건 생산성보다 설계 부채가 먼저인 경우가 많다. 권한 규칙을 잘못 이해한 채로 팀 전체가 동일한 실수를 공유하거나, CLAUDE.md 없이 에이전트가 매일 같은 컨벤션 오류를 반복하거나, 훅 없이 프로덕션 배포 명령이 에이전트 세션에서 실행 가능한 상태로 남아있는 것—이것들이 지금 대부분의 팀이 만들고 있는 조용한 위험이다.
도구를 고르는 판단력, 권한 경계를 구조로 만드는 능력, 실패에서 훅을 추출하는 운영 감각—이것이 AI-First 팀에서 테크 리드가 실제로 설계해야 할 것들이다. Claude Code가 코드를 짜는 속도는 이미 충분히 빠르다. 그 속도를 팀이 감당할 수 있는 구조를 만드는 것, 그게 지금 해야 할 일이다.