Claude Code 보안 심층 분석 ⑤ — 놓치기 쉬운 것들: 코드 품질, 포렌식, 컴플라이언스

작성자:


이 글은 Claude Code 보안 심층 분석 시리즈의 마지막 편입니다. 전체 시리즈: [1편 조감도] → [2편 위협과 공격 표면] → [3편 탐지 전략] → [4편 통제와 한계] → [5편 놓치기 쉬운 것들]

들어가며

이 시리즈에서 지금까지 데이터 유출, 공급망 공격, 프롬프트 인젝션(2편), 탐지 방법(3편), 통제의 가능과 한계(4편)를 다뤘다. 이 주제들은 “Claude Code의 보안”이라고 하면 대부분의 보안 엔지니어가 먼저 떠올리는 영역이다.

이 마지막 편에서는 그 너머에 있는 것들을 다룬다. 당장 눈에 띄지 않지만, 장기적으로 조직에 실질적 영향을 미치는 리스크들이다. AI 생성 코드의 보안 품질, 침해 사고 시 포렌식과 증거 보전, 라이선스 컴플라이언스, 그리고 비용 폭증 리스크까지. 이 영역들은 “Claude Code 보안”이라는 프레임 안에서 논의되는 경우가 드물지만, 실무에서는 반드시 대비해야 한다.

1. AI 생성 코드의 보안 품질: 동전 던지기 수준의 안전성

현실의 수치

AI 코딩 도구가 생성하는 코드의 보안 품질에 대한 벤치마크 결과는 낙관적이지 않다.

BaxBench의 측정에 따르면 AI 생성 코드의 보안 취약률은 62%에 달한다. Veracode의 별도 측정에서도 45%라는 수치가 나왔다. 두 벤치마크의 방법론이 다르지만, 방향은 일관된다. AI가 생성한 코드의 절반 가까이(혹은 그 이상)가 보안 취약점을 포함하고 있다는 것이다.

이 수치가 중요한 이유는, Claude Code가 단순히 코드를 생성하는 것을 넘어 취약점을 수정하는 패치를 제안하는 역할까지 하기 때문이다. Anthropic의 Claude Code Security는 코드베이스에서 취약점을 찾아서 패치를 제안하는 기능이다. 그런데 AI가 제안한 패치 자체가 45~62%의 확률로 새로운 취약점을 도입할 수 있다면, 하나의 취약점을 고치면서 다른 취약점을 만드는 순환이 발생할 수 있다.

왜 AI 생성 코드가 취약한가

근본적인 원인은 LLM의 학습 데이터와 동작 방식에 있다.

학습 데이터의 품질 문제. LLM은 인터넷의 공개 코드를 학습한다. GitHub의 수많은 레포지토리에는 보안 모범 사례를 따르지 않는 코드가 넘쳐난다. 튜토리얼, 개인 프로젝트, 오래된 코드 등에서 학습한 패턴이 프로덕션 코드 생성에 그대로 적용된다.

기능 우선 편향. LLM은 “동작하는 코드”를 생성하도록 최적화되어 있다. 보안적으로 안전한 코드보다 기능적으로 정확한 코드를 우선시하는 경향이 있다. 입력 검증, 에러 핸들링, 권한 확인 같은 방어적 코딩은 기능과 직접 관련이 없으므로 생략되기 쉽다.

컨텍스트 한계. 보안적으로 안전한 코드를 작성하려면 전체 시스템 아키텍처, 인증 체계, 데이터 흐름을 이해해야 한다. LLM은 컨텍스트 윈도우에 포함된 정보만으로 코드를 생성하므로, 시스템 전체의 보안 맥락을 반영하기 어렵다.

구체적 취약점 유형

AI 생성 코드에서 빈번하게 발견되는 보안 취약점 유형은 다음과 같다.

SQL 인젝션. 문자열 결합으로 쿼리를 구성하는 패턴이 흔하다. 파라미터화된 쿼리(Prepared Statement)를 사용해야 하지만, 학습 데이터의 많은 예제가 문자열 결합 방식이므로 이를 그대로 재현한다.

