에이전트를 설계할 때 가장 먼저 묻는 질문은 보통 이겁니다.

“어떤 모델을 쓸 것인가?”

틀린 질문은 아닙니다. 하지만 한국 산업 현장에서 올해 연속으로 터지는 신호들을 보면, 더 먼저 물어야 할 질문이 생겼습니다.

“이 에이전트, 어디서 판단하게 할 것인가?”

VIXA: 클라우드 없이 현장에서 판단하는 에이전트

인텔리빅스와 모빌린트가 공동 개발한 ‘VIXA’는 국산 NPU(신경망처리장치) 기반으로 현장에서 직접 구동되는 영상분석 에이전트입니다. 카메라 피드를 받아 실시간 영상을 분석하고, 위협 요소를 탐지하며, 현장 상황에 따라 판단하고 행동까지 수행합니다.

핵심은 이 모든 과정이 클라우드 없이 로컬에서 이루어진다는 점입니다.

대상 시장이 국방과 공공 안전입니다. 이유가 명확합니다. 국방 현장에서 촬영된 영상은 외부 서버로 전송할 수 없습니다. 공공 안전 인프라의 판단 결과가 인터넷 망을 통해 오갈 때 생기는 지연은 허용 불가합니다. 인텔리빅스는 이 시장에서 30%의 점유율을 목표로 명시했습니다. 한국에서 “소버린 AI 에이전트”라는 개념이 구체적인 제품과 시장 목표를 갖춘 첫 사례입니다.

세 곳에서 동시에 나온 같은 결론

VIXA가 단독 사례였다면 흥미로운 특이점에 그쳤을 겁니다. 그런데 같은 시기, 다른 두 곳에서 같은 방향의 신호가 나왔습니다.

씨이랩은 CCTV 기반 산업 안전 에이전트를 공개했습니다. 지게차와 작업자의 충돌 직전 상황을 탐지해 관리자에게 즉시 알림을 보내는 시스템입니다. “충돌 직전”이라는 표현이 핵심입니다. 사고가 발생한 뒤에 로그를 분석하는 게 아니라, 충돌이 일어나기 직전의 패턴을 감지하고 개입합니다. 이 판단이 클라우드 왕복 레이턴시를 견딜 수 있을까요? 수백 밀리초면 이미 늦습니다.

마키나락스는 국방과학연구소의 ‘AI 참모 에이전트’ 개발 사업을 14.6억원에 수주했습니다. 자사 AI OS ‘런웨이’ 기반으로 개발·실험·배포를 통합합니다. 국방 무기체계 도메인에 특화된 에이전트 — 여기에도 당연히 외부 클라우드 의존이 없어야 합니다.

세 회사, 세 도메인(국방/안전/공공), 하나의 결론: 현장형 에이전트는 클라우드 구조와 다른 설계 원칙을 요구한다.

클라우드 에이전트가 못 들어오는 이유

범용 에이전트가 이 시장에 들어오기 어려운 이유를 정리하면 세 가지입니다.

첫 번째, 규제입니다. 국방 데이터, 공공 안전 CCTV 영상, 의료 기록은 외부 서버로 내보낼 수 없습니다. 개인정보보호법, 국가보안법, 군사기밀 관련 규정이 클라우드 에이전트의 진입 자체를 막습니다. 아무리 뛰어난 모델이라도, 데이터가 모델에 도달할 수 없으면 의미가 없습니다.

두 번째, 레이턴시입니다. 충돌 직전 탐지, 침입 감지, 이상 행동 감시는 판단 시간이 수십~수백 밀리초 단위입니다. 클라우드로 데이터를 보내고 판단을 받아오는 왕복 시간은 현장 실시간성과 양립하지 않습니다. 판단이 현장에서 일어나야 하는 이유입니다.

세 번째, 데이터 주권입니다. “소버린 AI”는 단순히 ‘국산 모델’의 문제가 아닙니다. 추론이 어디서 일어나는가, 데이터가 어디에 저장되는가, 판단의 결과가 어떤 경로를 거치는가가 모두 포함됩니다. VIXA가 NPU 기반 온프레미스 에이전트로 설계된 이유가 이것입니다.

범용 클라우드 에이전트는 이 세 가지 조건을 충족하도록 설계되지 않았습니다. 이건 기술 격차가 아니라 아키텍처 선택의 차이입니다.

PM에게 생기는 새 설계 변수: Where-to-Run

에이전트를 기획하거나 도입을 결정하는 PM 입장에서, 이 흐름은 설계 체크리스트에 새 항목을 추가합니다.

기존 체크리스트는 대략 이렇습니다:

  • 어떤 모델을 쓸 것인가 (Claude / GPT / 국산 LLM)
  • 어떤 도구와 연동할 것인가 (MCP, 사내 API)
  • 오케스트레이션 구조는 어떻게 할 것인가 (단일 에이전트 / 멀티에이전트)
  • 메모리와 컨텍스트는 어떻게 관리할 것인가

