Anthropic, Slack에서 @Claude를 팀원처럼 호출하는 Claude Tag 기능 및 멀티플레이어 에이전트 협업 가이드 공개

9bow · 6월 30, 2026, 11:31오후

Claude Tag 소개

지금까지 우리가 AI와 일하는 방식은 대부분 싱글 플레이어(Single Player) 경험이었습니다. 한 사람이 하나의 채팅 창을 열어, 한 명의 어시스턴트와 일대일로 대화하며 작업을 끝내는 구조입니다. 코딩, 리서치, 재무 분석처럼 점점 더 복잡하고 오래 걸리는 일을 AI가 다룰 수 있게 되면서 터미널, IDE, 스프레드시트, 슬라이드 등 접점은 다양해졌지만, 그 본질은 여전히 한 사람과 한 에이전트의 1:1 협업 에 머물러 있었습니다.

Anthropic이 새롭게 공개한 Claude Tag 는 이 전제를 바꿉니다. Claude Tag는 팀이 이미 일하고 있는 협업 공간, 즉 Slack 안으로 Claude를 한 명의 팀원처럼 합류시키는 방식입니다. 관리자가 특정 채널에 Claude를 초대하고 필요한 도구, 데이터, 심지어 코드베이스까지 연결해 주면, 그 채널의 누구나 @Claude 를 멘션해 작업을 위임할 수 있습니다. Claude는 채널에서 오간 맥락을 기억하며 일을 이어받고, 앞으로 처리할 작업을 스스로 계획하기도 합니다. Anthropic은 이를 Claude Code의 진화로 설명합니다. 모델을 더 능동적으로 만들고, 한 사람이 아닌 팀 전체와 함께 일할 때 더 큰 효과를 내도록 한다는 것입니다.

이것이 단순한 채팅봇과 다른 이유는 멀티플레이어(Multiplayer) 라는 표현에 잘 담겨 있습니다. 위 그림의 왼쪽처럼 한 사람이 한 에이전트에게 작업을 시켜 결과물을 받던 구조가, 오른쪽처럼 여러 사람과 여러 에이전트가 하나의 팀으로 묶여 서로 보고하고(reports to) 협력하는(collaborates) 구조로 바뀝니다. 흥미롭게도 이 변화는 Anthropic 내부에서 이미 일상이 되었습니다. Anthropic은 @Claude를 태그하는 것이 이제 우리가 일을 처리하는 핵심 방식 중 하나가 되었다 고 밝히며, 제품 팀 코드의 65%가 사내 버전 Claude Tag로 생성된다고 공개했습니다. 이 패턴은 엔지니어링을 넘어 제품 지표와 데이터를 추적하거나, 고객 지원 티켓을 처리하거나, 까다로운 버그의 근본 원인을 찾는 데까지 번지고 있습니다.

이 글에서는 Claude Tag라는 제품 자체뿐 아니라, 그 배경이 되는 멀티플레이어 에이전트(Multiplayer Agents) 개념, 그리고 Anthropic이 지난 수개월간 사내에서 인간과 에이전트가 함께하는 팀을 운영하며 정리한 네 가지 교훈, 마지막으로 이 모든 것을 떠받치는 새로운 접근 권한 모델인 에이전트 정체성(Agent Identity) 까지 차례로 살펴봅니다. Claude Tag는 현재 Claude Enterprise 및 Team 고객을 대상으로 베타로 제공되며, Opus 4.8 모델 위에서 동작합니다.

@Claude와 함께 일한다는 것: 네 가지 새로운 특징

Claude Code나 Claude Cowork를 써본 적이 있다면 Claude Tag의 작동 방식은 친숙하게 느껴질 것입니다. @Claude를 멘션하고 평이한 말로 요청하면, Claude는 작업을 여러 단계로 쪼갠 뒤 자신이 가진 도구를 활용해 하나씩 처리하고, 완료되면 Slack 스레드에 결과물을 보고합니다. 그러나 태그한다 는 행위에는 기존의 1:1 채팅과 구분되는 몇 가지 새로운 이점이 따라옵니다.

멀티플레이어(@Claude is multiplayer): 하나의 Slack 채널 안에는 모두와 상호작용하는 하나의 Claude가 존재합니다. 채널의 누구나 Claude가 무엇을 하고 있는지 볼 수 있고, 앞 사람이 멈춘 지점에서 대화를 이어받을 수 있습니다. 위 그림은 #revenue-ops 채널에서 한 사람이 제안 단계에 머물러 있는 거래들을 살펴봐 달라 고 @Claude를 호출하자, Claude가 데이터를 분석해 4분기 비즈니스 리뷰(QBR) 에 쓸 표와 차트를 만들어 내고 다른 동료가 그 결과를 그대로 받아 가는 장면입니다. 단일 채팅이나 단일 작업과는 전혀 다른, 동료와 협업하는 것에 훨씬 가까운 경험입니다.

