掘金2026년 11월 5일 18:34중국어 → 한국어

코딩 에이전트에 저장소 따라가는 기억 부여하기

RSI-BOOT는 프로젝트 규칙과 교훈을 저장소의 .rsi/에 두어 도구를 넘나들며 유지하고 API 키 없이 쓰는 방식을 제안한다.

중국어 원문을 AI로 번역했습니다. 고유명사와 수치는 원문 표기를 우선하며, 중요한 판단에는 아래 출처 원문을 함께 확인하세요.

시리즈: 《AI 공유 메모리: RSI-BOOT가 도구를 넘나들고 여러 사람이 협업해 하나의 메모리 저장소를 공유하도록 만든다》 제1편. 시리즈 심층 탐구: RSI가 대체 무엇인가 - 제2편, 설치하고 실행하기 - 제3편, 다섯 호스트에 연결하기 - 제4편, 회수 링크 메커니즘 - 제5편, 벤치마크 공신력 - 제23/24/25편, Mem0와의 선정 비교 - 제26편에서 확인할 수 있다.

당신은 이 프로젝트에서 Agent에게 세 가지를 가르쳤다: 함수명은 스네이크(snake) 표기법을 쓰고, 결제 로그에 카드번호를 남기면 안 되며, 지난번 그 널 포인터(null pointer)는 먼저 null 체크를 하고 나서 필드를 가져와야 한다는 것. 이 세 가지는 이 저장소의 규칙이지, 어느 한 번의 채팅에서 나온 쓸데없는 말이 아니다.

그런데 이것들은 지금 저장소를 따라오지 않는 경우가 많다: 호스트의 메모리 기능이 언젠가 삭제될 수 있고, 로컬 메모리는 git에 들어가지 않으며, 클라우드 메모리는 저장소가 아니라 계정을 따라간다.

잃는 방식 세 가지, 그 대가는 각기 다르며, 바로 다음 절에서 하나씩 설명한다.

RSI-BOOT는 규약, 금지 항목, 그리고 고쳐온 교훈을 저장소 자체의 .rsi/ 에 넣는다. 디렉터리가 저장소를 따라가므로, 다른 저장소를 열면 그것은 또 다른 한 부이고, 서로 섞이지 않는다. Cursor, Claude Code, Codex, Qoder, DeepSeek Harness가 바로 이 한 부에 연결된다. 메인 경로는 모델을 호출하지 않고 API Key도 필요 없다.

1. 세 가지痛点: 규칙은 왜 늘 사라지는가

"프로젝트 규칙을 기억하지 못한다"는 일을 해체해서 보면, 실은 세 가지 서로 다른 상실 방식이며, 각각에 대응하는 대가가 다르고 해결책도 완전히 다르다.

첫 번째 유형: 호스트가 그것을 삭제한다. Cursor 2.1은 Memories 기능을 아예 잘라냈고, 사용자가 그 안에 저장해 둔 프로젝트 지식도 함께 증발했다. 이는 개별 사례가 아니다. AI 프로그래밍 호스트의 "메모리" 기능은 오랫동안 실험적 상태에 머물러 있어, 오늘 있던 것이 내일 없어질 수 있고, 제품 전략이 한 번 조정되면 당신이 가르친 것이 말 그대로 사라진다. 호스트 자체의 메모리 저장에 의존하는 것은, 공학 규칙을 남의 제품 로드맵에 거는 것과 같다. 더 은밀한 문제는, 많은 호스트의 "메모리"가 무구조·무승인 상태라 잡담과 제대로 된 제약이 뒤섞여 있어, 당신조차 어느 것이 규칙이고 어느 것이 노이즈인지 구분하지 못한다는 점이다.

