AI 스터디 · 7주차

Understand-Anything
— 코드를 지식그래프로 바꾸는 Claude Code 플러그인 해부

"Turn any code into an interactive knowledge graph you can explore, search, and ask questions about."

왜 이 도구? (1~6주차와의 연결) 1주차 OT · 2주차 하네스 · 3주차 LLM Wiki · 4주차 OMC/Octopus · 5주차 superpowers · 6주차 Vectorless RAG. 이번 주는 "대형 레포를 AI가 어떻게 구조적으로 이해하게 만드는가"를 메커니즘 수준에서 뜯어봅니다. 전부 Claude Code 구독 안에서(추가 과금 없이) 쓸 수 있습니다.

라이선스 · 제작

MIT License · author Egonex · plugin understand-anything v2.7.7

비용

오픈소스 무료 플러그인 — LLM 호출은 기존 Claude Code 구독 사용(추가 과금 없음)

출처: github.com/Egonex-AI/Understand-Anything — README, MIT License

1 / 10 문제

대형 레포, 신규 입사자 — AI도 길을 잃는다

레포를 처음 열면: 파일 수백 개, 디렉터리 수십 개.
"이 함수가 어디서 호출돼?" — grep만으로는 한계.

신규 입사자 온보딩

  • 코드 읽는 데만 며칠
  • 어떤 파일이 핵심인지 모름
  • 의존 관계를 머릿속에 쌓아야 함

AI 어시스턴트의 한계

  • 컨텍스트 창 한계 — 레포 전체를 못 넣음
  • 파일 선택을 사람이 해줘야 함
  • 구조를 모르면 엉뚱한 파일을 읽음
핵심 긴장: 레포는 크고, 컨텍스트 창은 작다. "전부 넣으면 되지 않나?" — 넣을 수가 없고, 넣어도 LLM이 구조를 파악하기 어렵다.

출처: github.com/Egonex-AI/Understand-Anything — README "Why Understand-Anything?"

2 / 10 순진한 접근

두 가지 순진한 접근이 왜 부족한가

접근한계
grep / 텍스트 검색
grep -r "fetchUser" .
호출 관계의 의미를 모름. 결과 목록만 줄뿐, "이게 핵심 경로인가 테스트 픽스처인가"를 알 수 없음.
전체를 LLM에 통째로
파일 100개를 붙여넣기
컨텍스트 한계 초과 + 비용 폭증 + LLM이 구조 없이 텍스트를 읽어야 함 → 부정확한 요약.
Understand-Anything의 답: 먼저 결정론적(deterministic) 도구로 구조를 추출하고, 그 구조 위에서만 LLM을 쓴다. 토큰을 쓸 곳과 안 쓸 곳을 명확히 분리.

출처: github.com/Egonex-AI/Understand-Anything — README; agents/file-analyzer.md (두 단계 구조)

3 / 10 UA란

Understand-Anything — Claude Code 네이티브 플러그인

설치 방법 두 가지 (실제 명령어):

# Claude Code 네이티브 (권장)
/plugin marketplace add Egonex-AI/Understand-Anything
/plugin install understand-anything

# 기타 플랫폼 원라인 (Cursor, Codex, Gemini CLI 등)
curl -fsSL https://raw.githubusercontent.com/Egonex-AI/Understand-Anything/main/install.sh | bash

👉 installer가 ~/.understand-anything/repo에 클론하고 심링크를 연결한다.

지원 플랫폼

  • Claude Code (네이티브)
  • Cursor / VS Code + Copilot (자동 감지)
  • Codex, OpenCode, Gemini CLI, Cline

무과금 포인트

오픈소스 무료 플러그인. LLM 호출은 기존 Claude Code 구독의 에이전트를 사용 — 추가 요금 없음.

출처: github.com/Egonex-AI/Understand-Anything — README "Installation"

4 / 10 메커니즘

2단계 하이브리드 파이프라인: tree-sitter + LLM

UA의 핵심 설계 결정 — 무엇을 결정론적으로, 무엇을 LLM으로 처리할지를 명확히 나눈다.

Phase 1

tree-sitter
결정론적

Phase 2

LLM
시맨틱

출력

knowledge-
graph.json

엔진담당특성
tree-sitter
(결정론적)
소스코드 → 구문트리 파싱
imports, exports, 함수 정의, 클래스, 호출 위치 추출
같은 입력 → 항상 같은 출력.
재현 가능 + 증분 변경 감지 기반.
LLM
(시맨틱)
요약 생성, 태그, 아키텍처 레이어 분류,
비즈니스 도메인 매핑
구조적 사실 위에서만 동작.
의미 해석이 필요한 부분만.
핵심 원리: tree-sitter가 만들어 준 구조적 사실(structural facts)을 기반으로 LLM이 의미 해석(semantic)만 담당한다. LLM이 파일 트리를 직접 걸어 다니거나 임포트를 추적하는 일을 하지 않는다.

