Basic Memory·SilverBullet·Docmost 비교·설치: 제2의 두뇌와 팀 위키

Claude에게 설명했던 우리 팀의 업무 방식, 다른 AI를 켜면 또 설명하고 있나요? 회의록은 쌓이는데, 막상 “이 결정을 왜 했죠?”라는 질문에는 답을 찾기 어렵고요.

이때 필요한 것은 대화를 더 오래 보관하는 기능만이 아닙니다. 중요한 내용을 내가 관리하는 문서로 남기고, AI와 사람이 다시 찾아 쓰는 구조입니다. 이 글에서는 Basic Memory, SilverBullet, Docmost로 그 구조를 만드는 방법을 알아봅니다.

이 역할 구분은 각 제품의 기능을 바탕으로 제안하는 운영 방식입니다. Basic Memory에도 팀용 Cloud가 있고 SilverBullet도 팀 지식 관리에 사용할 수 있습니다. 여기서는 개인 기록과 팀의 확정 문서를 구분하는 용도에 집중합니다. Basic Memory 공식 저장소, SilverBullet 공식 소개, Docmost 공식 문서

공식 자료 확인일: 2026년 10월 16일. 제품 설명, 설치 문서, 설정·사용법과 공식 저장소를 대조했습니다. 아래 업무 사례와 프롬프트는 이해를 돕기 위해 만든 예시이며, 제품의 성과를 측정한 결과가 아닙니다.

Basic Memory·SilverBullet·Docmost, 무엇이 다른가요?

세 도구를 고를 때는 “어느 앱이 더 좋을까?”보다 누가 어떤 질문의 답을 찾을 것인가부터 정하면 쉽습니다.

무료 범위는 직접 설치하는 오픈소스 소프트웨어를 기준으로 합니다. 호스팅 서비스와 AI 사용료까지 모두 무료라는 뜻은 아닙니다. Basic Memory 로컬·Cloud 비교, SilverBullet Server 소개, Docmost 에디션 안내

최신 정식 버전은 무엇인가요?

2026년 10월 16일 확인한 최신 정식 릴리스는 아래와 같습니다. 설치 예제에는 이 버전을 지정하고, 기능 설명은 현재 공식 문서와 해당 릴리스의 설정·소스를 대조했습니다.

이후 버전으로 설치하거나 업그레이드할 때는 위 릴리스 페이지와 설치 문서를 다시 확인하세요. latest 같은 이동 태그나 개발 중인 main 브랜치는 확인한 버전과 내용이 달라질 수 있습니다.

왜 필요한가요? 대화 기록과 업무 지식은 다릅니다

예를 들어 콘텐츠 팀이 제목을 여러 번 바꿨다고 해봅시다. 대화에는 후보 제목과 잡담, 수정 요청이 뒤섞여 있습니다. 다음 기획에 필요한 것은 전체 대화보다 다음 네 가지일 때가 많습니다.

• 무엇을 결정했는가?
• 어떤 근거로 선택했는가?
• 실제 결과는 어땠는가?
• 언제 다시 검토해야 하는가?

이 내용을 따로 정리하면 AI를 바꿔도 같은 문서를 근거로 질문할 수 있습니다. 사람이 읽고 틀린 내용을 고칠 수도 있고요. Basic Memory 공식 문서 역시 AI의 기본 메모리와 별도로, 결정·조사·프로젝트 지식을 구조화해 보관하는 용도를 설명합니다. 기본 AI 메모리와 함께 쓰는 방법

여기서 제2의 두뇌, 또는 세컨드브레인은 자료를 많이 쌓아 둔 폴더가 아닙니다. 기록을 찾고, 다음 행동에 적용하고, 바뀐 사실을 갱신하는 개인 지식 관리 방식이라고 생각하면 됩니다.

처음에는 최근 업무 하나만 고르세요. 예를 들어 “블로그 제작 과정”을 정하고, 결정 기록 3개와 참고 자료 3개로 시작합니다. 자료 전체를 옮기는 것보다 실제로 궁금했던 질문에 답할 수 있는지 확인하는 편이 낫습니다.

1. Basic Memory: AI가 다시 찾는 업무 기억 만들기

Basic Memory는 사람이 읽을 수 있는 Markdown 문서를 AI가 MCP로 검색하고 읽고 쓸 수 있게 해주는 지식 관리 도구입니다. Markdown은 제목·목록·링크를 문자로 작성하는 문서 형식이고, MCP는 AI와 외부 도구를 연결하는 공통 규격입니다.

