문제는 이것이었습니다. 기술은 내가 안 보는 동안에도 계속 발전하는데, 매주 쏟아지는 깃허브 저장소·논문·구루(그 분야에서 이름난 개발자) 글을 사람 손으로 다 따라갈 수가 없습니다. 그래서 트렌드 수확기(trend-harvest — 내가 만들어 매주 자동으로 돌리는 수집 장치)를 두었습니다. AI가 바깥세상에서 좋은 아이디어를 주워 오고, 내 작업 방식에 쓸 만한지 스스로 10점 만점으로 채점합니다. 260회 넘게 633건을 매겼는데 만점은 딱 30번뿐이었습니다. 그 30개가 무엇이고 왜 만점이었는지, 여섯 갈래로 묶어 정리했습니다.
만점이 드문 이유는 채점 방식에 있습니다. 수확기는 주워 온 아이디어를 다섯 잣대로 평가합니다. 자동화가 되는가, 사람 손이 덜 가는가, 애매한 규칙을 확실한 장치로 바꾸는가, 토큰(AI가 글을 읽고 쓰는 단위 — 많이 쓸수록 비용이 든다)을 아끼는가, 효과를 숫자로 잴 수 있는가. 각 잣대에 0~2점씩, 합이 10점입니다. 만점은 다섯 잣대가 모두 2점이라는 뜻이라, 좀처럼 나오지 않습니다.
가장 믿을 만한 신호는 반복입니다. 한 번 만점은 우연일 수 있습니다. 하지만 같은 저장소(깃허브에 올라온 한 프로젝트의 코드 묶음)가 여러 회차에 걸쳐 반복해서 만점을 받으면, 그 방향이 진짜라는 뜻입니다. 30장 중 가장 강한 신호가 여기 있습니다.
샌드박싱(sandboxing — 프로그램을 격리된 모래놀이터 같은 공간에서 돌려, 바깥에 영향을 못 주게 하는 기법)을 도구 출력에 적용한 것입니다. 도구를 돌리면 나오는 원시 출력(로그·화면 스냅샷)을 AI 기억 창(컨텍스트 — AI가 한 번에 읽을 수 있는 글의 양)에 통째로 넣지 않습니다. 대신 격리된 공간에서 실행해 요약만 들입니다. 56KB짜리 화면 스냅샷이 299바이트로, 99% 줄었습니다. 읽고 나서 줄이는 압축과 달리, 들어오기 전에 막는 상류 차단입니다.
복잡한 작업을 푼 뒤, 그 푸는 방법을 스스로 스킬(skill — AI가 나중에 다시 꺼내 쓰도록 절차를 적어 둔 재사용 문서)로 만들어 다음에 재사용합니다(25·48차). 내 자가개선(AI가 자기 작업 환경을 스스로 고치는 장치)은 "고친 것"에서만 배웁니다. 이건 "성공한 것"에서도 배웁니다. 그래서 자가진화 철학의 직접 경쟁자이자 보완재입니다.
30장을 성격별로 묶으면 여섯 갈래가 됩니다. 가장 큰 무리는 컨텍스트·도구 출력을 아끼는 계열입니다. 여기에 메모리(AI가 지난 작업을 기억해 두는 저장소)·라우팅(질문의 난이도에 맞춰 싼 모델과 비싼 모델을 골라 보내는 것)·비용 튜닝까지 더하면 19장(63%)이 "비용을 구조적으로 줄인다"는 한 방향을 가리킵니다.
회차가 쌓이면서 만점의 기준이 옮겨갔습니다. 초기엔 "나온 것을 줄이는" 사후 압축을 높이 봤습니다. 후기엔 "애초에 안 들이는" 사전 격리를 더 높이 쳤습니다. 강물로 치면 하류에서 물을 거르는 대신 상류에서 오염원을 막는 쪽입니다. 더 상류의, 더 근본적인 개입일수록 만점에 가까웠습니다.
"나온 출력을 줄인다"
CLI"애초에 안 들인다"
규칙 판단 기준도 "자주 쓰였나"에서 "빼봐도 괜찮나"로 옮겨갔습니다(252회차). 자주 쓰였는지 대신, 정말 없어서는 안 되는지를 봅니다. 규칙을 하나씩 빼 보고 무너지는지 확인하는 방식이라, 원문에서는 이렇게 부릅니다: build-to-delete
만점 30장 전체를 회차 내림차순으로 늘어놓았습니다. 항목 이름을 누르면 원 출처(깃허브 저장소 또는 논문)로 갑니다. mksglu는 일곱 회차 만점이라 한 줄로 묶었습니다. 상태 칸은 수확 로그 원문의 기록입니다. "적용"은 내 규칙에 실제로 배선됐다(연결돼 작동한다)는 뜻이고, 만점이라고 다 배선된 건 아닙니다.
| 회차 | 항목 | 테마 | ⭐ | 상태 |
|---|---|---|---|---|
| 260 | catastrophic-remembering | 규칙 위생 | 논문 | 큐잉 |
| 252 | build-to-delete-ablation | 규칙 위생 | 124 | 큐잉 |
| 234 | 알리바바 코드리뷰 | 결정론+AI | 17.7K | 미도입 |
| 110 | cocoindex | 컨텍스트 신선도 | 8.9K | 권한 보류 |
| 109 | memtrace | 메모리·그래프 | 148 | 권한 보류 |
| 107 | n8n-mcp | 오케스트레이션 | 20.2K | 적용 |
| 98 | multi-agent-shogun | 오케스트레이션 | 1.3K | 적용 |
| 97 | jcode | 메모리·그래프 | 3.9K | 적용 |
| 92 | Dive-into-Claude-Code | 결정론+AI | 956 | 적용 |
| 91 | ios-simulator-skill | 컨텍스트 압축 | 913 | 적용 |
| 86 | SWE-Pruner | 컨텍스트 압축 | 274 | 적용 |
| 85·81·79 69·64·53·47 | mksglu/context-mode ×7 | 샌드박싱 | ~11.7K | 적용 |
| 76 | memsearch | 메모리·그래프 | 1.5K | 적용 |
| 75 | sem | 시맨틱 diff | 1.9K | 적용 |
| 70 | semantic-router | 모델 라우팅 | 4.0K | apply 미기록 |
| 66 | graphify | 메모리·그래프 | 37 | 적용 |
| 65 | mattpocock/skills | 스킬 라이브러리 | 35 | 적용 |
| 57 | manifest | 모델 라우팅 | 5 | 적용 |
| 48 | hermes-agent | 자율 진화 | 112 | 적용 |
| 46 | claude-mem | 메모리·그래프 | 65 | 적용 |
| 39 | everything-claude-code | 비용 최적화 | 161 | 적용 |
| 25 | hermes-agent | 자율 진화 | 93 | 적용 |
| 23 | Archon | 오케스트레이션 | 17 | 적용 |
| 6 | rtk | 컨텍스트 압축 | 20 | 적용 |
만점 30장 중 실제로 규칙에 배선된 건 24장. 나머지 6장(20%)은 권한 보류·미도입·큐잉 상태입니다. 점수는 "좋다"는 판단이고, 실제로 내 작업에 넣는 건 또 다른 문턱(실제로 써 보고 효과가 있는지 확인하는 단계)을 넘어야 합니다.
"10점 = 좋은 설계"이지, "10점 = 내 작업에서 실제로 효과"가 아니다.
이 점수는 수확기가 스스로 매긴 다섯 축 평가입니다. 외부의 독립 검증(held-out — 채점에 쓰지 않은 별도 자료로 다시 확인하는 것)이 아닙니다. 각 수치(99% 감소·9분의 1·1,200× 등)도 원 저장소·논문 저자의 주장이지 내가 벤치마크(같은 조건에서 성능을 재는 표준 시험)로 확인한 값이 아닙니다. 그래서 이 30선은 "거의 안 주는 점수를 받은, 설계가 뛰어난 것들"로 읽는 게 정확합니다. 원 수치는 표의 출처 링크에서 직접 확인할 수 있습니다.
출처: 이 사이트의 수확 로그 페이지(회차마다 채점 카드를 쌓아 두는 기록, 12,248줄)를 결정론 파싱(사람 판단 없이 정해진 규칙만으로 글자를 읽어 내는 것)해 점수 배지 10/10을 전건 추출했습니다. 회차 범위 6~260차 · 만점 30장. 파싱한 원본 파일: trend-harvest-log.html