로컬 AI는 위안을 주는 이야기를 가지고 있습니다. 모델이 사용자의 기기에서 실행되고, 프롬프트가 클라우드 벤더로 전송되지 않으며, 코드가 근처에 머물고, 비행기 안에서도 데모가 작동한다는 점입니다.

저는 로컬 AI를 좋아합니다.

하지만 이것이 개발자 기기에 추가하는 요소들에 대해 우리가 너무 낮게 평가하고 있다고 생각합니다.

올해 Docker의 보안 발표에는 Docker Model Runner와 관련된 몇 가지 수정 사항이 포함되어 있습니다: 두 가지 추론 백엔드(Inference backend)에서의 컨테이너-호스트 간 코드 실행, OCI 레지스트리 클라이언트에서의 SSRF, 그리고 런타임 플래그 주입(Runtime flag injection) 문제입니다. Model Runner는 개발자들이 원하게 될 종류의 기능입니다. Docker Hub, OCI 레지스트리, Hugging Face에서 모델을 가져올 수 있고, OpenAI 및 Ollama와 호환되는 API를 통해 모델을 서빙하며, 모델 파일을 OCI 아티팩트(Artifacts)로 패키징하고, 코딩 도구와 연결할 수 있습니다.

이것은 유용합니다. 하지만 동시에 노트북 한 대를 가로지르는 엄청난 양의 신뢰를 요구합니다.

로컬이 단순함을 의미하지는 않습니다

"로컬(Local)"이라는 단어는 시스템을 실제보다 더 작게 느껴지게 만듭니다.

누군가 자신의 기기에서 로컬 모델이 실행되고 있다고 말할 때, 머릿속에 그려지는 그림은 대개 하나의 프로세스, 하나의 모델 파일, 한 명의 사용자, 그리고 하나의 프롬프트입니다. 그 그림은 너무 작습니다.

로컬 AI 런타임(Runtime)은 여러 경계에 걸쳐 존재합니다:

• 모델 배포 채널 (Model distribution channel)
• 모델 캐시 (Model cache)
• 추론 백엔드 (Inference backend)
• 로컬 API 서버 (Local API server)
• 컨테이너 또는 샌드박스 경계 (Container or sandbox boundary)
• GPU 드라이버 및 가속 라이브러리 (GPU drivers and acceleration libraries)
• API를 호출하는 개발자 도구 (Developer tools)
• 워크스테이션의 소스 코드 및 자격 증명 (Source code and credentials)

이것은 단일 요소가 아닙니다. 이것은 하나의 플랫폼입니다.

Docker Model Runner 문서는 그 형태를 꽤 명확하게 보여줍니다. 모델은 Docker Hub, OCI 준수 레지스트리, 또는 Hugging Face에서 가져올 수 있습니다. 모델은 로컬에 저장되고 런타임에 로드됩니다. 런타임은 OpenAI 및 Ollama와 호환되는 API를 노출할 수 있습니다. 또한 여러 추론 엔진(Inference engines)을 지원합니다. Linux에서 Docker는 엔진이 컨테이너 내부에서 실행된다고 말합니다. macOS 및 Windows에서는 샌드박스 환경(Sandboxed environments)에서 실행됩니다.

이것은 비판이 아닙니다.

하지만 일단 통합이 이루어지면, 우리가 다른 개발자 인프라에 적용하는 것과 동일한 수준의 지루한 보안 사고(Security thinking)를 적용할 가치가 있습니다.

모델 레지스트리(Model Registry)는 공급망(Supply Chain)입니다

가장 범하기 쉬운 실수는 모델을 불활성 데이터(Inert data)로 취급하는 것입니다.

때로는 그에 가까울 수도 있습니다. 모델 파일은 무작위 설치 스크립트와는 다른 것입니다. 하지만 모델을 둘러싼 런타임(Runtime)은 활성 소프트웨어이며, 그 런타임으로 들어가는 경로는 매우 중요합니다.

