Claude Tag 베타, Slack 채널마다 에이전트 신원을 나누는 실험

AI 요약

• 무슨 일: Anthropic이 2026년 6월 23일 Slack용 Claude Tag 베타를 공개했습니다.
  • Claude Enterprise와 Team 고객은 채널에서 @Claude를 호출해 코드, 데이터, 문서 작업을 맡길 수 있습니다.
• 숫자: Anthropic은 내부 버전의 Claude Tag가 제품팀 코드의 65%를 만들고 있다고 밝혔습니다.
• 운영 쟁점: 공유 채널 에이전트는 개인 권한이 아니라 채널별 에이전트 신원, 지출 제한, 감사 로그가 필요합니다.
  • AWS 공지는 주변 감지 모드가 기본으로 꺼져 있고, 채널별 범위와 비용 통제가 있다고 설명했습니다.
• 주의점: HN 토론은 GitHub·AWS 같은 외부 시스템에서 어떤 Claude가 행동했는지 추적하는 문제를 지적했습니다.

Anthropic이 2026년 6월 23일 Claude Tag를 공개했습니다. 겉모습은 Slack에서 @Claude를 부르는 새 베타 기능입니다. 하지만 개발팀과 보안팀이 먼저 볼 부분은 채팅창이 아닙니다. 공유 채널 안에 들어온 에이전트가 누구의 권한으로 GitHub, 데이터 창고, 문서 도구, 사내 API를 호출하는지입니다.

Claude Tag는 Claude Enterprise와 Team 고객에게 먼저 제공됩니다. Anthropic은 Slack 채널에 Claude를 초대하고, 선택한 채널과 도구, 데이터, 코드베이스에 접근 권한을 주면 누구나 채널에서 @Claude를 태그해 일을 맡길 수 있다고 설명했습니다. 작업이 끝나면 Claude는 Slack 스레드에 결과를 남깁니다. 개인 대화창에 갇힌 챗봇이 아니라, 팀이 보는 공개 작업 공간에서 움직이는 에이전트로 설계됐다는 점이 발표의 출발점입니다.

발표문에서 가장 눈에 띄는 숫자는 65%입니다. Anthropic은 내부 버전의 Claude Tag가 제품팀 코드의 65%를 만들고 있다고 밝혔습니다. 이 문장은 곧바로 과장처럼 읽힐 수 있습니다. 그래서 더 중요하게 봐야 할 부분은 "코드 생성률" 자체보다 어떤 환경에서 그런 숫자가 가능했는지입니다. Slack 채널의 요구사항, 연결된 코드베이스, 장시간 비동기 작업, 팀원이 함께 보는 진행 상황이 한 제품으로 묶였을 때의 운영 방식입니다.

Claude Tag는 기존 Claude in Slack 앱을 대체합니다. Anthropic은 관리자가 30일 안에 새 기능으로 옵트인할 수 있고, 대상 Enterprise·Team 조직에 출시 크레딧을 제공한다고 적었습니다. 또한 Claude Tag가 Opus 4.8에서 동작한다고 밝혔습니다. 단순한 Slack 응답 봇을 새 이름으로 포장한 것이라면 모델 이름, 코드베이스 접근, 지출 제한, 마이그레이션 일정이 동시에 나올 이유가 약합니다.

이 설명이 기술적 본문입니다. Anthropic은 2026년 6월 24일 agent identity 설명을 별도로 냈습니다. 개인 챗봇에서는 사용자가 자기 Google Drive, GitHub, 캘린더를 연결하고 모델이 그 사람의 권한으로 행동합니다. 공유 Slack 채널에서는 이 방식이 바로 깨집니다. 세 명의 엔지니어와 PM 한 명이 같은 스레드에서 버그를 논의할 때, Claude가 어느 사람의 저장소 권한과 문서 권한을 써야 하는지 답이 하나로 정해지지 않습니다.

Anthropic의 답은 에이전트 신원입니다. Claude Tag가 활성화된 채널에서 Claude는 한 사용자를 대신하지 않습니다. Slack에서는 Claude 앱으로 말하고, GitHub에서는 Claude GitHub App으로 PR을 열고, 데이터 창고에서는 관리자가 만든 서비스 계정으로 질의합니다. 개인 자격 증명이 채널 안에 섞이지 않으므로, 공유 채널이 누군가의 사적인 문서로 들어가는 뒷문이 되어서는 안 된다는 설명입니다.

