프로젝트가 늘어날수록 기억을 섞지 않는 법 — 지식존과 정본의 경계

프로젝트가 하나일 때는 기억이 조금 섞여도 문제가 잘 드러나지 않아요. 지난 대화와 작업 문서, 저장소를 두루 찾으면 대개 답에 도착해요. 그런데 제품이 늘어나자 검색 결과의 문장은 맞지만, 지금 묻는 제품의 답은 아닌 경우가 생겼어요.

KoalStudio가 다루는 지식의 경계는 꽤 멀리 떨어져 있어요. 감각 경험과 와인 데이터를 잇는 도메인, 같은 선택을 재현해야 하는 야구 커리어, 공간과 조합 결과가 저장되는 게임 세계는 모두 기록과 상태를 다루지만 정본은 서로 달라요. 와인 산지 매핑 규칙으로 야구 시뮬레이션을 설명할 수 없고, 커리어 재현 규칙으로 게임의 공간 진행을 검증할 수도 없어요.

여기서 제품 이름의 시간축도 분리해야 했어요. AsterDuck은 CoffeeDuck과 WineDuck을 포괄해 온 역사적·도메인 우산이에요. 현재 네이티브에서 사용자가 만나는 제품 정체성과 로그인 흐름은 WineDuck 중심이고요. 예전의 통합 셸이 지금도 제품 전면에 남아 있다는 뜻으로 AsterDuck을 쓰면, 이름 하나만으로 과거 구조를 현재 사실처럼 불러오게 돼요.

검색 범위를 넓혔더니 답이 더 흐려졌어요

처음에는 문서를 더 모으고 검색 결과를 많이 가져오면 놓치는 것이 줄어들 거라고 생각했어요. 실제로는 이름이 비슷한 개념과 오래된 결정이 함께 딸려왔어요. 에이전트는 그중 문장력이 좋은 자료를 골라 자연스럽게 답했지만, 자연스러움은 출처가 맞다는 보증이 아니었어요.

그래서 문서를 넣기 전에 **지식존(knowledge zone)**부터 나눴어요. 지식존은 폴더명이 아니라 “이 질문에 어느 프로젝트의 지식을 읽어도 되는가”를 정하는 접근 경계예요.

“콜업 조건을 바꾸면 저장 검증도 달라지나?”라는 질문은 Called Up 존에서 시작해요. Project Whisper에도 포탈 해금과 진행 조건이 있지만, 단어가 비슷하다고 함께 검색하지 않아요. 반대로 “조합 실패 때 재료를 소비하나?”는 Project Whisper의 Fusion 규칙을 먼저 봐요. WineDuck의 매핑 실패 처리나 Called Up의 선택 결과를 참고 답안처럼 붙이지 않아요.

검색창은 출발점이 아니라 세 번째쯤에 와요. 먼저 질문의 제품을 판정하고, 그 제품의 지식존을 연 뒤, 현재 기준을 찾기 위해 검색해요. 답이 모자랄 때만 이력과 원문으로 내려가요. 이 순서를 도메인 우선 검색이라고 부르고 있어요.

한 제품 안에서도 자료의 역할은 달라요

프로젝트만 분리한다고 끝나지는 않았어요. 같은 제품 안에도 현재 기준과 과거 결정, 검증할 원문, 검색을 위한 파생 데이터가 함께 있기 때문이에요. 이 자료를 네 역할로 갈랐어요.

정본: 지금 반복해서 따라야 할 기준

정본은 제품의 현재 정의와 오래 유지할 불변식을 담아요. WineDuck에서는 시음 기록이 중심 객체라는 제품 경계와 개인 셀러가 공용 와인 카탈로그와 개인 시음 이력을 잇는다는 구조가 여기에 들어가요. Called Up에서는 같은 시작값과 선택이 같은 커리어를 재현해야 한다는 규칙을, Project Whisper에서는 탐험과 조합, 세계 변화가 이어지는 코어 루프와 저장 불변식을 둬요.

정본에는 오늘의 배포 상태나 잠깐의 작업 메모를 넣지 않아요. “지금 서버가 응답해요”라는 관찰과 “같은 입력은 같은 결과를 만들어요”라는 제품 규칙은 수명이 다르기 때문이에요. 정본이 모든 사실을 품으면 오래 유지할 기준이 일시적인 상태에 묻혀요.

이력: 무엇이 왜 바뀌었는지 남기는 시간축

이력에는 날짜가 중요한 결정, 폐기된 초안, 정정 과정과 당시 검증 결과를 남겨요. Project Whisper의 초기 기획과 현재 구현 범위가 다를 때 초기안을 지워버리면 변화의 이유를 알 수 없어요. 그렇다고 초기안을 정본에 두면 현재 답이 오염돼요. 현재 기준은 정본에, 변화의 맥락은 이력에 두는 이유예요.

AsterDuck이라는 이름도 이 시간축을 빼면 틀리기 쉬워요. 역사적 도메인을 설명할 때는 유효하지만, 현재 네이티브 제품을 묻는 답에서는 WineDuck이라는 정체성을 먼저 써야 해요.

원문: 해석을 다시 확인할 근거

원문은 코드, 테스트, 승인된 기획과 운영 문서처럼 주장을 직접 확인할 수 있는 자료예요. Called Up의 현재 동작을 묻는다면 설명 문서보다 실제 구현과 테스트가 더 높은 권위를 가질 수 있어요. Project Whisper에서도 현재 코드, 승인된 설계, 초기 초안을 같은 무게로 읽지 않아요. 플레이 가능한 것과 구상 중인 것을 갈라야 해요.

