← Back to list

VM 에이전트의 경제학: 더 많은 일을, 더 적은 낭비로

AI 에이전트AI 인프라클라우드추론 효율화

AI 에이전트에게 컴퓨터 한 대를 배정한다는 설명은 직관적입니다. 파일을 보관하고, 브라우저를 열고, 코드를 실행하면서 사용자가 접속하지 않은 동안에도 일을 이어갑니다. 그런데 이 설명을 그대로 인프라 수요에 적용하면 중요한 차이를 놓칩니다. 사용자에게 전용 작업환경을 제공하는 것과, 사용자마다 물리적 컴퓨터와 대형 모델을 계속 점유하게 하는 것은 다른 설계입니다.

2026년 9월 발표된 Meta Muse와 OpenAI Dots는 개인별 클라우드 작업환경에서 문맥과 업무를 이어가는 방향을 보여 줍니다. 다만 제품 발표만으로 이용 규모나 경제성이 입증되는 것은 아닙니다. 지속적인 업무 수행이 가능한 제품이 등장했다는 사실과, 그 업무를 수익성 있게 제공할 수 있다는 판단을 나누어야 합니다. Meta 발표 · OpenAI 발표

호스팅 사업자의 입장에서 보면, 사용자의 로컬 컴퓨터에서 돌아가던 에이전트 실행을 자신이 관리하는 환경으로 옮기는 셈입니다. 여기서 추가적인 선택지가 생깁니다. 개인별 상태는 보존하되 실행 자원을 탄력적으로 배정하고, 모델 호출을 공유 서버로 모으며, 반복되는 작업은 검증된 코드로 바꿀 수 있습니다. 아래 사례를 종합하면, 비용 경쟁은 VM을 저렴하게 제공하는 수준을 넘어 어떤 일에 새 계산을 쓰고, 어떤 일에는 이미 만든 결과를 재사용할 것인가로 확장되고 있습니다.

전용으로 남겨야 하는 것은 컴퓨터 전체가 아닙니다

에이전트 서비스를 설계할 때 세 대상을 분리하면 원가가 선명해집니다. 하나는 목표·파일·기억·권한 같은 개인별 상태입니다. 다른 하나는 브라우저와 코드를 실행하는 CPU·메모리입니다. 마지막은 판단을 수행하는 모델 추론입니다. 이들을 같은 장비에서 처리할 수도 있지만, 반드시 그렇게 구성해야 하는 것은 아닙니다.

여러 사용자의 격리된 실행환경이 공용 추론 서버를 호출하도록 설계할 수 있습니다. 사용자가 업무의 연속성을 느끼는 데 필요한 것은 이전 결과와 권한을 정확히 이어받는 것이지, 매번 같은 물리 CPU를 배정받는 것은 아닙니다. 다만 공유 연산은 개인정보 공유와 다릅니다. 사용자별 문맥과 접근 권한은 분리해야 합니다.

개인별 상태, 탄력적인 실행환경, 공유 추론을 분리한 개념도업무는 이어가되, 자원은 분리해서 배정합니다개인별로 보존목표 · 파일 · 기억 · 작업 이력 · 권한필요에 맞춰 실행격리된 VM · 브라우저 · 코드 실행 · 정지와 복구공유하거나 재사용추론 서버 · 허용된 공통 입력 · 검증된 코드와 절차
필자 구성. 설계 선택지를 설명한 개념도이며, 특정 제품의 내부 구조를 재현한 그림은 아닙니다.

실제 제품에서도 상태와 실행을 분리하는 장치가 등장합니다. E2B는 샌드박스의 메모리와 파일시스템을 저장했다가 재개하는 기능을 제공합니다. 파일시스템만 보존하는 방식도 구분합니다. 정지된 동안 네트워크 연결은 유지되지 않으므로 다시 연결해야 합니다. 상태 복원은 비용을 없애는 마법이 아니라, 실행 자원을 계속 붙잡는 대신 저장·복구 비용과 지연을 선택하는 방식입니다. E2B 공식 문서

