실제 메모리를 가진 Alexa를 만들려고 시도했지만 — 3개월 실패 후 배운 점

Source: Dev.to

LangGraph와 메모리 아키텍처에 관한 이야기, 그리고 왜 나는 LLM과의 싸움을 멈추고 대신 시스템을 예측 가능하게 만들었는지

간단한 좌절에서 시작되었습니다

나는 Alexa와 같은 것을 만들고 싶었지만—그보다 더 똑똑했으면 좋겠었다. 세션이 끝나는 순간 바로 당신을 잊어버리는 음성 비서가 아니라. 대화 전체 기록을 텍스트 파일에 저장하고 그것을 “memory.” 라 부르는 AI도 아니다.

나는 당신의 습관, 선호도, 할 일 등을 실제로 알고, 진짜 비서처럼 시간이 지날수록 똑똑해지는 개인 AI를 원했다.

간단해 보였다. 그렇지 않았다.

Step 1: Alexa는 어떻게 작동할까?

아무것도 만들기 전에 Alexa 클라우드 아키텍처를 깊게 살펴보았습니다. 모델은 간단합니다:

1. 당신의 음성 쿼리가 클라우드로 전송됩니다.
2. 처리된 뒤 LLM에 도달하고, 응답이 스트리밍되어 기기로 돌아옵니다.

기기 자체는 얇습니다 — 모든 인텔리전스는 서버에 존재합니다.

Problem: 메모리는 어디에 존재할까요? 그리고 더 중요한 것은 — 개인 AI에게 메모리란 과연 무엇일까요?

Step 2: 개인 AI가 실제로 기억해야 할 것은 무엇인가?

대부분의 AI 프로젝트는 이 질문을 건너뛰고, 모든 메시지와 모든 세션을 저장하고 이를 메모리라고 부릅니다. 그것은 단지 로그 파일일 뿐, 메모리가 아닙니다.

개인 AI에게 실제로 중요한 것이 무엇인지 고민하는 데 시간을 들였습니다. 여러 차례 생각한 끝에 네 가지 카테고리로 정리했습니다:

• Identity – 당신이 누구인지, 이름, 역할, 기본적인 사실들
• Habits – 당신이 정기적으로 하는 일, 루틴
• Preferences – 당신이 선호하는 방식, 즐기는 것들
• Events & Tasks – 캘린더 항목, 할 일

그 외의 모든 것은 잡음에 불과합니다. AI에게 하는 대부분의 말은 저장할 필요가 없습니다. 이 통찰은 전체 프로젝트에서 가장 중요한 설계 결정이 되었습니다.

Step 3: 어디에 저장할까 — SQL vs. Vector DB

내 첫 번째 직감은 SQL 데이터베이스였다: 깔끔한 테이블, 구조화된 데이터, 쿼리하기 쉬움.
하지만 곧 문제에 부딪혔다: 자연어로 SQL 데이터베이스를 직접 쿼리할 수 없다는 점이다. 정확한 키와 컬럼 이름을 알아야 한다. 사용자가 “내가 너에게 말했던 헬스장 일정이 뭐였지?”라고 하면 이런 방식은 통하지 않는다.

자연어 검색을 위해서는 벡터 검색이 필요하다 — 쿼리와 저장된 기억을 벡터로 임베딩하고 의미적 매치를 찾는다.

하이브리드 솔루션

실제 데이터는 SQL에, 컨텍스트와 의미는 벡터 스토어에 저장한다. 두 시스템이 함께 작동한다.

Step 4: The First Approach — Give the LLM Everything

스토리지를 해결한 뒤, 버전 1을 만들었습니다: LLM에게 두 데이터베이스에 대한 도구 접근 권한을 부여하고 언제 읽고 쓸지 스스로 결정하게 했습니다.

In theory 깨끗했습니다. In practice 재앙이었습니다.

LLM은 환각을 일으킵니다. 모델은 자신 있게 메모리를 잘못된 카테고리에 기록하거나, 관련 없는 항목을 검색하거나, — 더 나쁘게는 — 존재하지 않는 메모리를 만들어냅니다. 시스템 전체의 역할이 신뢰할 수 있는 메모리 레이어가 되는 것이라면, 환각은 치명적입니다.

나는 시스템이 predictable해야 했습니다. 실수를 하더라도, 나는 그 실수가 where 발생할지 알아야 했습니다.

Step 5: 실제 아키텍처 — 매직이 아닌 노드

Instead of one LLM doing everything, I broke the pipeline into dedicated nodes, each with a single responsibility:

