Claw Patrol — 에이전트에게 프로덕션 접근을 허용하는 방법

에이전트에게 프로덕션 데이터베이스 접근 권한을 준다는 건 어떤 의미일까. 편리함과 위험이 동시에 오는 거다. kubectl delete namespace prod와 psql -c 'DROP TABLE users'는 둘 다 단 한 번의 도구 호출로 실행된다.

Deno는 Deno Deploy, JSR 등 자체 프로덕션 서비스를 운영하면서 이 문제를 직접 부딪혔다. 에이전트가 PagerDuty 알림을 트리아지하고, 대시보드를 확인하고, 잘못된 배포를 롤백하려면 AWS, GCP, Postgres, Kubernetes, ClickHouse에 접근해야 한다. 그 결과물이 오픈소스로 공개된 Claw Patrol이다.

에이전트에게 프로덕션 접근을 줄 때의 딜레마

핵심 문제는 하나다.

에이전트는 스스로를 통제할 수 없다. 에이전트 프로세스가 도구(psql, kubectl, gh, curl)와 해당 자격증명을 모두 쥐고 있기 때문이다.

프롬프트 인젝션, 환각, 잘못된 도구 호출 — 이 세 가지 중 하나만 발생해도 재앙이 될 수 있다. 그리고 Claude Code, Codex처럼 직접 만들지 않은 에이전트를 쓰는 경우, 에이전트 내부 동작 자체를 바꿀 수도 없다. 어떤 해결책이든 에이전트 바깥에서 작동해야 한다.

Deno의 구체적인 상황은 이랬다. 프로덕션 Aurora 데이터베이스가 VPC 안에 있고 EKS apiserver를 통해서만 접근 가능했다. 에이전트가 이 DB에 읽기 접근을 갖는 건 유용하지만, DROP TABLE은 절대 호출해선 안 된다.

[💡 잠깐! 이 용어는?] VPC(Virtual Private Cloud): 퍼블릭 인터넷에서 격리된 클라우드 사설 네트워크. VPC 안의 자원은 외부에서 직접 접근할 수 없다.

이게 HTTP 방화벽으로 해결되는 문제가 아닌 이유가 있다. 에이전트가 도달해야 하는 경로는 에이전트 호스트가 직접 닿을 수 없는 네트워크이고, 프로토콜은 HTTP가 아니며, 차단 규칙은 SQL 문법을 이해해야 한다.

기존 보안 도구가 부족한 이유

이미 비슷한 문제를 다루는 도구들이 존재한다. 문제는 각자 일부만 해결한다는 점이다.

비유하면 이렇다. 집 정문에 CCTV를 달았는데 창문이 열려 있는 상황이다. 각각의 도구는 정문, 창문, 지하실 출입구 중 하나만 지킨다.

Claw Patrol의 접근법

Claw Patrol은 에이전트와 실제 서비스 사이에 프로토콜 인식 게이트웨이를 끼워 넣는다.

[에이전트] → WireGuard/Tailscale 터널 → [Claw Patrol 게이트웨이] → 프로덕션 시스템

[💡 잠깐! 이 용어는?] WireGuard / Tailscale: 안전한 암호화 VPN 터널을 만드는 도구. 에이전트의 모든 트래픽이 이 터널을 통해 게이트웨이로 강제 라우팅된다.

게이트웨이가 하는 일은 세 가지다.

1. TLS 종료 및 프로토콜 파싱: HTTP, SQL, Kubernetes 등 실제 내용을 들여다본다.
2. 자격증명 보관 및 주입: 에이전트는 {{github_pat}} 같은 플레이스홀더만 쓰고, 게이트웨이가 실제 토큰으로 교체한다.
3. 규칙 평가: HCL로 작성한 규칙에 따라 각 요청을 허용/거부/승인 요청한다.

핵심은 에이전트가 실제 자격증명을 절대 보지 못한다는 점이다. 에이전트 프로세스가 침해당해도 키는 노출되지 않는다.

