Claude Code로 강의 PPT를 매번 다르게 만드는 이유 2026 – 디자인 스캐폴딩·병렬 원고·이미지 생성 워크플로우

Posted on by

강의 PPT를 매번 다르게 만들려면 새 도구를 하나 더 켜는 것보다 작업을 네 덩어리로 쪼개는 편이 낫다.

2026년 4월 29일 기준 내가 보는 핵심은 디자인 스캐폴딩, 원고 병렬화, 이미지 생성, 사람 검수다.

이 네 단계를 Claude Code 안에서 분리하면 매번 비슷한 템플릿을 재탕하지 않으면서도 품질이 무너지지 않는다.

PPT를 만들 때 제일 위험한 순간은 의외로 첫 슬라이드를 만들 때가 아니다.

처음 5장은 대체로 신난다.

새 주제, 새 예시, 새 이미지, 새 목차.

문제는 17장쯤 갔을 때 온다.

슬라이드마다 말투가 달라지고, 도식은 점점 아무 말 대잔치가 되고, 한 장은 컨설팅 보고서 같고, 다음 장은 동아리 발표자료처럼 보인다.

여기서 사람은 보통 도구 탓을 한다.

PowerPoint가 불편하다.

Gamma가 질린다.

Canva 템플릿이 다 비슷하다.

이미지 생성 모델이 글자를 이상하게 쓴다.

다 맞는 말인데, 정작 더 큰 문제는 워크플로우가 한 덩어리라는 점이다.

슬라이드의 구조, 말할 내용, 시각자료, 검수 기준을 한 프롬프트에 전부 넣으면 AI도 결국 대충 섞는다.

사람도 냉장고 정리와 세금 신고와 운동 계획을 한 번에 하라고 하면 잠깐 멍해진다.

AI도 별반 다르지 않다.

그래서 이 글은 “Claude Code로 PPT 만드는 법”을 기능 설명으로 다루지 않는다.

진짜 포인트는 어떤 일을 Claude Code에 맡기고, 어떤 일은 별도 레인으로 나누고, 어떤 지점에서 사람이 멈춰서 보는가다.

Threads Inbox에 들어온 메모는 짧았다.

강의를 갈 때마다 PPT를 매번 다르게 만든다는 말, 덕테이프처럼 여러 도구를 붙인다는 말, 이미지 생성, Claude Code, 디자인 스캐폴딩이라는 단서가 있었다.

이 정도면 그냥 “AI PPT 꿀팁”으로 쓰면 얇다.

TECHTAEK에서는 조금 다르게 봐야 한다.

강의 PPT는 결과물이 아니라 운영 파이프라인이다.

매번 다른 강의를 만든다는 건 매번 다른 디자인을 뽑는다는 뜻만이 아니다.

청중, 시간, 실습 난이도, 데모 실패 가능성, 강사의 말버릇, 자료 배포 방식까지 같이 바뀐다는 뜻이다.

그러니 Claude Code를 PPT 생성기로만 쓰면 아깝다.

Claude Code는 터미널 안의 슬라이드 공장이 아니라, 슬라이드 제작 과정을 나눠서 굴리는 작업 지휘실에 가깝다.

물론 말이 거창하면 보통 일은 망한다.

그래서 아래는 아주 현실적인 기준으로 간다.

강의 하나를 준비한다고 치자.

이미 대략의 주제는 있다.

예를 들어 “AI 에이전트로 블로그 파이프라인 운영하기” 같은 주제다.

이 주제를 매번 같은 PPT로 쓰고 싶지 않다.

청중이 개발자면 구조와 실패 로그를 더 보여줘야 한다.

마케터면 콘텐츠 생산 비용과 검수표를 더 보여줘야 한다.

대표나 의사결정자면 도입 비용과 리스크를 먼저 보여줘야 한다.

여기서 PPT 자동화의 목적은 슬라이드를 빨리 만드는 게 아니다.

청중별로 바뀌어야 하는 부분과 바뀌면 안 되는 부분을 분리하는 것이다.

이걸 분리하지 않으면 AI가 열심히 꾸며도 강의는 묘하게 흐물흐물해진다.

겉은 번쩍이고 속은 감자전이다.

맛은 있을 수 있는데, 발표장에서는 곤란하다.

짧은 판단

Claude Code로 강의 PPT를 만들 때는 한 번에 완성본을 요구하지 않는 편이 낫다.

먼저 슬라이드 뼈대와 디자인 규칙을 스캐폴딩한다.

그다음 원고와 예시를 병렬로 만든다.

이미지는 장식이 아니라 이해가 어려운 한두 지점에만 쓴다.