두 번째 유형: 로컬에 갇혀 git에 들어가지 않는다. Claude Code 같은 도구는 로컬 디스크에 일종의 "자동 메모리"를 써 넣지만, 그것들은 기본적으로 현재 기기, 현재 계정에서만 산다. 당신이 컴퓨터를 바꾸거나, 동료가 같은 저장소를 내려받아도 이 메모리는 나타나지 않는다. 결과는 같은 저장소인데 세 사람이 세 가지 메모리를 갖게 되고, 누구도 서로 맞출 수 없다. 더 나쁜 것은, 버전 관리에 들어가지 않기에 이 메모리는 code review도 할 수 없고 팀 안에서 전승될 수도 없다는 점이다. 그것들은 "당신의 이 컴퓨터에만 속한 유령 지식"이 되어버린다.

세 번째 유형: 클라우드에서 계정을 따라간다. 메모리를 클라우드에 두면(Mem0 같은 것) "기기 교체" 문제를 해결할 수 있지만, 새로운 대가를 불러온다: API Key가 필요하고, 네트워크 연결이 필요하며, 메모리가 어떤 저장소가 아니라 어떤 클라우드 계정에 귀속된다. 저장소를 고객에게 복사해 주거나, 오픈소스로 공개하거나, 혹은 당신이 그 클라우드 계정을 해지할 때, 메모리는 서비스 제공자에게 남는다. 많은 팀에게 "이 저장소의 금지 항목"을 제3자 계정에 위탁하는 것 자체가 컴플라이언스의 레드라인이다. 특히 금융, 의료처럼 데이터 거주(data residency)에 강제 요구가 있는 업종에서 그렇다.

세 가지痛点의 공통된 근본 원인은 단 하나다: 프로젝트 규칙이 "어떤 채팅 / 어떤 기기 / 어떤 클라우드 계정"에 묶여 있는 것이지, 그것이 진짜 있어야 할 곳인 저장소 자체에 묶여 있지 않다는 것. RSI-BOOT의 제1원리는 바로 메모리의 귀속을 "세션/계정"에서 "저장소"로 되돌려 놓는 것이다. 저장소는 코드를 따라가고, git에 들어갈 수 있으며, 팀이 공유할 수 있는 유일한 매개체이므로, 메모리도 그곳에 살아야 한다.

2. 한 문장의 포지셔닝, 그리고 반드시 짚고 넘어가야 할 정체성

RSI-BOOT의 포지셔닝은 한 문장으로 끝낼 수 있다: 프로젝트 메모리가 저장소를 따라가고, 도구를 넘나들어 한 부이며, API Key가 필요 없다.

- 저장소를 따라간다 : 메모리는 저장소 루트의 .rsi/ 에 놓이고, git을 따라 흐른다. 디렉터리를 바꾸든, 기기를 바꾸든, 동료를 바꾸든, 저장소만 있으면 메모리도 함께 있다. 다른 저장소를 열면 또 다른 한 부이고, 서로 맛이 섞이지 않는다.

- 도구를 넘나들어 한 부 : Cursor, Claude Code, Codex, Qoder, DeepSeek Harness가 연결되는 것은 동일한 rsi serve가 노출하는 MCP 서비스이며, 읽는 것은 동일한 .rsi/ 이다. 오전에 Cursor에서 기록한 금지 항목을 저녁에 Codex를 열어 읽으면, 읽히는 것은 같은 조항이다.

- API Key 제로 : 메인 경로(회수, 주입, 승인)는 어떤 대형 모델도 호출하지 않고, embedding도 호출하지 않으며, 네트워크에 연결하지 않는다. "프로젝트 규칙을 기억"하기 위해 어떤 키도 신청할 필요가 없다.

하지만 여기서 반드시 서두에 짚고 넘어가야 할 것이 있다. RSI가 대체 어떤 정체성인가 하는 것이다. 그것은 또 하나의 "지식 베이스"도 아니고 "채팅 기록 관리기"도 아니다. 저장소의 설계 문서에서 그 포지셔닝은 아주 단호하게 적혀 있다:

RSI는 호스트 모델의 절차적 기억 계층(procedural memory layer)이지, 저장소 이해기가 아니다. 그것은 "어떻게 하는가"(규약 / 금지 항목 / 버그 수정 경험 / 스킬)만 축적하며, 저장소 의미를 해석하지 않고, 호스트 모델을 대신해 답을 생성하지 않는다.

