• Anthropic이 2026년 5월 하순에 Claude Code를 위한 공식 플러그인인 security-guidance를 공개했습니다(각 미디어에서 소개된 것은 5월 27일입니다). 모든 플랜에서 이용 가능하며, 2026년 6월 시점에서 베타 표기는 없습니다. 다만 모델에 의한 리뷰는 통상적인 Claude 이용 한도를 소비합니다. "파일 편집 시 / 턴 종료 시 / 커밋(commit)이나 푸시(push) 시"의 3단계로 취약성을 탐지하고, 탐지한 내용을 그대로 AI가 수정하게 하는 흐름이 특징입니다.
• Anthropic의 사내 벤치마크(공식 발표를 미디어가 인용한 것으로, 공식 문서 본문에는 기재되어 있지 않음)에 따르면, 이 플러그인을 사용하여 연 풀 리퀘스트(Pull Request)에 달리는 보안 관련 코멘트가 30~40% 감소했다고 하며, 리뷰 전의 빠른 단계에서 문제를 해결하는 용도로 적합해 보입니다.
• 다만 "AI가 코드를 작성함 → AI가 수정함"이라는 루프 자체는 감사 대상으로 남기 때문에, Snyk / CodeQL / SAST와의 병용이나, Anthropic이 정리하고 있는 "봉쇄 설계 (Containment Design)"의 사고방식을 바탕으로 한 운용이 현실적이라고 생각합니다.

이 기사는 2026년 5월 말에 공개하였고, 2026년 6월 30일에 공식 문서(code.claude.com)에서 각 기술 내용을 재확인한 후 내용을 업데이트했습니다. 플러그인 이름, 설치 명령어, 전제 버전, 3단계 구성은 재확인 시점에도 변경되지 않았습니다.

이 플러그인의 사용법을 "/plugin install을 입력하면 끝"이라고만 소개하는 것은 아마도 본질을 벗어난 것이라고 느낍니다. 절차 자체는 몇 줄로 끝나기 때문에, 본 기사에서는 오히려 "왜 이런 종류의 플러그인이 지금 이 타이밍에 필요하게 되었는가", "AI가 작성한 코드의 취약성 탐지는 기존의 보안 검사와 무엇이 어떻게 다른가"라는 배경에 지면을 할애해 보겠습니다.

Claude Code를 비롯한 에이전트적인 코딩 지원이 일상에 들어오면, 개발 현장에서는 "인간이 한 줄씩 쓰고, 인간이 리뷰한다"라는 전제가 무너집니다. AI가 수백 줄을 한꺼번에 생성하고, 다른 AI가 그것을 고치며, 또 다른 세션에서 기능을 추가해 나갑니다. 이때 자연스럽게 떠오르는 의문은 "그렇다면 그 대량의 코드를 최종적으로 누가(혹은 무엇이) 리뷰하는가"라는 것입니다. security-guidance는 이 구조적인 질문에 대한 Anthropic 측의 하나의 답변으로 읽을 수 있다고 생각합니다.

본 기사에서는 이 플러그인의 위치 설정과 사용법을 짚어보면서, 그 이전에 있는 위협 모델의 변화, 3단계 분석이 공격면(Attack Surface)의 어디에 대응하고 있는지, AI에게 수정을 맡기는 것 자체의 리스크, 그리고 기존 도구와의 구분(棲み分け)을 "사상의 차이"로부터 정리해 보겠습니다. AI와 DevSecOps가 교차하는 영역에 관심이 있는 분들에게 닿기를 바랍니다.

기존의 소프트웨어 개발에서는 코드를 쓰는 속도에 인간의 손이 병목(Bottleneck)으로 작용했습니다. 하루에 인간이 쓸 수 있는 코드량에는 상한이 있었고, 리뷰하는 측도 대략 그 속도에 따라갈 수 있었던 것입니다. 리뷰가 따라가지 못하더라도 그것은 "인력이 부족하다"라는 양의 문제였지, 구조 자체가 파탄 난 것은 아니었습니다.

에이전트적 코딩이 보급되면 이 전제가 바뀝니다. 생성 측의 속도가 인간의 리뷰 속도를 크게 앞지르기 시작하면, "쓰는 것"과 "확인하는 것" 사이에 항구적인 격차가 발생합니다. 게다가 그 격차는 사람을 늘린다고 해서 쉽게 메워지지 않습니다. 생성 측도 함께 스케일링되기 때문입니다. 여기에 "AI가 대량으로 작성한 코드를 누가 리뷰하는가"라는, 양이 아닌 구조에 뿌리를 둔 질문이 등장했다고 파악하고 있습니다.