마지막으로 PowerPoint나 Keynote에서 사람이 실제 발표 흐름으로 검수한다.

이 순서가 귀찮아 보이지만, 반대로 하면 더 귀찮다.

완성된 40장짜리 PPT를 뒤늦게 고치는 일은, 이미 끓인 라면에서 스프만 다시 빼는 일과 비슷하다.

가능은 한데 마음이 상한다.

왜 Claude Code인가

PPT만 생각하면 전용 슬라이드 생성 도구가 더 편해 보인다.

그 도구들은 템플릿, 레이아웃, 자동 디자인, 발표자료 내보내기를 잘한다.

그런데 강의 자료를 계속 만드는 사람에게 더 큰 병목은 디자인 버튼이 아니다.

반복되는 주제 파일, 지난 강의 피드백, 실습 코드, 이미지 프롬프트, FAQ, 강의 시간표, 수강생 수준별 변형, 배포용 PDF, 블로그 후속 글까지 한 폴더에 얽힌다.

Claude Code는 이런 파일 기반 작업에서 힘이 난다.

공식 문서 기준으로 Claude Code는 프로젝트 안의 스킬, 명령, 서브에이전트, 설정, 훅 같은 구조를 통해 반복 작업을 나눠 운영할 수 있다.

custom command와 skill은 자주 쓰는 프롬프트와 지원 파일을 프로젝트 안에 둘 수 있게 해준다.

subagent는 탐색이나 초안 같은 보조 작업을 별도 컨텍스트에서 처리하게 해준다.

hooks는 특정 이벤트 뒤에 검증 스크립트나 알림을 붙일 수 있게 해준다.

settings는 권한과 민감 파일 접근 제한을 관리하는 층이다.

이 기능들이 PPT를 예쁘게 만들어 준다는 뜻은 아니다.

오히려 반대다.

PPT를 예쁘게 만드는 일은 마지막 단계다.

Claude Code가 잘하는 일은 PPT가 예뻐지기 전의 지저분한 준비물을 정리하는 쪽이다.

강의 목적을 정리하고, 청중별 목차를 나누고, 실습 코드를 확인하고, 슬라이드별 말할 내용을 만들고, 표현 톤을 통일하고, 이미지 생성 요청을 따로 뽑고, 검수 체크리스트를 남기는 일이다.

즉 Claude Code는 발표자료 편집기가 아니라 발표자료 운영자다.

이 구분을 놓치면 첫날은 신나고 둘째 날부터 파일명이 final_v7_really_final_last.pptx가 된다.

누구나 한 번쯤 그 지옥을 본다.

파일명에 감정이 들어가면 이미 늦은 것이다.

전체 구조

내가 추천하는 구조는 네 레인이다.

레인 맡기는 일 결과물 사람이 보는 기준
디자인 스캐폴딩 슬라이드 타입, 톤, 색, 반복 컴포넌트 정의 deck_style.md 매 강의에 재사용 가능한가
병렬 원고 청중별 목차, 슬라이드별 말하기 원고, 실습 흐름 slides_outline.md, speaker_notes.md 말로 읽었을 때 자연스러운가
이미지 생성 도식화가 필요한 장면만 이미지 프롬프트화 visual_brief.md 이미지를 빼도 내용이 남는가
검수·출고 분량, 흐름, 링크, 데모, PDF 배포 확인 deck_review.md 발표 당일 사고를 줄이는가

이 표에서 중요한 건 레인 이름보다 순서다.

디자인을 먼저 정한다고 해서 색상 팔레트를 먼저 고르라는 뜻이 아니다.

여기서 디자인 스캐폴딩은 “이번 강의는 어떤 종류의 슬라이드들로 이루어지는가”를 정하는 일이다.

예를 들어 강의 슬라이드는 보통 아래 타입으로 나눌 수 있다.

문제 제기 슬라이드.

개념 정의 슬라이드.

비교표 슬라이드.

워크플로우 슬라이드.

실습 안내 슬라이드.

실패 사례 슬라이드.

체크리스트 슬라이드.

마무리 행동 슬라이드.

이 타입을 먼저 정해두면 매번 새 강의를 만들어도 뼈대는 흔들리지 않는다.

겉모습은 바뀌어도 문법은 유지된다.

강의 PPT에서 중요한 건 바로 이 문법이다.

1단계: 디자인 스캐폴딩부터 만든다

디자인 스캐폴딩은 “예쁜 템플릿 골라줘”가 아니다.

그건 너무 늦게 묻는 질문이다.

먼저 물어야 할 질문은 이렇다.

이번 강의는 설명형인가, 실습형인가, 설득형인가, 워크숍형인가.

