코드 변경을 깊게 스캔해 소견과 패치 초안을 만들고 사람이 검토하며 자동 적용하지 않는 Claude Security 흐름

AI에게 로그인 화면을 맡기면 테스트는 쉽게 통과한다.

그런데 커밋 창 앞에서 자주 막힌다. 비밀번호 필드는 있는데, 잘못된 입력이나 권한 빠진 경로를 누가 봤는지 모른다. 리뷰어에게 “보안도 봐줘”라고 미루기 전에, 터미널에서 먼저 걸러 볼 도구가 있는지부터 알고 싶다.

그때 이름이 자주 나오는 것이 Claude Security다. 다만 같은 말이 여러 제품을 가리키므로, 터미널 플러그인이 무엇을 하고 무엇을 사람에게 남기는지만 좁혀 정리한다.

읽고 나면 “스캔 한 번 돌리면 끝”이 아니라 “커밋 전 깊은 점검 레이어”로 자리가 잡힌다.

먼저 같은 이름을 나누자

“Claude Security”라는 말은 한 제품만 가리키지 않는다.

확인한 공개 문서 기준으로는 크게 세 갈래가 있다.

  • Claude Security 플러그인: Claude Code 세션 안에서 /claude-security로 저장소나 변경 범위를 깊게 스캔한다.
  • security-guidance 플러그인: Claude가 코드를 쓰는 동안 변경을 자동으로 살펴 같은 세션에서 고치게 돕는다.
  • 관리형 Claude Security 제품: 연결된 저장소를 모니터링하는 호스팅 서비스로, 공개 설명 기준으로는 Enterprise 계획 중심이다.

여기서 다루는 대상은 첫 번째다. 터미널에서 코딩 에이전트와 같이 쓰는 플러그인이다.

2026-07-22 공식 계정 게시와 Claude Code 문서 기준으로, 플러그인은 베타로 쓸 수 있다고 안내된다. GA(정식 출시), 전 플랜 동일 조건, 가격 세부 사항은 단정하지 않는다. 설치와 사용 전에는 최신 공식 문서를 다시 본다.

한 줄로 보면 이것이다

커밋 전이나 머지 전에 코드 취약점을 깊게 훑고, 사람이 검토할 패치 초안까지 남기는 요청형 스캔이다.

공식 문서의 흐름은 단순하다.

플러그인 설치
-> /claude-security 로 전체 또는 변경 범위 스캔
-> 보고서 읽기
-> 고를 소견만 패치 제안
-> 사람이 검토한 뒤 git apply

중요한 문장이 하나 있다. 패치는 자동으로 적용되지 않는다. 적용은 항상 사람의 결정이다.

“보안 담당자를 대체하는 봇”으로 보면 기대가 어긋난다. 더 맞는 위치는 커밋 직전 또는 브랜치 점검 전에 소견을 좁혀 주는 깊은 스캔 레이어다.

무엇을 스캔하나

플러그인은 크게 두 방향으로 본다.

전체 스캔은 저장소 구조를 읽고, 위협 모델을 잡은 뒤, 여러 에이전트가 취약점을 찾고 다른 에이전트가 소견을 다시 검증한다. 큰 저장소에서는 한 번에 전체가 아니라 API 계층, 인증 코드처럼 범위를 나눠 돌리라고 문서가 권한다.

변경 범위 스캔은 브랜치 diff, pull request diff, 특정 커밋처럼 “이번 변경”만 본다. 커밋 전에 AI가 짠 코드만 빠르게 걸러 보고 싶을 때 이쪽이 맞다. 다만 변경 스캔은 커밋된 변경을 기준으로 한다. 작업 중인 파일을 아직 커밋하지 않았다면 먼저 커밋하거나 stash하거나 전체 스캔을 써야 한다.

스캔 결과는 저장소 안 타임스탬프 디렉터리에 남는다. 마크다운 보고서, 기계가 읽기 쉬운 결과 파일, 어떤 커밋을 어떤 설정으로 봤는지 찍은 기록이 함께 생긴다. 공식 설명에 따르면 이 디렉터리에는 자체 .gitignore가 있어 실수로 보고서가 커밋에 쓸려 들어가지 않게 돕는다.

소견에는 영향, 악용 시나리오, 심각도, 신뢰도, 권고가 붙는다. 패치 제안 단계로 넘어가면 각 소견에 대한 패치 파일이 생기고, 사람은 셸에서 적용한다.

git apply CLAUDE-SECURITY-타임스탬프/patches/F1.patch

패치는 소견마다 따로 pull request를 여는 쪽이 문서 권장이다. 한 번에 여러 수정을 섞으면 어떤 소견을 고친 것인지 나중에 추적하기 어렵다.

다른 검사와 뭐가 다른가

이름이 비슷한 도구를 한 줄씩 나눠 두면 헷갈림이 줄어든다.

  • security-guidance: 코딩 중에 자동으로 도는 가벼운·중간 깊이 검사. 설치 후 별도 명령을 외울 필요가 적다.
  • /security-review: 현재 브랜치를 한 번 훑는 요청형 검사.
  • Claude Security 플러그인: 저장소 또는 diff를 여러 에이전트로 깊게 보는 요청형 스캔과 패치 제안.
  • 관리형 Claude Security: 연결된 저장소를 호스팅 쪽에서 모니터링하는 제품 경로.
  • 기존 CI 정적 분석·의존성 스캐너: 규칙 기반, 공급망, 정책 강제처럼 결정적 검사.

