일하는 ai

04. 보고서 도표 30분 걸리던 게 3초로 줄어드는 Mermaid 실전법

11 min read

-

보고서에 도표 하나 넣으려고 파워포인트를 열고 박스를 맞추고 선을 잇다 보면, 정작 중요한 내용 정리에 쓸 시간이 사라질 때가 많다. 메이커 에반 영상이 보여주는 핵심은 단순하다. 도표를 그림으로 그리지 말고, 문장으로 정의하라는 것이다.

Mermaid는 텍스트로 다이어그램을 만드는 오픈소스 도구다. 공식 소개도 “text and code로 diagrams and visualizations를 만든다”는 점을 전면에 둔다. 즉, 디자인 감각보다 구조를 먼저 쓰는 방식이다. 이 방식이 좋은 이유는 예쁘게 그리기보다 고치기 쉽기 때문이다.

왜 이 방식이 보고서 시간을 줄여줄까

보고서에서 시간이 가장 많이 깨지는 지점은 첫 작성보다 수정이다. 상사가 “이 단계 하나 더 넣어줘”, “팀장 승인 앞에 검토 단계 추가해줘”, “일정표 순서 바꿔줘”라고 말하는 순간부터 박스 위치와 화살표를 다시 잡아야 한다. 도형 편집 방식은 수정 비용이 크고, 텍스트 방식은 수정 비용이 작다.

Mermaid는 이 문제를 꽤 정직하게 해결한다. 구조를 문장으로 적어두면 수정도 문장으로 끝난다. 예를 들어 검토 단계를 승인 앞에 끼워 넣고 싶다면, 도형을 옮기는 대신 한 줄만 추가하면 된다. 보고서에서 중요한 건 그림 실력이 아니라 의사결정 흐름을 빠르게 합의하는 것이기 때문에, 이 차이가 실무에서는 크게 느껴진다.

영상에서 바로 건질 수 있는 핵심 포인트 4개

1) 순서도는 설명 문장을 프로세스로 바꿀 때 가장 먼저 써볼 만하다

업무 보고서에는 “요청 접수 → 검토 → 승인 → 실행”처럼 순서가 있는 문장이 자주 등장한다. 이걸 문단으로 풀어 쓰면 읽는 사람이 한 번에 구조를 못 잡는다. 반대로 순서도로 바꾸면 어디서 막히는지, 누가 결재하는지, 예외 분기가 있는지가 훨씬 빨리 보인다.

Mermaid의 flowchart 문법은 이럴 때 가장 직관적이다. 승인 전 단계가 하나 추가되어도 줄 하나만 더 넣으면 된다. 특히 회의용 초안에서는 이 단순함이 강하다. 예쁘게 만드는 시간보다 흐름을 합의하는 시간이 중요하기 때문이다.

flowchart LR
A[요청 접수] --> B[담당자 검토]
B --> C{승인 필요?}
C -- 예 --> D[팀장 승인]
C -- 아니오 --> E[바로 실행]
D --> E
E --> F[결과 공유]

실무 예시:

  • 기안 프로세스 설명: 메일로 길게 쓰던 승인 절차를 한 장짜리 도표로 바꿀 수 있다.
  • 고객 응대 흐름 정리: 문의 접수, 1차 답변, 기술 검토, 재답변을 한 눈에 보여주기 좋다.

검증 포인트: 보고서를 처음 보는 사람이 10초 안에 “어디서 승인되고 어디서 분기되는지” 설명할 수 있으면 성공이다.

공식 참고:

2) 일정표는 표보다 간트 차트가 더 빨리 읽히는 경우가 많다

일정 보고에서 흔한 실수는 날짜는 빽빽하게 적혀 있는데, 언제 겹치고 언제 끝나는지가 안 보인다는 점이다. 특히 여러 작업이 병렬로 진행될 때는 표보다 간트 차트가 훨씬 빠르게 읽힌다.

Mermaid의 gantt는 PM 전용 툴이 아니어도 쓸 만하다. 보고용 초안이나 내부 정렬용 문서에서 “작업 A는 언제 시작하고, 작업 B와 얼마나 겹치는지”를 빠르게 보여주기 좋다. 엑셀 일정표보다 예쁜지보다, 변경 시 다시 만들기 쉬운지가 더 중요하다.