한 장에 들어갈 평균 정보량은 어느 정도인가.

코드나 표가 많이 나오는가.

라이브 데모가 실패했을 때 대체 슬라이드가 필요한가.

청중이 발표자료를 나중에 다시 읽을 가능성이 높은가.

현장 발표용과 배포 PDF용을 분리해야 하는가.

이 질문에 답하면 색상보다 먼저 레이아웃 규칙이 나온다.

예를 들어 개발자 대상 실습 강의라면 슬라이드가 예쁘기만 해서는 부족하다.

명령어가 잘 보여야 한다.

실습 순서가 끊기면 안 된다.

코드 블록은 복사 가능한 자료와 연결돼야 한다.

반대로 경영진 대상 세션이라면 코드 한 줄보다 결정표 하나가 더 중요하다.

그래서 Claude Code에는 먼저 이런 파일을 만들게 하는 편이 좋다.

deck_style.md.

여기에 슬라이드 타입, 각 타입의 목적, 금지 레이아웃, 반복 색상, 표현 톤, 이미지 사용 기준을 적는다.

예시는 이렇다.

# deck_style.md

## deck purpose
- audience: 실무 PM과 개발 리드
- length: 40분 발표 + 10분 Q&A
- mode: 설명 60%, 실습 25%, 의사결정 체크 15%

## slide types
- problem: 현장의 불편을 1문장으로 고정한다
- workflow: 단계는 4개 이하로 제한한다
- demo: 실패 시 대체 캡처를 둔다
- checklist: 발표 후 바로 실행할 항목만 남긴다

## visual rules
- 장식 이미지는 금지한다
- 도식은 텍스트만으로 이해가 안 되는 구간에만 쓴다
- 표는 한 장에 5행을 넘기지 않는다

이 파일이 있으면 Claude Code는 다음 작업에서 기준을 잃지 않는다.

슬라이드가 많아져도 같은 문법을 따라간다.

무엇보다 사람이 검수하기 쉬워진다.

PPT가 마음에 안 들 때 “별로야”라고 말하는 대신, workflow slide는 단계가 4개를 넘으면 안 된다고 고칠 수 있다.

이건 작은 차이 같지만 실제 작업 속도를 크게 바꾼다.

취향 싸움이 규칙 수정으로 바뀐다.

강의자료 제작에서 이건 꽤 큰 승리다.

2단계: 원고는 병렬로 쪼갠다

슬라이드 제작에서 원고는 늘 애매한 위치에 있다.

PPT를 먼저 만들고 원고를 붙이면 슬라이드가 말을 끌고 간다.

원고를 먼저 길게 쓰면 슬라이드가 문서가 된다.

그래서 둘을 완전히 분리하기보다 병렬로 만드는 편이 낫다.

Claude Code에서는 이 작업을 서브에이전트나 별도 작업 레인으로 나눌 수 있다.

공식 문서에 따르면 subagent는 별도 컨텍스트에서 특정 작업을 처리하고 요약 결과만 돌려주는 구조다.

PPT 작업에서는 이 특성이 꽤 잘 맞는다.

한 레인은 목차만 본다.

한 레인은 사례만 본다.

한 레인은 실습 흐름만 본다.

한 레인은 FAQ와 반박 질문만 본다.

메인 세션은 이 결과를 합쳐 최종 흐름을 만든다.

이렇게 나누면 좋은 점이 있다.

각 레인이 자기 일에만 집중한다.

목차 담당은 멋진 문장을 만들 욕심을 덜 낸다.

사례 담당은 전체 발표 시간을 망각하지 않는다.

FAQ 담당은 본문을 다시 쓰지 않고 빈틈만 찾는다.

물론 여기서도 조심할 점은 있다.

서브에이전트를 많이 늘린다고 항상 좋아지는 건 아니다.

작은 강의 하나에 에이전트 12개를 붙이면 작업보다 조율이 더 커진다.

치킨 한 마리 시키는데 위원회 8개 여는 느낌이다.

그래서 실무 기준은 이 정도가 적당하다.

초안 강의는 2개 레인.

상용 강의나 유료 세미나는 3개 레인.

회사 전체 교육이나 외부 컨퍼런스는 4개 레인.

그 이상은 자동화가 아니라 행사 운영이다.

행사 운영은 또 다른 체력전이다.

병렬 원고의 실제 산출물

원고 레인은 최소 세 파일로 닫는 편이 좋다.

slides_outline.md.

speaker_notes.md.

audience_variants.md.

첫 번째 파일은 슬라이드 단위 구조다.

두 번째 파일은 실제 말할 내용이다.

