Claude Security 지속 스캔, 발견 항목을 팀장이 거르는 법

보안 점검 보고서가 한 달에 한 번 쌓이는 팀이라면, 이번 주 발견 항목이 지난주와 어떻게 달라졌는지 따라가기 어려웠을 겁니다. 2026년 10월 Claude Security가 코드를 계속 스캔하고, 고친 항목은 자동으로 닫고, 같은 문제가 다시 나타나면 다시 여는 방식으로 바뀌었습니다. 이 글은 개발자가 아닌 팀장이나 기획자도 이 결과를 읽고 우선순위를 정할 수 있도록, 발견 항목을 거르는 프롬프트를 중심으로 정리합니다.

먼저 확인할 점이 있습니다. 이 업데이트는 2026년 10월 기준 Claude Enterprise 고객을 대상으로 한 퍼블릭 베타입니다. 개인 요금제에서 바로 쓸 수 있는 기능이 아니므로, 회사 계정이 Enterprise인지와 관리자가 기능을 켜 두었는지를 먼저 확인하세요. 관리자 콘솔에서 켜지 않으면 프로젝트 메뉴 자체가 보이지 않습니다.

무엇이 달라졌나: 한 번 찾고 끝나던 점검에서 계속 보는 점검으로

예전 방식은 점검 시점에 한 번 스캔하고 보고서를 받는 흐름이었습니다. 이제는 프로젝트를 만들고 저장소를 연결하면 먼저 기준 스캔(baseline scan)이 돌고, 그 뒤로는 변경된 코드만 주기적으로 다시 검사합니다. 연결은 Claude GitHub 앱을 쓰거나 Git 접근 토큰을 넣는 방식이고, 저장소마다 어느 브랜치를 볼지 정할 수 있습니다. 한 프로젝트에 최대 8개 저장소까지 묶을 수 있으며, 스캔 대상으로 보는 저장소와 맥락만 읽는 저장소를 구분할 수 있습니다.

발견 항목 하나하나에는 심각도(Critical부터 Low까지), 공격자가 취약한 코드에 어떻게 닿을 수 있는지에 대한 설명, 해당하는 경우 CWE 번호가 붙습니다. 여기서 중요한 점은 고치는 과정을 Claude가 추적한다는 것입니다. 개발자가 Claude Code에서 고쳤든 다른 도구에서 고쳤든, 변경된 코드에서 수정이 확인되면 해당 항목이 해결됨으로 바뀝니다. 해결된 항목이 나중에 다시 나타나면 자동으로 다시 열립니다. 팀장 입장에서는 "지난주 지적 사항이 실제로 닫혔는가"를 사람이 일일이 확인하지 않아도 된다는 뜻입니다.

한 가지는 미리 알아 두는 편이 좋습니다. 공개 자료에 따르면 같은 코드를 두 번 스캔해도 결과가 조금 다르게 나올 수 있다고 설명되어 있습니다. 그래서 한 번의 보고서를 최종 판정으로 보기보다, 같은 항목이 여러 주에 걸쳐 반복해서 잡히는지를 보는 쪽이 더 믿을 만합니다.

발견 항목을 팀이 읽을 수 있는 말로 바꾸기

개발팀이 내보낸 목록을 그대로 회의에 올리면 대부분의 항목이 "무슨 뜻인지 모르겠다"로 끝납니다. 그래서 Claude에게 목록을 넘기면서, 읽는 사람이 우선순위를 정할 수 있는 형태로 바꿔 달라고 요청하는 것이 가장 효과가 좋았습니다. 핵심은 심각도 등급을 그대로 믿지 않고, 우리 서비스에서 실제로 누가 영향을 받는지를 기준으로 다시 고르게 하는 것입니다.

아래 프롬프트는 결제 기능을 운영하는 팀에서 쓰는 형태를 예로 든 것입니다. 목록 자리에는 Claude Security 화면에서 복사한 항목 제목과 설명을 그대로 붙여 넣으면 됩니다. 실제 코드나 고객 정보는 넣지 않는 편이 안전합니다.

아래는 우리 결제 저장소에서 Claude Security가 찾은 취약점 목록입니다.
개발 용어를 모르는 팀장도 이해할 수 있게 정리해 주세요.