그렇다고 원문을 매번 처음부터 전부 읽지는 않아요. 코드 한 줄은 정확해도 제품 맥락 없이 읽으면 의미를 과장하기 쉬워요. 먼저 정본으로 질문의 좌표를 잡고, 충돌하거나 세부 근거가 필요할 때 해당 원문만 확인해요.

검색 인덱스: 답이 아니라 길찾기

검색 인덱스는 문서를 빨리 찾기 위해 잘게 나눈 파생 데이터예요. 가장 편리하지만 정본은 아니에요. 오래된 조각이 남거나 문맥이 잘린 문장이 상위에 나올 수 있어요. 검색 점수가 높다고 현재 기준이 되는 것은 아니에요.

그래서 인덱스가 가리킨 문장을 그대로 답으로 쓰지 않아요. 원문으로 돌아가 상태와 주변 문맥을 확인해요. 원문이 바뀌면 인덱스를 다시 맞추고, 둘이 충돌하면 원문을 따라요.

경계는 비슷한 말을 구체적인 결정으로 되돌려요

세 제품의 규칙을 멀리서 보면 모두 “상태를 안전하게 다룬다”로 요약할 수 있어요. 하지만 그 문장만 남기면 실제 판단에 필요한 차이가 사라져요.

WineDuck에서 산지 자동 매핑이 확실하지 않을 때는 그럴듯한 값을 만들기보다 미매핑 상태와 수정 경로를 남겨요. 경험의 정체를 잃지 않기 위한 데이터 신뢰의 결정이에요. Called Up에서는 결과 수치보다 시작 조건과 선택 기록을 신뢰해요. 같은 입력을 다시 실행해 같은 커리어가 나오는지가 저장 검증의 경계예요. Project Whisper에서는 조합 미리보기와 실제 소비를 분리하고, 저장 뒤 정화 진행이 뒤로 돌아가지 않는지 확인해요. 공간 도달성과 상호작용 경로, 세계 상태까지 함께 봐야 해요.

셋 모두 신뢰에 관한 규칙이지만 서로 대신 쓸 수는 없어요. 정말 오래 공유되는 원칙만 공통 영역으로 승격하고, 제품을 움직이는 구체적인 결정은 각 지식존에 남겨요.

질문마다 같은 검색 사다리를 내려가요

지식이 많아진 뒤에는 몇 개를 찾았는지보다 어떤 순서로 확인했는지를 봐요.

순서	확인할 것	멈추는 조건
1. 범위	질문이 어느 제품과 공개 범위에 속하는가	도메인이 하나로 정해졌어요
2. 정본	현재 정의와 장기 규칙은 무엇인가	답과 적용 범위가 충분해요
3. 이력	언제, 왜, 무엇이 바뀌었는가	시간축의 충돌이 풀렸어요
4. 원문	코드·테스트·승인 문서가 실제로 무엇을 말하는가	필요한 주장을 확인했어요
5. 인덱스 정합	찾은 문서와 검색 데이터가 맞는가	다음 검색에도 같은 경계를 유지해요

기본은 정본부터 읽고 필요한 만큼만 확장하는 방식이에요. 일반 질문에 과거 이력을 먼저 섞지 않고, 구현 근거가 필요하지 않은데 저장소 전체를 읽지도 않아요. 반대로 현재 출시 여부나 최신 동작처럼 시점에 민감한 질문은 오래된 정본 문장만으로 단정하지 않고 실제 상태를 다시 확인해요.

이 사다리는 에이전트의 컨텍스트도 작게 만들어요. 모든 프로젝트 문서를 한꺼번에 넣지 않고 한 도메인에서 적은 수의 후보부터 읽어요. 컨텍스트가 작아서라기보다 관련 없는 확신이 들어올 자리가 줄어서 유리해요.

기억은 누적보다 승격과 가지치기에 가까워요

대화에서 한 번 나온 아이디어, 특정 시점의 배포 확인, 아직 검증하지 않은 계획을 모두 정본으로 올리면 어떤 문장도 믿기 어려워져요. 새 기록은 먼저 이력에 두고 반복해서 유효한지, 명시적으로 승인됐는지, 기존 기준과 충돌하지 않는지 확인해요. 그 조건을 통과한 정의와 불변식만 정본으로 승격해요.

검색과 중복 탐지, 오래된 기록 표시, 인덱스 갱신은 자동화할 수 있어요. 하지만 이 결정이 여러 제품의 공통 원칙인지, 계획인 문장을 현재 기준으로 올려도 되는지, 외부에 공개해도 되는지는 사람이 판단해야 해요. 정본 승격은 기억을 하나 추가하는 일이 아니라 앞으로의 판단 기준을 바꾸는 일이기 때문이에요.

프로젝트가 늘어난 뒤 필요한 것은 더 큰 하나의 기억이 아니었어요. 서로 넘어가지 않는 여러 개의 정확한 기억이었어요. 질문을 받으면 제품과 시점을 먼저 고르고, 그 지식존의 정본에서 시작해요. 과거 맥락은 이력에서, 구체 근거는 원문에서 필요한 만큼만 가져와요.

이 구조는 결과를 정본으로 남기는 협업 방식과도 이어져요. 무엇을 저장할지 못지않게 어디의 현재 기준으로 저장할지를 정해야 다음 검색도 흔들리지 않아요.

좋은 지식 시스템은 모든 것을 기억하지 않아도 돼요. 지금 묻는 제품의 답을, 그 제품의 근거와 올바른 시점에서 꺼낼 수 있으면 돼요.