AI로 PPT 대신 HTML 슬라이드 만들기: 쓸 만한 경우와 망하는 지점

PPT를 만들어야 하는데 차트, 애니메이션, 3D, 영상용 설명 장면까지 필요하다면 파워포인트만 붙잡고 있을 이유는 없습니다. AI에게 HTML/CSS/JavaScript로 슬라이드를 만들게 하면 브라우저 전체화면만으로 발표 자료처럼 쓸 수 있습니다. 대신 한글 폰트, 글자 크기, 파일 구조를 처음에 못 박지 않으면 첫 화면만 예쁘고 수정할 때부터 귀찮아집니다.

결론부터 말하면 HTML 슬라이드는 PPT의 완전한 대체재라기보다 "웹페이지처럼 움직이는 발표 자료"에 가깝습니다. 그래서 정해진 회사 템플릿에 맞춰 파일을 제출해야 한다면 PPT가 낫고, 차트·인터랙션·3D·영상용 장면처럼 화면 자체를 조작해야 한다면 HTML 쪽이 더 실용적입니다.

 

 

 

먼저 갈라야 할 것: 문서 제출용인가, 화면 연출용인가

PPT는 파일을 주고받기 좋습니다. 회사 양식에 맞춰 수정하고, 다른 사람이 파워포인트에서 열어 고치고, 최종본을 첨부 파일로 제출해야 한다면 이 장점이 큽니다. HTML 슬라이드는 여기서 불리합니다. 받는 사람이 브라우저로 열 수는 있어도, 파워포인트처럼 익숙하게 고치기는 어렵습니다.

반대로 발표 자료가 점점 웹 화면처럼 변하면 HTML이 편해집니다. 버튼을 누르면 설명이 바뀌고, 차트가 움직이고, 3D 모델을 돌리고, 영상에 넣을 다이어그램 장면을 만들어야 한다면 PPT 안에서 억지로 버티는 것보다 웹 기술로 만드는 편이 덜 답답합니다.

간단히 나누면 이렇습니다.

 

상황	더 나은 선택
사내 템플릿, 파일 제출, 공동 수정	PPT
빠른 텍스트 중심 보고	PPT
차트, 애니메이션, 인터랙션	HTML 슬라이드
영상 편집용 설명 장면	HTML 슬라이드
3D 모델, 좌표축, 시뮬레이션	HTML 슬라이드
블로그나 웹페이지에 그대로 삽입	HTML 슬라이드

HTML 슬라이드는 "파일 제출용 문서"가 아니라 "브라우저에서 실행되는 발표 화면"이라고 생각해야 판단이 쉬워집니다.

 

핵심은 결과물이 아니라 관리 방식입니다. HTML 슬라이드는 슬라이드처럼 보이지만 실제로는 작은 웹 프로젝트입니다. 이 차이를 이해하고 시작하면 쓸 만하고, 모르면 "AI가 예쁘게 만들어준 이상한 파일"이 됩니다.

 

 

AI에게 그냥 맡기면 거의 같은 곳에서 망한다

AI에게 "PPT 스타일로 멋지게 만들어줘"라고만 하면 대체로 데모 화면은 잘 나옵니다. 문제는 그 데모가 한국어 발표 자료로 바로 쓸 수준이 아닐 때가 많다는 점입니다.

자주 나오는 문제는 정해져 있습니다.

• 한글 폰트를 제대로 지정하지 않아 줄 높이와 자간이 어색하다.
• 발표용인데 글씨가 너무 작다.
• 기술 발표처럼 보이려고 다크 모드를 기본으로 깐다.
• 한 화면에 정보를 너무 많이 넣는다.
• index.html 하나에 모든 코드와 슬라이드를 몰아넣는다.
• 차트나 3D 라이브러리를 애매하게 직접 구현하려다 결과가 불안정해진다.

 

그래서 처음 요청할 때부터 제약을 넣어야 합니다. 예쁘게 만들어 달라는 말보다 아래 조건이 더 중요합니다.

HTML/CSS/JavaScript로 16:9 발표용 슬라이드를 만들어줘.
브라우저 전체화면에서 발표할 수 있게 각 섹션을 슬라이드처럼 넘기게 해줘.
한국어 본문 기준으로 글자 크기를 크게 잡고, 한글 폰트는 Pretendard 또는 Noto Sans KR을 우선 사용해줘.
기본 배경은 밝은 모드로 만들고, 장식보다 가독성을 우선해줘.
차트가 필요하면 Chart.js를 사용하고, 데이터는 내가 준 값만 써줘.
3D가 필요하면 Three.js를 사용하되, 모델 파일은 /assets/models/ 폴더에 있다고 가정해줘.
파일은 index.html, styles.css, slides.js처럼 나눠줘.

 