이 문장은 매 편의 서두에 박아둘 만하다. 뒤에서 우리는 한 편 전체(제2편)를 할애해 그것이 왜 "절차적"이고 "사실적"이 아닌지를 펼칠 것이지만, 당신은 먼저 이 결론을 기억해야 한다: RSI가 바꾸는 것은 Agent의 행동 방식이지, Agent에게 참고 자료를 한 부 더 밀어 넣는 것이 아니다. 이것이 또한 그것이 대다수 "AI 메모리" 방안과 가장 본질적으로 갈라지는 지점이다. 남들은 "무언가를 더 아는 것"에 힘을 쓰지만, 그것은 "다음엔 다시 실수하지 않는 것"에 힘을 쓴다.

당신이 즉시 직관을 세우도록, 여기 먼저 "그것이 무엇인가 / 무엇이 아닌가"의 속람표를 제시하고, 세부는 뒤에서 편별로 펼친다:

3. 쓰임은 하나의 고리

포지셔닝만 말하면 너무 추상적이다. RSI-BOOT가 실제로 쓰일 때는 하나의 폐쇄 루프다. 현재 프로젝트 창의 Agent에게 "이 프로젝트를 처음 배운다"고 말하면, 그것이 이 저장소를 스캔해 발견한 것을 심사 대기 항목으로 써낸다. 당신이 승인한 뒤에야 다음 회수에서 읽히고, 승인하지 않은 것은 다음 컨텍스트에 섞여 들어오지 않는다.

그 후 일상은 이 몇 마디의 간단한 상호작용이다:

당신이 고개를 끄덕여(승인해) 정한 약속은 저장소 루트의 AGENTS.md에 있는 관리 블록에 기록되고, .cursor/rules 에도 기록됩니다. MCP를 연결하지 않은 도구가 이 저장소를 열어도 이 부분을 읽을 수 있습니다. MCP를 연결한 도구는 같은 .rsi/ 를 읽어 소환합니다. 오전에 Cursor에서 기록한 금지 항목을 저녁에 다른 도구로 바꾸거나 동료가 Codex로 열어도, 읽어오는 것은 같은 한 조항입니다.

이 고리를 그림으로 그리면 더 명확해집니다.

flowchart LR A[소환: 작업 시작 전 프로젝트 규칙 읽기] --> B[작업: 소환된 금지 항목과 약속 준수] B --> C[증류: 수정법/교훈을 심사 대기 항목으로 작성] C --> D[사람 승인: 당신이 고개를 끄덕여야 남는다] D --> A B -. 부정적 피드백 .-> E[실패 버킷: 쓰기 가능한 슬롯만 수정] E --> F[제안→게이트→7일 관찰→롤백]

이것이 "고리"의 완전한 서사 버전입니다. 소환 → 작업 → 심사 대기 항목으로 증류 → 사람이 승인해야 남는다 → 다음 라운드 소환에서 남은 항목을 읽는다. 가운데의 관문에 주목하세요. "사람 승인"은 기억이 남는 유일한 스위치이며, 모델은 스스로 무언가를 저장소에 기록할 수 없습니다. 이것이 이후 모든 신뢰 설계의 지점입니다.

구체적인 미니 예시를 하나 들어 보겠습니다. 당신이 널 포인터 하나를 고쳤습니다. 어떤 함수가 user.profile.name 을 곧바로 가져오는데, profile이 null일 때 인터페이스 전체가 500이 납니다. 당신이 Agent에게 이 교훈을 기록하라고 하자, 호스트가 teaching_case (교수 사례) 하나를 증류해 냅니다.

- wrong_action : 중첩 필드를 곧바로 가져오고, 널 검사를 하지 않음.

- correct_fix : 먼저 profile이 존재하는지 검사하고, 없을 때는 기본값으로 가거나 명시적으로 오류를 냄.

- error_signature : "객체의 깊은 필드를 가져오기 전에 널 검사를 하지 않은" 모든 구현.

