슬랙 안으로 들어온 지속형 에이전트, Claude Tag을 플랫폼 관점에서 읽습니다
개요
Anthropic이 2026년 6월 23일 Claude Tag을 공개했습니다. 슬랙 채널 안에서 @Claude를 호출해 일을 맡기면, 그 에이전트가 요청을 단계로 쪼개고 연결된 도구를 거치면서 작업한 뒤 같은 스레드에 결과를 보고하는 방식입니다. 현재는 Claude Enterprise와 Claude Team 고객을 대상으로 슬랙에서 베타로 제공되며, 더 넓은 출시가 예고되어 있습니다.
겉보기에는 또 하나의 슬랙 봇처럼 보일 수 있습니다. 그러나 발표 내용을 뜯어보면 설계 철학이 기존 챗봇과 다릅니다. 한 번 호출하고 끝나는 일회성 대화가 아니라, 채널에 상주하면서 여러 사람과 맥락을 공유하고, 비동기로 일하며, 설정에 따라 스스로 후속 조치를 챙기는 지속형 에이전트입니다. 회사는 이 도구의 내부 버전을 한 해 동안 써왔고, 제품팀 코드의 65%가 이 내부 버전으로 작성되었으며 그중에는 Claude Tag 자체를 만든 코드 대부분이 포함된다고 밝혔습니다.
ThakiCloud는 쿠버네티스 기반 AI/ML SaaS 플랫폼을 운영하면서 내부적으로 허브앤스포크 구조의 에이전트 팀을 돌리고, 작업 결과를 슬랙 보고 채널로 흘려보냅니다. 그래서 “에이전트가 협업 도구 안으로 들어와 상주한다”는 흐름은 우리에게 남의 이야기가 아니라 직접 운영하는 패턴입니다. 이 글은 Claude Tag이 실제로 무엇이 새로운지, 65%라는 숫자를 어떻게 읽어야 하는지, 그리고 이 패턴이 멀티테넌트 온프레미스 플랫폼에 무엇을 시사하는지를 정리합니다.
Claude Tag은 무엇인가
가장 단순하게 말하면 Claude Tag은 슬랙 안에 들어온 작업 수행형 에이전트입니다. 사용자가 평범한 자연어로 @Claude에게 요청을 적으면, 에이전트가 작업을 단계로 나누고, 연결된 도구와 데이터를 활용해 한 단계씩 처리한 뒤, 스레드 안에서 결과를 돌려줍니다. 코드 자동완성처럼 옆에서 거드는 도구가 아니라, 하나의 과업 전체를 맡아 끝까지 끌고 가는 방식입니다.
작동 무대를 슬랙으로 잡은 선택이 중요합니다. 슬랙은 이미 많은 조직의 업무 맥락이 모이는 곳입니다. 엔지니어링 논의, 제품 지표 질문, 지원 티켓, 디버깅 대화가 채널 단위로 쌓여 있습니다. Anthropic은 자사 팀이 내부 버전을 바로 이런 용도, 즉 엔지니어링과 제품 지표와 지원 티켓과 디버깅에 매일 써왔다고 설명합니다. 에이전트를 별도 도구로 띄우는 대신, 이미 맥락이 흐르는 곳에 상주시킨 것입니다.
무엇이 새로운가: 지속성, 멀티플레이어, 능동성
발표에서 반복적으로 강조되는 세 가지 성질이 이 도구의 핵심입니다.
첫째는 지속성입니다. 에이전트는 채널에 계속 머무릅니다. 한 번 답하고 사라지는 것이 아니라, 비동기로 일합니다. 사용자는 일을 맡겨두고 자리를 비웠다가 나중에 돌아와 결과를 확인할 수 있습니다. 긴 작업을 사람의 실시간 대기 없이 진행할 수 있다는 뜻입니다.
둘째는 멀티플레이어입니다. 하나의 Claude가 채널 안의 모든 사람과 상호작용합니다. 팀원들은 에이전트가 무엇을 하고 있는지 함께 보고, 누군가 시작한 대화를 다른 사람이 이어받을 수 있습니다. 기존 챗봇이 한 사람과 일대일로 비공개 대화하던 것과 달리, 작업 맥락이 팀 전체에 공유됩니다. 이 차이는 협업의 단위를 바꿉니다.
셋째는 능동성입니다. 이른바 앰비언트(ambient) 동작을 켜면, 에이전트가 관련 정보를 먼저 짚어주고, 해결되지 않은 스레드를 따라가 후속 조치를 챙기며, 사용자에게 갱신된 내용을 알려줍니다. 사람이 매번 호출해야만 움직이는 수동적 도구에서, 맥락을 보고 스스로 끼어드는 능동적 동료로 한 걸음 옮겨간 것입니다.
[ 기존 챗봇 ] [ Claude Tag ]
사용자 1명 ── 1:1 비공개 대화 채널(여러 사람) ── 공유 맥락
│ 호출하면 답, 끝나면 휘발 │ 상주, 비동기로 작업 지속
└─ 수동: 부를 때만 동작 ├─ 멀티플레이어: 누구나 이어받기
└─ 능동: 미해결 스레드 후속 조치
물론 이 세 가지 성질은 강력한 만큼 운영상의 부담도 함께 가져옵니다. 상주하는 에이전트는 권한과 데이터 접근 범위를 분명히 해야 하고, 능동 동작은 잘못 켜지면 채널을 잡음으로 채울 수 있습니다. 새로움의 가치와 통제의 비용은 항상 함께 옵니다.
65%라는 숫자를 어떻게 읽을 것인가
가장 눈에 띄는 주장은 제품팀 코드의 65%가 내부 버전으로 작성되었다는 수치입니다. 이 숫자는 인상적이지만, 사실관계와 해석을 분리해서 읽어야 합니다.
먼저 사실은 이렇습니다. 이것은 회사가 자사 제품팀에 대해 밝힌 자기 보고 수치이고, 측정 기준(무엇을 “작성”으로 세는지, 사람이 검토하고 수정한 부분을 어떻게 처리하는지)은 공개되어 있지 않습니다. 그래서 이 65%를 산업 전반에 일반화하거나, 다른 조직에서 동일하게 재현된다고 단정할 수는 없습니다[추정: 회사 발표 기준].
그럼에도 이 숫자가 시사하는 방향은 분명합니다. 프런티어 모델 개발사 내부에서 에이전트가 코드 생산의 다수를 담당하는 단계에 이미 들어섰다는 것입니다. 여기서 중요한 것은 비율 자체보다, 그 비율이 가능하려면 무엇이 갖춰져야 하는가입니다. 에이전트가 코드의 대부분을 쓰려면 결과를 검증하는 게이트, 사람이 방향을 잡는 개입 지점, 그리고 잘못된 변경을 되돌릴 수 있는 안전장치가 함께 있어야 합니다. 65%는 모델 능력만의 결과가 아니라 그 주변의 운영 설계가 받쳐준 결과입니다. 이 점이 사실은 가장 중요한 대목입니다.
ThakiCloud K8s AI/ML SaaS 플랫폼 적용 및 시사점
Claude Tag은 클라우드 SaaS이자 엔터프라이즈 슬랙에 묶여 있습니다. 바로 여기서 멀티테넌트 온프레미스 플랫폼의 각도가 생깁니다. 많은 조직, 특히 보안 요건이 강한 공공·금융·국방 영역의 고객은 업무 맥락과 코드와 데이터를 외부 SaaS로 보내기 어렵습니다. 이들에게 필요한 것은 같은 패턴을, 그러나 자체 인프라 안에서 돌리는 능력입니다.
ThakiCloud는 쿠버네티스 위에서 Kueue로 GPU 작업을 큐잉하고, 테넌트별로 모델 서빙을 격리하는 구조를 운영합니다. 이 토대 위에서 지속형 에이전트를 설계할 때 핵심 과제는 세 가지입니다. 첫째는 격리입니다. 채널에 상주하며 도구와 데이터에 접근하는 에이전트는 테넌트 경계를 절대 넘지 않아야 합니다. 멀티테넌트 환경에서 한 고객의 에이전트가 다른 고객의 맥락을 보는 일은 곧바로 보안 사고입니다. 둘째는 권한입니다. 능동적으로 움직이는 에이전트일수록 무엇을 읽고 무엇을 쓸 수 있는지를 코드로 강제해야 합니다. 셋째는 비용입니다. 상주하며 능동적으로 후속 조치를 챙기는 에이전트는 가만히 있어도 토큰을 쓸 수 있으므로, 폴링과 능동 동작의 빈도를 통제하는 설계가 필요합니다.
우리 내부 운영에서도 이미 비슷한 패턴을 다룹니다. 작업 에이전트의 결과를 슬랙 보고 채널로 보낼 때, 외부 커넥터 게이트웨이 하나에 의존하지 않고 저장소에 직접 토큰을 쓰는 자체 스크립트 경로를 폴백으로 둡니다. 게이트웨이가 죽어도 보고가 끊기지 않게 하기 위해서입니다. 지속형 에이전트가 업무 흐름의 일부가 될수록, 이런 단일 장애점 제거와 우아한 성능 저하 설계가 부수 기능이 아니라 필수가 됩니다.
플랫폼 사업 관점에서 이것은 분명한 기회입니다. Claude Tag이 보여주는 것은 에이전트가 협업 도구 안으로 들어와 상주하는 미래가 이미 시작되었다는 사실입니다. 그 미래를 SaaS로만 쓸 수 없는 고객, 즉 온프레미스와 self-hosting과 데이터 주권이 필요한 고객에게 같은 경험을 제공하는 것이 우리가 서 있는 자리입니다. 화려한 데모가 아니라, 격리와 권한과 비용이 코드로 강제되는 운영 설계가 그 차별점입니다.
한계 및 반론
가장 먼저 짚을 한계는 베타라는 사실입니다. 현재 Claude Tag은 특정 요금제 고객에게 슬랙으로 제공되는 베타이고, 능동 동작이 실제 업무에서 얼마나 신뢰할 만한지는 아직 폭넓게 검증되지 않았습니다. 발표된 능력과 현장의 안정성 사이에는 늘 간극이 있습니다.
둘째 반론은 상주형·능동형 에이전트가 항상 좋은 것은 아니라는 점입니다. 채널에 늘 떠 있는 에이전트는 잡음을 만들 수 있고, 능동적으로 끼어드는 동작은 잘못 조정되면 사람의 주의력을 빼앗습니다. 협업 도구는 사람의 집중이 모이는 곳이기도 해서, 에이전트가 그 집중을 흩뜨리면 오히려 생산성이 떨어집니다. 능동성은 기본값이 아니라 신중하게 켜야 하는 옵션입니다.
셋째는 종속성입니다. 업무 맥락과 워크플로가 특정 벤더의 협업 에이전트에 깊이 얽히면, 나중에 다른 환경으로 옮기기 어려워집니다. 이 지점은 역설적으로 온프레미스·표준 기반 접근의 가치를 키웁니다. 특정 SaaS에 종속되지 않고 같은 패턴을 자체 인프라에서 재현할 수 있다면, 조직은 능력은 얻되 종속은 피할 수 있습니다.
결론적으로 Claude Tag은 에이전트가 일회성 대화에서 상주형 동료로 옮겨가는 흐름을 가장 또렷하게 보여주는 사례입니다. 그러나 그 가치를 실제 조직에서 안전하게 누리려면, 모델의 능력만이 아니라 격리·권한·비용·되돌리기라는 운영 설계가 함께 와야 합니다. 그 설계를 자체 인프라 위에서 제공하는 것이 멀티테넌트 온프레미스 플랫폼이 서 있는 자리입니다.
관련 슬라이드
본문 내용을 NotebookLM(doodle_collage 스타일)으로 요약한 슬라이드입니다.
