AI 거버넌스 파일럿이 조직 규모가 커지면 무너지는 이유

정책은 잘못되지 않았습니다. 다른 팀이 알리지 않고 세운 에이전트를 감당할 크기로 설계되지 않았을 뿐입니다.

파일럿은 잘 돌아갔습니다. 에이전트 세 개, 팀 하나, 그리고 각 에이전트가 뭘 건드릴 수 있는지 짚어 말할 수 있는 담당자가 있었습니다. 6개월 뒤, 같은 조직에는 아무도 요청서를 내지 않은 MCP 서버 열두 곳에 연결된 에이전트들이 돌아가고, 원래 팀에는 들어본 사람이 없는 도구 위에서 작업이 이뤄지고 있습니다. 3월 심사를 통과한 거버넌스 프로그램은 이제 누가 뭘 돌리고 있는지조차 말할 수 없습니다. 정책은 그대로입니다. 바뀐 건 그 밑에 깔린 전제, 즉 누군가가 모든 에이전트를 추적할 수 있다는 전제입니다. 파일럿 규모에서는 그 전제가 성립했습니다. 조직이 커진 규모에서는 성립하지 않습니다.

가트너는 2025년 6월, 2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 중단될 것이라고 예측했습니다. 비용 급증, 불분명한 사업 가치, 미흡한 리스크 통제를 이유로 들었습니다. 파일럿용으로 만들어진 거버넌스도 그렇게 사라지는 것들 가운데 하나입니다.

빠른 답변: 대부분의 AI 거버넌스 도구는 파일럿의 관리 대상 목록(한 팀이 이름을 댈 수 있는 소수의 에이전트)에 맞춰 설계돼 있을 뿐, 조직이 커지며 늘어나는 목록에는 맞지 않습니다. Token Security가 의뢰한 CSA 조사에 따르면 조직의 68%는 자사 AI 에이전트 가시성이 충분하다고 믿는 반면, 82%는 지난 1년 동안 기존에 파악되지 않았던 AI 에이전트를 발견했습니다. Kiteworks의 2026년 전망 조사에서는 60%가 오작동하는 에이전트를 종료할 수 없는 것으로 나타났습니다. 해법은 더 나은 관리 대상 목록이 아니라, 최신 목록이 필요 없는 통제입니다.

파일럿의 거버넌스가 완벽해 보이는 이유

요약: AI 에이전트 가시성에 대한 확신과 실제 가시성은 같은 측정값이 아니며, 그 격차 자체가 이 글의 핵심입니다. Token Security가 의뢰한 CSA 조사에 따르면 조직의 68%가 자사 AI 에이전트에 대한 가시성이 충분하다고 믿습니다. 같은 조사에서 82%는 지난 1년 동안 기존에 파악되지 않았던 AI 에이전트를 발견했습니다.

파일럿 규모에서는 "우리는 가시성을 확보하고 있다"는 말이 사실입니다. 가시성을 확보하는 데 별다른 노력이 들지 않기 때문입니다. 에이전트 세 개, Slack 채널 하나, 요청 티켓을 직접 쓴 사람 한 명. 그 사람에게 뭐가 돌아가고 있냐고 물으면 10초 만에 정확한 답이 나옵니다.

두 번째 팀이 자체 에이전트를 세우고, 세 번째 팀이 앞선 두 팀도 모르는 MCP 서버에 에이전트를 물리고, 네 번째 팀이 거버넌스 문서에 잡히지 않은 평가를 시작하는 순간 이 모델은 그대로 멈춰 섭니다. 이때 조직이 자기 가시성에 대해 갖는 확신은 떨어지지 않습니다. 오히려 그대로 높게 유지되는 경우가 많은데, 아무도 그 확신을 다시 측정하지 않기 때문입니다. Token Security가 의뢰한 CSA 조사는 같은 응답자 418명을 대상으로 두 수치를 함께 확인했습니다. 68%는 자사의 AI 에이전트 가시성이 충분하다고 믿고, 82%는 지난 1년 동안 기존에 파악되지 않았던 AI 에이전트를 발견했으며, 전체 응답자의 41%는 그런 에이전트를 두 번 이상 발견한 경험이 있었습니다. 같은 보고서에서 수치 하나를 더 붙이면, 공식적인 폐기 절차를 갖춘 곳은 21%뿐입니다. 파일럿이 끝나도 그때 부여된 권한이 제대로 회수되지 않을 가능성을 시사하는 수치입니다. 보고서 자체의 문장이 이후 내용을 미리 요약한 주장에 가깝습니다. "에이전트가 더 큰 자율성을 갖게 될수록, 거버넌스는 조직 규모가 커져도 통제를 지속할 수 있는 통합 운영 모델로 진화해야 한다."

