기계 속도로 거버넌스하기: 실시간 AI 정책 집행을 위한 적응형 아키텍처를 읽고

이번 글에서 다루는 논문은 Governing at Machine Speed: An Adaptive Intelligence Architecture for Real-Time AI Policy Enforcement이며, arXiv에 arXiv:2609.13466으로 공개된 연구입니다. 원문 링크는 제목 아래에 붙어 있습니다.

이 논문의 주장은 기업의 AI 거버넌스 실패가 기술 부족이 아니라 실행 경로에서 정책을 실시간으로 집행하지 못하는 조직과 아키텍처의 문제이며 AGIL이라는 다섯 층위의 적응형 구조로 그 간극을 메울 수 있다는 것이고, 이 글에서는 증명하지 못하는 거버넌스가 왜 생기는지와 탐색부터 집행과 감사까지 이어지는 설계가 실제로 무엇을 바꾸는지를 차례로 풀어봅니다.

문서는 있는데 증명은 왜 없을까

여러 사람이 함께 일하는 조직을 떠올려 보시면 감이 옵니다. 규칙 문서는 책상마다 있는데, 막상 문제가 터졌을 때 누가 언제 어떤 결정을 내렸는지 복원할 수 없는 경우가 있죠. 로그는 여기저기 흩어져 있고, 담당자는 바뀌었고, 결재 기록은 메일로만 남아 있습니다. AI 거버넌스에서도 비슷한 일이 벌어지고 있습니다.

논문은 이 상태를 attestation deficit라고 부릅니다. 정책을 갖고 있다는 것과 집행을 증명할 수 있다는 것은 다른 일인데, 많은 조직이 전자에는 익숙하고 후자에는 준비가 안 되어 있다는 진단입니다. 규제 기관이 요구하는 시간 안에 감사 가능하고 변조 흔적이 남는 방식으로 집행 증거를 내놓지 못하면, 문서상 거버넌스는 있어도 실제로는 없는 것과 비슷해집니다.

안녕하세요, 패트릭입니다. 제가 이 논문에서 가장 흥미롭게 본 부분은 바로 이 단어 선택입니다. 저자들은 실패를 기술의 미성숙으로 돌리지 않습니다. 모델이 똑똑하지 않아서가 아니라, 거버넌스가 실행 흐름 밖에 서 있기 때문이라고 말합니다. 정책은 회의실에서 만들어지고, AI는 현장에서 돌아가는데, 둘을 잇는 기계가 없다는 것이죠.

그렇다면 그 기계는 어떤 모양이어야 할까요? 그 질문을 들고 논문을 따라가 보겠습니다.

78%라는 숫자는 절반만 말해줍니다

논문이 인용하는 숫자는 얼핏 보면 서로 따로 노는 것처럼 보입니다. 전 세계 조직의 78%가 이미 엔터프라이즈 AI를 쓰고 있다는 도입률, Stanford 2026 AI Index Report에 기록된 362건의 AI 관련 사고, IBM과 Ponemon의 2026년 데이터 유출 비용 연구에서 나온 평균 499만 달러라는 금액과 접근 통제가 없었다는 92%라는 비율, 그리고 EY와 AIUC-1 컨소시엄 조사에서 나온 38%의 종단 간 모니터링과 17%의 에이전트 간 커버리지까지요.

그런데 이 숫자들을 한 줄로 세우면 이야기가 달라집니다. 쓰는 곳은 많은데 보는 눈은 적다는 것이죠. 78%가 도입했다는 것은 AI가 이미 일상 업무 안에 들어왔다는 뜻입니다. 반면 종단 간 모니터링이 38%에 그친다는 것은 절반이 넘는 흐름이 중간에 끊겨 보인다는 뜻이고, 에이전트 간 커버리지가 17%라는 것은 AI끼리 주고받는 일은 거의 보지 못한다는 뜻입니다.