이 프롬프트의 목적은 AI를 세게 조종하는 게 아니라 나중에 손볼 지점을 줄이는 것입니다. 특히 한국어 발표 자료에서는 폰트와 글자 크기를 안 잡으면 거의 반드시 다시 뜯어고치게 됩니다.

 

 

제품 소개 슬라이드: 이미지가 없어도 시안은 뽑힌다

HTML 슬라이드는 제품 소개 시안에서 의외로 잘 맞습니다. 예를 들어 샴푸 제품 소개 슬라이드를 요청하면, 제품 이미지가 없어도 AI가 CSS 아트로 병 모양을 그려 넣는 경우가 있습니다. 상업용 최종 이미지라고 보기는 어렵지만, 방향을 보는 시안으로는 충분히 쓸 수 있습니다.

여기서 HTML이 더 재미있어지는 지점은 서브 페이지입니다. 첫 화면은 제품 히어로 슬라이드로 두고, 버튼을 누르면 성분, 사용감, 비교표, 상세 설명으로 넘어가게 만들 수 있습니다. PPT에서도 비슷한 이동은 가능하지만, JavaScript로 상태를 다루면 제품 소개 페이지처럼 자연스럽게 구성할 수 있습니다.

다만 실제 사진을 넣기 시작하면 다시 봐야 합니다. CSS 아트 기준으로 맞춘 색과 여백은 실물 이미지와 안 맞을 수 있습니다. 이때는 "첨부한 이미지 색상에 맞춰 배경색, 버튼 색, 그림자 강도를 다시 조정해줘"처럼 이미지 기준 재조정을 따로 시키는 편이 낫습니다.

 

 

차트와 표: 라이브러리를 지정해야 덜 흔들린다

발표 자료에서 차트가 많다면 HTML 슬라이드는 꽤 실용적입니다. 다만 AI에게 "차트 넣어줘"라고만 하면 직접 그린 SVG 비슷한 걸 만들거나, 데이터와 라벨을 대충 맞춘 듯한 결과가 나올 수 있습니다. 차트는 처음부터 Chart.js 같은 라이브러리를 지정하는 편이 안정적입니다.

예를 들면 이렇게 요청합니다.

Chart.js로 월별 매출 라인 차트를 만들어줘.
데이터 라벨은 한국어로 표시하고, 축 글자 크기는 발표 화면 기준 18px 이상으로 해줘.
범례는 차트 아래에 두고, 색은 3개 이하로 제한해줘.
데이터는 아래 값만 사용해줘.

 

차트에서 실제로 많이 망하는 건 화려함이 아니라 가독성입니다. 축 라벨이 작고, 색이 많고, 범례가 멀고, 애니메이션이 과하면 발표장에서 숫자가 안 읽힙니다. "크게, 적게, 읽히게"가 차트 프롬프트의 기준입니다.

 

 

영상 편집용 장면: 예쁜 대시보드처럼 만들면 실패한다

HTML 슬라이드는 영상에 넣을 설명 장면을 만들 때도 잘 맞습니다. 브라우저 화면을 녹화하거나, 개발자 도구로 풀사이즈 스크린샷을 찍어 이미지로 뽑을 수 있기 때문입니다. 해킹 과정, 메모리 변조 흐름, 네트워크 요청, 데이터 파이프라인처럼 단계별로 보여줘야 하는 장면에는 특히 편합니다.

예를 들어 리눅스 해킹 사건을 설명하면서 프로세스 메모리가 변조되는 흐름을 보여줘야 한다고 해봅시다. HTML로 만들면 큰 제목에는 글리치 효과를 넣고, 다음 슬라이드에서는 메모리 블록이 바뀌는 다이어그램을 움직이게 만들 수 있습니다.

문제는 AI가 이런 장면을 자꾸 "멋진 대시보드"처럼 만든다는 겁니다. 작은 글씨가 많고, 칸이 촘촘하고, 화면을 멈춰놓고 봐야 이해되는 식입니다. 발표용이면 그나마 낫지만 영상 안에 들어가면 거의 안 읽힙니다.

