[박준성의 SW] AI 에이전트 아키텍처는?

서비스 지향 아키텍처(SOA, Service-Oriented Architecture)는 2000년대 초 W3C에서 웹서비스 표준(SOAP, WSDL 등)을 제정하면서 더욱 본격화됐다. 아마존은 2002년에 SOA를 회사의 SW 개발 표준으로 채택했고, 이후 IaaS의 중요한 기반이 되었다. 아마존이 클라우드 서비스를 Amazon Web Services라 부른 배경과도 관련이 있다. 가트너에 따르면 2000년대 말에는 조사 기업의 80% 이상이 SOA를 도입하거나 검토했다.

아마존은 대규모 고객과 트랜잭션을 처리하기 위한 높은 확장성과 빠른 변화 대응을 위해 2000년대 중반 이후 개발 조직을 소규모 팀으로 나누고, 각 팀이 소수의 SOA 서비스를 소유하며 이를 독립적으로 배포하는 구조를 발전시켰다. 이 과정에서 SOA는 점차 마이크로서비스 아키텍처(Microservice Architecture, MSA)로 진화했고, 결국 MSA는 데브옵스(DevOps)를 효과적으로 구현하기 위한 SOA의 진화된 아키텍처로 볼 수 있다.

2010년대 초반부터 ThoughtWorks, Pivotal Software, IBM 등의 컨설팅 및 플랫폼 업체들은 아마존, 넷플릭스 등 웹 스케일 기업들이 적용하던 SOA 구현 패턴을 '마이크로서비스 아키텍처'라는 용어로 정립·확산시키며 일반 기업으로 전파하기 시작했다.

한편 가트너에 따르면, 2010년대 중반 이후 많은 기업들이 MSA 전환의 복잡성과 와해성으로 인해 순수한 마이크로서비스 대신 더 큰 서비스 단위를 사용하고 DB 공유를 허용하는 접근(일명 Gartner가 ‘miniservice’라고 부른 방식)을 채택하는 경향을 보였다.

국내서도 2010년대 중반부터 2020년대 초까지 많은 기업들이 MSA에 대한 충분한 이해 없이 과도한 기대 속에 도입을 추진했다. 이후 시간이 지나면서 이러한 접근의 한계가 드러나자, 일부 기업에서는 보다 단순하고 관리 가능한 구조로의 재조정이 이뤄지고 있다. 이 과정에서 Modulith(Modular Monolith, 모듈리스)가 주목받고 있으며, 이는 SOA의 일부 원칙을 재해석한 아키텍처 스타일로 볼 수 있다. Modulith는 애플리케이션을 논리적인 모듈 단위로 분할하고, 모듈 간에는 명확히 정의된 인터페이스를 통해 상호작용하도록 하면서도, 물리적으로는 하나의 애플리케이션으로 통합해 배포하는 구조다.

아래 표는 2005년경 확산되기 시작한 웹 서비스 기반의 SOA, 2015년경 확산되기 시작한 MSA, 그리고 2025년 확산되기 시작한 Modulith가 적용하는 아키텍처 패턴들을 비교, 보여주고 있다. 표에서 노란색 부분이 Modulith 적용 패턴들이다.

지난 20년간 SOA 구현 기술들은 크게 발전했다. 이에 따라 Modulith에서는 웹서비스(Web Services)보다는 레스트(REST) 스타일을, 전통적인 ESB나 상용 애플리케이션 서버 중심 구조보다는 애플리케이션 프레임워크, 이벤트 기반 통신, API 계층 등의 보다 경량화된 접근을 상황에 따라 활용하는 경향이 있다. 다만 이러한 기술들은 필수 요소라기보다 선택적으로 적용된다.

