‘LLM 호출' 하나가 아키텍처를 바꿨다: AI가 들어온 소프트웨어, 설계 패턴이 달라진다.

표준 프로토콜·에이전트 오케스트레이션·거버넌스 계층이 새 기본 구조로 … '확률적 부품을 결정적 구조로 감싼다'.

AI 에이전트가 기업 소프트웨어의 구성 요소로 자리 잡으면서 소프트웨어 아키텍처의 기본 패턴이 달라지고 있다. 같은 입력에 같은 출력을 내던 결정적 부품 위에 세워진 기존 설계에, 같은 요청에도 결과가 달라질 수 있는 확률적 부품이 들어왔기 때문이다. 업계에서는 이 변화를 크게 보면 '연결 방식의 표준화', '여러 에이전트를 조율하는 오케스트레이션 구조의 정립', '정책 집행을 맡는 게이트웨이와 컨트롤 플레인의 등장', '개발 프로세스 자체의 스펙·제약 중심 재편'으로 정리한다.

무엇이 달라졌나: 모듈 호출에서 '위임'으로

전통적인 아키텍처에서 시스템 구성 요소는 정해진 인터페이스를 통해 정해진 방식으로 호출됐다. 개발자는 입력과 출력의 계약을 정의하고, 그 계약이 지켜지는 한 부품의 내부 동작을 신경 쓸 필요가 없었다. 마이크로서비스, API 게이트웨이, 이벤트 기반 아키텍처는 모두 이런 가정 위에 서 있다.

AI 에이전트는 이 가정을 흔든다. 에이전트는 의도를 해석하고 단계를 계획하며 도구와 API를 통해 행동한다. 호출하는 쪽은 '무엇을 하라'가 아니라 '목표를 달성하라'고 위임하고, 어떤 도구를 어떤 순서로 쓸지는 에이전트가 정한다. 시스템 설계자는 에이전트가 무엇을 할 수 있고 무엇을 해서는 안 되는지를 구조로 정의해야 한다. 한 분석은 이를 두고 다중 에이전트 시대에 아키텍처가 단일 기능이나 챗봇이 아니라 거버넌스, 관측 가능성, 통제된 쓰기 권한을 갖춘 오케스트레이션 런타임을 만드는 일이 된다고 설명한다.

변화 1. 연결 계층의 표준화: MCP와 A2A

가장 눈에 띄는 변화는 에이전트가 시스템과 연결되는 방식이 표준화되고 있다는 점이다. 앤트로픽이 2024년 말 공개한 모델 컨텍스트 프로토콜(MCP)은 에이전트가 도구와 데이터 소스, 프롬프트에 접근하는 방식을 클라이언트-서버 구조로 정리한 개방형 표준이다. 구글이 제안한 에이전트 간 프로토콜(A2A)은 에이전트끼리 작업을 위임하고 조율하며 맥락을 공유하는 방식을 다룬다.

업계에서는 MCP를 '수직 통합', A2A를 '수평 통합'에 비유한다. MCP는 에이전트가 아래로 도구 계층과 연결되는 길이고, A2A는 에이전트들이 옆으로 협업하는 길이다. 두 프로토콜은 경쟁 관계라기보다 상호 보완 관계로 평가되며, 대다수 기업 환경에서는 두 계층이 모두 필요하다는 진단이 우세하다. 실무에서 거론되는 절충안은 결정적인 도구 호출, 즉 데이터베이스 조회나 API 호출에는 MCP를 쓰고, 다른 에이전트의 맥락적 추론이 필요한 작업에만 A2A를 쓰는 하이브리드 구조다.

거버넌스 측면의 움직임도 빠르다. 앤트로픽은 2025년 12월 MCP를 리눅스 재단 산하의 '에이전틱 AI 재단(AAIF)'에 기증했다. 이 재단은 앤트로픽, 블록, 오픈AI가 공동 설립했고 구글, 마이크로소프트, AWS 등이 지원한다. 오픈AI의 AGENTS.md , 블록의 goose와 함께 창립 프로젝트가 됐다. 구글의 A2A도 앞서 리눅스 재단으로 이관돼 100곳이 넘는 기술 파트너가 참여하고 있고, IBM의 에이전트 통신 프로토콜(ACP)도 A2A로 흡수되는 흐름이다. 특정 기업의 규격이 아니라 중립 기구가 관리하는 '공용 배관'으로 옮겨가면서, 기업은 모델이나 벤더를 바꾸더라도 연결 계층을 다시 짜지 않아도 되는 기반을 확보하게 됐다.

다만 신중론도 있다. 일부 개발자들은 생긴 지 1년 남짓한 프로토콜이 재단으로 넘어가기에는 이르다며, 안정성이 아직 충분히 검증되지 않았다고 지적했다. 표준이 빠르게 자리 잡고 있지만 성숙까지는 시간이 필요하다는 뜻이다.

변화 2. 오케스트레이션 토폴로지의 정립

