AI를 팀원으로 쓴다는 건, 구조를 먼저 설계한다는 뜻이다
Anthropic이 6월 23일 공개한 Claude Tag는 단순한 Slack 봇 업그레이드가 아니다. 핵심은 agent identity—Claude가 특정 사용자의 권한을 빌려 동작하는 게 아니라, 관리자가 발급한 전용 계정으로 채널에 상주하며 독립된 행위자로 작동한다는 설계 철학이다. Slack에는 Claude 앱으로 메시지를 남기고, GitHub에는 Claude 전용 앱으로 PR을 열고, 데이터 저장소에는 전용 계정으로 접근한다. 모든 작업 이력이 단일 계정에 귀속된다.
이게 왜 중요한가. 지금까지 팀에서 AI를 쓰는 방식은 개인 단위였다. 각자 브라우저 탭을 열고, 배경을 설명하고, 결과를 복사해 Slack에 붙여넣는다. AI가 한 일은 그 사람의 탭 안에서만 사라진다. Claude Tag는 그 흐름을 팀이 이미 모여 일하는 채널 안으로 끌어들인다. 게다가 권한은 채널 단위로 격리된다. 법무 채널의 Claude는 엔지니어링 채널 코드에 접근하지 못하고, 비공개 채널에서 학습한 맥락은 다른 워크스페이스에 유출되지 않는다. 공유되는 AI지만 권한은 철저히 분리된다는 게 설계의 핵심이다.
MCP를 RPC로만 보면 절반을 놓친다
여기서 MCP(Model Context Protocol) 얘기를 빼놓을 수 없다. 대부분의 논의는 MCP를 도구 호출 레이어로 본다. AI가 GitHub 이슈를 읽고, DB를 쿼리하고, API를 호출하는 RPC 계층. 틀린 말은 아니다. 그런데 dev.to의 한 글(MCP Is More Useful as Context Distribution Than as RPC)이 더 날카로운 지점을 짚는다.
"MCP는 AI가 작업 중에 도구를 호출하는 방법이 아니라, 작업이 시작되기 전에 작업 환경을 정의하는 방법이 될 수 있다."
팀 레벨 AI 운영에서 RAG와 로컬 프롬프트가 공통으로 실패하는 지점이 있다. RAG는 '이 요청에 관련 있을 정보가 뭔가?'에 답하지만, '이 작업을 어떻게 수행해야 하는가?'는 정의하지 못한다. 로컬 프롬프트는 개인마다 버전이 다르고, 업데이트를 빠뜨리면 팀 전체 AI 산출물 품질이 개인의 프롬프트 숙련도에 종속된다. 이건 팀 레벨 시스템이 아니라 개인 프롬프트 장인 문화다.
MCP 컨텍스트 배포 모델은 이 문제를 구조로 푼다. 세션 시작 시 AI 클라이언트가 get_startup_context를 호출하면 접근 정책, 권위 있는 컨텍스트 소스, 사용 가능한 스킬 카탈로그, 워크플로우, 미지 처리 규칙, 클로저 조건이 한꺼번에 내려온다. 모델은 단순히 도구에 접근하는 게 아니라, 거버넌스가 적용된 컨텍스트 안에서 작업을 시작한다. 시니어 엔지니어가 도메인 스킬을 MCP 서버에 한 번 정의해두면, 팀원 누구든 AI 클라이언트를 통해 동일한 스킬 정의를 런타임에 받아 쓴다. 로컬 체크아웃도, 버전 불일치도 없다. 이건 지식 검색이 아니라 운영 계약의 배포다.
WebMCP: 브라우저까지 확장되는 컨텍스트 레이어
MCP 패턴이 서버-에이전트 사이에만 머물지 않는다는 신호도 나왔다. Google I/O 2026에서 Chrome 팀은 "Gemini in Chrome이 곧 WebMCP API를 지원할 것"이라고 공식 발표했다(출처: dev.to). navigator.modelContext를 통해 웹사이트가 자신의 기능을 에이전트가 호출 가능한 도구로 노출하는 구조다.
아직 오리진 트라이얼(Chrome 149~156) 단계고 WebKit은 반대 입장이다. 표준이 확정된 게 아니다. 그런데 핵심은 리스크 비대칭이다. 기능 감지(if (navigator.modelContext))로 구현하면 에이전트가 없을 때 코드가 아무것도 하지 않는다. 비용은 기존 핸들러를 얇게 감싸는 오후 반나절이다. 반면 늦으면 경쟁사 전환율 지표로 그 차이를 나중에 확인하게 된다. 팀 관점에서 WebMCP는 '웹 레이어까지 내려오는 MCP 컨텍스트 확장'으로 읽어야 한다.
시사점: 도구 도입보다 컨텍스트 거버넌스 설계가 먼저
세 신호를 같이 놓으면 방향이 보인다. Claude Tag는 AI에게 팀 채널 안의 고정된 신원과 채널별 권한 경계를 부여한다. MCP 컨텍스트 배포는 AI가 작업 전 팀의 운영 규칙을 중앙에서 수신하게 만든다. WebMCP는 그 패턴을 브라우저 레이어까지 확장한다. 공통 구조는 하나다. AI 에이전트를 팀 인프라로 운영하려면, 도구 연결 이전에 컨텍스트를 어떻게 정의하고 배포하고 격리할지를 먼저 설계해야 한다.
실무적으로 이게 의미하는 건 이렇다. MCP 서버를 '도구 호출 엔드포인트'로만 설계하지 말고, 팀의 운영 계약을 중앙 배포하는 레이어로 설계하라. 어떤 문서가 권위 있는 소스인가, AI가 언제 멈추고 사람 확인을 요청해야 하는가, 미지(unknown)를 어떻게 처리하는가—이 규칙들을 프롬프트 파일로 개인이 관리하면 팀 AI 품질은 개인 역량에 종속된다. MCP 서버가 이 계약을 배포하면 팀 전체가 동일한 거버넌스 위에서 AI를 쓴다.
전망: AI 팀원 거버넌스의 세 층위
앞으로 AI-First 팀 인프라는 세 층위로 수렴할 가능성이 높다. 신원 레이어(agent identity, Claude Tag처럼 채널별 전용 계정과 권한 경계), 컨텍스트 레이어(MCP 기반 운영 계약과 도메인 스킬 중앙 배포), 인터페이스 레이어(WebMCP처럼 서비스 접점까지 에이전트가 접근 가능한 구조). 이 세 층위를 설계하지 않으면, AI는 팀 인프라가 아니라 개인 도구로 남는다.
Claude Tag의 ambient 모드를 처음부터 모든 채널에 켜지 말라는 조언(Lushbinary)은 이 구조 설계의 단면이다. 팀이 결과물을 신뢰한다고 판단한 채널부터 단계적으로 확장하는 것, 그게 AI 팀원 거버넌스를 운영하는 방식이다. 도구가 아무리 강력해도, 구조 없이 켜면 비용과 리스크만 빠르게 쌓인다.