저장소를 스타하고, 클론하고, 절반쯤 작동하게 만든 다음, 다음 문제로 넘어간다. 3개월 후에 같은 폴더를 다시 발견하지만, 왜 이걸 가져왔는지, 실제로 사용한 적이 있는지, 아니면 같은 종류의 도구를 다른 이름으로 두 번이나 클론했는지 전혀 기억나지 않는다. 30개가 넘는 저장소가 쌓이면, 더 이상 농담이 아니고 실제 시간을 낭비하게 된다.
왜 저장소당 README 하나만으로는 충분하지 않은가
README는 작성자가 이 도구를 왜 만들었는지 알려줍니다. 하지만 당신이 왜 이걸 가져왔는지, 실제로 사용하고 있는지, 아니면 이미 같은 작업을 하는 다른 세 개의 도구를 가지고 있는지에 대해서는 전혀 알려주지 않습니다.
바로 그 부분을 아무도 기록하지 않습니다. 자신의 저장소가 아닌 것에 대해 기록하는 사람은 아무도 없으니까요. 유용한 것을 클론해서 한 번 실행해보고 나면, 그 이유에 대한 맥락은 터미널을 닫는 순간 사라져버립니다. 같은 폴더에 30개의 저장소가 쌓이면, 무엇이 중요한지, 무엇이 죽은 짐인지 확신할 수 없어서 청소하기 두려운 묘지가 됩니다.
그 어떤 것도 단일 README에는 나타나지 않습니다. 그것은 오직 당신이 수집한 모든 것을 가로질러 읽는 무언가가, 당신이 확인하지 않아도 정기적으로 실행될 때만 나타납니다.
결과물은 무엇인가요
하나의 저장소(vault), 두 개의 폴더:
1found-tools-vault/2├── notes/ # 클론한 저장소당 하나의 마크다운 노트3│ ├── some-scraper-tool.md4│ ├── some-telegram-lib.md5│ └── ...6└── memory/7 └── PORTFOLIO.md # 네 가지 저장소 간 패스(Pass)가 여기에 기록됨
디스크에 있는 일반 마크다운 파일입니다. Obsidian에서 열거나 터미널에서 cat 명령어로 볼 수 있습니다. 데이터베이스가 없으며, 직접 읽을 수 없는 것은 없습니다.
설정 방법
Mac 또는 Linux의 경우:
1mkdir -p ~/found-tools-vault/notes ~/found-tools-vault/memory
Windows, PowerShell의 경우:
1New-Item -ItemType Directory -Force -Path "$HOME\found-tools-vault\notes","$HOME\found-tools-vault\memory"
루프 1과 루프 2를 이 폴더로 지정하면 설정이 완료됩니다. 여기부터는 Claude에게 이 폴더 안에서 무엇을 할지 지시하는 내용입니다.
스택: 동일한 세 가지 요소, 단지 다른 사람의 코드를 가리키는 것뿐인가요
저장소(vault). 하나의 Obsidian 폴더, 클론한 도구당 하나의 노트, 그리고 저장소 간 패스를 위한 폴더 하나.
소스(source). 클론 폴더에 있는 모든 저장소. 매일 사용하든 존재 자체를 잊었든 상관없습니다.
두뇌(brain). 작업별로 분할된 Claude입니다. 저렴한 모델은 저장소와 README를 읽고, Sonnet이 판단을 내립니다: 이미 가진 다른 도구와 중복되는지, 그리고 디스크 공간을 차지할 가치가 있는지 여부를 판단합니다.
루프 1: 도구 하나당 하나의 노트, Claude가 작성합니다 (당신이 작성하는 것이 아닙니다)
중요: 실제로 실행하기 전에 다음 사항을 명심하세요:
- 이 루프가 코드를 푸시(push)하거나, 의존성을 설치하거나, 도구 자체에서 아무것도 실행하지 못하게 하세요. 항상 읽기 전용(read-only)이어야 합니다.
- why_i_grabbed_it은 저장소의 README에서 추측하는 것이 아니라, 당신의 노트, 커밋(commit), 또는 프로젝트 내 다른 사용처에서 가져옵니다.
- 도구를 사용하고 있는지 확실하지 않다면, 건너뛰지 말고 status: unclear로 노트를 작성하세요.
1TRIGGER: 새 저장소가 폴더에 클론되거나, 하루에 한 번2STEPS:3 1. 저장소 읽기: README, package.json / requirements.txt, 마지막4 업스트림 커밋 날짜, 그리고 다른 프로젝트에서 참조되는지 확인5 (imports, configs, scripts)6 2. notes/<repo-name>.md 를 작성하거나 업데이트:7 ---8 repo:9 what_it_does:10 why_i_grabbed_it:11 last_upstream_commit:12 referenced_in_my_projects: []13 status: in-use | shelved | duplicate | unclear14 ---15 ## 실제로 하는 일16 ## 가져온 이유17 ## 실제로 사용하고 있는가18VERIFY: 모든 필드가 채워졌는지, "referenced_in_my_projects"는19 실제 사용 여부를 확인, 추정하지 않음20STOP: 검증 통과 또는 2회 재시도 후 수동 검토 플래그
이것만으로도 루프 2 없이도 구축할 가치가 있습니다. 30개의 노트를 처음으로 연속해서 읽어보면, 절반은 당신을 놀라게 할 것입니다. 도구를 사용하고 있다는 사실을 잊었거나, 아니면 한 번도 사용한 적이 없기 때문입니다.
생성된 도구 노트 하나가 실제 클론 폴더 옆에 있습니다. 이것이 바로 당신이 다른 방법으로는 절대 기록하지 않을 맥락입니다.
루프 1이 실행된 후, 30개의 발견된 저장소는 실제로 어떻게 보일까요
Claude가 새로운 것을 클론할 때마다 다시 생성하는 목록입니다. 노트에서 직접 가져옵니다.
- github.com/author/scrape-lite - in-use, 마지막 업스트림 커밋 2일 전, 참조: feed-reader 프로젝트
- github.com/author/tg-bot-kit - in-use, 마지막 업스트림 커밋 5일 전, 참조: 내 봇 2개
- github.com/author/quick-scheduler - shelved, 마지막 업스트림 커밋 41일 전, 참조: 없음
- github.com/author/api-wrapper-x - in-use, 마지막 업스트림 커밋 1일 전, 참조: 1개 프로젝트
- github.com/author/rss-to-json - duplicate, 마지막 업스트림 커밋 3일 전, 참조: 없음 (scrape-lite와 동일 작업)
- github.com/author/cheap-queue - in-use, 마지막 업스트림 커밋 6시간 전, 참조: 2개 프로젝트
- github.com/author/webhook-relay-lib - shelved, 마지막 업스트림 커밋 96일 전, 참조: 없음
- github.com/author/simple-cache - in-use, 마지막 업스트림 커밋 2일 전, 참조: 3개 프로젝트
- github.com/author/old-scraper - abandoned upstream, 마지막 업스트림 커밋 340일 전, 참조: 없음
- github.com/author/notify-me - unclear, 마지막 업스트림 커밋 12일 전, 참조: 확실하지 않음
- github.com/author/token-utils - in-use, 마지막 업스트림 커밋 1일 전, 참조: 1개 프로젝트
- github.com/author/quick-parser - duplicate, 마지막 업스트림 커밋 8일 전, 참조: 없음 (rss-to-json과 동일 작업)
- github.com/author/tiny-orm - shelved, 마지막 업스트림 커밋 55일 전, 참조: 없음
- github.com/author/rate-limiter - in-use, 마지막 업스트림 커밋 3일 전, 참조: 2개 프로젝트
- github.com/author/config-loader - in-use, 마지막 업스트림 커밋 4일 전, 참조: 대부분의 내 프로젝트
- github.com/author/legacy-fetch - abandoned upstream, 마지막 업스트림 커밋 400+일 전, 참조: 없음
- github.com/author/env-check - in-use, 마지막 업스트림 커밋 9일 전, 참조: 1개 프로젝트
- github.com/author/pretty-logs - shelved, 마지막 업스트림 커밋 70일 전, 참조: 없음
- github.com/author/proxy-list - unclear, 마지막 업스트림 커밋 20일 전, 참조: 확실하지 않음
- github.com/author/backoff-lib - in-use, 마지막 업스트림 커밋 6일 전, 참조: 2개 프로젝트
- github.com/author/dead-simple-db - shelved, 마지막 업스트림 커밋 88일 전, 참조: 없음
- github.com/author/quick-hash - in-use, 마지막 업스트림 커밋 1일 전, 참조: 1개 프로젝트
- github.com/author/retry-wrapper - duplicate, 마지막 업스트림 커밋 14일 전, 참조: 없음 (backoff-lib와 동일 작업)
- github.com/author/format-time - in-use, 마지막 업스트림 커밋 2일 전, 참조: 대부분의 내 프로젝트
- github.com/author/quick-mailer - shelved, 마지막 업스트림 커밋 50일 전, 참조: 없음
- github.com/author/health-check-lib - in-use, 마지막 업스트림 커밋 5일 전, 참조: 2개 프로젝트
- github.com/author/dotenv-plus - in-use, 마지막 업스트림 커밋 3일 전, 참조: 대부분의 내 프로젝트
- github.com/author/simple-lock - unclear, 마지막 업스트림 커밋 30일 전, 참조: 확실하지 않음
- github.com/author/old-notify - abandoned upstream, 마지막 업스트림 커밋 500+일 전, 참조: 없음
- github.com/author/tiny-scheduler - duplicate, 마지막 업스트림 커밋 18일 전, 참조: 없음 (quick-scheduler와 동일 작업)
(위 이름들은 실제 도구가 아닌 목록의 형태를 보여주기 위한 예시입니다)
30줄은 수동으로 읽기에 전혀 부담되지 않습니다. 또한 세 개의 별도 재시도 로직 라이브러리가 같은 작업을 수행하고 있다는 점, 그리고 실제로 의존하고 있는 저장소 중 하나가 1년 넘게 업스트림 커밋이 없다는 점을 알아차리기에 충분합니다.
모든 30개의 노트가 존재하는 저장소(vault)의 그래프 뷰(graph view)입니다. 모든 도구가 노드(node)로 표시되며, 중복 및 공유 목적의 저장소가 시각적인 클러스터(cluster)로 모입니다.
루프 2: 30개 이상의 도구를 모은 후에만 작동하는 패스(pass)들인가요
단일 도구의 README는 이것을 알려줄 수 없습니다. 당신이 가져온 모든 것을 가로질러 읽는 무언가만이 가능합니다.
1TRIGGER: 12시간마다2STEPS:3 패스 1, 실제로 보류(shelved)된 항목:4 status: in-use 이지만 30일 이상 프로젝트에서 참조되지 않은5 저장소 플래그, 실제 사용 여부를 내 저장소와 교차 확인6 패스 2, 중복 도구:7 모든 노트의 "실제로 하는 일"을 비교, 같은 문제를 해결하는8 항목 그룹화, 함수 이름이나 목적이 일치하는지 확인, 설명만9 비슷한 것은 제외10 패스 3, 업스트림 위험:11 의존하는 도구 중 마지막 업스트림 커밋이 120일 이상 지난12 도구 플래그, 예고 없이 스테일(stale)해질 수 있는 의존성 파악13 패스 4, 정직한 평가:14 각 도구가 디스크 공간과 기억할 정신적 오버헤드를 감당할15 가치가 있는지 한 줄로 평가, 누그러뜨리지 않음16VERIFY: 각 패스가 memory/PORTFOLIO.md에 기록, 패스 2의 그룹은17 실제 공유 함수 또는 목적 일치로 뒷받침됨18STOP: 네 패스 모두 완료, 또는 패스 실패 시 로그 기록, 절대19 조용히 건너뛰지 않음
패스 3이 실제로 작업 방식을 바꾸는 패스입니다. 당신이 의존하고 있는 세 개의 도구의 유지 관리자가 1년 전에 조용히 사라졌다는 것을, 눈앞의 목록에서 확인하기 전까지는 깨닫지 못합니다.
패스 3에서 생성된 위험 테이블입니다: 실제로 사용 중인 도구들을 업스트림 프로젝트가 마지막으로 업데이트된 이후 경과 시간순으로 정렬합니다.
먼저 수동 버전을 시도해보시겠어요
항상 같은 규칙입니다. 직접 손으로 증명하지 않은 것은 예약하지 마세요.
1작업이 기준을 충족할 때까지 루프로 작업합니다.23TASK:4[경로]의 모든 저장소 폴더를 읽습니다. 각각에 대해 다음을 기록합니다:5무엇을 하는지, 원래 왜 가져왔는지, 여전히 실제로 사용하고 있는지,6업스트림 프로젝트의 마지막 커밋이 얼마나 지났는지. 그런 다음 모든7저장소를 비교합니다: 중복 항목과 의존하지만 업스트림이 조용해진8항목을 찾습니다.910SUCCESS CRITERIA (엄격, 소프트 패스 없음):11- 모든 "duplicate"는 실제 일치하는 함수 또는 목적으로 뒷받침됨,12 비슷한 설명만으로는 안 됨13- 모든 "shelved" 저장소는 내 프로젝트에서 마지막으로 참조된14 이후 경과 일수를 포함15- 업스트림 위험은 실제 커밋 날짜 기반, 추정 아님1617LOOP PROTOCOL, 각 턴마다 반복:181. PLAN - 다음 단계 하나를 명시192. DO - 출력을 생성하거나 개선203. VERIFY - 각 기준을 1-10점으로 평가, 솔직하게214. DECIDE - 모든 기준이 8+이면 "FINAL"을 출력하고 중지2223RULES:24- 모든 기준이 8+일 때까지 완료했다고 하지 마십시오25- 질문하지 말고, 합리적인 가정을 하고 계속 진행하십시오2627시작하십시오. FINAL이 나올 때까지 루프를 실행하십시오.
중복 목록이나 업스트림 위험 목록이 당신을 놀라게 한다면, 예약(schedule)할 가치가 있습니다. 만약 이미 알고 있던 것을 확인시켜줄 뿐이라면, 아직 자동화하지 마세요.
실제로 작동하는 순서는 무엇인가요
루프 1을 모든 클론된 저장소에 실제 노트가 있을 때까지 실행하세요. 자리 표시자(placeholder)가 아닌 실제 노트 말입니다.
일주일에서 이주일 정도 그대로 두세요. 그 이후로 새로 가져오는 모든 도구는 자동으로 노트가 생성됩니다.
그때서야 루프 2를 켜세요. 중복 및 업스트림 위험 패스는 충돌할 만큼 충분한 노트가 필요합니다.
마지막으로 예약하세요. 직접 손으로 최소 두 번은 깨끗하게 실행되는 것을 확인한 후에야 예약하세요.
비용은 얼마인가요
루프 1은 새 클론(clone)당 실행되므로, 고정된 일정이 아닌 실제로 가져오는 양에 따라 확장됩니다. 대부분의 주에는 몇 번의 저렴한 모델 호출만으로 충분합니다.
루프 2는 30개 이상의 노트에 대해 하루에 두 번 실행됩니다. 패스 1과 패스 3은 저렴한 모델로 이동하세요. 이는 조회(lookup)일 뿐, 판단 호출이 아닙니다. 패스 2와 패스 4는 Sonnet에 유지하세요. 실제 중복을 찾고 정직한 평가를 내리는 것은 비교 대상을 추론할 수 있는 모델이 필요하기 때문입니다. 이렇게 분할하면, 30개 저장소 컬렉션에서 하루 두 번 실행하는 비용은 같은 감사를 수동으로 수행하는 시간보다 적습니다.
기억해야 할 한 가지는 무엇인가요
README는 도구가 무엇을 하는지 알려줍니다. 하지만 이것은 30개의 도구 중 어떤 것을 실제로 사용하고 있는지, 어떤 것들이 조용히 서로를 중복하고 있는지, 그리고 어떤 것에 의존하고 있지만 아무도 유지 관리하지 않는지 알려줍니다.
가치는 결코 단일 도구 노트에 있지 않습니다. 당신이 수집한 것 중 어느 것도 조용히 썩거나, 조용히 중복되거나, 조용히 관리되지 않은 채로 남아있지 않도록, 당신이 실제로 볼 수 있는 곳에 기록하는 무언가가 있다는 사실에 있습니다.
루프 1을 먼저 구축하세요. 루프 2를 건드리기 전에 2~3주간 실행하세요. 중복 및 업스트림 위험 패스는 5개의 저장소로는 쓸모가 없습니다. 20개를 넘어서면 비용을 지불하기 시작합니다.
이와 같은 분석을 더 원하신다면, Telegram과 X에 며칠에 한 번씩 게시합니다. 둘 다 무료입니다.
Telegram - https://t.me/GipArcAI
