71.5배 토큰 절감, Graphify가 LLM 토큰 비용은 낮추고 답변 정확도는 높이는 방법

요약

오늘코드 채널이 Graphify를 1시간 2분에 걸쳐 해설한 한국어 영상이다. Graphify는 임의의 폴더를 하나의 지식 그래프로 만들어 주는 도구이고, Andrej Karpathy가 X에 올린 LLM Wiki 아이디어를 자동화한 것으로 소개된다. 영상은 도구를 소개하는 데 그치지 않고 실제 데이터에 적용한 실행 화면을 함께 보여 준다.

구성은 두 부분으로 나뉜다. 앞 17분은 한국 법령 저장소 legalize-kr에 Graphify를 직접 적용한 실행 시연이고, 뒤 45분은 슬라이드 강의다. 강의 부분은 9단계 파이프라인, 이중 경로 추출, AST와 tree-sitter, Leiden community detection을 차례로 다룬다.

이 자료의 값어치는 수치의 측정 조건을 화면으로 같이 보여 준다는 점에 있다. 영상 제목이 내건 71.5배는 Graphify 문서의 벤치마크를 인용한 값이고, 시연에서 나온 657배는 특허법 폴더라는 특정 코퍼스에 특정 질의(query)를 던진 뒤 도구가 스스로 산출해 보고한 값이다. 두 수치의 성격이 다르므로 인용할 때 구분해야 한다.

배경

기존 도구가 놓치는 것

LLM 코딩 어시스턴트가 폴더 안의 내용을 찾을 때는 폴더 전체를 훑으며 토큰을 대량으로 소비한다. 발표자는 여기에 정확도 문제가 겹친다고 지적한다. LLM은 확률 모델로 동작하는 비결정적 시스템이라 같은 질문에 늘 같은 답을 내지 않기 때문이다.

기존의 코드 분석 도구도 이 자리를 대신하지 못한다. 발표자는 세 종류를 검토하고 각각의 한계를 짚는다.

지식 그래프는 이 세 한계에 여섯 가지로 대응한다. 구조와 의미를 동시에 분석하고, cross-file 관계를 자동으로 발견하며, 인터랙티브 시각화와 자연어 질의를 지원한다. 그래프는 영구 저장되어 나중에 다시 활용할 수 있고, 문서가 추가되거나 변경되면 증분 업데이트로 바뀐 부분만 빠르게 반영한다.

발표자는 슬라이드의 비교표를 근거로 네 항목에서 지식 그래프가 앞선다고 정리한다. 관계 인식, cross-file 연결, 시각화, 영구 저장이다. 앞의 두 항목이 grep과 IDE 정적 분석이 각각 놓치는 지점이고, 뒤의 두 항목은 한 번 만든 분석을 다시 쓸 수 있게 하는 조건이다.

Karpathy의 raw 폴더에서 Graphify로

Graphify의 출발점은 Karpathy가 X에 올린 LLM 지식 베이스 구축 방법이다. 발표자는 도입부와 17:30, 39:30에서 이 계보를 반복해 짚는다.

Karpathy가 제안한 흐름은 단순하다. 기사, 논문, 저장소, 데이터셋, 이미지, 영상처럼 포맷이 제각각인 자료를 raw 폴더 하나에 모은다. 그다음 그 안의 데이터를 요약하고, 개념으로 분류하고, 마크다운이나 위키나 그래프로 작성한다.

이 흐름의 약점은 마지막 연결 작업이 사람 몫이라는 데 있다. 자료를 한 폴더에 모아 두어도 그 안의 연결 관계는 사람이 직접 찾아야 했다. Graphify는 이 과정을 자동화한다. graphify ./raw라는 명령 예시가 Karpathy의 폴더 이름을 그대로 쓰는 것도 이 계보 때문이다.

발표자 본인의 사용 경험도 함께 전한다. LLM Wiki 아이디어가 좋다고 생각하면서도 지식 베이스를 어떻게 활용할지 고민이 있었는데, Graphify가 나온 뒤로는 복잡한 파일 구조를 탐색할 때 이 도구를 쓴다는 것이다.

임베딩을 쓰지 않는다는 선택