시간이 지나며 학습(@Claude learns over time): Claude는 자신이 속한 채널의 흐름을 따라가며 작업에 대한 맥락을 쌓아 갑니다. 사용자가 매번 처음부터 모든 것을 설명할 필요가 없다는 뜻입니다. 권한이 부여되면 다른 Slack 채널이나 데이터 소스로부터도 자동으로 학습할 수 있습니다. (단, 비공개 채널의 내용은 외부로 보고하지 않습니다.) 이렇게 축적된 암묵지(tacit knowledge)가 더 나은 결과물의 바탕이 됩니다.

주도적으로 행동(@Claude takes initiative): 앰비언트(ambient) 동작이 켜져 있으면, Claude는 사용자가 알아야 할 만한 정보를 능동적으로 챙겨 알려 줍니다. 자신이 속한 채널과 연결된 도구들에서 관련 정보를 짚어 주고, 해결되지 않은 채 조용해진 스레드나 작업을 먼저 챙겨 후속 조치를 취합니다.

비동기적으로 작업(@Claude works asynchronously): Claude에게 작업을 맡겨 두면, 사용자는 다른 우선순위에 집중하는 동안 Claude가 일을 처리합니다. Claude는 스스로 작업을 미래 시점에 예약할 수도 있어, 몇 시간에서 며칠에 걸쳐 하나의 프로젝트를 자율적으로 끌고 갈 수 있습니다. Anthropic은 이제 여러 Claude에게 작업을 병렬로 위임하는 데 훨씬 더 많은 시간을 쓴다 고 말합니다.

이러한 능력들이 합쳐지면서, AI와의 협업은 한 사람의 보조 도구를 넘어 팀의 일원으로 옮겨 갑니다. 그렇다면 이런 식으로 여러 사람과 동시에 일하는 에이전트는 기존 에이전트와 무엇이 다를까요?

멀티플레이어 에이전트란 무엇인가

Anthropic은 멀티플레이어 에이전트 를 동시에 여러 사람과 함께 일하는 AI 모델 로 정의합니다. 일반적인 에이전트와 마찬가지로 이들도 자신만의 메모리(Memory)와 스킬(Skills)을 가집니다. 하지만 다른 점도 분명합니다. 멀티플레이어 에이전트는 사람에게 묶이지 않은 자신만의 자격 증명(Credentials) 을 보유하며, 무엇보다 일이 실제로 벌어지는 장소 안에 상주합니다. Anthropic의 경우 그곳은 Slack 같은 팀 협업 도구 내부입니다.

에이전트가 팀 채널에서 생산적으로 일하려면 다음과 같은 구체적인 역량이 필요합니다.

지속적 메모리(Persistent Memory): 목표를 기억하고 그 목표에 맞춰 실행을 조율할 수 있어야 합니다.
사람에게 묶이지 않은 자격 증명(Credentials not tied to humans): 안전하고 예측 가능한 가드레일 안에서 동작할 수 있어야 합니다.
정보에 대한 폭넓고 지속적인 접근(Ongoing broad access to information): 조직이 어떻게 돌아가는지 학습하고, 팀의 목표를 위해 실제로 작업을 실행할 수 있어야 합니다.

이 세 가지가 에이전트가 여러 사람으로 이루어진 팀에 생산적으로 참여하기 위한 기술적 토대 입니다. 다만 인간-에이전트 팀을 단지 돌아가게 하는 것을 넘어 성공 시키려면, 기술만으로는 부족합니다. 팀에는 고유한 일하는 방식과 공유된 규범이 필요합니다. Anthropic이 사내에서 직접 부딪히며 정리한 네 가지 교훈이 바로 그것입니다.

효과적인 인간-에이전트 팀을 위한 네 가지 교훈

교훈 1: 공개적으로 일하고, 에이전트에게 넓은 맥락을 준다

Anthropic의 팀은 정보를 능동적이고 개방적으로 공유합니다. 에이전트가 팀에 포함되면 이 원칙은 더욱 중요해집니다. 에이전트는 팀이 검색 가능하게 만들어 둔 텍스트 (Slack, 코드, 문서, 회의록)로부터 전적으로 이해를 구축하기 때문입니다. 개인 메시지, 복도에서 오간 대화, 접근이 제한된 문서는 에이전트에게 맥락을 줄 수 없습니다. 에이전트에게는, 적혀 있지 않고 접근할 수 없다면 그것은 존재하지 않는 것 입니다.

