연산은 흘러가고, 상태는 남는다: 위임형 에이전트의 인프라
“이 문서를 요약해 주세요”와 “다음 달까지 납기 지연을 줄여 주세요”는 다른 종류의 주문입니다.
첫 번째 주문은 답변을 반환하면 끝납니다. 두 번째 주문은 공급업체의 회신을 기다리고, 재고와 발주 현황을 다시 확인하고, 조건이 바뀌면 계획을 수정해야 합니다. 이미 누구에게 연락했는지, 어떤 결정을 승인받았는지, 언제 사람에게 도움을 요청해야 하는지도 기억해야 합니다. 사용자가 대화창을 닫았다고 업무가 사라지지는 않습니다.
위임형 에이전트의 확산에서 제가 주목하는 변화는 여기에 있습니다. 사람이 질문할 때마다 답하는 컴퓨팅에서, 맡겨진 목적을 일정 기간 유지하는 컴퓨팅으로의 전환입니다.
저는 이를 ‘목적지향형 상시 컴퓨팅’이라고 부릅니다. 업계의 표준 용어가 아니라, 앞으로의 인프라를 바라보는 제 관점입니다. 여기서 상시라는 말은 GPU를 쉬지 않고 돌린다는 뜻이 아닙니다. 목표와 책임 범위는 이어지되, 실제 연산은 필요한 때와 장소에서 수행된다는 뜻입니다.
위임형 에이전트가 확산되면 인프라의 기본 단위는 개별 모델 호출에서 목표·권한·예산·기한을 가진 지속적인 업무로 이동합니다. 연산은 판단의 난도와 응답 기한에 따라 코드·특화 모델·대형 모델로 분업됩니다. 그 과정에서 선택되고 검증된 상태와 지식은 개별 연산보다 오래 남으며, 이를 저장·갱신·이동·재사용하는 능력이 중요해집니다.
다만 여기서 곧바로 “모든 반도체와 스토리지의 수요가 폭증한다”는 결론으로 넘어가서는 안 됩니다. 업무가 늘어나는 것, 물리적 자원이 더 필요한 것, 공급자가 더 많은 이익을 얻는 것은 각각 다른 명제입니다.
이 글은 2026년 10월 5일까지 확인한 공개 기술 문서와 연구를 바탕으로 한 투자 관점입니다. 제품의 구현 가능성과 실제 도입 규모, 연구 결과와 상용 서비스의 경제성을 구분합니다.
질문을 파는 시장에서, 일을 맡기는 시장으로
모델 API를 사용하는 개발자는 어떤 입력을 보낼지, 결과를 어디에 연결할지 직접 설계합니다. 반면 위임형 제품을 사용하는 사람은 끝내고 싶은 일을 말합니다. 문서 수집, 계산, 도구 연결, 중간 결과 보관 같은 절차는 제품 안으로 들어갑니다.
제 수요 가설은 이 차이에서 출발합니다. 사용자가 컴퓨팅의 사용법을 자세히 알지 못해도 일을 맡길 수 있다면, 접근 가능한 수요가 개발자의 API 호출에서 비개발자의 반복적인 사무·생활 업무로 넓어질 수 있습니다. 그러나 가입자가 늘었다는 사실만으로 이 전환이 입증되지는 않습니다. 시간이 지나도 계속 맡기는 일이 있고, 그 결과에 다시 비용을 지불하는지가 중요합니다.
제품의 원가 단위도 달라져야 합니다. 답변 하나가 저렴하더라도, 그 답변을 실제 업무에 적용하는 과정에서 오류 수정과 사람의 확인이 반복되면 싼 서비스가 아닙니다. 반대로 비싼 모델을 일부 사용하더라도 전체 작업을 안정적으로 끝낸다면 경제적일 수 있습니다.
따라서 제가 보고 싶은 지표는 토큰당 가격만이 아닙니다. 같은 품질과 권한 기준을 만족하는 검증된 업무 한 건당 총비용입니다. 모델 호출, 코드 실행, 데이터 접근, 저장, 재시도, 사람의 검토까지 포함한 비용입니다.
계속 유지해야 하는 것은 실행 자원이 아니라 업무의 연속성입니다
상시 컴퓨팅을 개인마다 가상머신 한 대를 계속 켜 두는 구조로 상상하면 수요를 과대평가하기 쉽습니다.
사용자에게 필요한 것은 어제와 같은 물리 CPU가 아닙니다. 어제 처리한 일과 남은 일을 구분하고, 승인받지 않은 일을 실행하지 않으며, 멈췄던 지점에서 올바르게 다시 시작하는 능력입니다. 실행 자원은 공유하거나 회수할 수 있지만, 업무의 상태와 권한은 보존되어야 합니다.
E2B의 공식 문서는 샌드박스를 정지할 때 파일시스템과 메모리 상태를 저장했다가 재개하는 기능을 설명합니다. 파일시스템만 보존하고 다시 시작하는 방식도 제공합니다. 정지 중에는 네트워크 연결이 유지되지 않으므로 복구 과정이 필요합니다. 이는 업무의 연속성과 연산 자원의 연속 점유가 분리될 수 있다는 구현 사례입니다. 저장된 메모리 스냅샷을 그 시간 내내 점유하는 물리 DRAM으로 계산해서는 안 됩니다. E2B 공식 문서
AWS AgentCore의 공식 요금 문서도 CPU, 메모리, 저장, 데이터 전송을 구분합니다. 조회 시점의 Runtime v2는 외부 응답을 기다리는 동안 CPU를 사용하지 않을 수 있고, 유휴 메모리를 회수하는 구조를 설명합니다. 다만 고객에게 청구하는 방식이 사업자의 물리적 원가 전체를 보여 주는 것은 아닙니다. AWS 공식 요금 문서
장기간 실행되는 업무 흐름이나 예약 작업 자체가 새로 발명되는 것은 아닙니다. 제가 보는 변화는 기존 실행 인프라 위에 자연어로 받은 목표를 분해하고, 상황에 따라 다음 행동을 선택하는 능력이 결합하는 것입니다.
그 목표에는 경계도 필요합니다. 얼마까지 쓸 수 있는지, 언제까지 처리해야 하는지, 무엇을 성공으로 볼지, 어떤 행동은 승인받아야 하는지, 언제 중단해야 하는지가 함께 저장되어야 합니다. 계속 일할 수 있는 능력만큼, 더 일하지 않아야 할 때를 아는 능력도 인프라의 일부가 됩니다.
실시간 응답과 기한이 있는 업무는 서로 다른 자원을 요구합니다
위임된 업무의 모든 단계가 즉시 끝날 필요는 없습니다. 반대로 사용자에게 결과를 전달하거나 중요한 거래를 확정하는 순간까지 무조건 배치로 미룰 수도 없습니다.
저는 실행을 다음처럼 구분합니다. 특정 회사의 내부 구조를 재현한 것이 아니라, 업무의 시간 제약을 기준으로 한 설계 구분입니다.
| 실행 형태 | 업무의 예 | 자원 배정에서 중요한 것 |
|---|---|---|
| 사용자가 기다리는 실시간 실행 | 질문의 의도 확인, 승인 직전 설명, 진행 중 오류 대응 | 응답 지연, 최악에 가까운 지연의 관리, 즉시 사용할 수 있는 자원 |
| 사건이 발생하면 시작하는 실행 | 회신 도착, 가격 변경, 새로운 문서 등록 후 후속 처리 | 중복 실행 방지, 상태 복구, 연결 서비스의 호출 제한 |
| 마감 시간 안에 끝내는 배치 실행 | 야간 대사, 자료 정제, 정기 보고서, 대규모 평가 | 처리량, 작업 묶음의 크기, 유휴 자원 활용, 완료 기한 |
| 나중을 위해 미리 하는 준비 | 자주 쓸 자료의 정리, 예상 질문 준비, 재사용 가능한 절차 구축 | 실제 재사용률, 정보의 유효기간, 준비 비용과 낭비 |
특히 마지막 행은 앞선 행들과 경제성이 다릅니다. 반드시 필요한 보고서를 밤에 만드는 것과, 사용될지 모르는 보고서를 미리 만드는 것은 같지 않습니다.
‘Sleep-time Compute’ 연구는 질문이 들어오기 전에 문맥을 처리해 두는 접근을 실험합니다. 이는 준비 작업을 별도의 시간대로 옮길 수 있음을 보여 주지만, 연구의 성과를 모든 기업 업무에 적용할 수는 없습니다. Sleep-time Compute 논문
제 판단 기준은 단순합니다. 사전 작업이 실제로 쓰일 확률과 그때 절약하는 비용이, 준비·저장·갱신 비용을 넘어야 합니다. 밤새 계산했다는 사실보다 다음 날 그 결과가 얼마나 쓰였는지가 중요합니다. 사용되지 않는 준비를 늘리는 것은 지능의 축적이 아니라 재고의 과잉 생산일 수 있습니다.
반복 업무의 효율화는 모델을 작게 만드는 데서 끝나지 않습니다
모든 단계를 대형 언어모델에게 맡길 이유는 없습니다. 그러나 모든 단계를 작은 모델로 바꿔야 하는 것도 아닙니다.
입력 형식과 처리 규칙이 정해져 있다면 일반 코드가 먼저입니다. 파일명을 바꾸거나, 숫자를 대사하거나, 정해진 검사 도구를 실행하는 일을 매번 언어모델이 다시 판단할 필요는 없습니다. 분류나 추출처럼 어느 정도의 확률적 판단이 필요하지만 범위가 좁다면 특화된 경량 모델이 후보가 됩니다. 새로운 목표의 해석, 복잡한 예외, 서로 충돌하는 제약의 조정에는 더 강한 모델이 필요할 수 있습니다.
Stripe의 내부 코딩 에이전트 Minions는 이런 결합을 실제 운영 구조로 설명합니다. 코드로 정의한 업무 흐름 안에서 구현과 오류 수정은 에이전트가 수행하고, 정해진 검사나 변경 전송은 결정론적 단계가 처리합니다. 회사가 공개한 설계 설명이지, 이 구조가 모든 업무에서 같은 비용 절감률을 낸다는 독립 검증은 아닙니다. Stripe의 Minions 설명
소형 언어모델의 역할을 주장한 NVIDIA·Georgia Tech 연구진의 논문도 범위가 제한된 반복 업무와 여러 크기의 모델을 결합하는 방향을 제시합니다. 다만 이는 방향성을 제안하는 논문이며, 대형 모델이 대부분의 상용 업무에서 이미 대체됐다는 증거가 아닙니다. Small Language Models are the Future of Agentic AI
여기서 결정론적 코드와 경량 모델을 같은 것으로 취급하면 안 됩니다. 작은 모델도 틀릴 수 있으며, 출력과 품질을 검사해야 합니다. 또한 CPU에서 실행하는 작은 모델이 잘 묶어서 처리하는 GPU 서비스보다 언제나 저렴한 것도 아닙니다. 비교 대상은 모델의 크기가 아니라, 실제 이용률과 오류 대응을 포함한 업무의 총원가입니다.
제가 기대하는 발전은 성공한 업무 수행 기록이 다음 실행의 절차로 바뀌는 것입니다. 처음에는 대형 모델이 탐색하던 경로에서 반복되는 부분을 찾아 코드, 검사 규칙, 특화 모델로 고정합니다. 예외는 다시 강한 모델이나 사람에게 넘깁니다.
전문 에이전트의 우위도 여기에 생길 수 있습니다. 같은 도메인의 업무를 반복하면서 합법적으로 확보한 정보, 검증된 절차, 실패 사례와 예외 처리 방식이 누적된다면, 범용 에이전트가 매번 처음부터 풀어야 하는 일을 더 적은 탐색으로 끝낼 수 있습니다. 단, 모델의 출력 기록이 쌓였다고 이런 우위가 자동으로 만들어지지는 않습니다. 재사용 전에 평가하고, 환경이 바뀌면 절차를 다시 검증해야 합니다.
GPU 밖에서 해야 할 일이 더 선명해집니다
에이전트의 업무를 모델 호출로만 세면, 그 앞뒤에서 처리되는 일을 놓칩니다.
납기 지연을 줄이는 에이전트는 문서의 의미를 이해하는 것 외에도 주문 데이터를 읽고, 거래처를 맞추고, 날짜와 수량을 계산하고, 변경 이력을 남겨야 합니다. 모든 원본을 모델에 넣는 대신 필요한 행을 조회하고, 코드를 실행해 결과를 좁힌 다음 판단을 요청하는 편이 적합한 단계가 있습니다.
Anthropic의 MCP 코드 실행 설명은 도구에서 가져온 데이터를 실행 환경 안에서 처리하고, 필요한 결과만 모델에 전달하는 패턴을 보여 줍니다. 모델에 들어가는 중간 데이터를 줄이는 대신 실행 환경과 그 보안·운영이 중요해지는 구조입니다. Anthropic의 MCP 코드 실행 설명
이는 AI 연산이 줄어들면 일반 컴퓨팅도 함께 줄어든다는 단순한 관계가 성립하지 않을 수 있음을 뜻합니다. 모델이 하던 일부 절차가 CPU와 데이터 처리 시스템으로 옮겨갈 수 있고, 저렴해진 업무가 더 많이 수행될 수도 있습니다. 다만 둘 다 조건부입니다. 처리 효율이 높아지고 여러 작업이 자원을 공유하면, 업무량만큼 CPU 대수가 늘어나지는 않습니다.
모델 추론 내부에서도 분업이 있습니다. Splitwise 연구는 입력을 처리하는 단계와 토큰을 생성하는 단계의 서로 다른 자원 특성을 활용해 실행을 분리합니다. 분리의 이익은 상태를 옮기는 비용과 함께 평가해야 합니다. Splitwise 논문
이것은 업무를 실시간과 배치로 나누는 것과 다른 축입니다. 배치 작업도 대형 GPU를 사용할 수 있고, 실시간 작업도 코드와 작은 모델로 처리할 수 있습니다. 언제 끝내야 하는지와 어떤 계산이 필요한지를 따로 판단해야, 이종 컴퓨팅의 수요가 보입니다.
컨텍스트가 늘어난다는 말에는 서로 다른 종류의 기억이 섞여 있습니다
“연산은 효율화되지만 컨텍스트와 지식은 누적된다”는 것이 제 테시스의 중심입니다. 이 문장을 투자에 사용하려면 무엇이 어디에 남는지 구분해야 합니다.
현재 계산 중인 정보, 다시 이어갈 업무 상태, 검증된 지식, 원본과 감사 기록은 수명도 접근 방식도 다릅니다. 아래 표의 저장 위치는 대표적인 설계 선택지이지, 모든 서비스의 고정된 구성은 아닙니다.
| 남겨야 하는 것 | 대표적인 내용과 성격 | 연결되는 자원·기능 |
|---|---|---|
| 현재 추론과 가까운 작업 정보 | 입력 토큰에서 계산한 KV 캐시, 즉시 사용하는 문맥 | HBM·DRAM, 필요에 따른 외부 캐시 계층, 빠른 전송 |
| 다시 이어갈 업무 상태 | 완료 단계, 미완료 과제, 체크포인트, 승인과 권한 | 데이터베이스, DRAM·SSD, 일관성 있는 기록과 복구 |
| 재사용할 지식과 절차 | 출처가 있는 사실, 사용자 선호, 검증된 코드, 도메인별 수행 방법 | 파일·데이터베이스·검색 색인, 갱신·버전·접근권한 관리 |
| 원본과 증빙 | 문서·영상·산출물·실행 로그·감사 기록 | 객체·파일 저장, 접근 빈도에 따른 SSD·HDD 등 저장 계층 |
모델 가중치는 이 표와 별도로 봐야 합니다. 여러 사용자가 같은 모델을 공유할 수 있으므로, 에이전트 수만큼 전체 모델을 새로 보관한다고 가정할 수 없습니다. 객체 저장 서비스에 저장된 데이터가 모두 특정 종류의 디스크에 들어간다고 단정할 수도 없습니다.
KV 캐시도 장기 지식과는 다릅니다. 이전 입력의 계산을 재사용하기 위한 중간 상태이지, 검증된 사실을 관리하는 지식베이스가 아닙니다. vLLM의 자동 접두부 캐싱은 같은 접두부의 계산을 다시 하지 않도록 돕지만, 생성 단계 자체를 빠르게 하는 기능은 아니며 공유할 접두부가 없다면 이점이 제한됩니다. vLLM 공식 문서
따라서 장기 기억이 늘어난다고 그 전체가 매 순간 GPU의 HBM에 올라가야 하는 것은 아닙니다. 반대로 SSD에 보관할 수 있다는 이유만으로, 빠른 추론에 필요한 HBM을 모두 대체할 수 있는 것도 아닙니다. 검색·전송·재계산의 지연을 감당할 수 있는지가 계층을 나누는 기준이 됩니다.
Anthropic의 문맥 설계 설명도 모든 자료를 항상 입력에 넣는 대신, 필요할 때 자료를 찾고 문맥을 압축하며 장기 작업의 메모를 별도로 보관하는 접근을 다룹니다. 보존할 정보의 범위와, 지금 추론에 투입할 정보의 범위는 같지 않습니다. Anthropic의 문맥 설계 설명
이 구분에서 한 걸음 더 나아가면, 제가 말하는 메모리 중심 컴퓨팅은 단순히 메모리 반도체를 많이 장착한 컴퓨터가 아닙니다. 어떤 정보가 유효한지, 누가 접근할 수 있는지, 어디에 두고 언제 가져올지를 중심으로 연산을 배치하는 시스템입니다.
저장된 기록이 지식이 되려면 잊는 기능도 필요합니다
회의록이 쌓이는 것과 조직이 학습하는 것은 다릅니다. 에이전트도 마찬가지입니다.
과거의 판단에는 오류가 있을 수 있습니다. 사용자 선호는 바뀔 수 있고, 계약 조건은 만료될 수 있으며, 한 프로젝트에서 허용된 정보가 다른 프로젝트에서는 금지될 수 있습니다. 이런 차이를 처리하지 못하면 기억의 증가는 잘못된 답변을 더 그럴듯하게 만드는 원인이 될 수 있습니다.
제가 투자 대상으로 보고 싶은 것은 무한히 저장하는 기능이 아니라 무엇을 지식으로 승격하고, 언제 갱신하거나 폐기할지 결정하는 기능입니다. 근거의 출처, 확인 시점, 적용 범위, 접근 권한이 함께 관리되어야 합니다. 고객별 정보와 절차를 축적한다는 주장이 고객 간 비공개 데이터를 자유롭게 섞어 써도 된다는 뜻은 아닙니다.
또한 원본 데이터가 이미 다른 시스템에 있다면 복제하지 않고 위치와 접근 방법만 기억하는 것이 나을 수 있습니다. 중복 제거와 압축, 요약, 보존 기간 설정도 필요합니다. 에이전트의 기억이 유용해질수록 저장 용량이 언제나 같은 비율로 증가해야 하는 것은 아닙니다.
Google Research가 공개한 TurboQuant는 KV 캐시와 벡터 검색에 쓰이는 표현을 압축하는 연구입니다. 발표된 실험을 모든 상용 작업에 일반화할 수는 없지만, 필요한 기억의 논리적 범위가 넓어져도 그 기억을 담는 물리적 바이트는 더 효율적으로 사용될 수 있다는 반대 방향의 힘을 보여 줍니다. Google Research의 TurboQuant 설명
결국 지식의 가치는 저장량 그 자체가 아닙니다. 다시 찾고, 다시 판단하고, 다시 검증하는 데 들 비용을 얼마나 줄였는가입니다. 여기에서 보관·검색·갱신 비용과 오래되거나 잘못된 기억이 만드는 손실을 빼야 합니다.
네트워크의 기회는 모든 연결이 똑같이 빨라지는 데 있지 않습니다
연산과 저장을 분리하면, 정보를 옮기는 일이 늘어날 수 있습니다. 그러나 에이전트의 도구 호출이 늘어나는 것을 곧바로 GPU 클러스터용 고성능 네트워크의 수요와 동일시해서는 안 됩니다.
모델을 여러 장치에서 함께 실행하기 위한 연결, 추론 상태와 데이터를 옮기는 연결, 외부 서비스의 API에 접근하는 연결은 다릅니다. 앞선 연결에서는 대역폭과 지연이 핵심일 수 있지만, 외부 API에서는 호출 제한, 인증, 재시도, 상대 서비스의 응답 시간이 더 큰 제약일 수 있습니다.
NVIDIA가 2026년 3월 발표한 BlueField-4 STX는 CPU, 저장 처리, 네트워크를 함께 구성하는 참조 아키텍처이며, CMX를 통한 추론 문맥 저장 계층의 확장을 제시합니다. 이는 긴 문맥과 에이전트 업무를 저장·전송 구조와 함께 풀려는 방향을 보여 줍니다. 다만 공급자의 아키텍처 발표와 파트너의 채택 계획을 실제 대규모 출하나 수익성의 증거로 읽어서는 안 됩니다. NVIDIA의 STX 발표
제 해석은 “더 많이 옮기는 기업이 이긴다”가 아닙니다. 옮겨야 할 때는 빠르게 옮기고, 가능하면 옮기지 않아도 되게 만드는 기업이 유리하다는 것입니다. 데이터 가까이에서 처리하거나, 허용된 결과를 재사용하거나, 실행 위치를 데이터의 위치에 맞추는 능력이 포함됩니다.
중앙의 대형 모델과 데이터 가까이에 있는 실행 환경을 함께 쓰는 분산 구조도 이 기준으로 평가할 수 있습니다. 로컬·엣지 실행은 데이터 이동이나 응답 지연을 줄일 가능성이 있지만, 낮은 장비 이용률과 분산 운영 비용을 감수해야 합니다. 중앙화와 분산 중 어느 쪽이 무조건 이기는 것이 아니라, 데이터의 위치와 업무의 기한이 배치를 결정한다는 가설입니다.
연산은 흐름이고, 저장은 잔고입니다
이 테시스를 검증하려면 최소한 계산의 단위를 맞춰야 합니다. 토큰 수, GPU 시간, CPU 시간, 저장 바이트, 네트워크 전송량을 하나의 “AI 사용량”으로 합쳐서는 안 됩니다.
연산 자원별로는 다음 관계가 출발점이 됩니다.
해당 기간의 자원 사용량 = 검증된 업무 건수 × 업무당 평균 자원 사용량 + 그 업무에 배분하지 않은 준비·유휴 사용량
업무당 평균에는 성공한 시도만 아니라 실패와 재시도의 사용량도 포함해야 합니다. 사전 준비 비용을 이미 업무당 비용에 배분했다면 뒤에서 다시 더하지 않아야 합니다.
가령 검증된 업무가 3배가 되고, 업무당 GPU 시간이 기존의 40%로 줄었다고 가정하면, 그 부분의 총 GPU 사용량은 1.2배입니다. 같은 업무에서 CPU 시간이 기존의 80%가 된다면 해당 CPU 사용량은 2.4배입니다. 각각 3 × 0.4 = 1.2, 3 × 0.8 = 2.4로 계산한 설명용 가정이며, 시장 전망이나 관측치가 아닙니다. 여기에 사전 계산과 유휴 자원의 변화를 별도로 반영해야 합니다.
효율화와 수요 증가가 동시에 일어나더라도 어느 자원이 얼마나 늘어나는지는 다를 수 있다는 뜻입니다. 효율 개선이 더 많은 업무를 열어 준다는 반등 효과 역시, 사용자의 미충족 수요와 지불 의사가 충분할 때 작동합니다. 자동으로 성립하는 성장 공식은 아닙니다.
저장은 기간 중의 사용량보다 남아 있는 잔고를 봐야 합니다.
기말 물리 저장량 = 기초 저장량 + 실제 새로 보존한 바이트 − 삭제·만료·추가 압축 등으로 회수한 바이트
신규 바이트에는 실제 복제본과 색인 등 부가 저장을 포함하되, 쓰기 전에 중복 제거한 부분은 다시 세지 않아야 합니다. 같은 정보를 계속 고쳐 쓰는 작업은 저장 잔고를 크게 늘리지 않으면서도 읽기·쓰기 부하를 높일 수 있습니다.
그래서 저장 인프라는 용량만 볼 수 없습니다. 얼마나 자주 읽는지, 얼마나 많이 다시 쓰는지, 복구에 얼마나 걸리는지, 지연의 편차가 얼마나 큰지도 봐야 합니다. 반대로 거의 찾지 않는 원본은 빠른 저장 계층에 계속 둘 이유가 적습니다.
에이전트 수보다 검증된 업무량이, 논리적 기억량보다 실제 보존 정책과 접근 패턴이 인프라 수요에 더 가까운 지표입니다.
인프라의 필요성이 공급자의 이익을 보장하지는 않습니다
기업용 SSD는 이 변화에서 검증할 가치가 큰 영역이라고 생각합니다. 추론 관련 캐시, 작업 상태의 복구, 검색과 데이터베이스, 실행 결과 보관 등 서로 다른 역할이 연결될 수 있기 때문입니다. 그러나 모든 데이터가 기업용 SSD를 요구하는 것은 아니고, 같은 SSD라도 용량·지연·쓰기 내구성 중 무엇이 중요한지는 업무에 따라 다릅니다.
여기서 “장기적으로 SSD가 더 쓰일 수 있다”와 “지금 SSD 가격 상승이 가속하고 있다”를 분리해야 합니다. 앞선 명제는 업무 구조의 가설입니다. 뒤의 명제는 동일 사양의 실현 판매가격, 계약 조건, 고객 재고, 공급 증가와 실제 수요로 확인해야 하는 시장의 판단입니다. 이 글의 기술 근거만으로 가격 가속이 입증되지는 않습니다.
메모리와 네트워크, CPU에서도 마찬가지입니다. 단위당 처리 능력이 높아지거나 공급이 빠르게 증가하면 사용량이 늘어도 매출과 이익의 증가율은 낮아질 수 있습니다. 서비스 제공자가 절약한 비용을 가격 인하로 모두 돌려주면 고객은 이득을 얻어도 공급자의 이익은 늘지 않을 수 있습니다.
제가 찾는 것은 수요 증가의 방향만이 아닙니다. 고객이 실제로 지불하는 병목을 해결하고, 경쟁과 효율화 이후에도 그 가치의 일부를 남길 수 있는 사업입니다. 하드웨어에서는 단위당 원가, 인증과 대체 가능성, 증설 후 공급 능력이 중요합니다. 소프트웨어에서는 고객 업무에 얼마나 깊게 연결되어 있는지, 같은 결과를 다른 방법으로 얼마나 쉽게 얻을 수 있는지가 중요합니다.
VC의 기회는 일을 이어가는 능력과 재사용의 경제성에 있습니다
이 관점에서 제가 더 깊게 보고 싶은 사업은 다음과 같습니다. 특정 기업의 실적이나 경쟁 우위가 이미 검증됐다는 목록이 아니라, 투자 검토에서 확인하고 싶은 제품과 수익 구조입니다.
| 사업의 역할 | 고객이 지불할 이유 | 확인할 경쟁 우위와 위험 |
|---|---|---|
| 지속적인 업무 실행과 복구 | 중단 이후에도 이어가고, 같은 외부 작업을 중복 실행하지 않으며, 승인 범위를 지키는 것 | 실제 장애 복구와 연결 시스템의 깊이. 일반 실행 기능은 클라우드에 흡수될 위험 |
| 문맥과 지식의 관리 | 유효하고 접근 가능한 정보를 필요한 순간에 찾아, 재계산과 데이터 이동을 줄이는 것 | 최신성·권한·검색 품질을 함께 유지하는 능력. 단순 저장·검색 인터페이스만으로는 차별화가 약할 수 있음 |
| 반복 업무의 코드·특화 모델 전환 | 강한 모델이 탐색한 절차를 검증된 저비용 실행으로 바꾸는 것 | 동일 품질에서의 총원가 개선, 예외 처리, 모델 교체 후 재검증. 특정 모델의 단기 약점에만 의존할 위험 |
| 행동의 검증·권한·감사 | 잘못된 결제·전송·변경을 막고, 누가 무엇을 왜 실행했는지 설명하는 것 | 업무 시스템과의 연결 및 실패 비용 절감. 호출 기록을 보여 주는 기능만으로 끝날 위험 |
범용 실행 환경만 제공하는 회사라면 클라우드 사업자와 경쟁해야 합니다. AWS AgentCore는 실행·메모리·도구 등 관련 서비스를 제공하고, Cloudflare의 Agents 문서는 지속적인 식별자와 상태, 로컬 SQL 저장, 예약 실행과 복구 가능한 실행을 결합하는 방향을 설명합니다. “에이전트 인프라”라는 이름 자체는 방어력이 아닙니다. AWS AgentCore · Cloudflare Agents 공식 문서
독립 기업이 남길 수 있는 가치는 어느 클라우드에서 실행하든 고객에게 필요한 업무의 맥락, 제어, 품질과 경제성에 있을 가능성이 있습니다. 다만 고객 정보를 붙잡아 두는 것만으로 경쟁 우위를 설명해서는 안 됩니다. 데이터가 고객 소유이고 이동할 수 있어도, 운영 품질과 검증된 절차 때문에 계속 선택받는지를 봐야 합니다.
반복 업무를 많이 보유한 사업자가 효율화에 유리할 가능성도 있습니다. 같은 유형의 일을 여러 번 처리해야 어떤 계산을 없애고 어떤 결과를 재사용할지 알 수 있기 때문입니다. 그러나 그 규모가 실제 학습과 원가 개선으로 연결되는지, 또는 단지 더 많은 사용료를 내는 규모인지가 투자 검증의 대상입니다.
인프라 수요에 연결된다는 이유만으로 모든 사업이 VC에 적합한 것도 아닙니다. 자본집약적인 범용 공급 능력의 확대와, 적은 추가 자본으로 여러 고객에게 확장할 수 있는 소프트웨어·설계·시스템 기술은 서로 다른 사업입니다. 고객당 매출뿐 아니라 그 매출을 유지하고 늘리는 데 필요한 자본과 운영 부담도 함께 봐야 합니다.
테시스가 틀렸다는 신호도 업무에서 나옵니다
목적지향형 상시 컴퓨팅이 기술적으로 가능하다는 것과, 큰 투자 기회라는 것은 다릅니다. 저는 다음 신호가 반복되면 이 테시스의 강도를 낮출 것입니다.
| 검증할 주장 | 테시스를 약화하는 관측 |
|---|---|
| 사용자가 지속적인 업무를 위임한다 | 초기 체험 이후 반복적으로 맡기는 일이 줄고, 사람의 재작업이 많아 유료 이용이 유지되지 않음 |
| 효율화 이후에도 인프라 수요가 커진다 | 검증된 업무 증가보다 업무당 자원 사용량 감소가 더 빨라, 해당 자원의 총수요가 정체됨 |
| 장기 상태와 지식이 경제적 가치를 만든다 | 저장한 정보와 절차가 거의 재사용되지 않거나, 오래된 기억의 오류를 고치는 비용이 더 큼 |
| 기억의 확대가 추가 저장 수요로 연결된다 | 기존 시스템의 위치 참조, 압축·삭제·중복 제거로 대부분을 처리해 신규 물리 저장 수요가 제한됨 |
| 독립 인프라 기업이 가치를 확보한다 | 고객에게 필요한 기능이 기존 플랫폼에 포함되어, 별도 제품의 유료 사용과 이익이 남지 않음 |
제품 회사에 요청할 자료도 여기에서 나옵니다. 같은 고객군의 반복 위임 업무가 어떻게 변했는지, 품질 기준을 고정했을 때 업무당 총원가는 어떻게 바뀌었는지, 사람의 개입과 재시도는 얼마나 필요한지, 저장한 지식과 사전 작업은 실제로 얼마나 재사용되는지입니다.
하드웨어와 기반 서비스에서는 그다음 연결을 확인해야 합니다. 이 업무가 실제로 어떤 자원을 소비하는지, 그 자원 사용이 유료 매출로 이어지는지, 가격과 단위당 원가의 차이가 유지되는지입니다. 에이전트의 출시 발표나 토큰 사용량 하나로 이 연결을 대신할 수는 없습니다.
더 오래 생각하는 기계보다, 맡긴 일을 이어가는 시스템
제가 예상하는 변화는 GPU의 중요성이 사라지는 미래가 아닙니다. 강한 모델이 필요한 판단은 남고, 더 어려운 일에 쓰일 수도 있습니다. 다만 그 판단이 실제 업무가 되려면 코드 실행, 데이터 처리, 권한 확인, 상태 복구, 저장과 전송이 함께 작동해야 합니다.
반복되는 절차는 더 저렴하게 수행되고, 새롭게 어렵거나 예외적인 부분에 더 많은 판단을 쓰는 구조입니다. 이 과정에서 남아야 하는 것은 끝없는 대화 기록이 아니라, 다음 일을 더 정확하고 경제적으로 수행하는 데 도움이 되는 상태와 지식입니다.
제 투자 테시스의 중심은 연산량의 무조건적인 증가가 아니라, 업무의 지속성과 지식의 재사용이 인프라의 설계와 경제성을 바꾼다는 데 있습니다.
연산은 흘러가고, 상태는 남습니다. 그러나 남는다는 사실만으로 가치는 생기지 않습니다. 올바르게 보존하고, 필요할 때 꺼내 쓰고, 낡으면 고치거나 버릴 수 있어야 합니다.
다음 기회는 기계를 무작정 더 오래 켜 두는 데 있지 않습니다. 맡긴 일을 끝까지 이어가면서, 이미 배운 것을 다시 계산하지 않아도 되게 만드는 데 있습니다.
관련 글: VM 에이전트의 경제학: 더 많은 일을, 더 적은 낭비로. 이 글은 앞선 실행 비용 논의를 업무의 지속성, 기억의 계층, 인프라 수요와 사업의 이익 구조로 확장한 필자의 관점입니다.