AI 에이전트 스택 2026 완전 정리 — 6개 레이어로 이해하는 프로덕션 아키텍처
O'Reilly가 정리한 2026년 AI 에이전트 스택 6개 레이어를 분석합니다. 모델·프로토콜·메모리·프레임워크·옵저버빌리티·가드레일까지, 팀이 실제로 어떤 계층을 선택해야 하는지 의사결정 프레임워크와 함께 정리했습니다.
2026년 AI 에이전트 인프라는 어디까지 왔을까요? O'Reilly의 Paolo Perrone이 2024년 Letta 다이어그램을 업데이트해 발표한 AI 에이전트 스택 2026 에디션을 토대로, 프로덕션 환경에서 실제로 필요한 6개 레이어를 정리합니다.
왜 지금 에이전트 스택인가
팀이 LangGraph로 고객지원 챗봇을 만들기 시작합니다. 3주가 지나면 상태 그래프에 노드가 14개가 됩니다. Redis에 커스텀 체크포인터까지 붙습니다. 그런데 막상 돌아보면 더 단순한 해결책으로 충분했을 때가 많습니다.
O'Reilly가 강조하는 핵심 메시지는 하나입니다. 복잡도를 실제 요구사항에 맞추세요. 6개 레이어를 한꺼번에 쌓는 것이 아니라, 지금 해결해야 하는 문제가 어느 레이어에 속하는지 판단하는 것이 먼저입니다.
6개 레이어 완전 정리
레이어 1: 모델과 인퍼런스
OpenAI, Google, Anthropic 그리고 Llama·DeepSeek 같은 오픈웨이트 옵션이 공존합니다. o1과 Claude의 확장 사고(Extended Thinking) 같은 추론 모델이 등장하면서, 이전에는 여러 단계로 나눠야 했던 체인을 단일 호출로 해결할 수 있게 됐습니다.
프로토타입과 프로덕션 사이의 격차가 가장 작은 레이어이기도 합니다. 모델 자체가 빠르게 진화하고 있어, 기존에 복잡한 파이프라인을 써야 했던 작업이 점차 모델 한 번으로 처리됩니다.
레이어 2: 프로토콜과 툴
MCP(Model Context Protocol) 가 도구 연결을 표준화했고, 주요 AI 랩들이 모두 채택했습니다. Browser Use도 중요한 플레이어로 부상했습니다.
주목할 보안 이슈가 있습니다. MCP 서버의 82%가 경로 탐색(path traversal) 취약점에 노출됐다는 데이터가 있습니다. 에이전트가 도구를 쓰는 순간부터 보안은 선택이 아니라 필수입니다.
레이어 3: 메모리와 지식
"벡터 데이터베이스 = 메모리"라는 단순한 공식에서 벗어났습니다. 2026년에는 3단 메모리 아키텍처가 표준이 됐습니다.
| 계층 | 설명 |
|---|---|
| 인컨텍스트 상태 | 현재 대화/작업의 단기 맥락 |
| 벡터 검색 | 관련 정보를 의미 기반으로 조회 |
| 영속적 크로스세션 메모리 | 세션을 넘어 축적되는 장기 기억 |
컨텍스트 엔지니어링이 핵심 역량으로 부상했고, 많은 팀에서 pgvector가 실용적인 기본 선택으로 자리 잡았습니다.
레이어 4: 프레임워크와 SDK
주요 AI 랩이 모두 자체 에이전트 SDK를 출시했습니다(OpenAI, Google, Microsoft). 오픈소스 진영에서는 LangGraph가 그래프 기반 프레임워크의 사실상 표준으로 굳어졌습니다.
동시에 "직접 만들기(build it yourself)" 접근법도 추진력을 얻고 있습니다. 추상화보다 제어권을 선호하는 팀들이 선택하는 방향입니다.
레이어 5: 평가(Eval)와 옵저버빌리티
가장 늦게 독립 인프라로 분리된 레이어입니다. 놀라운 통계가 있습니다. 프로덕션 에이전트를 운영하는 팀의 89%가 옵저버빌리티를 구현했지만, 평가(eval)를 구현한 팀은 52%에 그칩니다.
옵저버빌리티는 "무슨 일이 일어나는가"를 보는 것이고, eval은 "제대로 작동하는가"를 측정하는 것입니다. 이 격차는 치명적인 위험입니다. 에이전트 전용 벤치마크(메모리 관리·오류 복구)도 이제 존재합니다.
레이어 6: 가드레일과 안전
6개 레이어 중 가장 미성숙한 레이어입니다. 지배적인 프레임워크도, 확립된 패턴도 없습니다.
핵심 원칙 하나는 분명합니다. 인가(Authorization)는 출력 필터링이 아니라 도구 실행 시점에 이뤄져야 합니다. 출력을 필터링할 때는 이미 원하지 않는 행동이 발생한 뒤입니다.
에이전트 유형별 의사결정 프레임워크
모든 에이전트가 같은 스택을 필요로 하지 않습니다. 네 가지 유형에 따라 아키텍처 선택이 달라집니다.
| 에이전트 유형 | 필요한 스택 |
|---|---|
| 무상태 도구 호출자 | 최소 스택으로 충분 |
| 멀티스텝 워크플로 | LangGraph + eval 인프라 필요 |
| 학습 에이전트 | 전용 메모리 아키텍처 필수 |
| 멀티에이전트 시스템 | 정교한 트레이싱 포함 전체 스택 |
실전 사례: Cursor와 Claude Code
Cursor와 Claude Code는 6개 레이어 전부가 맞물려 동작하는 대표 사례입니다.
- 레이어 1: 작업별 모델 선택 라우팅
- 레이어 2: 개발 도구와 MCP 통합
- 레이어 3: 코드베이스 인지 기반 검색
- 레이어 4: 커스텀 오케스트레이션 (LangGraph 미사용)
- 레이어 5: 수락률(acceptance rate) 지속 평가
- 레이어 6: 샌드박스 실행 가드레일
이 도구들이 "그냥 잘 작동하는" 이유가 있습니다. 각 레이어를 해당 문제에 정확히 맞춰 설계했기 때문입니다.
핵심 정리
2026년 AI 에이전트 스택의 결론은 명확합니다. 대부분의 팀은 필요 이상의 프레임워크를 선택합니다. 6개 레이어는 점점 더 주관적인(opinionated) 제공사 스택으로 수렴하고 있지만, 규모 있는 팀이라면 각 레이어가 어떤 프로덕션 장애를 해결하는지 이해하고 있어야 합니다.
복잡도를 추가하기 전에 먼저 물어보세요. "지금 어느 레이어에서 문제가 생기고 있는가?"
💬 댓글 0
댓글을 불러오는 중…