이 질문에 대한 응답 방향성은 몇 가지 생각할 수 있습니다. 예를 들어 "생성을 늦춰서 리뷰에 맞춘다", "리뷰도 자동화하여 생성에 추종시킨다", "애초에 위험한 방식이 생성 단계에서 나오지 않도록 한다"와 같은 방식입니다. security-guidance는 이 중 주로 뒤의 두 가지, 즉 "검사를 생성 근처에 배치하여 위험한 방식을 그 자리에서 없앤다"라는 방향으로 치우친 설계로 보입니다. 생성과 검사의 거리를 좁힘으로써 격차가 확대되기 전에 닫으려는 발상이라고 이해하고 있습니다.

서드파티 (Third-party) 보안 도구는 이전부터 수없이 많았습니다. 그럼에도 Anthropic 스스로가 플러그인을 출시한 것에는 몇 가지 의미가 있다고 느낍니다. 하나는 Claude가 생성하는 순간의 컨텍스트 (직전의 편집 차분, 세션 내의 의도, 도구 출력 등)에 가장 가까운 위치에서 동작할 수 있는 것은 Claude Code 본체에 통합된 메커니즘이라는 점입니다. 외부 도구는 생성이 끝나고 출력된 코드를 나중에 보지만, 통합된 메커니즘은 '작성 중'인 문맥을 그대로 사용할 수 있습니다.

또 다른 하나는, AI가 작성한 코드 특유의 실패 패턴을 생성 측 벤더가 가장 잘 파악할 수 있는 입장에 있다는 점입니다. 어떤 입력에서 어떤 오류가 발생하기 쉬운지는 모델을 훈련 및 운용하는 측에 지견이 쌓입니다. 그 지견을 검사 측에도 반영할 수 있는 것은 동일한 제공처만이 가질 수 있는 강점이라고 생각합니다. 다만, 이것은 '공식이라서 안심할 수 있다'는 이야기가 아니라, '공식이기 때문에 파악할 수 있는 실패 패턴이 있는 반면, 간과하는 범위도 당연히 존재한다'는 양면성으로 파악하는 것이 타당하다고 느낍니다.

이 부분이 본 기사에서 가장 심도 있게 다루고 싶은 대목입니다. AI가 작성한 코드의 위험성은 양이 많다는 점 이상으로, 위험의 질이 기존과 다르다는 점에 있다고 생각합니다.

인간의 리뷰는 오랜 기간 쌓아온 '인간이 저지르기 쉬운 실수'의 패턴 인식에 의해 지탱됩니다. off-by-one, null 체크 누락, 락 (Lock) 망각, 전형적인 SQL 구성 실수 등이 그것입니다. 그런데 AI는 인간과는 다른 통계적인 경향으로 코드를 생성합니다. 학습 데이터의 분포에 끌려가서, 문맥적으로는 그럴듯하지만 국소적으로는 불일치하는 작성 방식을 섞어서 내놓을 때가 있습니다.

문제는 이러한 '인간은 작성하지 않는 패턴'의 실수에 대해, 인간 리뷰어의 직관적인 경고(Alert)가 울리기 어렵다는 점입니다. 겉보기에 자연스럽고, 변수명도 타당하며, 주석까지 정성스럽게 달려 있으면 리뷰어는 '제대로 생각해서 작성된 코드'로 읽고 지나치기 쉽습니다. 유창함이 오히려 경계심을 낮추는 방향으로 작용하는 것입니다.

기능을 구현하기 위해 AI가 라이브러리 추가를 제안할 때가 있습니다. 대부분은 타당하지만, 때로는 '하고 싶은 일에 비해 과도한 권한을 요구하는 라이브러리'나 '유지보수가 중단된 오래된 패키지', '이름은 비슷하지만 목적이 다른 패키지'를 자연스러운 말투로 권할 때가 있습니다.

