2026년 7월 3일, 에르메스단 웨비나에 쓸 슬라이드 18장과 대본을 하룻밤에 만들었다. 손이 움직이지 않는 나는 발표자료도 AI로 만든다. 대신 만든 도구와 검수하는 도구를 나누자 스무 개가 넘는 결함이 보였다. 이 글은 빠르게 만든 자료를 어떻게 다시 읽었는지에 대한 기록이다.
"만든 놈이 검수까지 하면 자기 걸 자기가 통과시킨다. 사람이든 AI든 똑같다."
왜 만드는 AI와 검수하는 AI를 나눴나?
제작과 검수를 분리하면 결과물을 만든 쪽의 흐름에 끌리지 않고, 화면에 실제로 남은 문제를 따로 볼 수 있다.
이날 제작은 Codex exec가 맡고, Claude Fable5는 트집을 잡는 역할만 맡았다. 한 도구에게 처음부터 끝까지 맡기지 않은 이유는 단순했다. 초안을 만든 쪽은 자기 결과물의 문맥을 이미 알고 있다. 문맥을 알고 있으면 빈칸을 머릿속에서 채우기 쉽고, 그래서 화면에 겹친 글자나 잘린 숫자가 있어도 내용이 읽힌다고 판단하기 쉽다. 반면 검수 역할은 무엇을 만들었는지보다 무엇이 깨졌는지에만 집중할 수 있다.
여기서 중요한 것은 특정 모델의 우열이 아니다. 제작 단계와 검수 단계를 서로 다른 질문으로 나누는 일이다. 제작 단계에서는 전달할 내용과 장면의 순서를 묻는다. 검수 단계에서는 문장이 끝까지 보이는지, 숫자가 잘리지 않았는지, 제목이 의도하지 않은 곳에서 꺾이지 않았는지를 묻는다. 질문이 달라지면 같은 18장을 보고도 다른 결함이 드러난다.
18장을 다시 볼 때 무엇부터 확인했나?
화면 검수는 문장 뜻을 다시 읽는 일보다, 배치와 잘림처럼 눈으로 확인할 수 있는 항목을 먼저 훑는 방식이 유용하다.
검수 과정에서 잡힌 것은 스무 개가 넘었다. 겹친 글자, 잘린 숫자, 어절 중간에서 꺾인 제목이 대표적이었다. 이 문제들은 내용 초안을 읽을 때는 지나가기 쉽지만, 발표 화면에서는 한 번에 신뢰를 떨어뜨릴 수 있다. 특히 숫자는 맥락으로 복구하기 어렵다. 72,268이라는 숫자는 끝자리가 잘려 있었고, 제목은 ‘운영하는’이라는 어절의 중간에서 줄바꿈됐다.
- 첫 번째는 각 장의 제목이 한 덩어리로 읽히는지 확인하는 일이다.
- 두 번째는 숫자와 기호가 프레임 안에 끝까지 남아 있는지 보는 일이다.
- 세 번째는 본문끼리 겹치거나 이미지와 충돌하는 지점이 없는지 확인하는 일이다.
- 마지막은 수정 뒤에도 18장을 처음부터 다시 렌더해 보는 일이다.
이 목록은 내용을 중복해 요약하려는 것이 아니라, 화면에서 확인할 순서를 정하기 위한 것이다. 한 번에 모든 걸 보려 하면 결국 익숙한 부분만 보게 된다. 제목, 숫자, 본문, 수정 뒤 전체 순서를 고정하면 검수의 기준점이 생긴다. 그 기준점은 다음 발표자료에도 그대로 가져갈 수 있다.
Pretendard를 바꾼 뒤 왜 전부 다시 봐야 했나?
폰트가 바뀌면 글자 모양만 달라지는 것이 아니라 줄바꿈과 폭이 함께 달라져, 기존 화면의 배치를 다시 확인해야 한다.
폰트를 Pretendard로 바꾸자 슬라이드 다섯 장이 깨졌다. 어떤 장은 숫자의 끝이 잘렸고, 어떤 장은 제목이 어절 한가운데서 꺾였다. 이 경험에서 폰트는 꾸밈 요소가 아니라 레이아웃 변수였다. 글꼴 하나를 바꾸는 일은 슬라이드 전체를 다시 조판하는 일과 같았다. 그래서 한 장이 정상으로 보인다고 멈추지 않고 18장을 전부 다시 렌더해서 봤다.
참고: 웹이나 문서에서 글꼴을 적용하는 기본 방법과 사용 가능한 글꼴 정보는 Google Fonts 개발자 문서에서 확인할 수 있다. 이 문서는 내 슬라이드의 결함을 설명하는 근거가 아니라, 글꼴 적용 자체를 별도 기술 요소로 확인하려는 참고 자료다.
검수가 끝났다는 판단은 어떻게 내렸나?
수정한 장만 확인하지 않고 전체를 다시 보는 절차까지 마쳐야, 앞선 수정이 다른 장의 배치를 건드리지 않았는지 확인할 수 있다.
이 기록에서 결론은 ‘AI가 슬라이드를 만들었다’가 아니다. 하룻밤에 만든 결과를 그대로 발표하지 않고, 만드는 역할과 의심하는 역할을 갈라 화면으로 다시 확인했다는 데 있다. 결함이 스무 개 넘게 나왔다는 숫자는 자동화가 실패했다는 뜻이 아니라, 자동화 결과도 검수 없이 통과시키면 안 된다는 경고다. 손으로 직접 편집하기 어려운 상황에서도 품질 기준을 포기할 이유는 없다. 오히려 역할을 쪼개고 확인 순서를 명시하는 방식이 더 중요해진다.
이건 좀 가다로 물어보십니다
Q. AI가 만들었으면 검수도 AI에게 맡겨도 되나?
가능하지만 제작 역할과 같은 흐름으로 보지 않도록, 검수 항목과 판단 기준을 따로 주는 편이 낫다.
Q. 한 장만 고쳤다면 그 장만 보면 되나?
이 기록에서는 폰트 교체 뒤 다섯 장이 깨졌으므로, 수정 범위를 추측하지 않고 18장을 다시 렌더해 확인했다.
Q. 화면에서 가장 먼저 볼 문제는 무엇인가?
제목의 줄바꿈, 숫자 잘림, 글자 겹침처럼 발표 중 즉시 드러나는 문제부터 확인하면 검수 순서를 잡기 쉽다.
Q. 폰트 교체는 단순한 디자인 수정 아닌가?
글자의 폭과 줄바꿈이 바뀌면 배치가 달라질 수 있으므로, 이 기록에서는 레이아웃을 다시 확인할 일로 다뤘다.
그래서 무엇을 배웠나
빠르게 만드는 일과 제대로 확인하는 일은 서로 반대가 아니다. 제작 단계를 줄일수록 검수 단계를 독립시키고, 화면에서 확인할 항목을 더 명확히 적어야 한다. 이번에는 18장의 자료와 스무 개가 넘는 결함이 그 기준을 남겼다.
이 내용은 2026년 7월 3일에 스레드에 처음 적었습니다. 발표자료를 다시 검수한 맥락을 더했습니다 → 스레드에서 원문 확인