로드맵

간략 요약

D2 프로젝트의 현재 작업들에 대한 자세한 내용은 여기를 확인하세요.

D2 프로젝트의 장기적인 목표는 실무에서 쓰이는 높은 수준의 다이어그램을 만들고 유지하는 데 소요되는 시간과 노력을 크게 줄이는 것입니다. 이는 야심찬 대규모 사업이며, 완성까지 수년의 시간이 걸릴 것입니다. 특히 이러한 초기 단계에서는 활용성을 높이는 데 가장 큰 영향을 미치는 요소들에 집중하는 것이 중요합니다. 현재 최우선 과제는 다음과 같습니다.

1. 제작 가능한 레이아웃의 범위를 확장한다.
2. 보기 좋은 다이어그램을 만들기 위해 필요한 노력을 최소화한다.
3. 널리 쓰이는 개발툴과의 통합을 지원한다.

이들 각각의 진행률을 평가할 수 있는 기준들에 대해 설명하겠습니다.

레이아웃

가끔은 머릿속의 그림을 정확하게 따라야 하는 다이어그램이 필요할 때가 있습니다. 이런 경우에는 디자인 도구와 드래그 앤 드롭 기능이 필요합니다. 그러나 때로는 굳이 정확하게 그릴 필요가 없거나, 결과물을 머릿속에 떠올리기 힘든 경우가 있습니다. 이런 경우에는 일련의 제약 조건만 만족하면 되기 때문에 다이어그램에 대한 요구사항이 상대적으로 엄격하지 않습니다. 이러한 종류의 다이어그램은 알고리즘을 사용하여 자동으로 생성할 수 있습니다.^[0] 주로 소프트웨어 엔지니어링 다이어그램이 이에 해당합니다.

정확한 배치와 고유의 모양 때문에 자동화할 수 없습니다.

자동화 가능합니다. 이런 관계를 보기 좋은 형태로 100가지 다른 방법을 통해 보여줄 수 있습니다.

현재로서 D2는 일부 자동화 가능한 다이어그램을 잘 처리할 수 있으며, 이 범위를 확대하는 것이 최우선 목표입니다.^[1] 물론 이를 실현할 주요 수단은 당연하게도 레이아웃 엔진입니다. 이는 모양, 라벨, 아이콘, 연결 및 힌트를 입력으로 받아들여 "가독성"을 갖도록 배치하는 알고리즘을 기반으로 구동됩니다.

다이어그램의 가독성에 대한 평가 기준으로는 다음 두 가지가 있습니다.

1. 시각적 가독성: 불필요한 요소가 없고, 깔끔하며, 정렬되어 있고, 불필요한 연결 교차가 없는 상태인가? 더 이상의 개선 필요성이 존재하지 않는가?
2. 의미론적 가독성: 모델을 새로이 그릴 경우 시각적 가독성이 조금 떨어지더라도 모델이 더 이해하기 쉬워질 수 있는가?

알고리즘은 보통 시각적 가독성에서 사람보다 더 뛰어난 성능을 보입니다. 다이어그램이 커질수록 그 차이는 더 뚜렷해집니다.

의미론적 가독성은 좀 더 어려운 문제입니다. 대부분의 레이아웃 엔진은 계층 구조와 같이 단순한 "유형"의 다이어그램에만 국한되어 있습니다. 하지만 소프트웨어 아키텍처를 계층적으로 나타내고자 하는 경우는 드물며, 그렇게 배치할 경우 그 의미가 변경될 수 있습니다.

평가 방법

• 시각적 관점: 명백한 개선 사항을 찾을 수 있는가?
• 의미론적 관점: 튜닝 테스트와 비슷한 맥락에서, 레이아웃이 알고리즘의 결과물인지 사람의 결과물인지 구별할 수 있는가?

D2는 기본적으로 Dagre 엔진을 사용합니다. 마크다운 문법으로 다이어그램을 작성할 수 있는 Mermaid에서도 사용되는 최고의 오픈 소스 레이아웃 엔진 중 하나이지만, 이 또한 여전히 많은 부분에서 개선의 여지가 있습니다.^[2] Dagre는 불행히도 유지 보수되지 않고 계층 구조의 레이아웃만 생성합니다. 유지 보수가 다시 이뤄진다 하더라도, 기본적으로 계층적인 레이아웃을 벗어나지 않을 것입니다. 또한 소프트웨어 아키텍처 다이어그램에 필수적인 컨테이너 기능이 없습니다(D2는 해당 기능[2]을 지원합니다).

앞으로의 계획

