저는 한 모델에게 동일한 44개 노드 아키텍처를 두 번 요청했습니다.

첫 번째에는 가공되지 않은 SVG를 요청했습니다. 모든 박스를 배치하고, 모든 에지 (edge)의 경로를 지정하며, 좌표를 전달해 달라고 했습니다. 두 번째에는 동일한 시스템을 텍스트 형식의 JSON으로 설명하고 레이아웃 엔진 (layout engine)이 이를 그리도록 요청했습니다. 동일한 모델, 동일한 세션, 동일한 지침이었습니다. 제가 바꾼 유일한 것은 출력 범위 (output boundary)뿐이었습니다.

두 경우 모두 박스들은 괜찮았습니다. 이 점에 대해서는 솔직하게 말씀드리고 싶은데, 이 주장의 일반적인 버전은 이미 시대에 뒤처졌기 때문입니다. 모델들은 이제 라벨이 붙은 박스를 잘 배치합니다. 현재의 프런티어 모델 (frontier model)에게 6개의 박스로 이루어진 플로우차트 (flowchart)를 SVG로 요청하면 깔끔한 6개 박스 플로우차트를 얻을 수 있습니다. 만약 그것이 필요하다면 그렇게 하십시오. 그것은 올바른 도구이며 저는 그렇지 않은 척하지 않겠습니다.

문제가 된 것은 에지 (edges)였습니다.

경로 지정 알고리즘 (routing algorithm)이 없었기에, 모델은 단순히 관련 없는 박스들을 가로지르는 긴 대각선을 그렸습니다. 몇 개 수준이 아니라, 그래프가 밀집된 모든 곳에서 발생했습니다. 그리고 노드 하나를 변경했을 때, 수동으로 배치된 전체 좌표 레이아웃 (coordinate layout)을 다시 생성해야 했으며, 결과물은 이전과 달라져 있었습니다.

두 번째 부분이 실제로 저를 짜증 나게 했던 부분입니다. 이것은 눈을 가늘게 뜨고 넘길 수 있는 렌더링 버그가 아닙니다. 그림은 죽은 유물 (dead artifact)입니다. 차이점(diff)을 비교할 수도 없고, 박스 하나만 수정할 수도 없으며, 동일한 것을 두 번 얻을 수도 없습니다. 모든 변경 사항은 전체 재생성(full regeneration)이며 새로운 주사위 던지기입니다.

이것은 "더 나은 모델을 기다려라"라는 문제가 아닙니다

만약 다른 사람이 이 글을 썼다면 제가 반박했을 부분이라, 제 논거를 말씀드려 보겠습니다.

중첩된 그래프 (nested graph)에서 장애물을 피해 커넥터 (connector)의 경로를 지정하는 것은 전역 제약 최적화 (global constraint optimization) 문제입니다. 이것은 ELK와 같은 레이아웃 엔진이 존재하여 해결하고자 하는 구체적인 문제입니다. SVG를 생성하는 모델은 전체 그림을 본 후에도 되돌아갈 방법 없이, 모든 지점에 대해 순서대로 x/y 좌표를 확정해야 합니다. 모델은 레이아웃을 해결하는 것이 아니라, 다음 토큰 (token)을 예측하고 있는 것입니다.

따라서 더 나은 모델은 엉킨 모서리(untangled edges)가 아니라 깔끔한 상자(nicer boxes)를 제공합니다. 실패는 구조적인 것이며, 수십 개의 노드를 넘어서면 여러 모델에서 재현될 것으로 예상합니다. 만약 그렇게 믿지 못한다면, 정직하게 테스트해보는 것이 좋습니다. 신뢰하는 어떤 모델이든 40개 노드 아키텍처를 던져보고 모서리를 살펴보세요. (제가 이 이미지의 배경이 되는 방법을 별도의 게시물에 작성했습니다—동일한 모델, 단발성 처리, 수정 과정 없음—하단 링크에서 확인하실 수 있습니다.)

제가 내린 결론은 다음과 같습니다: 다이어그램을 그리는 것은 잘못된 출력 유형입니다. 'AI가 다이어그램을 만들지 못한다'는 것이 아닙니다. 경계가 잘못 설정되어 있는 것입니다.

그러니 경계를 이동시키세요

모델이 본래 잘하는 일, 즉 다이어그램이 무엇을 의미 하는지를 설명하도록 하고, 실제 엔진이 공간 수학(spatial math)을 담당하게 하세요. 그것이 Glyphic입니다. 모델은 순수한 타입의 JSON을 방출합니다. 좌표도 없고, 오타가 날 수 있는 DSL 문법도 없습니다:

