AI 피피티(AI PPT) 제작의 한계 극복: HTML과 개인 자동화로 나만의 발표 자료 빌드하기

문서 자동화 시도

자동화에 관심을 가지게 된 이후, 가장 먼저 생각났던 것은 문서의 자동화였습니다.

여기서 겪은 몇 가지 문제는, hwpx¹와 docx²는 내부 구조를 풀어보면 XML³ 기반 파일들이 드러나는데, 이때 발생되는 태그 때문에 토큰을 많이 먹고, 양식 보존이 생각보다 어려웠다는 것이었습니다.

마누스와 젠스파크를 이용해보기도 했고, 깊게 사용하지는 못했지만 클로드 코워크를 이용해보기도 했습니다. 마누스와 젠스파크에서도 양식을 재구성해서 빈칸을 채우는 작업은 어려웠고, 코워크는 채워넣기 자체는 가능했지만 비효율이라고 느꼈습니다. 마누스의 경우 PPT 생성 등에 시간이 걸리는 점도 있었습니다. 다만 테스트해본 것은 두어 달 전이라, 지금은 또 달라졌을 수 있습니다.

docx의 경우는 파이썬 라이브러리가 존재해서 꽤 결과가 잘 나왔으나, hwpx는 기존 양식을 변경하거나 유지하기가 꽤 힘들었습니다.

(1) HWPX — 한글과컴퓨터 한글 문서의 개방형 XML 기반 문서 형식입니다. 내부 구조를 분석할 수 있다는 장점은 있지만, 양식 보존과 세밀한 편집은 자동화하기 까다로운 편입니다.

(2) DOCX — Microsoft Word의 문서 형식입니다. 내부적으로 여러 XML 파일과 리소스를 압축한 구조이며, Python 라이브러리 생태계가 비교적 잘 갖춰져 있습니다.

(3) XML(eXtensible Markup Language) — 데이터를 태그 구조로 표현하는 마크업 형식입니다. 문서 파일 내부 구조를 표현하는 데 자주 쓰이지만, 태그가 많아지면 LLM이 읽고 수정하기에는 부담이 커질 수 있습니다.

HTML로 방향 전환

이것들을 직접 조작해보려는 시도를 거쳐서, HTML⁴을 이용하는 게 낫겠다는 결론을 내렸습니다. LLM이 무엇보다 잘 다루는 게 HTML, CSS⁵, JavaScript⁶인데, 굳이 MS 오피스와 한글에 묶일 필요가 있을까?

행정안전부도 공식 보도자료에서 사람뿐만 아니라 AI도 쉽게 이해할 수 있는 문서 형식으로 마크다운 양식 내려받기를 지원한다고 밝힌 상황⁷에서, 굳이 도구에 얽매일 필요는 없겠다는 결론을 내렸습니다.

일정 규모의 서류가 쌓여 있는 기업이 아닌 경우라면, HTML로 발표 자료와 문서를 만들어서 발표 자료는 브라우저에 바로 띄우고, 문서의 경우 PDF로 바로 변환하면 되겠다는 생각을 하게 되었습니다.

이 사고의 흐름 끝에 발표 자료 쪽으로 나온 결과물이 Vanilla Presentation⁸입니다.

(4) HTML(HyperText Markup Language) — 웹페이지의 구조를 정의하는 마크업 언어입니다. 제목, 문단, 표, 이미지 같은 정보의 뼈대를 만듭니다.

(5) CSS(Cascading Style Sheets) — HTML 요소의 색상, 간격, 크기, 배치 같은 시각 표현을 담당하는 스타일 언어입니다.

(6) JavaScript — 웹페이지에 동작을 부여하는 프로그래밍 언어입니다. 이 스킬에서는 좌우 방향키 이동 같은 최소한의 발표 내비게이션만 담당합니다.

(7) 행정안전부 공식 보도자료 — 행정안전부는 보도자료 게시판을 개편하면서, 사람뿐만 아니라 인공지능도 쉽게 이해할 수 있는 문서 형식인 마크다운 양식 내려받기를 함께 지원한다고 밝혔습니다. 보도자료 보기 →

Vanilla Presentation 구조

Vanilla Presentation은 외부 프레젠테이션 라이브러리를 쓰지 않고 HTML, CSS, JavaScript만으로 발표 자료를 만드는 스킬입니다. 이름에 Vanilla를 붙인 이유도 그 때문입니다. 무언가를 더 붙이기보다 브라우저가 원래 잘하는 것만으로 발표 자료를 만들자는 방향입니다.

제가 직접 만든 스킬이고, 저장소에서 받아서 써볼 수 있습니다. jih4855/custom-productivity-suite

구조는 단순합니다.