이 교훈이 저장된 후, 다음에 당신(또는 동료)이 비슷하게 필드를 가져오는 코드를 다시 작성하면, 소환이 이 교훈을 되가져와 금지 항목 뒤에 "회피 권장"으로 배치합니다. 그것은 "널 포인터 조심하세요"라는 쓸데없는 말이 아니라, 구조를 갖추고, 위치를 특정할 수 있으며, 코드 수정을 직접 지도할 수 있는 제약입니다. 이것이 "절차적 기억"이 고리 안에 자리 잡은 모습입니다.

또한 독립적인 우회로가 하나 있습니다. Agent가 규칙대로 하다가 일을 망치면, 이 규칙은 몰래 바뀌지 않고 부정적 피드백으로 실패 버킷에 들어갑니다. 실패 버킷은 자기 개선 폐루프에만 공급되고, 폐루프는 그 몇 개의 쓰기 가능한 슬롯 (프롬프트 / 스킬 / 소환 전략 / 의도 규칙 / 지식)만 바꾸며, 당신의 비즈니스 코드는 절대 건드리지 않습니다. 제안은 정적 게이트를 통과해야 하고, 당신의 확인도 받아야 하며, 7일을 관찰하고, 채택률이 떨어지면 자동으로 롤백됩니다. 이 고리는 이미 소프트웨어에 적혀 있습니다(13–16편에서 펼쳐집니다).

여기에 기록되는 것은 이 저장소의 작성 방식, 금지 항목, 버그 수정 경험입니다. 채팅 기록은 여기에 없습니다 — 이것은 철칙이며, 시리즈에서 반복해서 나옵니다. "Agent의 공학 기억은 대화 기억이 아니다".

四、정직한 예고: 기준 숫자는 "찾아낼 수 있는가"만 답한다

여기까지 준비했으니, 당신은 아마 궁금할 것입니다. 도대체 쓸모가 있는가? 먼저 숫자 한 묶음을 제시하지만, 기준을 반드시 명확히 해야 합니다 — 이 숫자들은 예고용 갈고리에 불과하며, 완전한 방법론과 항목별 편차는 23/24/25편으로 미룹니다.

소환은 RSI-BOOT의 공개 메인 순위표입니다. 문제는 남의 것입니다(LoCoMo 1536문제, LongMemEval-S 500문제). 소환은 RSI-BOOT 자체의 콜드 스타트로, 단어로 기억을 대조하며, 기본적으로 5개를 제출하고, 추가로 10개도 측정했습니다. 다른 모델을 연결해 답안을 작성하게 하지는 않았습니다. 따라서 아래 보고하는 것은 검색 적중 이지 모델의 답안 점수가 아닙니다.

데이터셋 입증 가능한 문제 Hit@5 Recall@5 MRR LoCoMo 1536 56.5% 51.0% 0.427 LongMemEval-S 500 96.6% 90.1% 0.907

토큰 이득도 하나 있습니다. 본 저장소에 관한 같은 질문 세트를, 기억을 끄고 한 번 답하고 기억을 켜고 다시 한 번 답했을 때, Cursor가 보고한 토큰 합계가 74.1% 절감 되었습니다 (여섯 그룹의 세부 내용은 후술).

왜 내가 "찾아낼 수 있는가"만 답한다고 강조하는가? 쉽게 잘못된 자를 대기 때문입니다. Mem0 홈페이지의 92.5(LoCoMo), 94.4(LongMemEval)는 다른 방식입니다. 먼저 모델이 답하게 하고, 심판이 점수를 매기며, 앞 50개 또는 앞 200개를 봅니다. 그 백분율은 "모델이 기억을 가진 후 얼마나 정확하게 답하는가"를 측정하고, RSI-BOOT의 백분율은 "찾아야 할 그 기억을 콜드 스타트가 되찾아올 수 있는가"를 측정합니다. 두 측정 기준은 같은 열에 놓고 비교할 수 없습니다. 이것이 공신력의 바닥선이며, 23편에서 펼쳐 설명합니다.

