에이전트를 도입하는 게 아니라, 운영할 통제 평면이 없습니다

데모에서 당직으로

올해 상반기 국내 AI 뉴스를 하루치만 모아 읽어도 흐름이 또렷합니다. 보험사는 상담 응대 수준에 머물던 AI를 자동차 사고 과실 판정과 언더라이팅 같은 핵심 업무로 밀어 넣고 있습니다. 한국중부발전은 생성형을 넘어 실제로 일을 실행하는 ‘액셔너블 AI’로 26개 업무를 옮기겠다고 밝혔습니다. 마이크로소프트와 아마존웹서비스는 에이전트를 고객 현장에 투입하는 전담 조직을 따로 키우고 있습니다.

공통점이 하나 있습니다. 질문이 바뀌었다는 것입니다. 작년까지 회의실에서 오가던 물음은 “이걸 도입해야 하나”였습니다. 지금 실무자가 붙들고 있는 물음은 “이걸 어떻게 안전하게 운영하나”입니다. 에이전트가 데모 무대에서 내려와 야간 당직을 서기 시작하면서, 무게 중심이 성능에서 운영으로 넘어갔습니다.

병목은 모델이 아닙니다

흔한 오해부터 걷어내겠습니다. 더 좋은 모델이 나오면 풀린다는 생각입니다. 현장에 붙여 보면 막히는 지점은 모델의 추론 능력이 아닙니다. 세 가지 운영의 벽입니다.

첫째는 감사 불가능성입니다. 에이전트가 왜 그 판단을 내렸고, 그 과정에서 어떤 도구를 어떤 순서로 호출했는지를 사후에 재구성하지 못하면, 금융이나 공공처럼 규제가 강한 영역에서는 프로덕션 승인 자체가 나지 않습니다. 보험 언더라이팅 자동화가 정확히 이 지점에 서 있습니다. 심사 결과가 맞고 틀리고를 떠나, 판단 경로를 설명하지 못하는 시스템은 감독 앞에서 버티지 못합니다.

둘째는 주권과 공급망입니다. 오늘 나온 소버린 AI 기사가 짚은 대목이 핵심을 찌릅니다. 이제 모델 주권만으로는 부족하고, 그 모델이 실제로 구동되는 오픈소스 패키지와 데이터셋, 에이전트 도구 계층까지 출처와 무결성을 검증해야 한다는 것입니다. 민감한 의료·개인정보를 다루는 금융사일수록 망분리와 온프렘이 협상 대상이 아니라 전제 조건입니다.

셋째는 안전한 실행입니다. 에이전트가 코드를 돌리고 외부 도구를 호출하는 순간, 격리되지 않은 실행 환경은 그 자체가 사고의 씨앗입니다. 잘못된 도구 호출 한 번이 데이터 유출이나 비가역 변경으로 이어질 수 있습니다.

세 벽은 모두 모델을 한 단계 키운다고 사라지지 않습니다. 운영을 어디에 맡기느냐의 문제이기 때문입니다.

기존 클라우드가 못 푸는 이유

지난 15년 동안 클라우드는 가상 머신과 데이터베이스, 네트워크를 일급 리소스로 추상화하는 데 성공했습니다. 필요할 때 서버를 띄우고, 권한을 붙이고, 로그를 남기는 일이 플랫폼 레벨에서 표준화됐습니다. 그런데 그 위에 에이전트를 올리면 이야기가 달라집니다.

에이전트의 핵심 개념은 서버가 아닙니다. 어떤 능력을 쓰는가, 어떤 도구에 접근하는가, 어떤 정책 아래 움직이는가, 무엇을 했는가입니다. 기존 클라우드에서 이 네 가지는 일급 리소스가 아니라 애플리케이션 코드 안에 흩어진 부수 효과로 남습니다. 감사 로그는 팀마다 알아서 남기고, 정책은 프롬프트 문장에 묻히고, 도구 권한은 여기저기 흩어진 API 키로 관리됩니다.

결과적으로 통제가 플랫폼이 아니라 관행에 얹혀 있습니다. 팀이 바뀌고 사람이 나가면 그 관행도 함께 사라집니다. 규제 심사관 앞에서 “관행상 그렇게 하고 있습니다”라는 답은 통하지 않습니다. 통제는 재현 가능하고 강제되는 형태여야 하며, 그건 개별 코드가 아니라 플랫폼이 책임질 몫입니다.

