Claude Tag란? @Claude로 업무를 위임하는 Slack 협업 방식(Slack in Claude, Claude Tag는 무엇이 다른가)

안녕하세요! 갓대희 입니다.

Slack에서 @Claude라고 한 번만 부르면 일을 맡길 수 있는 도구가 나왔다.

이름은 Claude Tag. 2026년 6월, Team·Enterprise 고객 대상 베타로 공개됐다.

 

이 글을 읽기 전에, 다들 제일 먼저 궁금해하는 것부터 바로 풀고 시작하자.

Q. 나는 개인 Pro나 Max 요금제인데, Claude Tag 쓸 수 있어?

→ 아니요, 지금은 안 됩니다. Claude Tag는 회사(조직)가 Team 또는 Enterprise 플랜일 때만 관리자가 켤 수 있는 기능이다. 개인이 쓰는 무료·Pro·Max 요금제로는 우회 방법이나 개인 업그레이드 경로가 없다. 회사 전체가 Team·Enterprise가 아니라면, 지금 당장은 사용할 수 없다.

2026-07-06 기준 공식 문서에 공개된 범위는 Team·Enterprise 플랜의 Slack 베타다. 다른 요금제나 다른 협업 도구 지원 시점은 확인되지 않았다.

기존 Claude in Slack 또는 Claude Code in Slack을 써본 팀이라면 Slack에서 @Claude를 부르는 흐름은 익숙할 수 있다. 다만 Claude Tag는 권한 범위, 청구 주체, PR 작성 주체, Agent Identity가 달라지는 새 경험이다. 
https://code.claude.com/docs/en/slack

캡처 주의: 아래 일부 화면은 실제 Claude Tag 화면이 아니라 기존 Claude Code in Slack/Claude in Slack 기준의 참고 화면이다. UI 흐름을 이해하기 위한 예시로만 보고, Claude Tag의 권한·청구·PR 작성 주체·Agent Identity는 공식 Claude Tag 문서를 기준으로 확인해야 한다.

공식 화면으로 캡처하면 좋은 지점

• Claude Tag 제품 페이지: 실제 @Claude 화면 예시와 Team·Enterprise 베타 문구
• Claude Tag Overview: 개인 플랜 미지원, 실행 환경, usage balance 설명
• Security and data handling: Agent Proxy, credential store, default-deny 네트워크 흐름

Claude Code in Slack - Claude Code Docs

 

"우리 회사는 개인 요금제만 쓴다"면 이 글은 미리보기 정도로만 읽고, 나머지는 회사가 Team·Enterprise로 옮겨갈 때를 위해 저장해두면 된다. 반대로 "우리 회사가 Team이나 Enterprise 고객"이라면, 지금부터 나오는 내용이 바로 실무에 쓰일 이야기다.

처음 읽는 분을 위한 안내

이 글은 총 8개 섹션이다.
시간이 없다면 1(뭔지) → 3(뭘 할 수 있는지) → 5(실제 예시) → 8(FAQ)만 읽어도 충분하다.
4장(내부 구조)은 보안 담당자·관리자용으로, 일반 사용자는 건너뛰어도 된다.

Anthropic은 자기 회사 제품팀 코드의 상당 부분을 내부 버전 Claude Tag로 만들고 있다고 밝혔다.

자기가 만든 도구를 자기 개발 과정에 이 정도로 깊이 쓴다면, 단순한 채팅 봇 취급하고 넘어가기는 어렵다.

 

그래서 이 글은 "Claude Tag가 뭔가"라는 정의보다 "언제, 어떻게 쓰는가"에 초점을 둔다.

목차

1. Claude Tag란 — Slack에 상주하는 팀 단위 Claude
2. 시작하기 — 관리자 4단계 설정
3. 핵심 기능 — 위임·비동기·Ambient 동작
4. (선택) 내부 구조 — 채널 격리 모델
5. 실전 활용 시나리오 4가지 — 언제·어떻게 쓰는가
6. 요금제와 제한사항
7. 대안 비교 — Claude.ai 채팅·API 직접 호출 대비
8. 자주 묻는 질문과 결론

용어부터 쉽게 잡고 가자

• Claude Tag: Slack 채널에 상주하며 @Claude라고 부르면 일을 맡을 수 있는 팀용 Claude. 채팅창이 아니라 '팀에 새로 들어온 동료'라고 생각하면 쉽다.
• 멀티플레이어: 채널마다 Claude가 한 명씩 있고, 그 한 명을 팀원 전체가 같이 쓴다는 뜻. 나만의 개인 챗봇이 아니라 '팀 공용 계정' 개념에 가깝다.
• Ambient 동작: 공식 문서의 ambient presence/ambient behavior를 이 글에서 쉽게 부르는 말. 누가 부르지 않아도 Claude가 채널 흐름을 보고 필요하다고 판단하면 먼저 답할 수 있는 동작이다.
• 에피메럴 샌드박스: 작업할 때마다 새로 만들었다가 끝나면 바로 없애버리는 임시 작업 공간. '1회용 컴퓨터'라고 이해하면 된다.
• usage balance(사용량 잔액): 회사(조직) 단위로 깎이는 사용량 한도. 통신사 데이터 요금제처럼, 회사 전체가 하나의 잔액을 나눠 쓴다고 보면 된다.
• Connections/도구 연결: Claude가 외부 도구나 데이터(예: 사내 데이터베이스, 깃허브)에 접근하도록 조직 관리자가 붙여주는 연결.
• Member Access: Claude Tag를 누가 호출할 수 있는지 제한하는 설정. Enterprise에서는 역할과 capability를 이용한 제한까지 가능하다.
• Routines(루틴): 사람이 매번 태그하지 않아도 알아서 반복 실행되는 작업. 예: 매일 아침 지표 요약, PR 올라오면 자동 확인.

 

