아프니까 개발자다 아프니까 개발자다

코드 위키가 코드베이스의 변화를 추적하기 위해 첫 번째로 해야 하는 일은 코드를 파싱하는 것이다. 어떤 파일에 어떤 함수가 정의되어 있는지, 어떤 모듈이 임포트되었는지를 알아야 위키의 뼈대를 세울 수 있다. 하지만 수십 개의 저장소, 수만 줄의 소스코드를 매일 밤 분석해야 할 때, 전통적인 파싱 방법론은 커다란 장벽에 부딪힌다.단순 정규식(Regex)으로 `def func_name`을 매칭하는 방식은 주석 안의 텍스트나 멀티라인 정의를 처리하지 못해 쉽게 깨진다. 그렇다고 소스 언어별 온전한 컴파일러 툴체인을 띄우는 것은 무겁고 느리며, 다언어 환경으로 확장할 때 복잡도가 폭발한다. deep-wiki Stage A는 이 모순을 해결하기 위해 tree-sitter를 도입했다.1. 왜 tree-sitter인..

22개 repo의 위키를 만들어 놓고 봤더니 한 가지가 마음에 안 들었다. "단촐하다." 내용이 풍부한 Rich 그룹 5개 repo만 8개 섹션 표준에 가까웠고, 거의 빈 Bare 그룹 4개 repo는 dependencies.md 한 페이지뿐이다. 같은 도구로 인덱싱했는데 격차가 너무 컸다. DeepWiki.com(Cognition)·Google CodeWiki는 한 repo당 평균 8개 섹션(Overview / Structure / Architecture / API / Subsystems / Operations / Testing / Glossary) + 페이지당 mermaid 3-5개를 floor로 두는데, 우리는 한참 부족했다.해결책은 단순해 보였다 — "자동 생성 페이지 종류를 늘리자." 그런데 어..