1. 개발이 완료된 특수 목적 레이아웃 엔진과 통합합니다. 예를 들어 시퀀스 다이어그램 레이아웃 엔진에는 개선 사항이 없습니다. git-commit 타임라인이나 방사형 레이아웃의 경우에도 마찬가지입니다.
2. 우리는 아예 새로운 범용 레이아웃 엔진^[3]을 개발하여 소프트웨어 아키텍처 다이어그램 제작 테스트를 하고 있습니다. 해당 엔진은 하나의 다이어그램에서 여러 하위 타입을 지원할 수 있습니다. 예를 들어, 다이어그램의 일부는 트리이지만 다이어그램 전체가 트리 구조일 필요는 없습니다. 또한, 컨테이너와 클러스터를 매우 잘 처리하고 레이블과 아이콘을 옮겨 충돌을 방지하는 등의 작업을 수행합니다.

심미적 관점

공식 문서는 활용될 때만 가치가 있습니다. 그리고 그 안의 다이어그램이 보기 좋아야 더 잘 활용될 수 있습니다. 알고리즘 생성 다이어그램이 수작업으로 만든 것을 대체하려면 적어도 동등한 미적 수준을 가져야 합니다. 그리고 그것이 수작업으로 만든 것들보다 항상 우위에 있으려면 그 이상의 아름다움을 가져야 합니다. 또한, 사용자 맞춤 설정은 얼마나 많은 노력을 들이고 싶은지에 따라 단계적으로 나뉘어야 할 것입니다.

1. 적은 노력: 전문 디자이너가 미리 만든 테마 중에서 선택합니다.
2. 적당한 노력: 자신만의 테마를 만들고 편집합니다.
3. 많은 노력: 모든 것을 맞춤형으로 만듭니다.

대부분의 엔지니어는 1, 2단계에서 만족하지만 D2는 3단계를 만족시켜야 할 것입니다.

평가 방법

• 블로그 포스팅 또는 회의에서 쓸 발표 자료와 같이 많은 사람들이 볼 자료에 넣을 다이어그램을 만들 떄, D2를 사용하여 만들 수 있을까?

심미적 관점에 대한 평가에서, 중요한 기준 중 하나는 발표에서 쓸만한 다이어그램을 완성할만한 수준에 이르기까지 걸리는 시간입니다. 발표에서 사용 가능하다는 것은 화려한 색상과 그림자, 디자인 장식이 가득하지 않다는 것을 의미합니다. 이는 명확성을 높이는 일관된 색상, 회사 색상의 팔레트, 구분 가능한 형태와 화살표 등 발표할 때 사용해도 어색하지 않은 전문적인 다이어그램을 만드는 속성을 의미합니다.

또 다른 고려 사항은 미적 요소에 대한 커스터마이징이 가능한지, 그리고 그 설정에 얼마나 많은 노력이 필요한지입니다. 커스터마이징을 GUI 수준으로 만든다는 건 욕심일 수 있겠지만, D2는 적어도 텍스트 기반 스타일링 언어인 CSS만큼의 수준을 목표로 하고 있습니다.

앞으로의 계획

1. 커스터마이징을 더 쉽게 할 수 있는 기능을 구현합니다. 전역 타겟팅(예: x.*.style.fill: x의 모든 하위 요소의 내부를 빨간색으로 채움) 또는 클래스(스타일 정의 후 재사용) 같은 기능들을 말합니다. 도형과 연결 기능의 경우 카탈로그의 확장이 필요합니다.
2. 테마 제작에 계속 투자합니다. 테마는 엔지니어들이 디자인하지 않고도 아름다운 다이어그램을 만들 수 있도록 합니다. D2는 색상뿐만 아니라 글꼴, 배경 스타일(점, 그리드, 색상)과 같이 다이어그램의 모든 요소에 대해서 테마가 적용될 수 있는 부분을 세부적으로 적용할 수 있도록 확장해야 합니다. 그리고 테마를 쉽게 만들고 수정할 수 있도록 해야 합니다.
3. D2와 번들로 제공될 고품질의 일관된 아이콘 세트를 선별합니다.

개발자 도구

개발 도구가 기존 워크플로우나 익숙한 툴들에 대해 더 잘 지원할수록 유용하겠죠. D2에는 공식 Vim 및 VSCode 확장이 있습니다. 언어 내의 기능은 자동 서식, 손상된 구문에 대한 분석, 사람이 읽을 수 있는 여러 오류 메시지 출력 등 편집기 환경 개선을 위해서만 존재합니다.

결합성을 더 높이기 위해 D2에서는 추상 구문 트리(AST)를 고수준에서 조작할 수 있는 내장 API를 제공합니다. 이는 AST 노드에 대한 CRUD보다 더 지능적인 조작을 가능하게 합니다. 이를 통해 누구나 프로그래밍 방식으로 다이어그램을 작성하고 편집할 수 있습니다. 이 기능의 목표는 특정한 사용 방법을 제공하는 것이 아니라, 사용자들이 예상치 못한 새로운 방법으로 D2를 사용할 수 있게 하여, 무한한 가능성을 탐색할 수 있도록 하고자 하는 것입니다.