1. 각 항목을 "무엇이 위험한가 / 공격자가 실제로 닿을 수 있는가 / 고치는 데 걸리는 대략적 규모" 세 줄로 설명하세요.
2. 심각도 등급과 별개로, 고객 결제 정보에 실제로 영향을 주는 순서로 우선순위 3개를 고르고 근거를 한 문장씩 적으세요.
3. 기술 용어가 나오면 괄호 안에 한 줄 풀이를 붙이세요.
4. 목록만으로 확실하지 않은 내용은 "확인 필요"라고 표시하고 추측으로 채우지 마세요.

[발견 항목 목록 붙여넣기]

이렇게 나옵니다 (예시 형식):

[우선순위 1] 결제 승인 토큰 검증 누락
- 무엇이 위험한가: 승인 요청을 위조해 다른 사용자의 결제가 실행될 수 있습니다.
- 공격자가 닿을 수 있는가: 로그인 후 외부 요청 한 번이면 도달 가능한 경로로 보입니다. 확인 필요: 게이트웨이 앞단 설정.
- 고치는 규모: 검증 함수 한 곳과 테스트 추가 수준으로 보입니다.
- 근거: 고객 결제 정보가 직접 걸려 있어 심각도와 무관하게 먼저 봐야 합니다.

이 형식으로 나오면 회의 자료에 그대로 옮기기 좋습니다. 중요한 것은 "확인 필요" 표시가 남아 있는지 보는 것입니다. 그 표시가 있는 항목은 개발자에게 한 번 더 확인받은 뒤에 우선순위에 올려야 합니다.

고친 것과 다시 열린 것을 주간 보고로 정리하기

팀장이 가장 자주 받는 질문은 "지난주 지적한 것은 고쳐졌나요?"입니다. 이제는 해결됨, 재발(다시 열림), 보류(무시 처리) 세 상태를 기준으로 답하면 됩니다. 특히 재발 항목은 "고쳤다고 보고했는데 다시 생긴 문제"라서 가장 민감하게 다뤄야 합니다. 보류 항목은 거짓 양성이나 수용한 위험으로 처리된 것이므로, 누가 어떤 이유로 보류했는지 메모가 남아 있는지 함께 봐야 합니다.

아래 프롬프트는 이 세 가지 상태를 받아서 경영진에게 올릴 주간 보고 초안으로 바꿉니다. 상태 목록은 화면에서 복사하거나 API로 가져온 결과를 붙여 넣어도 됩니다.

아래는 이번 주 보안 점검 상태 목록입니다. 경영진 보고용 주간 보고 초안을 써 주세요.

조건:
- 첫 문단에는 재발 항목을 가장 먼저 쓰고, 어떤 항목이 고쳤다고 보고됐다가 다시 나타났는지 밝히세요.
- 두 번째 문단에는 해결된 항목 수와 해결 항목 중 심각도가 높은 것을 적으세요.
- 세 번째 문단에는 보류 항목을 적고, 보류 메모가 없는 항목은 "사유 미기재"로 표시하세요.
- 목록에 없는 내용은 쓰지 마세요. 해결됐다고 확인되지 않은 항목을 해결됐다고 쓰면 안 됩니다.
- 문장은 짧게, 존댓말로 쓰세요.

[상태 목록 붙여넣기]

이렇게 나옵니다 (예시 형식): 첫 문단은 "이번 주 재발 항목은 2건입니다. 지난주 해결로 기록된 인증 우회 항목 1건이 다시 열렸습니다." 같은 식으로 시작하고, 이어서 해결 수와 보류 사유 누락 항목을 짧게 씁니다. 보고서의 첫 줄이 좋은 소식이 아니라 재발 여부로 시작하면, 경영진이 판단하기 쉬워집니다.

위협 모델 검토를 회의 안건으로 바꾸기

이번 업데이트에서 눈여겨볼 기능은 위협 모델입니다. Claude는 코드를 보고 이 서비스가 어떤 위험에 노출되어 있는지에 대한 모델을 만들고, 팀이 그것을 수정할 수 있게 해 줍니다. 이 모델이 틀리면 엉뚱한 항목이 높은 심각도로 올라오거나, 이미 막혀 있는 위험이 계속 보고됩니다. 그래서 위협 모델은 자동 생성된 결과를 그대로 믿기보다, 가정이 맞는지 사람이 확인하는 자료로 다루는 것이 좋습니다.

아래 프롬프트는 위협 모델의 가정을 회의 안건으로 바꿉니다. 배포 환경, 외부 공개 범위, 이미 있는 통제 장치처럼 팀이 답할 수 있는 질문으로 바꾸는 것이 목적입니다.

