대부분의 팀이 에이전트 기반 코딩 (Agentic Coding)에 실패하는 이유는 에이전트의 성능이 부족해서가 아니라, 제어 (Control), 접근 (Access), 효율성 (Efficiency)을 하나의 통제 불가능한 계층으로 붕괴시키기 때문입니다. 이러한 아키텍처 부채 (Architecture Debt)는 빠르게 누적됩니다. 잘못 배치된 훅 (Hook)은 숨겨진 정책이 되고, MCP 서버는 워크플로우 엔진이 되며, 프록시 (Proxy)는 잘못된 컨텍스트 설계 (Context Design)를 가리게 됩니다. 이를 인지했을 때는 이미 기능을 출시하는 대신 기술 부채 (Technical Debt)를 관리하고 있는 상태가 됩니다.

혼돈 없는 에이전트 기반 코딩: Claude Code, MCP, 그리고 훅 기반 프록시를 위한 3계층 아키텍처

요약 (TL;DR): 팀이 통제 불가능한 혼란을 만들지 않고 에이전트 기반 코딩을 확장할 수 있도록 Claude Code, MCP, 그리고 훅 기반 프록시를 위한 실용적인 3계층 아키텍처를 제안합니다.

대부분의 팀이 실패하는 이유는 에이전트의 성능이 부족해서가 아닙니다. 제어 계층이 무엇을 담당해야 하는지, 접근 계층이 무엇을 담당해야 하는지, 그리고 효율성 계층이 무엇을 담당해야 하는지를 결정하지 않은 채 프롬프트 (Prompt), 훅 (Hook), 커넥터 (Connector), 프록시 (Proxy)를 하나의 스택에 쌓아 올리고 있기 때문입니다.

현재 많은 에이전트 기반 코딩 스택이 인상적으로 보일 수 있습니다. 하지만 그것이 잘 설계되었다는 것과 동일한 의미는 아닙니다.

Claude Code는 코드베이스를 읽고, 명령을 실행하며, 파일을 편집하고, 훅 (Hook)을 사용하며, 서브 에이전트 (Subagent)와 협업하고, MCP를 통해 외부 도구에 연결할 수 있습니다. RTK 스타일의 프록시 (Proxy)는 토큰 소모가 많은 셸 노이즈 (Shell Noise)를 줄일 수 있습니다. MCP는 수십 또는 수백 개의 시스템에 대한 접근을 열어줄 수 있습니다. Anthropic의 자체 가이드라인은 이제 훅 (Hook), 보안 배포 (Secure Deployment), 서브 에이전트 (Subagent), 기술 (Skill), MCP, 프롬프트 캐싱 (Prompt Caching), 그리고 관리형 설정 (Managed Settings)까지 아우르고 있습니다 (1).

이는 스택이 더 이상 단순하지 않음을 의미합니다. 다행인 점은 이것이 혼란스러울 필요는 없다는 것입니다.

핵심 문제: 팀들이 세 가지 서로 다른 작업을 하나의 계층에 혼합하고 있음

대부분의 AI 코딩 도입 과정에서는 세 가지 별개의 관심사가 뒤섞여 버립니다:

• 제어 (Control)
• 접근 (Access)
• 효율성 (Efficiency)

이는 예측 가능한 혼란을 야기합니다.

훅(Hook) 하나가 정책(Policy), 통합(Integration), 최적화(Optimization) 역할을 동시에 수행하게 됩니다. MCP 서버는 워크플로 엔진(Workflow engine)이 되어버립니다. 컨텍스트 설계(Context design)나 모델 라우팅(Model routing)을 통해 해결했어야 할 문제들을 해결하기 위해 프록시(Proxy)가 도입됩니다. Anthropic의 자체 비용 가이드라인은 이와 정반대 방향을 가리키고 있습니다: 컨텍스트를 선제적으로 관리하고, 적절한 모델을 선택하며, MCP 오버헤드(Overhead)를 줄이고, 지침(Instructions)을 기술(Skills)로 옮기며, 전처리 훅(Preprocessing hooks)을 의도적으로 사용하십시오 (1).

그것이 바로 실마리입니다. 성숙한 스택은 관심사 분리(Separation of concerns)를 수행합니다.

3계층 아키텍처 (The 3-Layer Architecture)

이것은 대부분의 기술 팀에게 제가 추천할 수 있는 가장 단순한 아키텍처입니다.

제1계층: 제어 계층 (Control Layer)

