다이어그램(Mermaid)

작동 방식

Mermaid 다이어그램. 순서도(flowchart/graph, 네 방향 모두), 시퀀스 다이어그램(sequenceDiagram), 원 그래프(pie)가 담긴 ```mermaid 울타리는 읽기 모드, 내보낸 파일, 그리고 다이어그램이 가장 많이 오는 노트에 질문의 답변에서 그림으로 그려집니다. 그림은 노트 테마(글자색, 종이색, 강조색)를 따르므로 두 테마 모두에서 주변 글과 어울립니다. 서식 편집(기본 모드)에서도 다이어그램은 그려집니다. 위에는 블록 막대(복사, 편집, 삭제)가 나타납니다. 편집을 누르면 아래에 원본 막대가 열립니다. 열려 있는 동안 노트는 잠기고, 그림은 입력하는 동안 다시 그려집니다. 닫으면 적용되며(저장도 취소도 없습니다), Ctrl+Z는 변경 전체를 한 번에 되돌리고, 칸을 비우면 블록이 삭제됩니다. 분할 모드에서는 다이어그램을 클릭하면 커서가 원본 텍스트의 울타리로 이동합니다. 텍스트 편집기에서는 모두 텍스트로 남습니다. 다이어그램을 보려면 Ctrl+E를 누르세요. 목록 항목 안에서는 다이어그램(SMILES 구조, 블록 수식, [files], ![[노트]]도 마찬가지)이 서식 편집에서는 텍스트로 남고 읽기 모드에서 그려집니다. 그 자리에서는 항목 기호를 파일로 되돌릴 방법이 없기 때문입니다.

서브그래프(subgraph … end, 중첩 포함)는 제목이 붙은 상자로 그려지고, 간선은 실제 노드에서 출발해 테두리를 가로지릅니다. 서브그래프의 id를 간선의 끝점으로 쓸 수도 있습니다(sub --> X). 작성자가 선언한 색도 적용됩니다: classDef, class, :::클래스, style(채우기, 테두리, 두께, 점선, 글자색). 시작할 때는 노트 도구 모음의 삽입 → 다이어그램(Mermaid)을 쓰세요. 메뉴에는 가장 많이 쓰는 여섯 가지가 바로 놓이고, 모든 다이어그램…을 누르면 33가지 전부를 용도별로 묶어 놓은 선택 창이 열립니다. 검색(이름으로도, 다이어그램이 보여 주는 내용으로도)과 각각의 실제 그림 미리 보기가 함께 있습니다. 33가지나 되면 이름을 읽는 것보다 그림을 보는 편이 더 빠릅니다. 선택한 종류의 기본 골격이 그대로 들어옵니다. 다이어그램의 프론트매터—첫 줄 앞의 --- 블록—도 읽습니다. title은 그림 위에 그려지는 제목이 되고(본문의 title이 우선), LightNote가 아는 config 키는 다이어그램에 전달됩니다(gitGraph.mainBranchName, gantt.displayMode, 그리고 packet의 bitsPerRow, 줄을 좌우로 뒤집는 bitOrder: descending, showBits: false). 모르는 키는 무시되고 노트를 거부하지 않습니다.

시퀀스, 엔티티, 클래스, 상태

시퀀스 다이어그램에서는 participant/actor(as 포함), 화살표 종류(->>, -->>, -x, -)), 활성화(+/-와 activate/deactivate), 노트(Note left of/right of/over), loop/alt/else/opt/par 블록, autonumber가 동작합니다. 아직 그리지 못하는 것 — 다른 다이어그램 종류 — 은 지금처럼 색이 입혀진 코드 블록으로 나타납니다. 서브그래프 안의 direction과 linkStyle은 무시됩니다. Mermaid v11의 노드 문법(A@{ shape: rounded, label: "텍스트" })도 읽고, v11 도형 카탈로그를 그립니다. doc, lin-doc, docs, tag-rect, win-pane, hourglass, bolt, flag, das 등 저마다 이름이 말하는 기호가 되며, 어느 것도 사각형으로 대체되지 않습니다. 문서 대신 사각형을 그리는 것은 다른 그림을 보여 주는 일이기 때문입니다. Mermaid에 없는 이름은 줄 번호와 함께 코드 블록으로 되돌아갑니다. 간선 ID(A e1@--> B)와 e1@{ animate: true }는 받아들이되 무시합니다. 애니메이션은 그리지 않습니다. 타입을 지정한 참여자(participant DB@{ "type": "database" })는 레인 위에 UML 기호를 그립니다 — boundary, control, entity, database, queue, collections — 그곳에 선언한 "alias"는 as와 같은 구실을 합니다.

erDiagram도 그려집니다. 각 엔티티는 속성이 있는 상자가 되고, 관계의 양쪽 끝에 카디널리티가 표시됩니다(||--o{, }o--||, |o, |{). --는 식별 관계, ..는 비식별 관계입니다.별칭 p[Person]은 관계가 참조하는 id를 바꾸지 않고 상자 이름만 정합니다. subgraph … end도 여기에서 쓸 수 있습니다. 안의 엔터티들은 제목이 있는 상자에 들어가고, 서브그래프는 중첩되며, 상자의 id를 관계의 끝으로 쓸 수 있습니다(CLIENTE ||--o{ Vendas : faz). 이때는 같은 이름의 엔터티가 아니라 경계에 붙습니다.

classDiagram도 마찬가지입니다. 세 구획으로 나뉜 상자(이름, 속성, 메서드. 메서드의 괄호로 구분됩니다), 독립된 줄의 <<interface>>, 상자가 되는 namespace, 그리고 여섯 가지 관계(<|--, *--, o--, -->, ..>, ..|>)를 지원합니다. 방향에 주의하세요. A <|-- B에서 삼각형은 A 쪽에 붙고, 상속하는 쪽은 B입니다. 따옴표로 쓴 카디널리티는 양쪽 끝에 표시됩니다("1" --> "*"). 제네릭 List~T~은 List<T>로 표시되며, 멤버에서도 마찬가지입니다. 롤리팝 인터페이스(bar ()-- foo)는 ()가 있는 쪽 상자 위에만 원을 그리고, 관계선은 그 원에 닿습니다. namespace도 중첩되며, 안쪽 } 다음에 선언한 클래스는 바깥쪽 namespace로 돌아갑니다.

stateDiagram-v2는 상태 기계를 그립니다. [*]는 시작(채워진 원)과 끝(고리가 있는 원), state X { … }는 상자, <<fork>>/<<join>>는 막대, <<choice>>는 마름모가 됩니다. 복합 상태 안의 --는 동시 영역을 구분하며, 파선으로 표시됩니다.

타임라인, 여정, 사분면, 간트

timeline도 그려집니다. 각 기간은 타임라인의 열이 되고 그 아래에 사건이 쌓이며, section은 시대를 색 띠로 묶습니다. 여러 사건을 적는 두 가지 표기가 모두 됩니다 — 같은 줄에 쌍점으로 나열(2004 : Facebook : Google)하거나 다음 줄에 이어 쓰기(: 다른 사건). 그리고 여기서는 title, section, direction이 아닌 모든 줄이 자유 문장입니다. direction TD(세로 타임라인)는 아직 그리지 못하고 코드 블록으로 남습니다.

journey(사용자 여정)도 그려집니다. 각 작업은 여정 축 위의 상자가 되고, 1에서 5까지의 점수가 그 표정을 위아래로 옮깁니다. 그 표정들이 그리는 굴곡이야말로 이 다이어그램이 보여 주려는 것입니다. section은 단계를 묶고, 참여자는 작업 위의 색 표식이 되며 범례는 왼쪽에 나옵니다. 여기서 문법은 timeline과 달리 엄격합니다(작업: 점수: 참여자, 참여자). 이름과 점수 짝이 없으면 표정을 놓을 자리가 없으므로, 형식이 어긋난 줄이나 1~5 밖의 점수는 줄 번호와 함께 다이어그램을 거부합니다.

그리고 quadrantChart는 사분면 평면을 그립니다. x-axis와 y-axis가 각 축의 양 끝에 이름을 붙이고(--> 오른쪽은 생략할 수 있습니다), quadrant-1부터 quadrant-4가 각 영역에 라벨을 붙이며, 점은 이름: [x, y] 형식으로 x와 y는 0에서 1까지입니다. 번호에 주의하세요. 읽는 순서가 아니라 좌표평면의 번호입니다 — quadrant-1은 오른쪽 위이고 거기서 시계 반대 방향으로 갑니다. y = 1은 맨 위입니다. 점의 색과 반지름은 직접(P: [0.5, 0.5] radius: 10, color: #109060) 주거나 클래스(P:::클래스와 classDef)로 줄 수 있고, 직접 지정이 클래스를 이깁니다. 0에서 1을 벗어난 좌표는 잘리지 않고 줄 번호와 함께 다이어그램을 거부합니다. 좌표는 평면 위의 위치라서, 자르면 쓰지 않은 사분면에 점이 들어가기 때문입니다.

gantt는 일정표를 그립니다. dateFormat은 여러분이 적는 날짜의 형식(기본값 YYYY-MM-DD)을, axisFormat은 축 라벨의 형식(%m/%d)을 정하고, section은 작업을 띠로 묶습니다. 각 작업은 텍스트 : 표시, id, 시작, 끝 형식입니다. 표시인 done, active, crit, milestone은 맨 앞에 오며 함께 쓸 수 있고, 시작은 날짜나 after 다른id, 끝은 날짜, 기간(5d, 2w, 3h, 45m) 또는 until 다른id입니다. 항목이 하나뿐이면 앞 작업이 끝난 지점에서 시작합니다.

after는 노트의 뒤쪽에 선언된 작업도 가리킬 수 있습니다. 반면 어디에도 없는 id나 순환 의존은, 막대를 오늘 날짜에 놓는 대신 줄 번호와 함께 다이어그램을 거부합니다. excludes weekends(excludes monday나 특정 날짜도 됩니다)는 제외된 날만큼 각 작업의 끝을 뒤로 밉니다. 그래서 막대 길이가 달라집니다. includes 2026-03-07은 주말보다 우선해, 그 토요일은 일하는 날임을 알립니다. 마일스톤은 마름모로 나오고, todayMarker off는 오늘 선을 없앱니다. 여러 작업을 같은 줄에 쌓는 displayMode compact도 그립니다. 여기서는 작업이 차지하는 범위(라벨 포함)가 이미 있는 것과 닿지 않을 때만 같은 줄을 나눗니다. vert 표시(개시 : vert, v1, 20:15, 0m)는 순간을 차트 전체를 가로지르는 수직선으로 그리고, 줄을 차지하지 않으며, 라벨은 축 아래에 놀입니다. dateFormat X(또는 x)는 날짜를 초(또는 밀리초) 단위의 유닉스 시간으로 읽고, 축에서는 %s/%Q가 다시 쓴다. Mermaid가 모르는 tickInterval(1decade)은 그쪽처럼 조용히 무시되고 축은 자동으로 돌아갑니다.

마인드맵, 요구사항, Git, C4

mindmap에서는 계층이 들여쓰기에서 나옵니다. 항목의 단계는 그 본문이 시작하는 열이며, 중괄호도 화살표도 쓰지 않습니다(탭은 다음 4의 눈금까지로 셉니다. 편집기와 같은 계산입니다). 첫 항목이 루트이고, 같은 열에 항목이 하나 더 오면 두 번째 루트가 되므로 줄 번호와 함께 다이어그램을 거부합니다. 각 항목은 모양을 선언할 수 있습니다 — [사각형], (둥근 모서리), ((원)), {{육각형}}, ))폭발((, )구름(. 구분자가 없으면 둥근 모서리로 나옵니다. ::icon(...)과 :::클래스는 인식한 뒤 무시합니다(아이콘 글꼴을 함께 배포하지 않고, 클래스는 여기에 없는 외부 CSS를 가리키기 때문입니다). 그림은 좌우 두 방향입니다. 루트를 가운데에 두고 가지를 양쪽으로 나누며, 가지마다 고유한 색을 갖고 자손이 그 색을 물려받습니다. 잔가지는 깊이가 깊어질수록 가늘어집니다.

이것은 나무이지, 머메이드처럼 힘 시뮬레이션이 아닙니다. 마인드맵에서는 계층이 곧 내용이라 위치에서 읽혀야 하고, 게다가 테마를 바꾸면 그림을 다시 그리므로 무작위 초기 위치에서 수렴하는 배치는 지도 전체를 매번 다시 배열해 버립니다.

treeView(treeView-beta)는 프로젝트의 폴더 트리를 그리며 두 가지 표기를 받습니다. 들여쓰기(직접 타이핑할 때)와 tree 명령 그 자체의 문자(├──, │, └──)입니다. 뒤의 표기 덕분에 터미널 출력을 그대로 붙여넣을 수 있습니다 — 거기서는 들여쓰기만으로는 부족합니다. │와 공백은 같은 칸을 차지하지만 가지가 이어진다고 말하는 것은 앞의 것뿐이기 때문입니다. 끝의 슬래시는 폴더를 표시하고(src/), 공백이 있는 이름은 따옴표로 묶으며, ## 텍스트는 줄 끝에 주석을 달고, :::highlight는 이름을 강조합니다. icon(...)은 마인드맵의 ::icon()처럼 인식하되 무시합니다. 아이콘 팩은 JavaScript로 Iconify에서 오고, Mermaid 자체도 기본값으로는 그리지 않습니다.

ishikawa(ishikawa-beta)는 원인 분석의 생선가시도를 그립니다. 첫 항목이 결과(오른쪽 머리)이고, 다음 단계가 범주(비늘), 그 안쪽 두 단계가 원인과 하위 원인입니다. 단계는 셋까지이며, 네 번째는 줄을 가리키며 거부합니다 — Mermaid에 없기 때문입니다. 비늘은 중심선 위아래로 번갈아 미쳐서 이웃한 두 범주의 글자가 겹치지 않으며, 원인을 적은 순서는 양쪽 모두 위에서 아래로 읽힙니다.

venn(venn-beta)는 서로 겹치는 집합을 그립니다. set A["바람직함"]으로 하나를 선언하고, union A,B["만들 수 있음"]으로 공통 영역에 이름을 붙이며(합집합은 교차하는 집합들로 부릅니다), 바로 아래의 text A1["React"]는 그 영역 안에 항목을 넣습니다. 집합은 셋까지이고, 네 번째는 줄을 가리키며 거부합니다. 원 네 개로는 모든 영역을 만드는 배치가 없고, “거의 맞는” 그림은 선언한 영역을 숨기기 때문입니다. 라벨 뒤의 :숫자(set A["Alpha"]:20)는 원의 크기를 조절하고(넓이가 숫자를 따릅니다) 교집합은 바꾸지 않습니다. 교집합까지 비례하는 것은 다른 그림(오일러 다이어그램)이며 수치 최적화가 필요합니다. style A fill:#ff6b6b는 집합을 칠하고, 쉼표를 쓰면(style A,B color:#333) 그 집합들의 합집합에 적용됩니다.

cynefin(cynefin-beta)는 의사결정을 분류하는 스노우덴 틀을 그립니다. 다섯 영역은 이름이 고정이고(complex, complicated, chaotic, clear, confusion) 위치도 고정입니다(네 사분면과 가운데의 confusion). 고르는 것은 각 영역 안에 들어갈 내용뿐입니다. 항목은 한 줄에 하나씩 따옴표로 묶고, complex --> complicated : "패턴 파악"은 영역 사이의 전환을 그립니다. 다섯 밖의 이름은 줄을 가리키고 있는 이름을 알려 주며 거부합니다. clear와 chaotic의 경계는 물결모양으로 나옵니다. 모델에서 그곳은 낭러러지이기 때문이며, 여기서 물결은 항상 같아서 여는 때마다 그림이 바뀌지 않습니다.

swimlane(swimlane-beta)은 담당별 레인으로 나눈 프로세스를 그립니다. 문법은 순서도와 같고(같은 도형, 화살표, 라벨, classDef), subgraph은 상자가 아니라 레인이 됩니다. 모든 노드는 어느 레인에든 들어가야 합니다 — 밖에 남은 노드는 누구의 일인지 말할 수 없어 거부합니다 — 레인 안의 레인도 거부합니다. LR에서 레인은 행이고 흐름은 오른쪽으로, TB에서는 열이고 흐름은 아래로 갑니다. 흐름 상의 위치는 각 작업까지의 가장 긴 경로로 정해지고, 띄는 주인의 것입니다. 작업은 그렇게 하는 편이 더 빽빽해지더라도 절대 자기 레인을 벗어나지 않습니다.

agentflow(agentflow-beta)는 AI 에이전트 흐름을 그리며, 실질적으로 순서도의 다른 어휘입니다. 화살표는 같고, flow id["이름"] … end이 subgraph 역할을 하며(중첩도 됩니다), global … end은 모든 에이전트가 참조하는 것을 담고, connector id["이름"]은 외부 시스템을 선언합니다. 정말 달라지는 것은 각 단계의 역할을 말하는 도형입니다: @{ shape: input }, task, tool(도구 호출), decision, refdoc(참조 문서), action(최종 행동). 문서는 -.-로, 화살표 없이 연결합니다. 참조할 뿐 흐름의 단계가 아니기 때문입니다. 에이전트를 글로 설명하는 키(instruction, params, returns, connectorRef, protocol, endpoint)는 읽되 그림에서는 무시합니다. 이 도형 이름들은 여기에서만 유효하고, flowchart에서는 거부됩니다. 거기서는 Mermaid에도 없기 때문입니다.

usecase(usecase-beta)는 UML의 유스케이스 다이어그램을 그립니다. actor로 선언한 것은 사람 모양이 되고, 나머지는 모두 유스케이스로 타원으로 그려집니다. 바로 이 구분을 보이려고 있는 그림입니다. 유스케이스는 Id("라벨"), Id[라벨], Id만, 또는 따옴표 문자열만으로도 쓸 수 있습니다. systemBoundary "이름" … end은 시스템 경계이고, note for X "텍스트"는 메모를 달아 둡니다. 관계는 UML 그대로입니다: -->는 연관, --|>는 일반화(빈 삼각형이 일반적인 쪽에), A ..> : include B(대상은 콜론 뒤에)는 점선 «include»이며 extend도 같습니다. 그림을 바꾸지 않는 행위자 설명 키(type, business, icon)는 읽되 무시하고, <<스테레오타입>>은 라벨에 들어갑니다. json 노드는 아직 그리지 않으며 코드 블록으로 남습니다. 여러 줄에 걸친 데이터 트리이기 때문이며, 거기서 JSON은 그대로 읽힙니다.

wardley(wardley-beta)는 워들리 맵을 그립니다. 세로축은 사용자에게의 가시성(위쪽이 사용자가 보는 것), 가로축은 Genesis에서 Commodity까지의 진화도입니다.

쌍의 순서에 유의하세요: component 차 [0.63, 0.81]는 [가시성, 진화도]이며 첫 번째 숫자가 세로축입니다. 반대로 읽으면 그림은 그대로 그려지면서 다른 전략을 말하게 됩니다. anchor는 위에 있는 사용자, A -> B는 사슬(이름에 공백을 넣을 수 있고 따옴표는 선택), A +> B는 흐름(더 굵으며 +<>는 양방향, +'텍스트'>는 라벨 포함), evolve 주전자 0.62는 가야 할 위치까지의 점선 화살표입니다. 그 밖에 evolution(축 단계 이름), size, (build)/(buy)/(outsource)/(market), (inertia)(저항 막대), label [dx, dy], pipeline X { … }, note, accelerator/deaccelerator, 번호가 붙은 annotation과 annotations 범례를 쓸 수 있습니다.

eventmodeling은 이벤트 모델링을 그립니다. 세 개의 레인으로 된 타임라인으로, 위가 화면, 가운데가 명령(과 읽기 모델), 아래가 이벤트입니다. 각 줄은 tf 02 cmd AddItem 형태이며, 숫자는 시점(열), 가운데 단어는 레인을 고르는 유형입니다 — ui, cmd/command, pcr/processor, rmo/readmodel, view, evt/event(긴 형태도 같습니다). 레인은 선언하지 않습니다. 그것이 바로 이 방법론이기 때문입니다. rf(resetframe)는 새 슬라이스를 열며 점선 구분선이 들어갑니다 — 이야기가 다시 시작되는 지점입니다. 스키마는 중괄호({ description: string })나 data … { … } 블록 참조([[Data]])로 주며, 블록은 뒤에 와도 됩니다. ->> 02 ->> 03은 그 프레임을 먹여 주는 시점들을 번호로 연결합니다.

railroad(railroad-ebnf-beta, -abnf-beta, -peg-beta, railroad-beta)는 문법을 철로도처럼 그립니다. 규칙 하나하나가 손가락으로 따라갈 수 있는 경로가 되고, 쓸 수 있는 것이 곳 갈 수 있는 경로입니다. 규칙은 이름 = 식 ;(PEG은 이름 <- … ;)이며 여러 줄에 걸쳐도 됩니다 — 닫는 것은 ;입니다. 따옴표 문자열은 단말(캡슐 모양), 맨 이름은 다른 규칙(사각형)입니다. |(또는 /)는 선택, ?는 선택적, +는 한 번 이상, *는 영 번 이상이고 ( ), [ ], { }는 묶기·선택·반복입니다. ABNF는 반복을 앞에 두고(1*( ALPHA / "-" ), *DIGIT), PEG은 !x·&x 술어를 받으며(입력을 소비하지 않아 라벨로 들어갑니다), railroad-beta는 함수 표기(sequence(choice(terminal("+"), …)))를 받습니다. 넷은 모두 같은 그림으로 떨어집니다: 위로 지나가는 길이 선택적, 아래로 도는 고리(뒤로 향한 화살표)가 반복입니다.

requirementDiagram은 요구사항과 요소를 칸이 나뉜 상자로 그립니다. 선언한 종류(requirement, functionalRequirement, performanceRequirement, interfaceRequirement, physicalRequirement, designConstraint)는 이름 위에 겹화살괄호로 표시되고, id·text·risk·verifymethod 항목이 각각 한 줄이 됩니다(element에서는 type과 docref). 관계(satisfies, traces, derives, verifies, refines, copies, contains)는 a - satisfies -> b로 쓰거나 뒤집어서 b <- satisfies - a로 쓰며, 뒤집은 형태에서는 먼저 쓴 이름이 도착점입니다. 실선은 contains뿐이고 기호는 담고 있는 쪽에 붙습니다. 나머지는 점선이고 화살표는 도착점에 있습니다. 공백이 들어간 이름은 따옴표로 묶습니다.

gitGraph는 저장소의 기록을 그립니다. commit마다 시간이 한 칸 나아가고, branch 이름은 새 줄기를 열면서 그대로 그 줄기에서 작업을 이어갑니다(git switch -c와 같습니다). checkout은 다른 줄기로 돌아가고 merge는 둘을 합칩니다. 속성은 콜론으로 씁니다: commit id: "텍스트" tag: "v1" type: HIGHLIGHT(REVERSE도 됩니다), branch 이름 order: 2는 줄기의 차례를 바꿉니다. cherry-pick id: "…"에는 실제로 있는 커밋의 id가 필요합니다. 모양이 종류를 말합니다 — 보통 커밋은 채운 점, 강조한 커밋은 사각형, 되돌린 커밋은 X가 들어간 원, 병합은 이중 고리, cherry-pick은 잘린 원입니다. 테마에 따라 팔레트의 두 색이 비슷해 보일 수 있어서, 그때는 모양만이 둘을 갈라 줍니다. LR:(기본값), TB:, BT:는 시간 축의 방향을 바꿉니다. 없는 브랜치를 checkout/merge하면 요청하지 않은 줄기를 만들어 내는 대신 줄 번호를 알려 주고 그리기를 그만둡니다.

C4 계열(C4Context, C4Container, C4Component, C4Dynamic, C4Deployment)도 그립니다. 여기서는 모든 것이 매크로라서 문법에 화살표가 하나도 없습니다. 요소마다 종류를 겹화살괄호로 위에 적고, 이름을 굵게, 설명을 아래에 둔 상자가 됩니다: Person(alias, "이름", "설명"), System, Container, Component과 Db·Queue·_Ext 변형입니다. Container와 Component에서는 세 번째 인자가 기술이고(Container(app, "App", "C++/Qt", "하는 일")), 나머지에서는 세 번째가 곧 설명입니다. 경계(Boundary, Enterprise_Boundary, System_Boundary, Container_Boundary, C4Deployment의 Node)는 중괄호를 열고 제목이 붙은 상자가 되며, 중첩도 됩니다. 연결은 Rel(a, b, "레이블", "기술")로 쓰고, BiRel은 양쪽 끝에 화살표를 두며 Rel_Back은 반대쪽을 가리킵니다. C4Dynamic은 관계에 나온 순서대로 번호를 붙입니다. 위치 힌트(Rel_U, Rel_D, Rel_L, Rel_R)와 Update…Style은 받아들이되 무시합니다. 배치는 다른 다이어그램과 같은 레이아웃이 정하고, 색은 노트 테마에서 나오기 때문입니다. 선언하지 않은 별칭을 가리키는 관계는, 쓰지도 않은 상자를 만들어 내는 대신 줄 번호를 알려 주고 그리기를 그만둡니다.

보드, 차트, 패킷

kanban에서는 들여쓰기가 문법이고 단계는 둘입니다. 바깥쪽이 레인, 안쪽이 카드입니다(id[레이블], 또는 글자만). 카드 뒤의 @{ ticket: LN-9, assigned: 'ana', priority: 'High' }는 카드 본문에 들어가지 않습니다. 티켓과 담당자는 전용 아래줄로 가고, 우선순위(Very High, High, Low, Very Low)는 왼쪽 띠의 색이 되어 따뜻한 색에서 찬 색으로 이어집니다. 레인은 모두 같은 줄에서 끝나고, 카드가 없는 레인도 그대로 보입니다. 빈 칸임을 알려 주는 것이 바로 그 레인이기 때문입니다. 이것은 노트 안에서 흐름을 설명하기 위해 그려 놓은 보드입니다. 카드를 끌어다 놓으며 실제로 작업하는 보드는 앱 자체의 작업 패널입니다.

xychart(xychart-beta)는 두 축 위에 막대와 꺾은선을 그립니다. x-axis "제목" [1월, 2월, 3월]로 분류를 주고(공백이나 쉼표가 든 이름은 따옴표로 감쌉니다), y-axis "제목" 0 --> 100으로 눈금 범위를 정하며, bar [10, 40, 90]이나 line [20, 30, 80]이 각각 계열을 하나씩 더합니다. 값은 분류마다 하나씩, 분류를 선언한 순서대로 대응합니다. 값의 개수가 맞지 않는 계열은 해당 줄을 알려 주며 그리기를 거부합니다. 막대가 다른 분류로 밀려나서 그래프가 다른 이야기를 하게 되기 때문입니다. y-axis가 없으면 눈금은 데이터에서 나오고, 데이터가 그 아래로 내려가지 않는 한 0에서 시작합니다. 가장 작은 값에서 시작하면 막대 사이의 차이가 과장되는데, 그건 아무도 고른 적이 없습니다. 범위를 선언했다면 범위를 벗어난 값은 그림 밖으로 삐져나가는 대신 거부됩니다.

x-axis는 연속 범위(0 --> 100)도 받으며, 쓰지 않으면 분류는 번호가 됩니다. 막대 계열이 둘이면 나란히 그립니다. mermaid처럼 겹치면 뒤의 계열이 사라지기 때문입니다. xychart-beta horizontal은 아직 그리지 못하고 코드 블록으로 남습니다. 세로로 그리면 축이 뒤바뀐 그래프를 건네는 셈이기 때문입니다. 계열에 이름을 붙일 수 있습니다(bar "공개" [10, 40], line "비공개" [20, 30]). 이름은 플롯 위의 범례가 되고, 칠한 막대·점이 있는 선처럼 각 계열의 모양을 그대로 쓴다 — 색깔만으로는 구분되지 않기 때문입니다. 선 계열에서는 값에 라벨을 달 수 있으며([540 "PaLM", 65]) 점 위에 그려집니다. 막대에서는 Mermaid처럼 무시됩니다.

radar(radar-beta)는 중심에서 뻗어 나가는 축 위에 한 개 이상의 곡선 프로필을 그립니다. axis a["레이블"], b, c로 축을 선언하고(이 줄은 여러 번 쓸 수 있습니다), curve x["이름"]{80, 60, 90}로 축마다 값을 하나씩 줍니다. 값은 축을 선언한 순서대로 대응합니다. 이름을 쓰는 형태({a: 80, c: 90, b: 60})도 됩니다. 방향에 주의하세요: 첫 번째 축은 위를 향하고 도는 방향은 시계 방향입니다. max와 min은 눈금 범위를 정하며(max가 없으면 읽어 들인 가장 큰 값이 됩니다), 범위를 벗어난 값은 잘라내지 않고 해당 줄을 알려 주며 그리기를 거부합니다. ticks는 고리 개수를 바꾸고, graticule circle은 고리를 원으로 만들며, showLegend false는 범례를 없앱니다. 값의 개수가 축의 개수와 맞지 않는 곡선도 거부합니다. 그것은 덜 그려진 그림이 아니라 다른 그림이기 때문입니다.

packet(packet-beta)은 패킷의 비트 배치를 그립니다. 각 필드는 0-15: "레이블"처럼 쓰고, 범위는 양끝을 모두 포함합니다. 0-15는 열여섯 비트입니다. 비트 하나는 4: "레이블"로 쓰고, 상대 형식 +16: "레이블"은 다음 열여섯 비트를 가져오므로 중간에 필드를 넣어도 전부 다시 셀 필요가 없습니다. 필드는 빈틈없이 이어져야 합니다. 빈틈이나 겹침이 있으면 해당 줄을 알려 주며 그리기를 거부하는데, 둘 다 뒤에 오는 모든 것을 조용히 밀어내기 때문입니다. 한 줄은 32비트이고, 줄바꿈을 넘어가는 필드는 두 줄에 걸쳐 그려지며 레이블은 더 넓은 쪽에 들어갑니다. 격자 위의 숫자는 각 필드가 시작하는 위치와 각 줄의 마지막 비트를 나타냅니다.

격자, 면적, 아키텍처, 흐름, ZenUML

block(block-beta)은 상자의 격자를 그리며, 위치는 쓴 순서로 정해집니다. columns 3으로 열 수를 정하고(쓰지 않으면 모두 한 줄에 놓입니다), 각 상자는 순서도와 같은 모양(a["레이블"], b(("원")), c{"마름모"})을 받으며, a:2는 상자가 두 열을 차지하게 하고 space(또는 space:2)는 빈자리를 남깁니다. block:id … end는 격자 안에 격자를 넣고 자체 columns를 가지며, 바깥이 하나의 상자가 됩니다. 화살표는 순서도의 것(a --> b, 레이블은 a -- "글" --> b)이지만, 여기서는 이미 선언된 블록을 가리킬 뿐입니다. 없는 이름을 가리키는 화살표는 쓰지도 않은 칸에 상자를 만들어 내는 대신, 해당 줄을 알려 주며 그리기를 거부합니다. 열 사이의 간격은 화살표 레이블이 들어갈 때까지 넓어져서 옆 상자에 닿지 않습니다. 블록 화살표(a<["이동"]>(right))는 화살표 모양의 상자입니다. 방향은 괄호 안에 적고(right, left, up, down, 가로 둘은 x, 세로 둘은 y) 조합할 수 있습니다((x, down)). 없는 방향은 아무 화살표로 바뀌는 대신 줄을 가리키며 다이어그램을 거부합니다.

treemap(treemap-beta)은 넓이 지도를 그립니다. 각 사각형의 넓이는 값에 비례하고, 들여쓰기로 중첩되며 깊이에 제한이 없습니다. 잎은 값을 선언하고("이름": 12) 구역은 아무것도 선언하지 않습니다. 구역의 값은 자식의 합이며, 자체 합계를 허용하면 자기 구성에 대해 거짓말하는 사각형이 생기므로 해당 줄을 알려 주며 그리기를 거부합니다. 공백이나 쌍점이 든 이름은 따옴표로 감싸고, classDef와 :::클래스로 색을 줍니다. 배치는 squarified로 사각형을 정사각형에 가깝게 유지합니다. 늘 같은 축으로만 자르면 눈으로 비교할 수 없는 띠가 되는데, 넓이를 비교하는 것이 이 그림이 하는 유일한 일이기 때문입니다. 레이블과 값은 사각형 안에 온전히 들어갈 때만 나타납니다. 가장자리에서 잘리면 아무것도 알려 주지 못하기 때문입니다.

architecture(architecture-beta)는 서비스와 그 사이의 연결을 그립니다. service api(server)[API]로 구성 요소를 선언하고, group gureum(cloud)[클라우드]로 경계를 열며, 접미사 in gureum은 서비스를 그 안에 넣고(그룹은 중첩됩니다), junction j는 연결을 꺾을 모서리를 만듭니다.

위치를 정하는 것은 연결의 「변」입니다. a:R -- L:b는 a의 오른쪽 변을 b의 왼쪽 변에 붙이므로, b는 a의 오른쪽에 놓입니다. L, R, T, B를 쓸 수 있고, 화살촉은 <나 >가 있는 쪽에 나타납니다(-->, <-->, 화살촉 없는 --). 끝에 붙인 {group}은 선을 안쪽 상자가 아니라 그룹의 경계로 보냅니다. 아이콘은 Mermaid가 기본으로 담고 있는 다섯 개입니다 — cloud, database, disk, internet, server. 그 밖의 이름은 해당 줄을 알려 주고 쓸 수 있는 이름을 제시하며 그리기를 거부합니다. 나머지(logos:aws-lambda 같은 것)는 Iconify에서 오며, 페이지를 게시하는 쪽이 자바스크립트로 아이콘 팩을 등록한 곳에서만 나타나는데 GitHub조차 등록하지 않습니다. 여기서 받아들이면 다른 어디에서도 재현되지 않는 그림을 건네는 셈입니다. align row a b c(또는 align column)는 적은 구성원들을 같은 줄—또는 같은 열—에 놓습니다. 없는 이름은 이유를 말하지 않은 채 배치를 그대로 두는 대신 줄을 가리키며 다이어그램을 거부합니다.

sankey(sankey-beta)는 흐름 다이어그램을 그리며, 띠의 두께가 곧 값입니다. 본문에는 화살표가 하나도 없고 세 열짜리 CSV(출발,도착,값)로, 한 줄이 연결 하나입니다. 같은 이름을 양쪽 끝에 적으면 흐름이 이어집니다. 쉼표가 든 이름표는 따옴표로 감싸고, 그 안의 따옴표는 두 번 적습니다("고정 ""비용"""). 같은 출발/도착 짝이 반복되면 더해집니다. 노드 막대의 높이는 들어오는 양과 나가는 양 가운데 큰 쪽입니다. 받는 것보다 많이 나눠 주는 노드에서 나가는 띠가 테두리를 넘지 않게 하기 위해서입니다. 열은 각 노드까지의 가장 긴 경로에서 정해지고, 나가는 곳이 없는 노드는 마지막 열로 갑니다. 0 이하의 값, 자기 자신으로 가는 연결, 순환은 줄을 짚어 다이어그램을 거절합니다. 순환에는 가장 긴 경로가 없고, 그리려고 연결 하나를 끊으면 적지 않은 흐름을 보여 주게 되기 때문입니다. 여기에는 title이 없습니다. 본문이 순수한 CSV라서, 받아들이면 LightNote에서는 잘 그려져도 Mermaid에서는 문법 오류가 됩니다.

zenuml은 같은 그림을 위한 또 다른 문법— 시퀀스 다이어그램 —으로, 화살표 대신 코드처럼 씁니다. 동기 호출은 대상만 적고(Store.register(item)), 보내는 쪽은 그것을 감싼 블록입니다. Store.register() { Stock.reserve() } 안에서 Stock을 부르는 것은 Store입니다. 가장 바깥에서 부르는 것은 시작자이며 @Starter(Ana)가 이름을 줍니다. 적지 않으면 막대 인형 User가 쓰이고, 어떤 호출이 필요로 할 때만 나타납니다. 비동기 메시지는 A->B: 텍스트(열린 화살촉, 아무도 기다리지 않음)이고 A->B.method()는 보내는 쪽을 직접 적은 동기 호출입니다. {}가 중첩하고, return x는 감싼 호출을 한 쪽으로 돌아가며(중간의 if는 영향을 주지 않습니다), x = A.m()은 같은 응답의 다른 표기, new A(args)는 생성, // 주석은 다음 메시지 위의 메모가 됩니다. 블록은 if/else if/else, while/for/forEach/loop, opt, par, try/catch/finally이며, } else {는 새 틀을 여는 대신 같은 틀을 구분선으로 이어 갑니다. @Actor는 막대 인형을 그리고, 다른 주석자(@Database, @Boundary 등)는 이름표의 스테레오타입(«Database» Stock)이 됩니다. 여기서는 그 아이콘들을 그리지 않기 때문이며, 이름은 그대로 보입니다. 공백이 든 이름은 따옴표로 감쌉니다.

이 블록이 어디로 가는지 유의하세요. Mermaid에서 zenuml은 페이지가 JavaScript로 등록해야 하는 외부 다이어그램이고 GitHub은 그렇게 하지 않으므로, 여기서 그려지는 같은 노트가 그곳에서는 코드 블록으로 남습니다.

그리고 LightNote가 다이어그램을 읽지 못하면 블록 바로 아래에 이유와 줄 번호를 알려 줍니다. 아직 그리지 않는 종류에는 경고가 나오지 않습니다. 작성한 내용에 잘못이 없기 때문입니다.