실제로 무너지면 어떤 모습인가

요약: Kiteworks의 2026년 전망 수치는 원래 적용 범위를 넘어선 거버넌스 프로그램의 모습을 보여 줍니다. 60%는 오작동하는 에이전트를 종료할 수 없고, 63%는 목적 범위를 강제할 수 없습니다. 2026년 MCP 서버 스캔에서도 비슷한 패턴이 나타납니다. 스캔된 빌드의 40.6%에서 파일·자격증명 접근, 코드 실행, 파괴적 동작이 가능해 보이는 도구가 최소 하나 이상 발견됐습니다.

파일럿 3개월 차에는 "이 에이전트가 잘못 행동하면 멈출 수 있는가"라는 질문에 그렇다고 답할 수 있습니다. 그 세 에이전트만을 위한 킬 스위치를 누군가 직접 만들어 뒀기 때문입니다. 1년 뒤, Kiteworks가 보안·IT·리스크 책임자 225명을 대상으로 진행한 2026년 전망 조사에서는 60%가 오작동하는 에이전트를 종료할 수 없고, 63%는 에이전트에게 허용된 목적 범위를 강제할 수 없는 것으로 나타났습니다.

같은 문제의 공급 쪽 단면을 보여 주는 사례도 있습니다. 브라우저 보안 벤더 Island가 2026년 진행한 MCP 서버 스캔은 공개된 MCP 서버 빌드 33,563건, 도구 475,865개를 대상으로 했습니다. 단순 목록 표시를 제외하고도 49%가 정보성(informational) 등급을 넘는 발견 사항을 최소 하나 이상 냈고, 40.6%는 파일이나 자격증명 접근, 코드 실행, 파괴적 동작이 가능해 보이는 도구를 최소 하나 이상 포함했습니다. 관리자 수를 확인할 수 있는 패키지 중 84%는 관리자·게시자 신원이 하나뿐이었습니다. Island는 이 신원이 개인일 수도, 기업일 수도, 자동화된 게시 계정일 수도 있다고 덧붙입니다. 그리고 소유자를 식별할 수 있었던 패키지 중에서도 92%는 GitHub로 검증된 조직과 일치하지 않았습니다. 서드파티 MCP 서버 대부분이 나오는 공개 패키지 공급망 자체에 귀속 공백이 있다는 뜻입니다.

맞는 정책이 파일럿을 넘어 조직 규모가 커지면 무너지는 이유

요약: 작고 다 파악된 관리 대상 목록을 기준으로 범위를 정하고 검증한 거버넌스 프로그램에는, 다음 팀의 MCP 서버나 아무도 요청서를 내지 않은 도구로 자동 확장되는 장치가 애초에 없습니다. 첫날 완전했던 적용 범위는 관리 대상 목록이 커지면서 아무 신호 없이 불완전해지며, 이는 정책 자체가 잘못됐는지와는 무관합니다.

대개는 나쁜 정책을 쓴 사람이 없습니다. 팀 하나의 에이전트 세 개를 관장했던 정책은 그 규모에서는 대체로 문제가 없었을 겁니다. 다만 그 정책에 없었던 건, 그리고 아무도 만들도록 강제하지 않았던 건, 네 번째 팀이나 새로운 MCP 서버, 티켓 없이 시작된 도구 평가로 자동 확장되는 장치였습니다. 관리 대상 목록이 작고 다 파악돼 있을 때는 적용 범위가 완전했습니다. 하지만 그 적용 범위에는, 목록이 커지고 더 이상 다 파악되지 않게 됐을 때도 완전함을 유지시켜 주는 속성이 원래 없었습니다. 정책보다는 구조에 뚫린 공백입니다. "심사 시점에는 정책이 괜찮았다"와 "6개월 뒤 조직은 뭐가 돌아가는지 전혀 모른다"가 동시에 성립할 수 있는 것도 그래서입니다.

이 문제를 방치하면 무엇이 걸려 있는가