하드코딩된 시크릿. 예제 코드의 API 키나 비밀번호를 그대로 포함하거나, 플레이스홀더가 아닌 실제 값처럼 보이는 문자열을 생성한다.

불충분한 입력 검증. 사용자 입력을 검증 없이 사용하는 코드를 생성하는 경우가 많다. XSS, 경로 탐색, 명령 인젝션 등의 취약점으로 이어진다.

안전하지 않은 기본 설정. CORS를 전체 허용하거나, 디버그 모드를 켜놓거나, TLS 인증서 검증을 비활성화하는 설정을 포함한 코드를 생성한다.

취약한 의존성. 오래된 라이브러리 버전이나 알려진 취약점이 있는 패키지를 의존성에 포함시키는 경우가 있다.

탐지와 대응

Git 기반 AI 코드 식별. Claude Code는 기본적으로 co-authored-by Claude 태그를 커밋에 포함한다. 이 태그가 있는 커밋을 자동으로 식별하여 추가 보안 검사 대상으로 분류한다.

# AI 생성 커밋 식별
git log --all --grep="Co-authored-by.*Claude" --format="%H %s" > ai-commits.txt

# 해당 커밋의 변경 파일에 대해 SAST 스캔
while read hash msg; do
    git diff-tree --no-commit-id --name-only -r "$hash" | while read file; do
        echo "SAST scan target: $file (commit: $hash)"
    done
done < ai-commits.txt

SAST/SCA 파이프라인 강화. AI 생성 코드에 대해서는 일반 코드보다 엄격한 정적 분석 규칙을 적용한다. 특히 SQL 쿼리 구성, 사용자 입력 처리, 인증/인가 로직, 암호화 관련 코드에 집중한다.

코드 리뷰 프로세스. AI 생성 코드에 대한 사람의 코드 리뷰를 강화한다. 특히 보안 관련 로직(인증, 권한, 암호화, 입력 검증)은 반드시 시니어 개발자의 리뷰를 거치도록 한다.

2. 인시던트 대응과 포렌식: 로컬 데이터의 증거 가치

Claude Code가 남기는 포렌식 아티팩트

Claude Code는 로컬 파일시스템에 상당히 풍부한 활동 기록을 남긴다. 침해 사고 시 이 데이터는 핵심 포렌식 증거가 된다.

~/.claude/history.jsonl — 모든 세션의 모든 프롬프트를 시간순으로 기록한다. 각 줄은 프롬프트 텍스트, 타임스탬프, 프로젝트 경로, 세션 ID를 포함하는 JSON 객체다. 이 파일을 분석하면 “어떤 프로젝트에서, 언제, 무슨 작업을 AI에게 요청했는지”를 시간순으로 재구성할 수 있다.

~/.claude/projects/{인코딩된-경로}/{sessionId}.jsonl — 전체 대화 기록이다. 사용자의 프롬프트뿐 아니라 Claude의 응답, 파일 수정 내역, 도구 호출 기록까지 포함된다. 어떤 파일이 읽혔고, 어떤 명령이 실행되었고, 어떤 코드가 생성되었는지를 완전하게 재현할 수 있다.

~/.claude/file-history/{sessionId}/ — 파일 수정 전 상태의 스냅샷이다. Claude Code가 파일을 변경할 때마다 변경 전 버전이 {fileHash}@v{version} 형식으로 저장된다. 이를 통해 AI가 수정한 코드의 변경 전후를 정확히 비교할 수 있다.

~/.claude/todos/{sessionId}-agent-{agentId}.json — 세션별, 에이전트별 태스크 목록이다. 어떤 작업이 계획되고 실행되었는지의 기록이다.

~/.claude/stats-cache.json — 일별 메시지 수, 세션 수, 도구 호출 수, 모델별 토큰 사용량 등 집계 통계다. 사용 패턴의 전체적인 윤곽을 파악하는 데 유용하다.

