AI 거버넌스의 격차: 왜 대부분의 기업 정책은 한 단계 늦을 수밖에 없는가

제가 본 모든 기업의 AI 거버넌스 프레임워크 (AI governance framework)에는 동일한 구조적 결함이 있습니다. 그것은 다음 사건을 방지하기 위해서가 아니라, 지난 사건을 방지하기 위해 작성되었다는 점입니다.

기업의 AI 거버넌스에는 제가 하나의 규칙이라고 부를 수 있을 정도로 자주 관찰되는 패턴이 있습니다.

한 조직이 최소한의 공식적인 거버넌스 (governance) 없이 AI 도구를 배포합니다. 그러다 무언가 잘못됩니다 — 데이터 노출, 컴플라이언스 (compliance) 위반 발견, 대중적인 망신, 혹은 AI 에이전트 (AI agent)가 아무도 예상치 못한 행동을 하는 내부 사고 등 말이죠. 조직은 정책 (policy)을 작성함으로써 이에 대응합니다. 그 정책은 정확히 발생했던 일만을 다룹니다. 동일한 근본 원인을 공유하는 17가지의 관련 실패 모드 (failure modes)에 대해서는 아무것도 말하지 않습니다.

그러면 또 다른 문제가 발생합니다. 또 다른 정책이 작성됩니다.

그 결과로 만들어진 거버넌스 프레임워크는 일관된 리스크 아키텍처 (risk architecture)라기보다는 반응적인 패치 (reactive patches)들의 집합체가 됩니다. 이는 설계 (design)에 의해서가 아니라 사고 (incident)에 의해 성장합니다. 그리고 각 정책이 미래 리스크의 범주가 아닌 특정 과거 사건만을 다루기 때문에, 프레워크에는 항상 격차(gap)가 존재합니다. 구체적으로, 아직 발생하지 않은 일들에 대한 격차 말입니다.

이것이 바로 AI 거버넌스의 격차 (AI governance gap)입니다. 대부분의 기업이 현재 이 격차 속에서 살아가고 있습니다.

왜 반응적 거버넌스 (Reactive Governance)가 AI에는 통하지 않는가

반응적 거버넌스는 대부분의 기업 리스크 관리 (risk management)에서 일반적인 방식입니다. 무언가를 배포하고, 실패 모드 (failure modes)를 발견하며, 통제 수단 (controls)을 추가합니다. 대부분의 기술 범주에서 이는 합리적인 접근 방식입니다. 리스크 환경 (risk landscape)이 잘 이해되어 있고, 실패 모드는 유한하며 알려져 있으며, 사고를 통해 이를 발견하는 비용도 수용 가능한 수준이기 때문입니다.

AI 시스템은 반응적 거버넌스를 특히 부적절하게 만드는 세 가지 특성을 가지고 있습니다.

실패 모드(Failure modes)가 새롭고 명확하지 않습니다. 잘못 설정된 방화벽은 예측 가능한 방식으로 작동을 멈춥니다. 하지만 에지 케이스(Edge-case) 입력값에 따라 작동하는 AI 에이전트는 이를 구축한 사람들조차 예상하지 못한 방식으로 실패하곤 합니다. 프롬프트 인젝션(Prompt injection) 공격, 컨텍스트 조작(Context manipulation), 멀티 에이전트 상호작용에서 발생하는 창발적 행동(Emergent behaviors), 시간이 지남에 따라 발생하는 모델 행동 드리프트(Model behavior drift) 등은 대부분의 기업 거버넌스 프레임워크가 기반을 두고 있는 기존의 위험 분류 체계(Risk taxonomy)에 깔끔하게 매칭되지 않습니다.

실패의 폭발 반경(Blast radius)이 클 수 있습니다. 민감한 데이터에 접근할 수 있고 도구 호출(Tool-calling) 기능이 있는 AI 에이전트는 실패 시나리오에서 인간이 개입할 수 있는 속도보다 더 빠르게 중대한 조치를 취할 수 있습니다. 자율적 행동과 광범위한 데이터 접근 권한의 결합은 대부분의 전통적인 소프트웨어보다 더 큰 잠재적 영향을 미치는 실패 모드를 생성합니다.

