# Graphviz가 필요할까? 직접 만들면 되는데? > Clean Markdown view of GeekNews topic #24024. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24024](https://news.hada.io/topic?id=24024) - GeekNews Markdown: [https://news.hada.io/topic/24024.md](https://news.hada.io/topic/24024.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-10-30T22:33:08+09:00 - Updated: 2025-10-30T22:33:08+09:00 - Original source: [spidermonkey.dev](https://spidermonkey.dev/blog/2025/10/28/iongraph-web.html) - Points: 3 - Comments: 1 ## Topic Body - **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밀리초**에 렌더링 - 수천 배 빠른 속도와 더 나은 탐색성 확보 ### 향후 계획 - **Firefox 프로파일러**에 iongraph 통합 완료, 성능 분석 시 그래프 확인 가능 - 현재는 SpiderMonkey 셸 빌드에서만 사용 가능, 브라우저 빌드에는 미포함 - 향후 기능 제안 - **고급 탐색 기능**, **검색**, **레지스터 할당 시각화** 등 - 명확한 로드맵은 없으며, **오픈소스 기여**를 환영 - 로컬 실험은 `IONFLAGS=logs` 설정으로 `/tmp/ion.json` 생성 후 [독립 배포판](https://mozilla-spidermonkey.github.io/iongraph/)에서 로드 가능 - 소스코드는 [GitHub](https://github.com/mozilla-spidermonkey/iongraph)에 공개되어 있으며, **Matrix 채팅방**을 통해 개발자와 직접 소통 가능 ## Comments ### Comment 45672 - Author: neo - Created: 2025-10-30T22:33:09+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45742907) - 비교를 정확히 하자면 Graphviz 전체가 아니라 **dot(1)** 과의 비교임 Graphviz는 여러 **레이아웃 엔진**(dot, neato, fdp, sfdp, circo, twopi 등)을 포함한 시각화 프레임워크임 새로 제안된 알고리즘이 Graphviz에 기여된다면 정말 멋질 것 같음 - 약간 혼란스러움. dot은 Graphviz의 **문법 언어 이름**이자 동시에 **레이아웃 엔진 이름**이기도 함 관련 문서는 [Graphviz 언어 설명](https://graphviz.org/doc/info/lang.html)과 [dot 레이아웃 엔진 문서](https://graphviz.org/docs/layouts/dot/) 참고 - iongraph 알고리즘의 **일반화 가능성**이 얼마나 될지 확신이 없음 제어 흐름 그래프(CFG) 중 **reducible control flow**를 가진 경우엔 잘 작동할 수 있겠지만, 복잡한 예외가 많을 것 같음 - iongraph는 MPL, Graphviz는 EPL 라이선스임 게다가 iongraph는 **JavaScript 기반**이라 Graphviz에 통합하려면 **Claude 같은 도구로 C로 변환**해야 함 - 알고리즘의 **원본 구현을 직접 살펴보는 능력**이 진짜 슈퍼파워 같음 Graphviz로 복잡한 시각화를 해본 입장에서 누군가가 직접 재구현했다는 게 처음엔 놀라웠음 하지만 알고리즘 구조를 보고 나니 생각보다 단순할 수도 있겠다는 깨달음이 있었음 다만 실제 구현을 끝내기 전까지는 **숨은 복잡성**을 알기 어렵다는 점은 여전함 - **일반 알고리즘을 특정 문제 영역에 특화**하면 훨씬 좋은 결과를 얻을 수 있음 하지만 대부분의 경우 우리는 편의상 범용 알고리즘을 그대로 씀 - 나도 이 주제로 **논문을 썼음** 특정 애플리케이션에 맞춘 시스템 설계는 **성능, 확장성, 내결함성** 모두에서 큰 향상을 줌 하지만 1000배 개선을 노리다 보면 1~2년은 금방 지나감 - 이 말에 동의하지만, 특정 도메인에서는 **‘단순한 알고리즘’이 오히려 더 잘 작동**할 때가 있음 일반 그래프 레이아웃 시스템은 훨씬 다양한 경우를 처리해야 하므로 복잡해질 수밖에 없음 그래서 입력을 분석해 특수 케이스에선 빠른 알고리즘을, 그 외엔 **보장된 일반 알고리즘**을 쓰는 절충이 좋다고 생각함 - 좋은 글이었음. 참고로 Graphviz의 dot은 **Sugiyama 알고리즘의 순수 구현**이 아님 실제 구현은 [사이트의 논문](https://graphviz.org/)에 자세히 나와 있음 큰 그래프에서 dot과 iongraph를 비교한 이미지를 보면 dot은 **면적 최소화**에 최적화되어 있고, iongraph는 그렇지 않음 큰 그래프 시각화는 보기엔 멋지지만 실제로는 **도움이 되는 경우가 드묾** - 큰 그래프 시각화는 **‘타르 구덩이 아이디어’** 같음 — 처음엔 매력적이지만 실제로는 거의 실패함 시각화는 수십 개의 노드까지만 유효하고, 그 이상은 **엣지 복잡성** 때문에 이해가 어려워짐 결국 단순한 예시에서만 잘 작동하고, 복잡한 환경에서는 오히려 방해가 됨 - 나도 큰 그래프에서 얻는 게 많지 않다고 느낌 대부분의 문제는 작은 단위로 축소 가능함 다만 Graphviz는 작은 그래프에서도 **미적으로 별로**인데, iongraph는 **선의 가독성**이 훨씬 좋음 장기적으로는 **검색, 강조/감춤 기능** 같은 인터랙티브 요소가 필요하다고 생각함 - 나도 같은 생각임. 관련 글 [On Layers and Boxes and Lines](https://jerf.org/iri/post/2025/on_layers_and_boxes_and_lines/) 참고 다이어그램이 **링크를 내보내거나 받아들이지 못하는 한계**가 답답함 Mermaid도 텍스트 링크는 되지만 다이어그램 링크는 제한적임 [StackOverflow의 관련 논의](https://stackoverflow.com/questions/41960529/how-to-add-a-link-in-a-mermaid-node-description)도 참고할 만함 이런 기능이 **설계 단계에서 1급 기능으로 고려된 도구**가 필요함 - CMake의 **의존성 그래프**도 Graphviz를 쓰지만, 큰 다이어그램은 **부분 확대/축소 탐색** 기능이 꼭 필요함 - Graphviz의 진짜 강점은 **dot 언어**임 dot으로 정의된 그래프는 **여러 도구 간 호환성**이 뛰어나고, 문법이 단순하고 읽기 쉬움 Mermaid 같은 대안이 생겼지만 dot은 여전히 **표준 포맷**으로 오래갈 것 같음 - “현상 유지가 제일 좋아요! 왜냐면 그게 현상 유지니까요.”라는 농담이 떠오름 - 정말 멋진 글이었음 혹시 이런 기법들이 D2의 **TALA 레이아웃 엔진**에도 쓰였는지 궁금함 [TALA 예시 보기](https://d2lang.com/examples/tala/) - 그래프 드로잉에 관심 있다면 **Will Evans의 강의**([링크](https://www.cs.ubc.ca/~will/536E/))를 추천함 나는 예전에 **Open Graph Drawing Framework(OGDF)** 의 Dot lexer에 버그픽스를 기여했는데, OGDF는 Graphviz보다 **교차점이 적고 빠른 알고리즘**을 구현함 내 경험상 OGDF의 결과물이 훨씬 깔끔했음 관련 PR 기록은 [GitHub 링크](https://github.com/ogdf/ogdf/pulls?q=is%3Apr%20author%3Adllu%20is%3Aclosed) 참고 - 흥미로움. 예제는 **어떻게 실행하는지** 궁금함 - 이 프로젝트의 좋은 점은 **웹 클라이언트 환경을 전제로 한 인터랙티브 탐색 지원**임 제어 흐름 그래프(CFG)에 특화된 레이아웃이라 **도메인 맞춤형 시각화**가 가능함 Graphviz에도 **폴리라인, 엣지 순서 제어** 기능이 있지만 문서화가 부족함 Brandes와 Kopf의 **엣지 라우팅 알고리즘**을 통합하면 좋을 듯함 Graphviz는 40년 가까이 된 프로젝트로, 현재는 2세대 자원봉사자 몇 명이 유지 중임 도구 제작은 항상 어려운 시장이고, 사용자들은 똑똑하지만 **예산이 적은 부서**에 속해 있음 **선언적 2D 다이어그램 도구의 발전이 느린 현실**이 아쉬움 - 이런 분야에서 일하는 사람은 언제나 **+1 응원**임 나도 **mermaid와 graphviz**를 써봤지만, 결국 **FigJam**으로 돌아감 — 가독성과 미적 완성도가 높음 graphviz는 **거대한 바이너리**, mermaid는 **브라우저 SVG 렌더링** 의존이라 불편함 단순히 **텍스트로 다이어그램을 쉽게 만드는 도구**가 필요함 - 이런 도구들의 문제는 노드 수가 많아지면 **읽기 어려워지는 한계**임 저자가 제시한 접근은 이 **절충점을 제어**하려는 좋은 시도라고 생각함 - 나는 [mermaid를 이용해 자동 생성한 프로젝트 문서](https://basisrobotics.tech/2024/11/24/basis-robot-02-software/)를 써봤는데 꽤 잘 작동했음 루프를 처리하지 않았다는 점만 빼면 만족스러웠음 **SVG/HTML 출력**은 스타일 수정과 복사에 유리함 - **D2**도 살펴볼 만함. 최근 [HN 프론트페이지에 올라온 글](https://news.ycombinator.com/item?id=45707539) 참고 - graphviz 코드가 얼마나 큰지 궁금해서 봤더니 **25만 줄 이상**이었음 텍스트 기반 다이어그램 도구를 원한다면 **TikZ**를 추천함 [TikZ 위키](https://en.wikipedia.org/wiki/PGF/TikZ) 참고 다만 FigJam 같은 **즉각적 시각 피드백**은 없음 - 나는 **resvg-js**([링크](https://github.com/thx/resvg-js))와 **dagre/graphlib**([링크](https://github.com/dagrejs/dagre))를 조합해 렌더링에 성공했음 mermaid의 **의존성 과다와 코드 일관성 부족**이 마음에 들지 않았음 대신 **nomnoml**([링크](https://github.com/skanaar/nomnoml))은 코드가 깔끔하고 Typescript로 포팅된 **graphre**([링크](https://github.com/skanaar/graphre))도 있음 mermaid를 resvg-js와 함께 쓰려면 **SVG 텍스트 폭 측정** 관련 리팩터링이 필요함