카카오 AI 전략 맡던 대표가 말하는 AI 에이전트 사고가 나기 전에 회사가 깔아야 할 통제 4단계 (임페라이 음병찬 대표님)

한 줄 요약

카카오에서 AI 사업 전략을 맡았던 임페라 대표가 AI 에이전트를 회사에 들이기 전에 어떤 통제 장치를 깔아야 하는지 설명해요. 에이전트에게 착하게 굴라고 타이르는 대신 실제로 행동하는 지점을 따로 통제하라는 게 요지예요. 그 구조를 식별·통제·증명·최적화의 4단계로 풀어 보여 줍니다.

전체 내용 정리

에이전트 거버넌스는 AI 거버넌스와 뭐가 다를까요

이번 편에는 임페라 대표가 나왔어요. 카카오에서 AI 사업 전략을 맡았고 엘리먼트 AI(Element AI)에서도 일했던 사람입니다. 스스로는 하드코어 개발자나 연구자가 아니라 AI가 사업 현장에 어떻게 들어오는지를 계속 지켜본 쪽이라고 소개해요. 올해 AI 에이전트 거버넌스 제품을 만드는 임페라를 공동 창업했고요.

두 거버넌스의 차이부터 짚고 갑니다. 보통 AI 거버넌스라고 하면 어시스턴트형 AI를 떠올리죠. 자문이나 답변은 AI가 해 주지만 마지막 실행은 사람이 하는 구조예요.

에이전트는 마지막 도장 찍는 일, 그러니까 실제 실행까지 합니다. 그만큼 리스크의 크기가 커졌고 리스크가 생기는 면(리스크 서피스)도 다양해졌어요. 그래서 거버넌스가 주기적으로 점검하는 정적인 일에서 실시간으로 돌아가야 하는 동적인 일로 바뀌었다고 대표는 봐요.

에이전트를 단계로 나누면 네 가지예요. 조회나 질문에 답하는 수준, 보고서처럼 참고 자료를 만들어 주는 수준, 사람의 통제를 받으며 실제로 행동하는 수준, 그리고 완전 자율이죠. 대부분의 기업은 영역과 상관없이 3단계로 가는 중이라고 해요. 일부 대기업과 글로벌 기업을 빼면 에이전트를 10개, 50개, 100개씩 돌리는 곳이 드물어서 제대로 된 거버넌스 운영 체계를 갖춘 곳은 빅테크 정도라는 진단입니다.

경영진의 질문도 달라지고 있어요. 예전엔 우리 회사 어디에 적용할 수 있느냐가 질문이었다면 요즘은 생산성이 오르는지, 비용이 줄어드는지, 매출을 낼 수 있는지를 묻습니다. 도입에서 운영으로 관심이 옮겨 간 거죠. 거버넌스 질문은 올해 들어, 특히 해외에서 에이전트 실패 사례가 뉴스로 많이 나오면서 생겼어요. 일부는 과장된 공포 조장(피어 멍거링)으로 보이지만 우리 회사에선 그런 일이 없을지 묻는 경영진이 늘었다고 합니다.

에이전트는 사람 대리인과 전혀 다르게 움직여요

대표는 이 문제를 주인-대리인 문제(PA 문제, Principal-Agent problem)로 설명합니다. 회사 주인이 직원을 뽑는 건 내 일 일부를 떼어서 맡기는 일이에요. 그런데 여기엔 늘 두 가지 틈이 생겨요. 정보의 비대칭과 목표의 비대칭이죠.

사람 직원은 그래도 짐작할 수 있는 범위가 있습니다. 상식과 세상을 보는 관점이 있고 사회에서 살아가며 지는 책임과 평판도 있으니까요. 그걸로 다 커버하지 못하는 부분은 결재선, 회의록, 업무 기술서 같은 장치로 메워 왔어요. 기업 조직이 생기고 100년 가까이 쌓아 온 학습이에요.

그런데 에이전트는 새로운 동물이에요. 한두 달 전 오픈AI 에이전트들이 허깅페이스(Hugging Face)를 해킹했다는 자극적인 제목의 기사가 많이 나왔죠. 대표는 이 사건이 에이전트가 진짜 대리인이 됐을 때 PA 문제가 어떤 모습일지 단적으로 보여 줬다고 봅니다.

