AI 거버넌스 리스크: 반복되는 사고 패턴과 체크리스트

보안 사고 브리핑에서 “전례 없는 방식”이라는 표현을 보면 나는 그 말을 먼저 의심한다. 이 글은 특정 사고의 책임을 가리는 대신, AI 연동에서 실패가 반복되는 구조가 무엇이고 도입 전에 어디를 확인해야 하는지를 다룬다. 23년간 AI·데이터 전환 프로젝트를 해오며 사고 리뷰에 여러 번 들어가 봤는데, 거기서 확인한 것은 대개 이미 한 번은 지적됐던 시나리오였다는 사실이다.

문제 정의: “전례 없다”는 말이 반복되는 이유

OpenAI와 Hugging Face 연동 과정에서 발생한 침해 사고 기사를 봤다^[1]. 기사 제목에 “unprecedented”라는 단어가 박혀 있었다^[2]. 이 단어를 볼 때마다 드는 생각이 있다 — 이런 사고 브리핑에서는 거의 항상 “이런 경로로 노출된 건 전례가 없다”는 말이 나오는데, 실제로는 리스크 리뷰 단계에서 이미 지적됐던 시나리오인 경우가 적지 않다는 것이다. 조직은 매번 같은 실수를 하면서 매번 “이번엔 처음 겪는 일”이라고 말한다.

23년간 AI·데이터 전환 프로젝트를 하면서 본 컨테인먼트 실패는 대부분 새로운 유형이 아니었다. 권한 범위, 외부 연동, 사고 대응 체계. 늘 이 세 가지 축에서 반복되는 패턴이었다.

원인 분석①: AI 컨테인먼트 실패가 반복되는 구조적 원인 (조직·책임 분산·속도 압박)

컨테인먼트 실패의 본질은 기술 결함이 아니다. 조직 구조의 결함이다. AI 추천 엔진 같은 파일럿에서, 보안팀과 AI팀이 같은 회의실에 앉아서도 서로 다른 문서를 보고 있는 상황은 드물지 않다. AI팀은 모델 허브에서 가져온 사전학습 모델의 라이선스와 성능만 검토하고, 보안팀은 그 모델이 어떤 외부 API를 호출하는지조차 파악하지 못한 채로 회의가 진행되는 경우가 있다. 이런 회의는 결국 “누가 이 부분을 승인했는가”를 따지는 데 상당한 시간을 소모하고 끝난다.

낯선 상황이 아니다. 파일럿 킥오프 회의에서 흔히 나오는 말이 “일단 되게 하자, 거버넌스는 나중에 정리하자”다. 이 한 문장이 체크 게이트를 통째로 생략시킨다. 속도 압박은 실제로 존재하는 사업적 압력이라, 그걸 무시하라는 조언은 현장에서 통하지 않는다. 진짜 문제는 속도와 거버넌스를 양자택일로 놓는 프레임 그 자체다.

원인 분석②: 컨설팅 현장에서 반복적으로 나타나는 리스크 패턴과 놓치기 쉬운 신호

놓친 신호는 항상 사고 이전에 이미 존재한다. 챗봇 파일럿에서 권한 범위 검증 없이 서비스 계정 하나가 사내 시스템 전체 조회 권한을 갖고 있는 경우를 여러 차례 발견했다. 담당자에게 물어보면 대체로 “테스트할 때 편해서 그냥 넓게 열어뒀다”는 취지의 답이 돌아온다. 이 답을 들을 때의 느낌은 놀라움이 아니라 익숙함에 가깝다 — 여러 프로젝트에서 반복적으로 보는 패턴이기 때문이다.

API 연동 리스크를 점검할 때 HashiCorp Vault로 시크릿을 관리하는 방안과 AWS Secrets Manager를 그대로 쓰는 방안을 흔히 비교하게 된다. Vault는 세밀한 정책 기반 접근 제어와 동적 시크릿 발급이 강점이라 다중 클라우드·다중 팀 구조에는 적합하지만, 러닝커브가 있어서 촉박한 파일럿 일정에는 부담이 된다. 반면 AWS Secrets Manager는 이미 쓰던 AWS 환경에 바로 붙일 수 있어 빠르게 적용 가능하지만, 세분화된 권한 정책을 짜는 데는 한계가 있다.