Claude Code 네이티브 제어 기능이 정책(Policy), 권한(Permissions), 안전성(Safety), 그리고 워크플로 경계(Workflow boundaries)를 소유해야 합니다.

제2계층: 접근 계층 (Access Layer)

MCP는 외부 도구, 시스템 및 데이터에 대한 접근(Access)을 소유해야 합니다.

제3계층: 효율성 계층 (Efficiency Layer)

RTK와 같은 훅 기반 프록시(Hook-based proxies)는 에지(Edge)에 위치하여 특정 흐름을 최적화해야 하며, 운영 모델(Operating model)을 정의해서는 안 됩니다.

이것이 스택입니다. 이를 뒤집으면 스택은 취약해집니다. 계층을 깨끗하게 유지하면 시스템을 확장(Scale)하기가 훨씬 쉬워집니다.

제1계층: Claude Code 네이티브 제어가 시스템을 소유해야 함

이것이 토대입니다.

Anthropic의 Claude Code 문서는 이제 심각할 정도로 강력한 로컬 제어 표면(Control surface)을 노출합니다: 훅(Hooks), 설정 범위(Settings scopes), 권한(Permissions), 관리형 정책(Managed policy), 샌드박싱(Sandboxing), 서브에이전트(Subagents), 그리고 컨텍스트 관리(Context management)가 그것입니다. Anthropic은 또한 allowManagedHooksOnly, allowManagedMcpServersOnly, allowManagedPermissionRulesOnly와 같은 관리형 제어 기능과 더불어, 샌드박스 설정 및 민감한 경로에 대한 명시적 거부 규칙(Explicit deny rules)을 문서화하고 있습니다. 이것은 단순히 "있으면 좋은" 설정이 아닙니다. 이것이 바로 여러분의 제어 평면(Control plane)입니다 (1).

이 계층은 다음을 결정해야 합니다:

• 어떤 명령어를 실행할 수 있는지
• 어떤 훅(Hooks)이 허용되는지
• 어떤 MCP 서버가 허용되는지
• 어떤 파일이 거부되는지
• 언제 승인(Approval)이 필요한지
• 어떤 샌드박스 모드(Sandbox mode)가 적용되는지
• 어떤 서브에이전트(Subagents)가 존재하며 그들이 무엇을 할 수 있는지

만약 귀하의 팀이 취약한 네이티브 제어(native control)를 보완하기 위해 MCP나 RTK를 사용하려 한다면, 귀하는 잘못된 기반 위에 구축하고 있는 것입니다.

Layer 1에 포함되어야 할 것

• 관리형 설정 (Managed settings)
• 권한 (Permissions)
• 샌드박싱 (Sandboxing)
• 승인 정책 (Approval policy)
• CLAUDE.md 및 프로젝트 가이드라인 (project guidance)
• 서브에이전트 (Subagents)
• 반복 가능한 워크플로우를 위한 기술 또는 커스텀 명령 (Skills or custom commands)

Anthropic의 베스트 프랙티스(best-practices) 자료들은 이러한 설계 방향을 강화합니다. 이 회사는 하네스 설계(harness design), 병렬 세션(parallel sessions), 전문적인 작업을 위한 서브에이전트(subagents), 그리고 장기 실행되는 에이전트 워크플로우를 위한 구조화된 환경 설정(structured environment setup)을 명시적으로 권장합니다 (2).

Layer 1에 포함되지 말아야 할 것

• 광범위한 도구 확산 (Broad tool sprawl)
• 매주 변경되는 프록시 전용 로직 (Proxy-specific logic)
• 문서화되지 않은 셸 해킹 (Undocumented shell hacks)
• 임시적인 네트워크 액세스 (Ad hoc network access)
• 사용자 로컬 설정 내에 갇힌 숨겨진 워크플로우 관례 (Hidden workflow conventions)

Layer 1은 스택에서 가장 지루한 부분이 되어야 합니다. 그렇기 때문에 가장 중요한 결정들을 소유해야 합니다.

Layer 2: MCP는 거버넌스(Governance)가 아닌 액세스(Access)를 소유해야 합니다

MCP는 Claude Code가 로컬 환경 외부로 확장되는 지점입니다.