RSI-BOOT 자신도 매우 절제되어 있습니다. 공개 결과는 지금까지 다른 사람의 "답안 점수"와 같은 열에 놓인 적이 없습니다. 그것은 자신이 규칙을 얼마나 정확하게 소환해 주는지만 말하고, "모델이 이로 인해 더 똑똑해졌다"고 대신 주장하지 않습니다. 이런 절제야말로 그것이 신뢰받을 만한 이유입니다.

五、이 시리즈를 읽는 법: 통점에서 행동으로

이 편은 시작이며, 뒤의 29편은 대략 이 호를 따라갑니다. 먼저 개념을 명확히 하고(본편 + 2편), 이어서 설치하고 호스트에 연결하고(3, 4편), 그다음 원리를 층층이 뜯어봅니다 — 소환 링크, 충돌, 메인 루프, 지식 검색, 의도와 소환 팔, 고정 건강(5–12편), 이어서 소프트웨어에 적힌 자기 개선 폐루프(13–16편), 쓰기와 주입 경계(17편), 아키텍처 전경(18–22편, 그중 22편은 DAG 관계도와 함수 파이프라인), 다시 기준 공신력(23–25편), 선형 비교(26편), 팀과 마이그레이션(27, 28편), 보안 프라이버시(29편), 마지막으로 기여와 로드맵으로 마무리합니다(30편).

처음부터 끝까지 읽을 필요는 없습니다. 그저 "빨리 써보고 싶다"면 3, 4편이면 충분하고, "AI 기억이 대체로 믿을 수 있는가"에 끌려온 사람이라면 곧바로 23–25편으로 뛰어 기준을 보면 됩니다. 기술 리드로서 선형을 고민 중이라면 26편의 비교표가 결정을 내리는 데 도움이 됩니다. 그러나 어떤 경로든 "고리"라는 개념은 반복해서 나타납니다 — 그것은 RSI-BOOT의 모든 설계를 이해하는 열쇠입니다.

六、흔한 반론과 나의 선택

여기까지 왔으니 세 가지 반론이 예상됩니다. 그것들을 먼저 꺼내 놓고, 나의 판단도 말하겠습니다. 당신이 속으로 의아해하지 않도록.

첫 번째 유형: "Claude Code는 스스로 기억할 수 있고, Cursor의 Rules도 작성할 수 있는데, 왜 RSI-BOOT이 필요한가?" 기억할 수 있다는 것과 도구를 넘나들 수 있고, 감사할 수 있고, 스스로 개선할 수 있다는 것은 다르다. Claude Code의 자동 기억은 로컬 기기에 갇혀 있고 git에 들어가지 않아서, 동료로 바뀌면 맞지 않는다. Cursor Rules는 사람이 직접 유지하는 정적 파일이라 "지난번 그 널 포인터는 어떻게 고쳤는지" 같은 경험을 담아내지 못하고, 부정적 피드백으로부터 더 나은 행동 제약을 길러내지도 못한다. RSI-BOOT의 가치는 "한 줄 기록"이라는 점에 있지 않고, "같은 기억을 다섯 개 호스트가 공유할 수 있고,每条(항목)마다 당신이 승인해야만 남으며, 채택률에 따라 스스로 수정된다"는 데 있다. 기억을 "특정 도구의 편의 기능"에서 "저장소의 자산"으로 승격시키는 것, 이것이 바로 그것의 주장이다.

두 번째 유형: "그냥 벡터 DB에 임베딩을 얹는 게 더 정확하지 않나? 시맨틱 검색이 더 고급스럽게 들리는데." 나의 판단은, 프로젝트 규칙의 대다수는 문자 그대로의 약속—"함수명은 snake_case를 쓴다""결제 로그에 카드번호를 찍지 않는다"—이고, 이런 것들은 표면의 단어만 맞으면 걸리기 때문에 BM25로 충분하며, 게다가 Key가 필요 없고 오프라인이며 비용이 들지 않는다. RSI-BOOT의 설계 제1원리는 "메인 경로는 API Key 제로, 네트워크 연결 없음, 저장소 자신의 .rsi/에만 기록"이므로, 리콜과 지식베이스 혼합 검색을 두 개의 독립 서브시스템으로 나눈다(제5편, 제10편에서 상세히 다룬다). 시맨틱 리콜이라는 10%만 플러그형 벡터 채널에 맡겨 보완하고, Key를 설정하지 않으면 순수 BM25로 퇴화한다. 먼저 90%의 제로 코스트 시나리오를 해결하고 나서 증강을 논하는 이 타협점은 나도 동의하며, 당신도 처음부터 벡터화를 쫓지 말 것을 권한다.