에이전트에게 주는 지시는 자연어라서 우리는 사람에게 말하고 있다고 착각하기 쉬워요. 답도 사람처럼 돌아오니까요. 하지만 AI는 우리처럼 교육받지 않았어요. 보상 신호를 어떻게 받아들여 어떤 행동을 할지 예측하기가 무척 어렵습니다.

최근 인상 깊게 읽은 글도 소개해요. AI에 대해 글을 많이 쓰는 한 경제사학자가 쓴 'AI가 무엇을 원하느냐'라는 글인데, 그 안에 '토탈리테리안(totalitarian)'이라는 말이 들어간 원칙이 나와요. 전체주의 얘기가 아니라 물리 법칙상 불가능한 일이 아니면 무조건 일어난다는 한 물리학자의 말에서 온 원칙이에요. 회색 지대가 없는 셈이죠. 대표는 AI도 마찬가지로 원칙이나 장치로 일어날 수 없게 막아 두지 않은 일은 결국 일어난다고 해석합니다.

대표 자신도 클로드 코드(Claude Code)와 이미지 생성 도구를 쓰는데, 이미지 생성 도구에 이런 걸 만들지 말라고 프롬프트를 주면 꼭 그게 나온대요. 실행 경로가 열려 있으면 그걸 할 가능성은 무조건 있어요. 이게 AI 에이전트를 쓸 때 PA 문제의 핵심이라고 대표는 봐요.

섀도우 에이전트는 '안 보이는 에이전트'만 뜻하지 않아요

섀도우 에이전트는 현업에서 들여온 AI를 회사가 파악하지 못하는 문제를 말해요. 그런데 대표는 '에이전트'보다 '섀도우'에 더 집중해야 한다고 봐요. 중앙 레지스트리에 등록돼 있으면 괜찮고 없으면 섀도우라는 식으로 볼 일이 아니라는 거죠.

예전의 섀도우 IT는 사람이 회사가 관리하지 않는 소프트웨어를 쓰는 문제였어요. 결국 사람이 뭔가를 하는 일이었죠. 에이전트는 스스로 실행합니다.

등록된 에이전트라도 미처 관리하지 못한 API 키나 서비스 접근 권한을 언제든 덥석 물어서 써 볼 수 있어요. 나쁜 마음을 먹어서가 아니라 엉뚱한 생각을 하다가, 혹은 일을 잘하려다가 그럴 수 있어요. MCP 연결이나 권한 관리(IAM) 문제도 모두 이 범주에서 다시 봐야 한다고 대표는 말합니다.

대표가 드는 사례가 리플릿(Replit)이에요. 코드 프리즈(코드 변경을 멈춘 기간) 중이었는데 회사에서 쓰던 개발 에이전트가 갑자기 움직이기 시작했어요. 프로덕션 데이터베이스에 접근할 권한을 찾아내 접속했고 고객 데이터를 다 삭제해 버렸습니다. 리플릿 CEO까지 나서서 조사하고 바로 복구해 줬는데, 다행히 복구할 수 있는 환경이었던 거죠.

그래서 섀도우는 에이전트가 안 보인다는 뜻만이 아니에요. 있는 에이전트라도 책임 범위, 의사 결정의 경계, 쥐여 준 도구가 관리되지 않으면 옛날 섀도우 IT 같은 일이 얼마든지 벌어질 수 있어요. 예상하기 힘든 일이니 방어해야 할 최소한의 진지부터 구축해야 한다는 게 대표의 답입니다.

착하게 만들기보다 행동하는 면을 통제해야 해요

첫 번째 원칙은 실행의 면과 통제의 면을 분리하라예요. 프롬프트에 이런 거 하지 말라고 쓰면 확률은 줄겠죠. 하지만 절대 안 일어난다고 보장하긴 힘들어요. 에이전트를 착하게 만들려는 시도는 극단적으로 많이 해야겠지만 거기에만 기대는 건 무리라고 대표는 말해요.

은행이 좋은 예입니다. 우리나라 사람들은 은행에 맡긴 돈에 문제가 생길 거라고 거의 생각하지 않죠. 대표는 "내가 은행을 신뢰하는 이유는 은행원을 믿어서가 아니고" 은행원이 일하도록 짜인 시스템과 인프라 때문이라고 말해요.

