에이전트 런타임의 재발견 — 왜 2026년 4월, 모두가 같은 문제를 다시 풀고 있는가

에이전트가 며칠씩, 몇 주씩 실행된다면 — 그 에이전트는 도대체 어디서 살고 있는가. 누가 재시작하고, 누가 상태를 보존하고, 누가 죽으면 깨우는가.

2026년 4월 8일과 9일 사이의 48시간을 타임라인으로 정리하면, 이상한 일이 일어났다는 사실이 선명해진다.

수요일 새벽, Anthropic이 공식 트위터에 짧은 문장을 올렸다. “Managed Agents는 컴퓨팅의 고전적 난제 — ‘아직 생각되지 않은 것을 어떻게 안전하게 실행할 것인가’ — 에 관한 것”이라는 한 줄이었다. 같은 날 GIGAZINE이 일본어 해설을 내며 “Claude Managed Agents 등장”이라는 제목을 달았다. 같은 주, SkyPilot 블로그는 “Research-Driven Agents”라는 제목으로 에이전트가 코드를 쓰기 전에 먼저 “읽기” 단계를 거쳐야 한다는 설계 철학을 발표했고 Hacker News에서 113점 40코멘트를 기록했다. 또 같은 주, InstantDB가 1.0을 출시하면서 “AI가 만든 앱을 위한 백엔드”라는 부제를 달았다(HN 56점, 32코멘트). 그리고 4월 8일, TechCrunch는 Astropad Workbench가 “IT 지원이 아니라 AI 에이전트를 위한 원격 데스크톱”으로 출시되었다고 보도했다. 거기에 Relvy(YC F24)가 “On-call runbooks, automated”라는 카피로 Launch HN을 올려 37점을 받았다.

서로 다른 회사, 서로 다른 분야, 서로 다른 기술 스택이다. Anthropic은 LLM 제공자이고, SkyPilot은 클러스터 오케스트레이션 회사이고, InstantDB는 백엔드-as-a-service이고, Astropad는 원래 iPad 그래픽 도구 회사였고, Relvy는 SRE 자동화 스타트업이다. 이들이 같은 주에 발표한 제품들의 공통분모는 무엇인가. 단어 한 줄로 표현하면 이렇다 — 장기 실행 에이전트를 어떻게 호스팅할 것인가.

이것은 우연이 아니다. 에이전트가 “요청-응답 함수”에서 “장기 실행 프로세스”로 전이하면서, 1990년대에 application server가 풀려고 했고 2010년대에 FaaS가 도망쳤던 오래된 분산 시스템 문제가 — 새로운 옷을 입고 — 돌아오고 있다는 신호다. 이 글은 그 신호를 일곱 개의 단면으로 해부한다.

1. 에이전트가 “함수”에서 “프로세스”로 전이하는 순간

2023년부터 2025년 초반까지, LLM을 호출하는 코드의 기본 모양은 단순했다. 사용자가 메시지를 보내면, 모델이 응답하고, 세션이 끝난다. ChatGPT의 한 번의 대화. Cursor의 한 번의 코드 제안. 약간 더 복잡해진 것이 multi-turn agent loop였다. 도구를 호출하고 결과를 받고 다시 호출하기를 반복하지만, 여전히 한 세션이라는 시간 단위 안에서 끝나는 게 보통이었다. 길어야 수십 분.

이것은 본질적으로 함수다. 입력이 있고, 출력이 있고, 그 사이의 시간은 짧다. 함수가 실행되는 동안 어딘가에 살아 있어야 하지만, 끝나면 사라져도 상관없다. 상태가 필요하면 호출자가 다음번에 다시 넘겨주면 된다. Stateless. 이것이 LLM API가 처음부터 가질 수 있었던 자연스러운 모양이었다. AWS Lambda가 처음 등장했을 때 모든 백엔드 워크로드를 stateless 함수로 환원하려 했던 것과 정확히 같은 그림이다.

