Claude Code 보안 2026: 배포 전 훅(Hooks)을 차단하라

Claude Code는 더 이상 단순한 개발자 편의 도구가 아닙니다. 이는 공격 표면(Attack Surface)을 가진 실행 표면(Execution Surface)입니다. 만약 귀하의 팀이 이를 인프라처럼 다루지 않고 있다면, 첫 번째 프롬프트를 입력하기도 전에 위험을 초래하고 있는 것입니다.

Claude Code는 더 이상 단순한 개발자 편의 도구가 아닙니다. 이는 실행 표면(Execution Surface), 워크플로 표면(Workflow Surface), 그리고 정책 표면(Policy Surface)입니다. 즉, 이제는 보안 모델이 생산성 향상만큼이나 중요해졌음을 의미합니다.

대부분의 팀은 여전히 Claude Code를 그저 더 똑똑한 터미널처럼 이야기합니다.

그것은 이미 시대에 뒤떨어진 생각입니다.

Claude Code는 코드를 실행하고, 파일에 접근하며, 훅(Hooks)을 사용하고, MCP 서버에 연결하며, 리포지토리 수준의 설정(Repository-level configuration)에 따라 동작할 수 있습니다. Anthropic의 자체 보안 배포 가이드(Secure deployment guide)에 따르면, 이러한 에이전트 도구(Agentic tools)는 파일, 웹페이지 또는 사용자 입력에 의해 영향을 받을 수 있으며, 프롬프트 인젝션(Prompt injection), 최소 권한 원칙(Least privilege), 심층 방어(Defense in depth)를 핵심 운영 고려 사항으로 명시하고 있습니다. (Claude)

이것이 대화의 흐름을 바꿉니다.

질문은 더 이상 Claude Code가 유용한가 하는 것이 아닙니다.

질문은 귀하의 팀이 Claude Code를 공격 표면을 가진 인프라처럼 다루고 있는가 하는 것입니다.

최근의 두 가지 패턴이 이를 명확히 보여줍니다.

첫째, Check Point Research는 훅(Hooks), MCP 통합, 환경 변수(Environment variables)를 포함하는 악성 리포지토리 수준 설정을 통해 원격 코드 실행(Remote code execution) 및 API 자격 증명 탈취를 허용할 수 있는 Claude Code의 취약점을 공개했습니다. Check Point는 또한 해당 문제들이 공개 전에 패치되었다고 밝혔지만, 교훈은 남아 있습니다: 리포지토리 설정이 이제 실행 로직(Execution logic)처럼 동작할 수 있다는 점입니다. (Check Point Blog)

이것들은 서로 다른 공격 경로(Attack paths)입니다.

하지만 이들은 동일한 전략적 진실을 가리킵니다:

Claude Code 보안은 이제 첫 번째 프롬프트가 시작되기 전부터 시작됩니다.

Claude Code의 공격 표면은 대부분의 팀이 생각하는 것보다 더 넓습니다

Claude Code는 단순한 모델 UI가 아닙니다.

Anthropic은 사용자(user), 프로젝트(project), 로컬(local), 관리형 정책(managed-policy), 그리고 플러그인(plugin) 레벨에서의 훅(hooks)을 문서화하고 있으며, 훅 핸들러(hook handlers)는 이벤트와 설정에 따라 셸 명령(shell commands), HTTP 엔드포인트(HTTP endpoints), 프롬프트(prompts) 또는 에이전트(agents)를 실행할 수 있습니다. 또한 Anthropic은 .claude/settings.json을 통해 공유되는 프로젝트 레벨 설정, 사용자 레벨 설정, 로컬 재정의(local overrides), 그리고 조직 전체에서 관리되는 설정에 대해서도 문서화하고 있습니다. (Claude API Docs)

이는 공격 표면(attack surface)이 최소 다섯 가지 계층에 걸쳐 퍼져 있음을 의미합니다:

설치 소스 (installation source)
로컬 및 프로젝트 설정 (local and project configuration)
훅 (hooks)
MCP 서버 및 권한 규칙 (MCP servers and permission rules)
자격 증명 및 외부 네트워크 액세스 (credentials and outbound network access)

만약 여러분의 사고 모델이 여전히 "위험은 모델이 잘못된 코드를 작성할 때 시작된다"에 머물러 있다면, 더 큰 문제를 놓치고 있는 것입니다.

많은 팀에게 위험은 훨씬 더 일찍 시작됩니다.

공격 표면 1: 설치 경로

이곳은 가장 쉽게 피해를 입을 수 있는 지점입니다.

설치는 종종 무해한 설정 작업으로 취급되기 때문에 이 점이 중요합니다.

하지만 그렇지 않습니다.

만약 여러분의 팀이 검색 결과, 복제된 문서, 무작위 튜토리얼, 또는 "유출된" 저장소(repositories)를 통해 Claude Code를 도입하고 있다면, 저장소 정책, 훅 규칙, 또는 MCP 결정이 도움을 주기 전부터 보안 태세(security posture)는 이미 침해된 상태입니다.

