AI 보안 에이전트의 병합 근거 경계 설계

1. AI 보안 에이전트가 빨라질수록 먼저 분리할 것

코드 생성과 변경 속도가 빨라지면 보안 검토도 같은 리듬으로 들어와야 한다. 그러나 “AI가 취약점을 찾았다”와 “이 변경을 병합하면 안 된다”는 서로 다른 문장이다. 전자는 탐지 시스템의 출력이고, 후자는 제품·운영·보안 책임을 함께 묶은 결정이다. 둘을 한 줄의 심각도 점수로 합치면 개발자는 왜 멈춰야 하는지 알 수 없고, 보안팀은 정말 위험한 변경과 넓은 의심 목록을 같은 대기열에서 처리하게 된다.

Google AI and Infrastructure 팀이 2026년 9월 공개한 사례는 AI 기반 취약점 스캔과 패치를 소프트웨어 개발 수명 주기에 직접 넣는 방식을 설명한다. 원문은 배포되는 수억 줄의 코드에서 모든 변경을 계속 스캔하고, 그 결과로 매달 수백 건의 취약점이 코드베이스나 운영 환경에 들어가는 일을 막고 있다고 Google 내부 운영 결과로서 보고한다. 이 수치는 다른 조직의 기대 효과나 일반적인 도입 기준이 아니다. 다만 탐지를 연례 또는 대규모 일괄 스캔으로만 다루지 않고, 변경 단위의 흐름으로 옮기려는 방향은 주목할 만하다.

여기서 재사용할 만한 핵심은 모델이 말한 위험도를 곧바로 권한으로 바꾸지 않는 구조다. 원문은 빠른 첫 스캔 뒤에, 코드 구조와 도달 가능 경로를 확인하는 전문 분류 에이전트를 두는 2단계 검증을 설명한다. 이어서 야간 통합 테스트에서 여러 변경을 넘나드는 위험을 다시 보는 층도 둔다. 즉 빠른 신호, 구조적 확인, 넓은 범위의 재검토는 같은 작업이 아니라 서로 다른 속도와 책임을 가진 단계다.

팀이 작은 규모에서 시작한다면 거대한 다중 에이전트 시스템을 복제할 필요는 없다. 먼저 “누가 어떤 근거로 지금의 변경을 멈추게 하는가”를 분명히 해야 한다. 모델의 서술, 정적 분석 규칙의 결과, 테스트에서 재현된 경로, 정책 위반 여부 중 무엇이 발견됐는지를 섞지 않고 표시하는 것만으로도 논의가 달라진다. 탐지 도구는 더 많은 말을 할 수 있지만, 병합 게이트는 더 적고 분명한 이유만 제시해야 한다.

2. 신호는 넓게, 병합 근거는 좁게

사전 탐지는 놓치는 위험을 줄이기 위해 넓게 보는 단계다. 이 단계의 결과에는 아직 가설도 섞여 있다. 반면 병합 차단은 개발자의 진행을 실제로 멈추게 하는 조치이므로, 상대적으로 좁고 설명 가능한 근거가 필요하다. 이 차이를 무시하면 두 가지 실패가 반복된다. 경고를 전부 차단으로 올리면 개발자가 피로해져 중요한 알림도 무시한다. 반대로 오탐이 두려워 차단을 거의 쓰지 않으면, 즉시 멈춰야 할 위험이 일반 리뷰 대기열에 섞인다.

Google 사례에서 말하는 구조 검증은 이 간격을 메우는 한 가지 방법이다. 원문은 추상 구문 트리, 호출 그래프, 미리 색인된 도메인 안전 규칙을 이용해 취약한 경로가 실제 공격자에게 도달 가능한지를 확인한다고 설명한다. 이 글이 특정 도구나 기준값을 권장하는 것은 아니다. 조직마다 언어, 저장소 구조, 위협 모델, 승인 책임이 다르기 때문이다. 대신 차단 근거에는 최소한 “어떤 변경에서”, “어떤 경로가”, “어떤 정책 또는 보호 대상과 연결되는가”가 보이게 하자는 제안이다.