Anthropic의 MCP 문서에 따르면, Claude Code는 로컬 및 원격 MCP 서버에 연결하여 에이전트가 외부 도구와 데이터 소스를 사용할 수 있도록 합니다. 또한 Anthropic은 제3자 MCP 서버가 신뢰할 수 없는 콘텐츠를 가져오거나 민감한 시스템에 접근할 수 있는 경우, 특히 주의해서 다뤄야 한다고 경고합니다. Anthropic의 2025년 11월 엔지니어링 포스트는 이와 관련된 효율성 측면을 언급합니다: 도구의 수가 증가함에 따라 도구 로딩 오버헤드(tool-loading overhead)와 컨텍스트 오버헤드(context overhead)도 함께 증가하므로, 도구 액세스는 무심하게 처리하는 대신 신중하게 다뤄져야 합니다 (3).

이를 통해 Layer 2의 규칙이 도출됩니다:

MCP는 숨겨진 워크플로우 정책이 아니라, 통제된 도달(controlled reach)을 위해 사용해야 합니다.

MCP는 다음과 같은 질문에 답해야 합니다:

• Claude가 GitHub 이슈에 접근할 수 있는가?
• Slack에 도달할 수 있는가?
• 클라우드 리소스를 검사할 수 있는가?
• 데이터 소스를 쿼리할 수 있는가?

MCP는 다음과 같은 것들을 숨기는 장소가 되어서는 안 됩니다:

• 승인 로직 (Approval logic)
• 팀 방법론 (Team methodology)
• 보안 가정 (Security assumptions)
• 스킬 (skills), 커맨드 (commands) 또는 관리형 정책 (managed policy)에 존재해야 하는 비즈니스 규칙 (Business rules)

Layer 2에 속해야 하는 것들

• 외부 도구 액세스 (External tool access)
• 외부 데이터 검색 (External data retrieval)
• 시스템 통합 경계 (System integration boundaries)
• 허용 목록에 포함된 (Allowlisted) MCP 서버
• 서버별 신뢰 결정 (Server-specific trust decisions)

Layer 2에 속하지 않아야 하는 것들

• 기본 정책 (Default policy)
• 광범위한 워크플로우 오케스트레이션 (Broad workflow orchestration)
• 리포지토리 신뢰 가정 (Repo trust assumptions)
• 스킬 (skills) 또는 커맨드 (commands)에 속해야 하는 출력 계약 (Output contracts)

Anthropic의 자체 비용 가이드 또한 중요한 실무적 지점을 짚어줍니다: MCP가 항상 가장 저렴하거나 깔끔한 경로는 아닙니다. 문서에서는 사용하지 않는 서버를 비활성화할 것과, 직접적인 커맨드 라인 액세스가 컨텍스트 효율성 측면에서 더 나을 때는 MCP보다 CLI 도구를 선호할 것을 권장합니다 (1).

이것은 Layer 2가 의도적이어야 하기 때문에 중요합니다. 모든 통합이 MCP 서버가 될 가치가 있는 것은 아닙니다.

Layer 3: 훅 기반 프록시 (Hook-Based Proxies)는 통제하는 것이 아니라 최적화해야 한다

이 지점에서 팀들은 권한을 과도하게 확장하려는 유혹을 느낍니다.

RTK와 같은 훅 기반 프록시 (Hook-based proxies)는 셸(shell) 중심의 토큰 낭비를 줄일 수 있기 때문에 유용합니다. RTK의 README에는 자체 Claude Code 설정이 Bash 훅을 통해 작동하며 일반적인 셸 워크플로우를 압축할 수 있다고 명시되어 있습니다. 하지만 RTK는 또한 Read, Grep, Glob과 같은 Claude Code 내장 도구들은 Bash 훅을 통과하지 않으며 자동으로 재작성되지 않는다고 명확히 밝히고 있습니다 (4).

그것이 바로 프록시가 Layer 3에 속해야 하는 정확한 이유입니다. 프록시는 보편적인 제어 인터페이스 (control surfaces)가 아닙니다. 그것들은 에지 최적화 도구 (edge optimizers) 입니다.

다음과 같은 경우에 사용하십시오:

• 팀이 터미널 우선 (terminal-first)인 경우
• 셸 출력 (shell output)이 실제 비용 문제인 경우
• 네이티브 제어 계층 (native control layer)이 이미 성숙한 경우
• 팀이 프록시 동작이 적용되는 곳과 적용되지 않는 곳을 이해하고 있는 경우

다음의 대체제로 사용하지 마십시오:

• 권한 (Permissions)
• 정책 (Policy)
• 샌드박싱 (Sandboxing)
• MCP 허용 목록 (MCP allowlists)
• 깔끔한 컨텍스트 설계 (Clean context design)
• 모델 라우팅 (Model routing)

