AI 에이전트 아키텍처, '모델 경쟁'에서 '구조 경쟁'으로

DoorDash·LinkedIn·AAIF가 보여준 2026년 가을의 세 가지 변화…추론은 줄이고 구조는 단단하게

AI 에이전트가 시연 단계를 지나 운영 시스템의 핵심 구성요소가 되면서, 경쟁의 축이 바뀌고 있다. 어떤 모델을 쓰느냐보다 에이전트를 어떤 구조로 감싸고, 무엇을 실시간 추론에 맡기고 무엇을 미리 처리할지가 성패를 가른다. 지난 열흘 사이 공개된 DoorDash의 식료품 재주문 사례, LinkedIn의 하네스 진화 분석, 그리고 에이전틱 AI 재단(AAIF)의 연례 행사는 이 변화를 서로 다른 각도에서 보여준다.

1. DoorDash: 에이전트 루프에서 '빼는 것'을 설계하다

DoorDash는 AI 기반 식료품 재주문 흐름의 응답 지연을 약 16초에서 2초로 줄였다. 요청이 들어올 때마다 구매 이력을 다시 추론하는 대신, 반복 구매 수요를 미리 계산해 두는 방식으로 구조를 바꾼 결과다. 회사는 쇼핑 리스트 조회가 두 배로 늘었고 해당 흐름의 주문율이 약 34% 올랐다고 밝혔다.

핵심은 처리 시점의 분리다. 오프라인 단계에서는 90일치 구매 이력과 소비자 프로필 신호를 배치 LLM 추론으로 분석해 반복 구매 후보를 뽑고, 결정론적 검증을 거쳐 재사용 가능한 쇼핑 리스트 데이터로 저장한다. 실시간 단계에서는 이 데이터를 불러와 현재 카탈로그와 대조한다. 원래 매장 상품을 먼저 찾고, 없으면 카탈로그 상품 식별자, 그다음에는 검색어 순으로 대체해 품절이나 목록 변경에 대응한다.

(출처: DoorDash Engineering Blog, 「Building Ask DoorDash Part 6」 )

모든 요청이 LLM을 거치는 것도 아니다. 더 저렴한 대안 상품을 찾는 것처럼 추가 추론이 필요한 요청만 식료품 에이전트가 처리하고, 수량 변경이나 상품 삭제 같은 단순 조작은 모델 호출 없이 리스트를 바로 갱신한다. 소비자가 직접 수정한 내용이 우선하며, 다음 에이전트 턴은 대화 이력이 아니라 수정된 리스트에서 출발한다. 대화 기록 대신 사람과 에이전트가 함께 고치는 '구조화된 산출물'을 상태의 기준으로 삼은 셈이다.

이 구조를 떠받치는 것은 공유 에이전트 플랫폼이다. 플랫폼이 오케스트레이션, 메모리, 모델 접근, 트레이싱, 평가 인프라, 롤아웃 제어를 제공하고, 도메인 팀은 에이전트 지침과 스킬, 도구, 평가 기준을 맡는다. DoorDash는 이 방식으로 예약(Reservations) 에이전트를 일주일 만에 추가했으며, 초기 도메인 에이전트 구축보다 약 열 배 빨랐다고 설명했다.

(출처: DoorDash Engineering Blog, 「Building Ask DoorDash Part 4」)

2. LinkedIn: 체인에서 그래프, 그리고 코드로

LinkedIn의 카르틱 람고팔은 InfoQ 기고에서 에이전트 하네스가 체인, 그래프, 코드의 세 단계로 진화해 왔다고 정리했다. 체인은 프롬프트를 선형으로 잇는 초기 방식이다. 지연과 비용이 가장 낮지만, 앞 단계의 실수가 끝까지 전파되는 취약성이 있다. 그래프는 노드와 엣지로 분기, 병렬 처리, 재시도, 상태 관리를 명시적으로 표현한다. 여러 에이전트를 최상위 오케스트레이터가 조율하는 멀티 에이전트 구조로 이어졌고, 에이전트 간 비동기 통신을 위한 A2A 같은 프로토콜이 필요해졌다.

대표적인 멀티 에이전트 아키텍처 (출처: Karthik Ramgopal, 「The Evolution of Agentic Harnesses: From Chains to Graph to Code」)