1. Claude Tag란 — Slack에 상주하는 팀 단위 Claude

Claude Tag를 한 문장으로 줄이면 이렇다. "팀이 이미 쓰고 있는 Slack 채널 안으로, 일을 맡길 수 있는 Claude가 직접 들어온다."

개인이 Claude.ai 탭을 따로 여는 방식과는 다르다.
팀원들이 원래 대화하던 그 채널에 Claude가 상주한다.

핵심은 "멀티플레이어" 구조다. 공식 발표는 채널과 Claude의 관계를 이렇게 설명한다.

"Within a given Slack channel, there's one Claude that interacts with everyone."
(Slack 채널마다 팀원 모두와 상호작용하는 Claude가 하나씩 있습니다.)

 

쉽게 풀면 이렇다. 채널 하나에 Claude는 딱 한 명이고, 그 한 명을 팀원 전체가 같이 쓴다.

사람마다 별도 대화창이 열리는 개인 채팅과는 다르다. 한 채널의 모든 사람이 같은 Claude와, 같은 대화 맥락 위에서 이야기한다. 그래서 좋은 점이 있다. 누구나 Claude가 지금까지 뭘 했는지 볼 수 있고, 다른 사람이 멈춘 지점부터 이어서 대화할 수 있다.

예를 들면, 채널마다 하나의 @Claude가 붙어 있다고 이해하면 된다.

 

기존 Claude 인터페이스와 가장 다른 지점도 여기다.

Claude.ai 채팅은 '나 혼자 쓰는 세션'이고, Claude Tag는 '채널 전체가 공유하는, 계속 이어지는 동료'다.

이 차이를 실무에서 어떻게 체감하는지는 7장 대안 비교에서 다시 정리했다.

Anthropic이 밝힌 도입 이유

Anthropic은 공식 발표에서 "현재 제품팀 코드의 65%가 내부 버전 Claude Tag로 작성된다"고 밝혔다. 만든 회사가 자기 제품 개발에 이 정도 비중으로 쓴다는 건, "그냥 채팅 도우미"가 아니라 "실제로 일을 맡기는 도구"를 목표로 만들었다는 가장 직접적인 근거다.

정의만 놓고 보면 "그냥 Slack 봇 아닌가" 싶을 수 있다.

차이는 여기 있다. 명령어를 외워서 호출하는 봇이 아니라, 사람에게 일을 맡기듯 그냥 말로 부탁하고, 채널의 대화 맥락을 같이 공유한다는 점이다.

이 감각을 가지고 다음 장의 설정·기능을 보면 훨씬 이해가 쉽다.

 

기존 Claude in Slack 화면에서는 아래처럼 모델 선택 UI가 보였다.

아래 화면은 기존 Slack 연동 참고 화면이며, Claude Tag 실제 UI와 다를 수 있다.

 

출시 발표에서는 Claude Tag가 Opus 4.8과 함께 동작한다고 소개됐다. 다만 최신 공식 문서 기준으로는 조직에서 허용한 모델 중 스레드·채널·DM별로 모델을 바꿀 수 있고, 선택 가능한 모델 목록은 조직 설정에 따라 달라진다.

 

2. 시작하기 — 관리자 4단계 설정

Claude Tag는 일반 팀원이 혼자 켤 수 있는 기능이 아니다. 회사(조직) 관리자가 설정해야 한다.

정확히는 Claude 조직의 Owner 또는 Primary Owner가 Claude Tag의 identity와 Access bundle을 설정해야 한다. Slack 앱 승인이나 @Claude connect 단계에서는 Slack 워크스페이스 관리자 권한이 추가로 필요할 수 있다. Claude 조직 Admin은 일부 항목을 볼 수 있어도, 워크스페이스 페어링과 Access bundle 생성은 완료하지 못한다.

설정 시작 위치는 claude.ai/admin-settings/claude-tag다.

 

설정 절차는 네 단계, 그리 복잡하지 않다.

단계	할 일	왜 하는가
1	Slack 워크스페이스 연결하기	Claude를 우리 회사 Slack에 연결
2	쓸 수 있는 도구·데이터 정하기	Claude가 어디까지 손댈 수 있는지 범위 지정
3	한 달 지출 한도 정하기	비용이 예상치 못하게 쌓이지 않도록 상한선 설정
4	비공개 채널에서 먼저 테스트	전사에 풀기 전에 좁은 범위에서 확인

 