Graphify는 기존의 그래프 기반 검색과 달리 임베딩을 쓰지 않는다. 발표자는 LLM으로 임베딩을 만들어 그래프를 그리는 방식이 흔하다는 점을 먼저 짚은 뒤, Graphify는 NetworkX 라이브러리로 그래프를 그린다고 설명한다. 임베딩 모델을 거치지 않고 실제 텍스트의 내용을 분석해 그래프로 변환한다는 것이다.

이 선택이 만드는 결과는 두 가지다. 첫째, 코드 분석 부분에서 LLM 호출이 사라지므로 토큰 사용량이 크게 줄어든다. 둘째, 코드를 통해 분석하므로 환각이 줄어든다. 발표자는 두 효과를 함께 묶어 Graphify의 핵심 아이디어로 제시한다.

영상 전체를 관통하는 대비도 여기서 나온다. LLM은 확률 모델이라 비결정적이고 폴더 전체를 훑어야 하지만, Graphify는 Python 파일로 구성된 결정적 프로그램이라 코드를 통해 코드를 분석한다는 대비다.

핵심 개념

지식 그래프. 자료 안의 개체와 그 사이의 관계를 노드와 엣지로 표현한 구조다. Graphify는 코드뿐 아니라 문서, 논문, 이미지, 영상까지 같은 그래프에 담는다.

노드, 엣지, 속성. 지식 그래프를 이루는 세 구성 요소다. 노드는 entity를 나타내고, 엣지는 노드 사이의 관계를 나타내며, 속성은 둘에 붙는 메타데이터다. entity는 코드의 함수나 클래스, 문서의 개념이나 인물처럼 노드로 삼는 개별 대상이다.

슬라이드의 예시 다이어그램은 main.py가 utils.py와 models.py를 import하고 이들이 config와 database에 의존하는 구조를 보여 준다. 노드의 색상은 엔트리 포인트, 모듈, 인프라, API 외부 연동으로 구분한다.

AST. Abstract Syntax Tree의 약자로, 소스 코드의 구조를 트리 형태로 표현한 자료 구조다. 코드의 모든 문자를 보존하지 않고 의미 있는 구조만 남긴다는 점이 핵심이다.

결정적 추출과 확률적 추출. 결정적 추출은 코드를 실행해 같은 입력에서 항상 같은 결과를 얻는 방식이다. 확률적 추출은 LLM에 맡겨 매번 결과가 달라질 수 있는 방식이다. Graphify는 두 방식을 함께 쓰되 구조 정보는 결정적 경로에 맡긴다.

커뮤니티. 그래프에서 서로 밀접하게 연결된 노드의 묶음을 말한다. 군집 분석에서 클러스터에 해당하는 개념이고, Graphify는 Leiden 알고리즘으로 이를 찾는다.

증분 업데이트. 이미 분석한 파일을 다시 분석하지 않고 변경된 파일만 다시 처리하는 방식이다. 그래프를 한 번 만들고 끝내는 것이 아니라 자료가 늘어나는 동안 계속 유지하려면 필요한 조건이다.

신뢰도 태그. 엣지마다 붙는 라벨로, 그 관계가 소스에서 직접 확인된 것인지 LLM이 추론한 것인지를 구분한다. 감사 추적의 최소 단위 역할을 한다.

이중 경로 추출. 결정적인 AST 경로와 확률적인 LLM 경로를 병렬로 실행한 뒤 결과를 하나의 그래프로 병합하는 Graphify의 핵심 설계다. 발표자는 영상을 마무리하며 이 설계를 Graphify의 첫 번째 핵심으로 꼽는다.

God Node. 그래프에서 연결이 가장 많은 허브 노드다. 발표자는 새 프로젝트에 합류했을 때 이 노드부터 읽으라고 권한다.

방법

9단계 파이프라인 개요

Graphify의 전체 흐름은 아홉 단계로 구성되며, 아홉 단계 전체가 CLI 명령 하나로 자동 실행된다.

1단계 detect

detect는 파이프라인의 첫 관문이면서 다음 단계의 분기를 결정한다. 입력 폴더를 재귀적으로 스캔해 처리 가능한 파일을 식별하고 카테고리별로 분류한다. 지원 카테고리는 코드, 문서, 논문, 이미지, 영상, 오디오 여섯 가지다.