검증: agents/file-analyzer.md — "This script uses tree-sitter for code files and specialized parsers for non-code files, providing deterministic, high-quality structural extraction."

출처: github.com/Egonex-AI/Understand-Anything — agents/file-analyzer.md "Phase 1 — Structural Extraction (Bundled Script)"

5 / 10 멀티에이전트 파이프라인

에이전트 파이프라인: scanner → file-analyzers → architecture → tour

agents/ 디렉터리에 실제로 존재하는 에이전트 파일들 (직접 확인):

project-scanner

파일 목록
언어 감지
복잡도

file-analyzer ×N

병렬 실행
최대 5개 동시
20~30파일/배치

architecture-analyzer

레이어 분류
도메인 매핑

tour-builder

온보딩 투어
순서 생성

graph-reviewer

품질 검토
dangling edge

project-scanner 분업 (agents/project-scanner.md 검증)

결정론적 (스크립트)

  • 파일 열거 (git ls-files 우선)
  • 언어 감지 · 카테고리 분류
  • 라인 수 계산 · 복잡도 추정
  • .understandignore 필터링
  • 임포트 맵 추출

→ scan-project.mjs, extract-import-map.mjs
"Do NOT re-implement any of this logic."

LLM 담당

  • README + manifests 읽기
  • 프로젝트 이름·설명 서술
  • 프레임워크 내러티브 합성

→ 구조 사실은 스크립트가 주고
LLM은 서술(narrative)만 작성

출처: github.com/Egonex-AI/Understand-Anything — agents/project-scanner.md, agents/file-analyzer.md (직접 검증)

6 / 10 산출물

산출물: .understand-anything/knowledge-graph.json

분석이 끝나면 프로젝트 루트에 생성되는 파일:

# .understand-anything/knowledge-graph.json (구조 요약)
{
  "nodes": [
    { "id": "file:src/api/user.ts",      "type": "file", ... },
    { "id": "function:src/api/user.ts:fetchUser", "type": "function", ... },
    { "id": "class:src/models/User.ts:User",      "type": "class", ... }
  ],
  "edges": [
    { "from": "function:...:fetchUser", "to": "file:src/db/conn.ts", "type": "imports" },
    { "from": "function:...:fetchUser", "to": "function:...:queryDB", "type": "calls" }
  ]
}

# .understand-anything/meta.json — 증분 업데이트의 기준점
{ "gitCommitHash": "a3f9..." }

노드 유형

  • file — 소스 파일
  • function — 함수·메서드
  • class — 클래스

엣지 유형

  • imports — 임포트 관계
  • calls — 호출 관계
  • inherits / implements
  • related — 시맨틱 연관
meta.json의 gitCommitHash가 다음 슬라이드에서 설명할 증분 업데이트의 기준점(baseline). 커밋 해시가 바뀌면 diff를 계산해 변경된 파일만 재분석한다.

출처: github.com/Egonex-AI/Understand-Anything — README "Output", agents/file-analyzer.md

증분 전 정리 대형 레포에서

대형 레포에 적용하면 — 비용/시간의 구조

수천 개 파일을 가진 레포에서도 위 파이프라인이 그대로 돈다. 핵심은 "어디에 토큰을 쓰고 어디엔 안 쓰는가"다.

토큰을 안 쓰는 곳 (결정론적)

  • 파일 열거·언어 감지·라인 수 (스크립트)
  • tree-sitter 구문 파싱·import 맵
  • Louvain 시맨틱 배치 계산 (~수 초)

토큰을 쓰는 곳 (LLM)

  • 배치별 file-analyzer 요약 (최초 1회가 큰 비중)
  • 아키텍처 레이어 분류·도메인 매핑
  • 가이드 투어 서술
그래서 언제 쓰나: 최초 1회 분석은 레포 크기에 비례해 토큰을 쓰지만 — ① 결과(knowledge-graph.json)는 디스크에 남아 재사용 ② 이후엔 증분 업데이트가 변경 파일만 재분석(다음 슬라이드) ③ 신규 입사자 온보딩·대형 레거시 파악처럼 "사람이 며칠 걸릴 일"을 대체할 때 본전을 뽑는다. 작은 레포·자주 바뀌는 코드엔 과하다.

