2026년 5월, Google이 google/ax 라는 분산 에이전트 런타임을 공개했다. README 어디에도 "Akka"나 "Erlang"이라는 단어는 등장하지 않는다. 그런데 60~63줄에 이런 문장이 박혀 있다.
"tools, skills and agents are deployed as isolated actors, a distributed runtime with dynamically spawned isolated workers becomes a necessity."
Google이 액터모델이라 부르지 않을 뿐, AX의 설계는 1973년 Carl Hewitt가 정의하고 Erlang이 대중화한 그 모델 그대로다. 놀랍지 않다. 에이전트 오케스트레이션을 진지하게 만들면 결국 액터모델로 수렴한다.
English edition: Actor Model Underneath Agentic AI — No Surprise · Sister piece (Akka.NET port): Building LLM Agents in Akka.NET — Porting Akka.io's Agent SDK to the Actor Model
이 글은 그 수렴이 어쩌다 우연이 아닌지를 정리한다. 대상 독자는 액터모델이 뭔지는 들어봤지만 "지금도 쓰나?" 싶은 한글 IT 독자다.
[이미지 #1 — 액터모델 위에 선 에이전틱 AI] Google AX의 'isolated actor' 메타포를 시각화한 히어로 카드.
파일:
2026-05-24-agentic-actor-hero.png
1. 액터모델은 사라진 게 아니라 너무 당연해졌다
3줄 요약
- 액터모델은 1973년 Carl Hewitt 논문에서 시작해 Erlang으로 대중화된 동시성 모델이다.
- "유행이 끝났다"는 말은 사라졌다는 뜻이 아니라 너무 당연해서 더 이상 언급되지 않는다는 뜻이다.
- 카카오톡 채팅 서버, IoT 플랫폼, 금융 트레이딩, 게임 서버 등 우리가 매일 쓰는 시스템이 이미 액터모델 위에 있다.
액터모델의 핵심은 세 줄이면 끝난다.
- 액터(Actor) 는 상태와 동작을 캡슐화한 동시성 단위다.
- 액터끼리는 메시지 로만 통신한다. 공유 메모리도, 락도 없다.
- 각 액터에는 메일박스(메시지 큐) 가 있어서 한 번에 한 메시지만 처리한다.
[이미지 #2 — 액터모델의 기본 원리] 메일박스를 이고 있는 액터들이 메시지를 주고받는 모습.
파일:
2026-05-24-actor-model-basics.png
이게 왜 분산 시스템에서 유리한가? Akka의 자료에서 빌려오면 메모라이저: Akka Actor Model - 핵심 개념과 특징 — 위치 투명성(Location Transparency) 때문이다. 같은 프로세스에 있든 다른 머신에 있든, 액터에 메시지를 보내는 코드는 동일하다. 분산 시스템에서 "원격을 로컬처럼" 다루는 게 아니라, 처음부터 "전부 원격이라 가정하고 최적화로 로컬화" 하는 발상이다. Akka.NET 자료 메모라이저: Akka.NET - 분산 Actor 모델 프레임워크 의 표현을 빌리면, 이게 맞는 방향 이고 반대는 실패할 수밖에 없는 방향 이다.
오해 하나만 짚자. 한때 "액터모델은 한물갔다"는 말이 돌았다. 사실관계는 정반대다. Erlang/OTP는 1986년부터 통신 인프라를 지탱하고 있고, Akka는 JVM 진영에서 카카오·라인·국내 게임사들이 채팅과 게임 서버에 쓴다. 마이크로소프트는 Orleans를, 자바스크립트 진영은 Vert.x를, 클라우드는 Erlang의 후예인 Elixir를 쓴다. 사라진 게 아니라 인프라 안으로 내려가서 잘 보이지 않게 된 것이다.
2. Tyler Jewell의 통찰 — 에이전틱은 그냥 분산 시스템이다
3줄 요약
- MIT 연구: 2025년 기준 AI 프로젝트의 95%가 기대 결과를 내지 못한다. S&P Global은 포기율이 17%→42%로 두 배 이상 뛰었다고 보고했다.
- Akka CEO Tyler Jewell의 진단: 실패의 본질은 상상력 부족이 아니라 인프라 엔지니어링의 실패다.
- 에이전틱 시스템은 결국 분산 시스템이고, 분산 시스템이 풀어야 했던 문제(큐 포화, 노드 크래시, 재시도 폭주, 분산 디버깅, 시간 걸친 워크플로우)가 그대로 돌아온다.
Akka의 CEO Tyler Jewell이 2025년에 쓴 글 메모라이저: Agentic AI: 경험이 과대광고보다 중요한 이유 의 골자는 단순하다. LangChain이 ARR 1500만 달러 수준에서 10억 달러 이상 가치평가를 받는 동안, 정작 프로덕션에 올린 팀들의 답은 "이걸로는 안 된다" 였다는 것이다.
이유는 에이전틱 시스템이 기존 챗봇·요청응답 함수와 본질적으로 다른 클래스의 분산 시스템이기 때문이다.
측면 | 전통 시스템 | 에이전틱 시스템 |
상태 | 없음(stateless) | <strong>장기 보유(stateful)</strong> |
시간 척도 | 요청/응답(ms~s) | <strong>분/시간/일</strong> |
결정성 | 결정적 | <strong>확률적(LLM)</strong> |
부작용 | 순수 데이터 | <strong>이메일, 결제, 인프라 변경</strong> |
자원 | 균일 CPU | <strong>CPU + GPU 혼합</strong> |
Tyler는 Akka가 15년간 부딪힌 분산 시스템 실문제 — 큐 포화, 노드 크래시, 재시도 폭주, 분산 디버깅, 시간에 걸친 워크플로우 — 가 에이전틱에서 그대로 재등장한다고 본다. 그리고 해법도 이미 있다. 경계가 있는 메일박스, 이벤트 소싱, 서킷 브레이커, 감독 계층, 영속 가능한 프로세스 같은 액터모델 생태계의 표준 도구들이다.
이 시점에서 액터모델이 에이전트 오케스트레이션의 후보가 아니라 사실상의 정답 이라는 결론이 나오는 게 자연스럽다.
3. 4대 플랫폼이 전부 액터모델인 이유
3줄 요약
- Google AX, Akka Agents, Microsoft Orleans, Ray Serve — 2025~2026년 등장한 주요 Agent Orchestration 플랫폼은 모두 액터 기반 또는 액터형 모델이다.
- 공통점은 (1) 격리된 워커, (2) 메시지 기반 통신, (3) 영속화된 상태, (4) 위치 투명성이다.
- "왜 액터모델인가"를 묻기보다 "다른 모델로 어떻게 가능한가"를 묻는 게 더 어려운 질문이다.
[이미지 #3 — 4대 플랫폼이 액터모델로 수렴] 중심에서 다섯 갈래(AX·Akka·Orleans·Ray·Temporal)가 갈라지는 모습.
파일:
2026-05-24-four-platforms-convergence.png
3.1 Google AX — "isolated actors"라 부르지만 액터모델
google/ax 의 README 그림을 텍스트로 풀면 이렇다.
graph LR Client --> Router Router --> Controller["AX Controller<br/>(executor, event log, registry)"] Controller <-->|resumable stream| RemoteAgent["Agent<br/>(isolated actor)"] Controller --> Env["Environment<br/>(isolated actor)"] Controller --> Tool["Tool<br/>(MCP server)"]
핵심 설계 결정 5가지를 액터모델 용어로 번역하면 다음과 같다.
AX 용어 | 액터모델 대응 |
Controller | ActorSystem + Supervisor |
Remote Agent / Environment (isolated actor) | Remote Actor + Sharding |
Event Log | Event Sourcing (Akka Persistence와 동치) |
Resumable Stream | 메시지 메일박스 + 재시도 가능한 전달 |
Single-Writer Architecture | 액터의 단일 스레드 처리 보장 |
AX는 Single-Writer 패턴으로 컨트롤러 하나가 일관성을 책임지고, 이벤트 로그로 장애에서 복구한다. 컨트롤러를 재시작하면 이벤트 로그를 리플레이해서 마지막 위치부터 다시 작동한다. Akka Persistence의 EventSourcedBehavior 와 거의 1:1 매핑된다.
3.2 Akka Agents — 원조의 직진
Akka는 액터모델 그 자체이고 메모라이저: Akka Agents - 구조화된 에이전트 개발 플랫폼 의 구조는 Context Gathering → Reasoning → Action Taking → Progress Evaluation 의 4단계 라이프사이클을 한 액터의 FSM(Finite State Machine)으로 표현한다.
@ComponentId("activity-agent") public class ActivityAgent extends Agent { public Effect<String> query(String message) { return effects() .systemMessage("You are an activity agent...") .userMessage(message) .thenReply(); } }
Akka의 에이전트는 메시지 받기 → 시스템 프롬프트 + 사용자 메시지로 LLM 호출 → 응답 반환 의 액터 그 자체다. 에이전트가 도구(외부 API)를 호출할 때는 Workflow 컴포넌트 — Akka Persistence 기반의 영속 워크플로우 — 가 단계별 진행을 이벤트 로그에 기록한다. 노드가 죽어도 다른 노드가 마지막 단계부터 이어 받는다. 이게 Google AX의 "resumable execution"의 원형이다.
3.3 Microsoft Orleans — 가상 액터로 에이전트마다 액터 1개
Orleans는 액터모델의 한 변종인 Virtual Actor 를 만든 곳이다. 일반 액터는 "생성하고 종료" 하지만, Virtual Actor(Orleans에선 Grain )는 개념적으로 항상 존재한다. 처음 접근하는 순간 자동 활성화되고, 한동안 안 쓰이면 알아서 메모리에서 내려간다. 다음 접근에서 다시 살아나는데, 상태는 영속 저장소에서 복원된다.
이 패턴은 에이전틱에 거의 완벽하게 들어맞는다. 사용자 1명당 영속 대화 에이전트 1개, 기업 고객 1곳당 RAG 에이전트 1개 — 이렇게 개체 단위로 액터를 매핑 한다. 사용자가 늘면 클러스터에 노드만 추가하면 된다. 2026년 Microsoft Agent Framework가 .NET과 Python 양쪽으로 공개되면서 Orleans 위에서 돌아가는 에이전트가 표준 옵션이 됐다.
3.4 Ray Serve — 파이썬 진영의 분산 액터
Ray는 OpenAI가 GPT-3·GPT-4 학습에 쓴 그 Ray다. Ray의
@ray.remote 데코레이터로 만든 클래스는 클러스터에 분산된 액터로 배치된다. Anyscale의 글 AI agents on Ray Serve: Single to multi-agent architecture 가 보여주는 패턴은 단순하다.- LLM 추론은 GPU 액터(독립 스케일)
- 도구 호출은 CPU 액터(독립 스케일)
- 라우팅·메모리는 또 다른 액터
각 액터는 독립적으로 스케일링·롤링 업데이트가 가능하다. Tyler Jewell이 말한 "큐 포화·노드 크래시"의 분산 시스템 표준 해법 그대로다.
3.5 Temporal — 액터 형제 진영(durable execution)
Temporal/Cadence는 엄밀히 액터모델보다는 결정론적 워크플로우 엔진(durable execution) 으로 분류된다. 그러나 대화 1개 = 워크플로우 인스턴스 1개 의 매핑은 Orleans의 Grain 이나 Akka의 EventSourcedBehavior 와 본질이 같다. 작업 단위가 상태를 캡슐화하고, 메시지(시그널)로 상호작용하고, 장애에서 자동 복구된다. OpenAI VP가 "Temporal's durable orchestration framework is critical to handling our massive scale, complex agentic workflows" 라고 한 발언은 이 패턴의 프로덕션 정합성을 증언한다.
3.6 공통 분모
위 5개를 표 하나로 묶으면 이렇다.
플랫폼 | 핵심 단위 | 통신 | 영속화 | 위치 투명성 |
Google AX | Isolated Actor | Resumable Stream (gRPC) | Event Log | ⭕ (Kubernetes) |
Akka Agents | Agent + Workflow | Message + Effect | Event Sourcing | ⭕ (Cluster) |
Orleans | Grain (Virtual Actor) | RPC | Storage Provider | ⭕ (Silo) |
Ray | @ray.remote Actor | Message | Externalized | ⭕ (Cluster) |
Temporal | Workflow Instance | Signal/Query | Event History | ⭕ (Worker) |
다섯 칸 모두 채워진다. 다른 분산 모델 — 액터가 아닌 모델 — 로 이 다섯 칸을 모두 채우려고 시도하면, 결국 액터 비슷한 것을 직접 만들게 된다. 이게 "에이전틱에 액터모델, 놀랍지 않다" 의 핵심이다.
4. 단일 장비 에이전트에도 액터모델인가 — AgentZeroLite 사례
3줄 요약
- 오케스트레이션이 아닌 개인 PC에서 돌리는 작은 에이전트에도 액터모델은 자연스럽다.
- AgentZeroLite는 윈도우 데스크톱에서 WPF + Akka.NET으로 LLM 툴체인을 액터로 구현했다.
- 단일 장비에서도 액터모델은 (1) UI·LLM·터미널의 분리, (2) FSM 기반 에이전트 루프, (3) 격리된 워크스페이스 관리에 깔끔한 도구가 된다.
[이미지 #4 — 단일 장비 안의 중첩 액터 토폴로지] AgentZeroLite 데스크톱 내부의 액터 5계층을 마트료시카 형식으로 시각화.
파일:
2026-05-24-agentzerolite-single-machine.png
오케스트레이션급의 액터모델은 직관적이다. 그런데 한 대 PC에서만 돌아가는 에이전트에도 액터모델이 필요할까?
필자(@webnori)가 직접 작성한 글 — 이 부모 페이지의 자매 글인 Building LLM Agents in Akka.NET — Porting Akka.io's Agent SDK to the Actor Model — 에서 답한 가설은 예, 단일 장비에서도 액터모델은 충분한 가치를 한다. 였다. 이 가설을 실제로 구현한 게
D:\Code\AI\AgentZeroLite 다.액터 토폴로지
AgentZeroLite의 CLAUDE.md에 명시된 액터 계층은 이렇다.
/user/stage StageActor — 슈퍼바이저 + 메시지 브로커 /bot AgentBotActor — UI 게이트웨이: 채팅/키 모드, 피어 라우팅, 인트로 추적. AgentLoopActor를 지연 생성. /loop AgentLoopActor — 에이전트 본체: IAgentLoop 1개 소유, Idle→Thinking→Generating→Acting→Done FSM 구동. /ws-<name> WorkspaceActor — 워크스페이스(폴더)당 1개 /term-<id> TerminalActor — ITerminalSession 1개 래핑
단일 장비에서 액터모델이 잘 들어맞는 5가지 지점
1. UI ↔ 로직 ↔ 외부 자원 분리. WPF의 UI 스레드는 단일 스레드 모델이라 LLM 추론이나 ConPTY 터미널 같은 장시간 작업이 들어오면 즉시 굳어버린다. 액터 시스템에 그 작업을 위임하면 UI는 메시지만 보내고 콜백으로 응답을 받는다. (
AgentEventStream / SetBotUiCallback)2. 에이전트 루프 = FSM. 에이전트는 생각 → 도구 호출 → 결과 받아 다시 생각 의 루프를 돈다. Akka.NET의 FSM 트레이트를 쓰면 Idle → Thinking → Generating → Acting → Done 의 5상태가 정확히 한 액터의 받기 함수 5개로 분리된다.
3. 워크스페이스 = 액터. 사용자가 폴더를 열 때마다
WorkspaceActor 가 하나 뜨고, 그 안의 터미널 탭은 TerminalActor 자식이 된다. 한 폴더의 터미널이 죽어도 다른 워크스페이스는 영향 없음 — 이게 감독 계층의 isolation 효과.4. 메시지가 곧 영속화 단위.
Messages.cs 한 파일에 모든 메시지 타입이 모이고, 이를 직렬화해서 SQLite(agentZeroLite.db)에 기록하면 그대로 이벤트 로그가 된다. 같은 패턴이 Google AX 의 Event Log, Akka의 EventSourcedBehavior다 — 스케일만 다르다.5. 향후 확장 = 노드 추가. AgentZeroLite는 PRO 로드맵에서
AgentZeroRemote → AgentZeroCluster 로 확장 예정이다. 액터모델이라서 가능한 일이다. 단일 장비에서 동작하던 같은 코드가 클러스터로 거의 그대로 올라간다. 위치 투명성 덕이다.핵심 통찰
AgentZeroLite는 온디바이스 공개 모델 활용 이 목적이지 오케스트레이션이 아니다. 그럼에도 액터모델을 채택한 이유는 단순하다 — 윈도우 데스크톱이라는 작은 분산 시스템(UI 스레드 + LLM 워커 + 터미널 프로세스)을 다루는 가장 깔끔한 방법 이기 때문이다. 분산의 정도가 작을 뿐, 분산 시스템임에는 변함없다.
5. 마치며 — "당연한 것"의 가치
OpenAI는 2026년 4월 Agents SDK를 발표하면서 메모라이저: OpenAI Agents SDK 차세대 진화 "harness와 compute의 분리" 를 핵심으로 내세웠다. 그 본질을 액터모델 용어로 풀어보면 컨트롤 플레인(harness)과 워커(compute)의 분리, 영속 상태로 회복 가능한 실행 이고, 이는 Akka가 15년, Erlang이 40년 해온 일이다.
Google AX는 "distributed agent runtime" 으로 자신을 소개하면서 README 어디에도 "actor"라는 단어를 굳이 노출하지 않는다. 왜 그럴까?
가설 하나는 — 너무 당연해서 굳이 강조하지 않는 것 이다. 분산 데이터베이스가 "우리는 ACID를 지킵니다" 라고 광고하지 않듯이, 분산 에이전트 런타임이 "우리는 액터모델입니다" 라고 광고할 필요가 없는 단계가 된 것이다. Google이 mermaid 다이어그램에서 isolated actor 라고 표기한 건 의도된 절제다.
다른 가설은 — 이미 Erlang/Akka 진영에 빚지지 않으려는 브랜딩 이다. 그러나 60~63줄의 그 한 문장 "agents are deployed as isolated actors" 가 출처를 가렸지만 디자인 결정만큼은 그대로 드러나 있다.
어느 쪽이든 결론은 같다. 에이전틱 AI의 미래는 액터모델 위에 서 있다. 한국 IT 독자에게 이 글의 실용적 함의는 단순하다.
- 에이전트 오케스트레이션 도구를 평가할 때 "어떻게 격리, 메시징, 영속, 위치 투명성을 다루는가" 의 4축으로 보면 본질이 보인다.
- JVM/Java/Kotlin 진영이라면 Akka, .NET이면 Orleans/Akka.NET, Python/AI 스택이면 Ray, 워크플로우 중심이면 Temporal — 이미 검증된 도구 중에서 고르는 것이 합리적이다.
- 단일 장비 에이전트라도 나중에 분산으로 갈 가능성이 있다면 처음부터 액터모델로 짜는 게 이식 비용을 가장 낮춘다.
액터모델은 돌아온 게 아니라 처음부터 사라진 적이 없다. 다만 이제는 에이전틱이라는 이름으로 한 번 더 무대 위로 올라설 차례다.
참고 자료
1차 자료
- Google AX (github.com/google/ax) — Apache 2.0, 2026-05 active early development
- Microsoft Agent Framework — Orleans 위 에이전트 프레임워크
메모라이저
인용 출처
- Tyler Jewell, "Agentic AI: Why Experience Matters More Than Hype", Akka, 2025
- Building Stateful AI Agents at Scale with Microsoft Orleans, DEV Community, 2026
- AI agents on Ray Serve: Single to multi-agent architecture, Anyscale Blog, 2025
- MIT Sloan Management Review, 2025 (95% AI 프로젝트 실패율)
- S&P Global, 2025 AI Project Survey (포기율 17% → 42%)