Claude Tag, 슬랙 속 상주형 에이전트의 신호

팀 채널에 들어온 Claude

Anthropic은 2026년 6월 23일 Claude Tag를 공개했다. 시작점은 Slack이다. 관리자가 선택한 채널, 도구, 데이터, 코드베이스에 접근 권한을 부여하면 팀원은 채널에서 @Claude를 호출해 일을 맡길 수 있다. Anthropic은 내부 버전의 Claude Tag가 제품팀 코드의 65%를 만든다고 밝혔다.

이 발표가 중요한 이유는 AI 업무의 중심이 개인 채팅창에서 팀 공간으로 이동한다는 데 있다. 지금까지 많은 기업용 AI는 사용자가 복사해 넣은 문서와 질문에 답하는 보조 도구였다. Claude Tag는 채널 흐름을 따라가며 맥락을 쌓고, 비동기 작업을 계획하고, 필요하면 며칠에 걸쳐 일을 이어간다.

멀티플레이어 에이전트의 장점과 비용

Anthropic은 Claude Tag가 하나의 채널 안에서 여러 사람과 함께 일하는 멀티플레이어 모델이라고 설명한다. 이는 Claude Code 사고 로그, 감사 추적의 착시에서 다룬 개인 세션 중심 감사와 다른 문제를 만든다. 이제 질문은 한 사용자가 무엇을 요청했는가가 아니라 어느 채널의 어떤 맥락이 작업 권한이 되었는가다.

권한은 채널 단위로 나뉜다. 영업용 Claude와 엔지니어링용 Claude의 메모리는 섞이지 않아야 하고, 민감 데이터도 도구 연결에 따라 달라져야 한다. Anthropic은 관리자 로그와 토큰 지출 한도를 제공한다고 설명하지만, 실제 운영에서는 Slack 보존 정책, 퇴사자 권한, 외부 협력사 채널, 코드 저장소 권한까지 함께 점검해야 한다.

Slack AI 경쟁이 아니라 업무 OS 경쟁

이 제품은 Slack 플러그인 경쟁으로만 보면 작게 보인다. 하지만 OpenAI의 Codex 장기 작업 가이드가 말하는 지속 워크스페이스와 같은 방향을 가리킨다. 에이전트는 한 번의 프롬프트보다 긴 업무를 맡고, 사람은 일을 나누고 검증하는 역할로 이동한다.

BitBoard, 에이전트 분석을 대시보드로 고정하다에서 봤듯이 다음 경쟁력은 모델 성능만이 아니라 업무 상태를 어디에 남기느냐다. Slack 스레드에만 결과가 흩어지면 장기 지식은 오히려 더 지저분해질 수 있다. 반대로 채널 맥락, 티켓, PR, 문서, 로그가 함께 묶이면 팀의 운영 지식이 축적된다.

개발팀에는 좋은 소식이자 경고

Claude Tag는 Claude Code의 진화로 소개됐다. 개발자는 버그 재현, 지표 조회, PR 준비, 릴리스 노트 작성 같은 일을 채널에서 바로 위임할 수 있다. 그러나 AI는 코드다, 프롬프트만으론 안전해지지 않는다에서 다룬 것처럼 에이전트가 읽는 메시지와 도구 출력은 모두 외부 입력이다.

특히 Slack은 농담, 임시 결정, 고객 정보, 장애 대응 기록이 뒤섞이는 공간이다. 에이전트가 이런 맥락을 오래 기억할수록 생산성은 올라가지만 잘못된 암묵지를 학습할 위험도 커진다. 한국 기업은 개인정보보호법과 내부 보안 규정 때문에 채널별 데이터 보존 기간, 삭제 요청, 감사 로그 반출 정책을 제품 도입 전에 정해야 한다.

결론: 에이전트는 사람처럼 보일수록 관리 대상이 된다

Claude Tag의 메시지는 분명하다. 기업용 AI는 더 이상 별도 앱에서 답을 주는 도구가 아니라 업무 대화 안에 상주하는 동료처럼 설계된다. 다만 동료처럼 보인다고 해서 동료처럼 신뢰하면 안 된다. 실제로 필요한 것은 역할 정의, 권한 경계, 비용 회계, 감사 로그다.

한국의 스타트업과 대기업 모두 Slack, Teams, Jira, GitHub, Notion 위에 이미 업무 기록을 쌓고 있다. Claude Tag는 이 기록층을 에이전트 실행층으로 바꾼다. 준비된 조직에는 레버리지가 되고, 준비되지 않은 조직에는 보안과 비용의 새 그림자가 된다.

자주 묻는 질문

Q1: Claude Tag는 기존 Claude Slack 앱과 무엇이 다른가요?

A: 단순 질의응답 앱보다 팀 채널의 맥락, 도구 접근, 비동기 실행, 기억 범위를 더 적극적으로 활용하는 상주형 에이전트에 가깝다.

Q2: 한국 기업이 가장 먼저 확인할 것은 무엇인가요?

A: 채널별 데이터 등급, 도구 권한, 로그 보존, 토큰 예산 한도, 외부 협력사 접근 범위를 먼저 점검해야 한다.

Q3: 개발팀에는 어떤 활용이 현실적인가요?

A: 버그 조사, PR 초안, 코드베이스 질의, 릴리스 준비, 지표 조회처럼 채널 협업과 코드 작업이 만나는 지점이 적합하다.

Q4: 가장 큰 위험은 무엇인가요?

A: 에이전트가 과도한 도구 권한과 오래된 채널 맥락을 함께 갖는 경우다. 최소 권한과 정기 권한 검토가 필요하다.

Q5: Microsoft Teams에도 같은 흐름이 올까요?

A: 가능성이 높다. Slack이 출발점일 뿐, 팀 협업 도구 안에 에이전트가 상주하는 방식은 주요 업무 플랫폼 전반으로 확산될 수 있다.