요약
Mermaid 다이어그램을 SVG로 가볍고 빠르게 그려 주는 오픈소스 라이브러리 Pele가 나왔습니다.
Mermaid는 텍스트로 순서도 같은 다이어그램을 그리는 문법입니다. 노트 앱 Obsidian에서 다이어그램을 빠르게 그리고 사용자 테마에 맞추려고 kepano가 만들었고, MIT 라이선스로 공개했습니다.
왜 중요한가
- 공식 라이브러리 Mermaid.js보다 훨씬 작고 빨라서, 다이어그램을 많이 띄우는 문서·노트 앱의 부담이 줄어듭니다.
- 색을 CSS 변수로 정하므로 다크 모드나 사이트 테마에 맞추려고 다시 그릴 필요가 없습니다.
- 댓글에 따르면 브라우저를 띄워야 했던 정적 사이트 빌드에서도 가볍게 대신 쓸 수 있습니다.
핵심 내용
- Mermaid 12.1.0에 들어 있는 다이어그램 종류를 모두 지원하고, 직접 의존성은 하나도 없습니다(Mermaid.js는 23개).
- gzip 압축 기준 크기는 230kB로, 1.6MB인 Mermaid.js의 약 6분의 1입니다.
- 그리는 데 0.05~0.3ms가 걸려, 6~82ms인 Mermaid.js보다 최대 500배 빠르다고 밝혔습니다.
--pele-bg,--pele-fg같은 CSS 변수로 색과 글꼴을 바꾸며, 바꿔도 다시 렌더링하지 않습니다.- 작은 화면에서는 그림을 줄이는 대신 배치 자체를 바꿉니다.
HN 반응
- 복잡한 그림에서 Mermaid의 배치가 엉성하다는 불만에, kepano는 Pele가 문법만 따르고 배치는 따로 짰다고 답했습니다.
- 문서 사이트와 빌드 스크립트에서 Mermaid.js를 Pele로 바꾼 이용자들은 배치가 오히려 더 낫다고 평가했고, D2 같은 대안을 권하는 댓글도 있었습니다.
문법이 더 쉽고, Mermaid가 AI를 너무 밀어붙여서 저는 D2Lang으로 갈아탔습니다. 그래도 Mermaid를 조금은 쓸 만하게 만들어 주셔서 감사합니다, Kepano.
새로운 변화를 호기심으로 맞이하는 기술이 유사 종교적으로 외면하는 기술을 이길 겁니다. 전자를 만드는 사람들의 부류가 그렇거든요.
(번역: 새로운 변화를 호기심으로 맞이하는 기술이 유사 종교적으로 외면하는 기술을 이길 겁니다. 전자를 만드는 사람들의 부류가 그렇거든요.)
이렇게 쓰면 안 됩니까?
아니요, 그건 틀린 말이라서 안 됩니다.
코딩 에이전트를 쓰는 동기는 이해와 생산성입니다. 전통적으로 종교적인 열망은 아니죠.
소프트웨어 공학에서도, 다른 많은 분야에서도, LLM은 호기심과 비판적 사고를 강하게 북돋울 수도 있고 강하게 꺾을 수도 있습니다. 예전에 딱 내가 겪던 문제를 다룬 StackOverflow 글을 찾았을 때를 생각해 보세요. 해결책을 복사해 붙여넣고 그냥 밀고 나갈 수도 있었고, 그 단서를 따라 문제와 가능한 해법을 더 깊이 파고들 수도 있었죠. 모델도 똑같이 쓸 수 있습니다.
비판적으로 생각하고 싶다면 그 과정에서 정말 훌륭한 파트너가 될 수 있습니다. 이해할 마음도 없는 문제를 대충 때우고 싶다면 그것도 해 줍니다. 어떻게 쓸지는 본인에게 달렸습니다. 다른 사람들이 쓰는 방식도 그 스펙트럼 전체에 걸쳐 있을 수밖에 없고요.
(번역: 비판적으로 생각하고 싶다면 그 과정에서 정말 훌륭한 파트너가 될 수 있습니다.)
"비판적 사고"와 진실의 기반이 없는 도구를 한데 묶는 건 우려스럽습니다. 계산기를 쓰는 대신 숫자를 뽑기 상자에 넣고 하나 꺼내는 것과 다를 게 없습니다.
LLM 도구가 강제하는 "정답"의 정의는 어디에도 없는데, 그런 게 어떻게 사고의 파트너가 될 수 있습니까?
이게 슬롭 코딩의 핵심 문제입니다. 가능하다면 차라리 의사코드를 주고받는 편이 훨씬 유용할 겁니다. 논리적 의미는 언제나 프로그래밍 문법과 무관합니다. 코드를 생성할 필요가 없습니다.
잠깐, 그럼 유사 종교적이라는 게 AI를 만병통치약처럼 숭배하면서 뭐가 문제인지 보지 못하는 사람들을 가리키는 게 아니라고요? 이상하네요.
장난감 수준을 넘어서는 다이어그램을 Mermaid로 그리려 하면, 난해하고 위상적으로 엉망인 레이아웃 때문에 매번 완전히 질려 버립니다.
그에 비하면 스타일링은 사소한 문제처럼 보이고요.
전적으로 동의합니다. 그래서 Pele는 문법만 따르고 레이아웃은 따르지 않도록 설계했습니다. 예제는 여기서 보실 수 있습니다. https://pele.run/examples
플레이그라운드에는 비교(Compare) 모드도 있습니다. https://pele.run/playground
레이아웃 품질이 정말 인상적이네요!
다이어그램 diff에 대해서는 많이 생각해 보셨나요? 소스는 버전 관리를 하고 소스 diff를 볼 수 있지만, 시각적 diff가 있다면 정말 멋질 겁니다. 글로 쓰던 걸 다이어그램으로 쓰도록 저를 쉽게 설득할 수 있을 거예요.
정말 대단해요! Mermaid는 늘 읽기 힘들었는데 Pele는 보는 맛이 있네요. Pele에 대한 작은 감사의 표시로 GitHub에서 후원했습니다. 정말 고맙습니다, kepano.
참고로 여기 첫 두 예제가 똑같습니다. https://pele.run/examples/timeline
수정: 7번도 똑같고(8번도 거의), 9, 10, 11, 12번도 똑같네요.
그렇다면 제가 쓰는 도구가 마음에 드실 겁니다. https://ferroman.github.io/diagc/
그래프 레이아웃은 어렵기로 유명한 문제죠!
글쓰기와 거의 비슷하지 않나 싶습니다. 잘 전달되는 다이어그램을 만들려면 문제를 제대로 풀어 놓아야 하니까요.
흔한 레이아웃 구현은 SAT 솔버에 제약 조건을 주는 방식인데… 그러니 거의 맞히셨네요 :)
제 취향으로는 자동 레이아웃 구현 대부분이 끔찍한 결과를 냅니다. SAT 풀이로 최적화해서 선이 교차하지 않는 노드 순서를 얻을 수는 있겠지만, 그렇게 나온 결과는 내용을 직관적으로 이해시키는 경우가 드뭅니다.
좋은 레이아웃은 오히려 글쓰기에 훨씬 가깝습니다. 의도한 독자가 어떻게 받아들일지, 어떤 순서로 무엇을 눈에 띄게 할지, 여러 관계를 어떻게 따라가기 쉽게 만들지를 고민해야 하니까요.
저는 D2에 elk나 dagre를 써서 잘 됐습니다. elk를 깊이 파고들면 정말 많은 걸 할 수 있어요.
이제 D2에 tala 레이아웃 엔진이 포함돼서 아주 좋은 레이아웃을 줍니다.
문서만 좋았어도 좋았을 텐데요. 저는 elkjs JavaScript 버전이 정말 마음에 듭니다(고마워요, Ulf!). bitte, 그런데 트랜스코딩을 거치다 보니 Java 문서를 옮겨 오기가 더 어려워지네요...
정말 감사합니다!
저는 정적 웹사이트를 빌드할 때 마크다운 파일을 HTML로 렌더링하면서 mermaid 코드 블록을 렌더링된 SVG로 바꾸는 스크립트를 씁니다. 여기에 mermaidjs를 썼는데, 이 용도로는 너무 무겁습니다(렌더링에 chromium 인스턴스가 통째로 필요하거든요).
제 용도에 딱 맞아 보여서 바로 바꿔 끼웠습니다. 레이아웃이 1대 1로 똑같지는 않았지만, 반갑게도 mermaidjs보다 Pele가 그리는 쪽이 오히려 더 마음에 들었어요.
(번역: 플로차트 서브그래프는 서브그래프 바깥 노드와 연결되어 있어도 자기만의 방향을 유지합니다.)
이것만으로도, Mermaid.js보다 느리다 해도 갈아탈 충분한 이유가 됩니다.
목록을 끝까지 보지도 않았는데 벌써 넘어갔습니다.
브라질 사람인 저는 펠레 선수에게 바치는 헌정인 줄 알았어요. 글에서 이름의 유래를 설명해 줘서 다행입니다.
저는 브라질 사람은 아니지만 모두가 펠레를 아는 세상에서 자랐거든요(제가 좀 나이가 많은 걸까요?)... 그래서 저도 그분 이름을 딴 건 줄 알았어요! :-)
정말 영감을 받았습니다. 저는 터미널과 브라우저에서 쓸 페이저용 파일 형식 렌더링을 작업하고 있었는데 Mermaid를 까맣게 잊고 있었거든요!
작업 대부분이 SVG를 중간 단계로 쓰기 때문에 이 Pele 방식이 아주 잘 맞습니다. 원 프로젝트는 TypeScript 프로젝트인데, 그쪽 생태계에 잘 어울려 보입니다.
검색해 보니 SVG를 대상으로 비슷하게 동작하는 go-mermaid 라이브러리 [1]가 있었습니다. 저희에게는 Golang TUI 그림/SVG 위젯과 Golang WASM/브라우저 임베더가 있어서, 그걸 포크한 뒤 LLM에게 이 둘을 쓰는 실시간 Mermaid/SVG 데모를 추가하게 했습니다 [2]. 이 데모는 go-mermaid용이라 go-mermaid의 래스터라이저를 쓰고, 그 결과를 저희 위젯에 합성합니다.
(며칠 전에 비슷한 작업을 해서 부품이 준비돼 있었고 Pele를 참고로 가리킬 수도 있어서 15분도 안 걸렸습니다. 이런 LLM들은 패턴을 보고 만들어 내는 솜씨가 터무니없어요.)
멋진 점은 터미널이 Kitty 그래픽 프로토콜을 지원하면 똑같은 시각 경험을 터미널에서도 얻을 수 있다는 겁니다.
[1] https://github.com/zkrebbekx/go-mermaid
[2] https://neomantra.github.io/go-mermaid/
대단합니다. 제 프로젝트의 문서 사이트에 있는 다이어그램을 방금 옮겼는데 정말 멋지게 나옵니다[0]. 전에는 mermaid, panzoom에 스타일 통합과 다크 테마를 제대로 맞추려는 사소한 우회책까지 섞어 썼거든요. Pele는 그걸 전부 알아서 처리해 줄 뿐 아니라 레이아웃도 더 보기 좋게 만들어 줍니다!
[0] https://cetacean.mazetti.me/authentication#oidc
SVG로 바로 렌더링하는 방식이 마음에 듭니다. 제가 원하던 게 바로 그거거든요. 레이아웃을 한 번만 돌리고 그 결과를 브라우저나 서버 쪽에 캐시해 두는 것 말입니다.
훌륭한 작업입니다... 저희 도구와 프로젝트에도 넣어 보려고 합니다. 다크 모드 지원이 큰 장점이네요. 이런 작업 감사합니다. 계속 힘내 주세요.
공식 Mermaid 라이브러리는 SVG를 배치하려면 여전히 전체 브라우저나 헤드리스 브라우저 환경이 필요한가요? 그렇다면 Pele는 Mermaid 렌더링을 다른 곳에 임베드하려는 입장에서 좋은 소식이겠네요.
GitHub에 SVG를 출력해 주는 Merman도 있습니다.
https://github.com/Latias94/merman
아주 좋네요, 북마크했습니다. 저는 svgdom을 써서 비슷한 걸 Astro 플러그인으로 만들었어요. https://better-static-sites.github.io/build-tools/mermaid/
mermaid 개발자들이 SVG 하나 렌더링하는 데 브라우저가 통째로 필요하다고 생각한다는 게 아직도 이해가 안 됩니다. 가끔은 사람들에게 기본기를 다시 일깨워 줘야 하는 게 아닌가 싶어요.