교안 만들 때 쓰는 오픈소스 3가지, Diagram Design·Presenton·Quarkdown 직접 써 본 결과

강의를 준비하다 보면 내용을 고르는 시간보다 자료 모양을 만지는 시간이 더 길어지는 날이 있습니다. 흐름도 하나 그리려고 도형 정렬을 맞추고, 슬라이드 글꼴을 고치고, 강의가 끝난 뒤 나눠줄 PDF의 목차 쪽수를 손으로 맞춥니다.

이번 글에서는 교안 만들기에서 이 세 가지 일을 맡길 수 있는 오픈소스 세 개를 다루겠습니다. 그림은 Diagram Design, 발표용 PPT는 Presenton, 책 형태의 교재 PDF는 Quarkdown입니다. 셋 다 오픈소스이고 라이선스는 각각 MIT, Apache-2.0, GPL-3.0입니다(Quarkdown의 CLI·LSP 모듈은 AGPL-3.0).

소개로 끝내지 않으려고 Diagram Design과 Quarkdown은 제 PC에서 돌려 봤습니다. 제가 실제로 쓰는 블로그 발행 흐름을 그림으로 그려 달라고 했고 예전에 쓴 RAG 기초 글 원고를 교재 PDF로 만들어 달라고 했습니다. 어디서 막혔는지까지 그대로 적겠습니다. (작성일 기준(2026-10-15) 정보이고, 별 수와 버전은 금방 바뀝니다.)

크게 보기

교안 만들기 도구 3가지 한눈에 보기

먼저 표로 정리하면 다음과 같습니다. 이 셋은 경쟁 관계가 아니라 맡는 자료가 다릅니다.

여기서 용어 하나만 짚고 가겠습니다. 스킬(Skill)은 Claude Code 같은 코딩 에이전트가 특정 일을 할 때 꺼내 읽는 설명서 묶음입니다. 신입에게 "이 업무는 이 매뉴얼대로 해"라고 바인더를 건네는 것과 비슷합니다. Diagram Design과 Quarkdown은 이 바인더를 제공하고 Presenton은 바인더가 아니라 따로 실행하는 프로그램입니다. 이 차이를 모르고 시작하면 Presenton을 Claude Code에 설치하려다 헤매게 됩니다.

Diagram Design: 말로 그리는 흐름도

Diagram Design은 그림을 "HTML과 SVG로 된 파일 하나"로 그려 주는 에이전트 스킬입니다(README 표현). SVG는 확대해도 깨지지 않는 그림 형식이라고 보시면 됩니다. Claude Code뿐 아니라 Codex, Cursor, Copilot에서도 쓸 수 있다고 합니다.

설치는 아래 둘 중 하나입니다.

npx skills add cathrynlavery/diagram-design
/plugin marketplace add cathrynlavery/diagram-design
/plugin install diagram-design@diagram-design

첫 줄은 스킬 설치 도구로 받는 방법이고, 아래 두 줄은 Claude Code 안에서 플러그인 마켓으로 받는 방법입니다. 둘 중 하나만 하시면 됩니다. 설치가 끝나면 평범한 말로 요청하면 됩니다.

크게 보기

직접 해 본 것: 블로그 발행 흐름도

저는 저장소를 받아서 스킬 폴더를 Claude Code 에이전트에게 그대로 읽히고, 제가 실제로 쓰는 블로그 발행 과정을 설명했습니다. 요청 원문은 이렇습니다.

이 업무 흐름을 처음 보는 사람도 이해하게 그려줘: 블로그 글은 blog-writer로 초안을 쓰고 → humanize-korean으로 AI 티를 지우고 → blog-auditor로 감사해서 BLOCKER·HIGH가 0이어야 다음으로 간다. 통과하면 blog-packet-builder로 발행 패킷을 만들고(BLOCK 0이어야 함) → zexea 레포를 git pull 한 뒤 blog-post-importer로 가져오고 → zexea-blog-auditor 발행 감사(findings 0) → npm run build 성공 → 푸시 → 라이브 URL에서 200·canonical·sitemap·RSS를 직접 확인. 어느 게이트든 못 넘으면 그 자리에서 멈추고 이유를 보고한다.

