Trend Harvester Analysis · 16 Diagrams · iter 7~15

6시간마다 바깥 AI 소식을 긁어
스스로 반영하는 trend-harvester를 만들었다

문제는 이것이었습니다. AI 도구의 세계는 매일 바뀌는데, 내가 안 보는 사이에 놓친 소식은 시스템에 반영되지 않았습니다. 그래서 바깥 소식을 스스로 모아 오는 도구 trend-harvester(트렌드 수확기)를 만들었습니다. 훑는 곳은 세 갈래입니다. 첫째는 개발자들이 몰리는 GitHub의 인기 프로젝트입니다. 둘째는 유명 AI 구루(guru, 이 분야에서 널리 인정받는 전문가)의 GitHub 활동과 소셜 글(X·Threads)입니다. 셋째는 뉴스 구독 피드입니다. 뉴스 구독 피드란 사이트가 새 글 목록을 기계가 읽기 쉬운 형식으로 내보내는 것입니다. 개발자들은 이것을 세 글자 약어로 부릅니다: RSS.

이 세 갈래를 6시간마다 훑습니다. 모은 소식은 두 번 검문합니다. 먼저 이 시스템의 개발 철학인 loopy-era(스스로 고치는 반복 루프를 돌리는 방식)의 5가지 기준에 맞는지 채점합니다. 다음엔 autoresearch 방식으로 실제 점수가 오르는지 재실험합니다. autoresearch란 바꿔 보고 점수를 재서 좋아진 것만 남기는 자동 실험 방식입니다. 통과한 것만 시스템에 자동 반영합니다. 그 결과 시스템을 망가뜨릴 뻔한 대형 사고 3건을 미리 막았고, 완료 알림이 실제 텔레그램으로 전송되는 것까지 확인했습니다.

6h
loop interval
7명
guru github
3층
dedup filter
287
checks pass
0
regressions
Design Philosophy
핵심 철학
"바깥세상이 빠르게 바뀌므로, 시스템도 바깥 신호를 받아 함께 진화해야 한다. 단, 유행이라고 무조건 따르지는 않는다. loopy-era 철학 필터(우리 원칙에 맞는지 거르는 검문)를 통과한 것만, keep/discard(남길지 버릴지) 판정을 거친 뒤 반영한다." — SKILL.md, Core Philosophy
Diagram 1 · 자가학습 메타 루프 (Self-Learning Meta Loop)
loopy-era self-improving ① 외부 수집 GitHub · Gurus · RSS ② 철학 필터 5개 기준으로 채점 ③ Keep/Discard harness-report ④ 시스템 반영 rules · skills · hooks ⑤ 실패 학습 9/9 rejected → fix
바깥 소식 수집 → 원칙에 맞는지 거르기 → 반영 여부 판정 → 시스템 진화 → 실패를 다시 학습. 이 다섯 단계가 계속 돕니다.

trend-harvester는 loopy-era 시스템(스스로 고쳐 나가는 반복 루프)에서 바깥 소식이 들어오는 입구 역할을 합니다. 안에서만 배우면 우물 안 개구리가 되므로, 세상의 최신 AI 지식을 주기적으로 빨아들입니다. 단, 우리 원칙과 어긋나는 유행은 거부합니다. 좋으면 남기고 아니면 버리는 keep/discard 판단을, 시스템 내부 실험에서 바깥 소식 수용으로 넓힌 셈입니다. 이 도구의 절차와 설정은 스킬 정의 파일 한 장에 적혀 있고, 위 인용문은 그 파일의 첫머리입니다.

Scheduling · /loop 6h
6시간 주기 자동 실행

trend-harvester(정식 이름은 loopy-era-trend-harvester, 바깥 소식을 모아 시스템에 반영하는 스킬)는 자동 반복 명령 /loop 6h /loopy-era-trend-harvester에 등록되어 하루 4회 알아서 돌아갑니다(백그라운드 실행). 실행이 겹치지 않도록 두 가지 장치를 둡니다. 첫째, lockfile(잠금 파일, 실행 중이라는 표시로 남기는 파일)에 실행 중인 프로세스 번호를 적어 두어, 이미 돌고 있으면 새 실행을 막습니다. 둘째, 한 번 돈 뒤 최소 1시간은 다시 돌지 않게 합니다. 그래서 사람이 직접 불러도 충돌하지 않습니다.

Diagram 2 · 24시간 · 6시간 루프 타임라인
00:00 06:00 12:00 18:00 24:00 Run #1 scan Run #2 scan Run #3 scan Run #4 scan (next day) 6h interval 6h interval 6h interval 6h interval cooldown ≥ 1h enforcement · PID lockfile · trap-on-exit Daily schedule: 00 · 06 · 12 · 18 KST (4 runs/day) Per run: Phase 0 → 1 → 2 → 3 → 4 → 5 (~4~5 min)
자동 반복 명령으로 하루 4회 실행됩니다. 최소 간격(쿨다운)과 lockfile로, 두 실행이 동시에 겹치는 사고를 막습니다.

등록 방법

# Claude Code 대화창에서:
/loop 6h /loopy-era-trend-harvester