규칙 작성 방법

규칙은 HCL로 작성한다. 세 가지 프로토콜을 지원한다.

rule "k8s-no-secrets" {
  endpoints = [kubernetes.deploy-dev, kubernetes.deploy-prod]
  condition = "k8s.resource == 'secrets'"
  verdict   = "deny"
  reason    = "Secret values must not leave the cluster via the agent"
}

[💡 잠깐! 이 용어는?] HCL(HashiCorp Configuration Language): Terraform 등에서 쓰는 설정 언어. JSON보다 사람이 읽기 편하고, 주석을 달 수 있다.

각 규칙은 어느 엔드포인트에, 어떤 조건이면, 어떤 판정을 내릴지 정의한다. 조건은 프로토콜별 파싱 결과를 쓴다.

판정은 단순히 allow/deny가 아니다. 승인 체인을 구성할 수 있다.

rule "support-reply-approval" {
  endpoints = [http.support-api]
  condition = "http.method == 'POST' && http.path == '/reply'"
  verdict   = chain {
    approver = llm.tone-checker      # LLM이 마크다운 형식과 톤 검사
    approver = slack.support-channel  # Slack에서 사람이 최종 승인
  }
}

Deno 팀은 이 체인을 고객 지원 답변에 실제로 쓴다. LLM이 먼저 본문의 마크다운과 톤을 검사하고, 그 다음 #support 채널의 사람이 최종 승인하거나 수정한다.

자격증명 격리

자격증명 격리는 Claw Patrol에서 가장 중요한 개념 중 하나다.

기존 방식에서 에이전트는 실제 API 키나 DB 비밀번호를 환경 변수로 직접 들고 다녔다. 프로세스가 침해당하면 키도 같이 유출된다.

Claw Patrol에서는 에이전트가 플레이스홀더만 사용한다.

curl -H "Authorization: Bearer {{github_pat}}" https://api.github.com/repos/...

게이트웨이는 와이어 위에서 {{github_pat}}를 실제 토큰으로 교체한다. 에이전트 프로세스 메모리에는 플레이스홀더 문자열만 존재한다. 침해당해도 얻을 수 있는 게 없다.

실전 사용 사례

Deno 팀이 실제로 쓰는 시나리오들이다.

운영 자동화: 에이전트가 PagerDuty 알림을 받아 Grafana 대시보드를 확인하고, 필요하면 kubectl로 롤백한다. 단, kubectl delete는 규칙으로 차단하고 kubectl rollout만 허용한다.

DB 읽기 전용 접근: 에이전트가 Aurora 데이터베이스에 SELECT 쿼리만 실행 가능하도록 SQL 동사로 게이팅한다. INSERT, UPDATE, DROP은 전부 deny된다.

고객 지원 답변: 에이전트가 초안을 작성하면 LLM이 톤을 검사하고, 사람이 Slack에서 최종 승인한다. 완전 자동화 없이 인간 판단이 항상 마지막에 위치한다.

정리

Claw Patrol이 해결하는 핵심 문제는 세 가지다.

• 프로토콜 다양성: HTTP 외에 SQL, Kubernetes, SSH 등을 게이팅할 수 있다.
• 자격증명 격리: 에이전트가 실제 키를 갖지 않으므로 침해당해도 유출이 없다.
• 유연한 판정: allow/deny를 넘어 LLM 판단과 인간 승인을 체인으로 구성할 수 있다.

에이전트에게 프로덕션 접근을 주는 건 선택의 문제가 아니라 시간의 문제다. 24/7 동작하는 에이전트가 더 많아질수록 이 레이어의 필요성은 커진다. 현재 알파 단계지만, MIT 라이선스로 공개되어 있고 시작 가이드에서 5분 안에 게이트웨이를 구동할 수 있다.

참고:

• Claw Patrol 블로그 포스트: https://deno.com/blog/clawpatrol
• Claw Patrol 시작 가이드: https://clawpatrol.dev/docs/getting-started/