분류 결과는 graphify-out 폴더에 JSON으로 저장되고, 이 정보가 다음 단계에서 어떤 추출기를 쓸지 정하는 기준이 된다. 코드 파일은 AST 경로로, 문서와 논문은 LLM 경로로 보내진다.

detect가 맡는 안전장치는 두 가지다. 첫째로 민감 파일을 자동으로 걸러 낸다. .env, credentials 파일, 프라이빗 키 같은 파일이 여기서 제외된다. 둘째로 대규모 코퍼스를 보호한다. 파일 200개 또는 단어 200만 개를 초과하면 경고를 표시하고 하위 폴더를 선택하도록 안내한다.

2단계 extract와 이중 경로 추출

extract는 Graphify에서 가장 중요한 단계다. 이중 경로 추출이라는 방식을 쓰는데, 성격이 다른 두 추출기를 병렬로 돌린 뒤 결과를 하나의 그래프로 병합한다.

Path A는 tree-sitter로 23개 언어의 AST를 만들고 거기서 노드와 엣지를 추출한다. 코드를 실행하는 방식이라 LLM이 전혀 필요 없다. 발표자는 이 결정성이 토큰 사용량을 크게 줄이는 근거라고 설명한다. 기존에 코드를 짜서 실행하듯 동작하므로 비용이 들지 않고 결과가 항상 같기 때문이다.

Path B는 Path A가 원리상 잡을 수 없는 정보를 채운다. 개념과 entity를 인식하고, 인용과 참조 관계를 찾고, 설계 결정의 근거까지 추출한다. 이미지는 비전 기능으로 분석해 UI, 스크린샷, 차트, 다이어그램의 내용을 이해한다.

발표자가 특히 중요하게 보는 것은 설계 근거 추출이다. 코드만 봐서는 알 수 없는 "왜 이렇게 설계했는가"라는 정보가 그래프에 포함되기 때문이다.

신뢰도 태깅

두 경로의 결과가 한 그래프로 병합되면 출처가 다른 엣지가 섞인다. Graphify는 각 엣지에 신뢰도 태그를 붙여 이를 구분한다.

발표자는 이 투명성 덕분에 Graphify를 연구 목적으로도 쓸 수 있다고 평가한다. 어떤 관계가 확실하고 어떤 관계가 추론된 것인지 드러나므로 분석 결과를 얼마나 신뢰할 수 있는지 판단할 수 있기 때문이다.

실행할 때마다 자동으로 출력되는 항목도 정해져 있다. God Node, 의외의 연결, 추천 질문, 신뢰도 점수, 구조적 연결이 없는 의미적 유사성 엣지, 하이퍼 엣지, 토큰 벤치마크다.

3단계 cache와 4단계 build

cache는 증분 업데이트를 담당한다. 대규모 코드베이스를 매번 처음부터 분석하면 시간과 비용이 많이 들기 때문에, 이미 추출된 파일의 결과를 캐시에 저장해 둔다. 변경 여부는 파일의 해시값으로 판단하므로 내용이 바뀌지 않은 파일은 건너뛴다. --update 플래그를 주면 변경된 파일만 재추출한다.

build는 추출된 프래그먼트를 하나의 통합 그래프로 조립한다. 네 단계를 순서대로 밟는다.

1. AST 추출 결과와 의미 추출 결과를 병합한다.
2. 같은 개념을 나타내는 중복 노드를 제거한다.
3. NetworkX 라이브러리로 그래프 객체를 생성한다.
4. Leiden 알고리즘을 적용해 커뮤니티를 감지한다.

5단계 analyze

analyze는 구축된 그래프에서 인사이트를 뽑는 단계이며 세 가지 분석을 수행한다.

God Node 분석은 가장 많이 연결된 핵심 허브 노드를 찾는다. 발표자가 든 예시가 Graphify 자신의 extract.py인데, 함수 48개와 관계 239개를 가진 허브다. 새 프로젝트에 합류했을 때 이 노드부터 읽기 시작하면 전체 아키텍처를 빠르게 파악할 수 있다는 것이 이 분석의 쓸모다. main.py가 어디서 시작하는지 찾아보는 습관을 그래프 수준으로 옮긴 셈이다.