세 번째 파일은 청중별로 바뀌는 부분이다.

예를 들면 같은 AI 자동화 강의라도 개발자 버전은 이런 식이다.

## developer variant
- 더 보여줄 것: 폴더 구조, 실패 로그, 테스트 명령
- 줄일 것: 시장 트렌드, 추상적 생산성 문구
- 강조할 리스크: 권한, 컨텍스트 오염, 검수 누락

마케터 버전은 다르다.

## marketer variant
- 더 보여줄 것: 콘텐츠 캘린더, 승인 플로우, 재사용 템플릿
- 줄일 것: 코드 구현 세부사항
- 강조할 리스크: 브랜드 톤, 근거 출처, 발행 전 QC

의사결정자 버전은 또 다르다.

## executive variant
- 더 보여줄 것: 비용 절감 구간, 책임 경계, 도입 순서
- 줄일 것: 도구별 세부 사용법
- 강조할 리스크: 보안, 품질 책임, 운영 중단 시 대체 절차

이렇게 나누면 PPT를 매번 다르게 만드는 일이 쉬워진다.

완전히 새로 만드는 게 아니라, 청중별 변수를 바꾸는 일이 되기 때문이다.

바로 이 지점에서 Claude Code가 강해진다.

파일을 읽고, 차이를 반영하고, 반복되는 규칙을 지키고, 수정 이력을 남길 수 있기 때문이다.

3단계: 이미지 생성은 한두 장만 이긴다

PPT 자동화에서 이미지 생성은 달콤하다.

한 줄만 쓰면 멋진 그림이 나오고, 발표자료가 갑자기 있어 보인다.

그래서 위험하다.

이미지 생성은 발표자료를 살리는 도구이기도 하지만, 내용이 약한 슬라이드를 가리는 화장품이 되기도 한다.

화장품이 나쁜 건 아니다.

다만 발표자료가 세수도 안 했는데 화장만 하면 조금 슬프다.

이미지 생성은 아래 세 경우에만 쓰는 편이 좋다.

첫째, 말로 설명하면 너무 추상적인 개념.

둘째, 프로세스의 before/after가 한눈에 보여야 하는 장면.

셋째, 청중이 기억해야 할 은유나 장면.

반대로 이런 곳에는 쓰지 않는 편이 낫다.

이미 표로 충분한 비교.

숫자가 정확해야 하는 차트.

제품 UI를 실제처럼 보여줘야 하는 화면.

법적·금융적 판단이 들어가는 자료.

출처가 필요한 인물·로고·브랜드 이미지.

특히 강의 PPT에서 숫자가 들어간 이미지는 조심해야 한다.

이미지 생성 모델은 보기 좋은 표를 만들 수는 있지만, 숫자와 텍스트 정확성은 사람이 반드시 확인해야 한다.

그래서 나는 이미지 생성 전에 visual_brief.md를 따로 만드는 편을 추천한다.

# visual_brief.md

## target slide
- slide 12: 한 프롬프트에 모든 작업을 넣었을 때와 레인 분리 후의 차이

## image purpose
- 장식이 아니라 작업 분리 개념을 5초 안에 이해시키는 것

## labels
- design scaffold
- draft lanes
- visual brief
- review gate

## no-go
- 실제 로고 금지
- 수치 표기 금지
- 작은 글자 과다 금지

이 파일을 먼저 만들면 이미지 생성 요청도 깔끔해진다.

그리고 더 중요한 장점이 있다.

이미지를 만들지 않기로 결정하기 쉬워진다.

visual_brief.md를 써봤는데 목적이 흐리면, 그 이미지는 대체로 없어도 된다.

이 판단을 먼저 하는 게 좋다.

이미 만든 이미지를 버리는 건 사람 마음을 묘하게 아프게 한다.

작업물에 정이 들면 객관성이 줄어든다.

PPT도 마찬가지다.

내가 만든 이미지가 예뻐 보이면 그 슬라이드의 말이 약해도 살리고 싶어진다.

그래서 이미지 생성은 늦게, 적게, 명확하게 쓰는 게 낫다.

4단계: 검수는 발표 리허설 기준으로 한다

AI가 만든 PPT에서 제일 흔한 실수는 보기에는 괜찮은데 말로 하면 이상한 것이다.

슬라이드 제목은 멋있다.

본문도 정돈돼 있다.

그런데 발표자가 읽으면 흐름이 끊긴다.

왜냐하면 슬라이드는 시각 문서이고, 강의는 시간 속에서 진행되는 경험이기 때문이다.

검수 기준을 파일 품질이 아니라 발표 리허설 기준으로 바꿔야 한다.