로컬판에서는 문서 파일이 원본이고 데이터베이스는 검색을 돕는 색인입니다. 파일 변경을 감지해 색인을 갱신하므로, 직접 고친 내용도 이후 검색에 반영할 수 있습니다. 다만 서버가 실행되고 갱신이 끝나야 하며, 이미 나온 AI 답변까지 자동으로 바뀌는 것은 아닙니다. Basic Memory 구조 설명

AI끼리 공유하는 것은 ‘저장한 문서’입니다

Claude Code에서 남긴 결정을 Codex나 Cursor에서도 참고하려면, 각 도구가 같은 Basic Memory 프로젝트에 연결되어야 합니다. 프로젝트 이름뿐 아니라 실제 저장 위치와 접근 권한도 확인하세요. 로컬 폴더를 각각 따로 만들었다면 같은 이름을 붙여도 내용은 공유되지 않습니다.

또한 설치만으로 예전 Claude·ChatGPT 대화와 기본 메모리가 전부 합쳐지지는 않습니다. 필요한 내용을 노트로 저장하거나 별도로 가져오는 과정이 필요합니다. 처음에는 AI에게 “기억해”라고만 하지 말고 어디에 무엇을 저장했는지 확인하세요. AI 기본 메모리와의 역할 구분, 프로젝트와 폴더

Basic Memory 설치: uv로 로컬 프로젝트 준비하기

먼저 uv 공식 설치 안내에 따라 uv를 설치합니다. 이미 설치했다면 이 단계는 건너뛰세요.

curl -LsSf https://astral.sh/uv/install.sh | sh

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

설치 후 터미널을 새로 열고 아래 명령을 실행합니다. Basic Memory 0.23.2는 Python 3.12 이상을 요구하며, 여기서는 3.12 실행 환경과 확인한 정식 버전을 지정합니다.

uv --version
uv tool install --python 3.12 "basic-memory==0.23.2" --prerelease=allow
basic-memory --version

--prerelease=allow는 의존성의 사전 배포 버전도 허용하는 옵션입니다. Basic Memory 자체는 정식판 0.23.2로 지정했지만, 이 릴리스는 fastmcp==4.0.0b1을 의존성으로 명시합니다. 현재 공식 README에도 이 옵션이 포함되어 있습니다. 0.23.2 패키지 설정, 현재 공식 설치 안내, uv의 Python 버전 지정

basic-memory --version에서 설치 결과를 확인하세요. Basic Memory에는 자동 업데이트 기능도 있으므로, 이후 동작을 비교할 때는 실제 실행 버전을 다시 확인하는 것이 좋습니다. 공식 자동 업데이트 안내

다음으로 업무 노트를 담을 폴더를 만들고 business-memory라는 이름으로 등록합니다.

mkdir -p "$HOME/Knowledge/business-memory"
basic-memory project add business-memory "$HOME/Knowledge/business-memory" --local
basic-memory project list --local

New-Item -ItemType Directory -Force "$env:USERPROFILE\Knowledge\business-memory"
basic-memory project add business-memory "$env:USERPROFILE\Knowledge\business-memory" --local
basic-memory project list --local

목록에 business-memory와 내가 지정한 경로가 나타나면 프로젝트 등록이 된 것입니다. 아직 AI 연결까지 완료된 상태는 아닙니다. 공식 프로젝트 설정, CLI 명령 참조

Claude Code·Codex·Cursor 중 사용하는 도구에 연결하기

아래에서 사용하는 도구의 탭을 선택하세요. 해당 AI 도구는 먼저 설치되어 있어야 합니다. 예제의 --project business-memory는 사용할 지식 프로젝트를 명시합니다.

claude mcp add --scope user basic-memory -- basic-memory mcp --project business-memory

codex mcp add basic-memory -- basic-memory mcp --project business-memory
codex mcp list

{
  "mcpServers": {
    "basic-memory": {
      "command": "basic-memory",
      "args": ["mcp", "--project", "business-memory"]
    }
  }
}

첫 번째 실습: 결정 하나를 저장하고 다른 대화에서 찾기

연결한 AI에 아래 요청을 붙여 넣으세요. 대괄호 안 내용은 실제 업무에 맞게 바꿉니다.

