Gradle 워크플로에 Graphify 통합: Knowledge Graph에서 PlantUML 다이어그램까지 한 명령어로
게시: 19 April 2026
- 문제: 항상 코드보다 뒤처진 다이어그램
- 해결책: 결정적 파이프라인 Knowledge Graph → PlantUML
- 단계 1 : Graphify 설치 및 Knowledge Graph 추출
- 단계 2 : Gradle 플러그인이 Knowledge Graph를 PlantUML로 변환합니다.
- 3단계: 일상 사용
- Gradle 워크플로우의 전체 파이프라인
- 도그푸딩: 플러그인은 스스로를 문서화한다.
- 왜 그것이 결정적이며 (그리고 왜 그것이 중요한가)
- 파이프라인 자체 다이어그램
- 프로젝트 거버넌스 내 통합
- 준비 : 5분 체크리스트
- 함정 및 완화 방안
- 최종적으로 얻는 것
- 링크
당신의 코드베이스가 커지고 있습니다. 모듈 간의 의존성이 늘어납니다. 아키텍처 문서는 작성되기도 전에 구식이 됩니다. 만약 Gradle 빌드가 자동으로 실제 코드 구조로부터 최신 다이어그램을 생성할 수 있다면? 이는 정확히 pipeline Graphify + PlantUML Gradle Plugin :`graphify . --no-viz`Knowledge Graph을 추출합니다,`./gradlew generateKnowledgeGraphDiagram`이를 PlantUML 다이어그램으로 변환합니다. LLM 없음, 매뉴얼 없음, 100% 결정적.
- 톡
-
[]
문제: 항상 코드보다 뒤처진 다이어그램
몇천 줄을 넘는 모든 프로젝트는 이 증후군을 겪는다 :
-
프로젝트 초기에 아키텍처 다이어그램을 그립니다.
-
코드가 진화하고, 의존성이 바뀝니다.
-
도표는 장식적인 거짓이 된다.
-
아무도 이것을 업데이트하지 않아요, 왜냐하면 귀찮기 때문이에요
-
신규 사용자들은 그것에 기반을 두고 실수를 합니다.
@startuml
skinparam backgroundColor #FEFEFE
skinparam ActivityBackgroundColor #FDEDEC
skinparam ActivityDiamondBackgroundColor #FFF3CD
start
:Diagramme d'architecture créé\n(manuellement, à la main);
:Le code évolue\n(nouvelles classes, nouvelles dépendances);
:Diagramme obsolète\n(ne reflète plus le code);
if (Qui met à jour ?) then (Personne)
:Documentation mensongère;
note right: Les nouveaux développeurs\nse basent dessus... et font des erreurs
else (Quelqu'un)
:Mise à jour manuelle\n(2-3 heures de travail);
note right: Déjà obsolète\nà la prochaine PR
endif
stop
@enduml
질문은 도표가 필요한가요? — 모두가 알다시피 그렇습니다. 질문은 :누가 그들을 최신 상태로 유지합니까?
답변 : 아무도 없습니다. 자동인 경우를 제외하고
해결책: 결정적 파이프라인 Knowledge Graph → PlantUML
원칙은 간단합니다: 손으로 다이어그램을 그리는 대신에, 우리는 그들을,실제 코드 구조에서 생성.
@startuml skinparam backgroundColor #FEFEFE skinparam componentStyle rectangle actor Développeur component "Graphify (pip install graphifyy)" as Graphify collections "graphify-out/graph.json (지식 그래프)" as KGJSON component "PlantUML Gradle Plugin\n(generateKnowledgeGraphDiagram)" as Plugin component "KnowledgeGraphParser" as Parser component "KnowledgeGraphRenderer" as Renderer component "PlantumlService (검증 + 렌더링 PNG)" as PS collections "diagrams/knowledge-graph/ (.puml + .png)" as Output Développeur --> Graphify : graphify . --no-viz Graphify --> KGJSON : extrait la structure\ndu code source Développeur --> Plugin : ./gradlew generateKnowledgeGraphDiagram Plugin --> Parser : parse(graph.json) Parser --> Plugin : KnowledgeGraph\n(noeuds + arêtes + communautés) Plugin --> Renderer : render(graph, filters) Renderer --> Plugin : code PlantUML\ndéterministe Plugin --> PS : validateSyntax + generateImage PS --> Output : .puml + .png note bottom of Plugin Pipeline DÉTERMINISTE Aucun appel LLM Résultat reproductible end note @enduml
두 개의 명령어. 그게 전부입니다.
# Étape 1 : extraire le Knowledge Graph
graphify . --no-viz
# Étape 2 : générer les diagrammes PlantUML
./gradlew generateKnowledgeGraphDiagram
결과? 파일들`.puml` et .png`안에`diagrams/knowledge-graph/, Git에서 버전 관리된, 코드와 항상 최신 상태인
단계 1 : Graphify 설치 및 Knowledge Graph 추출
설치
Graphify는 코드베이스를 분석하고 구조화된 지식 그래프를 구축하는 Python 도구입니다:
# Méthode recommandée
uv tool install graphifyy && graphify install --platform opencode
# Alternative avec pip
pip install graphifyy && graphify install --platform opencode
제외 항목 구성
파일 생성`.graphifyignore`프로젝트 루트에 비즈니스 로직과 관련 없는 파일을 제외하기 위해:
# Secrets — JAMAIS dans le graphe
*-context.yml
*.env
# Fichiers générés
build/
.gradle/
# Tests fonctionnels
src/functionalTest/
지식 그래프 추출
graphify . --no-viz
플래그`--no-viz`HTML 생성을 건너뛰습니다 (Gradle 파이프라인에서는 불필요함). 결과는 파일입니다.`graphify-out/graph.json`포함 :
-
매듭들: 클래스, 함수, 파일 — 그들의 유형과 커뮤니티
-
모서리:노드간 관계(EXTRACTED 코드에서, INFERRED LLM에 의해)
-
커뮤니티연결된 노드의 자동 그룹화
{
"nodes": [
{"id": "0", "label": "LlmService", "file_type": "code", "community": 0},
{"id": "1", "label": "ApiKeyPool", "file_type": "code", "community": 0},
{"id": "2", "label": "PlantumlService", "file_type": "code", "community": 1}
],
"links": [
{"source": "1", "target": "0", "relation": "uses", "confidence": "EXTRACTED", "weight": 0.9},
{"source": "0", "target": "2", "relation": "calls", "confidence": "INFERRED", "weight": 0.7}
]
}
|
소스 코드 ( |
단계 2 : Gradle 플러그인이 Knowledge Graph를 PlantUML로 변환합니다.
파이프라인 아키텍처
플러그인`com.cheroliv.plantuml`작업을 통합한다`generateKnowledgeGraphDiagram`이 변환하는`graph.json`en PlantUML 다이어그램 방식으로완전하게 결정적:
@startuml
skinparam backgroundColor #FEFEFE
participant "Gradle" as G
participant "지식 그래프 다이어그램 생성 작업" as Task
participant "지식 그래프 파서" as Parser
participant "KnowledgeGraphRenderer" as Renderer
participant "PlantumlService" as PS
collections "graphify-out/graph.json" as JSON
G -> Task : execute
Task -> JSON : read
Task -> Parser : parse(graph.json)
Parser --> Task : KnowledgeGraph\n(noeuds + arêtes + communautés)
Task -> Renderer : render(graph, filters)
Renderer --> Task : code PlantUML\n(déterministe)
Task -> PS : validateSyntax(plantumlCode)
alt syntaxe valide
Task -> PS : generateImage → .png
else syntaxe invalide
Task -> Task : save .puml avec warning
end
@enduml
내부 구성 요소
| 구성 요소 | 역할 |
|---|---|
|
파싱`graph.json`— 3가지 형식 지원:네이티브 graphify ( |
|
결정론적으로 변환해`KnowledgeGraph`PlantUML 코드에서. 유형별 그룹, 패키지 내 커뮤니티, 자동 범례. |
|
Gradle 작업이 오케스트레이션: parse → render → validate → PNG. Gradle 속성을 통해 구성 가능. |
|
데이터 모델:`KnowledgeGraph`, |
|
문법 검증 + PNG 렌더링 (플러그인의 모든 작업에서 재사용됨). |
렌더링 규칙
렌더러는 결정적인 시각적 관행을 적용합니다:
| 엣지 타입 | 표기법 PlantUML | 의미 |
|---|---|---|
추출된 |
|
소스 코드에서 추출된 관계 (확실성) |
추론된 |
|
LLM에 의해 추론된 관계 (신뢰 점수) |
모호한 |
|
애매한 관계 (확인 필요) |
커뮤니티는 자동 색상 팔레트가 적용된 PlantUML 패키지처럼 렌더링됩니다.
3단계: 일상 사용
완전한 다이어그램
# Générer le diagramme du Knowledge Graph complet
./gradlew generateKnowledgeGraphDiagram
출력 :`diagrams/knowledge-graph/knowledge-graph-full.puml`+.png
커뮤니티별 필터
# Une seule communauté
./gradlew generateKnowledgeGraphDiagram \
-Pplantuml.kg.community=community_0
# Limiter le nombre de noeuds (lisibilité)
./gradlew generateKnowledgeGraphDiagram \
-Pplantuml.kg.community=community_0 \
-Pplantuml.kg.maxNodes=15
엣지 유형별로 필터링
# Uniquement les relations certaines (EXTRACTED)
./gradlew generateKnowledgeGraphDiagram \
-Pplantuml.kg.edgeTypes=EXTRACTED
# Relations certaines + inférées
./gradlew generateKnowledgeGraphDiagram \
-Pplantuml.kg.edgeTypes=EXTRACTED,INFERRED
노드 유형 및 신뢰도로 필터링
# Uniquement les classes de code
./gradlew generateKnowledgeGraphDiagram \
-Pplantuml.kg.nodeTypes=code
# Seuil de confiance minimum (pour les INFERRED)
./gradlew generateKnowledgeGraphDiagram \
-Pplantuml.kg.minConfidence=0.7
사용자 지정 출력 디렉터리
./gradlew generateKnowledgeGraphDiagram \
-Pplantuml.kg.outputDir=docs/architecture
속성 전체 참조
| 재산 | 결함 | 설명 |
|---|---|---|
|
(모두) |
이름으로 커뮤니티 필터링 (부분 문자열 일치) |
|
(모두) |
콤마로 구분된 모서리 유형:`EXTRACTED`, |
|
|
엣지에 대한 최소 신뢰도 임계값 |
|
(무한한) |
표시할 최대 노드 수 |
|
(모두) |
콤마로 구분된 노드 유형 (예`class`, |
|
|
파일을 위한 출력 디렉터리`.puml` et |
Gradle 워크플로우의 전체 파이프라인
워크플로 유형
@startuml
skinparam backgroundColor #FEFEFE
skinparam ActivityBackgroundColor #E8F4FD
skinparam ActivityDiamondBackgroundColor #FFF3CD
skinparam ActivityBorderColor #2C3E50
start
partition "추출" {
:graphify . --no-viz;
note right: Analyse le code source\ntree-sitter (local, pas de LLM)
:graphify-out/graph.json;
note right: Noeuds + arêtes\n+ communautés
}
partition "세대" {
:./gradlew generateKnowledgeGraphDiagram;
note right: Pipeline déterministe\nparse → render → validate → PNG
if (Filtres actifs ?) then (Oui)
:Appliquer filtres\n(community, edgeTypes,\nmaxNodes, nodeTypes);
else (Non)
:Diagramme complet;
endif
:diagrams/knowledge-graph/\nknowledge-graph-full.puml\nknowledge-graph-full.png;
}
partition "통합" {
:git add diagrams/knowledge-graph/;
:git commit;
note right: Diagrammes versionnés\ntoujours à jour avec le code
}
stop
@enduml
개발 사이클에 통합
파이프라인은 개발의 핵심 단계에 자연스럽게 통합됩니다 :
@startuml skinparam backgroundColor #FEFEFE state "개발" as dev state "추출 graphify . --no-viz" as extract state "생성 ./gradlew generateKnowledgeGraphDiagram" as generate state "커밋 버전 관리된 다이어그램" as commit [*] --> dev dev --> extract : Code modifié extract --> generate : graph.json à jour generate --> commit : .puml + .png générés commit --> dev : Diagrammes dans le repo note right of extract Quasi instantané sur du code Kotlin (tree-sitter, pas de LLM) end note note right of generate Déterministe Pas de LLM Résultat reproductible end note @enduml
증분 업데이트
코드가 변경될 때 전체 그래프를 처음부터 다시 구축하지 않는다:
# Mise à jour incrémentale (fichiers modifiés uniquement)
graphify . --update
# Puis régénérer les diagrammes
./gradlew generateKnowledgeGraphDiagram
|
|
도그푸딩: 플러그인은 스스로를 문서화한다.
PlantUML 플러그인은 프롬프트를 다이어그램으로 변환하기 위해 존재합니다. 또한 자체 propre 코드베이스의 Knowledge Graph를 문서화 다이어그램으로 변환할 수도 있습니다. 이것은 _dogfooding_입니다: 플러그인은 자신의 서비스를 소비합니다.
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
package "정상 파이프라인
(사용자 → 다이어그램)" as normal {
[Fichier .prompt] as prompt
[LlmService\n+ ApiKeyPool] as llm1
[ProcessPlantumlPromptsTask] as task1
[Diagramme PNG] as out1
prompt --> task1
task1 --> llm1
llm1 --> out1
}
package "파이프라인 지식 그래프
(결정적, LLM 없음)" as kg {
[graphify-out/graph.json] as kgjson
[KnowledgeGraphParser] as parser
[KnowledgeGraphRenderer] as renderer
[PlantumlService] as ps
[Diagramme PNG\n(documentation du plugin)] as out2
kgjson --> parser
parser --> renderer
renderer --> ps
ps --> out2
}
package "Pipeline Dogfooding
(LLM → 플러그인 문서)" as dogfood {
[GraphifyPromptAdapter] as gpa
[Fichiers .prompt\nauto-générés] as auto_prompt
[LlmService\n+ ApiKeyPool] as llm2
[ProcessPlantumlPromptsTask] as task2
[Diagramme PNG\n(documentation LLM)] as out3
kgjson --> gpa
gpa --> auto_prompt
auto_prompt --> task2
task2 --> llm2
llm2 --> out3
}
note "LlmService, ApiKeyPool도 동일하고,
PlantumlService도 동일합니다
— 중복 없음" as N
@enduml
연관된 Gradle 작업 :
| 작업 | LLM ? | 설명 |
|---|---|---|
|
아니요 |
변환해`graph.json`PlantUML에서 (결정적) |
|
예 |
생성해`.prompt`그래프에서부터, LLM(도그푸딩)를 통해 그들을 처리한다 |
# Documentation déterministe (rapide, pas de LLM)
./gradlew generateKnowledgeGraphDiagram
# Documentation LLM (plus riche, consomme des tokens)
./gradlew generateDiagramDocs
왜 그것이 결정적이며 (그리고 왜 그것이 중요한가)
파이프라인의 핵심 지점`generateKnowledgeGraphDiagram`:그는 어떤 LLM도 부르지 않는다.. 변환`graph.json`→ PlantUML은 순수 함수이다.
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
rectangle "결정적 파이프라인\n`generateKnowledgeGraphDiagram" as det {
[graph.json] as json
[KnowledgeGraphParser] as parser
[KnowledgeGraphRenderer] as renderer
[PlantUML code] as puml
json --> parser : parse
parser --> renderer : KnowledgeGraph
renderer --> puml : render (fonction pure)
}
rectangle "파이프라인 LLM
(processPlantumlPrompts)" as llm {
[.prompt] as prompt
[LlmService] as llmSvc
[ChatModel] as model
[PlantUML code] as puml2
prompt --> llmSvc
llmSvc --> model : API call
model --> puml2 : réponse non-déterministe
}
note bottom of det
Même entrée → même sortie
Pas de latence réseau
Pas de coût en tokens
Reproductible en CI
end note
note bottom of llm
Même entrée → sortie variable
Latence réseau (1-5s)
Coût en tokens
Nécessite une clave API
end note
@enduml
구체적인 이점:
| 장점 | 영향 |
|---|---|
재현성 |
같은`graph.json`→ 같은 다이어그램입니다. 정확히. 매번. |
제로 비용 |
LLM 호출 없음 = 토큰 없음 = API 청구서 없음 |
지연 없음 |
Parse + render은 약 100ms가 소요되며, 1-5초가 아닙니다. |
CI 호환 |
API 키가 필요하지 않습니다. 변동적인 LLM 응답으로 인한 불안정한 테스트가 없습니다. |
버전 가능 |
Le |
파이프라인 자체 다이어그램
루프를 닫기 위해, 플러그인이 생성할 파이프라인 다이어그램은 다음과 같습니다:
@startuml
skinparam backgroundColor #FEFEFE
participant "개발자" as Dev
participant "그레이들" as G
participant "지식 그래프 다이어그램 생성 태스크" as Task
participant "지식 그래프 파서" as Parser
participant "지식 그래프 렌더러" as Renderer
participant "PlantUML서비스" as PS
collections "graphify-out/graph.json" as JSON
collections "다이어그램/지식-그래프/" as Out
Dev -> G : ./gradlew generateKnowledgeGraphDiagram
G -> Task : execute
Task -> JSON : read
Task -> Parser : parse(graph.json)
Parser --> Task : KnowledgeGraph
alt filtres actifs
Task -> Task : appliquer filtres\n(community, edgeTypes, maxNodes…)
end
Task -> Renderer : render(graph, filters)
Renderer --> Task : code PlantUML
Task -> PS : validateSyntax()
alt valide
Task -> PS : generateImage()
PS --> Out : .puml + .png
else invalide
Task -> Out : .puml (avec warning)
end
@enduml
프로젝트 거버넌스 내 통합
우리 프로젝트에서 이 파이프라인은 AI 에이전트를 위한 EAGER/LAZY 컨텍스트 관리 전략에 통합됩니다. Knowledge Graph는 수동 아키텍처 문서를 구조화되고 질의 가능하며 자동으로 업데이트되는 그래프로 대체합니다.
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
package "EAGER\n(항상 충전된)" as eager {
[PROMPT_REPRISE.adoc\n(contexte session)] as pr
[INDEX.adoc\n(vue d'ensemble)] as idx
[GRAPH_REPORT.adoc\n(~50 lignes)] as gr
}
package "LAZY — 전략
(요청 시)" as lazy_strat {
[Méthodologies] as meth
[Archives sessions] as sessions
}
package "LAZY — Graphify
(대상 쿼리)" as lazy_graph {
[graph.json] as gj
[Queries\n(query/path/explain)] as queries
}
package "Pipeline PlantUML\n(자동 생성된)" as puml {
[generateKnowledgeGraphDiagram] as kgTask
[generateDiagramDocs] as ddTask
[Diagrammes PNG] as diagrams
}
Agent --> eager : Lit en début de session
Agent ..> lazy_strat : Charge si type détecté
Agent ..> lazy_graph : Query si besoin structurel
kgTask --> diagrams : Déterministe
ddTask --> diagrams : Via LLM
note right of gr
Condensé du Knowledge Graph
God nodes + communautés
Remplace ECOSYSTEM_OVERVIEW
(225 lignes → 50 lignes)
end note
@enduml
두 시스템의 결합은 보완적이다 :
-
전략은 언제와 어떻게를 관리합니다— 거버넌스, 워크플로우, 아카이빙
-
Graphify는 무엇과 어디를 관리합니다.— 코드 구조, 관계, 대상 쿼리
__ 세션 전략이 관리하는언제 et le 어떻게(거버넌스, 워크플로우, 임계값), Graphify가 관리하는뭐 et le 어디(코드 구조, 관계, 대상 쿼리). 이 PlantUML 파이프라인이 그것을 관리한다.무엇으로(결정적, 버전 관리된, 항상 최신 상태인 다이어그램). </think>
준비 : 5분 체크리스트
| # | 단계 | 명령 |
|---|---|---|
1 |
Graphify 설치 |
|
2 |
제외 사항 구성 |
만들다`.graphifyignore` |
3 |
Knowledge Graph 추출 |
|
4 |
다이어그램 생성 |
|
5 |
결과를 커밋하다 |
|
# Script complet en 5 commandes
uv tool install graphifyy
cat > .graphifyignore << 'EOF'
*-context.yml
*.env
build/
.gradle/
EOF
graphify . --no-viz
./gradlew generateKnowledgeGraphDiagram
git add graphify-out/GRAPH_REPORT.adoc graphify-out/graph.json diagrams/knowledge-graph/
함정 및 완화 방안
| 함정 | 설명 | 완화 |
|---|---|---|
너무 빽빽한 그래프 |
큰 프로젝트는 수백 개의 읽을 수 없는 노드를 생성한다 |
사용하다`-Pplantuml.kg.maxNodes=30`그리고 커뮤니티별로 필터링 |
너무 넓은 제외 사항 |
안에 파일이 너무 많음`.graphifyignore`그래프의 값을 줄입니다 |
먼저 credentials와 build만 제외하고 시작 |
화살표의 방향 |
INFERRED 엣지는 방향이 모호할 수 있다. |
필터 기준`-Pplantuml.kg.edgeTypes=EXTRACTED`확실한 관계에만 |
구식 그래프 |
코드가 변경되지만 그래프는 재구축되지 않습니다. |
사용하다`graphify . --update`정기적으로 또는 git 후크`graphify hook install` |
업데이트된 비용 |
증분 업데이트는 거의 무료입니다 (tree-sitter 로컬) |
문서들만 ( |
최종적으로 얻는 것
@startuml
skinparam backgroundColor #FEFEFE
rectangle "이전" as avant {
card "수작업으로 그린 다이어그램
항상 구식
아무도 업데이트하지 않는다" as av1 #FDEDEC
}
rectangle "후" as apres {
card "자동 생성된 다이어그램\n항상 코드와 최신 상태\nGit에서 버전 관리됨\n결정적이고 재현 가능" as ap1 #E8F8E8
}
avant --> apres : graphify . --no-viz\n+ ./gradlew generateKnowledgeGraphDiagram
@enduml
구체적인 혜택 :
| 수익 | 세부 |
|---|---|
항상 최신 문서 |
다이어그램은 현재 코드를 반영하고, 수동 스냅샷이 아닙니다. |
유지보수 노력이 제로 |
다이어그램은 매 빌드마다 재생성됩니다. |
기술 부채 감소 |
더 이상 다이어그램을 수동으로 유지할 필요가 없습니다 |
새로운 것을 위한 시각적 컨텍스트 |
새로운 개발자는 다이어그램을 보고 아키텍처를 이해한다. |
파인튜닝 잠재력 |
서브그래프 → 다이어그램 쌍은 AI 훈련의 예시입니다. |
자동 검증 |
`PlantumlService.validateSyntax()`생성된 각 다이어그램을 확인합니다 |
빠른 온보딩 |
5개의 다이어그램 = 아키텍처의 완전한 뷰 |
_ _pourquoi_를 가진 사람은 모든 _comment_을 견딜 수 있다. _
왜 : 항상 최신인 다이어그램. 어떻게 : Gradle 파이프라인 내의 두 명령어.
링크
-
fg 명령의 슈퍼 팁— 터미널 워크플로우에 대한 이전 기사
관련 기사
31 May 2026
14 May 2026