여기서 잠깐 현장 장면을 그려보겠습니다. 월요일 아침에 마케팅 에이전트가 고객 데이터를 요약하고, 그 요약을 영업 에이전트가 받아서 견적 메일을 쓰고, 그 메일에 붙은 첨부 조건을 다시 검토 에이전트가 확인하는 흐름이 있다고 해보죠. 각각의 에이전트는 로그를 남깁니다. 하지만 세 로그를 한 사건으로 엮어주는 끈이 없으면, 나중에 문제가 생겼을 때 누가 무엇을 근거로 판단했는지 재구성하기가 어렵습니다. 숫자로 보면 78 대 38 대 17이라는 간극이 바로 이 장면을 가리킵니다.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 사고 362건이 많으냐 적으냐를 따지기 전에, 사고가 났을 때 원인을 추적할 수 있는 구조였는지를 먼저 물어야 하기 때문입니다.

사고는 기술이 아니라 틈에서 생깁니다

사고 소식을 들을 때마다 우리는 모델 탓부터 하게 됩니다. 환각이 있었겠지, 학습 데이터가 오염됐겠지, 모델이 지시를 잘못 따랐겠지, 이렇게 말이죠. 물론 그런 원인이 있는 경우도 있습니다. 하지만 논문이 던지는 질문은 조금 결이 다릅니다. 모델이 완벽했더라도 막을 수 있었을까, 라는 질문입니다.

IBM과 Ponemon 연구에서 92%가 접근 통제를 갖추지 못했다는 대목은 그래서 눈에 밟힙니다. 평균 비용 499만 달러라는 금액 자체보다, 그 사고들 가운데 상당수가 문을 잠그지 않은 집에서 벌어진 일과 비슷한 구조였다는 점이 더 뼈아프기 때문입니다. 누가 어떤 데이터에 닿을 수 있는지, 어떤 에이전트가 어떤 도구를 호출할 수 있는지를 실행 시점에 묻지 않으면, 모델 성능이 좋아질수록 피해의 속도만 빨라집니다.

EY 조사에서 나온 38%와 17%도 같은 방향을 가리킵니다. 종단 간으로 보지 못하면 사건의 앞뒤가 끊기고, 에이전트 사이를 보지 못하면 책임의 소재가 흐려집니다. 사람 조직으로 치면 결재선 없이 돈을 쓰고 사후 보고서만 쓰는 셈인데, 그 보고서마저 자동 생성된 요약에만 의존하면 감사는 더 어려워집니다.

그렇다면 이 흐름은 어디에서 끊을 수 있을까요? 그 이야기는 집행 장치를 다룰 때 다시 꺼내겠습니다.

저는 이 실패를 조직과 구조의 문제로 읽었습니다

논문에서 제가 고개를 끄덕인 대목은 진단의 방향입니다. 거버넌스 실패는 조직적이고 아키텍처적인 문제이지 기술적인 문제가 아니라는 문장인데요. 처음에는 조금 심심하게 들릴 수도 있습니다. 그런데 곰곰이 뜯어보면 꽤 날카로운 지적입니다.

많은 기업에는 이미 정책이 있습니다. 데이터 분류 기준도 있고, 개인정보 처리 원칙도 있고, 모델 사용 가이드도 있습니다. 문제는 그 정책이 코드로 살아 있지 않다는 데 있습니다. PDF에는 있는데 트래픽 경로에는 없는 것이죠. 그래서 새로운 모델이 들어오거나 에이전트가 늘어나면 정책은 그 속도를 못 따라가고, 현장에서는 각 팀이 알아서 판단합니다. 중앙 거버넌스팀은 사후에 설문을 돌리고, 보고서를 모으고, 예외를 승인하느라 바빠집니다.

생각해보면 사람도 비슷하게 배웁니다. 규칙을 외우는 것만으로는 행동이 안 바뀌고, 행동이 일어나는 순간에 멈추거나 고쳐주는 장치가 있어야 습관이 바뀌죠. 헬스장에 가지 않으면서 운동 계획을 세우는 것과 같습니다. 계획은 있는데 실행과 연결된 고리가 없는 상태랄까요.