최근 단계인 코드 하네스는 프롬프트 대신 코드를 추론의 매개체로 삼는다 . 에이전트가 샌드박스에서 코드를 생성하고 실행해 결과를 검증하며, 실패하면 수정해 다시 실행한다. 자연어 출력은 확률적이지만 코드는 통과하거나 실패하는 결정론적 결과를 낸다는 점이 신뢰성을 끌어올린다. 실행 샌드박스, 계측과 로깅, 검증 하네스, 반복 개선 루프가 핵심 구성요소다. LinkedIn은 자연어 분석 질문을 SQL과 파이썬 코드로 바꿔 실행하고 개인정보와 거버넌스 제약을 검증하는 내부 도구에 이 방식을 적용했다고 밝혔다.

설계 원칙 (LinkedIn 제시)

LLM 출력은 검증 전까지 신뢰할 수 없는 입력으로 취급한다.

계획 수립과 실행을 분리하고, 실행은 통제된 소프트웨어 프레임워크 안에서 한다.

단계별 상태, 실행 추적, 검증 결과를 볼 수 있도록 관측성(Obserbavility)에 투자한다.

신뢰성, 속도, 비용을 만족하는 가장 단순한 추상화를 고른다.

람고팔은 정교한 구조일수록 비용과 지연, 운영 복잡도가 성과보다 빠르게 늘 수 있다며, 강한 엔지니어링 조직은 달러당 역량을 최적화하는 곳이라고 강조했다. DoorDash가 '미리 계산해 루프에서 빼는' 선택을 한 것도 같은 맥락으로 읽힌다.

3. AAIF: 프로토콜·샌드박스·신원이 표준화되는 중

구조의 표준화도 빨라지고 있다. 10월 2223일 미국 산호세에서 열린 AGNTCon + MCPCon 북미 2026에서 에이전틱 AI 재단(AAIF)은 알리바바의 OpenSandbox, OpenAI의 Open Responses, Anthropic의 Agent Skills, 허깅페이스의 OpenEnv를 새 프로젝트로 받아들였다. 출범 첫해에 3개였던 프로젝트가 10개로 늘었다. 에이전트 실행 격리, 모델 인터페이스, 스킬 패키징, 학습·평가 환경이 각각 공개 표준의 영역으로 들어온 것이다.

행사의 무게중심은 새 기능에서 보안과 신원으로 옮겨갔다. 발표자들은 도구마다 어노테이션을 달고 스키마를 작게 유지하며, 빌린 사용자 토큰 대신 자체 신원을 가진 에이전트를 전제로 설계하라고 조언했다. MCP 프로토콜 쪽에서는 7월 28일 규격에 상태 비저장 서버가 추가됐고, 호출이 몇 분에서 며칠까지 이어지는 장기 실행 태스크 지원도 공개됐다. 주최 측은 MCP SDK 누적 다운로드가 41억 7천만 건에 이르렀고, 적합성 시나리오 116개 중 약 3분의 1이 보안을 점검한다고 밝혔다. 다만 InfoQ는 일부 수치가 근거 자료 없이 무대에서 제시된 주장이며 보안 확장 일부는 아직 초안 단계라고 짚었다.

시사점: 추론 예산을 어디에 쓸 것인가

세 사례를 관통하는 질문은 '에이전트에게 무엇을 맡기고 무엇을 구조로 해결할 것인가'다. 정리하면 다음과 같다.

시점 분리 : 반복되는 추론은 오프라인에서 미리 처리하고, 실시간 경로에는 최신성이 필요한 해석만 남긴다.

검증의 결정론화 : 모델 출력은 스키마, 규칙, 실행 결과로 검증하고 코드로 확인 가능한 영역을 넓힌다.

상태의 구조화 : 대화 이력보다 사람과 에이전트가 함께 수정하는 산출물을 기준 상태로 삼는다.

플랫폼화 : 오케스트레이션, 메모리, 트레이싱, 평가를 공통 기반으로 두고 도메인 팀은 지침과 도구에 집중한다.

신원과 경계 : 샌드박스, 도구 권한, 에이전트 신원을 프로토콜 수준에서 다룬다.

국내 기업과 공공기관도 에이전트 도입 단계에서 모델 선택에 앞서 이 구조 질문부터 점검할 필요가 있다. 특히 망분리나 데이터 반출 제한이 있는 환경에서는 어떤 단계를 내부에서 미리 계산하고, 어떤 단계를 샌드박스 안에서 검증할지가 아키텍처의 출발점이 될 것이다.

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