Anthropic의 비용 관련 문서도 이 순서를 뒷받침합니다. 다른 훅 (hook)을 찾기 전에, Anthropic은 컨텍스트 관리 (context management), 모델 선택 (model choice), MCP 오버헤드 감소 (reduced MCP overhead), 전처리 훅 (preprocessing hooks), 스킬 (skills), 그리고 서브에이전트 (subagents)를 권장합니다 (1).

이것이 제가 프록시 (proxies)를 마지막에 배치한 이유입니다. 프록시는 가치 있지만, 근간이 되는 요소는 아닙니다.

이 아키텍처가 작동하는 이유

이 구조는 각 계층 (layer)에 하나의 역할만을 부여합니다.

계층 1: 제어권 제공

Claude Code의 네이티브 설정 (native settings), 권한 (permissions), 서브에이전트 (subagents), 그리고 샌드박싱 (sandboxing)은 무엇이 허용되고 무엇이 거부되는지, 그리고 워크플로 (workflow)가 로컬에서 어떻게 동작하는지를 정의합니다 (1).

계층 2: 도달 범위 제공

MCP는 통제된 허용 목록 (allowlists)과 신뢰 경계 (trust boundaries) 하에서 에이전트 (agent)를 외부 시스템 및 데이터와 연결합니다 (5).

계층 3: 효율성 제공

RTK 스타일의 프록시 (proxies)는 전체 시스템을 소유하는 척하지 않으면서도 노이즈가 많은 셸 경로 (shell paths)를 최적화합니다 (4).

이러한 분리는 스택 (stack)을 더 이해하기 쉽게 만듭니다. 또한 다음과 같은 실질적인 질문에 답하기를 더 쉽게 만듭니다.

• 이 규칙은 어디에 위치해야 하는가?
• 어떤 계층이 이 실패의 원인을 담당하는가?
• 무엇을 표준화할 수 있는가?
• 무엇을 선택 사항으로 둘 수 있는가?
• 나머지를 망가뜨리지 않고 무엇을 끌 수 있는가?

이것이 바로 좋은 아키텍처가 하는 일입니다.

잘못된 설계에서 나타나는 혼돈의 모습

다음과 같은 상황이 발생하면 스택이 건강하지 않다는 것을 알 수 있습니다.

• 레포지토리 수준 (repo-level)의 동작이 조직의 의도를 조용히 무시할 수 있을 때
• MCP 서버가 모든 워크플로 요구 사항에 대한 기본 해답이 될 때
• 잘못된 컨텍스트 설계 (context design)를 가리기 위해 프록시가 사용될 때
• 아무도 문서화하지 않은 숨겨진 정책이 훅 (hooks)에 담겨 있을 때
• 팀이 내장 도구가 언제 가로채기 (interception)를 우회하는지 설명하지 못할 때
• 한 엔지니어의 로컬 설정이 사실상의 운영 모델 (de facto operating model)이 될 때

Anthropic의 보안 배포 가이드는 여기서 유용한 경고가 됩니다. 이 회사는 에이전트의 동작이 레포지토리 콘텐츠, 웹페이지, 그리고 사용자 입력에 의해 영향을 받을 수 있기 때문에 최소 권한 (least privilege), 격리 (isolation), 그리고 심층 방어 (defense in depth)를 명시적으로 권장합니다. 각 계층이 다른 계층의 역할까지 수행하기 시작하면 관리는 더욱 어려워질 뿐입니다 (1).

실질적인 배포 순서

혼돈 없는 에이전틱 코딩 (agentic coding)을 원한다면, 다음 순서대로 도입하십시오.

1단계: 레이어 1 (Layer 1) 안정화

먼저 Claude Code의 네이티브 제어 기능을 올바르게 설정하십시오.

• 권한 (Permissions)
• 샌드박싱 (Sandboxing)
• 설정 범위 (Settings scopes)
• 훅 정책 (Hook policy)
• 서브에이전트 (Subagents)
• 워크플로우 메모리 및 명령 (Workflow memory and commands)

2단계: 레이어 2 (Layer 2) 제약

실제로 필요한 MCP 서버만 추가하십시오.

• 소유권 정의 (Define ownership)
• 허용 목록 정의 (Define allowlists)
• 신뢰 경계 정의 (Define trust boundaries)
• 미사용 기능 비활성화

3단계: 레이어 3 (Layer 3) 최적화

앞선 두 레이어가 성숙해진 후에야 RTK 스타일의 프록시 (proxies) 또는 기타 훅 기반의 효율성 도구를 도입해야 합니다.

