스택이 아닌 런타임(Runtime)을 구축하라

By Krish Garg, Mithilesh Gaurihar

이 포스트에서 다루는 내용

AI 인프라 리스크는 더 이상 이론적인 문제가 아닙니다. 우리가 살펴볼 내용은 다음과 같습니다:

• 미국 정부의 지침으로 인해 Anthropic의 Fable 5가 전 세계 모든 개발자에게 예고 없이 오프라인 상태가 되었습니다.
• GitHub Copilot은 정액제(Flat-rate pricing)를 종료하고 사용량 기반 과금(Usage-based billing) 방식으로 전환하며, AI 코딩 보조금 시대의 막을 조용히 내렸습니다.
• 단일 모델, 도구 또는 가격 플랜에 고정된 모든 팀은 대체 수단(Fallback)이 없었습니다. 대체 수단을 가진 팀들은 그 모든 것 위에 위치한 런타임(Runtime) 레이어를 보유하고 있었습니다.
• 모델 불가지론(Model-agnostic)이 마이그레이션(Migration) 비용이 들지 않는다는 의미는 아닙니다. 재튜닝(Retune)이 필요할 것입니다. 하지만 런타임은 피해 범위를 모든 것이 아닌 단 하나의 레이어로 제한합니다.
• 여러분이 라우팅(Routing)하고 있는 플랫폼들인 OpenAI, Anthropic, Microsoft는 모두 오케스트레이션(Orchestration) 레이어를 직접 흡수하려고 적극적으로 시도하고 있습니다. 진짜 락인(Lock-in) 리스크는 모델이 아니라 바로 이것입니다.
• 정답은 필요로 한 후가 아니라, 필요로 하기 전에 오픈 인프라(Open infrastructure) 위에 런타임을 구축하는 것입니다.

결론: 모델, 도구, 가격 플랜은 모두 하룻밤 사이에 바뀔 수 있습니다. 하지만 그 위에 있는 런타임 레이어는 그럴 필요가 없습니다.

두 개의 헤드라인. 하나의 교훈.

미국 상무부는 금요일 저녁 Anthropic에 서한을 보냈습니다. 자정이 되기 전, Fable 5와 Mythos 5는 전 세계 모든 사용자에게 오프라인 상태가 되었습니다. 외국인뿐만 아니라 모든 사람이 대상이었는데, 이는 Anthropic이 실시간으로 대규모 시민권을 검증할 방법이 없었기 때문입니다. AWS Bedrock, Google Cloud, Microsoft Foundry, 그리고 직접적인 Claude API가 동시에 중단되었습니다. 팀들은 다음 날 아침 아무런 경고 없이 망가진 파이프라인(Pipelines)을 마주하며 깨어났습니다.

Anthropic의 공식 성명 읽기 →

비슷한 시기에 GitHub Copilot은 정액제(Flat-rate pricing)를 종료하고 모든 플랜을 사용량 기반 과금(Usage-based billing) 방식으로 전환했습니다. AI 코딩 보조금 시대는 이메일 한 통과 청구서의 새로운 항목 하나와 함께 끝이 났습니다.

GitHub 공지 읽기 →

그리고 이것이 모델과 과금 방식에만 국한된 문제라고 생각한다면, SpaceX는 규제 당국의 승인을 기다리는 조건으로 Cursor 제작사인 Anysphere를 600억 달러에 인수하기로 합의했습니다. 동일한 패턴, 다른 계층(layer)입니다.

CBS News 보도 읽기 →

서로 다른 기업. 서로 다른 계층. 하지만 동일한 패턴: 빌려 쓰는 땅(rented ground).

왜 이런 일이 계속 발생하는가

대부분의 AI 시스템 엔지니어링은 모델 계층(model layer)에 집중됩니다. 프롬프트 디자인 (Prompt design), 도구 호출 (tool calling), 평가 파이프라인 (eval pipelines), 출력 파싱 (output parsing) 등 모든 것이 특정 모델의 동작에 맞춰 조정됩니다. 해당 모델이 변경되거나, 사라지거나, 가격이 재조정될 때, 그 조정 작업이 이식(portable) 가능한지 여부는 갈립니다. 대부분의 프로덕션 시스템(production systems)에서는 이식되지 않습니다.