~/.claude.json — OAuth 세션 정보, MCP 서버 설정, 프로젝트별 허용 도구 등의 상태 데이터다. 침해 시점의 설정 상태를 확인하는 데 필요하다.

증거 보전의 문제

이 풍부한 포렌식 데이터에는 치명적인 약점이 있다. 모두 로컬 파일이라는 점이다.

개발자가 의도적으로든 실수로든 ~/.claude/ 디렉토리를 삭제하면 모든 증거가 소멸된다. rm -rf ~/.claude한 줄이면 충분하다. Claude Code 자체에도 cleanupPeriodDays 설정이 있어, 기본값 30일이 지난 세션 데이터는 자동으로 삭제된다.

또한 history.jsonl은 append-only이지만, 무결성 검증 메커니즘(해시 체인, 디지털 서명 등)이 없다. 파일 내용이 수정되거나 특정 줄이 삭제되어도 이를 탐지할 방법이 없다.

증거 보전 전략

사전 수집. 침해가 발생하기 전에, 주기적으로 포렌식 데이터를 중앙 저장소로 백업한다.

#!/bin/bash
# claude-evidence-backup.sh
# Claude Code 포렌식 데이터 주기적 백업

BACKUP_DIR="/secure/backups/claude/$(hostname)/$(date +%Y%m%d)"
mkdir -p "$BACKUP_DIR"

# 핵심 포렌식 파일 백업
cp -p "$HOME/.claude/history.jsonl" "$BACKUP_DIR/" 2>/dev/null
cp -p "$HOME/.claude/stats-cache.json" "$BACKUP_DIR/" 2>/dev/null
cp -p "$HOME/.claude.json" "$BACKUP_DIR/" 2>/dev/null

# 프로젝트별 세션 데이터 백업
if [ -d "$HOME/.claude/projects" ]; then
    tar czf "$BACKUP_DIR/projects.tar.gz" -C "$HOME/.claude" projects/
fi

# 파일 히스토리 백업
if [ -d "$HOME/.claude/file-history" ]; then
    tar czf "$BACKUP_DIR/file-history.tar.gz" -C "$HOME/.claude" file-history/
fi

# 무결성 해시 생성
find "$BACKUP_DIR" -type f -exec sha256sum {} \; > "$BACKUP_DIR/checksums.sha256"

echo "Backup completed: $BACKUP_DIR"

이 스크립트를 일일 cron으로 실행하면, 최소한 일 단위의 포렌식 타임라인을 확보할 수 있다.

EDR 파일 모니터링. EDR 도구에서 ~/.claude/ 디렉토리에 대한 삭제 이벤트를 모니터링한다. 대량 삭제가 감지되면 즉시 알림을 발생시키고, 가능하다면 삭제 전 스냅샷을 확보한다.

cleanupPeriodDays 조정. managed-settings.json에서 cleanupPeriodDays를 조직의 데이터 보존 정책에 맞게 설정한다. 0으로 설정하면 즉시 삭제, 높은 값으로 설정하면 오래 보존된다. 포렌식 관점에서는 가능한 한 길게 보존하는 것이 좋지만, 개인정보 보호 관점에서는 최소한으로 유지해야 하므로 균형이 필요하다.

네트워크 로그 보완. 로컬 데이터가 삭제되더라도, 프록시/방화벽의 네트워크 로그는 별도로 보존된다. api.anthropic.com으로의 트래픽 로그(타임스탬프, 소스 IP, 요청 크기)는 로컬 데이터의 부재를 부분적으로 보완할 수 있다.

침해 조사 시 확인 사항

실제 인시던트가 발생했을 때, 다음 순서로 Claude Code 관련 증거를 확인한다.

  1. ~/.claude/ 디렉토리 존재 여부 및 최종 수정 시간 확인
  2. history.jsonl 분석: 침해 시점 전후의 프롬프트 내용, 특히 민감 데이터 포함 여부
  3. projects/ 내 해당 세션의 전체 대화 기록 복원
  4. file-history/ 에서 AI가 수정한 파일의 변경 전후 비교
  5. .claude.json 에서 침해 시점의 MCP 서버 설정, OAuth 상태 확인
  6. stats-cache.json 에서 비정상적 사용 패턴(급격한 세션 수 증가 등) 확인
  7. 네트워크 로그에서 api.anthropic.com으로의 비정상 트래픽 확인