기술이 거버넌스가 추적할 수 있는 속도보다 더 빠르게 변화합니다. 18개월 전에는 존재하지 않았던 기능들이 현재 프로덕션(Production) 환경에서 실행되고 있습니다. 만약 조직의 거버넌스 프레임워크가 18개월 전에 작성되었다면, 그것은 현재 배포된 것과는 다른 범주의 AI를 위해 작성된 것입니다. 대부분의 기업은 실제로 실행되고 있는 환경을 반영하여 프레임워크를 업데이트하지 못했습니다.

선제적 AI 거버넌스(Proactive AI Governance)에 실제로 필요한 것

선제적 거버넌스는 다른 질문에서 시작합니다. "무슨 일이 일어났으며 어떻게 재발을 방지할 것인가"가 아니라, "우리의 현재 AI 아키텍처를 고려할 때 어떤 범주의 실패가 가능하며, 그중 우리가 아직 통제 수단을 갖추지 못한 것은 무엇인가?"라는 질문을 던지는 것입니다.

이것은 정책 작성(Policy writing) 연습이 아니라 위협 모델링(Threat modeling) 연습입니다. 그리고 이는 이론적이거나 지향적인 아키텍처가 아니라, 실제 현재의 AI 배포 상태를 대상으로 수행되어야 합니다.

1단계: 정확한 인벤토리(Inventory) 작성.

매핑되지 않은 것은 관리할 수 없습니다. 대부분의 기업은 거버넌스 팀이 파악하고 있는 것보다 훨씬 더 넓은 AI 발자국(Footprint)을 가지고 있습니다. 섀도우 AI(Shadow AI) 도입 — 직원들이 개인 AI 도구 계정을 사용하거나, 팀이 법인카드로 AI 구독을 결제하거나, 개발자가 공식적인 검토 없이 AI 기능을 구축하는 행위 — 은 실제 배포 현황이 승인된 목록을 상당한 차이로 초과하고 있음을 의미합니다.

인벤토리는 공식적으로 승인된 것이 아니라, 실제로 무엇이 실행되고 있는지에 대해 정직해야 합니다. 이 두 가지 사이의 격차 자체가 거버넌스 측면의 발견 사항(Finding)입니다.

2단계: 역량 수준의 리스크 분류 (Capability-level risk classification).

AI 배포를 도구의 이름이 아니라 역량 프로필(Capability profile)에 따라 분류하십시오. 즉, 이 시스템이 어떤 데이터에 접근할 수 있는지, 어떤 행동을 자율적으로 수행할 수 있는지, 루프 내에(In the loop) 어떤 인간의 감독이 존재하는지, 그리고 예상치 못한 동작을 할 경우 그 영향 범위(Blast radius)는 어디까지인지에 따라 분류해야 합니다.

문서를 요약하는 읽기 전용(Read-only) AI 어시스턴트는 데이터베이스에 기록을 남기거나, 통신을 보내고, 워크플로우 상태를 수정할 수 있는 AI 에이전트와는 근본적으로 다른 리스크 프로필을 가집니다. 첫 번째 사례에 적합한 거버넌스 통제(Governance controls)는 두 번째 사례에는 불충분합니다.

3단계: 도구가 아닌 역량에 따른 통제 매핑 (Control mapping against capabilities, not tools).

각 역량 수준의 리스크 카테고리에 대해 현재의 통제 항목을 매핑하고 격차를 식별하십시오. 중요한 통제 카테고리는 다음과 같습니다: 접근 제한(시스템이 무엇에 접근할 수 있는가), 행동 제한(시스템이 자율적으로 무엇을 할 수 있는가), 감사 로그(모든 AI 작업이 사후에 재구성될 수 있는가), 인간 에스컬레이션 경로(언제 인간에게 알림이 가거나 승인을 받아야 하는가), 그리고 사고 대응(문제가 발생했을 때 누가 알고 무엇을 하는가)입니다.