deck_review.md에는 아래 항목이 들어가면 좋다.

첫째, 한 장당 말하는 시간이 과한가.

둘째, 이전 장과 다음 장 사이의 연결 문장이 있는가.

셋째, 실습 전에 필요한 준비물이 명확한가.

넷째, 이미지나 도식 없이도 핵심을 설명할 수 있는가.

다섯째, 데모가 실패했을 때 대체 슬라이드가 있는가.

여섯째, 배포 PDF만 보는 사람도 이해할 수 있는가.

일곱째, 강의 후 행동이 한두 개로 좁혀져 있는가.

여기서 Claude Code hooks를 붙일 수 있는 지점도 있다.

공식 hooks 문서에 따르면 Claude Code는 도구 사용 전후, 세션 시작, 서브에이전트 시작과 종료, 파일 변경 같은 이벤트에 훅을 연결할 수 있다.

PPT 작업에서는 예를 들어 Markdown 초안 생성 후 줄 수, 금지어, 링크, 이미지 brief 존재 여부를 검사하는 스크립트를 붙일 수 있다.

물론 처음부터 훅까지 붙일 필요는 없다.

처음에는 체크리스트 파일 하나면 충분하다.

자동화는 반복이 쌓인 뒤에 붙여야 한다.

처음부터 자동화를 붙이면 내가 무엇을 반복하는지 모른 채로 자동화부터 하게 된다.

그건 꽤 고급스러운 삽질이다.

삽도 티타늄이면 멋있긴 한데, 땅은 그대로 파야 한다.

실제 폴더 구조

강의 하나를 프로젝트처럼 관리한다면 이런 구조가 편하다.

lecture-ai-blog-pipeline/
├── brief.md
├── deck_style.md
├── slides_outline.md
├── speaker_notes.md
├── audience_variants.md
├── visual_brief.md
├── deck_review.md
├── assets/
│   ├── generated/
│   └── screenshots/
├── exports/
│   ├── slides.pdf
│   └── handout.pdf
└── sources/
    ├── official-links.md
    └── examples.md

이 구조에서 핵심은 brief.md와 deck_style.md다.

둘 중 하나가 없으면 강의가 쉽게 흔들린다.

brief.md는 왜 이 강의를 하는지 말한다.

deck_style.md는 어떤 형식으로 말할지 정한다.

나머지는 이 둘의 하위 산출물이다.

assets 폴더는 무조건 분리한다.

이미지 생성 결과, 실제 캡처, 로고, 스크린샷, 임시 시안이 섞이면 나중에 출처 확인이 힘들다.

특히 외부 강의나 회사 교육이라면 더 조심해야 한다.

내가 만든 이미지인지, 캡처한 화면인지, 외부 자료인지, 배포해도 되는지 구분되지 않으면 마지막에 발목을 잡는다.

PPT는 발표 직전에 고치기 쉬운 파일처럼 보인다.

하지만 출처와 권한은 발표 직전에 고치기 어렵다.

그래서 파일 구조가 중요하다.

구조는 귀찮음을 줄이는 장치다.

멋으로 하는 게 아니다.

프롬프트는 이렇게 나눠야 한다

한 프롬프트에 이런 식으로 쓰면 실패 확률이 높다.

AI 블로그 파이프라인 강의 PPT 40장 만들어줘.
예쁘게 해줘.
개발자도 이해하고 마케터도 좋아하게 해줘.
이미지도 넣어줘.

이건 부탁이 아니라 소원이다.

소원은 아름답지만, 작업 지시는 아니다.

대신 이렇게 나눈다.

1단계.
brief.md를 읽고 40분 강의용 슬라이드 타입을 8개 이하로 설계해줘.
각 타입의 목적, 금지 패턴, 예시 슬라이드 제목을 표로 정리해줘.

2단계.
deck_style.md를 기준으로 slides_outline.md를 만들어줘.
슬라이드는 24장 이하로 제한하고,
각 장마다 목적, 핵심 문장, 청중이 해야 할 생각을 적어줘.

3단계.
slides_outline.md를 보고 speaker_notes.md를 작성해줘.
각 슬라이드는 60초 이내로 말할 수 있게 하고,
전환 문장을 반드시 포함해줘.

4단계.
도식이 필요한 슬라이드만 골라 visual_brief.md를 만들어줘.
이미지 생성이 필요 없는 슬라이드는 이유와 함께 제외해줘.

5단계.
deck_review.md를 작성해줘.
발표 리허설 기준으로 시간 초과, 흐름 끊김, 데모 실패, 출처 누락을 점검해줘.

이렇게 나누면 Claude Code가 매 단계에서 다른 역할을 한다.

