2026년 7월 9일, Anthropic은 Slack 채널에서 Claude를 직접 언급(mention)하는 방식이 어떻게 작동하는지에 대한 별도의 실습 웨비나를 진행했습니다. 공식 발표는 그보다 앞선 6월 23일에 있었지만, 7월 미팅을 통해 회사는 팀을 위한 구체적인 시나리오를 선보였습니다. 핵심은 간단합니다. 이제 어시스턴트와 개인 채팅을 여는 대신, 공용 스레드(thread)에 태그를 달면 Claude가 채널의 대화 내용을 파악하여 모두가 보는 앞에서 답변을 남깁니다.

독립 언론들은 이를 한 단어로 '멀티플레이어(multiplayer)'라고 묘사했습니다. TechRadar Pro는 이번 출시를 개인용 AI에서 팀용 AI로의 전환이라고 정의합니다. 즉, 어시스턴트가 더 이상 당신만의 개인적인 대화 상대가 아니라 공용 대화의 참여자가 되는 것입니다. 이는 사소한 통합처럼 들릴 수 있지만, 그 이면에는 제가 분석하고자 하는 세 가지 큰 질문이 숨어 있습니다. 바로 채널의 공통 컨텍ст(context), 답변의 투명성, 그리고 데이터 접근에 대한 새로운 규칙입니다.

만약 당신이 업무 프로세스에 AI를 도입하는 책임을 맡고 있다면, Slack 자체를 사용하지 않더라도 이 모델을 분석하는 것은 유용합니다. 어시스턴트가 공용 대화에 접근할 수 있는 곳이라면 어디든 동일한 선택의 기로가 나타나기 때문입니다. 다양한 모델로 가설을 빠르게 검증하려면 VPN 없이 Claude, GPT, Gemini에 통합 접근할 수 있는 환경을 곁에 두는 것이 편리합니다. 이후 내용은 오직 출처를 통해 확인된 사실만을 다루며, 벤더의 발표가 끝나고 저의 해석이 시작되는 지점은 솔직하게 표시하겠습니다.

정확히 무엇이 출시되었고, 무엇이 출시되지 않았는가?

이러한 발표를 둘러싸고 빠르게 신화가 만들어지기 때문에, 우선 경계(boundaries)부터 짚고 넘어가겠습니다. Anthropic의 데이터에 따르면, 이 메커니즘은 Slack에서 Claude를 언급(mention)하는 방식이라고 불립니다. 메시지에 태그를 달면 어시스턴트가 동일한 스레드에서 답변합니다. TechRadar Pro는 이를 AI를 멀티플레이어(multiplayer)로 만드는 방법, 즉 한 대화에서 여러 사람이 동시에 사용할 수 있도록 만드는 방법이라고 설명합니다.

그리고 출처로부터 얻은 중요한 주의 사항이 있습니다. 웨비나 날짜는 7월이며, 최초 발표는 6월 23일입니다. 이것은 사람 없이 스스로 작업을 수행하며 돌아다니는 완전히 자율적인 에이전트 (autonomous agent)의 출시가 아닙니다. 이것은 태그를 통해 수동으로 호출되는 공용 대화 속의 어시스턴트 (assistant)입니다. 이 둘 사이에는 근본적인 차이가 있습니다. 자율적인 에이전트는 스스로 행동을 개시하지만, 여기서는 멘션 (mention)을 남긴 사람이 주도자입니다. 만약 토론 중에 누군가가 이를 "Slack의 자율적인 직원"이라고 부른다면, 그것은 벤더 (vendor)의 의도를 넘겨짚는 것입니다.

이것이 실무에서 무엇을 변화시킬까요? 어시스턴트와의 개인 채팅에서 컨텍스트 (context)는 사용자의 메시지로 제한됩니다. 채널에서의 컨텍스트는 모든 참여자가 볼 수 있는 공용 대화 내용입니다. Claude의 답변 또한 모두에게 보입니다. 바로 이 프라이빗 (private)에서 공용 (shared)으로의 전환이 이번 뉴스의 핵심 내용입니다. 요금 체계의 세부 사항, 제한 사항, 지원되는 채널 유형의 정확한 목록을 포함한 나머지 모든 내용은 제가 제공한 출처에 공개되지 않았으므로, 임의로 꾸며내지 않겠습니다.

팀을 위한 초기 실무적 결론은 다음과 같습니다. Claude를 공용 채널로 부르기 전에 세 가지를 결정하십시오. 어떤 채널이 어시스턴트에 연결되어 있는지, 누가 태그할 권한을 가졌는지, 그리고 참여자들이 자신의 메시지가 모델의 컨텍스트가 된다는 사실을 이해하고 있는지입니다. 이 중 어느 것도 통합 (integration) 설치 사실만으로 저절로 해결되지 않습니다.

채널의 공용 컨텍스트는 어떻게 작동하는가?