이때 어떤 문서나 채널을 에이전트에게 열어 줄지 하나씩 결정하는 대신, Anthropic은 Slack 워크스페이스 전체, 회의록, 문서 라이브러리에 적용되는 명확하게 정의된 보안 경계(security boundary) 를 사용합니다. 보안 경계 안에서는 사람이든 AI든 모든 팀원에게 맥락이 흐릅니다. 이 방식은 에이전트와 사람이 접근할 수 있는 범위를 넓혀 줄 뿐 아니라, 무엇을 누구와 공유해도 되는가 에 대한 혼란을 줄여 줍니다. 이 채널은 공개여야 할까 비공개여야 할까? 이 문서를 저 사람과 공유해도 될까? 이 에이전트가 저 스레드를 봐도 될까? 같은 항목별 공유의 모호한 경계는 사람에게도 에이전트에게도 어렵습니다. 워크스페이스 수준의 소수의 명확한 경계는 일상 업무에서 이런 결정 피로를 없애 줍니다.

높은 투명성에는 보상이 따릅니다. 예를 들어 팀 회의의 결정 사항을 읽을 수 있는 에이전트는 우선순위에서 밀려난 작업을 제안하지 않습니다. 자기 팀을 넘어 제품 스펙에 접근할 수 있는 에이전트는 다른 팀에서 성공한 패턴을 추천할 수 있습니다. 그리고 에이전트는 사람보다 훨씬 빠르게 방대한 텍스트를 읽기 때문에, 사람이라면 놓쳤을 관련 작업을 일상적으로 끌어올려 줍니다. Anthropic은 빠르게 움직이는 산업에서 정보를 따라잡고 협업을 유지하기 위해 에이전트에 크게 의존한다고 말합니다.

Anthropic에서 공개적으로 일하기 는 다음과 같은 모습입니다.

회사 차원에서 소수의 보안 경계를 고르고, 각 경계에 맞춰 워크스페이스와 문서 공유 설정을 구성하기
새로운 커뮤니케이션 채널을 기본적으로 조직 내 공개로 두고, 결정 사항이 매번 채널, 문서, 회의록에 남도록 보장하기
이제 에이전트가 팀 문서의 주요 소비자가 되었으므로, 에이전트가 찾을 수 있도록 산출물과 회의록을 작성하기
AI가 일을 끝내는 데 필요한 올바른 도구와 정보에 접근할 수 있도록 보장하기

정보를 기본적으로 내부 공개로 두는 것은 문화적 변화를 요구할 수 있습니다. 그러나 맥락을 가진 인간-에이전트 팀과 그렇지 못한 팀의 차이는 무시하기엔 너무 큽니다. 물론 일부 민감한 상호작용은 한 사람과 AI 사이에서 비공개로 이루어져야 합니다. 그런 경우에는 @Claude에게 다이렉트 메시지(DM)를 보내거나, 기존의 Claude.ai와 Claude Cowork 애플리케이션을 사용하면 됩니다.

교훈 2: 모든 사람과 에이전트에게 역할과 도구를 명확히 부여한다

인간-에이전트 팀은 하나의 명단(roster), 하나의 산출물 집합, 하나의 작업 공간을 공유합니다. 에이전트는 자신만의 자격 증명, 스킬, 도구 접근 권한을 가지며, 서로 다른 역할을 맡습니다. 예를 들어 한 에이전트가 프로젝트의 데이터 분석을 책임진다면, 다른 에이전트는 디자인 표준을 보유하고 강제하며, 또 다른 에이전트는 리서치 종합을 담당하는 식입니다.

프로젝트가 시작되면, 사람들은 에이전트들과 대화하며 어떤 역할을 배정할지, 사람과 에이전트가 어떻게 함께 일할지를 정합니다. 아래는 #launch-room 채널에서 출시를 앞둔 팀이 팀 명단을 짜고 @Claude에게 채널을 읽어 우선순위가 높은 작업을 제안해 달라고 요청하는 모습입니다.

사람과 에이전트의 일이 명확해지면, 한 에이전트가 다른 에이전트들을 띄워(spin up) 각 작업이 적절한 메모리와 접근 권한을 가진 에이전트에게 맡겨지도록 합니다. 중요한 것은 일을 끝내는 데 필요한 모든 도구 에 대한 접근입니다. 데이터 분석을 맡은 에이전트는 BigQuery가 필요할 수 있고, QA를 수행하는 에이전트는 Playwright MCP가 필요할 수 있습니다.