AWS AgentCore의 과금 구조는 자원별 차이를 더 명확하게 보여 줍니다. 조회한 공식 문서에서 microVM 방식은 CPU와 메모리를 따로 계산합니다. 외부 API를 기다리며 CPU를 사용하지 않으면 그 CPU 비용은 발생하지 않지만, 메모리는 실행 중 그 시점까지의 최대 소비량을 기준으로 청구됩니다. 이는 고객 과금 방식이며 사업자의 실제 물리 원가 전체를 뜻하지 않습니다. 대기 중 CPU 비용이 없다는 설명을 실행환경 전체가 무료라는 뜻으로 읽으면 안 됩니다. AWS 공식 요금 문서

Always computing은 계속 켜 두는 것보다 넓은 개념입니다

여기서는 Always computing을 사용자가 대화하지 않는 동안에도 위임한 일을 이어가는 것으로, Active computing을 그 목표 안에서 다음에 필요한 일을 선택하는 것으로 구분하겠습니다. 업계의 단일 표준 용어라기보다 발전 방향을 이해하기 위한 구분입니다.

정해진 계산을 밤새 수행하는 프로그램은 지속적이지만 능동적이지 않을 수 있습니다. 반대로 중요한 변화가 생겼을 때만 다음 행동을 선택하는 에이전트는 능동적이면서 간헐적으로 실행될 수 있습니다. 두 경우 모두 가동 시간을 늘리는 것 자체가 목적은 아닙니다.

Cursor는 2026년 3월 Automations를 발표했습니다. 일정이나 Slack·GitHub 등에서 발생한 사건이 에이전트를 호출하면 클라우드 샌드박스를 만들고, 지정한 모델과 도구를 사용합니다. 반복 실행 사이에 기억을 활용하는 기능도 제공합니다. Anthropic이 4월 발표한 Claude Code routines 역시 지시문·저장소·연결 도구를 설정한 뒤 일정·API·GitHub 사건으로 실행합니다. 사용자의 노트북을 켜 둘 필요가 없습니다. Cursor 발표 · Claude 발표

이는 예약된 업무가 클라우드에서 이어지는 제품화 사례입니다. 사람이 정한 범위 안에서 다음 작업을 진행한다는 의미이지, 사용자의 목표나 외부 실행 권한을 제한 없이 정한다는 뜻은 아닙니다.

더 긴 목표를 이어가는 실험도 있습니다. Anthropic은 2026년 2월 16개 에이전트가 공유 코드베이스에서 C 컴파일러를 만드는 실험을 공개했습니다. 작은 과제를 선택하고, 작업 기록과 코드 변경을 남기며, 다음 세션이 이를 이어받았습니다. 반면 큰 병목 하나에 여러 에이전트가 몰리자 같은 문제를 중복 수정하는 상황도 발생했습니다. 지속 실행이 가능해져도 작업 분해와 검증이 나쁘면 병렬 실행이 낭비로 바뀝니다. Anthropic 실험

이때 효율화는 일을 멈추게 하는 데만 있지 않습니다. 가치 있는 미완료 업무가 충분하다면, 절약한 자원을 다른 일에 다시 투입할 수 있습니다. 관건은 에이전트를 얼마나 오래 돌렸는지가 아니라 같은 예산으로 무엇을 더 완수했는지입니다.

Stripe가 보여 준 절감: 생각할 필요가 없는 단계는 코드로 처리합니다

Stripe의 내부 코딩 에이전트 Minions는 지속형 에이전트의 경제성을 살펴보기에 좋은 운영 사례입니다. 2026년 2월 19일 회사는 Minions가 작성한 코드 변경 요청이 매주 1,300건 이상 병합되고 있다고 밝혔습니다. 코드 작성은 에이전트가 수행하지만 사람이 검토합니다. 회사 자체 보고이며, 이 수치만으로 개발 인건비나 결함률이 얼마나 줄었는지는 알 수 없습니다. Stripe 기술 설명