• 절감 효과 검증 (Validate savings)
• 범위 문서화 (Document scope)
• 우회 사례 (bypass cases)에 대한 팀 교육
• 효과가 입증될 때까지 선택 사항으로 유지

이러한 순서는 예기치 못한 상황을 줄여줍니다. 또한 표준화(standardization)를 위한 훨씬 강력한 논거를 제공합니다.

나의 결론

2026년의 승리하는 에이전틱 코딩 스택은 구성 요소가 가장 많은 스택이 아닙니다. 가장 명확한 소유권 모델 (ownership model)을 가진 스택입니다.

대부분의 기술 팀에게 이는 다음을 의미합니다:

• Claude Code 네이티브 제어가 정책을 담당
• MCP가 도달 범위 (reach)를 담당
• 훅 기반 프록시가 최적화를 담당

그 외의 방식은 데모에서는 강력해 보이지만, 프로덕션 (production) 환경에서는 관리하기 어려워지는 스택으로 흘러가는 경향이 있습니다.

핵심 요약

• Claude Code, MCP, 그리고 RTK 스타일의 프록시는 서로 다른 문제를 해결하며, 하나의 레이어로 통합되어서는 안 됩니다 (1).
• 레이어 1은 정책, 권한, 샌드박싱, 서브에이전트 및 워크플로우 경계를 담당해야 합니다 (1).
• 레이어 2는 MCP를 통한 외부 도구 및 데이터 액세스를 담당해야 합니다 (5).
• 레이어 3은 시스템을 관리하는 것이 아니라, 셸 중심의 워크플로우를 최적화해야 합니다. RTK의 Bash 훅 제한 사항은 바로 프록시가 이 레이어에 머물러야 하는 이유입니다 (4).
• 팀은 제어, 액세스, 효율성을 하나의 무질서한 툴체인 (toolchain)으로 섞는 대신 분리할 때 에이전틱 코딩을 더 빠르게 확장할 수 있습니다.

FAQ

왜 모든 것에 MCP만 사용하지 않나요?

MCP는 액세스 계층 (access layer)이지, 완전한 운영 모델 (operating model)이 아니기 때문입니다. 외부 시스템에 도달하는 데는 매우 훌륭하지만, 정책 (policy), 권한 (permissions), 그리고 워크플로 경계 (workflow boundaries)는 스택의 더 높은 곳에 위치해야 합니다. Anthropic의 문서에서는 MCP를 도구 액세스 표면 (tool access surface)으로 취급하며, 팀들에게 제3자 서버 및 신뢰할 수 없는 콘텐츠를 주의할 것을 경고합니다 (5).

왜 Claude Code 네이티브 제어가 기반이 되어야 하나요?

Anthropic이 이미 팀들에게 훅 (hooks), 설정 범위 (settings scopes), 권한 (permissions), 샌드박싱 (sandboxing), 하위 에이전트 (subagents), 그리고 관리형 제어 (managed controls)를 제공하고 있기 때문입니다. 그곳이 시스템이 무엇을 할 수 있는지 정의하기에 가장 자연스러운 장소입니다 (1).

이 모델에서 기술 (skills)은 어디에 위치하나요?

기술 (skills)은 보통 재사용 가능한 워크플로 로직 (workflow logic)과 함께 레이어 1 (Layer 1)에 속합니다. 왜냐하면 기술은 행동을 형성하고 반복 가능한 절차를 패키징하기 때문입니다. Anthropic의 현재 자료들은 기술을 특화된 워크플로 지식 (specialized workflow knowledge)으로 규정하고 있으며, 기술 가이드 또한 필요할 때 기술이 어떻게 MCP 호출을 적절한 순서로 오케스트레이션 (orchestrate)할 수 있는지 보여줍니다 (6).

왜 RTK 스타일의 프록시 (proxies)를 마지막에 배치하나요?

그것들은 최적화 도구 (optimization tools)이지, 보편적인 제어 표면 (control surfaces)이 아니기 때문입니다. RTK 자체에서도 자신의 Bash 훅 (Bash hook)이 Read, Grep, Glob과 같은 Claude Code 내장 도구들을 가로채지 않는다고 명시하고 있으며, 이는 RTK가 완전한 거버넌스 계층 (governing layer) 역할을 할 수 없음을 의미합니다 (4).

팀이 훅 기반 프록시 (hook-based proxy)를 추가해야 하는 시점은 언제인가요?