파일	역할
spec.json	슬라이드 구조와 내용
index.html	빌드된 발표 자료
base.css	공통 프레임과 발표 셸
theme.css	발표 주제별 시각 스타일
engine.js	좌우 방향키 이동

spec.json을 먼저 쓰게 한 이유도 여기에 있습니다. 사용자가 발표 대본이나 슬라이드 순서를 주면, LLM이 그 내용을 발표 자료 구조로 바꿉니다. 긴 문장은 줄이고, 순서를 정리하고, 각 슬라이드에 맞는 표현 형식을 고릅니다.

예를 들면 어떤 내용은 카드로 나누고, 어떤 내용은 표로 정리하고, 어떤 내용은 흐름도로 보여주는 식입니다. 이 과정을 먼저 거치면 HTML을 직접 만지기 전에 발표 자료의 뼈대를 정할 수 있습니다.

{
  "deck": "발표 제목",
  "slides": [
    {
      "type": "cover",
      "title": "표지 제목",
      "subtitle": "부제"
    },
    {
      "type": "content",
      "title": "핵심 메시지",
      "components": [
        {
          "type": "cards",
          "items": [
            { "title": "항목", "desc": "설명" }
          ]
        }
      ]
    }
  ]
}

(8) Vanilla Presentation — 외부 프레젠테이션 라이브러리 없이 HTML, CSS, JavaScript만으로 발표 자료를 만드는 로컬 스킬입니다. JSON 스펙을 작성하면 index.html, base.css, theme.css, engine.js 파일 묶음으로 발표 자료를 생성합니다. custom-productivity-suite 저장소 보기 →

(9) JSON(JavaScript Object Notation) — 데이터를 구조화해 저장하는 가벼운 텍스트 형식입니다. 이 스킬에서는 슬라이드 제목, 순서, 컴포넌트, 표 데이터 등을 정의하는 설계도 역할을 합니다.

테마 CSS 분리

또 하나 신경 쓴 부분은 base.css와 theme.css를 분리한 점입니다. base.css는 발표 자료의 프레임을 잡습니다. 슬라이드 크기, 기본 셸, 내비게이션, 한 화면 원칙 같은 부분입니다. 반면 theme.css는 분위기를 담당합니다. 색상, 글꼴, 카드, 표, 흐름도 스타일은 여기서 바꿉니다.

내용을 바꾸고 싶으면 JSON을 봅니다. 디자인을 바꾸고 싶으면 theme.css를 봅니다. 발표 자료의 기본 동작이 이상하면 engine.js를 봅니다. 역할을 나눠두면, AI 에이전트가 엉뚱한 곳을 건드릴 확률도 줄어듭니다.

스킬로 고정한 제작 기준

LLM에게 매번 발표 대본이나 구상을 상세히 적어줘도 꽤 그럴듯한 발표 자료를 만들어주긴 합니다. 다만 이 경우에는 슬라이드의 테마, 비율, 폰트가 매번 임의로 생성되어 만족스러운 결과를 얻기가 꽤 어려워집니다.

스킬의 형태로 고정시켜놓으면 상당 부분 이러한 불편을 줄일 수 있습니다. 고정된 템플릿에 내용만 변경하는 방식이기 때문입니다. 물론 이 경우에도 검수는 필요합니다.

원칙	이유
시각 우선	설명은 발표자가 하고, 슬라이드는 표·다이어그램·이미지 중심으로 둡니다.
한 장 한 메시지	한 슬라이드에서 여러 말을 하려 하면 결국 아무 말도 선명하지 않습니다.
JSON 먼저	디자인을 만지기 전에 슬라이드 구조를 먼저 합의합니다.
컴포넌트 최대 2개	한 장에 우겨넣는 순간 발표 자료가 아니라 보고서가 됩니다.
스크롤 금지	PPT는 한 장이 한 화면이어야 합니다. 넘치면 내용을 줄이거나 슬라이드를 쪼갭니다.

Vanilla Presentation은 이 기준을 미리 적어둔 스킬입니다. 매번 테마, 비율, 폰트, 구성 방식을 다시 설명하지 않기 위한 장치에 가깝습니다.

문서에서 발표 자료까지

AI 에이전트를 쓰면서 계속 느끼는 것은, 좋은 결과물은 한 번의 프롬프트에서 나오지 않는다는 점입니다. 반복 작업을 하다 보면 나만의 기준이 생기고, 그 기준을 문서화해야 다음 작업의 품질이 올라갑니다.

Vanilla Presentation은 그 기준을 발표 자료 제작에 적용한 사례입니다. 문서 자동화를 해보면서 기존 문서 형식이 다루기 어렵다는 점을 확인했고, HTML 쪽이 LLM과 더 잘 맞는다는 결론을 얻었습니다.