눈여겨볼 부분은 마지막 단계인 "비공개 채널 테스트"다.

처음 도입한다면 반드시 이 테스트 채널부터 작게 시작하자. 전사 채널에 곧바로 붙이면, 도구 권한과 비용이 어디까지 열려 있는지 확인할 틈도 없이 많은 사람이 한꺼번에 쓰기 시작한다.

 

설정이 끝나면 Claude Tag를 쓰는 방법은 세 가지다.

1) 채널에서 @Claude라고 태그하기
아래 예시 화면에서는 Claude Tag로 마이그레이션된다는 안내가 보인다. 다만 실제 Claude Tag 화면이 아니라 기존 Slack 연동 참고 화면이다.

2) Claude와 1:1 DM 하기

 

3) Slack 화면 위쪽 AI assistant 아이콘으로 Claude 패널 열기.

 

채널에서 태그하면 회사가 정한 채널 권한과 회사 usage balance(사용량 잔액)를 쓴다. DM과 패널은 개인 계정 쪽 기능에 더 가깝다. 이 차이는 6장 요금제에서 다시 자세히 다룬다.

 

관리자 입장에서 중요한 점이 하나 더 있다. Claude Tag가 외부 도구에서 수행한 작업은 서비스 계정 기준으로 추적 가능해야 한다는 것.

Anthropic 공식 문서 기준으로 관리자는 조직·채널별 지출 한도를 정할 수 있고, @Claude가 Slack·GitHub·연결 도구에서 남긴 활동은 Claude app, Claude GitHub App, 또는 별도 서비스 계정의 audit trail로 남는다.

그러니 도입 전에는 기능만 테스트하지 말고, Slack 스레드 링크와 연결 도구의 audit log에서 작업 출처가 어떻게 보이는지까지 확인해보자.

설정 권한 주의

Claude Tag 설정의 핵심 권한은 Claude 조직 Owner/Primary Owner다. Slack 앱 승인이나 워크스페이스 연결 단계에서는 Slack 쪽 관리자 권한도 필요할 수 있다. 도입을 검토 중이라면 "우리 Claude 조직 Owner와 Slack 승인 담당자가 누구지?"부터 확인하자.

기존에 "Claude in Slack" 앱을 쓰던 팀이라면 일정도 챙겨야 한다.

지원 문서 기준으로 이 앱은 2026년 8월 3일에 Claude Tag 경험으로 전환된다. 다만 기존 사용자 연결이나 도구 접근이 그대로 넘어간다고 보면 안 된다.

마이그레이션 기한 주의

기존 Claude in Slack은 2026년 8월 3일에 Claude Tag 경험으로 전환될 예정이다. 하지만 새 Claude Tag는 채널 단위 Agent Identity로 동작하므로, GitHub 저장소·연결 도구·서비스 계정 권한은 Access bundle로 다시 구성해야 한다. 기존 앱에 의존하는 업무가 있다면, 전환일 전에 어떤 채널을 New/Legacy/Off 중 어디에 둘지와 어떤 도구 권한을 붙일지 먼저 정리하자.

 

혹시나 하여 미리 https://claude.ai/admin-settings/claude-tag 에서 설정 가능한지 확인해 보았으나

 - 개인 사용자는 다음과 같이 안내 되고 있다.

 

 

3. 핵심 기능 — 위임·비동기·Ambient 동작

Claude Tag의 기능을 한 줄로 줄이면 이렇다. "맡기고, 기다리지 않고, 먼저 챙긴다."

채널에서 일을 맡기는 기본 동작 위에, "기다릴 필요 없는 실행 방식"과 "먼저 알아서 챙기는 기능"이 얹혀 있다. 반복되는 작업은 루틴으로 등록해두면 된다.

 

가장 기본이 되는 건 비동기 실행이다. 쉽게 말해 "시켜두고 신경 안 써도 되는" 방식이다.

일을 넘긴 뒤 사용자는 다른 일을 하면 된다. Claude는 그동안 알아서 작업을 진행하고, 결과가 나오면 채널 스레드에 올라온다. 답을 기다리며 대화창을 계속 붙잡고 있지 않아도 된다는 뜻이다.

 

Ambient 동작은 한 단계 더 적극적이다.

공식 문서 표현으로는 Claude가 채널 안의 ambient presence처럼 동작할 수 있다는 뜻이다. 즉, 늘 @Claude를 붙여야만 하는 것은 아니다. 채널 흐름을 보고 답할 만하다고 판단하면 먼저 정보를 알려줄 수 있다. 부르면 대답하는 도구가 아니라, 옆에서 지켜보다가 알아서 끼어드는 동료에 가깝다.

Ambient 동작이 바꾸는 것

평소에는 Claude가 @Claude 태그가 있을 때 응답이 보장된다. Ambient 동작에서는 태그 없이도 채널 흐름을 보고 먼저 움직일 수 있다. 편리한 만큼, 비용과 승인 절차 측면의 부담도 함께 커진다. 이 한계는 6장에서 자세히 다룬다.