통제를 관행이 아니라 플랫폼으로

Paxis가 택한 전제는 단순합니다. 에이전트 시대의 일급 리소스는 가상 머신이 아니라 Skills, Tools, Policies, Audit Logs라는 것입니다. 기존 클라우드가 서버와 네트워크를 다루듯, Paxis는 이 네 가지를 플랫폼이 직접 관리하는 자원으로 끌어올립니다.

Skills는 에이전트의 능력을 버전 관리되는 자원으로 다룹니다. 능력을 등록하고 검증하고 회수하는 일이 개별 프로젝트가 아니라 플랫폼 레벨에서 이뤄집니다. Tools는 도구 접근을 선언적으로 정의합니다. 어떤 에이전트가 어떤 도구를 언제 호출할 수 있는지 정책이 앞에서 판단합니다. Policies는 자율도를 명시적으로 규정합니다. 정해진 승인 게이트를 지나야 실행이 이어지므로, 에이전트가 넘지 말아야 할 선이 문서가 아니라 실행 경로에 박혀 있습니다. Audit Logs는 모든 행동이 통과하는 기본 관문입니다. 사후 재구성이 예외가 아니라 기본값입니다.

세 벽에 대입하면 이렇게 맞물립니다.

현장의 벽	기존 방식의 한계	Paxis의 대응
감사 불가능성	팀마다 제각각인 로깅, 판단 경로 재구성 불가	모든 도구 호출·판단이 Audit Logs를 통과, 사후 재구성이 기본값
주권·공급망	모델만 통제, 스킬·툴·데이터 계층은 사각지대	Skills·Tools를 일급 자원으로 등록·검증, 소버린 K8s 위에서 온프렘 구동
안전한 실행	격리 없는 도구 호출, 권한이 흩어진 API 키	정책 게이트를 통과한 실행만 격리 샌드박스에서 수행

핵심은 에이전트가 스스로 일정을 잡고, 격리된 샌드박스에서 코드를 실행하고, 팀 위키에서 지식을 끌어오는 그 모든 동작이 정책 게이트와 감사 로그를 반드시 지나간다는 점입니다. 통제가 사람의 성실함이 아니라 플랫폼의 구조에 얹혀 있습니다.

오늘 뉴스에 그대로 대입해 보면

보험사의 언더라이팅 자동화는 감사 가능한 실행이 승인 조건입니다. 판단 경로가 남지 않으면 규제 문턱을 넘지 못하고, 그 요건을 Audit Logs가 채웁니다. 소버린 AI가 공급망 주권으로 넓어져야 한다는 지적은, 모델뿐 아니라 스킬과 도구 계층의 출처·무결성을 배포 파이프라인에서 검증하라는 요구로 읽힙니다. 금융사가 요구하는 망분리와 온프렘은 소버린 K8s 인프라 위에서 에이전트를 돌린다는 전제와 곧장 맞닿습니다.

같은 뉴스를 두 가지 시선으로 볼 수 있습니다. 하나는 “에이전트 도입이 빨라지고 있다”는 표면입니다. 다른 하나는 “그 속도를 감당할 운영 기반이 준비돼 있는가”라는 질문입니다. 도입의 병목이 성능에서 운영으로 넘어간 지금, 두 번째 질문에 답하는 쪽이 다음 단계를 가져갑니다.

남은 질문

에이전트 시대의 인프라 경쟁력은 더 빠른 GPU 한 장에서 갈리지 않습니다. 믿고 맡길 수 있는 통제 평면이 있느냐에서 갈립니다. 도입은 이미 시작됐고, 실무자에게 남은 선택지는 운영을 관행에 맡길지 플랫폼에 맡길지입니다. Paxis는 후자를 택했습니다. 에이전트의 능력과 도구, 정책, 감사를 처음부터 일급 자원으로 다루는 Agent-Native Cloud가 그 답입니다.

금융·공공처럼 감사와 주권 요건이 강한 현장에서 에이전트를 프로덕션에 올리는 일을 고민하고 있다면, ThakiCloud와 파일럿 단계에서 함께 검증해 볼 수 있습니다. 통제 평면을 나중에 덧대는 대신 처음부터 깔고 시작하는 편이, 결국 더 빠른 길입니다.