AI는 클라우드에서 로컬 컴퓨팅(Local Compute)으로 이동해야 하지 않을까요?

몇 가지 일들이 거의 동시에 일어났습니다.

GitHub은 Copilot을 사용량 기반 과금(usage-based billing) 방식으로 더 깊게 전환했습니다.

OpenAI는 에이전트(agent) 구축을 위한 기본 프리미티브(primitive)로서 Responses API를 계속해서 밀어붙이고 있습니다.

Anthropic은 Fable/Mythos를 출시했으나, 미국 정부의 지침으로 인해 며칠 후 액세스를 중단해야 했습니다.

NVIDIA는 DGX Spark 및 DGX Station을 통해 "개인용 AI 슈퍼컴퓨터" 하드웨어를 시장에 내놓고 있습니다.

개별적으로 보면, 이 각각의 이야기들은 별개의 뉴스로 취급하기 쉽습니다.

하지만 저는 이것들이 별개가 아니라고 생각합니다.

저는 이 모든 것들이 같은 방향을 가리키고 있다고 생각합니다:

AI 코딩은 클라우드 기능에서 로컬 인프라(local infrastructure)로 이동하고 있습니다.

그리고 이것은 개발자들에게 질문의 성격을 바꿉니다.

단순히:

어떤 에이전트(agent)를 사용해야 할까?

가 아니라:

에이전트가 어디에서 실행되는가?
어떤 모델을 사용할 수 있는가?
런타임(runtime)의 소유주는 누구인가? 그리고 컴퓨팅(compute)의 소유주는 누구인가?
가격 책정, 정책, 모델 액세스 또는 하드웨어가 변경되면 어떻게 되는가?

이 부분이 제가 중요하다고 생각하는 지점입니다.

무슨 일이 일어났나

GitHub은 Copilot이 2026년 6월 1일에 사용량 기반 과금(usage-based billing) 방식으로 전환할 계획이라고 발표했습니다. 기존의 프리미엄 요청 단위 모델은 사용된 모델에 따라 가격이 책정되는 토큰 소비량(입력 토큰, 출력 토큰, 캐시된 토큰)을 기준으로 계산되는 GitHub AI Credits로 대체됩니다. GitHub은 또한 이것이 Copilot이 단순한 에디터 내 어시스턴트에서 리포지토리(repository) 전반에 걸쳐 긴 다단계 코딩 세션을 실행할 수 있는 에이전트 플랫폼(agentic platform)으로 이동했기 때문이라고 밝혔습니다. (The GitHub Blog)

여기에는 중요한 세부 사항이 있습니다. GitHub는 코드 완성 (Code Completions) 및 Next Edit 제안은 그대로 포함되며 AI 크레딧 (AI Credits)을 소비하지 않는다고 밝혔습니다. 따라서 이것은 "모든 고스트 텍스트 (ghost text) 완성이 이제 과금된다"는 의미가 아닙니다. 더 큰 핵심은 에이전트적 사용 (agentic usage), 채팅 (chat), 장시간 실행되는 세션 (long-running sessions), 코드 리뷰 (code review), 그리고 더 무거운 모델 작업이 이제 가시적인 토큰 경제 (token economy)의 일부가 되었다는 점입니다. (The GitHub Blog)

OpenAI는 반대편에서 동일한 방향으로 움직이고 있습니다. Responses API는 Chat Completions 스타일의 단순함과 Assistants API의 도구 사용 (tool use) 기능을 결합하여, 에이전트 (agents) 구축을 위한 새로운 기본 요소 (primitive)로 도입되었습니다. OpenAI는 또한 웹 검색 (web search), 파일 검색 (file search), 컴퓨터 사용 (computer use)과 같은 내장 도구와 트레이싱 (tracing) 및 관측성 (observability)을 갖춘 에이전트 SDK (Agents SDK)를 추가했습니다. (OpenAI)

그 후 OpenAI는 원격 MCP 서버 지원, 코드 인터프리터 (Code Interpreter), 개선된 파일 검색, 장시간 실행되는 작업을 위한 백그라운드 모드 (background mode), 추론 요약 (reasoning summaries), 그리고 암호화된 추론 항목 (encrypted reasoning items)을 통해 Responses를 더욱 확장했습니다. (OpenAI)

