2026년 6월 23일, Anthropic은 Claude Tag를 출시했습니다: Slack 채널에서 @Claude 태그를 사용하면 에이전트 팀원(agentic teammate)으로서 작동합니다. 즉, 도구 호출(tool calls)을 실행하고, 스레드를 따르며, 메모리(memory)를 구축하고, 귀하의 조직(org)의 신원(identity) 하에 활동합니다. 기존의 "Claude in Slack" 채팅 앱은 2026년 8월 3일에 은퇴합니다. 관리자에게는 마이그레이션(migrate)을 위한 30일의 시간이 주어집니다. 이것은 단연코 당신이 빌릴(rent) 수 있는 최고의 에이전트 팀원입니다.

이 점에 대해 미리 솔직하게 말씀드리고 싶습니다. 왜냐하면 흥미로운 질문은 Claude Tag가 좋은지 아닌지가 아니기 때문입니다. 그것은 좋습니다. 흥미로운 질문은 Claude Tag가 답하지 않는 질문입니다: 에이전트가 귀하의 워크스페이스(workspace)에서 관리자 권한 범위의 도구(admin-scoped tools)를 가질 때, 에이전트가 구축한 메모리는 누가 소유하며, 에이전트가 수행한 작업의 로그(log)를 누가 검증할 수 있는가?

Claude Tag의 가치를 인정하며

비난하는 글을 쓰는 것은 쉽고 잘못된 일일 것입니다. Claude Tag의 엔지니어링은 강력하며, 이 논쟁의 솔직한 버전은 그 점을 인정하는 것부터 시작합니다:

• 인프라 제로 (Zero infrastructure). 서버도, 배포도, 온콜(on-call)도 필요 없습니다. 봇을 태그하기만 하면 작동합니다. 설정 비용 측면에서 이와 경쟁할 수 있는 셀프 호스팅 (self-hosted) 방식은 없습니다.
• 멀티플레이어 공유 컨텍스트 (Multiplayer shared context). 채널 내에서 "모두와 상호작용하는 하나의 Claude" 역할을 수행합니다. 누구나 봇이 무엇을 작업하고 있는지 볼 수 있으며, 마지막 사람이 중단한 지점부터 작업을 이어받을 수 있습니다.
• 복리 효과를 내는 메모리 (Compounding memory). 시간이 지남에 따라 "학습하며... 작업에 대한 더 많은 컨텍스트를 구축"하고, 권한이 있다면 채널을 넘나들며 학습할 수 있습니다.
• 중앙 집중식 거버넌스 (Central governance). 관리자는 채널별로 모델이 접근할 수 있는 도구와 데이터를 지정할 수 있습니다. 사용량은 조직(org) 단위로 청구됩니다. 관리자는 조직 및 채널별로 **토큰 지출 한도 (token-spend caps)**를 설정할 수 있습니다.
• 진정으로 훌륭한 보안 모델 (A genuinely good security model). 작업은 **Anthropic의 인프라 내 격리된 샌드박스 (isolated sandbox)**에서 실행됩니다. 외부 시스템이 필요한 경우, 요청은 **에이전트 프록시 (Agent Proxy)**를 거치게 됩니다. 실행 범위에 따라, 자격 증명은 "스토어에 보관되어 있다가 네트워크 경계에서 주입되며, 모델은 원시 키 (raw keys)를 받지 않는" 방식으로 처리됩니다. 또한 허용되지 않은 호스트에 대해서는 **기본 거부 정책 (default policy of deny)**을 적용합니다.

마지막 지점은 강조할 가치가 있습니다. 사람들이 과소평가하는 부분이기 때문입니다. 원시 자격 증명을 모델로부터 격리하고 외부 유출(egress)을 기본적으로 차단하는 것은, 보안을 중시하는 셀프 호스팅 스택이 구축하고자 하는 방식과 정확히 일치합니다. Anthropic은 어렵지만 올바른 길을 택했습니다. 인프라 구축 없이 내일 당장 Slack에서 에이전트를 사용하고 싶다면, Claude Tag는 매우 훌륭한 제품이며 당신은 이를 사용해야 합니다.

따라서 이것은 "그들의 방식이 보안에 취약하다"는 뜻이 아닙니다. 이는 완전히 다른 문제입니다.

