GPT-6 Cyber 도입 전 점검: Daybreak 접근·IP 허용 목록·데이터 보존

승인된 접근, 격리된 실행 환경, 암호화 기록을 표현한 생성형 에디토리얼 이미지. 실제 제품 화면이나 시스템 구조를 나타내지는 않는다.

OpenAI가 November 5, 2026 GPT-6 Cyber를 발표했다. 보안팀이 먼저 확인할 것은 자신의 조직에서 쓸 수 있는지, 어떤 네트워크로 호출할지, 입력한 코드와 분석 기록이 어디에 남는지다. 이 글은 공식 문서를 바탕으로 도입 준비 사항을 정리한다. 모델을 직접 실행하거나 성능을 재현한 사용기는 아니다. 아래 운영 절차는 문서에 근거한 권고다. 공식 발표

1. Daybreak Red 승인과 모델 승인을 따로 확인하자

발표 당시 GPT-6 Cyber는 승인된 Daybreak Red 고객 일부에 API와 Codex로 제공됐다. 전체 Red 고객으로의 확대는 향후 계획이다. 현재 도움말도 GPT-5.6 Cyber는 모든 Red 조직의 대상이지만, GPT-6 Cyber에는 별도 모델 승인이 필요하다고 설명한다. Blue 승인, Red 승인, GPT-6 Cyber 승인 여부를 각각 확인해야 한다. Daybreak 접근 안내

승인 이후에도 설정이 남는다. API는 승인된 조직의 기본 프로젝트가 아닌 내부용 프로젝트에서 Red를 활성화하고, 해당 프로젝트의 키를 사용해야 한다. 워크스페이스 접근과 API 프로젝트 접근은 별도로 구성한다. 기업 온보딩 문서는 Red 사용 조직의 SSO 적용도 요구한다. 도입 담당자는 승인된 사용자, 모델, 프로젝트, 제품 화면을 한 장에 기록해 두는 편이 좋다. 기업 온보딩

Red를 곧바로 도입할 이유도 점검하자. 공식 안내는 일반적인 보안 코드 리뷰, 취약점 분류, 패치 검증에는 Blue부터 시작할 것을 권한다. Red는 별도로 승인된 고급 보안 연구를 위한 접근 단계다. 고객용 서비스에 모델을 붙이거나 외부 사용자에게 접근을 중계하는 용도까지 승인되는 것은 아니다. 모델과 Trusted Access

2. IP 허용 목록은 호출 환경부터 정리해야 한다

발표는 Daybreak Red API 접근에 IP 허용 목록을 기본 요구 사항으로 두며 제한적인 예외가 있다고 명시한다. 조직별 예외를 기대하기보다 고정된 호출 경로를 준비하는 것이 현실적이다. 공식 발표

이 설정은 OpenAI API를 호출하는 출발지 IP를 제한한다. 등록되지 않은 IP에서는 유효한 키가 있어도 요청이 거부된다. 모델이 검사할 대상 서버의 목록과는 구분해야 한다. API 허용 목록에 사내 IP를 등록했다고 에이전트의 외부 네트워크 접근까지 제한되는 것은 아니다. API IP 허용 목록

실무에서는 개발 PC, CI 실행기, 보안 분석 서버가 실제로 어떤 공인 IP로 나가는지 먼저 조사하자. NAT, VPN, 프록시, 장애조치 경로가 바뀌는 경우도 포함한다. 파일럿 프로젝트에서 정상 경로의 호출 성공과 미허용 경로의 거부를 모두 확인하고 결과를 남기자. 넓은 주소 대역을 급하게 허용하기보다 네트워크 담당자와 필요한 범위를 정하는 편이 좋다.

공식 문서상 설정 반영에는 최대 15분이 걸릴 수 있고, IP 때문에 차단되면 401과 ip_not_authorized 오류가 반환된다. 변경 직후 실패했다고 키를 계속 새로 만들기보다 출발지 IP와 적용 상태부터 확인하자. 설정·오류 안내

3. ZDR을 원한다면 PSP의 저장·운영 책임까지 읽자

발표에 따르면 표준 보존 방식이 기본이며, ZDR을 사용하는 API 고객은 일반적으로 PSP를 사용해야 한다. Daybreak 승인이 ZDR을 자동으로 부여하지도 않는다. 조직이 요구하는 데이터 처리 조건이 해당 프로젝트와 실제 사용할 엔드포인트에 적용되는지 먼저 확인해야 한다. 공식 발표, 기업 온보딩