이것은 단순히 "새로운 API 기능"이 아닙니다.

이것은 모델 벤더 (model vendors)들이 런타임 (runtime), 도구 (tools), 상태 (state), 관측성 (observability), 그리고 오케스트레이션 (orchestration) 단계로 스택을 높여 올라가고 있다는 것을 의미합니다.

그 후 Anthropic의 Fable/Mythos 이야기가 일어났습니다.

Anthropic은 미국 정부가 외국인 Anthropic 직원들을 포함한 외국인(foreign nationals)의 Fable 5 및 Mythos 5에 대한 접근을 중단하도록 요구하는 수출 통제 지침(export-control directive)을 발행했다고 밝혔습니다. Anthropic은 그 실질적인 결과로 규정 준수(compliance)를 보장하기 위해 모든 고객의 접근을 차단해야 했다고 말했습니다. (Anthropic) The Verge 또한 동일한 기본 내용을 보도했습니다: 국가 안보 우려를 인용한 수출 통제 지침이 외국인에 대한 접근 차단을 요구했고, Anthropic은 모든 고객의 접근을 차단했다는 것입니다. (The Verge)

정책에 대해 논쟁할 수 있습니다. 안전성 문제에 대해 논쟁할 수 있습니다. 정부가 과잉 대응했는지에 대해 논쟁할 수 있습니다.

하지만 개발자로서 얻을 수 있는 실질적인 교훈은 지루합니다:

원격 모델 접근(remote model access)은 안정적인 프리미티브(primitive)가 아닙니다.

가격 때문에 변할 수 있습니다.

정책 때문에 변할 수 있습니다.

지역(region) 때문에 변할 수 있습니다.

제공업체의 리스크 포스처(risk posture) 때문에 변할 수 있습니다.

모델 가용성(model availability) 때문에 변할 수 있습니다.

그렇다고 해서 "프런티어 모델(frontier models)을 절대 사용하지 마라"는 뜻은 아닙니다. 그것은 어리석은 일입니다. 프런티어 모델은 매우 유용합니다.

그것은 런타임 레이어(runtime layer)가 중요하다는 뜻입니다.

이것이 개발자인 우리에게 의미하는 바

지난 2년 동안 많은 AI 툴링(tooling)이 마치 제품의 기능(feature)처럼 판매되었습니다.

확장 프로그램 설치.

로그인.

마법 같은 경험을 얻으세요.

첫 번째 물결(first wave)에서는 그것이 통했습니다.

하지만 진지한 AI 코딩 작업은 더 이상 단순한 UI 기능이 아닙니다. 그것은 하나의 스택(stack)입니다.

모델 선택이 있습니다.

컨텍스트 관리(context management)가 있습니다.

파일 검색이 있습니다.

도구 실행(tool execution)이 있습니다.

셸 접근(shell access)이 있습니다.

정책(policy)이 있습니다.

로그(logs)가 있습니다.

장시간 실행되는 작업(long-running tasks)이 있습니다.

비용(cost)이 있습니다.

속도 제한(rate limits)이 있습니다.

모델별 특이사항(model-specific quirks)이 있습니다.

그리고 소스 코드, 프롬프트(prompts), 도구 결과, 트레이스(traces)가 어디로 가는지에 대한 문제가 있습니다.

그것이 바로 런타임(runtime)의 영역입니다.

불편한 점은 현재 많은 개발자가 저장소(repos)를 조사하고, 파일을 편집하며, 명령어를 실행하고, PR(Pull Requests)을 생성하고, 도구를 호출하며, 때로는 몇 분 또는 몇 시간 동안 실행되는 에이전트(agents)를 사용하고 있다는 사실입니다. 반면 그 아래의 실행 계층(execution layer)은 여전히 블랙박스(black box)처럼 취급되고 있습니다.

실험용으로는 괜찮습니다.

하지만 이것이 기본값이 될 미래로서는 괜찮지 않습니다.

AI 코딩이 일반적인 개발의 일부가 된다면, 개발자와 팀은 런타임(runtime)에 대해 더 많은 제어권(control)을 가져야 합니다.