이를 이식 가능하게 만드는 계층은 런타임(runtime)입니다. 모델 자체의 상단에 위치하는 모델 라우팅 (model routing), 관측성 (observability), 그리고 비용 추적 (cost tracking)이 그것입니다. 이 계층을 구축한 팀들은 금요일 밤에 선택권을 가졌습니다. 그렇지 못한 팀들은 지원 티켓(support tickets)이 오기만을 기다려야 했습니다.

이것은 새로운 아이디어가 아닙니다. Perplexity의 Aravind Srinivas는 모델이 제품이 아니라고 주장해 왔습니다. Anthropic의 Boris Cherny는 루프 엔지니어링 (loop engineering)에 대해 글을 썼습니다. 에이전트(agents)에게 직접 프롬프트를 주는 것을 멈추고, 그들에게 프롬프트를 주는 루프를 설계하라는 것입니다. 지속 가능한 산출물(durable artifact)은 모델이 아니라 루프입니다.

이 뉴스는 그 사실을 무시하기에는 너무나도 값비싼 대가를 치르게 만들었습니다.

실무에서 모델 불가지론 (model-agnostic)이 실제로 의미하는 것

모델 불가지론적(model-agnostic)인 런타임은 세 가지를 수행해야 합니다. 대부분의 팀은 그 결과에 직면할 때까지 이 세 가지를 모두 건너뜁니다.

1. 모델을 의존성(dependency)이 아닌 설정(configuration)으로 취급하십시오.
프롬프트(Prompts), 도구 정의(tool definitions), 그리고 출력 스키마(output schemas)는 특정 제공자(provider)의 API 형태를 가정해서는 안 됩니다. 프롬프트가 GPT-4의 출력 형식에 맞춰 작성되거나, 도구 호출(tool calling)이 Anthropic의 스키마를 가정하는 순간, 여러분은 유연성으로 위장한 강력한 의존성(hard dependency)을 갖게 됩니다.

2. 전체 실행(run)을 아우르십시오.
런타임(runtime)은 모든 구성 요소, 모든 모델 호출, 모든 핸드오프(handoff)를 단일 트레이스(trace) 내에서 볼 수 있어야 합니다. 여러 모델을 가로질러 라우팅할 때, 실패는 거의 항상 단일 모델 내부에서 발생하지 않습니다. 그것은 모델들 사이의 핸드오프(handoff)에서 발생합니다. 단일 제공자만 다루는 트레이스는 해당 실패에 대해 유용한 정보를 전혀 제공하지 못합니다.

3. 비용을 실시간으로 드러내십시오.
월말의 결제 대시보드가 아니라, 실행(run)이 수행되는 동안에 말입니다. 토큰당 비용을 지불할 때, 워크로드를 비용이 많이 드는 모델에 할당할지 여부에 대한 결정은 할당한 후가 아니라, 할당하기 전에 이루어져야 합니다.

대부분의 팀은 모델 통합(model integration)을 먼저 구축하고 런타임(runtime)을 나중에 구축하기 때문에 이 중 어느 것도 제대로 수행하지 못합니다.

RocketRide가 이를 구현하는 방법

모델은 의존성이 아니라 노드(node)입니다

RocketRide의 파이프라인 빌더(pipeline builder)에서 모델은 프롬프트(prompt)와 출력(output) 사이에 위치하는 컴포넌트 노드(component node)입니다. 채팅(Chat) 소스가 프롬프트 컴포넌트(Prompt component)로 입력되고, LLM 노드에 질문을 전달하며, 하류(downstream)로 답변을 반환합니다. 해당 LLM 노드는 하나의 설정 항목(configuration entry)입니다. 이를 OpenAI, Anthropic, Gemini, Mistral, Qwen 또는 로컬 Ollama 인스턴스로 지정하더라도 파이프라인의 나머지 부분은 정확히 그 자리에 유지됩니다. 연결(connections), 프롬프트 컴포넌트, 출력 핸들러(output handler) 중 어느 것도 변경되지 않습니다. 여러분은 시스템을 다시 쓰는 것이 아니라 하나의 노드를 교체하는 것입니다.

