뒤로
D
decksmith ·

AI가 만든 슬라이드는 늘 같은 자리에서 틀립니다

레이아웃 167종을 1920×1080으로 전부 렌더링해서 자동 검사하는 작업을 하고 있습니다. 캔버스를 넘어간 요소, 잘린 텍스트, 푸터를 침범한 콘텐츠, 겹친 요소, 가려진 요소까지 다섯 가지를 봅니다.

그런데 이 작업을 반복하다 보니 예상하지 못한 것이 눈에 들어왔습니다. AI가 만든 발표자료는 못 만들어서 이상한 것이 아니라, 늘 똑같은 자리에서 틀립니다. 색도 괜찮고 정렬도 맞는데 세 번째 장쯤에서 "어디서 본 것 같다"는 느낌이 옵니다. 그 느낌의 정체를 일곱 가지로 정리했습니다.

  1. 전부 가운데 정렬입니다. 표지도 가운데, 본문도 가운데, 마무리도 가운데입니다. 가운데 정렬은 읽는 사람에게 어디부터 보라는 지시를 주지 못합니다. 한 줄짜리 표지는 가운데가 맞지만, 정보 덩어리가 둘 이상이면 왼쪽 정렬에 크기 차이를 주는 편이 낫습니다.

  2. 내용이 무엇이든 카드가 세 장입니다. 항목이 둘이어도 세 장, 다섯이어도 세 장입니다. 항목을 세기 전에 레이아웃부터 고른 결과입니다. 학습 데이터에 카드 세 장짜리 슬라이드가 압도적으로 많아서 그것이 되돌아 나오는 것으로 보입니다. 항목 수를 먼저 세고 그 수에 맞는 배치를 고르면 절반은 해결됩니다.

  3. 제목이 문장입니다. "데이터 기반 접근으로 고객 만족도를 개선했습니다"는 제목이 아니라 발표 대본입니다. 제목은 청중이 0.5초에 읽는 표지판입니다. 문장이 되는 순간 읽는 데 시간이 들고 발표자의 말과 경쟁합니다. 명사구로 줄이고 숫자를 앞에 놓는 편이 낫습니다. "만족도 32% 상승"처럼요.

  4. 숫자에 출처가 없습니다. 시장 규모가 90포인트로 박혀 있는데 몇 년 자료인지, 누가 만든 숫자인지 없습니다. 모델은 그럴듯한 숫자를 채우는 데 능하고 출처를 빠뜨리는 데도 똑같이 능합니다. 투자자 앞에서는 그 한 장이 덱 전체의 신뢰를 깎습니다. 틀린 숫자보다 빈 자리가 쌉니다.

  5. 의미 없는 장식이 붙습니다. 텍스트 뒤 그라데이션, 모든 항목마다 아이콘. 장식은 시선을 한 곳으로 끌기 위해 있는 것이라, 전부 장식하면 아무것도 끌지 못합니다. 강조색은 하나만 골라 한 장에 한 번만 씁니다.

  6. 텍스트가 잘리거나 넘칩니다. 제목이 두 줄로 넘어가면서 아래 카드를 밀어냅니다. 이것은 디자인 문제가 아니라 검증 문제입니다. 생성된 슬라이드는 대개 실제 크기로 한 번도 렌더링된 적이 없습니다. 코드로는 멀쩡하고 화면에서는 깨집니다.

  7. 장끼리 서로 어긋납니다. 3장과 7장의 여백이 다르고 본문 크기가 중간에 바뀝니다. 한 장씩 만들면 매번 새로 결정하게 되고, 그때마다 값이 조금씩 달라집니다. 청중은 이 문제를 지적하지 못합니다. 대신 "덱이 좀 성의 없다"로 기억합니다.

일곱 개를 하나씩 고치는 것보다 만드는 순서를 바꾸는 편이 빠릅니다. 이 장이 해야 할 말을 먼저 정하고, 항목을 세고, 그 수에 맞는 배치를 고른 다음, 주어진 자리에 맞춰 글을 씁니다. 보통은 정반대로 합니다. 다 써 놓고 레이아웃을 찾은 다음 안 맞으면 글씨를 줄이거나 상자를 늘립니다. 1번부터 7번까지가 바로 그 순서에서 나옵니다.

검증된 배치를 먼저 놓으면 이 목록에서 다섯 개는 생길 기회조차 없다는 것이, 지금 만들고 있는 것의 전제입니다.

전문 보기

getdeck

AI가 슬라이드를 근거 있게 고르고, 덱 단위로 조립하게 만드는 MCP 서버

1

댓글

로그인 후 댓글을 남길 수 있습니다.

오피셜메일
오피셜메일

항목 수를 세기 전에 레이아웃부터 고르면 카드 세 장 패턴이 반복된다는 설명이 특히 와닿았습니다. 생성 단계보다 실제 크기로 렌더링하고 잘림과 겹침을 검사하는 절차가 품질을 더 크게 좌우하는 것 같아요.

D
decksmith

말씀하신 대로였습니다. 167종을 대표 테마 4개로 돌렸더니 15종이 걸렸는데, 전부 코드로는 문제없어 보이던 것들이었습니다. 더 흥미로웠던 건 실패가 무작위로 퍼지지 않았다는 점입니다. 가격표, 다이어그램, 3단 카드, 프로세스 단계처럼 칸이 미리 정해진 레이아웃에 몰렸습니다. 내용 길이가 칸을 넘는 순간 깨지는 구조라서요. 생성 단계에서 이걸 피하려면 모델이 글자 수까지 맞추어 써야 하는데 그게 잘 안 됩니다. 말씀하신 것처럼 일단 렌더링해서 확인하는 쪽이 현실적인 것 같습니다.