권한 상속 방식도 발표됐습니다. 관리자는 작업공간 수준에서 Claude가 가진 기본 연결과 기술을 정의하고, 채널별로 이를 덮어쓸 수 있습니다. 예를 들어 엔지니어링 채널은 GitHub와 데이터 창고에 접근하게 하고, CRM 연결은 영업 비공개 채널에만 둘 수 있습니다. Claude 블로그는 공개 채널이 작업공간 수준 신원을 공유하고, 비공개 채널은 서로 다른 신원을 만든다고 설명했습니다. 비공개 법무 채널에서 배운 기억과 접근 권한이 엔지니어링 채널에 흘러가면 안 된다는 설계입니다.

이 차이는 에이전트 제품이 기업에 들어갈 때 자주 빠지는 부분입니다. 사람이 쓰는 도구는 "이 사용자는 무엇을 할 수 있는가"로 권한을 정합니다. Claude Tag는 "이 채널의 에이전트는 무엇을 할 수 있는가"로 질문을 바꿉니다. 채널 구성원이 직접 저장소 접근권을 갖고 있지 않아도, 채널 프로필이 Claude에게 해당 저장소 접근권을 주면 Claude에게 읽기나 쓰기 작업을 시킬 수 있습니다. 그래서 편리함과 위험이 같은 지점에서 생깁니다.

AWS도 같은 날 Marketplace 공지를 냈습니다. AWS 공지는 Claude Enterprise on AWS Marketplace 고객도 Claude Tag 베타를 사용할 수 있고, 경험은 1차 Claude Enterprise와 같다고 설명했습니다. AWS가 덧붙인 운영 정보가 중요합니다. Claude Tag는 자체 신원으로 동작하고, 채널별 범위가 있으며, 지출 통제를 제공하고, 주변 감지 모드는 기본으로 꺼져 있습니다. 소비 기반 가격은 인원수가 아니라 사용량을 추적하고, 조직 전체 예산 가시성과 채널별 제한을 둔다고 적었습니다.

주변 감지 모드(ambient mode)는 특히 조심스러운 기능입니다. Anthropic 발표문은 이 모드가 켜져 있으면 Claude가 연결된 채널과 도구에서 필요한 정보를 찾아 알려주고, 멈춘 스레드나 과제를 따라갈 수 있다고 설명했습니다. 팀 입장에서는 좋은 비서처럼 보입니다. 보안팀 입장에서는 "누가 시키지 않아도 말하는 에이전트"입니다. AWS 공지가 이 기능을 기본으로 끈다고 밝힌 이유가 여기에 있습니다.

Claude 블로그는 감사와 네트워크 통제도 설명했습니다. 관리자가 채널 프로필에 연결을 추가하면 자격 증명은 독립적으로 저장되고, 요청 시 네트워크 경계에서 주입됩니다. 관리자가 허용하지 않은 호스트로 나가는 트래픽은 차단됩니다. 에이전트 자격 증명으로 실행된 routine, 기억 쓰기, 네트워크 호출은 감사 로그에 기록되고, 연결된 시스템의 로그에도 Claude 자체 서비스 계정 활동으로 남는다는 설명입니다.

이 모델은 보안팀에게 반가운 단어를 많이 제공합니다. 서비스 계정, 채널별 범위, 역할 기반 접근 제어, 감사 로그, 네트워크 차단, 지출 제한입니다. 동시에 운영 난이도도 높입니다. 관리자가 기본 프로필을 넓게 잡으면 Claude가 유용해집니다. 너무 넓으면 채널 구성원보다 많은 권한을 가진 에이전트가 됩니다. 좁게 잡으면 매번 연결을 요청해야 하고, 팀은 다시 개인 챗봇이나 임시 스크립트로 돌아갑니다.

HN 토론이 이 지점을 바로 찔렀습니다. 한 댓글 흐름은 "사고 때 어떤 Claude Tag가 AWS를 호출했는지 어떻게 아느냐"는 식으로 신원과 귀속 문제를 물었습니다. 또 다른 댓글은 GitHub에서는 결국 Claude GitHub App 하나가 보일 수 있으니, 채널 Y의 Claude인지 채널 X의 Claude인지 외부 감사 로그에서 구분하기 어렵지 않겠느냐고 지적했습니다. Anthropic이 채널별 신원을 말해도, 연결된 외부 시스템의 권한 모델이 같은 수준의 세분화를 제공하지 않으면 빈틈이 생깁니다.