역할과 책임이 분명하면 인간-에이전트 팀은 성공할 준비가 됩니다. 사람은 종종 에이전트와 같은 스레드에서 일하지만, 오직 사람만이 맡을 수 있는 역할 을 보유합니다. 이렇게 해야 모든 것이 맞물려 돌아가고, 가장 중요한 결정에 인간의 판단이 적용됩니다. 역할이 분명하지 않으면 사람들은 결국 각자 개인용 AI 함대를 따로 돌리며 작업을 중복하고 팀의 맥락을 파편화시키게 됩니다. 지표 추적이 대표적인 사례입니다. 멀티플레이어 에이전트는 그 일을 한 번만 수행하고, 모두가 같은 숫자를 보게 할 수 있습니다.

위 그림은 Claude 에이전트들이 코드베이스의 일상적 유지보수를 나눠 맡는 방식을 보여 줍니다. 매니저(Manager)는 우선순위와 가이드라인을 최신으로 유지하고, 테크 리드(Tech Lead)는 계획과 변경을 리뷰하며 공유 코드베이스를 건강하게 유지합니다. 리뷰어(Reviewer)는 열린 이슈를 조사해 권장 접근법을 정리하고, 코더(Coder)는 이슈를 받아 코드를 작성해 풀 리퀘스트를 엽니다. PM은 피드백 채널을 살펴 처리할 가치가 있는 이슈를 등록하고, 커뮤니케이션(Comms) 담당은 팀 전체를 위한 실시간 상태 보고를 최신으로 유지합니다. 각 에이전트는 분명한 작업을 소유하고 자신만의 주기(cadence) 로 실행하는데, 커뮤니케이션 담당은 반시간마다, PM은 몇 시간마다, 코더는 하루에도 여러 번, 리뷰어는 주 며칠씩 도는 식으로 역할마다 빈도가 다릅니다. 사람은 목표를 정하고 산출물을 검토합니다.

Anthropic의 한 엔지니어링 팀은 사람과 에이전트의 역할을 명문화하기 위해 명단을 만들기 시작했고, 이를 통해 초기에 몇 가지를 깨달았다고 합니다.

구체적인 역할은 사람들이 어떤 작업에 대한 책임이 어디에 있는지를 쉽게 추적하도록 돕습니다.
특정 에이전트의 역할을 정의하는 스킬 파일(Skill File)을 작성하면 전문화가 쉬워지고, 회사 전체의 누구나 같은 유형의 에이전트를 빠르게 세울 수 있습니다.
프로젝트가 복잡해지면 팀은 새로운 영역에 집중할 에이전트를 추가합니다. 예를 들어 신규 소프트웨어 릴리스를 다룰 릴리스 매니저(Release Manager) 에이전트를 더하는 식입니다.

이러한 방법은 에이전트 수가 늘어나도 인간이 인간-에이전트 팀에 대해 갖는 멘탈 모델이 함께 확장되도록 해 줍니다.

교훈 3: 북극성을 세워 에이전트를 더 주도적으로 만든다

Anthropic의 일부 에이전트는 단순히 배정된 작업만 수행하지만, 가장 중요한 에이전트들은 새로운 프로젝트와 워크스트림을 주도적으로 제안합니다. 이는 이미 풍부한 맥락과 분명한 역할을 갖춘 팀이 또 하나의 지침, 즉 북극성(North Star) 을 더할 때 자주 일어납니다.

북극성은 어떤 작업과 워크스트림이 올바른 것인지를 팀이 판단하도록 돕는, 야심차고 폭넓은 목표입니다. Anthropic에서는 항상 사람이 북극성을 정하며, 이를 비즈니스의 미션과 목표에 단단히 뿌리내리게 합니다. 북극성이 글로 분명히 표현되고 나면, 사람들은 이를 팀의 에이전트들과 공유합니다. 그리고 중요한 점은, 어떤 에이전트가 새로운 워크스트림을 주도적으로 제안할지를 사람이 선택 한다는 것입니다. (팀의 모든 에이전트가 작업을 성공적으로 제안할 만한 사전 역량과 신뢰를 갖추고 있을 가능성은 낮습니다.)

예를 들어 제품 온보딩을 더 도움이 되게 만들자 라는 북극성을 가진 한 내부 도구 팀에서는, 한 에이전트가 온보딩 흐름의 오류 메시지 문구 수정을 주도적으로 추천했습니다. 이 변경은 다음 주 온보딩 성공률을 측정 가능한 수준으로 끌어올렸습니다.

Anthropic에서 북극성 세우기 는 다음과 같은 모습입니다.

사람들이 회사의 미션과 비즈니스 목표에 뿌리내린, 야심찬 북극성 목표를 논의하고 토론하며 문서화하기
북극성을 팀의 에이전트들과 공유하고, 어떤 에이전트가 새 워크스트림을 주도적으로 추천할 수 있는지 를 명시적으로 지정하기
고품질의 인간 시간을 캘린더에 보호해 두고, 회의는 가장 중요한 작업에 집중하기