여기서 가장 먼저 차단해야 할 사항

내부적으로 공식 설치 경로를 표준화하십시오.
검색 광고, 복제된 문서, 또는 소셜 미디어 스니펫에서 복사한 설치 지침을 금지하십시오.

Check Point의 Claude Code 연구가 유용한 이유는 단순히 공개된 특정 결함 때문만이 아니라, 현대의 코딩 에이전트(Coding Agents)가 설정(Configuration)과 실행(Execution) 사이의 경계를 어떻게 모호하게 만드는지를 명확히 보여주기 때문입니다. Check Point는 악의적인 저장소 수준의 설정(Repository-level configuration)이 훅(Hooks), MCP, 그리고 환경 변수(Environment variables)를 악용하여, 사용자가 신뢰할 수 없는 프로젝트를 클론(Clone)하고 열 때 숨겨진 명령을 트리거하고 API 자격 증명(Credentials)을 유출할 수 있다고 밝혔습니다. 또한 이러한 문제들은 게시 전에 해결되었다고 언급했습니다. (Check Point Blog)

Anthropic의 보안 배포 가이드(Secure deployment guide)는 이러한 광범위한 교훈을 뒷받침합니다. Anthropic은 에이전트의 동작이 저장소 파일, 웹페이지 또는 사용자 입력에 의해 영향을 받을 수 있다고 말하며, Claude Code가 자신의 작업에 포함할 수 있는 특이한 지침이 포함된 README 파일을 예로 들었습니다. Anthropic이 권장하는 대응책은 마법 같은 탐지가 아닙니다. 그것은 격리(Isolation), 최소 권한(Least privilege), 그리고 심층 방어(Defense in depth)입니다. (Claude)

이것이 올바른 모델입니다.

이제 신뢰할 수 없는 저장소는 단순히 소스 파일이 아니라, **준신뢰 코드(Semi-trusted code) + 정책(Policy) + 지침(Instructions)**의 결합체로 취급되어야 합니다.

공격 표면 세 번째: 훅(Hooks)은 강력하며, 그 힘은 양날의 검이다

훅(Hooks)은 Claude Code에서 가장 유용한 부분 중 하나입니다.

동시에 가장 민감한 부분 중 하나이기도 합니다.

Anthropic은 사용자(User), 프로젝트(Project), 로컬(Local), 관리 정책(Managed-policy), 그리고 플러그인(Plugin) 범위에 걸친 훅의 위치를 문서화하고 있습니다. 또한 Anthropic은 엔터프라이즈 관리자가 allowManagedHooksOnly를 사용하여 사용자, 프로젝트 및 플러그인 훅을 차단함으로써, 관리형 훅(Managed hooks)과 SDK 훅만 허용할 수 있다고 문서화했습니다. (Claude API Docs)

해당 설정 하나만으로도 Anthropic이 현재 훅 거버넌스(Hook governance)를 얼마나 진지하게 다루고 있는지 알 수 있습니다.

프로젝트 및 플러그인 훅(Hooks)의 로딩을 방지하기 위해 관리 전용 설정(managed-only setting)이 필요한 기능이라면, 해당 기능은

만약 팀이 여전히 모든 저장소(repo)가 각자의 에이전트 권한(agent permissions)을 정의하도록 방치하고 있다면, 그것은 에이전트 보안(agent security)을 수행하고 있는 것이 아닙니다.

그것은 에이전트 보안에 대한 '희망(hope)'을 품고 있는 것뿐입니다.

공격 표면(Attack surface) 5: 비밀 정보(secrets), 외부 접속(outbound access), 그리고 자격 증명 노출(credential exposure)

이 지점에서 많은 팀이 지나치게 안일한 태도를 유지합니다.