2026년의 변화는 이 그림이 더 이상 들어맞지 않는다는 것이다.

지금의 코딩 에이전트는 한 번에 수 시간을 돈다. 백그라운드 리서치 에이전트는 며칠을 돈다. on-call 에이전트는 — Relvy가 지향하는 것처럼 — 사실상 상시 돈다. 사용자가 자고 있을 때, 사용자가 회사를 그만두었을 때도 돌아야 한다. 어떤 에이전트는 한 시간에 한 번씩 외부 시스템을 폴링하고, 어떤 에이전트는 알람이 울리면 깨어나 30분간 디버깅을 하고 다시 자며, 어떤 에이전트는 며칠에 걸친 코드베이스 마이그레이션을 진행하다가 중간에 사람의 승인을 기다린다.

이것은 더 이상 함수가 아니다. 프로세스다. 한 번 켜지면 명시적으로 끄기 전까지 살아 있다. 메모리를 점유하고, 파일 디스크립터를 들고 있고, 외부 연결을 유지한다. 죽으면 누군가가 깨워야 하고, 다시 깨울 때 어디서부터 다시 시작해야 할지를 알아야 한다.

함수와 프로세스의 차이는 단어의 차이가 아니라 인프라 요구사항의 차이다. 함수는 컨테이너를 그때그때 띄웠다 내릴 수 있다. 프로세스는 그렇게 못 한다. 함수는 메모리를 다 쓰면 OOM으로 죽이고 다음 호출을 새로 띄우면 된다. 프로세스는 그렇게 죽이면 며칠치 작업이 사라진다. 함수의 관찰은 호출당 로그 한 줄로 충분하다. 프로세스의 관찰은 시간축을 따라 흐르는 상태의 변화를 추적해야 한다.

2026년 4월의 모든 발표는 이 전이에 대한 응답이다.

2. Anthropic Managed Agents — “오래된 컴퓨팅 문제가 돌아왔다”

Anthropic 공식 계정이 Managed Agents를 발표하면서 사용한 문장은 의도적으로 추상적이다. “장기 실행 에이전트용 호스팅 서비스 Managed Agents는 컴퓨팅의 고전적 난제 — 아직 생각되지 않은 것을 어떻게 안전하게 실행할 것인가 — 에 관한 것.”

이 문장이 흥미로운 이유는, Anthropic이 이것을 “AI의 새 기능”이 아니라 “오래된 컴퓨팅 문제의 새로운 사례”로 프레이밍한다는 점이다. “아직 생각되지 않은 것”이라는 표현은 Edsger Dijkstra가 1972년 튜링상 강연에서 “아직 작성되지 않은 프로그램(programs not yet written)“을 다루는 것이 컴퓨팅 사이언스의 본질이라고 말했던 것을 — 의도적이든 아니든 — 떠올리게 한다. 코드가 실행되기 전에 그 코드가 어떻게 동작할지 추론하고 안전성을 보장하는 것이 컴파일러와 타입 시스템이 풀어온 문제였다.

에이전트의 경우는 한 단계 더 나아간다. 에이전트는 컴파일 시점에 코드가 결정되어 있지 않다. 모델이 런타임에 다음 행동을 결정하고, 그 행동이 어떤 시스템 호출, 어떤 외부 API 호출, 어떤 파일 변경으로 이어질지는 그때그때 새로 만들어진다. 즉, 호스트는 “아직 존재하지 않는 코드”를 받아서 안전하게 실행해야 한다. 1972년의 문제가 2026년에 새 형태로 돌아온 것이다.

GIGAZINE의 해설 기사는 이 발표를 일본어 독자에게 정리하면서 “장기 실행 프로세스의 신뢰 가능한 호스팅”이라는 표현을 사용했다. 키워드는 세 개다. 장기 실행, 신뢰 가능, 호스팅. 이 세 단어가 이번 사건의 핵심을 정확히 짚는다. 단순히 모델을 호출해주는 API가 아니라, 에이전트라는 객체에 수명을 부여하고, 그 수명이 며칠이든 몇 주든 지속되도록 책임지는 인프라.

