비교를 정확히 하자면 Graphviz 전체가 아니라 dot(1) 과의 비교임
Graphviz는 여러 레이아웃 엔진(dot, neato, fdp, sfdp, circo, twopi 등)을 포함한 시각화 프레임워크임
새로 제안된 알고리즘이 Graphviz에 기여된다면 정말 멋질 것 같음
iongraph 알고리즘의 일반화 가능성이 얼마나 될지 확신이 없음
제어 흐름 그래프(CFG) 중 reducible control flow를 가진 경우엔 잘 작동할 수 있겠지만, 복잡한 예외가 많을 것 같음
iongraph는 MPL, Graphviz는 EPL 라이선스임
게다가 iongraph는 JavaScript 기반이라 Graphviz에 통합하려면 Claude 같은 도구로 C로 변환해야 함
알고리즘의 원본 구현을 직접 살펴보는 능력이 진짜 슈퍼파워 같음
Graphviz로 복잡한 시각화를 해본 입장에서 누군가가 직접 재구현했다는 게 처음엔 놀라웠음
하지만 알고리즘 구조를 보고 나니 생각보다 단순할 수도 있겠다는 깨달음이 있었음
다만 실제 구현을 끝내기 전까지는 숨은 복잡성을 알기 어렵다는 점은 여전함
일반 알고리즘을 특정 문제 영역에 특화하면 훨씬 좋은 결과를 얻을 수 있음
하지만 대부분의 경우 우리는 편의상 범용 알고리즘을 그대로 씀
나도 이 주제로 논문을 썼음
특정 애플리케이션에 맞춘 시스템 설계는 성능, 확장성, 내결함성 모두에서 큰 향상을 줌
하지만 1000배 개선을 노리다 보면 1~2년은 금방 지나감
이 말에 동의하지만, 특정 도메인에서는 ‘단순한 알고리즘’이 오히려 더 잘 작동할 때가 있음
일반 그래프 레이아웃 시스템은 훨씬 다양한 경우를 처리해야 하므로 복잡해질 수밖에 없음
그래서 입력을 분석해 특수 케이스에선 빠른 알고리즘을, 그 외엔 보장된 일반 알고리즘을 쓰는 절충이 좋다고 생각함
좋은 글이었음. 참고로 Graphviz의 dot은 Sugiyama 알고리즘의 순수 구현이 아님
실제 구현은 사이트의 논문에 자세히 나와 있음
큰 그래프에서 dot과 iongraph를 비교한 이미지를 보면 dot은 면적 최소화에 최적화되어 있고, iongraph는 그렇지 않음
큰 그래프 시각화는 보기엔 멋지지만 실제로는 도움이 되는 경우가 드묾
큰 그래프 시각화는 ‘타르 구덩이 아이디어’ 같음 — 처음엔 매력적이지만 실제로는 거의 실패함
시각화는 수십 개의 노드까지만 유효하고, 그 이상은 엣지 복잡성 때문에 이해가 어려워짐
결국 단순한 예시에서만 잘 작동하고, 복잡한 환경에서는 오히려 방해가 됨
나도 큰 그래프에서 얻는 게 많지 않다고 느낌
대부분의 문제는 작은 단위로 축소 가능함
다만 Graphviz는 작은 그래프에서도 미적으로 별로인데, iongraph는 선의 가독성이 훨씬 좋음
장기적으로는 검색, 강조/감춤 기능 같은 인터랙티브 요소가 필요하다고 생각함
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 렌더링 의존이라 불편함
단순히 텍스트로 다이어그램을 쉽게 만드는 도구가 필요함
이런 도구들의 문제는 노드 수가 많아지면 읽기 어려워지는 한계임
저자가 제시한 접근은 이 절충점을 제어하려는 좋은 시도라고 생각함
graphviz 코드가 얼마나 큰지 궁금해서 봤더니 25만 줄 이상이었음
텍스트 기반 다이어그램 도구를 원한다면 TikZ를 추천함 TikZ 위키 참고
다만 FigJam 같은 즉각적 시각 피드백은 없음
나는 resvg-js(링크)와 dagre/graphlib(링크)를 조합해 렌더링에 성공했음
mermaid의 의존성 과다와 코드 일관성 부족이 마음에 들지 않았음
대신 nomnoml(링크)은 코드가 깔끔하고 Typescript로 포팅된 graphre(링크)도 있음
mermaid를 resvg-js와 함께 쓰려면 SVG 텍스트 폭 측정 관련 리팩터링이 필요함
Hacker News 의견
비교를 정확히 하자면 Graphviz 전체가 아니라 dot(1) 과의 비교임
Graphviz는 여러 레이아웃 엔진(dot, neato, fdp, sfdp, circo, twopi 등)을 포함한 시각화 프레임워크임
새로 제안된 알고리즘이 Graphviz에 기여된다면 정말 멋질 것 같음
관련 문서는 Graphviz 언어 설명과 dot 레이아웃 엔진 문서 참고
제어 흐름 그래프(CFG) 중 reducible control flow를 가진 경우엔 잘 작동할 수 있겠지만, 복잡한 예외가 많을 것 같음
게다가 iongraph는 JavaScript 기반이라 Graphviz에 통합하려면 Claude 같은 도구로 C로 변환해야 함
알고리즘의 원본 구현을 직접 살펴보는 능력이 진짜 슈퍼파워 같음
Graphviz로 복잡한 시각화를 해본 입장에서 누군가가 직접 재구현했다는 게 처음엔 놀라웠음
하지만 알고리즘 구조를 보고 나니 생각보다 단순할 수도 있겠다는 깨달음이 있었음
다만 실제 구현을 끝내기 전까지는 숨은 복잡성을 알기 어렵다는 점은 여전함
일반 알고리즘을 특정 문제 영역에 특화하면 훨씬 좋은 결과를 얻을 수 있음
하지만 대부분의 경우 우리는 편의상 범용 알고리즘을 그대로 씀
특정 애플리케이션에 맞춘 시스템 설계는 성능, 확장성, 내결함성 모두에서 큰 향상을 줌
하지만 1000배 개선을 노리다 보면 1~2년은 금방 지나감
일반 그래프 레이아웃 시스템은 훨씬 다양한 경우를 처리해야 하므로 복잡해질 수밖에 없음
그래서 입력을 분석해 특수 케이스에선 빠른 알고리즘을, 그 외엔 보장된 일반 알고리즘을 쓰는 절충이 좋다고 생각함
좋은 글이었음. 참고로 Graphviz의 dot은 Sugiyama 알고리즘의 순수 구현이 아님
실제 구현은 사이트의 논문에 자세히 나와 있음
큰 그래프에서 dot과 iongraph를 비교한 이미지를 보면 dot은 면적 최소화에 최적화되어 있고, iongraph는 그렇지 않음
큰 그래프 시각화는 보기엔 멋지지만 실제로는 도움이 되는 경우가 드묾
시각화는 수십 개의 노드까지만 유효하고, 그 이상은 엣지 복잡성 때문에 이해가 어려워짐
결국 단순한 예시에서만 잘 작동하고, 복잡한 환경에서는 오히려 방해가 됨
대부분의 문제는 작은 단위로 축소 가능함
다만 Graphviz는 작은 그래프에서도 미적으로 별로인데, iongraph는 선의 가독성이 훨씬 좋음
장기적으로는 검색, 강조/감춤 기능 같은 인터랙티브 요소가 필요하다고 생각함
다이어그램이 링크를 내보내거나 받아들이지 못하는 한계가 답답함
Mermaid도 텍스트 링크는 되지만 다이어그램 링크는 제한적임
StackOverflow의 관련 논의도 참고할 만함
이런 기능이 설계 단계에서 1급 기능으로 고려된 도구가 필요함
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 렌더링 의존이라 불편함
단순히 텍스트로 다이어그램을 쉽게 만드는 도구가 필요함
저자가 제시한 접근은 이 절충점을 제어하려는 좋은 시도라고 생각함
루프를 처리하지 않았다는 점만 빼면 만족스러웠음
SVG/HTML 출력은 스타일 수정과 복사에 유리함
텍스트 기반 다이어그램 도구를 원한다면 TikZ를 추천함
TikZ 위키 참고
다만 FigJam 같은 즉각적 시각 피드백은 없음
mermaid의 의존성 과다와 코드 일관성 부족이 마음에 들지 않았음
대신 nomnoml(링크)은 코드가 깔끔하고 Typescript로 포팅된 graphre(링크)도 있음
mermaid를 resvg-js와 함께 쓰려면 SVG 텍스트 폭 측정 관련 리팩터링이 필요함