[실패 사례] Claude Code로 MD→PPT 변환 스킬 만들다가... 392개 슬라이드의 충격 😱

[실패 사례] Claude Code로 MD→PPT 변환 스킬 만들다가... 392개 슬라이드의 충격 😱

  • ✅ 3주간 Phase 1~3 완료, 14개 기능 구현

  • ❌ 실전 테스트에서 참담한 실패

  • 💡 "기능 많다고 좋은 게 아니다"를 뼈저리게 깨달음


프로젝트 시작: 야심찬 계획

동기

"Obsidian에 있는 강의 자료 MD 파일을 PPT로 자동 변환하면 편하겠다!"

목표

Markdown → PowerPoint 자동 변환 스킬 개발

Phase 1: 기본 기능

  • Markdown 파싱 (제목, 불릿, 표, 이미지)

  • 슬라이드 자동 생성

  • 한글 폰트 지원

  • 품질 검증

Phase 2: 향상 기능

  • 구분선 처리 개선

  • 하이퍼링크 변환 ([텍스트](URL))

  • 코드 블록 지원 (Monospace 폰트)

  • 템플릿 시스템

Phase 3: 고급 기능

  • 슬라이드 노트 (발표자 메모)

  • 이미지 자동 크기 조정

  • PDF 변환 (--pdf 옵션)

  • 차트/그래프 지원 (<!-- chart:bar -->)


개발 과정: 순조롭게 진행

아키텍처 설계

Parser → Planner → Generator → Validator

1. Parser (parser.py)

  • Markdown 구조 파싱

  • 제목, 불릿, 표, 이미지, 코드, 차트 감지

2. Planner (planner.py)

  • 슬라이드 설계도 생성

  • 자동 분할 (슬라이드당 불릿 5개)

  • 타입별 슬라이드 배치

3. Generator (generator.py)

  • python-pptx로 실제 PPTX 생성

  • 폰트, 레이아웃, 차트 적용

4. Validator (validator.py)

  • 품질 검증 및 경고

기술 스택

  • Python 3.13

  • python-pptx (PowerPoint 생성)

  • Pillow (이미지 처리)

  • LibreOffice (PDF 변환)

개발 결과

✅ 총 14개 기능 구현 ✅ 테스트 문서 7개 작성 ✅ Phase 1, 2, 3 모두 완료 ✅ 설치 스크립트 완성


실전 테스트: 재앙의 시작 💥

테스트 파일

CEE_Sales_Process_1. situation analysis_Pages_21-40.md
  • 용도: 세일즈 프로세스 자료

  • 위치: Obsidian Vault

  • 예상: "20-40페이지 정도니까... 30개 슬라이드?"

변환 실행

/md-to-ppt "파일경로.md"

결과 발표 🎊

🔄 MD to PPT 변환 시작...
✓ 파싱 중...
✓ 슬라이드 설계 중...
  - 총 392개 슬라이드 생성 예정    <-- !!!
✓ PPTX 생성 중...
✓ 검증 중...

📄 생성 완료!
⚠️  356개 경고 발견

392개 슬라이드 😱😱😱


문제 분석: 무엇이 잘못되었나

1. 과도한 자동 분할

max_bullets_per_slide = 5  # 이게 문제였다

의도: 슬라이드가 너무 꽉 차지 않게 결과: 불릿이 조금만 많아도 수십 개로 분할

예시:

## 주요 기능
- 기능 1
- 기능 2
- 기능 3
- 기능 4
- 기능 5
- 기능 6  <-- 새 슬라이드
- 기능 7  <-- 또 새 슬라이드
...

2. 모든 컨텐츠 블록을 슬라이드화

문제점:

  • 텍스트 단락 → 슬라이드

  • 불릿 리스트 → 슬라이드

  • 표 → 슬라이드

  • 이미지 → 슬라이드

  • 코드 → 슬라이드

결과: 내용이 조각조각 흩어짐

3. 중복 제목 대량 발생

⚠️ 356개 경고 발견
- 슬라이드 8: 중복 제목 "영문" (슬라이드 3과 동일)
- 슬라이드 10: 중복 제목 "영문 (계속)"
- 슬라이드 11: 중복 제목 "한국어 번역"
...

같은 섹션 내용이 여러 슬라이드로 분할되면서 제목이 반복됨

4. 사용자 니즈 오해