Surprising Connections는 예상하지 못한 cross-file 관계를 찾는다. 직접적인 import나 호출이 없는데도 간접적으로 연결된 모듈을 찾아내, 숨겨진 의존성이나 암묵적 결합을 드러낸다. 코드 리뷰나 리팩터링 시점에 유용한 정보다.

Suggested Questions는 AI가 그래프 구조를 분석해 탐색할 만한 질문을 자동 생성한다. 예를 들어 extract와 build 사이의 데이터 흐름을 묻는 질문이 만들어져 그래프 탐색의 출발점이 된다.

6단계부터 9단계까지

visualize는 그래프를 여러 형식으로 내보낸다. 형식마다 상정한 사용처가 다르다.

transcribe는 오디오와 비디오 파일을 텍스트로 변환한다. OpenAI Whisper를 사용하고, 도메인 힌트를 함께 주어 전문 용어의 인식 정확도를 높인다. 머신러닝 관련 영상이면 Transformer나 attention 같은 키워드를 힌트로 제공하는 식이다.

query는 그래프를 자연어로 탐색하게 한다. 두 탐색 방식은 찾으려는 것이 다를 때 나뉘어 쓰인다. BFS는 시작 노드 주변을 넓게 훑어 광범위한 맥락을 모으고, DFS는 한 경로를 끝까지 따라가며 특정 관계를 깊게 추적한다. legalize-kr 시연에서 특허 출원과 등록의 관계를 찾을 때도 두 방식이 함께 쓰였다.

토큰 예산을 설정해 응답 길이를 제한할 수도 있다. 이 설정이 토큰 절감의 실질적인 지렛대다. 폴더 전체를 읽는 방식에서는 읽는 양이 파일 크기에 따라 정해지지만, 그래프 탐색에서는 몇 개의 노드까지 따라갈지를 미리 정할 수 있기 때문이다.

report까지 마치면 최종 결과물은 세 가지로 정리된다. 질의 가능한 그래프 데이터인 graph.json, 인터랙티브 시각화인 graph.html, 인사이트를 담은 리포트 마크다운 파일이다.

AST와 tree-sitter

AST는 소스 코드의 구조를 트리 형태로 표현한 자료 구조다. 이름에 들어간 추상이라는 말이 핵심을 가리킨다. 코드의 모든 문자를 보존하는 것이 아니라 의미 있는 구조만 추출한다는 뜻이다. 괄호, 세미콜론, 공백 같은 구문 장식은 버리고 함수 정의, 변수 선언, 조건문 같은 의미 단위만 남긴다.

트리의 각 노드는 코드의 구성 요소에 대응한다. 루트는 보통 모듈이나 프로그램이고, 그 아래에 함수 정의, 클래스, 선언, 표현식이 자식 노드로 배치된다.

발표자는 a와 b를 받아 더한 결과를 반환하는 간단한 함수를 예로 든다. 이 함수를 AST로 그리면 모듈 노드 하나가 최상단에 놓이고, 그 아래에 함수를 정의하는 노드와 결과를 반환하는 노드가 갈라진다. 함수 정의 노드 아래에는 인자 a, b와 두 값을 더해 할당하는 구문이 붙는다. 콜론과 들여쓰기와 공백은 사라졌지만 코드의 의미는 완전히 보존된다는 것이 추상화의 결과다.

AST가 중요한 이유는 두 가지다. 첫째, 언어 독립적인 코드 분석이 가능하다. Python이든 JavaScript든 AST로 변환하면 동일한 방식으로 분석할 수 있다. 둘째, 정규식이나 텍스트 매칭과 달리 코드의 구조를 정확히 반영한다. 컴파일러, 린터, IDE 코드 분석 도구가 모두 이 기술을 기반으로 삼는다. 확률적 모델이 아니라 결정적 방법을 쓴다는 점이 Graphify가 AST를 선택한 이유다.

Python은 표준 라이브러리 ast로 이 변환을 수행한다. ast.parse()를 호출하면 AST 객체가 반환되고, ast.dump()로 트리를 텍스트로 출력하며, ast.walk()로 모든 노드를 순회한다. Graphify가 이 역할을 tree-sitter에 맡기는 이유는 Python ast가 Python만 지원하기 때문이다.

