- Claude Code가 팀 도구로 중요한 이유
- Claude Code가 할 수 있는 일
- 설정은 계층적으로 관리해야 한다
- 메모리는 팀, 개인, 조직으로 나눠야 한다
- subagents 는 컨텍스트 분리용이다
- hooks 는 강력하지만 조심해서 써야 한다
- 팀 롤아웃의 핵심은 shared memory 와 policy 다
- Claude Code와 GitHub 중심 cloud agent의 차이
- 흔한 실수
- 롤아웃 순서
- References
Claude Code가 팀 도구로 중요한 이유
Claude Code는 Anthropic의 agentic coding tool로, 터미널 안에서 동작한다. 이게 핵심이다. 많은 AI 코딩 도구가 채팅 창을 하나 더 만드는 데 머무를 때, Claude Code는 이미 개발자가 일하는 터미널에 들어와 직접 파일을 수정하고, 명령을 실행하고, 커밋을 만들고, 필요한 경우 claude -p로 스크립트처럼 돌릴 수 있다.
즉, 이 도구는 대화형 비서라기보다, 터미널 작업 흐름에 붙는 실행형 에이전트에 가깝다.
Claude Code가 할 수 있는 일
공식 문서 기준으로 Claude Code는 다음을 할 수 있다.
- 파일을 직접 편집한다
- 명령을 실행한다
- 커밋을 만든다
- MCP를 사용해 외부 도구와 연결한다
claude -p로 스크립트처럼 호출된다
이 점 때문에 Claude Code는 단일 질문 응답보다 실제 작업 수행에 더 강하다. 로컬 검증, 리팩터링, 린트 수정, PR 준비 같은 흐름과 잘 맞는다.
설정은 계층적으로 관리해야 한다
Claude Code 설정은 계층 구조를 가진다.
~/.claude/settings.json은 사용자 전역 설정이다.claude/settings.json은 팀이 공유하는 프로젝트 설정이다.claude/settings.local.json은 개인 실험이나 로컬 전용 설정이다
이 구조가 좋은 이유는 팀 규칙과 개인 취향을 분리할 수 있기 때문이다. 팀은 프로젝트 설정으로 기본 행동을 맞추고, 개인은 로컬 설정으로 자기 작업 스타일만 조정하면 된다.
메모리는 팀, 개인, 조직으로 나눠야 한다
Claude Code의 memory 문서는 이 도구를 잘 쓰려면 매우 중요하다.
./CLAUDE.md는 프로젝트 메모리다~/.claude/CLAUDE.md는 사용자 메모리다- enterprise policy 메모리는 조직 전체에 적용된다
실무적으로는 ./CLAUDE.md 에 프로젝트 구조, 빌드 방법, 테스트 명령, 커밋 규칙, 자주 틀리는 주의점을 적어 두는 것이 가장 효과적이다. 개인 메모리는 각자 자주 쓰는 도구나 스타일을 보관하는 용도로 두면 된다.
subagents 는 컨텍스트 분리용이다
Claude Code 문서에서 subagents의 장점은 분명하다. 각 subagent는 별도의 context window를 쓰고, 특정 tools를 갖도록 설정할 수 있다. 이건 팀 운영에서 꽤 강력하다.
- 리뷰 전용 subagent
- 테스트 전용 subagent
- 문서 전용 subagent
- 마이그레이션 전용 subagent
이렇게 나누면 한 에이전트가 모든 일을 다 하느라 문맥을 오염시키는 문제를 줄일 수 있다. 특히 큰 저장소에서는 subagent 분리가 품질에 직접적인 영향을 준다.
hooks 는 강력하지만 조심해서 써야 한다
hooks는 실행 중 특정 지점에서 shell command를 돌릴 수 있게 해 준다. 검증, 로깅, 보안 검사, 워크플로 자동화에 유용하다. 하지만 공식 문서도 분명히 말한다. hook command를 추가하기 전에 반드시 검토하고 이해해야 한다.
실무 원칙은 단순하다.
- 먼저 읽고 이해한 뒤에 추가한다
- 파일 경로는 절대 경로로 둔다
- 민감한 파일은 제외한다
- 검증용 hook과 파괴적 hook을 섞지 않는다
hook은 자동화의 끝이 아니라, 관리되는 자동화의 시작점으로 봐야 한다.
팀 롤아웃의 핵심은 shared memory 와 policy 다
Claude Code를 팀에서 잘 굴리려면 기능보다 운영 규칙이 먼저다.
- 프로젝트마다
./CLAUDE.md를 만든다 - 기본 설정은
.claude/settings.json에 둔다 - 개인 취향은
.claude/settings.local.json으로 분리한다 - 위험한 명령은 permissions 또는 deny 규칙으로 제한한다
- hooks 를 넣기 전에는 반드시 검토 절차를 둔다
- 반복 작업은 subagent 로 분리한다
이 순서를 지키면 팀 전체가 같은 기본 동작을 공유하면서도, 개인별 실험은 안전하게 남길 수 있다.
Claude Code와 GitHub 중심 cloud agent의 차이
Claude Code는 터미널 우선이다. 개발자가 이미 있는 곳에서 직접 일한다. 반면 GitHub Copilot cloud agent는 GitHub 우선이다. 이슈, 브랜치, PR, 리뷰를 GitHub 안에서 묶는다.
둘의 차이는 이런 식으로 정리할 수 있다.
- 빠른 로컬 수정과 명령 실행은 Claude Code가 잘 맞는다
- GitHub 안에서 비동기적으로 작업을 맡기고 싶다면 cloud agent가 더 맞는다
- 팀 규칙과 실행 정책을 세밀하게 다루려면 Claude Code의 settings와 hooks가 유리하다
두 도구는 경쟁 관계라기보다, 개발 흐름의 다른 지점에 놓인 도구다.
흔한 실수
Claude Code를 도입할 때 자주 보이는 실수는 다음과 같다.
CLAUDE.md를 개인 메모 수준으로만 두고 팀 규칙을 넣지 않는다settings.local.json과 공유 설정을 섞어 버린다- subagent 없이 하나의 큰 컨텍스트에 모든 일을 몰아넣는다
- hooks 를 검토 없이 추가한다
- MCP 도구를 너무 빨리 넓혀서 권한이 과해진다
특히 hooks 는 편리하지만, 잘못 쓰면 자동화가 아니라 사고 지점이 된다.
롤아웃 순서
안전한 도입 순서는 대체로 다음과 같다.
CLAUDE.md로 프로젝트 기준을 정한다- 공유 설정과 로컬 설정을 분리한다
- 자주 반복되는 작업을 subagent 로 만든다
- 필요한 경우에만 MCP 도구를 연결한다
- hooks 는 검증용부터 천천히 도입한다
- 위험 명령과 민감한 파일 접근은 명시적으로 제한한다
이렇게 하면 터미널 자동화의 속도는 살리면서도, 팀 전체의 안전성은 유지할 수 있다.