원가 관점에서 중요한 것은 작업 구조입니다. Stripe는 코드로 정의한 흐름인 blueprint 안에 에이전트의 판단과 정형 작업을 섞습니다. 기능 구현과 오류 수정은 에이전트에게 맡기되, 정해진 정적 검사 실행이나 변경 전송 같은 단계에서는 모델을 호출하지 않습니다. 재시도도 제한하고, 해결되지 않는 문제는 사람에게 넘깁니다.

모든 단계에서 모델에게 “다음에 무엇을 할까”를 묻는 대신, 이미 답이 정해진 부분을 일반 코드로 실행하는 것입니다. 이때 절감되는 것은 모델 단가만이 아닙니다. 불필요한 대화와 도구 선택, 예측하기 어려운 분기까지 줄일 수 있습니다. 다만 해당 구조의 전체 비용 절감률은 공개 자료에서 확인하지 못했습니다.

이 방향의 연구적 선례는 2023년 Voyager에서도 보입니다. Minecraft 환경에서 다음 학습 과제를 고르고, 성공한 행동을 실행 가능한 코드로 저장해 재사용했습니다. 게임 실험을 실제 기업 업무의 생산성 증거로 삼을 수는 없지만, 매번 처음부터 추론하는 대신 수행 절차를 축적한다는 설계는 연결됩니다. Voyager 논문

호스팅 사업자가 많은 반복 업무를 처리할수록 검토할 질문도 달라집니다. “어떤 모델이 더 저렴한가”와 함께, 이 단계에서 모델 호출 자체가 필요한지도 물어야 합니다. 공통 절차는 재사용하되, 사용자별 혜택·권한·최신 데이터까지 동일하다고 간주해서는 안 됩니다.

사전 계산은 대기시간을 줄이지만, 총비용은 따로 계산해야 합니다

Active computing의 다른 방향은 사용자가 묻기 전에 필요한 내용을 준비하는 것입니다. 특정 회사나 프로젝트를 계속 다룬다면, 문서의 의미를 매번 처음부터 파악하는 대신 미리 정리해 둘 수 있습니다.

Letta는 2025년 4월 공개한 sleep-time 에이전트에서 대화 담당과 기억 정리 담당을 분리했습니다. 사용자의 대화 뒤에서 다른 에이전트가 문맥을 읽고 기억을 갱신합니다. 서로 다른 모델을 사용할 수 있으며, 기억 정리 빈도를 높이면 토큰 사용도 증가한다고 명시합니다. 여기서 축적되는 것은 주로 외부 기억과 문맥입니다. 개인마다 모델 가중치를 계속 재학습시키는 구조와는 다릅니다. Letta 기술 설명

같은 달 발표된 논문 Sleep-time Compute는 질문이 오기 전에 문맥을 처리하는 방식의 가능성을 평가했습니다. 변형한 수학 벤치마크에서 같은 정확도에 필요한 질문 이후 연산량을 약 5분의 1로 줄였다고 보고했습니다. 논문 원문

질문 이후 연산량 5분의 1은 총비용 80% 절감과 다릅니다. 질문 전에 투입한 계산도 비용입니다. 논문의 별도 비용 비교는 같은 문맥에 여러 질문을 처리하고, 실시간 계산이 사전 계산보다 비싸다는 가정을 둡니다. 재사용 횟수와 상대 단가가 달라지면 경제성도 달라집니다.

투자 검토 자료를 예로 들어 보겠습니다. 한 회사의 계약과 재무 자료를 미리 정리해 열 번의 후속 질문에 활용한다면 준비 비용을 나눌 수 있습니다. 반대로 사용자가 묻지 않거나, 질문 전에 계약이 바뀌어 준비 결과를 폐기해야 한다면 비용을 회수하지 못합니다. 이는 논문 결과를 업무에 적용한 예시이며, 해당 업무에서 측정한 실증 수치는 아닙니다.

또 하나의 구분이 필요합니다. 사용자가 쉬는 시간과 호스팅 사업자의 GPU가 비는 시간은 같지 않습니다. 사용자가 접속하지 않을 때도 다른 고객의 작업이 있을 수 있습니다. 사전 계산의 장점은 실행 기한을 유연하게 선택할 수 있다는 데 있지, 연산이 자동으로 공짜가 된다는 데 있지 않습니다.

