▲

Jeffgeerling.com이 Hugo로 마이그레이션됨

 (jeffgeerling.com)
2P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • 2009년부터 Drupal 기반으로 운영되던 JeffGeerling.com이 개인 블로그 효율성을 위해 Hugo 정적 사이트 생성기(SSG) 로 전환됨
  • Drupal 6부터 10까지 이어진 다수의 업그레이드와 유지보수 부담이 전환의 주요 계기
  • Hugo는 Markdown 기반 작성을 지원해 기존의 복잡한 게시 절차를 단순화하고, 게시·배포 과정을 명령어 한 줄로 처리 가능
  • 마이그레이션 과정에서 이미지 링크 오류, URL 손실 등 일부 문제가 발생할 수 있으며, 댓글과 검색 기능은 추후 단계에서 복원 예정
  • 개인 개발자에게 간결한 워크플로와 유지보수 효율성을 제공하는 사례로, 정적 사이트 전환의 실질적 장점을 보여줌

Drupal에서 Hugo로의 전환 배경

  • 사이트는 2009년부터 Drupal 6으로 시작해 7, 8, 9, 10으로 단계적 업그레이드를 거침
    • 10년 이상 직업적으로 사용하던 CMS를 개인 블로그에도 적용해 왔음
  • Drupal 7에서 8로의 복잡한 업그레이드 과정 이후, 개인 블로그에 기업용 Digital Experience Platform(DXP) 을 유지하는 데 피로감이 누적됨
  • 블로그는 개인 프로젝트와 YouTube 콘텐츠 보조 공간으로 활용되고 있으며, CMS 유지보수보다 글 작성에 집중하기 위해 전환 결정

Hugo 선택 이유

  • 과거 취미 사이트를 정적 호스팅으로 이전한 경험이 있으며, 일부는 Jekyll 또는 Hugo로 변환
  • Jekyll은 GitHub Pages용으로 적합하지만, Ruby 비전문가로서 Hugo의 간단한 설정과 빠른 속도를 선호
  • Hugo는 Markdown을 기본 지원하며, 기존 작성 방식과 자연스럽게 연동됨

마이그레이션 과정과 문제점

  • 마이그레이션 작업은 GitHub 이슈 #158에서 진행 중
  • 약 3,500개 이상의 게시물과 20년치 데이터로 인해 일부 이미지 손상, 링크 오류, 리디렉션 누락 가능성 존재
  • 가능한 한 기존 URL 구조를 유지하거나 리디렉션을 추가하려 노력 중

Markdown 기반 워크플로 개선

  • 2020년부터 모든 게시물을 Markdown으로 작성
    • 이전에는 Sublime Text에서 Markdown으로 작성 후 HTML로 변환해 Drupal에 수동 업로드
  • Drupal에서는 게시물 작성 시 다단계 절차 필요
    • 본문 붙여넣기, 이미지 개별 업로드 및 삽입, 게시 날짜 수정, 캐시 초기화 등
    • DDoS 대응을 위한 Cloudflare 캐시 관리까지 포함되어 복잡한 절차였음
  • Hugo에서는 Markdown 파일 작성 후 hugo && git commit && git push 명령으로 즉시 게시 가능
  • Composer, Drush, PHP, MariaDB, Nginx 등 서버 관리 부담이 사라져 유지보수 효율 향상

향후 계획 (TODOs)

  • 댓글 기능은 2단계에서 자체 호스팅 정적 댓글 시스템으로 복원 예정
  • 사이트 검색 기능은 과거 Apache Solr 기반이었으나, 현재는 중단 상태
    • Hugo 내 검색 구현 방식을 이슈 #168에서 검토 중
  • 마이그레이션 초기에는 댓글이 비활성화되어 있으며, 이전 작업에 시간이 소요될 예정

전환의 의미

  • Drupal의 복잡한 콘텐츠 작성·관리 구조에서 벗어나, 단순하고 효율적인 정적 사이트 운영 모델로 이동
  • 개인 개발자에게 유지보수 부담 감소와 창작 집중 환경을 제공하는 실질적 사례
  • Hugo 기반 전환은 개인 블로그 운영의 지속 가능성을 높이는 방향으로 평가됨
