<aside> 🌏 English edition — Running Actors Inside an AOT Binary — How agent-one's Bot/Loop Pair Actually Behaves

</aside>

<aside> 📚 시리즈 2편 — 1편: 판단을 LLM에서 떼어내다 — CLI 에이전트에 System One 모델을 앉힌 기록

</aside>

<aside> 🎯 3줄 요약 — ① Akka.NET이 1.6에서 AOT 대응을 준비하고 있었고 나는 마침 그게 필요해서, 1편의 CLI 에이전트를 Bot / Loop 액터 쌍 위에 다시 세웠다. ② 채택 이유는 성능도 크기도 아니다 — 에이전트가 요구하는 성질(한 번에 한 턴 · 밖에서 오는 개입 · 안에서 부르는 사람 · 순서 있는 팬아웃 · 실패 격리)이 액터가 원래 모델링하던 것과 거의 같고, 무엇보다 흐름을 머릿속에서 끝까지 따라갈 수 있다. ③ 값은 치렀다 — 바이너리 8.3MB → 20.8MB, 그리고 액터 스레드로 창을 그리다 만든 데드락 한 건.

</aside>

대상 독자: 액터 모델을 알거나, 에이전트 루프를 직접 만들어 본 개발자. 실측은 전부 저전력 미니 PC 한 대에서 나왔다.

<aside> 📌 기준 시점 2026-09-23. 대상은 agent-one v0.3.78 (1편 시점 v0.3.27에서 51번의 패치 빌드 — 이 프로젝트는 빌드마다 패치 번호가 오른다), 저장소는 psmon/AgentZeroLite, feat/agent-one 브랜치가 main에 머지된 상태. Akka.NET은 1.6.0-beta20260922000138 — nuget.org에 없는 나이틀리라 NuGet.config가 Akka.NET 자체 피드를 추가한다. 나이틀리 기준 관찰이므로 정식 릴리스에서 달라질 수 있다. 외부 출처는 전부 2026-09-23에 확인했고, 테스트·바이너리 수치는 같은 날 직접 돌려 얻었다.

</aside>

1. Akka 1.6은 AOT를 준비하고 있었고, 나는 마침 그게 필요했다

1편에서 agent-one을 AgentZero Lite 본체에서 떼어낸 이유는 조합 때문이었다. ZeroCommon의 에이전트 루프는 Akka, EF Core, LLamaSharp, ONNX에 한꺼번에 묶여 있었고, 그 묶음째로는 단일 네이티브 바이너리가 나오지 않는다. 그래서 필요한 최소한만 다시 구현했다.

그런데 그 시점에 Akka.NET 진영은 1.6 라인에서 AOT 대응을 준비하고 있었다. 나이틀리가 피드에 올라와 있었고, 나는 마침 그게 필요한 상황이었다. 그래서 물려 봤다.

됐다. 지금 저장소의 README는 의존성 목록을 이렇게 쓴다.

AgentZero Lite's own agent loop lives in ZeroCommon and is bound to EF Core, LLamaSharp and ONNX…

Akka가 빠져 있다. 1편의 문장이 틀렸다기보다, 그 문장이 가리키던 상황이 바뀌었다. 기술 글에서 흔한 일이고, 솔직히 이쪽이 더 흔하다 — 생태계는 움직이고, 어제 못 하던 게 오늘 된다.

그래서 이 2편은 1편의 리빌딩에 가깝다. 같은 에이전트를, 이번에는 액터 위에 다시 세웠다. 1편에서 다룬 Jev 판단 지점들도 그대로 살아 있는데 위치가 달라졌다 — 그 얘기가 3절이다.

2. 왜 액터인가 — 에이전트가 요구하는 성질이 액터와 닮았다

이 글에서 제일 중요한 질문이다. 더 가벼운 방법이 분명히 있는데 왜 12MB를 더 지불했나.

에이전트 한 턴이 실제로 요구하는 것

이 목록을 다시 읽어 보면, 액터 모델 교과서의 목차와 거의 같다. 메일박스(직렬화), 비동기 메시지(개입), Ask/응답(역방향), 부모-자식(실패 격리), behaviour 전환(상태 기계).

우연이 아니라고 본다. 에이전트는 본질적으로 오래 걸리는 일을 하면서 바깥과 계속 주고받는 독립된 실행 단위고, 그건 액터가 애초에 모델링하려던 대상 그 자체다.