클라우드(cloud)가 나쁘기 때문이 아닙니다.

제어권 없는 의존성(dependency)은 취약하기 때문입니다.

로컬 컴퓨팅(local compute) 트렌드는 더 이상 밈(meme)이 아닙니다

또 다른 신호는 하드웨어입니다.

NVIDIA DGX Spark는 Grace Blackwell GB10 슈퍼칩, 128GB의 코히어런트 통합 메모리(coherent unified memory), 그리고 최대 1 petaFLOP의 FP4 AI 성능을 갖춘 데스크톱 AI 시스템입니다. NVIDIA는 이 시스템을 통해 데스크톱에서 최대 2,000억 개의 파라미터(parameters)를 가진 모델로 AI 개발 및 테스트 워크로드(workloads)를 실행할 수 있으며, 두 대의 DGX Spark 시스템을 연결하면 최대 4,050억 개의 파라미터 모델까지 지원할 수 있다고 밝혔습니다. (NVIDIA)

DGX Station은 여기서 한 발 더 나아갑니다. NVIDIA는 이를 748GB의 코히어런트 메모리(coherent memory)와 최대 20 petaFLOPS의 AI 연산 성능을 갖추어 최대 1조 개의 파라미터 모델을 지원하는 데스크사이드(deskside) AI 슈퍼컴퓨터로 설명합니다. 또한 NVIDIA는 한 명의 개발자를 위한 전용 AI 슈퍼컴퓨터 또는 팀을 위한 공유 로컬 컴퓨팅 노드(local compute node)로 사용할 수 있는 시스템인 Windows용 DGX Station도 발표했습니다. (NVIDIA) (NVIDIA Newsroom)

물론, 모든 사람이 DGX Station을 구매하지는 않을 것입니다.

그것이 핵심이 아닙니다.

핵심은 나아가고 있는 방향입니다.

한동안 로컬 AI란 "인내심만 있다면 노트북에서 작은 모델을 실행할 수도 있다"는 의미였습니다.

이제 시장은 분명히 더 진지한 로컬/온프레미스(on-prem)/프라이빗 컴퓨팅(private-compute) 계층을 향해 움직이고 있습니다.

• 소규모 모델 및 단순 워크플로우를 위한 노트북 (laptop)
• 본격적인 로컬 개발을 위한 워크스테이션 (workstation)
• 더 무거운 워크로드를 위한 대여형 GPU 박스 (rented GPU box)
• 공유 추론 (shared inference)을 위한 팀 로컬 노드 (team-local node)
• 필요할 때 사용하는 클라우드 프런티어 모델 (cloud frontier model)
• 추후 데이터 센터 또는 클러스터 (data center or cluster)

이는 "모든 유용한 지능이 단일 벤더의 API 뒤에 존재한다"는 세상과는 매우 다른 세상입니다.

그리고 로컬 또는 대여형 컴퓨팅 (compute)이 충분히 강력해지면, 부족한 조각은 단지 모델 실행기 (model runner)만이 아닙니다.

그것은 모델을 둘러싼 런타임 (runtime)입니다.

라우팅 (Routing).

호환성 (Compatibility).

정책 (Policies).

도구 (Tools).

로그 (Logs).

에디터 통합 (Editor integration).

지루한 것들.

사용 가능하게 만드는 것들.

생태계는 이미 형성되고 있습니다

이 지점에서 저는 사람들이 파벌을 나누지 말아야 한다고 생각합니다.

오늘 바로 시작하고 싶다면, 이미 좋은 프로젝트들이 있습니다.

Kilo Code는 VS Code, JetBrains, CLI 및 클라우드 전반에 걸쳐 작동하는 오픈 소스 AI 코딩 에이전트 (AI coding agent)입니다. 다양한 모델을 지원하며, 사용자 본인의 키를 사용하는 방식 (bring-your-own-key), 다양한 에이전트 모드, 자동 완성 (autocomplete), 그리고 완전한 에이전트 기반 코딩 경험을 제공합니다. (Kilo)

