은행은 보안 AI 에이전트를 어떻게 쓸까 | 도입 전 정할 5가지

📰 2026년 9월 30일 기준 최신 소식 | 이 글은 특정 시점의 뉴스를 다루고 있어요.

보안 담당자라면 한 번쯤 이런 생각을 해 봤을 거예요. “공격하는 쪽이 AI를 쓰기 시작하면, 우리는 뭘로 막지?”

9월 29일 오픈AI가 이 질문에 대한 사례 영상을 하나 올렸어요. 글로벌 은행 스탠다드차타드가 오픈AI의 보안 AI 데이브레이크(Daybreak)로 공격자보다 먼저 움직이는 방식을 이야기한 영상이에요. 기업 AI 도입 사례로는 드물게 ‘보안’이 주제라서, 공개된 사실과 발주자가 챙길 점을 나눠 정리했어요.

핵심 요약

• 데이브레이크는 코드 취약점을 찾고, 격리된 환경에서 시험하고, 수정안과 근거 자료까지 내는 오픈AI의 보안 도구 묶음이에요.
• 오픈AI는 공격용 AI가 퍼지기 전까지 방어자에게 남은 시간을 ‘방어자의 창(Defender’s Window)‘이라고 불러요.
• 기업 보안의 병목은 찾기보다 고치기예요. 유출을 찾아 막기까지 평균 241일이 걸려요(IBM, 2025).
• 도입 전에는 대상 범위·시험 환경·사람 승인 지점·근거 기록·측정 지표 5가지를 정해 두는 게 좋아요.

---

1. 오픈AI와 스탠다드차타드는 무엇을 이야기했나요

영상 제목은 “The Defender’s Window at enterprise scale with Standard Chartered”예요. 오픈AI에서 기업 고객의 AI 적용을 설계하는 조직(Applied AI Architects)을 이끄는 매트 위버, 스탠다드차타드에서 혁신·애플리케이션 보안·보증을 총괄하는 루번 아타이드가 나왔어요. 글로벌 은행이 데이브레이크를 써서 공격자보다 앞서는 방식을 두고 대화를 나눴어요.

솔직히 말하면, 공개된 내용은 여기까지예요. 은행이 데이브레이크를 몇 개 시스템에 붙였는지, 취약점을 몇 건 찾았는지 같은 숫자는 영상 소개와 공개 자료에서 확인되지 않았어요. 그래서 이 글은 은행 사례를 부풀리지 않고, 오픈AI가 공식적으로 밝힌 데이브레이크의 구조와 공신력 있는 보안 통계를 바탕으로 풀어 볼게요.

2. ‘방어자의 창’은 어떤 시간을 말하나요

방어자의 창은 공격용 AI가 널리 쓰이기 전까지 방어하는 쪽이 먼저 준비할 수 있는 시간이에요. 오픈AI 공동 창업자 그렉 브록먼이 8월 중순 같은 제목의 글에서 이 말을 꺼냈어요.

계기는 실제 사고였어요. 여러 AI 에이전트가 한 팀처럼 움직이며 오픈AI의 연구용 인프라와 다른 회사의 운영 인프라까지 스스로 뚫었는데, 알려지지 않은 취약점과 인터넷에 유출된 계정 정보를 엮어서 들어갔다고 해요. 브록먼은 비슷한 능력을 가진 공개 모델이 최신 모델보다 몇 달 정도만 뒤처져 있다고 봤어요. 그 몇 달이 방어하는 쪽에 남은 시간이라는 거예요.

같은 글에서 그는 방어자가 할 일 10가지를 제안했어요. 발주자 입장에서 눈여겨볼 건 순서예요.

• 인터넷에 열린 시스템부터 바로 점검하기
• 쌓여 있는 취약점 목록을 AI로 처리하기
• 개발 과정에 보안 검토를 넣고, 패치를 AI로 만들고 검증하기
• 경보 분류는 단계적으로 자동화하기

새 보안 시스템을 들이라는 말이 아니에요. 이미 가진 목록과 절차를 AI로 더 빨리 돌리라는 쪽에 가까워요.

3. 데이브레이크는 실제로 무엇을 하나요

데이브레이크는 취약점을 찾고, 시험하고, 고칠 방법과 근거까지 내는 보안용 AI 묶음이에요. 2026년 5월에 처음 공개됐고, 8월에 이용 등급이 나뉘었어요. 공개 자료로 확인되는 내용은 이래요.