분명한 북극성은 에이전트에게 일관된 방향과, 팀의 일을 주도적으로 지원할 의미 있는 기회를 제공합니다.

교훈 4: 시간을 들여 신뢰를 쌓는다

Anthropic의 팀은 에이전트에게 입증된 신뢰성에 비례해 자율성을 부여하고, 그 범위를 신중하게 넓혀 갑니다. 엔지니어들은 팀의 에이전트에게 500건의 버그 수정을 독립적으로 처리하게 한 적이 있지만, 처음부터 그랬던 것은 결코 아닙니다.

새로운 동료가 팀에 합류하면 그의 역량을 가늠하고 탄탄한 업무 루틴을 만드는 데 시간이 걸립니다. 작업을 가장 잘 끝내는 방법에 대한 암묵적 정보를 모두 겉으로 끄집어내려면 보통 여러 번의 피드백 사이클이 필요합니다. 에이전트도 마찬가지입니다. 사용자는 다양한 작업을 맡겨 보며 그 에이전트가 무엇을 할 수 있는지, 목표를 어떻게 명확히 기술해야 하는지, 어떤 스킬 파일이 필요한지, 어떤 프롬프트가 원하는 행동을 끌어내는지를 학습해야 합니다. 모델이 바뀌고 개선될 때마다 작업을 다시 테스트하는 것도 중요합니다. 프롬프트는 다시 다듬어야 할 수 있고, 한때 유용했던 가드레일이 더 똑똑해진 모델의 창의적 해법을 가로막을 수도 있기 때문입니다.

특히 Anthropic은 가장 뛰어난 장기 실행 에이전트는 사람이 보기 전에 자신의 작업을 검증할 여러 방법을 갖추고 있다 는 점을 발견했습니다. 코드에는 당연히 테스트가 있지만, 다른 대부분의 작업도 검증할 수 있습니다. 예를 들어 기술 문서에는 루브릭과 스타일 가이드를 적용할 수 있습니다. 사람이 기준을 세우고 에이전트에게 맡긴 모든 작업이 검증 가능하도록 보장하면, 품질이 높게 유지되고 원래 의도에서 벗어나지 않습니다. 또한 사람의 경우처럼, 한 에이전트에게는 작업을 수행하는 일을 맡기고 다른 에이전트에게는 첫 번째 에이전트의 작업을 검사하는 일을 맡기는 것이 도움이 될 때가 많습니다. 이는 흔히 도어-베리파이어(Doer-Verifier) 에이전트 하네스라고 불립니다.

위 그림은 백로그를 정리하는 도어-베리파이어 구조의 예시입니다. 평가자(Evaluators) 집단이 들어오는 이슈를 포착해 중요도와 복잡도로 점수를 매기고 순위를 정하면, 실행자(Executors) 집단이 중요도가 높고 복잡도가 낮은 작업을 가져가 수정하고 배포합니다. 아직 준비되지 않은 항목은 다시 평가 단계로 돌려보냅니다.

Anthropic에서 시간을 들여 에이전트와 신뢰 쌓기 는 다음과 같은 모습입니다.

초기에는 에이전트의 작업을 수동으로 검토해 품질을 확인하고, 피드백을 주며, 작업 검증 체크리스트를 설계하기
작업의 일부로 베리파이어(verifier) 에이전트를 사용해 자신의 작업을 검사하도록 에이전트에게 지시하기
사이클에 성찰(reflection) 을 포함시켜, 에이전트가 자신의 실수를 되돌아보며 작업을 개선하도록 하기
각 에이전트가 어떤 종류의 작업에서 자율성을 얻었는지 추적하고, 반복적으로 성공한 작업 유형부터 범위를 넓혀 가기

Anthropic의 한 엔지니어링 리더는 큰 백로그를 안고 새 팀을 맡았습니다. 그는 몇 명의 사람과 몇 개의 에이전트를 초대해 백로그를 분류하고 우선순위를 정했습니다. 한 무리의 에이전트가 백로그의 모든 항목을 읽어 담당자가 있는지 확인하고, 담당자가 없는 항목에 복잡도 점수를 매겼습니다. 다른 무리는 그 목록에서 중간 및 낮은 복잡도의 항목만 추려 코드 변경을 만들었습니다. 처음에는 사람이 에이전트의 모든 결정을 검토하고, 사람의 입력이 필요한 결정을 표시했습니다. 그다음 사람들은 에이전트가 그런 결정을 직접 사람에게 올리도록 가르쳐, 어려운 트레이드오프가 있는 결정에는 항상 사람이 개입(human in the loop)하도록 만들었습니다.