여기에 채널 메모리가 더해진다. 쉽게 말해 "이 채널에서 있었던 일을 Claude가 계속 기억한다"는 뜻이다.

Anthropic이 다른 글에서 짚은 원칙이 이 설계를 잘 설명해준다 — "에이전트에게는, 적혀 있지 않고 접근할 수 없다면 그것은 존재하지 않는 것과 같다."

 

사람끼리는 구두로 합의하거나 어깨너머로 들은 이야기도 통한다. 하지만 Claude에게는 채널에 실제로 기록된 대화만 존재하는 정보다. 그래서 Claude는 채널 안의 대화를 계속 따라가며 팀의 작업 맥락을 조금씩 배운다. 시간이 지날수록 그 채널의 일을 더 잘 이해하게 되는 구조다.

 

다만 알아둘 점이 있다. 공식 문서 기준으로 이 메모리는 '개인'이 아니라 '채널과 워크스페이스'에 붙는다.

공개 채널에서 만들어진 메모리는 회사 전체(워크스페이스) 차원에서 공유되고, 비공개 채널에서 쌓인 메모리는 그 채널만의 별도 저장소에 남는다.

앞서 말한 멀티플레이어 구조와 합쳐지면, 한 사람이 시작한 작업을 다른 사람이 같은 맥락 위에서 자연스럽게 이어받을 수 있다.

 

핵심 기능을 표로 정리하면 다음과 같다.

기능	쉽게 말하면	언제 작동하나
작업 위임	말로 부탁하면 실제로 일을 해줌	채널에서 @Claude 멘션할 때
비동기 실행	시켜두면 알아서 하고 스레드에 결과만 올려줌	일을 맡기면 자동으로
Ambient 동작	안 불러도 채널 지켜보다가 먼저 알려줌	채널 응답 설정과 루틴에 따라
채널 메모리	이 채널에서 있었던 일을 계속 기억함	채널에 상주하는 동안 항상
루틴	매번 안 불러도 반복해서 알아서 실행	채널에서 루틴 등록해두면
응답 제어	특정 스레드나 채널에서 조용히 시키거나 아예 빼기	직접 지시하거나 /remove @Claude

기능 체크 — 우리 팀엔 뭐가 맞을까

• 결과가 명확한 작업을 그냥 넘기고 싶다 → 작업 위임 + 비동기 실행
• 채널에서 중요한 걸 놓치기 싫다 → Ambient 동작 (다만 비용·승인 문제는 꼭 확인)
• 여러 사람이 같은 일을 이어서 해야 한다 → 멀티플레이어 + 채널 메모리
• 매일 똑같은 점검이나 알림이 필요하다 → 루틴

 

4. (선택) 내부 구조 — 채널 격리 모델

이 섹션은 보안 담당자·관리자용으로 다소 기술적이다. 그냥 사용자로서 궁금한 분이면 5장으로 건너뛰어도 무방하다.

공식 문서는 Claude Tag의 작업이 어디서 도는지 이렇게 설명한다.

"an ephemeral sandbox hosted by Anthropic, not on your computer or inside your network."
(작업은 사용자의 컴퓨터나 내부 네트워크가 아니라, Anthropic이 제공하는 임시 샌드박스 환경에서 실행됩니다.)

쉽게 말해, 작업은 사용자 PC나 회사 내부망 안이 아니라 Anthropic이 관리하는 임시 공간(에피메럴 샌드박스)에서 돌아간다. 작업이 끝나면 이 공간은 바로 사라진다. 그래서 실행 환경이 회사 인프라에 직접 붙어 있지 않다.

 

권한 모델도 공식 문서에 나와 있는 확정된 사실이다.

Claude가 무엇에 접근할 수 있는지는 "누가 쓰는가"가 아니라 "지금 어느 채널에 있는가"로 정해진다. 사람의 신원이 아니라 채널이 기준이라는 게 이 설계의 핵심이고, 동시에 6장에서 다룰 보안 우려의 출발점이기도 하다.

 

여기서부터는 공개된 정보를 종합한 추정이다.

기존 Claude in Slack은 사용자별 계정 연결을 바탕으로 동작했다. 반면 Claude Tag는 채널이 메모리를 공유하고, 조직이 provision한 Agent Identity가 도구에 접근하는 방식으로 바뀐다. 공식 문서는 Claude Tag가 채널 메모리와 세션 트랜스크립트를 보존하기 때문에, Zero Data Retention(ZDR, 데이터를 아예 남기지 않는 정책)을 켠 회사에는 제공되지 않는다고 명시한다.

 

보안 설계에서 더 중요한 부분은 Agent Proxy다.

연결에 필요한 자격증명(비밀번호나 인증 토큰 같은 것)은 샌드박스 안에 직접 들어가지 않는다.

별도 저장소(credential store)에 보관되고, 외부 시스템에 요청을 보낼 때만 Agent Proxy가 허용 규칙을 확인한 뒤 그 경계에서 자격증명을 붙인다.

 

