Mermaid는 다이어그램-코드 방식을 정착시켰다: 시퀀스 다이어그램은 Markdown 안의 텍스트가 되었다

UML은 소프트웨어가 설계 다이어그램을 표준화하려 한 거대한 시도였다. OMG는 1997년에 이를 받아들였고 ISO는 2005년에 채택했다. UML은 자체의 무게에 짓눌려 붕괴했다. UML 2.2 문서는 1,000페이지를 넘었고, 표준은 무거운 CASE 도구와 부담스러운 사전 작업에 묶이게 되어, 2020년대에 이르러서는 지지자와 비판자 모두 그것이 사실상 죽었다는 데 동의했다.

그러나 하나의 산출물은 그것보다 오래 살아남았다. 바로 컴포넌트 사이를 흐르는 메시지를 단순하게 그린 시퀀스 다이어그램이다. 살아남은 이들은 그것을 그릴 수 있었지만, 도구가 이를 고통스럽게 만들었다. BitHawk의 개발자 jessems는 Lucidchart에서 도형을 끌어다 놓는 것이 느리고 취약했으며, 이후의 어떤 변경이든 레이아웃을 망가뜨린다고 느꼈다.

전환점은 Mermaid였다. 다이어그램을 일반 텍스트로 선언하는 JavaScript 라이브러리로, 참여자와 화살표, 메시지를 Markdown 코드 펜스 안에 작성하면 Markdown 도구 체인이 이를 렌더링한다. 작성자는 코드 위에 코드를 쓰는 것이 어색하게 느껴질 것이라 생각하고 시도했다가, 빠르고 간편하며 아름답다는 것을 발견했다. 그는 사용자 스토리의 구현 계획에 시퀀스 다이어그램을 넣기 시작했고, 핫 리로드로 미리 보며 이미지로 내보내 HTML 필드에 붙여넣었다.

이것이 정착한 이유는 다이어그램이 평범한 코드 산출물이 되었기 때문이다. 다이어그램은 그것이 문서화하는 스토리 옆에 존재하고, 코드 리뷰에서 diff되며, 다시 그리는 대신 한 줄 수정으로 갱신되고, Markdown이 있는 어디서든 렌더링된다. GitHub Markdown은 Mermaid를 기본으로 지원한다고 Hacker News 스레드의 댓글 작성자들이 지적했다. Mermaid의 창립자는 이를 Rational Rose 시대 도구들의 경직된 복잡성을 대체하는 비공식적 단순함으로 규정했다.

다이어그램을 코드 산출물로 만들기: Markdown에 텍스트로 입력하고 렌더러가 그리게 하기

다이어그램을 타이핑하는 것이 끌어다 놓는 것보다 빠르므로, 작성 비용이 캔버스 세션에서 문서 옆의 몇 줄로 줄어든다.

텍스트는 코드처럼 버전 관리되고 diff되므로, 다이어그램 갱신은 취약한 재작성이 아니라 리뷰에서의 한 줄 수정이 된다.

Markdown 렌더러는 이미 어디에나 있으므로, 다이어그램은 팀이 이미 문서를 읽고 댓글을 다는 곳에서 표시된다.

UML은 복잡성을 더하다 죽었고, Mermaid는 유용한 산출물만 남기고 그 주변의 도구 비용을 제거했다.

표준은 사람들이 이미 일하는 곳에서 비용을 줄임으로써 살아남는다. 이기는 다이어그램은 문서에 타이핑하고 리뷰에서 diff할 수 있는 다이어그램이다.

이 글은 2023년 7월 24일 Hacker News에서 207점과 111개의 댓글을 얻었다. 댓글 작성자들은 GitHub Markdown이 Mermaid를 기본으로 렌더링한다는 점을 언급하고, 이를 PlantUML, d2, Graphviz와 비교했으며, 한 번의 설치 명령으로 렌더링하는 Docusaurus 같은 Markdown 생태계를 추천했다. 작성자는 BitHawk에서 이 워크플로를 유지했고, 시퀀스 다이어그램이 Markdown 파일 안에 있는 구현 계획을 작성했으며, 기록에 HTML이 필요할 때는 mermaid-cli로 이미지로 내보냈다.