OpenAI가 최근 «Defense Factory»(방어 공장)이라는 자동화 보안 운영의 아키텍처를 공개했다. AI 에이전트가 취약점을 지속해서 스캔하고 검증하고 수정함으로써, '발견–분류–수정–확인' 전체 흐름을 사람이 한 건씩 티켓을 챙길 필요가 없는 파이프라인으로 바꾼 것이다. 개념 글이 아니다. 내부 보안 스프린트의 실제 수치가 붙어 있다: 첫날 긴급/고우선 문제 53건 해결, 담당 매칭 수락률 90.6%, 동적 검증 후 오탐률 0.81%, Codex가 생성한 패치의 롤백률 0.53%.
OpenAI가 밝힌 이유는 직설적이다. 최신 에이전트는 오래 실행되고, 세션을 넘어 대상 시스템에 대한 이해를 쌓으며, 흩어진 취약점들을 공격 체인으로 엮는 것이 가능해졌다. 예전에는 숙련된 레드팀이 수 주가 걸렸던 일을, 공격 측은 이제 에이전트 함대로 기계 속도로 스캔·테스트·이용한다. 게다가 오픈웨이트 모델의 보급으로 이 능력이 더 이상 드물지 않다. 즉: 공격의 자동화는 이미 끝났고, 방어는 여전히 티켓이 담당자에게 배정되길 기다리고 있다 — 그 차이 자체가 인시던트의 창이다.
동시에 OpenAI는 방어 측이 아직 쥐고 있는 두 가지 구조적 우위도 짚는다. 첫째, 승인된 에이전트에게 소스 코드와 내부 시스템 컨텍스트를 직접 공급할 수 있는 것. 둘째, 시중 오픈웨이트 모델보다 강한 프런티어 모델을 쓸 수 있는 것. 다만 이 선점은 기간이 정해져 있다. OpenAI는 이를 «방어자의 창»이라 부른다 — 자율적 공격 능력이 널리 보급되기 전에 지속 방어를 먼저 구축하라는 것이다. 이 창은 열려 있지 않는다.
아키텍처상 기존 도구를 대체하지 않는다. API·CLI·MCP로 기존 도구를 에이전트가 실행할 수 있는 파이프라인으로 잇는다. GitHub / GitLab으로 소스 관리, Snyk / Semgrep / Tenable로 스캔, Jira / Linear / ServiceNow로 티켓 관리와 추적. 기반은 두 개의 평면으로 나뉜다: 컨트롤 평면이 오케스트레이션·정책 강제·크레덴셜 프록시를 담당하고, 데이터 평면은 일회성·재현 가능한 개발 환경을 제공해 에이전트가 취약점 재현과 패치 테스트를 마치면 환경을 폐기한다. 다음 실행에 오염이 묻지 않도록. 전체를 모니터링·감사 로그·액세스 제어가 감싼다.
코어 루프는 5단계다: 자산 인벤토리 → 취약점 발견 → 동적 검증 → 담당 매칭 → 검증된 수정. 각 단계가 공유 컨텍스트인 SECURITY.md를 읽고 쓴다 — 시스템 맵, 담당, 조사 증거, 테스트 절차가 쌓여 다음 루프가 처음부터 시작하는 것이 아니라 이전 성과를 재사용한다. 이는 전통적 5가지 병목(조사 대기, 중복이 우선순위를 묻어버림, 담당 부재, 엔지니어의 반복 조사, 병합 후 미검증)에 대한 하나하나의 답이기도 하다.
쉽게 놓치는 교훈도 있다: 패치 병합은 배포된 수정이 아니다. OpenAI는 '병합된 패치'와 '플릿 전체에 배포된 수정' 사이의 간극을 발견했고, '배포 결과의 독립적 재검증'을 파이프라인의 독립 단계로 만들었다. 대규모 플릿을 돌리는 모든 팀에게 이 한 걸음이 바로 MTTR의 마지막 구간이다.
공격은 이미 자동화되었고, 방어는 아직 티켓을 기다리고 있다 — 이것이 2026년의 보안 격차다. Lafa System은 24/7 AI로 로그와 자산을 감시해 '발견–검증–수정'을 사후 대응이 아닌 상시 파이프라인으로 만든다. 창은 아직 열려 있다. 그러나 곧 닫힌다.