지난 1년, 20년의 조각들을 모아 에이전트형 출판ERP 만들기

[덴디]

지난 1년, 20년의 조각들을 모아 에이전트형 출판ERP 만들기

https://www.youtube.com/watch?v=P95to6YrL1k

책 한 권 세상에 내놓는 일이 겉보기와 다르게 참 손이 많이 갑니다. 기획부터 필자나 번역가 섭외하고, 1교 보고 2교 보고 인쇄소랑 배본사 챙기고, 출간 후에는 재쇄를 언제 찍어야 하나 부수 세는 일까지 끊임없이 이어집니다.

돌아보면 출판 관련 일을 한지 20년이 훌쩍 넘었습니다. 그동안 만들어서 회사에서만 쓴 크고 작은 미니 ERP만 해도 수십개 주문자동화나 도서 쇼핑몰 연동 등에 사용했습니다.

지금도 남들처럼 출판사 관리 프로그램을 월정액으로 사용중입니다. 창고가 지정한 프로그램이기 때문에 어쩔수 없는 현실이고 필요한 기능만 떼어서 중간 다리 역할을 하는 중계 프로그램을 만들어 붙여가며 어떻게든 타협을 보려고도 했고 해당업체 프로그램을 브라우저조작으로 수발주 자동화를 했습니다.

그런데 남의 손에 데이터를 맡겨두니 결국 큰 대가를 치르게 되더라고요. 믿고 쓰던 출판 프로그램 회사가 랜섬웨어에 걸려서 하루아침에 시스템이 먹통이 되기도 하고, 데이터가 날아가는 사고를 몇 차례 겪었습니다. 물론 자체 백업 프로그램이 있긴 했지만 수많은 책판매의 이력과 데이터가 한순간에 날아가는 걸 보면서 ‘아, 출판 데이터는 누구한테 기댈 게 아니라 우리가 직접 쥐고 있어야겠구나’ 뼈저리게 느꼈습니다.

그래서 결심하고 지난 1년 동안, 20년간 흩어져 있던 백여 개의 미니 ERP 조각들을 하나로 합치는 작업에 매달렸습니다.

처음에는 그저 주문 정리하고 결산이나 잘되는 단단한 관리 프로그램 하나 만들면 끝날 줄 알았습니다. 그런데 개발을 하면 할수록 늘 부딪히는 문제가 있었습니다. 업무 시스템이란 게 만들어두면 얼마 못 가 금방 삐걱거리고 낡아버린다는 점이었습니다. 특히 수 많은 거래처에 사람이 바뀌면 발생하는 일이 의외로 시스템에 영향을 미침니다. 담당자 바뀌면 시스템(판매, 마케팅, 행사)도 함께 바뀌어야 합니다.

잘 팔리던 책도 담당자가 바뀌면 어느순간 판매가 안되고 광고를 해도 진행이 안됩니다. 재미로 붙였던 부적굿즈를 줬던 책은 기독교인이었던 담당자가 싫어한다는 이유로 판매가 멎었죠. 하여간 출판은 규격대로 찍어내는 공산품이 아닙니다. 사람마다 일하는 방식이 다 다릅니다. 기획자, 편집자, 디자이너마다 고집이 있고, 같은 책이라도 상황에 따라 최선의 방법이 매번 바뀝니다. 어떤 사람은 A라는 방식으로 교정을 보고 싶어 하고, 어떤 사람은 B라는 방식으로 기획을 풀어가고 싶어 하죠. 기존의 딱딱한 ERP는 이 다양한 고집들을 전혀 품어내지 못했습니다. 시스템에 사람을 억지로 끼워 맞추다 보니 결국 안 쓰게 되거나, 개발자가 메뉴를 끝도 없이 늘리다가 프로그램 자체가 무너져버리더군요.

https://www.youtube.com/watch?v=4dKkpN4RnxU

결국 시스템이 살아남으려면, 고정된 규칙이 아니라 사람이 일하는 방식에 맞춰 스스로 변이를 일으키는 일종의 '진화론'적인 구조로 가야 했습니다. 그리고 그 중심을 잡아준 게 바로 AI 에이전트였습니다.

지금 만든 시스템은 단 하나의 방식만 강요하지 않습니다. 시장 조사나 목차 구성을 할 때 A 방법과 B 방법이 있다면, 에이전트가 각 방식대로 시뮬레이션을 돌려 결과를 뽑아줍니다. 그리고 실무진의 선택이나 실제 결과를 바탕으로 더 나은 방식이 살아남습니다. 살아남은 로직과 프롬프트는 시스템의 ‘DNA’로 남고, 도태된 방식은 자연스럽게 뒤로 빠집니다.