ZDR은 고객 콘텐츠를 남용 모니터링 로그에서 제외하는 통제다. 다만 엔드포인트와 기능별 예외가 있고, ZDR 대상이 아닌 기능은 애플리케이션 상태를 저장할 수 있다. 코드 입력만 확인하고 끝내지 말고 파일 업로드, 대화 상태, 연결 도구까지 실제 사용 경로를 따라 검토하자. API 데이터 통제

ZDR with PSP는 보존 대상 API 콘텐츠를 암호화해 고객이 관리하는 저장소에 보관하고, 승인된 자동 안전 검토에 사용한다. 프로젝트에서 활성화하면 PSP를 요구하지 않는 모델을 포함해 해당 프로젝트의 모든 API 트래픽에 이 정책이 적용된다. 공식 가이드는 사람의 접근을 차단한 검토 환경에서 자동 검사를 수행하고, 제한된 안전 신호와 운영 메타데이터만 평문으로 내보내도록 설명한다. 고객은 암호화 기록을 최소 30일 유지해야 하며, 저장소 수명 주기와 접근 권한을 올바르게 관리해야 한다. 따라서 내부 문서에는 저장 위치, 보존 기간, 검토 방식까지 구체적으로 적는 것이 정확하다. PSP 가이드

도입 전에 저장소 소유자와 운영 담당자를 정하자. 프로젝트·데이터 레지던시 위치별 연결 검증, 30일 보존 설정, 저장소와 키 접근 장애 대응을 점검 항목에 넣는다. 특히 마지막 PSP 저장소 연결을 끊으면 프로젝트의 보존 정책이 조직 기본값으로 돌아갈 수 있다는 점도 변경 절차에 반영해야 한다. 연결 해제와 기존 기록 삭제는 별개다. PSP 운영 책임과 연결 해제

4. 허용 범위는 문서와 실행 환경에서 함께 제한하자

OpenAI는 범위 준수 평가에서 배포 안전 지침을 적용한 GPT-6 Cyber가 범위 밖 서비스를 악용한 비율이 관측상 0%였다고 보고했다. 이는 특정 평가 조건에서 얻은 결과다. 우리 조직의 도구, 연결 계정, 네트워크에서도 항상 같은 행동을 보인다는 보증으로 읽어서는 안 된다. 시스템 카드

첫 실행 전에 대상 저장소와 브랜치, 허용된 호스트, 제외 대상, 실행 시간, 허용 작업, 중단 조건을 작성하자. 관련 시스템을 발견했더라도 승인 범위에 없으면 멈추도록 규칙을 정한다. 작업 중 읽은 README, 웹페이지, 도구 출력이 새로운 검사 권한을 부여할 수는 없다. 공식 권장 설정도 범위를 사전에 문서화하고 독립적인 접근 통제로 집행하도록 안내한다. 권장 보안 설정

처음에는 운영망과 분리된 테스트 환경에서 작은 저장소 하나로 시작하는 편이 좋다. 운영 자격 증명이나 고객 데이터를 넣지 않고도 확인할 수 있는 과제를 고르자. 출력은 발견 사항, 근거, 재현 여부, 미완료 작업, 패치 제안으로 나눠 받는다. “취약점 발견”이라는 문장만으로 이슈를 확정하지 말고 사람이 증거를 검토해 우선순위를 결정한다.

5. 자동 검토와 사람의 승인 지점을 설계하자

시스템 카드는 Codex의 샌드박스와 Auto-Review 사용을 권하고, API 사용자에게도 민감한 작업 전 검토와 거부·실패 시 실행 중단을 권한다. 고위험 작업에서는 사람이 상황을 관찰하고 중지할 수 있어야 한다. 시스템 카드의 운영 권고

자체 에이전트에 Codex의 검토 기능이 자동 적용된다고 가정하면 안 된다. 공식 설정 문서는 외부 실행 환경과 사용자 정의 도구에도 실행 직전의 검토 장치를 따로 구성하라고 안내한다. 허용된 네트워크 목적지로 향하는 요청은 자동 검토를 항상 유발하지 않으므로, 민감한 명령의 검토 조건도 별도로 확인해야 한다. 사용자 정의 워크플로 보호

팀에서는 운영 환경 변경, 외부 공개, 권한 확대, 되돌리기 어려운 작업을 사람의 승인 단계에 두자. 검토자 이름과 긴급 중단 방법을 정하고, 경보나 기록 수집이 작동하지 않으면 실행을 멈춘다. 모델이 패치를 제안한 뒤에는 기존 테스트와 코드 리뷰를 통과시켜야 한다. 보안 분석에서 나온 제안에도 평소의 변경 관리 절차를 적용하자.