장부는 복식으로 정리하고 감사가 주기적으로 돌아요. 지점은 매일 문을 닫은 뒤 대사(장부와 실제 잔액을 맞춰 보는 일)를 하는데, 1,000원이나 만 원만 비어도 큰일이 나는 구조예요. 에이전트도 똑같이 접근해야 한다는 게 대표의 생각입니다.

대표가 짚는 또 하나의 개념이 '폴리시-런타임 갭(policy-runtime gap)'이에요. AI 원칙과 지침은 시스템 안에 있는데 실제 실행 순간에는 작동하지 않는 틈이죠. 이 틈을 줄이려면 에이전트의 생각과 행위를 분리해서 봐야 해요. 회사에서 고객을 응대하는 사람도 속으로는 딴생각을 하거나 앞에 있는 고객이 밉다고 생각할 수 있잖아요. 정말 중요한 건 고객 정보 조회, 상담, 대금 지급, 환불 같은 행동이에요.

"에이전트한테 착해져라. 너 내 말 잘 들어." 이런 말을 자꾸 하는 것보다, 에이전트가 영향을 줄 수 있는 행동의 면을 통제하는 게 폴리시-런타임 갭을 줄이는 데 가장 중요하다고 대표는 말해요.

그래서 필요한 게 액션 온톨로지(action ontology)예요. 우리 에이전트가 접근할 수 있는 행동이 무엇인지, 그 행동에 어떤 위험이 있고 어떻게 통제해야 하는지를 정리해 둔 지도죠. 요즘 온톨로지가 다시 주목받고 있지만 주로 에이전트가 일을 잘 이해하게 하는 얘기를 해요. 통제 쪽에서도 온톨로지가 무척 중요하다는 게 대표의 강조점입니다.

흩어진 로그를 하나의 원장으로 묶어야 판단이 보여요

대표는 로그는 판단의 기록이 아니라고 말해요. CCTV는 그 순간 카메라에 비친 장면을 기록할 뿐이죠. 필요한 건 그 의미를 해석할 수 있는 기록이에요.

여기엔 두 가지 흩어짐(프래그멘테이션) 문제가 있어요. 첫째는 물리적으로 흩어져 있어요. 권한 정보는 IAM 시스템에, 툴 호출은 에이전트 프레임워크 로그에, 관찰 로그(옵저버빌리티)는 따로, 프롬프트는 모델이나 에이전트 시스템에 있죠. 그냥 저장만 해 두면 어떤 결정과 행동이 있었는지 종합해서 보기 어려워서 이걸 하나로 묶을 의사 결정 ID(디시전 ID) 같은 물리적 장치가 필요해요.

둘째는 의미가 흩어져 있어요. 은행에서 고객에게 돈을 지급하는 행동이 있다고 해 보죠. 에이전트가 늘어나면 어떤 에이전트는 이걸 'send money transfer'로, 다른 에이전트는 'transfer funds'로 부를 수 있어요. 같은 의미인데 다른 행위로 남으면 같은 정책과 원칙을 적용하기가 무척 힘들어지니 여기서도 액션 온톨로지가 필요합니다.

두 문제가 풀리면 누가 책임을 지는지 알 수 있고 여러 관점에서 볼 수 있는 하나의 중앙 데이터가 생겨요. 임페라는 이걸 원장(레저, ledger)이라고 부릅니다. 조쉬는 이걸 골든 데이터셋(golden dataset)이라고 불러도 되겠다고 했어요. 대표도 이 데이터가 회사만의 중요한 자산이 된다는 데 동의하고요.

대표는 AI의 흐름을 이렇게 짚어요. 2012년 알렉스넷(AlexNet)이 나왔을 때는 알고리즘이 경쟁력이었는데, 트랜스포머가 나온 뒤로는 그 얘기가 거의 끝난 것처럼 보이죠. 이제는 빅테크와 모델 개발사들이 인터넷 데이터를 넘어 기업 데이터까지 흡수하려 하고 있어요. 그래서 기업들은 어떤 데이터가 해자(경쟁자가 넘보기 어려운 방어벽)가 될지 고민하는데, 대표는 빅테크가 탐내기엔 규모가 작지만 우리 회사에서만 작동하는 의사 결정 데이터가 바로 그런 데이터라고 봐요.