README 설명대로 에이전트가 바로 그리지 않고 먼저 계획을 말했습니다. 그림 종류는 Flowchart(순서도)로 골랐고 이유는 "게이트마다 통과/중단으로 갈리는 결정 논리"라서였습니다. 재미있는 건 그다음입니다.

복잡도 예산(노드 9·화살표 12) 때문에: blog-writer와 humanize-korean을 '초안 작성·윤문' 한 칸으로 합치고, git pull과 blog-post-importer를 '가져오기' 한 칸으로 합치고, 푸시는 별도 칸 대신 빌드 통과 화살표 라벨(PASS · PUSH)로 표시.

이 스킬에는 그림 한 장에 넣을 수 있는 칸과 화살표 수의 상한이 정해져 있습니다. 그래서 제가 말한 열한 단계를 그대로 늘어놓지 않고 아홉 칸으로 줄였습니다. 교안에 넣는 그림은 많이 담는 것보다 한눈에 읽히는 게 중요한데, 그 판단을 스킬이 대신 해 준 셈입니다.

크게 보기

결과를 읽어 보면, 마름모 다섯 개가 통과 조건이고 FAIL 화살표가 전부 가운데 붉은 띠 하나로 모입니다. "어느 게이트든 못 넘으면 멈춘다"는 문장을 띠 하나로 바꾼 게 제 손으로 그렸을 때보다 낫습니다. 강조색은 이 띠에만 썼습니다. 위 줄은 왼쪽에서 오른쪽, 아래 줄은 오른쪽에서 왼쪽으로 꺾여 내려오는 배치라서 화살표가 엉키지 않습니다.

수정 없이 한 번에 나왔고 스킬에 들어 있는 검사 스크립트(겹침·여백 검사)도 첫 시도에 통과했습니다. 굳이 흠을 찾자면 붉은 띠의 폭이 스킬 자체 규칙(칸 최대 폭 320px)을 넘는데, 에이전트가 이걸 스스로 "규칙 이탈"이라고 적어 두었습니다.

내 사이트 색 맞추기: 어두운 사이트에서 차이가 큽니다

README에는 onboard diagram-design to https://yoursite.com처럼 사이트 주소를 주면 홈페이지에서 색과 글꼴을 뽑아 이후 그림 전부에 적용한다고 되어 있습니다. 그래서 제가 운영하는 사이트 두 곳으로 해 봤습니다. 하나는 이 블로그(zexea-education.com), 하나는 회사 소개 사이트(zexea.io)입니다.

먼저 결과부터 나란히 놓으면 다음과 같습니다. 같은 흐름도를 기본 스타일, 밝은 사이트 색, 어두운 사이트 색으로 세 번 그린 것입니다.

크게 보기

가운데 밝은 사이트판은 기본판과 거의 구분이 안 됩니다. 오른쪽 어두운 사이트판은 배경부터 글자, 강조색까지 다 바뀌었습니다.

어두운 사이트(zexea.io)로 맞춘 결과

zexea.io는 검은 배경에 청록색 버튼을 쓰는 사이트입니다.

크게 보기

이 사이트는 색을 CSS 변수(사이트가 색 이름표를 붙여 둔 값)로 공개하고 있어서 스킬이 화면 색을 일일이 재지 않고 그 이름표를 우선으로 읽었습니다. 뽑아낸 값은 배경 #0b0d0d, 카드 배경 #121515, 본문 글자 #edefee, 보조 글자 #a9aead·#858b8a, 버튼 청록 #26d0ae, 그 밖에 주황 #f5a524와 파랑 #5aa7ff입니다. 스킬의 온보딩 문서에는 "어두운 배경이 기본인 사이트는 그 어두운 배경을 기본 종이색으로 쓰고, 밝은 판은 뒤집어서 만든다"는 규칙이 있어서 이번에는 어두운 판이 기본이 됐습니다.

크게 보기

사이트 요소별로 보면 다음과 같습니다.

