금융권 망분리 환경에서 클로드 코드 도입할 때 실제로 걸리는 5가지 — 보안팀 질문과 대응 설정




카드사·신용평가사 대형 SI와 멀티클라우드·Kubernetes 운영을 20년 가까이 해 왔고, 최근에는 사내 AI 코딩 도구 도입과 거버넌스(가드레일) 설계를 다루고 있습니다. 이 글은 금융권처럼 망분리·보안 심사가 있는 환경에서 클로드 코드(Claude Code)를 도입할 때 실제로 어디에서 막히고, 무엇을 준비하면 통과하는지를 정리한 것입니다.

도입이 막히는 지점은 기술이 아니라 "질문"입니다

클로드 코드는 파일을 읽고 쓰고, 셸 명령을 실행하고, MCP로 외부 도구까지 부르는 에이전트입니다. 개발자 입장에서는 강력하지만, 정보보호팀 입장에서는 "우리 소스코드와 데이터를 외부로 내보내고, 운영 환경에 명령을 내릴 수 있는 프로그램"입니다. 그래서 심사에서 나오는 질문은 늘 비슷합니다. 이 질문에 설정 파일과 증적으로 답할 수 있으면 통과하고, 말로만 답하면 막힙니다.

보안팀이 반드시 묻는 5가지와 대응

1. 소스코드가 외부로 나가는가?

나갑니다. 이걸 부정하려고 하면 신뢰를 잃습니다. 대신 두 가지를 준비합니다. 첫째, 벤더의 데이터 보존 정책(학습 미사용, 보존 기간)을 계약 문서·DPA로 확보합니다. 둘째, 나가면 안 되는 파일은 아예 읽지 못하게 설정으로 막습니다. .claude/settings.json의 permissions.deny에 .env*, *.pem, *.jks, 운영 프로파일 설정을 넣으면 클로드가 그 파일을 열 수 없습니다. 1번에서 막히면 나머지는 의미가 없으니 계약 확인부터 하세요.

2. 어떤 경로로 나가는가?

망분리 환경에서는 "직접 호출 경로가 막혀 있다"는 것을 증적으로 보여야 합니다. 구성 패턴은 세 가지입니다.

  • 프록시 화이트리스트: 개발망에서 벤더 API 도메인만 프록시로 허용. 가장 단순하고 빠릅니다. HTTPS_PROXY 환경변수로 클로드 코드가 프록시를 타게 합니다.
  • 사내 LLM 게이트웨이: 모든 호출을 사내 게이트웨이로 보내고 게이트웨이가 벤더에 중계. 사용량 집계·로깅·키 관리가 한곳에 모입니다. ANTHROPIC_BASE_URL로 게이트웨이를 가리키게 합니다. 금융권은 대부분 이 패턴으로 갑니다.
  • 클라우드 사업자 경유: AWS Bedrock, GCP Vertex AI를 통해 호출. 이미 해당 클라우드와 전용선·계약이 있으면 심사가 빠릅니다.

어느 패턴이든 프록시 로그나 게이트웨이 로그가 증적입니다.

3. 누가 무엇을 했는지 남는가?

클로드 코드의 훅(hooks)을 씁니다. 세션이 응답을 끝낼 때(Stop 이벤트) 변경된 파일 목록을 로그에 남기는 스크립트 하나면 "AI가 어떤 파일을 건드렸는지" 추적이 됩니다. 여기에 커밋 메시지 규칙(AI 사용 표기)과 브랜치 보호(사람 승인 1인 이상)를 더하면 내부 감사 대응이 끝납니다.

4. 실 데이터에 접근할 수 있는가?

MCP로 DB나 Kubernetes를 붙일 때가 가장 예민한 지점입니다. 원칙은 첫 연결은 무조건 읽기 전용입니다. DB는 SELECT 권한만 가진 계정 + 읽기 레플리카 엔드포인트 + PII 컬럼은 마스킹 뷰. Kubernetes는 get/list/watch만 되는 ClusterRole로 별도 ServiceAccount를 만들고, 그 토큰으로 만든 전용 kubeconfig만 MCP에 넘깁니다. 평소 쓰는 admin kubeconfig를 그대로 주면 안 됩니다.