Managed Agents가 구체적으로 무엇을 다루는지는 발표 시점에 모든 것이 공개되지 않았지만, “managed”라는 단어가 시사하는 것은 분명하다. 클라우드 업계에서 managed라는 접두사가 붙는 서비스의 의미는 일관된다 — 사용자는 워크로드의 본질만 정의하고, 인프라(스케일링, 재시작, 장애 복구, 관찰 가능성)는 호스트가 책임진다. Managed Kubernetes(EKS, GKE), Managed Redis(ElastiCache), Managed Postgres(RDS)가 모두 이 패턴이다. Managed Agents는 이 패턴을 에이전트라는 신생 객체에 적용하는 첫 시도다.

3. SkyPilot Research-Driven Agents — 런타임 설계가 에이전트의 행동을 바꾼다

SkyPilot의 “Research-Driven Agents” 블로그는 Anthropic의 발표와 같은 주에 나왔지만, 정반대 방향에서 같은 문제에 접근한다. Anthropic이 “에이전트를 어떻게 호스팅할 것인가”의 인프라 쪽을 다룬다면, SkyPilot은 “호스팅된 에이전트는 어떻게 다르게 행동할 수 있는가”의 행동 쪽을 다룬다.

핵심 주장은 단순하다. 코딩 에이전트는 코드를 쓰기 전에 먼저 읽어야 한다. SkyPilot이 말하는 research 단계는 검색과 다르다. 코드베이스를 탐색하고, 관련된 파일을 식별하고, 의존성을 추적하고, 기존의 패턴을 이해하는 것 — 이것을 코드 작성과 명시적으로 분리된 단계로 만들자는 제안이다.

이 제안이 왜 지금 나왔는가. 함수형 에이전트의 시대였다면 이런 주장은 사치였을 것이다. 한 세션 안에서 빠르게 끝나야 하는 에이전트에게 “먼저 며칠 동안 코드베이스를 읽어봐”라고 말할 수는 없다. 토큰 비용도 문제고, 사용자의 인내심도 문제고, 무엇보다 세션이 그 시간 동안 살아 있을 보장이 없다. read 단계에서 모은 맥락이 write 단계로 안전하게 전달된다는 보장도 없다.

장기 실행 에이전트 런타임이 등장하는 순간 이 제약이 풀린다. 에이전트가 며칠 동안 살아 있을 수 있다면, 그 며칠을 read에 쓸 수 있다. 세션이 끊어져도 read 결과를 영속 스토리지에 안전하게 보관할 수 있다면, write 단계는 그 결과를 신뢰할 수 있다. 런타임이 행동을 결정한다. 에이전트가 어떤 모양의 작업을 할 수 있는지는 모델의 능력만이 아니라, 그 모델을 감싸는 런타임이 어떤 시간 단위를 허용하느냐에 달려 있다.

이 통찰은 새로운 것이 아니다. 같은 논리를 데이터베이스 분야에서 본 적이 있다. 단일 머신 RDBMS의 시대에 가능했던 쿼리와, 분산 OLAP 엔진의 시대에 가능해진 쿼리는 종류 자체가 다르다. 인프라가 행동의 지평을 넓혔다. SkyPilot의 제안은 같은 동학을 에이전트에 적용한 것이다. 호스팅이 가능해지면 에이전트의 작업 방식 자체가 재설계될 수 있다.

4. InstantDB 1.0 — AI가 만든 앱을 위한 백엔드의 등장

InstantDB의 1.0 발표는 또 다른 각도다. Anthropic이 에이전트의 호스트를 다루고, SkyPilot이 에이전트의 행동을 다룬다면, InstantDB는 에이전트가 만든 결과물 — 즉 AI가 코딩한 앱 — 이 사는 곳을 다룬다.

