슬라이드를 따로 안 만들기로 했다 — 위키만 잘 쓰면 저절로 나온다

📝 한줄 요약

강의용 슬라이드가 필요해서 위키(마크다운 문서)를 슬라이드로 자동 변환해봤는데, 잘 안 되는 부분이 하나같이 원래부터 안 읽히던 문단이었다. 그래서 슬라이드를 손보는 대신 위키를 손봤더니 양쪽이 같이 좋아졌다.

바쁘시면 이것만 읽어도 돼요:

• 위키 마크다운을 발표 슬라이드로 보는 뷰를 만들었다. 슬라이드용 파일은 안 만든다 — 글 한 벌에서 조립
• 처음엔 생각보다 잘 됐다. 위키가 이미 단계별로 쪼개져 있어서
• 안 되는 데를 고치려고 변환 규칙의 기준값을 다섯 번 조정했는데, 하나 맞추면 다른 하나가 어긋났다
• 원인은 규칙이 아니라 원문이었다. 소제목 없이 줄줄 이어진 긴 문단
• 원문을 다듬자 한 챕터 14장이 전부 한 화면에 들어가고, 화면에서 뺄 내용이 하나도 안 남았다
• 결론: 슬라이드를 위해 뭘 따로 만들 필요가 없다. 위키를 눈에 잘 들어오게 쓰면 슬라이드는 저절로 나온다

🎯 이런 분들께 도움돼요

• 노션·옵시디언에 문서는 쌓는데, 그게 발표나 공유로 안 이어지는 분
• 강의·스터디를 운영하며 교안과 슬라이드를 두 벌 관리하는 분
• "문서 정리해야 하는데" 하면서 계속 미루고 있는 분 (미루게 되는 이유가 명분이 없어서인 경우)

😫 문제 상황 (Before)

원래 하려던 건 전자책이었다. 강의 위키를 전자책 형태로 묶는 것.

전자책은 쓸 데가 분명하다. 파일로 다운로드해서 나눠줄 수 있고, 무료로 주는 미끼 상품이 될 수도 있고, 제대로 다듬으면 출판까지 간다. 다만 그건 전부 "언젠가"였다. 지금 당장 나눠줄 일도, 팔 일도, 낼 일도 없었다.

그래서 "지금 당장 필요한 게 뭐지?" 를 다시 생각했다. 답은 강의용 슬라이드였다. 강의는 곧 시작한다. 시작할 때 화면에 띄워놓고 "오늘은 이걸 합니다" 설명할 자료가 필요했다. 위키 페이지를 그대로 띄우면 글이 빽빽해서 발표용으로는 안 맞았다.

같은 재료(위키)로 만들 수 있는 게 여럿인데, 먼저 만들 건 지금 쓸 것이었다.

여기에 미루고 있던 문제도 하나 있었다. 위키를 읽다 보면 눈에 잘 안 들어오는 대목이 있었다. 한 문단이 너무 길고, 소제목 없이 여섯 문단이 이어지고. "언젠가 고쳐야지" 생각만 하고 계속 미뤘다. 급하지 않았으니까.

🛠️ 사용한 도구

• 도구: Claude Code
• 모델: Claude Opus
• 대상: 마크다운으로 쓴 강의 위키 (챕터 25개)

🔧 작업 과정

시작은 가벼웠다 — "위키를 슬라이드로 한번 변환해보자"

거창한 계획은 없었다. 이미 마크다운으로 글이 다 있으니 보여주는 방식만 바꾸면 되지 않을까 싶었다.

아루나 사이트에 23기 위키를 발표용 슬라이드로 만들고 싶어.

여기서 방향을 한 번 못 박았다. 슬라이드용 파일을 따로 만드는 안도 있었지만 골랐다.

지금 위키가 비추고 있는 마크다운 파일을 활용해서 그냥 뷰어만 슬라이드로 바꾸고 싶은 거야.

이유는 단순하다. 파일이 두 벌이 되면 글을 고칠 때마다 양쪽을 고쳐야 하고, 그러면 반드시 어긋난다. 글은 한 곳에 두고 보여주는 방식만 바꾸기로 했다.