세 번째 유형: "기억 시스템이 한 겹 더 얹히면 Agent 컨텍스트가 터져버리지 않나?" 정반대다. 이 글에서 인용한 74.1%의 token 실험은 반직관적으로, 기억을 켜면 오히려 token이 더 절약된다는 것을 보여준다. 이유는 기억이 "프로젝트 규칙"을 매번 파일이나 대화에서 다시 끌어와야 하는 것에서, 한 번의 정확한 리콜로 얻는 몇 줄의 제약으로 바꿔주기 때문이다. 주입에는 또한 단일 파일 4000자, 프로젝트 총량 32KB라는 하드 상한이 있다(src/rsi_boot/injector/targets.py의 MAX_FILE_CHARS / MAX_TOTAL_CHARS). 기억은 컨텍스트에 물을 붓는 것이 아니라, 올바른 제약을 마땅히 있어야 할 자리에 정확히 넣는 것이다. 컨텍스트를 터뜨리는 것은 결코 "기억이 있어서"가 아니라 "코드 전체나 대화 전체를 밀어 넣어서"다—RSI-BOOT의 증류 규율은 바로 이런 일을 금지한다.

반박을 마쳤으니 솔직히 털어놓자면: RSI-BOOT은 만병통치약이 아니다. 당신의 프로젝트가 1인, 단일 도구이고, 약속이 README에 명확히 적혀 있다면, 손으로 쓴 AGENTS.md로 충분하며 굳이 이것을 도입할 필요가 없다. 정말로 이득이 되는 변곡점은 "도구를 넘나듦 / 다인 협업 / 장기 유지보수 / 실패로부터 스스로 개선하고 싶음" 이 몇 가지 중 최소 두 가지에 해당할 때 나타난다. 이 글에서는 먼저 포지셔닝을 속 시원히 설명하니, 도입할 가치가 있는지는 제3편, 제4편을 읽으면 당신 스스로 답을 얻게 될 것이다.

七、기억을 도구 기능이 아닌 저장소 자산으로 대하기

내가 "저장소를 따라간다"를 거듭 강조하는 것은 수사가 아니라 구체적인 공학적 판단이다. 기억의 귀속권은 어떤 도구의 클라우드 계정이 아니라 저장소와 팀으로 돌아가야 한다.

실제로 일어날 수 있는 장면을 들어보자. 당신이 결제 저장소에서 Agent에게 "로그에 평문 카드번호를 찍으면 안 된다"를 가르쳤다. 이 항목이 Claude Code의 로컬 기억에 기록되어 있다면, 다른 기기로 바꾸거나 동료가 이어받는 순간 이 항목은 사라지고, 다음 Agent가 또 카드번호를 로그에 찍을 수 있다. 어떤 클라우드 기억 서비스에 기록하면 그것은 당신의 계정을 따라가고, 저장소를 고객에게 복사하거나 오픈소스로 공개해도 기억은 남의 서비스에 남아 귀속이 불분명해진다. .rsi/에 기록하면 그것은 저장소를 따라 git에 들어가고(승인된 부분), fork를 따라, 인수인계를 따라 함께 간다—이 규칙의 수명은 저장소와 같으며, 누구든 이 저장소를 열면 누구나 읽는다.