매주 이 리더와 팀은 에이전트에게 교훈과 실수(lessons & missteps) 를 포함한 주간 보고서를 작성하게 했습니다. 에이전트가 실수를 기록해 두고 같은 실수를 반복하지 않도록 하기 위함입니다. 시간이 지나면서 리더는 점점 더 복잡한 코드 변경을 에이전트에게 맡길 수 있었고, 일상적인 안내에 쓰는 시간은 줄어들었습니다. 에이전트가 더 독립적이 되자, 리더는 인간의 주의(attention)는 희소 자원 이라는 점을 에이전트에게 코칭했습니다. 질문은 한 번에 모아서 묻고, 핵심 맥락을 반복해 사람을 빠르게 따라잡게 하며, 한 사람이 한 번에 보는 항목 수를 제한하라는 것입니다. 실제로 어떤 팀은 가장 중요한 소통만 골라 사람에게 모아 전달하는 일을 전담하는 에이전트를 따로 두기도 하고, 또 어떤 팀은 에이전트가 하루에 처리하는 작업량 자체에 가드레일을 걸어 둡니다. 이런 장치는 사람이 일에 의미 있게 관여할 시간을 남기고, 자신에게 중요한 역량을 잃지 않으며, 사람이 검토해야 할 항목 수가 감당 가능한 수준에 머물도록 보장합니다.

에이전트 정체성: 멀티플레이어를 위한 새로운 접근 권한 모델

지금까지의 이야기에는 한 가지 까다로운 전제가 숨어 있습니다. 에이전트가 팀에서 최고의 성과를 내려면 사람과 동일한 도구, 문서, 맥락에 접근해야 한다는 것입니다. 싱글 플레이어 환경에서는 이것이 간단합니다. 사용자가 자기 계정을 연결하면 에이전트가 사용자를 대신해 행동하면 됩니다. 그러나 Claude Tag 같은 멀티플레이어 환경에서는 Claude가 여러 사람과 한 채널에 함께 앉아 있고, 특정 개인이 아니라 워크스페이스 에 속한 도구와 맥락을 끌어다 씁니다. Anthropic은 이를 위해 Claude가 자신만의 계정 을 갖는 접근 모델을 도입했고, 이를 에이전트 정체성(Agent Identity)이라 부릅니다.

사용자처럼 행동하기 가 무너지는 이유

AI를 개인 비서로 쓸 때는 Google Drive, GitHub, 캘린더 같은 플랫폼을 연결하고 모델이 내 권한으로 읽고 쓰도록 할 수 있습니다. 하지만 이 모델은 Claude Tag에서 두 가지 이유로 작동하지 않습니다.

첫째, 에이전트 자율성의 증가 입니다. AI 에이전트가 스스로 안정적으로 끝낼 수 있는 작업의 길이는 대략 4개월마다 두 배씩 늘어나고 있습니다. 에이전트는 이제 작업을 나중 시점으로 스스로 예약하고, 요청한 사람이 로그아웃한 한참 뒤의 이벤트에도 반응합니다. 둘째, 멀티플레이어 팀 입니다. Claude Tag는 세 명의 엔지니어와 한 명의 PM이 함께 디버깅하는 채널처럼, 팀이 이미 일하고 있는 공유 공간에 Claude를 둡니다. 그런데 여러 사람이 동시에 방향을 잡고 있을 때, 누구의 권한 이 적용되어야 할까요? 항상 옳은 단 한 사람의 권한이란 존재하지 않습니다.

Claude가 자기 자신으로서 행동한다

해법은 Claude가 단일 사용자를 대신하지 않고 자기 자신 으로서 행동하게 하는 것입니다. Claude Tag가 활성화된 채널에서 Claude는 자신이 닿는 각 시스템마다 자신만의 계정을 가집니다. Slack에는 Claude 앱으로 글을 쓰고, 풀 리퀘스트는 Claude GitHub App으로 열며, 데이터 웨어하우스는 관리자가 프로비저닝한 서비스 계정으로 질의합니다. 개인 사용자 자격 증명이 개입하지 않으므로, 공유 채널이 누군가의 비공개 문서로 들어가는 옆문 이 될 일도 없습니다.

관리자는 워크스페이스 수준에서 Claude가 어디서나 보유하는 기본 연결과 스킬의 집합인 정체성 을 정의하고, 모든 채널이 이를 기본값으로 상속합니다. 그런 다음 필요한 곳에서 채널 수준으로 이를 재정의할 수 있습니다. 예컨대 엔지니어링 채널에는 GitHub와 데이터 웨어하우스 접근을 부여하고, CRM 연결은 특정 비공개 채널 하나로만 한정하는 식입니다. 자격 증명 외에도 관리자는 Claude가 읽고 쓸 수 있는 저장소(Repository), 도구와 API 키인 커넥터(Connector), 동적으로 로드되는 스킬과 플러그인, 채널별 상시 지침(Standing Instruction)을 정의합니다. 이 모델은 별개의 Claude 정체성을 중심으로 동작하기 때문에, 정체성을 회수하면 그 정체성이 쓰이던 모든 곳에서 Claude의 접근이 한 번에 끊깁니다.

