·약 9분 읽기
지난 포스팅에서 잠시 언급했듯, 내가 일하는 출판사는 프로그래밍 도서를 주로 내왔다. AI가 코드 예제까지 즉석에서 뽑아 주는 시대가 되면서, 우리 같은 소규모 IT 전문 출판사는 타격이 컸다. 해외 대형 출판사들이 시도한 구독 모델이나 라이브 북 방식은 사례 조사를 해 봐도 우리 규모에는 맞지 않았다. 현실적으로 손댈 수 있는 옵션은 많지 않다는 결론에 도달했고, 대표님과 공유한 뒤 방향을 이렇게 잡았다. 출판 과정을 더 빠르고 덜 낭비하게 바꾸고, 독자에게는 더 편한 형태로 콘텐츠를 전달하는 것.
그 첫걸음이 교정 자동화였다. 맞춤법, 오탈자, 띄어쓰기, 어미 통일, 캡션 형식 맞추기처럼 반복적이지만 시간이 많이 드는 작업을 로컬에서 돌릴 수 있는 프로그램을 만들었다.
그동안 여러 방식으로 AI 교정을 시도해 봤다. 결과는 늘 애매했다. 긴 원고를 통째로 올리면 LLM 특성상 빠뜨리는 구간이 생기고, 돌려받는 결과는 원문에 바로 반영되지 않는 엑셀 목록이었다. 사람이 일일이 위치를 찾아 확인하고 붙여 넣어야 했다. 수정 근거도 모델이 학습한 일반 기준에 가까워서, 출판사 내부 규칙과 맞지 않는 경우가 잦았다. 가끔은 원문 뉘앙스를 바꿔 버려서, 문장 전체 톤이 달라지기도 했다. AI가 무능하다는 뜻은 아니다. 다만 단락마다 붙여 넣으며 전면 교정을 맡기기에는 비효율적이고, 편집자 업무 방식과도 맞지 않았다.
그래서 범위를 좁혔다. AI가 잘하는 쪽은 창작이 아니라 반복이다. 맞춤법(국립국어원 표준국어대사전 기반), 띄어쓰기, 오탈자, 어미 통일만 처리하도록 설계했다. 결과물은 두 가지다. MS Word 변경 추적이 켜진 수정본 한 파일, 변경 내역과 근거를 정리한 엑셀 시트 한 파일. 편집자는 의심되는 부분만 골라 확인하면 된다. 화려한 문장 다듬기는 사람이, 규칙에 맞는 기계적 교정은 프로그램이 맡는 구조다.
이 작업을 비개발자인 내가 혼자 끝낼 수는 없었다. 다만 방향을 잡고, 테스트하고, 버그를 짚어 주는 역할은 할 수 있었다. 순서는 단순했다.
블로그를 직접 만들고, 게임도 배포해 본 경험이 있었지만, 교정 도구는 웹 AI에 매달려 하던 방식과 달랐다. 로컬 프로그램으로 돌리니 속도와 통제권이 확실히 달랐다. 만드는 데 걸린 시간은 두 시간 남짓이었다. 아직 못 찾은 버그는 있을 수 있지만, 한 권 교정할 때마다 줄어드는 시간은 체감된다.
기쁘기도 하고 씁쓸하기도 하다. 사람들이 왜 프로그래밍 책을 사지 않는지는 이제 너무 잘 안다. 그런데도 출판 현장에서 줄일 수 있는 낭비는 줄여야 한다. 이 도구가 만능은 아니다. 문장을 살리는 일은 여전히 사람 몫이다. 다만 반복 교정에 쓰이던 시간을 아껴, 그만큼 원고와 독자에게 쓸 여유를 되찾는 쪽에 가깝다. 소규모 출판사가 살아남는 길이 거창한 플랫폼 전환만은 아니라는 걸, 이번에도 몸으로 확인했다.
