HTML to PPTX 변환 실험
AI가 만든 HTML 슬라이드를 고칠 수 있는 pptx로. 하루 시험하고 접었다.
회사에서 하루 동안 돌린 기술 실험이다. 회사명, 사내 환경, 저장소, 시험에 쓴 문서 내용은 비공개다. 코드는 공개하지 않으며, 여기 남기는 것은 무엇을 시험했고 왜 접었는지뿐이다.
무엇을 했나
AI 가 만든 HTML 발표 자료를 사람이 고칠 수 있는 pptx 로 옮기는 변환기를 시험했다. 그림으로 구운 슬라이드가 아니라, 글상자와 목록과 표가 PowerPoint 안에서 그대로 편집되는 파일이 목표였다.
오픈소스 변환기 dom-to-pptx 를 바닥에 두고, 그 앞뒤에 손질 단계를 붙여 결함을 메웠다. 변환은 규칙 기반이고 AI 모델을 부르지 않는다. 그리고 같은 날 오후, 이 변환기를 접었다. 상위 AI 에 같은 HTML 을 주면 편집 가능한 pptx 를 바로 만들어 줬고, 거의 모든 면에서 변환기보다 나았기 때문이다.
왜 시작했나
출발 질문은 하나였다. HTML 을 pptx 로 정확히 바꾸는 게 기술적으로 얼마나 어려운가. AI 가 만든 HTML 슬라이드를 PowerPoint 에서 고쳐 쓰려면, 그림이 아니라 편집 가능한 pptx 로 옮겨야 한다.
그래서 다른 것보다 먼저 기존 변환 도구가 실제로 깨지는지부터 봤다. 깨지지 않는다면 만들 이유가 없고, 깨진다면 어디가 깨지는지가 곧 할 일 목록이 된다.
기존 변환기는 어디서 깨지나
시험 덱을 따로 만들었다. 6장짜리 기본 덱, 원인을 한 가지씩 떼어 보는 대조 덱, Tailwind 와 Chart.js 를 쓴 8장짜리 보고서형 덱이다. 변환 결과는 pptx 안의 XML 을 집계해 구조를 보고, 렌더링한 그림을 원본 HTML 과 장별로 나란히 놓아 봤다.
dom-to-pptx 에서 확정한 결함은 여섯 가지다.
- 하위 목록이 끼면 바깥 목록이 낱장 글상자로 무너지고 글머리표가 사라진다
- 굵게와 기울임이 섞인 문장이 단어 단위로 쪼개진다
- 글상자 안쪽 여백이 0 이라, 줄이 바뀌는 자리에서 글자가 꺾이고 겹친다
- 그라데이션 글자가 투명도 100% 로 들어가 보이지 않는다
thead·tr에 준 배경색이 빠져 표 머리글이 사라진다. 변환기가 칸 단위 스타일만 옮기기 때문이다- 차트가 그림으로 굳어 수치를 고칠 수 없다
보고서형 덱은 8장 중 3~4장에서 이 중 하나 이상이 나왔다.
판정은 PowerPoint 에서 한다
처음엔 PowerPoint 를 프로그램으로 띄울 수 없어서 LibreOffice 로 렌더링해 비교했다. 여기서 두 번 속을 뻔했다.
- 번호 목록이 매 항목 1 로 되돌아가는 현상을 변환기 결함으로 적었다. PowerPoint 에서 열어 보니 1, 2, 3 으로 정상이었다. LibreOffice 만의 문제였고 결함 목록에서 뺐다.
- 실전 덱에서 웹 글꼴이 안 보이는 현상도 같았다. PowerPoint 에서는 제대로 나왔다.
반대 방향으로도 속았다. 보고서형 덱 5장은 구조 집계로는 「온전」이었는데, 그림으로 보니 표 머리글이 없었다. 구조는 맞는데 색이 빠진 것이다.
그래서 규칙을 세웠다. 렌더러 하나의 그림으로 결함을 확정하지 않는다. 구조 집계와 그림 비교를 둘 다 보고, 최종 판정은 PowerPoint 에서 한다. 이후 PowerPoint 렌더링을 자동화해 비교 그림에 칸을 하나 더 붙였다.
보정 변환기 구조
변환기를 바꾸지 않고 앞뒤를 덧댔다. 범용 문서 변환 서비스 두 곳에도 넣어 봤는데 슬라이드를 한 장 단위로 알아보지 못했다. 브라우저가 그린 결과를 옮기는 방식이 맞는 방향이라고 보고, 그 계열인 dom-to-pptx 를 바닥으로 남겼다.
구현은 코딩 에이전트에 맡기고, 다른 에이전트로 리뷰를 두 번 돌렸다. 두 번 다 조건부 승인이었다. 시험 설계와 결함 판정, PowerPoint 실물 확인은 사람이 했다.
글상자 안쪽 여백이 0 이라 굵은 글자가 줄 끝에서 꺾인다. 그렇다고 모든 글상자를 넓히면 여러 줄 문단의 줄 바뀌는 자리가 원본과 달라진다. 변환 전에 브라우저가 실제로 몇 줄로 그렸는지 기록해 두고, 한 줄이었던 글상자에만 폭을 더 준다. 두 꺾임을 같이 막는 방법은 이것 하나였다.
굵은 글자로 시작하는 목록 항목은 번호 「1.」 까지 굵게 나온다. pptx 파일 규격상 번호의 굵기를 항목 글자와 떼어 줄 방법이 없다고 보고 보류했다. 차트가 그림으로 굳는 문제는 고칠 수는 있지만 시제품 범위를 넘어서 다음 단계로 미뤘다.
리뷰에서 걸린 것 중 무거운 것은 이랬다.
- 목록 첫 항목에만 왼쪽 여백이 있으면 들여쓰기 값이 음수로 들어가 파일 규격을 어긴다
- 목록을 하나도 못 찾아도 성공으로 처리했다
- 변환이 실패하면 이전 결과 파일이 남아, 비교 그림이 옛 파일과 원본을 대조했다
전부 고쳤다.
남의 PowerPoint 를 끄지 않는다
PowerPoint 렌더링을 자동화하면서 더 무서운 문제가 하나 보였다. 그 PC 에서 pptx 를 더블클릭하면, 렌더링용으로 띄운 같은 PowerPoint 프로세스 안에 사용자 문서가 열릴 수 있었다. 실험으로 재현했다. 렌더링이 끝났다고 그 프로세스를 강제 종료하면 사용자가 저장하지 않은 편집이 같이 날아간다.
종료 직전에 우리가 열지 않은 문서가 있는지 본다. 있으면 끄지 않고 경고만 남긴다. 확인 자체가 실패해도 끄지 않는다. 남는 프로세스 하나는 되돌릴 수 있지만, 날아간 편집은 되돌릴 수 없다.
프로세스 번호는 재사용된다. 번호만 들고 있다가 끄면 그 사이 같은 번호를 받은 다른 프로그램을 끌 수 있다. 리뷰에서는 창 제목으로 가리자는 제안도 나왔는데, PowerPoint 가 숨은 창을 띄우는 탓에 창 제목으로는 우리가 띄운 PowerPoint 조차 구분되지 않았다. 실측으로 다른 판정 방식을 찾아 썼다.
오류가 나면 자동화로 띄운 PowerPoint 가 숨은 채 남아, 다음 실행이 그것을 사용자의 PowerPoint 로 착각할 수 있다는 지적도 받아 고쳤다.
실전 덱을 넣자 새 결함이 나왔다
자체 제작 덱 다섯 개로 맞춘 변환기를 AI 가 실제로 만든 덱에 넣어 봤다. 첫 덱은 쓸 수 없었다. 코딩 에이전트 세션에서 받은 것이라 기존 시험 덱을 참고해 만들어져 있었다. 시험 대상이 시험지를 베낀 셈이다. 파일과 도구를 못 쓰게 하고 주제를 바꾼 프롬프트로 다시 받았다.
그 덱에서 결함이 여럿 새로 나왔다. 하위 목록 글머리, 표 안의 막대, 시간선의 동그라미가 사라졌고 바닥글 줄이 바뀌었다. 원인은 ::before·::after 로 그린 장식을 옮기지 못하는 것과, 중첩 선택자가 깨지는 것이었다. 자체 제작 덱으로는 드러나지 않던 결함이다. 장식을 고치는 작업은 중간에 멈췄다.
그리고 접었다
같은 HTML 을 범용 AI 채팅에 주고 pptx 를 만들어 달라고 했다. 원본, 보정 변환기 결과, AI 가 만든 파일을 나란히 렌더링했다.
AI 는 HTML 의 내용을 읽고 편집 가능한 pptx 를 기본 차트까지 포함해 만들어 냈다. 변환기가 아직 못 푸는 차트를 AI 는 처음부터 고칠 수 있는 차트로 줬다. 거의 모든 면에서 앞섰다.
변환기에 남는 강점은 셋이다. 비용이 0 이고, 빠르고, 같은 입력에 같은 결과가 나온다. 이게 의미 있는 곳은 대량 변환이나 AI 를 쓸 수 없는 환경 정도인데, 그 수요는 확인하지 못했다. 그래서 여기서 접었다.
같은 날 비슷한 결론이 하나 더 나왔다. 사내 도구 화면을 자동으로 찍어 사용자 매뉴얼 pptx 를 만드는 시험이었는데, 일반 AI 에 명령만 내려도 충분히 잘 나왔다. 반복 작업이라 값어치는 있으니 별도 도구 대신 팀 내부 스킬로 굳히자고 권했다.
변환기의 결함을 하나씩 메우는 동안 비교 대상은 기존 변환기였다. 정작 경쟁자는 변환기가 아니라 「HTML 을 보여 주고 pptx 를 달라고 하는 것」이었다. 그 비교는 변환기를 다 손본 뒤에야 했다. 다음부터는 구현 전에 이것부터 돌린다.
지금 상태
접었다. 비공개 저장소에 결론과 근거를 README 로 정리해 종료 커밋을 남겼다. 공개 링크는 없다.
손대지 않고 남긴 것:
- 차트가 그림으로 굳는 문제
::before·::after장식과 중첩 선택자 처리. 장식을 도형으로 옮기는 코드는 써 두었지만 변환에 연결하지 않았다- 굵은 글자로 시작하는 항목의 번호 굵기, 인라인 코드가 낀 문단 분리, CSS 카운터로 매긴 번호 목록
- 자동 렌더링용 PowerPoint 와 사람이 보는 PowerPoint 가 심은 글꼴을 다르게 다루는 것으로 보이는 현상. 원인은 확정하지 못했다