공유 채널의 개인정보 문제도 토론에 나왔습니다. 일정 조율 에이전트가 개인 캘린더 사유를 공개 스레드에 말해버릴 수 있다는 예시는 단순한 농담이 아닙니다. 기업 Slack에는 영업 기회, 고객 장애, 인사 평가, 보안 사고, 채용 면접, 법무 검토가 같은 조직 안에 섞여 있습니다. Claude Tag가 채널마다 기억과 접근을 나눈다고 해도, 어느 채널에 어떤 도구를 붙일지 정하는 일은 결국 관리자의 설계와 훈련 문제입니다.

비용도 새롭게 보입니다. 개인 챗봇은 사용자당 요금으로 이해하기 쉽습니다. 공유 에이전트는 채널 하나에서 여러 사람이 동시에 일을 맡기고, Claude가 몇 시간이나 며칠 동안 비동기 작업을 이어갈 수 있습니다. AWS 공지가 소비 기반 가격, 조직 전체 예산 가시성, 채널별 제한을 언급한 이유가 이 구조 때문입니다. 한 채널의 "편한 자동화"가 한 달 뒤 예산 초과로 돌아오면 제품 가치는 바로 회계 문제로 바뀝니다.

개발팀에는 두 가지 실무 질문이 남습니다. 첫째, Claude Tag가 만든 코드나 PR을 어떤 검토 단위로 다룰 것인가입니다. Anthropic은 내부 제품팀 코드의 65%를 말했지만, 이 숫자는 리뷰, 테스트, 배포, 롤백, 보안 스캔과 함께 봐야 합니다. 코드가 많이 생성된다는 사실은 병목이 작성에서 검토와 책임 소재로 옮겨갔다는 뜻일 수 있습니다.

둘째, 채널을 권한 단위로 써도 되는가입니다. Slack 채널은 보통 협업 단위이지 보안 경계로 설계되지 않았습니다. 프로젝트가 바뀌면 사람이 들어오고 나가고, 임시 채널이 만들어지고, 공개 채널에서 비공개 논의가 이어집니다. Claude Tag의 에이전트 신원이 채널을 기준으로 움직인다면, 채널 관리가 곧 권한 관리가 됩니다. 사내 Slack 운영 규칙이 느슨한 회사라면 먼저 채널 생애주기부터 정리해야 합니다.

경쟁 구도도 흥미롭습니다. Slack 자체도 AI 기능과 MCP 지원을 넓히고 있고, Glean은 기업 검색과 지식 접근을 오래 다뤘습니다. Cursor, Devin, GitHub Copilot 계열은 코드 작업을 에이전트화하고 있습니다. Claude Tag의 차별점은 모델 품질만이 아니라 "팀 대화가 일의 입력이 되고, 에이전트가 그 채널의 장기 맥락을 기억한다"는 위치입니다. 경쟁사는 더 좋은 모델보다 더 좋은 권한·감사·비용 UX로 대응해야 합니다.

하지만 Claude Tag가 모든 팀에 맞지는 않습니다. 발표 기준으로 시작점은 Slack입니다. Microsoft Teams 중심 조직, 엄격한 망 분리 환경, 자체 Git 서버와 복잡한 권한 체계를 가진 조직은 도입 경로가 바로 열리지 않을 수 있습니다. HN 댓글에서도 Teams를 쓰는 회사라면 좋은 기능이어도 당장 쓰기 어렵다는 반응이 있었습니다. Anthropic은 향후 더 많은 장소로 확장하겠다고 했지만, 구체적인 지원 일정은 발표하지 않았습니다.

도입을 검토하는 팀이라면 첫 실험을 개발 채널 하나로 제한하는 편이 낫습니다. 저장소는 낮은 위험의 내부 도구부터 붙이고, 데이터 창고는 읽기 전용 계정으로 시작해야 합니다. 주변 감지 모드는 꺼둔 채 @Claude 호출 작업만 관찰하고, 채널별 지출 제한을 낮게 잡아야 합니다. 첫 달의 성공 기준은 "Claude가 일을 많이 했다"가 아니라, Claude가 한 일과 쓴 비용과 접근한 시스템을 사람이 재구성할 수 있는지입니다.

기사로서 이 발표의 결론은 단순합니다. Claude Tag는 Slack 안에 Claude를 넣은 기능이지만, 실제 제품은 팀 단위 에이전트의 신원 모델입니다. Anthropic이 65% 코드 생성이라는 공격적인 숫자를 들고 나온 만큼, 기업 고객은 같은 숫자를 자신의 조직에서 재현하기 전에 권한, 비용, 로그, 채널 관리부터 검증해야 합니다. 에이전트가 팀원이 되려면 먼저 조직도와 감사표에 들어갈 이름이 필요합니다.