의존성(Dependency) 추가는 코드 본체보다 공격 표면(Attack Surface)을 넓히기 쉬운 작업입니다. 의존성을 하나 추가하면, 그 의존성이 다시 끌어오는 의존성(전이적 의존성, Transitive Dependency)까지 포함하여 프로젝트에 도입됩니다. AI의 제안은 문장으로서 설득력이 있기 때문에, 리뷰어가 '그럴듯하니까'라며 받아들여 버리면 공격 표면이 조용히 확대될 수 있습니다.

나아가 고유한 리스크로서, AI가 존재하지 않는 패키지 이름을 자신만만하게 생성해 버리는 현상이 있습니다. 이것 자체는 단순한 오류이지만, 악용 경로로 이어질 수 있다는 점이 까다롭습니다. 공격자가 AI가 자주 환각(Hallucination)하는 이름을 선점하여 실재하는 패키지로 등록해 둔다면, 그 이름을 믿고 설치한 개발자가 악의적인 코드를 도입하게 된다는 시나리오가 성립될 수 있습니다.

이러한 수법은 'slopsquatting'이라고 불리기도 합니다. 기존의 타이포스쿼팅(Typosquatting, 오타를 노리는 수법)이 인간의 타이핑 실수를 전제로 했다면, slopsquatting은 AI의 환각을 전제로 한다는 점에서 그야말로 AI 시대에 고유한 리스크라고 할 수 있습니다.

slopsquatting을 포함한 공급망 공격(Supply Chain Attack)의 구체적인 수법이나 대책은 상황에 따라 크게 달라집니다. 여기서의 기술은 개념 정리를 목적으로 한 것이므로, 실제 대책을 검토할 때는 이용 중인 패키지 레지스트리나 보안 벤더의 최신 공식 정보를 확인하는 것이 안전하다고 생각합니다.

기존의 위협 모델이 '인간이 일으키는 실수나 외부 공격자가 시도하는 공격'을 주로 상정했다면, AI 시대에는 '그럴듯함으로 경계심을 해제하는 생성물'이라는 새로운 축이 추가되었다고 정리하고 있습니다. 유창하고 설득력이 있기 때문에 오히려 그냥 지나치기 쉽다는 점이 공통분모입니다. 그렇다면 검사 측도 '딱 봐도 이상한 코드'뿐만 아니라, '자연스러워 보이지만 위험한 코드'를 잡아내는 방향으로 무게 중심을 옮길 필요가 있습니다.

security-guidance의 특징은 리뷰를 한 번으로 끝내지 않고, 개발 흐름의 서로 다른 타이밍에 3단계로 끼워 넣고 있다는 점입니다. 기사와 Anthropic의 설명을 정리하면 대략 다음과 같은 구성이 됩니다.

레이어	트리거 타이밍	주요 처리	비용 체감
1. 패턴 매칭 (Pattern Matching)	파일 편집 시 (Edit / Write / NotebookEdit 직후)	위험한 라이브러리 호출이나 알려진 악성 패턴을 결정론적(Deterministic)으로 고속 탐지 (모델 호출 없음)	가벼움, 토큰 소비 없음
2. 턴 종료 리뷰 (Turn-end Review)	1 턴 분량의 변경 사항이 정리된 시점	백그라운드에서 모델이 git 차이점(diff)을 리뷰하여 누락된 부분을 재확인하고 Claude에게 피드백 제공	중간
3. 커밋 시 리뷰 (Commit-time Review)	git commit / git push 직전	주변 코드 및 호출부까지 읽어 들여 본격적인 에이전트 리뷰 수행	무거움

공식 문서를 읽어보면, 각 레이어에는 실제 운영상의 상한선과 전제 조건이 설정되어 있습니다. 레이어 2는 1회당 최대 30개 파일, 연속 3회까지, 레이어 3은 대략 시간당 20회까지와 같은 방식으로 비용이 과도하게 늘어나지 않도록 조정되어 있습니다. 레이어 2와 3은 git 리포지토리(Repository) 내에서만 작동하며, 리포지토리 외부에서는 스킵됩니다.

여기서 한 가지 주의해야 할 점은, 커밋 시 리뷰(레이어 3)가 작동하는 것은 어디까지나 Claude가 Bash 도구를 통해 git commit / git push를 실행했을 때로 한정된다는 동작 방식입니다. ! 쉘 이스케이프(Shell Escape)를 통해 직접 커밋하거나, 사용자가 자신의 터미널에서 수동으로 커밋하는 경우에는 리뷰 대상이 되지 않습니다. "커밋만 하면 반드시 최종 체크가 돌아간다"라고 믿어버리면 놓치는 부분이 생기기 쉬우므로, 운영에 도입할 때는 반드시 숙지해야 할 점이라고 느꼈습니다.