같은 문맥을 재사용하고, 업무 전체의 대기를 줄입니다

사전 계산과 추론 캐싱은 관련이 있지만 같은 기능은 아닙니다. 전자는 나중에 쓸 내용을 미리 준비하는 것이고, 후자는 이미 수행한 입력 처리의 중간 결과를 다시 사용하는 것입니다.

vLLM의 자동 프리픽스 캐싱은 동일한 입력 앞부분을 처리하며 만든 주의집중 계산의 중간값인 KV 캐시를 재사용합니다. 긴 문서에 여러 질문을 하거나 공통 문맥이 반복될 때 입력 처리 비용을 줄일 수 있습니다. 그러나 새 답변의 토큰을 생성하는 작업까지 없애지는 않습니다. 공식 문서도 입력 처리 단계의 개선과 출력 생성 단계를 구분합니다. vLLM 공식 문서

재사용의 대상을 나누면 서로 다른 효율화가 보입니다.

재사용하는 것 줄이려는 반복 작업 남는 비용과 제약
VM의 파일·메모리 상태 환경을 처음부터 준비하는 작업 상태 저장·복구, 연결 재설정
정리된 기억과 사전 분석 같은 문맥을 다시 파악하는 작업 준비 비용, 자료 갱신, 미사용 결과
추론의 입력 KV 캐시 같은 입력을 다시 계산하는 작업 캐시 메모리, 새 출력 생성
검증된 코드와 절차 이미 해결한 행동을 다시 추론하는 작업 실행 비용, 환경 변화 감지, 예외 처리

이 표는 앞선 제품과 연구를 바탕으로 구성한 비교입니다. 캐시가 있다는 이유만으로 개인별 문맥을 사용자 간에 섞어도 되는 것은 아닙니다. 공유 가능한 입력과 비공개 데이터를 구분하고, 권한에 맞는 격리 범위를 유지해야 합니다.

다수의 에이전트를 함께 운영하면 작업 순서를 조정할 여지도 생깁니다. 2025년 논문 Autellix는 모델 호출 하나보다 여러 호출로 구성된 프로그램의 진행 상태를 보고 자원을 배정합니다. 작업 간 의존성과 이미 진행된 과정을 활용해 대기를 줄이며, 실험한 환경에서 같은 지연시간을 유지할 때 프로그램 처리량을 4~15배 개선했다고 보고했습니다. Autellix 논문

이 역시 개별 모델의 토큰 생성속도가 모든 상황에서 4~15배 빨라졌다는 뜻은 아닙니다. 특정 작업과 비교 시스템에서 얻은 프로그램 단위 결과입니다. 다만 호스팅 사업자가 업무의 진행 상황까지 알면, 개별 API 요청만 보는 시스템보다 더 많은 자원 배정 선택지를 가질 수 있다는 점은 중요합니다.

모델과 업무를 함께 통제하는 사업자는 이런 최적화를 적용할 범위가 넓습니다. 반대로 VM만 제공하고 외부 모델 API를 그대로 사용하는 사업자는 GPU 내부의 추론 효율을 직접 바꾸기 어렵습니다. 효율화가 가능하다는 사실과 그 이익을 어느 사업자가 가져가는지는 별개의 질문입니다.

계산을 써서, 앞으로 필요한 계산을 줄일 수 있습니다

Google DeepMind의 AlphaEvolve는 한 단계 더 나아간 사례입니다. 모델이 알고리즘 후보를 만들면 자동 평가기가 이를 실행하고 성능을 검증합니다. 좋은 후보를 다음 탐색에 활용해 개선을 이어갑니다. AlphaEvolve 발표

2025년 5월 Google은 AlphaEvolve가 발견한 데이터센터 자원 배치 알고리즘을 실제 운영에 적용했고, 전 세계 연산 자원의 평균 0.7%를 회수한다고 보고했습니다. 회사 자체 측정이며, 연구와 배포 비용까지 차감한 순수익률을 뜻하지는 않습니다.