# 또는 정해진 시각마다 실행(cron 예약):
/schedule create --name harvest --cron "0 */6 * * *" --prompt "/loopy-era-trend-harvester"
설정 항목값이렇게 정한 이유
실행 주기6hGitHub 인기 순위(trending)는 시간 단위로 바뀝니다. 6시간마다면 낭비 없이 최신 상태를 유지합니다.
최소 간격(쿨다운)1h사람이 부른 실행과 자동 실행이 겹치지 않도록, 한 번 돈 뒤 최소 1시간은 다시 돌지 않게 강제합니다.
동시 실행 방지PID lockfilelockfile에 실행 중인 프로세스 번호를 적어 둡니다. 두 실행이 동시에 WebFetch(웹 페이지를 가져오는 도구)로 긁어 raw/ 폴더에 같은 파일을 겹쳐 쓰는 것을 막습니다.
죽은 실행 정리kill -0앞 실행이 비정상 종료하면, 적어 둔 프로세스 번호가 죽었는지 확인해 잠금을 자동으로 풉니다.
하루 실행 횟수4회한국시간 0·6·12·18시. 한 번에 약 25건씩 × 4회 = 하루 100건을 처리합니다.
Loopy-Era Fitness Filter
채택할지 가리는 5가지 기준 (loopy-era 정합성 5축)

새로 들어온 소식은 아래 5가지 기준(loopy-era 정합성 5축) 중 3개 이상 을 만족해야 반영 후보가 됩니다. 기준마다 0~2점을 매겨, 합쳐서 10점 만점입니다.