에이전트가 여러 개로 늘면 '누가 누구에게 일을 시키는가'가 설계의 핵심이 된다. 업계 분석에서는 운영 환경의 다중 에이전트 시스템이 대체로 몇 가지 구조로 수렴한다고 본다.

오케스트레이터-워커형 : 중앙 조율자가 작업을 쪼개 전문 에이전트에 나눠 주고 결과를 모은다. 가장 널리 쓰이는 구조로 꼽힌다.

슈퍼바이저형 : 조율자가 결과를 평가하고, 반복하거나 중단할지까지 판단한다. 오류 비용이 큰 컴플라이언스 검토 같은 업무에 맞는다.

계층형 : 슈퍼바이저 아래 또 다른 슈퍼바이저를 두는 다단 구조로, 복잡도가 가장 높다.

파이프라인·라우터형 : 에이전트를 순차로 잇거나, 요청을 성격에 따라 전문 에이전트로 분기한다.

한 분석에 따르면 기업 환경의 에이전트 도입 가운데 60% 이상이 슈퍼바이저 또는 오케스트레이터-워커 패턴을 쓴다. 여러 패턴을 혼합하는 경우도 많다. 다만 각 구조에는 대가가 따른다. 조율자가 병목이 될 수 있고, 슈퍼바이저가 모든 결과를 읽다 보니 토큰 비용이 커질 수 있다. 여러 에이전트가 얽힌 시스템은 디버깅이 어렵다는 지적도 공통적이다. 실무 지침으로는 일부 에이전트가 실패하는 상황을 전제로 설계하고, 타임아웃과 최대 반복 횟수, 교착 상태 탐지를 넣으며, 한 에이전트를 시스템 전체 재배포 없이 갱신할 수 있게 하라는 조언이 나온다. 단순하게 시작해 필요할 때 구조를 키우라는 권고가 많다.

변화 3. 게이트웨이와 컨트롤 플레인: 정책은 '에이전트 바깥'에서 집행한다

에이전트가 도구와 시스템을 직접 호출하기 시작하면서 새로운 계층이 등장했다. 기존 API 게이트웨이가 하던 인증, 요청 제한, 분석 기능을 LLM 호출과 도구 호출, 에이전트 간 위임까지 확장한 ‘AI 에이전트 게이트웨이'다. LLM 게이트웨이는 여러 모델 공급자로 요청을 분배하고 장애 시 자동 전환하며, 예산과 정책을 한 곳에서 관리하는 계층으로 자리 잡고 있다. 업계에서는 이를 운영용 AI의 컨트롤 플레인으로 부르기도 한다.

구조의 특징은 컨트롤 플레인과 데이터 플레인의 분리다. 컨트롤 플레인은 에이전트의 신원, 허용 권한, 정책, 도구 카탈로그 같은 '원하는 상태'를 관리하고, 데이터 플레인은 실제 트래픽에서 그 정책을 즉시 집행한다. 컨트롤 플레인과의 연결이 일시 끊겨도 데이터 플레인은 마지막으로 승인된 정책을 계속 적용하도록 설계한다. 한 설계 지침은 에이전트가 계속 가동되므로 행동을 배포 시점이 아니라 실행 시점에 통제해야 한다고 강조한다. 도구의 보안을 목적지 서비스에서만 집행하는 방식은 안티패턴으로 꼽힌다. 에이전트의 계획이나 예산 같은 맥락 정보는 게이트웨이 경계에서만 알 수 있기 때문이다.

이는 앞서 설명한 O-ring 구조와도 맞닿는다. 에이전트 하나하나의 능력이 높아져도 사슬 전체의 신뢰도는 가장 약한 고리가 정한다. 권한 경계, 사람의 승인 단계, 감사 추적 같은 통제 계층이 곧 그 약한 고리를 보강하는 장치다.

변화 4. 관측과 평가가 ‘1급 시민'이 된다

결과가 비결정적이라면 '동작하는지'만으로는 품질을 보장할 수 없다. 그래서 관측 가능성과 평가(eval)가 아키텍처의 필수 구성 요소로 올라섰다. 업계 분석은 운영 단계의 AI 시스템도 일반 소프트웨어와 같은 수준의 모니터링, 알림, 디버깅, 성능 관리, 지속적 평가 인프라가 필요하다고 본다. 게이트웨이는 에이전트에서 LLM, 도구, 다른 에이전트로 이어지는 호출 전체를 하나의 추적으로 엮어, 비용과 행동을 재현할 수 있게 하는 역할도 맡는다. 코드가 바뀌지 않았는데 동작이 달라질 수 있는 시스템에서는 '배포 전 테스트'보다 '운영 중 평가'의 비중이 커진다.

변화 5. 데이터 계층: 검색을 넘어 의미 구조로