주목할 점은 운영 중 매 순간 LLM이 모든 자원 배치를 새로 판단하는 방식이 아니라는 것입니다. 비싼 탐색으로 알고리즘을 발견한 뒤, 검증된 코드를 반복 실행합니다. 한 번의 고비용 탐색이 앞으로 수많은 작업의 저비용 실행으로 이어지는 구조입니다.

고비용 탐색 결과를 검증된 절차로 바꾸어 반복 실행하는 과정매번 다시 생각하지 않도록, 한 번 제대로 찾습니다1. 탐색하고 발견모델이 후보를 만들고 비교2. 실행해서 검증테스트 · 품질 · 비용 확인3. 절차로 저장재사용 가능한 코드와 규칙4. 반복해서 실행달라진 부분과 예외만 재판단필자 구성 · 탐색 비용을 이후의 반복 작업에 나누는 설계
좋은 결과를 실행 가능한 절차로 남길수록, 다음 업무가 같은 추론을 반복할 필요가 줄어듭니다. 절차의 유효성 검증은 계속 필요합니다.

AlphaEvolve의 성과를 모든 에이전트 서비스로 일반화할 수는 없습니다. 알고리즘의 실행시간이나 정확도를 자동으로 평가할 수 있다는 조건이 중요합니다. 투자·협상처럼 정답이 늦게 드러나는 업무에서는 코드 테스트와 같은 검증 장치를 만들기 어렵습니다. 무인 실행 시간을 늘리기 전에 무엇을 성공으로 인정할지부터 정해야 합니다.

많이 생각했지만, 쓸모없는 결과를 만들 수도 있습니다

2026년 논문 ProAct는 사전 계산의 반대편을 보여 줍니다. 합성한 200개 상황에서 방향 없이 미리 조사하는 방식은 상황당 약 6만 9,800개의 추가 능동 연산 토큰을 사용하고도, 필수 내용을 모두 충족하기까지 대화 턴을 약 0.9% 줄이는 데 그쳤습니다. 다음 필요를 예측한 방식은 약 11만 1,800개의 추가 토큰을 사용했고, 해당 턴 수를 약 14.8% 줄였습니다. ProAct 논문

이 수치는 일반 응답·사용자 시뮬레이션·평가용 토큰을 제외한 추가 연산입니다. 대화 턴 감소도 실제 근무시간 절감과 같지 않습니다. 합성 환경과 모델 평가에 기반한 결과이므로, 총비용 절감이나 실제 고객 생산성의 증거로 읽어서는 안 됩니다.

그럼에도 실무에 던지는 질문은 분명합니다. 사용자가 요구하지 않은 분석을 계속 만드는 것만으로는 가치가 생기지 않습니다. 사전 계산의 품질은 무엇을 만들었는지뿐 아니라, 준비한 결과가 실제로 사용됐는지로 평가해야 합니다.

이미 끝난 프로젝트를 조사하거나, 변경된 지시를 반영하지 못하거나, 같은 근거를 반복 검토하면 지속 실행이 낭비가 됩니다. 중단·취소·예산 제한은 자율성을 방해하는 부속 장치가 아니라 원가 관리의 일부입니다. 중요한 외부 실행에는 별도의 승인 경계도 필요합니다.

수요 증가와 효율화는 동시에 일어날 수 있습니다

개별 업무가 저렴해지면 지금은 비용 때문에 맡기지 않는 일까지 에이전트에 위임할 수 있습니다. 반대로 추가 업무의 가치가 낮다면 비용 절감은 전체 지출 감소로 끝날 수 있습니다. 어느 쪽인지는 기술만 보고 확정할 수 없습니다.

이를 판단하기 위한 단순한 분해는 다음과 같습니다.

전체 연산 수요 = 활성 사용자 수 × 사용자당 수행 업무 수 × 업무당 평균 연산량

설명용 가정으로 사용자 수가 같고, 업무당 연산량이 5분의 1로 줄어도 수행 업무가 10배 늘면 전체 연산량은 2배가 됩니다. 업무량이 늘지 않으면 전체 연산량도 5분의 1로 줄어듭니다. 실제 연산 수요 전망이 아니라, 효율 개선만으로 수요 방향을 정할 수 없다는 산식입니다.

