컨텍스트와 기억

모델에 무엇을 올려보내고 무엇을 밖에 남길 것인가를 다루는 것들. 컨텍스트 압축, 벡터 없는 검색, 제2의 뇌, 그리고 레포를 사람과 에이전트 둘 다 읽을 수 있게 정리하는 방식.

마지막 항목이 이 분류에 들어오는 게 처음엔 이상해 보입니다. 당근 SEED는 디자인 시스템인데, 실제로 건진 건 컴포넌트가 아니라 문서를 배치한 방식이었습니다. 여기 기준은 대상이 무엇이냐가 아니라 “기계가 무엇을 읽게 할 것인가”를 다루느냐입니다.

열하나, 그리고 코드는 한 줄도 안 넘어왔다

대상	넘어온 것	형태
Headroom	못 재는 값에 신뢰구간과 라벨을 붙인다	규약 1건
당근 SEED	소스를 고치면 빌드 자동 실행 · 세션 끝 검증 리마인더	훅 2개
벡터DB 없는 RAG	규모를 축으로 잘라 경계선을 긋는 법	구조 1건
세컨드 브레인 강의	새 스킬을 만든 그 턴 안에서 채점한다	타이밍 규칙 1건
그래프 엔지니어링	적대 리뷰 3렌즈를 병렬로 — 런당 9.9분	배선 1건
옵시디언 LLM 위키	한 자료는 딱 한 자리 · AI 접근 기록	위생 규칙 2건
세컨드 브레인 인터뷰	“자동화 전에 맥락” — 도구는 여럿인데 판단 기준이 얇다	태도 1건
파일 관리 체계	분류가 안 되는 것의 임시 거처 · 인덱스에 정원	규칙 2건 + 정정 2건
세컨드 브레인 4단계	안 넘어왔다 — 대신 내 칸 하나가 비어 있는 걸 찾았다	채택 1건 + 결함 확정 1건
dsh-anchored-standard	안 넘어왔다 — 설치할 훅 자체가 없었다	기각 1건 + 미실행 24일 확정
public-apis	값싼 검사를 비싼 검사 앞에 두면 뒤가 실행된 적 없이도 돌아 보인다	함정 1건 + 결함 확정 1건

전부 규칙·훅·구조·배선입니다. 코드 이식은 0건. 컨텍스트 문제는 대개 남의 코드로 안 풀립니다 — 내 데이터가 어떻게 생겼는지에 답이 있어서, 남한테서 가져올 수 있는 건 자를 대는 방식뿐입니다.

그리고 이 분류가 제 구멍을 가장 많이 찾아냈다

일곱 편이 남의 것을 자로 삼아 제 것을 재다가 숫자를 냈습니다.

• 제 볼트 마크다운 1,021개 중 프론트매터가 있는 건 47개(4.6%) — 검색이 안 되는 원인이 도구가 아니라 비어 있는 메타데이터일 가능성
• 캐시 재사용률 92.596.3%, 미캐시 입력이 콜당 1.82.0 토큰 — 압축 도구가 줄여 줄 대상이 존재하지 않았다
• 수확이라고 적은 7종 중 5종이 제 settings.json을 열어 보니 이미 있거나 헛다리
• 스킬 99개 전수 스캔에서 설명문이 아예 없어 자동 호출이 안 되던 것 1건과 500줄 초과 16종
• 52개 런 로그에서 영상이 「핵심」이라 부른 기능의 발동 조건이 단 1회
• 자율 축적 트랙을 실제로 돌려보니 쌓인 항목 0 · 파일 0 · 관측기 훅 0 — 설치만 돼 있었다
• 한 달 전에 만든 API 카탈로그를 열어 보니 링크 생사 실측이 1,791건 중 300건(17%)에만 걸려 있었다

셋째가 제일 아팠습니다. 레포를 아무리 정독해도 안 잡히는 종류의 오류였습니다.

두 번째 축 — 넘어온 건 「언제」와 「어디에」였다

셋일 때는 “코드가 안 넘어온다”만 보였습니다. 다섯이 늘고 나니 더 정확한 문장이 따로 있었습니다 — 넘어온 것 대부분이 「무엇을」이 아니라 「언제」와 「어디에」였습니다.

세컨드 브레인 강의에서 건진 건 새 점검 도구가 아니라 점검을 언제 돌리느냐였고, 그래프 편에서 건진 것도 새 단계가 아니라 있던 단계를 언제 동시에 돌리느냐였습니다. 파일 관리 편에서 건진 것도 새 폴더 구조가 아니라 분류가 안 되는 것을 어디에 두느냐였습니다. 전부 이미 있는 것의 시점과 자리를 옮긴 것입니다.