3. 라이선스 컴플라이언스: 의도치 않은 위반

문제의 본질

Claude Code가 생성하는 코드는 LLM의 학습 데이터에서 파생된다. 학습 데이터에는 다양한 오픈소스 라이선스(GPL, MIT, Apache, BSD 등)가 적용된 코드가 포함되어 있다. AI가 생성한 코드가 학습 데이터의 특정 코드와 유사하거나 동일할 경우, 원본 코드의 라이선스 의무가 발생할 수 있다.

이것은 아직 법적으로 완전히 정리되지 않은 영역이다. 그러나 리스크 관점에서 무시할 수 없다.

구체적 시나리오

GPL 오염. AI가 GPL 라이선스 코드를 학습하여 유사한 코드를 생성했고, 이것이 상용 소프트웨어에 포함된 경우, GPL의 카피레프트 조항에 따라 전체 소프트웨어의 소스코드를 공개해야 할 수 있다. 의도치 않게 GPL 코드가 섞여 들어오는 것을 “GPL 오염”이라고 부르며, 이는 상용 소프트웨어 개발에서 심각한 법적 리스크다.

저작권 침해. 특정 오픈소스 프로젝트의 코드와 실질적으로 동일한 코드를 AI가 생성하여 사용하는 경우, 저작권 침해에 해당할 수 있다. 현재 미국, EU 등에서 AI 생성물의 저작권에 대한 법적 논의가 진행 중이며, 판례가 확립되지 않은 상태다.

라이선스 의무 미이행. MIT, Apache 등의 허용적(permissive) 라이선스도 저작권 고지, 라이선스 텍스트 포함 등의 의무가 있다. AI가 이런 라이선스의 코드를 기반으로 생성한 코드에는 이 의무가 이행되지 않는다.

대응 방안

SCA(Software Composition Analysis) 도구 적용. AI 생성 코드에 대해 SCA 도구를 실행하여, 알려진 오픈소스 코드와의 유사도를 검사한다. 높은 유사도가 발견되면 원본 라이선스를 확인하고 적절한 조치를 취한다.

라이선스 정책 수립. 조직의 AI 코딩 도구 사용 정책에 라이선스 관련 조항을 포함한다. 특히 상용 소프트웨어 개발 시 AI 생성 코드의 라이선스 리뷰 절차를 정의한다.

Anthropic 데이터 정책 확인. Anthropic은 상업 계약 하에서 고객 코드를 모델 훈련에 사용하지 않는다고 명시하고 있지만, 반대 방향(학습 데이터의 코드가 고객에게 생성되는 것)에 대한 면책 조항은 별도로 확인해야 한다.

4. 비용 폭증 리스크: API 키 탈취의 재정적 영향

공격 시나리오

2편에서 다룬 API 키 탈취(CVE-2026-21852)는 보안 침해일 뿐 아니라 직접적인 재정 리스크다.

공격자가 탈취한 API 키로 대량의 API 호출을 수행하면, 조직에 예상치 못한 비용이 청구된다. Anthropic의 API 과금은 입력/출력 토큰 기준이므로, 대규모 컨텍스트 윈도우를 활용한 호출을 반복하면 비용이 빠르게 증가한다.

Workspaces로 인한 피해 확대

API 키가 Workspace에 연결되어 있는 경우, 단일 키 탈취로 해당 Workspace의 모든 리소스에 접근할 수 있다. 공격자는 탈취한 키로 다른 프로젝트의 데이터에 접근하거나, 추가 API 키를 생성하거나, 조직의 사용량 한도를 소진시킬 수 있다.

구체적 비용 시나리오

Claude Opus 모델 기준으로, 200K 토큰 컨텍스트 윈도우를 활용한 단일 요청의 비용은 상당하다. 공격자가 이를 자동화하여 시간당 수백 건의 요청을 보내면, 하루 만에 수천~수만 달러의 비용이 발생할 수 있다.

