AI 보안 검증 체크리스트: 코드 변경마다 위협 모델과 사람 검토를 연결하는 법
AI가 취약점을 찾아주면 검토는 끝난 걸까요?
코드 생성과 보안 분석에 AI를 쓰면 보안 점검은 빨라집니다. 그러나 빠른 결과가 곧바로 안전한 배포를 뜻하지는 않습니다. 탐지 결과가 어떤 변경과 어떤 업무 경로에 연결되는지, 누가 수정안을 승인하는지, 규칙이 최신 위협을 반영하는지가 함께 맞아야 합니다.
Google Cloud는 2026년 9월 18일 인프라 코드의 각 변경을 사전 제출 단계에서 AI 에이전트로 점검하는 방식을 소개했습니다. 이 사례의 핵심은 AI가 사람을 대신해 자동 배포를 결정한다는 데 있지 않습니다. 개별 변경처럼 문맥이 좁은 단위에서 검사하고, 최신 코드베이스 메타데이터에 연결된 위협 모델을 제공하며, 수정 제안은 사람 검토가 있는 변경 요청으로 되돌린다는 데 있습니다.
큰 스캔 한 번보다 변경 단위 검증이 필요한 이유
배포 직전에 전체 코드를 한 번에 검사하면 결과가 늦고, 취약점이 어느 변경에서 시작됐는지 추적하기 어렵습니다. 반대로 변경 단위 검증은 해당 수정의 호출 관계, 데이터 흐름, 권한 변화처럼 필요한 문맥을 좁혀 볼 수 있습니다.
그렇다고 AI 결과를 곧바로 통과시키면 안 됩니다. Google Cloud도 AI 스캔과 결정적·구조적 검증을 함께 사용하고, 탐지·분석·수정 에이전트의 규칙과 문맥을 분리할 것을 제안합니다. 예를 들어 비밀정보 형식, 승인되지 않은 의존성, API 명세의 파괴적 변경은 규칙 기반 검사로 명확하게 막고, 그 변화가 실제 공격 경로를 만드는지는 위협 모델과 사람의 판단으로 확인하는 구조가 필요합니다.
위협 모델은 문서함에만 있으면 늦습니다
위협 모델이 연 1회 작성하는 문서라면, 서비스 구조와 의존성이 바뀐 뒤에는 검증에 쓰기 어렵습니다. 변경된 API의 호출자와 데이터 유형, 권한 경계, 외부 의존성을 코드·명세·운영 정보와 연결해 최신 상태로 유지해야 합니다.
특히 API 변경에서는 ‘컴파일이 되는가’만으로 충분하지 않습니다. 인증 우회가 생기지 않았는지, 응답에서 민감정보가 더 노출되지 않는지, 호출량 제한과 감사 로그가 새 경로에도 적용되는지 확인해야 합니다. API Gateway와 애플리케이션, 모니터링 도구에 흩어진 증거를 같은 변경 검토에 가져오는 이유입니다.
사람 검토와 야간 재검증을 분리하세요
AI가 제안한 수정은 코드 품질, 서비스 영향, 정책 적합성을 사람이 승인해야 합니다. 긴급 변경이라고 해서 이 원칙이 사라지지는 않습니다. 승인자를 지정하고, 근거와 예외 사유를 변경 기록에 남기며, 배포 뒤에는 넓은 범위의 통합 테스트와 재검증을 수행해야 합니다.
사전 제출 검증은 빠른 피드백을, 야간 또는 배포 후 검증은 여러 변경이 합쳐졌을 때의 위험 탐지를 맡길 수 있습니다. 둘 중 하나만 선택하는 문제가 아니라, 시간 범위와 책임을 다르게 설계하는 문제입니다.
시작 전 다섯 가지 질문
어떤 변경은 자동으로 차단하고, 어떤 변경은 사람의 보안 승인을 요구할 것인가?
위협 모델은 API 명세·의존성·권한 경계의 최신 상태를 반영하는가?
AI가 낸 결과를 뒷받침할 규칙 기반 검사와 재현 가능한 증거가 있는가?
수정 제안이 배포되기 전 책임자는 누구이며, 예외는 어디에 기록하는가?
배포 후 로그·트레이스·경보로 새 경로의 이상을 확인할 수 있는가?
Litis는 API Security와 API Monitoring 관점에서 정책 적용 지점과 호출 증적, 운영 가시성 요구사항을 함께 검토할 수 있습니다. AI 도구 자체의 보안 성능이나 자동 수정 범위를 보장하는 의미는 아니며, 고객의 개발 프로세스와 적용 도구에 맞춘 검증이 필요합니다.