4단계: 신규 배포를 위한 필수 체크포인트 (Mandatory checkpoints for new deployments).

거버넌스 프레임워크는 새로운 AI 배포 시점에 마찰(Friction) — 의도적이고 적절하게 조정된 마찰 — 을 만들어내야 합니다. 질문은 "이 도구가 승인되었는가"가 아닙니다. 질문은 "이 배포의 역량 프로필은 무엇이며, 해당 프로필에 적합한 통제 장치가 마련되어 있는가"여야 합니다.

이 체크포인트(checkpoint)는 배포가 음성적으로 이루어지지 않을 만큼 충분히 빨라야 합니다. 6주가 소요되는 거버넌스(Governance)는 섀도우 AI(shadow AI) 배포를 양산할 것입니다. 표준 배포를 위해 구조화된 이틀간의 검토로 완료될 수 있는 거버넌스만이 실제로 사용될 것입니다.

거버넌스에서 아키텍처의 역할

대부분의 거버넌스 프레임워크(governance frameworks)가 놓치고 있는 핵심은 바로 이것입니다: 아키텍처(architecture)가 곧 거버넌스라는 점입니다.

데이터가 인프라 외부로 절대 나가지 않는 셀프 호스팅(self-hosted) AI 배포는 단순한 아키텍처적 선택이 아닙니다. 이는 거버넌스의 단순화입니다. 이는 위험의 한 범주(데이터가 외부 인프라를 통과하는 것)와 그에 따른 통제 요구 사항(벤더의 데이터 처리 합의서(DPA), 하위 프로세서(subprocessor) 검토, 데이터 레지던시(data residency) 확인, 제3자 사고 통지)을 통째로 제거합니다.

데이터 주권(data sovereignty)을 제약 조건으로 하여 AI 아키텍처를 설계할 때, 여러분은 단순히 데이터를 보호하는 것이 아니라 거버넌스 프레임워크를 더 단순하고 실행 가능하게 만드는 것입니다. 데이터가 어디에 있는지 알게 됩니다. 데이터가 실행되는 인프라를 직접 제어합니다. 벤더의 증명(attestations)에 의존하는 대신 통제 장치를 직접 검증할 수 있습니다.

이것이 바로 거버넌스 논의와 아키텍처 논의가 동시에 이루어져야 하는 이유입니다. 거버넌스 팀은 AI 배포를 기정사실로 받아들인 뒤 이를 어떻게 통제할지 고민해서는 안 됩니다. 그들은 아키텍처 결정이 거버넌스 요구 사항을 생성하거나 제거하는 설계 프로세스의 일부가 되어야 합니다.

실질적인 시작점

만약 현재의 거버넌스 프레임워크가 1년 이전에 마지막으로 업데이트되었거나, 선제적인 리스크 모델(proactive risk model)이 아닌 특정 사고에 대한 대응으로 작성되었다면, 여러분이 할 수 있는 가장 가치 있는 일은 보안, 법무 및 엔지니어링 리드(leads)와 함께 반나절 동안 워킹 세션(working session)을 예약하여 다음 질문들에 대해 솔직하게 답하는 것입니다:

현재 우리 환경에서 실제로 실행되고 있는 AI 시스템은 무엇인가요? 공식적으로 승인되지 않은 시스템을 포함해서 말입니다. 각각의 시스템은 무엇에 접근할 수 있으며, 자율적으로 무엇을 수행할 수 있나요? 만약 우리가 보유한 가장 강력한 AI 시스템이 내일 예상치 못한 방식으로 동작한다면, 우리는 한 시간 이내에 이를 인지할 수 있을까요? AI 에이전트(AI agent)의 행동에 대한 현재의 감사 추적(audit trail)은 어떻게 되어 있나요?

이 질문들에 대한 답변은 여러분의 거버넌스 격차(governance gaps)가 어디에 있는지 알려줄 것입니다. 사고가 발생한 후에 대응하는 것보다 사고가 발생하기 전에 이를 해결하는 것이 훨씬 더 비용이 적게 듭니다.