2026년 1월에 TOKIUM에 입사하여, QA 팀에서 테스트 설계 자동화에 힘쓰고 있는 ikedan입니다.

지난 기사에서 저는 Claude에게 '회고'와 '시운전'이라는 인간의 습관을 도입한 이야기를 썼습니다.

그 결론 부분에서 "다음에는 Claude에게 무엇을 기억시킬지를 쓰겠습니다"라고 예고했기에, 본 기사는 그 후속편입니다.

당시 납득이 가지 않는 점이 있었습니다.

같은 팀의 동료는 제가 만든 회고나 시운전 메커니즘을 하나도 넣지 않았음에도 불구하고, Claude의 빗나간 답변(Hallucination, 할루시네이션)이 저보다 명백히 적었습니다.

동료의 Claude가 제 Claude보다 더 똑똑해 보였습니다.

차이는 하나였습니다.

동료는 지식을 Obsidian의 지식 베이스(Knowledge Base)에 정리하고, Claude가 그곳을 참조하게 하고 있었습니다.

저는 메커니즘을 추가하는 데만 몰두하느라, 지식을 둘 장소를 방치하고 있었습니다.

이 설계의 모티브는 전 Tesla의 AI 책임자이자 OpenAI의 공동 창업자인 Andrej Karpathy가 제시한 "LLM Knowledge Bases"라는 개념입니다.

생데이터(Raw data)와 LLM이 읽는 정리된 지식을 분리하여, 필요할 때 참조한다. 저에게 부족했던 것은 바로 이 정리였습니다.

이 "기억을 어떻게 다룰 것인가"라는 질문에는 사내에서도 이전부터 여러 발신이 쌓여왔습니다.

계기 중 하나는 저희 회사의 Matsubara가 X에서 제시한 "인간의 기억 구조를 Claude Code에 겹쳐보기"라는 견해(해당 포스트)로, 여러 멤버가 각자의 운용 방식에 도입해 나갔습니다.

그 후, 저희 회사의 Massan이 "Claude Code에 「의식하지 않아도 할 수 있는 것」을 구현한 이야기 ── 학습하는 기억의 3층 구조"에서 관찰 → 기억 → 진화라는 기억의 "움직이는 방식"을 기술했습니다.

본 기사는 그 계보의 세 번째로서, 동일한 주제를 "어디에 둘 것인가"라는 정리의 관점에서 다룹니다.

「기억하고 있다」와 「사용할 수 있다」는 별개

Claude에는 매 턴마다 읽히는 메모(MEMORY.md

. 대화할 때마다 자동으로 문맥에 포함되는 상주 메모)가 있습니다. 편리한 반면, 세 가지 함정이 있었습니다.

첫 번째는 메모가 길어지면 중간까지만 읽히게 된다는 점입니다. 제 메모는 255행까지 늘어나서, 잘림 경고가 나오고 있었습니다. Claude는 "중간까지 읽은 기억"을 전부라고 믿어버려, 후반에 작성한 최신 수정 사항이 누락됩니다.

두 번째는 일시적인 수치가 사실로서 고정된다는 점입니다. 예를 들어, 어느 시점에 "테스트 케이스 49건 · 스코어 90점"이라고 적었다고 가정해 봅시다. 한 달 후에는 건수도 스코어도 바뀌어 있는데, "메모에 있으니까 사실"이라며 오래된 값을 인용해 버립니다.

세 번째는 사양을 규칙 문장으로 적으면 유추를 통해 잘못 적용된다는 점입니다. "이 판정은 D열(테스트 케이스 Excel이 있는 열)을 본다"와 같은 지식을 자연어로 적으면, 비슷하지만 다른 케이스에 적용하여 틀리게 됩니다.

그리고 가장 뼈아팠던 것은, 이것이 AI만의 병이 아니라는 사실을 깨달은 것이었습니다.

폴더 정리 과정에서 "이것은 사용 중 / 사용하지 않음"이라고 저 스스로 판단한 7건을 실제로 grep(파일을 가로질러 문자열을 검색하는 명령어)으로 참조원을 확인해 본 결과, 7건 모두가 제 짐작과 반대였습니다(사용 중이라고 생각한 것이 미사용, 그 반대도 마찬가지).

AI의 Hallucination(할루시네이션)과 저의 "어렴풋이 기억하는 것"은 완전히 같은 구조였습니다.

문제는 "무엇을 기억할 것인가"가 아니라, "어디에 두고 어떻게 꺼낼 것인가"였습니다.

그리고 이 세 가지 함정은, 이후에 설명할 "4가지 장소"와 두 가지 규율(그때그때 참조할 것 / 실증 없는 것을 정본으로 삼지 않을 것)을 통해 완화해 나갈 것입니다.

지식을 4곳으로 분류하기

그래서 지식을 항상 곁에 둘 것인지, 필요할 때만 참조할 것인지라는 축으로 4곳으로 나누었습니다.