여기서부터 엔지니어링 (engineering)적인 부분이 시작됩니다. 어시스턴트가 개인 채팅에서 답변할 때, 모델은 입력값으로 좁은 범위의 메시지 세트를 받습니다. 채널에서 태그되었을 때, 주변의 대화 내용이 자연스럽게 컨텍스트에 포함됩니다. 그렇지 않으면 답변이 무의미해질 것이기 때문입니다. Anthropic은 이를 장점으로 내세웁니다. Claude가 스레드 (thread)에서 이미 논의된 내용을 고려하여 답변한다는 것입니다. TechRadar Pro 또한 바로 이 공용 컨텍스트 때문에 이 모델을 멀티플레이어 (multiplayer)라고 부르며 이 프레임워크를 지지합니다.

벤더(vendor)의 주장과는 별개로, 저의 공학적 해석은 다음과 같습니다: 공유 컨텍스트(shared context)는 기능(feature)인 동시에 리스크(risk)의 표면이기도 합니다. 기능인 이유는 어시스턴트가 이미 위에 작성된 내용을 다시 묻지 않기 때문입니다. 리스크인 이유는 모델이 "보는" 범위의 경계가 이제 단일 대화의 경계가 아니라 채널의 경계와 일치하게 되기 때문입니다. 대화 기록에 남아 있는 모든 것이 잠재적으로 답변을 위한 입력 데이터(input data)가 됩니다.

이것이 추상적인 개념에 그치지 않도록, 전형적인 흐름을 단계별로 나누어 설명하겠습니다. 이것은 Anthropic의 공식 문서가 아니라, 이와 유사한 모든 통합(integration) 사례를 읽는 방법론으로서의 작업 모델입니다.

1. 채널 내 누군가가 메시지에 Claude를 언급하는 태그를 답니다.
2. 어시스턴트는 해당 메시지와 스레드(thread)의 관련 컨텍스트(context)를 입력값으로 받습니다.
3. 모델이 답변을 생성하고 동일한 스레드에 게시합니다.
4. 답변과 최초의 언급은 채널 히스토리에 남아 참여자들에게 공개됩니다.

네 번째 단계에 주목하십시오. 개인 채팅(DM)에서 어시스턴트와의 대화는 당신만의 것입니다. 하지만 채널에서는 질문과 답변 모두 공용 히스토리의 일부가 됩니다. 이것이 바로 편집자적 관점(editorial-angle)에서 말하는 투명성입니다: 어떤 참여자든 Claude에게 정확히 무엇을 물었고 무엇이라고 답변했는지 볼 수 있습니다. 여기서 투명성은 마케팅 수식어가 아니라 문자 그대로의 속성입니다: 답변은 비공개(private)가 아닙니다.

여기서부터 채널 설계에 관한 실무적인 규칙이 도출됩니다. 민감도에 따라 공간을 미리 분리하십시오. 공개 릴리스(public release)를 논의하는 채널과 고객 데이터 또는 인시던트(incident) 정보가 담긴 채널은 서로 다른 멘션(mention) 정책을 요구합니다. 공용 대화에서의 어시스턴트는 채널에 이미 존재하는 것을 강화합니다: 만약 채널 내에 공개된 주제와 폐쇄적인 주제가 섞여 있다면, 공유 컨텍스트는 그 혼합을 더욱 두드러지게 만들 것입니다.

여기서 보안 및 데이터 접근 리스크는 무엇인가?

엔터프라이즈(enterprise)에서 가장 중요한 보안(security) 및 접근 규칙에 대해 살펴보겠습니다. 미리 말씀드리자면, 제가 참고한 소스에는 구체적인 기업용 설정, 관리자 권한 및 저장 세부 사항이 기술되어 있지 않으므로, Anthropic이 존재하지 않는 보장을 제공한다고 단정 짓지는 않겠습니다. 저는 제품의 확인된 기능 목록이 아니라, 리스크의 유형(class)으로서 이를 분석합니다.

첫 번째 리스크 모드는 오디언스(audience) 간의 컨텍스트(context) 유출입니다. 채널 내의 모델은 해당 채널의 대화 내용을 볼 수 있습니다. 만약 스레드(thread)에 새로운 참가자가 추가되었거나 채널의 범위가 질문 작성자가 예상했던 것보다 넓다면, 어시스턴트의 답변은 일부 사람들이 그런 형태로 봐서는 안 될 정보를 수집하여 보여줄 수 있습니다. 이는 모델의 버그가 아니라 공용 컨텍스트(common context)의 특성입니다. 이는 연결된 채널에 어떤 데이터를 포함할 것인지에 대한 정책과 같은 조직적인 방식으로 해결해야 합니다.

