넉 달 전 사고를 지금 찾아낸 회사, 오늘 사고도 못 찾는 회사

AI 거버넌스라고 하면 대개 규정 문서와 승인 절차를 떠올리게 됩니다. 무엇을 금지할지 정하고 누가 결재할지 정하고, 위반하면 어떻게 할지 적어두는 일 말입니다. 그런데 지난달 프런티어 AI 업계에서 벌어진 일을 따라가 보면 실제로 조직을 구해낸 건 규정이 아니라 기록이었습니다.

지난달에 무슨 일이 있었나

간단히만 짚겠습니다. 7월 21일 오픈AI가 자사 모델 몇 개가 격리된 시험 환경을 뚫고 나가 허깅페이스의 운영 인프라에 접근했다고 발표했습니다. 이 발표를 본 앤트로픽이 자기 평가 기록을 되짚기 시작했고 열흘 뒤인 7월 30일에 세 건의 사고를 공개했습니다. 클로드가 시험 환경 안에서 인터넷에 닿아 실제 조직 세 곳의 운영 인프라에 무단 접근한 사례였으며 가장 이른 건은 4월까지 거슬러 올라갔습니다.

사고 자체의 기술적 원인과 사내 에이전트에 주는 교훈은 앞선 글에서 다뤘습니다. 이 글에서 보려는 건 다른 지점입니다.

넉 달 전에 벌어진 일을, 어떻게 지금 찾아냈을까요.

사고를 찾아낸 쪽은 침입당한 조직이 아니었습니다

앤트로픽 보고서를 읽다 보면 사고 내용보다 이 대목에 눈이 더 오래 머뭅니다. 피해를 입은 세 조직 중 연락이 닿은 두 곳은 그 활동을 스스로 탐지한 적이 없었고 앤트로픽에 연락해온 적도 없었습니다. 나머지 한 곳은 발표 시점까지 연락이 닿지 않은 상태였습니다.

피해가 사소했던 것도 아닙니다. 세 건 중 가장 심각했던 사고에서는 취약한 비밀번호와 인증 없는 접점을 통해 애플리케이션과 인프라 인증 정보가 빠져나갔고 운영 데이터베이스에서 수백 행이 조회됐습니다. 그런데 당한 쪽은 몰랐습니다. 가장 이른 사고가 4월 건이니 어떤 조직은 넉 달 가까이 모르고 지냈다는 뜻입니다.

알아낸 건 침입한 쪽이었습니다. 그 회사는 남의 발표를 보고 자기 기록을 다시 뒤졌고 아무도 신고하지 않은 사고를 스스로 찾아내 피해 조직에 알렸습니다.

여기서 거버넌스의 통념 하나가 뒤집힙니다. 거버넌스의 목표는 사고를 완전히 막는 게 아닙니다. 세계에서 가장 정교한 안전팀을 굴리는 회사에서도 사고는 났습니다. 목표는 사고가 났을 때 알아차리고 무슨 일이었는지 설명하고, 고칠 수 있는 상태를 미리 만들어두는 쪽입니다.

사고 대응이 9일 만에 끝났습니다

앤트로픽이 이 사고를 처리한 과정을 날짜순으로 늘어놓으면 그 자체가 하나의 교본이 됩니다.

남의 사고 소식을 듣고 9일만에 자기 사고를 찾아내서 알리기까지 갔습니다. 이게 가능하려면 그전에 갖춰져 있어야 하는 게 있습니다.

기록이 남아 있어야 합니다. 검토 대상이 된 실행 기록만 141,006건이었습니다. 모델이 무엇을 시도하고 어떤 판단을 했는지가 전부 남아 있었기 때문에 사후 검토가 가능했습니다.

쌓여만 있고 뒤질 수 없는 로그는 없는 것과 같습니다. 14만 건에서 "인터넷에 접근했을 가능성이 있는 실행"을 걸러낼 수 있었기 때문에 하루 만에 세 건으로 좁혀졌습니다. 기록은 남기는 데서 끝나지 않고 검색이 되는 형태여야 합니다.

