월요일 아침, 작은 개발팀의 채널에 메시지 세 묶음이 한꺼번에 올라온다. 코드를 바꿀 때마다 자동으로 빌드하고 테스트하는 지속적 통합 시스템에 새 경고가 떴다. 이미지 검사 보고서에는 고위험 취약점이 30개 올라와 있다. 그리고 AI 보안 도구가 바로 적용할 수 있는 패치 12개를 정리해 각각 테스트 결과까지 붙여 왔다. 버튼 하나면 전부 내보낼 수 있다.

이 속도는 진짜다. 2026년 5월, OpenAI는 Daybreak라는 계획을 시작했다. 자사 모델과 코드 보안 도구를 결합해 코드 저장소 안에서 취약점을 자동으로 찾고, 패치를 만들고, 제한된 권한 안에서 테스트를 돌린다. 패치가 기계의 속도로 만들어지면, 병목은 “고칠 수 있느냐"에서 “어떤 패치를 사람의 승인 없이 내보내도 되느냐"로 옮겨 간다. 기준은 AI가 얼마나 잘 쓰느냐가 아니다. 문제가 생겼을 때 되돌릴 수 있느냐다.

테스트를 통과했다고 배포해도 되는 것은 아니다

AI가 낸 패치에 테스트 결과가 붙어 있으면 이미 검증이 끝난 것처럼 보인다. 하지만 테스트가 증명하는 것은 “테스트가 다루는 부분은 망가지지 않았다"는 것이지, “변경이 건드리면 안 될 곳을 건드리지 않았다"는 것이 아니다. 패키지 버전을 올리는 패치가 슬그머니 로그인 동작을 바꿀 수 있다. 권한 설정을 고치는 패치 때문에 일부 사용자가 갑자기 데이터를 못 보게 될 수도 있다. 기존 테스트가 이런 것을 꼭 잡아낸다는 보장은 없다.

Security Boulevard는 Daybreak를 보도하면서, 시스템이 감사에 쓸 수 있는 증거를 내부 추적 시스템으로 돌려보내 검증하게 한다고 전했다. 하지만 누가 검증하는지, 적용 전에 사람의 승인이 꼭 필요한지는 적혀 있지 않다. 다시 말해 증거를 준비하는 것은 도구가 할 수 있어도, “누가 배포를 결정하느냐"는 그 도구를 쓰는 팀이 스스로 정해야 한다.

“되돌릴 수 있느냐"로 자동화 정도를 정한다

미국 국립표준기술연구소(NIST)는 기업 패치 관리 지침에서 패치를 기술의 예방 정비로 보고, 패치를 일상적으로 돌릴 수 있는 전략을 세우라고 권한다. 침해, 데이터 유출, 업무 중단의 위험을 줄이기 위해서다. 패치를 일상적으로 돌리려면 먼저 빨리 해도 되는 것과 그렇지 않은 것을 나눠야 한다.

나누는 질문은 하나다. 이 패치로 문제가 생기면 몇 분 안에 이전 버전으로 되돌릴 수 있고, 되돌린 뒤에 피해가 남지 않는가.

  • 되돌릴 수 있고 범위도 분명하다: 예를 들어 민감한 기능을 건드리지 않는 패키지 하나만 올리고, 자동 테스트가 다루며, 배포 뒤 클릭 한 번으로 되돌릴 수 있다. AI에게 준비시키고 간단히 확인한 뒤 빠르게 내보내도 된다.
  • 되돌릴 수는 있지만 영향 범위가 불분명하다: 변경이 여러 서비스에 걸치거나 테스트가 일부만 다룬다. 엔지니어가 먼저 영향 범위를 확인한 뒤 정한다.
  • 깔끔하게 되돌릴 수 없거나, 되돌리기 전에 피해가 날 수 있다: 로그인, 결제, 인증 정보, 고객 데이터, 암호화, 데이터베이스 구조 변경, 배포 스크립트를 건드리는 패치. AI가 테스트했더라도 반드시 책임자가 검토한 뒤 내보낸다. 데이터베이스 구조를 바꿔 버렸거나 데이터가 새어 나갔다면, 코드 버전을 되돌려도 되찾을 수 없다.
광고

내보내기 전에 답해야 할 네 가지

내보내려는 패치는 모두 네 가지 질문에 답할 수 있어야 한다. 답하지 못하면 초안에 둔다.

  1. 영향 범위: 어떤 서비스, 어떤 데이터 흐름, 어떤 사용자에게 영향을 주는가.
  2. 변경 내용: 바꾸는 것이 버전인가, 설정인가, 권한인가, 절차인가. 위에서 말한 민감한 영역을 건드리는가.
  3. 테스트 증거: 자동 테스트나 수동 확인 기록이 있고, 이번 변경과 대응하는가.
  4. 되돌리기 방법: 문제가 생기면 어떻게 되돌리고, 누가 언제 시작하는가. 실제로 연습해 봤는가.

