Claude Code 보안 리뷰 운영법: 466M 라인 스캔 사례로 보는 적용 순서

AI 코드 리뷰를 보안 점검에 붙일 때 가장 먼저 생기는 질문은 단순합니다. 어디까지 자동화하고, 어디서 사람이 멈춰서 확인해야 할까요? 최근 앤트로픽이 공개한 앨버타 주정부 사례는 이 질문에 꽤 실무적인 답을 줍니다. 앨버타 기술혁신부는 약 1,280개 애플리케이션과 3,400개 코드 저장소를 관리하고 있었고, Claude Code 기반 에이전트 약 50개를 병렬로 돌려 4억 6,600만 줄의 코드를 약 20시간 안에 훑었습니다. 앤트로픽 설명에 따르면 전통적인 방식으로는 약 6.5년이 걸릴 수 있는 규모였습니다.

이 글은 그 사례를 그대로 찬양하려는 글이 아닙니다. 실무 개발팀이 Claude Code 같은 코딩 에이전트를 보안 리뷰에 붙일 때 필요한 운영 구조를 정리합니다. 핵심은 ‘AI가 취약점을 고친다’가 아니라 ‘AI가 반복 탐색, 증거 수집, 테스트 초안, 패치 후보 생성을 맡고, 사람은 우선순위와 배포 책임을 잡는다’입니다.

왜 AI 보안 리뷰는 일반 코드 리뷰와 다르게 설계해야 하나

일반 코드 리뷰는 변경분 중심입니다. PR에 올라온 diff를 보고, 요구사항을 만족하는지, 테스트가 충분한지, 스타일이 맞는지를 확인합니다. 반면 보안 리뷰는 현재 변경분만 보면 부족합니다. 오래된 인증 로직, 방치된 관리자 엔드포인트, 배포 스크립트의 권한 설정, 의존성 버전, 로그에 남는 개인정보처럼 저장소 전체와 런타임 경계를 같이 봐야 합니다.

AI 코딩 에이전트가 유리한 지점도 여기에 있습니다. 사람은 수백 개 저장소를 같은 기준으로 반복 확인하는 데 빨리 지칩니다. 반대로 에이전트는 규칙을 반복 적용하고, 파일 경로와 라인 번호를 모으고, 비슷한 패턴을 여러 저장소에서 찾아내는 작업에 강합니다. 앨버타 사례에서도 Claude Code는 먼저 룰 엔진으로 알려진 패턴을 표시한 뒤, 그 결과를 다시 검토하면서 정확한 파일과 라인을 인용하는 2단계 루틴을 사용했습니다.

하지만 이 장점은 곧 위험이기도 합니다. AI가 그럴듯한 취약점 설명을 만들 수 있기 때문입니다. 그래서 보안 리뷰 워크플로우는 ‘발견 수’보다 ‘검증 가능한 증거’를 중심으로 설계해야 합니다. 결과물에는 반드시 저장소, 파일, 라인, 재현 조건, 영향 범위, 권장 수정안, 테스트 방법이 붙어야 합니다. 이 중 하나라도 빠지면 티켓으로 올리지 않는 편이 낫습니다.

1단계: 저장소 인벤토리와 리뷰 범위를 먼저 고정하기

바로 Claude Code를 저장소에 붙이면 대부분 실패합니다. 스캔 범위가 넓고 기준이 모호하면 결과가 잡음으로 가득 차기 때문입니다. 먼저 인벤토리를 만드십시오. 최소한 다음 항목은 표로 정리해야 합니다.

• 서비스명과 저장소 URL
• 언어와 프레임워크
• 외부 노출 여부
• 인증 방식
• 개인정보 또는 결제정보 처리 여부
• 배포 환경
• 최근 6개월 변경 빈도
• 테스트 실행 방법

이 인벤토리를 기준으로 1차 스캔 대상을 나눕니다. 모든 저장소를 한 번에 보는 것보다 외부에 노출된 API, 관리자 기능, 인증·권한 코드, 파일 업로드, 결제·정산 로직을 먼저 보는 편이 실익이 큽니다. 오래된 내부 배치 저장소보다 사용자 입력을 직접 받는 엔드포인트가 먼저입니다.