검토를 시작한 그날 모든 사이버 평가를 중단했습니다. 원인을 다 알기 전에 일단 세운 겁니다. 멈출 권한이 있어야 이런 판단이 나옵니다. 조직에 이 권한이 명시돼 있지 않으면 실무자는 "확실해지면 보고하자"고 미루게 되고 그사이 피해는 계속됩니다.

앤트로픽은 여러 요인이 겹친 사고였지만 책임을 묻지 않는 사후 분석 문화에 따라 마치 책임이 전적으로 자기들에게 있는 것처럼 접근하겠다고 밝혔습니다. 책임을 따지지 않는 사후 검토 문화가 깔려 있지 않으면 나오기 어려운 태도입니다. 누구 잘못인지 가리는 회의부터 열리는 조직에서는 실무자가 로그를 지웁니다.

여기에 더해 앤트로픽은 자기가 자기를 검사한 결과를 남에게 다시 검사받는 쪽으로도 움직였습니다. 독립 평가 기관인 METR과 제3자 검토를 논의 중이라고 밝혔고 악성 패키지를 만든 실행 기록을 일부 가린 형태로 공개하겠다고 했습니다.

우리 회사라면 며칠 걸릴까요

이 질문이 이 글의 전부입니다.

만약 다음 주에 어떤 AI 회사가 자사 모델의 사고를 공개하면서 "이 취약점을 쓰는 조직은 자체 점검을 권한다"고 발표했다고 해봅시다. 우리 회사는 무엇을 할 수 있을까요.

지난 4월에 사내에서 어떤 에이전트가 어떤 시스템에 접근했는지 조회할 수 있습니까. 조회한다면 며칠이 걸립니까. 애초에 사내에 몇 개의 에이전트가 돌고 있는지는 세어볼 수 있습니까.

대부분의 조직은 세 번째 질문에서 막힙니다. 각자 노트북에서 각자 계정으로 각자 방식으로 쓰고 있으니 목록 자체가 없습니다. 목록이 없으면 점검할 대상도 없고 점검할 대상이 없으면 사고가 났는지 안 났는지를 영원히 알 수 없습니다. 사고가 없는 게 아니라 사고를 셀 수 없는 상태입니다.

규제는 이미 이 방향을 보고 있습니다

국내에서는 AI 기본법이 2026년 1월 22일 시행에 들어갔고 과기정통부는 최소 1년 이상의 과태료 계도기간을 운영하겠다고 밝혔습니다. 저희가 앞서 정리한 체크리스트에서 짚었듯 계도기간이라는 건 위반해도 과태료를 물리지 않겠다는 뜻이지 아무 일도 없다는 뜻이 아닙니다. 시정명령은 나올 수 있고 그걸 어기면 과태료가 붙습니다. 고영향 AI로 분류되면 위험관리 문서와 영향평가를 갖춰야 하고 알고리즘이 어떤 기준으로 판단했는지 설명할 수 있어야 하며, 최종 결정은 사람이 내리는 구조를 만들어두어야 합니다.

이 요구사항들의 공통점을 보시면 흥미롭습니다. 전부 나중에 설명할 수 있느냐를 묻고 있습니다. 무엇을 금지하라는 조항보다 무슨 일이 있었는지 재구성해서 보여줄 수 있느냐를 확인하는 쪽에 무게가 실려 있습니다.

그리고 이번 사고를 두고 국제적으로는 기업의 자체 안전성 평가만으로는 부족하니 제3자 검증과 정부 차원의 감독 체계를 강화해야 한다는 논의가 나오고 있습니다. 밖에서 요구하는 설명 책임의 수준은 올라가는 중인데 안쪽 사정을 보면 실행 기록조차 남지 않는 조직이 훨씬 많습니다.

발견 가능한 조직의 조건

첫 번째 항목이 나머지를 좌우합니다. 목록이 없는 이유는 관리를 안 해서가 아니라 애초에 개인이 각자 만들어 쓰는 구조이기 때문입니다. 잘 쓰는 직원일수록 자기 방식을 다듬고 그 방식은 그 사람 노트북 안에 있습니다. 조직 입장에서는 자산이 쌓이지 않고 사각지대가 늘어납니다.