부제는 도발적이다. “a backend for AI-coded apps.” 이 부제가 함의하는 바는, 기존 백엔드는 사람이 만든 앱을 가정하고 설계되었다는 것이다. 사람이 만든 앱은 어떻게 다른가. 사람이 만든 앱은 스키마를 미리 결정한다. 마이그레이션은 의도적이고, 천천히 일어난다. API 설계는 여러 라운드의 리뷰를 거친다. 운영 환경에 배포되기 전에 스테이징과 테스트가 있다. 백엔드는 이 모든 가정 위에서 작동한다.

AI가 만든 앱은 이 가정을 전부 뒤집는다. 에이전트는 한 시간에 스키마를 다섯 번 바꿀 수 있다. 마이그레이션을 의도하지 않고, 그냥 다음 버전을 만들어버린다. API는 기존 클라이언트와의 호환성을 고려하지 않을 수 있다. 스테이징과 프로덕션의 경계가 흐려진다. 이런 환경에서 전통적 백엔드는 빠르게 깨진다. ORM의 마이그레이션 파일이 누적되고, API 버저닝이 무너지고, 스키마와 클라이언트 사이의 동기화가 어긋난다.

InstantDB의 답은, 백엔드 자체를 “스키마와 클라이언트가 실시간으로 동기화되는” 모델로 재설계하는 것이다. 클라이언트가 스키마 변화에 자동으로 따라가고, 동기화 레이어가 그 일관성을 책임진다. 에이전트가 무엇을 어떻게 바꾸든, 백엔드가 그 변화를 흡수한다. 이것은 에이전트가 만든 앱이 살아 있을 수 있는 환경을 제공하는 것이다.

여기서 흥미로운 것은, 이 발상이 에이전트 런타임 문제와 연결되는 방식이다. 에이전트가 장기 실행 프로세스라면, 그 프로세스가 만든 앱도 장기 실행이다. 에이전트가 며칠에 걸쳐 앱을 진화시킨다면, 그 며칠 동안 앱이 살아 있어야 한다. 죽었다 살아나는 것이 아니라, 끊임없이 변하면서 계속 켜져 있어야 한다. 이 요구사항은 백엔드가 “사람의 배포 사이클”을 가정하고 설계된 시대의 것이 아니다. 에이전트의 시간 척도에 맞춘 새 백엔드가 필요하다.

InstantDB 1.0은 그 시도다. 그리고 이 시도가 같은 주에 Anthropic, SkyPilot의 발표와 함께 등장했다는 것은, 같은 구조적 압력이 다른 회사들로 하여금 다른 레이어에서 같은 문제를 풀도록 만들고 있다는 증거다.

5. Astropad Workbench와 Relvy — 에이전트가 “사용자”가 될 때

TechCrunch의 Astropad Workbench 보도는 헤드라인 자체가 이 변화를 압축해서 보여준다. “for AI agents, not IT support.” 원격 데스크톱이라는, 1990년대에 만들어져서 30년 이상 동일한 사용자 — IT 지원 인력 — 를 가정해온 카테고리가, 처음으로 그 가정을 바꾸고 있다.

기존 원격 데스크톱(VNC, RDP, TeamViewer)의 설계는 일관된다. 사람이 사람의 화면을 본다. 사람이 사람의 마우스와 키보드를 빌린다. 화면은 사람의 시각에 맞춘 해상도와 리프레시 레이트를 가진다. 입력 이벤트는 사람의 손가락 속도를 가정한다. 권한 모델은 “이 사람이 저 머신을 잠시 빌려 쓴다”는 시나리오를 가정한다.

