팀 도입 워크플로

혼자 잘 쓰는 것과 팀이 잘 쓰는 것은 다른 문제입니다. 파일럿 1명에서 팀 공용 CLAUDE.md·스킬, 리뷰 게이트, KPI까지 조직에 정착시키는 4단계.

16분 갱신

앞의 두 글로 하네스와 스킬을 개인 환경에 세웠다면, 이제 그것을 팀에 옮기는 문제가 남습니다. 한 사람이 잘 쓰는 팀은 많지만 그 사람이 휴가를 가도 자동화가 도는 팀은 드뭅니다. 이 글은 실전 코스의 마지막 페이지로, 우리가 초급 8주 마지막 수업의 수료 후 루틴 5가지와 개발팀 집중 과정 D-2(1일 8시간)에서 쓰는 4단계 정착 순서를 그대로 옮겼습니다. 읽고 나면 다음 분기 도입 계획을 주 단위로 쓸 수 있습니다.

핵심 요약

  • 순서는 파일럿 1명 → 팀 공용 CLAUDE.md·스킬 → 리뷰 게이트 → KPI입니다. 순서를 건너뛰면 도구만 남고 시스템은 안 남습니다.
  • 공용 규칙은 저장소에 커밋된 파일(CLAUDE.md, .claude/settings.json, .claude/skills/)만 인정합니다. 채팅에만 있는 규칙은 없는 규칙입니다.
  • 안전 경계는 permissions.deny와 훅으로 강제하고, 사람의 리뷰는 PR 한 곳에 모읍니다.
  • 측정은 작업 시간과 리뷰 반려율입니다. 감상은 KPI가 아닙니다.

1단계: 공통 기반 만들기 (1주)

파일럿 한 명이 먼저 한 달을 씁니다. 그 사람의 개인 CLAUDE.md에서 팀에도 참인 문장만 골라 프로젝트 ./CLAUDE.md로 옮기고 커밋합니다. 기준은 4주차에 배운 "정리된 폴더에서 일한다"입니다. 빌드·테스트 명령, 폴더 구조, 절대 규칙 세 종류만 넣고 200줄을 넘기지 않습니다. 개인 취향은 CLAUDE.local.md(gitignore)로 남깁니다. 주 단위로 반복된 지시가 있으면 .claude/skills/에 스킬로 올립니다. 이 주가 끝나면 새 팀원이 저장소를 받아 claude를 실행했을 때 파일럿과 같은 규칙을 보는 상태여야 합니다.

2단계: 검증 자동화 (2주)

사람이 읽는 규칙을 기계가 확인하는 검사로 바꿉니다. 첫 주는 PostToolUse 훅으로 파일 수정 뒤 린트·타입체크를 돌려 실패만 stderr로 돌려주고, 둘째 주는 Stop 훅에서 테스트 미실행 상태의 종료를 막습니다. 핵심 원칙은 앞 글과 같습니다. 통과는 조용히, 실패만 시끄럽게. 우리 8주 수업의 개발 루프(플랜모드 → 샘플 확인 → 오토모드 → 다른 AI 교차 체크 → 반복)에서 교차 체크 단계가 이 훅으로 대체됩니다. 결제·보안처럼 무거운 코드는 두 번째 모델의 읽기 전용 리뷰를 게이트로 둡니다.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/lint-changed.sh" }
        ]
      }
    ]
  }
}

3단계: 안전 경계 설정 (1주)

경계는 세 겹입니다. 첫째, permissions.deny로 .env·운영 접속 정보 읽기와 파괴적 명령을 막습니다. 둘째, ask로 push·배포를 사람 확인에 겁니다. 셋째, 브랜치 규칙입니다. 우리 CRM 프로젝트는 develop까지만 AI가 다루고 main은 대표가 직접 배포합니다. 이 세 가지를 프로젝트 settings.json에 커밋하면 개인 settings.local.json으로 완화할 수는 있어도 팀 파일은 그대로 남습니다. 조직 단위 강제가 필요하면 관리 설정(managed)이 모든 사용자 설정보다 우선합니다.

4단계: 지식 순환 만들기 (지속)