프롬프트도 저장소마다 새로 쓰지 말고 공통 템플릿을 둡니다. 예를 들어 ‘인증 우회 가능성’, ‘권한 체크 누락’, ‘서버 측 요청 위조’, ‘SQL 또는 NoSQL 인젝션’, ‘민감정보 로그’, ‘위험한 파일 업로드’, ‘의존성 취약점’, ‘배포 비밀키 노출’처럼 항목을 고정합니다. 항목이 고정되어야 저장소별 결과를 비교할 수 있습니다.

2단계: AI 에이전트에는 발견보다 증거 수집을 시키기

Claude Code 보안 리뷰를 운영할 때 가장 중요한 지시는 ‘취약점을 단정하지 말라’입니다. 에이전트에게는 후보를 찾고, 왜 후보인지 설명하고, 사람이 재현할 수 있는 증거를 남기게 해야 합니다. 좋은 출력 형식은 다음과 같습니다.

• finding_id: 저장소별 고유 ID
• severity: critical, high, medium, low 중 하나
• confidence: high, medium, low 중 하나
• evidence: 파일 경로와 라인 범위
• attack_path: 공격자가 어떤 입력으로 어디까지 도달하는지
• affected_data: 노출 또는 변경될 수 있는 데이터
• proposed_fix: 최소 수정안
• test_plan: 실패해야 하는 테스트와 성공해야 하는 테스트
• human_review_required: 배포 전 사람이 확인할 항목

이 형식을 강제하면 ‘이 코드는 위험할 수 있습니다’ 같은 문장이 줄어듭니다. 보안팀이나 백엔드 리드가 바로 판단할 수 있는 단위로 바뀝니다. 앨버타 사례에서 눈여겨볼 부분도 여기입니다. Claude Code가 파일과 라인을 인용하게 했고, 패치가 나오더라도 엔지니어가 승인하기 전에는 배포하지 않았습니다.

가능하면 에이전트를 역할별로 나누는 것도 좋습니다. 레드팀 에이전트는 외부 공격 흐름을 찾고, 블루팀 에이전트는 방어 기준과 보완 계획을 정리합니다. 코드 품질 에이전트는 테스트 가능성과 유지보수성을 봅니다. 하나의 거대한 프롬프트보다 역할이 나뉜 에이전트가 결과를 검토하기 쉽습니다.

3단계: 패치는 테스트 생성 이후에만 허용하기

AI가 바로 코드를 고치게 하면 빠르게 보이지만, 보안 수정에서는 위험합니다. 취약점 패치는 기능 동작을 바꾸거나 기존 클라이언트를 깨뜨릴 수 있습니다. 그래서 순서는 ‘후보 발견 → 재현 테스트 생성 → 테스트 실패 확인 → 패치 생성 → 테스트 성공 확인 → 사람 리뷰’가 되어야 합니다.

테스트가 없는 레거시 코드라면 AI에게 먼저 테스트를 쓰게 해야 합니다. 앤트로픽이 공개한 사례에서도 자동 테스트가 부족한 시스템에서는 Claude가 테스트를 먼저 작성한 뒤 패치를 진행했습니다. 이 접근은 실무에서 특히 중요합니다. 테스트 없는 보안 패치는 배포 직전까지 안전성을 설명하기 어렵습니다.

예를 들어 관리자 권한 체크 누락이 의심된다면, 먼저 일반 사용자 토큰으로 해당 API를 호출했을 때 403이 나와야 한다는 테스트를 작성합니다. 현재 코드에서 테스트가 실패하면 취약점 후보의 신뢰도가 올라갑니다. 그 다음 권한 체크를 추가하고, 같은 테스트가 통과하는지 확인합니다. 마지막으로 관리자 토큰의 정상 동작 테스트도 같이 돌려야 합니다.

이 흐름을 지키면 AI가 만든 패치도 리뷰 가능한 단위가 됩니다. 리뷰어는 ‘AI가 고쳤다’가 아니라 ‘재현 가능한 실패 테스트가 있었고, 이 패치로 통과한다’를 봅니다.