Astropad Workbench는 이것을 근본부터 다시 짠다. TechCrunch의 정리에 따르면, 이 제품은 Mac mini 위에서 돌아가는 에이전트를 모바일 디바이스에서 모니터링하고 제어하기 위한 플랫폼이다. 저지연 스트리밍, 모바일 우선 접근, UI 자동화 호환성이 핵심 축으로 제시된다. 사용자가 사람에서 에이전트로 바뀌면 무엇이 달라지는가. 화면은 사람을 위한 것이 아니라 에이전트의 시각 처리 파이프라인을 위한 것이 된다. 입력은 사람의 손가락 속도가 아니라 에이전트가 의사결정하는 속도다. 권한 모델은 “에이전트가 며칠 동안 이 머신을 점유한다”는 시나리오를 다뤄야 한다. 그리고 사람의 역할은 직접 사용자가 아니라 — 에이전트가 무엇을 하고 있는지 모바일에서 들여다보는 — 슈퍼바이저다.

Relvy의 Launch HN은 또 다른 측면이다. 온콜 대응 자동화, 즉 SRE의 runbook을 에이전트가 실행하는 제품이다. 이 영역이 흥미로운 이유는, 온콜 대응이라는 작업의 시간 척도다. 알람이 울릴 때까지 잠들어 있다가, 울리면 깨어나서 진단을 하고, 필요하면 사람을 페이지하고, 가능하면 자동으로 복구하고, 다시 잠든다. 이것은 함수가 아니다. 이것은 daemon이다 — 1970년대 유닉스 시스템에서 등장한 그 개념. 백그라운드에서 끝없이 살아 있으면서 이벤트에 반응하는 프로세스.

Relvy 같은 에이전트는 호스팅 인프라가 없으면 존재할 수 없다. 누군가가 24시간 그 에이전트를 살려두고, 알람을 라우팅하고, 죽으면 깨우고, 행동의 이력을 감사 가능한 형태로 저장해야 한다. 이것은 정확히 Anthropic Managed Agents가 풀려고 하는 문제의 모양이다.

Astropad와 Relvy를 함께 놓고 보면 한 가지가 분명해진다. 에이전트가 “사용자” 역할을 하는 영역이 폭발적으로 늘어나고 있다. 그리고 사용자가 사람에서 에이전트로 바뀌는 모든 인터페이스 — 원격 데스크톱, 온콜 시스템, 그 외에 곧 따라올 모든 것 — 에서, 기존의 가정이 한꺼번에 깨지고 있다.

6. 오래된 문제의 새로운 변주 — application server, FaaS, 그리고 agent runtime

여기서 한 발 뒤로 물러나서 더 긴 시간 척도에서 보면, 우리는 같은 문제가 30년 동안 모양을 바꿔가며 돌아오는 광경을 목격하고 있다.

1990년대: application server. Java 진영의 WebLogic, WebSphere, JBoss. .NET 진영의 IIS와 COM+. 이 시대의 핵심 문제는 “상태 있는 장기 실행 프로세스를 어떻게 안전하게 호스팅할 것인가”였다. 트랜잭션, 세션, 커넥션 풀, 객체 수명 주기, 분산 락. application server라는 카테고리는 이 문제들에 대한 답을 한 패키지로 묶은 것이었다. 개발자는 애플리케이션의 비즈니스 로직만 작성하고, 런타임이 나머지를 책임진다는 약속이었다.

이 약속은 부분적으로만 지켜졌다. application server는 무거웠고, 디버깅이 어려웠고, 벤더 종속이 심했고, 한 머신에 한 인스턴스라는 모델이 클라우드 시대의 수평 확장과 잘 맞지 않았다. 그래서 다음 세대는 정반대로 갔다.

2010년대: FaaS와 stateless 강제. AWS Lambda, Google Cloud Functions, Azure Functions. 이 시대의 답은 “장기 실행 프로세스라는 개념 자체를 포기하자”였다. 모든 워크로드를 짧은 함수 호출로 환원하고, 상태는 외부 스토리지(DynamoDB, S3, Redis)로 빼낸다. 함수는 stateless여야 한다. 이 제약을 받아들이는 대가로, 운영 책임의 대부분을 클라우드 제공자에게 떠넘길 수 있었다. 개발자는 함수의 로직만 짜고, 스케일링과 가용성은 자동이다.