여기에 하나가 추가됩니다:

“이 에이전트, 어디서 추론할 것인가?”

클라우드냐 온프레미스냐, 중앙 서버냐 엣지 디바이스냐. 이 결정이 이제 나머지 모든 설계 선택에 앞서야 합니다. Where-to-Run이 먼저 정해져야 모델 선택, 도구 설계, 배포 구조가 뒤따를 수 있습니다.

실제 사례로 보면 선택지가 구체화됩니다:

배포 환경대표 사례요구 조건
퍼블릭 클라우드범용 SaaS 에이전트범용성, 비용 최적화
프라이빗 클라우드금융·의료 에이전트컴플라이언스, 데이터 격리
온프레미스 서버마키나락스 국방 AI망분리, 데이터 주권
엣지 NPU인텔리빅스 VIXA실시간성, 오프라인 작동

이 네 가지가 대등한 선택지입니다. “에이전트 = 클라우드 서비스”라는 기본 가정이 이미 깨졌습니다.

설계 원칙이 갈리는 지점

Where-to-Run에 따라 에이전트 설계 원칙이 달라지는 지점이 있습니다.

모델 경량화가 1차 제약이 됩니다. 엣지 NPU에서 구동되는 에이전트는 모델 크기가 곧 배포 가능성입니다. 파라미터 수, 양자화 수준, 추론 속도가 “가장 좋은 모델”보다 중요해집니다. VIXA가 국산 NPU를 선택한 이유도 여기에 있습니다. 글로벌 프론티어 모델의 추론 능력보다 현장 배포 가능성이 먼저입니다.

업데이트 패턴이 달라집니다. 클라우드 에이전트는 모델 업데이트가 투명하게 이루어집니다. 온프레미스·엣지 에이전트는 업데이트 주기, 승인 절차, 배포 방식이 별도로 설계되어야 합니다. 국방 시스템이라면 더욱 엄격한 검증 프로세스를 통과해야 합니다.

관측성(observability)의 위치가 바뀝니다. 클라우드 에이전트는 중앙 로그 시스템에서 모든 추론을 관찰할 수 있습니다. 현장형 에이전트는 로그를 어디서 어떻게 수집할 것인지, 이상 징후를 어떻게 감지할 것인지를 현장 조건에 맞게 설계해야 합니다.

한국이 먼저 이 시장을 열고 있는 이유

글로벌 AI 에이전트 담론은 여전히 클라우드 중심입니다. OpenAI, Anthropic, Google의 에이전트 제품은 모두 클라우드 API 기반입니다.

반면 한국에서는 국방·공공 안전·제조 현장형 에이전트가 동시에 등장하고 있습니다. 이유가 있습니다.

한국은 망분리 규정이 엄격합니다. 금융, 의료, 공공, 국방 모두 데이터의 외부 이동에 높은 벽이 있습니다. 이 벽이 클라우드 에이전트의 진입을 막는 동시에, 현장형 에이전트 개발의 동인이 됩니다. 규제가 불편으로 작용하는 게 아니라 새로운 제품 범주를 만드는 압력이 된 겁니다.

산업부 400억원 규모의 산업 AI 에이전트 R&D 사업이 “판단을 넘어 실제 설비 제어까지”를 목표로 명시한 것도 같은 맥락입니다. 제조 현장 설비를 클라우드 에이전트가 직접 제어하는 건 현실적이지 않습니다. 에이전트가 현장에 있어야 합니다.

PM이 지금 할 일

이 흐름에서 PM이 해야 할 일은 하나입니다. 에이전트를 기획할 때 “Where-to-Run”을 설계의 첫 번째 질문으로 올리는 것입니다.

구체적으로:

  1. 에이전트가 다루는 데이터의 규제 환경을 먼저 파악합니다. 외부 전송이 불가한 데이터라면 클라우드 에이전트는 출발선에서 탈락입니다.

  2. 판단 시간이 사용자 경험이나 안전에 직결되는 도메인이라면 레이턴시 요구 사항을 정량으로 정의합니다. “실시간”은 설계 조건이 아닙니다. 몇 밀리초 안에 판단이 나와야 하는가가 설계 조건입니다.

  3. 클라우드/온프레미스/엣지 중 배포 환경을 먼저 결정한 뒤, 그 환경에서 구동 가능한 모델과 아키텍처를 선택하는 순서로 접근합니다.

에이전트의 지능이 아무리 뛰어나도, 판단이 현장에 닿지 않으면 의미가 없습니다. VIXA가 보여주는 것은 기술이 아닙니다. 에이전트 설계의 순서입니다.

당신이 지금 설계하는 에이전트는 어디서 판단합니까?

클라우드가 당연한 선택이었다면, 한 번만 더 물어보세요. 이 에이전트가 다루는 데이터가 클라우드로 나갈 수 있는지, 판단이 클라우드 왕복을 기다릴 수 있는지를요.

그 두 질문이 설계 방향을 바꿀 수 있습니다.