샌드박스에서 나가는 HTTP/HTTPS 요청은 Agent Proxy에서 connection rule, bundle의 domain list, environment network access 중 하나에 허용되어야 한다. 아무 규칙에도 걸리지 않으면 인증 실패가 아니라 요청 자체가 차단된다. 다만 기본 Trusted 환경의 개발자 호스트 허용, 조직이 별도로 켠 allow-all egress, 서버 측 web search처럼 별도 경로도 있으므로 "무조건 모든 외부 요청이 막힌다"로 단순화하면 안 된다.

항목	공개된 설계	근거 수준
실행 환경	Anthropic이 관리하는 임시 격리 공간	공식 문서(확정)
접근 범위	사람이 아니라 채널 단위로 결정	공식 문서(확정)
메모리 모델	공개 채널은 회사 전체 공유, 비공개 채널은 그 채널만의 저장소	공식 문서(확정)
자격증명 처리	샌드박스가 아닌 별도 저장소에 보관, 경계에서만 주입	공식 문서(확정)
네트워크 정책	connection rule·domain list·environment network access에 없는 요청은 기본 차단	공식 문서(확정)
ZDR 지원	채널 메모리·세션 트랜스크립트를 보존하기 때문에 ZDR 회사는 이용 불가	공식 문서(확정)

 

표를 한 줄로 요약하면 이렇다 — 접근 권한이 "누가"가 아니라 "어느 채널"로 정해지므로, 채널 멤버 관리가 곧 보안 경계다.

채널 스코프 격리, 실무에서 뭘 뜻하나

Enterprise 플랜에는 Claude Tag를 쓸 수 있는 사람을 제한하는 기능(역할 기반 Member Access)이 있다. 하지만 한 채널에 붙은 서비스 계정 권한은 그 채널에 있는 사람이라면 누구나 함께 쓴다.

그래서 민감한 도구를 연결한 채널일수록 두 가지를 따로 확인해야 한다. "누가 Claude Tag를 호출할 수 있는가"와 "그 채널의 서비스 계정이 어디까지 손댈 수 있는가."

 

5. 실전 활용 시나리오 4가지 — 언제·어떻게 쓰는가

Claude Tag가 실무에서 진짜 쓸모 있어지는 순간을 네 가지로 정리했다. 공통점은 하나다 — "Slack 채널에 이미 있는 맥락을 그대로 활용한다."

5-1. 소프트웨어 엔지니어링 — 조사부터 PR까지 위임

엔지니어가 채널에서 이렇게 태그한다고 해보자.

@Claude can you investigate this latency spike and open a PR with a fix?

(@Claude, 이 지연(latency) 급증 원인을 분석하고, 수정한 뒤 PR까지 생성해 줄래?)

 

이 한 줄만으로 지연 급증의 원인 조사부터 수정 PR 생성까지 통째로 넘어간다.

엔지니어는 부탁만 해두고 다른 작업으로 넘어가면 된다. 결과(PR)가 나오면 스레드에서 확인만 하면 끝. 결과물이 눈으로 딱 확인되는 작업이라, 위임 효과를 가장 체감하기 쉬운 시나리오다.

 

5-2. PM·데이터 분석 — 지표 쿼리를 스레드에서 바로

제품 매니저가 지표(수치) 조회를 부탁하면, 결과가 그대로 채널 스레드에 뜬다.

분석 도구를 따로 열거나 데이터팀에 별도로 요청할 필요가 없다. 지금 논의 중인 그 채널에서 바로 숫자를 받아본다. 결정을 위한 대화와 데이터 조회 사이를 왔다갔다하는 시간을 줄여준다.

 

5-3. 고객 지원 — 티켓 전반의 패턴 발견과 팔로업

고객 지원 업무에서는 Claude가 여러 티켓을 가로질러 반복되는 패턴을 발견해준다.

아직 해결 안 된 이슈도 놓치지 않고 계속 챙긴다. 티켓 하나하나 대응하는 게 아니라, 흩어진 티켓들에서 공통된 신호를 찾아내는 역할이다. 지원 채널에 계속 상주하며 맥락을 쌓아가는 구조라서 가능한 활용이다.

 

5-4. 크로스팀 조율 — 부서 간 연결 지점 표면화

서로 다른 부서가 각자 하는 작업 사이에서 연결 지점을 찾아 드러내준다. 한 팀의 진행 상황이 다른 팀 일과 어떻게 맞물려 있는지 눈에 보이게 해주는 게 목적이다.

여러 채널을 함께 지켜보는 에이전트일수록 이 활용의 가치가 커진다.

 

네 시나리오를 표로 정리하면 다음과 같다.

시나리오	누가 쓰나	부탁 예시	결과
엔지니어링	개발팀	"레이턴시 조사하고 수정 PR 열어줘"	원인 분석 + PR 생성
PM·데이터	제품/데이터팀	지표 쿼리 부탁	결과가 스레드에 바로 표시
고객 지원	CS팀	티켓 패턴 분석 요청	공통 패턴 발견·미해결 추적
크로스팀	여러 부서	부서 간 작업 연결 확인	연결 지점 표면화

 

