supermemory
프레임워크supermemoryai/supermemory
AI 메모리 엔진 및 API로, AI 에이전트에 영속적인 컨텍스트와 사용자 프로필을 제공합니다.
개요
Supermemory는 AI를 위한 메모리 및 컨텍스트 엔진입니다. 대화에서 사실을 추출하고, 사용자 프로필을 구축하며, 하이브리드 검색(RAG)을 제공합니다. 개발자가 API를 통합하는 용도로도 적합하고, 최종 사용자가 앱을 사용하는 용도로도 적합합니다.
README 미리보기
\n \n \n \n \n \n\n\n\n State-of-the-art memory and context engine for AI. And yes - you can use it as a company/personal brain.\n\n\n\n Docs ·\n Quickstart ·\n Dashboard ·\n Discord\n\n\n\n \n \n \n\n\n---\n\nSupermemory is the memory and context layer for AI. **#1 on [LongMemEval](https://github.com/xiaowu0162/LongMemEval), [LoCoMo](https://github.com/snap-research/locomo), and [ConvoMem](https://github.com/Salesforce/ConvoMem)** — the three major benchmarks for AI memory. \n\nWe are a research lab building the engine, plugins and tools around it.\n\nYour AI forgets everything between conversations. Supermemory fixes that.\n\nIt automatically learns from conversations, extracts facts, builds user profiles, handles knowledge updates and contradictions, forgets expired information, and delivers the right context at the right time. Full RAG, connectors, file processing — the entire context stack, one system.\n\n| | |\n|---|---|\n| 🧠 **Memory** | Extracts facts from conversations. Handles temporal changes, contradictions, and automatic forgetting. |\n| 👤 **User Profiles** | Auto-maintained user context — stable facts + recent activity. One call, ~50ms. |\n| 🔍 **Hybrid Search** | RAG + Memory in a single query. Knowledge base docs and personalized context together. |\n| 🔌 **Connectors** | Google Drive · Gmail · Notion · OneDrive · GitHub — auto-sync with real-time webhooks. |\n| 📄 **Multi-modal Extractors** | PDFs, images (OCR), videos (transcription), code (AST-aware chunking). Upload and it works. |\n\nAll of this is in our single memory structure and ontology. \n\n\n\n\n---\n\n## Use Supermemory\n\n\n\n\n\n🧑💻 I use AI tools\n\nBuild your own personal supermemory by using our app. Builds **persistent memory graph across every conversation**.\n\nYour AI remembers your preferences, projects, past discussions — and gets smarter over time.\n\n**[→ Jump to User setup](#give-your-ai-memory)**\n\n\n\n\n🔧 I'm building AI products\n\nAdd memory, RA
FAQ (4)
문제 해결왜 withSupermemory가 AI SDK 6를 사용할 때 AI_UnsupportedModelVersionError를 던지나요?
withSupermemory 함수는 객체 스프레드를 사용하여 언어 모델을 래핑하지만, AI SDK 6 모델은 specificationVersion, provider, modelId, supportedUrls와 같은 열거 불가능/프로토타입 속성을 저장합니다. 스프레드는 이러한 속성을 복사하지 않아 undefined 값이 발생하여 오류를 트리거합니다. 수정 방법: wrapVercelLanguageModel(packages/tools/src/vercel/index.ts)에서 스프레드 패턴을 'ai'의 표준 wrapLanguageModel 미들웨어 방식으로 대체합니다(import { wrapLanguageModel, LanguageModelV3Middleware } from 'ai'). 임시 해결책으로 라이브러리가 업데이트될 때까지 wrapLanguageModel을 사용하여 수동으로 래퍼를 구현합니다. 영향을 받는 버전: @supermemory/tools@1.4.1, ai@6.0.158, @ai-sdk/provider@3.0.8.
문제 해결브라우저 또는 엣지 런타임용으로 supermemory SDK v5를 번들링할 때 발생하는 esbuild 'Could not resolve fs/stream' 오류를 해결하는 방법
**원인:** supermemory v5.0.0-rc.6부터(Speakeasy에서 Fern codegen으로 전환된 이후) 생성된 코어에는 리터럴 동적 임포트가 포함되어 있습니다 — generated/core/file/file.js에는 await import("fs")가, generated/core/form-data-utils/FormDataWrapper.js에는 await import("stream")이 있습니다. esbuild와 같은 번들러는 해당 코드 경로가 절대 실행되지 않더라도 빌드 시점에 리터럴 import() 지정자를 해석하므로, 파일을 전혀 업로드하지 않더라도 모든 브라우저/엣지 번들(Cloudflare Workers, Vercel Edge, Convex 기본 런타임, Vite/esbuild)이 Could not resolve "fs" / Could not resolve "stream" 오류로 실패합니다.
**해결 방법:**
1. 번들링 가능한 마지막 버전으로 고정: npm i supermemory@5.0.0-rc.5 (Speakeasy로 생성된 빌드는 깔끔하게 번들링됩니다).
2. **Convex:** 기본 Convex 런타임은 Node API를 사용할 수 없으므로, SDK를 임포트하는 모든 모듈을 파일 상단에 'use node' 지시어를 추가하여 Convex의 Node 런타임으로 옮기세요.
3. **SDK 유지관리자 / 로컬 패치용:** 생성 후 패치를 적용하여(예: scripts/generate.ts에서) 리터럴 지정자를 계산된 지정자로 대체하면 esbuild가 이를 런타임 임포트로 그대로 둡니다: import("fs") 대신 import(["f","s"].join("")) (참고: const s = "fs"; import(s)와 /* @vite-ignore */ 주석은 작동하지 않습니다 — --minify-syntax가 적용된 esbuild는 상수를 인라인화하고 여전히 이를 해석합니다). webpack도 처리하려면 /* webpackIgnore: true */를 추가하세요. Node는 여전히 런타임에 계산된 형태를 해석하므로, 그 환경에서는 업로드가 계속 작동합니다.
4. 빌드된 패키지를 브라우저 타겟으로 번들링하는(esbuild entry.js --bundle --platform=browser --format=esm) CI 검사를 추가하고 해석 오류 발생 시 실패하도록 하여 회귀를 방지하세요.
문제 해결왜 Supermemory SDK client.fetch()가 'Failed to parse URL' 오류를 발생시키거나 Authorization 헤더 없이 401을 반환하나요?
이것은 client.fetch() 패스스루가 기본 환경을 무시하는 알려진 버그(v5.0.1)입니다. 타입화된 메서드와 달리 SupermemoryEnvironment.Default로 폴백하지 않기 때문에, 상대 경로는 결합할 기본 URL이 없어 Failed to parse URL 오류를 throw하고, 절대 URL은 Authorization 헤더를 첨부하는 인증 확인을 건너뛰어 401 오류를 발생시킵니다. 해결 방법: 클라이언트를 생성할 때 기본 URL을 명시적으로 전달하세요:
import { Supermemory } from "supermemory"
import { SupermemoryEnvironment } from "supermemory/environments"
const client = new Supermemory({
apiKey: "sm_test",
baseUrl: SupermemoryEnvironment.Default, // or "https://api.supermemory.ai"
})
await client.fetch("/v3/settings") // now resolves and sends Bearer authbaseUrl이 설정되면 상대 경로 해석과 targetsBaseUrl 인증 첨부가 모두 올바르게 작동합니다. 영구적인 수정을 위해서는 생성된 클라이언트에서 기본값을 this._options.baseUrl ?? this._options.environment ?? environments.SupermemoryEnvironment.Default로 해석해야 합니다.
문제 해결파일 중간을 조금만 수정해도 self-hosted 문서 upsert에서 거의 모든 chunk를 re-embedding하는 것을 막으려면 어떻게 해야 하나요?
이 문제는 청크 경계가 위치에 민감하기 때문에 발생합니다. 문서 시작 부분 근처에서 삽입이나 삭제가 발생하면 모든 하위(downstream) 경계가 이동하므로 콘텐츠 해시가 더 이상 일치하지 않게 되고 거의 모든 청크가 다시 임베딩됩니다. 추가(append) 작업은 기존 경계를 이동시키지 않기 때문에 정상적으로 작동합니다.
해결 방법: PR fix(chunking): stable content-defined chunking with hash-based reuse planning(issue #1649에 대한 수정)이 포함된 릴리스로 자체 호스팅 서버를 업그레이드하세요. 이 수정은 stable/content-defined chunking과 해시 기반 재사용을 사용하므로, 파일 중간의 편집 시 문서 전체가 아닌 영향을 받는 청크만 무효화됩니다.
업그레이드할 수 있을 때까지 다음 해결 방법을 사용하세요:
1. 가능한 경우 추가 전용(append-only) 업데이트를 사용하세요.
2. 주요 Markdown 제목당 하나의 파일처럼, 지속적으로 변경되는 대형 문서를 더 작고 상대적으로 안정적인 문서로 분할하세요.
3. 자주 편집하는 섹션을 문서 끝으로 이동하세요.
4. 더 빠른 임베딩 제공자, GPU 가속 또는 더 작은 로컬 임베딩 모델을 사용하여 불가피한 전체 재임베딩 비용을 줄이세요.
업그레이드 후에는 동일한 customId를 사용하는 후속 /v3/documents upsert가 변경되지 않은 하위 청크를 재임베딩하는 대신 재사용합니다.