증분 파싱과 오류 복구는 실제 개발 환경에서 값어치가 크다. 증분 파싱은 코드가 수정될 때 전체를 다시 읽지 않으므로 실시간 편집기나 watch 모드에서 유용하고, 오류 복구는 작성 중인 코드나 실험적인 코드에서도 가능한 많은 정보를 뽑아낸다. tree-sitter가 지원하는 주요 언어로는 Python, JavaScript, TypeScript, Go, Rust, Java, C++가 언급되며, 다중 언어 프로젝트도 하나의 그래프로 통합할 수 있다.

AST에서 노드와 엣지를 뽑는 규칙

AST에서 그래프를 만드는 하위 파이프라인은 여섯 단계다. 코드 파일이 tree-sitter로 파싱되어 AST가 생성되고, 거기서 노드와 엣지가 차례로 추출되어 최종적으로 그래프 프래그먼트가 나온다.

노드 ID는 파일명과 entity명을 언더스코어로 조합해 만든다. detect.py의 scan_folder 함수는 detect_scan_folder라는 ID를 가진다. 이 규칙이 모든 코드 파일에 일관되게 적용되므로 그래프 요소가 같은 방식으로 추출된다.

노드 유형별로 함께 뽑는 정보도 정해져 있다. 함수 정의 노드에서는 함수 이름, 파라미터, 반환 타입을 추출하고, 클래스 정의 노드에서는 클래스 이름, 부모 클래스, 메서드 목록을 추출해 노드 속성으로 저장한다. 호출 노드는 예외인데, 노드가 아니라 엣지로 변환된다.

발표자가 든 실전 예시는 pandas를 import해 DataFrame을 가져오고, 그 값을 다루는 함수를 정의해 반환하는 짧은 코드다. 이 코드 한 조각이 그래프로 바뀌는 과정을 따라가면 규칙이 어떻게 맞물리는지 보인다.

먼저 import 문에서 pandas 노드가 만들어지고 DataFrame 노드가 따라 붙는다. 다음으로 함수 정의에서 process 노드가 만들어지며, 노드 ID는 파일명과 함수명을 조합한 형태를 따른다. 마지막으로 함수가 pandas를 참조한다는 사실이 import 엣지가 되어 process에서 pandas로 연결된다.

결과적으로 노드 세 개와 엣지 하나가 남는다. 같은 규칙이 모든 코드 파일에 반복 적용되므로, 코드베이스 전체의 관계가 사람 손을 거치지 않고 그래프가 된다.

Leiden community detection

Leiden은 2019년에 발표된 community detection 알고리즘으로 Louvain의 개선판이다. modularity라는 지표를 최적화하면서, Louvain의 알려진 문제인 연결이 끊긴 커뮤니티가 생기는 현상을 해결했다. resolution 파라미터를 조정하면 더 세밀하거나 더 큰 클러스터를 만들 수 있어 분석 목적에 맞게 유연하게 쓸 수 있다.

커뮤니티가 실제로 쓰이는 곳은 세 군데다.

• 모듈 구조를 자동으로 발견해 아키텍처를 이해한다.
• 관심사가 잘 분리되어 있는지 검증해 설계 품질을 평가한다.
• 코드를 변경할 때 같은 커뮤니티의 다른 노드가 영향을 받을 가능성을 함께 분석한다.

핵심 라이브러리와 코드 구조

Graphify를 떠받치는 Python 라이브러리는 네 가지다.

발표자는 영상 끝부분에서 실제 코드를 세 파일에 걸쳐 훑는다. 모듈 사이의 역할 분담이 함수 단위로 드러나는 부분이다.

extract의 반환값은 딕셔너리이며 노드 리스트, 엣지 리스트, 입력 토큰, 출력 토큰을 담는다. AST 추출이 로컬에서 수행되므로 토큰 사용량은 항상 0으로 기록된다. 반환되는 노드는 ID, 라벨, 파일 타입, 소스 파일 경로를 가지고, 엣지는 시작 노드 ID, 도착 노드 ID, 관계 유형, 신뢰도를 가진다. 직접 추출된 관계이므로 신뢰도는 항상 extracted이고 점수는 1이다.

cluster가 돌려주는 결과는 각 노드 ID가 어떤 커뮤니티 번호에 속하는지 담은 딕셔너리다. 이 값이 그래프의 노드 속성으로 저장되어 시각화할 때 색 구분에 쓰인다.