Basic Memory의 business-memory 프로젝트를 사용해줘.
먼저 해당 프로젝트에 접근할 수 있는지 확인해줘.

아래 결정을 20_Decisions 폴더에 노트로 저장해줘.
제목: 블로그 글에 설치 확인 단계를 넣기로 한 결정
날짜: [결정한 날짜]
결정: 설치 명령 다음에 성공 여부를 확인하는 단계를 넣는다.
이유: 명령을 실행했지만 제대로 설치됐는지 모르는 독자가 있었다.
재검토 조건: 독자 피드백을 2주간 모은 뒤 검토한다.

없는 성과 수치나 근거는 만들지 마.
저장 후 실제 도구 결과에 나온 파일 경로 또는 permalink를 알려주고,
저장한 노트를 다시 읽어 내용이 맞는지 확인해줘.

파일 탐색기에서 앞서 만든 폴더를 열어 .md 파일이 생겼는지 확인합니다. 그다음 새 대화에서 다음을 요청해보세요.

Basic Memory의 business-memory 프로젝트에서
'블로그 글에 설치 확인 단계를 넣기로 한 결정'을 찾아줘.
검색 결과의 원문을 읽고 결정, 이유, 재검토 조건을 정리해줘.
근거가 된 노트 제목과 파일 경로 또는 permalink도 붙여줘.
찾지 못한 내용은 추측하지 말고 '기록 없음'이라고 써줘.

다른 AI에서도 같은 기록을 찾고 싶다면 그 도구에도 앞의 MCP 연결을 설정한 후 같은 질문을 합니다. 저장 파일 확인 → 새 대화에서 검색 → 원문 확인까지 되면 기본 흐름을 확인한 것입니다.

복사용 결정 기록 템플릿

아래는 Basic Memory의 노트 구조에 맞춰 만든 예시입니다. Observations에는 사실·결정을, Relations에는 관련 문서와의 관계를 둡니다. 공식 Knowledge Format

---
title: 블로그 글에 설치 확인 단계를 넣기로 한 결정
type: decision
tags: [content, workflow]
status: active
decision_date: "YYYY-MM-DD"
last_reviewed: "YYYY-MM-DD"
---

# 블로그 글에 설치 확인 단계를 넣기로 한 결정

## Observations
- [decision] 설치 명령 뒤에 성공 여부를 확인하는 단계를 넣는다.
- [reason] 독자가 설치 완료 여부를 판단하기 어려웠다.
- [source] 독자 피드백 원문 링크를 여기에 적는다.
- [review] 적용 후 2주간 피드백을 모아 다시 검토한다.

## Relations
- relates_to [[블로그 제작 프로젝트]]

[[블로그 제작 프로젝트]]는 연결할 노트 이름입니다. 해당 노트가 아직 없어도 링크를 남겨 두고 나중에 만들 수 있습니다. decision_date와 last_reviewed는 이 예시에서 추가한 관리 항목이며, 날짜 자리표시자와 출처를 실제 값으로 바꿔 사용하세요.

2. SilverBullet: 메모를 연결하고 흩어진 할 일 모으기

SilverBullet은 Markdown 파일을 바탕으로 메모를 연결하고 검색·쿼리로 재구성할 수 있는 위키입니다. 이 글에서는 조사 자료와 내 생각을 직접 읽고 정리하는 개인 위키로 사용합니다. 오픈소스 설치 대상은 SilverBullet Server입니다. SilverBullet 공식 소개

예를 들어 회의 메모에 [[Projects/콘텐츠]]를 넣으면 콘텐츠 프로젝트 페이지로 이동할 수 있습니다. 반대로 프로젝트 페이지의 Linked Mentions에서는 그 페이지를 언급한 다른 메모와 주변 문맥을 확인합니다. 기본 위치는 페이지 아래쪽이며, 보기 설정에 따라 옮기거나 닫을 수 있습니다. Linked Mention 공식 문서

SilverBullet 설치: Docker Compose로 시작하기

먼저 Docker Compose 설치 안내에 따라 Docker를 준비하고 실행해둡니다. macOS·Windows에서 Docker Desktop을 사용하면 Compose도 함께 제공됩니다. Windows에서는 Linux 컨테이너를 실행할 수 있는 환경을 준비하세요.

터미널에서 실습 폴더를 만듭니다. 아래 두 줄은 macOS·Linux 터미널과 Windows PowerShell에서 모두 사용할 수 있습니다.

