어느 날 지인으로부터 자기 블로그의 어떤 글을 추천 받았다. 추천받은 글을 읽기 전에, 그 지인이 작성한 몇 개의 글을 둘러보았다. 얼핏 읽어봐도 상당한 지식과 내공이 엿보였다. 게다가 필력까지.
하지만 문제는, 내게는 재미가 없었다. 그것이 좋은 글이란 것을 알면서도 말이다. 문득 '내 블로그도 마찬가지가 아닐까' 하는 생각이 들었다. 나는 내 생각을 나름 진지하게 남기지만, 과연 그것이 독자에게도 와닿을까?
미래의 나를 독자로 상정한 블로그이긴 하지만, 먼훗날 내 가족과 주변 사람들에게도 읽힐 수 있다는 마음은 블로그를 시작했을 때부터 있었다.
그 점을 고려해보면 비록 내 이야기라고 하더라도 좀 더 독자 친화적으로 쓸 필요가 있다고 판단했다. 그리고 무엇보다 이제까지 쌓인 글들을 정리할 필요를 느꼈다.
다음 순서로 진행하기로 했다.
전략을 수행하기 위해 아래의 부수 작업이 필요했다.
요즘 많은 블로그가 마크다운(md) 에디터를 쓰는 것에 반해, 내 블로그는 Quill이라는 에디터를 사용한다. 이 에디터를 사용하면, 내가 쓴 글이 데이터베이스에 html 형태로 저장된다. 이런 에디터를 Rich Text 에디터라고 하는데, 마크다운과 달리 폰트, 글자 크기, 글자 색깔, 정렬 등을 자유롭게 정할 수 있다는 장점이 있다.
하지만 AI는 html 문서보다 마크다운 문서를 더 쉽고 빠르게 이해한다. 게다가 나는 글자에 색을 입히거나 정렬을 요란하게 하는 것을 싫어해서, 어차피 Rich Text 에디터를 쓸 필요도 없다.
따라서 각각의 글을 채점하기 전에 우선 모든 글을 html 형식에서 마크다운 형식으로 바꾸기로 했다. 이 과정에서는 파이썬 스크립트를 이용했다. 파이썬 스크립트 작성 시 주의한 점은 다음과 같다.
이외에도 내가 유튜브 영상을 삽입했거나, 목록을 여러 계위로 작성했다면(i.e. sub-bullets of sub-bullets of sub-bullets...) 그 부분도 고려했어야 마땅하다. 하지만 다행히 그런 경우가 없었다.
특이사항이 또 있다. 만약 문장의 시작점에 숫자와 구두점이 들어가면, 마크다운 문서에서는 무조건 숫자 목록으로 인식한다. 예를 들어 어떤 문장이 "2018. 10. 19.에 쓴 글에 따르면..."처럼 시작하면, 마크다운에서는 이 문장을 숫자 목록으로 표현한다. 그래서 모두 "2018-10-19에 쓴 글에 따르면..."으로 고쳐줘야 한다.
다음 단계는 각 글에 점수를 붙이는 것이다. 앞 단계에서 변환한 마크다운 문서 수백 개를 깃헙에 올려두고, 그 깃헙 레포지토리를 Claude Code와 연결했다. 그 다음 reviewer라는 에이전트를 만들었다. 이 때 가이드를 자세히 주지 않았는데, 이게 나중에 품질 이슈로 이어졌다. 앞서 언급했듯 글의 매력도와 상관 관계가 높은 속성들과 속성별 가중치를 고려해서 평가해달라고 했다.
그 후, 대략 700개 정도 되는 글에 대해 점수를 매겨달라고 요청했다. 생각보다 토큰이 많이 들지 않았다. 7만 토큰 밖에 쓰지 않았고, 아마 3천 원도 안 쓰였을 것이다. 하지만 점수가 내 직관과 일치하지는 않았다. 가장 높은 점수를 받은 글을 몇 개 읽어보았는데, 교훈적이거나 반직관적이긴 해도, 정말 잘 쓴 글이라고 느끼지는 않았다. 이유가 뭘까?
토큰을 절약하기 위해 글 하나 당 30초 이내로 평가해달라고 했는데, 그래서 대충대충 훑어본 게 아닐까 싶다. 그리고 앞에 썼듯 reviewer 에이전트를 만들 때 가이드를 자세히 주지 않아서 더욱 그랬다.
고쳐 쓰는 거야 짬 날 때 하면 되는데, 그 과정을 어떻게 편하게 할 수 있을까? 이 과정은 아직 진행 중이지만 아래 대략적으로 남겨둔다. (구현 후기는 다음 글에서)
우선 블로그 작성자의 권한으로 로그인하면, 내가 쓴 글들의 점수가 제목 옆에 보이도록 하고자 한다. 그리고 점수가 낮은 것들을 클릭해서 짬날 때마다 고쳐 쓰려고 한다. 오래 전에 쓴 설익은 글은 그 자체로 소장할 가치가 있기 때문에, 원본은 남겨두고 글의 상단에 REMASTER 같은 느낌으로 글을 써보려고 한다. 상대적으로 최근에 쓴 글(5년 이내)은 지우거나 합치는 방법도 고려해볼 생각이다.
뻔한 얘기지만 AI의 힘을 다시 한 번 느꼈다. 특히 Claude Code 등장 이후, 걸어다니면서 휴대전화로 일을 시킬 수 있게 되었다. 구현 후기에서 (hopefully) 더 자세히 쓰겠지만, 이번 점수 할당 작업과 더불어 블로그 리뉴얼도 진행했다. 에디터를 마크다운 기반으로 바꾸고, 기술 스택도 변경하기로 결심한 것이다. 이 과정에서 정말 많은 것을 느꼈다.
내가 기억하기로... 이 블로그는 처음에는 React + Node.js로 만들었다. 아마 2019년쯤이었을 거다. 그 다음에는 Next.js로 한 번 고쳐 쓰지 않았을까 싶다. (아닌가?) 그리고 2023년쯤, 감도 살리고 재미도 느낄 겸 SvelteKit으로 다시 만들었다. 이 때 SvelteKit에 대해 불만이 많았다. 딱히 편하지도 않고... 유행을 주도하는 개발자들이 너무 어려서 생긴 hype는 아닐까? 하는 생각도 해봤다. 가만 생각해보면, 무림의 고수들이 사용하는 기술을 조사해보면 PHP가 얼마나 많을 것인가. SvelteKit보다 많지 않을까?
아무튼, 이번에는 회사 직원들이 사용하는 기술 스택에 대한 이해도를 높일 겸, Kotlin으로 백엔드 로직을 모두 옮기고, Next.js로 클라이언트 코드를 짜보기로 했다. 정확히는, 내가 짜는 게 아니라 AI에게 그 일을 시키기로 했다.
결과는 놀라웠다. 마이그레이션 플랜, 작업 플랜을 스스로 세우더니 30여 개에 달하는 마일스톤을 쉬지 않고 작업해냈다. 그리고 TDD approach를 살려서 진행해달라고 했더니, 수백 개의 테스트를 만들고 모두 PASS 하기까지 했다.
그렇게 단 하루만에 웹사이트가 완성됐는데... 그 놀라운 과정은 다음 글에 적어보려고 한다. 그 글을 적을 때쯤엔 이미 이 블로그가 많이 바뀌어 있을 것 같다.