에이전트 = 마이크로서비스? 2017년 석사 논문이 예견했던 것

2017년, 저는 멀티 에이전트 시스템 (multi-agent systems)을 마이크로서비스 (microservices)로 구현할 수 있다고 주장하는 석사 논문을 작성했습니다. 8년이 지난 지금, 모두가 "AI 에이전트 (AI agents)"를 구축하고 있으며, 대부분은 제가 당시에 설계했던 내용을 그대로 재발견하고 있습니다. 여기 핵심적인 통찰과 변하지 않은 점, 그리고 제가 틀렸던 점을 정리했습니다.

저는 간단한 문제를 해결하려 했습니다. 사용자가 실제로 사용하는 서비스가 무엇이든 그에 맞춰 적응하는 개인 비서를 만드는 것이었습니다. Google Calendar인가, Microsoft인가? 집인가, 사무실인가? 전화기인가, 데스크톱인가? 비서는 사용자가 어디에 있는지와 지금 무엇이 중요한지를 파악해야 했습니다.

당연한 아키텍처 (architecture)는 멀티 에이전트 시스템이었습니다. 하지만 기존의 에이전트 프레임워크 (agent frameworks) (JADE, NetLogo)는 개미 군집, 질병 확산, 공장 최적화와 같은 **시뮬레이션 (simulations)**을 위해 구축되었습니다. 실제 인프라에서 실행되는 프로덕션 시스템 (production systems)을 위한 것이 아니었습니다.

반면, 마이크로서비스는 바로 그것을 위해 설계되었습니다. 배포하고, 확장하고, 독립적으로 실패하며, API를 통해 통신하는 것입니다. 그래서 저는 질문했습니다: 이 두 개념은 실제로 같은 것인가?

다음은 논문에 수록된 표입니다 (번역):

속성	에이전트 (Agent)	마이크로서비스 (Microservice)
자율성 (Autonomy)	✅ 예	✅ 예
주도성 (Proactivity)	✅ 예	❌ 해당 없음
시스템 회복탄력성 (System resilience)	✅ 예	✅ 예
배포 용이성 (Ease of deployment)	❌ 해당 없음	✅ 예

결론: *"에이전트와 마이크로서비스는 완전히 다른 도메인(소프트웨어 공학 vs 인공지능)에서 유래했음에도 불구하고, 많은 속성에서 놀라울 정도로 유사하다."

논문은 개인 비서를 구성하는 세 가지 에이전트 그룹을 식별했습니다:

외부 서비스를 래핑(wrap)하는 에이전트: 이메일, 캘린더, GPS, 데이터베이스, 디스플레이 장치 등. 각 리소스는 통일된 인터페이스를 가진 자체 에이전트를 가집니다.

현대의 대응물: LLM 에이전트 프레임워크의 API 래퍼 (API wrappers), 커넥터 (connectors), 도구 (tools). 아이디어는 같고 시대만 다릅니다.

다른 여러 에이전트가 사용하는 공통 문제를 해결하는 에이전트. 예: GPS, WiFi 삼각 측량, 캘린더 컨텍스트를 결합하여 사용자의 위치를 결정하는 것.

현대적 대응물: 유틸리티 함수 (utility functions), 임베딩 서비스 (embedding services), 공유 RAG 파이프라인 (shared RAG pipelines). 에이전트의 행동에 적용된 "중복 방지 (Don't Repeat Yourself)" 원칙.

실제 추가된 기능을 포함하는 에이전트. 이들은 원시 데이터 소스 (raw data sources)를 직접 다루지 않으며, 목표를 달성하기 위해 리소스 (Resource) 에이전트와 헬퍼 (Helper) 에이전트를 조합합니다.

현대적 대응물: 에이전트 그 자체 — 결정하고, 경로를 지정하며, 행동하는 주체.

시간이 흘러도 변치 않는 통찰: 멀티 에이전트 시스템 (multi-agent system) 내에서의 관심사 분리 (separation of concerns)는 마이크로서비스 경계 (microservice boundaries)를 설계하는 문제와 동일하다.

에이전트에는 지능뿐만 아니라 인프라가 필요합니다. 오늘날 대부분의 "AI 에이전트" 프레임워크는 함수 호출 (function-calling) API를 갖춘 미화된 LLM 래퍼 (wrapper)에 불과합니다. 메시지 라우팅 (message routing), 회복 탄력성 (resilience), 서비스 발견 (discovery), 배포 (deployment)와 같은 어려운 부분은 정확히 마이크로서비스 플랫폼이 10년 전에 해결했던 문제들입니다. -
주도성 (Proactivity)이 차별화 요소입니다. 마이크로서비스는 반응적 (reactive)입니다. 즉, 요청에 응답합니다. 에이전트는 주도적 (proactive)입니다. 즉, 행동을 개시할 수 있습니다. 이것이 표에서 두 개념이 갈라지는 유일한 지점이며, 오늘날 에이전트 설계에서 가장 어려운 문제입니다. -
"네임스페이스 (namespace)" 문제는 아직 해결되지 않았습니다. 제 학위 논문에서 에이전트들은 공유 메시지 버스 (Vert.x Event Bus)를 통해 통신했습니다. 하지만 주소 지정 (addressing) 방식은 임시방편적이었습니다. 이러한 한계는 제가 현재 연구하고 있는 적절한 네임스페이스 기반 아키텍처 (namespace-based architecture)로 직접적으로 이어졌습니다.