임페라가 쓰는 말이 '위임 역량(델리게이션 캐파시티, delegation capacity)'이에요. 얼마나 자신 있게 믿고 맡길 수 있느냐는 뜻이죠. 최근 나온 아스트라 모델이 아주 좋다고 하는데 돈을 들여 쓸 수 있는 회사는 많을 거예요. 하지만 그 모델을 쓰는 게 바로 경쟁력이 되진 않아요. 모델이 잠재력을 100%에 가깝게 발휘하도록 얼마나 믿고 맡기느냐가 내 문제로 남거든요.

이걸 개념적인 공식으로 표현하면 이렇습니다. 에이전트가 기업에 주는 가치는 에이전트의 지능·역량 × 얼마나 많이, 오래 돌리느냐 × 거버넌스 관점에서 얼마나 위임할 수 있느냐(G 계수)예요. 이 중 기업이 사실상 통제할 수 있는 건 G 계수뿐이에요. 대표는 여기서 되는 회사와 안 되는 회사의 성과 차이가 크게 날 거라고 봐요.

통제 4단계는 식별·통제·증명·최적화로 돌아가요

임페라가 만드는 거버넌스 제품은 기능적으로 네 개의 동사로 짜여 있어요. 식별, 통제, 증명, 최적화입니다. 식별과 통제는 런타임에 실시간으로 일어나는 일이고 증명과 최적화는 비동기적으로 나중에 처리되는 영역이에요.

1단계 식별의 중심은 에이전트 레지스트리예요. 섀도우 에이전트를 없애려고 어떤 도구나 프레임워크로 만든 에이전트든 다 연결하는 곳이죠. 여기에 에이전트가 지켜야 할 규칙과 정책, 그걸 확인할 증거(에비던스)를 어떻게 모을지도 연결합니다. 정책은 전부 버전으로 관리해요.

같은 지급·결제 에이전트라도 확인 수준이 달라요. 내부 업무용이라 위험도가 낮으면 극단적으로는 "에이전트가 그렇다고 하면 믿자" 정도로 갈 수도 있죠. 대고객용이라면 에이전트가 KYC(고객 확인) 절차를 거쳤다고 주장할 때 정말 했는지를 백엔드 시스템에서 직접 확인해야 할 수 있어요.

위험도 등급은 이해관계자들이 모여서 정해요. 규제가 이런 정리를 원하고 있기도 하고요. 대표는 범죄자도 죄질에 따라 미국의 슈퍼맥스(최고 보안 교도소)에 가기도 하고 훈방되기도 한다는 비유를 들어요. 실험용이나 조회만 하는 에이전트는 관찰만 해도 되지만 고객에게 돈을 지급하거나 평판에 영향을 줄 수 있는 에이전트는 면밀히 보다가 행동하는 순간 잡아내야 하죠. 임페라는 이걸 L0부터 L2까지 등급으로 나눠 서로 다른 통제를 연결해요.

2단계 통제에서는 사람이 어디에 어떻게 개입할지 정해야 해요. 대표는 정답은 없다고 전제하면서 일반적인 가이드를 줍니다. 먼저 우리 회사에서 눈여겨봐야 할 행동, 즉 액션 온톨로지를 정리하세요. 한 번에 다 하든 영업 지원이나 상담처럼 에이전트를 주로 쓸 영역부터 하든 괜찮아요. 그다음 각 지점에 사람이 직접 판단하게 할지(휴먼 인 더 루프), 기준선을 넘으면 위로 올리게 할지(에스컬레이션), 무조건 막을지(블록)를 정하는 게 설계자의 역할이에요.

액션 온톨로지는 제품의 '컨트롤 패브릭' 영역에 들어가요. 회사 비즈니스 전체를 다루는 온톨로지가 아니라 통제 관점에서 행동에만 집중한 온톨로지예요. 송금 같은 행동 유형, 접근하는 리소스 유형, 그리고 행동이 일어날 때 확인할 맥락이나 증거를 어디서 가져올지(고객 정보 시스템, 상품 마스터, 결제 데이터베이스 등)가 정의돼 있죠.

여기서 확인은 두 종류예요. 하나는 행동하기 전에 이게 적법한지 확인하는 증거예요. 다른 하나는 실행한 결과가 백엔드에 실제로 반영됐는지, 나아가 고객과 사업에 좋은 영향을 줬는지예요. 뒤쪽은 아직 아주 초기 단계인데, 최소한 백엔드에서 실제 실행이 일어났는지까지는 거버넌스 시스템이 확인해야 루프가 닫힌다고 대표는 봅니다.

