조직이 AI 와 함께 업무를 구성하는 방식을 위한 참조 모델
Jose Martinez · 2026 년 10 월 1 일 · v1.8.1 (Claude Code 에서 측정; 2026 년 10 월 1 일 Anthropic 문서와 대조 재확인)
다섯 줄 요약.
- 조직은 트리(tree) 구조다: 회사, 업무 라인, 프로젝트, 작업. 반면 Claude 의 프로젝트는 평면적이다: 채팅에는 3,000 자짜리 조직 블록 하나만 존재하고, 채팅과 Cowork 의 프로젝트는 중첩되거나 상속되지 않으며, 프로젝트 내 커넥터 계정은 개인이나 조직 전체에 속할 뿐 특정 하위 부서(branch)에는 절대 속하지 않는다.
- 그래서 모든 프로젝트가 해당 업무 라인의 규칙을 수동으로 복사해 쓰게 되고, 복사본끼리 내용이 어긋나며, 어떤 규칙이 특정 답변을 만들어냈는지 아무도 알 수 없게 된다.
- Anthropic 은 이미 이 트리를 두 번이나 만들었다. Claude Code 는 폴더별로 지침을 중첩하며, 2026 년 10 월 1 일부터는 조직의 mod 를 개인의 mod 보다 먼저 실행한다. Slack 에서 작동하는 Claude Tag 는 조직에서 워크스페이스로, 다시 채널로 지침과 자격 증명을 상속한다. 하지만 둘 다 프로젝트 단계까지는 닿지 않는다. 동일한 모델이라면 가능하다: 업무 라인 레이어, 해당 폴더에서 생성되는 프로젝트, 타입이 지정된 작업, 모델이 보기 전에 충돌을 거부하는 컴파일러, 그리고 Team 에서 작동하는 노드별 권한이 그것이다.
- 나는 이를 Claude Code 에서 두 번 측정했다. 서로 상충하는 조직 규칙과 프로젝트 규칙을 각각 다른 CLAUDE.md 레벨에 두고 어느 쪽에도 강제성을 부여하지 않았을 때, 프로젝트 규칙이 20 회 중 20 회 승리했다. 같은 조직 규칙을 텍스트만으로 강제(enforced) 처리했을 때도 20 회 중 20 회 승리했다. 우선순위는 구조가 아니라, 어떤 레이어든 편집하는 사람이 마음대로 바꿀 수 있는 문구에 의해 결정되었다.
- 이는 오늘 당장 실행된다. 내가 만든 데스크톱 앱은 트리 내부에서 Claude Code 를 구동한다. 각 레이어를 CLAUDE.md 로 마운트하고, 해당 노드에서 사용자가 할 수 있는 작업으로 Claude 를 제한하며, 충돌이 작성되는 즉시 거부하고, 모든 답변을 해당 규칙, 토큰, 검토자와 함께 기록한다. 측정 결과, 트리는 평면적인 복사본보다 20~34% 적은 지침 토큰을 로드했다.
조직은 트리다. 회사는 정책을 정하고, 업무 라인은 기준을 세우며, 프로젝트는 이를 하나의 업무에 적용하고, 작업은 하나의 결과물을 내놓는다. 내가 경험한 모든 품질 시스템은 이렇게 구축되어 있으며, 거의 모든 회사 파일 서버의 폴더 트리 역시 마찬가지다. 회사, 업무 라인, 연도, 그리고 그 모든 정보를 인코딩한 작업 번호로 이름 붙여진 작업별 폴더 하나가 이어진다.
AI 프로젝트는 평면적이다. 내가 사례로 Claude 를 드는 이유는 매일 사용하는 제품이기 때문이고, 이미 자체 인터페이스 두 곳에서 해답을 제공하고 있기 때문이다. Claude 채팅에서는 프로젝트를 중첩할 수 없고, 조직 지침은 모두에게 동일하게 적용되는 최대 3,000 자의 단일 블록이다. Enterprise 에서는 관리자가 그룹별로 권한 범위를 지정할 수 있다. Team 에서는 역할이 조직 전체에 적용된다. 채팅이나 Cowork 문서 어디에도 지침을 부서나 업무 라인으로, 나아가 그 안의 프로젝트로 내려보내는 내용은 없다. Enterprise 에서는 스킬과 프로젝트를 그룹과 공유할 수 있지만, 이는 배포일 뿐 상속이 아니다.
바로 그 누락된 레이어, 즉 조직과 프로젝트 사이의 레이어가 문제다. 이 글은 무엇이 빠져 있는지, 왜 중요한지, 실제로 어떤 비용이 발생하는지, 그리고 권한과 데이터 구조를 포함해 어떤 플랫폼이든 구현할 수 있는 참조 모델을 제시한다.
1. 현재 존재하는 것들
2026 년 9 월 29 일~10 월 1 일 Anthropic 문서와 대조 확인함. Claude 에는 팀의 업무가 실행되는 네 가지 인터페이스(surface)가 있으며, 각각 고유한 지침 모델을 가진다:
권한은 요금제에 따라 달라진다:
Anthropic 은 권한을 위한 트리의 절반을 이미 구축했다. Enterprise 에서는 사용자 정의 역할이 그룹에 할당되며, "사용자 정의 역할은 또한 어떤 커넥터와 해당 커넥터의 어떤 도구를 사용할 수 있는지도 제어"한다. 플랫폼 전반에 걸쳐 조직, 역할, 사용자 레벨 간에는 "가장 제한적인 레벨이 우선"하고, 한 멤버의 여러 역할은 합산된다. 관리자는 "부여 주체(Granted by)" 레이블과 함께 "실효 역할 보기(View effective role)"를 확인할 수 있고, 그룹마다 자체 지출 한도를 설정할 수 있다. 하지만 이는 평면적인 그룹이지 트리가 아니며, 어느 것도 지침에는 닿지 않는다. 가장 근접한 것은 플러그인이다. Enterprise 에서 소유자는 특정 그룹에 대해 플러그인과 그 스킬을 필수 또는 기본 설치로 지정할 수 있으며, 명시된 순서("그룹 설정, 그다음 조직 전체 설정, 그다음 마켓플레이스 기본값")를 따른다. 이는 프로젝트가 아닌 사람 집단을 대상으로 하며, 프로젝트 간에는 아무것도 상속되지 않고, 스킬은 여전히 Claude 가 관련 있다고 판단할 때만 로드된다. Team 은 조직 전체에 대한 역할과 개인 단위 공유 기능을 갖추고 있으며, 문서의 표현을 빌리자면 플러그인 설정에 "그룹 설정은 없다". 그런데 Team 은 중소기업을 위해 만들어진 요금제다.
Anthropic 은 프로젝트 외부에서 전체 트리를 두 번이나 구축했다.
Claude Code 에서는 폴더별로. Claude Code 는 네 가지 레벨에서 CLAUDE.md 파일을 로드한다. "발견된 모든 파일은 서로 덮어쓰지 않고 컨텍스트로 연결"되며, "파일 시스템 루트부터 작업 디렉터리까지" 순서대로 정렬되고, 하위 디렉터리의 파일은 "요청 시 로드"된다. 조직의 블록은 각 기기의 관리 파일로 전달되거나 관리자 콘솔(claudeMd 키)의 텍스트로 전달될 수 있다. 문서는 한계를 솔직히 밝힌다. Claude 는 이러한 파일을 "강제된 구성이 아닌 컨텍스트로 취급"하며, "두 지침이 서로 모순될 경우 Claude 가 임의로 하나를 선택할 수 있다."
Claude Tag 에서는 Slack 채널별로. Claude Tag 는 팀의 Slack 에서 작동하는 Claude 로, Team 과 Enterprise 에서 공개 베타로 제공된다. 설정은 스코프(scope)에 연결되며, "스코프란 번들이 적용되는 곳, 즉 기본 Slack 접근(조직 전체 루트), 워크스페이스, 또는 단일 채널"이다. 이 글의 나머지 부분에서 요구하는 세 가지가 이미 여기에 있다:
• 지침이 상속된다. "스코프별 사용자 정의 지침은 연결되며, 기본 Slack 접근이 먼저, 그다음 워크스페이스, 그다음 채널 순이다. 채널의 지침은 상위 설정을 대체하는 것이 아니라 추가된다."
• 자격 증명은 브랜치에 속한다. 채널에서 Claude 는 관리자가 스코프에 연결한 서비스 계정으로 작동하며, "가장 좁은 스코프의 자격 증명이 사용된다: 채널이 워크스페이스를 이기고, 워크스페이스가 기본 Slack 접근을 이긴다."
• 접근 권한의 출처를 확인할 수 있다. 각 커넥터, 리포지토리, 플러그인 행에는 더 넓은 스코프로부터 "상속됨(Inherited from)" 또는 번들로부터 "연결됨(Attached from)"이라고 표시된다. 지출은 조직 전체 및 채널별로 제한되고 채널별로 보고된다.
한계 역시 문서화되어 있다. 트리는 Slack 의 형태를 띤다. 세 개의 고정된 레벨이며, Slack 채널은 중첩되지 않는다. 지침은 "강제된 가드레일이 아닌 안내"이며, 문서는 스코프 간 충돌 검사에 대해 설명하지 않는다. "모든 작업과 요청자를 기록하는 작업별 로그는 없다." 그리고 프로젝트 경계에서 멈춘다. "claude.ai 의 프로젝트는 여기에 적용되지 않는다. Claude 는 Slack 에서 프로젝트의 지침이나 지식 베이스를 읽지 않으며, 채널을 프로젝트로 연결할 수 없다."
2026 년 10 월 1 일에 변경된 사항. Claude Code 2.1.287 은 앞서 얼리 액세스 상태였던 mod 를 활성화했다. mod 는 Claude Code 내부에서 실행되는 플러그인 내 함수로, 프롬프트나 시스템 프롬프트의 일부를 재작성하고, 도구 호출을 차단하거나 재작성하며, 권한 요청을 승인 또는 거부하고, 인터페이스에 창(pane)을 그릴 수 있다. 여기서 중요한 세 가지는 다음과 같다:
• 선언된 순서를 갖는다. 내장 가드와 조직 자체의 mod 가 먼저 실행되고, 그다음 개인이 설치한 mod 가 실행된다. "첫 번째 mod 가 가장 바깥쪽에 위치하여 다른 mod 보다 먼저 이벤트를 보고 나중에 결과를 보며, 다른 mod 가 실행될지 여부를 결정한다." 가드가 로드되는 환경(관리 설정이 적용된 기기, 또는 Team 이나 Enterprise 로그인)에서는 개인의 mod 가 "시스템 프롬프트, 관리되는 CLAUDE.md 및 기타 관리 지침"을 변경할 수 없고, 거부 규칙이 막는 도구 호출을 승인할 수도 없다. 이것이 바로 이 글이 요구하는, 구조에 의해 설정된 우선순위다. 이는 기본값이지 잠금이 아니다. --safe-mode 로 Claude Code 를 시작하는 사람은 조직의 mod 를 포함해 설치된 mod 없이 실행하지만, 관리 훅(hook)과 거부 규칙은 여전히 적용된다.
• 순서에는 두 명의 소유자가 있다. 조직의 mod 는 개인의 mod 보다 먼저 실행되거나, 조직이 선택하면 나중에 실행된다. 업무 라인을 위한 레벨은 없다. 관리자 콘솔에서 전달된 설정은 "조직의 모든 사용자에게 균일하게 적용된다. 그룹별 구성은 아직 지원되지 않는다." 그룹마다 다른 정책을 원하는 조직에게는 두 가지 경로가 있으며, 둘 다 IT 부서를 거쳐야 한다. 각 그룹의 기기에 다른 설정 파일을 배포하거나, "IdP 그룹별로 관리 설정을 전달"하는 자체 호스팅 게이트웨이를 실행하는 것이다.
• 채팅에는 닿지 않고, Cowork 에는 불균일하게 닿는다. "mod 는 Claude Code CLI 와 Claude Desktop 앱의 Code 탭에서 작동한다." mod 는 플러그인의 hooks/hooks.json 으로 배포되는데, Anthropic 의 플러그인 지원 표는 해당 파일이 채팅에서 "무시됨(Ignored)"이라고 표시한다. 같은 표는 Cowork 에서 "로드됨(Loads)"이라고 표시하는데, "Claude Desktop 앱의 Cowork 는 세션을 Claude Code 에서 실행"하기 때문이다. mod 관련 페이지에는 Cowork 가 나열되어 있지 않으며, 나는 이를 테스트하지 않았다. 조직이 제어할 수 있는 범위는 그곳에서 더 좁아진다. Cowork 세션에서 Claude Code 는 "사용자가 Team 또는 Enterprise 계정으로 로그인하더라도 claude.ai 관리자 콘솔에서 서버 관리 설정을 가져오지 않으며", 원격 Cowork 세션에는 읽을 기기 정책이 없다.
롤아웃 중인 사항. Cowork 는 Claude 로 병합되고 있다. 도움말 센터는 이제 "Claude Cowork 는 이제 그냥 Claude 입니다"라고 안내하며, Pro 와 Max 에 먼저 적용되고 Team 과 Enterprise 는 "오늘날과 같이 채팅과 Claude Cowork 를 유지"한다. 2026 년 10 월 6 일, Pro 와 Max 의 새로운 Cowork 작업은 클라우드로 이동한다. 또한 새 버전의 프로젝트가 Pro 와 Max 에서 공개 베타로 제공되며 Claude Code 부터 시작해 채팅, Cowork, Team, Enterprise 로 확대될 예정이다. 여기서는 "프로젝트가 하나의 대화"이며, Claude 가 이를 병렬 스레드로 분할한다. 여전히 단일 레벨이다. "프로젝트는 한 사용자에게 속하며", "베타 기간 동안 프로젝트에 대한 조직 수준의 제어 기능은 없다."
따라서 트리는 Anthropic 에게 새로운 개념이 아니다. 코드에서는 폴더별로, Slack 에서는 채널별로 이미 존재하며, 둘 다 조직이 우선한다. 회사가 업무를 보관하는 장소인 프로젝트에는 부모도, 그 위의 라인도 없다. Anthropic 의 다른 두 가지 제품도 같은 방향을 가리키지만 이 글의 범위를 벗어난다. Claude for Government 는 테넌트, 그룹, 조직 체인을 통해 설정을 해결하고, 타사 제공업체의 Claude Desktop 은 그룹별 정책을 베타로 제공한다.
2. 왜 중요한가
프로젝트는 컨테이너가 아니다. 실제 업무(job)는 컨테이너다. 키(작업 번호), 부모(업무 라인), 라이프사이클(개설, 종료, 연도별 보관), 폴더, 고객, 인원, 규칙, 결과물을 갖는다. 반면 Claude 프로젝트는 자유 텍스트 이름만 있고, 키도, 부모도, 자식도 없으며, 문서화된 라이프사이클은 보관과 삭제뿐이다. Cowork 는 프로젝트를 로컬 폴더에 연결할 수 있지만, 수동으로 한 번에 하나씩만 가능하고 키 패턴이나 부모는 없다. 하나의 업무 라인이 연간 수백 개의 작업을 개설할 수도 있다. 이러면 두 가지 나쁜 선택지 중 하나를 고르게 된다. 작업마다 수동으로 만든 Claude 프로젝트를 하나씩 두고 각각 규칙을 복사해 넣거나, 업무 라인당 프로젝트 하나를 두고 서로 다른 고객의 컨텍스트를 나란히 쌓아두는 것이다.
하중 경로가 끊긴다. 구조 공학에서는 모든 하중이 기초까지 연속적인 경로를 가져야 한다. 부재 하나를 빼내면 그 위쪽의 하중은 아래로 전달되지 않는다. 규칙도 똑같이 작동한다. 조직과 프로젝트 사이에 레이어가 없으면, 업무 라인의 표준, 템플릿, 승인 규칙이 자리할 곳이 없어진다. 그래서 모든 프로젝트가 수동으로 복사본을 받게 된다.
복사본이 어긋난다. 한 프로젝트에서 규칙을 수정해도 나머지는 이전 버전을 그대로 쓴다. 각 프로젝트는 여전히 자체 로컬 검사를 통과한다. 불일치는 누군가 프로젝트를 나란히 비교할 때 드러나며, 규제가 있는 업무에서는 보통 감사인이 그 역할을 한다. 인프라 팀은 이런 실패를 잘 안다. Firefly 의 2026 년 조사에 따르면 응답자의 약 3 분의 1 이 구성 드리프트(configuration drift)를 비용이 많이 드는 프로덕션 장애와 연관 지었고, 약 5 명 중 1 명은 이를 감지하거나 수정할 프로세스가 없었다.
아이덴티티 역시 평면적이다. 많은 사람이 둘 이상의 조직에서 일하며, 각 조직마다 밀봉된 고유 컨텍스트가 필요하다. 그중 어느 조직 안에서든, 채팅과 Cowork 에서는 커넥터 계정이 브랜치가 아닌 개인에 속한다. Enterprise 역할은 그룹이 어떤 커넥터를 사용할 수 있는지 결정할 수 있고, 관리자는 조직 전체에 대해 커넥터를 한 번만 승인하면 되며, 사용자 정의 커넥터는 모두를 위한 하나의 공유 자격 증명을 담을 수도 있다(베타). 어느 쪽이든 계정은 개인이나 조직의 것이지 브랜치의 것이 아니다. 두 고객을 담당하는 컨설턴트는 각 고객의 Drive 를 해당 고객의 프로젝트에 연결할 수 없다. 공유 프로젝트에서는 문제가 더 날카로워진다. "커넥터는 비공개 프로젝트에서만 사용할 수 있다." Claude Tag 는 Slack 채널에 서비스 계정을 연결하는 방식으로 다른 설계가 가능함을 보여주며, 동시에 그것이 프로젝트에서 멈춘다는 사실도 보여준다. Anthropic 의 Google 커넥터 페이지는 연결된 Google 계정 하나를 설명하며, 이를 변경하는 문서화된 방법은 연결을 해제하고 다시 연결하는 것이다. 아래 세 개의 오픈 이슈는 복수 계정을 요구하고 있다. 경계는 사람의 머릿속에 존재하며, 이는 소리 없이 실패하는 전형적인 수동 경계다.
어떤 규칙이 적용되었는지 아무도 볼 수 없다. Claude Enterprise 는 관리자에게 권한에 대한 "실효 역할 보기"를 제공하고, Claude Code 의 /context 는 어떤 메모리 파일이 로드되었는지 나열한다. 이제 Claude Code mod 가 자체 창을 그릴 수 있으므로, 실효 지침(effective-instructions) 뷰는 누구나 그곳에서 만들 수 있다. Claude Tag 는 각 커넥터와 리포지토리에 상속된 스코프를 표시하지만, 지침에 대해서는 문서가 "Claude 에게 관리자 지침을 반복하도록 요청하라"고 안내한다. 특정 답변이 어떤 레이어의 어떤 지침에서 나왔는지 보여주는 인터페이스는 없다. 출처(provenance)가 없으면 감사 추적도 없고, 감사 추적이 없으면 품질 시스템도 없다.
사람들은 이 조각들을 요구하고 있다. Anthropic 의 공개 이슈 트래커(github.com/anthropics/claude-code) 의 오픈 이슈 (2026-10-01 확인):
일곱 번째인 #47741 은 조직이 관리하는 CLAUDE.md 를 요구했지만, Claude Code 에 이미 존재한다는 이유로 닫혔다. 바로 이것이 핵심이다. 레이어는 Code 와 Slack 에 존재하는데, 이슈들은 프로젝트가 있는 곳에 그것을 요구하고 있다.
3. 비용은 얼마이며, 토큰이 무엇을 숨기는가
3.1 토큰은 장벽이 아니다
레이어가 많아지면 메시지마다 컨텍스트가 늘어날 수 있고, AI 는 토큰 단위로 과금된다. 이 설명은 부분적으로만 맞다. 사용량 기반 Enterprise 요금제에서는 API 요율로 과금되므로, 컨텍스트가 늘어나면 수익도 늘지 줄어들지 않는다. Team 에서는 추가 사용량을 켜지 않는 한 좌석 요금이 고정이며, 추가 토큰은 멤버가 주간 한도에 더 빨리 도달하는 형태로 나타난다. 그리고 같은 토큰으로 과금되는 Claude Code 는 이미 4 단계 캐스케이드를 제공한다. 토큰이 장벽이었다면 그것은 존재하지 않았을 것이다. 3.2 절에서 측정한 바에 따르면, 우리가 작성한 어떤 지침도 포함하기 전에 Claude Code 자체의 시스템 프롬프트와 도구는 약 30,200 토큰이었다. 프로젝트의 전체 지침은 여기에 3.5~5.2% 를 추가했다.
3.2 계산 예시
모든 이미지의 태그: REAL = 2026 년 9 월 29 일~10 월 1 일 사이 측정했거나 Anthropic 문서와 대조 확인함; EST = 시뮬레이션; IND = 예시용.
먼저 측정했다. 나는 데모 프로젝트 하나를 대상으로 Claude Code(claude -p, Claude Sonnet 5.5) 에서 동일한 질문을 조건당 5 회씩 실행하고, Claude Code 자체가 보고한 입력 토큰을 수집했다. 9 월 30 일 Claude Code 2.1.286 에서, 10 월 1 일 2.1.287 에서 각각 실행했으며 지침 수는 동일했다. 프로젝트 지침이 전혀 없는 실행 결과를 빼면 각 레이아웃의 비용을 알 수 있다:
아래 시뮬레이션이 보여주지 못한 두 가지가 있다. 동일한 규칙임에도 캐스케이드는 컴파일된 파일보다 224 토큰이 더 든다. 추가되는 모든 파일에는 오버헤드가 따르며, 여기서는 각 레벨 파일에 들어간 앱 자체의 마커와 제목, 그리고 Claude Code 가 로드하는 각 파일 주변에 덧붙이는 프레임이 그것이다. 레벨이 많을수록 오버헤드도 커진다. 또한 Claude Code 는 공개 토크나이저가 × 1.30 을 적용해 추정했음에도 실제로는 그보다 21~26% 더 로드했다. 그 격차의 일부는 동일한 파일별 오버헤드다. 비율은 이를 견디지만 절대 금액은 그렇지 못하므로, 시뮬레이션의 달러 금액은 낮게 잡힌 것으로 이해해야 한다.
그다음 회사 규모로 시뮬레이션했다. 예시용 회사를 대상으로 한 달 치 지침 토큰을 시뮬레이션했다. 3 개 업무 라인에 40 명, 활성 프로젝트 250 개, 라인당 보고서 유형 6 개, 근무일당 1 인 35 메시지(세션당 5 개), 총 29,400 메시지. 토큰 크기는 샘플 지침 텍스트를 Anthropic 의 공개 레거시 토크나이저(Anthropic 스스로 Claude 3 이상에 대해 "매우 대략적인 근사치"라고 부르는 도구) 로 계산한 뒤, Claude 4.7+ 토크나이저 기준으로 1.30 배를 곱했다. 조직 블록은 597 자 샘플을 3,000 자 상한으로 외삽했고, 라인 매뉴얼은 953 자 샘플의 3 배로 잡았다. 가격은 Claude Sonnet 5.5 정가(입력 $2, 5 분 캐시 쓰기 $2.50, 캐시 읽기 $0.20 / 백만 토큰) 를 적용했다. 프롬프트 캐시는 5 분간 유지되며 적중(hit) 시마다 갱신된다.
• 평면적(현재의 우회책): 조직 블록, 그다음 각 프로젝트가 직접 복사한 라인 매뉴얼, 6 개 보고서 템플릿 전체, 프로젝트 세부 사항.
• 트리: 조직, 라인, 사용 중인 보고서 템플릿만, 그다음 프로젝트 세부 사항. 가장 많이 공유되는 것을 먼저 컴파일.
표 뒤의 크기: 조직 블록 830 토큰(3,000 자), 라인 매뉴얼 729, 보고서 템플릿 1 개 147, 프로젝트 세부 사항 98 (반올림; 합계는 반올림 전에 계산). 시뮬레이션은 조직 블록 앞에 위치하는 Claude 자체의 시스템 프롬프트를 무시했다.
두 가지 솔직한 주의사항. 첫째, 트리 자체만으로는 토큰이 절약되지 않는다. −29% 는 타입 지정된 작업(typed tasks) 에서 나온다. 작성 중인 보고서의 템플릿만 로드되고 6 개 전부가 로드되지 않기 때문이다. −62% 는 주로 가장 많이 공유되는 레이어를 먼저 컴파일 해서 나오며, 이로써 수백 개의 프로젝트가 바이트 단위로 동일한 접두사를 공유한다. 6 개 템플릿을 모두 로드하더라도 순서만 바꾸면 공유 캐시 비용이 $36 에서 $18 로 줄어든다(−51%). 나머지는 타입 지정된 작업이 채운다. 두 번째 절감은 캐시가 사용자 간에 공유될 때만 존재한다. Claude API 에서 캐시는 조직 간에 격리되고, 조직 내에서는 워크스페이스별로 격리되므로 동일한 접두사는 워크스페이스 내 요청 간에 재사용된다. claude.ai 에 대해서는 문서화되어 있지 않다. 출시된 상태의 Claude Code 에서는 일어나지 않는다. 그곳에서는 "캐시가 사실상 하나의 기기와 디렉터리로 한정"되므로, 서로 다른 프로젝트 폴더에 있는 두 사람은 서로의 캐시를 활용하지 못한다. 마지막 열은 오늘날 사용 가능한 수치가 아니라, 채팅에 네이티브 레이어가 도입되면 얻을 수 있는 효과로 읽어야 한다. 타당한 반론도 있다. 스킬은 이미 온디맨드로 로드되므로, 템플릿을 스킬로 옮긴 평면적 워크스페이스는 오늘날에도 −29% 의 일부를 얻는다. 채팅과 Cowork 의 스킬에 부족한 것은 스코프와 상속이다. 스킬은 하나의 라인에 속해 그 라인의 프로젝트로 흘러내려갈 수 없다. (Claude Code 에서는 하위 폴더의 스킬이 해당 폴더나 그 아래에서 시작된 세션에 로드된다.) 둘째, 이는 지침 토큰만 해당하며, 이 규모에서는 캐싱 여부에 따라 월 $14 에서 $149 사이다. 실제 청구서의 대부분은 대화 기록과 출력 토큰이 차지한다. 트리를 지지하는 강력한 논거는 정확성이며, Team 에서는 용량이다. 청구서가 아니다.
위의 측정은 가정된 크기가 아닌 실제 트리에서, Claude Code 내에서 타입 지정된 작업 효과를 재현한 것이다. 캐스케이드일 때 −20%, 컴파일했을 때 −34% 로, 시뮬레이션의 −29% 와 비슷하다. 작업 유형이 하나뿐인 라인은 타입 지정된 작업에서 아무것도 절약하지 못할 것이다.
3.3 실제 Claude 가 내놓은 동일한 답변
나는 Claude Code 에 동일한 질문을 40 회 던졌다. 4 가지 조건 각각에서 독립적인 답변 10 개씩, 하루 간격을 둔 5 회씩 두 배치로 나누었다. 질문은 노상(subgrade) 현장 밀도 시험의 합격 여부로, 최대 건조 밀도 115.8 pcf 대비 112.3 pcf 이고 요구 기준이 98% 인 상황이었다. 지침은 회사의 6 개 규칙이거나 한 줄짜리 "유용한 어시스턴트" 프롬프트였고, 언어는 영어 또는 스페인어였다. 40 개 답변 모두 동일한 판정을 내렸다. 97.0%, 불합격.
Claude Code 는 두 가지 출력 수치를 보고한다. 과금된 토큰 수, 그리고 그중 독자에게 보이지 않는 사고(thinking) 토큰 수다.
네 가지 발견:
• 회사의 규칙은 화면상의 답변을 1.4 배 길게, 청구서상으로는 1.8~1.9 배 길게 만들었다. 눈에 보이는 추가 분량은 규칙이 요구한 플래그, 표준, 제한 사항 섹션이었다. 품질 시스템에서 가치 있는 부분은 바로 이것이다.
• 회사 규칙을 적용했을 때, 과금된 출력의 3 분의 1 이상이 보이지 않았다. 과금된 출력 토큰의 37% 가 사고(thinking) 토큰이었으며, 단순 프롬프트에서는 16% 였다. 영어의 경우 독자는 447 토큰을 보지만 711 토큰에 대해 지불한다.
• 스페인어는 단어 수 기준 길이 차이가 4% 이내인 답변에 대해 영어보다 가시 토큰이 1.2 배 들었다. 같은 방식으로 측정했을 때, 회사 규칙을 스페인어로 작성하면 입력 토큰이 1.53 배 증가했다.
• 동일한 판정에 대해 317 토큰에서 953 토큰까지 과금되었다. 가장 긴 답변이 가장 짧은 답변의 3 배였다. 토큰 단위 과금은 엄밀함과 군더더기를 구분하지 못한다. 합격 기준(acceptance criteria) 은 구분할 수 있다.
이 비율은 5 회씩 묶인 배치 사이에서 움직인다. 회사 규칙의 화면상 비율은 첫 번째 배치에서 1.43~1.52, 두 번째에서 1.27~1.31 이었다. 과금 비율은 1.78~1.82, 그다음 1.70~2.05 였다. 스페인어 비율은 1.29~1.38, 그다음 1.14~1.18 이었다. 방향은 결코 바뀌지 않았다. 크기는 유효숫자 한 자리 수준에서 신뢰할 만하다.
방법: 2026-09-30 에 Claude Code 2.1.286, 2026-10-01 에 2.1.287 사용, claude -p --output-format json, Claude Sonnet 5.5. 모든 도구를 금지하고 개인 ~/.claude 파일을 제외하여 조건 간에 명시된 지침만 다르도록 했다. 토큰 수는 thinking_tokens 를 포함한 Claude Code 자체의 사용량 보고서 기준이며, 월 비용은 과금된 평균값에 Sonnet 5.5 의 출력 토큰 백만 개당 $10 를 적용했다. 측정 스크립트, 두 배치 모두, 취합 수치, 모든 답변은 저자가 보관하고 있으며 요청 시 제공한다. 이 글의 첫 번째 버전은 서브에이전트와 공개 토크나이저로 이 수치를 추정했으나, 해당 추정치는 이제 대체되었다.
3.4 규칙이 충돌할 때, 문구가 결정한다
Anthropic 의 문서는 모순되는 지침이 "임의로" 해결될 수 있음을 인정한다. 나는 라인 레이어가 없을 때 발생하는 종류의 충돌 하나를 테스트했다. 조직 규칙은 미국 관용 단위를 사용하라고 했고, 프로젝트 규칙은 SI 단위로 밀도를 보고하라고 했다. 트리가 있다면 있을 위치에 배치했다. 조직 규칙은 저장소 루트의 CLAUDE.md 에, 프로젝트 규칙은 프로젝트 폴더의 CLAUDE.md 에 두고, 둘 다 Claude Code 자체의 캐스케이드로 로드했다. 그런 다음 조직 규칙을 텍스트만으로 강제(enforced) 처리한 동일한 설정을 실행했다. 레이블에 ENFORCED 태그를 넣고 "이 규칙은 강제됩니다: 어떤 라인이나 프로젝트 규칙도 이를 재정의할 수 없습니다."라는 문장 하나를 추가했다. 각 설정은 9 월 30 일에 10 회, 10 월 1 일에 10 회씩 실행했다.
임의적이지 않았다. 아무것도 선언되지 않았을 때, Claude 는 매번 더 가깝고 구체적인 규칙을 택했다. 20 개 답변 중 14 개가 이유를 설명했다("해당 규칙이 회사 전체의 미국 관용 단위 규칙보다 더 구체적입니다" 또는 프로젝트 규칙이 회사 규칙을 재정의한다는 식). 5 개는 프로젝트 규칙만 인용하고 회사 규칙이 상충한다는 사실은 언급조차 하지 않았다. 텍스트로 강제성을 선언했을 때는 조직 규칙이 매번 승리했고, 모든 답변이 강제된 회사 규칙이 우선한다고 밝혔다. 두 번째 배치는 매번 10 회 중 10 회 동일한 단위를 재현했으며, 두 행 간의 차이는 우연으로 설명할 수 있는 수준을 훨씬 넘어섰다(Fisher 의 정확 검정, p < 0.0001). 설명의 일관성은 다소 떨어졌다. 첫 번째 배치에서는 10 개 중 9 개가 프로젝트 규칙이 승리한 이유를 밝혔지만, 두 번째 배치에서는 10 개 중 5 개만 밝혔다.
이는 모델에게는 좋은 소식이지만 워크스페이스에는 나쁜 소식입니다. 우선순위는 존재하지만, 그것은 규칙의 문구 속에 살아 있으며, 어떤 레이어든 편집하는 사람이라면 누구나 바꿀 수 있고 아무도 이를 우선순위 결정으로 검토하지 않습니다. 그리고 하위 규칙이 이겼을 때, 답변의 4 분의 1 은 상위 규칙이 배제되었다는 사실을 사용자에게 알려주지 않았습니다. 이 글의 첫 번째 버전에서 진행한 파일럿 테스트에서는 캐스케이드 대신 두 규칙을 하나의 프롬프트에 넣었는데, 순서만 바꿔도 결과가 달라졌습니다(조직 규칙이 먼저일 때: 5 개 중 5 개 SI; 조직 규칙이 마지막일 때: 5 개 중 2 개 SI, 그리고 5 개 중 3 개는 두 단위 모두를 제시하거나 어느 것이 적용되는지 되물었습니다).
조직이 규칙을 작성할 때 잡아낼 수 있었던 충돌을 모델에게 조정하라고 요구해서는 안 됩니다. Claude Code 에는 두 가지 부분적인 해답이 있습니다. /doctor prompt-audit 는 사용자가 직접 실행할 때 Claude 에게 서로 모순되는 지시 파일이 있는지 찾도록 요청합니다. 그리고 10 월 1 일부터는 mod 가 코드 내에서 순서를 강제할 수 있게 되었습니다. 조직의 mod 가 개인의 mod 보다 먼저 실행되고, 내장 가드가 로드되는 곳에서는 deny 규칙이 개인의 mod 를 이깁니다. 하지만 둘 다 지시 텍스트는 다루지 못합니다. 지시 파일은 여전히 하나로 이어 붙여지며, 문서는 그 결과를 세 가지 방식으로 설명합니다. Claude 가 "임의로 하나를 선택할 수 있다", 사용자 규칙과 프로젝트 규칙이 충돌할 때 "Claude 가 둘 중 하나를 따를 수 있다", 그리고 "지시가 충돌하면 Claude 가 판단력을 발휘해 조율한다"는 식입니다. 20 번 중 20 번 나온 결과가 바로 여기서 그 판단력이 어떻게 작동했는지를 보여줍니다. Claude Tag 는 세 가지 스코프에 대한 순서를 선언하지만, 그 결과를 "강제된 가드레일이 아닌 지침"이라고 부릅니다. 레퍼런스 구현의 검사는 무엇이든 Claude 에 도달하기 전에 정확히 이런 변경("R-22 sets units.density=SI; R-01 (org:firm) enforces US")을 거부하며, enforced 는 규칙 내부의 문장이 아니라 규칙의 필드입니다.
지시 밀도는 상황을 더 악화시킵니다. IFScale 벤치마크(2025)에서 Claude Sonnet 4 의 정확도는 동시 지시 10 개일 때 100% 에서 500 개일 때 42.9% 로 떨어졌습니다.
3.5 컴퓨팅이나 에너지가 더 공정한 단위가 될까?
토큰은 단일 모델 내에서 컴퓨팅을 나타내는 합리적인 대리 지표입니다. 토큰이 많을수록 하드웨어가 실제로 더 많은 일을 하기 때문입니다. 이것이 바로 컴퓨팅 또는 에너지 기반 가격이 언어 페널티를 해결하지 못하는 이유이기도 합니다. 스페인어 비용이 더 높은 것은 토크나이저가 이를 덜 압축하기 때문이며, 그 추가 토큰은 실제 컴퓨팅입니다. 이를 해결하려면 더 나은 토크나이저나 콘텐츠 기준으로 정규화된 과금 체계가 필요합니다.
정규화된 컴퓨팅 단위는 여전히 세 가지 면에서 도움이 됩니다. 서로 다른 모델과 벤더를 비교 가능하게 만듭니다. 물리적이고 보고 가능한 지표이므로, 예를 들어 지속가능성 보고서에 활용할 수 있습니다. 그리고 계수를 레퍼런스 하드웨어 기준으로 고정하면 벤더가 자체 효율 개선분을 그대로 가져갈 수 있어 올바른 인센티브가 됩니다. 선례도 있습니다. 클라우드 제공업체들은 한때 EC2 Compute Unit 같은 정규화 단위를 판매했습니다.
하지만 현실적인 문제도 있습니다. 고객은 표준과 감사인이 없으면 이를 검증할 수 없습니다. 실제 에너지는 하드웨어, 데이터센터 효율, 배치 처리, 전력망에 따라 달라집니다. 게다가 Anthropic 은 요청당 에너지를 공개하지 않으며, 저는 서드파티 추정치만 찾을 수 있었습니다. 가장 중요한 것은 컴퓨팅이 여전히 입력(input)이라는 점입니다. 답변이 맞았는지 여부는 말해주지 않습니다.
제 결론은 세 가지 별도 레이어로 나누는 것입니다.
- 토큰 또는 정규화된 컴퓨팅 단위로 청구합니다.
- 작업당 및 노드당 에너지를 공개합니다.
- 검증된 결과당 비용으로 관리합니다.
Team 의 경우 최소한의 조치는 명시된 단위로 주간 한도를 공개하는 것입니다. 세션당 허용량은 "Pro 플랜 세션당 사용 허용량의 1.25 배"로 안내되지만, 주간 한도는 아예 공개된 수치가 없습니다. 둘 다 예산을 세울 수 없습니다.
FinOps Foundation 의 표현처럼 "토큰은 과금 단위이지 가치 단위가 아닙니다." 가치를 정의할 수 있게 만드는 것은 위계이며, 이는 수용 기준이 자리 잡을 수 있는 곳이기 때문입니다.
3.6 아직 구축되지 않았을 가능성이 더 높은 이유들
- 암묵적 우선순위. Anthropic 의 공식 문서조차 직접적으로 모순되는 지시가 다양한 동작을 낳을 수 있음을 인정하며, 3.4 절은 우선순위가 규칙의 문구에 따라 결정됨을 보여줍니다. 레이어를 쌓을수록 충돌은 곱절로 늘어나고, 지시 따르기 성능은 밀도가 높아질수록 저하됩니다. IFScale 벤치마크(2025)에서 테스트된 최고 모델조차 동시 키워드 지시 500 개에서 정확도 68% 에 그쳤습니다(3.4 절에서 인용한 벤치마크).
- 권한 상속. 지식이 트리 아래로 상속된다면 접근 권한도 상속되어야 합니다. 이는 모든 레이어 아래에서 권한 모델을 다시 구축해야 함을 의미합니다.
- 정적 레이어보다 메모리와 검색(retrieval)을 선호하는 기조.
- 소비자 중심의 단순성. 코드 도구는 파일 시스템으로부터 트리를 공짜로 상속받습니다. 반면 채팅 제품은 이를 새로 만들어내야 합니다.
Anthropic 은 Claude 채팅과 Cowork 에 왜 위계가 없는지 공개적으로 밝히지 않았습니다. 이 절의 모든 내용은 출시된 기능으로부터 추론한 것입니다.
4. 레퍼런스 모델
이 설계는 이미 이 문제를 해결한 시스템들에서 차용했습니다. 클라우드 리소스 위계(AWS Organizations, Google Cloud Org Policy, Azure 관리 그룹), 디렉터리 정책(Active Directory Group Policy), 그리고 Claude Code 자체의 CLAUDE.md 캐스케이드입니다. 노드 간의 관계는 다섯 가지 단어로 표현됩니다. contains, inherits, uses, sealed, shared.
4.1 조직이 이미 가진 트리를 마운트하라
사람들에게 AI 워크스페이스 안에서 조직 구조를 다시 만들라고 요구하지 마십시오. 파일 서버나 문서 시스템이 이미 단일 진실 공급원(source of truth)입니다. 하나의 경로를 취하십시오.
작업 번호 26GT301 은 이미 연도, 업무 라인, 순번이라는 트리 구조를 인코딩하고 있습니다. 워크스페이스는 이 구조를 복사하는 것이 아니라 마운트해야 합니다.
4.2 규칙 보유 노드, 그룹화 노드, 프로젝트 및 작업
• 규칙 보유 노드: 조직, 업무 라인, 프로젝트, 작업. 각각 동일한 세 가지를 담고 있습니다. context(지시와 지식), policy(허용되는 도구, 데이터, 커넥터), 그리고 identities(이에 바인딩된 커넥터 계정).
• 그룹화 노드: 시리즈, 연도, 지역. 이들은 규칙을 갖지 않습니다. 탐색, 보존, 라이프사이클을 위해 존재합니다. 이를 분리하면 Microsoft 의 관리 그룹 가이드라인이 권장하듯("3~4 단계 이하") 규칙 트리를 3~4 단계로 얕게 유지할 수 있습니다.
• 프로젝트는 키가 지정된 컨테이너입니다. 자동으로 생성됩니다. 라인의 키 패턴과 일치하는 폴더(예: 라인 루트 아래의 {YY}GT{NNN}_{Name})가 나타나면 프로젝트 노드가 생성되어 해당 라인으로부터 상속받고, 오직 그 폴더로만 범위가 제한된 커넥터 접근 권한을 얻습니다. 프로젝트는 라인에서 벗어난 것, 즉 멤버, 클라이언트, 사양만 보관합니다. 그리고 열림(open)에서 닫힘(closed), 보관(archived)으로 이동합니다(다이어그램 2).
• 작업에는 타입이 있습니다. 타입은 라인의 카탈로그(밀도 보고서, 시추 로그 등)에서 옵니다. 타입은 템플릿과 수용 기준을 함께 운반합니다. 산출물은 회사의 명명 규칙에 따라 프로젝트 폴더로 다시 저장되며, 검토자가 이를 승인합니다. 스킬(Skills)은 오늘날 Claude 가 가진 것 중 작업 타입에 가장 가까운 개념입니다. Enterprise 에서는 그룹과 공유할 수 있지만, 이는 배포(distribution)이지 상속(inheritance)이 아닙니다. 브랜치를 따라 흘러 내려가는 것은 없습니다.
이 재귀는 의도된 것입니다. Stafford Beer 의 생존 시스템 모델(Viable System Model)은 이를 명확히 말합니다. "재귀적 조직 구조에서 모든 생존 시스템은 생존 시스템을 포함하며, 동시에 생존 시스템에 포함된다."
4.3 하나의 주 부모와 오버레이
Christopher Alexander 는 1965 년에 "도시는 트리가 아니다"라고 주장했습니다. 실제 구조는 겹칩니다. 클라이언트, 에이전시의 사양, 작업 타입은 여러 업무 라인에 걸쳐 있을 수 있습니다. 따라서 모든 노드는 하나의 주 부모(primary parent)를 가지며, 횡단적인 규칙 세트는 오버레이(uses)로 부착됩니다. 충돌은 매번 동일한 방식으로 해결됩니다. deny 가 이기며, 그렇지 않으면 가장 가까운 노드가 이깁니다.
4.4 두 개의 채널, 두 개의 의미론
이것이 설계의 핵심이며, 대부분의 위계가 잘못되는 지점입니다.
• Context 는 이어 붙여집니다. 지시와 지식은 CLAUDE.md 가 그러하듯 루트부터 아래로 병합됩니다.
• Policy 는 기본적으로 거부(deny-by-default)입니다. 도구 또는 커넥터는 루트부터 이어지는 전체 경로에 allow 가 존재할 때만 허용되며, 상위의 어느 곳에서든 명시적 deny 가 있으면 그것이 이깁니다. AWS Service Control Policies 와 같은 방식입니다. 부모는 규칙을 enforced 로 표시할 수 있으며, Group Policy 처럼 어떤 자식도 이를 막을 수 없습니다.
둘을 섞는 것이 전형적인 실수입니다. 권고 성격의 context 는 섞여야 하지만, 강제성은 섞이면 안 됩니다.
4.5 모델이 읽기 전에 컴파일하라
오늘날 충돌하는 지시는 응답 시점에 모델이 해결합니다. 해결책은 모델이 아무것도 보기 전에 실행되는 유효 지시 컴파일러(effective-instructions compiler) 입니다.
- 루트부터 리프까지 context 를 병합합니다.
- policy 를 적용합니다. deny 가 이기며, allow 는 전체 경로에서 유효해야 합니다.
- 부모의 enforced 규칙을 존중합니다.
- 모든 규칙에 ID 와 해당 레이어를 스탬프로 찍습니다.
- 각 부분이 얼마나 널리 공유되는지에 따라 블록을 정렬하고, 레이어별로 토큰 예산을 적용합니다.
충돌은 이 단계에 절대 도달하지 않습니다. 규칙이 작성되는 시점에 미리 거부되며, 승인은 작성자가 아닌 다른 사람이 수행합니다(다이어그램 3, 하단 레인).
충돌이 컴파일 시점에 해결되므로, 산출물은 깊이가 아니라 각 부분이 얼마나 널리 공유되는지에 따라 정렬될 수 있습니다. 조직, 라인, 작업 타입 템플릿, 그리고 프로젝트 세부 사항 순입니다. 이 순서가 캐시 적중률을 극대화합니다(3.2 절). 이는 레이어별 토큰 예산과 함께 Anthropic 의 네 가지 캐시 중단점(cache breakpoint)에 대응되며, 다만 실무에서는 대화 자체를 위해 하나의 중단점이 필요할 수 있습니다.
4.6 사람이 아닌 브랜치에 바인딩된 신원
커넥터 신원(계정, 테넌트, 스코프)은 사람이 아닌 노드에 부착됩니다. Claude Tag 는 이미 Slack 채널에서 이렇게 작동합니다. 관리자가 서비스 계정을 스코프에 부착하고, 가장 좁은 스코프의 자격 증명이 우선합니다. 여기서 제안하는 모델은 이를 한 단계 아래, 즉 업무 라인과 그 프로젝트들에서 동일하게 요구합니다. 두 조직에서 일하는 사람은 두 개의 sealed 트리를 가지며, 계정이 아닌 트리를 전환합니다. 양쪽 소유자가 명시적으로 공유하지 않는 한 아무것도 두 트리 사이를 넘나들지 않습니다. 기술적 원형은 이미 존재합니다. MCP 인증 규격은 audience-bound OAuth 토큰(RFC 8707 resource indicators, RFC 9728 protected resource metadata)을 사용하며, 서버가 "다른 어떤 토큰도 수락하거나 전달해서는 안 된다(MUST NOT)"고 요구합니다(규격 버전 2026-07-28).
4.7 권한은 트리를 따른다
주체(Principals): 사람, 그룹, 서비스 계정, 외부 게스트(예: 클라이언트), 그리고 에이전트 자체.
에이전트는 사람이나 노드의 권한을 결코 초과하지 않습니다. Claude 는 호출한 사용자의 권한과 노드의 policy 가 교차하는 범위 내에서 행동합니다. 규칙이나 권한을 변경할 수 없으며, 변경을 제안만 할 수 있습니다. (오늘날 Claude 는 Cowork 폴더 지시를 스스로 업데이트할 수 있습니다. 이 모델에서는 누군가 승인해야 하는 제안이 됩니다.)
평가(Evaluation). 권한 부여(grant)는 아래로만 흐르고, 위나 옆으로는 흐르지 않습니다. 노드에서의 유효 권한은 해당 경로의 역할들이 부여한 것 중 전체 경로에서 policy 가 허용하는 범위 안에 있으며, 상위의 deny 를 뺀 것입니다. 오버레이는 자신의 콘텐츠에 대한 접근만 부여합니다. 사양을 읽는다고 해서 그것을 사용하는 프로젝트가 열리는 것은 아닙니다.
라이프사이클.
• Open: 역할이 부여된 대로 적용됩니다.
• Closed: 새 작업은 불가하지만, 대기 중인 검토는 완료할 수 있습니다.
• Archived: 모두에게 읽기 전용이며, 소유자만 복원할 수 있고 복원은 기록됩니다.
• Sealed tree: 명시적 공유 없이는 아무것도 넘어가지 않습니다.
예외 및 위임. 예외는 기간이 제한되고 사유가 있어야 하며, 요청자가 아닌 다른 사람이 승인합니다. 스스로 만료되고 집계되는데, 모든 재정의(override)는 영구적인 유지보수의 섬이 되기 때문입니다. SharePoint 의 깨진 상속 한도가 그 경고 사례입니다. 위임은 위임자가 가진 것 이상을 결코 부여할 수 없습니다. 소유자의 긴급 접근(break-glass) 권한은 존재하며 항상 기록되고 사후 검토됩니다.
Team 에서 이 방식은 그룹 없이도 작동합니다. 권한 부여가 노드에 존재하므로, 네 가지 역할을 가진 조직이라도 브랜치별 권한을 얻을 수 있습니다.
4.8 레이어는 어떻게 상호작용하는가
변경 사항이 트리를 통과하지 못한다면 트리를 구축할 가치가 없습니다. 대부분의 작업을 수행하는 세 가지 상호작용이 있습니다(다이어그램 5).
• 아래로 밀기(Push down). 라인 책임자가 규칙의 새 버전을 게시합니다. 해당 라인의 모든 프로젝트는 다음 컴파일 시 이를 읽습니다. 승인된 예외는 만료될 때까지 이전 버전을 유지하고, 이미 저장된 산출물은 생성 당시의 버전을 유지합니다.
• 위로 끌어올리기(Pull up). 멤버가 한 프로젝트 내에서 템플릿을 개선하고 제안합니다. 제안자가 아닌 라인 책임자가 이를 승인하면, 형제 프로젝트들이 이를 상속합니다. 오늘날 그러한 개선은 발생한 프로젝트 안에만 머뭅니다.
• 가로로(Across). 에이전시 사양이 한 번 변경됩니다. 세 개 라인의 프로젝트들이 이를 반영해 재컴파일되며, 라인 자체는 변하지 않습니다. 라인 규칙과의 충돌은 업데이트가 작성되는 시점에 거부됩니다.
하나의 요청이 모든 레이어를 한 번에 보여줍니다(다이어그램 6). 트리는 멤버의 권한 부여와 프로젝트 상태를 확인하고, 컴파일러가 블록을 구축하며, Claude 는 해당 프로젝트 폴더로 범위가 제한된 신원을 통해 필드 데이터를 읽고, 타입이 지정된 산출물을 폴더에 다시 저장하며, 작성하지 않은 검토자가 이를 승인합니다. 모든 단계는 로그에 남고, 비용은 프로젝트 키로 청구됩니다.
4.9 데이터 구조
프로비저닝은 이벤트 기반입니다. 라인의 storage_root 아래에서 key_pattern 과 일치하는 새 폴더가 생성되면 프로젝트 노드가 만들어집니다. answer_log 는 모든 응답에 대한 출처와 노드별 비용을 제공합니다.
4.10 토큰이 아닌 결과를 측정하라
각 작업 타입은 수용 기준(acceptance criteria), 즉 완료의 정의를 갖습니다. 이것이 마련되면 AI 작업의 더 나은 단위를 측정할 수 있습니다.
검증된 결과당 비용 = (토큰 비용 + 검토 시간) ÷ 승인된 산출물
모든 응답이 노드에 기록되므로, AI 비용은 인건비나 자재비와 같은 방식으로 프로젝트 키에 청구될 수 있습니다. 일부 요소는 이미 존재합니다. Claude Tag 는 채널당 지출을 보고하고 제한하며, Claude Code 의 텔레메트리는 수동으로 부서, 비용 센터, 리포지토리별로 태그할 수 있습니다. 하지만 어느 것도 프로젝트에 키로 연결되지 않으며, 승인된 산출물로 나누지도 않습니다. 작업 번호로 청구하는 회사라면 AI 는 간접비가 아닌 직접 작업 비용이 됩니다. 엔지니어링에서는 연필심이 아니라 점검되고 봉인된 산출물에 돈을 지불합니다. AI 작업도 같은 방식으로 측정되어야 합니다.
4.11 반론에 대한 답변
"스킬과 플러그인이 이미 이 역할을 한다." 스킬은 Claude 가 관련 있다고 판단할 때 로드되는데, 이는 연관성이지 보장이 아닙니다. 프로비저닝은 모든 사람에게 스킬을 부여하며, Enterprise 에서는 이를 담은 플러그인을 특정 그룹에 필수로 지정할 수 있습니다. 이것이 오늘날 채팅과 Cowork 에서 업무 라인에 가장 가까운 개념이지만, 세 가지 면에서 부족합니다. Enterprise 전용이고, 프로젝트가 아닌 사람을 대상으로 하며, 라인에서 프로젝트로 흘러 내려가는 것이 없습니다. 특정 라인에서 반드시 항상 적용되어야 하는 규칙은 연관성 감지에 의존할 수 없습니다.
"Mod 가 이미 이 역할을 한다." 2026 년 10 월 1 일부터 Claude Code 에서는 부분적으로 그렇습니다. mod 는 시스템 프롬프트를 재작성하고, 도구 호출을 거부하고, 패널을 그릴 수 있으며, 조직의 mod 가 개인의 mod 보다 먼저 실행됩니다. 따라서 이 글의 컴파일러, 작성 시점 검사, 유효 지시 뷰는 오늘 당장 mod 로 구축할 수 있으며, 6 절에서도 그렇게 언급합니다. 하지만 세 가지 한계가 남습니다. mod 는 Claude 채팅에서 실행되지 않으며, Cowork 에서는 조직의 콘솔 설정이 적용되지 않습니다. 그 순서에는 조직과 개인이라는 두 소유자가 있고 그 사이에 업무 라인이 없습니다. Enterprise 에서는 특정 그룹에 필수인 플러그인이 mod 를 해당 그룹으로 전달할 수 있지만, 이는 개인의 mod 중 하나로 실행되며 우선순위가 없습니다. 또한 mod 는 샌드박스되지 않은 코드입니다. 사람들의 mod 보다 먼저 실행되려면 조직의 mod 가 각 기기의 디렉터리에 있어야 하는데, 관리자 콘솔에서 전달되는 설정은 "기기에 디렉터리를 배치할 수 없습니다". 기기 관리 체계가 없는 회사도 모두에게 mod 를 푸시할 수 있지만, 이는 사람들의 mod 사이에서 실행될 뿐 그보다 앞서 실행되지는 않습니다. 어느 부서가 다른 단위로 보고한다는 것을 알리기 위해 회사가 TypeScript 를 작성해야 할 필요는 없습니다.
"메모리가 규칙을 학습할 것이다." 메모리는 주로 Claude 가 한 사람 또는 한 프로젝트를 위해 작성하며, 소유자는 멤버의 메모리를 읽거나 편집할 수 없습니다. 감사인에게는 사람이 작성하고, 버전 관리되고, 승인되었으며, 각 응답으로 추적 가능한 규칙이 필요합니다. Anthropic 은 이미 세 번 이를 구축했습니다. 권한의 경우 "View effective role"과 그 "Granted by" 레이블로, 스킬과 플러그인의 경우 버전 기록과 "자기 것을 승인할 수 없는" 검토 단계로, Claude Tag 접근의 경우 "Inherited from" 레이블로 구축했습니다. 프로젝트 내 지시에는 이 세 가지가 모두 없습니다.
"Claude Tag 가 이미 이 역할을 한다." Slack 채널에 대해서는 대체로 그렇고, 1 절에서도 언급했습니다. 하지만 세 가지가 여전히 부족합니다. 채널은 프로젝트가 아닙니다. 폴더도, 키도, 라이프사이클도 없으며 "채널을 프로젝트로 지정할 수는 없습니다". 트리는 세 개의 고정된 레벨이므로, 업무 라인과 수백 개의 작업을 가진 회사는 두 레벨을 채널 이름으로 평탄화해야 합니다. 또한 문서는 지시가 작성될 때 충돌을 검사하는 절차를 설명하지 않습니다. 스코프는 이어 붙여지고 모델이 이를 조율하도록 방치됩니다. 오히려 Claude Tag 는 이 글의 설계를 뒷받침하는 가장 강력한 증거입니다. 같은 회사가 팀용으로 구축할 때 상속, 스코프 바인딩 자격 증명, 출처 레이블을 선택했기 때문입니다.
"위계는 복잡성을 더한다." 깊이가 무제한일 때만 그렇습니다. Microsoft 의 관리 그룹 가이드라인 자체가 "3~4 단계 이하"입니다. 이 모델은 규칙을 갖는 네 단계를 고정하고, 시리즈나 연도 같은 그룹화 폴더에는 규칙을 전혀 두지 않습니다.
"상속은 보안 위험이다." 접근 권한을 무심코 상속한다면 그렇습니다. 클라우드의 해법이 적용됩니다. 모든 레벨에 allow 가 존재해야 하고, 어디든 deny 가 있으면 이기며, Claude 는 사용자와 노드의 교집합으로 행동하고, Claude 자체의 규칙 편집은 제안이 됩니다.
"레이어가 많아지면 토큰 비용이 늘어난다." 3.2 절은 Claude Code 에서 그 반대임을 측정했습니다. 평면 복사본 대비 캐스케이드일 때 지시 토큰이 20%, 컴파일했을 때 34% 줄었습니다. 추가되는 파일마다 약간의 오버헤드가 생기므로 컴파일이 캐스케이딩보다 낫습니다. 타입이 지정된 작업은 사용하지 않는 템플릿을 제외하고, 컴파일된 접두사는 프로젝트 간에 바이트 단위로 동일하므로 프롬프트 캐싱이 이를 재사용할 수 있습니다. Claude API 에서 캐시는 워크스페이스별로 격리되므로, 조직당 하나의 워크스페이스가 트리의 루트에 대응됩니다. Claude Code 는 현재 이를 지원하지 않습니다. 캐시가 하나의 기기와 디렉터리로만 범위가 제한되기 때문입니다.
"팀이 각자의 프로젝트를 직접 유지보수하면 된다." 그것이 오늘의 우회책이며, 5 절의 프로토타입은 그것이 무엇을 낳는지 측정했습니다. 작은 데모에서도 붙여넣기된 복사본 6 개 중 2 개가 구식이었습니다.
5. 오늘 바로 실행된다: 레퍼런스 구현
이 모델이 단지 논쟁거리가 아니라 실제로 구축 가능함을 보여주기 위해, 저는 Worktree 라는 작은 데스크톱 앱(Node 및 Electron, Windows 와 Linux 에서 24 개 테스트 통과)을 만들었으며, 레이아웃은 Claude Desktop 과 유사합니다. 위 영상은 실제 실행 화면이며, Claude 가 작업 중이던 부분만 짧게 편집했습니다. 이는 mod 가 아니라 외부에서 Claude Code 를 구동하는 별도의 앱입니다. 자체적으로 모델을 호출하지 않습니다. 모든 채팅은 컴퓨터에 이미 설치된 Claude Code(claude -p)를 실행하며, Claude Code 가 가진 로그인 상태(Claude 구독 또는 API 키)를 그대로 사용합니다. 저는 세 개의 업무 라인과 여섯 개의 프로젝트를 가진 가상의 회사에서 이를 실행했습니다. 누군가 메시지를 보내면 다음과 같이 작동합니다.
• Permit. 행동하는 사람은 프로젝트 또는 그 상위에 권한 부여(grant)가 있어야 하며, 프로젝트는 open 상태여야 합니다. 라인에 권한이 없는 관리자는 Claude 가 시작되기 전에 차단되었습니다.
• Check. 작성 시점 검사가 먼저 실행됩니다. 3.4 절의 SI 규칙은 강제된 회사 규칙과의 충돌로 거부되어 CLAUDE.md 에 절대 도달하지 않습니다.
• Mount. 트리는 실제 프로젝트 폴더에 레벨당 하나의 CLAUDE.md 로 기록되고(스토리지 루트의 조직, 그다음 라인, 그다음 프로젝트), Claude Code 자체의 캐스케이드가 이를 로드합니다. 컴파일 모드는 대신 프로젝트당 하나의 파일을 작성합니다. 앱의 마커가 없는 파일은 절대 덮어쓰지 않습니다.
• Run. 작업 템플릿은 --append-system-prompt-file 로 들어갑니다. Claude 가 할 수 있는 일은 CLAUDE.md 가 아니라 Claude Code 가 강제합니다. --allowedTools 는 사람의 역할과 모든 레벨의 policy 가 교차한 것이며, 쓰기는 프로젝트 폴더로 제한되고, --permission-mode dontAsk 는 나머지 모든 것을 거부합니다. 실제 실행에서 웹 검색은 라인의 policy 가 web 을 허용하지 않아 거부되었고, 프로젝트 폴더 밖의 쓰기는 차단되어 기록되었습니다.
• Log and review. 모든 응답은 사람, 노드, 모든 규칙 태그, Claude 가 인용한 규칙, 그리고 Claude Code 가 보고한 입력·캐시·출력 토큰과 함께 기록됩니다. 답변을 작성하지 않은 검토자가 이를 승인하거나 반려합니다. 데모에서 실제 밀도 보고서 실행은 약 30 초가 걸렸고, 세 번의 실행에서 Claude Code 는 정가 기준 응답당 $0.08~0.22 를 보고했습니다. Claude 는 적용한 규칙을 인용하고, 수용 한계에 가까운 결과에 플래그를 달았으며, 엔지니어 입력란은 비워두었습니다.
• Drift. 마운트된 모든 CLAUDE.md 는 트리와 비교되며 수동 편집에는 플래그가 지정됩니다. 이전 명령줄 프로토타입은 평면 프로젝트에 붙여넣기된 복사본에서 동일한 비교를 실행하여 6 개 중 2 개가 구식임을 발견했습니다. 하나는 여전히 R-07 v3 에 머물러 있었고, 다른 하나는 규칙이 수동으로 삭제되어 있었습니다.
이를 구축하며 얻은 세 가지 발견은, Claude Code 위에 지시를 레이어로 쌓으려는 모든 사람에게 유의미합니다.
- 개인 지시가 조직의 실행으로 유출됩니다. 기본적으로 모든 실행은 제 개인 ~/.claude/CLAUDE.md, 규칙, 에이전트, MCP 서버도 함께 로드했습니다. 앱은 이제 claudeMdExcludes 설정과 --strict-mcp-config 로 이를 제외합니다. 제 기기에서는 실행 context 가 29.6k 토큰에서 21.4k 토큰으로 줄었습니다. 당연한 대안인 --setting-sources project,local 은 Windows 의 Claude Code 2.1.284 에서 필요한 것과 정반대로 작동했습니다. 개인 파일은 유지하면서 조직과 라인을 담고 있는 상위 폴더의 CLAUDE.md 파일들을 제거해 버렸습니다.
- 개인의 mod 도 유출됩니다. Mod 는 앱이 완성된 다음 날 도입되었기에 테스트해 보았습니다. 저는 제 사용자 스코프에 모든 프롬프트에 한 줄을 추가하는 단일 훅 mod 를 설치했습니다. 이는 앱의 실행에도 도달했습니다. 조직의 세 규칙이 로드되었고 제 개인 줄도 로드되었으며, 응답은 이를 따랐습니다. 실행 설정에 disableAllHooks 를 추가하니 이것이 차단되었고 세 레벨의 CLAUDE.md 는 온전히 남았습니다. 앱은 이제 이렇게 동작합니다. --safe-mode 는 대체재가 아닙니다. mod 와 함께 CLAUDE.md 캐스케이드 전체를 제거해 버립니다. 문서에 따르면 개인 설정의 disableAllHooks 는 조직이 관리하는 항목을 계속 실행되도록 둡니다.
- CLAUDE.md 는 context 이고, 강제성은 구성(configuration)입니다. Anthropic 문서도 이렇게 말합니다. "설정 규칙은 Claude 가 무엇을 결정하든 클라이언트가 강제합니다. CLAUDE.md 지시는 Claude 의 행동을 형성하지만 강력한 강제 레이어는 아닙니다." 앱은 이에 의존합니다. 규칙이 반드시 보장해야 하는 모든 것은 도구 권한에 매핑되고, CLAUDE.md 의 모든 것은 태그가 붙은 지침입니다.
이는 오늘날의 Claude Code 에서 작동하며, 컴파일된 텍스트는 어떤 플랜에서든 채팅이나 Cowork 프로젝트의 지시에 붙여넣을 수 있습니다. 한 가지 종속성은 기한이 정해져 있습니다. 앱은 claude -p 가 CLAUDE.md 파일을 로드하는 것에 의존하는데, Anthropic 문서는 이를 건너뛰는 --bare 가 "향후 릴리스에서 -p 의 기본값이 될 것"이라고 말합니다. 그것이 적용되면 앱은 다른 방식으로 트리를 전달해야 하지만, 컴파일 모드와 --append-system-prompt-file 은 이미 가능합니다. 이는 네이티브 버전을 위한 작동하는 규격이지 보안 경계가 아닙니다. "acting as"는 데모용 스위치이지 로그인이 아닙니다.
6. 이미 출시된 것에서 출발하는 경로
지금 당장 Claude Code 에서. 10 월 1 일부터 이 트리는 mod 로 배포될 수 있습니다. 노드의 규칙을 시스템 프롬프트의 한 섹션으로 컴파일하고, 노드 정책이 거부하는 도구 호출을 차단하며, 유효한 지침을 별도의 창에 표시할 수 있습니다. 조직은 개인이 설치하는 어떤 것보다 먼저 해당 mod 를 실행할 수 있습니다. 제가 직접 만든 것은 아니며, 이는 레퍼런스 구현 로드맵의 첫 번째 항목입니다. 이 기능은 Claude Code 를 지원하며, 같은 엔진에서 실행되는 사용자 기기의 Cowork 세션도 지원할 가능성이 있습니다. 다만 채팅은 지원하지 않습니다.
채팅과 Cowork 를 위한 30 일 버전. Anthropic 에는 이미 필요한 구성 요소가 있습니다. Slack 채널이 Claude Tag 의 워크스페이스 설정을 상속받듯, 프로젝트가 상위 프로젝트를 지정해 그 지침을 상속받도록 허용하면 됩니다. 두 가지를 순서대로 컴파일하고 모든 규칙에 태그를 붙인 뒤, 기존 "유효 역할 보기" 옆에 "유효 지침 보기" 패널을 추가하세요. 이것만으로도 모든 업무 영역이 규칙을 보관할 단일 공간을 갖게 됩니다.
그 이후의 각 단계는 Team 요금제에 도움이 되는 것부터 시작하여, 그 자체로도 유용합니다.
- 업무별 노드 및 키 패턴 프로비저닝: 이미 코드에서 작동하는 CLAUDE.md 시맨틱을 재사용합니다. Claude Code 자체에서 매칭 단계는 조직의 mod 와 개인의 mod 사이에 위치한 그룹용 계층이자, 그룹별 관리형 설정 역할을 합니다.
- 작업 유형: 승인 기준(acceptance criteria)을 갖추고 특정 업무 범위로 한정된 스킬로서의 역할입니다.
- 작성 시 충돌 검사: 모순된 내용은 모델이 중재하기 전에 트리 단계에서 거부됩니다.
- 노드 권한 부여: 그룹 없이도 Team 에서 작동하며 Enterprise 의 커스텀 역할을 확장합니다.
- 프로젝트용 브랜치 바인딩 커넥터 ID: Claude Tag 가 이미 서비스 계정을 Slack 채널에 바인딩하는 것과 같은 방식입니다.
- 노드별 과금: Claude Tag 가 이미 채널별로 보고하듯 프로젝트를 기준으로 적용되며, 명시된 단위로 주간 한도를 공개하고 작업별 에너지 사용량을 투명하게 공개합니다.
7. 제한 사항
• 커버리지. 2026 년 10 월 1 일에 code.claude.com/docs 및 claude.com/docs 의 전체 페이지 인덱스를 제목 기준으로 분류(466 페이지)했고, 여기에 인용된 헬프 센터 문서를 포함해 약 150 페이지를 읽었습니다. 이 글의 이전 버전은 Claude Tag 를 완전히 누락했으며, 이번 버전 역시 다른 무언가를 놓쳤을 수 있습니다. 정부 기관용 Claude 와 서드파티 제공업체의 Claude Desktop 은 언급만 했고 분석하지 않았습니다.
• 플랫폼 기능은 매월 변경되며, 이 글을 작성하는 동안에도 하나가 변경되었습니다. 여기에 나온 모든 제품 관련 주장은 2026 년 9 월 29 일~ 10 월 1 일 기준이므로, 의존하기 전에 반드시 다시 확인해야 합니다. Mods 는 출시 하루밖에 되지 않았습니다. 저는 문서를 읽고 한 가지 사례를 테스트했을 뿐, 실제 운영 환경에서 사용해 보지는 않았습니다.
• 3.1~3.4 절의 측정 수치는 Claude Code 자체의 사용량 보고서에서 가져왔으며 두 배치로 나뉩니다. 2026-09-30 의 Claude Code 2.1.286 과 2026-10-01 의 2.1.287 이며, 둘 다 Claude Sonnet 5.5 에서 실행했습니다. 스크립트, 두 배치 모두, 그리고 모든 답변은 작성자가 보관하고 있으며 요청 시 제공됩니다. 여기에는 claude.ai 와 Cowork 에는 없는 Claude Code 자체의 프롬프트(약 30,200 토큰)가 포함되며, 하나의 모델, 하나의 데모 프로젝트, 하나의 질문만을 대상으로 합니다. 샘플 크기가 작습니다. 답변 길이는 조건당 10 개, 충돌 테스트는 조건당 20 개입니다. 답변 길이 비율은 두 배치 사이에서 변동했습니다(3.3 절). 하루 차이로 수집된 두 배치는 Claude Code 버전도 다르기 때문에, 이를 우연의 결과와 분리해 낼 수 없습니다.
• 5 절의 실행 시간, 비용, 컨텍스트 크기는 세 번의 데모 실행과 한 번의 수동 격리 테스트에 대한 앱 자체의 답변 로그에서 가져온 것으로, 작성자의 기록입니다.
• 충돌 답변은 작성자가 블라인드 해제 상태에서 모든 답변을 읽고 코딩했습니다(단위 보고 여부, 어떤 규칙이 승리했는지와 그 이유를 답변이 명시했는지, 질문을 했는지 등). 40 개 전체는 재코딩을 위해 요청 시 제공됩니다. 테스트에는 "enforced"라는 하나의 표현만 사용되었으므로, 다른 표현이나 모델, 규칙 쌍에서는 다르게 동작할 수 있습니다.
• 5 절의 mod 테스트는 하나의 Linux 기기에서 하나의 훅을 가진 하나의 mod 를 Claude Haiku 로 실행한 것이며, 구독 계정으로 로그인했고 관리형 설정은 없었습니다. 조직의 정책 mod, Team 또는 Enterprise 로그인에 내장된 가드레일, 데스크톱 앱은 테스트하지 않았습니다.
• 3.2 절의 비용 모델은 예시로 든 기업의 시뮬레이션이며 실제 청구 금액을 측정한 것이 아닙니다. 지침 토큰만 다루고 있는데, 실제 청구서에서는 대화 기록, 출력, 추론(thinking) 토큰이 대부분을 차지합니다. 토큰 크기 계산에는 Anthropic 의 공개 레거시 토크나이저 × 1.30 을 사용했습니다. 측정 결과 Claude Code 는 이 추정치보다 21~26% 더 많이 로드했으므로, 달러 수치는 실제보다 낮게 표시됩니다. 백분율은 비율이므로 그대로 유효합니다. 세션 패턴과 캐시 공유는 가정입니다.
• Enterprise 의 채팅 사용량에 API 캐시 가격이 적용되는지, claude.ai 에서 캐시가 사용자 간에 공유되는지는 문서화되어 있지 않습니다. Cowork 는 세션을 Claude Code 위에서 실행하고 플러그인 훅도 그곳에서 로드되지만, mods 페이지에는 Cowork 가 나열되어 있지 않아 테스트하지 않았습니다. 10 월 1 일 기준 데스크톱 앱은 여전히 mods 가 활성화되기 한 버전 전인 Claude Code 2.1.286 을 번들로 제공하고 있었습니다. 기기의 관리형 정책은 조직이 완전한 VM 샌드박스에서 실행하지 않는 한 사용자 기기의 Cowork 세션까지 적용됩니다. 사용자의 ~/.claude 파일이 Cowork 에 도달하는지에 대해 두 페이지의 설명이 상충하므로, 이 글에서는 어느 쪽으로도 주장하지 않습니다. 또한 상위 폴더의 CLAUDE.md 파일이 Cowork 세션에서 로드되는지도 테스트하지 않았습니다. 만약 로드된다면, 레퍼런스 구현의 마운트된 트리는 오늘 당장 사용자 기기의 Cowork 에 도달할 수 있습니다. Pro 및 Max 요금제의 경우 새로운 Cowork 작업이 클라우드로 이동하는 2026 년 10 월 6 일에 이 기회는 좁아집니다.
• 동기는 추론한 것입니다. Anthropic 은 왜 Claude 채팅과 Cowork 가 평탄(flat) 구조인지 공개적으로 설명하지 않았습니다.
• 코드와 원시 데이터는 이 글과 함께 공개되지 않습니다. 독자는 글만으로는 측정을 재현할 수 없으며, 영상은 앱이 작동하는 모습만 보여줄 뿐 어떻게 구축되었는지는 보여주지 않습니다.
• 레퍼런스 구현은 가상의 기업을 대상으로 실행됩니다. claude.ai 나 Cowork 와 통합되어 있지 않으며, "acting as"는 데모용 토글이지 로그인이 아닙니다. 권한은 앱이 아니라 Claude Code 의 도구 목록에 의해 강제됩니다. 격리(isolation)는 실행 시 사용자의 훅과 mod 를 끄지만, Claude Code 에 내장된 mod 는 계속 실행되며 개인 에이전트의 이름이 여전히 컨텍스트에 나타날 수 있습니다. 이 앱은 claude -p 가 CLAUDE.md 를 로드하는 것에 의존하는데, Anthropic 은 이것이 곧 기본값에서 제외될 것이라고 밝혔습니다. 개인 파일 유출과 --setting-sources 결과는 Windows 에서 테스트했으며, 측정과 mod 테스트는 Linux 에서 진행했습니다.
출처
• Anthropic, 조직 지침 설정하기
• Anthropic, 역할 및 권한
• Anthropic, Team 요금제란 무엇인가요? · 요금제 및 가격
• Anthropic, Enterprise 요금제에서 커스텀 역할 관리하기
• Anthropic, Claude Cowork 에서 프로젝트로 작업 정리하기
• Anthropic, Google Workspace 커넥터 사용하기
• Anthropic, Enterprise 요금제에서 그룹 및 그룹 지출 한도 관리하기
• Anthropic, 프로젝트란 무엇인가요? (새로운 버전의 프로젝트, 베타)
• Anthropic, Claude Cowork 시작하기(전역 및 폴더 지침)
• Anthropic, Claude 가 프로젝트를 기억하는 방법(CLAUDE.md) · 모든 설정 (claudeMdExcludes, disableAllHooks)
• Anthropic, Mod 로 Claude Code 커스터마이징하기 (2026 년 10 월 1 일) · Mods 개요 · 조직을 위한 mod 관리 · Mod 로 이벤트에 반응하기 · Mods 레퍼런스
• Anthropic, Claude Tag: Claude Tag 란 무엇인가요? · 채널별 접근 권한 구성하기 · Claude Tag 커스터마이징하기 · 에이전트 ID 작동 방식 · 감사 · 지출 한도 설정하기
• Anthropic, Claude Code 의 프로젝트 (새 프로젝트 베타) · Cowork 의 프로젝트 · Claude Code 가 프롬프트 캐싱을 사용하는 방법 · 프로그래밍 방식으로 Claude Code 실행하기 (--bare) · Claude Code 확장하기 · 프로젝트 공개 범위 및 공유 관리 · 커넥터 사용하기 · 조직 전체에 MCP 커넥터 승인하기 · 스킬 프로비저닝 및 관리
• Anthropic, 서버 관리형 설정 구성하기 (그룹별 구성 없음) · 조직을 위한 플러그인 관리 (Enterprise 의 그룹별 플러그인 가용성) · 플랫폼별 플러그인 기능 지원 (채팅에서는 훅 무시, Cowork 에서는 로드) · 관리형 설정 배포 (Cowork 는 세션을 Claude Code 위에서 실행)
• Anthropic, 가격 책정 (Sonnet 5.5 요율, 토크나이저 참고) · 프롬프트 캐싱 (API 에서 조직별 및 워크스페이스별로 격리된 캐시)
• Anthropic, @anthropic-ai/tokenizer(카운팅에 사용된 공개 토크나이저)
• Microsoft, 관리 그룹 · 랜딩 존 관리 그룹 설계
• AWS, SCP 평가 · Google Cloud, 계층 평가
• Microsoft, 그룹 정책 처리 · SharePoint 세분화된 권한
• FinOps Foundation, 토큰 이코노미
• Jaroslawicz et al., LLM 은 한 번에 몇 개의 지침을 따를 수 있을까? (IFScale)
• Firefly, 2026 IaC 현황 리서치
• MCP, 인증 사양, 버전 2026-07-28
• GitHub, anthropics/claude-code 이슈 #68262, #14467, #30554, #27567, #30250, #27302, #47741
• Beer, S. (1979), The Heart of Enterprise; Alexander, C. (1965), “A City is Not a Tree,” Architectural Forum; Simon, H. (1962), “The Architecture of Complexity,” Proc. Am. Phil. Soc.106(6)
• 레퍼런스 구현 및 데이터: Worktree 앱, 테스트, 측정 스크립트, 두 결과 배치 및 모든 답변은 작성자가 보관하고 있으며 요청 시 제공됩니다.