요약: 가트너의 40% 중단 예측과 Kiteworks의 2026년 전망 수치는 서로 다른 두 조사이면서도 같은 실패를 가리킵니다. 하나는 기술적 공백을 짚고, 다른 하나는 그 공백을 프로젝트가 중단되는 이유로 지목합니다.

두 데이터 셋을 나란히 두면 표본이나 모집단을 공유하지 않고도 같은 실패를 가리킵니다. Kiteworks의 수치는 기술적 실태입니다. 60%는 오작동하는 에이전트를 종료할 수 없고, 63%는 목적 범위를 강제할 수 없습니다. 가트너는 비용 급증, 불분명한 사업 가치와 함께 미흡한 리스크 통제를 에이전틱 AI 프로젝트가 중단되는 세 가지 이유 중 하나로 지목합니다. 뭐가 돌아가고 있는지 말할 수 없거나, 문제가 생겨도 멈출 수 없는 프로그램은 이 설명에 들어맞습니다. 팀 내부에서 그 표현을 직접 쓰는지 여부와는 상관없이 그렇습니다.

조직 규모가 커져도 버티는 거버넌스에 필요한 것

요약: 모든 에이전트·도구·팀을 담은 완전하고 최신인 지도를 누군가 계속 유지해야 하는 통제는, 그 지도가 낡는 순간 깨집니다. 더 오래가는 답은 자신에게 도달하는 대상을 판단하는 데 최신 목록이 필요 없는 통제이며, 애초에 그 대상이 통제를 거쳐 가도록 만드는 것으로 충분합니다.

흔한 답은 더 나은 지도입니다. 더 완전한 관리 대상 목록, 새 에이전트를 위한 더 엄격한 등록 절차, 어떤 팀이든 MCP 서버를 세우기 전에 거쳐야 하는 의무 등록 단계 같은 것들입니다. 이 중 일부는 쓸모가 있지만, 구조적 문제 자체를 풀어 주지는 않습니다. 지도는 마지막으로 누군가 갱신한 시점까지만 최신입니다. 팀이 그 갱신 주기보다 빠르게 움직이기 때문에, 파일럿은 결국 그 규모를 벗어나게 됩니다.

대안이 되는 통제는 다릅니다. 자신에게 도달하는 것을 판단하는 데 최신 에이전트별 목록이 필요 없고, 그 대상이 통제를 거치도록 만들기만 하면 됩니다. 그래서 거버넌스를 실행 제어 레이어에 둬야 한다는 주장이 나오며, AI 네이티브 PAM인 Alpacon이 바로 그 레이어를 기반으로 만들어진 제품입니다. 아이덴티티는 누가 접속하는지를 정하고, 정책은 서류상 뭐가 허용되는지를 정하며, 실행 제어는 각 명령이 실행되기 전에 판단이 이뤄지는 지점입니다. Work Session은 아이덴티티, 선언된 의도, 스코프 상한을 지정한 상태로 열립니다. 실행 경로에 들어온 명령은 명령어 텍스트뿐 아니라 그 선언된 의도와도 대조해 판단됩니다. Alpacon은 실행 전에 강제로 거부하거나 사람에게 넘겨 승인받게 할 수 있고, 이 강제가 기본값입니다. 판정을 먼저 지켜보고 싶은 팀을 위한 monitor-and-record 모드도 있습니다. 이 판단은 건별로 이뤄져 누군가가 에이전트 목록을 최신으로 유지하는지에 좌우되지 않습니다. 새 팀의 에이전트를 이 경로에 올리는 일은 그 자체로 별도의 등록 작업이고, 처음부터 등록되지 않은 MCP 서버를 찾아내는 일은 여전히 또 다른 과제로 남습니다.

결론

거버넌스 프로그램이 무너진 건 누군가 잘못된 정책을 썼기 때문이 아닙니다. 더는 존재하지 않는 인원과 관리 대상 목록에 맞춰 설계됐고, 그 사실이 더 이상 참이 아니게 된 순간을 아무것도 감지하지 못했기 때문입니다. 해법은 경로 자체를 요건으로 만들어, 그 경로 위의 명령이 그 자체로 판단받게 하는 데 있습니다. 같은 지도를 더 정교하게 그리는 것만으로는 부족합니다.

누군가 이름으로 추적할 수 있는 규모를 넘어 AI 에이전트를 확장하고 있다면, 그 레이어는 파일럿이 자기 거버넌스보다 커지기 전에 만들어 두는 편이 낫습니다. 커진 뒤에는 이미 늦습니다.