정책과 규제는 '컨트롤 라이브러리'에 들어가요. 컨트롤은 세 가지 타입이에요.

• 일반 정책 — 행동이 들어올 때마다 실시간으로 체크
• 사람 개입 규칙 — 사람이 판단해야 하는 경우를 따로 묶음
• 격리 규칙(컨테인먼트 룰) — 여러 트랜잭션을 모아서 보는 규칙. 비용이 폭증하거나 멀티 에이전트 환경에서 같은 의도의 주문이 정해진 시간 안에 반복해서 들어오는 경우가 여기에 해당해요. '로지컬 킬(logical kill)'도 이쪽이에요

법을 컨트롤로 옮기다 보면 실시간 체크로 끝나지 않는 조항이 꽤 있다고 해요. 예를 들어 어떤 일이 일어나면 며칠 안에 보고해야 하는 조항은 3일이 지나는지 모니터링해서 누군가에게 배정하고 실제로 했는지 확인해야 하죠. 이런 건 격리 규칙에 들어가요. 한국 AI 기본법처럼 상위 수준의 법은 해석이 필요해서 임페라는 이 분야 전문성이 있는 법무법인 변호사들과 함께 일한다고 합니다.

AI 기본법이나 개인정보 관련 법은 문서가 아니라 에이전트의 행동에 맞대어 매핑할 수 있는 '폴리시 코드'로 바뀌어요. 쿠버네티스(Kubernetes) 쪽에서 보안 경계를 정할 때 쓰는 OPA 레고(Rego) 같은 선언형 언어를 쓰고 있다고 해요. 여기에 LLM을 활용한 '거버넌스 컴파일러' 파이프라인도 만들고 있어요.

이 파이프라인은 법 조문뿐 아니라 경영진의 의도도 컨트롤로 바꿔 줘요. 같은 금융 상품 판매 에이전트라도 한국 리전과 해외 리전에서 다른 기준을 두고 싶을 수 있잖아요. 이건 규제가 아니라 전략인데, 그걸 글로 적으면 LLM이 에이전트가 따를 수 있는 컨트롤로 만들어 준다는 설명이에요.

데모에서는 증권사 샘플 시나리오를 보여 줘요. PB(프라이빗 뱅킹) 에이전트가 고객에게 상품을 추천하는데, 수익률이 높고 성과도 내야 하니 고수익 상품을 권하고 싶겠죠. 그런데 고객이 70세가 넘었어요. 고령 고객에게는 위험도가 높은 상품 추천에 제한이 있어서 이 행동은 블록됩니다.

LLM이 내용을 생성하고 고객을 조회하고 상품을 추천하는 앞 단계는 다 허용됐는데 이 지점에서 막힌 거예요. 기본 원칙은 가장 강한 신호를 따르는 거라서 허용이 100개 있어도 블록이 하나 있으면 블록이에요.

이 기록은 원장에 그대로 남아요. 상품 추천이라는 활동, 차단 기록, 에이전트와 액션 번호, 토큰, 판정 결과, 관련 버전 번호(데모에서는 1.2), 어떤 정책이었는지, 누구 권한이었는지까지요. 감사할 때는 재현 가능한 것과 아닌 것, 시간에 따라 바뀔 수 있는 부분적 증거를 나눠 줘야 해서 그것도 구분해 둡니다. 이상적으로는 바꿀 수 없는 불변 기록이 돼야 한다고 해요.

원장이 쌓이면 감사가 아니라 변화의 도구가 돼요

대표는 이 기록 시스템이 "감사를 위한 도구가 아니에요"라고 잘라 말해요. "변화를 위한 도구죠." 그게 4단계 최적화예요.

데이터가 쌓이면 다양한 패턴이 보여요. 사람이 자꾸 뒤집는(오버라이드) 정책이 많다거나 한 번도 체크되지 않은 정책이 많다거나요. 그러면 우리가 정책을 제대로 운영하고 있는지, 정책을 어떻게 바꾸면 에이전트가 더 일을 잘할지 판단할 수 있죠. 비용의 렌즈로도, 리스크의 렌즈로도 볼 수 있고요.

