내부 자동화 1단계 완료

Epub 로컬 변환기 Ver 1.0을 완성하다

일이 자꾸 밀린다.

오늘 저녁에서야 만들어뒀던 자체 제작 Epub 변환기를 써볼 수 있었다.

결론은 예상대로 대만족.

물론, 좌충우돌의 시간이 있긴 했다. 오늘은 빠르게 전체 틀을 잡는 건 아니고, 나도 시행착오를 겪으며 나름 세밀한 부분만 다듬는 거라서 이전처럼 gpt 5.2와 대화를 하며 작업했다.

폰트 임베딩, 어째서인지 epub로 폰트가 넘어오질 않았다. 결국 코드로 직접 임베딩 명령어를 때려 넣었다.
대화문과 본문 나누기, 대화문마다 단락 나누기 등. 이건 설정을 어떻게 하느냐에 따라서 다음 작업에도 영향을 줄 수 있는 문제인지라 선택 과정에서 시간이 좀 걸렸다
<br/> 노가다. 이건 어쩔 수 없는 부분. 로컬 변환기에서 <br/>이 과하게 박힌 문서는 에러가 날 수 있단 경고에 따라 epub로 1차 변환 후, sigil에서 직접 쓰고, 복사, 붙여넣기를 했다.
폰트와 스타일 공통 요소 점검. 미세한 부분들이 신경 쓰여서 이것도 몇 차례 삭제와 변환 생성을 반복했다.
표지를 전자책 환경에 맞춰 리사이징.

그러니 실제 앞서 codex로 설계했던 변환기 자체는 문제가 없었다. 어디까지나 이후에도 수월하게 진행할 수 있도록 오늘은 공통 요소 스타일과 폴더 구분, 폰트 고정 등에서 시간을 소요했던 것이다.

그마저도 이제는 잘 정리가 되었기 때문에 다음부터는 초안을 만들 때만 신경을 써서 마크다운 형식으로 써두면 그만이다.

마크다운이야 지금의 블로그 글도 전부 마크다운으로 쓰고 있으니 이젠 어렵지도 않다.

다음은 로컬 윤문 변환기를 꿈꿔보지만...

해보니 현실적인 걸림돌은 역시 자원이다. 로컬 LLM을 써서 작업을 해보고 싶지만, 이미 상용화된 클로드나 제미나이, GPT 등이 워낙 월등하기 때문에 로컬 LLM을 굳이 써보는 모험을 할 필요가 없긴 하다.

그럼, 왜 미련을 버리기 힘들까?

궁극적으로는 토큰을 절약하는 측면에서도 그렇고ㅎㅎㅎㅎㅎ 로컬에서 직접 운영되는 프로그램을 직접 설계한다는 게 아무래도 매력적이기 때문이다. 비교적 단순한 업무를 처리하는데 굳이 온라인 접속 상태를 매번 유지한다는 것도 번거롭고ㅎㅎㅎ

하지만, 이미 너무 잘 만들어진 LLM들이라서 어지간한 자원을 들여서는 그 모델들을 넘어서는, 아니, 그건 너무 과하고 비교해서 그래도 써볼 만한 걸 만드는 것조차 현실적으로 너무 어렵다. 비용 감당이 터무니가 없다.

나의 경우에는 기초적인 교정, 교열과 윤문을 해주는 로컬 프로그램을 만들고 싶은 마음이 간절하다. 헌데, 현실적으로는 그냥 GPT에게 여러 차례 묻는 게 훨씬 빠르고, 저렴하다...

로컬 LLM을 쓰든, 5.2 gpt나 제미나이 3.1을 쓰든, 모두가 일정 이상의 텍스르를 한 번에 밀어넣는 건 아주 바보같은 짓이다. 최대한 그럴싸한 형태로 작업이 되려면, 일반 단행본 기준 12만자 가량의 문서를 작업할 때, 한 번에 4~8천자 정도만 인식을 시키는 게 안전하다.

그러니까 한 권 분량을 작업하기 위해선 나뉘어진 파일이 대략 15개 ~ 30개 정도는 필요한 셈이다. 그런데 로컬 LLM이 그 파일 하나를 처리하는데 얼마나 걸리는가? 아주 빌어먹을 정도로 시간을 잡아먹는데... 그마저도 답변이 정상적이지 않을 수 있다는 리스크가 있으니 효율 면에서 비교가 안되는 셈이다.

게다가 직접 그런 환경을 구축하기 위해선 gpt plus 요금 기준으로 1년치 이상의 돈이 깨질 수 있다는 것도 문제다.

꼭 그런 게 아니더라도 기존에 쓰던 세부적인 툴의 성능들도 구현하려면 벽이 꽤 높다.

hwp의 맞춤법 검사를 구현한다고 해도 그만한 데이터가 내게 축적되어 있어야 구현이 가능한 법이다.

현실적으로 내가 자동 윤문기를 생각하게 된 이유는

일이 없을 땐 문제가 아니지만, 바쁜 시기에 밀려오는 원고 중 소위 '똥글'이 있다면, 전체 작업에 막대한 영향을 미치게 된다. 단순히 읽기조차 버거울 정도로 비문과 오탈자가 난무하는 글을 보면 하루 생체 리듬 자체가 크게 흔들려서 깨지니 말이다.
그래도 그런 글을 살려내야 하는 게 일이고, 일이 되어야 돈이 되므로 받아야만 하는데, 이때 당장 거슬리는 비문이나 간결하지 못한 복문만 추려내 줘도 스트레스가 크게 줄어들게 된다. 문제는 hwp도 그렇고, 부산대 한글맞춤법 검사기도 그렇고, 체크는 잘 해줄지 몰라도 자동 교정은 해주지를 않는다는 거다.
난 스트레스를 줄이기 위해 자동을 원하고, 현실은 수동이다. 열 받게도 너무 잘 만들어진 수동이다. 심지어 둘 모두 오픈소스도 아니다;;
그렇기 때문에 그것들과 그나마 비벼볼 만한 수준으로 만들려면, 오픈소스와 함께 LLM 모델의 도움을 받는 게 최선인데, 말했듯이 로컬 LLM은 그 성능이 한참 뒤떨어져 있다...

그러니 이런저런 고민과 자원의 한계 앞에서 좌절하는 것보단 그냥 마음을 내려놓고 현재 유료 모델을 최대한 이용하는 게 압도적으로 유리한 셈이다.

그렇다고 해서 현재의 내가 이 문제를 완전히 포기한 것은 아니다. 당장은 이전의 방식을 고수하겠지만, 내가 욕망하고, 내가 간절히 필요로 하는 것이니 ㅋㅋ 분명 또다른 길이 곧 열릴 거라 믿으며 ㅡ

오늘은 이만 일지 쓰기를 종료한다.