한편 MSA에서 강조되던 서비스별 DB 소유, Event Sourcing, 서비스별 독립적 배포 등의 패턴은 운영 복잡성 때문에 Modulith에서는 일반적으로 단순화되거나 제한적으로 적용된다. (박준성, The Complete Guide to SOA, MSA and Modulith, KOSTA Online, 2025: https://www.kosta-online.com/post/the-complete-guide-to-soa-msa-and-modulith)

Modulith의 개발 프로세스는 DevOps 특징 중 하나인 팀별 독립적 배포는 적용하지 않지만, 릴리즈 사이클 단축과 신뢰성 향상을 위한 CI/CD, IaC, 모니터링·트레이싱·로깅을 통한 Dev와 Ops 간의 긴밀한 피드백 루프는 그대로 유지한다. 한편 AI 에이전트의 비결정적(확률적)이고 상태를 가지는 실행 특성과 ReAct-Reflection 루프를 고려한 개발·운영 방식은 일반적으로 AgentOps라고도 불린다.

Modulith와 MSA의 중간 형태에 해당하는 아키텍처 스타일도 존재한다. 이러한 접근에서는 애플리케이션을 마이크로서비스보다 더 큰, 더 적은 수의 서비스로 분할하고, DB 공유를 허용하는 경우가 많으며 필요에 따라 일부 분리하기도 한다. 또한 완전한 서비스별 독립 배포 대신 필요에 따라 부분적으로 분리 배포를 허용한다. 이 범주에 속하는 SOA 아키텍처 스타일로는 가트너가 2017년 언급한 ‘miniservice’ 접근과, Mark Richards와 Neal Ford가 정리한 Service-Based Architecture(SBA)가 있다.

결국 하나의 애플리케이션 전체를 특정 SOA 아키텍처 스타일로 일괄 적용하기보다는, 각 유스케이스 또는 비즈니스 서브도메인별로 다양한 설계 및 구현 패턴 중 적합한 것을 선택하는 하이브리드(Hybrid) 접근이 실무적으로 효과적인 방식으로 널리 받아들여지고 있다.

국내에서도 마이크로서비스 하이프(Hype)에 영향을 받아 과도한 MSA 교육과 파일럿 프로젝트, 그리고 운영 복잡성으로 어려움을 겪었던 사례들이 있었으나, 최근에는 이러한 접근에 대한 재평가가 이루어지면서 보다 현실적인 아키텍처 선택이 이루어지고 있다.

Spring Boot, Spring Modulith, Express, NestJS, Django, FastAPI, Flask 등 애플리케이션 프레임워크의 발전으로 REST 기반 서비스 구현의 생산성은 크게 향상되었지만, SOA 서비스 식별, API 설계, 서비스 컴포지션, 서비스 인벤토리 관리, 그리고 서비스 거버넌스 확립은 여전히 높은 수준의 아키텍처 역량과 공학적 훈련을 요구한다. 따라서 단순한 기술 도입에 대한 투자보다는 SOA의 기본 원칙과 서비스 설계 역량에 대한 체계적인 투자가 더욱 중요하다.

AI 시대를 맞아 생성형 AI 및 AI 에이전트 기반의 AI-Native 애플리케이션은 GitHub Copilot과 Claude Code와 같은 AI 코딩 도구 및 에이전트 기반 개발 도구를 활용하여 개발되고 있다. 이러한 애플리케이션은 기능을 명확히 분리하고 재사용성을 높이기 위해 SOA 스타일의 구조가 매우 적합하며, 실제로 서비스 단위로 분해된 구조로 구현되는 경우가 많다.

아래 그림은 SOA 스타일로 구성된 AI 에이전트의 논리적 아키텍처를 보여주며, 각 블록은 기능적으로 분리된 논리적 서비스(또는 컴포넌트)로 이해할 수 있다. 이러한 구조에서 에이전트는 여러 서비스를 동적으로 조합하고 오케스트레이션하는 역할을 수행한다. (박준성, AI Agent의 허허 실실, KOSTA Online, 2026: https://www.kosta-online.com/post/ai-agent-hype-and-reality)

외부 이벤트가 에이전트를 트리거하면, 오케스트레이터(Orchestrator), 즉 워크플로우 레이어가 상황 인지(Perception) 서비스를 호출하여 에이전트 목표 정의, 달성 정도, 세션 히스토리 등의 상황 정보를 확보한 후, 프롬프트 조립(Prompt Assembly) 서비스를 호출하여 프롬프트를 조립한다.

워크플로우는 RAG 서비스를 호출해 기업 내 정보를 확보하고, 프롬프트를 보완한 후, 행동 계획(Planning) 서비스를 호출한다. 이 서비스는 LLM 추론을 통해 행동(Action) 계획을 수립한다. LLM 서비스의 AI 추론은 Gen AI 벤더들이 제공하는 기본 모델(Foundation Model)을 모델 레지스트리 또는 API를 통해 사용한다.

워크플로우는 다음에 정책(Policy) 서비스를 호출하여 계획된 행동이 정책, 보안, 예산 등의 제약 조건을 위반하지 않는지 검증한다. 워크플로우는 검증된 행동 계획을 실행하는 데 필요한 툴들을 선정하고, MCP를 통해 툴(MCP 서버)에 접근하여 호출한다. 워크플로우는 다음에 행동 실행(execution) 서비스를 호출하여 관련 실행 시스템들을 수행시킨다. 행동 실행 서비스는 코레오그래피를 통해 에이전트 간 통신 프로토콜(일명 A2A) 서비스를 가동하여 타 에이전트들을 실행시킬 수 있다.

행동 실행 서비스가 계획된 행동을 실행하는 동안, 코레오그래피를 통해 모니터링(Monitoring) 서비스를 작동시켜 실행 로그와 소요 비용을 기록하고, 평가(evaluation) 서비스를 가동시켜 행동 실행 결과를 평가한다. 또한 학습 서비스를 가동시켜 평가 결과로부터 학습(Learning)된 교훈을 기록한다. 학습된 교훈은 직접적인 모델 파라미터 학습에는 제한적으로만 활용되며, 주로 프롬프트, RAG, 정책 등에 피드백된다. 따라서 생성형 AI 에이전트는 상황적응적(Adaptive) AI 시스템이지만, 전통적인 의미의 지속적 학습형 AI와는 차이가 있다.

워크플로우는 행동 실행 계획의 자동 실행이 완료되면, 정책 서비스를 호출하여 행동 실행 결과의 적합성을 판단한다. 다음, 상황 인지 서비스를 호출하여 행동 실행의 결과 상황을 업데이트하고, 에이전트 종료 결정(Termination) 서비스를 호출하여 에이전트 반복 주기의 계속 또는 종료 여부를 결정한다. 반복 주기가 계속될 경우에는 오케스트레이터가 상황 인지 서비스, 프롬프트 조립 서비스 순으로 다시 다음 주기를 시작한다.

생성형 AI의 본질적 허점이 유발하는 오류(Hallucination)와 위험을 완화하고 통제하기 위해, 사람(전문가)이 프롬프트 조립, 행동 계획, 행동 실행, 정책 검증, 평가, 학습, 에이전트 종료 등 여러 단계에 개입하여 에이전트 산출물의 품질을 보완하고 책임져야 하는 경우가 많다.

생성형 AI 에이전트의 물리적 배포 아키텍처는 MSA, SBA, Modulith 중 하나를 선택하는 문제가 아니라, 이들 아키텍처 스타일을 어떻게 조합할 것인가의 문제이다. 보다 구체적으로는, AI 에이전트를 구성하는 어떤 기능 또는 서비스는 모노리스(Monolith)로 통합 배포하고, 어떤 부분은 서비스별로 독립 배포하는 것이 적절한지를 판단해야 한다. 또한 서비스별 독립 배포를 적용할 경우에도 데이터의 특성에 따라 DB를 분리할 것인지, 일부 공유할 것인지에 대한 전략적 선택이 필요하다.

다음에서는 이러한 AI 에이전트의 물리적 아키텍처 구현 패턴에 대해 살펴본다. 아래 그림은 생성형 AI 에이전트의 물리적 배포 아키텍처를 보여주며, 빨간색 선은 물리적 배포 단위를 나타낸다.

사용자, 웹모바일 앱, API 게이트웨이 등 클라이언트 단에서 에이전트 레이어를 호출한다. 에이전트들은 워크플로우, 프롬프트, 정책 등을 포함한다. 에이전트들은 같은 비즈니스 도메인에 속한 것들끼리 묶어 도메인별로 단위 서비스로 설계하고 각 서비스를 별개 팀에게 배정할 수 있지만, 에이전트 계층 전체를 모노리스로 통합하여 배포하는 게 일반적으로 권장된다. 극단적인 Scalability나 Agility를 요구하는 서비스에 대해서만 예외적으로 MSA를 적용할 수 있다.

빠르게 반복되는 에이전트 루프 속에서 워크플로우가 비결정적(Nondeterministic)이고, 따라서 에이전트 호출도 실행 시에 동태적으로 결정되기 때문에, 에이전트들을 물리적으로 분산할 경우 일관된 상태 관리 및 컨텍스트 유지, 서비스 및 툴의 버전관리, 서비스 간 의존성 관리, 트레이싱/로깅/메트릭 등의 관측성(Observability) 확보, 디버깅 등 유지보수 및 운영의 복잡성이 크게 증가하며, 네트워크 지연과 분산 실행의 실패 복구 문제도 성능에 영향을 미칠 수 있다.

플랫폼 레이어의 Core 서비스들은 오케스트레이터, 상황 인지 및 정책 서비스와 에이전트 루프, 즉 행동 계획 → 행동 실행 → 모니터링 → 평가 → 학습 서비스들을 포함한다. Cross-Cutting 서비스들은 프롬프트/형상 관리, 관측성 관리, 원가 트래킹, 보안/접근 제어 등을 포함한다. 플랫폼을 구성하는 서비스들은 빠른 속도로 반복되는 Tightly-Coupled 런타임으로 여러 서비스로 분산하여 배포하기보다는 모노리스로 통합하여 배포하는 것이 일반적으로 유리하다.

비즈니스 로직을 실행하는 도메인 서비스 레이어는 Bounded Context 단위로 SOA 서비스를 설계하여 미니 서비스나 마이크로 서비스로 구현하거나 필요에 따라 Modulith 내부에 포함할 수 있다. 외부 시스템이나 인프라 시스템의 경우에는 이미 독립적으로 배포 가능한 SOA 서비스 형태로 제공되는 게 일반적이다.

이와 같이 AI 에이전트 시스템은 전반적으로 Modulith, Miniservice(Service-Based Architecture), Microservice가 조합된 하이브리드 아키텍처로 구성하는 것이 실무적으로 효과적인 접근이다.

◆ 필자 박준성은...

서울대 경영학 학사 및 석사, 미국 오하이오주립대 전산학/산업공학 학제간 박사를 취득했다. 미국 아이오와대학(University of Iowa)에서 MIS 분야 종신교수로 재직하면서 미국 INFORMS 통신학회 회장을 역임했다.