결과는 생각보다 잘 됐다. 위키가 이미 소제목으로 단계가 나뉘어 있어서, 그 경계를 그대로 슬라이드 경계로 쓰니 챕터 하나가 8~9장으로 잘렸다. 슬라이드용으로 뭘 새로 쓰지 않았는데도.

✅ 됐는지 확인: 챕터 페이지에 "발표 슬라이드 (8장)" 버튼이 뜨고, 눌렀을 때 전체화면으로 열렸다. 25개 챕터 전부에 버튼이 붙었는지는 목록을 세어 확인했다.

그런데 예쁘지 않았다

내 발표 슬라이드가 너무 안 예뻐. 그리고 그냥 위키를 슬라이드 형식으로 것 뿐인 거 같아.

맞는 말이었다. 흰 화면에 검은 글씨 두 문단이 위쪽에 몰려 있고 아래는 텅 비어 있었다. 슬라이드가 아니라 문서를 확대한 것이었다.

그래서 디자인을 갈아엎었다. 16:9 비율 무대를 고정하고(화면 크기가 달라져도 배치가 안 흔들리게), 글자를 키우고, 목록을 카드로 만들고.

이거 너무 별로야.

계속 어긋났다 — 다섯 번의 조정

여기서부터가 이 글의 본론이다. 안 되는 부분을 고치려고 규칙을 계속 손봤다.

한 화면에 너무 많이 들어간다 → 분량 기준을 낮췄다. 그랬더니 이번엔 실습에 필요한 단축키 안내까지 화면에서 사라졌다.

단축키가 사라졌다 → 기준을 다시 올렸다. 그랬더니 다시 넘쳤다.

그림이 잘린다 → 그려진 크기를 재서 넘치면 자동으로 줄이는 장치를 넣었다. 두 번 시도해서 두 번 다 더 나빠졌다. 배율을 바꾸면 레이아웃이 바뀌고, 바뀐 걸 다시 재느라 값이 안 잡혔다. 위에는 거대한 빈 공간이 생기고 아래는 여전히 잘렸다.

다 이상해졌어. 다 잘리고. 다 난리가 났어.

되돌렸다. 세 번째 시도는 하지 않았다. 두 번 연속 어긋나면 그건 숫자 문제가 아니라 방식 문제라서.

✅ 됐는지 확인: 챕터마다 슬라이드 몇 장이 나오고 각 장이 화면을 넘치는지를 스크립트로 세어 표로 뽑았다. 눈으로 하나씩 넘겨보는 대신 "넘칠 수 있는 장 N개"라는 숫자로 봤다.

방향이 뒤집힌 한마디

이거를 뭐 바꿀 때마다 이렇게 하나하나 다 바꿔줄 순 없는데,
원문에 그 줄바꿈이나 문단도 슬라이드를 고려해서 하는 게 나을 수도 있을 거 같아.
그게 원문 자체 가시성 좋아질 수 있을 거 같고.

이 말을 하고 나서야 보였다. 잘 안 되는 대목이 하나같이, 원래부터 안 읽히던 대목이었다.

• 한 문단에 세 가지 얘기가 들어 있는 곳 → 슬라이드에서 넘침
• 소제목 없이 굵은 글씨로만 강조하고 넘어간 곳 → 슬라이드에서 계층이 안 잡힘
• 목록 한 항목이 세 줄인 곳 → 카드가 커져서 네 개만 돼도 화면을 넘김

변환 규칙이 부족한 게 아니었다. 원문이 그렇게 쓰여 있어서 그런 거였다. 규칙을 아무리 정교하게 만들어도, 원문마다 문단 길이도 형식도 제각각이면 하나의 기준으로 다 맞출 수가 없다.

그리고 이건 미루고 있던 그 문제와 같은 문제였다.

원문을 다듬었다

챕터 하나를 골라 이렇게 고쳤다.

• 굵은 글씨로만 강조하고 지나가던 문장을 소제목으로 승격 (5군데)
• 세 가지 얘기가 든 문단을 여러 문단으로 쪼갬
• **제목** + 긴 설명 문단 네 개를 목록 네 줄로
• 목록 항목의 설명을 한 줄로 줄임
• 인용 상자 안에 목록이 들어 있던 것을 소제목 + 목록으로 펴냄