gantt
    title 4월 캠페인 준비 일정
    dateFormat  YYYY-MM-DD
    section 준비
    기획안 확정      :done, a1, 2026-04-01, 2d
    시안 제작        :a2, after a1, 3d
    section 운영
    내부 검토        :a3, 2026-04-04, 2d
    최종 배포        :a4, after a3, 1d

실무 예시:

  • 행사 준비 보고: 기획, 제작, 검수, 배포의 겹치는 구간을 빠르게 설명할 수 있다.
  • 콘텐츠 캘린더 공유: 원고, 디자인, 검수, 발행 단계를 한 장으로 정리할 수 있다.

검증 포인트: 누가 봐도 “이번 주에 밀릴 가능성이 있는 작업”이 보이면 제대로 만든 것이다.

공식 참고:

3) 조직도나 역할도도 “예쁘게”보다 “관계가 보이게”가 먼저다

조직도는 디자인을 조금만 만지기 시작하면 끝이 없다. 박스 폭 맞추고, 선 길이 맞추고, 사람 이름 길이 때문에 정렬이 무너진다. 그런데 실제 보고에서 더 중요한 건 디자인 완성도가 아니라 누가 누구와 연결되는지다.

Mermaid는 조직도 전용 툴만큼 화려하진 않지만, 의사결정 관계를 빠르게 공유하는 데는 충분하다. 특히 프로젝트 킥오프 문서에서 PM, 디자이너, 개발, QA의 역할 관계를 먼저 설명할 때 유용하다.

미니 케이스:

  • 신규 프로젝트 시작 문서에서 “PM → 디자이너/개발 → QA” 구조를 먼저 공유하면, 회의 때 역할 질문이 줄어든다.
  • 외부 협력사 보고서에서 “본사 담당자 / 대행사 / 외주 제작사” 관계를 정리할 때 유용하다.

검증 포인트: 사람 이름을 빼고 역할만 남겨도 구조가 이해되면 잘 만든 조직도다.

4) 보고서용 도표는 ‘완성본’보다 ‘반복 가능한 템플릿’이 더 중요하다

한 번 멋지게 만든 도표보다, 다음 주에도 다시 쓸 수 있는 템플릿이 실제로 더 가치 있다. 영상의 메시지도 결국 여기에 가깝다. 도표를 예술 작품처럼 다루지 말고, 반복 가능한 작성 규칙으로 바꾸라는 것이다.

예를 들어 팀에서 자주 쓰는 승인 흐름, 운영 체크리스트, 주간 일정표가 있다면 매번 새로 만들지 말고 Mermaid 템플릿으로 저장해두면 된다. 그러면 작성자는 텍스트만 바꾸고, 독자는 익숙한 형식으로 읽는다. 이게 실무 효율이다.

오늘 바로 써볼 수 있는 가장 쉬운 시작법

  1. 보고서에서 자주 반복되는 구조 1개를 고른다.
    예: 승인 프로세스, 일정표, 조직 역할도.
  2. 박스를 그리지 말고 먼저 문장으로 적는다.
    예: 요청 접수 → 담당자 검토 → 팀장 승인 → 실행.
  3. 그 문장을 Mermaid 코드로 옮긴다.
  4. 초안 회의에서 구조만 먼저 확인받고, 디자인 다듬기는 마지막에 한다.

이 순서만 지켜도 “도표 때문에 시간 다 썼다”는 상황이 꽤 줄어든다.

이 글의 한계와 읽는 법

이 영상은 길지 않고 자막도 공개되어 있지 않아, 글은 영상 설명란에서 확인 가능한 핵심 주장과 Mermaid 공식 문서를 중심으로 재구성했다. 그래서 과장된 생산성 숫자보다, 실제로 바로 적용할 수 있는 사용법에 무게를 뒀다.

관련 글

참고 링크

영상 메타

이 글은 AI를 활용해 초안을 정리한 뒤, 원영상 설명란과 Mermaid 공식 문서를 교차 확인해 다듬었습니다.

그래프 뷰

백링크