인프라별 영향도 같지 않습니다. CPU의 실제 실행시간, 상태를 유지하는 메모리, 모델 추론에 쓰이는 GPU, 로그와 파일을 보관하는 저장장치는 다른 변수에 반응합니다. 따라서 VM 에이전트 수를 물리 서버 수나 GPU 수에 그대로 곱하면 안 됩니다. 동시에 업무당 추론량이 줄었다고 저장 데이터까지 같은 비율로 줄어든다고 가정해서도 안 됩니다.

앞선 글에서는 에이전트가 남기는 데이터와 저장 수요를 다뤘습니다. 여기서 보태야 할 것은 효율화입니다. 에이전트가 더 많은 일을 하면서도 같은 문맥을 덜 읽고, 같은 절차를 덜 추론하며, 실행 자원을 더 잘 공유할 수 있습니다. 수요와 효율 중 한쪽만 강조하면 사업의 실제 원가를 놓칩니다.

VC가 확인해야 할 것은 가동률보다 완료 단가입니다

투자 검토에서는 “에이전트가 하루 종일 일한다”는 데모를 다음 질문으로 바꿀 필요가 있습니다. 업무 하나가 수락되기까지 비용이 얼마나 들고, 다음번 같은 업무에서는 그 비용이 실제로 내려가는가.

제가 비교 지표로 삼고 싶은 것은 검증된 업무당 총원가입니다. 측정 기간의 실제 추론비·실행환경비·저장 및 도구비에 사람의 검토비를 더하고, 수락된 업무 수로 나눕니다. 실패와 재시도에 쓴 자원도 분자에 포함하되 같은 비용을 별도로 중복 가산하지 않습니다. 사람의 검토시간은 동일한 기준으로 금액을 환산해야 합니다.

능동형 서비스에는 준비 결과의 실제 사용률과 폐기율도 필요합니다. 원가가 낮아져도 사용자가 검토해야 하는 결과가 급증하면 부담을 다른 곳으로 옮긴 것일 수 있습니다. 정확도와 완료시간, 검토시간을 함께 봐야 합니다.

호스팅·실행환경 기업에는 상태 복원과 격리 이후의 원가를 묻겠습니다. 에이전트 서비스 기업에는 불필요한 작업을 얼마나 줄이고, 익숙한 업무를 얼마나 검증된 절차로 바꾸는지 묻겠습니다. 모델 서빙 기업에는 토큰 생성속도뿐 아니라 여러 호출로 구성된 업무 전체를 얼마나 효율적으로 끝내는지 묻겠습니다. 이는 앞선 사례에서 도출한 평가 기준이지, 특정 회사의 우위를 확정한 결론은 아닙니다.

에이전트의 활동은 늘어날 수 있습니다. 같은 일을 반복해서 생각하는 비용까지 함께 늘어야 하는 것은 아닙니다. 지속적으로 맡길 가치가 있는 일을 찾고, 반복 가능한 결과는 코드와 기억으로 남기고, 필요 없어진 작업은 멈추는 능력. VM 에이전트의 확산을 사업의 이익으로 바꾸려면 이 세 가지가 실제 운영 원가에 나타나야 합니다.


자료와 해석 범위

자료 확인 기준일은 2026년 10월 3일입니다. 제품 기능은 공식 발표와 문서를, 운영 성과는 회사 자체 보고를, 연구 성과는 해당 논문의 평가 조건을 기준으로 서술했습니다. 발표 당시 수치를 현재의 이용 규모로 바꾸어 해석하지 않았습니다. 제품별 기능은 요금제와 출시 단계에 따라 달라질 수 있습니다.

Sleep-time Compute의 질문 이후 연산량, Autellix의 프로그램 처리량, AlphaEvolve의 운영 자원 회수율은 서로 다른 지표입니다. 이 수치들을 곱해 하나의 비용 절감률로 환산할 수 없습니다. 산업 수요와 사업 경쟁력에 관한 문장은 위 자료를 바탕으로 한 필자의 해석입니다.

VM 에이전트의 경제학: 더 많은 일을, 더 적은 낭비로