개발자 생각:

  • "기능 많으면 좋겠지!"

  • "자동화 많이 하면 편하겠지!"

  • "테스트 문서로 잘 되니까 괜찮겠지!"

사용자 실제 니즈:

  • 간결한 슬라이드: 핵심만 압축

  • 맥락 유지: 내용 흐름이 자연스러워야 함

  • 커스터마이징: 자동화보다 조정 가능성


사용자 반응

1차 반응

"이게 뭐야 디자인도 전혀 들어가 있지도 않고 내용 파악도 안되고 그만해!!!!"

2차 반응

"이내용이 무슨 392 페이지나 된다고!!! 내용파악을 잘못한 거야"

3차 반응

"스킬이 잘못 만들어 진것은 아닐까?"

정곡을 찌르는 지적 👍


교훈: 뼈아픈 깨달음

1. 기능 != 가치

착각:

기능 14개 = 엄청 좋은 스킬

현실:

실제로 쓸 수 없으면 = 가치 0

핵심: 사용자가 원하는 건 "많은 기능"이 아니라 "문제 해결"

2. 테스트 데이터의 함정

개발 중 테스트:

  • simple-test.md: 9개 슬라이드 ✅

  • code-test.md: 15개 슬라이드 ✅

  • chart-test.md: 26개 슬라이드 ✅

실전 데이터:

  • 실제 책 원고: 392개 슬라이드

교훈: 인위적 테스트 데이터는 현실을 반영하지 못한다

3. 기본값의 중요성

max_bullets_per_slide = 5  # 너무 작음
max_bullets_per_slide = 10  # 적절할 수도?
max_bullets_per_slide = "사용자가 선택"  # 최선!

문제: 개발자의 추측으로 기본값 결정 해결: 사용자가 조정 가능하게

4. 점진적 개발 vs 한 번에 다 만들기

내가 한 것:

Phase 1 → Phase 2 → Phase 3 완료!
→ 실전 테스트
→ 대참사

했어야 하는 것:

Phase 1 완료
→ 실전 테스트 (이 단계에서 발견했어야!)
→ 피드백 반영
→ Phase 2

5. 사용자와의 소통

실패 요인:

  • 중간 확인 없이 3개 Phase 연속 개발

  • "다 만들면 좋아하겠지" 착각

  • 실제 사용 시나리오 검증 부족

개선 방향:

  • 각 Phase마다 실제 파일로 테스트

  • 사용자 피드백 받고 방향 조정

  • MVP(Minimum Viable Product) 먼저


개선 방안

즉시 적용 가능한 수정

1. 분할 설정 노출

/md-to-ppt file.md --max-bullets 10

2. 미리보기 기능

/md-to-ppt file.md --preview
# → "총 45개 슬라이드 생성 예정. 계속? (y/n)"

3. 범위 지정

/md-to-ppt file.md --sections "섹션1,섹션2"

4. 요약 모드

/md-to-ppt file.md --summary
# → AI가 핵심만 추출해서 슬라이드 생성

근본적 재설계

현재 접근:

모든 내용을 슬라이드로 = 문제

새로운 접근:

사용자가 선택한 부분만 슬라이드로
+ AI가 구조를 이해하고 재구성
+ 디자인 템플릿 적용

결론: 실패에서 배운 것

실패의 원인

  1. ❌ 사용자 니즈 검증 부족

  2. ❌ 실제 데이터 테스트 부족

  3. ❌ 기능 vs 사용성 균형 실패

  4. ❌ 과도한 자동화

  5. ❌ 점진적 검증 부재

성공한 부분

  1. ✅ 기술적 구현 능력

  2. ✅ 체계적 아키텍처

  3. ✅ 다양한 기능 구현

  4. ✅ 문서화 및 테스트

가장 큰 교훈

"기능을 만드는 것보다 사용자의 문제를 이해하는 것이 먼저다"

다음 프로젝트에서는...

  1. ✅ MVP 먼저, 기능은 나중에

  2. ✅ 실제 사용자, 실제 데이터로 테스트

  3. ✅ 각 단계마다 피드백

  4. ✅ "왜 이 기능이 필요한가?" 끊임없이 질문

  5. ✅ 자동화보다 제어권을 사용자에게


마무리

이번 실패는 아팠지만 값진 경험이었습니다.

392개 슬라이드는 제게 이렇게 말했습니다:

"기능 14개 만드는 데 쓴 시간을 사용자와 대화하는 데 썼다면 이런 일은 없었을 거야"

뉴스레터 무료 구독