여기서 의식해야 할 점은, 3개의 레이어가 각각 서로 다른 공격 표면(Attack Surface)에 작용하고 있다는 점입니다. 서두에서 언급한 "의존성·코드·설정"이라는 관점에서, 어떤 레이어가 어떤 공격 표면에 대응하기 쉬운지 정리해 보겠습니다.

코드 인젝션(Code Injection), 안전하지 않은 역직렬화(Unsafe Deserialization), 위험한 DOM 조작, 인증 우회(Authentication Bypass)와 같이 소스 코드 내에 직접 나타나는 취약점입니다. 이것들은 비교적 "위험한 작성 방식의 형태"가 정해져 있기 때문에, 파일 편집 시의 패턴 매칭(레이어 1)에서 첫 단계를 잡아내고, 턴 종료 리뷰(레이어 2)에서 문맥을 고려하여 누락된 부분을 재확인하는 2단계 방어 체계가 효과적인 영역이라고 생각합니다.

작성 직후 그 자리에서 피드백이 돌아오므로, 2-1에서 언급한 "유창함 때문에 그냥 지나치는 현상"을 인간이 읽고 넘어가기 전에 기계 측에서 한 번 걸러주는 형태가 됩니다.

2-2나 2-3에서 언급한 과도한 의존성 추가나 존재하지 않는 패키지의 혼입은 단 한 줄의 패턴만으로는 판단하기 어렵습니다. "이 기능에 이 의존성이 타당한가", "이 패키지는 실제로 존재하는가, 유지보수되고 있는가"와 같은 판단에는 변경 사항 전체나 프로젝트의 문맥이 필요합니다. 그렇다면 변경 이력 전체를 보는 턴 종료 리뷰(레이어 2)나, 주변 코드까지 읽어 들이는 커밋 시 리뷰(레이어 3)가 더 적합해 보입니다.

다만, 의존성 취약점 관리 자체는 후술하겠지만 전용 도구(Snyk 등)의 영역이 넓으며, 이 플러그인 단독으로 모든 것이 해결되는 문제는 아니라고 판단하고 있습니다.

권한 설정, 시크릿(Secret) 취급, CORS나 인증 흐름 구성과 같은 "설정 측면"의 문제는 단일 파일만 봐서는 알아채기 어렵고, 여러 파일에 걸친 문맥을 읽어야 비로소 위험성이 보이는 종류의 것입니다. 주변 코드를 읽으러 가는 커밋 시 리뷰(레이어 3)가 상대적으로 이 측면에 깊이 파고들기 쉬울 것으로 생각합니다.

이처럼 3개 층은 단순한 "만약을 위한 다중 체크"가 아니라, 가벼운 패턴 매칭으로 잡을 수 있는 공격 표면부터 문맥을 요하는 공격 표면까지 단계적으로 커버 범위를 넓혀가는 구조로 이해하면 납득이 갑니다. 탐지 대상으로 기사 내에서 언급된 것은 코드 인젝션, 위험한 역직렬화, DOM 조작 문제, 인증 우회와 같은 대표적인 예시이지만, 포괄성에 대해서는 공식 문서의 기재 내용이 1차 정보이므로, 자신의 스택에서 어디까지 효과가 있을지는 도입 후에 확인해 보고 싶은 부분입니다.

여기서 잠시 기존 방식의 검사 기법으로 돌아가 보겠습니다. SAST(정적 분석)나 DAST(동적 분석)는 오랫동안 보안 검사의 주축이었습니다. 이것들이 AI 시대에 "불필요해지는" 것은 아니라고 생각하지만, 그것만으로는 따라잡기 어려운 구조가 있는 것도 사실이라고 느낍니다.

하나는 속도의 미스매치(Mismatch)입니다. SAST/DAST는 CI나 정기 스캔에서 동작하는 경우가 많아, 피드백이 돌아오는 시점은 대부분 코드를 다 작성하고 나서 한참이 지난 후입니다. 생성 속도가 빨라진 상황에서는 검사 결과가 돌아올 때쯤이면 이미 다음 생성이 쌓여 있어, 피드백 루프(Feedback Loop)가 상시적으로 뒤처지기 쉽습니다. 작성자 본인(또는 AI)의 문맥(Context)이 식어버린 뒤에 지적이 들어오면, 수정 비용이 높아지기 쉽기 때문입니다.

