지난 글에서 API 키를 동기화 대상에서 뺀 AI Wiki를 봤다. 세 번째는 겉보기엔 제일 초라한 지표(4스타)인데, 소스를 열어보고 나서 완전히 다른 인상을 받은 AI RAG + LLM Wiki(yep49)다.
서비스 파일이 30개 — RerankService, FusionService, FeedbackTuningService
main.ts 자체는 1463줄짜리 단일 클래스라 얼핏 모놀리식처럼
보였는데, src/services/ 폴더를 열어보니 실제 로직은 30개 가까운
서비스 파일로 잘게 나뉘어 있었다. RerankService(검색 결과
재정렬), FusionService(여러 검색 결과를 합치는 하이브리드 검색),
FeedbackTuningService/FeedbackRecallService(사용자 피드백으로
검색 품질을 조정), SensitivityService, ContextCompressionService,
QueryAnalysisService까지 — 이 여섯 개 플러그인 중 RAG 파이프라인을
가장 정교하게 짜놓은 쪽이었다. views/ 폴더에도 TuningProposalModal,
CorrectionModal처럼 사용자가 검색 품질을 직접 조정할 수 있는
UI까지 갖춰져 있었다.
그런데 하루 만에 만들어지고 버려졌다 — GitHub created_at·pushed_at 하루 차이
이 정교함에 놀라서 GitHub 지표를 확인했는데, 진짜 발견은 여기
있었다. created_at이 4월 24일, pushed_at이 4월 25일 — 생성일과
마지막 커밋일이 하루 차이였다. 스타는 4개, 포크는 0개. 즉 이
서비스 30개짜리 설계는 하루짜리 몰입 작업의 결과물이었고, 그 이후
한 번도 다시 손대지 않은 채 남아 있었다.
설계의 정교함과 완성도는 다른 축이었다 — 스타 수·커밋 이력으로 구분
이게 이번 조사에서 제일 인상 깊었던 지점이다. 아키텍처 파일 개수나 기능 목록만 보고 “이 프로젝트가 제일 잘 만들어졌다”고 판단했으면 완전히 틀렸을 거다. 실제로 얼마나 다듬어졌는지, 실사용 버그가 잡혔는지, 유지보수되고 있는지는 커밋 이력을 봐야만 알 수 있었다. 반대로 obsidian-llm-wiki(1편)는 지표는 훨씬 크지만 코드 구조는 더 단순했고, AI Wiki(2편)는 스타가 4개뿐이어도 9월 2일까지 계속 커밋되고 있었다 — 설계 규모, 스타 수, 실제 관리 상태가 셋 다 서로 다른 신호였다.
배운 점
“서비스 파일이 몇 개나 되는가”는 이 프로젝트가 진지한지를 보여주는
증거가 아니었다 — 하루 만에도 서비스 30개짜리 뼈대는 만들 수
있다. 진짜 신호는 그 뒤로 얼마나 오래, 얼마나 자주 다시 손댔는지였다.
지금 다른 플러그인을 참고할 때도, 코드 규모나 기능 목록보다
pushed_at과 created_at 사이의 간격, 그리고 이슈 트래커의 실제
활동을 먼저 보는 게 더 정직한 판단 기준이라는 걸 다시 확인했다.