영상용이면 처음부터 이렇게 제한하는 편이 좋습니다.

이 슬라이드는 유튜브 영상 삽입용이야.
작은 설명 문장은 제거하고, 한 화면에 핵심 문장 1개와 큰 도형 1개만 남겨줘.
모바일에서도 읽히도록 최소 글자 크기는 32px 정도로 잡아줘.

 

기술 내용도 별도로 확인해야 합니다. AI가 그린 다이어그램은 그럴듯해 보여도 보안, 해킹, 성능, 정책 같은 설명에서는 틀린 흐름을 예쁘게 그릴 수 있습니다. 화면 제작과 사실 검증은 분리해서 봐야 합니다.

 

 

3D와 시뮬레이션: 멋있어서가 아니라 이해가 빨라질 때만 쓴다

브라우저는 3D 장면도 처리할 수 있습니다. Three.js 같은 라이브러리를 쓰면 3D 모델을 올리거나, 좌표 공간에 점을 찍거나, 카메라를 움직이며 구조를 보여줄 수 있습니다. 예를 들어 LAB 색상 공간의 분포를 3D 월드에 찍어 보여주는 자료는 평면 슬라이드보다 공간 관계를 설명하기 쉽습니다.

AI에게 시킬 때는 3D 모델의 위치와 장면 조건을 같이 줘야 합니다.

같은 폴더에 /assets/models/bottle.glb 파일이 있어.
Three.js로 3D 모델을 중앙에 배치하고, 마우스로 회전 가능하게 해줘.
슬라이드 배경은 밝게 하고, 모델 아래에는 짧은 설명 한 줄만 넣어줘.
성능을 위해 그림자와 후처리 효과는 최소화해줘.

 

3D는 쉽게 과해집니다. 발표 자료에서 중요한 건 "와 멋있다"가 아니라 "이걸 3D로 보니 바로 이해된다"입니다. 색상 분포, 제품 형태, 공간 구조, 좌표축처럼 3D가 설명력을 줄 때만 넣는 게 좋습니다.

 

 

웹페이지에 넣거나 배포할 수 있다는 것도 장점이다

HTML로 만든 슬라이드는 발표로 끝나지 않습니다. 블로그 글 안에 인터랙티브 예시로 넣거나, 별도 페이지로 배포할 수 있습니다. 정적인 이미지 한 장보다 독자가 눌러보고 돌려볼 이유가 생기면 글 자체의 가치도 올라갑니다.

다만 이것을 검색 순위 상승 공식처럼 말하면 안 됩니다. HTML을 넣었다고 검색이 잘 되는 건 아닙니다. 의미 있는 건 독자가 이해할 만한 상호작용을 제공할 수 있다는 점입니다. 차트 값을 바꿔보거나, 3D 모델을 돌려보거나, 단계별 설명을 직접 넘겨볼 수 있으면 글이 단순 설명보다 오래 남습니다.

배포는 GitHub Pages 같은 정적 사이트 호스팅을 쓸 수 있습니다. HTML/CSS/JavaScript 파일을 저장소에 올리고 공개 URL로 열면, 발표장 컴퓨터에 파일을 옮기는 대신 브라우저에서 주소를 열 수 있습니다. 물론 오프라인 발표라면 필요한 파일을 로컬에 같이 챙기는 편이 안전합니다.

 

 

PPT 단일 파일 흐름과 HTML 슬라이드 프로젝트의 파일 분리 흐름을 비교한 다이어그램

 

에이전트를 쓰면 파일을 나누는 순간부터 편해진다

Cursor나 Claude Code 같은 AI 에이전트를 쓰면 HTML/CSS/JS 파일을 직접 만들고 고치게 할 수 있습니다. 이때부터는 프롬프트 한 번 잘 쓰는 것보다 프로젝트 구조를 잘 잡는 쪽이 더 중요합니다. Cursor를 쓴다면 rules와 context를 어떻게 잡을지 먼저 정리해두는 편이 좋고, 이 부분은 Cursor 완전 가이드 2025: AI 코딩 워크플로우, rules·context 설정법을 같이 보면 이어서 잡기 쉽습니다.

추천 구조는 이 정도면 충분합니다.

/slides-project
  index.html
  styles.css
  slides.js
  data/
    chart-data.json
  assets/
    images/
    models/
  guide.md

 

 