mkdir silverbullet-demo
cd silverbullet-demo

이 폴더 안에 compose.yml 파일을 만들고 다음을 저장합니다.

services:
  silverbullet:
    image: ghcr.io/silverbulletmd/silverbullet:2.12.1
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - ./data:/data

공식 예제를 내 컴퓨터에서만 접속하는 실습용으로 바꾸고 정식판 2.12.1을 지정했습니다. 현재 공식 문서는 /data를 데이터 루트로 사용합니다. 예전 안내의 /space 경로를 그대로 섞지 마세요. latest는 최신 정식 릴리스를 가리키는 이동 태그이며 edge는 개발 빌드입니다. 공식 Docker 설치 문서

파일을 저장한 폴더에서 실행합니다.

docker compose up -d
docker compose ps

브라우저에서 http://localhost:3000을 엽니다. 빈 데이터 폴더로 처음 시작하면 관리자 계정을 만들고 첫 Space를 설정하는 과정이 나옵니다. Space는 메모가 들어가는 작업 공간입니다. 기본 콘텐츠 폴더는 데이터 루트 안에 만들어지며, 실제 위치는 설정에서 확인할 수 있습니다. Dashboard 초기 설정

Space에 들어간 뒤 명령 팔레트에서 Client: Version을 실행하면 사용 중인 버전을 확인할 수 있습니다.

링크와 역링크를 직접 확인하기

첫 번째 페이지 이름을 Projects/콘텐츠로 만들고 아래 내용을 넣습니다.

# 콘텐츠 프로젝트

## 목표
독자가 설치부터 첫 결과 확인까지 따라 할 수 있는 글을 만든다.

## 다음 행동
* [ ] 초안에 설치 성공 확인 단계를 넣는다.

두 번째 페이지 이름을 Daily/2026-10-16으로 만들고 아래 내용을 넣습니다. 날짜는 작성하는 날에 맞춰 바꿔도 됩니다.

# 오늘의 작업

[[Projects/콘텐츠]] 글의 실습 부분을 보완했다.

* [ ] [[Projects/콘텐츠]] 공식 문서 링크가 열리는지 확인한다.
* [x] 글의 주제를 정한다.

이제 Projects/콘텐츠를 열면 Linked Mentions에서 일일 메모의 언급을 찾을 수 있습니다. 보이지 않으면 명령 팔레트에서 Navigate: Linked Mentions를 실행해보세요. 체크하지 않은 할 일 중 이 페이지를 언급한 항목은 Linked Tasks에서도 확인할 수 있습니다. Linked Tasks 공식 문서

미완료 할 일을 한 페이지에 모으는 쿼리

Tasks 페이지를 만들고 아래 한 줄을 일반 본문에 그대로 붙여 넣으세요. SilverBullet 안에서는 코드 블록으로 감싸지 않습니다.

${query[[from t = index.tasks() where not t.done order by t.page select templates.taskItem(t)]]}

이 예제는 Space의 작업을 가져와 완료하지 않은 항목만 남기고, 작업이 적힌 페이지 이름 순서로 정렬해 목록으로 표시합니다. 다른 미완료 작업이 없는 Space에서 위의 두 페이지를 작성했다면 미완료 작업 2개가 모이고 완료한 작업은 빠져야 합니다.

SilverBullet은 체크박스 작업을 색인하고, Space Lua의 쿼리 문법과 작업 표시 템플릿으로 이를 모아 보여줍니다. 오래된 query 코드 블록 예제와 현재 문법을 섞지 않는 것이 좋습니다. Task, 작업 객체와 템플릿, 현재 쿼리 문법

메모를 위키로 정리하는 복사용 프롬프트

SilverBullet 자체에 AI가 자동 연결되었다고 가정할 필요는 없습니다. 다음 요청과 메모를 AI에 전달해 Markdown을 만든 뒤, 내가 검토하고 SilverBullet에 붙여 넣어도 됩니다.

아래 메모를 SilverBullet에 넣을 개인 위키 초안으로 정리해줘.

1. 확인된 사실, 내 해석, 다음 행동을 나눠줘.
2. 관련된 페이지는 [[페이지 이름]]으로 연결해줘.
3. 아직 없는 페이지를 제안할 때는 '새로 만들 페이지'로 따로 표시해줘.
4. 다음 행동은 * [ ] 형식으로 써줘.
5. 출처 URL과 확인 날짜를 보존하고, 없는 근거는 만들지 마.
6. 팀의 확정 규칙처럼 표현하지 말고 검토용 초안으로 써줘.