네 시나리오의 공통점은 명확하다. 별도 도구로 맥락을 옮길 필요 없이, Slack에 이미 있는 대화·티켓·지표 논의를 그대로 쓴다는 점이다.

반대로 중요한 자료가 채널 밖에 있거나, 결과를 사람이 매번 승인해야 하는 작업이라면 효과가 제한적이다.

 

"우리 팀 맥락이 어디에 모여 있는가"가 도입 여부를 가르는 첫 질문인 셈이다.

처음 써본다면

5-1 엔지니어링 시나리오처럼, 결과물이 명확한 작업부터 시작하는 게 낫다.

PR·테스트 통과·쿼리 결과처럼 "됐는지 안 됐는지"가 딱 보이는 작업이 위임 효과를 가장 체감하기 쉽다.

"코드 품질을 높여줘"처럼 끝이 뭔지 애매한 작업은 나중으로 미뤄두자.

 

6. 요금제와 제한사항

앞서 초반에 확인했듯, Claude Tag는 Team·Enterprise 전용이다. 개인 무료·Pro·Max 요금제로는 이용할 수 없다. 아래 내용은 회사가 이미 Team·Enterprise인 경우를 전제로 한 비용·제한 이야기다.

채널과 스레드에서 쓰는 Claude Tag 사용량은 회사(조직) 단위 usage balance(사용량 잔액)에서 깎인다. 사용자 1인당 추가 요금은 없다.

 

단, 예외가 있다. Direct Message(DM)로 Claude에게 직접 보내는 메시지는 회사 잔액이 아니라 개인 claude.ai 계정 한도에서 깎인다. 같은 Claude라도 "채널에서 쓸 때"와 "개인 DM으로 쓸 때"는 요금이 청구되는 곳이 다르다는 점, 꼭 구분해두자.

 

비용을 통제할 수단도 있다. 관리자는 회사 전체 또는 채널별로 지출 한도를 정할 수 있고, 사용량 분석 페이지에서 채널별 breakdown을 볼 수 있다. 단가 예측은 아직 어렵다. 공식 문서도 파일럿에서는 먼저 지출 한도를 작게 잡고 채널별 사용량을 보며 조정하라고 안내한다.

 

단, 이게 ZDR(Zero Data Retention, 데이터 완전 미보존) 지원을 뜻하는 건 아니다.

공식 보안 문서는 Claude Tag가 채널 메모리와 세션 트랜스크립트를 보존하기 때문에, ZDR을 켠 회사에서는 아예 쓸 수 없다고 밝히고 있다. 또한 Slack에서 Claude를 제거하거나 scope를 끄는 것만으로 메모리·루틴·트랜스크립트가 자동 삭제된다고 보면 안 된다. 삭제는 Claude 콘솔의 전용 삭제 controls와 Slack 보존 정책을 분리해 확인해야 한다.

항목	내용
채널·스레드 작업	회사(조직) usage balance에서 차감
개인 DM	개인 claude.ai 계정 한도에서 차감
좌석 요금	1인당 추가 요금 없음
지출 통제	조직 전체·채널별 지출 한도와 채널별 사용량 breakdown 확인
데이터 보존	제거·Off·scope 변경만으로 자동 삭제되지 않음. 전용 삭제 controls와 Slack 보존 정책 확인 필요
ZDR 회사	채널 메모리·세션 트랜스크립트를 보존하기 때문에 이용 불가

 

구체적인 단가는 베타 단계라 앞으로 바뀔 가능성이 크다. (2026-07-01 기준이며, 최신 가격은 공식 페이지에서 확인하자.)

비용 통제 팁

쓴 만큼 청구되는 구조라, 사람이 많이 오가는 채널에서 Claude가 먼저 응답하거나 루틴을 자주 돌면 사용량이 예상보다 빨리 쌓일 수 있다. 도입 초반에는 지출 한도를 보수적으로 잡고, usage page에서 채널별 사용량을 확인할 담당자를 미리 정해두자.

 

알려진 제한도 분명히 짚고 가자.

 

Claude Tag는 현재 Slack 전용이다. Microsoft Teams 같은 다른 협업 도구는 지원하지 않는다. 또한 이 글에서 확인한 공식 문서 범위에서는 Ambient 동작이나 루틴 작업 전에 별도 human approval 흐름이 핵심 통제로 제시된 것을 확인하지 못했다. 그래서 민감한 작업은 낮은 권한의 서비스 계정, 제한된 channel scope, spend limit, audit 확인을 전제로 파일럿부터 시작하는 편이 안전하다.

 

권한 통제는 특히 정확하게 표현하고 넘어가야 한다.

공식 문서 기준으로 Enterprise에는 역할 기반 Member Access가 있어서, 관리자가 Claude Tag를 부를 수 있는 사람을 제한할 수 있다. 하지만 연결된 서비스 계정의 권한 자체는, 그 채널에 들어와 있는 사람이라면 누구든 함께 쓰는 구조다.