guide.md에는 반복해서 지킬 규칙을 적어둡니다.

한국어 발표용이므로 본문은 28px 이상을 기본으로 한다.
기본 테마는 밝은 모드로 한다.
한 슬라이드에는 핵심 메시지 하나만 둔다.
Chart.js 차트는 축 라벨을 18px 이상으로 잡는다.
영상용 슬라이드는 작은 보조 설명을 과감히 줄인다.

 

이렇게 해두면 매번 긴 프롬프트를 새로 쓰지 않아도 됩니다. "3번 슬라이드 차트 색만 바꿔줘", "5번 슬라이드를 영상용으로 줄여줘", "모바일에서는 세로 스택으로 바꿔줘"처럼 지시할 수 있습니다.

단일 HTML 파일 하나에 모든 슬라이드를 몰아넣으면 초반에는 편하지만 뒤로 갈수록 귀찮아집니다. 작은 문구 하나 고치려고 긴 파일 전체를 다시 읽히고, 토큰을 많이 쓰고, 엉뚱한 레이아웃이 같이 바뀔 수 있습니다. AI 에이전트를 쓸수록 파일 분리가 보험입니다.

여기서 더 나아가 MCP 서버나 플러그인까지 붙여 이미지 생성, 문서 컨텍스트, 브라우저 검증 같은 작업을 연결하고 싶다면 Claude Code 잘 쓰는 법: 2026년 생산성 높이는 설정, 플러그인, MCP 서버 가이드 쪽이 다음 단계에 가깝습니다. HTML 슬라이드도 결국 작은 프론트엔드 프로젝트라서, 도구가 할 수 있는 일과 사람이 검토해야 하는 일을 나눠두는 게 중요합니다.

 

 

 

바로 쓰기 전 체크리스트

HTML 슬라이드는 웹페이지라서 발표 직전에 처음 열어보면 위험합니다. 최소한 아래는 확인하는 게 좋습니다.

• 브라우저 전체화면에서 16:9 화면이 잘 맞는가?
• 발표장 해상도나 녹화 해상도에서 글자가 읽히는가?
• 한글 폰트가 실제 환경에서 적용되는가?
• 차트 데이터와 라벨이 원본과 일치하는가?
• 다이어그램 설명이 사실과 맞는가?
• 모바일이나 작은 화면에서도 최소한 깨지지 않는가?
• 인터넷이 끊겨도 필요한 이미지, 모델, 폰트가 로드되는가?
• 모든 슬라이드가 한 파일에 몰려 있어 수정이 어려운 상태는 아닌가?

 

특히 외부 CDN으로 폰트나 라이브러리를 불러오는 구조라면 발표 장소의 네트워크도 변수입니다. 중요한 발표라면 로컬에서 필요한 파일을 같이 들고 가거나, 오프라인에서도 열리는지 확인하는 편이 안전합니다.

 

 

FAQ

 

코딩을 몰라도 HTML 슬라이드를 만들 수 있나요?

초안은 만들 수 있습니다. 다만 실제 발표에 쓰려면 폰트, 글자 크기, 파일 경로, 데이터 정확도 정도는 확인해야 합니다. 코딩을 깊게 몰라도 되지만, 결과물을 검토하지 않고 그대로 쓰는 건 위험합니다.

 

HTML 슬라이드를 PPT 파일로 변환하는 게 좋나요?

보통은 변환보다 브라우저 전체화면이나 이미지/영상 캡처가 낫습니다. HTML을 쓰는 이유가 인터랙션, 차트, 3D라면 PPT로 바꾸는 순간 장점이 줄어듭니다. 파일 제출이 목적이면 처음부터 PPT로 만드는 편이 낫습니다.

 

정리하면

AI로 HTML 슬라이드를 만드는 방식은 꽤 쓸 만합니다. 특히 차트, 인터랙션, 3D, 영상용 설명 장면처럼 PPT에서 손이 많이 가는 작업에서는 실전성이 있습니다.

다만 핵심은 "AI가 알아서 만들어준다"가 아닙니다. 발표 조건을 명시하고, 한글 폰트와 글자 크기를 잡고, 라이브러리를 지정하고, 파일을 나눠서 관리해야 합니다. 그렇게 해두면 HTML 슬라이드는 단순한 PPT 대체재가 아니라 웹에서 보여주고, 고치고, 배포할 수 있는 발표용 작업물이 됩니다.