이 데이터 위에서는 이해관계자들이 하나의 데이터를 각자의 관점에서 보며 트레이드오프를 논의할 수 있어요. 감사 관점에서만 보면 이 데이터의 가치는 크게 떨어진다고 대표는 봐요. 컴플라이언스는 일을 올바로 했느냐를 보지만 성과는 올바른 일을 했느냐를 보거든요. CFO 관점에서는 늘 최저 비용으로 처리된 결정만 있으면 최고겠지만 리스크 부서와 사업부는 또 다르게 보죠. 이 데이터가 정책을 바꾸기 시작하면 그게 조직의 의사 결정 DNA가 됩니다.

얼마나 걸릴까요? 임페라가 시뮬레이션을 돌려 보니 영역이나 산업마다 다르겠지만 정책을 의미 있게 조정할 만큼 데이터가 모이려면 2년 정도면 될 것 같다고 해요. 완전한 자율 운영을 보장한다는 뜻은 아니에요. 2년이면 거의 모든 업무 사이클이 한 바퀴 돈 상태이기 때문이죠.

2년이 필요한 이유는 피드백 루프가 세 개 돌아야 하기 때문이에요. 첫째는 AI의 판단을 보고 사람이 좋다, 나쁘다를 매기는 기본 피드백 루프예요. 둘째는 벤치마크 같은 평가 루프고요. 셋째가 에이전트 거버넌스에서 닫아야 하는 성과(아웃컴) 루프입니다.

환불 사례를 보면 감이 와요. 10만 원 한도까지 환불할 권한을 받은 에이전트가 한도를 넘기지 않고 환불했다면 컴플라이언스 관점에선 잘한 거예요. 그런데 진상 고객이 3개월 동안 말도 안 되는 이유로 10번, 20번 환불을 요청했는데 아무 말 없이 다 해 줬다면요? 반대로 충성 고객인데 환불을 너무 까다롭게 처리해서 떠나 버렸다면요?

성과 관점에선 전혀 다른 얘기가 되죠. 이건 빈도가 아니라 범위의 문제라서 1~2년은 모아야 하는 데이터라고 해요. 보통 AI 피드백 루프는 짧게 줄이는 데 집중하지만 이 루프는 호흡을 다르게 가져가야 합니다.

비용도 같은 원리예요. 올해 메타, 우버 같은 곳에서 토큰을 최대한 많이 쓰게 하는 '토큰 맥싱(token maxing)' 리더보드를 돌렸다가 1년 치 AI 토큰 예산을 4개월 만에 다 썼다는 얘기가 나왔죠. 대표는 지금의 비용 운영이 근거 없이 쓰다가 화들짝 놀라 확 줄이는 식으로 오간다고 지적해요.

운영은 그렇게 진폭이 커서는 안 되고 비용에도 이유와 전략이 있어야 하죠. 그 근본도 액션 온톨로지예요. 우리가 어떤 행동에 돈을 많이 쓰고 싶은지가 정리돼 있어야 하니까요.

일상적인 실패를 막는 첫 단추는 작은 실험이에요

임페라의 주 고객은 지금은 한국과 아시아 기업이에요. 거버넌스는 컴플라이언스, 그러니까 규제 얘기로 흐르기 쉬운데 아시아·태평양 지역에서 AI 규제가 가장 앞선 나라가 한국과 싱가포르라고 해요. 한국은 AI 기본법이 이미 나와 있고 계속 개정 중이죠. 타깃은 에이전트를 많이 도입했거나 도입을 고민하는 대기업, 그중에서도 금융과 일부 제조 기업이에요.

소버린 AI(Sovereign AI, 자국 AI 주권) 관점에서도 이 도구를 봐야 한다고 대표는 말해요. 소버린 AI의 완성은 모델이 아니라는 거죠. 우리 모델을 잘 만드는 것도 중요하지만 고객은 결국 좋은 모델을 고르게 돼 있고 모델은 계속 바뀌어요. 그래서 모델을 소유하는 것보다 내 뜻대로 통제할 수 있느냐가 소버린 AI의 중요한 구성 요소라고 봅니다. 국내 모델 개발사나 독자 AI 파운데이션 모델(독파모)을 중심으로 소버린 AI 스택을 만드는 회사들과 파트너십도 생각하고 있다고 해요.

임페라의 위치는 원 여러 개가 겹친 벤 다이어그램으로 설명해요. 보안이 있고 예전부터 있던 GRC(거버넌스·리스크·컴플라이언스)가 있고 새로운 에이전트 거버넌스 영역이 있죠. 대표는 보안을 전통적으로 엣지 케이스(거의 안 일어나는 예외 상황)의 문제로 봐요.