다음은 엔드 투 엔드(end to end)로 실행되는 파이프라인의 모습입니다:

파이프라인을 건드리지 않고도 GPT를 Claude, Gemini, Qwen, Mistral 또는 로컬 Ollama 인스턴스로 교체할 수 있습니다.

모든 실행은 완전히 관찰 가능합니다

파이프라인이 실행될 때, RocketRide는 Design, Status, Tokens, Flow, Trace, Errors의 6가지 뷰를 동시에 스트리밍합니다. 각 뷰는 모든 실행에 대해 집계되는 것이 아니라, 해당 특정 실행(run)에 국한됩니다. Status 탭은 CPU%, CPU Memory, GPU Memory, 그리고 초당 총 완료 횟수(Total Completions per second)를 실시간으로 스트리밍합니다.

CPU, 메모리, 그리고 완료 처리량(completion throughput)은 파이프라인이 실행됨에 따라 실시간으로 스트리밍됩니다. 계정이 아닌 실행(run) 단위로 제한됩니다.

이것은 특정한 이유 때문에 중요합니다. 여러 모델을 가로질러 라우팅할 때, 런타임(runtime)은 이 모든 모델을 볼 수 있는 유일한 장소입니다. 이러한 범위(span)가 없다면, 여러분은 모든 제공업체 경계(provider boundary)를 넘나들며 눈을 가린 채 비행하는 것과 같습니다. 단 하나의 모델만 다루는 트레이스(trace)는 모델 간의 핸드오프(handoff)에서 실패가 발생했을 때 아무런 유용한 정보도 제공하지 못합니다.

비용은 확정하기 전에 드러납니다

Tokens 탭은 각 컴포넌트가 소비한 내역을 파이프라인 전체 합계가 아닌, 컴포넌트별로 상세히 분류하여 보여줍니다: 총 토큰(Total Tokens), CPU 사용량(CPU Usage), CPU 메모리(CPU Memory), 그리고 GPU 메모리(GPU Memory).

Tokens 탭은 컴포넌트별 CPU 사용량, 메모리, 총 토큰을 실시간으로 상세히 보여줍니다. 적절한 계층에서의 비용 가시성(Cost visibility)을 제공합니다.

이러한 컴포넌트별 상세 내역이 비용 결정을 실행 가능하게 만듭니다. 비용이 많이 드는 LLM 노드가 실행되기도 전에 Chat 컴포넌트가 불균형하게 많은 토큰을 소비하고 있는지 확인할 수 있습니다. 더 저렴한 모델이 복잡한 작업에서 잘 버텼는지 평가할 때, 여러분은 월말에 청구서를 기다리는 것이 아니라 이 뷰를 보고 있는 것입니다.

솔직한 부분: 교체는 공짜가 아닙니다

설정 키(config key)를 다시 지정하는 것은 작업의 끝이 아니라 시작일 뿐입니다.

만약 금지된 모델이 여러분의 프롬프트(prompt), 도구 호출 스키마(tool-calling schemas), 그리고 평가 임계값(eval thresholds)을 조정할 때 기준이 되었던 모델이라면, 여러분은 다시 튜닝(retune)을 해야 할 것입니다. 프롬프트 동작은 제공자(provider)마다 다릅니다. 도구 호출 스키마(tool-calling schemas)는 보편적이지 않습니다. 한 모델에서 통과했던 평가(evals)가 다른 모델에서는 실패할 것입니다. 이는 실제적인 노력이 필요한 작업이며, 우리는 이를 부정하지 않을 것입니다.

