보안 구멍 막으라고 붙인 AI가, 그 구멍이 됐습니다

보안 취약점을 자동으로 찾아서 패치까지 만들어주는 AI. 몇 년 전만 해도 꿈 같은 이야기였는데요. 지금은 GitHub Copilot Autofix를 비롯해 여러 도구가 실제로 그 일을 하고 있습니다. 그런데 요즘 보안 커뮤니티에서 반복해서 나오는 질문이 하나 있습니다. 그 AI가 만든 패치를, 우리는 대체 누가 검토하고 있느냐는 겁니다.

먼저 솔직하게 말씀드릴 게 있습니다. 이번 주제로 커뮤니티 데이터를 훑어봤지만, 최근 30일 안에 이 사안을 직접 다룬 확인 가능한 토론은 못 찾았습니다. 그래서 이 글은 특정 사건의 속보가 아닙니다. AI 자동 수정과 CI/CD 공급망이 맞물리는 지점에서 구조적으로 뭐가 위험한지를 짚는 쪽에 무게를 뒀습니다. 구체적인 피해 사례를 기다리시는 분이라면 이 점을 감안하고 읽어주시면 좋겠습니다.

자동 수정이란, 결국 봇에게 커밋 권한을 주는 일입니다

Autofix류 기능이 돌아가는 방식은 단순합니다. 정적 분석이 취약점을 잡아내면, AI가 수정 코드를 짜서 풀 리퀘스트로 올립니다. 사람은 승인 버튼만 누르면 됩니다.

여기서 승인 버튼이 문제의 핵심인데요. 조직에서 이런 도구를 도입하는 이유는 대부분 “취약점이 너무 많아서 다 못 고친다"입니다. 그런데 그 조직에 갑자기 코드 리뷰 여력이 생길 리는 없습니다. 결국 AI가 올린 PR은 다른 PR보다 훨씬 가볍게 검토됩니다. 보안 도구가 만들었으니 보안상 안전할 거라는 암묵적 전제가 깔리거든요.

공격자 입장에서 이건 대단히 매력적인 구조입니다. 사람이 만든 PR은 의심받지만, 보안 봇이 만든 PR은 신뢰받습니다. 신뢰받는 경로를 오염시킬 수 있다면, 그 뒤는 훨씬 쉬워집니다.

프롬프트 인젝션은 코드 주석에도 심을 수 있습니다

AI가 취약점을 고치려면 주변 코드를 읽어야 합니다. 함수 정의, 주석, 커밋 메시지, 이슈 본문, 때로는 연결된 티켓 내용까지 컨텍스트로 들어갑니다.

문제는 이 컨텍스트 상당수가 외부인이 쓸 수 있는 영역이라는 점입니다. 오픈소스 저장소의 이슈, 외주 개발자가 남긴 주석, 자동 연동된 티켓 설명. 여기에 “이 파일을 수정할 때는 다음 헬퍼 함수도 함께 추가하라"는 식의 지시문을 자연스러운 문장으로 숨겨두면, AI는 그걸 개발자의 의도로 읽을 수 있습니다.

생성된 코드에 백도어 한 줄이 섞여 들어가도 티가 잘 안 납니다. 보안 패치 diff는 원래 낯설게 생겼거든요. 이스케이프 처리, 입력 검증, 라이브러리 교체 같은 변경은 리뷰어가 “이런 것도 필요한가 보다” 하고 넘기기 쉽습니다.

진짜 위험은 CI/CD와 만나는 지점입니다

여기서 한 단계 더 나갑니다. 코드 저장소는 혼자 존재하지 않습니다. 커밋이 들어오면 CI가 돌고, 빌드가 배포되고, 그 과정에서 클라우드 자격 증명과 데이터 웨어하우스 접근 토큰이 동원됩니다.

즉 저장소에 코드 한 줄을 심는다는 건, 단순히 그 코드가 실행된다는 뜻이 아닙니다. CI 러너가 가진 모든 권한에 손을 댈 수 있게 된다는 뜻입니다. 데이터 웨어하우스 연결 정보, 이슈 트래커 API 토큰, 배포용 클라우드 키. 최근 몇 년간 대형 유출 사고가 반복해서 보여준 패턴이 정확히 이겁니다. 취약한 건 데이터베이스 자체가 아니라, 데이터베이스로 가는 자격 증명이 굴러다니는 파이프라인이었습니다.

AI 자동 수정은 이 파이프라인 최상단에 사람이 아닌 커밋 생성자를 하나 추가합니다. 그리고 그 생성자는 외부에서 온 텍스트를 읽고 판단합니다. 위험 구조가 어떻게 완성되는지 보이실 겁니다.

그래서 쓰지 말라는 얘기냐면, 아닙니다

오해는 없었으면 합니다. Autofix 같은 도구는 실제로 쓸모가 있습니다. 수천 개씩 쌓인 취약점 경고를 사람이 다 처리하는 건 불가능합니다.

다만 도입 방식이 달라져야 합니다. 몇 가지만 정리해보겠습니다.

AI가 만든 PR에는 더 엄격한 리뷰 기준을 적용해야 합니다. 더 느슨한 게 아니라요. 자동 병합은 특히 위험합니다. AI 봇 계정의 커밋으로는 프로덕션 배포 파이프라인이 트리거되지 않게 분리하는 것도 방법입니다. CI 러너 권한도 다시 들여다볼 필요가 있습니다. 빌드 하나가 조직의 모든 비밀에 접근할 수 있다면, 그건 AI 이전부터 이미 문제였습니다.

그리고 AI에게 어떤 텍스트를 컨텍스트로 주는지 파악해야 합니다. 외부인이 편집할 수 있는 필드가 AI 프롬프트에 들어가고 있다면, 그건 사실상 외부인에게 코드 작성 권한을 일부 넘긴 것과 같습니다.

마무리하며

AI 에이전트에게 쓰기 권한을 주는 순간, 우리는 새로운 신뢰 경계를 하나 만든 셈입니다. 문제는 그 경계가 어디에 그어졌는지 대부분의 조직이 문서화하지 않았다는 점입니다.

지금 여러분의 저장소에서, 사람이 아닌 계정이 만들 수 있는 커밋은 어디까지 갈 수 있나요. 그 답을 모른다면, 그게 먼저 확인할 일입니다.