Page History

AgentWin AgentZero 실사례로 풀어보는 Akka.NET 메시지 패턴. 작성일: 2026-04-14. 대상: Akka를 처음 보는 .NET / 서버 개발자. 이번 편은 여러 AI 터미널이 왜 질서 있는 메시지 구조를 필요로 하는지부터 설명한다.

0. 들어가며

요즘 CLI는 더 이상 사람이 혼자 명령을 치는 검은 창이 아니다. claude, codex, gemini, copilot 같은 AI CLI가 각자 자기 머리를 가진 채 돌아가고, 사람은 그들과 대화한다.

최근 재밌는 실험을 하나 진행했다. 어느 순간 내 개발 환경은 코드 편집기라기보다, 여러 AI CLI를 제어하는 조종석이 되어 가고 있었다.

똑똑한 AI CLI만 해도 Claude Code, Codex, Gemini, 온디바이스 LLM까지 제각각이고, 이들을 쓰는 환경도 제각각이다. 어떤 건 WSL 위에서 돌고, 어떤 건 Windows Terminal 위에서 돈다. IDE도 하나로 통일되지 않는다. 인텔리J, 라이더, 웹스톰, 토이 프로젝트에선 VS Code, 조금 더 네이티브한 OS 프로그래밍으로 가면 Visual Studio까지 섞여 들어온다.

문제는 여기서 끝나지 않는다. 왼쪽 IDE에서는 코드를 보고, 아래 터미널에서는 여러 AI CLI를 돌리고, 오른쪽 보조 AI로는 Copilot이나 JetBrains AI를 붙이게 된다. 어느 순간 IDE는 디버깅 도구만이 아니라, CLI를 다중으로 제어하기 위한 거대한 리모컨이 된다.

그렇다고 이 툴들을 버릴 수도 없다. 집중 모드로 들어가면 도커도 관리해야 하고, 메모리 릭 도구도 써야 하고, 코드 퀄리티 검사도 로컬에서 직접 돌려봐야 하기 때문이다. 즉 우리는 “IDE를 버리고 AI만 쓰는 시대”로 간 게 아니라, “IDE 안에서 AI와 기존 도구를 동시에 더 많이 다뤄야 하는 시대”로 들어온 셈이다.

그러다 문득 이런 상상을 하게 됐다. “이 많은 CLI를 TUI 멀티뷰로 모아두고, 명령은 만능 리모컨 하나로 제어하면 어떨까?” 그 발상에서 시작한 프로젝트가 AgentZero다.

처음엔 단순했다. 여러 AI CLI를 한 화면에서 보고, 필요한 쪽에 명령을 보내는 정도였다. 그런데 일을 벌려 놓고 보니 리모컨과 CLI들이 조금씩 더 많은 말을 하기 시작했다. 간단한 명령 전달을 넘어서, AI CLI끼리 티키타카까지 가능해졌다. 바로 그 지점부터 통신체계가 눈에 띄게 복잡해졌고, 사람이 제어하기 어려운 수준에 도달했다.

여기서 문제가 더 재밌고 더 무서워졌다. 통합 리모컨으로 TV를 켰는데 에어컨이 켜지고, 냉장고에게 “식혀줘”라고 했더니 전자레인지가 데우는 모드로 들어가는 식이다. 더 골치 아픈 건 이게 항상 틀리는 것도 아니라는 점이다. 어떤 날은 맞고, 어떤 날은 엉뚱하게 반응한다. 그래서 더 헷갈린다. 리모콘이 지능을 달았나? 장치들이 서로의 신호를 잘못 듣고 있나? 아니면 주소 체계 자체가 꼬인 건가?

Image Added

이쯤 되면 이건 그냥 만능 리모컨이 아니라 슈뢰딩거의 리모콘에 가깝다. 버튼을 누르기 전까지는 어떤 장치가 반응할지 확정되지 않고, 버튼을 누른 뒤에도 확률적으로만 맞는 것 같은 이상한 시스템. 개발자 입장에서는 “가끔 되니까 더 위험한” 종류의 버그다.

결국 전체 문제를 해결하려면 버튼을 더 영리하게 누르는 것이 아니라, 누가 어떤 메시지를 받고, 어디까지 전달하고, 누가 책임지고 복구해야 하는지 설계를 다시 해야 했다.

여기서부터는 단순 채팅 앱이 아니라 작은 애니메이션 관제실이 된다. 성격 다른 조연들이 한 무대에 올라와 서로 대사를 주고받기 시작했는데, 감독이 큐 사인을 놓치면 순식간에 장면이 무너지는 구조다문제는 그 다음 장면이다. 사용자가 “Claude1은 코드 리뷰하고, Claude2는 테스트 돌리고, Claude3는 회의록 정리해. 사회자는 전체 상황을 보고 조율해.”라고 말하는 순간, 앱은 단순 채팅창이 아니라 작은 관제실이 된다. 누가 누구에게 말을 걸었는지, 누가 대기 중인지, 어느 터미널이 죽었는지, 지금 전체 방이 어떤 상태인지 한 번에 알아야 한다.

AgentWin에서 AgentZero에서 이 장면을 구현하다 보니 기존 WPF 콜백 구조는 바로 한계에 부딪혔다. 그래서 선택한 것이 Akka.NET 액터 모델이다.

1. 토이 스토리의 장난감 회의실 — Akka 1분 요약

...

2. 어벤져스 작전실 — 콜백 4개 구조가 왜 막혔나

Image Added

AgentWin의 AgentZero의 초기 구조는 전형적인 WPF 코드비하인드였다. MainWindow와 AgentBotWindow가 콜백 4개로 연결되어 있었다.

...

3. 주토피아 교통관제실 — 액터 4개로 만든 작은 도시

Akka를 도입하면서 AgentWin은 AgentZero는 화면 중심 구조에서 도시 구조로 바뀌었다.

ActorSystem("AgentZero")
└── /user/stage          (StageActor)
      ├── /bot           (AgentBotActor)
      ├── /ws-proj1      (WorkspaceActor)
      │     ├── /term-0  (TerminalActor)
      │     └── /term-1  (TerminalActor)
      └── /ws-proj2      (WorkspaceActor)
            └── /term-0  (TerminalActor)

...

6. 인크레더블의 안전 매뉴얼 — 감독 전략은 예외별로 다르게

Image Added

액터 모델의 또 다른 핵심은 장애 처리다. 처음엔 모든 예외를 Restart로 몰아도 될 것처럼 보인다.

...

7. 가디언즈 오브 갤럭시 영입전 — 7단계 점진 통합

Image Added

새 구조가 좋다고 기존 코드를 하루아침에 다 갈아엎을 수는 없다. AgentWin은 AgentZero는 이 이행을 7단계로 쪼갰다.

...

9. 엔드게임 회의록 — 3인 미팅은 실제로 어떻게 돌아갔나

Image Added

모든 구조와 가드를 넣고 나서야 아래 시나리오가 깨끗하게 돌아갔다.

...

이번 1편은 왜 여러 AI 터미널 협업이 콜백 구조로는 쉽게 무너지는지, 왜 Akka의 액터 트리가 이 문제를 잘 정리하는지, 실제 AgentWin이 AgentZero가 어떤 관제 구조를 세웠는지를 먼저 보여줬다.

하지만 아직 남은 질문이 있다.

...