2026년 5월 · 11분 분량 · Fran Olivares, Founder of OlivaresAI
프로젝트 관리는 대부분 메모리 작업입니다. 누가 이 스트림을 소유하나? 마이그레이션 창에 대해 무엇을 동의했나? 왜 레이트 리미터를 범위에서 제외했나? 법무 검토가 출시를 차단하는 것은 언제인가? 매일 아침 이러한 질문을 다시 해야 하는 에이전트는 에이전트가 아닙니다 — 약간 더 빠른 인턴입니다. 이를 바꾸는 방법은 모델에 턴 사이에 읽고 쓸 수 있는 영속 메모리 레이어를 부여하는 것이며, 대화에서 자동으로 채워집니다. 이 가이드는 Anthropic Claude API를 LLM으로, Alma의 REST API를 메모리 레이어로 사용하여 참조 아키텍처와 통합 코드를 안내합니다.
세 가지 구조적 이유. 첫째, PM이 추적하는 엔티티(사람, 결정, 산출물, SLA, 위험)는 그 자체로 오래 지속됩니다 — 정의상 단일 대화보다 오래 살아남습니다. 둘째, 대화 스타일은 고빈도, 저노력입니다: 짧은 스탠드업 메시지, 빠른 명확화, "X에 대해 무엇을 말했나?" 질문. 올바른 컨텍스트 슬라이스를 저렴하게 로드하는 것이 중요합니다. 셋째, 잊는 비용이 높습니다: 놓친 결정은 놓친 출시가 되고, 잊혀진 종속성은 차단 요소가 됩니다.
무상태 Claude 대화는 단일 계획 세션을 잘 처리합니다. 사용자가 연속성("어제 우리가 동의했...", "이번 주 인증 팀을 차단하는 것은 무엇?")을 원하는 순간 대화는 전체 기록을 컨텍스트 창에 다시 재생(비용이 많이 들고 결국 불가능)하거나 모델 외부의 메모리 레이어에 의존해야 합니다.
네 가지 움직이는 부분:
messages.create 스트림. 모델이 필요할 때 이름으로 엔티티에 대해 메모리 레이어에 요청할 수 있도록 도구 사용이 활성화됩니다.stakeholder, decision, sla, risk)와 중요도 점수가 있는 메모리 레코드입니다. Episodes는 압축된 일일 스탠드업을 캡처합니다; procedures는 반복 워크플로("핫픽스 처리 방식")를 캡처합니다.다섯 가지 카테고리가 대부분의 팀을 커버합니다: stakeholder(역할 + 책임이 있는 사람), decision(무엇이 동의되었고, 언제, 누가, 근거와 함께), sla(다른 팀이나 고객에 대한 약속), risk(소유자 + 완화가 있는 미해결 문제), milestone(목표 날짜 + 범위 + 상태). 각 메모리는 어셈블러가 검색에서 고위험 항목의 우선순위를 정할 수 있도록 중요도 점수를 가집니다.
카테고리는 단순히 조직을 위한 것이 아닙니다 — 검색 신호의 일부입니다. 사용자가 "무엇을 결정했나?"를 물으면 어셈블러는 결정 카테고리 메모리의 가중치를 높입니다. "누가 차단되었나?"를 물으면 위험 카테고리 메모리의 순위가 올라갑니다. Alma 컨텍스트 조립은 정확히 이 사용 사례를 위해 카테고리별 부스트 가중치를 노출합니다.
사용자 메시지당 세 단계. 아래 의사 코드는 Node.js와 Alma SDK 및 Anthropic SDK를 사용하지만 동일한 모양이 Python 또는 다른 스택에서 작동합니다:
const { systemPrompt } = await alma.context.assemble({ query: userMessage, environmentId: projectId });const stream = anthropic.messages.stream({ model: 'claude-opus-4-7', system: systemPrompt, messages: [{ role: 'user', content: userMessage }] });await alma.memories.extract({ text: lastTurn, environmentId: projectId });3단계는 백그라운드에서 실행됩니다 — 사용자는 즉시 스트리밍된 응답을 보고, 추출은 차단하지 않고 다음 약 1 s 안에 발생합니다. 새 메모리는 중복 제거되고, 모순은 기존 항목에 대해 감지되며, 저장소는 자동으로 깨끗하게 유지됩니다. 전체 SDK 참조: @olivaresai/alma-sdk; REST API 문서의 HTTP 동등물.
Alma environments를 사용하세요: 프로젝트당 하나의 환경. 각 환경은 다른 환경과 완전히 격리된 자체 memories, episodes, procedures, Soul 블록을 가집니다. 에이전트는 모든 메모리 호출에서 environmentId를 전달합니다; API가 경계를 강제합니다. 명시적인 환경 전환 없이는 교차 프로젝트 쿼리가 불가능합니다 — 프로젝트 A의 결정이 프로젝트 B로 누출되는 것이 실제 문제인 PM 도구에 대한 올바른 기본값입니다.
팀 전체 PM 에이전트(여러 사람이 동일한 에이전트와 상호작용)의 경우 Alma teams 리소스를 사용하세요: 각 팀은 모든 멤버에게 표시되는 공유 메모리와 개인 선호도를 위한 사용자별 메모리를 가집니다. 역할 기반 액세스가 누가 무엇을 쓸 수 있는지 제어합니다.
사용자 메시지: "스탠드업: 백엔드 팀, Maria는 오늘 마이그레이션을 차단 해제하고 있음, José는 레이트 리미터에 있음; 법무가 여전히 DPA를 검토 중이므로 GA 출시를 금요일로 미루기로 결정". 에이전트의 흐름:
결정 고고학. "왜 레이트 리미터를 범위에서 제외했나?" — 에이전트는 결정 메모리, 주변 episode, 참조한 위험 메모리를 검색합니다. 사용자가 필요하다면 대화로 파고들 수 있도록 레코드에 대한 인용과 함께 답변을 반환합니다.
이해관계자 조회. "누가 마이그레이션을 소유하나?" — stakeholder 카테고리에 대한 직접 메모리 쿼리, 레코드를 반환합니다. 답변이 오래되었다면(지난주에 역할이 변경됨), 모순 감지는 새 소유자를 언급하는 다음 대화에서 이를 잡습니다.
반복 보고서 생성. "이번 주 인증 스트림에 대한 상태 보고서 생성" — 에이전트는 해당 스트림에 태그된 episodes, decisions, risks의 컨텍스트 창을 조립한 다음 그 큐레이션된 슬라이스에서 보고서를 작성합니다. 이는 Claude에 원시 채팅 기록을 요약하도록 요청하는 것보다 훨씬 저렴하고 정확합니다.
어셈블러의 기본 토큰 예산: memories에 ~2 K 토큰, episodes에 ~1 K, procedures에 ~500, Soul 블록에 ~500. 총 ~4 K — 어떤 모델의 컨텍스트 예산 아래로 잘 들어가며, 캐시 히트가 대화 전반에 분산됩니다. 프로젝트가 작다면(<100 활성 메모리) 예산을 더 낮출 수 있습니다. 크다면(10 K+ 메모리), 검색이 저장소가 클 때도 포함된 레코드 수를 제한하기 때문에 어셈블러는 ~4 K에 머무릅니다.
운영상 두 가지가 중요합니다: Soul 블록(에이전트의 정체성)은 반복 호출이 입력 토큰을 다시 지불하지 않도록 안정적인 시스템 프롬프트 접두사로 캐시되어야 합니다; 동적 컨텍스트(memories + episodes)는 각 호출이 변경된 부분만 다시 업로드하도록 캐시 중단점 뒤에 있어야 합니다. Anthropic의 프롬프트 캐싱 문서는 중단점 배치를 다룹니다.
일반적인 PM 팀 흐름(사용자당 일일 ~20개 메시지, 주로 스탠드업 + 명확화)에서 한계 비용은 LLM 호출 자체가 지배합니다. 메모리 레이어는 추가합니다: 하나의 조립 호출(몇 KB 읽기 + 검색, ~30 ms), 하나의 추출 호출(Haiku, 턴당 ~$0.001). 활성 사용자당 일일 총 메모리 오버헤드: 1센트 미만. 결정을 잃지 않는 PM 팀의 가치와 비교하면 — 그리고 수학은 명백합니다.
Alma의 Starter 플랜($14/월)은 진입 티어이며 영속 메모리 레이어를 포함합니다. alma.olivares.ai에서 가입하고, Settings에서 API 키를 생성하고, 개발자 페이지에서 SDK 스타터를 복제하세요. 에이전트 코드에 3단계 루프를 배선하고, 단일 테스트 프로젝트를 가리키고, 일주일 동안 실행하세요. 저장소는 대화에서 자연스럽게 채워집니다; 수동 데이터 입력 없이 결정, 이해관계자, 위험이 누적되는 것을 볼 수 있습니다. 거기에서 카테고리를 늘리고 어셈블러를 조정하는 것뿐입니다.
관련 자료: AI를 위한 영속 메모리: 완전한 2026 가이드 · AI에 영속 메모리를 부여하는 방법 · 3-레이어 메모리 아키텍처 · 컨텍스트 조립 문서 · Environments.