User Input
   ↓
[Segmentation Node]
   – splits input into: memory_to_write | memory_to_fetch | ignore
   ↓
[Classification Node]
   – labels each piece: identity | habit | preference | event | task
   ↓
[Router Node]
   ├──→ [Memory Writer] → Pinecone + Postgres (parallel)
   └──→ [Memory Reader] → Fetch relevant context (parallel)
   ↓
[Final Answer Node]
   – aggregates context → single LLM call → response

이 작업을 가능하게 한 두 가지 핵심 결정

1. Read and write in parallel – Running them sequentially killed latency. Parallelizing both brought response times down dramatically.
2. Use LLMs only where you have to – Every node that could be implemented with regex or deterministic logic was. LLMs are expensive in tokens and unpredictable. The only mandatory LLM call is the final answer generation.

결과: A system that’s predictable end‑to‑end. If something goes wrong, I know which node failed and why — infinitely better than a black box that hallucinates.

6단계: 하드웨어 꿈은 (당분간) 사라진다

I originally wanted Orion to be a hardware device — a tabletop robot, always listening, always learning. That vision is still there, but 2–3 months in I made a decision: get the software layer right first.

처음에 나는 Orion을 하드웨어 장치, 즉 항상 듣고 항상 배우는 테이블 위 로봇으로 만들고 싶었다. 그 비전은 여전히 남아 있지만, 2~3개월 차에 나는 결정을 내렸다: 먼저 소프트웨어 레이어를 제대로 만드는 것이다.

Hardware is a multiplier. If the memory architecture is broken, a physical device just amplifies the problem. If the memory architecture is solid, hardware becomes a packaging issue — not a fundamental one.

하드웨어는 곱셈 효과를 가진다. 메모리 아키텍처가 깨져 있으면 물리적인 장치는 문제를 단순히 확대시킬 뿐이다. 메모리 아키텍처가 견고하면 하드웨어는 근본적인 문제가 아니라 포장 문제가 된다.

So Orion is now a software‑first memory layer. The hardware will come later, if at all. The memory problem was always the interesting part anyway.

그래서 Orion은 이제 소프트웨어 우선 메모리 레이어가 되었다. 하드웨어는 나중에, 어쩌면 전혀 나오지 않을 수도 있다. 어쨌든 메모리 문제가 항상 흥미로운 부분이었다.

기술 스택 구성

• LangGraph – 오케스트레이션 프레임워크; 노드 그래프와 상태를 관리합니다
• Groq – 최종 답변 노드를 위한 빠른 LLM 추론
• Pinecone – 의미 기억 검색을 위한 벡터 저장소
• Postgres – 구조화된 기억(신원, 작업, 이벤트)을 위한 관계형 DB

(여기에 사용 중인 추가 구성 요소를 추가하세요.)

# Orion – Agentic Memory Stack (Overview)

- **PostgreSQL (Supabase)** – Structured memory storage  
- **Redis** – Caching and fast in‑session state  
- **Jina** – Embeddings for vectorizing memory content  
- **LangSmith** – Tracing and debugging the graph (genuinely essential)  
- **FastAPI** – Serves the whole thing as a REST API  

3개월 전의 나에게 전하고 싶은 말

• “무엇을 저장할까?”라는 질문이 “어떻게 저장할까?”보다 더 중요합니다.
  대부분 사람들은 설계 질문에 답하기 전에 기술을 먼저 선택합니다. 먼저 설계를 올바르게 해야 합니다.
• 메모리 시스템에서 지연 시간은 실제 문제입니다.
  병렬 조회 및 쓰기는 선택 사항이 아니라 필수입니다.
• 범위를 바꾸는 것은 실패가 아닙니다.
  하드웨어를 포기하고 소프트웨어 계층에 집중한 것은 포기가 아니라 집중이었습니다.

다음 단계

• Orion은 아직 개발 중입니다.
• 메모리 레이어가 작동합니다.
• 다음 단계:
  1. 검색을 더 스마트하게 만들기 – 더 나은 컨텍스트 주입.
  2. 오래되거나 관련 없는 항목에 대한 메모리 감쇠 구현.
  3. 다른 개발자들이 자신의 AI 프로젝트에 쉽게 넣을 수 있는 깔끔한 SDK 출시.

LangGraph 또는 agentic memory와 함께 무언가를 구축하고 있다면, 정말 대화하고 싶습니다.
GitHub 레포는 공개되어 있습니다:

예비 최종학년 CSE 학생. 아직 작동하지 않아야 할 것들을 만들고 있습니다.