▲

AI 모델에는 가상 머신이 필요함

 (blog.sigplan.org)
2P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • AI 소프트웨어는 단순히 모델 호출을 넘어서 보안·격리·확장성·이식성을 제공하는 운영체제적 특성을 필요로 하며, 이를 위해 AI 모델 전용 가상머신(MVM) 개념이 제안됨
  • Java Virtual Machine(JVM) 이 메모리 안전과 “한 번 작성, 어디서나 실행”을 가능하게 했던 것처럼, AI VM도 모델과 통합 로직을 분리해 교체 가능성과 상호운용성을 보장함
  • VM은 모델 호출, 툴 호출, 결과 저장, 사용자 입력, 조건 분기 같은 표준 명령 집합을 정의하여, 모델 행동을 안전하게 제약하고 추적할 수 있도록 함
  • OpenAI의 구조화된 툴 호출, Anthropic의 MCP, Microsoft의 FIDES/AC4A, 오픈소스 런타임 등 기존 연구가 이미 표준화 방향성을 보여주고 있음
  • 잘 정의된 AI VM은 보안·프라이버시 강화, 성능 모니터링, 출력 검증, 크로스 플랫폼 생태계 구축을 가능하게 하며, AI 시스템을 더 신뢰할 수 있고 안전하게 만드는 핵심 인프라로 자리매김할 수 있음

소개

  • AI 모델은 애플리케이션 코파일럿, IDE 통합, MCP 프로토콜을 통한 도구 사용 등 다양한 용도로 소프트웨어에 활용되고 있음
    • 이러한 발전은 프라이버시, 보안, 정확한 작동을 보장할 필요성을 증가시킴
  • 보안과 프라이버시는 시스템 설계 단계에서부터 확보되어야 하며, 사후 추가로는 부족
  • Java Virtual Machine(JVM) 에서 영감을 받아, AI 모델을 위한 표준화된 가상 머신의 중요성을 제안
    • JVM은 메모리 안전성, 액세스 제어, 바이트코드 검증을 통해 신뢰성 있는 실행 환경 제공
    • 이를 통해 “한 번 작성하고 어디서나 실행”이 가능해짐

AI 모델 가상 머신(MVM)의 역할

  • MVM은 AI 모델과 외부 환경 간의 중재 소프트웨어로 작동
    • 예: 사용자가 “항공편 예약” 프롬프트를 입력하면, MVM이 이를 모델에 전달(컨텍스트 추가 포함)
    • 모델이 “예약 도구 사용”을 응답하면, MVM은 허용된 도구 목록을 확인 후 도구 호출 여부 결정
    • 이는 모델이 승인되지 않은 호출을 수행하지 않도록 보장
  • 모든 상용 AI 시스템은 이와 유사한 제어 소프트웨어를 필요로 함
  • MVM은 명령어 집합을 정의하며, 예를 들어:
    • 모델 인증, 로드, 초기화, 언로드
    • 컨텍스트를 포함한 모델 호출
    • 모델 출력 파싱
    • 도구 인증, 로드, 호출, 결과 파싱 및 메모리 저장
    • 사용자 입력 요청, 히스토리 메모리 추가, 조건문 등 제어 구조

기존 연구와 필요성

  • OpenAI의 구조화된 도구 호출 프로토콜: JSON 기반 함수 호출 API와 OpenAPI 사양을 통해 명확한 도구 통합 제공
  • Anthropic의 MCP(2024): AI 어시스턴트와 외부 데이터를 연결하는 오픈 프로토콜
    • “AI 애플리케이션의 USB-C 포트”로 비유되며, 보편적 인터페이스 제공
    • 대기업을 포함한 빠른 채택 사례 보유
  • 보안 오케스트레이터 – FIDES & AC4A(2025):
    • FIDES(Microsoft Research): 정보 흐름 정책을 강제하며, 데이터 기밀성 라벨 추적 및 “검사” 액션 추가
    • AC4A: OS 스타일로 도구와 데이터를 계층 구조로 관리, 최소 권한 운영 모드 강제
    • 이러한 프로젝트는 MVM이 보안과 액세스 제어를 내장할 가능성을 보여줌
  • 오픈소스 에이전트 런타임: langchain, Semantic Kernel, llguidance는 런타임 서비스를 제공해 안정적인 AI 애플리케이션 개발 지원
  • MVM 사양은 모델 훈련 데이터가 인터페이스 사양을 반영해야 하며, 모델과 MVM 간 공동 진화 필요