이것이 바로 두 번째 절의 그 요약표에서 "저장소를 따라가고 git을 따라 흐르는 기억"과 "클라우드 계정을 따라가는 클라우드 기억"이 나란히 두 칸으로 놓인 이유이기도 하다. 기억을 계정에 묶는 것은 본질적으로 프로젝트의 자산을 도구 업체에 아웃소싱하는 것이다. 기억을 저장소에 묶어야 프로젝트가 비로소 자기만의 "사내 규칙"을 진정으로 소유하게 된다. RSI-BOOT의 .rsi/identity.json에서 project_id가 항상 local인 것은 바로 이 판단을 코드에 못박아 둔 것이다. 격리는 디렉터리로 하고, 계정이나 네임스페이스로 하지 않는다. 이 판단에서 한 걸음 더 나아가면—기억이 git을 따라 흐를 때 그것은 code review도 될 수 있다. 한 번의 기억 변경은 한 번의 git diff이며, 당신은 "이 금지 항목을 누가, 언제 승인해서 추가했는지"를 볼 수 있다. 이것은 클라우드 기억 방안의 블랙박스 계정이 결코 줄 수 없는 투명성이다.

八、내가 실제로 측정한 그 74.1%의 방법, 그리고 정직한 편향

이 글에서 인용한 token 숫자는 즉흥적인 것이 아니다. 방법은 이렇다. rsi-boot 이 저장소 자체의 문제를 가지고, 기억을 끄고 한 번 답하고, 기억을 켜고 다시 한 번 답하며, Cursor CLI가 보고하는 token을 본다. 관건은 "기억 끄기"를 어떻게 정의하느냐인데—그것이 제거하는 것은 저장소 루트의 AGENTS.md托管블록과 .rsi/ 체크아웃으로, Agent가 어떤 프로젝트 규칙도 볼 수 없게 만든다. "기억 켜기"는 바로 이 저장소이며, 리콜과 주입이 모두 존재한다. 환경은 2026-10-29, Cursor CLI 2026.10.22, ask 모드, 모델 Auto이고, token은 입력, 출력, 캐시 읽기, 캐시 쓰기 네 항목을 모두 더한 것이다.

여섯 그룹 합산: 기억 끔 1637977, 기억 켬 423973, 절약 1214004, 비율 74.1%. 하지만 나는 정직한 편향 하나를 강조하고 싶다. 같은 문제 세트를 나는 네 번 돌렸다(첫 그룹을 세 라운드 더 돌렸다). 각각 89.7%, 76.0%, 74.7%, 79.5%였다. 단일 그룹은 10.5%에서 89.7%까지 변동이 매우 컸다—어떤 그룹(프로젝트 루트, basetemp, 작업 공간 경계)은 기억을 끄면 파일을 거듭 끌어와야 해서 token이 폭증했고, 기억을 켜면 몇 줄의 제약으로 눌러졌다. 어떤 그룹(의존성, 키, 헬스 스캔)은 기억을 꺼도 token을 그다지 많이 먹지 않아, 기억을 켜는 이득이 작았다. 그래서 이 글은 오직 합계 74.1%만 인용하며, 결코 어느 한 번을 총성적으로 삼지 않는다. 이렇게 "변동을 드러내고 평균만 보고하지 않는" 방식이 rsi-boot 벤치마크의 공신력의 바탕색이다.

한 가지 더 눈에 거슬리는 정직한 지점이 있다. LoCoMo의 그 450문제 중 "답이 애초에 대화에 없는" 문제에서, rsi-boot은 콜드 스타트 전 5개를 한 번도 비워서 내놓지 않았다—대화에 답이 전혀 없을 때조차 그것은 여전히 관련 있어 보이는 몇 줄을 반환했다. 이것은 버그가 아니라 BM25 리콜의 고유한 행동이다. 그것은 "단어 표면이 비슷한지"만 판단하고 "답이 있어야 하는지"는 판단하지 않는다. rsi-boot은 "비워야 할 때 비웠다"는 이 열(0/450)을 감추지 않고 드러내기로 선택했다. 일단 리콜의 실패 모드를 미화하기 시작하면, 이후의 모든 숫자는 신뢰할 수 없게 되기 때문이다.

