이번 편은 자랑이 아닙니다. 사고 이야기입니다.
만들어둔 전자책을 열었는데 책이 비어 있었습니다.
"전자책 내용이 하나도 없다"
저희 순서는 이렇습니다. 제가 작업을 끝내면 제가 먼저 훑어보고, 그다음 아내에게 본격적인 검수를 넘깁니다. 아내 시간을 아끼려는 거지요.
그날 한 일은 별거 없었습니다. 전자책 판권에 가격 고치고, 표지 첫 페이지 배경색 손보고, 새로 빌드했지요. 빌드는 성공이라고 나왔고 파일 크기도 멀쩡했습니다. 32MB. 정상입니다.
맥에서 전자책 검수는 도서 앱으로 합니다. 절차가 좀 번거로워요. 먼저 앱에 들어 있던 예전 파일을 지우고, 새 파일을 넣고, 로딩이 끝날 때까지 기다립니다. 파일이 32MB나 되니 한참 걸립니다.
그렇게 기다려서 책을 열었는데.
제목만 있고 내용이 하나도 없었습니다.
20개 챕터가 전부 그랬습니다. 사진 47장도 통째로 사라졌고요. 나중에 물어보니 챕터 하나가 871바이트짜리 껍데기였다더군요. 제목 한 줄 말고는 아무것도 없었던 겁니다.
처음에는 그냥 황당했습니다. 로딩이 덜 됐나 싶어 다시 열어봤고요.
그러다 화가 났습니다. AI가 작업이 잘됐다고 자랑스럽게 말했거든요. 초록색 체크 표시까지 붙여서요. 그 말을 믿고 저는 로딩을 기다리고 있었던 겁니다.
그런데 냉정하게 따져보면 AI도 몰랐을 겁니다. 파이썬 프로그램을 짜서 돌린 것뿐이고, 프로그램은 에러 없이 끝났으니까요. 결과물을 따로 열어보지 않는 한 알 방법이 없습니다. 저한테 거짓말을 한 게 아니라, 둘 다 확인을 안 한 거지요.
원고가 95KB에서 1.9KB가 되어 있었습니다
전자책이 이상하면 원고부터 봐야지요. 여기서 등이 서늘해졌습니다.
원고 파일부터 확인해보라고 했습니다. 돌아온 답이 이랬어요. 95,289바이트여야 하는데 1,877바이트.
20개 챕터, 28,206자가 통째로 날아가 있었어요. 남은 건 앞부속이랑 목차뿐. 전자책이 빈 게 문제가 아니라 원고 자체가 죽어 있는 상황이었습니다. 아내가 쓴 원고요...
범인은 제가 만든 빌드 스크립트였습니다
원고를 건드릴 만한 코드를 전부 뒤져보라고 했습니다. 전자책 빌더 맨 끝에 이런 게 있더군요.
파싱한 결과를 원고 파일에 다시 저장하는 코드. 원고를 읽어서 정리한 다음, 그 결과를 원본 자리에 덮어쓰고 있었습니다. 언제 왜 넣었는지 기억도 안 납니다.
한동안 멀쩡하다가 하필 그날 터진 이유가 있었어요. 며칠 전 목차에서 "1화" "2화" 같은 번호를 빼달라는 요청을 받고 제목 출력 형식을 바꿨는데, 공교롭게도 이 되쓰기 코드가 같은 형식을 쓰고 있었습니다.
원고 파서는 01화 정말 가는 거야? 같은 줄을 찾아 챕터를 구분합니다. 그런데 되쓴 원고엔 번호가 빠져 정말 가는 거야?만 남았지요. 다음 빌드는 챕터를 하나도 못 찾습니다. 본문 전체가 앞부속으로 흘러가고, 그 빈 결과를 또 원고에 저장합니다.
한 번 돌리는 걸로 끝장이 났습니다
전자책 빌더는 애플북스용과 일반 리더용을 만드느라 연달아 두 번 돕니다. 1회차가 챕터 번호를 지우고, 2회차가 그 원고를 읽어 통째로 무너뜨렸어요. 두 번 다 초록색 체크 표시를 찍으면서요.
제일 무서웠던 건 조용했다는 겁니다
이 사고에서 가장 서늘했던 건 아무 경고도 없었다는 점입니다.
에러 안 났습니다. 두 번 다 성공했다고 나왔어요. 파일 크기도 32MB로 멀쩡했고요. 폰트랑 표지가 그대로 들어 있었으니 크기만으로는 티가 안 납니다. 화면에 뜬 것만 봐서는 알 도리가 없었습니다.
제가 도서 앱에 넣어 열어보지 않았다면 그대로 아내에게 넘어갔을 겁니다. 아내도 안 열어봤다면 빈 책이 서점에 올라갔을 거고요. 생각만 해도...
그런데 그 확인이라는 게 사람 손으로 하기엔 번거롭습니다. 앞에 적었듯이 예전 파일 지우고, 32MB를 밀어 넣고, 로딩 기다리고. 한 번 고칠 때마다 이걸 해야 하니 자꾸 건너뛰고 싶어집니다. 그러다 한 번 놓치면 오늘 같은 일이 나는 거지요.
그리고 똑같이 한 번 더 당했습니다
여기까지 쓰고 나서 저는 배웠다고 생각했습니다. 그런데 아니었어요. 몇 주 뒤에 판박이로 한 번 더 당했습니다. 이번에는 실제로 책이 나간 다음이었고요.
종이책에는 조판 검사기를 붙여뒀습니다. PDF를 만들고 나서 그걸 다시 읽어 사진이 판면 밖으로 넘쳤는지 검사하고 스스로 고치는 장치예요. 3편에 적은 그 반복 작업입니다.
돌릴 때마다 화면에 이렇게 떴습니다. 결함 0건. 몇 번을 다시 뽑아도 0건이었어요. 그래서 안심하고 교보에 올렸습니다. 승인도 났고요.
그런데 승인이 난 뒤에 알았습니다. 사진 세 장이 재단선을 넘어가 있었습니다. 그대로 인쇄하면 사진 아랫부분이 잘려 나가고, 한 쪽은 쪽번호 자리까지 사진이 덮고 있었습니다.
검사기를 뜯어보라고 했더니 이런 게 나왔습니다. 이 검사기는 계획한 사진 수와 실제 사진 수가 안 맞으면 검사를 통째로 건너뛰게 되어 있었습니다. 그리고 건너뛴 결과가 화면에는 결함 0건으로 찍혔고요.
수가 안 맞은 이유는 어이없을 만큼 사소했습니다. 19화에 사진 두 장을 나란히 놓은 데가 있는데, 그걸 한 장으로 세고 있었습니다. 계획 46장, 실제 47장. 딱 한 장 차이로 검사기 전체가 멈춰 있었던 겁니다.
또 같은 구조였습니다.
전자책 때는 "빌드 성공"이 결과물이 멀쩡하다는 뜻이 아니었고, 이번에는 "결함 0건"이 문제가 없다는 뜻이 아니었습니다. 둘 다 확인을 못 했다와 문제가 없다가 같은 화면으로 나왔습니다.
더 민망한 건 그다음입니다. 사고가 난 뒤에야 검사기를 믿지 말고 따로 처음부터 전부 검사해보라고 시켰는데, 그게 몇 분 안 걸렸습니다. 재단선을 넘은 사진, 해상도 모자란 사진, 원고와 본문 대조까지 한꺼번에요.
진작 시켰으면 됐을 일입니다. 검사기가 있으니 됐다고 생각한 게 화근이었어요. 검사기를 믿으려면 검사기부터 검사했어야 했는데 말입니다.
왜 검증을 안 시켰을까
사고가 난 뒤에 스스로 물어봤습니다. 이 확인을 왜 매번 내 손으로 하고 있었을까. 빌드가 끝날 때 알아서 확인하게 시켜뒀으면 될 일인데요.
답은 토큰이었습니다.
2편에서 적었듯이 저는 문단 나누기를 하면서 토큰을 크게 데였습니다. 원고를 몇 번이나 통째로 읽히다가 1주일치를 다 써서 5일을 손 놓고 있었거든요. 그 뒤로 토큰을 아끼는 게 습관이 됐습니다.
그래서 "빌드해줘" 하고 거기서 끊었습니다. 확인까지 시키면 그만큼 더 나가니까요. 결과물은 제가 눈으로 보면 되지, 하고요. 아끼려던 습관이 사고를 불렀습니다.
그런데 따져보면 확인에 드는 토큰은 얼마 안 됩니다. 파일 크기 비교하고 첫 장에 글자가 있는지 보는 정도인데, 원고를 통째로 읽히는 것과는 비교가 안 되지요. 저는 비싼 작업과 싼 작업을 구분하지 못하고 뭉뚱그려 아끼고 있었던 겁니다.
지금은 아예 지침에 박아뒀습니다. 빌드가 끝나면 최소한 이 둘은 확인한다.
하나, 파일 크기가 예상 범위인가. 원고가 95KB에서 1.9KB가 된 걸 이때 잡습니다.
둘, 첫 장에 실제로 내용이 들어 있는가. 제목만 남은 껍데기를 이때 잡습니다.
시키는 쪽에서 이걸 매번 말하는 것보다, 지침에 적어두고 알아서 하게 만드는 편이 확실합니다.
AI에게 일을 시킬 때 "했다"와 "됐다"는 다른 말입니다. 프로그램이 에러 없이 끝난 것과 결과물이 멀쩡한 것은 별개예요. 그 사이를 메우는 건 결국 사람 몫이거나, 사람이 미리 시켜둔 검증 몫입니다.
살아난 이유
다행히 복구가 됐습니다. 운이 좋았어요.
문단 나누기 작업을 할 때 원본 백업을 두고 거기서 결정적으로 다시 만들어내는 구조로 짜뒀거든요. 어떤 문단을 어떻게 묶고 쪼갤지가 코드에 명세로 남아 있어서, 백업에서 다시 돌리면 같은 결과가 나옵니다.
돌려보니 404문단, 3~5줄 69%, 6줄 이상 1개. 파손 전 수치와 정확히 같았습니다. 그제야 숨이 쉬어지더군요.
정답지도 하나 있었습니다. 파손 5분 전에 만들어진 인쇄용 워드 파일. 여기서 문단을 전부 뽑아 복구본과 글자 단위로 대조했습니다. 차이는 딱 두 군데(제목 물음표, 마지막 줄 쉼표)였고 다시 넣었습니다.
도구를 바꾼 이야기
1편에서 안티그라비티로 시작했다가 클로드로 갈아탔다고 했지요. 2주가 넘게 걸린 그 이야기입니다.
처음엔 제 탓인 줄 알았습니다. 제가 설명을 못 해서 엉뚱한 게 나오는 거라고요. 그래서 더 자세히 적고, 더 잘게 쪼개서 시켰습니다. 그래도 마찬가지더군요.
제일 답답했던 건 판권을 만들 때였습니다.
책 맨 뒤에 들어가는 발행 정보 말입니다. 저는 "전작과 똑같은 형식으로 만들어달라"고 했습니다. 시리즈니까요. 그러려면 전작 PDF를 열어서 어디에 무엇이 어떤 크기로 놓였는지를 알아내야 합니다.
그런데 PDF에서 글자만 뽑아내면 레이아웃은 안 나옵니다. 무슨 글자가 적혀 있는지는 알아도, 그게 어디에 어떤 간격으로 놓였는지는 모릅니다. 디자인은 글자 목록이 아니니까요.
여기서 막혔습니다. PDF를 그림으로 바꿔서 재보면 되는데, 저도 그 생각을 못 했고 안티그라비티도 그 생각을 못 했습니다.
그래서 제가 어떻게 했냐면, 눈으로 본 디자인을 말로 풀어서 설명했습니다. "제목이 위에 있고 그 밑에 한 줄 띄고 발행일이 있고 왼쪽 정렬이고 글자는 작고..." 이런 식으로요. 그림을 말로 옮기는 일이 얼마나 답답한지 해보시면 압니다. 설명하면 다르게 나오고, 다시 설명하면 또 다르게 나오고.
결국 아내가 쓰던 클로드로 옮겼습니다. 이 편에서 원고를 날린 그 도구입니다.
같은 걸 시켜봤더니 전작을 뜯어보는 방식이 달랐습니다. 글자만 뽑는 게 아니라 좌표를 재고, 크기를 재고, 여백을 계산해서 가져오더군요. 2편에서 적은 판형 실측이 바로 그겁니다. 제가 말로 설명할 필요가 없어졌습니다.
옮기고 나서 든 생각은 하나였어요. 왜 진작 안 했을까.
그런데 도구를 바꿨다고 사고가 안 나는 건 아니었습니다. 이 편에서 다룬 원고 소실은 클로드로 옮기고 한참 뒤에 일어난 일이거든요. 그때 짜인 코드가 나중에 터진 겁니다.
여기서 배운 것
도구가 좋아지면 실수가 줄어드는 게 아니라 실수의 종류가 바뀝니다. 안티그라비티 때는 "시킨 걸 못 알아듣는" 문제였다면, 그다음은 "시킨 건 잘하는데 시키지 않은 것까지 하는" 문제였어요. 원고를 되쓰는 코드가 딱 그랬습니다. 아무도 그걸 만들어달라고 한 적이 없거든요.
고친 것, 그리고 배운 것
되쓰기 단계를 통째로 지웠습니다. 그리고 왜 지웠는지 코드에 길게 적어두라고 시켰어요. 나중에 누군가 다시 넣지 않도록요. 그 누군가는 아마 저겠지요. 정확히는, 제가 시켜서 그렇게 될 테고요.
교훈은 한 줄입니다. 빌드 스크립트는 자기 입력을 절대 고쳐 쓰면 안 된다. 출력 형식 한 번 바꾸는 순간 입력이 조용히 오염됩니다.
그리고 하나 더. 빌드 끝날 때마다 원고 파일 크기가 그대로인지 확인하는 버릇이 생겼습니다. 성공 메시지는 아무것도 보증해주지 않더군요.
다음 편은 접히는 표지 만들기입니다. 날개 달린 표지는 앞뒤 표지에 책등이랑 날개까지 한 장에 펼쳐 그려야 합니다. 이것도 만만치 않았어요.