[정리할 메모]
여기에 메모를 붙여 넣기

[이미 있는 페이지]
Projects/콘텐츠
Daily/2026-10-16

3. Docmost: 팀이 같은 기준을 보는 위키 만들기

Docmost는 여러 사람이 문서를 함께 편집하고, 팀·프로젝트별 공간에서 관리하는 협업 위키입니다. 실시간 공동 편집, 댓글, 검색, 페이지 이력, 공간별 권한을 갖췄습니다. 팀 매뉴얼과 온보딩 문서를 직접 운영하려는 경우에 적합합니다. Docmost 공식 소개

개인 메모의 “이렇게 해보면 어떨까?”와 팀 문서의 “이번 주부터 이렇게 진행합니다”는 다릅니다. Docmost에는 후자처럼 누가 봐도 실행 기준을 알 수 있는 문서를 모으는 방식으로 시작해보세요.

무료 기능과 유료 기능을 먼저 구분하세요

무료 Open Source 에디션으로도 기본 문서 작성과 협업을 시작할 수 있습니다. 다만 공식 문서의 모든 기능이 무료인 것은 아닙니다.

따라서 “팀마다 누가 볼 수 있는지 정한다”와 “모든 페이지에 무료로 세부 권한을 건다”를 같은 기능으로 보면 안 됩니다. 아래에서 제안하는 문서 검토 절차는 사람이 운영하는 규칙이며, 유료 승인 기능을 전제로 하지 않습니다. 에디션 안내, 유료 기능 목록, 공간 역할

Docmost 설치: 공식 Compose 파일로 로컬 실행하기

Docker가 실행 중이어야 합니다. SilverBullet과 동시에 실습할 수 있도록 Docmost는 3001번 포트를 사용하겠습니다.

mkdir docmost-demo
cd docmost-demo
curl -fL https://raw.githubusercontent.com/docmost/docmost/v0.96.0/docker-compose.yml -o docker-compose.yml

mkdir docmost-demo
cd docmost-demo
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/docmost/docmost/v0.96.0/docker-compose.yml" -OutFile "docker-compose.yml"

이 파일은 Docmost와 PostgreSQL, Redis를 함께 실행하고 필요한 데이터를 볼륨에 보관합니다. 공식 설치 문서의 Compose 구성을 따르되, 개발 브랜치 대신 0.96.0 릴리스에 포함된 파일을 받습니다. 이 파일 안의 앱 이미지는 여전히 latest이므로 아래 표에 따라 버전도 바꿔주세요.

다음 명령으로 서로 다른 비밀값 두 개를 만듭니다. Docker로 임시 Python 컨테이너를 실행하므로 컴퓨터에 Python을 따로 설치할 필요는 없습니다. 첫 실행에는 이미지 다운로드가 필요합니다.

docker run --rm python:3.12-alpine python -c "import secrets; print('APP_SECRET=' + secrets.token_hex(32)); print('DB_PASSWORD=' + secrets.token_hex(24))"

이어서 docker-compose.yml을 편집기로 열고 다음을 바꾸세요. 생성된 값은 본인 설정 파일에만 넣고 공개 문서나 저장소에 올리지 않습니다.

생성 결과에서는 = 뒤의 값만 복사합니다. DATABASE_URL은 주소 전체를 지우는 것이 아니라 비밀번호 부분만 바꿉니다. 두 위치의 데이터베이스 비밀번호가 같아야 합니다. 공식 문서상 APP_SECRET은 최소 32자이며 기본값을 그대로 두면 시작에 실패합니다. Docmost 필수 설정

같은 폴더에서 실행합니다. 첫 명령은 Compose 설정의 형식을 검사하며, 앱이 정상 작동하는지는 실행 후 브라우저에서 별도로 확인합니다.

docker compose config --quiet
docker compose up -d
docker compose ps

브라우저에서 http://localhost:3001을 열어 워크스페이스와 첫 계정을 만듭니다. http://localhost:3001/api/health도 상태 확인에 사용할 수 있습니다. 공식 실행·확인 절차