정체성 경계는 어떻게 동작하는가

에이전트 정체성은 이 사용자는 무엇을 할 수 있는가 라는 질문을, 이 에이전트는 이 구획(compartment)에서 무엇을 할 수 있는가 로 바꿉니다. 이는 사용자별 접근 제어 목록(Access Control List)에서 벗어나는 변화입니다. 채널 멤버가 저장소에 직접 접근 권한이 없더라도, 채널의 프로필이 Claude에게 그 권한을 부여했다면 Claude에게 그 저장소를 읽어 달라고 요청할 수 있습니다.

Claude Tag는 각 비공개 채널마다 별개의 정체성을 만들고, 워크스페이스의 공개 채널들은 워크스페이스 수준의 정체성을 공유합니다. 법무 채널에서의 Claude 정체성은 그 채널에 부여되지 않은 코드에 닿을 수 없고, 엔지니어링 채널에서의 정체성은 거기에 부여되지 않은 법무 문서를 읽을 수 없습니다. 메모리와 접근 권한 모두 이 경계를 존중하므로, Claude가 비공개 채널에서 학습한 내용이 더 넓은 워크스페이스에 나타나는 일은 없습니다.

정체성은 채널에 속하므로, 기본적으로 그 채널의 누구나 Claude를 태그할 수 있고, 관리자는 각 채널의 프로필을 가장 권한이 낮은 멤버(least-privileged member) 에 맞춰 좁힐 수 있습니다. Enterprise 플랜에서는 역할 기반 접근 제어(RBAC)로 한 걸음 더 나아가, 어떤 멤버가 Claude를 호출할 수 있는지까지 정할 수 있습니다. 즉 하나의 채널이 에이전트가 무엇에 닿을 수 있는가 와 누가 요청할 수 있는가 를 동시에 통제합니다.

위 그림은 Anthropic이 사내에서 도구 접근을 표면(surface) 에 따라 어떻게 구획하는지를 보여 줍니다. 넓고 위험이 낮은 통합(GitHub 읽기, Datadog, 공개 가격 정보 등)은 공유 채널에서 에이전트 정체성 으로 동작하고, 운영 배포 키나 Salesforce 쓰기처럼 민감한 도구는 정리된 소수만 있는 비공개 채널에 둡니다. 그리고 개인 저장소, 로컬 환경 비밀, 개인 캘린더처럼 나에게만 속한 도구는 DM에 남겨 사용자 자신의 정체성 으로 실행합니다.

Anthropic이 사내에서 Claude Tag를 운영하며 발견한 것은, 그 가치가 도구와 맥락에 대한 접근과 함께 복리로 불어난다(compounds) 는 점입니다. 연결된 시스템 하나하나가 나머지 모두를 더 유용하게 만듭니다. Claude가 Slack의 스레드, Drive의 문서, 이슈 트래커의 티켓, 웨어하우스의 쿼리 결과를 한데 엮어 어떤 단일 도구로도 낼 수 없는 하나의 답을 만들어 내기 때문입니다. 그래서 Claude에게서 가장 많은 것을 얻는 팀은 처음부터 넉넉하게 접근을 부여하는 팀입니다. Anthropic의 권고는 몇 개 채널에 기본 프로필로 시작해, 감사 로그(audit trail)를 읽어 가며, 일이 정당화하는 곳에 한 번에 하나씩 신중하게 접근을 넓혀 가라 는 것입니다. 더 촘촘한 통제가 필요한 조직은 특정 채널에서 Claude Tag를 아예 비활성화하거나, RBAC로 특정 사용자만 Claude Tag를 쓰도록 제한할 수 있습니다.

다이렉트 메시지와 감사 추적

Claude Tag에서 DM은 공유 채널과 다르게 동작합니다. DM은 사용자 개인의 Claude.ai 계정 위에서, 즉 그 사람의 커넥터와 자격 증명, 그리고 그 사람의 이름으로 실행됩니다. 따라서 이메일 초안이나 본인만 라이선스를 가진 소프트웨어처럼 채널에 두어서는 안 되는 작업에는 DM이 적합합니다.

