코드 취약점 스캔, 패치는 직접

AI로 만든 코드에서 제일 마음에 걸리는 건 보안입니다. 돌아는 가는데 안전한지는 모르겠고, 뭘 확인해야 하는지도 모르겠으니까요. 코드베이스를 훑어 취약점을 찾아주는 플러그인이 나왔는데, 설명을 읽다 눈에 띈 대목이 둘 있었습니다. 찾은 것을 스스로 다시 검토한 뒤에야 보고서를 쓰고, 고치는 것은 사용자가 직접 하게 남겨둔다는 점입니다.

📌 30초 요약

① 여러 에이전트가 역할을 나눠 구조 파악 → 위협 정리 → 탐색 순서로 훑습니다.

② 찾은 것을 하나하나 독립적으로 재검토한 뒤 보고서를 씁니다.

③ 전체 저장소·브랜치 변경분·PR·커밋 하나 중에 골라 볼 수 있습니다.

④ 패치를 만들어 주지만 적용은 직접 해야 합니다.

⑤ 유료 요금제가 필요하고 스캔이 사용량을 깎습니다. 문서에 명시돼 있습니다.

⑥ 비슷한 검사 도구가 이미 셋 더 있어서, 겹치지 않게 골라야 합니다.

혼자 훑지 않고 나눠서 훑습니다

"코드 검사"라고 하면 보통 규칙 목록에 걸리는 패턴을 찾는 것을 떠올립니다. 이건 순서가 다릅니다. 여러 에이전트가 먼저 이 코드가 어떤 구조인지 지도를 그리고, 그 구조에서 무엇이 위험할 수 있는지를 정리한 다음, 그 목록을 들고 실제로 찾으러 갑니다.

# 스캔이 도는 순서

1. 구조 파악    이 코드가 어떻게 생겼는지 지도 그리기
2. 위협 정리    이 구조에서 뭐가 위험할 수 있는지
3. 탐색         정리한 목록을 들고 실제로 찾기
4. 독립 재검토   찾은 것을 하나하나 다시 따져보기
5. 보고서 작성  CLAUDE-SECURITY-<시각>/ 폴더에 저장

# 4번이 이 도구의 성격을 보여줍니다

4번 단계가 눈에 띈 이유가 있습니다. 자기가 찾은 것을 자기가 다시 의심하는 절차를 공정 안에 넣어둔 것인데, AI 도구에서 흔한 문제가 "뭔가 찾긴 찾았는데 진짜인지 모르겠는 결과"이기 때문입니다. 목록만 길게 뽑아놓으면 확인하는 데 드는 시간이 더 큽니다.

고치는 것까지는 안 합니다

찾은 문제 중 내가 고른 것만 패치로 만들어 줍니다. 그리고 그 패치는 내가 읽어보고 내가 적용합니다. 자동으로 코드를 고쳐놓지 않습니다.

💡 왜 여기서 멈춰 세웠을까

보안 수정은 고치다가 기능을 망가뜨리기 쉬운 영역입니다. 입력을 막았더니 정상 사용자까지 막히는 식이죠. 게다가 "왜 위험한지 모른 채 적용한 수정"은 다음에 같은 실수를 반복하게 만듭니다. 찾는 데까지만 자동화하고 판단과 적용을 사람에게 남긴 설계로 읽힙니다.

범위를 고를 수 있다는 점도 실용적입니다. 전체 저장소를 다 훑을 수도 있고, 브랜치에서 바뀐 부분만, 병합 요청 하나, 심지어 커밋 하나만 볼 수도 있습니다. 처음부터 전체를 돌리면 결과가 너무 많이 나와서 손을 못 대니, 내가 방금 만든 부분부터 좁게 보는 편이 현실적입니다.

공짜로 돌리는 건 아닙니다

"플러그인 설치"라고 하면 부담 없이 들리지만, 공식 문서에 조건이 여럿 붙어 있었습니다. 가장 중요한 건 스캔 한 번이 내 사용량을 깎는다는 것입니다.

항목	조건
요금제	유료 요금제 필요
사용량	스캔마다 한도에서 차감
파이썬	설치돼 있어야 함(추가 패키지는 불필요)
버전 관리	변경분 스캔·패치에 필요 / 전체 스캔은 없어도 됨
일부 요금제	설정에서 관련 기능을 먼저 켜야 함

전체 스캔은 버전 관리가 없어도 된다는 줄이 의외로 반갑습니다. AI에게 시켜서 만든 프로젝트가 깃 저장소도 아닌 채 폴더로만 있는 경우가 흔한데, 그 상태에서도 전체 훑기는 됩니다. 다만 그때는 패치 만들기와 변경분만 보기는 못 씁니다.

비슷한 도구가 이미 셋 더 있습니다

문서가 스스로 구분선을 그어둔 것이 흥미로웠습니다. 이름이 비슷한 검사 기능이 이미 여럿이라 헷갈리기 쉬운데, 보는 시점이 각각 다릅니다.

🧱 층이 나뉘어 있습니다

쓰는 중에 봐주는 것이 하나, 브랜치를 한 번 훑는 것이 하나, 병합 요청을 보는 것이 하나, 그리고 이번 플러그인은 코드베이스 전체를 깊게 파는 쪽입니다. 겹치는 게 아니라 언제 보느냐로 층이 나뉜 구조입니다.

회사 쪽에는 저장소를 상시 감시하는 별도 유료 제품도 있는데, 문서는 그것과의 차이도 적어뒀습니다. 이 플러그인은 관리형 제품이 닿지 못하는 곳까지 닿습니다 — 다른 호스팅 서비스에 있거나, 바깥에서 접속이 안 되는 망 안에 있는 저장소 같은 경우죠. 내 컴퓨터에서 도는 도구라 가능한 일입니다.