또 다른 하나는 문맥(Context) 부족입니다. CI 단계의 도구는 최종적으로 출력된 코드는 볼 수 있지만, "왜 그렇게 작성했는지", "어떤 의도로 이 의존성(Dependency)을 추가했는지"와 같은 생성 당시의 문맥까지는 파악하지 못합니다. AI 생성 코드의 위험성이 "그럴듯함"에 있다면, 그 문맥을 결여한 채 형태만 봐서는 자연스러워 보이는 위험성을 포착하기 어려울 수 있습니다.

나아가, 오탐(False Positive)과 미탐(False Negative)의 구조적 문제도 있습니다. 규칙 기반(Rule-based)의 SAST는 오탐이 많으면 운영 측이 지쳐 경고를 무시하는 습관이 생깁니다. 반대로 너무 엄격하게 조정하면 미탐이 발생합니다. 이러한 조정의 어려움 자체는 기존부터 있었으나, 생성량이 늘어나면 경고의 절대수도 늘어나기 때문에 "알람 피로(Alert Fatigue)\

상태로 두면, 파일 편집 시의 패턴 매칭 계층(Layer 1)에서 shell=True와 외부 입력의 결합을 포함하는 조합이 걸러집니다. 이어서 턴 종료 시(Layer 2)에 "이것은 인수를 분할하여 호출하는 것이 더 안전해 보입니다. 수정안을 제시할까요?"라고 Claude가 자발적으로 제안하는 흐름이 됩니다. 이는 3-1에서 다룬 "코드 자체에 대한 공격 표면(Attack Surface)"을 이중 구조로 포착하는 전형적인 사례라고 정리할 수 있습니다.

수정 후의 코드는 대체로 다음과 같은 형태가 될 것입니다.

import subprocess
from pathlib import Path
def run_backup(filename: str) -> str:
...

또 다른 흔한 사례는 외부에서 받은 바이트 열(Byte sequence)을 그대로 pickle.loads로 복원하는 방식입니다.

import pickle
def load_state(payload: bytes):
return pickle.loads(payload) # 임의 코드 실행(Arbitrary Code Execution)으로 직결되기 쉬움

커밋 시의 본격적인 리뷰 계층(Layer 3)은 이러한 "임의 코드 실행으로 직결되기 쉬운 함수의 조합"을 주변 코드까지 읽어 들인 상태에서 찾아낼 것으로 예상됩니다. 수정 방향으로는 JSON 등 다른 표현 방식으로의 교체나, 검증 기능이 포함된 데시리얼라이저(Deserializer) 사용이 제안되는 경우가 많다고 생각합니다.

import json
def load_state(payload: bytes) -> dict:
# 임의 코드 실행을 동반하지 않는 표현으로 변경
...

JSON으로 표현할 수 없는 구조를 다루는 경우에는, 애초에 신뢰할 수 없는 입력을 데시리얼라이즈(Deserialize)하는 설계 자체를 재검토하거나, 스키마 검증(Schema Validation)을 거치는 방향을 검토하는 것이 무난하다고 느낍니다.

여기서 보여드린 코드 예시는 어디까지나 동작 이미지를 파악하기 위한 것이며, 실제 탐지 메시지나 수정 제안 문구는 버전이나 상황에 따라 달라집니다. 실제 환경에 투입하기 전에는 자신의 리포지토리에서 작은 PoC를 실행하여 동작을 확인하는 것이 안전하다고 생각합니다.

유용한 플러그인이기는 하지만, "AI가 작성한 코드를 AI가 수정한다"는 루프에는 구조적으로 주의해야 할 점이 있습니다. 이 부분은 1장에서 다룬 "누가 리뷰하는가"라는 질문과 동전의 양면 같은 관계에 있다고 느낍니다. 검사와 수정을 모두 AI 측에 맡기면, 루프가 닫히면서 인간의 눈이 개입하기 어려워지는 방향으로 작용하기 때문입니다.

구체적으로는 다음과 같은 점들이 우려됩니다.