아래는 우리 서비스의 자동 생성 위협 모델 요약입니다.
이 모델이 전제하고 있는 가정을 뽑아, 이번 주 회의에서 확인할 질문 목록으로 바꿔 주세요.

- 질문마다 담당자가 답해야 할 내용을 한 줄로 쓰고, 담당자 칸은 "[담당자]"로 비워 두세요.
- 배포 환경, 외부 공개 범위, 이미 적용된 인증·접근 통제 세 분류로 묶어 주세요.
- 모델이 "막혀 있다"고 가정한 항목은 실제로 막혀 있는지 확인하는 질문을 따로 표시하세요.

[위협 모델 요약 붙여넣기]

이렇게 나옵니다 (예시 형식): "외부 공개 범위: 관리자 페이지가 사내망에서만 열린다고 가정했습니다. 실제 방화벽 규칙 확인이 필요합니다. [담당자]" 같은 질문이 세 분류 아래 나열됩니다. 회의에서는 이 질문을 위에서부터 답하기만 하면 되므로, 위협 모델을 처음 보는 사람도 흐름을 따라갈 수 있습니다.

돌리기 전 확인할 실무 체크리스트

이 기능을 팀 업무에 붙이기 전에 몇 가지를 정해 두면 실수를 줄일 수 있습니다. 첫째, 프롬프트에 비밀번호, 접근 토큰, 고객 개인정보를 넣지 마세요. 발견 항목 제목과 설명만으로 대부분의 정리가 가능합니다. 공개된 내용에 따르면 이 기능은 Zero Data Retention을 지원하지 않으므로, 데이터 보관 정책이 엄격한 조직이라면 법무나 보안 담당자와 먼저 검토해야 합니다.

둘째, 보류 처리를 할 때는 반드시 사유를 적으세요. 보류된 항목은 이후 스캔에서 다시 올라오지 않기 때문에, 사유가 없으면 나중에 아무도 그 판단을 설명하지 못합니다. 주간 보고 프롬프트가 "사유 미기재"를 골라내도록 짠 이유가 여기에 있습니다.

셋째, 스캔 결과를 한 번의 정답으로 취급하지 마세요. 같은 항목이 여러 주 연속으로 나타나는지를 보고, 한 번만 나타나고 사라진 항목은 "확인 필요"로 남겨 두면 불필요한 소동을 줄일 수 있습니다. 마지막으로, 개발팀과 회의 자료를 공유할 때는 위의 프롬프트로 만든 정리본을 쓰고 원본 목록은 개발팀 안에서만 관리하는 방식이 무난합니다.

한눈에 정리

Claude Security의 지속 스캔은 보안 점검을 한 번의 보고서에서 계속 이어지는 흐름으로 바꿉니다. 현재는 Enterprise 고객의 퍼블릭 베타이므로 계정 조건부터 확인하세요. 발견 항목은 우선순위와 근거를 붙여 정리하고, 재발과 보류를 먼저 보는 주간 보고로 묶으면 회의 시간이 줄어듭니다. 위협 모델의 가정은 자동 결과로 믿지 말고 질문 목록으로 바꿔 확인하세요.

자주 묻는 질문

Q. 개인 Claude 요금제에서도 쓸 수 있나요? A. 공개된 자료 기준으로는 Claude Enterprise 고객을 대상으로 한 퍼블릭 베타입니다. 개인 요금제에서 같은 기능을 쓸 수 있다는 내용은 확인되지 않았으므로, 회사 계정이 Enterprise인지 먼저 확인하세요.

Q. 프롬프트로 정리한 내용을 그대로 믿어도 되나요? A. 아닙니다. 심각도와 우선순위는 참고용입니다. 특히 "확인 필요"로 표시된 항목은 개발자가 실제 코드를 보고 확인한 뒤에 우선순위에 올려야 합니다.

Q. 개발자가 Claude Code에서 고친 항목도 자동으로 해결됨이 되나요? A. 변경된 코드에서 수정이 확인되면 해결됨으로 바뀝니다. 다만 공개 자료에는 수정 확인이 어떤 기준으로 이뤄지는지 세부 내용이 없으므로, 중요한 항목은 개발자가 직접 닫는 방식과 함께 쓰는 것을 권합니다.

Q. 해결된 항목이 나중에 다시 나타나면 어떻게 하나요? A. 자동으로 다시 열립니다. 주간 보고 프롬프트에서 재발 항목을 가장 앞에 두면, 한 번 고쳤다고 보고했던 문제가 다시 생긴 상황을 놓치지 않을 수 있습니다.