Diagram 3 · 5축 철학 필터 (Pentagon Radar)
자동화 증대 Axis 1 마찰 제거 Axis 2 HARD 전환 Axis 3 토큰 효율 Axis 4 측정 가능 Axis 5 0.5 1.0 2.0 합격선: 6점 이상 (기준 3개 이상 충족) → 분석 통과
예시 점수 8점. 다섯 기준을 모두 1.5~2.0으로 높게 받은 우량 소식(예: "테스트가 새로운 병목이다")입니다.
Axis 1
자동화를 늘리는가
사람이 손으로 되풀이하던 일을 줄이는가? 매번 사람이 손대야 하던 절차를 기계가 대신할 수 있는가?
Axis 2
반복 실수(마찰)를 없애는가
되풀이되는 오류·실패를 뿌리부터 막는가? 2번 이상 겪은 같은 실수를 규칙으로 다시 안 생기게 하는가?
Axis 3 · SOFT → HARD
하드 판정으로 바꿀 수 있는가
"좋아 보인다" 같은 사람·AI의 주관 판단(이 시스템에서는 소프트 판정이라 부릅니다)을, 기계가 통과(0)/실패(1) 종료 코드로 딱 잘라 판정하는 하드 판정으로 바꿀 수 있는가?
Axis 4
낭비(토큰)를 줄이는가
AI가 쓸데없이 여기저기 뒤지거나 같은 일을 되풀이하지 않는가? AI가 한 번에 기억하는 분량(컨텍스트)을 아끼는가? 컨텍스트가 곧 토큰(AI가 읽고 쓰는 글자 단위) 비용입니다.
Axis 5
숫자로 잴 수 있는가
하나의 숫자 지표로 추적할 수 있는가? 하네스(harness, AI가 다 했다고 거짓말하지 못하게 증거를 요구하는 감시 장치)의 상태를 harness-report(시스템 건강 점수를 내는 도구)나 하드 판정 비율처럼 수치로 잴 수 있는가?
Pipeline Architecture
소식이 거치는 6단계(Phase 0~5) 처리 과정
Diagram 4 · 6-Phase 파이프라인 (Full Flow)
Phase 0 실행 전 점검 lockfile · 쿨다운 trap-on-exit Phase 1 수집 (Scan) WebFetch 3-way raw/*.jsonl Phase 2 분석 (Analyze) AI가 의미 파악 5개 기준 채점 Phase 3 Dry-Run 기준 점수 기록 harness-report Phase 4 적용 (Apply) 3단계 판정 auto rollback A. GitHub trending +100 stars weekly B. 구루 X/Threads karpathy · swyx · simonw C. 뉴스 구독(RSS) Latent Space · Anthropic score ≥ 6? 3/5 axes analyzed/ rejected/ YES NO auto apply TG approve reject 점수 비교 NEW ≥ BASELINE? keep rollback git reset Phase 5 Report Telegram 알림 모든 제안 처리 완료 →
0~5단계 전체 흐름입니다. 6점 이상이면 통과로 갈라지고, 반영은 3단계로 판정하며, harness-report 점수가 떨어지면 이전 상태로 되돌립니다.

15번째 검증 회차(iter 15)에서 추가: 3단계와 4단계 사이에 Phase 3.5 autoresearch judge가 끼어들어, 검문을 두 겹으로 만듭니다. judge란 바꿔 본 뒤 점수를 재서 남길지 판정하는 심판 단계입니다(아래 Diagram 16 참조).

Collection Sources
네 갈래로 소식을 모으는 구조 (12번째 회차에 확장)
Diagram 5 · 4-way 수집 소스 (A/A'/B/C → raw/)
A. GitHub Trending (7 sources) All + Python + TS + Rust + Go + Markdown + Shell (6 langs) + 5 topic queries + 8 awesome lists allow_no_code: true A'. AI 구루 GitHub ⚡ 신규 구루 10명 계정 직접 훑기 • karpathy (w=10) • anthropics (w=10) • simonw (w=9) • openai (w=8) • yoheinakajima (8) • cognition-ai (8) pushed_repos + starred B. 구루 소셜 글(X·Threads) RSSHub / Nitter mirrors 구루 10명 × 최근 7일치 (선언·의견 수집) C. 뉴스 구독(RSS) Latent Space (weekly) Simon Willison (daily) Anthropic · OpenAI (weekly) WebFetch or gh CLI fallback or Nitter → RSSHub → ThreadReader retry cascade raw/*.jsonl $HARVEST_DIR/raw/ github-all-20260405.jsonl github-typescript-20260405.jsonl guru-github-karpathy-20260405.jsonl guru-github-anthropics-20260405.jsonl guru-x-karpathy-20260405.jsonl feed-latent_space-20260405.jsonl feed-anthropic-20260405.jsonl iter 12
12번째 회차 확장. A(GitHub 인기 순위 7갈래) + A'(구루 GitHub 10명, 신규) + B(구루 소셜 글 X·Threads) + C(뉴스 구독 피드)를 모아 원본 파일로 저장합니다. 네 갈래 수집입니다. 원본 파일은 한 줄에 한 항목씩 적는 형식으로 저장 폴더에 쌓입니다: raw/ JSONL
change_type Routing
어디에 반영할지 갈라지는 판정
Diagram 6 · 반영 종류 4갈래 분기 — change_type
change_type 분석 결과에 따라 갈림 rule 공통 규칙에 덧붙이기 ~/.claude/rules/*.md AUTO if score≥7, risk=low scaffold-rule 프로젝트별 규칙 {proj}-scaffold/SKILL.md AUTO if score≥7, risk=low new-skill 새 스킬 만들기 ~/.claude/skills/{name}/ 텔레그램 승인 필요 hook 새 자동검사(훅) 추가 hooks/*.sh + settings.json 텔레그램 승인 필요 Safety Guards (HARD BLOCK) ✗ 새 스킬: 같은 이름 파일이 이미 있으면 덮어쓰기 금지 ✗ 삭제 요청은 자동 거부 · ✗ 위험도 높음은 자동 거부
반영 종류(위 그림 맨 위 상자, 분석 결과가 정하는 값) 4가지의 경로입니다. 자동 반영과 사람 승인으로 갈리고, 위험한 작업은 강제로 막는 안전장치 4가지가 있습니다.
반영 대상change_type저장 위치반영 방식
공통 규칙rule~/.claude/rules/*.md기존 파일에 덧붙임 (안전)
프로젝트별 규칙scaffold-rule{proj}-scaffold/SKILL.md기존 파일에 덧붙임 (안전)
새 스킬new-skill~/.claude/skills/{name}/새로 만들기만 · 덮어쓰기 방지
새 자동검사(훅)hook~/.claude/hooks/*.sh새로 만들기만 · 덮어쓰기 방지
Apply Decision Logic
반영을 3단계로 판정하기
Diagram 7 · 반영 여부 판정 과정
analyzed/*.json score · risk · change_type risk == high? or delete? REJECT score≥7 + risk=low + type∈{rule,sr}? AUTO APPLY score≥6 + type∈ {new-skill,hook}? TELEGRAM APPROVE SKIP (low score) YES NO YES NO YES NO
3단계로 거릅니다. 먼저 위험한 것을 걸러내고, 자동으로 반영할지 판정하고, 사람 승인이 필요한지 판정합니다. 나머지는 건너뜁니다.
Keep/Discard Rollback
harness-report 점수가 떨어지면 되돌리기 (keep/discard)
Diagram 8 · Keep/Discard Rollback Loop
① 기준 점수 측정 /harness-report quick BASELINE = 72 ② apply_change 제안 반영 git add -A ③ 다시 측정 /harness-report quick NEW_SCORE = ? NEW ≥ BASELINE? KEEP mv → applied/ git commit BASELINE = NEW_SCORE DISCARD (rollback) git reset --hard mv → rejected/ BASELINE unchanged → 다음 제안 처리 YES NO harness-report score 72 max=100
harness-report 점수가 떨어지면 곧바로 이전 상태로 되돌립니다(discard). 기준 점수(baseline)는 성공했을 때(keep)만 새 점수로 올립니다. 되돌릴 때는 git의 강제 되감기 명령을 씁니다: git reset --hard
System Integration Map
전체 시스템에서 이 도구의 위치
Diagram 9 · Loopy-Era 시스템 속 trend-harvester의 위치
외부 세계 (External) GitHub X/Threads RSS Feeds Awesome Newsletters trend-harvester 6-phase pipeline 5가지 기준 필터 /loop 6h 스스로 개선하는 시스템(loopy-era) rules/ global rules 11개 파일 scaffolds/ project-specific ~15개 프로젝트 skills/ new-skill target 50+ 스킬 hooks/ hook target 자동검사 15개 harness-report 하나의 점수로 검증 점수 하락 감지 applied/ rejected/ jsonl log Telegram Notify · approve reply rule scaffold-rule new-skill hook validate
바깥세상 → trend-harvester(6시간마다) → 시스템 4곳에 반영 → harness-report 점수로 검증 → 반영 또는 거부.
Verification Report · 2026-04-05
실제로 반복 검증한 결과
287
total checks
287
passed
0
regressions
15
iterations
3
막은 사고
2×
검문 관문

사용자 요청: "반복검증해서 설계의도에 맞게 작동하는지 확인하고 개선점은 자동 보완해 — 더 이상 보완점이 없을 때까지". 이 요청에 따라 autoresearch 방식(점수가 오를 때만 남기는 자동 실험)으로 7~11번째 검증 회차(iter 7~11)를 돌렸습니다.

Diagram 10 · 검증 회차 0~15의 점검 항목 수 누적 그래프
0 50 100 145 200 check count 45 iter 0 45 iter 1 65 iter 2 65 iter 3 65 iter 4 100 iter 5 100 iter 6 125 iter 7 145 iter 8 5 iter 9 e2e-v2 6 iter 10 live e2e 145 iter 11 287⚡ iter 12 scope++ 287📱 iter 13 telegram 287🛡️ iter 14 dedup 287⭐ iter 15 judge ← 이번 세션 v1/v2 v3/e2e-v1 v4/v5 (new) e2e-v2/live scope++
점검 항목 수가 쌓인 그래프입니다. 7회차에 예외 상황 점검(v4)으로 25개 늘고, 8회차(v5)에 145개로 안정됐습니다. 10회차에는 실제 전 과정 시험을 6개 항목 모두 통과했고, 12회차에 무엇을 모을지 범위를 근본부터 다시 설계했습니다.
7
예외 상황 점검표 (v4)
점검 항목 25개를 새로 추가했더니 실제로 2건이 실패했습니다: E1:existing_file_guard, E4:concurrent_lock. 앞은 기존 파일 덮어쓰기 보호, 뒤는 동시 실행 잠금을 점검하는 항목입니다. 두 곳 모두 즉시 고쳤습니다.
125/125
8
보안·일관성·실행 기록 점검 (v5)
점검 20개를 추가했습니다. 위험한 문자열 실행(eval) 금지, 파일 경로 안전 처리, 안전한 출력 방식(printf)을 확인했습니다. 전부 통과해 손댈 곳이 없었습니다.
145/145
9
전 과정 모의 실행 (2차)
apply_change / is_auto_applicable 두 함수(실제로 반영하는 함수와 자동 반영 여부를 정하는 함수)를 진짜 셸 실행 환경에서 돌려 확인했습니다.
5/5
10
실제 전 과정 실행 ⭐
이번 작업의 최대 성과. 실제로 WebFetch로 9개를 모았는데, 단순 단어 검색(grep)으로는 9개 전부 거부됐습니다. 대신 사람이 고른 좋은 제안으로 반영에 성공했습니다.
6/6
11
분석 단계(Phase 2)는 AI가 꼭 필요함을 문서화
10회차 실험으로 '단순 단어 검색으로는 안 되고 AI(Claude)의 의미 판단이 필수'임을 확인해 문서에 남겼습니다.
145/145
12
모으는 대상을 전면 확장 ⚡ (사용자 피드백)
근본적인 결함 발견·수정. "파이썬에만 치우쳤고 구루 GitHub가 빠졌다"는 지적을 받아들여, 모든 언어 인기 순위 + 언어별 6갈래 + 구루 GitHub 10명 + 주제 검색 5개로 다시 설계했습니다. 스킬 정의 파일이 6,977바이트(+44%) 커졌습니다.
287/287
13
완료 알림 텔레그램 자동 전송 (Phase 5) 📱
실행하면 몇 개를 모으고 분석·반영했는지 통계를 텔레그램으로 자동 보냅니다. 반영 상세 5건 + 점수 변화 + 걸린 시간이 들어갑니다. 실전 검증: 실제 전송에 성공했습니다(텔레그램이 돌려준 메시지 번호 6195).
287/287
14
이미 본 것 기록해 중복 막기 (dedup) 🛡️
세 번째 사고 시나리오 차단. 반복 실행할 때 같은 프로젝트를 다시 모으고 다시 반영하는 것을 막습니다. 세 겹으로 방어합니다. 수집 단계(Phase 1)에서 건너뛰기, 반영 정책(Phase 4), 반영 함수의 내용 해시 대조입니다. 4번 이상 본 것은 graveyard(더는 안 보는 항목을 치워 두는 보관소)로 치웁니다.
287/287
15
구루 선정 기준 + Phase 3.5 autoresearch 판정 ⭐
activity_type (활동 유형) 3축과 4가지 기준으로 구루를 10명에서 7명으로 다시 추렸습니다(GitHub 데이터로 실제 확인). Phase 3.5 이중 검문 신설: 변경을 git stash(작업 중인 변경을 잠시 치워 두는 git 명령)로 임시 적용해 보고 harness-report 점수를 다시 재서, 점수가 오른 것만 남깁니다(keep).
287/287
Live Harvest · iter 10
실제로 모아 온 바깥 데이터

A. GitHub Trending (Python, weekly)

수집 시각: 2026-04-05 16:28(한국시간) · loopy-era와 관련성 높은 항목 3건

Repo+⭐설명
NousResearch/hermes-agent 9,566 "사용자 필요에 맞춰 진화하는 AI 에이전트(스스로 판단하며 일하는 AI)", loopy-era 철학과 정확히 일치
bytedance/deer-flow 6,900 오래 걸리는 작업을 처리하는 AI 프레임워크, 장기 실행 루프 패턴
mvanhorn/last30days-skill 4,741 레딧·X·유튜브의 트렌드를 조사하는 AI, trend-harvester와 목적이 비슷함

B. Simon Willison Blog (RSS)

"11월이 전환점이다 — AI 모델이 스스로 일하는 에이전트로 믿고 맡길 만큼 좋아졌다. 이제는 테스트(검증)가 새로운 병목이다. 코딩 AI를 잘 쓰려면 상당한 요령이 필요하다." — Simon Willison, Lenny's Podcast 정리 (2026-04-02)

→ "기계가 강제로 검증한다"는 loopy-era 철학과 정확히 일치
→ 11회차에 "분석은 AI가 필수"라고 못 박은 실제 근거

Applied Fixes
스스로 고친 3가지 (코드 변경 diff)
고침 1 · Phase 0 lockfile (+14줄)
실행이 겹치지 않게 막는 장치
+ # 동시 실행 방지 lockfile (race condition 차단)
+ LOCKFILE="$HARVEST_DIR/.lock"
+ if [ -f "$LOCKFILE" ]; then
+   LOCK_PID=$(cat "$LOCKFILE" 2>/dev/null || echo "0")
+   if kill -0 "$LOCK_PID" 2>/dev/null; then
+     echo "이미 실행 중 (PID=$LOCK_PID)"
+     exit 0
+   fi
+   rm -f "$LOCKFILE"  # stale lock 제거
+ fi
+ echo $$ > "$LOCKFILE"
+ trap 'rm -f "$LOCKFILE"' EXIT
고침 2 · 반영 함수 안전장치 (+5줄), 대상은 apply_change
기존 파일 덮어쓰기 방지
    new-skill|hook|agent)
-     # 새 파일 생성
+     # 새 파일 생성 — 기존 파일 덮어쓰기 방지
+     if [ -f "$file_path" ]; then
+       echo "already exists: $file_path (skip to avoid overwrite)" >&2
+       return 1
+     fi
      mkdir -p "$(dirname "$file_path")"
      printf "%s\n" "$content" > "$file_path"
      ;;
고침 3 · Phase 2 분석은 AI가 필수임을 명시 (+2줄)
단순 검색(grep)의 한계를 실험으로 확인해 반영
### Phase 2: 분석 (Analyze)

각 수집 항목에 대해 **loopy-era 정합성 점수**를 계산.
+**중요**: 이 Phase는 **LLM(Claude)의 의미 분석**으로 수행한다.
+grep/키워드 매칭만으로는 문맥·암시·의도를 포착할 수 없으므로
+실패한다 (검증 완료: 9/9 rejected).
iter 12 · Scope Expansion
모으는 대상을 전면 재설계 (사용자 피드백)
"수집하는 목적자체에 부합하는게 맞아? github.com/trending/python?since=weekly 이건 파이썬에 국한된거잖아? loopy-era 개선하는데 쓰이는 모든게 대상이야. 심지어 개념이나 스크립트만 있는 repo도 대상이고, 유명한 AI 구루 github repo도 수집대상으로 추가해줘" — 사용자 피드백, 2026-04-05

근본적인 결함: 기계가 자동 판정하는 하드 점검 286개를 다 통과했지만, "애초에 목적에 맞게 모으고 있는가"라는 질문은 점검표에 없었습니다. 파이썬만 모으다 보니, Claude Code 생태계의 TypeScript·Rust·Markdown 도구 소식의 30~40%를 놓쳤습니다.

Diagram 12 · 모으는 범위 확장 전후 비교
BEFORE (iter 11) GitHub Trending · Python only trending/python?since=weekly · 1개 언어 ~10 repos/week · topics: ai/llm/agent/rag AI 구루: 소셜 글만 (선언·의견) 구루 10명 · 가중치 6~10 awesome 리스트 3개 · 주제 검색 없음 코드 없는 프로젝트(개념·문서만)는 거부 소식 포착 범위 ~40% of whole ecosystem 놓친 소식 ✗ TypeScript MCP 도구 · Claude Code 플러그인 ✗ Rust로 만든 명령줄 · 추적 도구 ✗ Go 언어 데브옵스 자동화 프로젝트 ✗ Markdown만 있는 awesome-list · 프롬프트 모음 ✗ Karpathy의 nanoGPT · llm.c (교육용 프로젝트) iter 12 AFTER (iter 12) 모든 언어 + 언어별 6개 (총 7갈래) All · Python · TS · Rust · Go · MD · Shell ~70 repos/week · allow_no_code: true AI 구루: 소셜 글 + GitHub 계정 직접 훑기 구루 10명 · 올린 프로젝트 + 별표 (실제 활동) awesome 리스트 8개 + 주제 검색 5개 ai-agent · mcp · claude-code · self-improving 소식 포착 범위 ~95% of whole ecosystem 새로 잡은 소식 ✓ TypeScript MCP 도구 + Claude Code 플러그인 ✓ Rust/Go CLI (stars_delta > 100) ✓ awesome-claude-code · awesome-llm-apps ✓ concept-only markdown repo (allow_no_code) ✓ karpathy·simonw·anthropics가 방금 올린 것 실시간 반영 +44% SKILL.md · +5 languages · +10 guru GitHub · +3 awesome · +3 topic queries · 0 regressions
사용자 피드백으로 포착 범위를 약 40%에서 95%로 넓혔습니다. 스킬 정의 파일 +6,977바이트 · 성능 저하(회귀) 0건.
항목이전 (11회차)이후 (12회차)변화
SKILL.md 크기 (스킬의 절차와 설정을 적은 정의 파일)15,906 B22,883 B+44%
GitHub 인기 순위 소스27+5
지원 언어 (전체 + TypeScript·Python·Rust·Go·Markdown·Shell)1 (Python)6 (All+TS+Py+Rust+Go+MD+Shell)+5
AI 구루 GitHub 계정0 (소셜 글만)10+10
주제 검색 개수25+3
awesome 리스트(추천 목록)58+3
concept-only repo거부됨허용 (코드 없어도 됨)✓
주간 예상 수집량~10~80~1008~10×

새로 추가: AI 구루 GitHub 계정 10명

handle이름notable reposweightscan
karpathyAndrej KarpathynanoGPT · llm.c · minGPT · micrograd · cryptos10pushed + starred
anthropicsAnthropic (Official)anthropic-cookbook · claude-code · courses10pushed
simonwSimon Willisonllm · datasette · shot-scraper · files-to-prompt9pushed + starred
yoheinakajimaYohei Nakajimababyagi · babyagi-ui · instagraph8pushed
openaiOpenAI (Official)openai-cookbook · swarm · evals8pushed
cognition-aiCognition AI (Devin)—8pushed
sw-yxShawn Wang (swyx)—8pushed + starred
hwchase17Harrison Chase (LangChain)—7pushed
mshumerMatt Shumergpt-prompt-engineer · gpt-author · ai-researcher7pushed
jimfanJim FanEureka · Voyager7pushed
12회차 핵심 교훈
아무리 많은 자동 하드 점검(287개)으로 검증해도, 무엇을 왜 모을지는 사용자 의도와 맞춰야 한다. 이건 단순 검색으로는 확인할 수 없는 영역입니다. 사용자 피드백 → 설계 결함 인정 → 즉시 수정 → 성능 저하 0건. "근본을 묻는 질문"은 점검표에 저절로 생기지 않습니다.
iter 13 · Phase 5 Telegram Report
실행 리포트 자동 전송 📱

소식 수집이 끝나면 몇 개를 모으고 분석·반영했는지 통계를 텔레그램으로 자동 보냅니다(Phase 5). 사용자는 결과를 일부러 확인하지 않아도, 끝나는 순간 알림을 받습니다. 실제 전송까지 확인했습니다 (텔레그램 응답: message_id=6195).

Diagram 13 · Phase 5 텔레그램 알림(리포트) 만드는 흐름
raw/*.jsonl 오늘 수집 파일 analyzed/ + rejected/ 분석 결과 반영됨 (이번 실행) last-run.txt(지난 실행) 기준 BASELINE → NEW_SCORE harness-report delta START_TS 실행 시간 측정 메시지 조립 (Phase 5) • 소스별 수집 개수 합산 • 고득점/저득점 계산 • 반영한 종류 + 제목 뽑기 • 점수 변화 계산 (+/−) • 걸린 시간 정리 (분/초) 10줄짜리 텔레그램 메시지 🌾 [소식 수집] 완료 📥 수집: GitHub 47개, 구루GH 32개, 구루 소셜 8개, 뉴스 5개 (총 92개) 🔍 분석: 고득점 12개, 저득점 거부 80개 ✅ 자동 반영: 3개 - [rule] karpathy: Single-file... - [rule] simonw: CLI-first tooling - [scaffold-rule] anthropics:... ⏸️ 승인 대기: 2개 📊 harness-report: 72 → 75 (+3) ⏱️ 걸린 시간: 4분 32초 📅 완료: 2026-04-05 17:22:23 (message_id=6195, API "ok":true) 전송 실패 대비책 telegram-notify.sh 없음 → 콘솔+log 전송 실패 → telegram_send_failed 기록 알림이 실패해도 전체 작업은 멈추지 않고 계속 진행됩니다
입력 5가지 → 집계 → 10줄 텔레그램 메시지. 전송이 실패해도 괜찮은 대비책이 있습니다.
iter 14 · Dedup Index
이미 본 것을 기록해 중복 막기 🛡️

세 번째 사고 시나리오 차단: 반복 실행할 때 같은 프로젝트를 다시 모으고 분석·반영하면, 규칙 파일에 같은 내용이 계속 덧붙어 잡음이 쌓입니다. 그래서 출처와 주소를 해시(내용을 짧은 고유 번호로 바꾸는 함수)에 넣은 값 sha256(source|url) 로 만든 고유 번호를 '이미 본 것' 목록 파일에 기록해, 세 겹으로 막는 구조를 만들었습니다.

Diagram 14 · 중복을 세 겹으로 막는 구조
수집 항목 source + url → compute_id() Layer 1 · Phase 1 Collection is_seen(id)? .seen.json → applied/rejected: SKIP → 분석 중이면: 건너뛰기 → times_seen ≥ 4: SKIP (💀) → 새 항목: mark_seen() + raw/ 저장 Layer 2 · Phase 4 Policy status == "applied"? → YES: return 1 (SKIP) → NO: is_auto_applicable() score≥7 + risk=low + type∈{rule, sr} Layer 3 · apply_change content_hash 이미 있나? → is_rule_applied(hash): SKIP → 파일에 이미 있으면: 건너뛰기 → 통과: 덧붙이기 실행 → mark_applied(id,hash) '이미 본 것' 기록 파일 예시 { "d5975f2293e19d5e": { "source": "github", "url": "https://github.com/karpathy/nanoGPT", "first_seen": "...", "last_seen": "...", "times_seen": 2, "status": "applied", "final_score": 8, "applied_rule_hash": "3f9a2b...", "applied_at": "..." } }
세 겹 필터: 수집 단계(Phase 1) → 반영 정책(Phase 4) → 내용 대조. 반복 실행으로 생기는 잡음을 완전히 막습니다. 내용 대조는 반영 함수가 내용 해시로 합니다: apply_change(content_hash)
iter 15 · Guru Matrix + Phase 3.5
구루 선정 기준 + autoresearch 실측 판정 ⭐
"구분을 해야해 handle 가 직접적으로 컨텐츠를 주기적으로 생산하는지, 신규 repo를 지속적으로 생산하는지? 선정근거에 있어야해. loopy-era-trend-harvester의 3단계 적용 판정 프로세스에 autoresearch 스킬로 판단하는 프로세스도 추가해야해" — 사용자 피드백, 2026-04-05

15.1 구루 활동 유형 3축 분류 (activity_type)

Diagram 15 · 구루 활동 유형 3축 분류표 (activity_type)
content_production (X/blog) repo_production (GitHub) LOW HIGH HIGH HIGH 1: 프로젝트만 활발 2: 둘 다 활발 → GitHub 수집 ✓ 3: 둘 다 저조 → 제거 4: 글만 활발 → 소셜·블로그만 수집 karp w=10 simonw w=9 anthro w=10 mshumer 799⭐ hwchase17 130⭐ openai w=8 yohei babyagi3 jimfan → X only sw-yx → blog only cognition ✗ 제거 10명 → GitHub 수집 7명 유지 + 소셜·블로그로 2명 전환 + 1명 제거 GitHub 데이터로 실제 확인: cognition-ai는 공개 프로젝트 없음 · jimfan·sw-yx는 프로젝트 비어 있음 guru_github (pushed + starred) gurus(X/blog) only 완전 제거
두 축으로 분류합니다. 프로젝트(repo) 활동 × 글 활동. GitHub 데이터를 실제로 확인해 10명에서 7명으로 다시 추렸습니다.

15.2 구루 선정 4가지 필수 기준

#기준측정 방법
C1loopy-era와 맞는가에이전트·루프·자동화 관련 결과물이 있는가
C2활동성최근 90일 동안 코드를 3번 이상 올림(push)
C3활동 폭공개 프로젝트(repo) 10개 이상
C4주 활동 창구 구분뉴스 피드·소셜·GitHub 중 주 활동 창구를 한 곳만 대표로

15.3 Phase 3.5 autoresearch 판정, 검문을 두 겹으로

기존 3단계 판정에 실제로 점수를 재서 남길지 버릴지(keep/discard) 정하는 단계를 더해 4단계로 늘렸습니다. AI의 주관 점수(소프트 판정)에, 실제 점수로 딱 잘라 판정하는 autoresearch 원칙(하드 판정)을 결합한 것입니다.

Diagram 16 · Phase 3.5 autoresearch 판정 실험 흐름 (autoresearch_judge())
proposal analyzed/*.json score + risk + type ① git stash 임시 보관 작업 내용 잠시 치움 ② apply_fn() 실제 파일 수정 시도 (indirect call) ③ harness-report 현재 점수 다시 측정 PREV = BASELINE ④ JUDGE CURR > PREV? 점수 오르면 채택 ⑤ REVERT git checkout -- git stash pop keep → Phase 4 discard → rejected/ crash trial-{id}.verdict = "crash" 실험 결과 기록 파일 {commit}\t harness_score \t{CURR}\t{verdict}\t trial:{id} always revert YES NO exception
5단계 실험: 잠시 치우기(stash) → 임시 적용 → 점수 측정 → 판정 → 원상복구. 적용은 임시일 뿐, 판정 후 되돌립니다.

15.4 검문을 두 겹으로 만든 효과

항목14회차 (검문 한 겹)15회차 (검문 두 겹)
판정 근거Claude 주관 점수만주관 점수 + 실제 측정 점수
강제력약함 (AI 주관 판단)약함 + 기계 강제 (자동 판정)
통과 조건score ≥ 7score ≥ 7 그리고 실제 점수 개선
autoresearch 원칙미반영"좋아지면 남기고, 그대로거나 나빠지면 버림"
Disasters Prevented
미리 막은 대형 사고 3건
Diagram 11 · 안전장치 추가 전후 효과
시나리오 A · 스킬 덮어쓰기 BEFORE 새 스킬 만들라는 제안이 들어옴 file_path: user-proxy-agent 기존 파일을 통째로 덮어씀 💥 200KB짜리 스킬 파괴 Fix 2 AFTER [ -f $file_path ]? → YES → return 1 건너뛰기 메시지 출력 ✓ 100% 차단 시나리오 B · 동시 실행 중복 BEFORE 자동 실행 + 사람이 직접 호출 두 실행이 동시에 WebFetch 같은 파일에 중복 저장 → 충돌 💥 저장 커밋 실패 Fix 1 AFTER 잠금 파일 확인 이미 돌면 두 번째 실행은 그냥 종료 끝나면 잠금 자동 해제 ✓ 100% 차단 사고 차단 효과 이 영역은 git으로 관리되지 않아 → 되돌릴 수 없음 user-proxy-agent는 검증 자동화의 핵심 (모든 작업이 의존) → 안전장치 2개로 이 재앙을 영구 차단 5개 기준 개선 점수 (고침 1+2) 자동화 +2 마찰 제거 +4 기계 판정 +4 낭비 절감 0 측정 가능 +2 총 +12/20 (60% 개선)
user-proxy-agent(사용자 대신 결과를 검증하는 핵심 에이전트)가 되돌릴 수 없게 파괴되는 사고를, 고침 2개로 영구히 막았습니다.
시나리오 A · 스킬 덮어쓰기 재앙
trend-harvester가 기존 핵심 스킬을 날려버릴 뻔한 상황
  1. trend-harvester가 hermes-agent 프로젝트를 분석함
  2. change_type="new-skill", file_path="~/.claude/skills/user-proxy-agent/SKILL.md" (우연히 이름이 겹침)
  3. 안전장치가 없으면: printf > file_path → user-proxy-agent 스킬이 통째로 파괴됨
  4. user-proxy-agent는 사용자 대신 결과를 검증하는 에이전트로, 검증 자동화의 핵심입니다 (모든 작업이 의존)
  5. 되돌릴 수 없음 (이 영역은 git으로 관리 안 됨)
→ 고침 2로 100% 차단 · [ -f ] 로 이미 있으면 건너뛰고 다음 제안으로
시나리오 B · 동시 수집 중복
자동 실행과 사람이 직접 부른 실행이 충돌
  1. /loop 6h /loopy-era-trend-harvester 가 뒤에서 돌고 있음
  2. 사용자가 Claude 세션(대화창)에서 /loopy-era-trend-harvester 를 직접 호출
  3. 두 실행이 동시에 WebFetch로 긁어, 같은 프로젝트를 두 번 raw/ 에 저장
  4. analyzed/에 같은 내용 중복 → 저장 커밋 충돌
→ 고침 1로 100% 차단 · lockfile + 끝나면 자동 해제
시나리오 C · 반복 실행 중복 (14회차)
반복 실행할 때 같은 규칙이 또 추가됨
  1. 1주차: karpathy/nanoGPT 수집 → 분석 → 규칙 반영 ✓
  2. 2주차: 같은 nanoGPT 다시 수집 → AI가 또 점수 매김 → 규칙 파일에 또 덧붙음
  3. 4주차: 같은 내용이 규칙 파일에 4번 중복 → 잡음 누적
  4. 새 소식이 기존 항목에 묻혀 눈에 잘 안 띔
→ 14회차 .seen.json 세 겹 방어로 100% 차단 · 고유 번호(id)로 건너뛰기 + 내용 해시(content hash) 대조 + graveyard(보관소)로 치우기
Quantitative Impact
개선 효과 측정 (7~12회차 누적)
지표6회차11회차12회차15회차총 변화
SKILL.md 크기 (스킬 정의 파일)15,475 B15,906 B22,883 B36,743 B+137%
검증 점검 항목 수106287287287+181 (2.7×)
성능 저하(회귀) 건수-0000
막은 대형 사고0223+3
새 테스트 파일4777+3
수집 언어 범위1166+5
AI 구루 GitHub 계정00107 ✓기준으로 선별
GitHub 인기 순위 소스1277+6
반영 판정 관문1112 ⭐두 겹 검문
텔레그램 자동 알림✗✗✗✓13회차
중복 방어 겹수000314회차
Next Loop Candidates
아직 남은 개선점 (다음 차례 후보)
우선순위개선안예상 점수작업량
🔴 높음분석 단계(Phase 2) 채점 지시문(프롬프트) 표준화7/10중
🔴 높음file_path에 {id}-{sha256:8} 접미사 자동 부여 (이름 충돌 원천 차단)7/10소
🟡 중간텔레그램 승인 답장 자동 처리 (지금은 사람이 직접)8/10대
🟡 중간WebFetch 실패 시 간격을 늘려가며(지수 백오프) 재시도5/10소
🟢 낮음applied/ 오래된 것 자동 정리 (90일 넘으면 보관)5/10중
🟢 낮음harness-report 도구가 없으면 임시 대체본 자동 생성4/10소
Verdict
결론
전체 종합 평가 (7~15회차)
trend-harvester는 loopy-era(스스로 개선하는 시스템)에서 바깥 소식을 받아들이는 감각기관입니다. 바깥 트렌드를 5가지 기준 필터와 autoresearch 실측 이중 검문으로 걸러 시스템에 자동 반영합니다. /loop 6h로 하루 4회 자동 실행되며, 점검 287개 전부 통과·성능 저하 0건·대형 사고 3건 차단·실제 텔레그램 전송 확인을 달성했습니다. 12~15회차에 사용자 피드백 3건을 받아들여 (1) 수집 범위를 파이썬에서 6개 언어로 확장, (2) 완료 텔레그램 알림, (3) 이미 본 것 3겹 중복 제거, (4) Phase 3.5 autoresearch 판정으로 진화했습니다.

loopy-era 철학에 얼마나 부합하나: 바깥 트렌드 수집 → 실제 실행 → 실패 경험 축적 → 스킬 자체 개선 → 사용자 피드백으로 근본 결함 발견 → 구조적 진화. 다섯 단계 되먹임 순환의 살아있는 사례입니다. 스킬 정의 파일이 15.5KB에서 36.7KB로(+137%) 커졌고, 구루 선정도 "이름값"에서 GitHub 데이터 실측 기반으로 바뀌었습니다. 판정 근거도 AI 주관에서 주관+실측의 두 겹 검문으로 강화됐습니다.