개발자로 일하다 보면 '내 기술 블로그 하나쯤은 제대로 만들어야지'라는 욕심이 생길 때가 있습니다. 저도 처음에는 남들이 다 쓴다는 워드프레스나 티스토리를 쓰다가, 조금 더 커스터마이징하고 싶은 욕심에 직접 서버를 띄우고 데이터베이스를 연동했던 기억이 납니다. 하지만 시간이 지나면서 깨달은 건, 블로그를 운영하는 목적이 '글 쓰기'가 아니라 '서버 유지보수'로 변질되었다는 사실이었습니다. 최근 유명 테크 유튜버이자 개발자인 제프 기어링(Jeff Geerling)이 자신의 블로그를 무려 17년간 사용하던 Drupal에서 Hugo로 이전했다는 소식을 접했습니다. 이 과정에서 그가 겪은 고민과 기술적 선택은 우리가 사이드 프로젝트나 개인 블로그를 구축할 때 어떤 태도를 가져야 하는지 시사하는 바가 큽니다.
제프 기어링은 2009년부터 Drupal을 사용해 왔습니다. Drupal은 단순한 블로그 툴이 아니라, 기업급 웹사이트를 구축하기 위한 강력한 DXP(Digital Experience Platform)이자 CMS입니다. 그는 자신이 현업에서 사용하는 기술을 직접 사용해보며 익히는, 이른바 '개밥 먹기(Dogfooding)' 차원에서 이 무거운 시스템을 유지해 왔습니다. Drupal 6에서 시작해 10버전까지 업그레이드하며 수많은 마이그레이션을 거쳤지만, 결국 그는 지쳤습니다. 개인의 생각과 기술 조사를 정리하는 공간에 엔터프라이즈급 CMS를 유지보수하는 것은 배보다 배꼽이 더 큰 상황이었기 때문입니다. 복잡한 시스템을 관리하느라 정작 글을 쓸 시간은 줄어들었고, 이는 본질적인 가치를 훼손하는 일이었습니다.
그가 묘사한 Drupal 기반의 글쓰기 워크플로는 듣기만 해도 숨이 턱 막힐 정도로 비효율적이었습니다. 로컬 컴퓨터에서 Markdown으로 글을 작성한 뒤, 비공개 게시물을 생성하고 내용을 붙여넣어야 했습니다. 더 끔찍한 것은 이미지 처리였습니다. 게시물당 20~30장에 달하는 사진을 일일이 업로드하고, 본문의 적절한 위치에 HTML 태그를 삽입해야 했습니다. 발행 후에는 Ansible 플레이북을 실행해 Drupal, Nginx, Cloudflare 캐시까지 비워야 했습니다. 글을 발행하는 과정 자체가 하나의 거대한 '배포 엔지니어링'이었던 셈입니다. 물론 자동화 모듈이 있었지만, 메이저 버전 업그레이드 때마다 모듈 호환성이 깨지는 문제(Dependency Hell)를 해결하느라 또 다른 리소스를 투입해야 했습니다.
결국 그는 정적 사이트 생성기(SSG)인 Hugo를 선택했습니다. 인프라를 직접 운영하는 것을 선호하는 그의 성향상, 루비(Ruby) 기반의 Jekyll보다는 단일 바이너리로 동작하며 빌드 속도가 빠른 Go 언어 기반의 Hugo가 더 적합했기 때문입니다. 마이그레이션 후 그의 워크플로는 극적으로 단순해졌습니다. 로컬에서 Markdown 파일을 작성하고, Git 커밋과 푸시를 하면 끝입니다. PHP, MariaDB, Composer 같은 무거운 의존성 도구들을 관리할 필요도 없어졌습니다. 엔터프라이즈 환경에서는 수십 명의 사용자와 복잡한 권한 관리(RBAC)가 필요해 CMS가 필수적이지만, 혼자 글을 쓰고 발행하는 개인 블로그에는 텍스트 파일 그 자체가 가장 효율적인 데이터베이스였던 것입니다.
물론 모든 기술적 선택에는 트레이드오프가 따릅니다. 정적 사이트로 전환하면서 기존에 사용하던 댓글 시스템과 통합 검색 기능(Apache Solr 기반)을 잃게 되었습니다. 그는 댓글 기능을 위해 별도의 호스팅된 정적 댓글 시스템을 도입할 예정이며, 검색 기능 또한 Hugo 생태계 내에서 새로운 방법을 모색해야 합니다. 또한 20년간 쌓인 3,500개 이상의 게시물을 변환하는 과정에서 깨진 이미지나 링크가 발생하는 문제도 감수해야 했습니다. 하지만 그는 이러한 불편함을 감수하고서라도 '작성 경험의 개선'과 '유지보수 스트레스 해방'이라는 더 큰 가치를 선택했습니다.
제프 기어링의 사례는 우리에게 '적정 기술(Appropriate Technology)'의 중요성을 다시 한번 일깨워줍니다. 우리는 종종 개발자라는 이유로 개인 프로젝트에 오버엔지니어링을 적용하곤 합니다. 트래픽이 거의 없는 블로그에 MSA(마이크로서비스 아키텍처)를 도입하거나, 단순한 정적 페이지에 쿠버네티스 클러스터를 붙이기도 합니다. 기술 학습 목적이라면 훌륭한 시도지만, 만약 그 프로젝트의 본질이 '콘텐츠 생산'이라면 시스템은 최대한 단순하고 투명해야 합니다. 도구가 목적을 압도하지 않도록 경계하는 것, 그리고 내 상황에 가장 적합한 도구를 냉정하게 선택하는 것. 그것이 시니어 엔지니어로 성장하는 과정에서 배워야 할 중요한 덕목이 아닐까 합니다.
