메모라이저로 읽는 AI 에이전틱의 현재 지도
작성일: 2026-04-14
대상 독자: AI 에이전트 구조를 개념적으로 정리하고 싶은 개발자, 아키텍트, 기술 기획자
자료 범위: 메모라이저에 축적된 agentic-ai, multi-agent, memory, orchestration 관련 메모리 묶음
이 글은 외부 웹 전체를 다시 조사한 시장 보고서가 아니라, 메모라이저 내부에 저장된 AI 에이전틱 관련 메모리를 재분류해 만든 기술 정리 문서다. 목적은 최신 유행어를 나열하는 것이 아니라, 현재 지식베이스가 이 주제를 어떤 구조로 이해하고 있는지 한 장의 지도로 보여 주는 데 있다.
0. 왜 이 글을 쓰는가
요즘 AI agent, agentic AI, multi-agent, workflow, memory라는 단어는 자주 같이 등장한다. 문제는 이 단어들이 한 문서 안에서는 서로 비슷해 보이는데, 막상 시스템을 만들려고 하면 전혀 다른 층위의 문제라는 점이다.
이번 글은 메모라이저에 저장된 관련 자료들을 다시 훑어 보면서, 현재 내부 지식베이스가 AI 에이전틱을 어떤 구조로 이해하고 있는지 한 장의 지도로 정리한 것이다.
핵심 결론부터 말하면 이렇다.
에이전틱은 모델 이름이 아니라 시스템 설계 문제다.멀티에이전트는 채팅 놀이가 아니라 오케스트레이션 문제다.메모리는 옵션이 아니라 상태 관리 계층이다.프레임워크 선택은 성능 경쟁보다결정성 vs 자율성의 trade-off에 가깝다.
1. 메모라이저에서 가장 강하게 잡힌 네 축
이번 조사에서 관련 메모리는 크게 네 묶음으로 모였다.
축 |
핵심 질문 |
대표 메모리 |
|---|---|---|
에이전틱 개념/아키텍처 |
에이전틱 시스템은 기존 SaaS와 무엇이 다른가 |
|
멀티에이전트 오케스트레이션 |
여러 에이전트를 어떻게 고장 나지 않게 조율할 것인가 |
|
에이전트 메모리 |
LLM의 stateless 한계를 어떻게 보완할 것인가 |
|
프레임워크/패턴 |
어떤 제어 모델로 구현할 것인가 |
|
이 분포만 봐도 흥미롭다. 메모라이저는 AI 에이전트를 "좋은 프롬프트를 넣는 기법"보다는 상태, 제어, 검색, 실행을 가진 시스템으로 보는 자료를 더 많이 품고 있다.
2. 에이전틱은 왜 "모델"보다 "시스템"에 가깝나
What is Agentic AI 계열 메모리들이 공통으로 강조하는 지점은 단순하다.
기존 SaaS는 짧고, 요청-응답형이며, 대체로 stateless 하다. 반면 에이전틱 시스템은 다음 특성을 갖는다.
대화와 작업이 더 오래 지속된다.
중간 상태를 저장해야 한다.
외부 도구와 API를 호출한다.
실패 후 재개가 가능해야 한다.
단일 답변보다
계획 -> 실행 -> 관찰 -> 재시도가 더 중요하다.
즉, 에이전틱은 LLM을 붙인 앱이 아니라 비결정적 추론 엔진을 시스템 안에 안전하게 가두는 방식에 가깝다.
Akka 계열 메모리들이 A-Tier라는 표현으로 분리한 것도 이 맥락이다. 전통적인 N-tier 위에, 에이전트 특유의 상태와 워크플로우를 받쳐 주는 별도 계층이 필요하다는 주장이다.
정리하면, 에이전틱 시스템의 본질은 아래 세 줄이다.
LLM은 강력하지만 느리고 흔들린다.
그래서 앞뒤를 붙여 주는 상태/워크플로우/검색 계층이 필요하다.
결국 성패는 모델 스펙보다 그 계층을 어떻게 설계했는지에 달린다.
3. 멀티에이전트의 핵심은 "몇 명이 말하느냐"가 아니라 "누가 조율하느냐"다
메모라이저 안의 멀티에이전트 자료는 크게 두 부류다.
3.1 정적 오케스트레이션
Weather Agent -> Preferences Entity -> Activity Agent처럼 순서가 미리 정해진 방식이다.
장점
흐름이 읽기 쉽다.
장애 지점이 명확하다.
재현성과 테스트가 좋다.
단점
새 에이전트를 붙일 때 워크플로우도 같이 수정해야 한다.
예상 밖의 요청에는 유연성이 떨어진다.
3.2 동적 오케스트레이션
SelectorAgent -> PlannerAgent -> Workflow -> Worker Agents 구조처럼, 실행 시점에 LLM이 사용할 에이전트를 고르고 호출 순서를 짜는 방식이다.
장점
새 worker를 추가해도 전체 플로우를 덜 건드린다.
요청이 바뀌면 계획도 같이 바뀐다.
복잡한 문제에 더 자연스럽게 대응한다.
단점
결정성이 약해진다.
잘못된 분해나 잘못된 라우팅이 생길 수 있다.
관찰성과 평가 체계가 없으면 금방 "멋진 데모"에 머문다.
이 대목에서 중요한 건, 멀티에이전트는 에이전트 수가 아니라 오케스트레이션 계약으로 이해해야 한다는 점이다. 누가 선택하고, 누가 계획을 만들고, 누가 상태를 들고 있고, 실패 시 어디서 재개하는지가 먼저다.
4. 메모리는 부가 기능이 아니라 에이전트의 상태 계층이다
메모리 관련 메모들을 종합하면, 내부 지식베이스는 거의 같은 입장을 반복한다.
메모리가 없으면 LLM은 강력하지만 상태가 없는 텍스트 처리기일 뿐이다.
여기서 메모리는 하나가 아니다. 최소 세 층으로 나뉜다.
메모리 층 |
역할 |
예시 |
|---|---|---|
단기 메모리 |
현재 컨텍스트 윈도우 안의 즉시 작업 공간 |
현재 대화, 현재 단계의 중간 추론 |
작업 메모리 |
멀티스텝 태스크의 진행 상태 |
예약 날짜, 예산, 현재 step, tool 결과 |
장기 메모리 |
세션 밖에 저장되는 지속 정보 |
사용자 선호, 도메인 지식, 절차적 루틴 |
여기서 실무적으로 중요한 문장은 두 가지다.
첫째, 장기 메모리는 "많이 저장"보다 잘 검색이 중요하다.
둘째, 잘못 저장된 메모리는 context poisoning을 일으킨다.
그래서 메모리 시스템은 단순한 벡터 DB 도입으로 끝나지 않는다.
무엇을 저장할지 선택해야 하고
중복을 정리해야 하며
오래된 정보를 폐기해야 하고
검색 결과를 다시 리랭킹해야 한다
MapZero는 이를 지식 관리 계층으로 설명하고, One Context는 아예 Git 비유를 써서 branch/commit/merge/search로 다룬다. 둘 다 같은 문제를 겨냥한다. 에이전트가 긴 작업을 하면서도 맥락을 잃지 않게 하는 것이다.
5. ReAct에서 CrewAI/LangGraph까지: 패턴과 프레임워크는 어떻게 이어지나
메모라이저 자료를 이어 보면, 에이전트 설계는 대략 다음 축으로 연결된다.
5.1 가장 작은 동작 패턴: ReAct
Thought -> Action -> Observation 반복이다.
이 패턴은 여전히 중요하다. 이유는 간단하다. 에이전트의 최소 단위를 설명하기 때문이다.
생각한다
도구를 호출한다
결과를 본다
충분하지 않으면 다시 시도한다
라우팅, 병렬화, self-review도 결국 이 바닥 위에 올라간다.
5.2 프레임워크 선택의 실제 기준
Crew AI vs LangGraph 메모리는 이 질문을 잘 압축한다.
질문 |
CrewAI 쪽 |
LangGraph 쪽 |
|---|---|---|
추상화 수준 |
높다 |
낮다 |
자율성 |
높다 |
낮다 |
제어력 |
낮다 |
높다 |
결정성 |
약하다 |
강하다 |
적합한 용도 |
빠른 프로토타입, 실험 |
운영, 검증, 명시적 제어 |
비유도 적절하다. CrewAI는 자동 카메라, LangGraph는 수동 카메라다.
즉, 프레임워크 선택은 "누가 더 최신인가"보다 아래 질문에 가깝다.
이 시스템은 실험인가 운영인가
실패 비용이 큰가 작은가
흐름을 사람이 고정해야 하는가, LLM에게 맡겨도 되는가
6. 지금 시점의 실무적 결론
이번 메모라이저 조사만 놓고 보면, AI 에이전틱 시스템은 아래 3단계로 이해하는 것이 가장 실용적이다.
6.1 1단계: 단일 에이전트 + 도구 + 짧은 메모리
가장 먼저 검증할 단계다.
ReAct
툴 콜링
최소한의 작업 메모리
이 단계에서 중요한 것은 "똑똑한 답변"보다 실패를 관찰하는 것이다.
6.2 2단계: 워크플로우가 있는 오케스트레이션
작업이 길어지면 이 단계가 필요하다.
단계별 상태 저장
실패 후 재개
명시적 라우팅
사람 승인 지점
이 시점부터 에이전트는 모델이 아니라 운영 시스템이 된다.
6.3 3단계: 동적 멀티에이전트 + 장기 메모리
여기서부터는 화려함보다 규율이 더 중요하다.
selector / planner / worker 분리
장기 메모리 검색 품질 관리
평가와 리플레이 가능성 확보
관찰성, 감사 추적, 복구 전략 포함
이 단계를 건너뛰고 "바로 자율 에이전트 팀"으로 가면, 대개는 데모는 되지만 운영은 무너진다.
이번 메모라이저 풀은 특히 Akka 기반 agentic architecture, 멀티에이전트 오케스트레이션, 메모리 시스템 쪽 자료가 강했다. 반대로 범용 프레임워크의 실제 운영 장애 사례나 비용 모델은 비교적 덜 축적되어 있었다. 즉, 현재 지식베이스는 "에이전틱은 시스템 공학"이라는 관점에는 강하지만, 개별 제품의 최신 경쟁 구도까지 모두 대표한다고 보기는 어렵다.
7. 한 문장으로 요약하면
에이전틱 AI는 여러 LLM이 똑똑하게 말하는 기술이 아니라, 비결정적 모델을 메모리와 워크플로우와 오케스트레이션으로 길들이는 시스템 공학이다.
8. 이번 정리에 직접 사용한 메모리
5c54cc6f-689d-4f46-9856-3b4a085066e8-Agentic AI: Comprehensive Overview from Akka708e1686-36f6-4e32-8076-f9df3268069b-Akka Multi-Agent Planner 튜토리얼f56703c6-00ce-4b60-9407-30a366fa987f-Multi-Agent Planner Step 6: Dynamic Orchestrationff6775c2-a8e5-4192-ae4b-dfa0d93b5dd3-ReAct 프레임워크 - AI 에이전트의 사고와 행동 메커니즘501aeb53-94f9-4719-ad4b-37f38c0dfc05-에이전트 메모리 시스템 가이드 (Agent Memory Guide)2eda1ddf-cfea-427a-9bf5-9f40a300ffb0-맵제로 - AI 에이전트를 위한 지식 메모리 시스템8a98df57-0a8b-4320-a2b8-fce6b23ae2fe-One Context - Git Context Controller(GCC) 기반 에이전트 장기 메모리 해결책ae24ef3e-6ee2-4bb7-a9c1-03fec01e64f8-크류 AI vs 랭그래프 - 에이전트 프레임워크 비교와 선택 가이드
외부 원전은 위 메모리들이 참조한 Akka, Weaviate Context Engineering, ProcessGPT/Lilys AI, One Context 관련 자료를 따른다.