애플리케이션 보안을 다루는 개방형 커뮤니티 OWASP의 AI 에이전트 보안 지침도, 외부에 영향을 주는 고위험 동작에는 단순한 승인 확인창 이상의 통제가 필요하고, 승인은 구체적인 동작과 매개변수에 묶어야 한다고 권한다. 패치에 적용하면, 승인하는 사람은 “모두 적용"을 누르는 게 아니라 이번에 구체적으로 무엇이 바뀌는지 봐야 한다는 뜻이다.

취약점이 지금 공격당하고 있을 때

이렇게 나누면 민감한 영역의 패치는 느려진다. 취약점이 지금 공격받고 있다면 느려지는 것 자체가 위험이다. 그럴 때는 코드를 바꾸지 않고 노출을 줄이는 방법을 먼저 쓴다. 영향받는 기능을 잠시 끄거나 방화벽 규칙을 더하는 식이다. 그다음 정식 패치를 사람이 검토한다. 급하다고 검토를 건너뛰어서는 안 된다.

또 네 가지 질문에 답하려면 팀에 테스트와 배포 기록이 있어야 한다. 자동 테스트가 없고 변경을 특정 커밋까지 추적할 수 없는 팀이라면, 먼저 갖춰야 할 것은 그 기반이지 AI에게 패치를 더 맡기는 것이 아니다.

다음 단계로, AI가 이번 주 제안한 패치 목록을 꺼내 하나씩 표시해 보자. 되돌릴 수 있고 범위가 분명함, 되돌릴 수 있지만 범위가 불분명함, 깔끔하게 되돌릴 수 없음. 빠르게 하는 것을 고려해도 되는 것은 첫 번째뿐이다. 어떤 취약점부터 고칠지는 취약점 순서는 점수만 보지 말고 실행 경로와 외부 입력부터 확인한다를 참고하자. 컨테이너 이미지 검사 결과라면 AI 컨테이너 스캐너도 스스로 여기에 선을 긋는다, 기계적인 수정은 자동으로, 베이스 이미지 교체는 사람이 정한다도 참고할 만하다.

AI 정리 카드

패치 묶음을 빨리 내보낼 것과 사람이 검토할 것으로 AI와 함께 나누기 이 프롬프트는 시스템과 패치 목록을 확인한 뒤, 문제가 생겼을 때 되돌릴 수 있느냐로 패치를 분류하고, 내보내기 전에 아직 부족한 증거를 정리한다.

AI 보안 도구에게서 취약점 패치 묶음을 받았다. 어떤 것은 빠르게 내보내도 되고 어떤 것은 사람이 검토해야 하는지 판단하고 싶다.
판단 방법은 이 글에서 가져왔다: https://boosterminiclass.com/ko/posts/ai-security-patching-needs-human-triage/
글의 관점은 이렇다. 패치를 사람의 승인 없이 내보내도 되는지는 문제가 생겼을 때 되돌릴 수 있느냐로 정해진다. 되돌릴 수 있고 범위가 분명하며 테스트된 작은 업그레이드는 빠르게 해도 된다. 로그인, 결제, 인증 정보, 고객 데이터, 암호화, 데이터베이스 구조, 배포 스크립트를 건드리는 패치는 반드시 사람이 승인한다. 모든 패치는 내보내기 전에 영향 범위, 변경 내용, 테스트 증거, 되돌리기 방법에 답할 수 있어야 한다.

먼저 나에게 질문 3개를 해 달라:
1. 각 패치는 무엇을 바꾸는가(패키지 버전, 설정, 권한, 프로그램 로직);
2. 자동 테스트와 클릭 한 번으로 되돌리는 배포 방식이 있는가;
3. 지금 공격받고 있거나 특히 급한 취약점이 있는가.

내 답을 바탕으로 다음을 출력해 달라:
- 패치마다 한 줄: 변경 내용 / 민감한 영역을 건드리는지 / 테스트 증거 / 되돌리기 방법 / 분류(빠르게 내보냄, 엔지니어 확인 필요, 책임자 검토 필요);
- 각각 내보내기 전에 아직 부족한 증거;
- 급하지만 사람이 검토해야 하는 항목에 대해, 코드를 바꾸지 않고 먼저 노출을 줄이는 방법;
- 팀이 가장 먼저 갖춰야 할 기반 하나(테스트나 되돌리기 장치 등).
패치를 적용하거나 설정을 바꾸지 말 것. 내보낼지는 책임자가 정한다.

분류는 출발점일 뿐이다. 어떤 패치를 배포할지는 시스템 보안을 책임지는 사람이 정한다.

광고

Share

이 미니 클래스 공유

이 글이 업무 병목을 푸는 데 도움이 되었다면, AI를 어떻게 쓸지 고민하는 사람에게도 공유해 주세요.

참고 자료