OpenAI, 250명 보안 스프린트를 지속형 AI 방어 팩토리로 전환
OpenAI는 사이버 모델이 수백 개 시스템 전반의 취약점 수정에 도움을 주었으며, 이를 계기로 지속적인 에이전트 기반 방어 프로그램을 마련했다고 밝혔다.
목차 · 11
OpenAI는 Codex와 특화 사이버 모델을 활용해 탐지, 분류, 수정, 검증을 지원하면서 수백 개 시스템 전반의 취약점을 찾고 수정하기 위해 250명 이상의 직원을 동원했다고 밝혔다. 회사는 이제 이 내부 보안 스프린트에서 발전한 아키텍처와 운영 프로세스를 공개했으며, 그 결과물인 시스템을 “Defense Factory”라고 부른다.
이번 공개에는 이례적으로 구체적인 운영 결과가 담겼다. OpenAI는 스프린트 첫날 긴급 또는 높은 우선순위의 이슈 53건을 종료했고, 발견 사항을 담당자에게 전달할 때 90.6%의 수용률을 달성했으며, 발견 사항의 37%를 중복으로 분류했고, 동적 검증 이후 오탐률을 0.81%로 낮췄다고 밝혔다.
이 수치는 공개된 외부 침해 사고가 아니라 내부 방어 프로그램을 설명한다. OpenAI는 영향을 받은 서비스, 전체 취약점 수나 심각도 분포, 또는 보고된 각 비율의 분모와 측정 기간을 공개하지 않았다. 따라서 공개 자료만으로는 결과를 독립적으로 재현할 수 없다. 이번 공개의 중요성은 운영 모델에 있다. 보안 업무가 주기적 스캔과 사람 간 인계의 연속이 아니라 지속적인 에이전트 워크플로로 재편되고 있다는 점이다.
1. 보안 스프린트는 100개가 넘는 서비스 영역을 포괄했다
OpenAI는 최초의 노력을 자사의 보안, 응용, 연구 조직을 한데 모은 내부 “code red”로 설명한다. 250명 이상이 참여했으며, 업무 범위는 수백 개 시스템을 아우르는 100개 이상의 서비스 영역에 걸쳤다.
스프린트는 OpenAI가 해당 시스템의 완전한 지도를 갖추기 전부터 시작됐다. Codex는 자산 인벤토리를 구축하는 데 도움을 주었고, 팀들은 기존 보안 발견 사항을 공유 백로그로 가져왔다. 서비스 소유권 데이터, 배포 구성, 클라우드 기록, 소스 코드, 노출된 엔드포인트를 단계적으로 연결해 에이전트가 각 발견 사항을 어느 팀에 전달해야 하는지 판단할 수 있도록 했다.
OpenAI는 이 프로세스가 90.6%의 소유권 수용률을 냈다고 보고했다. 사람 검토자는 모호한 사례를 계속 해결했고, 긴급 수정은 인벤토리가 완성되기 전에 진행됐다. 이 병렬 접근 방식 덕분에 팀들은 첫날 긴급 또는 높은 우선순위의 이슈 53건을 종료할 수 있었다.
에이전트는 발견 사항을 심각도 기준표에 따라 평가하기도 했다. OpenAI는 초기 분류가 일관되지 않았고 모델에 제공되는 지시문에 민감했다고 밝혔다. 이에 회사는 프롬프트와 기준표를 버전 관리하고, 반복 가능한 평가를 추가했으며, 검토자가 예상한 우선순위와 그 근거를 기록하고, 사람의 표본 점검을 유지했다.
중복 제거도 별도의 명시적 관문이 됐다. OpenAI는 이 과정이 개선될 때까지 자동 할당을 일시 중지했고, 결국 검토한 발견 사항의 37%가 중복이라고 판단했다. 단지 더 많은 보고서를 생성하는 에이전트 시스템은 위험을 줄이지 못한 채 보안 엔지니어의 부담만 늘릴 수 있기 때문에 이는 중요하다.
동적 검증은 재현 가능한 취약점과 정적 분석 노이즈를 구분하는 데 사용됐다. 에이전트는 선택된 서비스의 실행 가능한 버전을 받고 통제된 환경에서 의심되는 문제를 재현하려 했다. OpenAI는 이 단계 이후 오탐률이 0.81%였다고 보고했지만, 검증된 표본의 규모나 구성은 공개하지 않았다.
2. Defense Factory는 5단계 에이전트 루프를 사용한다
Defense Factory는 단일 모델이나 취약점 스캐너로 제시되지 않는다. 이는 기존 소스 제어 시스템, 보안 스캐너, 이슈 트래커, 개발 환경, 회사별 컨텍스트, AI 에이전트를 연결하는 참조 아키텍처다.
워크플로는 인벤토리, 탐지, 동적 검증, 소유권 할당, 검증된 수정이라는 5개 반복 단계로 구성된다.
인벤토리 에이전트는 클라우드 리소스, 배포 구성, 소스 코드, 노출된 엔드포인트, 서비스 소유권 기록을 조정한다. 이어서 탐지 에이전트는 이 인벤토리를 위협 모델, 보안 정책, 소스 코드, Snyk나 Wiz 같은 도구에서 가져온 발견 사항과 결합한다. 결과물은 확인된 결함 목록이 아니라 잠재적 취약점의 풀로 남는다.
동적 검증 중 에이전트는 관련 코드를 검사하고 실행 가능한 애플리케이션에서 각 후보를 재현하려 한다. OpenAI의 명세는 정적 추적만으로는 충분하지 않다고 밝힌다. 검증된 취약점에는 재현 증거가 포함돼야 한다. 반증되었거나 결론이 나지 않은 발견 사항도 기록에 첨부되며, 트래커에 이슈를 생성하려면 승인이 필요하다.
소유권 에이전트는 검증된 발견 사항을 자산 인벤토리, 코드 소유자 파일, 커밋 이력, 내부 커뮤니케이션, 이슈 트래커와 연결한다. OpenAI는 할당과 확인을 구분해 자동으로 전달된 티켓이 수락된 업무로 처리되지 않도록 한다.
마지막 단계에서 Codex는 패치를 준비하고 재현 가능한 환경에서 그 동작을 점검한다. 사람의 검토와 승인된 배포 후에는 별도의 점검이 프로덕션 수정 사항을 다시 테스트한다. 병합된 풀 리퀘스트나 이동된 티켓은 수정 완료의 증거로 간주되지 않으며, 검증이 실패했거나 결론이 나지 않으면 이슈는 열린 상태로 유지된다.
공유 SECURITY.md 파일은 사이클 간 시스템별 지식을 전달한다. 각 반복은 컨텍스트를 다시 구성하는 대신 매핑, 소유권 정보, 조사 증거, 이전 검증 점검을 재사용할 수 있다. 회사는 중요한 변경 사항은 여전히 사람의 검토를 거치며, 배포된 수정은 독립적으로 검증된다고 밝혔다.
3. 격리와 접근 제어는 보안 경계의 일부다
OpenAI의 아키텍처는 제어 플레인과 데이터 플레인을 분리한다. 제어 플레인은 워크로드 오케스트레이션, 정책 시행, 자격 증명 접근을 관리한다. 데이터 플레인은 에이전트가 애플리케이션을 실행하고, 취약점을 재현하며, 패치를 테스트할 수 있는 격리된 개발 환경을 제공한다.
이 환경은 일시적이도록 설계됐다. 각 실행은 새로운 환경에서 시작하며, 이후 상태는 폐기된다. 이는 한 조사가 다른 조사에 영향을 미칠 위험을 낮추고 반복 검증의 신뢰성을 높인다.
아키텍처는 소스 제어, 시크릿 저장소, 아티팩트 레지스트리, 모델 엔드포인트도 조직의 프라이빗 네트워크 내부에 둔다. 자산 인벤토리와 발견 사항 데이터베이스는 워크플로 상태를 보존하며, 호스트 모니터링, 인프라 보안, 에이전트 감사 시스템은 파이프라인 전반의 활동을 감독한다.
OpenAI는 자율성을 점진적으로 높였다고 밝혔다. 소규모 배치와 사람의 검토로 시작한 뒤, 결과가 더 신뢰할 수 있게 되자 반복되는 수동 단계를 제거했다. 에이전트에 부여된 권한은 수행할 수 있는 분석 작업의 양과 분리해 유지했다.
이 구분은 특히 수정 단계에서 중요하다. OpenAI는 스프린트의 모든 패치를 에이전트가 생성했으며 수정을 “100% Codex-based”라고 설명했지만, 중요한 검토와 승인된 배포는 여전히 사람이 담당했다. 롤백된 수정의 보고 비율은 0.53%였지만, 회사는 그 비율이 나타내는 원시 패치 수를 공개하지 않았다.
후속 점검에서는 수정 사항이 병합된 것과 모든 배포 시스템에 도달한 것 사이에 격차가 있다는 사실도 확인됐다. OpenAI는 배포 후 검증을 확대했지만, 실패한 수정과 일반적인 배포 지연을 구분하는 방법을 마련하는 동안 자동 재개방은 처음에는 비활성화해 두었다.
4. 이식 가능한 결과는 인원 수가 아니라 검증 파이프라인이다
OpenAI의 핵심 주장은 공격자가 비슷한 접근 권한을 얻기 전에 방어자가 프라이빗 코드, 배포 컨텍스트, 소유권 기록, 더 강력한 프런티어 모델을 활용할 수 있다는 것이다. Defense Factory는 이 이점을 탐지와 검증된 수정 사이의 더 짧은 주기로 전환하도록 설계됐다.
Cloudflare는 이와 견줄 만한 멀티 에이전트 취약점 하니스를 별도로 설명한 바 있다. 이 파이프라인은 정찰, 탐색, 적대적 검증, 중복 제거, 의존성 추적, 패치 준비에 각각 별도 에이전트를 사용한다. 생성된 수정 사항이 프로덕션에 도달하려면 사람의 승인이 필요하며, 모델의 서면 평가를 신뢰하는 대신 재현 가능한 테스트를 관문으로 취급한다.
이 독립적 구현은 기본 워크플로 패턴을 뒷받침하는 동시에 그 비용도 보여 준다. Cloudflare는 대규모 스캔에 수 시간이 걸릴 수 있고, 50명에서 200명의 워커 풀을 필요로 하며, 운영 병목이 결함 발견에서 수정 사항 검토와 안전한 배포로 이동한다고 밝혔다. 지속적인 에이전트 활동이 애플리케이션 소유자, 신뢰할 수 있는 테스트 환경, 릴리스 엔지니어링, 보안 판단의 필요성을 없애지는 않는다.
OpenAI의 설계를 고려하는 조직에 가장 구체적인 변화는 절차적이다. 잠재적 발견 사항은 엔지니어에게 전달되기 전에 중복 제거와 재현을 거쳐야 하고, 소유권은 최신 운영 기록과 연결돼야 하며, 패치는 회귀 점검을 통과해야 하고, 수정은 배포 후 검증돼야 한다. 이러한 관문이 없으면 에이전트를 추가하는 일은 취약점 감소가 아니라 보고서 생산을 가속할 위험이 있다.
기반 모델에 대한 접근 권한도 균일하지 않다. OpenAI의 공개 아키텍처는 Daybreak Blue 및 Daybreak Red 보안 모델과 함께 Astra, Sol, Terra, Luna를 포함한 범용 모델을 언급한다. 더 허용적인 사이버 기능은 Daybreak를 통해 검증된 방어자에게 제공되며, 더 강력한 신원 확인, 범위 제어, 모니터링, 감독이 적용된다.
따라서 공개 자료는 어떤 조직이든 OpenAI의 결과를 즉시 재현할 수 있다는 증거가 아니라 참조 아키텍처와 내부 사례 연구다. OpenAI는 성능 지표와 워크플로 세부 사항을 제공했지만, 자사 시스템을 기존 보안 프로그램과 비교하거나 탐지 범위를 독립적으로 평가하기에 충분한 취약점 수준 데이터는 제공하지 않았다.
자주 묻는 질문
OpenAI는 확인된 외부 침해 사고에 대응한 것인가요?
아니다. OpenAI는 이 작업을 내부 보안 스프린트로 설명하며, Defense Factory 발표가 새로운 외부 침입과 관련 있다고 말하지 않았다.
Defense Factory는 무엇을 하나요?
자산 인벤토리, 취약점 탐지, 런타임 검증, 소유권 라우팅, 패치 생성, 배포 후 검증을 반복적인 에이전트 지원 워크플로로 연결한다.
AI 에이전트가 사람의 승인 없이 수정 사항을 배포했나요?
OpenAI는 Codex가 패치를 생성했다고 밝혔지만, 중요한 변경 사항은 사람의 검토와 배포 승인을 계속 거쳤다. 이후 프로덕션 수정 사항은 독립적으로 다시 테스트됐다.
OpenAI는 취약점을 몇 건 찾았나요?
OpenAI는 총수를 공개하지 않았다. 첫날 긴급 또는 높은 우선순위의 이슈 53건을 종료했다고 보고했지만, 발견 사항의 전체 수나 심각도 분포는 공개하지 않았다.
어떤 조직이든 동일한 사이버 모델을 사용할 수 있나요?
자동으로 가능하지는 않다. OpenAI는 승인된 방어자에게 Daybreak를 통해 신청하도록 안내하며, 더 강력하거나 허용적인 사이버 도구에 대한 접근은 검증, 범위 제어, 감독에 따라 결정된다.
참고 자료
Share
이 글 공유
