부처별 소버리니티 시대에는 프론트 단위가 필요하다

공공 AX의 다음 문제는 협력 구조입니다.

앞으로 각 부처는 자기 에이전트를 만들 가능성이 큽니다. 행안부, 복지부, 교육부, 국토부가 같은 데이터와 같은 승인 체계와 같은 책임 구조를 공유한 채 하나의 에이전트만 쓰는 그림은 발표자료에서는 그럴듯하지만, 현실에서는 저항이 큽니다. 부처마다 다루는 정보가 다르고, 업무 규칙이 다르고, 결재 흐름이 다르고, 설명 책임의 방식도 다르기 때문입니다.

저는 이 흐름을 부처 단위 소버리니티라고 봅니다.

각 부처는 자기 데이터의 경계를 스스로 정하고 싶어 하고, 자기 업무 언어를 자기 방식으로 유지하고 싶어 하고, 자기 로그와 판단 체계를 자기 통제 아래 두고 싶어 합니다. 이건 폐쇄성의 문제가 아니라 책임의 문제입니다. 공공업무에서는 결과만 맞는 것으로 충분하지 않습니다. 누가 어떤 근거와 어떤 절차를 거쳐 그 결과에 도달했는지가 함께 중요합니다.

다음 사일로는 에이전트 사일로입니다

그래서 앞으로는 부처 간 사일로가 에이전트 사일로로 이어질 가능성이 큽니다.

각 부처가 자기 업무에 맞는 에이전트를 갖는 것은 충분히 자연스럽습니다. 문제는 그 다음입니다. 부처별 최적화가 쌓일수록 부처와 부처 사이의 협업은 더 어려워질 수 있습니다. 지금도 부처 간 협업은 문서 형식, 용어, 판단 기준, 결재 흐름이 달라서 자주 막힙니다. 여기에 각 부처가 자기만의 에이전트 체계까지 갖게 되면, 사람 사이의 사일로가 시스템 사이의 사일로로 굳어질 가능성이 큽니다.

이 문제는 대한민국만의 특수한 현상도 아닙니다. 부처가 분화된 정부라면 어디서나 비슷한 긴장이 생깁니다. 미국 연방정부도 기관별 시스템과 데이터, 책임 구조가 다르고, 유럽의 행정조직도 부처별 언어와 절차가 쉽게 통합되지 않습니다. 복지, 교육, 재정, 국토처럼 업무 성격이 달라질수록 각 조직은 자기 규칙과 로그, 승인 체계를 지키려 합니다. 그래서 부처 간 사일로는 한국 행정만의 예외라기보다, 큰 정부가 전문성과 책임을 나누는 순간 거의 필연적으로 생기는 구조적 현상에 가깝습니다.

이 지점에서 중요해지는 것은 에이전트 하나의 성능이 아닙니다. 에이전트들 사이의 연결 방식입니다. 어떤 요청을 어느 부처의 어떤 에이전트가 받아야 하는지, 중간 결과를 어떤 형식으로 넘길지, 서로 다른 판단을 어떻게 이어붙일지, 어느 지점에서 사람이 승인해야 하는지를 설계해야 합니다. 공공 AX의 병목은 점점 모델 자체보다 협업 구조 쪽으로 이동할 가능성이 큽니다.

통합보다 먼저 필요한 것은 프론트 단위입니다

원론적으로는 전 부처가 하나의 공통 에이전트 체계 아래로 들어오면 됩니다. 프롬프트를 맞추고, 로그를 통합하고, 승인 규칙을 표준화하면 됩니다. 그러나 현실의 정부는 그렇게 쉽게 움직이지 않습니다. 부처는 자기 소버리니티를 쉽게 포기하지 않고, 실제로 포기하면 안 되는 부분도 있습니다.

그래서 더 현실적인 해법은 소버리니티를 강제로 없애는 것이 아니라, 소버리니티를 유지한 채 협력하게 만드는 것입니다.

이때 필요한 것이 프론트 단위입니다. 프론트 단위는 사람의 요청을 받고, 요청의 맥락을 정리하고, 어느 부처의 어떤 전문 에이전트로 보내야 할지 판단하고, 돌아온 결과를 다시 사람 기준으로 묶어주는 앞단 레이어입니다. 여기에 승인 경계, 로그, 설명 흐름까지 보이게 해야 비로소 공공영역에서 쓸 수 있는 체계가 됩니다.