• 탐지 로직 자체가 확률적으로 작동하는 부분을 포함하므로, 놓치는 부분이 제로(0)가 된다고 보장할 수 없습니다.
• 수정 제안이 표면적인 패치에 그쳐, 본질적인 설계상의 문제는 별도로 재검토가 필요할 수 있습니다.
• 하나의 수정이 다른 부분을 망가뜨리고, 그것을 다시 AI가 수정하는 식의 수정 연쇄가 발생하면 변경 사항 전체의 가시성이 나빠지기 쉽습니다.
• 수정을 위해 권한을 확장하거나 의존성을 추가하다 보면, 고쳤다고 생각한 것이 오히려 공격 표면을 넓히는 결과가 될 수 있습니다.
• "AI가 스스로 탐지하고 스스로 고쳤다"는 구도는 자기 검증의 한계(자신의 오류는 스스로 알아차리기 어려움)와 맞물리는 부분이 있습니다.
• "수정했으니 안전하다"라는 심리적 안도감이 인간의 리뷰를 경시하는 방향으로 작용할 가능성이 있습니다.

이러한 관점은 Anthropic이 공개한 How we contain Claude(봉쇄 설계에 관한 해설)를 참고하면 도움이 됩니다. "봉쇄(Containment)\

이 분류로 말하자면 모델 계층(Model Layer) 측에 가까운 메커니즘이므로, 샌드박스(Sandbox)나 권한 제어를 별도로 갖춰두지 않으면 탐지가 누락되는 순간 피해가 커질 수 있습니다. 역설적으로 말하면, 이 플러그인을 설치했다고 해서 환경 계층(Environment Layer)을 소홀히 해도 된다는 뜻은 아니라는 관계라고 생각합니다.

Claude Code 자체는 OS 레벨의 샌드박스(macOS의 Seatbelt, Linux의 bubblewrap 등)에서 실행하도록 하는 설계가 소개되어 있으므로, 로컬에서 실행할 경우에도 이 경계를 유지하는 것이 현실적인 타협점으로 보입니다.

'보안 감사(Security Audit)'라고 하면 Snyk, CodeQL, Dependabot, 각종 SAST/DAST 도구를 떠올리는 분들이 많을 것입니다. security-guidance는 이들을 대체하는 것이라기보다, 보완하는 위치로 파악하는 것이 타당해 보입니다. 여기서는 단순히 표로 나열하는 것에 그치지 않고, 각각이 무엇을 전제로 하는 '사상(Philosophy)'을 가진 도구인지라는 관점에서 정리해 보겠습니다.

Dependabot의 사상— "의존성은 노후화된다. 새로운 취약점은 나중에 발견된다"라는 전제에 서서, 알려진 취약점 데이터베이스와 대조하며 의존성을 지속적으로 업데이트해 나가는, 시간축 방향의 방어라고 파악하고 있습니다. 코드의 내용보다는 "어느 시점의 의존성인가"를 문제 삼습니다.

Snyk의 사상— 의존 라이브러리와 그 전이적 의존(Transitive Dependency)을 포함한 공격 표면(Attack Surface)을 알려진 취약점으로 체계적으로 관리하는 발상입니다. 2-2에서 언급한 "의존성이 공격 표면을 넓힌다"는 문제에 대해, 데이터베이스의 방대함과 재현성으로 대응하는 도구라고 이해하고 있습니다.

CodeQL의 사상— 코드를 질의 가능한 데이터로 취급하여, 데이터 흐름(Data Flow)을 추적함으로써 "위험한 입력이 위험한 지점까지 도달하는가"를 의미론적으로 분석합니다. 3-1에서 언급한 코드 자체의 공격 표면에 대해, 재현성 높은 결정론적(Deterministic) 분석으로 깊게 파고드는 발상입니다.

위의 도구들이 모두 "작성이 완료된 코드"를 대상으로 하는 반면, security-guidance의 사상은 "작성 중인, 문맥(Context)을 가진 코드"를 대상으로 합니다. 결정론적인 범위나 재현성보다는, 생성(Generation) 단계 근처에서 빠르게 피드백을 주는 것에 무게를 둔 설계라고 읽힙니다.