이 분류에서 남의 것으로부터 새 부품을 얻은 적은 거의 없습니다. 얻은 건 제 부품을 언제 어디에 쓸지에 대한 판단이었습니다.

세 번째 축 — 제일 값어치 있었던 건 「근거가 다른 일치」였다

파일 관리 편이 그 극단입니다. 그 영상은 제가 따로 만든 설계와 결론 다섯 개가 일치했는데 근거가 하나도 안 겹칩니다 — 그쪽은 “복잡하면 사람이 도망간다”, 저는 “경로가 분류에 종속되면 깨진다”. 서로 다른 길로 같은 지점에 도달하면 그 지점이 맞을 확률이 올라갑니다.

반대 방향도 있었습니다. 같은 기법인데 한쪽에선 무해하고 한쪽에선 치명적인 경우 — 폴더 이름에 번호를 붙이는 것은 ID 기반 저장소면 괜찮고 경로 기반이면 안 됩니다. “저 사람은 되는데 나는 안 된다” 로 끝냈으면 취향으로 남았을 것을, 왜 갈리는지를 찾으니 규칙이 됐습니다.

네 번째 축 — 「이미 갖고 있다」는 판정이 제일 위험하다

아홉 번째 편이 앞의 세 축을 전부 흔들었습니다. 이 분류에서 가장 자주 내리는 판정이 “그건 이미 하고 있다” 인데, 그 판정을 무엇으로 내렸는지를 한 번도 안 물었습니다.

자율 축적 단계를 대조할 때 저는 “설치돼 있다”를 근거로 동등이라고 적었습니다. 실제로 눌러보니 쌓인 항목도, 파일도, 관측기 훅도 전부 0이었습니다. 승격이 0건인 게 아니라 관측이 없어 만들 재료가 애초에 없었습니다.

보유 ≠ 작동. 그리고 이건 그 칸 하나로 끝나지 않습니다 — 같은 표의 「동등」 판정 넷이 전부 설치 여부 기준이었습니다. 나머지 셋은 아직 안 눌러봤고, 그때까지는 장부상 숫자입니다.

이 축이 에이전트 하네스의 결론과 정면으로 맞물립니다. 그쪽에서 가장 자주 나온 문장이 “내가 이미 갖고 있었다” 인데, 그 문장이 맞는지를 재는 방법이 여기서 나왔습니다.

열 번째가 네 번째 축을 한 겹 더 팠다 — 「안 켰다」

아홉 번째 편은 배울 게 거의 없는 자료였는데, 그래서 오히려 대조표를 끝까지 채우게 됐고 거기서 빈칸이 나왔습니다. 가져올 게 없는 자료도 값을 합니다 — 남의 것을 자로 쓸 때는 그 자가 훌륭할 필요가 없습니다. 열 번째가 그걸 한 번 더 증명했습니다.

아홉 번째가 보유 ≠ 작동을 찾았다면, 열 번째는 그 아래 칸을 열었습니다. 보유 ≠ 실행 이력.

이 편은 컨텍스트 예산을 줄이는 남의 프리셋을 뜯으러 갔습니다. 그런데 도입 판정이 나기 전에 조사가 멈췄습니다 — 제 하네스에는 세션 첫 요청에서 주입을 빼는 훅이 없습니다. 설치할 자리가 없으니 채택도 기각도 아니라 적용 불가입니다.

그 자리에서 더 아픈 게 나왔습니다. 그걸 재려고 반년 전에 들여놓은 측정 스킬이 있는데, 설치 후 24일 동안 한 번도 실행되지 않았습니다. 산출물 0건, 받쳐 줄 명령은 만들어지지도 않았습니다. 그리고 같은 날 하네스 쪽 조사가 서로 모르는 채로 같은 스킬을 가리켰습니다.

그래서 네 번째 축이 이렇게 늘어납니다:

층	물어야 하는 것
1	갖고 있나 — 설치 여부
2	도나 — 눌러 보면 산출이 나오나 (아홉 번째 편)
3	켠 적 있나 — 마지막 실행 날짜가 있나 (열 번째 편)

1층만 보고 「이미 갖고 있다」를 적으면 창고에 있는 물건을 밖에서 사 오자는 결론이 나옵니다. 그리고 이 분류에서 가장 자주 내리는 판정이 바로 그것입니다.

한 줄 더. 이 편은 제 설정 자체가 남의 프리셋 묶음을 통째로 복사한 결과라는 것도 확정했습니다 — 스킬 절반 이상, 룰 대부분, 훅 열 개가 거기서 왔고 자작 훅은 둘입니다. 남의 프리셋을 심사하러 갔다가, 제가 이미 남의 프리셋 위에 앉아 있다는 걸 확인한 셈입니다. 그걸 재려고 같이 집어온 자가 24일째 포장도 안 뜯긴 채였습니다.