전체 구현 흐름은 여섯 개 함수 호출로 이어진다. detect에서 시작해 extract, build_from_json, cluster, God Node, HTML 렌더 순서이며, 각 함수의 출력이 다음 함수의 입력이 되는 설계다. 발표자는 이 간결한 API 뒤에 tree-sitter의 복잡한 파싱 로직이 숨어 있지만 사용자는 두 줄의 함수 호출만으로 전체 코드베이스 구조를 추출할 수 있다고 정리한다.

CLI와 슬래시 스킬

설치 절차 자체가 이 도구의 배포 방식을 드러낸다. Claude Code나 Antigravity 화면에서 Graphify의 홈페이지 주소나 git 저장소 주소를 주고 스킬로 설치해 달라고 요청하면 끝난다. 별도의 설치 스크립트를 실행하는 것이 아니라 어시스턴트가 스스로 스킬을 만들어 붙이는 방식이다. 발표자는 이 과정이 복잡하지 않다는 점을 두 번에 걸쳐 강조한다.

설치 후에는 /graphify 슬래시 커맨드로 전체 파이프라인을 실행하며, 별도의 설정이나 구성은 필요 없다. 실행하면 어떤 폴더든, 코드베이스든 노트든 논문이든 이미지든 텍스트든 영상이든 그 안의 내용을 정리해 graphify-out 폴더에 HTML 문서, 마크다운 파일, JSON 문서, 캐시를 생성한다. 문서가 나중에 갱신되면 캐시를 참조해 변경된 부분만 반영한다.

논문이나 트윗은 URL만 넣으면 폴더로 옮기는 과정 없이 그래프에 바로 추가된다.

보안과 프라이버시

Graphify가 외부 LLM을 부르는 도구인 만큼 발표자는 보안 설계를 네 계층으로 나누어 설명한다.

결과

legalize-kr 시연

발표자가 고른 시연 데이터는 legalize-kr이다. 박정환이 만든 git 기반 대한민국 법령과 판례 저장소로, 법령이 언제 변경되었는지 추적할 수 있는 형태로 관리된다. 방대한 분량 때문에 사람이 통째로 분석하기 어렵다는 점이 시연 대상으로 고른 이유다.

시연 흐름은 다음과 같이 진행된다.

1. 저장소를 클론한 뒤 graphify .를 실행한다.
2. 전체 법령이 너무 방대해 Graphify가 특정 폴더만 분석하라고 제안한다. 발표자는 특허법을 선택한다.
3. 선택한 폴더의 코퍼스 규모를 파악하고 AST를 생성한다. 이어서 단계별로 실행되며 HTML 시각화를 만든다.
4. God Node를 찾고, Surprising Connections로 연결 경로를 확인하고, Suggested Questions로 던질 만한 질문을 제안받는다.
5. graphify query로 "특허 출원과 등록의 차이"를 묻는다. BFS와 DFS로 법령을 탐색해 답을 만들고, 차이를 표로도 정리한다.
6. Graphify가 deep 모드로 재실행하면 등록, 심사, 거절 노드가 풍부해질 수 있다고 제안하고 발표자가 수락한다. 이 과정에서 API 오류가 발생해 다시 시도한다.
7. 산출물로 그래프 HTML, JSON, 마크다운 파일이 나온다.

시각화 화면에서 "파리"를 검색해 파리 협약과 연결된 노드를 확인하는 장면도 나온다. 검색어 하나로 관련 노드가 걸러지므로 법령끼리 어떻게 연결되는지 눈으로 확인할 수 있다.

발표자가 이 시연으로 보이려는 것은 그래프가 두 독자를 동시에 상대한다는 점이다. 사람에게는 방대하고 읽기 어려운 법령 문서를 노드와 엣지로 정리한 지도이고, LLM에게는 문서를 전부 열어 보지 않고도 필요한 부분을 찾게 해 주는 지도다. 지도를 참조하면 부정확한 답변을 낼 확률이 줄고 토큰 소모도 함께 줄어든다는 것이 발표자의 설명이다.