처음에는 설계자.

다음에는 편집자.

그다음에는 강의 코치.

마지막에는 검수자.

역할을 바꾸면 결과도 바뀐다.

같은 모델이라도 “예쁘게 만들어줘”와 “발표 리허설 기준으로 40분 안에 줄여줘”는 전혀 다른 일을 한다.

이 차이를 이해하는 사람이 AI PPT를 훨씬 안정적으로 쓴다.

언제 전용 PPT 도구를 써야 하나

Claude Code만으로 모든 걸 끝내려고 하면 또 다른 삽질이 된다.

전용 PPT 도구가 더 나은 순간은 분명히 있다.

첫째, 이미지와 레이아웃 편집을 빠르게 해야 할 때.

둘째, 브랜드 템플릿이 PowerPoint 파일로 정해져 있을 때.

셋째, 애니메이션과 발표자 노트를 실제 슬라이드 앱에서 확인해야 할 때.

넷째, 팀원이 Claude Code를 쓰지 않고 PPT 파일만 주고받을 때.

다섯째, 클라이언트가 원본 PPTX를 요구할 때.

이 경우 Claude Code는 앞단을 맡고, PowerPoint나 Keynote나 다른 슬라이드 도구가 뒤단을 맡는 편이 현실적이다.

앞단은 구조와 원고다.

뒤단은 레이아웃과 최종 배포다.

이 역할 분리가 중요하다.

Claude Code에서 만든 Markdown을 그대로 PPT로 변환하는 자동화도 가능하다.

하지만 모든 강의가 그 방식을 필요로 하지는 않는다.

간단한 사내 세미나는 Markdown 기반으로 충분할 수 있다.

외부 유료 강의는 최종 PPT 편집을 사람이 보는 편이 낫다.

컨퍼런스 키노트는 디자인 감수까지 별도 단계로 보는 게 안전하다.

AI가 다 해준다는 말은 듣기 좋다.

하지만 실제 현장에서는 “어디까지 AI가 하고 어디서 사람이 잡는가”가 더 중요하다.

이 선을 못 그으면 자동화가 아니라 자동 피로가 된다.

실패 패턴 7가지

첫 번째 실패는 제목만 바꾸고 같은 강의를 반복하는 것이다.

PPT는 달라 보이는데 청중별 질문이 달라지지 않는다.

개발자에게도 ROI 표를 보여주고, 경영진에게도 폴더 구조를 보여준다.

둘 다 살짝 난감해진다.

두 번째 실패는 이미지가 너무 많은 것이다.

슬라이드가 화려해질수록 발표자는 그림 설명자가 된다.

강의의 주인공이 메시지가 아니라 이미지가 된다.

세 번째 실패는 speaker note가 없는 것이다.

슬라이드만 만들고 말할 내용을 따로 만들지 않으면 발표 당일에 improvisation이 된다.

즉흥성이 나쁜 건 아니지만, 유료 강의에서 즉흥성은 양념이어야지 주식이면 곤란하다.

네 번째 실패는 출처 파일이 없는 것이다.

강의자료에 수치나 공식 문서를 넣었다면 출처를 따로 남겨야 한다.

AI가 요약한 문장만 믿고 넣으면 나중에 확인할 때 힘들다.

다섯 번째 실패는 검수 기준이 모호한 것이다.

“좀 더 세련되게”라는 피드백은 AI에게도 사람에게도 힘들다.

“workflow 슬라이드는 4단계 이하로 줄여줘”가 훨씬 낫다.

여섯 번째 실패는 모든 청중을 만족시키려는 것이다.

한 강의가 개발자, 마케터, 대표, 학생, 투자자에게 동시에 맞을 수는 없다.

그건 강의라기보다 행운권 추첨에 가깝다.

일곱 번째 실패는 마지막에 PPT 앱에서만 고치는 것이다.

최종 파일에서만 고치면 다음 강의에 재사용할 지식이 남지 않는다.

수정 이유를 Markdown 파일로 남겨야 다음번 자동화가 똑똑해진다.

체크리스트

PPT 제작 전에 아래를 먼저 확인한다.

  • brief.md에 청중, 시간, 목적, 배포 방식이 있는가.
  • deck_style.md에 슬라이드 타입과 금지 패턴이 있는가.
  • slides_outline.md가 24장 이하로 정리됐는가.
  • speaker_notes.md가 실제 말하는 순서로 되어 있는가.
  • audience_variants.md에 청중별 차이가 들어 있는가.
  • visual_brief.md가 필요한 이미지와 필요 없는 이미지를 구분했는가.
  • deck_review.md가 발표 리허설 기준으로 작성됐는가.
  • 출처와 이미지 권한이 sources/나 assets/에 분리돼 있는가.
  • 최종 PPT 편집 도구에서 열었을 때 글자 크기와 줄바꿈이 깨지지 않는가.
  • PDF로 내보냈을 때 링크와 이미지가 살아 있는가.

