팀 표준을 '입'으로 설명하던 시대는 끝났다
테크 리드로서 가장 자주 반복하는 말이 뭔지 아는가. "우리 팀 컨벤션 따라서 해줘." 그런데 그 컨벤션이 어디 있냐고 물으면—CONFLUENCE에 묻혀 있거나, 누군가의 머릿속에 있거나, 그냥 구두로 전달된다. AI 코딩 어시스턴트를 도입했더니 이 문제가 더 선명하게 드러났다. AI는 팀 컨벤션을 모른다. 매번 프롬프트로 설명해야 한다. 그 비용이 쌓이면, AI 도입의 속도 이득이 반쯤 상쇄된다.
최근 두 가지 업데이트가 이 문제를 정면으로 겨냥했다. Claude Code의 커스텀 슬래시 명령어(스킬 통합 모델)와 Claude Cowork의 화면 녹화 기반 스킬 학습이다. 표면상 별개 기능처럼 보이지만, 본질은 같다. 팀의 암묵지를 재사용 가능한 구조물로 굳히는 것.
Claude Code 슬래시 명령어: 명령어가 스킬이 됐다
dev.to의 Rulestack 분석에 따르면, Claude Code의 커스텀 슬래시 명령어는 이제 '스킬' 모델로 통합됐다. 기존 .claude/commands/ 파일은 그대로 작동하지만, 권장 경로는 .claude/skills/다. 차이가 뭔가?
단순 명령어는 마크다운 한 파일로 끝났다. 스킬은 그 위에 세 가지를 더한다. 첫째, 지원 파일 디렉터리—템플릿, 스크립트, 레퍼런스 문서를 필요할 때만 로드한다. 둘째, 호출 주체 제어—/deploy나 /commit처럼 부작용이 있는 스킬은 disable-model-invocation: true로 사람만 실행 가능하게 잠근다. 반대로 user-invocable: false로 Claude만 로드하는 백그라운드 컨텍스트 스킬도 만들 수 있다. 셋째, 자동 호출—대화 맥락이 스킬 description과 매칭되면 Claude가 알아서 불러온다.
실전에서 팀 리드가 챙겨야 할 포인트는 allowed-tools 동작 방식이다. 이게 세션 설정이 아니라 한 턴짜리 권한이라는 걸 모르면 "왜 또 권한 물어봐?" 혼란이 생긴다. 프론트매터에서 Bash(git commit:*)를 선언해도, 다음 메시지를 보내는 순간 그 권한은 사라진다. 스킬을 재호출해야 다시 적용된다. 세션 전체에서 유지하고 싶다면 permission rules 쪽에서 관리해야 한다.
또 하나, !\git diff HEAD`` 같은 라이브 데이터 인젝션 기능은 생각보다 강력하다. Claude가 프롬프트를 받는 시점에 실제 diff 내용이 이미 주입된다. AI한테 "diff 가져와서 분석해" 시키는 것보다 한 라운드트립이 줄고, 모델이 diff를 '요약'해서 날리는 사고도 막는다.
Claude Cowork: 시연하면 스킬이 된다
Claude Code가 개발자 워크플로우를 스킬로 구조화하는 방식이라면, Claude Cowork는 비개발 업무 영역까지 스킬화 범위를 넓힌다. AI 매터스 보도에 따르면, Anthropic이 업데이트한 Claude Cowork는 화면 활동을 음성 설명과 함께 녹화하면 Claude가 이를 재사용 가능한 스킬로 변환한다.
이게 왜 중요하냐면—대부분의 사람은 자신이 매일 하는 작업을 정확하게 문서로 쓰지 못한다. SOP 작성 경험이 있는 팀 리드라면 이 고통을 안다. 막상 쓰려고 하면 빠뜨린 단계가 생기고, 판단 기준이 누락된다. 그런데 실제로 작업하면서 "이 항목이 이 조건이면 이렇게 처리해" 하고 말로 설명하면? 기계적 단계와 판단 논리가 동시에 포착된다. 이게 범용 모델이 작업을 안정적으로 재현하는 데 필요한 정보의 정체다.
두 접근이 합쳐지면 팀에 생기는 변화
테크 리드 관점에서 이 두 업데이트를 같이 보면 패턴이 보인다. 팀 워크플로우 표준화의 인터페이스가 텍스트 문서에서 스킬 파일과 화면 녹화로 이동하고 있다.
실용적으로 정리하면 이렇다:
-
개발 사이드:
/fix-issue,/code-review,/migrate-component같은 스킬로 팀 컨벤션을 명령어 한 줄에 압축. 스킬 파일은 Git으로 버전 관리되고, PR로 변경한다. "AI한테 우리 팀 방식대로 해달라"를 매번 설명하는 비용이 사라진다. -
비개발 사이드: 문서화하기 어려운 SOP, 반복 업무 절차를 녹화 한 번으로 스킬화. 온보딩 때 신규 팀원한테 설명하던 그 작업들이 Claude가 재현 가능한 형태로 저장된다.
스킬이 팀 전체에서 공유되면, 암묵지가 조직 자산으로 바뀐다. 누군가 퇴사해도 그 사람의 작업 방식은 스킬 파일로 남는다.
냉정하게 짚어야 할 것들
낙관론만 늘어놓으면 곤란하다. 현장에서 이 구조를 굴릴 때 실제로 부딪히는 문제들이 있다.
스킬 품질은 입력 품질에 달렸다. Claude Code 슬래시 명령어 스킬은 마크다운을 잘 쓰는 사람이 잘 짠다. 팀원 모두가 즉시 잘 짤 수는 없다. 초기에는 테크 리드가 핵심 스킬을 설계하고, 팀이 점진적으로 기여하는 구조가 현실적이다. Cowork의 화면 녹화도 마찬가지—설명 없이 그냥 클릭만 녹화하면 스킬 품질이 떨어진다. 말로 판단 논리를 설명하는 습관을 팀에 심는 게 선행 과제다.
스킬 거버넌스는 별도로 설계해야 한다. 스킬이 늘어나면 관리 문제가 생긴다. 낡은 스킬, 중복 스킬, 충돌하는 스킬. dev.to의 Quentin Merle가 지적했듯, 스킬 파일을 Git으로 관리하고 PR 리뷰 프로세스를 붙이는 게 장기적으로 유일한 해법이다. AI 동작 변경이 Pull Request가 되는 구조.
allowed-tools 범위는 보수적으로 설계하라. 스킬에 너무 넓은 Bash 권한을 주면 보안 표면이 커진다. /deploy 류는 반드시 disable-model-invocation: true로 잠그고, 도구 범위는 해당 스킬이 실제로 필요한 것만 선언한다.
팀 워크플로우 표준화의 새 인터페이스
지금 AI-First 팀들이 겪는 공통 문제는 속도는 올라갔는데 일관성이 떨어진다는 것이다. AI가 코드를 빠르게 생성하지만, 팀 컨벤션을 모르니 리뷰 부담이 늘어난다. 스킬은 이 간극을 메우는 구조적 해법이다.
내일 당장 시작할 수 있는 것: 팀에서 가장 자주 쓰는 Claude 프롬프트 세 개를 뽑아라. 그걸 .claude/skills/에 마크다운으로 떨어뜨려라. 거기서 시작하면 된다. 완벽한 스킬 라이브러리를 한 번에 만들려고 하지 말고, 반복 사용하는 것부터 스킬로 굳히는 습관을 팀에 심는 게 우선이다.
슬래시 명령어 하나가 팀 표준 문서 10페이지보다 AI한테는 더 유용하다.