deep 모드 재실행 구간에서는 community detection 과정이 화면에 드러난다. 발표자는 커뮤니티를 찾는 일이 군집 분석으로 비슷한 주제를 묶는 것과 비슷하다고 풀이한다. 재실행 뒤 God Node로 특허 출원과 특허권과 심사 같은 노드가 올라오고, 출원과 등록의 차이가 표로 정리된다.

토큰 절감 수치와 측정 조건

토큰 절감은 이 영상의 핵심 주장이므로 수치마다 출처와 조건을 붙여 읽어야 한다.

이 수치를 읽을 때 함께 볼 조건이 두 가지 있다.

첫째, 657배는 질의 시점의 값이다. 발표자가 같은 답변에서 전한 바에 따르면 그래프를 처음 만들 때 그래프와 JSON과 HTML과 마크다운 파일을 생성하는 초기 투자 비용에 토큰이 들어간다. 절감 효과는 그 비용을 치른 뒤 반복 질의에서 나온다.

둘째, 657배는 외부에서 계측한 값이 아니라 도구 자신이 산출해 보고한 값이다. 산술적으로도 292 토큰의 657배는 191,844 토큰이므로 비교 기준은 정확히 20만이 아니라 19만 대의 어떤 값이다.

두 수치가 무엇을 세는지도 구분해야 한다. 20만 토큰은 특허법 폴더의 파일을 전부 읽어 컨텍스트에 담았을 때의 양이고, 292 토큰은 그래프에서 질문과 관련된 노드와 엣지만 뽑아 담았을 때의 양이다. 절감의 원천은 모델이 더 똑똑해진 것이 아니라 읽을 대상을 미리 좁혔다는 데 있다. 그러므로 이 배수는 코퍼스가 크고 질문이 국소적일수록 커지고, 반대의 경우에는 작아진다.

처리 속도

10만 줄 규모의 코드도 약 8분이면 처리된다. 캐시 히트율은 80% 이상이고, 증분 업데이트를 쓰면 첫 실행 대비 5배 이상 빨라진다.

이 성능을 만드는 전략으로 발표자가 이름을 붙여 설명한 것은 두 가지다. 캐싱은 이미 처리한 파일을 다시 처리하지 않고 파일 해시로 변경 여부를 판단한다. chunking은 파일을 chunk로 나누어 처리하되 같은 디렉터리의 파일은 같은 chunk에 담아 cross-file 관계의 추출 확률을 높인다.

Graphify 자체 분석

발표자는 Graphify로 Graphify 프로젝트 자체를 분석한 결과를 영상에서 세 번 반복해 제시한다.

응집도는 modularity를 가리키며 1에 가까울수록 커뮤니티 내부의 연결이 밀접하다는 의미다. 발표자는 0.78을 매우 높은 수준으로 평가한다. 클러스터링 시각화에서는 extract 모듈, build 모듈, analyze 모듈이 각각 하나의 커뮤니티를 형성한다.

God Node 1위는 extract.py로 함수 48개와 관계 239개를 가진다. 발표자는 이 결과를 프로젝트를 처음 접하는 개발자가 어느 파일부터 읽어야 할지 알려 주는 신호로 해석한다.

이 분석은 도구를 도구 자신에게 적용한 사례라는 점에서 시연 이상의 의미를 가진다. Graphify가 Python 20개 파일로 이루어진 프로젝트이고, 그중 extract.py가 허브로 잡히는 결과는 앞에서 설명한 아키텍처와 맞아떨어진다. extract가 이중 경로 추출을 맡는 핵심 단계라고 설명한 내용이 그래프 지표로도 확인되는 셈이다.

네 가지 활용 사례

발표자 자신도 이 사례를 실행한다. 이 영상의 슬라이드는 Graphify로 Graphify 저장소를 분석한 뒤 LLM에 만들게 한 결과물이다.

발표자가 정리한 세 가지 핵심

영상은 Graphify의 핵심을 세 가지로 정리하며 끝난다.

발표자가 이 정리에 붙인 결론은 읽는 방식의 변화다. 문서와 이미지와 영상을 하나씩 열어 보고 구조를 추측하는 대신, 지식 그래프로 전체 구조를 한눈에 보고 숨겨진 관계를 발견하게 된다는 것이다.

사실과 평가의 구분