문장을 손대는 일이라 하나하나 뭘 어떻게 바꿨는지 확인받으며 진행했다.

✅ 됐는지 확인: 다듬은 뒤 다시 세어보니 14장 전부 한 화면에 들어갔고, 발표자 노트가 비었다. 노트는 "화면에 넣기엔 긴 설명"이 가는 자리인데, 거기 갈 게 하나도 안 남았다는 건 원문이 이미 슬라이드 크기라는 뜻이다. 이게 방향이 맞다는 제일 확실한 신호였다.

곁다리로 발견한 것 둘

한글에서 굵은 글씨가 조용히 안 먹는다. **넘어지는 법(낙법)**을이라고 쓰면 별표가 그대로 화면에 보인다. 마크다운 표준상 닫는 별표 앞이 괄호 같은 문장부호이고 뒤에 글자가 바로 붙으면 강조로 안 쳐준다. 영어는 뒤에 공백이 오니까 잘 안 걸리는데, 한국어는 조사가 바로 붙어서 자주 걸린다. 사이트 전체를 훑어보니 52개 파일 중 18개, 29곳이 깨져 있었다. 글쓴이가 이 규칙을 외워서 피하는 건 무리라, 화면에 그릴 때 자동으로 받아주게 했다.

엉뚱한 파일을 고치고 있었다. 원문을 다듬었는데 화면에 반영이 안 됐다.

어디가 소제목이 반영된거야?

알고 보니 내가 고친 폴더는 자동 생성되는 복사본이었다. 진짜 원본은 다른 곳에 있었고. 더 나빴던 건, 결과를 확인하던 스크립트도 같은 복사본을 읽고 있어서 "잘 되고 있다"는 잘못된 신호를 계속 줬다는 것이다. 한참을 헤맸다.

✅ 결과 (After)

Before vs After

결과물

• 위키 챕터를 열면 "발표 슬라이드" 버튼이 있고, 누르면 전체화면 슬라이드로 열린다
• 주소에 장 번호가 붙어서, 링크만 보내면 그 장이 바로 열린다 ("3번 장 프롬프트 복사해서 해보세요")
• 실습용 프롬프트는 슬라이드에서도 복사 버튼이 살아 있다

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 결과물을 숫자로 확인하기. 슬라이드를 눈으로 하나씩 넘겨보는 대신 "각 장이 화면을 넘치는지"를 스크립트로 세어 표로 뽑았다. "넘칠 수 있는 장 3개"처럼 숫자로 보면 고칠 데가 바로 보이고, 고친 뒤에 나아졌는지도 바로 안다.
2. 같은 문제로 두 번 어긋나면 방식을 의심하기. 자동 축소 장치를 두 번 만들어 두 번 다 악화됐다. 세 번째를 시도하는 대신 되돌리고 방향을 바꿨다.
3. AI가 뭘 고쳤는지 어디를 고쳤는지 확인하기. 문장을 다듬는 작업이라 "이 문장을 이렇게 바꿨다"를 하나씩 보고받으며 진행했다. 내가 쓴 글이 조용히 바뀌는 걸 막을 수 있다.

이렇게 하면 안 돼요

1. 자동 변환 규칙만 계속 손보기. 기준값을 다섯 번 조정했는데 하나 맞추면 다른 하나가 어긋났다. 원문이 제각각이면 하나의 규칙으로 다 맞출 수 없다.
2. 결과를 확인하는 도구가 뭘 보고 있는지 안 챙기기. 확인 스크립트가 엉뚱한 파일을 읽고 있어서 "잘 된다"는 거짓 신호를 계속 받았다. 고치기 전에 "이 파일이 원본인가 복사본인가"부터.
3. 문서용으로 만든 그림을 슬라이드에 그대로 넣기. 세로로 길게 만든 도표는 슬라이드 비율(16:9)에 넣으면 줄이든 자르든 안 읽힌다. 슬라이드에서는 빼고 필요할 때 문서를 열어 보여주는 게 낫다.