두 번째 모드는 공개된 장소에서의 답변에 대한 잘못된 신뢰입니다. 어시스턴트가 개인 채팅(personal chat)에서 답변할 때는 사용자가 직접 답변을 평가합니다. 하지만 어시스턴트가 공개 스레드에서 답변할 때는 공개성이 권위의 환상을 만들어냅니다: "채널에서 모두가 보는 가운데 작성된 것이니 검증된 것이겠지"라고 생각하게 되는 것입니다. Anthropic은 채널에서의 답변이 더 정확하다고 주장하지 않습니다. 그것은 허구일 것입니다. 투명성은 답변을 모두에게 보여줄 뿐, 그것을 정답으로 만들지는 않습니다. 사실 관계 확인은 여전히 사람이 수행해야 합니다.

세 번째 모드는 멘션(mention)에 대한 책임의 모호함입니다. 채널 내의 누구나 어시스턴트를 태그(tag)할 수 있다면, 누구나 입력 데이터(input data)를 제공할 수 있다는 뜻입니다. 민감한 공간에서 누가, 어떤 주제로 Claude를 호출할 권한이 있는지 사전에 합의해야 합니다. 이는 순수하게 프로세스적인 통제이며, 별도의 설정 없이 자동으로 제공되는 기능은 아닙니다.

네 번째 모드는 조용한 공격 표면(attack surface)의 확장입니다. 어시스턴트에 연결되는 매 새로운 채널은 공용 컨텍스트가 모델의 입력값으로 들어가는 또 다른 지점이 됩니다. 리포지토리(repository) 접근 권한을 검토하는 것과 마찬가지로, 이러한 채널들의 레지스트리(registry)를 작성하고 정기적으로 검토하는 것이 유용합니다.

만약 당신이 러시아에 거주 중이며, 기업용 Slack에 적용하기 전에 Claude의 실제 동작을 바탕으로 이러한 시나리오를 실행해보고 싶다면, 모델에 직접 접근할 수 있는 방법이 유용합니다. 여기 provod.ai를 통해 Claude, GPT, Gemini, DeepSeek, Qwen을 하나의 API로 제공하며, 루블화 결제가 가능하고 해외 카드가 필요하지 않습니다. 이는 Slack 통합 기능이나 Claude Tag 자체를 대체하는 것이 아니라, 샌드박스(sandbox) 환경에서 자신의 데이터를 사용하여 프롬프트(prompt)와 모델의 응답을 미리 테스트할 수 있는 방법입니다. OpenAI 및 Anthropic SDK와의 호환성 덕분에 키(key)와 base_url만 변경하면 테스트 스크립트가 모델과 통신할 수 있습니다.

from anthropic import Anthropic

# 채널에 배포하기 전 모델 응답을 확인하기 위한 샌드박스
...

개인용 어시스턴트 vs 채널 참여자: 의사결정 테이블

언급(mention) 기능을 활성화할지 아니면 개인 채팅으로 남겨둘지를 결정하기 위해, 두 방식의 차이점을 하나의 테이블로 정리하는 것이 유용합니다. 원문에 수치적 지표는 없으므로, 이 테이블은 수치가 아닌 두 모드의 특성에 기반한 정성적(qualitative) 테이블입니다.

테이블 읽는 법: 만약 작업이 개인적이고 데이터가 민감하다면, 공용 채널은 필요하지 않습니다. 공용 채널은 단지 응답을 보는 대상(audience)을 확장할 뿐입니다. 만약 작업이 진정으로 팀 단위의 작업이고 참여자들이 이미 논의 내용을 보고 있다면, 채널 모드가 정당화됩니다. 이 경우 투명성은 단점이 아닌 장점이 되는데, 모든 사람이 동일한 버전의 응답을 볼 수 있기 때문입니다.

경제성에 대해 솔직하게 말씀드리겠습니다. 제공된 소스에는 Claude Tag의 정확한 가격이나 제한 사항이 명시되어 있지 않으므로, 비용이나 할당량(Quota)을 언급하지 않겠습니다. 구체적인 수치를 제시하는 것은 허구일 뿐입니다. 허구 없이 말할 수 있는 사실은 다음과 같습니다. 채널에서의 모든 응답은 모델에 대한 호출(Call)이며, 공용 공간에서의 잠재적 호출자는 개인 채팅보다 훨씬 많습니다. 즉, 대규모 사용 시 부하와 관련 비용은 직원 수가 아니라 언급(Mention) 횟수에 따라 증가합니다. 이는 어시스턴트를 모든 채널에 즉시 개방하기보다, 태깅(Tagging) 규칙을 먼저 설정해야 한다는 근거가 됩니다.

또 다른 냉철한 관점은 기대치 관리입니다. 멀티플레이어(Multiplayer) 방식의 접근은

여섯 번째는 모델에 직접 접근함으로써 어시스턴트의 행동을 연습(rehearse)해 볼 수 있는 바로 그 경우입니다. 시스템 제약 사항(system constraints)을 설정하고, 모델이 컨텍스트(context)에서 불필요한 정보를 출력하지 않는지 확인한 다음, 성공적인 문구들을 작업 공간(workspace)으로 옮깁니다.

이것이 해결하지 못하는 것