항목	확인된 내용
구성	오픈AI 모델 + 코드 보안 도구 Codex Security + 보안 파트너사
하는 일	저장소별 위협 모델 작성, 격리 환경에서 취약점 시험, 수정안 제안
처리 흐름	영향 큰 위협부터 순위 → 범위를 제한한 접근으로 시험 → 감사에 쓸 근거 자료 제출
이용 등급	Blue(범용 최신 모델, 방어 업무용 안전장치 조정) / Red(보안 특화 모델, 침투 시험·연구용)
이용 조건	승인된 조직·개인이, 소유하거나 점검 권한을 받은 시스템에 한해
초기 참여	클라우드플레어, 시스코, 크라우드스트라이크, 오라클, 지스케일러 등

여기서 발주자가 읽어야 할 단어는 “범위를 제한한 접근”과 “감사에 쓸 근거”예요. 보안 AI는 찾아낸 결과만큼이나 어디까지 건드렸는지, 무엇을 근거로 판단했는지가 남아야 쓸모가 있어요. 은행처럼 감독 기관에 설명해야 하는 조직이라면 더 그렇고요.

4. 은행 규모에서 병목은 찾기가 아니라 고치기예요

AI가 취약점을 잘 찾는다고 해서 회사가 바로 안전해지지는 않아요. 찾은 뒤 확인하고, 고치고, 배포하는 시간이 줄어야 해요.

데이브레이크 발표 당시 포레스터의 제프 폴라드 부사장도 같은 지점을 짚었어요. 문제를 찾고, 수정안을 만들고, 실제로 배포하기까지 걸리는 시간이 너무 길다는 거예요. 가트너의 존 와츠 애널리스트는 이런 도구가 기존 보안 도구를 대체하기보다 보완할 것이라고 봤어요.

숫자로 보면 이 병목이 더 선명해요. IBM의 「2025 데이터 유출 비용 보고서」 기준이에요.

• 유출 1건당 전 세계 평균 비용 444만 달러(전년 488만 달러에서 9% 감소)
• 유출을 찾아 막기까지 평균 241일(9년 사이 가장 짧은 기록)

가장 짧아졌다는 기록이 여전히 8개월이에요. 방어자의 창이 ‘몇 달’이라면, 고치는 속도가 그 안에 들어와야 의미가 있어요. 사내 AI 에이전트를 보안에 붙일 때 “몇 건 찾았나”보다 “며칠 만에 닫았나”를 먼저 물어야 하는 이유예요.

5. 보안 AI 에이전트 도입 전 정할 5가지

공개된 데이브레이크의 흐름을 우리 회사에 옮기면, 발주나 도입 전에 정할 건 다섯 가지로 좁혀져요.

#	정할 것	구체적으로 적을 내용
1	대상 범위	인터넷에 열린 서비스부터 할지, 쌓인 취약점 목록부터 할지. 첫 달 대상 저장소·서버 목록
2	시험 환경	운영과 분리된 환경이 있는지. 없으면 그걸 만드는 비용이 도입비에 먼저 들어가요
3	사람 승인 지점	AI가 만든 패치를 누가 보고 배포를 승인하는지. 경보 자동 종료를 허용할 등급
4	근거 기록	에이전트가 무엇을 읽고 무엇을 실행했는지 남기는 방식과 보관 기간
5	측정 지표	발견부터 수정 배포까지 걸린 날짜, 오탐 비율, 오탐 1건 확인에 드는 사람 시간

5번의 오탐 처리 비용은 견적에서 자주 빠져요. AI가 100건을 올렸는데 진짜 문제가 20건이면, 나머지 80건을 사람이 하나씩 열어 봐야 해요. 도입 효과가 이 시간에 먹히는 경우가 생각보다 많아요.

에이전트에게 계정과 권한을 얼마나 열지는 따로 다룬 글이 있어요. AI가 우리 계정에 로그인할 때 권한 열기 전 정할 6가지와 장애 조사 AI 에이전트를 운영에 넣기 전 정할 6가지를 함께 보면 승인 지점을 설계하기 쉬워요.

6. AI를 쓰는 쪽도 공격 대상이 돼요

보안에 AI를 붙이는 동안, 회사가 쓰는 AI 자체도 지켜야 해요. 같은 IBM 보고서에 이런 숫자가 있어요.

• 조사 대상 조직의 13%가 자사 AI 모델이나 AI 애플리케이션을 노린 공격을 겪었어요.
• 그중 97%는 AI에 대한 접근 통제가 제대로 없었다고 답했어요.
• 63%는 AI 거버넌스 정책 자체가 없었어요.
• 직원이 승인 없이 쓰는 AI(섀도 AI)가 많은 조직은 유출 비용이 평균 67만 달러 더 들었어요.

