오래된 레포(저장소)를 다시 잡거나, 대규모 리팩토링 앞에 서거나, 새 기능이 기존 구조 어디에 붙어야 하는지 파악해야 하는 순간이 반복해서 옵니다. 그때마다 Claude 컨텍스트(대화가 기억하는 범위)가 실질적인 작업보다 구조 파악에 먼저 소모됩니다. 파일이 많을수록, 세션이 끊길수록 이 비용이 쌓입니다.
Understand-Anything은 그 방향을 바꿉니다. 코드를 매번 Claude한테 읽히는 대신, 코드베이스 전체를 한 번 '지도'로 만들어 둡니다. 어떤 파일이 어떤 파일을 쓰는지, 무엇이 중심인지가 그림 한 장에 담깁니다.
제가 직접 써 보고 확인한 효용은 하나입니다. 파일 사이의 연결이 그림으로 보이고, 그 그림이 남에게 구조를 설명할 때 쓸 만했다는 점입니다. 컨텍스트 절약은 기대하는 효과로만 적어 둡니다. “이거 어디서 쓰여?”를 물을 때마다 토큰(Claude가 글을 읽고 쓰는 단위 비용)이 나가는데, 그래프를 파일로 만들어 두면 Claude가 코드를 다시 훑는 대신 그 파일을 참고할 수 있다는 설명입니다. 다만 실제로 얼마나 아꼈는지는 따로 재보지 않았고, 처음 스캔할 때 드는 비용도 이 글에서는 다루지 않았습니다.
Lum1104 / Understand-Anything이라는 이름의 Claude Code 플러그인이고, 코드베이스를 인터랙티브 지식 그래프와 질의응답으로 바꿔 줍니다. 이 글을 쓸 당시 별이 49,000개를 넘었습니다. 아래 지표는 그보다 앞서 확인한 시점(2026-05-30) 기준입니다.
“당신도 이 상황 알죠?”라는 질문 하나가 별을 모았습니다
README는 이렇게 시작합니다. “You just joined a new team. The codebase is 200,000 lines. Where do you even start?” — README 첫 문장(Lum1104)입니다.
이 세 줄이 별을 4만 개 넘게 모은 핵심이라고 봤습니다. 기술 설명도, 기능 나열도 아닙니다. “당신도 이 상황 알죠?”라는 질문입니다. 인수인계 받은 첫날, 외주 레포 처음 연 날, 6개월 만에 내 코드 다시 잡은 날. 모두가 겪는 고통인데 마땅한 도구가 없었습니다.
별보다 포크 수를 더 믿을 만한 신호로 봤습니다
포크(저장소를 자기 계정으로 복사해 가져가는 것) 수가 포인트였습니다. 별은 '나중에 보자'는 뜻이지만, 포크는 '나도 이 구조 뜯어볼래'는 뜻입니다. 포크했다고 다 구조를 다 이해했다는 뜻은 아니지만, 3,616명이 설치만 하고 끝내지는 않았다는 신호로는 읽었습니다. '유행'이 아니라 '실수요'라는 신호로 읽었습니다.
베타로 운영 중인 제 서비스에 직접 돌려 봤습니다
제가 베타로 운영 중인 서비스에 돌려봤습니다. 핵심 흐름이 여러 단계를 거치며 여러 파일에 흩어져 있는 앱입니다. 설치는 Claude Code 플러그인이라 두 줄이면 끝이고, 분석 명령 한 번이면 그래프가 만들어집니다. 정확한 설치 명령과 분석 명령은 참고 자료에 걸어둔 저장소 README에 있습니다. 결과부터 말하면, 처음 보는 사람에게 설명할 때 제일 쓸 만했습니다.
스캔하고 나니 그 흐름이 어느 파일에서 시작해 어디로 이어지는지가 한 화면에 잡혔습니다. 평소엔 머릿속에만 있던 그림인데, 밖으로 꺼내놓으니 “아, 여기가 허리구나” 하는 파일이 보였습니다.
코드를 위에서 아래로 읽을 땐 안 보이던 허브가 그래프에서 드러났습니다
그 파일 하나가 흐름의 절반을 쥐고 있었는데, 코드를 위에서 아래로 읽을 땐 그게 안 보였습니다. 돌리면 이런 그림이 나옵니다. 동그라미가 파일, 선은 “이 파일이 저 파일을 쓴다”는 연결입니다. 큰 동그라미일수록 많이 쓰이는 중요한 파일입니다.
이게 드러나는 순간 “이 파일을 건드리면 어디까지 영향받는지”가 한눈에 보였습니다. 코드만 위에서 아래로 읽을 땐 안 보이던 그림입니다. 동그라미를 클릭하면 그 파일이 뭐 하는 파일인지 한 줄 요약도 나옵니다. “이거 뭐야?”를 파일마다 Claude한테 안 물어봐도 되는 셈입니다.
매일 만지는 코드에서는 '뭘 하는 코드인지'는 새로 배운 게 없었습니다
신입이나 외주한테 이 그림 한 장 주면, 말로 30분 할 설명이 줄어들 거라고 봅니다. 반대로 제가 매일 만지는 코드에선 '이 함수가 뭘 하는지'는 새로 배운 게 없었습니다. 다만 '이게 어디까지 쓰이는지'는 이번에 처음 봤습니다. 이 그림은 '내가 모르는 코드'보다는 '내가 모르는 연결'에서 빛났습니다.
이 그림은 '내가 모르는 코드'보다는 '내가 모르는 연결'에서 빛났습니다.
이 글에서는 무엇이고, 왜 좋고, 언제 쓸 만한지 정도만 가볍게 다뤘습니다. 이 그림을 실제 작업에서 어떻게 읽고 활용하는지, 도구가 안에서 어떻게 동작하는지 같은 깊은 기술 분석은 따로 정리해 볼 생각입니다.
파일 백 개가 넘고 인수인계나 복귀가 잦을 때 써볼 만하다고 봅니다
네 가지 상황을 떠올렸습니다. 제가 직접 돌려 본 곳은 매일 만지는 베타 서비스 1곳뿐입니다. 그래서 그 서비스에서 실제로 본 것은 두 번째 상황(영향 범위 확인) 하나이고, 나머지 셋은 그 경험에서 미루어 짐작한 것입니다. 아래에 나오는 시간 숫자도 잰 값이 아니라 제 짐작입니다.
레포를 받아놓고 파일 트리만 멍하니 보게 되는 날, 그러니까 인수인계나 외주 코드, 팀 합류 첫날이라면 한 번 돌려두는 것만으로 전체 구조가 한눈에 들어와 “어디부터 봐야 하지”가 줄어들 거라고 봅니다. 이 경우는 직접 겪어 보지는 않았습니다. 신입 온보딩(새 사람이 팀 일에 익숙해지는 과정)이 1주에서 1일로 줄 수도 있겠다는 기대도 해 봤지만, 근거가 있는 숫자는 아닙니다.
공유하는 파일 하나를 고쳤는데 엉뚱한 화면에서 버그가 났던 경험이 있다면, 그림으로 그 파일이 어떤 화면들과 이어져 있는지 미리 볼 수 있습니다. 제 서비스에서도 손대기 전에 영향 범위를 가늠할 수 있었습니다. 예상 못 한 버그를 미리 막는 쪽이라, 고치기 전 1분 정도 확인해 보는 편이 더 싸게 먹힐 거라고 생각합니다.
신입 한 명 들어올 때마다 시니어가 두 시간씩 설명하는 팀이라면 그 비용도 줄어들 거라고 봅니다. 역시 짐작입니다. 그림은 자동으로 갱신되지 않으니, 넘기기 전에 한 번 더 돌려두면 됩니다. 사람이 자주 바뀌는 팀일수록 효과가 클 거라고 봅니다.
6개월 만에 내 프로젝트를 열면 나도, Claude도 처음부터 다시 파악해야 합니다. 그림을 한 번 만들어두면 다시 잡을 때 기억을 되살리기가 훨씬 빠를 거라고 봅니다. 이것도 오래 쉬었다 돌아온 프로젝트에 써 본 경험은 아직 없습니다.
아직 남은 문제: 작은 프로젝트엔 안 맞고, 코드가 바뀌면 다시 돌려야 합니다
작은 프로젝트, 파일 50개 이하에는 굳이 필요 없습니다. 그 정도면 Claude한테 통째로 읽히는 게 더 빠릅니다. 50개와 100개 사이는 README도, 제 경험도 뚜렷한 기준이 없어서 정확히 어디부터 필요한지는 모릅니다. 자주 바뀌는 코드는 다시 돌려야 합니다. 그림은 만든 시점 기준이라, 구조가 크게 바뀌면 갱신이 필요합니다. 결국 보는 건 사람입니다. 그림은 질문을 줄여줄 뿐, 판단을 대신하지는 않습니다. 그리고 Claude Code를 써야 의미가 있습니다. 안 쓰면 효과가 거의 없습니다.
마치며: '다 안다'가 아니라 '한 번 더 보인다'
파일 백 개가 넘는 레포에 Claude Code를 매일 쓰고 있다면, 한 번 돌려볼 가치가 있습니다. 제가 테스트한 서비스도 사실 그래프가 꼭 필요한 큰 규모는 아니었습니다. 그런데 써보고 나서 한 가지가 달라졌습니다. 한 모듈이 생각보다 훨씬 많은 파일에서 쓰이고 있다는 걸, 돌려보고 나서야 알았습니다. 코드를 이미 다 안다고 생각할 때도, 그래프는 다른 걸 보여줄 수 있습니다. 지금 다시 잡아야 하는 레거시 레포가 있다면, “이 함수 어디서 쓰여?”라고 Claude에게 매번 묻는 대신 오늘 그래프부터 한 번 그려 보시길 권합니다.
이 글은 AI의 도움을 받아 작성했습니다.
참고 자료
- Lum1104 / Understand-Anything: https://github.com/Lum1104/Understand-Anything