이 체크리스트가 너무 길어 보이면 정상이다.

PPT는 원래 생각보다 많은 일을 숨기고 있다.

단지 예전에는 그 일을 사람이 머릿속으로 들고 다녔다.

Claude Code를 쓰면 그 머릿속 일을 파일로 꺼낼 수 있다.

그게 핵심이다.

AI가 갑자기 천재 디자이너가 되는 게 아니다.

작업의 기억이 남는다.

그 기억이 다음 강의를 쉽게 만든다.

비용과 시간은 어디서 줄어드나

이 워크플로우가 줄여주는 건 첫 PPT 제작 시간이 아니다.

첫 번째 강의는 오히려 조금 더 걸릴 수 있다.

파일 구조를 만들고, 규칙을 쓰고, 검수표를 만드는 시간이 필요하기 때문이다.

효과는 두 번째 강의부터 나온다.

같은 주제를 다른 청중에게 바꿀 때, 지난번 deck_style.md와 audience_variants.md가 그대로 출발점이 된다.

강의 후 피드백도 다음 자료에 반영하기 쉽다.

예를 들어 수강생이 “실습 전 준비물이 헷갈렸다”고 말했다면, 다음번에는 실습 안내 슬라이드 타입을 고치면 된다.

어떤 도식이 이해가 안 됐다는 피드백이 나오면, visual_brief.md를 고치면 된다.

발표 시간이 초과됐다면, speaker_notes.md에서 각 슬라이드 시간을 줄이면 된다.

이렇게 수정 지점이 분리돼 있으면 개선이 누적된다.

PPT 파일 하나만 고치면 개선이 파일 안에 갇힌다.

Markdown 산출물을 고치면 개선이 워크플로우에 남는다.

여기가 비용 절감 지점이다.

디자인 비용보다 더 큰 건 반복 설명 비용이다.

매번 처음부터 설명하고, 매번 같은 실수를 고치고, 매번 출처를 다시 찾는 시간이 줄어든다.

강의가 많아질수록 이 차이는 커진다.

팀에서 쓸 때 권한과 보안

팀에서 Claude Code를 PPT 워크플로우에 붙일 때는 설정도 봐야 한다.

공식 settings 문서는 민감 파일 접근을 제한하는 permissions.deny 같은 설정을 안내한다.

강의 자료에는 고객명, 내부 수치, 비공개 로드맵, 수강생 정보, 계약 조건이 섞일 수 있다.

그래서 프로젝트 폴더 안에 무엇을 넣을지 먼저 정해야 한다.

AI가 읽어도 되는 자료.

읽으면 안 되는 자료.

요약본만 제공할 자료.

최종 발표에 들어가면 안 되는 자료.

이 네 가지를 나누지 않으면 위험하다.

특히 강의 PPT는 외부 공개와 내부 메모가 섞이기 쉽다.

초안에서는 편하게 쓴 문장이 최종 PDF에 남을 수도 있다.

이건 웃기지만 웃기지 않은 사고다.

따라서 팀 프로젝트에서는 private/, sources/, exports/를 분리하는 편이 좋다.

Claude Code가 읽어도 되는 범위를 명시하고, 최종 배포 파일은 별도 폴더에서 확인한다.

자동화가 편해질수록 권한 경계는 더 선명해야 한다.

이건 PPT에도 똑같이 적용된다.

코드만 보안이 필요한 게 아니다.

발표자료도 회사의 생각이 담긴 파일이다.

혼자 쓸 때의 최소 버전

혼자 강의자료를 만드는 사람이라면 처음부터 거창하게 시작하지 않아도 된다.

최소 버전은 세 파일이면 된다.

brief.md.

slides_outline.md.

deck_review.md.

처음에는 디자인 스캐폴딩도 brief.md 아래에 넣어도 된다.

이미지 생성도 당장은 안 해도 된다.

서브에이전트도 없어도 된다.

중요한 건 한 번에 완성본을 요구하지 않는 습관이다.

초안, 원고, 검수의 순서를 나누는 것만으로도 결과가 달라진다.

혼자 쓰는 워크플로우는 가벼워야 오래 간다.

처음부터 폴더 12개, 스킬 8개, 훅 5개, 서브에이전트 6개를 만들면 본업이 사라진다.

우리는 강의를 만들려고 했지, 작은 우주선을 띄우려던 게 아니다.