왼쪽으로 갈수록 항상 읽히기 때문에 얇게 유지하고, 오른쪽으로 갈수록 읽히지 않기 때문에 양을 두려워하지 않고 쌓을 수 있다는 배열입니다.

의도적으로 4개로 나눈 것이라기보다, 각각이 해결하는 문제가 달랐기에 자연스럽게 이 형태가 되었습니다. 나중에 되돌아보니 각 계층은 기존의 지식 관리 기법과 맞닿아 있었습니다.

이것들은 서로 다른 문맥에서 태어난 기법들이지만, 공통적으로 "항상 읽는 양을 줄인다 / 필요한 것만 참조한다"라는 동일한 문제를 해결하고 있습니다.

고유명사를 모르더라도 각 계층이 무엇을 방지하는지는 오른쪽 열만으로 파악할 수 있습니다.

색인은 얇게 유지하기

첫 번째는 항상 곁에 두는 색인입니다. 상시 메모는 색인으로만 구성했습니다. 내용은 담지 않습니다.

255줄에 달하던 메모를 십수 줄까지 줄였고, 본문은 모두 다른 곳을 가리키는 포인터(Pointer)로 대체했습니다. 이것이 내용이 길어지면 뒷부분이 잘려 나가는 함정 ①에 대한 대책입니다.

구체적으로는 다음과 같은 교체 방식입니다.

Before (내용을 직접 작성했을 때):

- 이 프로젝트의 판정은 D열을 참조한다. E열은 대상 외.
- 병렬 생성된 테스트 관점의 표기 불일치는 나중에 정규화한다.

After (색인 = 포인터만 존재):

- [판정열의 사양](./memory/judgment-column.md)
- [테스트 관점의 표기 불일치](./memory/viewpoint-wording.md)

매번 읽어들이는 설정 파일(Claude에게 상시 적용되는 지시서 = CLAUDE.md)에서도 사양 기술 부분을 추출하여, 계층에 따라서는 절반 가까이(실측 결과 최대 약 48%)까지 슬림하게 만들 수 있었습니다.

다만 한 가지 예외를 두었습니다. "사후에 떠올렸을 때는 이미 늦은 규율"만은 색인에 상주 시킵니다. 예를 들어 "도구 호출 (Tool Call, AI가 외부 도구를 호출하는 조작)이 실패하면, 동일한 형태로 다시 보내지 않는다"라는 규칙은, 필요해진 뒤에 검색해서는 늦습니다. 깨달았을 때는 이미 사고가 발생한 뒤입니다. 이러한 선제적인 규율만은 양을 늘리지 않는 범위 내에서 상시 메모에 남겨둡니다.

필요시 메모 ── 필요할 때만 읽기

두 번째는 필요할 때만 불러오는 메모입니다. 현재 약 65개가 있습니다.

각각에 짧은 설명문 (description)을 달아두면, Claude가 그 설명문을 보고 "지금 작업과 관련이 있을 것 같다"라고 판단할 때만 자동으로 읽어옵니다.

---
name: 테스트 관점의 표기 불일치
description: 병렬 생성된 테스트 관점은 용어 표기를 나중에 정규화함
...

메모 하나당 하나의 개념으로 작게 나누기 때문에, "D열을 참조한다"와 같은 사양도 건별로 독립시킬 수 있습니다.

유사하지만 다른 케이스에 적용해 버리는 유추 오류 적용 (함정 ③)이 일어나기 어려워지며, 오래된 일시적인 수치 (함정 ②)도 쌓아두지 않고 필요할 때만 찾아봄으로써 혼입되는 것을 방지할 수 있습니다.

상시에는 읽히지 않으므로, 개수가 늘어나도 색인이 비대해지지 않습니다. "읽히지 않을 수도 있다"는 점을 받아들이는 대신, 양에 대해 두려워하지 않아도 되는 설계입니다.

구조화 메모는 Cline Memory Bank를 빌려왔다

세 번째는 체계적인 배경지식입니다. 여기서는 Cline (VSCode용 AI 에이전트)이 사용하는 Memory Bank라는 설계를 빌려왔습니다.

프로젝트의 목적 · 도메인 지식 · 설계 패턴 · 기술 구성 · 진행 중인 상황 · 진척도, 이렇게 6개의 파일을 "코어 (Core)"로 둡니다.

Cline 자체는 이 6개를 필수 코어로 두면서 필요하다면 추가 파일도 허용합니다. 저는 거기서 "코어를 고정한다"라는 발상만 빌려와, 새로운 지견이 나와도 파일을 늘리지 않고 기존의 6개 파일을 다시 써서 흡수한다──늘리지 않는다──라는 제약을 스스로에게 부여했습니다. 코어가 물리적으로 늘어나지 않으므로, 기동 시 읽어야 할 양이 늘어나지 않습니다. "늘리지 않는다"라는 제약 그 자체가 비대화를 구조적으로 막아줍니다.