🩹 고치는 것까지 가는 쪽도 생겼습니다 (8월 27일 추가)

여기서 짚은 "찾아주고 패치는 사람 몫"이라는 성격은, 쓰는 도중에 보는 쪽에서는 달라집니다. 편집마다·대화가 끝날 때·커밋할 때 세 층으로 나눠 보고, 나온 것을 같은 대화 안에서 이어 고치게 합니다. 첫 층은 모델을 안 불러 값이 0이고요. 다만 성격은 정반대가 아닙니다 — 이쪽은 이미 있는 코드는 안 보고 지금 쓰는 변경분만 봅니다. 그러니 둘은 대체가 아니라 층이 다른 도구입니다. 확인한 내용은 짜면서 걸리는 취약점에 정리했습니다.

🏛️ 취약점을 찾는 일이 국가 사업이 됐습니다

도구 하나 고르는 문제를 넘어선 흐름이 생겼습니다. 정부가 보안 특화 AI 기반 모델을 만들기로 하고 사업자를 정했습니다 — 기업·대학·연구기관 33곳이 참여해 7천억 개 규모로 만듭니다. 다만 여기서도 교훈은 같습니다 — 찾아 주는 것과 고쳐 주는 것은 다른 일입니다.

🔁 반대로, 패치까지 맡길 수 있는 자리도 생겼습니다

취약점은 찾아 주지만 패치는 직접 해야 한다고 적었는데, 그 경계가 한 군데에서는 움직였습니다. 끌어올림 요청 자동 고치기를 켜 두면 검사가 깨지거나 리뷰 댓글이 달릴 때 클로드가 직접 고쳐서 밀어 올립니다. 다만 조건이 붙습니다 — 고칠 방향이 분명할 때만 밀고, 여러 갈래로 읽히거나 구조를 건드리는 얘기면 먼저 물어봅니다. 그러니 스캔 결과를 자동으로 닫고 싶다면 지적을 애매하지 않게 남기는 쪽이 실제로 효과가 있습니다.

자주 묻는 질문

Q. 개발을 몰라도 쓸 수 있나요?

돌리는 것 자체는 어렵지 않습니다. 명령 한 줄로 설치하고 한 줄로 시작합니다. 문제는 결과를 읽고 무엇을 고칠지 고르는 단계입니다. 패치를 만들어 줘도 적용은 내 몫이라, 코드를 전혀 모르면 그 판단이 어렵습니다. AI로 만들 때 자주 하는 실수를 먼저 훑어두면 결과를 읽기가 한결 낫습니다.

Q. 한 번 돌리면 얼마나 쓰나요?

문서에 구체적인 양은 없습니다. "스캔마다 사용량 한도에서 차감된다"고만 적혀 있습니다. 다만 에이전트를 여러 개 돌리고 찾은 것을 다시 검토하는 구조라 가벼운 작업은 아닐 겁니다. 처음에는 커밋 하나나 변경분만 걸어서 규모를 가늠해보시는 편을 권합니다.

Q. 여기서 나온 게 전부인가요?

아닙니다. 어떤 검사 도구도 전부를 잡지 못하고, 문서도 이 플러그인을 여러 층 중 하나로 소개합니다. 반대로 나온 것이 전부 진짜라는 뜻도 아닙니다 — 재검토 단계를 뒀다지만 확인은 여전히 필요합니다. 에러가 났을 때 원인을 좁히는 방법은 코딩 에러 해결 글에 정리해뒀습니다.

🧾 솔직하게 밝혀둘 것

① 공식 문서를 읽고 정리한 것이고 직접 돌려보지 않았습니다. 탐지 성능이 어느 정도인지는 제가 말할 수 없습니다.

② "왜 여기서 멈춰 세웠을까"는 제 해석입니다. 문서에는 적용을 사용자가 한다는 사실만 있고 이유는 없습니다.

③ 사용량이 얼마나 드는지는 문서에 없습니다. "차감된다"만 확인했고 규모는 추정하지 않았습니다.

④ 버전·요금제 조건이 붙습니다. 본문은 조건이 있다는 사실 위주로 적었으니 정확한 값은 원문에서 확인하세요.

⑤ 검사 도구를 돌렸다고 안전해지는 것은 아닙니다. 찾지 못한 문제는 여전히 남아 있고, 이 글도 그 한계를 없애주지 않습니다.

✨ 정리하면

AI 도구가 늘어나는 방향은 대개 "끝까지 알아서 해준다"인데, 이건 찾는 데까지만 하고 판단과 적용을 남겨뒀습니다. 자기가 찾은 것을 다시 의심하는 단계를 넣어둔 것도 같은 성격으로 보입니다. 대신 유료 요금제가 필요하고 돌릴 때마다 사용량을 씁니다. 전체를 한 번에 돌리기보다 방금 바꾼 부분부터 좁게 시작하는 편이 낫습니다.

결과를 읽는 밑바탕은 자주 하는 실수 정리와 에러 해결 글에 있고, 승인과 권한 쪽은 승인 창에 안 보이던 명령에서 이어집니다. AI에 쓰는 돈 전체는 AI 지출 허브에서 순서대로 보실 수 있습니다.

※ 출처: 제조사 공식 문서의 해당 플러그인 안내 페이지와 주간 변경점 페이지(2026년 7월 20~24일 구간) 원문. 2026년 8월 25일 확인 기준이며, 조건·요구 버전·정책은 이후 바뀔 수 있습니다.