"실수는 규칙이 된다"를 운영으로 만듭니다. 리뷰에서 같은 지적이 두 번 나오면 그날 CLAUDE.md나 .claude/rules/에 한 줄 추가하고, 반복 절차는 스킬로 굳힙니다. 수료 후 루틴 5가지가 여기서 팀 버전이 됩니다. 작업 끝에 목적·변경·명령·결과·다음 작업 5요소를 기록하고, 무인 잡 로그를 아침에 확인하고, 작업 시간을 재고, 작은 단위로 만들고, 발견을 공유합니다. 주 1회 30분 "규칙 리뷰"에서 오래된 지시를 지웁니다. 규칙이 서로 모순되면 모델은 임의로 하나를 고릅니다.

도입 시 흔한 실패

  1. 도구 교육만 하고 저장소에 파일이 안 남음. 교육 다음 날 아무도 안 씁니다.
  2. 파일럿 없이 전원 동시 도입. 규칙이 없는 상태에서 각자 다른 습관이 굳습니다.
  3. CLAUDE.md에 규칙을 계속 쌓기만 함. 200줄을 넘으면 준수율이 떨어집니다.
  4. 성공 로그를 잔뜩 출력하는 훅. 실패가 묻혀 게이트가 무의미해집니다.
  5. 실데이터로 실습. 구조가 같은 모의 데이터로 연습하고 실데이터는 보안 점검 뒤에 붙입니다.

측정할 것

  • 작업 단위별 소요 시간(도입 전 대비). 8주 수업에서 매주 발표시키는 그 숫자입니다.
  • PR 리뷰 반려율과 반려 사유 분포. 사유가 규칙 파일로 옮겨지는 속도가 곧 정착 속도입니다.
  • 훅 차단 횟수. 처음엔 오르고 규칙이 학습되면 내려가야 정상입니다.
  • 무인 잡 가동률(로그 기준). 사람이 안 볼 때도 돌아야 자동화입니다.

비개발 직군까지 넓히기

개발팀이 3단계까지 갔다면 경영지원·마케팅으로 같은 틀을 복제합니다. 저장소 대신 업무 폴더, 테스트 대신 산출물 대조표가 검증이 됩니다. 4주차 고객 DB 표준 10항목처럼 "정리된 데이터"부터 만들고, 스킬은 문서 생성 한 종으로 시작합니다. 코드가 없어도 하네스 네 축은 동일합니다.

정리

  • 1주 기반, 2주 검증, 1주 경계, 그다음은 순환입니다.
  • 팀 규칙은 커밋된 파일만 인정합니다.
  • 측정은 시간·반려율·차단 횟수·가동률입니다.

다음 레슨

실전 코스는 여기서 끝납니다. 하루 만에 팀 공용 설정과 파이프라인 하나를 남기는 D-2 개발팀 집중 과정, 그리고 2주마다 한 번 여는 무료 특강에서 이 4단계를 실물로 볼 수 있습니다.

자주 묻는 질문

팀원 수가 세 명인데도 4단계가 필요한가요?

네, 기간만 줄어듭니다. 세 명이면 1단계와 3단계를 같은 주에 끝낼 수 있습니다. 순서를 지키는 것이 인원보다 중요합니다.

파일럿은 누가 맡아야 하나요?

가장 잘 쓰는 사람이 아니라 기록을 가장 꾸준히 하는 사람입니다. 파일럿의 산출물은 코드가 아니라 팀 CLAUDE.md 초안입니다.

개인 설정이 팀 설정과 충돌하면요?

우선순위는 관리 > 명령줄 > local > 프로젝트 > 사용자입니다. 개인은 settings.local.json에서 완화할 수 있지만 관리 설정은 넘지 못합니다.

D-2 과정에서는 4단계 중 어디까지 하나요?

하루 8시간 동안 1단계와 2단계를 실제 저장소에서 끝내고 3단계 파일 초안까지 남깁니다. 4단계는 수료 후 루틴으로 이어집니다.

팀 도입CLAUDE.md리뷰 게이트KPI권한D-2

팀에 클로드코드를 도입하려면 실제 업무에 맞춘 설계가 필요합니다. 무료 상담 신청 →