핵심 이슈: '도구를 쓴다'와 '워크플로우에 올린다'는 다르다
Claude Code를 개인 생산성 도구로 쓰는 것과, 팀 워크플로우에 통합하는 것은 차원이 다른 문제다. 전자는 프롬프트 잘 쓰는 개인의 문제고, 후자는 팀이 함께 따라야 할 실행 루틴과 역할 재정의의 문제다. 그리고 지금, 이 두 번째 문제를 먼저 풀지 않으면 속도보다 혼란이 먼저 온다는 신호들이 동시에 들어오고 있다.
1단계: 스펙이 없으면 코드도 없다
Dev.to에 공개된 스펙 주도 개발(Spec-Driven Development) 셋업 사례는 한 문장으로 요약된다. "No approved spec, no code changes." 이 원칙을 에이전트에게 강제하는 방식이 실전 설계의 첫 번째 축이다.
구체적으로는 CODEX.md에 아키텍처 경계, 커밋 정책, 워크플로우 게이트를 명문화하고, 에이전트는 반드시 spec-architect → agent-router → specialist 체인을 따르도록 구성한다. 각 스펙 파일(TASK-YYYY-MM-DD-###.spec.md)에는 scope_in, scope_out, validation 항목이 명시되며, 이 범위를 벗어난 수정은 워크플로우 실패로 간주한다.
핵심은 .codex/hooks/workflow-guard.sh로 정책을 문서가 아닌 커맨드 시점에 강제한다는 점이다. git add . 같은 광범위한 스테이징, 스펙 삭제 없는 커밋, 에이전트 파일 누락 등이 자동으로 블록된다. 정책은 기억하는 게 아니라 실행 시점에 걸려야 작동한다. 이게 '가이드라인'과 '워크플로우'의 차이다.
팀 리드 입장에서 이 구조의 가장 큰 효과는 리뷰 대화의 질이 바뀐다는 것이다. "여기서 왜 이 파일이 바뀌었지?"가 아니라 "이게 의도한 동작인가?"로 질문이 이동한다. 스펙이 이미 의도를 기록해뒀기 때문이다. 하루 뒤, 일주일 뒤 맥락을 재구성하는 비용도 사라진다. 스펙 상태와 evidence 파일이 세션 간 기억을 대신한다.
2단계: 세션 루틴—컨텍스트를 관리하는 팀이 AI를 잘 쓰는 팀이다
Dev.to의 Claude Code 슬래시 커맨드 실전 가이드에서 가장 중요하게 다루는 개념은 '컨텍스트 위생(context hygiene)'이다. Claude Code는 세션 시작부터 CLAUDE.md, 시스템 인스트럭션, 프로젝트 파일이 컨텍스트 윈도우를 점유한다. 작업이 쌓일수록 응답 품질이 조용히 저하된다.
팀 단위로 표준화할 만한 세션 루틴은 이렇다:
/cost→ 현재 토큰 소비량 확인/permissions→ 파일 읽기, 테스트 실행 등 반복 승인 작업 사전 허용Shift+Tab(Plan 모드) → 코드 작성 전 접근 방식 설계Shift+Tab(Normal 모드) → 계획 기반 구현/compact→ 50% 도달 전 컨텍스트 압축/model haiku→ 단순 수정 작업 시 모델 전환/clear→ 무관한 다음 태스크로 전환 전 완전 초기화
특히 /compact는 95% 도달 후가 아니라 50% 시점에 선제적으로 실행해야 한다. 가비지 컬렉션처럼, 메모리가 바닥난 뒤에 실행하면 이미 중요한 신호가 손실된다. /model 전환도 비용 절감이 주목적이지만, 팀 전체가 이 패턴을 쓰면 주 단위로 의미 있는 API 비용 차이가 생긴다.
이 루틴의 포인트는 개인의 습관이 아니라 팀 표준으로 문서화하는 것이다. CLAUDE.md에 팀의 세션 시작 프로토콜을 명시하면, 신입 팀원도 첫날부터 같은 컨텍스트 위생을 유지할 수 있다.
3단계: 리드의 역할 재정의—아티팩트가 아니라 결정이 일이다
Anthropic Claude Code 팀 헤드 Boris Cherny의 통계가 공개됐다. 지난 30일 동안 그가 Claude Code 제품에 기여한 코드의 100%는 Claude Code가 작성했다. 259개 PR, 497개 커밋, 4만 라인 추가, 3만8천 라인 삭제. 팀 헤드의 커밋 수는 0이다.
Dev.to에 게재된 이 통계 분석 글이 지적하는 핵심은, 대부분의 반응이 'AI 생산성이 증명됐다'는 표면 레이어에서 멈춘다는 것이다. 진짜 질문은 다른 데 있다. 팀 헤드가 하루 종일 하는 일이 코드 작성도, 첫 번째 리뷰어도 아니라면, 그 일은 무엇인가?
답은 '결정(decision)'이다. 무엇을 만들지, 무엇을 킬할지. 슬랙 스레드에서 "이거 배포해도 되나요?"에 두 문장으로 답하는 것. AI가 회귀를 플래그했을 때 롤백할지 포워드 픽스할지 콜하는 것. AI가 쓴 코드가 제품 의도에 맞는지 최종 판단하는 것. 이 순간들은 커밋 로그에 남지 않는다. 하지만 이것이 팀 아웃풋을 결정하는 일이다.
여기서 팀 리드가 실질적으로 설계해야 할 것이 생긴다. 기존 성과 측정 시스템은 아티팩트(PR 수, 코드 라인, 배포 빈도)를 기준으로 만들어졌다. AI가 아티팩트를 대신 생산하는 지금, 그 지표로 리드의 기여를 측정하면 완전히 틀린 숫자가 나온다. 콜 로그(call log)가 필요하다. 무엇을 결정했고, 대안은 무엇이었고, 결과는 어땠는지. 이것이 AI 시대 시니어 엔지니어링의 아티팩트다.
시사점: 세 단계가 하나의 흐름으로 연결될 때
스펙 설계 → 에이전트 실행 루틴 → 리드의 역할 재정의. 이 세 단계는 순서대로 의존한다. 스펙 없이 에이전트를 돌리면 scope 이탈과 리뷰 비용이 쌓인다. 세션 루틴 없이 팀이 Claude Code를 쓰면 컨텍스트 저하와 비용 낭비가 조용히 누적된다. 그리고 리드가 여전히 코드 작성량으로 기여를 증명하려 하면, 팀에서 가장 중요한 결정들이 측정되지 않은 채 흘러간다.
내가 팀 리빌딩에서 가장 먼저 하는 것도 이 순서다. CLAUDE.md와 스펙 템플릿을 먼저 만들고, 세션 루틴을 팀 표준으로 문서화하고, 그다음에 '리드의 하루에서 결정이 몇 번 일어나는가'를 가시화하는 구조를 만든다. 도구가 빠를수록 이 설계가 먼저여야 한다.
전망: 역할 압축은 이미 시작됐다
시니어 IC에서 스태프, 매니저, 디렉터로 올라갈수록 코드 작성에서 방향 설정으로 무게중심이 이동하는 건 예전부터 있던 커리어 아크다. 달라진 건 속도다. AI가 모든 레벨의 아티팩트 생산을 흡수하면서, 이 이동이 IC 레벨에서부터 시작된다. 주니어 개발자도 Claude Code로 PR을 양산하는 지금, 리드가 차별화해야 할 것은 더 많은 코드가 아니라 더 나은 결정이다.
팀 리빌딩을 앞두고 있다면 지금 당장 세 가지를 점검하라. 팀의 스펙 게이트가 문서인가, 강제인가. 세션 루틴이 개인의 습관인가, 팀 표준인가. 리드의 기여가 커밋 수로 측정되는가, 결정의 질로 측정되는가. 이 세 질문에 솔직하게 답할 수 있을 때, Claude Code는 비로소 팀 워크플로우 위에 올라간다.