Claude Tag의 에이전트 ID(agent identity) 접근 모델이 어떻게 동작하는지, 그리고 팀 워크스페이스에 도입할 때 알아두어야 할 설정 방법과 모범 사례를 정리합니다.
AI 에이전트가 인간-에이전트 팀에서 제 역량을 발휘하려면, 팀원들이 쓰는 것과 동일한 도구, 문서, 컨텍스트에 접근할 수 있어야 합니다.
1:1 대화 방식의 AI(한 사람이 하나의 어시스턴트와 대화하는 방식)라면 이는 간단합니다. 본인 계정을 연결하면 에이전트가 그 권한으로 작업을 수행하면 되니까요. 하지만 Claude Tag처럼 여러 사람이 함께 사용하는 멀티플레이어 방식에서는 다릅니다. Claude는 다수의 팀원이 있는 공유 채널에 함께 존재하며, 특정 개인이 아닌 워크스페이스 전체의 도구와 컨텍스트를 활용합니다.
멀티플레이어 환경이 제대로 돌아가려면 Claude가 각 도구에 대한 자체 계정을 가져야 하며, 이는 관리자가 설정하고 워크스페이스에 귀속됩니다. 이 접근 모델을 에이전트 ID(agent identity)라고 부릅니다.
이 글에서는 에이전트 ID가 어떻게 동작하는지, 권한 구조를 사용자 단위에서 채널 단위로 어떻게 전환하는지, 그리고 워크스페이스에서 적절한 범위를 설정하는 방법을 설명합니다.
AI를 개인 비서로 활용할 때는 Google Drive, GitHub, 캘린더 같은 플랫폼을 연결하고, 모델이 본인의 접근 권한으로 파일을 읽고 쓰도록 허용하는 방식을 씁니다.
하지만 이 방식은 Claude Tag에 적용하기 어렵습니다. 이유는 두 가지입니다.
Claude Tag가 활성화된 채널에서 Claude는 특정 사용자를 대리하지 않습니다. 연결된 각 시스템에서 고유한 자체 계정을 사용합니다. Slack에서는 Claude 앱으로 메시지를 올리고, GitHub에서는 Claude GitHub App으로 풀 리퀘스트를 열며, 데이터 웨어하우스는 관리자가 프로비저닝한 서비스 계정으로 쿼리를 실행합니다.
개인 사용자 자격증명이 개입하지 않으므로, 공유 채널이 누군가의 개인 문서로 들어가는 뒷문이 될 우려도 없습니다.
에이전트 ID 모델에서 관리자는 워크스페이스 수준에서 에이전트 ID를 정의합니다. 이 ID는 Claude가 어디서든 기본적으로 갖게 되는 연결과 기능의 집합이며, 모든 채널이 기본적으로 이를 상속합니다. 이후 필요에 따라 채널 수준에서 재정의할 수 있습니다. 예를 들어 엔지니어링 채널에는 GitHub와 데이터 웨어하우스 접근 권한을 부여하고, CRM 연결은 특정 비공개 채널 하나로 제한하는 식입니다.
자격증명 외에도 관리자는 다음 항목을 함께 설정합니다.
이 모델은 독립된 Claude ID를 기반으로 작동하기 때문에, ID를 폐기하는 것만으로 해당 ID가 사용된 모든 곳에서 Claude의 접근이 즉시 차단됩니다. 수십 개의 사용자 계정에 걸쳐 에이전트 활동을 일일이 감사하는 것보다 훨씬 적은 관리 비용으로 운영할 수 있습니다.
에이전트 ID는 "이 사용자가 무엇을 할 수 있는가?"라는 질문을 "이 에이전트가 이 구획에서 무엇을 할 수 있는가?"로 바꿉니다. 이는 사용자별 접근 제어 목록(ACL)에서 벗어나는 방식입니다. 즉, 저장소에 직접 접근 권한이 없는 채널 멤버라도, 해당 채널의 프로필이 Claude에게 그 저장소 접근 권한을 부여했다면 Claude에게 읽어달라고 요청할 수 있습니다.
다소 낯선 방식이지만, 자율적으로 동작하는 멀티플레이어 에이전트에 적합한 접근 모델로 나아가기 위한 필연적인 전환이라고 생각합니다. 아래에서 경계를 설정하는 방법에 대한 사고 방식을 설명합니다.
Claude Tag는 각 비공개 채널마다 별도의 ID를 생성하며, 워크스페이스 내 공개 채널은 워크스페이스 수준의 ID를 공유합니다. 법무 채널의 Claude ID로는 해당 채널에 권한이 부여되지 않은 코드에 접근할 수 없고, 엔지니어링 채널의 Claude ID로는 권한이 없는 법무 문서를 읽을 수 없습니다. 메모리와 접근 권한 모두 이 경계를 따릅니다. 비공개 채널에서 Claude가 학습한 내용은 더 넓은 워크스페이스에 노출되지 않습니다.
ID는 채널에 귀속되므로 기본적으로 채널 내 누구나 Claude를 호출할 수 있으며, 관리자는 각 채널의 프로필을 최소 권한 원칙에 따라 설정할 수 있습니다. 엔터프라이즈 플랜에서는 역할 기반 접근 제어(RBAC)를 통해 Claude를 호출할 수 있는 멤버를 추가로 제한할 수 있어, 채널 단위로 에이전트의 접근 범위와 요청 가능한 사용자를 모두 관리할 수 있습니다.
.jpg)
Anthropic 내부에서 Claude Tag를 직접 사용해본 결과, 도구와 컨텍스트 접근 권한을 확대할수록 그 가치가 복리처럼 불어난다는 것을 확인했습니다. 연결된 시스템이 늘어날수록 각 시스템의 유용성도 함께 높아집니다. Claude가 여러 시스템에 걸쳐 컨텍스트를 통합할 수 있기 때문입니다. Slack 스레드, Drive 문서, 이슈 트래커 티켓, 웨어하우스 쿼리 결과를 하나로 엮어 어떤 단일 도구로도 낼 수 없는 답변을 만들어냅니다.
Claude를 가장 잘 활용하는 팀은 처음부터 넓은 접근 권한을 부여한 뒤, 조직의 관리 정책에 맞게 점진적으로 범위를 조정하는 방식을 택합니다. 에이전트 ID는 Claude가 시스템 간 유용한 작업을 수행할 수 있을 만큼 충분히 넓은 범위를 허용하면서도, 권한이 허가되지 않은 곳으로 접근이 확산되지 않도록 경계를 단단히 유지합니다. 권장하는 접근 방식은 몇 개 채널에 기본 프로필을 먼저 적용하고, 감사 로그를 살펴본 뒤, 작업 필요성이 확인된 곳에 한해 하나씩 신중하게 접근 권한을 확장하는 것입니다.
더욱 세밀한 제어가 필요한 조직이라면 특정 채널에서 Claude Tag를 비활성화할 수 있습니다. 또한 역할 기반 접근 제어를 적용해 Claude Tag에 접근 가능한 사용자를 특정 구성원으로 제한할 수도 있습니다.
Claude Tag에서 다이렉트 메시지(DM)는 공유 채널과 다르게 동작합니다. DM은 사용자 개인의 claude.ai 계정을 기반으로 실행되며, 커넥터, 자격증명, 결과에 표시되는 이름 모두 해당 사용자 것입니다. 채널에 두기 적합하지 않은 작업, 예를 들어 이메일 초안 작성이나 본인만 라이선스를 보유한 소프트웨어를 활용한 작업은 DM을 활용하는 것이 적절합니다.
관리자가 채널 프로필에 연결을 추가하면 해당 자격증명은 독립적으로 저장되고 채널 ID에 매핑된 뒤, 요청 시점에 네트워크 경계에서 주입됩니다. 관리자가 허용하지 않은 호스트로의 아웃바운드 트래픽은 전면 차단됩니다. 감사 측면에서는 에이전트 자격증명으로 실행된 모든 루틴, 메모리 쓰기, 네트워크 호출이 기록되며, Claude가 자체 서비스 계정으로 작동하기 때문에 해당 작업은 각 연결 시스템의 자체 로그에도 남습니다.
에이전트 ID는 Claude Tag 접근 모델의 근간입니다. 앞으로는 Claude Tag의 보안 기능을 더욱 강화할 계획입니다. 구체적으로는 적시(just-in-time) 자격증명 부여 기능을 도입해, 사용자가 에이전트의 전체 권한 범위를 영구적으로 확장하지 않고도 민감한 단일 작업을 그 순간에 직접 승인할 수 있도록 할 예정입니다. 또한 복잡한 보안 등급 체계를 가진 조직을 위한 ID 인식 오버레이도 제공할 계획입니다. 이를 통해 에이전트의 권한 범위 위에 사용자 수준 검증을 추가해, 채널 프로필과 요청 사용자의 권한이 모두 충족될 때만 Claude가 작업을 수행하도록 할 수 있습니다.
Claude Tag 같은 제품에서 AI가 1:1 방식에서 멀티플레이어 방식으로 전환되면서, 팀 기반의 장기 작업이 가능해졌습니다. 에이전트 ID는 Claude의 도구 접근 범위가 실질적인 도움이 될 만큼 충분히 넓으면서도, 엔터프라이즈 규모에서 안전하게 통제될 수 있을 만큼 명확한 경계를 유지하도록 보장합니다.
자세히 알아보기 (Claude Tag 소개)
이 글은 Claude Code 팀 소속 Noah Zweben이 작성했습니다.