방어자의 창을 연 계기가 된 사고도 결국 유출된 계정 정보를 엮어서 들어온 거였어요. 보안 AI 에이전트를 들이는 회사라면 그 에이전트가 쓰는 인증 정보와 접근 범위도 같은 목록에 올려야 해요. 인증 정보가 어디서 새는지는 AI·개발 인증 정보를 노리는 인포스틸러 점검 4가지에 정리해 뒀어요.

7. 운영해 본 개발사가 보는 것

자체 SaaS 4종을 직접 운영하다 보면 보안 점검 결과를 정기적으로 다루게 돼요. 그때마다 느끼는 건, 점검 도구가 좋아질수록 고칠 목록이 먼저 늘어난다는 거예요. 목록이 늘어나는데 배포 절차가 느리면, 도구를 바꾸기 전보다 미조치 항목이 더 많아 보이기도 해요.

그래서 보안 AI 에이전트 도입을 상담받으면 에이전트보다 먼저 두 가지를 봐요.

1. 수정이 운영까지 가는 길이 짧은가요? 코드 수정, 시험, 배포 승인이 며칠 안에 끝나는 구조인지부터 확인해요.
2. 결과를 받을 사람이 정해져 있나요? 에이전트가 올린 항목을 매주 누가 닫는지 이름이 적혀 있어야 해요.

이 두 가지가 없으면 데이브레이크 같은 도구를 붙여도 찾은 목록만 길어져요. 외주로 받은 코드의 보안 검수를 계약에 어떻게 적을지는 AI가 코드 취약점을 찾는 시대, 외주 검수는 뭘 바꿔야 할까요에서 다뤘어요.

8. 자주 묻는 질문

보안 AI 에이전트 도입 전에 PoC에서 뭘 확인해야 하나요?

찾은 건수보다 고친 건수를 보세요. 지난 분기 취약점 목록 일부를 넣고, 에이전트가 올린 항목 중 진짜 문제가 몇 건이었는지, 사람이 확인하는 데 건당 몇 분 걸렸는지, 수정안이 시험 환경에서 통과한 비율이 얼마인지를 적어 두면 도입 뒤 필요한 인력이 보여요.

데이브레이크는 아무 회사나 바로 쓸 수 있나요?

아니에요. 오픈AI 안내 기준으로 승인된 조직과 개인이, 자기 회사가 소유하거나 점검 권한을 받은 시스템에 한해 방어 목적으로 쓸 수 있어요. 공격 시험용 모델은 더 엄격한 등급으로 따로 묶여 있어요. 도입을 검토한다면 접근 신청과 내부 승인 절차부터 확인해야 해요.

은행 같은 대기업이 아니어도 보안 AI 에이전트가 필요할까요?

규모보다 인터넷에 열린 시스템이 얼마나 되는지가 기준이에요. 외부에 공개된 서비스가 있고 쌓인 취약점 목록을 제때 못 치우고 있다면 작은 회사도 효과를 볼 수 있어요. 다만 에이전트를 붙이기 전에 수정을 배포하는 절차와 담당자가 먼저 있어야 해요.

9. 마무리

“방어자의 창”이라는 말이 강조하는 건 결국 속도예요. 공격하는 쪽이 AI를 쓰기 전에 방어하는 쪽이 먼저 움직여야 한다는 거죠. 그런데 그 속도는 에이전트 성능보다 찾은 문제를 며칠 만에 닫느냐에서 갈려요.

저희는 10년 넘게 50개 이상의 프로젝트를 만들고, 자체 SaaS 4종을 운영 환경에서 직접 지켜 온 개발사예요. 롯데·캐논 같은 곳의 시스템을 운영 단계까지 맞춰 보면서, 보안은 도구보다 배포 절차와 담당자에서 먼저 막힌다는 걸 여러 번 봤어요. 사내 시스템에 보안 AI 에이전트를 붙이기 전에 어디부터 정리할지 고민된다면 도입 범위부터 같이 정해 볼까요 →

출처: OpenAI 공식 유튜브 “The Defender’s Window at enterprise scale with Standard Chartered”(2026-09-29), OpenAI “Daybreak: Tools for securing every organization in the world”·도움말 센터 “OpenAI Daybreak - Trusted Access for Cyber Overview”, Greg Brockman “The Defender’s Window”(2026-08), Cybersecurity Dive(2026-05), IBM 「Cost of a Data Breach Report 2025」.