OpenCode는 또 다른 중요한 요소입니다. 터미널 인터페이스, 데스크톱 앱 또는 IDE 확장 프로그램으로 사용할 수 있는 오픈 소스 코딩 에이전트입니다. 모델에 구애받지 않으며 (model-agnostic), 명확하게 "개발자 에이전트 (developer agent)" 카테고리에 속합니다. (OpenCode)

Ollama는 아마도 로컬 모델을 위한 가장 쉬운 시작점일 것입니다. 개발자들에게 오픈 모델을 로컬에서 실행하고 관리할 수 있는 간단한 방법을 제공하며, localhost:11434에서 채팅 및 생성을 위한 REST API를 노출합니다. (Ollama) (GitHub)

더 숙련되었거나 팀을 책임지고 있다면, vLLM이 이해해야 할 다음 계층입니다. 이는 고처리량 (high-throughput) 및 메모리 효율적인 추론 및 서빙 엔진 (inference and serving engine)입니다. 문서는 Hugging Face 통합, 스트리밍 출력 (streaming outputs), 도구 호출 (tool calling) 및 추론 파서 (reasoning parsers), 분산 추론 (distributed inference) 기능, 그리고 OpenAI 호환 API 서빙을 강조합니다. (vLLM)

이 대략적인 지도가 중요합니다:

• 단순히 로컬 모델을 실행하고 싶은 경우: Ollama로 시작하세요
• 오픈 소스 코딩 에이전트 (Coding Agent)를 원하는 경우: Kilo Code 또는 OpenCode를 시도해 보세요
• 팀을 위한 본격적인 서빙 (Serving)이 필요한 경우: vLLM을 살펴보세요
• 에디터 네이티브 워크플로 (Editor-native workflows)를 원하는 경우: VS Code/JetBrains/CLI 에이전트 분야를 살펴보세요
• 정책 (Policy), 런타임 (Runtime), 호환성 (Compatibility), 로컬 도구 (Local tools), 그리고 소유한 컴퓨팅 자원 (Owned compute)이 하나의 레이어로 통합되기를 원하는 경우: 이것이 바로 제가 관심을 두고 있는 격차 (Gap)입니다

저는 이 프로젝트들을 적이라고 보지 않습니다.

사실은 그 반대입니다.

이들은 시장을 형성합니다.

이들은 사용자들에게 무엇이 가능한지를 가르쳐 줍니다.

이들은 로컬 모델 (Local models), 오픈 소스 에이전트 (Open-source agents), 모델 라우팅 (Model routing), 셀프 호스팅 (Self-hosting), 그리고 단일 클라우드 제품 외부에서 AI를 실행하는 것을 일반화합니다.

그것이 다음 레이어를 가능하게 만듭니다.

이것이 Contenox에 가져온 변화

이것이 제가 Contenox의 형태를 바꾼 이유이기도 합니다.

한동안 Contenox를 "또 다른 에이전트 런타임 (Agent runtime)" 또는 "로컬 에이전트 프레임워크 (Local agent framework)"라고 설명하기가 너무 쉬웠습니다.

그러한 프레임워크 (Framing)는 너무 협소합니다.

이제 방향이 더 명확해졌습니다:

Contenox는 통제권을 포기하지 않으면서도 최상위 수준의 에이전트 작업을 수행할 수 있는 로컬 우선 (Local-first) AI 런타임이 되어야 합니다.

에이전트는 여전히 중요합니다.

하지만 에이전트는 증명용 워크로드 (Proof workload)일 뿐입니다.

더 깊은 차원의 제품은 그 아래에 있는 런타임 레이어 (Runtime layer)입니다:

• 직접 제어하는 컴퓨팅 자원에서 실행
• 로컬, 대여 또는 제공자 기반 (Provider-backed) 모델 사용
• 기존 도구들이 이해할 수 있는 호환성 인터페이스 (Compatibility surfaces) 노출
• 제공자 및 모델 간의 라우팅 (Route)
• 모델 역량 (Capabilities) 이해
• 도구 (Tools)를 안전하게 실행
• 정책 (Policy) 및 승인 프로세스를 가시적으로 유지
• 발생한 일을 로그 (Log)로 기록
• 에디터 워크플로 (Editor workflows) 지원
• 모든 로컬 실험이 취약한 글루 스크립트 (Glue scripts) 더미로 변하는 것을 방지