공식 문서도 플러그인이 기존 소스 코드 보안 도구를 대체하지 않는다고 분명히 적는다. 패턴 매칭이 잘 잡는 것과, 여러 파일에 걸친 권한·데이터 흐름 문제를 추론하는 일은 서로 다른 층이다.

에이전트 훅 글에서 다루는 훅은 push나 위험 명령 앞에서 흐름을 끊는다. Claude Security 플러그인은 그 앞에서 코드 소견과 패치 초안을 모아 준다. 멈춤 장치와 소견 수집을 한 기능으로 묶지 않는 편이 낫다.

사람이 남겨야 하는 것

공식 FAQ와 플러그인 문서가 공통으로 강조하는 한계가 있다.

Claude는 틀린다. 제안된 패치는 특히 중요 시스템일수록 반드시 사람이 검토해야 한다.

문서에 드러난 실패 조건도 같이 적어두면 기대치가 맞는다.

  • 스캔은 비결정적이다. 같은 코드라도 두 번 돌리면 소견 목록이 달라지기도 한다.
  • 소견이 비어 있어도 취약점이 없다는 뜻은 아니다. 검증기를 거친 소견만 보고서에 오른다.
  • 패치는 자동 적용되지 않는다. 적용, 테스트, 머지 결정은 사람 몫이다.
  • 변경 스캔은 git이 필요하고, 전체 스캔은 버전 관리 밖 디렉터리에서도 돌아간다.
  • 스캔은 시간이 걸리고 토큰 사용량에 잡힌다. “공짜 배경 작업”이 아니다.
  • 플러그인 자체 전제 조건이 있다. 공개 문서 기준 Claude Code 버전, 유료 플랜, 동적 워크플로 설정, Python 버전 등을 확인해야 한다.

그래서 실무 기준은 단순하게 잡는다.

이미 커밋된 브랜치·PR·커밋 diff를 볼 것인가?
-> 변경 범위 스캔을 후보로 본다.

아직 커밋하지 않은 작업 트리 변경을 볼 것인가?
-> 전체 스캔을 후보로 본다. (변경 범위 스캔은 커밋된 변경만 본다)

새 서비스나 인증·권한 코드를 넓게 손댔는가?
-> 해당 디렉터리 중심 전체 스캔을 후보로 본다.

의존성 버전, 라이선스, 비밀키 유출, CI 정책 위반인가?
-> 기존 결정적 스캐너와 리뷰를 먼저 본다.

패치 제안이 나왔는가?
-> 테스트, diff, 영향 범위를 사람이 확인한 뒤에만 적용한다.

“스캔 통과”를 “보안 완료”로 바꾸지 않는 것이 핵심이다. 플러그인은 검토 목록을 줄여 주지만, 책임 있는 배포 판단을 넘겨받지는 않는다.

언제 쓰기 좋은가

쓰기 좋은 장면은 비교적 분명하다.

AI 코딩 에이전트로 기능을 만든 뒤, 커밋 전에 “이번 변경만” 깊게 보고 싶을 때. 인증, 권한, 입력 처리, 파일·네트워크 경계를 손댄 브랜치를 머지하기 전일 때. 관리형 제품이 닿기 어려운 로컬 저장소나 외부 호스팅 저장소를 Claude Code 세션 안에서 보고 싶을 때.

반대로 기대를 낮춰야 하는 장면도 있다.

  • 실시간으로 모든 편집을 막아 주는 방화벽처럼 쓰기
  • 펜테스트, 버그 바운티, 규정 준수 감사 전체를 대체하기
  • 한 번 돌려서 모든 취약점을 찾았다고 단정하기
  • 패치를 검토 없이 바로 메인 브랜치에 넣기

커뮤니티 반응에서도 비슷한 경계가 보인다. 공식 발표 직후 “커밋 전 터미널 스캔”이라는 위치는 환영받지만, 보안은 데모만으로 끝나지 않으니 실측을 기다리자는 말도 같이 나온다. 그 균형이 이 주제에는 맞다.

도구가 열렸다고 해서 검증이 끝난 것은 아니다. 무엇을 읽고 쓰고 실행했는지 확인하는 일과, 그 결과가 안전한지 다시 보는 일은 서로 다른 층이다. 실행 경계는 훅 글에서, 외부 자료·도구 통로는 MCP 글에서 나눠 둔 기준과 같이 보면 자리가 더 분명해진다.

정리

Claude Security 플러그인은 “AI가 짠 코드를 커밋하기 전에 취약점을 어디서 걸러야 하지?”라는 질문에 대한 공식 답 후보 중 하나다.

한 줄로 남기면 이렇다.

터미널 안에서 깊게 스캔하고,
소견과 패치 초안을 남기되,
적용과 최종 판단은 사람이 한다.

설치 명령과 메뉴 이름은 바뀔 수 있다. 지금 확인한 공개 문서 기준으로는 /plugin install claude-security@claude-plugins-official/claude-security 메뉴에서 전체 스캔, 변경 스캔, 패치 제안을 고른다.

다음에 같은 이름을 보면 이렇게 나누면 된다. 코딩 중 자동 검사인지, 요청형 깊은 스캔인지, 기업용 관리형 제품인지. 그 구분이 보이면 “Claude Security가 도대체 뭐야?”라는 질문은 훨씬 짧아진다.