차단 정책은 단일 점수보다 행동 단위로 쓰는 편이 낫다. 예를 들어 첫 번째 경로는 “PR에 근거 카드와 리뷰어를 추가하지만 병합은 계속 가능”으로, 두 번째는 “보안 소유자가 확인할 때까지 해당 변경만 보류”로, 세 번째는 “노출 가능성이 있어 사고 대응 절차로 넘김”으로 구분할 수 있다. 각 경로에는 보류를 해제할 사람, 필요한 증거, 변경을 되돌릴 방법이 함께 있어야 한다. 그래야 도구가 만든 알림이 막연한 경고가 아니라 다음 행동이 된다.

3. 한 건의 발견을 ‘근거 묶음’으로 전달하기

아래 양식은 Google의 운영 절차를 그대로 재현한 것이 아니며, 검증된 위험 점수표도 아니다. AI 탐지 결과를 사람이 검토할 수 있는 입력으로 바꾸기 위한 편집부 제안이다.

# 보안 발견 근거 묶음

- **변경 식별자와 범위**: [PR·커밋·서비스·환경]
- **탐지 신호**: [도구가 지목한 패턴과 현재 가설]
- **구조 검증**: [도달 경로, 호출 관계, 테스트 또는 재현 결과]
- **보호 대상과 정책**: [데이터·권한·공개 계약·관련 규칙]
- **불확실성**: [확인하지 못한 전제와 추가로 볼 범위]
- **권장 행동**: [알림, 리뷰 보류, 긴급 대응 중 하나와 이유]
- **결정 소유자와 해제 조건**: [누가 무엇을 확인하면 다음 단계로 갈 수 있는가]

이 묶음에서 중요한 것은 장황한 모델 설명을 붙이는 일이 아니다. 오히려 발견 문장과 증명된 사실을 분리하는 일이다. “SQL 인젝션 가능성”이라는 문장만 남기면, 다음 검토자는 입력이 실제로 쿼리까지 도달하는지, 바인딩이 있는지, 외부 사용자가 해당 경로를 호출할 수 있는지 다시 처음부터 찾아야 한다. 반대로 경로와 확인 방법, 아직 모르는 전제를 같이 남기면 찬성·반대 어느 결론이든 더 빠르게 근거를 보강할 수 있다.

근거 묶음은 민감한 세부를 공개 이슈에 싣자는 뜻도 아니다. 취약점 재현 코드, 고객 데이터, 공격 절차가 포함된다면 PR에는 제한된 참조 ID와 상태만 남기고, 상세 근거는 접근이 통제된 보안 기록에 둔다. 보안 검토를 투명하게 만든다는 말은 모두에게 모든 내용을 노출한다는 뜻이 아니라, 필요한 사람이 결정을 이해할 수 있게 책임과 참조 위치를 연결한다는 뜻이다.

▲ 실제 탐지 결과나 제품 UI가 아니라, 빠른 신호와 구조 검증을 분리해 대응 경로를 정하는 흐름을 보여줍니다.

4. 자동 수정안은 ‘닫힌 고리’가 아니라 검토의 새 입력이다

Google은 스캔 결과와 생성된 증명을 바탕으로 수정안을 만들고, 원래 변경 요청의 사람 리뷰에 제출하는 방식을 설명한다. 이 지점은 특히 중요하다. 수정안이 있다고 해서 취약점 대응이 자동으로 끝나는 것은 아니다. 패치는 기능적으로 문제를 막을 수 있어도, 성능 저하, 호환성, 권한 축소, 로깅 누락, 롤백 가능성 같은 새로운 질문을 만들 수 있다. 수정 과정이 빠를수록 그 질문을 누가 맡는지 더 명확해야 한다.

