Claude Tag 발표를 보면서 제일 먼저 든 생각은 이거였다. 이제 AI 에이전트는 개인 채팅창 안에 갇힌 도구가 아니라, 팀 채널에 상주하는 작업자처럼 팔리기 시작했다.
Anthropic의 발표에 따르면 Claude Tag는 Slack에서 시작한다. 관리자가 특정 채널, 도구, 데이터, 코드베이스 접근을 열어주면 팀원 누구나 @Claude를 태그해서 일을 맡길 수 있다. 답은 DM이 아니라 스레드로 돌아온다. Anthropic은 내부 버전 기준으로 제품팀 코드의 65%가 Claude Tag를 통해 만들어지고 있다고도 적었다. 숫자 자체도 크지만, 나는 그보다 “팀이 AI를 부르는 위치”가 바뀐 게 더 크게 보였다.
Claude Tag는 개인 비서보다 팀원에 가깝다
채팅창 하나가 아니라 공유된 작업 공간이다
기존 AI 사용은 대부분 개인 중심이었다. 내가 Claude나 ChatGPT를 열고, 맥락을 붙여 넣고, 답을 받고, 다시 팀 도구로 옮긴다. 결과물이 좋더라도 작업의 흔적은 내 브라우저 탭 안에 남는다. 누가 어떤 요청을 했고, 왜 이런 결정이 나왔고, 다음 사람이 어디서 이어받아야 하는지는 따로 정리해야 했다.
Claude Tag는 이 위치를 Slack 채널로 옮긴다. 문서 표현대로라면 채널 안의 누구나 Claude를 불러 문제를 넘기고, Claude는 체크리스트를 스레드에 올린 뒤 작업을 진행한다. 버그 재현, PR 생성, 결정 스레드 문서화, 프로젝트 상태 정리 같은 일을 예시로 든다. 중요한 건 결과가 팀이 보는 곳에 남는다는 점이다. 개인 챗봇의 답변이 아니라 팀 작업 로그의 일부가 된다.
이건 꽤 현실적인 차이다. 실무에서 AI 답변이 애매해지는 순간은 모델이 멍청해서만이 아니다. 누가 무슨 배경으로 시켰는지, 이전에 어떤 합의를 했는지, 이 팀이 평소 어떤 기준으로 리뷰하는지 모르는 상태에서 답을 내기 때문이다. Claude Tag는 그 빈칸을 채널 맥락과 기억으로 메우려는 제품이다.
비동기 위임이 기본값이 된다
발표에서 제일 눈에 들어온 표현은 “asynchronously”였다. Claude에게 일을 맡기고 사용자는 다른 일을 하면 된다. 더 나아가 Claude가 자기 작업을 스케줄링하고, 몇 시간이나 며칠 동안 프로젝트를 밀고 갈 수 있다고 설명한다. 이건 그냥 Slack 봇 응답 속도가 빨라졌다는 얘기가 아니다.
이 흐름은 이전에 다뤘던 Claude Code Routines와 연결된다. 그때는 클라우드에서 반복 작업을 돌리는 쪽이 핵심이었다. Claude Tag는 거기에 팀 채널이라는 입구를 붙인다. 누군가는 스레드에서 “이 이슈 재현해서 PR 초안 열어줘”라고 말하고, Claude는 도구를 쓰고, 결과를 다시 스레드에 남긴다. 팀원은 그 스레드에서 바로 확인하고 후속 지시를 붙인다.
나는 이게 꽤 강한 UX라고 본다. 개발자는 이미 Slack에서 장애, 요구사항, 제품 질문, 고객 피드백을 본다. 그 자리에서 바로 에이전트에게 넘길 수 있으면 컨텍스트 전환이 줄어든다. 반대로 말하면 Slack이 더 무거운 작업 OS가 된다. 이건 좋기도 하고, 좀 무섭기도 하다.
진짜 제품은 권한 모델이다
채널별 신원과 기억을 나누는 구조
Claude Tag에서 제일 중요한 건 “Slack에서 Claude를 부른다”가 아니라 “관리자가 Claude의 접근 범위를 채널별로 정한다”는 점이다. Anthropic은 이를 별도 agent identity access model로 설명한다. 영업용 Claude와 엔지니어링용 Claude는 같은 이름을 달고 있어도 다른 신원처럼 다뤄진다. 기억, 도구, 데이터 접근 범위를 섞지 않는다는 얘기다.
이건 멋진 문구라기보다 최소 안전장치에 가깝다. AI 에이전트가 팀 전체 채널을 따라다니기 시작하면, 개인 챗봇보다 실패 반경이 훨씬 넓어진다. 엔지니어링 채널의 배포 토큰, 고객지원 채널의 사용자 정보, 영업 채널의 계약 맥락이 한 모델 안에서 섞이면 사고가 난다. 모델이 똑똑한지보다 먼저, 어디까지 볼 수 있고 어디까지 실행할 수 있는지가 정해져야 한다.
Claude Help Center의 Slack 안내도 기존 Slack 앱이 Claude Tag 경험으로 전환될 예정이라고 적고 있다. 즉 이건 실험용 데모가 아니라 기존 조직용 Slack 사용 흐름을 대체하려는 방향에 가깝다. 그래서 더더욱 권한 모델이 본체다.
감사 로그와 토큰 예산은 부가 기능이 아니다
Anthropic은 관리자가 조직 전체와 채널별 토큰 지출 한도를 설정하고, Claude가 무엇을 했는지 로그로 볼 수 있다고 설명한다. 이 부분이 마음에 들었다. AI 도구는 보통 “얼마나 똑똑한가”로 팔리지만, 조직에서 오래 살아남는 기준은 “누가 얼마를 썼고 무엇을 바꿨는가”다.
Hacker News의 Claude Tag 토론에서도 바로 토큰 비용 얘기가 나왔다. 채널 메시지를 계속 읽고, 기억을 압축하고, 여러 작업을 병렬로 돌리면 비용이 어떻게 되느냐는 질문이다. 당연한 반응이다. 개인이 하루에 몇 번 쓰는 챗봇과, 조직 채널에 상주하면서 여러 사람이 동시에 호출하는 에이전트는 비용 곡선이 다르다.
내 기준에서는 여기서 제품의 성패가 갈린다. 좋은 데모는 한 번의 멋진 작업을 보여주면 된다. 좋은 운영 도구는 실패한 작업, 중복 작업, 장기 실행 작업, 누가 봐도 이상한 비용 증가까지 추적할 수 있어야 한다. Claude Tag가 팀 작업자가 되려면 모델 성능보다 이 장부가 더 중요해진다.
기대보다 먼저 봐야 할 리스크
팀 채널의 맥락은 자산이면서 부담이다
Claude Tag는 채널을 따라가며 관련 정보를 기억할 수 있다고 설명한다. 이건 분명히 편하다. 매번 “우리 서비스는 이런 구조고, 지난주에 이렇게 결정했고, 이 리포는 여기 있어”라고 다시 말하지 않아도 된다. 에이전트가 팀의 암묵지를 조금씩 흡수한다면 작업 품질은 올라간다.
근데 바로 그 지점이 부담이다. Slack 채널에는 정리된 스펙만 있는 게 아니다. 농담, 임시 판단, 아직 확정되지 않은 의견, 고객 이름, 내부 갈등, 실수한 로그, 반쯤 맞는 추측이 다 섞인다. AI가 이걸 “팀 맥락”으로 가져가면 편해지지만, 동시에 무엇을 기억했고 무엇을 잊었는지 확인하기 어려워진다.
이전에 AI 코딩 에이전트 보안 글에서 에이전트에는 하네스가 먼저 필요하다고 썼다. Claude Tag도 똑같다. 좋은 모델을 팀 채널에 붙이는 순간, 채널 자체가 입력 파이프라인이 된다. 입력 파이프라인이 되면 필터, 권한, 보존 기간, 감사 로그가 필요하다. 그냥 “우리 팀 AI 비서 생겼다”로 보면 안 된다.
능동 알림은 생산성과 감시 사이에 걸친다
발표에는 ambient behavior라는 표현도 나온다. 켜두면 Claude가 관련 정보를 먼저 알려주고, 멈춘 스레드나 해결되지 않은 작업을 따라갈 수 있다고 한다. 나는 이 기능이 제일 양날의 검처럼 보였다.
잘 쓰면 엄청 좋다. 장애 채널에서 놓친 로그를 다시 끌어올리고, 제품 결정 스레드가 흐지부지될 때 문서화를 제안하고, 고객지원 이슈가 멈춰 있을 때 담당자를 찾아준다. 팀 운영자 입장에서는 꿈같은 기능이다. 실제로 이런 후속 관리가 안 돼서 프로젝트가 새는 경우가 많다.
하지만 팀원 입장에서는 다르게 느껴질 수 있다. AI가 채널을 계속 보고 있고, 조용해진 스레드를 다시 건드리고, 누가 무엇을 요청했는지 로그로 남긴다면 생산성 도구와 감시 도구의 경계가 흐려진다. 그래서 도입할 때는 “무엇을 도와줄 것인가”만 정하면 부족하다. “무엇은 보지 않을 것인가”, “어떤 상황에서는 먼저 말하지 않을 것인가”까지 정해야 한다.
지금 팀이 확인할 기준
도입보다 작업 분리가 먼저다
Claude Tag 같은 도구를 보면 바로 붙여보고 싶어진다. 나도 그렇다. 그런데 실제 팀에 넣는다면 먼저 할 일은 도입 신청이 아니라 작업 분리라고 본다. 어떤 작업을 채널 AI에게 맡길 수 있고, 어떤 작업은 개인 세션이나 별도 승인 흐름이 필요한지 나눠야 한다.
대충 이런 질문부터 봐야 한다.
| 확인할 것 | 왜 중요한가 |
|---|---|
| 채널별로 어떤 데이터가 보이는가 | 기억과 접근권이 섞이면 사고 반경이 커진다 |
| Claude가 어떤 도구를 실행할 수 있는가 | 읽기 도구와 쓰기 도구는 위험도가 다르다 |
| 결과를 누가 승인하는가 | PR, 고객 응답, 배포 작업은 자동 완료로 두기 어렵다 |
| 토큰 예산을 어디서 끊는가 | 상주형 에이전트는 비용이 조용히 늘 수 있다 |
나는 특히 쓰기 권한을 늦게 열어야 한다고 본다. 처음부터 코드베이스 수정, 티켓 상태 변경, 고객 메시지 발송까지 주면 빠르게 편해지지만, 실패했을 때 설명하기 어렵다. 처음에는 읽기, 요약, 체크리스트, 초안 생성 정도로 시작하고, 그 다음에 PR 초안이나 내부 문서 생성으로 넓히는 게 낫다.
운영자는 루프를 설계해야 한다
Armin Ronacher의 The Coming Loop도 같은 흐름을 다르게 표현한다. 이제 중요한 건 모델에게 한 번 프롬프트를 던지는 게 아니라, 모델 바깥의 루프를 설계하는 일이다. 작업을 큐에 넣고, 에이전트가 시도하고, 하네스가 끝났는지 판단하고, 아니면 다시 이어붙인다. Claude Tag는 이 루프의 입구를 Slack으로 가져오는 제품처럼 보인다.
그래서 운영자는 “Claude가 답을 잘하나?”보다 “작업이 언제 끝났다고 볼 것인가?”를 먼저 물어야 한다. PR이 열리면 끝인가. 테스트가 통과해야 끝인가. 리뷰어가 확인해야 끝인가. 고객지원 티켓은 답변 초안이면 끝인가, 실제 발송까지 끝인가. 이 기준이 없으면 에이전트는 열심히 움직이지만 팀은 계속 확인하느라 바빠진다.
개인적으로 Claude Tag의 방향은 맞다고 본다. 팀의 실제 작업은 이미 채널에서 시작되고, AI 에이전트는 점점 비동기로 움직이고 있다. 다만 이걸 잘 쓰는 팀과 못 쓰는 팀의 차이는 모델 선택보다 운영 설계에서 날 것 같다. 권한을 작게 열고, 로그를 남기고, 비용을 끊고, 완료 기준을 정한 팀은 꽤 큰 생산성 이득을 볼 수 있다. 반대로 “AI 팀원 들어왔다”는 기분만으로 붙이면, Slack은 더 시끄럽고 비싼 작업장이 될 가능성이 높다.
마치며
Claude Tag는 단순한 Slack 봇 업데이트가 아니다. 팀 채널, 장기 기억, 도구 접근, 비동기 작업, 감사 로그, 토큰 예산을 한 묶음으로 팔기 시작했다는 신호에 가깝다. 나는 이 방향이 앞으로 더 커질 거라고 본다. 개인 챗봇은 이미 충분히 익숙해졌고, 이제 시장은 “팀 전체가 AI와 같이 일하는 방식”을 제품화하려고 한다.
다만 지금 당장 봐야 할 건 멋진 데모가 아니다. 우리 팀의 채널 구조가 AI 입력으로 들어가도 되는지, 어떤 도구 권한을 줄 수 있는지, 실패한 작업을 어떻게 멈출지, 비용이 튀면 어디서 끊을지다. Claude Tag가 진짜 팀원이 되려면, 팀도 AI에게 일을 맡기는 운영 규칙을 먼저 가져야 한다.