보안 측면에서, 관리자가 채널 프로필에 연결을 추가하면 해당 자격 증명은 독립적으로 저장되어 그 채널의 정체성에 매핑되고, 요청 시점에 네트워크 경계에서 주입됩니다. 관리자가 허용하지 않은 호스트로 나가는 트래픽은 곧바로 차단됩니다. 감사(audit) 측면에서는 에이전트 자격 증명으로 이뤄진 모든 루틴, 메모리 쓰기, 네트워크 호출이 기록되며, Claude가 자신의 서비스 계정으로 행동하므로 그 행위들은 연결된 각 시스템의 자체 로그에도 함께 남습니다. Anthropic은 앞으로 적시 자격 증명 부여(just-in-time credential grants) 와, 채널 프로필과 요청 사용자의 권한이 모두 허용할 때만 Claude가 행동하는 정체성 인식 오버레이 를 더해 이 모델을 강화할 계획이라고 밝혔습니다.

시작하기

Claude Tag는 팀과 조직을 염두에 두고 설계되어, @Claude의 민감한 데이터 및 작업별 도구에 대한 접근을 매우 촘촘하게 통제할 수 있습니다. 시스템 관리자는 모델이 어떤 채널에서 어떤 도구와 정보에 접근해야 하는지를 지정합니다. 용도별로 별개의 Claude 정체성을 만든다고 생각하면 됩니다. 영업용으로 설정된 모델은 엔지니어링용 모델에 메모리를 넘기지 않고, 엔지니어에게 영업 데이터나 도구 접근을 주지도 않습니다.

Claude Enterprise 또는 Team 고객이라면 오늘부터 베타로 Claude Tag를 사용할 수 있으며, 관리자 설정 페이지에서 다음 네 단계를 따르면 됩니다.

Claude Tag를 Slack 워크스페이스와 페어링하기
Claude에게 도구 접근 권한 부여하기
조직의 월간 지출 한도 설정하기
비공개 채널에서 Claude를 테스트해 정상 동작 확인하기

Claude Tag는 기존 Claude in Slack 앱을 대체하며, 관리자는 30일 이내에 옵트인하여 마이그레이션할 수 있습니다. Anthropic은 자격을 갖춘 Enterprise 및 Team 조직에 회사 전체가 시험해 볼 수 있도록 도입용 런치 크레딧(launch credit)을 제공합니다. 관리자는 조직 및 채널별로 토큰 지출 한도를 설정할 수 있고, @Claude가 수행한 모든 작업과 각 작업을 누가 요청했는지를 로그로 확인할 수 있습니다.

정리하며: 새로울 것 없는, 그래서 더 중요한 원칙들

인간-에이전트 팀의 토대를 놓을 때 Anthropic은 다음과 같은 질문을 던져 보라고 권합니다. 에이전트와 사람이 필요로 하는 모든 정보와 접근이 공개되어 있고 폭넓게 검색 가능한가? 팀의 명단(사람과 에이전트)을 적어 내고 각 구성원이 무엇을 소유하는지 말할 수 있는가? 모든 사람과 에이전트가 자기 일을 수행할 올바른 도구에 접근할 수 있는가? 핵심 산출물을 검증할 루브릭이나 테스트가 있는가? 모두가 참조할 수 있는 분명한 북극성이 있는가?

흥미로운 점은, 이 패턴들이 사람에게는 전혀 새롭지 않다 는 것입니다. 강력한 북극성, 분명한 역할, 탄탄한 문서화, 품질에 대한 공통 기준, 실수로부터 배울 여지는 수십 년간 알려져 온 건강한 팀의 습관입니다. 에이전트는 단지 이 기본기를 건너뛰지 않는 것 을 더욱 중요하게 만들 뿐입니다. 에이전트에게서 가장 많은 것을 얻는 팀은, 이 기본기를 가장 의도적으로 적용하는 팀입니다.

개발자 관점에서 보면, Claude Tag와 멀티플레이어 에이전트는 어떤 모델이 더 똑똑한가 를 넘어 조직이 에이전트와 함께 일할 준비가 되어 있는가 라는 질문을 던집니다. 정보를 공개적으로 남기고, 역할과 검증 체계를 설계하고, 접근 권한을 구획화하는 일은 결국 사람과 AI가 같은 팀으로 일하기 위한 인프라이자 문화입니다. Claude Code의 에이전트 팀(Agent Teams) 기능이나 Claude Tag로 직접 멀티플레이어 에이전트를 구성해 보며, 이 변화가 자신의 팀에 어떤 의미인지 가늠해 볼 수 있습니다.

Introducing Claude Tag 발표 블로그

Building effective human-agent teams 블로그

Agent identity in Claude Tag 블로그

Claude Tag 공식 문서

Claude Tag 제품 페이지

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다!
텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~