클로드코드 팀 하네스 만들기: 다직무 협업 스킬·메모리 설계

개발자 한 명이 터미널 앞에서 클로드 코드를 켜던 시절은 지나가고 있다. 개발·기획·아트가 하나의 프로젝트 레포지토리를 함께 들여다보며 각자의 방식으로 클로드 코드를 쓰는 '팀 하네스' 구성이 커뮤니티에서 화두로 떠올랐다. 문제는 세 직무가 원하는 도구와 규칙이 서로 다르다는 데 있다. 이 기사는 클로드 코드의 스킬·메모리·권한 구조를 실제 운영 사례와 엮어, 다직무가 부딪히지 않고 함께 쓰는 팀 하네스를 어떻게 설계하는지 정리한다.

코드를 안 짜는 사람도 클로드 코드를 쓴다

클로드 코드가 개발자 전용 도구라는 인식은 이미 낡았다. Anthropic 자체 조직에서도 법무·마케팅·디자인·재무 등 비개발 부서가 일상 업무에 클로드 코드를 쓰고 있으며, 사내 직군은 'Member of Technical Staff'라는 하나의 타이틀로 통일돼 있어 기획자와 디자이너도 엔지니어와 나란히 코드를 다룬다는 사실이 여러 매체를 통해 알려졌다. 이들이 클로드 코드를 쓰는 방식은 기능을 새로 만드는 것과는 거리가 멀다. CSV를 정리하거나, 피드백을 주제별로 세는 것처럼 손은 많이 가지만 우선순위에서 밀리는 자잘한 업무를 코드 생성으로 대신 처리하는 식이다. 디자이너 쪽은 Figma MCP 연동으로 디자인 파일의 구조화된 컨텍스트를 직접 끌어오는 사례도 보고된다.

게임 업계에서는 한발 더 나아가, 클로드 코드 세션 자체를 스튜디오처럼 구성하려는 시도도 있다. 커뮤니티에 공개된 한 오픈소스 프로젝트는 디렉터·아트 디렉터·디자인 리드 같은 역할을 맡는 수십 개의 서브에이전트와 수십 개의 워크플로우 스킬을 묶어, 실제 게임 스튜디오의 조직 구조를 세션 안에 재현한다. 클코단 방에서 나온 개발·기획·아트가 함께 쓰는 팀 하네스 요청도 같은 맥락이다. 다만 방에서 오간 논의는 이렇게 거창한 시스템보다는, 실제로 운영 중인 팀이 스킬과 메모리를 어떻게 나눠 썼는지에 초점이 맞춰져 있었다.

스킬은 공용 배포, on/off는 프로필별로

클로드 코드의 Skills는 SKILL.md 파일 하나에 지시문·스크립트·참고자료를 묶어 필요할 때만 불러오는 폴더 단위 기능이다. 개인용 스킬은 홈 디렉터리의 `~/.claude/skills/`에, 프로젝트(팀) 스킬은 레포지토리 루트의 `.claude/skills/`에 두고 깃으로 커밋하면 팀원 전체가 같은 버전을 자동으로 받는다. 같은 이름의 스킬이 양쪽에 있으면 프로젝트 스킬이 우선한다. 규모가 더 큰 조직은 여기서 한 단계 나아가 깃 기반 '플러그인 마켓플레이스'로 스킬을 배포하기도 하는데, 마켓플레이스 저장소의 버전만 올리면 다음 세션에서 팀원들이 자동으로 최신 스킬을 받는 방식이다.

방에서 실제로 팀 하네스 운영을 맡고 있다는 유저가 공유한 방식도 이 구조와 맞닿아 있었다. 스킬 자체는 직무 구분 없이 공용으로 배포하되, 직무별 프로필에서 필요한 스킬만 켜고 나머지는 끄는 방식을 쓴다는 것이었다. 또 스킬을 무작정 자동 실행시키기보다 사람이 한 번 확인한 뒤에 로드되도록 운영한다는 경험도 나눴다. 공식 문서 기준으로도 SKILL.md의 프런트매터에 `disable-model-invocation: true`를 넣으면 클로드가 스킬을 알아서 부르지 않고 사용자가 슬래시 명령으로 직접 호출할 때만 실행되게 만들 수 있어, 이런 '확인 후 로드' 운영이 표준 기능만으로도 가능하다. 다만 스킬 프런트매터의 `allowed-tools` 필드로 도구 접근을 제한하는 기능은 일부 버전에서 실제로는 강제되지 않는다는 이슈도 깃허브에 보고돼 있어, 권한 통제까지 스킬 설정에만 의존하는 것은 아직 조심스럽다는 게 커뮤니티의 대체적인 시각이다.

"끄지 말고, 워크플로우를 지정하라"