밝은 사이트 때 빠졌던 이유(대비 기준, 그림자 금지, 글꼴 제한)는 그대로인데 결과가 이렇게 다른 건, zexea.io의 핵심 색이 애초에 그 기준을 통과하는 색이라서입니다. 검은 배경 위 흰 글자와 청록은 대비가 넉넉하니 깎일 게 없었습니다. 반대로 zexea-education.com의 얼굴인 노랑(#ffe600)은 밝은 배경 위 대비가 1.11:1이라 빠졌고, 주황(#ff6b00)도 더 어둡게(#b84900) 바뀌었습니다. 결국 배경이 조금 더 회색이 되고 라벨 글꼴이 Space Mono로 바뀐 정도로 끝났습니다.

제가 보기에 이 기능은 "사이트 색을 그대로 복사"하는 게 아니라 "읽기 규칙을 통과하는 색만 골라 쓰는" 쪽에 가깝습니다. 그래서 브랜드 색이 밝고 연한 사이트일수록 변화가 작고 대비가 강한 사이트일수록 그대로 살아납니다. 하나 걸리는 건 청록이 '멈추고 이유 보고' 띠에 들어갔다는 점입니다. 스킬은 색의 의미까지는 보지 않아서 초록 계열이 중단 표시에 쓰여도 문제 삼지 않았습니다. 교안에 쓸 때는 이런 부분만 손으로 바꾸면 될 것 같습니다.

하나 더 적어 두면, 이 기능은 사이트 주소에서 색을 뽑습니다. 제가 쓰던 PPT나 문서 파일에서 뽑는 기능은 아닙니다. 그리고 README에는 60초면 된다는 식으로 쓰여 있지만 실제 절차 문서에는 "이 주소를 열어도 되는지" 확인과 "바뀐 값을 승인할지" 확인이 한 번씩 더 들어 있습니다. 처음 그림을 그릴 때도 "스타일을 지금 맞출지" 먼저 묻습니다. 어두운 사이트판도 글자 대비 검사를 처음엔 통과하지 못해서(밝은 판의 강조 띠 위 글자 대비 4.11:1) 글자색을 두 번 바꾼 끝에 통과했습니다.

두 번째 샘플: 쇼츠 한 편 만드는 과정

블로그 발행 흐름은 제가 게이트를 이미 정해 둔 일이라 그리기 쉬운 편이었습니다. 그래서 진짜 복잡한 걸 하나 더 맡겨 봤습니다. 이 글과 짝을 이루는 쇼츠를 지금 다른 Claude Code 세션이 만들고 있는데, 그 제작 과정입니다. 단계마다 쓰는 명령과 검사가 수십 개라 저도 처음 보는 사람에게 말로 설명하기 어려운 흐름입니다.

요청은 큰 틀만 적었습니다.

내가 쇼츠 하나 만드는 과정을 큰 틀만 처음 보는 사람도 이해하게 그려줘: ① 재료 수확: 소개할 도구의 공식 사이트·저장소에서 이미지·영상을 자동으로 긁어 모은다(이번 편 651개). ② 대본: 사실표(FACTS)로 팩트 체크하고 내가 확정하면 잠근다. ③ 음성: 내 목소리 TTS로 합성하고, 다시 받아써서 단어마다 타이밍을 맞춘다(이번 편 약 51초). ④ 계획: 문장 하나 = 샷 하나로 쪼갠다(22샷). 음성이 잠기면 뒤에서 아바타 립싱크(7개 창)와 BGM 고정이 따로 돈다. ⑤ 3샷 파일럿: 대표 3샷만 먼저 만들고, 편 정보를 모르는 판정 에이전트가 레퍼런스와 블라인드로 비교한다. 방향이 틀리면 레퍼런스를 다시 고른다. ⑥ 나머지 샷 짓기 → 정적 검사(글자 크기 30px 이상 등) → 장면 전환 스틸 검사 → 본 렌더. 검사 하나라도 실패하면 거기서 멈추고 그 단계만 다시. ⑦ 마스터: 음량 −14 LUFS 맞추고 릴스판·쇼츠판 꼬리를 붙인다. ⑧ 발행 패키지: 쇼츠 제목·설명·고정 댓글·태그, 릴스 캡션·DM 6개. 단계마다 기계 게이트가 먼저 보고, 사람(나)은 대본 확정·파일럿 시트·최종 영상만 본다.

이번에는 그림 종류를 Swimlane(수영장 레인처럼 칸을 나눠 누가 무엇을 하는지 보여 주는 그림)으로 골랐습니다. 에이전트가 말한 이유는 이렇습니다.

메인 흐름 하나와 '음성이 잠기면 따로 도는' 백그라운드 트랙이 있고, 레인 사이 넘김(음성 잠금)이 핵심이라서.

첫 번째 그림처럼 칸 수 상한(9칸)에 맞추려고 덜어 낸 것도 있습니다. ⑦ 마스터와 ⑧ 발행 패키지를 한 칸으로, 립싱크와 BGM을 백그라운드 한 칸으로 합쳤습니다. ⑥ 안의 네 단계는 칸을 나누지 않고 글줄로 넣었습니다. 단계마다 있는 기계 게이트 여덟 개는 따로 그리지 않고 레인 머리말 한 줄로 처리했고 제가 직접 보는 세 지점은 칸이 아니라 옆에 붙은 표시로 달았습니다. 립싱크·BGM이 어디서 다시 합류하는지는 제가 요청에 안 적었더니 화살표를 지어내지 않고 비워 뒀습니다.

크게 보기

그림을 순서대로 읽어 보면 쇼츠 한 편이 이렇게 만들어집니다.

1. 재료 수확: 사람이 캡처를 하나하나 모으지 않고 소개할 도구의 공식 사이트와 저장소에서 이미지·영상을 스크립트가 긁어 옵니다. 이번 편은 651개가 모였고 여기서 실제 조작 화면인지 아닌지를 나눕니다.

2. 대본: 사실표에 근거가 있는 문장만 남기고 제가 확정하면 잠급니다. 이 글 서두에서 말한 "Presenton은 스킬이 아니라 앱"이라는 구분도 이 단계에서 바로잡은 것입니다.

3. 음성: 제 목소리로 TTS를 합성한 뒤, 그 음성을 다시 받아써서 단어 하나하나가 몇 초에 나오는지 맞춥니다. 자막과 화면 전환이 이 타이밍을 기준으로 움직입니다.

4. 계획: 문장 하나를 샷 하나로 쪼갭니다. 이번 편은 22샷입니다. 음성이 잠기는 순간부터 아바타 립싱크와 BGM 고정은 메인 흐름을 기다리지 않고 뒤에서 따로 돕니다. 그림에서 오른쪽 레인이 이 부분입니다.

5. 3샷 파일럿: 22샷을 한꺼번에 만들지 않고 대표 3샷만 먼저 만듭니다. 이 편 정보를 전혀 모르는 판정 에이전트에게 레퍼런스와 나란히 보여 주고 블라인드로 비교하게 합니다. 방향이 틀리면 여기서 레퍼런스를 다시 고릅니다. 그림에서 이 칸만 청록색인 건 이 단계가 영상 전체의 방향을 정하기 때문입니다.

6. 짓기·검사·본 렌더: 나머지 샷을 만든 다음 글자가 30px보다 작지 않은지 같은 정적 검사, 장면이 바뀌는 순간의 스틸 검사를 거쳐 본 렌더로 갑니다. 검사가 하나라도 실패하면 처음부터가 아니라 그 단계만 다시 합니다.

7. 마스터·발행 패키지: 음량을 −14 LUFS(유튜브·인스타가 맞추는 음량 기준)로 맞추고 릴스판·쇼츠판 끝부분을 각각 붙입니다. 마지막으로 쇼츠 제목·설명·고정 댓글·태그와 릴스 캡션·DM까지 6개를 한 번에 만듭니다.

제가 직접 보는 건 대본 확정, 파일럿 시트, 최종 영상 세 번뿐이고 나머지는 기계 게이트가 먼저 봅니다. 글로 쓰면 이렇게 일곱 문단이 필요한 내용이 그림 한 장에 들어갔습니다. 교안에서 제가 가장 그리기 귀찮아하던 종류가 바로 이런 "본류 + 옆에서 따로 도는 일 + 되돌아가는 고리"가 섞인 흐름인데, 순서도 대신 Swimlane을 고르고 덜어 낼 것을 스스로 정한 점이 인상적이었습니다. (이 쇼츠는 글 작성 시점 기준 3샷 파일럿 판정과 22샷 시안까지 진행된 상태이고, 본 렌더 전입니다.)

이미지로 받기

교안에 넣으려면 결국 이미지가 필요합니다. "Export this diagram as SVG and PNG"라고 말하거나 /diagram-design:export-diagram을 쓰면 PNG(기본 2배 해상도)와 SVG가 나옵니다. 제 결과는 PNG가 2560x1442였습니다. 문서에는 화면 크기 x 2배라 2560x1440이어야 한다고 되어 있는데 2픽셀이 더 나왔고 배경색이라 눈에는 안 보입니다. 사이트 색을 입힌 판의 SVG는 Space Mono 글꼴을 함께 담지 않아서 그 글꼴이 없는 PC에서 SVG를 열면 라벨 글꼴이 달라질 수 있습니다. 교안에 넣을 거라면 PNG 쪽이 안전합니다.

Presenton: 원고를 넣으면 PPT

Presenton은 오픈소스 AI 발표자료 생성기이고 API로도 쓸 수 있습니다. 저장소 설명에 Gamma·Canva·Beautiful AI의 대안이라고 적혀 있습니다. README 표현으로는 "프롬프트, 올린 문서, 또는 내 PowerPoint 디자인에서" 발표자료를 만듭니다.

크게 보기

실행 방법은 데스크톱 앱(Mac·Windows·Linux) 또는 Docker입니다. 2026-10-15 기준 최신 릴리스는 v0.9.11-beta(2026-09-21)이고 이름대로 베타입니다.

AI 연결은 세 가지 중 하나를 고릅니다.

1. 내 API 키 (OpenAI, Google 등)
2. ChatGPT 계정 로그인 (API 키 없이, README 239행)
3. Ollama 같은 로컬 모델

ChatGPT를 이미 쓰고 있다면 2번이 진입 장벽이 가장 낮습니다. 참고로 Claude Code 스킬이 아니라 앱이고, MCP 서버(에이전트가 앱을 직접 조작하는 연결 통로)는 Docker 판에만 있다고 합니다(README 655행).

기존 PPT 디자인 쓰기

교안을 만드는 입장에서 가장 쓸 만한 기능은 기존 디자인 재사용입니다. 회사나 기관에서 쓰라는 PPT 양식이 있는 경우가 많기 때문입니다.

크게 보기

공식 문서(docs/template-v2.md)에 따르면 PPTX를 올리면 슬라이드마다 다시 쓸 수 있는 레이아웃으로 바꾸고 글꼴·색·격자·간격을 보존합니다. 단 이 변환 단계는 이미지를 읽을 수 있는 AI 모델이 필요하다고 적혀 있습니다. 로컬 모델로 돌릴 생각이라면 그 모델이 이미지를 읽을 수 있는지 먼저 확인해야 합니다.

양식이 없다면 기본 템플릿에서 고르면 됩니다. README에 올라온 템플릿은 여섯 종입니다.

크게 보기

만든 뒤 다듬고 받기

생성된 슬라이드는 화면에서 끌어서 배치를 고칩니다(README "drag-edit interface").

크게 보기

다 만든 뒤에는 "Fully editable PPTX", 즉 문구를 그대로 고칠 수 있는 파워포인트 파일로 받거나 PDF로 받습니다. AI가 만든 슬라이드를 통이미지로만 주는 도구가 꽤 있는데, 강의 직전에 숫자 하나 고치려고 다시 생성을 돌리지 않아도 된다는 점이 실무에서는 크게 다가옵니다.

크게 보기

Quarkdown: 원고를 책 형태 교재로

Quarkdown은 마크다운 기반 조판 시스템입니다. 조판은 원고를 쪽 단위 지면으로 앉히는 일인데, 워드에서 쪽 나누기·목차·쪽 번호를 손으로 맞추던 작업을 코드가 대신한다고 보시면 됩니다. 한 원고를 인쇄용 책·논문, 지식베이스, 슬라이드로 바꿀 수 있고(README 54행), 문서 맨 위에 .doctype {paged}라고 적으면 책·논문 형태, {slides}면 슬라이드가 됩니다.

교안 관점에서 중요한 건 에이전트 스킬이 들어 있다는 점입니다. README에는 "코딩 에이전트가 Quarkdown 문법을 자연스럽게 쓰도록 하는 내장 스킬"이 있다고 되어 있고 Quarkdown 블로그에는 같은 다섯 과제에서 스킬이 있을 때 첫 컴파일 성공 4/5, 없을 때 0/5였다는 비교가 실려 있습니다(Opus 4.7 기준, 작성자 측 실험).

연결은 CLI를 먼저 설치한 뒤 한 줄입니다.

ln -s "$(quarkdown doctor get agent-skill)" ~/.claude/skills/quarkdown

quarkdown doctor get agent-skill이 스킬 폴더 위치를 알려 주고 그 폴더를 Claude Code 스킬 폴더에 바로가기로 거는 명령입니다. 제가 받은 윈도우판(v2.6.4, 64MB)은 Java 실행 환경이 같이 들어 있어서 Java를 따로 깔 필요가 없었습니다. 다만 PDF로 내보낼 때는 Chrome이 있어야 합니다(quarkdown doctor env에서 확인 가능).

직접 해 본 것: RAG 기초 글을 12쪽 교재로

원고는 제가 예전에 쓴 RAG 기초 글(RAG란 무엇인가, 오픈북 시험 비유로 이해하는 핵심 개념)의 본문을 썼습니다. 소제목 표시를 다 지운 맨 텍스트로 만들어서 넘겼고 요청은 대본 그대로 이 한 줄입니다.

이 원고를 목차와 챕터가 있는 교재로 만들어줘

에이전트는 스킬 안내대로 위키에서 표지(book-cover), 목차(table-of-contents), 쪽 번호(page-counter) 문서부터 읽고 원고를 여섯 챕터로 나눴습니다. 챕터 제목은 에이전트가 붙였고(들어가며 / RAG의 구조 / 임베딩과 의미 기반 검색 / 청킹과 벡터 데이터베이스 / 실습과 현장 적용 / 다음 글과 Reference), 본문 문장은 그대로 옮겼습니다. 결과 문서 첫머리는 다음과 같습니다.

.docname {RAG 기본 구조}
.doctype {paged}
.doclang {ko}
.theme {paperwhite} layout:{latex}
.font {fonts/malgun.ttf}
.pageformat size:{A4} margin:{2.5cm 2.2cm}

.pagemargin {bottomcenter}
    .currentpage / .totalpages

.tableofcontents title:{목차} maxdepth:{2}

책 형태(paged)로, A4 크기로, 아래 가운데에 "현재 쪽 / 전체 쪽"을 찍고, 목차를 넣으라는 뜻입니다. 이 정도면 코드를 몰라도 무슨 설정인지 읽힙니다.

크게 보기

결과는 A4 12쪽입니다. 목차의 쪽 번호가 실제 쪽과 전부 맞았습니다(1장 3쪽, 2장 4쪽 … 6장 12쪽). 챕터마다 새 쪽에서 시작하고 표지를 뺀 2~12쪽 아래에 "N / 12"가 찍힙니다. 대본에서 말한 "표지와 쪽 번호까지 들어간 PDF"가 실제로 나온 셈입니다.

크게 보기

한 번에 되지는 않았습니다

여기까지 컴파일을 여섯 번 돌렸고 세 번은 아예 실패했습니다. 막힌 곳은 거의 한글 글꼴과 표지였습니다.

윈도우에서 한글 교재를 만들 계획이라면 처음부터 글꼴 파일을 작업 폴더에 넣고 상대경로로 지정하시면 1·2번 실패는 건너뛸 수 있습니다. 4번의 "표지에도 쪽 번호" 문제는 문서 설명(선언한 쪽부터 적용)과 실제 동작이 달랐던 부분이라, 버전이 바뀌면 고쳐질 수도 있을 것 같습니다.

그 밖에 표 아래에 캡션 없이 "4.1" 같은 번호만 붙는 점, 따옴표 짝이 어긋나 보이는 곳이 몇 군데 있다는 점은 손대지 않았습니다. 나눠줄 자료로 쓰려면 표 캡션 정도는 직접 채우는 편이 좋겠습니다.

개인적인 생각 & 한계점

세 도구를 써 보면서 든 생각은, 자료 모양을 만드는 일은 꽤 많이 맡길 수 있게 됐다는 것입니다. 흐름도는 말 한 단락으로 나왔고 교재 PDF는 여섯 번 만에 나왔습니다. 그런데 두 번 다 결과의 질을 가른 건 제가 넘긴 재료였습니다. 흐름도는 제가 이미 게이트를 정해 둔 업무라서 깔끔하게 나왔고 교재는 이미 다듬어 둔 원고라서 챕터만 나누면 됐습니다. 무엇을 가르칠지 고르고 순서를 짜는 일은 그대로 남습니다.

어떤 도구부터 써 볼지는 상황별로 나눠 보겠습니다.

1. Claude Code를 이미 쓰고 있는 경우

Diagram Design부터 권합니다. 설치 한 줄에 말로 요청하면 되고 결과가 PNG로 나와서 어떤 교안 양식에도 붙일 수 있습니다. 사이트 색 맞추기는 기대를 낮추고 쓰시면 됩니다.

2. 회사·기관 PPT 양식으로 발표자료를 자주 만드는 경우

Presenton이 맞습니다. 기존 PPTX 디자인을 레이아웃으로 바꾸는 기능과 편집 가능한 PPTX 내보내기가 핵심입니다. 다만 아직 베타 버전이고 디자인 변환에는 이미지를 읽는 AI 모델이 필요하다는 점은 미리 알고 시작하시는 게 좋겠습니다.

3. 강의 후 나눠줄 교재·워크북을 만드는 경우

Quarkdown을 권합니다. 원고만 있으면 표지·목차·쪽 번호를 손으로 맞출 일이 없어집니다. 윈도우에서 한글로 쓴다면 위 표의 글꼴 문제는 거의 반드시 만납니다.

한계도 적어 두겠습니다. Diagram Design과 Quarkdown은 각각 한 가지 요청으로 한 번씩만 돌려 봤고 다른 주제나 더 긴 원고에서는 결과가 다를 수 있습니다. 별 수와 버전은 2026-10-15에 GitHub에서 확인한 값입니다. (최대한 작성 시점 기준으로 반영했지만 틀린 부분도 있을 수 있습니다.)

이 글을 마치며 & Reference

다음 글에서는 Quarkdown의 슬라이드 모드({slides})로 같은 원고를 발표 슬라이드까지 만들어서 Presenton으로 만든 것과 무엇이 다른지 비교해 보겠습니다.

관련 글

• Claude Code 프론트엔드 디자인 도구 5종, AI 티 나는 웹사이트를 고치는 스킬·CLI 사용법 : 스킬로 결과물의 디자인을 고치는 다른 사례
• RAG란 무엇인가, 오픈북 시험 비유로 이해하는 핵심 개념 : 이번 글에서 교재 PDF로 만든 원고의 원래 글
• 바이브코딩 디자인 레퍼런스 사이트 5곳 : AI에게 무엇을 보여 주느냐에 따라 결과가 달라진 실험

Reference

1. cathrynlavery/diagram-design : Diagram Design 저장소. 설치·온보딩·내보내기 설명이 README 한 장에 다 있습니다. 라이브 갤러리(https://cathrynlavery.github.io/diagram-design/)에서 그림 종류별 예시를 먼저 보면 어떤 요청을 할지 감이 옵니다.
2. presenton/presenton : Presenton 저장소. 기존 PPT 디자인 변환은 docs/template-v2.md에 조건이 정리되어 있습니다.
3. iamgio/quarkdown : Quarkdown 저장소. 표지·목차·쪽 번호는 저장소 위키의 book-cover, table-of-contents, page-counter 문서를 보시면 됩니다.
4. Quarkdown 블로그: agent skill : 스킬 연결 방법과 스킬 유무에 따른 첫 컴파일 성공률 비교(4/5 vs 0/5)가 실린 글입니다. 작성자 측 실험이라는 점은 감안하고 보시면 됩니다.

긴 글 읽어주셔서 감사합니다 :)