AI 보안 운영 사례
조사 속도는 높이고, 대응 권한은 사람과 고객이 정합니다
OpenAI가 공개한 소포스 사례에서 위협 조사 시간 96% 감소와 MDR 사례 52%의 AI 처리를 보고했습니다. 특정 운영 환경의 결과이며, 사람의 감독과 고객의 대응 권한은 유지합니다.
이 글에서 다룰 내용
공식 성과 수치의 분모, AI 조사 흐름, 고객 통제와 사람 감독, 도입 전 검토할 항목
96% 단축보다 먼저 살펴볼 숫자의 의미
보안 업무를 AI에 맡기면 빨라진다는 설명은 익숙합니다. 그런데 얼마나 빨라졌는지 못지않게 중요한 질문이 있습니다. “AI가 어디까지 처리하고, 누가 실행을 결정하는가”입니다.
OpenAI는 2026년 10월 9일 소포스의 OpenAI Daybreak 활용 사례를 공개했습니다. Daybreak 신규 출시 소식이 아니라 고객 사례 공개이며, 발표 제목에 제시된 성과는 위협 조사 시간 96% 감소입니다.
본문에는 에이전트를 사용한 사례의 평균 대응 시간이 약 38분에서 89초로 줄었다는 설명도 나옵니다. 다만 위협 조사 시간 96% 감소와 평균 대응 시간 89초를 동일한 측정 지표로 단정하면 안 됩니다. 발표에서 구분해 제시한 수치는 그대로 나누어 읽는 편이 정확합니다.
또한 소포스는 MDR, 즉 관리형 탐지·대응 사례의 52%를 AI가 종단 간 처리했다고 밝혔습니다. 이는 해당 운영 환경의 처리 비중이지, 전체 공격의 52%를 차단했다거나 탐지 정확도가 그만큼 높아졌다는 뜻이 아닙니다.
이 수치들은 OpenAI·소포스 발표 기준입니다. 독립 비교시험 결과나 모든 조직에서 재현되는 효과로 확대해 읽지 않는 것이 이번 사례를 이해하는 출발점입니다.
AI 보안 에이전트는 무엇을 맡았나
사례의 중심에는 MDR을 포함하는 소포스 Fusion 시스템이 있습니다. 조사 에이전트는 고객 맥락, 탐지 내용, 침해 지표, 관련 위협 정보를 모읍니다. 계획 모델은 이를 바탕으로 계획→실행→검토 루프를 구성하고, 분석가가 살펴볼 요약과 대응 권고를 만듭니다.
쉽게 풀면 “수상한 신호가 있다”는 알림에서 멈추지 않고, 판단에 필요한 자료를 모아 다음 행동의 근거까지 정리하는 구조입니다. 조사와 권고 작성이 연결되어 있다는 점이 눈에 띕니다.
여기서 읽을 수 있는 핵심은 단순한 답변 생성과 업무 처리의 차이입니다. 보안 질문에 그럴듯하게 답하는 것과, 실제 고객 상황에 맞춰 조사 순서를 세우고 결과를 검토하는 것은 다른 일입니다.
다만 계획을 만들 수 있다는 사실만으로 실행 권한까지 무제한이라고 생각해서는 안 됩니다. 조사 능력과 조치 권한은 별도로 살펴봐야 합니다. 다음 세 가지 운영 모드가 그 구분을 보여줍니다.
사람 승인은 세 가지 운영 모드에 남겼다
소포스 MDR의 Notify 모드에서는 소포스가 조사하고 대응을 권고하지만, 실행은 고객이 맡습니다. Collaborate 모드에서는 조치 전에 소포스와 고객이 함께 대응을 조율합니다. Authorise 모드에서는 소포스가 고객을 대신해 직접 대응할 수 있습니다.
따라서 “AI를 쓴다”는 설명만으로 고객이 매번 승인하는지, 위임한 범위에서 대응하는지 알 수는 없습니다. 어떤 운영 모드를 선택했는지를 함께 봐야 합니다.
발표에 따르면 사람이 처리하든 에이전트가 처리하든 같은 경계가 적용됩니다. 잠재적으로 파괴적인 조치에는 적절한 수준의 사람 감독이 필요하며, 에이전트에 맡기기 어렵다고 판단하는 일은 사람의 판단으로 넘깁니다.
이는 모든 단계마다 사람이 승인 버튼을 누른다는 뜻과는 다릅니다. 자동 처리 범위를 정해 두되, 위험한 조치와 예외에서는 사람이 개입하도록 경계를 남겼다는 의미로 읽는 편이 타당합니다.
제목의 “사람 승인은 어떻게 남겼나”에 대한 답도 여기에 있습니다. 자동화 자체를 막는 대신, 고객의 권한 설정과 위험도에 따른 사람 감독을 유지한 것입니다.
일반 도입 권고: 속도보다 권한부터 정하기
이 절은 소포스의 구현을 추가로 설명하는 내용이 아니라, 사례를 참고한 일반적인 도입 권고입니다. 자사 환경에 적용하려면 성과 수치부터 목표로 삼기보다 AI가 할 수 있는 일과 할 수 없는 일을 먼저 문서화하는 편을 권합니다.
예를 들어 자료 수집과 요약, 대응안 작성, 실제 조치 실행을 서로 다른 단계로 나눌 수 있습니다. 각 단계에 필요한 승인과 담당자를 정하면 “권고를 만들었다”와 “조치를 끝냈다”를 혼동하지 않을 수 있습니다.
시험 운영에서도 조사 시간과 대응 시간을 따로 기록하는 편이 좋습니다. 어떤 사건을 대상으로 했는지, 어느 시점부터 시간을 쟀는지, 사람에게 넘긴 사례를 어떻게 계산했는지까지 정해야 비교의 의미가 생깁니다.
사람 감독 역시 담당자 이름만 적는 것으로 끝내지 않는 편을 권합니다. 어떤 조건에서 자동 처리를 중단하고, 무엇을 확인한 뒤 승인하며, 잘못된 조치를 어떻게 되돌릴지까지 정해 두어야 운영 기준으로 사용할 수 있습니다.
빠른 조사와 책임 있는 대응은 함께 봐야 한다
이번 사례에서 주목할 지점은 큰 숫자만이 아닙니다. 조사 업무의 자동화와 고객이 정한 대응 권한을 함께 설명했다는 점입니다.
도입을 검토한다면 “우리도 89초가 가능한가”와 함께 “그 시간 안에 AI가 무엇을 했고, 무엇은 사람에게 남겼는가”를 물어보면 좋겠습니다. 속도와 책임의 경계를 함께 확인해야 자사에 맞는 자동화인지 판단할 수 있습니다.
한 줄 요약: 소포스·OpenAI Daybreak 사례의 핵심은 위협 조사 속도 개선뿐 아니라, AI의 조치 권한을 제한하고 위험한 결정에 사람 감독을 남긴 운영 방식입니다.
참고 출처
- OpenAI 공식 소포스 사례 — 2026년 10월 9일 공개. 성과 수치는 OpenAI·소포스 발표 기준입니다.
- OpenAI 공식 RSS에서 발행일 확인 — 정확 제목·발행일·공식 canonical·설명을 교차확인했습니다.
공식 원문은 같은 실행의 검색·본문 추출로 확인했습니다. 일반 HTTP 직접 접근은 403이었고, 공식 RSS는 HTTP 200으로 확인했습니다.