이것도 부분적으로만 작동했다. 모든 워크로드가 stateless로 환원되지는 않는다. 머신러닝 학습, 배치 처리, 워크플로우 오케스트레이션, 게임 서버, 그리고 — 지금 우리가 보고 있는 — 에이전트 같은 것들. 이 워크로드들은 stateful의 본성이 너무 강해서 외부 스토리지로 상태를 빼내는 것이 비현실적이었다. 결과적으로 FaaS는 “단순한 워크로드”의 영역에 머물렀고, 복잡한 long-running 워크로드는 여전히 컨테이너와 VM의 세계에 남았다.

2020년대 중반: agent runtime의 등장. 그리고 지금 우리가 보고 있는 것이 이 두 시대의 종합이다. 에이전트는 application server가 다뤘던 “상태 있는 장기 실행”의 본성을 가졌다. 동시에 FaaS가 약속했던 “운영 책임의 외주화”를 원한다. 에이전트 개발자는 에이전트의 행동만 정의하고 싶지, 그 에이전트가 며칠 동안 살아 있게 만드는 인프라를 직접 관리하고 싶지 않다.

이 두 요구를 동시에 만족시키는 새 카테고리가 필요하다. Anthropic의 Managed Agents가 한 답이고, SkyPilot의 클러스터 위에서 도는 long-running 에이전트가 다른 답이고, InstantDB가 에이전트가 만든 앱을 받아주는 또 다른 답이고, Astropad가 에이전트의 GUI 환경을 책임지는 또 다른 답이다. 한 회사가 전부 풀지 않는다. 여러 회사가 각자의 레이어에서 같은 문제의 다른 단면을 풀고 있다.

이 풍경이 익숙하다면 그 직관은 옳다. 1990년대 application server 시대에도, 한 회사가 모든 것을 풀지 않았다. BEA가 트랜잭션 모니터를 만들고, IBM이 메시지 큐를 만들고, Oracle이 데이터베이스를 만들고, Sun이 JVM을 만들었다. 카테고리가 새로 생길 때는 항상 이런 식으로 여러 회사가 같은 시기에 인접 영역을 점유한다. 2026년 4월 첫째 주의 풍경은, 그 시대의 reprise에 가까워 보인다.

7. 질문들 — 당신의 에이전트는 어디서 살고 있는가

여기까지의 분석은 회고적이다. 더 흥미로운 것은 앞으로의 질문이다.

첫째, 어떤 추상화가 살아남는가. 1990년대의 application server는 EJB라는 무거운 추상화를 시도하다가 결국 Spring 같은 가벼운 대안에 자리를 내주었다. 2010년대의 FaaS는 함수라는 가벼운 추상화로 시작했지만, 워크플로우 오케스트레이션이 필요해지면서 Step Functions, Temporal 같은 더 무거운 추상화가 위에 쌓였다. 에이전트 런타임은 어느 쪽을 따라갈 것인가. 처음부터 무거운 추상화로 시작해서 가벼워질 것인가, 아니면 가벼운 함수로 시작해서 무거운 오케스트레이션이 위에 얹힐 것인가.

둘째, 호스트 락인은 어떻게 회피되는가. Managed 서비스의 본질적 문제는 벤더 락인이다. Managed Agents가 표준이 된다면, 그 위에서 도는 에이전트의 정의와 상태는 누구의 자산인가. 한 호스트에서 다른 호스트로 에이전트를 옮기는 것이 가능한가, 아니면 application server 시대처럼 한번 한 벤더에 묶이면 빠져나오기 어려운가. 이 질문에 대한 답이 — 결국 — 에이전트 런타임 시장의 구조를 결정할 것이다.