따라서 자동 수정에는 원래 발견과 별도의 변경 경계를 붙이는 편이 좋다. 어떤 파일을 바꿨는지, 보호하려는 동작이 무엇인지, 테스트가 무엇을 확인했는지, 기존 공개 계약이나 운영 알림이 달라지는지를 일반 변경과 똑같이 읽는다. 보안 목적이라는 이유로 리뷰 기준을 낮추면, 취약점 하나를 닫는 동안 다른 장애 경로를 열 수 있다. 긴급 상황이라면 빠른 승인 경로를 쓰되, 사후에 정상 검토와 되돌림 확인을 생략하지 않는 정책이 필요하다.

수정안을 제안한 에이전트와 승인 기준을 제공하는 시스템도 분리하는 편이 안전하다. 원문 역시 개발·스캔·분류 에이전트의 하니스와 규칙, 문맥을 분리해 편향을 줄이라는 원칙을 제시한다. 작은 팀에서는 별도 모델을 여러 개 두지 못할 수 있다. 그렇더라도 같은 프롬프트의 자기 설명만으로 패치를 승인하지 않고, 독립된 테스트·정적 규칙·리뷰어 체크 중 하나 이상을 대조하는 습관부터 시작할 수 있다.

5. 다음 PR에서 시작할 최소 경계

처음부터 조직 전체의 보안 게이트를 바꾸려 하면, 탐지 도구의 품질보다 운영 합의가 먼저 병목이 된다. 한 저장소 또는 한 종류의 변경에서만 시작하는 편이 현실적이다. 예를 들어 인증 미들웨어, 외부 입력 처리, 의존성 업데이트처럼 이미 소유자와 검토 기준이 비교적 분명한 범위를 정한다. 그 안에서 AI 탐지는 ‘근거 묶음’을 만들고, 사람은 세 가지 행동 중 하나를 선택한다: 정보를 남기고 진행하기, 보안 리뷰가 끝날 때까지 해당 변경만 보류하기, 사고 대응으로 넘기기.

이 흐름의 성공을 탐지 건수나 차단 건수만으로 평가하지 않는 것도 중요하다. 경고가 줄었다고 보안이 좋아졌다는 뜻은 아니고, 차단이 많다고 시스템이 엄격하다는 뜻도 아니다. 대신 “멈춘 변경에서 근거를 찾을 수 있었는가”, “보류가 누구에게 얼마나 오래 머물렀는가”, “나중에 잘못된 분류를 정책과 문맥 개선에 반영했는가”처럼 판단의 질을 돌아볼 수 있다. 이 질문들은 보편적인 성과 지표가 아니라, 팀이 자신의 흐름을 점검하기 위한 회고 질문이다.

AI 보안 에이전트는 보안팀의 판단을 대체하는 마법의 병합 버튼이 아니다. 더 많은 변경을 더 빨리 읽고, 사람이 제한된 시간을 더 중요한 근거에 쓰게 할 가능성을 만드는 도구다. 그 가능성이 실제 안전으로 이어지려면, 신호를 증명으로 바꾸는 단계와 증명을 행동으로 바꾸는 정책, 그리고 최종 책임을 맡는 사람이 서로 분명해야 한다. 다음 PR 하나에서 이 세 경계를 짧게 기록하는 것으로 시작하면, 자동화의 속도와 책임의 속도를 같은 것으로 오해하지 않게 된다.

출처와 적용 범위

• Andrés Lagar-Cavilla·Parthasarathy Ranganathan, Changing the game: Using agentic AI to secure infrastructure code — Google Cloud Blog — 2026년 9월 18일 공개된 글에서 Google 내부의 변경 단위 사전 스캔, 구조적 2단계 검증, 야간 통합 테스트, 자동 수정안의 사람 리뷰 제출, 에이전트 하니스·규칙·문맥 분리 원칙을 확인했다. 본문의 근거 묶음과 행동 경로는 해당 사례를 모든 조직에 일반화한 운영 수칙이 아니라, 독자가 자신의 승인 흐름을 설계할 수 있게 확장한 편집부 제안이다.