위 예제는 내 컴퓨터에서 기능을 확인하는 설정입니다. 실제 팀 서버에서는 외부 도메인에 맞게 APP_URL을 바꾸고 HTTPS·인증·백업을 준비해야 합니다. 실시간 편집을 위해 리버스 프록시의 WebSocket 지원도 확인하세요. 공식 리버스 프록시 안내

첫날에는 공간 하나와 문서 하나만 만드세요

1. Settings → Spaces에서 콘텐츠 운영 공간을 만듭니다.
2. 공간의 Members에서 담당자나 그룹을 추가합니다.
3. 편집 담당자는 Can Edit, 읽기만 필요한 팀원은 Viewer로 배정합니다.
4. 새 페이지에 아래 양식을 넣고 실제 업무 한 개를 정리합니다.

공간 설정과 구성원·권한을 관리할 담당자는 Full Access가 필요합니다. 공간 만들기와 역할 설정

아래는 직접 복사해서 쓰는 문서 내용 양식입니다. Docmost의 유료 내장 템플릿 기능을 사용하지 않아도 됩니다. Markdown 파일로 저장해 가져오거나 새 페이지를 작성할 때 참고하세요.

# 블로그 발행 전 검수 기준

문서 상태: 초안 / 적용 중 / 폐기
담당자: [이름 또는 역할]
적용 대상: [팀·문서 종류]
적용일: [YYYY-MM-DD]
마지막 검토일: [YYYY-MM-DD]
다음 검토일: [YYYY-MM-DD]
결정 배경: [관련 기록 링크]

## 목적
독자가 설치부터 첫 결과 확인까지 따라 할 수 있게 한다.

## 절차
1. 작성자는 공식 문서의 출처와 확인 날짜를 남긴다.
2. 검수자는 명령어, 필수 설정, 성공 확인 단계를 점검한다.
3. 발행 담당자는 링크와 미리보기를 확인한다.

## 완료 기준
- 각 명령을 어디에서 실행하는지 적혀 있다.
- 독자가 바꿔야 할 값이 구분되어 있다.
- 성공했을 때 확인할 화면이나 결과가 있다.

## 예외
직접 실행하지 못한 예제는 검증 범위를 표시한다.

## 변경 이력
- [날짜]: [무엇을 왜 바꿨는지]

Notion 문서 가져오기와 이전 버전 복원

Notion에서 문서나 워크스페이스를 Markdown 또는 HTML이 들어 있는 ZIP으로 내보낸 뒤, Docmost 대상 공간의 Pages 옆 메뉴에서 Import pages → Notion을 선택해 올립니다. 공식 문서는 페이지 구조를 보존하는 가져오기를 안내합니다. Notion 가져오기

다만 이를 Notion의 모든 동작까지 똑같이 복제한다는 뜻으로 받아들이면 안 됩니다. 이전 전에 텍스트·이미지·하위 페이지·내부 링크가 있는 대표 문서를 골라 가져오고, 데이터베이스·수식·권한처럼 업무에 필요한 요소가 기대대로 옮겨졌는지 비교하세요. 이 검사는 전체 이전 여부를 정하기 위한 권장 절차입니다.

문서 내용을 잘못 수정했다면 페이지 메뉴의 Page history에서 저장된 버전을 보고 Restore로 복원할 수 있습니다. 저장된 이력 단위의 복원이므로 모든 키 입력을 개별적으로 되돌리는 기록이라고 생각하면 안 됩니다. 페이지 자체를 삭제했다면 휴지통 복원을 확인합니다. 페이지 이력과 삭제·복원

세 도구를 같이 쓸 때 중복 문서를 막는 방법

팀이 따라야 할 현재 기준은 원본 하나로 정하고, 다른 도구에는 링크와 배경만 남깁니다. 세 도구를 전부 쓰더라도 같은 매뉴얼 세 벌을 각각 수정할 필요는 없습니다.

아래는 이 글에서 제안하는 수동 운영 흐름입니다. 세 도구가 자동으로 동기화된다는 뜻은 아닙니다.

무엇을 어디에 저장할까요?

예를 들어 “글에 설치 확인 단계를 넣자”라는 결정은 Basic Memory에 남깁니다. SilverBullet에서는 독자 피드백과 개선 아이디어를 연결합니다. 팀이 합의하면 Docmost의 블로그 발행 전 검수 기준에 실제 절차를 반영합니다.