MVM의 이점

  • 관심사 분리: 모델 로직과 통합 로직을 분리해 모델을 교체 가능한 컴포넌트로 전환
    • 새 모델로 교체나 플랫폼 이동 시 상호 운용성 유지
  • 내장된 안전성과 거버넌스: MVM은 허가 확인, 감사 로그, 안전 장치를 통해 안전성 보장
    • AC4A처럼 MVM이 게이트키퍼 역할을 해 예상치 못한 행동 억제
  • 투명한 성능 추적: 런타임 진단을 통해 모델 성능, 자원 소비, 데이터 액세스 수준 제공
    • 벤치마크를 통해 정확성, 유용성, 응답성을 비교 가능
  • 모델 출력 검증: 제로 지식 증명 같은 기술로 출력 무결성을 확인, 신뢰와 책임성 강화

결론

  • AI 모델 가상 머신은 AI 시스템의 복잡성을 줄이고 상호 운용성을 높이기 위해 필요
  • 보안, 프라이버시, 이식성, 신뢰성을 강화하며, 개발 속도와 생태계 확장성 증대
  • 기술 회사, 스타트업, 학계의 연구를 바탕으로 MVM 사양은 AI 모델이 안전하고 원활하게 상호작용할 수 있는 표준 제공
  • 커뮤니티와의 협력을 통해 MVM 사양의 필요성과 포함 요소에 대한 합의 구축이 목표
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 이 글은 구체적인 설명이 부족해서, 정확히 무엇을 제안하는지 알 수 없다는 생각임. VM(Virtual Machine)이란 어쨌든 명령어 집합, 제어 흐름, 레지스터 등과 연관된 것인데, 이 글은 허가(authorization)에만 집중하고 있음. 결국 '모델이 외부 세계와 상호작용할 수 있게 하는 sandbox, jail, container와 비슷한 무엇'을 얘기하는 것으로 보임

    • 정말로 VM 실행 엔진, 혹은 LLM을 위한 Docker를 얘기하는 것인가 하는 의문이 있음. 전체적으로 포장만 된 이야기처럼 보임. 패키징 시스템 설계가 부실하면 재앙이 될 수 있다고 생각함. Python의 여러 패키징 경험만 봐도 알 수 있음

    • VM이란 단어를 보고 곧바로 sandbox와 상당히 가깝다고 느꼈음. 글에서도 '격리'라고 했기 때문에, 애매하다거나 정보가 부족하다고 느끼지 않았음. 다만, 저자의 주장은 너무 당연하고, 솔루션도 불완전함. OS나 하드웨어 레벨의 sandbox에 넣어도, 에이전트가 IAM 설정이 잘못된 AWS CLI 같은 걸 찾으면 곤란해짐. 원격 경계도 복잡함. 새로운 인사이트는 발견하지 못했음. 용어 선택이 문제가 아니라고 생각함

    • 글에서 정의한 대로라면, 현재 AI agent도 이미 VM에서 실행되고 있다고 볼 수 있음. 예를 들어 MCP host에서 사용자의 실행 동의를 묻거나, Claude code처럼 특정 패턴의 명령을 자동 승인하는 규칙을 둘 수 있음

  • LLM에 어떤 툴을 줄 것인가가 아니라, 어떤 행동을 할 수 있게 할지가 본질적 문제라고 생각함. 예를 들어 항공권 예약 시나리오에서, LLM이 다양한 웹사이트에서 가격 비교와 결제까지 해주는 걸 원함. 하지만 쓸데없이 3달러 싼 37시간짜리 항공권 같은 것을 선택하진 않길 바람. 복리후생 정보 조회도 본인 것만 볼 수 있고, 동료의 것은 볼 수 없어야 함. 동일한 툴이라도 권한의 범위가 다름. HR 담당자는 본인이 관리하는 직원 정보는 당연히 볼 수 있지만, 그 경우 감사 기록 등 이슈가 추가됨. 즉, 행동보다도 의도(intent)가 중요함. LLM을 사용자의 대리인으로 두고, 동일한 권한 상자 안에 넣는 게 바람직함

    • 결국 말하는 건 capability security model임. 소프트웨어 에이전트가 접근 가능한 capability를 명시적으로 넘겨줘야 하고, 이 리스트 밖의 행동은 물리적으로 못 하게 해야 함. 하지만 실제로 mainstream OS 중에 이 모델을 구현한 것은 없음. 몇몇 연구(OS EXAMPLES: EROS, Fuchsia, Sandstorm)와 시도가 많았지만, 시장에서 별로 성공하지 못했음. 그래서 실제로 가장 근접한 방법이 VM을 써서, 필요한 도구만 VM에 두는 방식임. 이건 완벽하진 않은데, 도구 자체가 진짜 capability에 비해 너무 일반적임. 최소 권한 원칙으로 지어진 소프트웨어는 시장에서 자주 실패하게 마련임

    • 툴이 어느 행동을 할 수 있는지가 중요한 게 아니라, 툴이 접근 가능한 데이터와 행동의 조합이 더 중요함. LLM의 행동을 완벽히 예측할 수 없기 때문에, 신뢰하지 말아야 함. 예를 들어 LLM에게는 항공권 예약 사이트에만 접근 허용하지만, SSN이나 뱅크 계좌정보 등은 넘기지 않도록 해야 함. 데이터의 출처(provenance)와 권한 문제가 있는 것임. 민감한 데이터를 가진 태스크일수록 더 많은 제약이 필요하고, 반대로 덜 민감하면 더 많은 행동 허용 가능함. 데이터는 권한 정보를 갖고 있어야 하고, mediator가 새로 spawn 되는 태스크가 어떤 데이터·행동을 가질지 제한해야 함. 예: 여행 계획 태스크가 하위 태스크인 항공권 검색을 spawn하면, mediator가 하위 태스크엔 일정 일부 같은 비민감 데이터만 넘기고, 민감 데이터 접근은 막아야 함

    • LLM agent는 사용자와 동일한 다른 하나의 user로 보면 됨. 문맥(context)마다 다른 권한을 가짐. 예를 들어 어떤 소스코드 폴더에는 읽기/쓰기 권한, 다른 폴더에는 읽기만 가능. 각 프로젝트별로 LLM agent가 갖는 권한이 다르고, 이는 사용자의 권한 내 교집합 또는 하위집합임. 기본적으로 Allow, Deny, 그리고 Ask(허용 요청) 세 가지 권한 유형이 있고, 필요한 경우 사용자에게 허용 여부를 물음. 문제는 기존 OS 및 앱/데이터 권한이 충분히 세분화되어 있지 않다는 것임. git만 해도 전체 접근이 아니라 특정 명령어만 허용되게 설계돼야 함. 지금은 애플리케이션들이 각자 사용자 공간에서 이를 흉내내며, 어색한 방법으로 구현함. 워크플로우는 sudo랑 비슷함. 내 LLM Agent user로 앱을 런치하면, 해당 컨텍스트에 따라 권한이 부여/제한됨. 내가 요청할 때만 내 허용 범위 안에서 행동할 수 있음. 그런데 현재는 각 agentic 앱마다 이 프로세스를 직접 구현해야 하므로, 체계적인 OS 서비스로 만들어야 함. 임시로는 agent 컨텍스트별로 임시 유저 계정을 생성/삭제하며, IPC나 네트워크로만 소통하는 식으로 우회 가능함

    • 이런 모델이 제대로 작동할지 의문임. LLM이 뭔가 할 수 있다 해도, 웹사이트들은 이를 감지해 가격을 조정하거나 의사결정 트리를 망가뜨릴 수 있음. 그럴 바에야 아예 모든 사이트가 LLM용 API, 혹은 'rss + json'을 쓰는 게 훨씬 나음. BBS, SMS 메뉴 시스템처럼 단순 데이터·선택지만 주면 LLM에게도 최적임. 광고도 마찬가지임. LLM에게는 괜히 광고 보여줄 필요가 없고, 오히려 LLM을 속이려는 광고가 더 효과적임. 예를 들어 항공 검색 시 광고가 LLM을 유혹해 내 상품이 최고라고 속일 수 있음. 실제로 AI가 아직 단순하니 AI 전용 광고가 나오면 재미있을 듯함

    • “좋은 응답”의 정의와 집행이 가능하다면, 굳이 LLM 자체가 필요 없을 수 있음. HR 담당자의 경우는 의도를 직접 물어볼 수 있지만, LLM은 의도가 없다는 점에서 어렵다고 봄

  • 예전에 John Carmack이 Meta에서 XROS 만들 때 시간과 돈만 낭비했다는 HN 글을 봤었음. 오늘 본 이 글은 반대로 ‘새로운 OS 필요성’을 강하게 주장함. VM은 완전한 OS는 아니지만, 기존 OS/코드베이스를 활용해서 가볍게 만들 수 있다는 점에서 차이가 있음

    • 두 글은 완전히 다른 이야기임. 실제로 이 글이 VM이나 새로운 OS 필요성을 강하게 주장한다고 보이지도 않음. 결국엔 access control 이야기가 전부임

    • XR에선 performance와 dev experience가 중심이었던 반면에, LLM 쪽은 tool/data 접근을 어떻게 sandbox하고 단순화할지 그 자체가 핵심임. LLM이 실행 환경을 망치거나 데이터 손상시키지 않도록 할 일이 많고, 표준이 있으면 재학습 부담을 줄이고 다른 사람들의 모델 활용도 편함. XR은 그냥 SDK 정도라면 트레이닝으로 해결 가능하지만, AI는 연구개발과 compute 비용이 훨씬 큼

    • WebAssembly는 기본적으로 sandbox를 제공하므로 절반쯤 도달했다고 봄. 남은 건 instance 간 데이터/권한 이전을 위한 명확한 인터페이스와, instance간 상호 생성 방법임

    • 이 글이 새로운 OS 작성의 근거는 되지 않는다고 생각함. AI를 위한 실행 환경 구축과 AI에 최적화된 OS를 무에서 설계하는 건 완전히 별개임

  • 글을 자세히 읽고 참고 링크들을 본 결과, 이 글이 단순히 "AI를 위한 VM"보다 더 근본적인 문제를 짚고 있다고 느낌. VM만으로는 LLM workflow 보안을 책임지기 부족함. 최상위 workflow는 네트워크, PII, credentials 등 민감한 작업과 데이터에 접근해야 하고, LLM은 prompt injection과 정합성 문제에 취약함. 단순히 LLM을 VM에 넣는다고 해결되지 않음. 작업 단위로 워크플로우, 데이터, 연산을 파티셔닝해서 최소한의 하위 task만 제한된 정보에 접근하게 하는 '정보-흐름 관리'가 필요함. 민감한 작업을 담당하는 subset만 별도로 신뢰·검증해야 함. 이 글이 언급한 “Secure Orchestrators”, 그리고 FIDES 논문 이핵심임. “VM”은 결국 제한된 권한/데이터만 준 컨테이너에 task를 실행하는 것임. orchestrator가 이 컨테이너를 만들고, 적절한 권한을 주며, 산출 데이터에도 민감도(taint-tracking) 라벨을 붙여야 함. 전체적으로 “VM for AI”라는 표현보다 “partitioning”이나 “isolation”, 그리고 데이터 이슈를 강조하는 게 더 맞다고 생각함

    • Microsoft Wassette랑 비슷하게 들림

    • 워크플로우라는 개념 자체를 없애는 게 목표가 되어야 함. LLM+VM 조합에서는, 도구(tool)를 LLM에 제공하는 것 자체가 워크플로우임. 이 방식은 이미 종종 잘 작동하지만, 미리 정의하지 않은 예외 상황이나 도구가 필요한 작업엔 한계가 있음. 게다가 워크플로우 기반은 언제나 선형적(혹은 DAG, loop 포함) 한계를 벗어나기 힘듦. 다음 단계는, 도구를 아예 제공하지 않고 LLM이 필요할 때마다 즉석에서 도구 자체를 만들어내는 것임. 어떤 문제는 brute-force식 접근이 필요함

  • 글을 읽으면서 요즘 글들이 AI가 쓴 것 같다는 생각이 들 정도임. 호스팅 입장에서 보면 어떤 환경에서든 AI agent를 안정적으로 띄우는 것부터가 큰 도전임. 개발자로서 wsl의 rootless docker devcontainer를 쓰고 있는데, 일부 악성코드는 뚫을 수 있겠지만 VM 접근법보다 이쪽이 더 안전함을 느낌. 게다가 재현성, 환경 분리 등 장점도 있고, AI가 내 환경을 망치면 그냥 컨테이너를 다시 세우면 되기 때문에 부담이 덜함

  • 상업적으로 가장 발전한 모델 배포 방식을 보면, 격리 등 이 글에서 언급한 거의 모든 특징이 이미 구현되어 있음. OS 자체 수준은 아니지만 기능은 비슷함. 근데 이 정도로도 충분하지 않음. 에이전트가 제대로 일하려면 중요한 리소스 접근 권한이 있어야 하고, 그 권한을 딱 필요한 만큼만 부여하는 건 LLM 자체를 격리하는 것보다 훨씬 어려움. LLM 보안을 위한 정확한 모델은 'untrusted userspace'임. OS 전체를 설계할 필요는 없음

    • 'untrusted userspace'라는 개념이 정확하다고 봄. 이런 방식들이 어쩌면 보안 측면에서 미세하게 도움이 되겠지만, "보장한다"는 식으로 저자들이 과장한 부분은 동의하지 않음. 툴 접근을 파일 권한에 비유했지만, 실제로 OS의 file permission track record는 썩 좋지 않음. 예약 툴 사용 허가 여부 등을 확인한다면, 결국 그건 웹 브라우저임. 브라우저는 범용 도구이기도 하면서 jailbreak 같은 공격에 노출될 수도 있음. 이런 가상 머신 제약하에서도 AI 모델이 반역적 행동을 하지 못하게 하는 새로운 보안 대책이 필요하다는 점이 중요함. 결국 'alignment' 문제를 반드시 해결해야 한다는 소박한 교훈임

  • LLM 격리를 VM 설계 수준으로 철저하게 해야 한다는 의견에 동의함. 전통적인 OS에서 이런 행위를 엄격하게 적용하는 이유와 동일함. 최근 이 블로그에 아이디어를 정리해 봤었음. LLM의 동작 방식과 전통적 OS 프로세스/태스크를 비교하는 식으로 접근했고, 주요 추상화는 구현이 어렵지 않음 — 8개 LLM backend의 chat/tool interface를 통합해 tool approval을 중앙 관리 가능. 아직 capabilities model은 구현하지 않았지만, 과거 OS(VSTa) 경험상 자연스러운 방식임. 한 LLM이 보유 권한의 subset을 다른 LLM에게 위임할 수 있어야 하고, delegation 도구도 만든 상태임

  • VM 같이 새로운 추상 머신을 만드는 것은 더 복잡한 일만 만들어준다고 봄. 이미 계정, 파일 읽기/쓰기/실행 권한, 그리고 임시 또는 원격 접근은 access token으로 충분히 커버할 수 있음. 모든 capabilities model은 이런 개념으로 충분히 구현 가능하다고 생각함. 나는 이미 있는 도구를 단순화하는 게 더 바람직하다고 봄. 소프트웨어 전체적인 근본적 변화를 기대하며, 현재 다들 새로운 걸 실험하고는 있지만 오히려 쓸데없는 복잡함을 줄이고 심플하게 만드는 시기로 삼아야 한다고 생각함. 예를 들어, MCP 서버를 Claude로 간단히 CLI 툴로 바꾸는 데 10분이면 됨. 이 정도면 충분히 쓸 만하다고 느낌

    • 현대 데스크톱 OS의 보안 모델은 지금 시대에 터무니없이 부족함. 사용자에게 별다른 경고나 확인조차 없이 모든 권한을 넘겨주는 건 미친 짓에 가까움. 만일 사용자가 정말 제약 없는 환경을 원한다면 선택권을 줘야겠지만, 기본값은 최소 권한이어야 함. 프로그램별로 도메인별 권한만 부여해야 함. 가령 디스크 사용량을 시각화하는 도구라면 파일시스템 풀 접근이 필요할 수 있지만, 로컬 네트워크나 인터넷 접근은 불필요함

    • VM의 가장 큰 강점은 피해 범위를 제한하는 것임. 좋은 agent는 시스템 내에서 zero day를 활용해 간단히 시스템을 뚫을 수 있음. 유저 권한만으로도 충분히 위험한데, 에이전트의 지식을 방화벽으로 제한하는 것은 매우 어렵고, 인터넷에서 우회할 수단이 많음. 이런 시스템 크래킹에 매우 능해질 것이므로, 아주 단단한 보안 장치가 필요함

    • LLM 환경에서는 일회성 읽기('temporary read')란 게 성립하지 않음. 한번 context에 들어간 순간, 에이전트가 죽고 컨텍스트가 삭제되기 전까지 연결된 모든 곳으로 데이터가 유출될 수 있다고 봐야 함. 이건 VM이건 아니건 마찬가지고, VM만으로는 보안 솔루션이 안 됨

    • 대부분 동의함. 많은 보안 위험은 VM이 있든 없든 상관없이 발생함. 앞으로 defense in depth가 더 중요해지겠지만, 현재는 공격자가 AI agent를 이용해 사용자를 해칠 수 있는 쉬운 수단이 너무 많음

    • 파일 편집 툴만 허용되는 순간, 사실상 모든 보안을 잃게 됨

  • Fuchsia는 AI 모델 동작 제어에 현실적인 OS가 될 수 있다고 생각함. object capability OS여서, 각 컴포넌트(프로세스)는 명시적으로 부여된 capability에만 접근할 수 있음

    • Fuchsia 디자인에 동의하고 좋아하지만, 실제로 실현될 거라고는 생각하지 않음. 새 OS를 만들기보다는, WASM/WASI component 기반의 Fuchsia 유사 모델이 클라우드~모바일 어디서나 호스팅될 방향이 될 가능성이 높다고 봄

  • ChatGPT가 코드 실행할 때(예: CSV 처리 요청), 특정 툴과 라이브러리만 접근 가능한 VM, 샌드박스된 디스크, 그리고 인터넷 미접속 환경에서 실행되는 것으로 보임. 결국 벌써 이런 구조와 비슷하게 가고 있음

    • Devin, OpenHands도 비슷함. 내가 몇 달 전 진행한 AI 파일럿 프로젝트에서도 ‘agent를 VM에서 실행(기본값)’이 핵심 요소였음

    • AKS(Azure Kubernetes) 기반 Kubernetes에 gvisor, Jupyter가 얹어진 형태임

    • 꼭 그렇지는 않음. 예를 들어 머신에 두 개의 AI(ChatGPT 등)를 돌린다고 가정하면, 협업이나 상호 작동에 관한 표준이나 상호 운용성이 전혀 없음.

답변달기