즉, 결정론적이고 재현성 높게 스캔하는 도구군(Snyk / CodeQL / Dependabot)과, 생성 단계의 근접성을 통해 속도와 문맥을 가져가는 플러그인(security-guidance)은 애초에 목표로 하는 축이 다르다고 정리할 수 있습니다. 참고로, SAST나 CodeQL은 재현성은 높지만 그 자체로 취약점의 완전한 망라를 보장하는 것은 아니라는 점에 유의해야 합니다. 그렇다면 어느 한쪽으로만 끝내기보다, 축이 다른 것들을 중첩하는 것이 더 합리적일 것입니다.

관점	security-guidance	Snyk / CodeQL / Dependabot / 일반적인 SAST	DAST
작동 타이밍	코드를 작성하는 도중 (Claude Code 세션 내)	PR / CI, 정기 스캔	스테이징 이후의 동적 환경
...

조합하는 방법의 한 가지 안으로는 다음과 같은 구성이 있을 것입니다.

• 로컬 / Claude Code 세션 내: security-guidance로 작성하면서 문맥과 함께 수정
• PR / CI: CodeQL이나 Snyk, Dependabot으로 의존성 및 데이터 흐름을 포함한 결정론적 정적 분석(Static Analysis)
• 스테이징: DAST나 fuzzing으로 실제 동작을 검증
• 운영(Production): 감사 로그, WAF, 런타임 보호

이 구성은 어디까지나 하나의 예시이므로, 다루는 언어나 컴플라이언스 요구사항에 따라 우선순위는 달라질 것입니다. 자신의 팀에 맞춰 재배열해 보는 것이 좋습니다.

이름이 비슷하여 혼동될 수 있으나, Anthropic에는 claude-code-security-review라는 별도의 리포지토리(GitHub Action)도 있습니다. 이것은 PR이 열리는 시점에 CI 상에서 보안 리뷰를 실행하는 것으로, 본문에서 다루고 있는 세션 내 플러그인인 security-guidance와는 별개의 것입니다. 플러그인 본체의 소스는 claude-plugins-official 리포지토리의 plugins/security-guidance 하위에 있습니다. 위의 "2. PR / CI" 계층에는 이 GitHub Action을 조합하는 선택지도 포함될 수 있습니다.

• security-guidance는 에이전트적 코딩(Agentic Coding)의 보급으로 인해 발생한 "대량의 AI 코드를 누가 리뷰할 것인가"라는 구조적 문제에 대해, 생성 측면에서 내놓은 하나의 응답으로 읽을 수 있습니다. AI 생성 코드의 위협은 "그럴듯함으로 경계심을 해제한다"는 점에서 기존과 다르며, 의존성 추가나 slopsquatting과 같이 AI 시대 특유의 리스크도 포함합니다.
• 3층 분석(3-layer analysis)은 단순한 다중 체크가 아니라, 코드(Code)·의존성(Dependency)·설정(Configuration)이라는 서로 다른 공격 표면(Attack Surface)에 단계적으로 대응하는 구조로 이해할 때 더욱 납득이 갑니다.
• AI가 탐지하고 AI가 수정하는 루프에는 수정의 연쇄(Chain of fixes)나 자기 검증(Self-verification)의 한계와 같은 리스크가 있습니다. 따라서 확률적인 탐지에만 전적으로 의존하기보다, 환경 계층에서 경계를 공고히 하는 "봉쇄 설계(Containment design)"의 발상이 계속해서 중요하다고 느낍니다.
• Snyk / CodeQL / Dependabot / DAST는 겨냥하는 축(결정론적인 재현성 vs 생성과의 근접성 및 문맥)이 다르므로, 대체하기보다는 중첩하여 구성하는 것이 현시점에서는 운용하기 쉬워 보입니다.

"AI와 보안을 어떻게 연결할 것인가"는 아직 각 기업이 시행착오를 겪고 있는 단계이며, 베스트 프랙티스(Best Practice)가 완전히 정립되지 않은 영역이기도 합니다. 본 기사의 내용도 도입을 검토하기 위한 입구로서 읽어 주시고, 실제 운영 환경에 적용하는 것은 공식 문서와 자사의 보안 정책을 대조하여 판단해 주시기를 권장합니다.

• security-guidance 플러그인 공식 문서 - Claude Code Docs (사양에 관한 1차 정보. 3층의 발화 조건·상한·전제 버전은 이곳이 정확합니다)
• 플러그인 찾는 법 및 도입 절차 - Claude Code Docs
• Claude Code 공식 문서 (Top) (구 docs.anthropic.com)