{
  "type": "flowchart",
  "nodes": [
...

ELK는 위치와 라우팅(데이터 타입에 대한 d3)을 계산하고, SVG를 Rust의 resvg를 통해 네이티브로 PNG로 래스터화합니다. 이 세 가지 요소는 모델 성능과 관계없이 유지됩니다.

검증은 충돌이 아니라 계약입니다. JSON은 어떤 것이 렌더링되기 전에 엄격한 Zod 스키마에 도달합니다. 모델이 잘못되면 edges[2].target references unknown node 'paymentss'와 같이 정확하고 다음 차례에서 수정 가능한 오류 메시지를 받게 됩니다. 이것이 generate → validate → fix → render 루프가 실제로 작동하게 만드는 요소입니다. Mermaid 같은 DSL은 오타 하나에 파싱 충돌(parse-crashes)을 일으키고 에이전트에게 아무것도 할 수 있는 것을 주지 않습니다.

스택에 브라우저가 없습니다. 제가 시도했던 모든 '서버 측 다이어그램 렌더링' 경로는 결국 헤드리스 Chromium을 호출하는 것으로 끝났습니다—약 300MB 크기에 호출할 때마다 발생하는 콜드 스타트 비용이 발생합니다. 여기서 레이아웃과 래스터화는 모두 네이티브하므로, 일반적인 Node 의존성처럼 Lambda나 CI 작업, 또는 에이전트 루프에 배포될 수 있습니다. 이것은 인프라의 사실이며, 모델 품질에 대한 주장이 아니기 때문에 제가 이 프로젝트에 대해 할 수 있는 가장 지속 가능한 말입니다.

규모가 커져도 비용이 저렴하게 유지됩니다. 큰 다이어그램을 손으로 그리는 것은 수천 개의 좌표 토큰(coordinate tokens)을 소모하며, 이는 속도가 느릴 뿐만 아니라 출력 제한(output ceiling)을 초과하여 렌더링이 깨진 채로 잘려버릴 위험이 있습니다. 반면, 컴팩트한 JSON을 입력하면 기하학적 구조(geometry)가 결정론적(deterministically)으로 생성됩니다.

또한 JSON이 신뢰할 수 있는 단일 원천(source of truth)이기 때문에, 다이어그램은 편집 가능한 데이터 상태로 유지됩니다. 차이점(Diff)을 비교하고, 노드 하나를 변경하거나, 테마를 바꾸고, 다시 렌더링할 수 있습니다. 처음부터 다시 생성하며 결과가 잘 나오길 기도해야 하는 단순한 그림이 아닙니다.

실제로 얻게 되는 것

단 한 번의 호출로 SVG, 고해상도 PNG, 그리고 React Flow JSON을 얻을 수 있습니다. 하나의 스키마(schema) 뒤에는 18가지의 다이어그램 유형이 있습니다 — 중첩된 VPC 및 클러스터가 포함된 아키텍처(architecture), 시퀀스(sequence), 까마귀 발 표기법(crow's-foot notation)이 적용된 ERD, UML 클래스(UML class), 상태 머신(state machines), 플로우차트(flowcharts), 간트(Gantt), 타임라인(timelines), 산키(Sankey), Git 트리(Git trees), 마인드맵(mindmaps), C4, 파이(pie), 사분면(quadrant), 칸반(kanban), 사용자 여정(user journeys), 트리맵(treemaps), 그리고 자유 형식 캔버스(freeform canvas)가 있습니다. 이 모든 유형은 갤러리에서 정확한 JSON 입력값으로부터 렌더링된 모습을 확인할 수 있으므로, 제 말을 믿는 대신 직접 결과물을 판단할 수 있습니다. 테마 설정, 모든 Google Font, FontAwesome 아이콘, 그리고 손으로 그린 듯한 스케치 스타일(hand-drawn sketch style)도 포함되어 있습니다.

내부 엔진은 동일하며, 실행 방식은 세 가지가 있습니다.

MCP 서버로서 실행: 설치가 필요 없는 30초 버전입니다.

claude mcp add glyphic -- npx -y @glyphicjs/mcp-server

그다음 이렇게 요청하기만 하면 됩니다: "Glyphic를 사용하여 사용자, 게시물, 댓글이 포함된 블로그의 ERD를 그려줘." 모델이 JSON을 생성하고 도구(tool)를 호출하면 다이어그램이 나타납니다. Cursor, Claude Desktop, VS Code, Windsurf 등 MCP를 지원하는 모든 환경에서 작동합니다.

라이브러리로서 실행:

npm install @glyphicjs/core @glyphicjs/schema

import { processDiagram } from "@glyphicjs/core";
import { writeFileSync } from "node:fs";

...

또는 자체 HTTP 엔드포인트 뒤에 셀프 호스팅(self-hosted): 모든 클라이언트에 라이브러리를 배포하고 싶지 않은 경우에 적합합니다.

라이선스, 명확하게

Schema와 MCP 서버는 MIT 라이선스입니다. 핵심 엔진은 FSL-1.1입니다. 사용, 수정, 셀프 호스팅(self-host)이 가능하지만, 유일한 제한 사항은 이를 경쟁 관계인 호스팅 서비스(hosted service)로 재판매할 수 없다는 점입니다. 또한 이 라이선스는 2년 후에 Apache-2.0으로 전환됩니다. 이는 지연된 오픈 라이선스(delayed open license)를 가진 소스 공개(source-available) 방식이며, 첫날부터 OSI 승인을 받은 것은 아닙니다. 과장해서 말하기보다는 이렇게 표현하는 것이 더 정확할 것 같습니다.

직접 체험해보기

• Playground (로그인 불필요): https://glyphic.web.app/generate
• Repo (저장소): https://github.com/MS-Teja/Glyphic
• 비교 전/후(before/after) 결과가 허수아비 공격(strawman)이 아닌 공정한 테스트인지 궁금하신가요? 제가 방법론을 정리해 두었습니다: Is the AI-diagram comparison fair?

이 프로젝트는 저 혼자 만들었습니다. 만약 에이전트(agents), 파이프라인(pipelines), 또는 다이어그램이 필요한 제품을 개발 중이시라면 여러분의 피드백을 기다리고 있으며, star를 눌러주시면 큰 도움이 됩니다.

ELK 레이아웃(layout) 선택, resvg의 트레이드오프(tradeoffs), 또는 스키마(schema) 설계에 대해 댓글로 심도 있게 논의할 준비가 되어 있습니다.