Anthropic의 설정 문서(settings docs)는 permissions.deny를 통해 .env, .env.*, secrets/**, 그리고 자격 증명(credential) JSON 파일과 같은 민감한 파일에 대한 접근을 거부할 것을 명시적으로 권장합니다. 또한 Anthropic은 sandbox.enabled 및 failIfUnavailable을 포함한 bash 샌드박싱(sandboxing)을 문서화하여, 샌드박스가 적용되지 않은 상태로 조용히 실행되는 대신 세션이 실패하도록 할 수 있습니다. (Claude API Docs)

Anthropic의 보안 배포 가이드(secure deployment guide)는 한 걸음 더 나아갑니다. 에이전트가 실제 자격 증명을 절대 볼 수 없도록 하고, 프록시(proxy)가 이를 외부에서 주입하며, 허용 목록(allowlisted)에 있는 엔드포인트(endpoints)만을 강제하고, 감사를 위해 요청을 기록하는 프록시 패턴(proxy pattern)을 권장합니다. 동일한 가이드에서는 가능한 경우 코드를 읽기 전용(read-only)으로 마운트(mounting)할 것과 .env, 클라우드 자격 증명, 설정 파일(config files)과 같은 민감한 디렉토리에 대한 접근을 피할 것을 권장합니다. (Claude)

이것이 바로 "Claude Code가 노트북에서 실행되는 것"과 "Claude Code가 프로덕션(production) 환경에서 실행되는 것"의 차이입니다.

여기서 가장 먼저 잠가야 할 것들

기본적으로 .env, 비밀 정보(secrets), 자격 증명 저장소(credential stores)에 대한 읽기 권한을 거부(Deny)하세요. Anthropic은 이 패턴을 명시적으로 보여줍니다. (Claude API Docs)
가능한 경우 샌드박싱(sandboxing)을 활성화하고, 샌드박스를 사용할 수 없는 경우 실패하도록 설정(fail closed)하세요. (Claude API Docs)
외부 자격 증명을 에이전트에 직접 노출하는 대신 프록시(proxy)를 사용하세요. Anthropic은 이를 권장되는 접근 방식(recommended approach)이라고 부릅니다. (Claude)
분석 워크플로(analysis workflows)를 위해 읽기 전용(read-only) 코드 마운트를 우선적으로 사용하세요. (Claude)

팀들이 놓치기 쉬운 한 가지 미묘한 차이: 데스크톱(Desktop)과 CLI 정책은 동일하지 않습니다

이 부분은 쉽게 간과하기 쉽습니다.

Anthropic의 데스크톱 문서에 따르면, 관리 콘솔(Admin Console)을 통해 업로드된 원격 관리 설정(Remote managed settings)은 현재 CLI 및 IDE 세션에만 적용되며, 데스크톱 전용 제한 사항은 데스크톱 관리를 위한 관리 콘솔 제어 기능을 통해 처리해야 합니다. (Claude)

이는 일부 팀들이 정책 적용 범위가 부분적임에도 불구하고, 표준화된 정책 적용이 완료되었다고 오해할 수 있음을 의미합니다.

만약 배포 범위가 데스크톱과 CLI 모두에 걸쳐 있다면, 정책이 실제로 어디에 적용되는지 확인하십시오.

하나의 관리 설정이 모든 접점(Surface)을 동일하게 제어한다고 가정해서는 안 됩니다.

실질적인 Claude Code 보안 강화(Hardening) 기준선

Claude Code를 본격적으로 도입하려는 팀에게 조언을 한다면, 저는 다음 사항부터 시작할 것입니다:

1. 설치 프로세스 잠금 (Lock down installation)

승인된 하나의 설치 경로만 사용하십시오. 광고, 복제된 문서, 유출된 저장소(Repo)로부터의 복사-붙여넣기 설치를 금지하십시오. (Push Security)

2. 신뢰할 수 없는 저장소를 준신뢰 실행 환경(Semi-trusted execution environments)으로 취급

복제된 저장소가 자동으로 신뢰를 상속받게 두지 마십시오. Check Point의 연구 결과는 저장소 설정(Repo config)이 이제 공격 표면(Attack surface)의 일부라는 점을 가장 명확하게 상기시켜 줍니다. (Check Point Blog)

3. 정책을 관리 설정(Managed settings)으로 이동

환경이 허용하는 경우 allowManagedHooksOnly, allowManagedMcpServersOnly, allowManagedPermissionRulesOnly를 사용하십시오. (Claude API Docs)

4. 기본적으로 비밀 정보(Secrets) 차단

.env, 비밀 정보 디렉토리, 자격 증명(Credential) 파일을 사전에 차단하십시오. (Claude API Docs)

5. 샌드박싱(Sandboxing) 및 프록시 패턴 사용

에이전트를 실행할 때 노트북이 제공하는 최대 권한이 아니라, 에이전트가 필요로 하는 최소 권한(Least privilege)만 부여하여 실행하십시오. (Claude)

나의 결론

Claude Code를 사용하는 것이 너무 위험한 것은 아닙니다.

하지만 무심코 배포하기에는 너무나 강력합니다.

2026년의 보안 교훈은 에이전트 기반 코딩 도구(agentic coding tools)가 결함이 있다는 것이 아닙니다. 이 도구들이 설치 위생(installation hygiene), 저장소 신뢰성(repo trust), 훅 거버넌스(hook governance), MCP 정책(MCP policy), 그리고 자격 증명 아키텍처(credential architecture)가 모두 출시 계획(rollout plan)에 포함되어야 하는 범주로 넘어왔다는 사실입니다. Anthropic의 자체 문서도 이제 이러한 현실을 반영하고 있으며, 외부 보안 연구는 이러한 위험 요소를 더욱 명확하게 드러냈을 뿐입니다. (Claude)

만약 여러분의 팀이 보안 강화 기준(hardening baseline) 없이 Claude Code를 도입하고 있다면, 여러분은 단순히 코딩 어시스턴트를 실행하고 있는 것이 아닙니다.

여러분은 제어 평면(control plane)에 대한 통제권을 갖지 못한 채 실행 표면(execution surface)을 도입하고 있는 것입니다.