당신이 실제로 하고 있는 트레이드오프 (The trade you're actually making)

이러한 모든 이점은 하나의 근본적인 원인을 공유합니다. 바로 기저(substrate)가 Anthropic의 것이라는 점입니다. 샌드박스(sandbox)가 그들의 인프라(infra) 위에 있으며, 메모리(memory) 또한 마찬가지입니다. AlphaSignal이 주장하듯, 진정한 Claude Tag 문제는 컨텍스트 소유권(context ownership)에 관한 것입니다. 즉, Claude가 구축하는 조직적 지식은 다음 벤더가 가져올 수 있는 내보내기 가능한 데이터셋이 아니라, 벤더의 독점적인 상태(proprietary state)가 됩니다. 이 상황이 가리키는 원칙은 간단합니다. '에이전트는 빌리되, 메모리는 소유하라'는 것입니다. 하지만 Claude Tag는 이를 뒤집습니다. 에이전트를 빌리는 동시에 메모리까지 벤더와 함께 머물게 됩니다. 비평가들은 이 더 깊은 함정을 동일한 방식으로 명명했습니다. 바로 모델 락인(model lock-in)이 아닌 컨텍스트 락인(context lock-in)입니다. 그리고 그들의 지적은 타당합니다. 우려의 핵심은 Anthropic이 무언가 잘못을 하고 있다는 것이 아니라, 그들의 인센티브(incentives)가 명확하다는 점입니다.

해당 기저(substrate) 위에는 메모리 이식성(memory portability)보다 더 중요한 두 가지 요소가 더 존재합니다.

1. 거버넌스(Governance)가 거칠다(coarse). 관리자 제어(Admin control)란 '어떤 채널을 사용할지', '어떤 도구/데이터를 사용할지', 그리고 '지출 한도(spend caps)'를 의미합니다. 이는 범위(scope)와 예산(budget)의 문제입니다. 이는 중요한 도구 호출(tool call)이 실행되기 전에 문서화되고 의무적인 인간의 승인을 거치는 것을 의미하지 않습니다.
2. 감사 로그(audit log)가 벤더의 소유다. 관리자는 "@claude가 수행한 모든 작업의 로그를 볼 수 있습니다." 즉, Anthropic의 기록을 '볼' 수는 있습니다. 하지만 신뢰 경로(trust path)에 벤더를 두지 않고, 자신만의 키를 사용하여 독립적으로 이를 '검증(verify)'할 수는 없습니다.

많은 팀에게 이 중 어느 것도 결정적인 결격 사유는 아니며, 그들은 Claude Tag를 사용해야 합니다. 하지만 규제 대상 기업, 보안 벤더, 또는 "당신의 에이전트가 무엇을 했는지 증명하라"는 질문에 대해 로그 저장소를 제어하는 적대자(adversary) 앞에서도 살아남아야 하는 조직에게는, 거친 거버넌스와 벤더가 보여주는 기록만으로는 충분하지 않습니다. 이것이 바로 두 개의 오픈 소스(open-source) 프로젝트가 만들어진 이유이자 메우고자 하는 간극입니다.

필터가 경계가 될 수 없었던 이유

대안이 생기기 전의 전제는 이렇습니다. 신뢰할 수 없는 텍스트를 읽는 도구 사용 에이전트(tool-using agent)에게 있어 — 모든 Slack 메시지는 신뢰할 수 없는 입력값입니다 — 콘텐츠 필터링은 보안 경계가 될 수 없습니다. 이는 CCSC와 AGP를 포함하여 어떤 Slack 연결 에이전트에도 해당하며, Claude Tag에 국한된 이야기가 아닙니다. 이것이 바로 답이 더 나은 필터가 아니라 다른 아키텍처여야 하는 이유입니다. 관련 문헌들은 이 점을 명확히 지적합니다. InjecAgent (ACL 2024 발표 결과)는 ReAct 프롬프트를 사용한 GPT-4가 간접적인 프롬프트 주입(indirect prompt injection)에 대해 24%의 확률로 취약하며, 이 중 사적 데이터 유출(private-data exfiltration)이 주요 공격 유형임을 발견했습니다. 더욱 심각하게는, Adaptive Attacks Break Defenses Against Indirect Prompt Injection (NAACL 2025)은 평가된 모든 여덟 가지 방어 메커니즘을 우회하여 공격 성공률을 50% 이상으로 유지했습니다. 그리고 MCP를 거치는 도구들(tools reached over MCP)이 '자연어 메타데이터를 가진 일급의, 구성 가능한 객체'이기 때문에, MCP Security Bench는 표준 자체가 공격 표면을 _확대_시킨다는 것을 보여줍니다 — 이름 충돌(name-collision), 도구 설명 주입(tool-description injection), 범위를 벗어난 매개변수(out-of-scope parameters) 등의 위험이 있습니다.

여기서 얻어야 할 교훈은 '더 나은 필터를 추가하라'가 아닙니다. 확률적 모델(probabilistic model)이 파괴적인 행동을 실행할지 여부를 결정하는 주체가 될 수 없다는 것입니다. 당신에게 필요한 것은 모델이 우회할 수 없는 결정론적 게이트(deterministic gate), 결과에 영향을 미치는 호출에 대한 인간의 개입(human in the loop), 그리고 런타임(runtime) 자체를 신뢰하지 않고도 신뢰할 수 있는, 실제로 실행된 내용에 대한 기록입니다. 이 세 가지 속성이 바로 제가 고객 소유의 검증 가능한 거버넌스(customer-owned, verifiable governance)라고 부르는 세 가지 기둥입니다.

두 가지 참조 구현체(reference implementations): CCSC (Claude Code Slack Channel)는 Claude Code를 정확히 이러한 게이트(gates) 뒤에 Slack에 배치하는 작고 감사 가능한 거버넌스 커널(auditable governance kernel)이며, AGP (Agent Governance Plane)는 여러 에이전트 하네스(agent harnesses)에 걸쳐 샌드박스 실행(sandboxed execution)을 통해 해당 커널을 재구현하고 강화(hardens)한 것입니다. AGP는 CCSC를 벤더링(vendor)하거나 이에 의존하지 않습니다. 이는 CCSC의 v0.10.0 설계에 고정된 독립적인 재구현(

CCSC에서 이는 순수한 결정 절차(decision procedure)입니다. evaluate(call, rules, now)는 부수 효과(side effects) 없이 도구 호출(tool call)을 allow | deny | require로 매핑합니다. 즉, 동일한 입력에 대해 매번 동일한 판결을 내립니다. 계층화된 규칙(Tiered rules)은 가장 엄격한 규칙이 우선 적용된 후, 그다음 적용 가능한 첫 번째 규칙을 따릅니다. 기본적으로 하나의 도구인 upload_file은 '실패 시 차단(fail-closed)'(규칙이 허용하지 않는 한 거부됨)을 기본값으로 합니다. 그 외의 모든 도구는 사용자가 작성한 정책을 따르므로, 워크스페이스에서 중요한 동작을 '실패 시 차단' 상태로 만드는 것은 상속받는 기본값이 아니라 사용자가 직접 작성해야 하는 규칙입니다. AGP는 더 강력한 입장을 취하며 이를 내장합니다. AGP의 엔진은 deny > require > allow 순서의 기본 거부(default-deny) 방식을 따르므로, 어떤 규칙과도 일치하지 않는 호출은 '허용(allow)'이 아닌 '거부(deny)'로 실패 처리됩니다. 이것이 바로 "AGP가 커널을 강화(hardens the kernel)한다"는 의미입니다. 두 방식 모두 결정 과정 근처에 if (model === "claude")와 같은 분기문을 전혀 두지 않습니다. 관문은 실행 전에 평가되는 데이터입니다.

비용 상한선(spend cap)과의 차이점이 바로 핵심입니다. 토큰 예산은 에이전트가 '얼마나 많이' 할 수 있는지를 제한합니다. 반면 정책 엔진은 '이 특정 동작'이 허용되는지를 결정하며, 중요한 동작에 대해서는 인간을 루프에 참여(human-in-the-loop)하도록 강제할 수 있습니다.

기둥 2 — 도구 호출당 인간 주도의 승인 (Human-in-command approval, per tool call)

감시(oversight)의 스펙트럼에서 중대한 동작에 중요한 모드는 **인간 주도(human-in-command)**입니다. 즉, 인간이 승인할 때까지 동작이 실행되지 않는 방식입니다. 이는 "사후에 로그를 검토하는 것"이 아닙니다. "예산을 설정하는 것"도 아닙니다. 실행되기 '전'에, '이' 호출에 대해 차단형 승인(blocking approval)을 수행하는 것입니다.

CCSC의 require 판결은 인간 승인자에게 라우팅됩니다: 승인은 게이트가 인식하는 응답 코드이며, 쿼럼(quorum)은 고유한 사용자 ID로 계산됩니다. 그리고 피어 봇(peer bots)의 권한-응답 메시지는 인바운드 게이트에서 폐기되므로, 주입된 메시지가 승인 투표를 할 수 없습니다. 별도의 더 강력한 핸드셰이크가 관리자 명령어 경로(!restart)를 보호합니다: 이는 단일 사용 64비트 논스(nonce)로, 아웃 오브 밴드(out of band) DM으로 전송되며, TTL(Time-To-Live)이 제한되고 잘못된 채널 재생 공격에 대해 확인됩니다. 이는 요청과 승인 모두가 손상된 채널에서 발생하는 EchoLeak급 주입을 무력화하도록 특별히 구축되었습니다. AGP는 호출당 승인을 Slack Block-Kit의 Approve/Deny 버튼으로 구현하며, 이 논스는 (messageId, sessionId)에 바인딩됩니다. 그리고 결정적으로, 봇은 절대 승인할 수 없으며, 봇의 클릭으로는 심지어 논스가 소모되지도 않습니다.

이것이 Claude Tag가 가장 눈에 띄게 갖추고 있지 않은 기둥(pillar)입니다. 관리자 범위는 어떤 도구에 접근 가능한지를 결정하며, 각 중요한 호출 전에 의무적인 인간 승인이 있다는 공개적 증거는 없습니다.

CCSC의 저널(journal)은 해시 체인(hash chain)입니다. 각 항목은 sha256(prevHash ‖ canonicalJson)을 커밋하므로, 순서를 변경하거나 편집하면 이후의 모든 링크가 깨지게 됩니다. 각 항목은 RFC 8785 JSON 정규화(JSON Canonicalization)에 대해 Ed25519 서명이 되어 있으며, 결정이 내려질 당시 정확히 어떤 규칙이 적용되었는지를 기록하는 policy_attestation 다이제스트(digest)를 포함합니다. 사용자는 오직 공개 키(public key)만을 사용하여 오프라인에서 bun server.ts --verify-audit-log <path> 명령어로 전체 내용을 검증할 수 있습니다. 벤더(vendor)도, 라이브 서비스도 필요하지 않습니다. 키 로테이션(key rotation)이 지원되므로, 검증자는 로테이션 이후에도 여전히 작동합니다. 이는 Certificate Transparency 설계 계보 — 운영자를 신뢰하지 않고도 제3자가 확인할 수 있는 추가 전용(append-only) 로그 — 를 따릅니다. 이는 GlassDB와 같은 검증 가능한 원장 데이터베이스(verifiable ledger databases), 그리고 에이전트 액션 체인을 위한 Certificate-Transparency 스타일의 출처 증명(Certificate-Transparency-style provenance for agent action chains)에 관한 최근 연구와 동일한 계보입니다. 여기서 외부 검증자는 런타임(runtime)에 접근하지 않고도 에이전트가 수행한 작업을 암호학적으로 검증합니다.

그리고 대부분의 "검증 가능한 로그" 주장이 생략하는 솔직하고 핵심적인 세부 사항이 있습니다. 바로 단순한 해시 체인만으로는 절단(truncation)을 막을 수 없다는 점입니다. 공격자가 마지막 N개의 항목을 삭제하더라도 남은 체인은 여전히 깨끗하게 검증됩니다. CCSC는 이를 위협 모델(threat model)에서 위협 T8로 명시적으로 문서화하고 있습니다. AGP는 바로 그 구멍을 메웁니다. AGP는 {seq, hash}를 고정하는 <journal>.head 파일을 통해 **서명된 HEAD 체크포인트(signed HEAD checkpoint)**를 작성하므로, 오프라인 검증자가 체인 단독으로는 잡아낼 수 없는 절단된 꼬리 부분을 포착할 수 있게 합니다. agp verify는 체인, 서명, 그리고 서명된 헤드(head)를 오프라인에서 오직 공개 키만으로 확인합니다. 이것이 바로 증거를 소유함으로써 얻는 가치입니다. "우리의 로그를 믿으세요"가 아니라, "여기 기록이 있으니 직접 확인하십시오. 그리고 그중 어떤 것도 몰래 잘려 나가지 않았음을 확인하십시오"라고 말할 수 있는 것입니다.

AGP가 추가하는 네 번째 속성 — 외부 유출(egress)이 차단되었음을 증명하는 샌드박스