🌍 다른 업무에 적용한다면?

이건 슬라이드에 국한된 얘기가 아니다. "쌓아둔 문서를 다른 형태로 꺼내 쓰려는 모든 경우"에 같은 원리가 통한다.

• 회의록 → 공유용 요약: 회의록에 소제목을 달고 문단을 짧게 써두면, 요약을 따로 쓸 필요 없이 소제목만 뽑으면 된다
• 업무 매뉴얼 → 신입 교육 자료: 매뉴얼이 단계별로 쪼개져 있으면 그게 곧 교육 슬라이드다
• 프로젝트 기록 → 보고서: 기록할 때 "이건 배경, 이건 결정, 이건 결과"로 나눠 써두면 보고서 목차가 이미 있는 셈

공통점은 하나다. 꺼내 쓸 때를 위해 뭘 따로 만드는 게 아니라, 원본을 잘 쓰는 것으로 해결된다. 그리고 원본을 잘 쓰면 원본 자체도 읽기 좋아진다.

🚀 앞으로의 계획

1. 앞으로 쓰는 위키는 처음부터 이 형식으로. 소제목 달고, 한 문단 짧게, 목록은 "제목 + 한 줄". 나중에 고칠 일이 없고 슬라이드도 알아서 잘 나온다.

2. 강의 전체 로드맵 슬라이드. 지금은 챕터마다 슬라이드가 있는데, 강의 전체를 훑는 슬라이드가 하나 더 있으면 좋겠다. 쓸 데가 두 군데다 — 강의를 처음 여는 날 전체 그림을 설명할 때, 그리고 기업에서 강의 문의가 왔을 때 커리큘럼을 제출할 때. 문의가 오면 "어떤 식으로 진행하는지 커리큘럼을 달라"는 요청이 늘 따라온다.

3. 나머지는 천천히. 발표자 노트를 별도 창으로 띄우는 것(지금은 화면 공유하면 관객에게도 보인다), 디자인 다듬기 같은 건 나중에 붙이면 된다. 우선은 틀을 잡는 게 중요하다.

📋 재사용 가능한 프롬프트

프롬프트 1: 문서를 다른 형태로 꺼내 쓰기 (파일을 두 벌로 만들지 않기)

[내 문서가 있는 위치]의 문서를 [슬라이드 / 요약본 / 교육자료]로도 볼 수 있게 해줘.

조건: 원본 파일은 그대로 두고 보여주는 방식만 바꿔줘. 파일이 두 벌이 되면 글을 고칠 때마다 양쪽을 고쳐야 하고, 그러면 반드시 어긋나니까.

프롬프트 2: 결과를 눈이 아니라 숫자로 확인하기

만든 결과가 제대로 됐는지 눈으로 하나씩 보는 대신, 숫자로 셀 수 있는 기준을 만들어줘. [예: 각 장이 화면을 넘치는지 / 빠진 항목이 몇 개인지]를 세서 표로 보여줘. 고치고 나서 나아졌는지도 같은 표로 비교할 수 있게.

프롬프트 3: 두 번 어긋났을 때 멈추기

같은 문제를 두 번 고쳤는데 두 번 다 더 나빠졌어. 세 번째 시도하지 말고, 이게 세부 조정 문제가 아니라 접근 자체의 문제인지 판단해줘. 접근을 바꿔야 한다면 방법 2~3개를 이유와 함께 알려줘. 내가 고를게.

프롬프트 4: 문서를 "꺼내 쓰기 좋은" 형태로 다듬기

이 문서를 아래 기준으로 다듬어줘. 문장을 바꾸는 부분은 어디를 어떻게 바꿨는지 다 알려줘.

• 한 문단 = 한 가지 얘기, 두세 줄 안쪽
• 굵은 글씨로 강조만 하고 지나가는 문장 중 소제목이 될 만한 건 소제목으로
• 목록 항목은 "제목 — 한 줄 설명" 형태로
• 문단이 넷 이상 이어지면 소제목으로 끊기

아루나의 다른 프로젝트가 궁금하다면 → aluna-site.vercel.app