발표 자료를 외주로 받아본 사람은 비슷한 경험이 있다. 파일을 열어 오타 하나를 고치려는데 슬라이드 전체가 한 장의 PNG로 박혀 있어서 글자를 클릭할 수 없다. 결국 발주자가 캡션 위에 텍스트 상자를 덧대거나, 다시 수정을 요청하는 왕복이 시작된다. doc-maker는 이 왕복을 없애는 것을 첫 번째 설계 목표로 잡았다. 주제 한 줄을 입력하면 자료조사와 구성, 슬라이드 디자인을 거쳐 파워포인트와 워드에서 글자를 직접 고칠 수 있는 산출물이 나온다. 아래는 그 과정과 품질 게이트를 실제 빌드물 기준으로 정리한 글이다.
주제 한 줄만 던졌을 때 안에서 벌어지는 일
입력은 “2분기 신규 구독 지표 요약 20장” 같은 한 줄이면 충분하다. 이 한 줄이 들어오면 파이프라인은 곧장 슬라이드를 그리지 않는다. 먼저 주제를 자료조사 단계로 넘겨 근거가 될 항목을 모으고, 그다음 구성 단계에서 20장을 어떤 논점 순서로 배치할지 뼈대를 짠다. 표지 1장, 핵심 요약 1장, 지표 상세 여러 장, 마무리 1장 같은 흐름이 이 단계에서 결정된다. 구성이 확정된 뒤에야 디자인 단계가 각 장의 레이아웃을 채운다. 순서를 이렇게 고정한 이유는 단순하다. 논점 배치가 흔들린 상태에서 예쁜 슬라이드를 먼저 만들면, 나중에 순서를 바꿀 때 디자인을 통째로 다시 손봐야 하기 때문이다.
이 다섯 칸이 파이프라인의 등뼈다. 왼쪽 끝의 한 줄짜리 주제가 오른쪽 끝의 검증된 파일로 바뀌는 동안, 각 칸은 앞 칸의 결과만 신뢰하고 자기 일만 한다. 구성 단계는 자료조사가 모은 항목이 사실인지 다시 따지지 않고, 디자인 단계는 구성이 정한 순서를 임의로 바꾸지 않는다. 이렇게 책임을 나눠두면 결과가 이상할 때 어느 칸에서 틀어졌는지 바로 짚을 수 있다.
파일을 열어 글자를 클릭했을 때 실제로 수정되는가
doc-maker의 가장 큰 차별점은 산출물이 이미지 박제가 아니라는 데 있다. 표지의 제목, 데이터 슬라이드의 숫자, 본문 문단까지 전부 파워포인트와 워드 안에서 커서를 올리고 직접 타이핑해 고칠 수 있다. 발주자가 회사명을 바꾸거나 수치를 최신값으로 갱신할 때 새로 의뢰할 필요가 없다는 뜻이다.
이 성질을 말로만 보장하지 않고 기계로 검증한다. pptx는 내부적으로 여러 XML 조각을 압축한 묶음인데, 슬라이드의 실제 글자는 <a:t> 태그 안에 들어간다. verify_pptx는 빌드된 파일을 풀어 이 <a:t> 태그에서 실제 텍스트가 나오는지 확인하고, 동시에 ppt/media 폴더에 이미지가 박혀 있지 않은지 검사한다. 글자가 이미지로 구워졌다면 <a:t>에는 아무 텍스트도 없고 ppt/media에 PNG만 잔뜩 쌓인다. 그래서 이 두 조건을 함께 보면 “편집 가능한 텍스트로 만들어졌는가"를 정확히 판정할 수 있다. 워드 쪽도 같은 원리로, verify_docx가 본문 글자가 담기는 <w:t> 태그의 실제 텍스트와 word/media의 부재를 확인한다.
급하게 렌더만 하고 넘겼다가 사고가 나는 지점
“렌더했다"와 “검수했다"는 다른 말이다. 브라우저에서 슬라이드가 그럴듯하게 보였다고 해서 pptx로 변환된 파일도 멀쩡하다는 보장은 없다. 특히 자주 터지는 사고가 슬라이드 재줄바꿈이다. HTML에서는 한 줄에 들어가던 긴 제목이 pptx 폰트 메트릭에서는 폭을 넘겨 두 줄이 되고, 그 바람에 아래 요소를 밀어내 레이아웃이 깨진다. 캡션이 슬라이드 밖으로 삐져나가거나 데이터 표가 다음 장을 침범하는 식이다.
doc-maker는 이런 조판 사고를 막기 위해 빌드 뒤에 실제 파일을 열어 육안과 자동 검사를 함께 돌린다. 텍스트가 지정한 박스를 벗어나지 않았는지, 제목이 의도치 않게 재줄바꿈되지 않았는지 같은 항목이 품질 게이트를 이룬다. 게이트를 통과하지 못하면 그 슬라이드는 폰트 크기나 줄바꿈 지점을 조정해 다시 빌드한다. 렌더 결과를 그대로 납품하지 않고 빌드물을 직접 검수한다는 원칙이 이 단계에 박혀 있다.
글자가 많아 촘촘한 화면에서 가독성이 갈리는 이유
발표 자료와 문서에서 인상을 좌우하는 건 색이 아니라 타이포그래피다. doc-maker는 본문과 제목에 Pretendard를 기본으로 쓴다. 한글과 숫자, 라틴 문자의 굵기와 자간이 한 서체 안에서 일관되게 정렬되기 때문에, 지표가 촘촘한 데이터 슬라이드에서도 숫자 열이 흐트러지지 않고 읽힌다. 폰트 하나를 잘 고르는 것만으로 “어디서 만든 티가 나는” 자료와 그렇지 않은 자료가 갈린다.
레이아웃은 표준 CSS로 짜서 Chromium PDF 엔진으로 렌더한다. 별도의 그리기 엔진을 쓰지 않고 브라우저가 실제로 웹 페이지를 그리는 방식 그대로 조판하기 때문에, 여백과 정렬이 화면에서 본 것과 PDF에서 본 것 사이에 어긋나지 않는다. CSS 기반이라 슬라이드 한 장의 간격을 바꾸고 싶을 때 규칙 한 줄만 고치면 전체에 일관되게 반영된다는 실무적 이점도 있다.
발표 자료가 아니라 긴 문서를 만들어야 할 때
doc-maker는 슬라이드만 다루지 않는다. 전자책 원고나 여러 쪽짜리 보고서처럼 장문 본문이 이어지는 문서는 docx로 빌드한다. 이때도 편집 가능성 원칙은 동일하게 적용돼서, 목차와 소제목, 본문 문단이 전부 워드에서 손댈 수 있는 텍스트로 들어간다. 발주자가 챕터 하나를 통째로 다시 쓰거나 문단 순서를 바꿀 때 원본 그대로 편집하면 된다.
문서는 슬라이드와 조판 관심사가 다르다. 슬라이드가 한 장 안에 정보를 배치하는 문제라면, 문서는 쪽을 넘어가며 흐름이 끊기지 않게 하는 문제다. 소제목이 페이지 맨 아래에 혼자 남고 본문이 다음 쪽에서 시작되는 어색한 분리, 표가 페이지 경계에서 잘리는 문제 같은 것이 문서 쪽 품질 게이트의 검사 대상이다. verify_docx는 이 흐름을 확인한 뒤, 앞서 말한 <w:t> 실제 텍스트 검증까지 함께 통과해야 산출물을 내보낸다.
이 파이프라인을 실제 의뢰에 붙였을 때
정리하면 doc-maker는 세 가지를 동시에 보장하려 한다. 첫째, 산출물은 이미지가 아니라 파워포인트와 워드에서 직접 고칠 수 있는 텍스트다. 둘째, Pretendard와 표준 CSS 조판으로 어디서 만든 티가 나지 않는 타이포그래피 품질을 맞춘다. 셋째, 렌더 결과를 그대로 믿지 않고 빌드된 파일을 열어 편집 가능성과 조판, 수치를 검증한 뒤에야 끝낸다. 이 글에 실린 이미지는 전부 SAMPLE 뱃지를 각인한 가상 예시이며 실제 의뢰물이 아니다. 실제 작업에서는 이 세 게이트를 통과한 파일만 발주자에게 전달된다.
이 프로젝트를 만드는 팀
doc-maker는 한 명의 에이전트가 아니라 역할이 나뉜 팀이 함께 만든다. 주제를 받아 자료조사·구성·슬라이드 조율의 최종 판단을 docmaker-lead가 맡고, 장문 텍스트와 전자책 작성은 document-team이, 내부에서 구성·논점 설계는 planner가, 슬라이드 디자인은 designer가, 편집 가능성과 수치 검증은 verify가 담당한다.