지식을 다루는 방식도 달라지고 있다. 업계에서는 2026년을 ‘LLM이냐 전통 시스템이냐'의 논쟁이 끝나고 하이브리드 구조가 자리 잡는 해로 본다. 그 한 갈래로 의미적 지식 그래프를 뼈대로 삼는 그래프RAG(GraphRAG)가 거론된다. 흩어진 데이터 사일로를 연결하고 거버넌스가 적용된 AI 플랫폼으로 바꿔야 단편적 지능이 조율된 통찰로 이어진다는 시각이다. 구조화된 데이터와 설명 가능성이 기업 신뢰의 기반이라는 점도 강조된다.

변화 6. 개발 프로세스: 스펙과 제약이 코드보다 앞선다

아키텍처 패턴의 변화는 소프트웨어를 만드는 방식에도 번지고 있다. AI 코딩 에이전트는 구현 속도를 크게 끌어올렸지만, 그 결과를 그냥 받아들이면 시스템이 서서히 어긋나는 문제가 생긴다. 이를 막으려는 접근이 '스펙 주도 개발(Spec-Driven Development)'이다. 사람의 의도와 AI가 만든 코드 사이에 명세 계층을 넣어, 요구사항을 먼저 쓰고 검증하고 합의한 뒤 구현에 들어가는 방식이다. 오픈소스 스펙 프레임워크와 AI 코딩 도구들이 이 흐름을 따르고 있다. 한 유럽 개발자 콘퍼런스의 워크숍은 아키텍처 규칙과 불변 조건, 금지 패턴을 '헌법'처럼 정의하고, AI가 만든 코드를 그 명세에 자동으로 대조하는 검증 루프를 소개한다. 학계에서도 코드가 변하는데 명세가 따라가지 못하는 '조용한 스펙 이탈'과, 저장소 전체를 한꺼번에 이해해야 하는 '컨텍스트 폭발'을 AI 지원 개발의 구조적 실패 모드로 짚는 논문이 나왔다.

이와 짝을 이루는 개념이 '아키텍처 적합도 함수(fitness function)'다. 소프트웨어 아키텍트 닐 포드는 비결정적인 코드 생성을 결정적인 가드레일로 묶어야 한다고 강조한다. 아키텍처 규칙을 코드로 정의해 두면 에이전트가 그 제약 안에서 해법을 찾아가고, 성공 여부도 자동으로 판정할 수 있다. 의존 경계, 금지된 코드 패턴, 비밀 정보 노출 점검 같은 검사를 커밋마다 돌리고, 아키텍처를 감시하는 별도의 에이전트가 브랜치마다 검토하는 사례도 오픈소스 프로젝트에서 나타났다. 포드는 경험 있는 엔지니어는 AI로 배가되지만, 0에 10을 곱해도 0이라는 점을 강조한다. 설계 역량이 없으면 AI의 속도도 의미가 없다는 뜻이다.

남은 과제

이 패턴들이 곧바로 정답인 것은 아니다. 몇 가지 쟁점이 남아 있다.

첫째, 프로토콜의 성숙도다. MCP와 A2A 모두 빠르게 진화 중이고, 한 가지에만 걸었다가 1년 안에 오케스트레이션 계층을 다시 짜게 될 것이라는 경고도 나온다. 둘째, 복잡도 비용이다. 에이전트가 늘수록 디버깅과 비용 관리가 어려워지고, 조율자나 슈퍼바이저가 병목이 될 수 있다. 셋째, 운영 데이터의 부족이다. 한 분석은 20252026년 기업 현장의 다중 에이전트 운영 성능을 보여주는 정량적 벤치마크가 아직 없다고 지적했다. 실험실 벤치마크가 현장의 성공률이나 부하 상황의 지연 시간으로 곧바로 이어지지 않는다는 것이다. 넷째, 인력이다. 에이전트 시스템을 실제로 설계하고 배포해 본 시니어 엔지니어가 부족하다는 점은 그대로 병목으로 남는다.

결론: 확률적 코어, 결정적 껍질

종합하면 AI가 반영된 소프트웨어의 새 아키텍처는 하나의 원칙으로 요약된다. CPL(Contextual Persistency Layer) 처럼 AI를 감싸 안은 새로운 계층이 필요하다. 확률적으로 움직이는 AI 부품을 결정적인 구조로 감싼다 는 것이다. 표준 프로토콜이 연결을 정리하고, 오케스트레이션 토폴로지가 역할을 나누며, 게이트웨이와 컨트롤 플레인이 정책을 집행하고, 관측과 평가가 품질을 확인하며, 스펙과 적합도 함수가 개발 과정을 제약한다. 모델은 빠르게 바뀌지만 이 껍질은 오래 남는다. 기업의 경쟁력이 어떤 모델을 쓰느냐보다 이 구조를 얼마나 잘 설계하고 운영하느냐에서 갈릴 것이라는 전망이 나오는 이유다.

본 콘텐츠는 글로벌 IT 아키텍처 컨설팅 회사 CHRISCOMPANY의 기술 인사이트를 바탕으로 제공됩니다. 발행: 크리스미디어 (CHRISMEDIA)