컨텍스트와 기억

AI에게 「무엇을 보여 주고 무엇을 안 보여 줄 것인가」를 다루는 글 열한 편입니다. 그리고 열한 편 전부 코드는 한 줄도 안 가져왔습니다.

먼저 — 왜 「안 보여 줄 것」을 정해야 하나요

AI에게 일을 시킬 때, 아는 걸 전부 알려 주면 잘할 것 같지만 반대입니다.

AI가 한 번에 읽을 수 있는 양에는 한계가 있습니다. 그 한계를 「책상 넓이」라고 생각해 보세요. 책상에 서류를 다 올려놓으면 정작 지금 필요한 한 장을 못 찾습니다. 넓은 책상이 좋은 게 아니라, 지금 필요한 것만 올라와 있는 책상이 좋습니다.

그래서 진짜 문제는 「어떻게 더 많이 기억시킬까」가 아니라 「무엇을 책상 위에 올리고 무엇을 서랍에 둘까」입니다. 이 칸의 열한 편이 전부 그 이야기입니다.

코드는 한 줄도 안 넘어왔고, 넘어온 건 전부 규칙이었습니다

열한 편에서 제 작업으로 넘어온 것을 세어 보면 이렇습니다.

넘어온 것의 종류	개수
프로그램 코드	0
규칙·습관·배치 방식	전부

왜 이렇게 되냐면, 이 문제의 답이 내 데이터 안에 있기 때문입니다.

남이 만든 정리 도구는 남의 자료 모양에 맞춰져 있습니다. 제 자료는 모양이 다릅니다. 그래서 도구를 통째로 가져오면 안 맞고, 가져올 수 있는 건 「이런 식으로 재 봐라」는 방법뿐입니다.

그리고 이 칸이 제 구멍을 제일 많이 찾아냈습니다

가져온 게 적은데 성과는 제일 컸습니다. 열한 편 중 일곱 편이 「남의 것을 자로 삼아 제 것을 재다가」 결함을 찾아냈습니다.

이게 이 칸의 진짜 값어치입니다. 좋은 걸 배워 오는 게 아니라, 남의 기준으로 내 것을 재 보면 안 보이던 게 보입니다.

넘어온 것 대부분이 「무엇을」이 아니라 「언제」와 「어디에」였습니다

처음 세 편일 때는 「코드가 안 넘어온다」만 보였습니다. 여덟 편이 되니 더 정확한 문장이 나왔습니다.

배워 온 것들의 모양이 이랬습니다.

• 「새 도구를 만들면 그 자리에서 바로 점검한다」 ← 언제
• 「한 자료는 딱 한 자리에만 둔다」 ← 어디에
• 「분류가 안 되는 건 임시 칸에 둔다」 ← 어디에

무엇을 만들지가 아니라 언제 하고 어디에 둘지입니다. 이런 건 도구가 아니라 습관이라 그대로 옮겨집니다.

제일 값나간 것은 「근거가 다른데 결론이 같은 것」이었습니다

한 편이 특히 그랬습니다.

어떤 영상에서 말하는 정리 원칙 다섯 개가, 제가 따로 만들어 둔 것과 결론이 똑같았습니다. 그런데 이유는 하나도 안 겹쳤습니다.

• 저쪽 이유: 복잡하면 사람이 지쳐서 안 쓴다
• 제 이유: 경로가 분류에 묶이면 나중에 분류를 바꿀 때 다 깨진다

완전히 다른 길로 갔는데 같은 지점에 도착한 것입니다. 그러면 그 지점이 맞을 확률이 올라갑니다.

같은 이유로 같은 결론이 나오면 그건 그냥 같은 이야기를 두 번 들은 것입니다. 다른 이유로 같은 결론이 나오는 게 훨씬 강한 증거입니다.

그리고 이 칸에서 제일 위험한 판정은 「그건 이미 하고 있다」였습니다

제가 이 칸에서 제일 자주 내리는 판정이 「이미 하고 있다」입니다. 아홉 번째 편에서 그 판정 자체가 흔들렸습니다.

「이미 하고 있다」고 말할 때, 저는 그걸 무엇으로 확인했을까요. 대개는 기억으로 했습니다. 실제로 열어 보지 않았습니다.

그래서 층을 셋으로 나눴습니다.

층	물어야 하는 것	어떻게 확인하나
1	갖고 있나	파일이 있나
2	돌긴 도나	실제로 눌러 보면 결과가 나오나
3	켠 적은 있나	마지막 실행 날짜가 있나

1층에서 멈추면 「있다」로 끝납니다. 그런데 아홉 번째 편에서는 2층에서 걸렸고(있는데 안 돎), 열 번째 편에서는 3층에서 걸렸습니다(돌긴 도는데 24일 동안 한 번도 안 켰음).

셋은 완전히 다른 상태인데 「이미 하고 있다」라는 같은 문장으로 덮입니다.

마지막 — 배울 게 없는 자료도 값을 합니다

재미있는 게 하나 있습니다. 아홉 번째와 열 번째 편은 둘 다 배울 게 거의 없는 자료였습니다.

그런데 배울 게 없으니 오히려 대조표를 끝까지 채우게 됐고, 그 과정에서 제 쪽 빈칸이 드러났습니다.

→ 남의 것을 자로 쓸 때, 그 자가 훌륭할 필요는 없습니다. 눈금만 있으면 됩니다.

여기부터는 자세한 기록입니다

모델에 무엇을 올려보내고 무엇을 밖에 남길 것인가를 다루는 것들. 컨텍스트 압축, 벡터 없는 검색, 제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일째 포장도 안 뜯긴 채였습니다.