왜 내가 기준을 굳이 "찾아낼 수 있느냐 없느냐"만 보고하고 "맞게 답했느냐 못 했느냐"는 보고하지 않는지. rsi-boot의 주 경로는 모델을 전혀 호출하지 않기 때문에 "답하기"라는 단계 자체가 없기 때문이다. 이것을 Mem0처럼 "먼저 답하고 나서 점수를 매기는" 방식과 백분율로 비교하는 것은 사과와 오렌지를 비교하는 격이다. 이것은 "찾아야 할 그 규칙을 콜드 스타트에서 되찾아올 수 있는가"를 정직하게 알려줄 수 있다——Hit@5 56.5%(LoCoMo)/ 96.6%(LongMemEval-S), MRR 0.427 / 0.907——이것으로 충분하다. 모델이 이런 규칙을 가지고 최종적으로 얼마나 잘 답하는지는 호스트 모델의 능력이지 rsi-boot의 공로가 아니며, 그 공적으로 계산되어서도 안 된다. 제23–25편에서는 세부 항목과 방법론 프로토콜, 그리고 "비어 있어야 할 때 비어 있다" 같은 실패 모드에 대한 완전한 분석을 다룰 것이지만, 이번 편에서는 한 문장만 확실히 세우겠다. 우리는 "기억을 되찾는 것"에만 책임이 있고, "모델이 얼마나 똑똑한가"에는 책임이 없다.

이런 절제는 마케팅 화법이 아니라, 내가 rsi-boot를 프로덕션에 추천하고자 하는 근본 이유다. 어떤 도구가 한편으로는 "내 기억이 얼마나 정확한지"라고 말하면서, 다른 한편으로는 "모델의 답안 점수"와 "검색 적중률"을 한 표에 뒤섞어 놓는다면, 내 첫 반응은 그것이 자기 검색조차 믿지 못한다는 것이다. rsi-boot는 반대다. 변동성, "비어 있어야 할 때 비어 있다"는 것, "답안의 정답 여부는 측정하지 않고 되찾기만 측정한다"는 것까지 전부 다 펼쳐 놓기에, 오히려 "이 물건은 자기 경계가 어디인지 안다"는 느낌이 든다. 엔지니어링 도구를 신뢰할 때는, 좋은 소식을 어떻게 보고하는지가 아니라 나쁜 소식을 어떻게 보고하는지를 먼저 본다.

소결

- 프로젝트 규칙은 저장소에 속하는 것이지, 어떤 한 번의 채팅이나 어떤 한 대의 기계, 또는 어떤 클라우드 계정에 속해서는 안 된다——이것이 RSI-BOOT의 전체 출발점이다.

- 그것의 정체성은 호스트 모델의 절차적 기억 계층이다. "어떻게 하는가"만 축적할 뿐, 저장소의 의미를 해석하지 않고 모델을 대신해 답하지 않는다.

- 사용은 하나의 고리다. 회수 → 작업 → 증류하여 검토 대기 → 당신의 승인 → 다음 라운드 회수. 부정적 피드백은 실패 버킷 우회 경로로 흐르며, 쓰기 가능한 슬롯만 바꾼다.

- 기준은 "콜드 스타트 검색 적중"만 보고하며, Mem0의 "모델 답안 점수"와 같은 자리에 놓을 수 없다——이것이 그것의 정직한 기준이며, 이후 공신력의 토대이기도 하다.

- 시리즈는 "페인 포인트 → 개념 → 시작하기 → 원리 → 자기 개선 → 아키텍처 → 기준 → 선정 → 팀 → 보안 → 마무리"로 전개되며, 필요에 따라 건너뛰어 읽어도 되지만 "고리"는 전편을 관통하는 열쇠다.

다음 편 예고

이번 편에서 "고리"를 다 설명했지만, RSI가 도대체 왜 "지식 베이스"가 아니라 "절차적 기억 계층"인지는 아직 명확히 말하지 못했다. 다음 편(제2편)에서는 이 개념을 집중적으로 풀어낸다. 절차적 기억과 사실적 기억은 어디서 다른지, RSI가 왜 저장소 이해기가 아니고, 대화 기억도 아니며, 더욱이 클라우드 계정 기억도 아닌지, 그리고——"절차적"이라는 세 글자가 대체 에이전트의 무엇을 바꾸는지. 그것은 이후의 모든 메커니즘을 이해하는 토대다.

출처 원문