이것이 VS Code 확장 프로그램이 중요한 이유이기도 합니다.

VS Code가 제품의 전부이기 때문이 아닙니다.

에디터 AI는 런타임이 즉각적으로 스스로를 증명해야 하는 지점이기 때문입니다.

자동 완성 (Autocomplete)은 빨라야 합니다.

채팅 (Chat)은 스트리밍 (Stream)되어야 합니다.

도구 호출 (Tool calls)에는 승인이 필요합니다.

파일 시스템 및 셸 (Shell) 액세스에는 경계가 필요합니다.

모델/제공자 선택은 이해 가능해야 합니다.

사용자가 로컬/에디터 AI를 사용하기 위해서 브라우저 제어판 전체를 실행하거나 무작위 HTTP 서버를 노출할 필요는 없어야 합니다.

에디터가 바로 압력 테스트 (pressure test)입니다.

만약 런타임 (runtime)이 훌륭한 VS Code 경험을 지원할 수 있다면, 그것은 단순한 CLI 실험 그 이상의 의미를 갖게 됩니다.

목표: 로컬 우선 (local-first), 하지만 제한되지 않음

제가 로컬 우선 (local-first)이라고 말할 때, 그것이 "로컬 전용 (local only)"을 의미하는 것은 아닙니다.

그것은 또 다른 함정이 될 것입니다.

최상급의 로컬 우선 AI 에이전트 (agent)는 다음과 같은 것들을 사용할 수 있어야 합니다:

• 충분할 때는 작은 로컬 모델 (local model)
• 워크스테이션 (workstation)에서의 더 큰 로컬 모델
• 간단한 로컬 모델 관리를 위한 Ollama
• 팀 단위 서빙 (serving)을 위한 vLLM
• 최첨단 성능 (frontier capability)이 적절한 트레이드오프 (tradeoff)가 될 때의 OpenRouter 또는 제공자 API
• 향후 적절한 시점이 되었을 때의 로컬/팀 GPU 박스

핵심은 순수성이 아닙니다.

핵심은 제어 (control)입니다.

모델이 어디에서 실행될지 선택할 수 있어야 합니다.

워크로드 (workload)를 이동할 수 있어야 합니다.

에이전트가 어떤 도구 (tools)를 호출했는지 볼 수 있어야 합니다.

위험한 동작을 승인할 수 있어야 합니다.

로그 (logs)를 유지할 수 있어야 합니다.

전체 워크플로 (workflow)를 다시 작성하지 않고도 하나의 백엔드 (backend)에서 다른 백엔드로 전환할 수 있어야 합니다.

그것이 제가 생각하는 "타협 없는" 부분입니다.

"모든 것이 무료"라는 뜻이 아닙니다.

"로컬 모델이 모든 최첨단 모델을 이긴다"는 뜻도 아닙니다.

"클라우드는 나쁘다"는 뜻도 아닙니다.

제가 원하지 않는 타협은 바로 이것입니다:

훌륭한 AI 코딩 경험을 얻기 위해서, 런타임 (runtime)에 대한 소유권을 포기해야만 한다.

우리는 더 잘할 수 있다고 생각합니다.

결론

최근의 뉴스들은 하나의 이야기가 아닙니다.

Copilot의 미터링 (metering)은 에이전트 기반 코딩 작업에 실제 가변 비용이 발생함을 보여줍니다.

OpenAI의 Responses API는 모델 제공자들이 도구 (tools), 상태 (state), 트레이싱 (tracing), 그리고 오케스트레이션 (orchestration)을 플랫폼 프리미티브 (platform primitives)로 전환하고 있음을 보여줍니다.

Anthropic의 Fable/Mythos가 가져온 파급력은 정책으로 인해 최첨단 성능 (frontier capability)에 대한 접근성이 갑자기 변할 수 있음을 보여줍니다.

NVIDIA의 DGX Spark와 DGX Station은 로컬 및 팀 로컬 AI 컴퓨팅 (compute)이 단순한 취미용 설정을 넘어 진지한 제품 카테고리가 되고 있음을 보여줍니다.