1. 이사 목적
- 이전부터 하고 싶었으나 염두가 안남.
- 그러는 동안 글이 640개 가량으로 늘어남.
- 홈서버에 워드프레스를 직접 호스팅하게 되면서 이사를 결심함.
2. 이사 방법
처음에는 워드프레스 플러그인을 찾아봤다.
Github에도 찾아봤고, 그런데 마음에 들지 않음.
조금씩 다 부족함.
몇가지는 빼고 몇가지는 보존하고 싶었다.
티스토리만의 CSS, HTML은 제거하고 순수한 데이터만 남기고 싶었음.
포스팅 개시일, 수정일은 보존하고 싶었고.
티스토리는 장차 폐쇄할거라 이미지를 WordPress로 옮겨야함.
카테고리, 태그도 최대한 유지하고 싶다.
이사하면 내부 참조 링크도 깨진다.
따라서 자동으로 바꾸거나 최소한 수동으로 변경할 수 있도록 추적해야함.
그렇다 엄청 요구사항이 굉장히 까다롭다.
요구사항이 까다로운 남자, 그것이 나다.
3. 개발할 결심
결국 직접 개발하기로 결정함.
가. WXR
처음 설계하기로는 티스토리 블로그를 크롤링하여 WXR 파일을 생성토록 설계했다.
WXR로 만들면 이미지를 직접 다운로드 및 업로드하지 않아도 된다고 파악했기 때문이었다. (이 부분의 오류가 있음을 나중에 가서 알게 됐습니다.)
이를 위해서 WXR을 생성 로직을 직접 구현해야 했다.
나. 데이터 정제
이번 프로젝트에서도 HTML을 크롤링하고 Markdown으로 변환해야 했다.
그래서 Notion2WordPress에서 사용하면서 익숙해진 라이브러리를 그대로 사용하기로 했고, 따라서 언어는 TypeScript를 사용하기로 했다.
순수한 데이터만을 원했기 때문에 HTML을 크롤링해서 Markdown으로 변환하고 이를 다시 HTML로 변환하는 과정을 통해서 강제로 불필요한 태그와 속성들을 제거하려고 했다.
HTML의 Markdown으로 변환하기 위해서 turndown이라는 오픈소스 라이브러리를 활용했고, 다시 Markdownd을 HTML로 변화하기 위해서 marked라는 오픈소스 라이브러리를 사용했다.
다. 병렬처리
600개가 넘는 글들을 빠르게 처리하기 위해서 병렬처리로 성능을 향상시킬 필요가 있었다.
이번에는 Notion2WordPress와는 다르게 배치 단위로 묶기보다는 p-queue라는 라이브러리를 사용하여 병렬처리를 구현하기로 했다.
여러 글을 동시에 처리하기에 프로세스 큐를 사용하는 것이 더 적합하다고 판단했다.
라. 내부 링크 추적
티스토리 포스트 속에는 다른 포스트를 가르키는 내부 링크가 있다.
600개를 다 일일이 뒤저가며 내부 링크를 찾을 수 없었기에, 자동으로 내부 링크를 감지하고 기록하도록 했다.
업로드가 끝난 후 수동으로 바꿀 생각인데 목록이 있다면 훨씬 편할거라 생각했기 때문이다.
4. 재설계
한 번 갈아엎었다.
기존 계획은 WXR 파일을 생성해서 WordPress Importer Plugin을 활용할 예정이었다.
WXR을 사용하면 이미지를 다운로드 및 업로드해야 하는 부담이 없다는 GPT의 대답을 믿었던 탓이다.
WXR을 사용하더라도 이미지는 별도의 작업을 거쳐야 자동으로 업로드된다.
다만, 직접 구현하는 난이도가 생각보다 너무 높아졌다.
PHP로 작성된 export.php를 리버스 엔지니어링하려고 시도했지만 REST API를 사용하는 것에 비하여 구현의 난이도, 안정성, 유지보수성 등 어느 하나에서도 장점이 없었다.
과감하게 WXR 대신 API를 사용하기로 결정했다.
앞서 개발한 Notion2WordPress를 참고하여 다시 설계하기 했다.
이 과정에서 상당히 많은 시간을 PRD를 수정하는데 써야했다…. 아 피곤하다.
하는 김에 실패한 포스트만 보여주거나, 다시 시도하는 기능을 추가하고, 중간에 작업이 비정상적으로 종료될 것을 고려하여 이어서 작업하는 기능도 추가했다.
5. OpenCode Skill 활용
이번엔 spec-kit을 변형하여 커스텀된 OpenCode Skill을 사용해 개발함.
해당 Skill만 만드는데 일주일이 걸렸다.
커스텀 명령어로 만드는 것보다 스킬로 만드는 것이 취지에 더 부합하고, 토큰 소비도 줄일 수 있을 것 같았다.
꽤나 안정적으로 동작했다.
개발자와의 상호작용을 늘리고, TDD도 강제했다.
느린 것 같지만 빨랐다.
읽고 검토해야 하는 코드가 많아서 피로도는 높았다.
다만 확실하게 Agent를 통제하기 쉽다.
잘못된 방향으로 가도, 즉시 바로잡을 수 있다.
이번 경험을 통해서 앞으로의 개발은 에이전트가 필수라는 것을 그리고 그 시점이 다 왔음을 느꼈다.
이제는 무조건 잘 써야한다.
6. 개발 마무리
목요일 새벽이 되서야 개발이 끝났다.
죽을 것 같다.
결과물은 아주 만족스럽다.