지금 팀에서 일어나고 있는 일
팀에 AI 코딩 에이전트를 도입하고 나서 가장 먼저 드는 질문은 대개 '얼마나 쓸 수 있나?'다. 그런데 진짜 문제는 그다음에 온다. 여러 명이 매일 Claude Code를 쓰기 시작하면, 비용보다 먼저 운영 가시성이 무너진다. 어느 프로젝트가 예산을 가장 많이 썼는지, 어떤 작업이 굳이 최고 성능 모델을 쓸 필요가 없었는지, 누가 어떤 요청에서 실패했는지—이 질문들에 깔끔하게 답할 수 없는 팀이 생각보다 많다.
두 개의 신호가 동시에 가리키는 것
dev.to에 올라온 'Keep Coding After Claude Code Limits' 글과 앤트로픽·세일즈포스가 공개한 Claude Tag 슬랙 통합, 이 두 신호는 언뜻 별개처럼 보인다. 하나는 모델 비용 최적화 이야기고, 다른 하나는 협업 UI 이야기니까. 그런데 함께 읽으면 하나의 설계 질문으로 수렴한다. 'AI 에이전트를 팀 워크플로우에 어떻게 구조적으로 심을 것인가.'
라우팅 레이어: 에이전트를 두 레인으로 분리하라
첫 번째 신호의 핵심은 단순하다. 모든 작업에 최고 성능 모델을 쓰지 말라는 것이다. 아키텍처 결정, 프로덕션 인시던트, 보안 민감 코드, 불명확한 요구사항—이런 작업은 판단이 필요하다. 여기서 아끼려다 리뷰 비용이 더 나온다. 반면 README 수정, 타입 픽스, 린트 정리, 작은 API 래퍼—이 작업들은 결과를 검증하기 쉽다. 패치 하나, 테스트 통과, diff 확인으로 충분하다.
중요한 건 이 분리를 팀 단위 규칙으로 만들어야 한다는 점이다. 개인이 알아서 판단하게 두면 다시 모든 작업이 최고 모델로 몰린다. 여기서 라우터 레이어가 필요해진다. 키 관리, 사용자별·프로젝트별 한도, 모델 라우팅 규칙, 실패 로그를 한 곳에서 제어하는 레이어. 이건 팀이 커질수록 선택이 아니라 필수 인프라다.
Claude Tag: 협업 맥락을 슬랙 안으로 끌어들이다
두 번째 신호는 다른 차원의 문제를 건드린다. 지금까지 AI 도구 사용 방식의 근본적인 결함은 맥락의 단절이었다. 개인이 별도 탭에서 AI와 작업하고, 그 결과물을 복사해 슬랙에 붙여넣는다. 팀이 그 추론 과정을 볼 수 없고, 이어받을 수 없고, 방향을 조정할 수 없다.
Claude Tag는 이 구조를 뒤집는다. 슬랙 채널에서 @Claude를 태그하면, AI가 자체 계정과 권한을 가진 팀원처럼 채널 맥락을 읽고 풀 리퀘스트 작성까지 수행한다. 더 중요한 건 멀티플레이어 구조다. AI의 작업 과정이 채널에서 실시간으로 공개되고, 팀 전체가 보고, 이어받고, 수정할 수 있다. 슬랙봇이 조직 전체의 맥락을 담당하고 @Claude가 개발 업무의 실행을 맡는 듀얼 에이전트 구조는, 에이전트를 개인 도구가 아니라 팀 공유 자원으로 만드는 첫 번째 실질적 시도다.
두 레이어를 합치면 보이는 설계
라우팅 레이어와 협업 레이어, 이 두 가지를 합치면 AI-First 팀 워크플로우의 윤곽이 잡힌다.
라우팅 레이어는 '어떤 모델에게 어떤 작업을 맡길 것인가'를 팀 수준에서 결정한다. 판단이 필요한 작업은 Claude Code 같은 최고 성능 모델로, 검증이 쉬운 루틴 작업은 저비용 모델로. 이 결정을 개인에게 맡기지 않고 시스템이 강제하게 만드는 것이 핵심이다.
협업 레이어는 '그 작업의 과정과 결과가 팀에게 어떻게 보일 것인가'를 결정한다. 슬랙 채널에서 @Claude를 통해 작업을 공개 실행하면, AI가 생성한 결과물에 대한 팀의 집단적 검증이 자연스럽게 일어난다. 개인의 블랙박스 사용이 아니라 팀의 투명한 협업 기록이 된다.
팀 리드로서 지금 당장 설계해야 할 것
이론은 충분하다. 내일 당장 써먹을 수 있는 것을 짚는다.
첫째, 작업 분류 기준표를 팀 문서로 만들어라. 어떤 작업이 '판단 필요'이고 어떤 작업이 '루틴'인지 팀 합의로 정해야 한다. 처음엔 대략적으로 시작해도 된다. 실패 케이스를 축적하면서 기준이 정교해진다.
둘째, 실패 로그를 의무화하라. 저비용 모델이 잘못된 결과를 낸 케이스는 팀 자산이다. dev.to 글에서 언급한 것처럼, 실패 케이스는 어디서 루틴 라우팅을 멈춰야 하는지 경계를 가르쳐준다.
셋째, Claude Tag 파일럿을 특정 채널에서 시작하라. 코드 리뷰 채널이나 버그 트래킹 채널에서 @Claude를 팀원처럼 태그하는 실험을 해봐라. AI의 작업 과정이 팀에 공개될 때 어떤 동학이 생기는지 직접 확인하는 게 가장 빠른 학습이다.
앞으로 주목해야 할 것
라우팅 레이어와 협업 레이어의 결합은 이제 막 시작됐다. 다음 단계는 이 두 레이어가 연동되는 것이다. 슬랙 채널에서 @Claude로 들어온 요청이 자동으로 작업 유형을 분류하고, 라우터가 적절한 모델을 선택하고, 결과가 다시 채널로 돌아오는 흐름. 이게 완성되면 팀의 AI 사용 패턴이 처음으로 측정 가능하고 통제 가능한 인프라가 된다.
지금 당장 완벽한 시스템을 갖출 필요는 없다. 하지만 라우팅 없이, 협업 맥락 없이 에이전트를 팀에 풀어놓는 것은—빠른 도입이 아니라 통제 불가능한 부채를 쌓는 일이다. 설계 순서가 중요하다.