작게 시작하고 반복되는 불편만 자동화한다.

그게 제일 오래 간다.

언제 이 방식이 과한가

모든 발표자료에 이 워크플로우가 필요한 건 아니다.

10분짜리 팀 공유.

한 번 쓰고 버릴 내부 보고.

이미 정해진 브랜드 템플릿에 숫자만 업데이트하는 자료.

이런 작업은 그냥 직접 만드는 편이 빠를 수 있다.

Claude Code 워크플로우는 반복과 변형이 있을 때 빛난다.

강의를 여러 번 한다.

청중이 자주 바뀐다.

같은 주제로 블로그, 뉴스레터, PPT, 실습 자료를 같이 만든다.

자료 품질을 다음번에도 이어가고 싶다.

이 조건이 있으면 워크플로우를 만들 가치가 있다.

반대로 한 번 쓰고 끝나는 자료라면 너무 큰 구조를 만들지 말자.

작업보다 구조가 커지면 구조가 일을 먹는다.

이건 AI 자동화에서 자주 보는 장면이다.

처음엔 생산성을 올리려고 시작했는데, 나중엔 자동화 설정을 관리하느라 하루가 간다.

그럴 땐 과감히 줄여야 한다.

도구는 일을 줄여야지, 새로운 취미가 되면 곤란하다.

취미로 자동화를 하는 건 괜찮다.

다만 그걸 업무 효율이라고 부르면 살짝 양심이 찔린다.

FAQ

Claude Code만으로 PPTX까지 바로 만들 수 있나?

가능한 경로는 있다.

Markdown을 슬라이드로 변환하거나, 스크립트로 PPTX를 생성하거나, 별도 프레젠테이션 도구와 연결할 수 있다.

다만 이 글의 핵심은 PPTX 자동 생성 자체가 아니다.

강의 품질을 좌우하는 앞단 구조를 먼저 나누는 것이다.

최종 PPTX 생성은 팀 도구와 배포 방식에 맞춰 선택하면 된다.

이미지 생성은 꼭 넣어야 하나?

아니다.

이미지는 이해를 돕는 장면에만 쓰는 편이 좋다.

비교표, 숫자, 출처가 중요한 자료는 텍스트와 표가 더 안전하다.

이미지 생성은 메시지를 강화할 때 쓰고, 메시지를 대신하게 하면 안 된다.

subagent를 꼭 써야 하나?

작은 발표자료에는 필요 없다.

하지만 강의가 길고 청중별 변형이 많다면 유용하다.

목차, 사례, FAQ, 실습 흐름처럼 역할이 분명한 보조 작업을 별도 컨텍스트에서 처리할 수 있기 때문이다.

단, 결과를 합치는 메인 기준은 사람이 잡아야 한다.

기존 PPT를 매번 새로 바꾸는 데도 쓸 수 있나?

쓸 수 있다.

다만 기존 PPT를 바로 수정하기 전에 먼저 역분해하는 게 좋다.

슬라이드 타입, 청중, 핵심 메시지, 불필요한 장식, 업데이트가 필요한 출처를 분리한다.

그다음 새 청중 기준으로 audience_variants.md를 만들면 재사용성이 올라간다.

강의자료와 블로그 글을 같이 만들 수 있나?

오히려 같이 만들 때 효율이 좋다.

강의의 speaker_notes.md는 블로그 초안의 재료가 된다.

deck_review.md에서 나온 빈틈은 FAQ가 된다.

이미지 brief는 블로그 인포그래픽이나 썸네일 기획으로도 전환할 수 있다.

단, 블로그는 검색 의도와 출처 표기가 더 중요하므로 그대로 복붙하면 안 된다.

참고 자료

관련 글

마무리

강의 PPT를 매번 다르게 만드는 일은 템플릿을 매번 갈아끼우는 일이 아니다.

바뀌어야 하는 부분과 유지해야 하는 부분을 분리하는 일이다.

Claude Code는 이 분리에 잘 맞는다.

디자인 스캐폴딩을 파일로 남기고, 원고를 병렬 레인으로 나누고, 이미지는 필요한 장면만 brief로 만들고, 검수는 발표 리허설 기준으로 닫는다.

이렇게 하면 PPT는 단발성 파일이 아니라 계속 개선되는 강의 시스템이 된다.

처음에는 조금 번거롭다.

하지만 두 번째, 세 번째 강의부터 차이가 난다.

매번 새로 만들지만, 매번 처음부터 시작하지는 않는다.

그게 좋은 자동화다.

화려한 버튼보다 오래 남는 구조.

PPT에도 결국 그게 이긴다.