특히 위험한 것은, 공격자가 비용 소진 자체를 목적으로 하는 경우다. 서비스 거부(DoS)와 유사하게, 조직의 API 사용량 한도를 소진시켜 정상적인 개발 작업을 방해할 수 있다.

예방과 대응

API 키 관리 강화. API 키를 코드, 환경변수 파일, 설정 파일에 하드코딩하지 않는다. 비밀 관리 도구(Vault, AWS Secrets Manager 등)를 사용하고, 정기적으로 키를 로테이션한다.

사용량 한도 설정. Anthropic Console에서 API 키별, Workspace별 사용량 한도를 설정한다. 한도에 도달하면 즉시 알림을 받고, 필요 시 키를 비활성화한다.

비정상 사용 패턴 모니터링. API 사용량의 급격한 증가, 비정상적 시간대의 호출, 평소와 다른 모델 사용 패턴 등을 모니터링한다. Anthropic의 Analytics API를 활용하면 일별 사용자 활동을 추적할 수 있다.

ANTHROPIC_BASE_URL 변조 탐지. 3편에서 다룬 환경변수 검사를 정기적으로 수행하여, API 트래픽이 정상 엔드포인트(api.anthropic.com)로 향하고 있는지 확인한다.

인시던트 대응 절차. API 키 탈취가 의심되면 즉시 해당 키를 폐기하고 새 키를 발급한다. 탈취 기간 동안의 API 호출 로그를 검토하여 어떤 데이터가 접근되었는지 파악한다. Anthropic 지원팀에 연락하여 비정상 과금에 대한 조치를 요청한다.

5. 추가 고려사항

Anthropic의 데이터 보존 정책

Anthropic의 데이터 보존 정책은 계정 유형에 따라 다르며, 조직의 컴플라이언스 요구사항과 충돌할 수 있다.

소비자 계정(Free, Pro, Max)에서는 사용자가 데이터 개선 옵트인 시 데이터가 모델 훈련에 사용될 수 있다. /bug 명령으로 전송된 대화 기록은 5년간 보존된다.

상업용 계정(Team, Enterprise, API)에서는 모델 훈련에 데이터를 사용하지 않지만, 안전 및 남용 방지를 위한 데이터 보존 기간이 존재한다.

GDPR, HIPAA 등 규제 환경에서는 이 보존 정책이 데이터 최소화 원칙이나 삭제권과 충돌할 수 있다. 특히 개인정보가 포함된 코드를 Claude Code로 작업한 경우, 해당 데이터가 Anthropic 서버에 보존되는 기간과 조건을 확인해야 한다.

모델 투명성의 한계

보안 팀은 Claude Code가 어떻게 응답을 생성하는지 완전히 감사할 수 없다. 모델의 의사결정 과정은 블랙박스이며, 동일한 입력에 대해서도 매번 다른 출력이 나올 수 있다(확률적 특성). 이는 보안 사고 조사 시 “왜 Claude가 이런 코드를 생성했는가”에 대한 정확한 원인 분석을 어렵게 만든다.

규제 환경의 변화

EU AI Act는 고위험 AI 시스템에 대한 투명성, 설명 가능성, 인간 감독 요구사항을 규정한다. AI 코딩 도구가 이 규제의 적용 대상에 포함될 가능성이 있으며, 이 경우 AI 생성 코드에 대한 추가적인 문서화, 감사, 리스크 평가 의무가 발생할 수 있다.

NIST AI Risk Management Framework (AI RMF)는 AI 시스템의 위험 관리를 위한 프레임워크를 제공한다. 프롬프트 인젝션에 대한 위협 모델링이 명시적으로 요구되며, Claude Code 사용 시 이 프레임워크에 따른 리스크 평가를 수행하는 것이 권장된다.

ISO 42001은 AI 관리 시스템 표준으로, 입력 조작 및 무단 지시 수정에 대한 리스크 평가를 요구한다. Claude Code의 프롬프트 인젝션 위험은 이 표준의 평가 대상에 해당한다.

