AI가 만든 코드를 안전하게 쓰는 법: 스캔·분류·수정·확인의 5단계
AI가 코드를 빠르게 만들수록 검토 대기열도 같이 늘어납니다. 해외 인프라 팀의 최근 보안 자동화 사례를 참고해, 작은 팀이 먼저 적용할 수 있는 스캔·분류·수정·검증·되돌리기 흐름을 정리했습니다.
9월 18일 Google Cloud는 AI 에이전트를 활용해 대규모 코드 변경을 지속적으로 검사하고, 취약점이 운영에 들어가기 전에 찾고 수정하는 자사 방식을 소개했습니다. 공개 글은 Google의 인프라와 조직을 다루는 사례입니다. 작은 팀이 같은 규모를 재현할 수 있다는 뜻은 아닙니다. 다만 AI가 만드는 코드가 늘수록 보안 검토도 생성 뒤에 한 번 하는 일이 아니라, 개발 흐름에 들어가야 한다는 방향은 참고할 만합니다.
이 글은 “AI가 보안을 자동으로 해결한다”는 이야기가 아닙니다. AI는 패턴을 찾아 보고 초안을 만드는 데 도움을 줄 수 있지만, 실제 영향과 우선순위는 시스템을 아는 사람이 판단해야 합니다. 중요한 것은 도구 수가 아니라, 발견된 문제를 어떻게 멈추고 확인하고 되돌릴지 정한 운영 흐름입니다.
AI 코드가 늘면 검토 대기열도 함께 늘어납니다
AI 코딩 도구는 반복 구현과 문서 정리 속도를 높일 수 있습니다. 동시에 더 많은 변경이 더 짧은 시간에 만들어집니다. 변경량이 늘면 취약한 의존성, 비밀값 노출, 권한 검사 누락, 예상하지 못한 데이터 흐름도 더 자주 검토해야 합니다. “AI가 쓴 코드만 따로 의심하자”는 방식은 충분하지 않습니다. 모든 변경에 같은 안전 기준이 필요합니다.
차이는 증거를 남기는 방식에 있습니다. 사람이 한 줄씩 고쳤든 에이전트가 초안을 만들었든, 무엇을 검사했고 어떤 결과에서 병합을 허용했는지 나중에 확인할 수 있어야 합니다. 그래야 빠른 수정이 조용한 위험으로 바뀌지 않습니다.
작은 팀의 5단계 보안 흐름
| 단계 | AI가 도울 수 있는 일 | 사람이 확인할 일 |
|---|---|---|
| 1. 스캔 | 변경 파일과 의존성의 알려진 위험 신호를 모은다 | 검사 범위와 제외 경로가 맞는지 확인한다 |
| 2. 분류 | 문제 후보를 파일·영향·근거별로 정리한다 | 실제 재현 가능성과 업무 영향도를 판단한다 |
| 3. 수정 초안 | 격리 브랜치에 작은 수정 제안을 만든다 | 변경이 의도한 경계만 건드렸는지 확인한다 |
| 4. 독립 검증 | 테스트·정적 검사 결과를 다시 모은다 | 다른 관점의 리뷰와 실제 동작 확인을 한다 |
| 5. 기록·되돌리기 | 검사 결과와 변경 링크를 요약한다 | 병합 승인, 배포 관찰, 되돌릴 조건을 결정한다 |
여기서 “독립”은 꼭 다른 제품을 쓰라는 뜻은 아닙니다. 수정 제안을 만든 작업과 별도로 테스트와 리뷰를 통과시키라는 뜻입니다. 수정하는 에이전트의 설명만으로 안전을 판단하면, 같은 가정이 오류를 놓칠 수 있습니다.
첫 파일럿은 읽기 전용 검토부터
처음부터 AI에게 저장소를 고치게 할 필요는 없습니다. 비핵심 서비스나 연습용 저장소 하나를 골라, 최근 변경을 읽고 “검토 후보와 근거”만 표로 만들게 하세요. 그 표를 기존 코드 리뷰 결과와 비교하면 어떤 종류의 경고가 유용한지, 어디서 맥락을 잃는지 알 수 있습니다.
그다음 단계에서만 격리 브랜치에 수정 초안을 만들게 합니다. 운영 브랜치 직접 푸시, 비밀값 접근, 배포 실행은 파일럿 범위에서 제외하세요. 이는 AI를 믿지 말자는 뜻이 아니라, 새 흐름의 실패 비용을 작게 만드는 방법입니다.
변경마다 남길 최소 증거
보안 문서가 길어지면 아무도 쓰지 않습니다. 아래 다섯 줄이면 리뷰어가 변경의 맥락을 빠르게 볼 수 있습니다. 이 양식은 이슈나 풀 리퀘스트 설명에 붙일 수 있습니다. “확인하지 못함”도 정직하게 기록해야 다음 사람이 위험을 알 수 있습니다.
변경 목적: 로그인 콜백의 권한 확인 누락 후보를 검토 검사 범위: src/auth 및 관련 테스트, 비밀값 파일과 운영 설정은 제외 근거: 정적 검사 경고 1건과 재현 절차 링크 수정 내용: 권한 확인을 추가한 격리 브랜치 초안 / 외부 호출 없음 검증 결과: 단위 테스트 통과, 보안 담당자 검토 대기 되돌리기: 배포 후 인증 오류 증가 시 해당 커밋을 되돌리고 기존 경로로 복구
“AI가 고쳤다”는 문장은 증거가 아닙니다. 어떤 파일이 바뀌었는지, 왜 바꿨는지, 무엇을 실행했는지, 아직 확인하지 못한 것은 무엇인지가 있어야 합니다. 이 기준은 AI를 쓰지 않는 변경에도 그대로 도움이 됩니다.
경고 개수만 세지 마세요
자동 검사는 많은 경고를 만들 수 있습니다. 경고가 많다는 것은 안전해졌다는 뜻이 아닙니다. 오탐이 너무 많으면 사람은 중요한 신호를 놓치고, 반대로 경고가 적어도 검사 범위가 좁았을 수 있습니다. 따라서 운영 지표도 흐름 전체를 봐야 합니다.
- 사람이 재현하거나 근거를 확인한 문제의 비율
- 발견부터 담당자 분류까지 걸린 시간
- 수정 뒤 테스트와 독립 리뷰를 통과한 비율
- 배포 뒤 되돌리거나 다시 연 문제의 수
- 검사에서 제외한 경로와 그 이유
이 지표는 성과 경쟁을 위한 점수가 아닙니다. 어떤 단계에서 검토가 막히는지 찾아 규칙을 고치기 위한 신호입니다. 예를 들어 오탐이 많다면 모델을 더 크게 바꾸기 전에 검사 범위와 분류 기준을 좁히는 편이 낫습니다.
승인 UX도 코드 보안의 일부입니다
AI가 수정 초안을 만들었을 때 “병합” 버튼만 보이면, 리뷰어는 무엇을 승인하는지 놓치기 쉽습니다. 변경 화면에는 수정 파일 수, 테스트 결과, 외부 호출 또는 권한 변경 여부, 남은 확인 항목을 짧게 보여 주세요. “테스트 18개 통과, 운영 설정 변경 없음, 보안 리뷰 1건 대기” 같은 문장이 판단에 필요한 시간을 줄입니다.
특히 AI가 새로운 의존성을 추가하거나 인증·결제·개인정보 경로를 만질 때는 일반 변경과 다른 확인 문구를 보여야 합니다. “이 변경은 외부 패키지 1개를 추가합니다. 라이선스와 공급망 검토가 필요합니다.”처럼 영향이 먼저 보이면, 빠른 개발과 책임 있는 승인을 함께 지킬 수 있습니다.
다음 주에 할 수 있는 작은 실험
한 저장소, 한 종류의 검사, 한 명의 리뷰어로 시작하세요. 월요일에 스캔 범위를 정하고, 수요일에 결과 후보를 함께 분류하고, 금요일에 실제 코드 리뷰와 비교합니다. 수정 자동화는 첫 주의 결과가 쓸 만하다고 판단될 때만 격리 브랜치에서 추가하세요.
AI 코딩의 속도는 이미 팀의 선택지가 되고 있습니다. 그 속도를 안전하게 쓰는 방법은 마지막에 더 오래 리뷰하는 것이 아니라, 스캔부터 되돌리기까지 확인 가능한 작은 단계를 연결하는 일입니다.
출처: Google Cloud의 2026년 9월 18일 엔지니어링 글을 2026년 9월 19일 확인했습니다. 이 글의 5단계 운영 흐름과 증거 양식은 LeanX의 제안이며, 특정 보안 결과를 보장하지 않습니다.
자주 묻는 질문
AI가 만든 코드만 별도로 보안 검사하면 되나요?
변경의 작성 주체보다 실제 변경 내용과 실행 경로가 중요합니다. AI가 작성했든 사람이 작성했든 같은 배포 전 검사와 리뷰 기준을 적용하고, AI 작업은 어떤 도구와 입력을 썼는지 추가로 남기면 좋습니다.
AI가 취약점을 고치게 해도 되나요?
격리된 브랜치에서 수정 초안을 만들고, 테스트와 독립 검토를 거친 뒤 사람이 병합 여부를 결정하는 방식부터 시작하세요. 운영 환경에 바로 변경을 적용하는 일은 별도 권한과 되돌리기 계획이 필요합니다.
보안 자동화의 성과는 무엇으로 보나요?
발견 건수만 보면 오탐이 많은 흐름도 좋아 보일 수 있습니다. 재현 가능한 문제 비율, 검토까지 걸린 시간, 수정 후 테스트 결과, 되돌린 변경 수를 함께 보고 운영 규칙을 조정하세요.
우리 팀의 AI 활용 범위와 검수 기준을 함께 점검해 보세요.
무료 AX 자가진단