보안 검토 포인트 (커뮤니티가 특히 우려하는 부분)

채널 접근 권한이 곧 도구 사용 가능성으로 이어질 수 있다. 그래서 외부 협력사나 일부 인원만 들어와야 하는 채널에 민감한 connector나 서비스 계정 권한을 붙이는 건 위험하다.

공식 문서상 게스트가 포함된 채널은 기본적으로 꺼져 있고, Slack Connect 채널은 항상 꺼져 있다. 그래도 내부 채널 안의 멤버 구성과 서비스 계정 범위는 별개 문제다.

도입 전에 "이 채널에 누가 들어와 있고, Claude의 서비스 계정이 어떤 도구까지 손댈 수 있는가"를 꼭 점검하자.

 

정리하면 비용은 지출 한도로 통제 가능한 변수다.

더 신경 써야 할 쪽은 서비스 계정 권한 공유, ZDR 미지원, 능동 동작의 승인·감사 절차다.

전자는 채널과 접근 권한(Access bundle)을 잘게 나눠 관리하고, 후자는 위험이 낮은 채널부터 조심스럽게 적용 범위를 넓혀가는 게 현실적이다.

 

7. 대안 비교 — Claude.ai 채팅·API 직접 호출 대비

Claude Tag의 위치를 가장 또렷하게 보여주는 비교는 기존 Claude in Slack과의 대비다.

 

기존 통합은 사용자별로 나뉜, 저장이 안 되는(stateless) 방식이었다.

Claude Tag는 계속 이어지는 메모리·회사 단위 아이덴티티·관리자가 정한 도구 접근을 갖춘 "하나의 공유 Claude"다.

같은 Slack 연동이라도, 분리된 개인 세션에서 공유하는 동료로 성격이 바뀐 셈이다.

 

Claude.ai 채팅, API 직접 호출과의 비교는 공개된 정보를 종합해서 정리한 것이다.

Claude.ai 채팅은 개인의 단일 세션에서 사람이 직접 주고받는 작업에 맞고, API 직접 호출은 프로그래밍으로 자동화하거나 비용을 아끼는 데 강하다.

Claude Tag는 개발자가 아니어도 Slack에서 바로 팀 협업 워크플로우를 굴릴 수 있다는 점에서, 셋 중 진입 장벽이 가장 낮다.

비교 기준	Claude.ai 채팅	API 직접 호출	Claude Tag
누가 쓰나	개인	프로그램·애플리케이션	팀 채널 전체
대화 맥락	1개 세션 안에서만	요청할 때마다 새로	채널이 공유하며 계속 이어짐
시작하기 쉬운 정도	쉬움	어려움(코딩 필요)	쉬움(Slack에서 바로)
잘 맞는 작업	1:1 대화·개인 작업	자동화·앱 개발	팀 단위 위임·비동기 실행

 

한 줄로 정리하면, Claude.ai 채팅은 개인의 대화를, API는 개발자의 자동화를, Claude Tag는 팀의 위임을 각각 최적화한 도구다.

셋은 서로 대체하는 경쟁 관계가 아니라, 쓰이는 층위 자체가 다르다.

팀이 이미 Slack에서 일하고 맥락이 거기 모여 있다면 Claude Tag가, 반복 작업을 코드로 자동화하고 싶다면 API가 더 맞는다.

 

8. 자주 묻는 질문과 결론

도입을 검토할 때 자주 나오는 질문부터 정리한다.

Q1. 개인 Pro·Max 요금제로도 쓸 수 있나?

아니다. 조직(회사)이 Team 또는 Enterprise 플랜일 때만 관리자가 켤 수 있다. 개인 무료·Pro·Max 요금제로는 우회 방법이 없다. 자세한 근거는 글 맨 위 첫 박스에서 확인할 수 있다.

Q2. Microsoft Teams나 다른 메신저에서도 되나?

지금은 Slack 전용이다. 다른 협업 도구는 지원하지 않으므로, Slack을 쓰지 않는 팀에는 현재로선 선택지가 아니다.

Q3. 사람 수가 늘면 1인당 요금이 붙나?

좌석 요금은 없다. 채널·스레드 작업은 회사 usage balance에서 차감되고, 개인 DM만 개인 계정 한도를 쓴다. 인원 수보다 실제 사용량이 비용을 좌우한다.

Q4. Ambient 동작을 켜도 괜찮은가?

이 글에서 확인한 공식 문서 범위에서는 행동 전 별도 승인 흐름을 핵심 통제로 확인하지 못했다. 민감한 작업이 오가는 채널에서는 신중해야 하며, 트래픽이 적고 위험이 낮은 채널부터 제한적으로 켜 보는 걸 권장한다. 너무 자주 끼어들면, 스레드 단위로 "멘션할 때만 답하라"고 지시하거나 채널 메모리에 같은 규칙을 저장해두면 된다.

Q5. ZDR(Zero Data Retention)이 필요한 회사도 쓸 수 있나?