6. 전체 시리즈 종합: 실행 체크리스트

이 시리즈에서 다룬 모든 내용을 실행 가능한 체크리스트로 정리한다.

즉시 실행 (1주 내)

  • [ ] 조직 내 Claude Code 사용 현황 파악: 3편의 탐지 스크립트 실행
  • [ ] 민감 프로젝트 식별: AI 코딩 도구 사용이 특히 위험한 프로젝트 목록 작성
  • [ ] API 키 감사: 사용 중인 모든 Anthropic API 키의 소유자, 권한, Workspace 연결 확인
  • [ ] ANTHROPIC_BASE_URL 변조 확인: 모든 개발 기기에서 환경변수 검사

단기 실행 (1개월 내)

  • [ ] AI 코딩 도구 사용 정책 수립: 허용 범위, 데이터 제한, 계정 요구사항 문서화
  • [ ] managed-settings.json 배포: 관리형 기기에 민감 파일 접근 차단 설정
  • [ ] CI/CD 보안 검사 추가: .claude/, .mcp.json 변경 시 자동 리뷰 트리거
  • [ ] 보안 교육 실시: 데이터 전송, 시크릿 관리, 레포지토리 신뢰에 대한 인식 제고

중기 실행 (분기 내)

  • [ ] 네트워크 모니터링 구축: api.anthropic.com 트래픽 로깅 및 이상 탐지
  • [ ] AI 생성 코드 SAST 강화: co-authored-by Claude 커밋에 대한 추가 보안 스캔
  • [ ] 포렌식 데이터 백업 체계 구축: history.jsonl, projects/ 주기적 백업
  • [ ] 라이선스 리뷰 프로세스 수립: AI 생성 코드의 SCA 검사 절차

장기 실행 (연간)

  • [ ] 보안 성숙도 평가: AI 코딩 도구 거버넌스 체계의 효과성 측정
  • [ ] 규제 컴플라이언스 검토: EU AI Act, NIST AI RMF, ISO 42001 대응 상태 점검
  • [ ] 인시던트 대응 훈련: Claude Code 관련 침해 시나리오를 포함한 대응 훈련
  • [ ] 정책 갱신: 기술 변화와 규제 변화를 반영하여 정책 업데이트

시리즈를 마치며

이 시리즈의 출발점은 단순한 질문이었다. “Claude Code의 .claude 디렉토리가 어떻게 생겼는가?” 그 질문에서 출발하여, 디렉토리 구조가 왜 보안적으로 중요한지(2편), 어떻게 탐지하는지(3편), 무엇을 통제할 수 있고 무엇은 불가능한지(4편), 그리고 탐지와 통제 너머에 무엇이 있는지(5편)까지 다뤘다.

핵심 메시지는 세 가지로 압축된다.

첫째, Claude Code는 강력한 도구이고, 강력한 도구에는 보안 거버넌스가 필수다. 개발자와 동일한 시스템 권한으로 동작하는 AI 에이전트를 거버넌스 없이 채택하는 것은, 모든 개발자에게 프로덕션 서버의 루트 권한을 주면서 감사 로그를 남기지 않는 것과 다르지 않다.

둘째, 완벽한 통제는 불가능하다. 클라이언트 측 도구의 구조적 한계를 인정하고, 기술적 통제·탐지·정책·교육을 겹겹이 쌓는 심층 방어가 현실적 답이다.

셋째, 이것은 Claude Code만의 문제가 아니다. GitHub Copilot, Cursor, ChatGPT, Gemini 등 모든 AI 코딩 도구에 동일한 프레임워크를 적용해야 한다. Shadow AI 거버넌스는 특정 도구가 아니라 AI 도구 전체에 대한 조직적 대응이다.

AI 코딩 도구의 보안은 아직 초기 단계다. 기술도, 규제도, 모범 사례도 빠르게 변하고 있다. 이 시리즈가 현 시점에서의 실무적 기준점이 되기를 바란다.



댓글 남기기