저는 LLM (Large Language Models)을 과소평가했습니다. 2017년 당시 저는 규칙 기반 에이전트 (rule-based agents)와 단순한 휴리스틱 (heuristics)에 대해 생각하고 있었습니다. 단일 모델이 추론 (reasoning), 도구 사용 (tool use), 그리고 자연어 (natural language)를 모두 처리할 수 있다는 아이디어는 실질적인 형태로 존재하지 않았습니다.

저는 Vert.x를 과대평가했습니다. 이벤트 버스 (Event Bus)는 데모용으로는 훌륭했지만, 문자열 주소를 사용하는 평면적인 메시지 네임스페이스 (flat message namespace)는 이질적이고 진화하는 시스템으로 확장될 수 없습니다. 계층 구조 (hierarchy), 와일드카드 (wildcards), 서비스 발견 (discovery)이 필요하며, 이는 바로 Plan 9의 네임스페이스 (namespaces)와 CoRE 리소스 디렉토리 (CoRE Resource Directories)가 해결하는 문제입니다.

"개인 비서"라는 프레임워크는 잘못되었습니다. 2017년에는 모두가 비서(Siri, Google Assistant, Cortana)를 만들고 있었습니다. 알고 보니 더 흥미로운 문제는 일반화된 멀티 에이전트 조정 (generalized multi-agent coordination) — 스마트 홈, 산업용 IoT, 엣지 AI (edge AI)였습니다.

그 논문은 제가 9년 동안 쫓아온 씨앗을 심었습니다:

• 생물정보학 (Bioinformatics): 다종 유전체 분석 파이프라인 — 복잡한 계산 워크플로우의 에이전트와 유사한 분해 (agent-like decomposition).
• Hako: Zephyr RTOS를 위한 Ruby 런타임 (runtime). 에이전트=마이크로서비스라는 아이디어를 가져와 32KB RAM 크기로 축소함.
• Takagi: Sinatra에서 영감을 받은 DSL을 갖춘 CoAP 프레임워크. 만약 마이크로서비스가 HTTP 대신 CoAP를 통해 통신하고, 모든 엔드포인트가 공유 네임스페이스 내의 리소스 (resource)라면 어떨까?

만약 여러분이 2026년에 AI 에이전트를 구축하고 있다면, 여러분은 다음과 같은 문제들을 해결하고 있는 것입니다:

• 2015년에 분산 시스템 (distributed systems) 엔지니어들이 해결했던 문제들 (메시지 라우팅, 회복 탄력성, 발견)
• 1995년에 멀티 에이전트 시스템 (multi-agent system) 연구자들이 해결했던 문제들 (조정, 창발성, 주도성)
• 1992년에 Plan 9이 해결했던 문제들 (모든 것은 파일이다 — 또는 이 경우에는 리소스다)

AI 부분은 새롭습니다. 아키텍처 부분은 그렇지 않습니다. 그리고 이 두 가지를 모두 이해하는 사람들이 차세대 에이전트 시스템을 구축하게 될 것입니다.

아이러니하게도, 모두가 LLM 기반 에이전트를 만들기 위해 경주하는 동안, 저는 반대 방향으로 가고 있음을 느낍니다.

LLM이 쓸모없기 때문이 아닙니다. 결코 그렇지 않습니다. 하지만 저는 더 흥미로운 질문은 이것이라고 믿기 때문입니다: 지능적 행동이 창발하기 위해 필요한 최소한의 요소는 무엇인가?

공유된 네임스페이스 (shared namespace)를 통해 상호작용하는 단순한 메시지 기반 유닛 (message-driven units)으로부터 조정 (coordination), 주도성 (proactivity), 그리고 적응 (adaptation)을 이끌어낼 수 있다면, 400B 파라미터 모델은 필요하지 않습니다. 당신에게 필요한 것은 아키텍처 (architecture)입니다. 발행/구독 (Pub/sub) 모델, 결정론적 보장 (Deterministic guarantees) 같은 것들 말이죠. 에이전트 (agents) 자체가 똑똑할 필요는 없습니다. 시스템이 똑똑하면 됩니다.

그것이 바로 향후 9년 동안 다루게 될 핵심입니다.

만약 에이전트 아키텍처 (agent architecture), 메시지 기반 설계 (message-driven design), 또는 실행되어서는 안 될 곳에서 Ruby를 실행하는 것과 같은 유사한 문제들을 고민하고 있다면, GitHub에서 인사해 주세요.

이 기사는 Qiita Tech Festa 2026의 일부입니다.