mizchi 님의 sprawlens가 궁금해서 11만 LOC 규모의 리포지토리를 건강검진해 보았다

mizchi 님이 sprawlens라는 도구를 공개했다. Git 이력에서 커밋별 import 그래프를 스냅샷으로 수집하여, 코드베이스의 「구조적 성장」을 관측하는 도구라고 한다.

눈길을 끈 것은 AI 관여 커밋을 마킹하는 기능이 처음부터 들어있었다는 점이다. 「AI에게 코드를 쓰게 하면서 리포지토리가 어떻게 비대해지는가」를 측정하려는 도구로 보였다. 나 자신도 일상적으로 Claude Code에게 코드를 쓰게 하고 있으므로, 이는 남의 일이 아니다.

궁금해져서 내가 개인 개발 중인 앱(약 11만 LOC / 1,495 커밋)에 실제로 실행해 보았다. 해보니 상상 이상으로 재미있었고, 조사해 보니 그 이면에 반세기 분량의 연구 축적이 있다는 것도 알게 되어 정리해 본다.

sprawlens란 무엇인가

정식 명칭은 CodeSprawl Lens. TypeScript/JavaScript의 import 그래프를 커밋마다 수집하고, 구조 메트릭스(structural metrics)와 차분을 계산하여 타임라인, 트리맵, 의존 차분, 핫스팟을 Web UI로 보여준다.

mizchi 님의 설계에서 특히 좋다고 생각한 점이 3가지 있다.

git worktree 기반으로 이력을 수집하므로, 작업 트리를 checkout으로 더럽히지 않는다 -
AI 관여 커밋의 휴리스틱(heuristic)한 마킹이 내장되어 있다 -
출력이 순수 JSON/CSV이므로, UI를 사용하지 않고 자체 스크립트나 CI에서도 다룰 수 있다

데모에서는 sprawlens 자신의 코드베이스를 볼 수 있다.

해보니: 1개월 분량·50개 커밋을 건강검진하다

최근 50개 커밋(2026-05-04~06-03)을 collect / analyze 하여, metrics.csv를 집계했다.

지표	5/4	6/3	변화
LOC	106,481	109,878	+3,397 (+3.2%)
...

보충: import 에지(edge) 수는 파일 간 import의 총 개수. 에지 밀도(edge density)는 파일당 평균 import 개수. 최대 연결 성분(maximum connected component)은 특정 파일에서 추적할 수 있는 최대 파일 그룹의 크기(전체 파일 수에 가까워질수록 일체화되는 신호). AI 관여 커밋 판정은 「Co-authored-by」, 「🤖」 등의 커밋 메시지 패턴으로부터 휴리스틱하게 추정한 수.

커밋의 70%가 AI 관여로 판정된 가운데, LOC가 3.2% 증가했음에도 구조 지표는 모두 보합세였다. 어디까지나 1개 리포지토리·1개월의 관측이지만, 일단 안심할 수 있는 자료가 되었다.

양방향 허브의 특정

「팬인(fan-in)」이란 얼마나 많은 파일로부터 의존되고 있는지를 나타내는 수이다. 상위 항목은 다음과 같았다.

fan-in	파일
66	`api/index.ts` (엔트리 포인트)
64	`api/env.ts` (환경 변수)
63	`api/tests/helpers/mock.ts` (테스트 헬퍼)
32	`api/types.ts` (공유 타입 정의)

엔트리 포인트는 의존하는 수(fan-out)도 45로 최대였다. 의존되는 쪽과 의존하는 쪽 양쪽에서 톱인 「양방향 허브」였다. Hono 앱의 전형적인 구조이기에 「중요한 파일이겠지」라고 생각은 했지만, fan-in 66이라는 숫자를 통해 영향 범위가 리포지토리 내에서 최대라는 것을 처음으로 확정할 수 있었다. 체감을 숫자로 변환할 수 있었던 것이 sprawlens의 수확이었다.

어떻게 읽는가 — 정상과 이상 사이의 경계

「순환(cyclomatic complexity 등 관련 지표) 1이 많은 건가 적은 건가?」라며 처음에는 당황했다. 결론부터 말하자면, 이러한 지표에 보편적인 「정상치」는 없다. 의미를 갖는 것은 트렌드이며, 봐야 할 것은 「코드의 증가율에 대해 구조적 복잡도가 어떻게 움직였는가」이다.

정상: 코드는 늘어나지만, 에지 밀도·순환 수·최대 연결 성분은 보합세 -
이상: 코드의 증가율을 구조 지표의 증가율이 상회함. 쓰면 쓸수록 얽혀가는 상태