이 앞단은 단순 접수창구가 아닙니다. 번역기이자 라우터이고, 조율자이며, 결과를 stitching하는 인터페이스입니다. 공공 AX에서 실제로 필요한 것은 모든 일을 한 에이전트가 다 처리하는 구조보다, 이 앞단이 뒤편의 여러 전문 에이전트를 얼마나 안정적으로 연결하느냐에 가깝습니다.

현재는 OpenClaw가 이 패턴을 보여주고 있습니다

현재는 OpenClaw가 이런 앞단 패턴을 꽤 잘 보여주고 있습니다.

사람의 자연어 요청을 받고, 도구를 선택하고, 적절한 작업 주체로 넘기고, 결과를 다시 사람 기준으로 정리하는 흐름을 이미 수행하고 있기 때문입니다. 물론 이것이 곧바로 공공형 완성체라는 뜻은 아닙니다. 다만 “앞단에서 요청을 받아 뒤편의 전문 작업 주체를 조율하는 구조”가 실제로 어떻게 작동하는지는 이미 보여주고 있습니다.

앞으로 공공영역 안에서도 활용 가능한 전문 에이전트들이 하나둘 개발될 가능성이 큽니다. 부처별 정책 에이전트, 법령 검토 에이전트, 통계 해석 에이전트, 예산 검토 에이전트, 코딩 에이전트처럼 뒤편의 ‘주방’은 점점 다양해질 수 있습니다. 그럴수록 앞단은 더 중요해집니다.

그래서 웨이터와 셰프의 비유가 유효합니다

저는 이 프론트 단위를 셰프보다 웨이터에 가깝다고 봅니다.

좋은 웨이터는 주문만 전달하지 않습니다. 손님이 무엇을 원하는지 이해하고, 어느 주방으로 보내야 할지 판단하고, 여러 요리의 순서와 맥락을 조율하고, 결과를 손님이 이해할 수 있는 경험으로 다시 묶습니다. 중간에 문제가 생기면 다시 연결하고, 특별 요청이 있으면 반영합니다.

공공 AX의 프론트도 그와 비슷합니다. 사람의 요청을 정부 업무 문맥으로 번역하고, 어느 부처의 어떤 에이전트에게 보내야 할지 판단하고, 여러 결과를 다시 하나의 업무 흐름으로 엮어야 합니다. 반대로 뒤편의 전문 에이전트는 셰프에 가깝습니다. 실제 분석, 검토, 코드 작성, 법령 비교, 통계 해석 같은 깊은 실행을 맡습니다.

이 비유에서 중요한 것은 위계가 아니라 역할입니다. 공공 AX의 핵심은 가장 똑똑한 셰프 한 명을 찾는 데 있지 않습니다. 웨이터와 셰프, 앞단과 뒤편, 요청과 실행이 어떻게 맞물리는지를 설계하는 데 있습니다.

그래서 공픈클로는 OpenClaw의 공공 버전이라는 말로는 부족합니다

공픈클로를 단순히 OpenClaw의 공공 버전이라고 부르면 설명이 충분하지 않습니다. 핵심은 UI를 옮겨오는 데 있지 않고, 정부형 프론트 단위를 만드는 데 있기 때문입니다.

공공형 프론트는 개인 비서와 다른 조건 위에서 작동해야 합니다. 공익과 적법 절차를 함께 봐야 하고, 승인 경계를 드러내야 하고, 로그와 작업 흔적이 조직 자산으로 남아야 하고, 부처 간 협업에서도 설명 가능한 형태를 유지해야 합니다. 이 요구조건 때문에 공픈클로는 메신저 위의 편한 비서라기보다, 사람과 부처별 에이전트 사이를 이어주는 정부형 업무 인터페이스에 가까워집니다.

저는 앞으로의 공공 AX가 이 방향으로 갈 가능성이 높다고 봅니다.

각 부처는 자기 소버리니티를 유지한 채 뒤편의 전문 에이전트를 운영할 것입니다. 그리고 그 위에서 사람의 요청을 받아 전체 흐름을 연결하는 프론트 단위가 필요해질 것입니다. 그 구조를 먼저 잡는 쪽이, 공공에서 실제로 작동하는 AI 체계를 더 빨리 만들 가능성이 큽니다.

결국 핵심은 세 가지입니다.

부처별 소버리니티는 쉽게 사라지지 않고, 그래서 에이전트 간 협력 구조가 중요해지며, 그 협력 구조의 앞단에는 프론트 단위가 필요합니다.

저는 공픈클로가 바로 그 방향에서 의미를 가진다고 생각합니다.