만약 여러분의 로컬 AI 도구가 공개 레지스트리(Public registry)에서 데이터를 가져오고, 메타데이터(Metadata)를 파싱하며, 리다이렉트(Redirect)를 따르고, OCI 클라이언트와 통신하며, 아티팩트(Artifact)를 캐싱하고, 네이티브 코드(Native code)가 포함된 백엔드에 모델 파일을 로드한다면, 여러분은 공급망(Supply chain)을 보유하고 있는 것입니다. 약간 특이한 형태이긴 하지만, 여전히 공급망입니다.

이 점은 Docker Model Runner의 OCI 레지스트리 클라이언트에서 발견된 SSRF(Server-Side Request Forgery) 수정 사항을 흥미롭게 만듭니다. SSRF는 생소한 것이 아닙니다. 소프트웨어가 사용자를 대신해 URL을 가져오는 방법을 계속해서 학습하기 때문에 계속해서 재발하는 오래된 취약점 클래스 중 하나입니다.

클라우드 서비스에서 SSRF는 메타데이터 엔드포인트(Metadata endpoints), 내부 관리 패널, 그리고 프라이빗 네트워크(Private networks)를 떠올리게 합니다.

개발자 머신에서는 그 형태가 다르지만 해롭지 않은 것은 아닙니다. 로컬 런타임은 내부 레지스트리, VPN 전용 서비스, localhost API, 로컬 자격 증명(Credentials), 모델 캐시, 그리고 프로젝트 파일에 접근할 수 있을지도 모릅니다. 컨테이너로부터 접근 가능할 수도 있습니다. 개발자가 프라이빗 저장소(Private repository)에서 작업하는 동안 에디터 플러그인(Editor plugin)에 의해 호출될 수도 있습니다.

실질적인 질문은 "모델 파일이 악성일 수 있는가?"가 아닙니다.

질문은 "모델 탐색(Model discovery)부터 추론(Inference)에 이르는 전체 경로가 무엇에 닿을 수 있는가?"입니다.

그것이 바로 보안을 강화해야 할 대상입니다.

로컬 API는 장난감 API가 아닙니다

놓치기 쉬운 또 다른 요소는 API 표면(API surface)입니다.

로컬 추론 제품들은 종종 API를 노출하는데, 그것이 생태계가 서로 연결되는 방식이기 때문입니다. 에디터, 에이전트(Agent), 노트북(Notebook), 테스트 하네스(Test harness), 웹 UI, 또는 아주 작은 사이드 프로젝트가 로컬 모델로 요청을 보낼 수 있습니다. OpenAI API 형태와의 호환성은 많은 글루 코드(Glue code)를 제거해주기 때문에 개발자들에게는 축복과도 같습니다.

하지만 로컬 API도 엄연한 API입니다.

Docker의 문서에 따르면 Model Runner API는 인증(Authenticated)되지 않으며, 동일한 Docker 네트워크 상의 다른 컨테이너를 포함하여 해당 API에 접근할 수 있는 모든 클라이언트는 모델을 가져오고(Pull), 로드하고, 실행하며, 추론(Inference) 요청을 보낼 수 있습니다.

이는 로컬 개발 환경에서는 매우 합리적인 기본 설정일 수 있습니다. 모든 노트북의 localhost 앞에 엔터프라이즈급 인증 체계가 필요하다고 주장하려는 것은 아닙니다.

하지만 팀들은 그 트레이드오프(Tradeoff)를 이해해야 합니다.

만약 다른 컨테이너가 모델 API에 접근할 수 있다면, 모델 API는 컨테이너 네트워크의 일부가 됩니다. 만약 코딩 도구가 모델 API에 접근할 수 있다면, 그 도구는 런타임(Runtime)이 할 수 있는 모든 권한을 상속받게 됩니다. 만약 런타임이 모델을 가져오고, 백엔드(Backend)를 로드하며, 기기를 버겁게 만들 정도로 많은 CPU, 메모리 또는 GPU를 소비할 수 있다면, 해당 API는 단순한 채팅 엔드포인트(Endpoint)가 아닙니다.