5. 권한 통제가 되는가?

개인이 각자 설정하게 두면 통제가 안 됩니다. settings.json을 리포지토리에 커밋해 팀 단위로 배포하고, kubectl delete/apply, terraform apply, git push --force, rm -rf 같은 명령은 permissions.deny와 PreToolUse 훅으로 이중 차단합니다. 설정으로 못 잡는 조합(curl … | sh, sudo, 외부 전송)은 훅이 잡습니다.

실제로 작동하는 훅 하나: 시크릿 쓰기 차단

말로 하는 것보다 설정 하나를 보여주는 게 심사에서 훨씬 잘 통합니다. 파일을 쓰기 직전에 내용을 검사해서 AWS 키·개인키·토큰·주민번호 패턴이 있으면 차단하는 훅입니다.

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command",
                  "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/block-secrets.sh" }]
    }]
  }
}

스크립트는 표준입력으로 들어오는 JSON에서 tool_input.content를 꺼내 정규식으로 검사하고, 걸리면 exit 2로 종료합니다. 그러면 클로드가 쓰기를 중단하고 stderr 메시지("환경변수 참조로 바꾸세요")를 읽은 뒤 스스로 고쳐 씁니다. 사람 리뷰보다 빠르고, 잊지 않습니다.

도입 첫 주에 할 일 (순서대로)

  1. 프로젝트 유형에 맞는 CLAUDE.md를 루트에 두고 "절대 하지 말 것" 섹션을 팀과 함께 채운다 — 30분
  2. .claude/settings.json에 permissions allow/deny를 넣고, 훅 스크립트 3~4개를 .claude/hooks/에 배치한다 — 20분
  3. 가짜 시크릿을 써 보라고 시켜서 실제로 차단되는지 팀원 전원이 확인한다 — 10분
  4. Kubernetes/DB는 읽기 전용 자격증명으로만 MCP를 연결한다 — 40분
  5. 위 다섯 질문에 대한 답을 표로 정리해 정보보호팀에 먼저 보낸다 — 60분

순서가 중요합니다. "일단 써 보자"로 시작해 3주 뒤 보안팀에 막히는 팀을 여럿 봤습니다. 차단 설정부터 넣고 쓰기 시작하면 보안팀에 "이렇게 막고 있다"고 먼저 말할 수 있습니다.

이 세팅을 파일로 정리했습니다

위 내용을 팀에서 바로 복사해 쓸 수 있게 클로드 코드 실무 세팅 킷으로 묶었습니다. 프로젝트 유형별 CLAUDE.md 템플릿 8종(Spring Boot SI·Python 데이터·Terraform·Kubernetes 운영·React·RAG/LLM·레거시·모노레포), 훅 스크립트 4종과 settings.json, 슬래시 커맨드 6종(/review-pr, /incident 등), Kubernetes 읽기전용 RBAC를 포함한 MCP 설정 4종, 그리고 위 다섯 질문을 19개 항목으로 펼친 보안 거버넌스 체크리스트와 팀 온보딩 1주 플랜이 들어 있습니다. 27쪽 가이드 PDF가 각 파일을 왜 그렇게 썼는지, 어디를 고쳐 쓰면 되는지 설명합니다.

훅 스크립트는 AWS 키·개인키·주민번호·카드번호 패턴과 kubectl delete·curl | sh 같은 명령이 실제로 차단되는지 테스트했습니다. 특정 회사의 보안 심사 통과를 보장하지는 않습니다. 체크리스트는 제가 겪은 심사 기준을 정리한 것이라 각 조직 정책에 맞게 보완이 필요합니다.

▶ 킷 보기: https://www.latpeed.com/products/uKSp6 (런칭 기간 12,900원, 정가 19,900원)

적용하다 막히는 부분이나 "우리 환경에서는 이렇게 막혔다"는 사례는 댓글로 남겨 주세요. 다음 글에서 다루겠습니다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

10.15 부동산 대책, 오피스텔도 LTV 40%인가요? 혼선 정리