저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 같은 눈으로 보면 이 논문의 진짜 주장은 숫자가 아니라 위치에 있습니다. 거버넌스를 문서 창고가 아니라 트래픽 한가운데로 옮기자는 것이죠.

거버넌스를 회의실이 아니라 길목에 두면

여기서 논문이 제안하는 AGIL이 등장합니다. Adaptive Intelligence를 표방하는 다섯 층위의 구조인데요. 논문을 조금 더 들여다보면 다섯 층위를 하나하나 외우는 것보다 전체 방향을 잡는 편이 도움이 됩니다. 발견하고, 판단하고, 집행하고, 기록하고, 다시 배우는 흐름을 실행 경로 안에 넣겠다는 것입니다.

저는 이 발상을 톨게이트에 비유해서 이해했습니다. 고속도로를 다닌다고 해보죠. 차가 얼마나 빠른지 일일이 외우게 하는 대신, 모든 차가 반드시 지나가는 지점에 게이트를 두고 거기서 속도와 통행권을 확인합니다. AGIL이 말하는 Policy Enforcement Gateway도 비슷한 자리입니다. AI 요청과 에이전트 호출이 지나가는 길목에서 허용과 거부와 수정을 실시간으로 가르는 것이죠.

이 차이가 생각보다 중요합니다. 사후 감사는 사고가 난 뒤에 영상을 돌려보는 일에 가깝습니다. 반면 인라인 집행은 사고가 나기 전에 핸들을 잡는 일에 가깝습니다. 물론 사후 분석이 필요 없다는 뜻은 아닙니다. 다만 증명은 사후 보고서가 아니라 집행 기록에서 나와야 한다는 것이 논문의 입장이고, 저는 그 순서가 맞다고 봅니다.

그렇다면 길목에 선 게이트는 무엇을 보고 판단할까요? 다음 두 층위가 그 눈과 손에 해당합니다.

모르는 AI부터 찾아야 하는 이유

기업 현장에서 가장 곤란한 질문은 의외로 단순합니다. 지금 우리 회사에서 어떤 AI가 어디에서 돌고 있나요? 클라우드에서 쓰는 거대 모델은 알아도, 팀마다 붙인 작은 에이전트나 외부 도구에 연결된 자동화까지 다 아는 경우는 드뭅니다. 모르는 상태에서 거버넌스를 논하면 정책은 처음부터 빗나갑니다.

그래서 첫 번째 층위인 Autonomous Discovery가 눈에 들어옵니다. 논문은 행동 지문이라는 표현을 쓰는데, 등록 대장을 믿는 대신 실제 행동을 보고 AI를 찾아낸다는 발상입니다. 누가 어떤 주기로 어떤 데이터에 접근하고, 어떤 도구를 호출하고, 어떤 패턴으로 응답하는지를 보고 이 흐름은 어떤 종류의 AI 활동인지 구분하는 것이죠.

일종의 출석부가 아니라 지문 감식에 가깝습니다. 이름표를 미리 받아 적는 방식은 새 에이전트가 생길 때마다 뒤처집니다. 반면 행동으로 구분하면 이름표가 없어도 찾을 수 있습니다. 섀도우 AI나 팀 단위 자동화가 늘어나는 요즘에는 후자가 훨씬 현실적입니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 행동 지문이 만능 열쇠처럼 들리지만, 논문은 구체적인 탐지율이나 오탐 수치를 내놓지 않습니다. 어디까지 식별할 수 있고 어디서부터는 사람 검토가 필요한지는 앞으로 메워야 할 부분입니다. 그럼에도 방향 자체는 설득력이 있습니다. 거버넌스의 첫걸음을 신고가 아니라 관측에 두자는 것이니까요.

100밀리초라는 숫자를 어떻게 읽을까