여기서 핵심은 썼던 자원이 그냥 버려지지 않는다는 점입니다. 실패했든 성공했든 다 잘게 쪼개서 다시 쓸 수 있는 레고 블록 같은 부품으로 남겨둡니다. 나중에 다른 프로젝트를 할 때 전혀 다른 조합으로 꺼내 쓸 수 있도록요. 1년간 170여 개의 부품을 그렇게 만들어왔고, 지금도 상황에 맞는 것들만 골라 쓰고 있습니다.

원고와 콘텐츠를 만드는 영역도 마찬가지였습니다. 외부 서비스에 의존하기 싫어서 사내 서버에 Gitea 같은 경량 오픈소스를 직접 올려서 GitBook 대용으로 구성했습니다. 글이 에이전트와 사람 사이를 오가며 다듬어지는 과정이 마치 소프트웨어 코드처럼 커밋되고 브랜치로 나뉩니다. 기획 메모부터 초교, 재교, 최종 원고까지 모든 이력이 투명하게 남고, 정제된 마크다운 텍스트는 위키나 출간용 데이터로 바로 뽑아 쓸 수 있습니다. 외부 플랫폼 정책이 바뀌든 말든 흔들리지 않는 우리만의 저장소입니다.

https://www.youtube.com/watch?v=iTn0GfJxMMs

여기에 사내에 있는 맥이나 나스, 고성능 PC들도 네트워크로 묶었습니다. 영상 편집이나 무거운 작업은 GPU가 달린 PC로 알아서 보냈다가 가져오게 만들었습니다. 기획 신간 진행 상황은 칸반 형태로 띄워두고, 전문가 섭외 리스트나 심지어 배본사 쉬는 대체공휴일까지 일정에 다 반영되게 해 뒀습니다. 도서별 판매 추이를 보면서 안전 재고 떨어지기 전에 재쇄 일정을 짚어주는 비즈니스 레이더까지 넣다 보니 데이터베이스 테이블만 180개가 훌쩍 넘어가더군요. 아마 제가 원격 디스크 관리하는 프로그램을 다모앙에 소개했던 이유도 원격에 어떤 리소스가 겹치고 버전관리가 안되는지 역으로 찾아내기 위해 만든 이야기를 올린 것도 파일에 대한 트라우마? 가 있기 때문입니다. 퇴사 직원이 업무시간에 경쟁사 일을 했었고 그 일로 소송을 하더라구요 ^^ 그래서 지워진 디스크 복구해서 증거를 제출한 기억이...

하여간 원래는 독립된 프로그램 형태로 짰는데, 계속 고치고 기능을 덧붙이다 보니 결국 웹과 서버 환경으로 통째로 돌려놓았습니다. 직원들 입장에선 본인 작업 상황이나 디스크에 중복된 파일까지 다 들여다보이니 썩 달갑지 않을 수도 있겠지만, 흩어진 자원을 한곳으로 모아 관리하려면 어쩔 수 없는 선택이었습니다.

돌아보면 지난 1년은 프로그램을 새로 코딩했다기보다, 20년간 출판 바닥에서 겪은 시행착오와 파편들을 하나의 유기체로 엮어낸 시간에 가깝습니다.

필요하다 싶은 건 일단 다 갖다 붙여놔서 솔직히 너무 많이 붙였나 싶기도 합니다. 대시보드를 보면 거의 자동으로 돌아가는 것처럼 보이지만, 결국 어떤 책을 만들지 결정하고 마지막 방점을 찍는 건 여전히 사람의 몫입니다. 시스템은 그저 만드는 사람이 온전히 책 만드는 일에만 신경 쓸 수 있게 뒤에서 묵묵히 받쳐줄 뿐입니다.

좋은 방식이 유전자처럼 시스템에 남고, 남겨진 부품들이 다음 책의 거름이 되는 구조. 완성된 프로그램이라기보다는, 매일 책을 내면서 계속 손보고 진화해 나가는 하나의 생태계를 만들어가고 있습니다.

결론은 싸게 만들수 없습니다.

ㅠㅠ 그냥 ERP 있는거 쓰세요 ㅠㅠ

https://argo9.com