아니다. 공식 문서 기준으로 Claude Tag는 채널 메모리와 세션 트랜스크립트를 보존하기 때문에, ZDR을 켠 회사에는 제공되지 않는다. 보안 검토에서 가장 먼저 확인해야 할 조건이다.

Q6. 기존 Claude in Slack을 쓰고 있는데 그대로 둬도 되나?

2026년 8월 3일에 Claude Tag 경험으로 전환될 예정이다. 다만 기존 사용자별 연결이 그대로 옮겨지는 것은 아니므로, Access bundle, GitHub 저장소, 서비스 계정 권한을 전환 전에 별도로 점검해야 한다.

이제 "지금 도입할지, 좀 더 기다릴지"를 정리해보자.

 

상황	판단
Team·Enterprise 고객이고 Slack에 맥락이 모여 있다	지금 도입 검토
결과물이 명확한 위임 작업(PR·쿼리 등)이 많다	지금 도입 검토
개인 Pro·Max 요금제만 쓰고 있다	현재 도입 불가·대기
외부 인력과 민감 도구가 한 채널에 섞인다	서비스 계정 범위 분리 후 도입
Microsoft Teams 중심으로 일한다	Slack 지원 전까지 대기
무인 능동 동작(Ambient)에 대한 사내 승인 절차가 없다	범위 제한 후 점진 도입
ZDR이 필수인 회사다	현재 도입 불가

도입 전 체크리스트

• 우리 회사가 Team·Enterprise 플랜인지부터 확인한다 (개인 Pro·Max로는 불가)
• Claude 조직 Owner/Primary Owner와 Slack 승인 담당자가 누구인지 확인한다
• 첫 연결 채널을 비공개 테스트 채널로 좁게 잡는다
• 지출 한도를 보수적으로 설정하고 usage page 확인 담당자를 정한다
• 민감 도구를 붙일 채널의 멤버 구성을 점검한다
• ZDR 요구사항, 감사 로그 확인 방식, 서비스 계정 범위를 보안팀과 먼저 맞춘다

 

Claude Tag는 "팀 채널 안의 공유 Claude에게 일을 맡긴다"는 한 문장으로 압축된다.

강점은 Slack에 이미 흐르는 맥락을 그대로 쓴다는 점이다. 지금의 약점은 개인 Pro·Max 요금제로는 못 쓴다는 점, 서비스 계정 권한이 채널 전체에 공유된다는 점, ZDR 미지원, 능동 응답·루틴 작업의 승인 절차를 조직이 별도로 설계해야 한다는 점, 그리고 Slack 전용이라는 범위다.

기술 체크리스트 밖의 비용 — 조직 운영

앞선 체크리스트는 전부 통제 가능한 기술적 변수다. 다만 Claude가 채널에서 먼저 답하고 루틴까지 맡기 시작하면, 사람이 언제 검토하고 언제 직접 결정할지에 대한 운영 규칙도 필요하다.

특히 PR 생성, 고객 응답, 데이터 조회처럼 결과가 실제 시스템에 남는 작업은 "Claude가 할 수 있는가"보다 "사람이 어디서 확인하고 승인하는가"를 먼저 정해두는 편이 안전하다.

오늘 바로 해볼 것

Team·Enterprise 관리자라면 claude.ai/admin-settings/claude-tag에서 비공개 채널 하나를 연결하고, 지출 한도를 보수적으로 잡은 뒤 결과물이 명확한 작업 하나(예: "레이턴시 조사하고 수정 PR 열기")로 먼저 돌려보자.

기존 Claude in Slack을 쓰고 있다면, 8월 3일 전환 전 마이그레이션 일정부터 잡아두자.

개인 Pro·Max 사용자라면, 지금은 회사 요금제가 바뀔 때를 대비해 이 글을 저장해두는 정도로 충분하다.

---

참고 자료

공식 발표·제품 페이지

• Anthropic — Introducing Claude Tag (공식 발표)
• Claude Tag product page (공식 제품 페이지)

공식 문서

• Claude Tag Overview (공식 문서)
• How Claude Tag works (공식 문서)
• Security and data handling (공식 문서)
• Control when Claude Tag responds (공식 문서)
• Set up routines (공식 문서)
• What Claude Tag remembers (공식 문서)
• Choose the model Claude Tag uses (공식 문서)
• Migrate from the earlier Claude in Slack (공식 문서)
• Restrict where Claude Tag operates (공식 문서)
• Set a spend limit (공식 문서)

공식 지원 문서

• What is Claude Tag (지원 문서)
• Get started with Claude in Slack (지원 문서)

작성일: 2026-07-01 (초보자 가독성 개선판: 2026-07-06)

대상: Claude Tag (Team·Enterprise 베타, 2026년 6월 공개)

이 글은 2026-07-06 기준 공개 정보로 작성됐다. 베타 기능이라 이후 기능·요금·제한이 바뀔 수 있으니, 도입 전 공식 문서에서 최신 내용을 확인하는 것을 권장한다.