집행 게이트웨이에 붙은 숫자 하나가 있습니다. 100밀리초 안에 결정한다는 sub-100ms라는 표현인데요. 처음 보면 그냥 빠른 속도처럼 보이지만, 실제로는 설계 선언에 가깝습니다. 거버넌스가 사용자 경험을 망가뜨리지 않으려면 이 정도 지연 안에는 답을 내야 한다는 것이죠.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 그 100밀리초 안에 무엇을 검사할 수 있을까요? 허용과 거부와 수정이라는 세 가지 선택지가 논문에 나오는데, 이 구분이 꽤 실용적입니다. 무조건 막는 것만이 집행은 아니기 때문입니다. 민감한 주민번호 한 줄만 마스킹하면 되는 요청을 통째로 거부하면 업무가 멈춥니다. 반대로 위험한 도구 호출을 살짝 고치는 정도로는 못 막을 때도 있습니다. 그래서 수정이라는 중간 선택지가 있는 것이고, 저는 그 선택지를 둔 판단이 현장 감각에 가깝다고 봅니다.

다만 이 숫자는 그대로 믿기 전에 조건을 봐야 합니다. 어떤 하드웨어에서, 어떤 정책 복잡도에서, 어떤 트래픽 밀도에서 측정한 것인지 논문은 아직 보여주지 않습니다. 논문 스스로도 이 구조를 이론적 틀로 소개하고, 통제된 배포를 통한 검증은 앞으로의 과제로 남겼다고 밝힙니다. 그래서 저는 100밀리초를 측정값이 아니라 목표로 읽었습니다. 거버넌스가 실시간이라는 말을 쓰려면 이 정도는 되어야 한다는 기준선처럼요.

그렇다면 이 기준선을 지키면서 정책을 어떻게 표현할까요? 정책 언어가 너무 무거우면 게이트가 병목이 되고, 너무 가벼우면 집행이 구멍투성이가 됩니다. 논문이 다섯 층위로 나눈 이유도 아마 여기에 있습니다. 판단과 집행과 기록을 한 덩어리로 만들지 않고 각자 빠르게 돌게 하려는 것이죠.

감사는 보고서가 아니라 부산물이 되어야 합니다

감사 시즌이 되면 많은 팀이 비슷한 풍경을 겪습니다. 흩어진 로그를 모으고, 스프레드시트를 맞추고, 누가 승인했는지를 메일에서 찾아 헤맵니다. 며칠 밤을 새워 보고서를 만들지만, 정작 그 보고서가 실제 집행을 그대로 보여주는지는 확신하기 어렵습니다. 논문이 말하는 attestation deficit는 바로 이 장면의 다른 이름입니다.

AGIL이 제안하는 답은 순서를 바꾸는 것입니다. 집행을 먼저 하고 기록은 그 부산물로 남기자는 것이죠. 게이트에서 허용과 거부와 수정을 내릴 때마다 그 결정과 근거를 변조 흔적이 남는 형태로 바로 적어두면, 나중에 보고서를 끼워 맞출 필요가 없어집니다. 집행 로그 자체가 감사 자료가 되니까요.

이 발상이 마음에 들었던 이유는 운영의 아침을 떠올렸기 때문입니다. 밤사이 공시가 늦게 도착하거나 아침에 특정 에이전트가 평소와 다른 도구를 호출해도, 집행 기록이 줄줄이 있으면 원인을 찾는 일이 훨씬 빨라집니다. 반대로 기록이 사후에 만들어지면 시간과 사람이 바뀔 때마다 이야기도 함께 흔들립니다.

물론 여기서도 물을 점이 남습니다. 변조 흔적이 남는다는 것은 어떤 저장 구조와 서명 방식을 쓰느냐에 따라 무게가 달라집니다. 모든 결정을 다 적으면 저장 비용이 커지고, 일부만 적으면 구멍이 생깁니다. 논문은 방향을 제시할 뿐 저장 용량이나 처리량 같은 숫자는 내놓지 않습니다. 그래서 저는 이 부분을 약속이 아니라 숙제로 읽었습니다. 집행과 기록을 한 몸으로 만들자는 숙제로요.