속도를 택해 Secrets Manager로 가는 선택 자체는 합리적일 수 있다. 문제는 권한 범위를 “넓게 열어두고 나중에 좁히자”로 처리하는 경우가 많다는 점이다. 사고 대응 프로토콜도 마찬가지다 — 침해가 발생했을 때 초기 대응 시점에 누가 무엇을 해야 하는지 문서화돼 있지 않은 경우가 흔하다.

해결 방법론: “기술 통제”에서 “거버넌스 프로세스 통제”로

특정 사고 하나가 아니라 반복되는 패턴 자체가 이 관점을 바꿔놓았다. 여러 프로젝트의 리스크 로그를 시간순으로 놓고 보면, 사고 유형은 결국 4가지 안에서 반복된다는 게 드러난다. 권한 과다 부여, 외부 연동 미검증, 로깅 부재, 책임자 불명확.

기술 스택은 매번 달랐다. 어떤 곳은 Splunk로 로그를 모았고, 어떤 곳은 Datadog을 썼다. 그런데도 사고가 터진 이유는 도구가 아니라 “이 로그를 누가 보고 언제 판단하는가”라는 프로세스가 없었기 때문이었다. Splunk는 방대한 로그를 규칙 기반으로 정교하게 분석할 때 강했고, Datadog은 인프라·애플리케이션 모니터링과 통합된 대시보드로 팀이 빠르게 상황을 파악하는 데 유리했다.

둘 중 뭘 쓰든 상관없었다. 결정적인 건 “이상 징후 발견 시 30분 내 누구에게 에스컬레이션한다”는 룰이 문서로 존재하느냐였다. 이때부터 나는 리스크 리뷰 질문지를 기술 항목(“어떤 모델을 쓰나요”)에서 프로세스 항목(“이 파일럿이 뚫렸을 때 첫 대응자는 누구인가요”)으로 바꿨다.

적용 시 체크리스트: AI 거버넌스 검토에 반드시 넣어야 할 항목들

체크리스트는 사후 감사 문서가 아니다. 파일럿 승인 전 필수 게이트로 작동해야 한다. 지금 다시 프로젝트를 맡는다면 아래 항목을 승인 단계에서 빠짐없이 확인할 것이다.

– 권한 범위: 서비스 계정·API 키가 필요한 최소 권한만 갖는지, 만료 기한이 설정돼 있는지

– 외부 연동 리스크: 모델 허브·API 제공자와의 데이터 흐름을 도식화했는지, 계약서에 침해 시 통보 의무가 명시됐는지

– 사고 대응 프로토콜: 이상 징후 발견 후 30분·2시간·24시간 단위 대응 주체와 절차가 문서화됐는지

– 로깅·모니터링 책임자: 로그를 누가 매일 보는지, 담당자 부재 시 대체자가 있는지

– 책임 분산 여부: 보안팀과 AI팀이 같은 리스크 문서를 공유하는지, 승인 서명이 한 명에게 몰려 있지 않은지

이 5가지 중 하나라도 빈칸이면 파일럿 킥오프를 늦춘다. 실무에서 가장 저항이 큰 부분이 바로 이 지점이다. 사업 담당자는 “일정 늦추면 손해”라고 하지만, 내 경험상 이 게이트를 건너뛴 프로젝트의 사고 복구 비용은 게이트 준수로 늦어진 2주보다 훨씬 컸다.

결론: ‘전례 없음’이 아니라 ‘반복되는 리스크’로 인식을 바꿔야 하는 이유

‘전례 없음’이라는 표현은 사고 원인 설명이 아니다. 조직의 리스크 인식 실패를 보여주는 자백에 가깝다. OpenAI-Hugging Face 침해 사고 역시 권한 범위, 외부 연동, 대응 프로토콜이라는 익숙한 세 축에서 벌어졌다. 새로운 건 모델의 성능이었고, 뚫린 방식은 낡은 방식이었다.

23년간 이 일을 하면서 배운 건 단순하다. 사고는 기술이 나빠서 나는 게 아니다. 이미 알고 있던 리스크를 “이번엔 괜찮겠지”라며 넘긴 그 순간에 난다. 다음 파일럿 킥오프 회의에서 누군가 “이런 사고는 우리한테 안 일어난다”고 말한다면, 나는 그 말을 신호로 받아들인다. 체크리스트를 다시 꺼낼 시점이라는 신호다.

관련 글

– AI 보안 도구 도입 전 반드시 확인할 5가지 체크포인트

– AI 도입 첫 3개월에 놓쳤던 거버넌스 설계