라벨: 부동산대책 , 10·15대책 , 오피스텔 , LTV , 비주택대출 , 부동산정책 , 서울규제지역 , 대출규제 , 토지거래허가구역 , 정책해설 10월 15일 발표된 부동산 대책(10·15 대책) 이후 “오피스텔도 LTV 40% 로 줄었다”는 말이 돌고 있습니다. 하지만 이는 초기 문서와 보도 간 혼선 에서 비롯된 것으로, 정부 공식 해명에 따르면 비주택(오피스텔·상가)은 기존 LTV 70% 유지 가 맞습니다. 즉, 주택만 규제지역 지정으로 LTV 70% → 40% 이 적용됩니다. 1️⃣ 이번 대책의 핵심 변경점 규제지역 확대: 서울 전역과 경기 12곳이 조정대상지역·투기과열지구로 지정되었습니다. 주택 LTV: 규제지역 내 주택 구입 시 LTV 70% → 40% 로 하향 조정되었습니다. 토지거래허가구역: 서울 전역이 포함되며, 10월 20일경부터 효력이 발생합니다. 즉, 이번 대책의 직접적 영향은 **아파트 등 주택담보대출** 중심으로 적용됩니다. 2️⃣ “오피스텔도 40%?” — 혼선의 원인 정부 발표문 초안에는 “비주택 담보대출(오피스텔·상가) LTV 70% → 40%” 라는 문구가 포함되어 있었습니다. 언론이 이 문장을 그대로 인용하면서 “오피스텔도 40%로 제한된다”는 보도가 확산되었습니다. 하지만 이후 국토교통부와 금융위원회는 “ 비주택은 이번 규제 적용 대상이 아니다 ”라고 정정했습니다. 따라서 실제로는 **오피스텔 대출은 기존 70% LTV가 유지됩니다.** 3️⃣ 정부의 공식 정정 내용 오피스텔·상가 등은 비주택 으로 분류되어, 이번 주택담보대출 규제의 직접 적용 대상이 아님. ‘비주택 LTV 40%’ 표기는 자료 작성 오류 또는 과도한 포괄 표현 이었다고 정부가 해명함. 따라서 실무상으로는 기존처럼 LTV 70% 수준의 대출이 유지됩니다. 4️⃣ 실제로 어떻게 확인하면 될까요? 현재 금융기관별로 시행령 및 세부지...
자세한 내용 보기

Kubernetes Pod Pending 해결법: FailedScheduling 원인별 실전 점검 가이드

이미지
Kubernetes를 운영하다 보면 Deployment를 배포했는데 Pod가 Pending 상태에서 움직이지 않는 경우가 있습니다. 재시작부터 해보거나 무작정 노드를 증설하기 전에, 스케줄러가 남긴 이벤트를 읽으면 대부분의 원인을 빠르게 찾을 수 있습니다. 이 글에서는 실무에서 자주 만나는 FailedScheduling 메시지를 기준으로 CPU·메모리 부족, taint, nodeSelector, PVC, Pod 수 제한 문제를 순서대로 점검하는 방법을 정리합니다. 1. Pending은 장애 원인이 아니라 현재 상태다 Pending은 Pod 객체가 생성됐지만 아직 실행할 노드가 결정되지 않았거나, 컨테이너 실행에 필요한 준비가 끝나지 않았다는 뜻입니다. 따라서 kubectl get pods 결과만 보고는 원인을 알 수 없습니다. kubectl get pods -A --field-selector=status.phase=Pending 문제가 발생한 Pod를 찾았다면 가장 먼저 상세 정보와 이벤트를 확인합니다. kubectl describe pod <pod-name> -n <namespace> kubectl events -n <namespace> --for pod/<pod-name> describe 출력의 맨 아래 Events 영역에 있는 Reason과 Message가 핵심입니다. 여러 메시지가 반복된다면 가장 최근의 Warning / FailedScheduling 부터 읽습니다. 2. 가장 흔한 원인: CPU 또는 메모리 부족 다음과 같은 메시지가 보인다면 Pod가 요청한 리소스를 수용할 노드가 없다는 뜻입니다. 0/3 nodes are available: 3 Insufficient cpu. 0/3 nodes are available: 2 Insufficient memory. Kubernetes 스케줄러는 현재 사용률이 아니라 Pod에 설정된 resources.requests 의 합계를 기준으로...
자세한 내용 보기