런타임(runtime)이 제공하는 것은 구조적 위기(architectural crisis) 대신 범위가 한정된 문제(scoped problem)입니다. 파이프라인 구조, Flow 및 Trace 탭을 통한 트레이싱(tracing), Tokens 탭에서의 비용 가시성 등은 모델 노드(model node)를 교체하더라도 전혀 변하지 않습니다. 여러분은 한 계층(layer)을 수정하는 것이지, 모든 것을 다시 구축하는 것이 아닙니다. 정부 지침으로 인해 모델이 갑자기 오프라인 상태가 되어 자정에도 허둥지둥 대처해야 하는 상황이라면, 이 차이는 매우 중요합니다.

경제성 측면에서도 그 노력은 가치가 있습니다. Harvey의 멀티 모델 접근 방식은 일관된 패턴을 보여줍니다. 복잡도가 낮은 단계에는 저렴한 모델을 라우팅(routing)하고, 중요한 단계에는 프리미엄 모델을 사용하는 방식은 단일 고가 모델을 사용하는 것보다 비용은 적게 들면서 성능은 더 뛰어날 수 있습니다. 토큰(token)당 비용을 지불할 때, 그 격차는 모든 에이전트(agent) 실행 과정에서 복리로 쌓입니다. 하지만 이러한 이점은 라우팅과 측정을 수행할 런타임 계층이 존재할 때만 실현됩니다. 런타임이 없다면 비용이 어디로 가고 있는지조차 볼 수 없으며, 최적화는커녕 시작조차 할 수 없습니다.

진지하게 고려할 만한 반론

명백한 반론은 다음과 같습니다:

당신이 라우팅(routing)하는 플랫폼들은 그들 스스로 런타임(runtime)을 흡수하려고 적극적으로 시도하고 있습니다.

그것은 실질적인 위험입니다. 또한 이는 오픈 인프라스트럭처(open infrastructure) 위에서 구축해야 한다는 가장 명확한 근거이기도 합니다. 특정 벤더가 소유한 런타임은 한 단계 위에서 발생하는 '임대된 토지(rented ground)' 문제와 동일합니다. 교체 비용(swap cost)은 낮게 유지되어야 하며, 이는 곧 런타임이 당신을 종속시키는(locked into) 요소가 되어서는 안 된다는 것을 의미합니다. 이것이 바로 RocketRide Server가 오픈 소스(open source)인 이유입니다. 이는 포지셔닝을 위한 결정이 아니라, 아키텍처(architectural) 차원의 결정입니다.

무엇을 해야 하는가

라우팅 로직(routing logic), 트레이싱(tracing), 그리고 비용 할당(cost attribution)은 새로운 엔지니어링이 아닙니다. 어려운 점은 그것이 필요하기 전에 추상화(abstraction)를 구축하는 것입니다. 대부분의 팀은 모델 통합을 먼저 구축하고, 런타임은 나중에 구축하거나 아예 구축하지 않습니다. 하지만 모델이 차단되거나 가격이 재조정될 때, '나중'이란 없습니다.

만약 당신의 루프(loop)가 모델 불가지론적(model-agnostic)이고, 관찰 가능(observable)하며, 오픈 인프라스트럭처 위에 있다면, 다음번의 차단, 인수, 또는 가격 재조정은 아키텍처적 위기가 아닌 운영상의 불편함에 그칠 것입니다.

여기서 시작하세요

• RocketRide Cloud 시도하기 — 모델 불가지론적(model-agnostic) 런타임을 실행하고, 실행되는 동안 모든 컴포넌트의 트레이스(trace)와 토큰 스트림(token stream)을 실시간으로 확인하세요.
• GitHub의 RocketRide Server — 오픈 소스이며 기여에 열려 있습니다. 이 분야에서 작업하고 계신다면, 저희는 여러분과 함께 구축해 나가기를 희망합니다.
• 무료 VS Code 확장 프로그램 다운로드 — 파이프라인 빌더(pipeline builder)와 6가지의 모든 실행 뷰(run views)가 VS Code 내부에서 직접 작동합니다. 무료이며 오픈 소스이고, 시작하는 데 계정이 필요하지 않습니다.