그래서 이 문제는 감사 도구를 하나 붙여서 해결되지 않습니다. 에이전트를 만들고 쓰는 자리 자체를 회사 안으로 옮겨야 목록이 생기고 목록이 생겨야 나머지가 따라옵니다.

Dify 엔터프라이즈를 기반으로 쓰는 이유가 여기 있습니다. SAML/OIDC 기반 SSO와 워크플로 단위까지 내려가는 RBAC로 누가 무엇에 접근할 수 있는지를 정하고 위변조 감지형 감사 로그를 사내 SIEM으로 흘려보내 기존 보안 관제 안에서 함께 보게 하며, 호출 단위 추적과 개인정보를 가린 프롬프트 이력을 남깁니다. 배포도 VPC와 온프레미스, 완전 폐쇄망까지 골라서 데이터를 사내 경계 밖으로 내보내지 않고 운영할 수 있습니다. 국내 규제 요건 충족 여부는 개별 환경에 따라 별도 검토가 필요하지만 적어도 기록을 남기고 되짚을 수 있는 토대는 여기서 만들어집니다.

다만 도구를 깐다고 목록이 저절로 생기지는 않습니다. 어떤 업무에 에이전트를 둘지 정하고 각각에 어떤 권한 경계를 그을지 설계하고, 실무진이 직접 만들 수 있게 해서 음지에서 양지로 끌어내는 과정이 함께 가야 합니다. ONS AX Foundry에서 과제를 발굴하는 Discovery 단계와 보안·거버넌스를 설계하는 Design 단계, 그리고 매월 상태를 점검하는 Operate 단계를 하나로 묶어놓은 것도 이 때문입니다.

지금 상태를 가늠해보는 질문

사내에 AI 에이전트가 몇 개나 돌고 있는지를 목록으로 답할 수 있느냐가 출발점입니다. 목록이 있다면 그다음은 각 에이전트가 어떤 시스템에 접근 가능한지가 문서로 남아 있느냐이고, 거기까지 통과하면 석 달 전 실행 기록을 조회할 수 있느냐와 조회에 며칠이 걸리느냐가 남습니다.

파악이 된다고 끝나지도 않습니다. 이상 징후를 발견했을 때 누가 어떤 절차로 중단시키는지가 정해져 있어야 하고 그 사고 대응 절차를 실제로 한 번이라도 연습해본 적이 있어야 합니다. 문제가 생겼을 때 책임을 가리기 전에 원인을 보는 회의가 열리는지도 같이 걸립니다.

막힌 데가 한 곳이 아니었다면 지금 필요한 건 새로운 규정 문서가 아닙니다. 규정은 이미 어딘가에 있을 테고 없는 건 그 규정이 지켜졌는지 확인할 방법입니다.

이번 사건을 보면서 오래 남은 인상은 두 회사 모두 자기에게 불리한 사실을 먼저 꺼냈다는 쪽이었습니다. 오픈AI가 자기 실수를 공개했기에 앤트로픽이 자기 기록을 다시 뒤졌고 앤트로픽이 찾아냈기에 아무도 모르던 피해 조직들이 자기가 당했다는 사실을 알게 됐습니다. 그렇게 할 수 있었던 건 결국 기록이 남아 있었기 때문이고 그 기록은 그렇게 설계해뒀기 때문에 남았지 누가 시켜서 남은 게 아닙니다. 사내에서 에이전트를 몇 개나 굴리고 있는지도 모르는 상태로는 이런 대응이 시작조차 되지 않습니다. 완벽하게 막는 일은 누구도 못 하지만 뚫렸을 때 알아차릴 수 있느냐는 지금 정해둘 수 있습니다.

사내 AI 에이전트의 현황 파악과 권한 경계 설계를 어디서부터 손봐야 할지 막막하시다면 ONS AX Foundry에서 지금 상태를 함께 짚어보셔도 좋습니다.

오픈네트웍시스템 ㅣ 권태규