팀 시범 도입 전에
민감한 정보가 없는 프로젝트로 시작하고, 서버와 계정, 업데이트, 백업을 관리할 운영자를 정하세요. 팀원을 초대하기 전에 누가 프로젝트를 읽고 쓸 수 있는지 확인하세요.
소프트웨어는 무료입니다. 머신과 운영 관리는 직접 준비합니다. 선택 사항인 클라우드 모델 제공업체의 요금은 각자 계정으로 청구됩니다.
모두가 바라보는 서버 하나
단일 바이너리에 SQLite 파일 하나, markdown 폴더 하나입니다. 사이드카도 벡터 데이터베이스도 없고, 동기화를 맞춰야 할 것도 없습니다.
Claude Code
Codex
Cursor
Gemini CLI
ai-memory 서버 한 대
프로젝트 위키
프로젝트 안에서 지식 공유
프로젝트 접근 권한이 있는 사용자는 해당 페이지를 읽을 수 있습니다. 한 사람의 Codex 세션에서 팀원의 Claude Code 세션이 지난주 기록한 문제를 찾을 수 있습니다.
다음 쿼리부터 보입니다
해당 프로젝트에 접근할 수 있는 사용자의 다음 검색이나 세션 브리핑에 팀원의 메모가 나타날 수 있습니다. 실행 중인 세션은 중단하지 않습니다.
에이전트는 무엇을 섞어 써도 됩니다
각자 좋아하는 에이전트를 그대로 씁니다. 모든 메모리 호출은 세션의 디렉터리로 프로젝트를 판별하므로, 동시에 돌아가는 세션끼리 섞이지 않습니다.
새로 온 개발자의 첫날
키를 받고, 에이전트를 서버에 연결하고, 그동안 무슨 일이 있었는지 프로젝트에 물어봅니다.
API 키 받기
서버 지정
현황 알려 줘
위키 검색
첫날
프로젝트에 직접 묻습니다
"그동안 있었던 일 알려 줘"라고 하면 최근 작업의 다이제스트가 나옵니다. "재시도 로직에 대해 논의한 적 있어?"라고 하면 결정 페이지와 그 근거가 된 세션들이 나옵니다.
위키는 살아 있는 지식 베이스입니다
세션이 자동으로 메모를 추가하고 git 이력과 함께 markdown으로 저장합니다. 공식 지침은 검토한 문서로 유지하고, 중요한 결정은 출처와 대조하세요.
직접 쓴 문서를 보완합니다
페이지는 세션에서 만들어지며 에이전트가 찾아 쓰기 좋은 형태입니다. 손으로 쓴 README와 아키텍처 문서는 그대로 두고, 위키에는 이유와 막다른 길을 맡기세요.
다이제스트는 LLM 제공자가 있으면 서술형으로, 없으면 구조화된 데이터로 반환됩니다. --enable-web을 사용하면 브라우저에서 위키를 확인할 수 있고 root는 보류 중인 편집 제안도 검토할 수 있습니다.
지식은 공유하고 인수인계는 개인별로
인수인계는 끝내지 못한 작업을 저장한 요약입니다. 프로젝트 페이지는 접근 권한이 있는 사용자와 공유하고, 인수인계는 남긴 사람에게 속합니다.
지식은 공유
바통은 한 사람 것
- 대기 중인 인수인계(핸드오프)는 여러분의 다음 세션으로 갑니다. 같은 저장소에서 에이전트를 시작한 팀원이 그것을 받거나 소비하는 일은 없습니다.
- 작업을 이어받을 누구에게든 바통을 공개하고 싶다면
shared: true를 넘기세요. - 두 사람이 같은 페이지를 수정하면 버전 체인이 만들어집니다. 나중에 쓴 쪽이 최신이 되고, 먼저 쓴 쪽도 계속 조회할 수 있습니다. 병합은 없고 사라지는 것도 없습니다.
- 선택 사항인 개인 슬롯에는 "지금 내가 하고 있는 일"이 담기며 팀 브리핑에는 나오지 않습니다. 기본값은 꺼짐입니다.
# 기본은 개인용: 여러분의 다음 세션만 받습니다
"다음 세션을 위해 맥락을 저장해 줘."
# 의도적으로 공개하기: memory_handoff_begin with shared: true
"내일 이 작업을 이어받는 사람이 받을 수 있게 공유 인수인계를 저장해 줘."
에이전트끼리 프로젝트를 넘어 메시지를 보낼 수 있습니다
프런트엔드 저장소의 에이전트에게 API 저장소의 엔드포인트가 필요합니다. 에이전트는 그 자체로 완결된 요청을 해당 프로젝트의 인박스로 보내고, 그쪽의 다음 세션이 이를 꺼냅니다. 메시지는 한 번만 수령되고, 수신 프로젝트는 이미 존재해야 하며, 인박스에는 대기 메시지가 최대 256개까지 쌓입니다. 메시징의 동작 방식.
계정, 키, 감사 기능까지. 유료 티어는 없습니다
팀 기능은 나머지 전부와 같은 MIT 바이너리에 들어 있습니다.
사람마다 이름 있는 계정
명령 하나로 사용자를 추가합니다. 계정을 비활성화하면 브라우저 접근이 끝나고 페이지는 유지됩니다. 직접 발급한 API 키는 별도로 폐기해야 합니다.
컴퓨터별 API 키
한 사람이 노트북이나 에이전트마다 하나씩, 라벨을 붙인 키를 여러 개 가질 수 있습니다. 키를 교체하면 이전 키는 즉시 거부됩니다.
모든 쓰기에 작성자 표시
페이지마다 작성자가 기록되고, 웹 UI에서 누가 수정했는지 볼 수 있습니다. 작성자 정보가 읽기 권한을 제한하는 일은 없습니다.
모든 변경을 담는 감사 로그
쓰기는 작성자의 id와 함께 기록됩니다. admission 웹훅은 행위자를 확인하고 작업을 거부할 수 있습니다.
감사 로그를 조회하는 화면이나 명령은 아직 문서화된 것이 없으므로, SQLite 파일의 audit_log 테이블을 직접 쿼리한다고 생각하세요. 역할, 비밀번호 로그인, 키 교체는 GitHub의 사용자 가이드에서 다룹니다.
서버 한 대가 초당 약 700건의 쓰기를 처리하며, 이는 활성 에이전트 수백 개를 감당하는 수준입니다. 측정 방법 보기.
팀 설정하기
설치 페이지에서 순서대로 안내합니다. 서버 한 대를 띄우고, 사람마다 키를 발급하고, 각자의 에이전트가 그 서버를 바라보게 합니다.
자주 묻는 질문
여러 개발자가 ai-memory 서버 하나를 함께 쓸 수 있나요?
네. 서버 하나에 위키를 두고 에이전트를 연결합니다. 프로젝트는 기본적으로 열려 있으며, 데이터베이스 사용자 계정은 프로젝트 권한으로 제한할 수 있습니다. 명시적으로 공유하지 않은 인수인계는 작성자에게 속합니다.
팀으로 쓰려면 유료 티어가 필요한가요?
아니요. 사람별 계정, API 키, 작성자 표시, 감사 로그는 오픈 소스 바이너리에 포함되어 있습니다.
프로젝트나 페이지를 일부 사용자에게만 제한할 수 있나요?
데이터베이스 사용자 계정에 대해 프로젝트 전체를 제한할 수 있습니다. root, 생성자, 권한을 부여받은 사용자는 계속 접근할 수 있으며 쓰기 권한에는 읽기가 포함됩니다. 프로젝트 안의 개별 페이지에는 별도 권한이 없습니다. 신뢰하는 프록시를 쓰는 배포에서는 프록시에서 접근을 제어해야 합니다.
서버 하나로 개발자 몇 명까지 감당할 수 있나요?
측정된 쓰기 상한은 빠른 로컬 디스크 기준 초당 약 700회이며, 프로젝트는 이를 동시에 활동하는 에이전트 수백 개 수준으로 해석합니다. 이 수치는 저장소 계층을 측정한 것이고, 네트워크 디스크에서는 더 느립니다.