4단계: 심각도 기준을 팀 언어로 바꾸기

보안 리뷰 결과가 쌓이면 다음 문제는 우선순위입니다. AI 에이전트는 많은 후보를 찾을 수 있지만, 모든 후보를 같은 속도로 고치면 팀이 마비됩니다. 심각도 기준을 팀의 제품 구조에 맞게 번역해야 합니다.

Critical은 외부 공격자가 인증 없이 개인정보, 결제정보, 관리자 기능에 접근할 수 있는 경우로 둡니다. High는 인증된 사용자가 다른 사용자의 데이터에 접근하거나, 서버 내부 자원에 접근할 수 있는 경우입니다. Medium은 특정 조건에서 권한 혼동이나 정보 노출이 생기는 경우입니다. Low는 보안 헤더, 오류 메시지, 오래된 패키지처럼 직접 악용 가능성은 낮지만 정리해야 하는 항목입니다.

여기서 중요한 것은 confidence를 severity와 분리하는 것입니다. 심각해 보이지만 증거가 약한 항목은 ‘High severity, Low confidence’가 될 수 있습니다. 이 항목은 바로 배포 패치가 아니라 추가 검증 티켓으로 가야 합니다. 반대로 영향은 작지만 증거가 명확한 항목은 빠르게 처리할 수 있습니다.

AI 리뷰를 처음 도입하는 팀은 첫 주에 finding을 많이 만드는 데 집중하지 말고, 심각도와 신뢰도 기준을 맞추는 데 시간을 써야 합니다. 기준이 흔들리면 두 번째 주부터 결과를 믿기 어렵습니다.

5단계: 운영 파이프라인에 넣을 때는 PR 단위로 작게 시작하기

대규모 일괄 스캔은 매력적이지만, 모든 팀이 바로 할 수 있는 방식은 아닙니다. 현실적인 시작점은 PR 보안 리뷰입니다. 외부 입력을 받는 API, 인증·권한 관련 변경, 파일 처리, 결제·정산, 배포 설정 변경이 포함된 PR에만 Claude Code 리뷰를 붙입니다.

PR 리뷰 프롬프트는 짧아야 합니다. ‘이 diff에서 보안상 위험한 변경만 찾고, 기능 스타일 코멘트는 하지 말라’고 제한합니다. 결과는 최대 5개만 내게 하고, 각 항목에 재현 조건과 테스트 제안을 붙이게 합니다. 이 제한이 없으면 리뷰 코멘트가 많아져 개발자가 무시하게 됩니다.

일괄 스캔은 월 1회 또는 분기 1회로 두고, PR 리뷰는 매일 돌리는 방식이 좋습니다. 신규 취약점은 PR 단계에서 막고, 레거시 부채는 별도 백로그로 줄이는 구조입니다. 앨버타 사례처럼 저장소가 수천 개라면 병렬 에이전트가 필요하지만, 일반 스타트업은 핵심 저장소 3~10개부터 시작해도 충분합니다.

실무 적용 체크리스트

• 외부 노출 저장소, 인증 코드, 관리자 기능부터 스캔 범위를 정한다.
• 에이전트 출력에는 파일 경로, 라인, 공격 흐름, 테스트 방법을 필수로 넣는다.
• 취약점 단정 표현을 금지하고 confidence를 따로 기록한다.
• 패치 전 재현 테스트를 먼저 생성하게 한다.
• Critical, High, Medium, Low 기준을 팀 데이터 구조에 맞게 정의한다.
• PR 리뷰에는 최대 5개 결과 제한을 둔다.
• AI가 만든 패치는 사람이 승인하기 전 배포하지 않는다.
• 월간 일괄 스캔과 일상 PR 리뷰를 분리한다.
• 첫 달 목표는 발견 수가 아니라 false positive를 줄이는 것이다.

Claude Code 보안 리뷰의 핵심은 자동 배포가 아닙니다. 반복 탐색과 증거 정리를 자동화해 사람이 더 중요한 판단에 시간을 쓰게 만드는 것입니다. 이 선을 지키면 AI 보안 리뷰는 위험한 마술이 아니라 꽤 현실적인 개발 생산성 도구가 됩니다.