그것은 로컬 기능 엔드포인트(Local capability endpoint)입니다.

그리고 기능 엔드포인트에는 경계(Boundaries)가 필요합니다.

개발자 머신은 이미 포화 상태입니다

현대의 개발자 머신은 본래 함께 설계되지 않은 수많은 것들로 가득 차 있습니다.

Docker Desktop, 패키지 매니저(Package manager), 언어 런타임(Language runtimes), 클라우드 CLI, 브라우저 세션, SSH 키, 로컬 데이터베이스, Git 자격 증명(Credentials), VPN 클라이언트, AI 코딩 도구, MCP 서버, 에디터 확장 프로그램(Editor extensions), 테스트 컨테이너, 그리고 보통 화요일부터 포트(Port)를 점유한 채 반쯤 잊혀진 어떤 프로세스까지 존재합니다.

로컬 AI는 바로 그 한복판에 자리 잡습니다.

모델(Model), 추론(Inference), 토큰(Tokens), 컨텍스트(Context), 임베딩(Embeddings)과 같이 주변 용어들이 다르기 때문에 로컬 AI를 특별한 카테고리로 분류하고 싶은 유혹이 생길 수 있습니다. 하지만 운영 측면에서 보면 로컬 AI는 또 다른 권한을 가진 개발자 서비스처럼 동작합니다. 아티팩트(Artifacts)를 가져오고, 네이티브 코드(Native code)를 실행하며, API를 노출합니다. 가속 하드웨어(Acceleration hardware)를 사용하고, 에디터 및 에이전트(Agents)와 통합됩니다. 또한 코드가 포함될 수 있는 프롬프트, 로그, 스택 트레이스(Stack traces), 고객 사례, 그리고 인간은 여전히 인간이기에 실수로 붙여넣은 비밀 정보(Secrets) 등을 접하게 됩니다.

이것은 공포에 빠져야 할 이유는 아닙니다.

다만, 이를 인벤토리(Inventory, 자산 목록)에 포함시켜야 할 이유입니다.

어떤 머신에서 로컬 추론 (Inference)을 실행하나요? 어떤 런타임 (Runtime)을 사용하나요? 어떤 버전인가요? 어떤 모델이 허용되나요? 어떤 레지스트리 (Registry)가 신뢰할 수 있는 곳인가요? API가 허용된 곳에만 바인딩 (Bind)되어 있나요? 컨테이너가 여기에 접근할 수 있나요? 어떤 도구들이 이를 호출하나요? 프롬프트 (Prompt)가 로그에 기록되나요? 응답이 로그에 기록되나요? 런타임이 프로젝트 파일을 읽을 수 있나요, 아니면 API를 통해 텍스트만 전달받나요? 보안 권고 (Security Advisory)가 발표되면 누가 백엔드 (Backend)를 업데이트하나요?

이것들은 지루한 질문들입니다.

좋습니다.

지루한 질문들이야말로 플랫폼을 생존 가능하게 만드는 방법입니다.

내가 가장 먼저 할 일

만약 내가 개발자 플랫폼 보안을 책임지고 있다면, 로컬 모델을 금지하는 것부터 시작하지는 않을 것입니다.

그것은 어리석은 일입니다. 개발자들은 어차피 그것들을 사용할 것이고, 어떤 워크플로 (Workflow)에서는 실제로 유용하기 때문입니다.

나는 기본 설정 (Defaults)부터 시작할 것입니다. Docker Desktop, 브라우저, 언어 도구와 동일한 관리 경로를 통해 로컬 AI 런타임을 최신 상태로 유지하십시오. 업무용 머신에 허용되는 모델 소스가 무엇인지 결정하십시오. 가능한 경우 서명되었거나 출처를 확인할 수 있는 아티팩트 (Artifact)를 선호하십시오. 런타임이 실제로 필요한 인터페이스에만 바인딩되도록 하십시오. 인증되지 않은 로컬 API는 컨테이너나 네트워크에 노출해야 할 의도적인 이유가 없는 한 로컬 전용으로 취급하십시오.

