Architecture

메모리는 어시스턴트를 반응형에서 지속형으로 전환시키지만, 동시에 많은 시스템이 조용히 부패하는 곳이기도 합니다. 설문 조사들은 단기적 대 장기적 이분법이 현대 에이전트 메모리에는 더 이상 충분하지 않다고 주장하며, OpenAI와 LangGraph SDK들은 작동 메모리(working memory), 내구 상태(durable state), 검색(retrieval)이라는 더 단순한 스택을 지향합니다.

프로덕션 환경의 AI 어시스턴트는 단순히 “프롬프트가 붙은 LLM"이 아닙니다. 의도(intent)를 수용하고, 상태를 유지하며, 언제 검색하거나 행동을 취할지 결정하는 시스템입니다. 또한 실패 원인을 디버깅할 수 있도록 충분한 런타임 세부 정보를 노출해야 합니다.

대부분의 현대 지식 시스템은 검색(Retrieval) 최적화에 집중하며, 이는 이해할 수 있는 접근입니다. 검색은 가시적이며 데모하기 쉽고, 작동할 때 마법처럼 느껴집니다. 질문을 입력하면 답변이 돌아옵니다.

전제는 간단합니다. 컴파일된 지식은 검색된 단편보다 재사용성이 높습니다. RAG는 직관적인 질문—LLM에게 외부 지식을 어떻게 접근하게 할 것인가?—에 대한 기본 답변이 되었습니다.

PKM, RAG, 위키(Wiki), AI 메모리 시스템, 그리고 최근 주목받는 실용적인 AI 지원 워크플로우가 마치 동일한 문제를 해결하는 것처럼 자주 논의됩니다. 하지만 사실 그렇지 않습니다. 이들은 모두 지식과 관련되어 있지만, 서로 다른 계층에서 작동합니다:

대부분의 대규모 언어 모델(LLM) ‘구조화된 출력(structured output)’ 튜토리얼은 진지하지 않습니다. 이들은 사용자에게 정중하게 JSON을 요청한 후 모델이 잘 작동하기를 바라고 만듭니다. 그것은 검증(validation)이 아닙니다. 그것은 중괄호를 사용한 낙관주의에 불과합니다.

탭을 닫으면 컨텍스트 창을 벗어나는 정보가 없다면 현대적인 어시스턴트는 여전히 모든 내용을 잊어버립니다. **에이전트 메모리 제공자(Agent memory providers)**는 세션 간에 사실과 요약을 유지하는 서비스 또는 라이브러리로, 프레임워크는 가볍게 유지하면서 메모리가 확장되도록 플러그인으로 연결되는 경우가 많습니다.

알다시피, AI 에이전트와 채팅을 열면 프로젝트를 설명하고 선호 사항을 공유하며 작업을 진행한 뒤 탭을 닫습니다. 다음 주에 다시 돌아와 보면 낯선 이와 대화하는 듯한 기분이 듭니다. 모든 컨텍스트가 사라지고, 모든 선호 사항은 잊혀졌으며, 프로젝트는 처음부터 다시 설명해야 합니다.

데모에서는 OpenClaw가 단순해 보입니다. 하지만 프로덕션 환경에서는 하나의 시스템으로 진화합니다.

실제 논쟁의 핵심은 PostgreSQL 이 텍스트를 검색할 수 있는지, 혹은 Elasticsearch 가 문서를 저장할 수 있는지 여부입니다. 둘 다 가능합니다. 흥미로운 질문은 검색의 복잡성이 어디에 존재해야 하는가입니다.

알람 (Alerting) 은 너무 자주 모니터링 기능으로 묘사됩니다. 그런 틀을 잡는 것은 편리하지만, 실제 문제를 가립니다.

Slack 통합은 하나의 HTTP 호출로 메시지를 게시할 수 있기 때문에 속임수처럼 보일 정도로 간단해 보입니다. 하지만 Slack 을 상호작용적이고 신뢰할 수 있는 시스템으로 만들려고 할 때 흥미로운 부분이 시작됩니다.

Discord 는 이를 하나의 시스템으로 대할 때 진정한 통합 표면이 됩니다: 시스템이 이벤트를 게시하고, 인간이 결정을 내리며, 자동화가 워크플로우를 이어가는 곳입니다.

채팅 플랫폼은 단순한 메시징 도구를 넘어 크게 진화했습니다. 현대 시스템에서는 자동화된 프로세스와 인간의 의사 결정 사이를 잇는 인터페이스로 작동합니다.

대부분의 애플리케이션 아키텍처 조언은 적용하기엔 너무 추상적이거나, 확장하기엔 너무 좁은 경향이 있습니다. 여기서는 통합, 코드 구조, 데이터 액세스에 걸쳐 프로덕션 시스템에 적용할 수 있는 실용적인 트레이드오프를 제시합니다.

대부분의 로컬 AI 환경은 동일한 방식으로 시작합니다. 모델, 런타임, 그리고 채팅 인터페이스가 그것입니다.