AI가 만든 슬라이드의 글자 겹침: 상자 크기와 실제 줄바꿈의 차이

슬라이드 생성 코드가 정상 실행되고 파일도 잘 열리지만, 제목과 설명 문장이 겹칠 때가 있다. 텍스트 상자가 슬라이드 안에 들어갔다고 해서 그 안의 글자까지 알맞게 들어가는 것은 아니다. 자동 맞춤 옵션을 켜 두었더라도 최종 화면에서 줄바꿈과 글자 크기를 다시 확인해야 하는 이유가 여기에 있다.

2026년 11월 3일 발표된 Palette (새 창)의 수정 전후 그림을 출발점으로, 글자 겹침을 상자·문자·내용의 세 문제로 나눠 본다. 아래 치수 계산은 작동 원리를 설명하기 위한 가상 예시이며, Palette를 직접 실행하거나 그 검사기를 재현한 결과는 아니다.

Palette의 공개 예시에서는 카드 네 개가 가로로 나열되어 있고, 각 카드의 제목과 설명이 서로 겹친다. 수정 후에는 이 카드 네 개를 2×2로 재배치해 카드당 가로 공간을 넓혔다. 원자료 그림 (새 창) 왼쪽에서 제목과 설명이 겹치는 부분과, 오른쪽에서 숫자와 설명이 분리된 부분을 비교해 보면 카드 배치가 바뀌었음을 알 수 있다.

이를 검사할 때는 세 가지 경계를 구분할 수 있다. 첫째는 상자가 슬라이드 밖으로 벗어났는지다. 둘째는 렌더링된 글자가 자기 상자를 넘치거나 다른 글자를 가리는지다. 셋째는 상자에 맞게 고치는 과정에서 수치나 문장이 누락되었는지다. 배경 사각형 위에 글자를 올리는 것은 의도한 겹침이므로, 사각형이 교차한다고 해서 모두 오류로 처리해서는 안 된다.

코드상의 x·y·너비·높이는 첫 번째 경계를 계산할 때 쓰인다. 두 번째 경계는 실제 폰트와 줄바꿈, 행간, 안쪽 여백의 영향을 받는다. 세 번째 경계는 원문과 수정본의 내용을 대조해야 알 수 있다. 좌표만 검사하는 코드 하나로 이 세 가지를 모두 통과했다고 볼 수는 없다.

높이가 96pt인 텍스트 상자를 가정해 보자. 위아래 여백은 각각 6pt이고, 현재 렌더링된 제목은 세 줄이며 한 줄당 36pt를 차지한다고 둔다. 이때 필요한 높이는 6+36×3+6=120pt다. 상자 자체는 슬라이드 안에 들어가더라도 글자를 담기에는 24pt가 부족하다. 이 수치는 폰트의 일반적인 측정값이 아니라 계산을 위해 둔 가정이다.

글자 크기를 30pt에서 24pt로 줄이고 줄 높이도 같은 비율로 줄어든다고 가정하면 한 줄은 28.8pt가 된다. 줄 수가 그대로 세 줄이라면 필요한 높이는 6+28.8×3+6=98.4pt로, 여전히 상자보다 2.4pt 높다. 글자를 줄였다고 해서 무조건 수정에 성공하는 것은 아니다. 실제로는 글자 크기가 바뀌면 줄 수도 달라질 수 있으므로 다시 렌더링해 봐야 한다.

다른 방법은 글자 크기를 유지한 채 카드 너비를 넓히는 것이다. 가로 네 칸을 두 칸으로 바꾼 뒤 제목이 두 줄로 줄었다고 가정하면, 필요한 높이는 6+36×2+6=84pt다. 대신 카드는 두 행으로 배치된다. 카드 높이가 각각 96pt이고 행 간격이 24pt라면 세로로 총 216pt를 써야 한다. 만약 남은 세로 공간이 180pt뿐이라면 이 수정은 또 다른 넘침을 부른다. 너비를 늘리는 해법 역시 슬라이드 전체의 여유 공간을 고려해 판단해야 한다.

PptxGenJS의 고정 버전 타입 정의 (새 창)에서는 fit 옵션을 none·shrink·resize로 구분한다. shrink는 넘치는 글자를 줄이는 설정이고, resize는 글자에 맞춰 상자를 늘리는 설정이다. 두 옵션은 조절하는 대상부터 다르다. 앞서 든 높이 96pt 예시에서 상자를 120pt로 늘리면 글자는 다 들어가지만, 바로 아래에 있는 요소를 밀어내거나 가릴 수 있다.

해당 소스 코드의 주석에는 shrink와 resize가 텍스트를 편집하거나 도형 크기를 변경한 뒤에 적용되며, 라이브러리가 그 동작을 직접 실행할 수는 없다고 적혀 있다. 따라서 이 방식으로 fit 설정을 파일에 기록하는 것과 실제 화면에서 원하는 글자 크기로 렌더링되는 것은 별개로 확인해야 할 문제다. 이를 모든 PowerPoint 생성기나 다른 버전의 동작으로 일반화할 수는 없다.

실무에서는 사용하는 라이브러리 버전과 파일을 실제로 열어 볼 프로그램, 그리고 폰트를 함께 고정해 두고 확인할 수 있다. 폰트가 바뀌어 같은 문장이 세 줄에서 네 줄로 늘어나면 앞서 본 높이 계산도 달라진다. 이 글에서는 특정 렌더러의 자동 맞춤 결과를 직접 측정하지 않았으므로, 옵션 하나로 모든 문제가 해결된다고 단정하지 않는다.

Palette의 처리 흐름 (새 창)은 설계 담당이 JSON 브리프를 만들면 슬라이드별로 코드를 생성한 뒤 렌더링·기하 검사·수정을 거치도록 구성되어 있다. 발표 내용에 따르면 개선이 확인된 수정본만 남긴다. 그림에서 코드 생성 뒤에 검사 단계가 따로 마련된 이유를 앞선 96pt 예시에 대입해 볼 수 있다. 코드 작성이 끝났더라도 실제 줄 수와 겹침 여부는 렌더링을 거쳐야 확인할 수 있기 때문이다.

이 예시를 실제 서비스에 적용한다면 수정 후보를 비교하는 항목을 세분화해 둘 수 있다. 상자 밖으로 넘친 글자나 다른 글자를 가리는 정도가 줄었는지, 정해 둔 최소 글자 크기를 유지했는지, 원문의 수치와 설명이 그대로 남았는지를 함께 살핀다. 이 비교 방식은 이 글의 제안일 뿐, Palette 내부 검사기의 정확한 채택 공식은 아니다. 기하 오류가 줄었다는 결과를 두고 내용 보존이나 가독성까지 좋아졌다고 확대 해석해서는 안 된다.

남은 공간이 충분하다면 요소를 재배치하고, 글자를 줄여도 괜찮다면 크기 조정을 검토할 수 있다. 둘 다 여의치 않으면 내용을 다음 슬라이드로 나누거나 별도의 편집 판단을 내려야 한다. 중요한 것은 수정 명령을 실행했는지가 아니라, 동일한 폰트와 화면 조건에서 글자·상자·내용을 다시 대조해 보았는지다.