제3자 해설 영상이라 서술의 근거가 층으로 나뉜다. 인용할 때 섞지 않으려면 구분이 필요하다.

한계

영상에 별도의 한계 절은 없다. 아래는 발표자가 지나가며 짚은 트레이드오프와 이 자료 자체의 제약이다.

초기 구축 비용. 토큰 절감은 질의 시점에 나타나는 효과다. 그래프를 처음 만들 때 Path B의 의미 추출에 LLM 토큰이 들어간다. 캐시와 증분 업데이트가 이후 비용을 낮추지만 첫 비용 자체는 사라지지 않는다.

대규모 코퍼스 가드레일. 파일 200개 또는 단어 200만 개를 넘으면 자동으로 처리하지 않고 사용자 확인을 요구한다. 안전장치인 동시에 큰 저장소를 한 번에 그래프로 만들기는 어렵다는 뜻이기도 하다. 시연에서 발표자가 법령 전체가 아니라 특허법 폴더만 고른 것도 이 제약 때문이다.

외부 LLM 의존. 시연 도중 API 오류가 발생해 재시도했다. Path B는 외부 모델에 의존하므로 네트워크와 quota 상태에 노출된다.

수치의 출처 한계. 657배는 도구가 스스로 산출해 답한 값이고 71.5배는 Graphify 문서의 값이다. 영상 안에서 두 수치를 독립적으로 계측한 절차는 나오지 않는다.

자료 내부의 수치 불일치. 지원 언어 수가 절마다 갈린다. 도입부와 detect 절에서는 20개 이상이라고 말하고, extract와 tree-sitter 절에서는 23개 이상이라고 말한다. 처리 속도도 요약 문장에서는 파일 1,000개를 5분에 처리한다고 말하지만 바로 뒤 표에서는 200개가 5분 이내이고 1,000개가 8분이다.

자막 노이즈. 이 페이지의 근거는 YouTube 한국어 자동 자막이며, 자막이 고유명사와 숫자를 잘못 합성한 구간이 있다. God Node를 "간드", Louvain을 "루베인", vis.js를 "bj.js", .env를 "DMV", 엣지 2,141개를 "2114, 141"로 옮긴 사례가 확인된다. 정확한 인용이 필요하면 원본 영상의 슬라이드를 직접 확인해야 한다.

정확도 주장의 근거 부재. 영상 제목과 본문은 토큰 비용을 낮추면서 답변 정확도를 높인다고 말하지만, 정확도 쪽에는 대응하는 측정값이 없다. 토큰 수는 292와 20만이라는 값으로 제시되는 반면, 정확도는 그래프를 참조하면 부정확한 답변을 낼 확률이 줄어든다는 설명으로만 제시된다. 두 주장의 근거 수준이 다르다는 점을 감안해 읽어야 한다.

향후 과제 부재. 발표자는 후속 계획을 밝히지 않는다. 영상은 시청자에게 도움이 되기를 바란다는 인사로 끝난다.

핵심 용어

관련 페이지

• Graphify 저장소: 이 영상이 해설 대상으로 삼은 도구 자체
• Graphify (graphify-labs 이전판): 같은 도구가 조직 계정으로 옮겨 간 판본
• Graphify 한국어 랜딩 페이지: 제작자 측이 낸 한국어 소개 자료. 이 영상은 제3자 해설이라 역할이 다르다
• Karpathy LLM Wiki 입문 튜토리얼: Karpathy의 Gist를 영어권 6단계 워크플로로 풀어쓴 자료
• Karpathy LLM Wiki 패턴 한국어 종합 정리: 같은 아이디어를 종합한 메타 리포트
• colbymchenry/codegraph: tree-sitter 기반 code-intelligence 서버로 같은 계열
• RAG, LLM Wiki, or GBrain?: 에이전트가 맡을 일을 기준으로 세 방식을 고르는 결정 프레임워크
• GraphRAG: Leiden community detection을 RAG에 도입한 원논문. Graphify의 build와 analyze 단계가 같은 계보에 있다
• LightRAG: GraphRAG 후속작. 그래프로 토큰을 줄이는 같은 흐름
• LeanRAG: 지식 그래프 기반 생성의 또 다른 후속작
• PageIndex: 임베딩 없이 구조를 활용하는 검색 계열