방 논의에서 가장 눈에 띈 팁은 스킬을 끄는 대신 선호하는 워크플로우를 지정하는 쪽으로 바꾸자 불만이 줄었다는 경험이었다. 기획자나 아티스트 입장에서는 스킬이 꺼진 이유를 알기 어렵고, '내 몫의 기능이 사라졌다'는 인상을 받기 쉽다. 반대로 "이 직무는 이 워크플로우를 기본으로 쓴다"는 식으로 방향을 제시하면 같은 결과라도 받아들이는 태도가 달라졌다.

이 접근은 클로드 코드의 output style·커스텀 명령 기능과도 잘 맞물린다. `/output-style` 명령으로 응답의 역할·톤·형식을 통째로 바꿀 수 있고, 이 설정은 프로젝트 레벨(.claude/settings.local.json)이나 사용자 레벨(~/.claude/output-styles)에 저장돼 개인화가 가능하다. 즉 스킬을 강제로 껐다 켰다 하는 대신, 직무별 기본 워크플로우와 출력 스타일을 미리 지정해두고 스킬은 그대로 공용으로 열어두는 쪽이 마찰을 줄이는 실무적인 절충안으로 자리 잡고 있는 셈이다.

직무별 메모리냐, 공유 메모리냐

메모리 구조를 둘러싼 논쟁도 방에서 이어졌다. 직무별로 개별 메모리를 두자는 의견과, 프로젝트 전체가 하나의 공유 메모리를 쓰자는 의견이 맞섰다. 공식 가이드가 권장하는 절충안은 계층 구조다. 레포지토리 루트의 CLAUDE.md는 80줄 안팎으로 짧게 유지하며 커밋 규칙·아키텍처처럼 모든 세션에 공통으로 필요한 내용만 담고, 하위 패키지나 디렉터리별로 30~60줄짜리 CLAUDE.md를 따로 둬서 해당 영역을 다루는 사람만 관련 컨텍스트를 불러오게 하는 방식이다. 이렇게 하면 아트 관련 작업을 할 때 백엔드 규칙까지 컨텍스트에 끌려 들어오는 낭비를 줄일 수 있다. 개인만의 설정은 별도로 gitignore 처리되는 로컬 파일에 두고 팀 공유 파일과 분리하는 것이 정석으로 통하는데, 다만 이 개인용 로컬 메모리 파일은 여러 워크트리 환경에서 잘 맞물리지 않는다는 이유로 최근에는 import 방식으로 대체하는 추세라는 점도 함께 알려져 있다.

방 논의에서는 직무별 개별 메모리와 전체 공유 메모리 중 어느 쪽이 낫다는 결론이 뚜렷하게 나지는 않았고, 팀 성격에 따라 갈린다는 의견이 많았다. 다만 공용 스킬 배포와 프로필별 on/off를 실제로 운영 중인 유저의 경험에 비춰보면, 공통 규칙은 얇게 공유하고 직무별 세부 사항은 하위 계층에 분리하는 쪽이 실무에서 통용되는 방식과 맞닿아 있었다.

팀 하네스의 숨은 비용

기능 설계 못지않게 걸림돌이 되는 건 비용이다. 클로드 코드는 Team 플랜 중에서도 프리미엄 시트(월 100달러, 5석 이상)에만 포함되며, 시트당 20달러인 스탠다드 플랜에는 클로드 코드 자체가 딸려 있지 않다. 여기서 한 단계 더 나아가 SCIM 프로비저닝이나 역할 기반 권한, 컴플라이언스 API 같은 조직 단위 통제까지 쓰려면 별도의 엔터프라이즈 계약이 필요하다. 결국 여러 직무가 함께 쓰는 팀 하네스를 제대로 굴리려면 개인 구독으로는 감당하기 어려운 수준의 지출이 따라붙는다.

방에서 하네스 운영을 맡고 있다는 유저는 정작 회사 차원의 지원이 충분하지 않아 구독료를 개인이 부담하며 실무를 겸하고 있다고 전했다. 팀 하네스에 대한 관심이 커지는 것과 별개로, 이를 실제로 설계하고 유지보수하는 역할과 그에 필요한 비용을 누가 감당할지는 아직 조직 차원에서 정리되지 않은 경우가 적지 않다는 방증이다.

정리

다직무 팀 하네스는 스킬을 공용으로 두고 프로필별로 켜고 끄는 구조, 끄는 대신 워크플로우를 지정하는 절충, 공통 규칙과 직무별 세부 사항을 나눈 계층형 메모리라는 세 가지 축으로 정리된다. 여기에 클로드 코드 자체가 시트당 최소 100달러부터 시작하는 프리미엄 요금제에서만 제공된다는 현실적 제약까지 고려해야 온전한 그림이 나온다. 다직무 협업이 늘어나는 만큼, 스킬·메모리 설계와 함께 누가 이 하네스를 유지보수하고 비용을 댈 것인지에 대한 조직 차원의 합의도 함께 논의될 필요가 있어 보인다.