D2의 플러그인 시스템은 이 언어를 더욱 확장 가능하게 만듭니다. 이를 통해 사용자는 D2 컴파일 과정의 여러 단계에 "훅(hooks)"을 추가할 수 있습니다. 예를 들어, D2의 핵심 기능은 아니지만, 가상의 플러그인 세트를 사용하여 스타일이 있는 테두리를 추가하고, 사용자의 서명이나 크레딧을 추가하며, 모든 것을 손으로 그린 것처럼 보이게^[4] 할 수 있고, 접근성을 높이기 위해 대비를 증가시킬 수 있습니다.

평가 방법

• 현재 환경에서 D2를 쓰고 읽는 것이 "완전하다"고 느껴지는가?
• 예상치 못한 방식으로 사용할 수 있을 만큼 유연하고 확장 가능한가?

완성도

Vim의 Go 플러그인에 대한 개선점이 있을까요?^[5] 전 잘 모르겠습니다. "완전하다"는 느낌이 들었습니다. 하지만 그렇지 않은, 기본적인 토큰만 식별하고 거기서 멈춘 것처럼 느껴진 많은 플러그인/확장 기능들도 상당히 많습니다. D2의 플러그인이 그렇게 되어서는 안되겠죠.

확장성

좋은 개발자 도구의 특징은 모듈 방식을 통해 예상 밖의 새로운 방식의 사용이 가능하다는 점입니다.

앞으로의 계획

1. 플러그인 시스템의 발전: D2의 플러그인 시스템은 아직 초기 단계에 있으며, 컴파일 과정의 다양한 부분에 더 깊이 있는 훅을 허용해야 합니다. 이를 통해 개발자들이 컴파일 과정에 더욱 효과적으로 개입하고, 사용자 정의 기능을 구현할 수 있게 됩니다.

2. 편집기 통합 완성: 현재는 문법 강조 기능이 지원되고 있습니다. 하지만, 예를 들어 VSCode와 같은 편집기에 대한 기능 완성도 높은 통합이 이루어진다면, 내장 브라우저로의 렌더링, 자동 포맷팅, LSP 기능 호출을 통한 리팩토링 등을 가능하게 할 수 있습니다.

3. Import/Export 기능 확장: 현재 D2는 D2 파일을 입력받아 SVG 파일로 내보낼 수 있습니다. 여기에 더해, 다른 인기 있는 텍스트-다이어그램 언어를 임포트하고, 다른 인기 있는 이미지 형식으로 출력할 수 있는 트랜스파일러를 구축해야 합니다. 또한, 스키마의 CSV를 입력받아 ERD(엔티티-관계 다이어그램)를 만들 수 있어야 하며, ASCII 아트로 렌더링할 수 있는 기능도 있어야 합니다.

4. 구성 가능한 린터 구축: 코드의 일관성과 품질을 유지하기 위해 사용자가 설정할 수 있는 린터를 구축해야 합니다. 이를 통해 개발자는 자신의 코딩 스타일과 규칙에 맞춰 코드를 검사하고 수정할 수 있습니다.

여러분의 피드백

제안 사항이나 피드백이 있으시면 언제든지 알려주세요! Github에서 이슈를 열어주세요.

주석

[0]

상당히 많은 분야의 다이어그램들이 알고리즘을 통해 대부분 해석이 가능합니다. 예를 들어 HR도의 경우도 알고리즘을 통해 해석될 수 있죠. 반면, 생물학과 같은 분야에서는 대부분의 다이어그램이 맞춤형으로 그려지곤 합니다.

[1]

일부 다이어그램의 경우에는 항상 육체 노동이 필요합니다. 예를 들어 비행기의 반투명 청사진을 만들고 특정 부분에 모양과 선을 오버레이하려는 경우입니다. 좋은 GUI 다이어그램 제작자는 항상 필요합니다.

[2]

MermaidJS는 컨테이너에 대한 지원도 구현한 것으로 보이지만 공식적으로 출시되지 않았으며 라이브 편집기에서는 여전히 해당 기능이 작동하지 않습니다.

[3]

현재로서는 비공개 소스입니다. 무료로 다운로드하고 평가할 수 있습니다. 자세히 알아보려면 https://terrastruct.com/tala를 방문하세요.

[4]

수작업의 ​​낭만을 원한다면 D2에서 도와드릴 수 있습니다. 링크를 참고하세요.

[5]

사실 gopls가 CPU를 많이 잡아먹는 바람에 제 컴퓨터 속도가 2005년으로 돌아간 것 같아요. 하지만 이건 vim-go의 잘못은 아니에요!