보안 업무에 AI를 붙이는 일은 일반적인 요약이나 코드 보완과 결이 다르다. 입력으로 들어가는 것은 공개 전 취약점 정보, 사내 소스 코드, 운영 로그처럼 유출 비용이 큰 데이터다. 모델이 취약점을 잘 찾는다는 사실만으로는 도입 판단이 끝나지 않는다. 누가 어떤 목적으로 쓰는지, 데이터가 어디를 지나고, 결과를 누가 검증하는지까지 같은 설계도로 봐야 한다.
8월 11일 AWS는 OpenAI의 Daybreak Red와 Daybreak Blue를 적격 고객 대상으로 Amazon Bedrock에서 제공한다고 발표했다. Red는 보안 업무용으로 훈련된 GPT-5.6 Cyber에, Blue는 방어적 보안 작업을 위해 안전장치를 조정한 GPT-5.6 Sol에 연결된다. 이번 변화에서 눈여겨볼 지점은 새 모델 이름이 아니라, 위험이 큰 능력을 일반 API가 아닌 심사와 통제가 있는 접근 경로에 묶었다는 데 있다.
같은 보안 질문도 쓰는 맥락에 따라 위험도가 달라진다
취약점 재현이나 익스플로잇 체인 분석은 방어자에게도 필요한 작업이지만 공격자에게도 바로 쓰일 수 있다. AWS는 Daybreak Blue를 대부분의 보안팀이 시작할 등급으로 소개한다. 취약점 탐색, 탐지 규칙 개발, 사고 대응이 대상이다. Red는 취약점 연구, 익스플로잇 재현, 완화책 개발처럼 더 높은 위험의 승인된 작업을 위한 등급이다.
여기서 중요한 것은 Red가 ‘더 똑똑한 모델’이라서가 아니다. 거절 기준을 낮춘 만큼 신원 확인, 모니터링, 접근 통제를 더 강하게 붙이는 구조다. AWS에 따르면 두 모델의 접근에는 OpenAI의 Trusted Access for Cyber 등록이 필요하고, 현재 제공 리전은 미국 동부(버지니아 북부)다. 국내 팀이 바로 사용 가능한지, 데이터 위치 요구사항을 만족하는지는 별도로 확인해야 한다.
모델 선택 표에 권한과 데이터 흐름을 넣어야 하는 이유
AI에 코드와 취약점 정보를 넘기는 순간 모델의 정확도만 보는 평가는 부족하다. AWS 발표에 따르면 Bedrock의 해당 추론 경로에는 전송·저장 암호화, AWS KMS 고객 관리 키, IAM 정책, CloudTrail 로그, VPC 엔드포인트를 적용할 수 있다. 운영자가 추론 중 프롬프트와 응답에 접근하지 못하게 하는 zero-operator access도 설명한다. 이는 AWS가 제공하는 통제 수단이지, 각 조직의 정책을 자동으로 완성해 주는 기능은 아니다.
특히 자동화된 에이전트에 권한을 줄 때는 입력과 출력의 경계가 더 중요해진다. 예를 들어 보안 스캐너 결과를 읽고 수정 제안을 만드는 흐름과, 실제 패치를 만들고 배포 요청을 여는 흐름은 분리하는 편이 낫다. 후자에는 사람 승인, 변경 범위 제한, 테스트 결과 첨부가 필요하다. 보안 AI가 낸 답을 곧바로 실행 가능한 명령으로 바꾸지 않는 원칙도 여기에 포함된다.
실제 취약점 사례는 가능성과 검증의 거리를 함께 보여준다
AWS는 GPT-5.6 Cyber를 사용한 연구자가 Chrome의 JavaScript 엔진 V8에서 이전에 알려지지 않은 취약점 두 건을 찾아냈다고 전했다. 그중 하나는 CVE-2026-15903으로 수정되어 공개됐다. NIST NVD는 이 취약점을 Chrome 150.0.7871.128 이전 V8의 범위 밖 읽기·쓰기로 설명하며, 조작된 HTML 페이지를 통해 샌드박스 안에서 원격 코드 실행이 가능할 수 있다고 기록한다.
다만 이 사례를 곧바로 ‘AI가 취약점 탐색을 해결했다’는 증거로 읽기는 이르다. AWS의 모델 기여 설명은 공급자 발표에 기반한다. 독립적으로 확인 가능한 부분은 CVE의 존재와 영향 범위다. 실제 운영에서도 모델이 찾은 후보는 재현 가능한 테스트, 영향 분석, 코드 리뷰를 거쳐야 한다. 발견 건수보다 오탐을 얼마나 빨리 걸러내고 수정이 회귀를 만들지 않게 하는지가 더 실무적인 지표다.
작게 시작할 때 확인할 세 가지
- 업무를 두 단계로 나눈다. 먼저 비공개 코드가 아닌 의도적으로 격리한 저장소나 이미 공개된 취약점 재현 과제로 탐색·분석 품질을 본다. 패치 생성과 배포는 별도 승인 단계로 둔다.
- 접근 권한을 모델별로 적는다. 누가 Blue나 Red에 접근하는지, 어떤 계정·리전·네트워크 경로를 쓰는지, 세션과 요청 로그를 얼마나 보관하는지를 모델 선정 문서에 함께 기록한다.
- 평가 기준을 결과물로 만든다. 취약점 후보의 재현 성공률, 오탐 처리 시간, 사람이 수정한 제안의 비율, 테스트 통과 여부를 남긴다. 벤치마크 점수보다 조직의 실제 수정 흐름을 보여준다.
도입의 질문은 ‘쓸 수 있나’에서 ‘통제하며 쓸 수 있나’로
Daybreak의 AWS 배포는 보안 특화 AI를 기존 클라우드 거버넌스 안에 넣으려는 시도다. 민감한 보안 작업에서 모델의 거절 정책을 완화하려면, 그 반대편에 신원 검증과 추적 가능성을 올려야 한다는 점도 분명하다.
개인이나 작은 팀이 당장 Red 같은 고위험 도구를 도입할 필요는 없다. 대신 이미 쓰는 코딩 보조 도구와 보안 스캐너에도 같은 질문을 적용해 볼 수 있다. 어떤 데이터가 모델로 가는지, 결과를 누가 검토하는지, 실행 권한이 어디서 생기는지다. 이 세 가지가 정리되어 있어야 AI가 빨라진 만큼 보안 운영도 흔들리지 않는다.