이번 진단 결과는 「모든 지표 보합세 = 건전」, 주의 관찰 대상은 3개의 허브 파일, 가벼운 숙제는 i18n의 순환, 이라고 읽을 수 있다.

조사해 보니 50년의 역사가 있었다

실측 결과가 나온 시점에서, 「애초에 이 측정 방식은 누가 생각한 걸까」 궁금해져서 조사해 보았다. 그랬더니 소프트웨어 메트릭스(software metrics)라는 확립된 연구 분야의 계보에 깔끔하게 올라타 있다는 것을 알게 되었다.

1970년대에 Lehman은 "진화하는 시스템은 조치를 취하지 않는 한 복잡성이 단조 증가한다"라는 법칙을 제창했다. 즉, 앞서 언급한 "횡보(横ばい)"는 자연 상태가 아니라, 리팩터링 (refactoring)이라는 역방향의 작업이 수행되고 있다는 증거로 읽을 수 있다. 자신의 리포지토리가 AI 관여도가 70%임에도 횡보를 유지할 수 있었던 것은, 리뷰를 통해 구조를 계속해서 지켜온 효과라고 해석하고 있다.

그 후 1990~2000년대에 걸쳐, 팬인/팬아웃 (fan-in/fan-out)에 의한 결합도 정식화, Git 이력으로부터 품질을 예측하는 연구 분야 (MSR: Mining Software Repositories), "복잡도 × 변경 빈도"로 리뷰 자원을 집중시키는 핫스팟 (hotspot) 분석 등으로 쌓여왔다.

즉, 이론은 반세기에 걸쳐 축적되어 왔으며, mizchi 님이 sprawlens를 통해 가져온 새로움은 도구의 기술 그 자체가 아니라, "AI 관여 커밋을 구분하여 관측한다"라는 질문 그 자체였다.

앞으로 AI를 사용하는 데 있어 유용할 것 같은 이유

나의 관측에서는 "AI가 작성해도 구조는 유지되었다"라는 결과가 나왔다. 그렇다면 이것은 개인적인 행운인가, 아니면 보편적으로 말할 수 있는 사실인가. 마침 그 질문을 생각하게 만드는 데이터가 있다.

GitClear의 조사에 따르면, AI 어시스턴트 보급 이후 복사하여 붙여넣기(copy-paste)된 코드의 비율이 2021년 8.3%에서 2024년 12.3%로 증가했으며, 리팩터링 (refactoring) 비율은 약 24%에서 10% 미만으로 떨어졌다. 반면 DORA (DevOps Research and Assessment, 개발 생산성에 관한 대규모 연례 조사)에서는 응답자의 59%가 "AI로 품질이 향상되었다"라고 답했다. 객관적 메트릭스 (objective metrics)와 주관의 괴리가 발생하고 있는 것이다.

이 괴리의 원인은 diff 리뷰의 사각지대에 있다. diff 리뷰가 검증할 수 있는 것은 "이 변경이 국소적으로 올바른가"까지다. 중복 코드가 여러 곳에 생겨나거나, 의존성 방향이 무너지거나, 허브 (hub)가 비대해지는 것과 같은 대역적인 열화는 작성자 본인의 체감으로도, diff로도 포착할 수 없다. AI의 생성 속도가 빨라질수록 이 사각지대는 넓어진다.

따라서 주관도 아니고 diff도 아닌 제3의 계기가 필요하다. sprawlens는 그 하나의 해답이라고 생각한다.

요약

mizchi 님의 sprawlens는 커밋마다의 import 그래프 스냅샷을 통해 "코드의 크기와 얽힘 정도를 시간축과 함께 찍는 카메라"였다.
11만 LOC 규모의 리포지토리에서 실측한 결과, AI 관여 커밋이 70%임에도 구조 지표는 횡보했다. "횡보"는 자연 상태가 아니라, 리뷰를 통해 구조를 지키는 작업이 기능하고 있다는 증거로 읽을 수 있다.
그 이면에는 반세기 분량의 연구 축적이 있다. 새로운 점은 "AI 관여 커밋을 구분하여 관측한다"라는 질문이다.
AI로 개발 속도가 빨라질수록, diff 리뷰와는 별개로 구조를 관측하는 계기가 표준 장비가 되어갈 것이라는 느낌이 든다.

공개된 지 얼마 되지 않은 도구라 API와 UI도 아직 변해가는 중이겠지만, 발상 자체를 보유할 가치가 있다고 생각한다.