출처: github.com/Egonex-AI/Understand-Anything — agents/*.md, skills/understand/compute-batches.mjs

7 / 10 증분 업데이트

증분 업데이트 — "토큰 0 원칙"

post-commit hook이 트리거. 핵심 원칙:

"Spend zero LLM tokens when changes are cosmetic (formatting, internal logic).
Only invoke LLM agents when structural changes (new/removed functions, classes, imports, exports) are detected."

— hooks/auto-update-prompt.md (직접 인용)

gitCommitHash 비교
변경 파일 목록
구조 fingerprint 비교
LLM 호출 (구조 변화만)
변경 유형LLM 호출이유
공백·포매팅·주석 수정없음 (토큰 0)구조적 fingerprint 동일
내부 로직 변경 (함수 시그니처 불변)없음 (토큰 0)exports/imports 변화 없음
함수 추가·제거, 임포트 변경필요 (해당 파일만)구조 변화 감지됨
새 파일 추가필요 (신규 파일만)지식그래프에 없는 노드
비유: 영어사전에서 기존 단어 설명만 고쳤으면 색인은 안 바꿔도 된다. 새 단어가 추가됐을 때만 색인을 갱신한다.

출처: github.com/Egonex-AI/Understand-Anything — hooks/auto-update-prompt.md "Key principle" (직접 인용)

8 / 10 명령어 · 실제 사용

명령어 한눈에 — 한국어(--language ko) 지원 포함

명령어역할
/understand전체 코드베이스 분석 · 지식그래프 생성 (최초 1회)
/understand-dashboard인터랙티브 대시보드 열기
/understand-chat지식그래프 기반 대화 Q&A
/understand-diff두 커밋 간 구조 변화 시각화
/understand-explain특정 파일·함수 설명
/understand-onboard신규 입사자용 투어 생성
/understand-domain비즈니스 도메인 매핑
/understand-knowledge지식베이스 검색

주요 플래그

# 한국어로 출력 (ko 지원 확인됨)
/understand --language ko

# post-commit hook 자동 업데이트 활성화
/understand --auto-update

# 지원 언어: en, zh, zh-TW, ja, ko, ru
--language ko: 요약·태그를 한국어로 생성. 국내 팀에서 쓸 때 유용. 기술 용어(middleware, hook 등)는 영어 유지.

출처: github.com/Egonex-AI/Understand-Anything — README "Commands" 및 "--language" 플래그 목록

9 / 10 트레이드오프

트레이드오프 — 솔직하게

강점

  • 결정론적 + LLM의 분업 — 재현 가능하고 비용 효율적
  • 증분 업데이트로 반복 비용 최소화
  • 한국어 포함 다국어 출력 지원
  • Claude Code 구독만으로 추가 과금 없음
  • 멀티 플랫폼 (Cursor·Copilot·Codex 등)

주의 / 한계

  • 최초 분석은 레포 크기에 따라 시간+토큰 필요
  • 지식그래프 품질은 LLM 요약 품질에 의존
  • tree-sitter 미지원 언어는 구조 추출 제한
  • 동적 패턴(런타임 의존성)은 정적 분석 한계
  • 신규 프로젝트: 레포가 작으면 overhead가 큼
언제 쓰면 좋은가: 파일이 수십 개 이상인 기존 레포, 신규 팀원 온보딩이 잦은 팀, "이 함수가 어디에 영향 미치나"를 자주 묻는 상황. 반대로 작은 사이드 프로젝트라면 overhead 대비 효용이 낮을 수 있음.

출처: github.com/Egonex-AI/Understand-Anything — README, agents/*.md 종합 분석

10 / 10 정리

정리 — 오늘의 핵심 세 가지

  1. 2단계 분업: tree-sitter(결정론적)가 구조적 사실을 추출하고, LLM(시맨틱)은 의미 해석만 담당한다.
  2. 토큰 0 원칙: 포매팅·내부 로직 변경에는 LLM을 쓰지 않는다. 구조가 바뀔 때만 LLM을 호출한다.
  3. 멀티에이전트 병렬화: file-analyzer가 최대 5개 동시, 배치당 20~30파일 처리 — 큰 레포도 현실적인 시간에 완료.

좋은 AI 도구는 "LLM을 어디에 쓰지 않을지"를 설계한다.

이번 주에 해볼 것 (딱 하나): 팀에서 가장 파악하기 어려운 레포 하나를 골라 /understand --language ko 한 번 돌려보기. knowledge-graph.json이 생기면 /understand-onboard로 온보딩 투어를 만들어 팀원에게 공유.

출처: github.com/Egonex-AI/Understand-Anything — 전체 분석 종합

감사합니다

질문 / 각자의 "레포 파악 고생담" 공유


참고자료

1 / 11← / → 넘기기 · a: 스크롤 · n: 노트