반면 AI 에이전트의 문제는 일상성의 문제, 그러니까 '먼데인 페일러(mundane failure, 일상적인 실패)'예요. 내 의도대로 움직이지 않거나 위험한 일을 하는 문제인데 그게 꼭 보안 문제일 필요는 없어요. 해법을 고민하는 곳이 아직 별로 없는 시장이고 임페라가 노리는 곳이기도 합니다.

그럼 무엇부터 시작해야 할까요? 대표의 첫마디는 너무 어렵게 생각하지 말라예요. 오늘 보여 준 걸 다 갖추려면 정말 어려운 일이지만 이것도 일종의 실험이거든요. 대표는 AI가 주는 가장 큰 가치가 실험 비용을 거의 0에 가깝게 만든 데 있다고 봐요. 그래서 AI 도입 효과(ROI)도 사람·시간·비용을 얼마나 줄였느냐보다 실험을 얼마나 많이 할 수 있게 됐느냐로 봐야 한다고 말합니다.

에이전트 개발을 실험처럼 하듯 통제도 실험으로 접근하면 돼요. 앞으로 3년간 안 바뀔 철옹성 같은 체계를 만들어 놓고 마음 편히 에이전트를 붙이는 식으로는 안 될 거라고 해요. 통제할 대상이 시시각각 변하니 도구도 조금씩 계속 바뀌어야 하니까요. 에이전트가 하나도 없거나 한두 개뿐이어도 그중 거버넌스를 테스트해 볼 만한 게 있으면 작게 돌려 보면서 데이터를 쌓고 연습하면 됩니다.

샌드박스를 만들 거라면 에이전트 개발 샌드박스만이 아니라 "거버넌스를 위한 샌드박스도 만드는게 좋겠다"는 게 대표의 마지막 조언이에요.

대표의 생각은 임페라 홈페이지와 링크드인, 그리고 미국에 있는 지인과 함께 운영하는 뉴스레터 '튜링 포스트 코리아'에서 더 볼 수 있다고 해요.

핵심 인사이트

• 프롬프트로 막는 건 확률을 낮출 뿐이에요: 막아 두지 않은 행동은 결국 일어난다는 전제에서 출발해야 해요. 에이전트의 '생각'을 고치려 하기보다 결제·삭제·발송처럼 실제로 영향을 주는 행동 지점에 통제를 거는 게 실행과 통제를 분리하는 첫걸음입니다.
• 등록돼 있어도 섀도우일 수 있어요: 리플릿 사례처럼 관리 중인 에이전트도 손에 닿는 권한을 찾아 쓰면 사고가 납니다. 그래서 에이전트 목록만큼이나 에이전트가 쥔 API 키와 권한 목록을 챙겨야 해요.
• 통제 기록은 비용이 아니라 자산이에요: 행동·정책·판정을 하나의 원장으로 모으면 감사용 기록을 넘어 정책을 고치는 근거가 됩니다. 대표가 말하는 'G 계수', 곧 얼마나 믿고 맡길 수 있느냐는 기업이 직접 키울 수 있는 몇 안 되는 변수예요.

오늘 당장 해볼 것

1. 지금 쓰는 AI 에이전트나 자동화(클로드 코드, 업무 자동화 워크플로 등)가 실제로 실행까지 하는 행동만 따로 적어 보세요. 메일 발송, 결제·환불, 파일이나 데이터 삭제, 고객 정보 수정 같은 것들이요. 이 목록이 대표가 말한 액션 온톨로지의 가장 작은 버전입니다.
2. 그 목록의 행동마다 세 가지 중 하나를 붙여 보세요. 그냥 두기(관찰), 기준을 넘으면 나에게 확인 요청(예: 환불 10만 원 초과), 무조건 막기(예: 운영 데이터 삭제)예요. 표 한 장이면 충분해요. 어디에 사람이 개입해야 하는지가 한눈에 보입니다.
3. 에이전트에 연결해 둔 API 키와 계정 권한을 점검해 보세요. 특히 실제 운영 데이터베이스에 쓰기·삭제 권한이 열려 있는지 확인하고 새 에이전트는 테스트용 복사본(샌드박스)에서 먼저 돌려 보세요. 리플릿 사고처럼 권한이 열려 있으면 언젠가는 쓰입니다.