셋째, 관찰 가능성은 어디에 있는가. stateless 함수의 관찰은 호출당 로그 한 줄로 충분했다. 장기 실행 에이전트의 관찰은 다른 종류의 도구를 요구한다. 에이전트가 며칠에 걸쳐 무엇을 했는지를 사람이 사후에 감사할 수 있어야 하고, 에이전트가 실시간으로 무엇을 하고 있는지를 모니터링할 수 있어야 한다. Astropad Workbench가 모바일에서 에이전트를 들여다본다는 발상은 이 영역의 첫 시도다. 하지만 한 회사의 한 제품이 전체 카테고리의 답이 될 수는 없다. 에이전트용 Datadog, 에이전트용 Grafana, 에이전트용 Sentry가 차례로 등장할 것으로 예상해도 무리가 없다.

넷째, 사람은 어디에 있는가. 함수의 시대에는 사람이 호출자였다. 프로세스의 시대에는 사람이 어디에 있는가. 슈퍼바이저인가, 협업자인가, 감사관인가, 아니면 아예 루프 밖의 외부자인가. Relvy의 온콜 에이전트는 사람을 페이지할 수 있어야 한다. Managed Agents는 사람의 승인을 기다릴 수 있어야 한다. 에이전트가 며칠 동안 도는 동안 사람은 무엇을 하고 있는가. 이 질문의 답이 — 기술적 답이 아니라 사회적·조직적 답이 — 에이전트 런타임의 진짜 차별화 지점이 될 것이다.

다시 처음의 질문으로 돌아가자. 에이전트가 며칠씩 실행된다면, 그 에이전트는 어디서 살고 있는가.

2026년 4월 첫째 주 이전의 답은 명확하지 않았다. 어떤 사람은 자기 노트북에 띄워두었고, 어떤 사람은 EC2 인스턴스 위에 띄웠고, 어떤 사람은 수동으로 운영했다. 에이전트라는 객체에 어울리는 호스팅 카테고리가 존재하지 않았기 때문이다.

같은 주에 다섯 곳이 동시에 다섯 가지 답을 내놓았다. Anthropic은 managed 호스팅으로, SkyPilot은 클러스터 오케스트레이션 위의 research-driven 워크플로우로, InstantDB는 에이전트가 만든 앱을 받아주는 백엔드로, Astropad는 GUI 환경의 재정의로, Relvy는 온콜 daemon으로. 각자가 다른 레이어를 점유했지만, 같은 구조적 압력 — 함수에서 프로세스로의 전이 — 에 응답하고 있다는 것은 분명하다.

1990년대 application server가 풀려고 했던 문제, 2010년대 FaaS가 도망쳤던 문제가 — 에이전트의 형태로 — 돌아왔다. 그리고 이번에는 도망갈 곳이 없다. 에이전트는 본질적으로 stateful이고 long-running이기 때문이다. 누군가는 그것을 호스팅해야 한다. 같은 주에 다섯 곳이 손을 든 이유가 여기에 있다.

다음 질문은 독자에게 던지고 싶다. 당신이 지금 만들고 있는 — 또는 곧 만들게 될 — 에이전트는 어디서 살고 있는가. 그 호스트는 며칠을 보장하는가, 몇 주를 보장하는가, 아니면 영원을 보장하는가. 그 호스트가 죽으면 누가 깨우는가. 그 호스트가 만든 흔적을 누가 감사하는가. 이 질문들에 답이 없다면, 당신이 만드는 에이전트는 아직 함수의 시대에 머물러 있다. 답이 있어야만 — 그 답이 어떤 모양이든 — 프로세스의 시대로 넘어갈 수 있다.

2026년 4월 첫째 주는, 그 답을 찾아야 한다는 사실이 업계 차원에서 동시에 인지된 순간으로 기억될 가능성이 크다.