그런 다음, 실험과 업무를 분리할 것입니다.

주말 프로토타입을 위해 무작위 모델을 시도하는 개발자가 프로덕션 자격 증명 (Production Credentials)이 포함된 리포지토리 (Repository)에서 작업하는 개발자와 동일한 정책을 적용받아서는 안 됩니다. 개인적인 호기심과 프로덕션에 인접한 엔지니어링은 서로 다른 경로가 필요합니다.

마지막으로, 보이지 않는 것을 보이게 만들 것입니다. 어떤 도구들이 로컬 모델 API를 사용하고 있는지 보여주십시오. 모든 민감한 프롬프트를 영구적으로 저장하지 않으면서도 디버깅할 수 있을 만큼 충분한 메타데이터 (Metadata)를 기록하십시오. 런타임 버전을 추적하십시오. 예상치 못한 네트워크 노출을 감시하십시오. 관리되는 머신에 취약한 추론 백엔드가 존재하는지 쉽게 답변할 수 있도록 만드십시오.

이 중 대부분은 화려하지 않습니다.

그것은 데스크톱 관리, 공급망 위생 (Supply Chain Hygiene), 그리고 API 경계 (API Boundary) 작업입니다.

그리고 그것이 바로 핵심입니다.

결론

로컬 AI가 자동으로 안전하지 않은 것은 아닙니다.

또한 노트북에서 실행된다고 해서 마법처럼 안전한 것도 아닙니다.

Docker Model Runner의 수정 사항이 유용한 이유는 그 추상화된 계층을 잠시나마 가시화해주기 때문입니다. 친숙한 명령어 뒤에는 레지스트리(registries), 백엔드(backends), 샌드박스(sandboxes), API, 네트워크(networks), 캐시(caches), 그리고 개발자 도구 통합(developer-tool integrations)을 갖춘 실제 런타임(runtime)이 존재합니다. 이 런타임은 소스 코드 및 자격 증명(credentials)과 나란히 존재합니다. 따라서 이를 위협 모델(threat model) 밖에 놓인 장난감이 아니라, 엔지니어링 환경의 일부로 취급해야 합니다.

업계는 컨테이너(containers)를 다룰 때도 수년간 이와 같은 실수를 저질렀습니다.

우리는 컨테이너를 가볍고, 이식성이 높으며, 개발자 친화적인 소프트웨어 단위라고 불렀습니다. 모두 사실입니다. 그러다 우리는 컨테이너에 이미지 정책(image policy), 레지스트리 제어(registry controls), 런타임 격리(runtime isolation), 패칭(patching), 스캐닝(scanning), 출처(provenance), 네트워크 경계(network boundaries), 그리고 소유권(ownership)도 필요하다는 사실을 서서히 깨닫게 되었습니다.

로컬 AI 런타임(Local AI runtimes)도 동일한 단계에 진입하고 있습니다.

올바른 대응은 공포가 아니라 성숙함입니다.

도움이 될 때는 로컬 모델을 사용하십시오. 개인정보 보호의 이점을 유지하고, 속도를 즐기십시오. 아주 작은 자동 완성(autocomplete) 실험을 할 때마다 클라우드 API 비용을 지불하는 것을 피하십시오.

하지만 런타임을 지도 위에 올려두어야 합니다.

만약 그것이 아티팩트(artifacts)를 가져오고, 추론 백엔드(inference backends)를 실행하며, API를 노출하고, 컨테이너와 통신하며, 코딩 도구에 연결될 수 있다면, 그것은 이제 당신의 공격 표면(attack surface)의 일부입니다.

사고가 발생하여 최악의 타이밍에 교훈을 얻기 전에, 그렇게 취급하십시오.

references

• Docker Docs: Docker security announcements
• Docker Docs: Docker Model Runner

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작하기 위해 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.