Graphviz가 필요할까? 직접 만들면 되는데?
(spidermonkey.dev)- SpiderMonkey 엔진의 JavaScript·WebAssembly 컴파일 과정을 시각화하기 위해 내부 도구를 전면 개편, 인터랙티브 그래프를 생성하는 기능 구현
- 기존 Graphviz 기반 iongraph는 불안정한 레이아웃과 비직관적 구조로 인해 디버깅 효율이 낮았으며, 이를 대체하기 위해 새로운 레이아웃 알고리듬을 직접 설계
- 새 알고리듬은 Sugiyama 방식을 단순화해 루프 구조를 명확히 표현하고, 안정적·고속 레이아웃을 1000줄 미만의 JavaScript 코드로 구현
- 그래프는 철도 다이어그램 스타일의 직선 엣지를 사용해 가독성을 높이고, Graphviz 대비 수천 배 빠른 렌더링 속도 달성
- 이 도구는 Firefox 프로파일러에 통합되어 있으며, 향후 검색·레지스터 시각화 기능 등 확장 계획 존재
SpiderMonkey의 시각화 도구 개편
- SpiderMonkey의 Ion 최적화 컴파일러가 생성하는 내부 그래프를 시각화하기 위해 도구를 새로 구축
- 사용자는 웹 페이지에서 JavaScript 코드를 입력해 함수 최적화 과정을 실시간 그래프로 탐색 가능
- 그래프는 드래그·줌·슬라이더 조작으로 단계별 변화를 확인할 수 있음
- 기존 Graphviz 기반 iongraph는 PDF 출력을 생성했으나, 소스 코드 구조와 불일치하고 출력 불안정성이 심각했음
- 작은 코드 변경에도 노드 위치가 크게 바뀌어 패스 간 비교가 어려움
- 루프·조건문 구조가 시각적으로 왜곡되어 제어 흐름 파악이 어려움
Graphviz 한계와 새로운 접근
- Graphviz의 Sugiyama 알고리듬은 일반 그래프 최적화에 적합하지만, 제어 흐름 그래프(CFG) 의 특성을 반영하지 못함
- JavaScript·WebAssembly의 루프는 단일 진입점만 가지며, 감소 가능한(reducible) 제어 흐름을 가짐
- SpiderMonkey 팀은 이러한 제약을 활용해 단순화된 전용 알고리듬을 설계
- 사이클 제거: 루프 백엣지를 무시
- 계층화(Leveling) : 루프 이후 블록을 아래로 배치해 코드 흐름을 반영
- 교차 최소화 생략: 안정성을 우선시해 true/false 분기 순서를 고정
- 루프 트리 구조 보존: 중첩 루프를 시각적으로 명확히 표현
- 결과적으로 간결·고속·안정적 레이아웃을 달성, 초기 구현은 약 1000줄의 JavaScript로 구성
iongraph 레이아웃 알고리듬 단계
-
1단계: Layering
- 블록을 계층별로 정렬하고, 루프 내부·외부 관계를 반영
- 루프 종료 후 블록은 루프 전체 높이만큼 아래로 배치
-
2단계: 더미 노드 생성
- 여러 계층을 가로지르는 엣지에 더미 노드를 추가해 시각적 충돌 방지
- 동일 목적지로 향하는 엣지는 병합해 시각적 노이즈 감소
-
3단계: 엣지 정렬(Straighten)
- 부모·자식 노드를 정렬해 수직선 형태 유지, 루프 들여쓰기 적용
- 더미 노드도 정렬 과정에 참여해 겹침 방지 및 구조 보존
-
4단계: 수평 엣지 트래킹
- 수평 엣지가 겹치지 않도록 트랙(track) 단위로 정렬
- 엣지 방향에 따라 상·하로 분리하고, 병합 가능한 엣지는 하나로 묶음
-
5단계: 수직 배치(Verticalize)
- 각 계층에 Y좌표를 부여해 균일한 높이 배치, 가독성 향상
-
6단계: 렌더링(Render)
- 철도 다이어그램 스타일의 직선 엣지를 사용
- 엣지는 수직·수평으로만 교차하며, 방향성과 구조가 명확
단순 알고리듬의 효과
- 복잡한 최적화 대신 예측 가능한 규칙 기반 배치로 가독성과 안정성 확보
- 노드 순서 고정, 엣지 단순화로 패스 간 일관성 유지
-
제약 해석기(Constraint Solver) 를 배제함으로써 사람이 이해하기 쉬운 구조 구현
- 루프 내부 배치나 후속 블록 하향 배치 등 의미 중심 설계 가능
-
성능 향상: Graphviz가 10분 걸리던 zlib 함수 그래프를 20밀리초에 렌더링
- 수천 배 빠른 속도와 더 나은 탐색성 확보
향후 계획
Hacker News 의견
-
비교를 정확히 하자면 Graphviz 전체가 아니라 dot(1) 과의 비교임
Graphviz는 여러 레이아웃 엔진(dot, neato, fdp, sfdp, circo, twopi 등)을 포함한 시각화 프레임워크임
새로 제안된 알고리즘이 Graphviz에 기여된다면 정말 멋질 것 같음- 약간 혼란스러움. dot은 Graphviz의 문법 언어 이름이자 동시에 레이아웃 엔진 이름이기도 함
관련 문서는 Graphviz 언어 설명과 dot 레이아웃 엔진 문서 참고 - iongraph 알고리즘의 일반화 가능성이 얼마나 될지 확신이 없음
제어 흐름 그래프(CFG) 중 reducible control flow를 가진 경우엔 잘 작동할 수 있겠지만, 복잡한 예외가 많을 것 같음 - iongraph는 MPL, Graphviz는 EPL 라이선스임
게다가 iongraph는 JavaScript 기반이라 Graphviz에 통합하려면 Claude 같은 도구로 C로 변환해야 함
- 약간 혼란스러움. dot은 Graphviz의 문법 언어 이름이자 동시에 레이아웃 엔진 이름이기도 함
-
알고리즘의 원본 구현을 직접 살펴보는 능력이 진짜 슈퍼파워 같음
Graphviz로 복잡한 시각화를 해본 입장에서 누군가가 직접 재구현했다는 게 처음엔 놀라웠음
하지만 알고리즘 구조를 보고 나니 생각보다 단순할 수도 있겠다는 깨달음이 있었음
다만 실제 구현을 끝내기 전까지는 숨은 복잡성을 알기 어렵다는 점은 여전함 -
일반 알고리즘을 특정 문제 영역에 특화하면 훨씬 좋은 결과를 얻을 수 있음
하지만 대부분의 경우 우리는 편의상 범용 알고리즘을 그대로 씀- 나도 이 주제로 논문을 썼음
특정 애플리케이션에 맞춘 시스템 설계는 성능, 확장성, 내결함성 모두에서 큰 향상을 줌
하지만 1000배 개선을 노리다 보면 1~2년은 금방 지나감 - 이 말에 동의하지만, 특정 도메인에서는 ‘단순한 알고리즘’이 오히려 더 잘 작동할 때가 있음
일반 그래프 레이아웃 시스템은 훨씬 다양한 경우를 처리해야 하므로 복잡해질 수밖에 없음
그래서 입력을 분석해 특수 케이스에선 빠른 알고리즘을, 그 외엔 보장된 일반 알고리즘을 쓰는 절충이 좋다고 생각함
- 나도 이 주제로 논문을 썼음
-
좋은 글이었음. 참고로 Graphviz의 dot은 Sugiyama 알고리즘의 순수 구현이 아님
실제 구현은 사이트의 논문에 자세히 나와 있음
큰 그래프에서 dot과 iongraph를 비교한 이미지를 보면 dot은 면적 최소화에 최적화되어 있고, iongraph는 그렇지 않음
큰 그래프 시각화는 보기엔 멋지지만 실제로는 도움이 되는 경우가 드묾- 큰 그래프 시각화는 ‘타르 구덩이 아이디어’ 같음 — 처음엔 매력적이지만 실제로는 거의 실패함
시각화는 수십 개의 노드까지만 유효하고, 그 이상은 엣지 복잡성 때문에 이해가 어려워짐
결국 단순한 예시에서만 잘 작동하고, 복잡한 환경에서는 오히려 방해가 됨 - 나도 큰 그래프에서 얻는 게 많지 않다고 느낌
대부분의 문제는 작은 단위로 축소 가능함
다만 Graphviz는 작은 그래프에서도 미적으로 별로인데, iongraph는 선의 가독성이 훨씬 좋음
장기적으로는 검색, 강조/감춤 기능 같은 인터랙티브 요소가 필요하다고 생각함 - 나도 같은 생각임. 관련 글 On Layers and Boxes and Lines 참고
다이어그램이 링크를 내보내거나 받아들이지 못하는 한계가 답답함
Mermaid도 텍스트 링크는 되지만 다이어그램 링크는 제한적임
StackOverflow의 관련 논의도 참고할 만함
이런 기능이 설계 단계에서 1급 기능으로 고려된 도구가 필요함 - CMake의 의존성 그래프도 Graphviz를 쓰지만, 큰 다이어그램은 부분 확대/축소 탐색 기능이 꼭 필요함
- 큰 그래프 시각화는 ‘타르 구덩이 아이디어’ 같음 — 처음엔 매력적이지만 실제로는 거의 실패함
-
Graphviz의 진짜 강점은 dot 언어임
dot으로 정의된 그래프는 여러 도구 간 호환성이 뛰어나고, 문법이 단순하고 읽기 쉬움
Mermaid 같은 대안이 생겼지만 dot은 여전히 표준 포맷으로 오래갈 것 같음- “현상 유지가 제일 좋아요! 왜냐면 그게 현상 유지니까요.”라는 농담이 떠오름
-
정말 멋진 글이었음
혹시 이런 기법들이 D2의 TALA 레이아웃 엔진에도 쓰였는지 궁금함
TALA 예시 보기 -
그래프 드로잉에 관심 있다면 Will Evans의 강의(링크)를 추천함
나는 예전에 Open Graph Drawing Framework(OGDF) 의 Dot lexer에 버그픽스를 기여했는데,
OGDF는 Graphviz보다 교차점이 적고 빠른 알고리즘을 구현함
내 경험상 OGDF의 결과물이 훨씬 깔끔했음
관련 PR 기록은 GitHub 링크 참고 -
흥미로움. 예제는 어떻게 실행하는지 궁금함
-
이 프로젝트의 좋은 점은 웹 클라이언트 환경을 전제로 한 인터랙티브 탐색 지원임
제어 흐름 그래프(CFG)에 특화된 레이아웃이라 도메인 맞춤형 시각화가 가능함
Graphviz에도 폴리라인, 엣지 순서 제어 기능이 있지만 문서화가 부족함
Brandes와 Kopf의 엣지 라우팅 알고리즘을 통합하면 좋을 듯함
Graphviz는 40년 가까이 된 프로젝트로, 현재는 2세대 자원봉사자 몇 명이 유지 중임
도구 제작은 항상 어려운 시장이고, 사용자들은 똑똑하지만 예산이 적은 부서에 속해 있음
선언적 2D 다이어그램 도구의 발전이 느린 현실이 아쉬움 -
이런 분야에서 일하는 사람은 언제나 +1 응원임
나도 mermaid와 graphviz를 써봤지만, 결국 FigJam으로 돌아감 — 가독성과 미적 완성도가 높음
graphviz는 거대한 바이너리, mermaid는 브라우저 SVG 렌더링 의존이라 불편함
단순히 텍스트로 다이어그램을 쉽게 만드는 도구가 필요함- 이런 도구들의 문제는 노드 수가 많아지면 읽기 어려워지는 한계임
저자가 제시한 접근은 이 절충점을 제어하려는 좋은 시도라고 생각함 - 나는 mermaid를 이용해 자동 생성한 프로젝트 문서를 써봤는데 꽤 잘 작동했음
루프를 처리하지 않았다는 점만 빼면 만족스러웠음
SVG/HTML 출력은 스타일 수정과 복사에 유리함 - D2도 살펴볼 만함. 최근 HN 프론트페이지에 올라온 글 참고
- graphviz 코드가 얼마나 큰지 궁금해서 봤더니 25만 줄 이상이었음
텍스트 기반 다이어그램 도구를 원한다면 TikZ를 추천함
TikZ 위키 참고
다만 FigJam 같은 즉각적 시각 피드백은 없음 - 나는 resvg-js(링크)와 dagre/graphlib(링크)를 조합해 렌더링에 성공했음
mermaid의 의존성 과다와 코드 일관성 부족이 마음에 들지 않았음
대신 nomnoml(링크)은 코드가 깔끔하고 Typescript로 포팅된 graphre(링크)도 있음
mermaid를 resvg-js와 함께 쓰려면 SVG 텍스트 폭 측정 관련 리팩터링이 필요함
- 이런 도구들의 문제는 노드 수가 많아지면 읽기 어려워지는 한계임