작은 Mermaid와 함께 프롬프트 엔지니어링을 개선하세요
Source: Dev.to
Summary
아마도 여러분은 이미 Mermaid Diagrams를 많이 보셨을 텐데, 그 뒤에 있는 공식 기술 언어가 LLM이 잘 이해한다는 사실을 깨닫지 못했을 수도 있습니다.
Mermaid 구문은 “A가 발생하고, 그 다음 B가 발생하며, X이면 C가 발생한다”와 같은 형식적이고 구조적이거나 시간적인 정보를 설명하기에 탁월합니다. 명확성을 강제하고 시각화가 텍스트 정의를 정확히 반영하도록 보장하므로 prompt‑as‑code 접근 방식에 완벽합니다.
프롬프트에 보완적인 Mermaid 코드를 추가하면 LLM에게 Dual‑Path Reinforcement를 제공하게 됩니다:
- 텍스트는 컨텍스트, 의도, 뉘앙스, 부드러운 제약조건을 제공하여 목표를 설명하고 모호성을 명확히 하며 전체 해석을 안내합니다.
- Mermaid 코드는 텍스트를 기반으로 하는 엄격하고 협상 불가능한 논리를 제공하여 흐름, 참여자, 타이밍, 조건(루프, 분기)을 명시적으로 정의하고 환각이나 오해를 방지합니다.
다이어그램이 정의되면 프롬프트 엔지니어는 단순히 시각화를 참조하면 되므로, 논리 흐름을 파악하기 위해 장황한 Mermaid 코드를 다시 읽을 필요가 없습니다. 이러한 시각적 명료성은 JSON이나 TypeScript와 같은 다른 prompt‑as‑code 접근 방식에 비해 큰 장점입니다.
Why Mermaid Syntax Helps an LLM
대형 언어 모델(LLM)에게 Mermaid 구문은 구조화된 정보를 처리할 때 몇 가지 핵심적인 장점을 제공합니다:
- 복잡한 시스템에 대한 자연어 설명(예: “A가 B를 사용하고, B는 D가 없을 경우 C를 호출한다”)은 본질적으로 모호합니다. LLM은 컨텍스트를 해석하고 언어적 관계를 해결해야 합니다.
- Mermaid는 도메인‑특정 언어(DSL)로, 매우 구조화되고 모호함이 없습니다.
A --> B는 “A가 B에 연결된다”는 의미를 명확히 나타내어 엔터티와 방향 관계를 즉시 드러내며, 자연어 해석 작업을 단순 파싱 작업으로 전환합니다. - Mermaid를 사용하면 LLM이 텍스트를 잘 정의된 개념 구조(그래프, 트리, 타임라인)와 직접 매핑할 수 있어, 인간이 흐름도를 즉시 이해하듯 모델도 빠르게 파악합니다.
Example: Describing a Purchase Order Process
보완적인 Mermaid 구문을 LLM 프롬프트에 추가했을 때의 효율성과 구조적 명료성을 보여주기 위해, 흔히 접할 수 있는 시나리오인 전자상거래 시스템에서 사용자가 상품을 구매하는 과정을 살펴보겠습니다. 여기서는 세 개의 서비스—Frontend, OrderService, InventoryService—가 관여합니다.
Steps
- 사용자가 Frontend에서 Buy 버튼을 클릭합니다.
- Frontend가 주문을 시작하기 위해 OrderService에 요청을 보냅니다.
- OrderService는 재고를 확인하기 위해 InventoryService에 문의합니다.
- InventoryService가 재고 수준을 반환합니다.
- 재고가 충분하면 OrderService가 InventoryService에서 재고를 차감합니다.
- OrderService가 주문 확인을 Frontend에 반환합니다.
- Frontend가 성공 메시지를 표시합니다.
Textual Representation
구매 프로세스는 Frontend가 OrderService에 제품 ID와 원하는 수량을 지정하여 요청을 보낼 때 시작됩니다.
OrderService는 해당 제품 ID에 대한 현재 재고 수준을 확인하기 위해 InventoryService를 호출합니다. 이 확인이 끝나면 InventoryService는 사용 가능한 수량을 응답합니다.
- 재고가 충분한 경우: OrderService는 InventoryService에 구매 수량을 차감하도록 메시지를 보내고, 이후 새로운 주문 ID를 포함한 주문 확인을 Frontend에 전송합니다.
- 재고가 부족한 경우: OrderService는 해당 분기를 종료하고 즉시 “Error: Out of Stock” 메시지를 Frontend에 전송합니다.
결과와 관계없이 Frontend는 최종적으로 사용자에게 적절한 성공 또는 실패 메시지를 표시합니다.
Complementary Mermaid Sequence Diagram (DSL)
sequenceDiagram
participant F as Frontend
participant O as OrderService
participant I as InventoryService
F->>O: Initiate Purchase (Product ID, Qty)
O->>I: Check Stock (Product ID)
I-->>O: Stock Available (Qty)
alt Stock Available
O->>I: Deduct Stock (Qty)
O-->>F: Order Confirmation (ID)
else Stock Unavailable
O-->>F: Error: Out of Stock
end
F->>F: Display Success Message조합된 입력은 핵심 LLM 약점을 보완합니다:
- 텍스트의 모호성 – Mermaid가 엄격하고 협상 불가능한 논리를 제공하여 설명을 기반으로 고정합니다.
- 환각/창의성 – Mermaid가 모델을 강제된 구조로 제한해 존재하지 않는 단계를 만들어내는 것을 방지합니다.
- 긴 컨텍스트에서의 추적 상실 – 다이어그램은 파싱하기 쉬운 요약 역할을 하여 모델이 텍스트와 시각적 논리를 교차 검증하고 장기적인 주의를 유지하도록 돕습니다.
Appendix: Mermaid Diagram Types You Should Consider for Your Prompts
| Diagram Type | Suitable For | Example Use Case | Key Benefit for the LLM |
|---|---|---|---|
Flowchart (graph TD, LR, 등) | 시간 흐름, 프로세스 로직, 의사결정 트리 | 복잡한 함수의 실행 경로 매핑, 배포 파이프라인 설명, 사용자 가입 워크플로우 개요 | 명시적인 노드‑간 연결을 통해 프로세스 순서와 조건 로직을 쉽게 추출 |
Sequence Diagram (sequenceDiagram) | 시간 순서 상호작용, API 호출, 메시지 전달 | 마이크로서비스 간 단계별 상호작용 문서화, 클라이언트‑서버 인증 핸드셰이크, 이벤트 발생 순서 | 시간에 따른 이벤트 순서와 참여 엔티티(lifeline)를 명확히 정의해 버그 추적에 도움 |
Class Diagram (classDiagram) | 구조, 계층, 엔티티 간 관계(OOP) | 새로운 모듈 구조 정의, 상속 관계 문서화, 코드베이스 내 객체 구성도 표시 | 상속, 구성, 가시성(public/private) 등 OOP 개념을 모호함 없이 포착 |
Entity Relationship Diagram (ERD) (erDiagram) | 데이터 구조, 데이터 모델 간 관계 | 데이터베이스 스키마 설명, 외래키 관계 시각화, 데이터 마이그레이션 계획 | 엔티티 관계를 정확히 매핑해 LLM이 데이터 흐름과 제약조건을 논리적으로 추론하도록 지원 |