이후 개인 메모에는 “현재 검수 기준은 Docmost의 이 페이지”라는 링크를 남깁니다. 과거 결정을 찾아온 AI도 지금 적용 중인 기준과 당시의 판단을 구분할 수 있게 하는 것입니다.

개인 메모를 팀 위키로 옮길 기준 4가지

아래는 제품의 자동 기능이 아니라 팀에서 합의해 쓸 수 있는 체크 기준입니다.

• 반복성: 나 말고 다른 팀원도 같은 상황에서 사용할 내용인가?
• 확정성: 아이디어를 넘어 실제로 따르기로 결정한 내용인가?
• 실행 가능성: 담당자·순서·완료 조건·예외가 적혀 있는가?
• 관리 가능성: 최신 원본 위치와 다음 검토 담당자가 정해졌는가?

모두 충족하면 Docmost의 운영 문서로 정리합니다. 아직 근거가 부족하면 개인 메모에 남겨 검토를 이어가세요.

아래 개인 메모를 팀 위키에 올릴 후보 문서로 검토해줘.

먼저 반복성, 확정성, 실행 가능성, 관리 가능성을 각각 점검해줘.
근거가 부족하면 임의로 승인하지 말고 확인할 질문을 적어줘.

그다음 '목적 → 적용 범위 → 담당자와 절차 → 완료 기준 → 예외 → 변경 이력'
순서로 Docmost용 초안을 작성해줘.
담당자, 적용일, 마지막 검토일, 다음 검토일, 원본 출처를 포함해줘.
이미 팀의 공식 기준이 있다면 새 문서를 만들기보다 수정할 부분을 제안해줘.

실제 게시나 원본 덮어쓰기는 하지 말고, 사람이 검토할 초안만 보여줘.

[개인 메모]
여기에 붙여 넣기

[현재 팀 기준]
접근 가능한 본문과 출처 링크를 여기에 붙여 넣기

링크만 전달했는데 AI가 해당 비공개 위키를 읽을 수 있다고 가정하지 마세요. 연결된 도구에 접근 권한이 없다면 필요한 본문을 함께 전달해야 합니다.

설치 후 막혔을 때 확인할 것

위 설치 예제는 공식 문서·설정을 대조해 구성했습니다. 이 글의 작성 환경에서는 세 서비스를 직접 구동해 전체 동작을 시험하지 않았으므로, 각 절의 성공 확인 단계를 본인 환경에서 따라 해보세요.

명령 경로 문제는 uv 도구 설치 안내, MCP 경로 설정은 Basic Memory 로컬 설치, 색인 상태는 CLI 참조를 참고하세요. Docmost의 필수 환경 변수와 WebSocket 조건은 공식 설치 문서에 정리돼 있습니다.

백업도 원본 위치에 맞춰 준비합니다. Basic Memory는 노트 폴더를, SilverBullet은 콘텐츠와 서버 설정이 있는 데이터 폴더를 보관합니다. Docmost는 페이지 내보내기뿐 아니라 데이터베이스·첨부 파일·설정을 복구할 수 있어야 합니다. 동기화와 페이지 이력만 믿지 말고, 별도 보관한 복사본으로 복원되는지 확인하세요.

자주 묻는 질문

오늘 할 일: 기록 하나를 저장하고 다시 찾아보세요

첫날의 목표는 도구 세 개를 설치하는 것이 아닙니다. 지난 결정을 다음 업무에서 다시 쓰는 경험을 한 번 만드는 것입니다.

1. 이번 주에 다시 설명했던 업무나 반복해서 받은 질문 하나를 고릅니다.
2. 그 답의 원본을 둘 도구 하나를 정합니다.
3. 결정 이유·출처·다음 행동을 짧게 기록합니다.
4. 새 대화나 다른 팀원이 그 기록만 보고 답을 찾을 수 있는지 확인합니다.

일주일 뒤에는 기록 수보다 찾는 데 걸린 시간, 다시 물어본 질문 수, 서로 다른 최신본의 개수를 살펴보세요. 같은 내용을 덜 설명하고 더 정확한 근거로 일하게 됐다면, 지식 관리가 실제로 도움이 되기 시작한 것입니다.

이미 Obsidian을 쓰고 있다면 Claude Code와 Obsidian으로 세컨드브레인 만들기도 함께 읽어보세요. MCP 연결이 처음이라면 Claude MCP 연결 가이드가 도움이 됩니다.