창고 ── 거의 사용하지 않는 것은 격리한다

네 번째는 창고입니다. 특정 티켓에서만 사용하는 조사 로그나 구버전의 결과물처럼, 거의 참조하지는 않지만 버리고 싶지는 않은 지식을 이곳으로 격리합니다.

PARA의 Archives와 같은 발상으로, 색인에서는 보이지 않게 해둡니다. 상시 메모나 필요시 메모를 얇게 유지하기 위해, "사용하지 않는 것을 대피시킬 곳"을 하나 마련해 두는 역할입니다.

"두기만 하면 안심"은 아니었다

여기까지는 "정리해서 두면 된다"라는 이야기였습니다. 실제로 해보면서 가장 크게 빠졌던 함정은 그다음입니다.

당초 저는 "지식은 모두 지식 베이스 (Knowledge Base)에 두면 된다"라고 생각했습니다. 이것은 틀렸습니다.

업무의 1차 정보는 소스 코드나 Excel 등 다른 곳에 있습니다. 지식 베이스에는 그것을 사람이나 AI가 읽기 쉬운 형태로 옮겨 적은 페이지들이 혼재합니다. 그래서 페이지에는 두 가지 얼굴이 생겨납니다.

하나는 그곳이 정본 (Single Source of Truth, 유일하고 올바른 출처)인 페이지.

다른 하나는 다른 곳에 있는 정본을 복사한, 말하자면 사본 페이지입니다. 후자는 정본을 업데이트하고도 반영하는 것을 잊으면 오래된 값 그대로 남게 됩니다.

그리고 Claude는 그 오래된 사본을 "지식 베이스에 적혀 있으니 옳다"라고 인용해 버립니다. 정리한 것이 오히려 새로운 할루시네이션 (Hallucination)의 씨앗이 되는 것입니다.

대책은 두 가지였습니다.

하나는 어떤 페이지가 정본(正本)이고 어떤 것이 사본(写し)인지를 인덱스(Index)를 통해 기계적으로 판별할 수 있도록 하는 것.

또 하나는 지식을 통째로(베타가키, ベタ書き) 안고 가는 것이 아니라, 필요할 때 찾아보는(引く) 형태로 만들어 항상 새로운 정보만을 컨텍스트(Context)에 넣는 것입니다 (함정 ②와 동일한 "그때그때 찾아보기"입니다).

"쌓아두고 읽기"에서 "그때그때 찾아보기"로 바꾸자, 오래된 파편이 섞여 들어오지 않게 되었습니다.

어디에 둘 것인가는 이 질문으로 결정한다

최종적으로 지식의 위치는 다음 질문으로 결정하고 있습니다.

• 항상 필요하며, 사후에는 되돌릴 수 없는가 → 인덱스 (상시 메모)
• 가끔 필요한가 → 필요 시 메모
• 체계적인 배경인가 → 구조화 메모
• 특정 작업에서만 사용하는가 → 창고

그리고 위치 선정만큼이나 효과적이었던 것은 "실증 없는 주장을 정본으로 삼지 않는다"라는 규칙이었습니다.

"본 것 같다", "사용하고 있을 것이다"를 출처로 삼지 않습니다. grep을 하거나 파일을 열어 확인한 것만을 정본으로 취급합니다.

이는 Claude에게 부여한 규칙인 동시에, 서두에서 7건을 잘못 파악했던 저 자신에 대한 경계이기도 했습니다.

마치며

지난번에는 회고와 시운전이라는 메커니즘을 추가했습니다. 이번에 배운 것은, 무언가를 더하는 것보다 정리하는 것이 더 효과적인 상황이 있다는 점입니다.

지식 정리의 답은 암기시키는 양을 늘리는 것이 아니었습니다. 내용에 따라 위치를 선택하고, 검색을 통해 신선도를 유지하며, 실증으로 지켜내는 것.

실제로 상시 읽어들이는 인덱스는 십수 줄까지, 매 턴 적용되는 지시 파일(Instruction file)도 계층에 따라서는 절반 가까이 가벼워져서 고정 비용을 작게 유지할 수 있게 되었습니다.

그리고 정리 후에 맞닥뜨렸던 "오래된 사본을 정본으로 착각하는" 문제도, 사본을 기계적으로 구별하는 메커니즘을 통해 억제되고 있습니다.

쌓아두는 것은 누구나 할 수 있습니다. 활용하는 것은 정리와 사실 확인(裏取り)이었습니다.

인간과 AI가 함께 품질을 지키는 시대에, AI에게 무엇을 전달할 것인가만큼이나 그것을 어디에 둘 것인가가 중요해집니다.

다음에는 이 정리를 뒷받침하는 "미리 차단하는 메커니즘"에 대해 글을 써보려고 합니다.