▲
GN⁺ 4일전  [-]
Hacker News 의견들

  • 몇 년 전, 내 개인 웹사이트를 내가 직접 만든 Common Lisp 기반 정적 사이트 생성기로 옮겼음
    처음엔 850줄 정도였는데 지금은 1500줄 정도로 커졌고, 블로그 포스트, 방명록, 댓글 페이지, 태그별 RSS 피드 등 거의 모든 걸 정적으로 렌더링함
    모든 코드와 HTML, CSS를 직접 손으로 짜서 미학적인 통제력을 유지할 수 있고, 새로운 기능 추가도 빠름
    예를 들어 ‘백링크’ 페이지를 추가하는 데 40줄 정도의 CL 코드와 15분이면 충분했음
    지금은 매우 안정적이라 거의 손댈 일이 없고, 글쓰기에만 집중할 수 있음

    • 나 같은 성격은 셀프호스팅 블로그가 문제였음
      블로그 엔진을 만지작거리는 데 시간을 다 써서 결국 글을 안 쓰게 됨
      그래서 일부러 제어권이 적은 호스팅 솔루션으로 돌아갔음. 이제는 오직 글쓰기에만 집중할 수 있음
    • 나도 단일 목적의 정적 사이트 생성기의 자유로움과 안정성이 마음에 듦
      예전엔 Tclssg라는 공개 프로젝트를 운영했는데, 사용자 피드백 덕분에 문서화도 하고 기능도 많이 추가했음
      하지만 공개 프로젝트라 마음대로 구조를 바꾸기 어려웠음
      지금은 내 사이트 전용 Python(900줄) + Pandoc Lua(700줄)로 구성된 생성기를 쓰고 있음
      기술적 변천사는 내 사이트에 정리해둠
    • 나도 공감함. 내 사이트 taoofmac.com을 Hy로 포팅했다가 다시 Python으로 재작성했음
      지금은 TypeScript/Bun으로 다시 만들고 있는데, 여전히 LISP스러운 요소가 남아 있음
      SQLite와 HTML 파싱을 내장하고 네이티브로 컴파일되는 가벼운 LISP/Scheme 방언을 찾고 있음
      관련 정보는 여기에 정리함
    • 나도 같은 일을 했는데, Go로 사이트 생성기를 구현했음
      수년이 지나도 1초 이내에 전체 사이트를 빌드할 수 있음
      RSS 피드와 코드 하이라이팅 기능도 직접 넣었고, Chroma와 Blackfriday를 사용함
      Hugo를 써봤지만 너무 복잡해서 직접 구현했음
    • 정적 블로그에서 댓글은 어떻게 처리하는지 궁금함

  • 예전에 svbtle에서 Hugo로 옮겼는데, 솔직히 후회하고 있음
    테마를 포크했는데 Hugo가 자주 깨져서 유지보수에 너무 많은 시간이 듦
    지금은 사이트가 아예 빌드되지 않음
    조언하자면, 사이트를 빌드한 바이너리 버전을 소스 컨트롤에 함께 넣어두는 게 좋음

    • 어떤 소프트웨어는 굳이 업데이트할 필요가 없다는 걸 깨달았음
      정적 사이트 생성기는 보안 이슈가 거의 없으니, 필요한 기능이 없다면 옛 버전 그대로 써도 됨
      운영체제나 CPU가 크게 바뀌지 않는 한 문제없음
    • CI 설정에서 버전을 명시하면 됨
      나도 이 설정을 참고해서 버전 고정함
      작동하는 버전을 찾을 땐 이진 탐색으로 찾는 게 효율적임
    • 나는 커스텀 Docker 이미지로 해결했음
      로컬과 CI 모두 같은 Hugo 버전을 사용하니 문제 생길 일이 없음
    • 오프더셸프 바이너리를 쓸 때는 ${project}/bin/에 넣고 .gitignore 처리한 뒤, 체크섬을 SHA256SUMS 파일에 기록하면 됨
      Git LFS의 간단한 버전 같은 방식임
    • 나도 Jekyll에서 같은 문제를 겪었음
      새 컴퓨터로 옮길 때 버전 맞추기가 두렵고, 결국 PHP로 포팅 중이지만 아직 미완성임

  • Markdown으로 글을 쓰는 사람이라면 Hugo 전환이 합리적임
    나도 500개 넘는 Jekyll 포스트를 Hugo로 옮겼는데, 템플릿 문법이 가장 힘들었음
    그래도 전반적으로는 이득이었음
    전환 과정과 자동 변환 스크립트를 블로그 글에 정리했음

    • 왜 Jekyll에서 Hugo로 옮겼는지 궁금함. Jekyll로도 충분히 만족 중임

  • SSG는 정적 사이트에는 좋지만, 상호작용이 필요한 경우엔 서버가 필요함
    어차피 서버를 돌릴 거라면 Markdown을 동적으로 렌더링하는 게 더 단순함
    결국 SSG는 의존성과 깨질 요소만 늘림
    Jeff가 나중에 댓글 같은 기능을 추가하려다 후회할 것 같음
    개인적으로는 SSR 기반의 간단한 서버가 더 현실적인 해법이라 생각함

    • 하지만 방문자나 봇이 많아지면 서버가 터질 수도 있음
      정적 페이지는 이런 위험이 없고, 대부분의 트래픽은 읽기 전용임
      Jeff도 댓글 기능을 이슈에서 직접 구현하려는 듯함
    • 나도 셀프호스팅 분석 도구와 댓글 시스템을 직접 운영 중임
      Drupal 시절보다 코드 규모가 훨씬 작고 단순함
    • 정적 사이트 생성기는 오히려 의존성을 줄이는 방향임
    • 나는 정적 페이지는 SSG로, 댓글은 Common Lisp + Hunchentoot 서버로 처리함
    • 나도 사이트를 SSG로 바꿨는데 전혀 후회하지 않음. 오히려 단순할수록 좋음

  • SSG를 선택할 때의 의사결정 과정이 궁금함
    Hugo, Eleventy, Jekyll 등 주요 도구가 많고, Hugo는 특히 호환성 깨짐이 잦음
    오래된 프로젝트라면 이제는 안정성을 보장해야 한다고 생각함

    • 실제로 Hugo는 v0.146에서 템플릿 시스템을 전면 개편했음
      덕분에 내 블로그 빌드가 깨졌고, 문서도 아직 완전히 갱신되지 않음
      변경 자체는 괜찮지만, 문서가 따라오지 않는 게 문제임

  • 요즘 Pelican은 어떤지 궁금함. Python 진영에서는 Hugo와 Pelican이 양대산맥 같음
    RSS보다 ActivityPub 통합이 매력적으로 보이기도 함

    • Pelican을 쓰는데 만족함
      예전에 Nikola를 썼지만 의존성이 너무 많고 증분 빌드 불일치 문제가 있었음
      Pelican은 단순함을 유지해서 좋음
    • 나도 Pelican을 몇 년째 쓰고 있음
      문서화가 90%쯤 완성된 느낌이라 세세한 부분이 부족하지만, 기본 기능만 쓰면 훌륭함
    • Pelican에 직접 만든 플러그인을 여러 개 붙여서 사용 중임
      매달 커밋이 있어서 프로젝트가 살아 있음
    • Python을 안다면 Pelican이 가장 자연스러운 선택임

  • 나는 지금 Hugo에서 Zola로 옮기려는 중임
    Zola의 설정과 템플릿이 훨씬 직관적으로 느껴짐

    • 나도 Jekyll에서 Zola로 옮겼는데 전혀 후회 없음
      GitHub Actions로 빌드와 배포를 자동화함
    • 요구사항이 많지 않다면 Zola + gist 조합이 단순하고 잘 맞음

  • 3년째 Hugo를 쓰고 있음
    배운 점은 테마를 포크해서 직접 관리하라는 것
    서브모듈은 피하고, 업데이트는 천천히 하는 게 좋음
    댓글 기능은 여전히 까다로워 보임

    • 맞음. 테마는 결국 사이트마다 다름
      나도 Drupal 테마를 옮기려다 포기했음
      서브모듈보다 직접 포함 후 필요한 부분만 오버라이드하는 게 낫다고 생각함

  • 작년에 Hugo로 블로그를 시작했는데, 18개 포스트 중 3/4이 빌드 오류로 고생했음
    너무 불안정해서 실망스러웠음

    • 나도 Hugo에서 직접 만든 Python SSG로 옮겼음
      Hugo 방식에 익숙해지기보다 내가 아는 언어로 빠르게 구현하는 게 훨씬 편했음

  • 예전에 간단한 SSG를 직접 만들었는데, 최근엔 좀 더 체계적인 걸 찾다가 11ty를 써봤음
    하지만 Liquid 템플릿이 너무 불편했음
    JSX 기반 템플릿을 쓰고 싶었지만 11ty는 그걸 어렵게 만듦
    NextJS SSG는 기능은 많지만 너무 복잡해서 과한 느낌임
    Tempest 같은 프레임워크 위에 커스텀 SSG를 만드는 것도 고려 중임

    • Eleventy는 Mustache 같은 고전 템플릿 언어도 지원함
      나도 Punch 기반 사이트를 Eleventy로 옮겼고, 빌드 속도만 괜찮다면 Hugo보다 낫다고 느낌
      지금은 Astro로 새로 만들었음
    • 우리 스타트업의 마케팅 사이트를 NextJS에서 Astro로 옮겼는데 매우 만족함
      정적 중심이지만 필요한 경우 백엔드 로직도 쓸 수 있음
      NextJS는 단순한 사이트에 비해 너무 복잡했음
답변달기