코드베이스가 지식 그래프가 됐을 때
— understanding-anything 써본 후기
"이 함수 어디서 호출돼?" — Claude한테 매번 물어볼 때마다 컨텍스트 예산이 줄어들죠. understanding-anything은 그 질문을 Claude 없이 답하는 구조를 만들어줘요. GitHub에서 별 4만 개 받은 플러그인을 제가 베타로 운영 중인 서비스에 직접 돌려보고, 뭐가 보였는지 솔직하게 적어요.
01이 도구가 뭘 하나
반복되는 상황이 있어요. 오래된 레포를 다시 잡거나, 대규모 리팩토링 앞에 서거나, 새 기능이 기존 구조 어디에 붙어야 하는지 파악해야 할 때. 그때마다 Claude 컨텍스트가 실질적인 작업보다 구조 파악에 먼저 소모되는 거예요. 파일이 많을수록, 세션이 끊길수록 이 비용이 쌓여요.
understanding-anything은 그 방향을 바꿔요. 코드를 매번 Claude한테 읽히는 대신, 코드베이스 전체를 한 번 "지도"로 만들어둬요. 어떤 파일이 어떤 파일을 쓰는지, 무엇이 중심인지가 그림 한 장에 담겨요.
핵심은 컨텍스트 절약이에요. "이거 어디서 쓰여?"를 물을 때마다 토큰이 나가는데, 지도가 한 번 생기면 그 질문들을 지도가 대신 답해줘요. Claude를 "코드를 매번 다시 읽는 사람"에서 "구조를 이미 아는 사람"으로 바꿔주는 셈이에요.
✱왜 4만 별이 붙었나
You just joined a new team.
The codebase is 200,000 lines.
Where do you even start?
— README 첫 문장 (Lum1104)
이 세 줄이 ★ 4만의 핵심이에요. 기술 설명도, 기능 나열도 아니에요. "당신도 이 상황 알죠?"라는 질문이에요. 인수인계 받은 첫날, 외주 레포 처음 연 날, 6개월 만에 내 코드 다시 잡은 날 — 모두가 겪는 고통인데 마땅한 도구가 없었어요.
포크 수가 포인트예요. 별은 "나중에 보자"지만, 포크는 "나도 이 구조 뜯어볼래"예요. 3,616명이 설치만 한 게 아니라 실제로 구조를 분해하고 있어요. "유행"이 아니라 실수요라는 신호예요.
02직접 써봤어요
제가 베타로 운영 중인 서비스에 돌려봤어요. 핵심 흐름이 여러 단계를 거치며 여러 파일에 흩어져 있는 앱이에요. 설치는 Claude Code 플러그인이라 두 줄이면 끝이고, 분석 명령 한 번이면 그래프가 만들어져요. 결과부터 말하면 — 처음 보는 사람한테 설명할 때 제일 쓸 만했어요.
스캔하고 나니 그 흐름이 어느 파일에서 시작해 어디로 이어지는지가 한 화면에 잡혔어요. 평소엔 머릿속에만 있던 그림인데, 밖으로 꺼내놓으니 "아, 여기가 허리구나" 하는 파일이 보였어요. 그 파일 하나가 흐름의 절반을 쥐고 있었는데, 코드를 위에서 아래로 읽을 땐 그게 안 보였거든요.
돌리면 이런 그림이 나와요. 동그라미가 파일, 선은 "이 파일이 저 파일을 쓴다"는 연결이에요. 큰 동그라미일수록 많이 쓰이는 중요한 파일이고요.
한 동그라미가 유독 크게 보이죠. 여러 파일이 공통으로 기대는 "허브"예요. 이게 드러나는 순간 "이 파일을 건드리면 어디까지 영향받는지"가 한눈에 보여요. 코드만 위에서 아래로 읽을 땐 안 보이던 그림이에요.
동그라미를 클릭하면 그 파일이 뭐 하는 파일인지 한 줄 요약도 나와요. "이거 뭐야?"를 파일마다 Claude한테 안 물어봐도 되는 거죠. 신입이나 외주한테 이 그림 한 장 주면, 말로 30분 할 설명이 끝나요. 반대로 제가 매일 만지는 코드에선 새로 배운 건 없었어요 — 이 그림은 "내가 모르는 코드"에서 빛나요.
여기선 "이게 뭐고, 왜 좋고, 언제 쓸 만한지"까지만 가볍게 다뤄요. 이 그림을 실제 작업에서 어떻게 읽고 활용하는지, 도구가 안에서 어떻게 동작하는지 같은 깊은 기술 분석은 따로 정리하고 있어요.
03이럴때 쓰세요
4가지 상황별로 어떻게 써야 하는지, 비즈니스적으로 뭐가 이득인지 정리했어요.
레포 받아놓고 파일 트리만 멍하니 봤던 그날. 인수인계·외주 코드·팀 합류 첫날이 다 이 상황이에요. 한 번 돌려두면 전체 구조가 한눈에 들어와서 "어디부터 봐야 하지"가 사라져요.
공유하는 파일 하나 고쳤는데 엉뚱한 화면에서 버그 났던 경험, 있으시죠. 그림으로 보면 그 파일이 어떤 화면들과 이어져 있는지 미리 보여서, 손대기 전에 영향 범위를 가늠할 수 있어요.
신입 한 명 들어올 때마다 시니어가 두 시간씩 설명하던 그 비용. 문서는 코드가 바뀌면 금방 낡지만, 이 그림은 코드를 따라가요. 넘겨주면 알아서 구조를 파악해요.
6개월 만에 내 프로젝트를 열면 나도, Claude도 처음부터 다시 파악해야 해요. 그림을 한 번 만들어두면 다시 잡을 때 기억 복구가 훨씬 빨라요.
04솔직한 한계
- 작은 프로젝트(파일 50개 이하)엔 굳이. 그 정도면 Claude한테 통째로 읽히는 게 더 빨라요.
- 자주 바뀌는 코드는 다시 돌려야 해요. 그림은 만든 시점 기준이라, 구조가 크게 바뀌면 갱신이 필요해요.
- 결국 보는 건 사람이에요. 그림은 질문을 줄여줄 뿐, 판단을 대신하진 않아요.
- Claude Code를 써야 의미가 있어요. 안 쓰면 효과가 거의 없어요.
05결론
파일 100개 넘는 레포 + Claude Code 쓰는 사람이라면, 한 번 돌려볼 가치 있어요.
✅ 써보세요: 파일 100개 이상 레포, Claude Code 매일 씀, 오래된 프로젝트 복귀가 잦음, 신입 온보딩이 반복됨.
⏸️ 지금은 아닐 수도: 소규모 사이드 프로젝트(50파일 이하), Claude가 전체 읽어도 충분한 규모.
제가 테스트한 서비스도 사실 그래프가 꼭 필요한 큰 규모는 아니에요. 그런데 써보고 나서 한 가지가 달라졌어요 — 한 모듈이 생각보다 훨씬 많은 파일에서 쓰이고 있다는 걸, 돌려보고 나서야 알았어요. 이런 "몰랐는데 보이는 것"이 이 도구의 진짜 가치인 것 같아요.
100파일이 넘는 레거시 레포를 다시 잡아야 하는 상황을 상상해봐요. Claude한테 "이 함수 어디서 쓰여?" 라고 물을 때마다 컨텍스트를 소모하는 대신, 그래프를 한 번 만들어두면 구조 파악 비용이 대폭 줄어요. 코드를 이미 다 안다고 생각할 때도, 그래프는 다른 걸 보여줄 수 있어요.
매주 메일로 받아보세요
✦ 바로 복붙할 수 있는 설정 템플릿 팩(CLAUDE.md 스니펫·치트시트)은 준비 중이에요 — 구독하면 나오는 대로 가장 먼저 알려드려요.