이 논문을 오해하기 쉬운 지점

이쯤에서 논문이 아닌 것을 정리해 두는 편이 도움이 됩니다. 첫째, 이 논문은 새로운 탐지 모델 하나를 내놓은 것이 아닙니다. 특정 모델의 점수를 올렸다는 이야기도 아닙니다. 거버넌스를 어디에 어떻게 앉힐지에 대한 아키텍처 제안에 가깝습니다.

둘째, AGIL은 이미 검증된 제품이 아닙니다. 논문도 이 점을 숨기지 않습니다. 이론적 틀로 제시하고, 통제된 배포를 통한 실증은 앞으로의 연구로 남겼다고 말합니다. 그래서 이 글을 읽을 때는 숫자의 정밀도보다 구조의 타당도를 보는 편이 맞습니다. 78%나 362건이나 499만 달러 같은 인용 수치는 문제의 크기를 보여주는 재료이고, 100밀리초는 목표선이며, 다섯 층위는 그 목표를 향한 설계도입니다.

셋째, 이 구조가 만능은 아닙니다. 정책을 잘 못 만들면 게이트는 잘못된 결정을 빨리 내릴 뿐입니다. 탐색이 놓치는 AI가 있으면 집행은 처음부터 빗나갑니다. 기록을 남긴다고 해서 그 기록을 읽고 고치는 사람이 없으면 거버넌스는 여전히 반쪽입니다. 논문을 읽을 때 저는 이 한계를 같이 적어두었습니다. 아키텍처는 사람의 판단과 운영을 대신하지 못하고, 그 둘을 빠르게 돕는 자리이기 때문입니다.

기계 속도에 맞는 거버넌스는 무엇을 남길까

처음 AGIL을 봤을 때는 또 하나의 프레임워크 그림처럼 보였습니다. 그런데 숫자를 겹쳐놓고 보니 생각이 바뀌었습니다. 78%는 이미 와 있고, 38%와 17%는 아직 못 보고 있고, 362건은 이미 벌어져 있고, 499만 달러는 이미 치른 셈입니다. 이 간극을 메우는 데 보고서 한 장 더 쓰는 것으로는 부족합니다. 길목에 서서 실시간으로 묻고 답하는 기계가 필요합니다.

제가 앞으로 보고 싶은 것은 세 가지입니다. 첫째, 행동 지문이 실제 기업 트래픽에서 어떤 정밀도와 재현율로 동작하는지입니다. 둘째, 게이트가 복잡한 정책을 얹고도 실제로 100밀리초 안에 답을 내는지, 그리고 그때 처리량과 지연이 어떻게 움직이는지입니다. 셋째, 집행 기록이 규제 기관이 요구하는 시간 안에 실제로 재현되는지입니다. 이 세 가지가 채워지면 이론적 틀은 운영 가능한 장치가 됩니다.

그렇다면 사람의 역할은 무엇일까요. 기계가 빨리 막고 빨리 기록할수록, 무엇을 막아야 하는지와 무엇을 남겨야 하는지를 정하는 일은 더 중요해집니다. 정책의 문장을 쓰는 일, 예외를 판단하는 일, 기록을 읽고 구조를 고치는 일은 여전히 사람의 몫입니다. 기계 속도의 거버넌스라는 말은 사람을 밀어내는 뜻이 아니라, 사람이 판단할 시간을 벌어주는 뜻에 가깝다고 저는 봅니다.

이 논문을 덮으면서 남는 문장은 하나입니다. 거버넌스는 문서가 아니라 길목에서 증명된다는 것, 그 길목을 어떻게 설계할지가 앞으로 몇 년의 숙제라는 것입니다.