# Jeffgeerling.com이 Hugo로 마이그레이션됨 > Clean Markdown view of GeekNews topic #25587. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25587](https://news.hada.io/topic?id=25587) - GeekNews Markdown: [https://news.hada.io/topic/25587.md](https://news.hada.io/topic/25587.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-06T05:33:20+09:00 - Updated: 2026-01-06T05:33:20+09:00 - Original source: [jeffgeerling.com](https://www.jeffgeerling.com/blog/2026/migrated-to-hugo/) - Points: 2 - Comments: 1 ## Topic Body - 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](https://github.com/geerlingguy/jeffgeerling-com/issues/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단계에서 자체 호스팅 정적 댓글 시스템으로 복원 예정 - 관련 작업은 [GitHub 이슈 #167](https://github.com/geerlingguy/jeffgeerling-com/issues/167)에서 진행 - **사이트 검색 기능**은 과거 Apache Solr 기반이었으나, 현재는 중단 상태 - Hugo 내 검색 구현 방식을 [이슈 #168](https://github.com/geerlingguy/jeffgeerling-com/issues/168)에서 검토 중 - 마이그레이션 초기에는 댓글이 비활성화되어 있으며, **이전 작업에 시간이 소요될 예정** ### 전환의 의미 - Drupal의 **복잡한 콘텐츠 작성·관리 구조**에서 벗어나, 단순하고 효율적인 **정적 사이트 운영 모델**로 이동 - 개인 개발자에게 **유지보수 부담 감소와 창작 집중 환경**을 제공하는 실질적 사례 - Hugo 기반 전환은 **개인 블로그 운영의 지속 가능성**을 높이는 방향으로 평가됨 ## Comments ### Comment 48722 - Author: neo - Created: 2026-01-06T05:33:20+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46487498) - 몇 년 전, 내 개인 웹사이트를 내가 직접 만든 **Common Lisp 기반 정적 사이트 생성기**로 옮겼음 처음엔 850줄 정도였는데 지금은 1500줄 정도로 커졌고, 블로그 포스트, 방명록, 댓글 페이지, 태그별 RSS 피드 등 거의 모든 걸 정적으로 렌더링함 모든 코드와 HTML, CSS를 직접 손으로 짜서 미학적인 통제력을 유지할 수 있고, 새로운 기능 추가도 빠름 예를 들어 ‘백링크’ 페이지를 추가하는 데 40줄 정도의 CL 코드와 15분이면 충분했음 지금은 매우 안정적이라 거의 손댈 일이 없고, 글쓰기에만 집중할 수 있음 - 나 같은 성격은 **셀프호스팅 블로그**가 문제였음 블로그 엔진을 만지작거리는 데 시간을 다 써서 결국 글을 안 쓰게 됨 그래서 일부러 제어권이 적은 호스팅 솔루션으로 돌아갔음. 이제는 오직 글쓰기에만 집중할 수 있음 - 나도 단일 목적의 정적 사이트 생성기의 **자유로움과 안정성**이 마음에 듦 예전엔 Tclssg라는 공개 프로젝트를 운영했는데, 사용자 피드백 덕분에 문서화도 하고 기능도 많이 추가했음 하지만 공개 프로젝트라 마음대로 구조를 바꾸기 어려웠음 지금은 내 사이트 전용 Python(900줄) + Pandoc Lua(700줄)로 구성된 생성기를 쓰고 있음 기술적 변천사는 [내 사이트](https://dbohdan.com/about#technical-history)에 정리해둠 - 나도 공감함. 내 사이트 [taoofmac.com](https://taoofmac.com)을 Hy로 포팅했다가 다시 Python으로 재작성했음 지금은 TypeScript/Bun으로 다시 만들고 있는데, 여전히 **LISP스러운 요소**가 남아 있음 SQLite와 HTML 파싱을 내장하고 네이티브로 컴파일되는 가벼운 LISP/Scheme 방언을 찾고 있음 관련 정보는 [여기](https://taoofmac.com/space/dev/lisp)에 정리함 - 나도 같은 일을 했는데, **Go로 사이트 생성기**를 구현했음 수년이 지나도 1초 이내에 전체 사이트를 빌드할 수 있음 RSS 피드와 코드 하이라이팅 기능도 직접 넣었고, [Chroma](https://github.com/alecthomas/chroma)와 [Blackfriday](https://github.com/russross/blackfriday)를 사용함 Hugo를 써봤지만 너무 복잡해서 직접 구현했음 - 정적 블로그에서 **댓글**은 어떻게 처리하는지 궁금함 - 예전에 svbtle에서 Hugo로 옮겼는데, 솔직히 **후회**하고 있음 테마를 포크했는데 Hugo가 자주 깨져서 유지보수에 너무 많은 시간이 듦 지금은 사이트가 아예 빌드되지 않음 조언하자면, 사이트를 빌드한 **바이너리 버전**을 소스 컨트롤에 함께 넣어두는 게 좋음 - 어떤 소프트웨어는 굳이 업데이트할 필요가 없다는 걸 깨달았음 정적 사이트 생성기는 보안 이슈가 거의 없으니, 필요한 기능이 없다면 **옛 버전 그대로** 써도 됨 운영체제나 CPU가 크게 바뀌지 않는 한 문제없음 - CI 설정에서 버전을 명시하면 됨 나도 [이 설정](https://github.com/oslc-op/website/blob/9b63c72dbb28c2d3733c2480ac4a9bf1ffe4c278/.github/workflows/hugo.yml#L23-L26)을 참고해서 버전 고정함 작동하는 버전을 찾을 땐 **이진 탐색**으로 찾는 게 효율적임 - 나는 **커스텀 Docker 이미지**로 해결했음 로컬과 CI 모두 같은 Hugo 버전을 사용하니 문제 생길 일이 없음 - 오프더셸프 바이너리를 쓸 때는 `${project}/bin/`에 넣고 `.gitignore` 처리한 뒤, 체크섬을 `SHA256SUMS` 파일에 기록하면 됨 Git LFS의 간단한 버전 같은 방식임 - 나도 Jekyll에서 같은 문제를 겪었음 새 컴퓨터로 옮길 때 버전 맞추기가 두렵고, 결국 PHP로 포팅 중이지만 아직 미완성임 - Markdown으로 글을 쓰는 사람이라면 Hugo 전환이 합리적임 나도 500개 넘는 Jekyll 포스트를 Hugo로 옮겼는데, **템플릿 문법**이 가장 힘들었음 그래도 전반적으로는 이득이었음 전환 과정과 자동 변환 스크립트를 [블로그 글](https://nickjanetakis.com/blog/converting-my-500-page-blog-from-jekyll-to-hugo)에 정리했음 - 왜 Jekyll에서 Hugo로 옮겼는지 궁금함. Jekyll로도 충분히 만족 중임 - SSG는 **정적 사이트**에는 좋지만, 상호작용이 필요한 경우엔 서버가 필요함 어차피 서버를 돌릴 거라면 Markdown을 동적으로 렌더링하는 게 더 단순함 결국 SSG는 의존성과 깨질 요소만 늘림 Jeff가 나중에 댓글 같은 기능을 추가하려다 후회할 것 같음 개인적으로는 **SSR 기반의 간단한 서버**가 더 현실적인 해법이라 생각함 - 하지만 방문자나 봇이 많아지면 서버가 터질 수도 있음 정적 페이지는 이런 위험이 없고, 대부분의 트래픽은 읽기 전용임 Jeff도 댓글 기능을 [이슈](https://github.com/geerlingguy/jeffgeerling-com/issues/167)에서 직접 구현하려는 듯함 - 나도 **셀프호스팅 분석 도구**와 댓글 시스템을 직접 운영 중임 Drupal 시절보다 코드 규모가 훨씬 작고 단순함 - 정적 사이트 생성기는 오히려 **의존성을 줄이는** 방향임 - 나는 정적 페이지는 SSG로, 댓글은 **Common Lisp + Hunchentoot** 서버로 처리함 - 나도 사이트를 SSG로 바꿨는데 전혀 후회하지 않음. 오히려 단순할수록 좋음 - SSG를 선택할 때의 **의사결정 과정**이 궁금함 Hugo, Eleventy, Jekyll 등 주요 도구가 많고, Hugo는 특히 **호환성 깨짐**이 잦음 오래된 프로젝트라면 이제는 안정성을 보장해야 한다고 생각함 - 실제로 Hugo는 [v0.146](https://gohugo.io/templates/new-templatesystem-overview/)에서 템플릿 시스템을 전면 개편했음 덕분에 내 블로그 빌드가 깨졌고, [문서](https://gohugo.io/templates/lookup-order/)도 아직 완전히 갱신되지 않음 변경 자체는 괜찮지만, 문서가 따라오지 않는 게 문제임 - 요즘 **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](https://tempestphp.com) 같은 프레임워크 위에 커스텀 SSG를 만드는 것도 고려 중임 - Eleventy는 Mustache 같은 **고전 템플릿 언어**도 지원함 나도 Punch 기반 사이트를 Eleventy로 옮겼고, 빌드 속도만 괜찮다면 Hugo보다 낫다고 느낌 지금은 Astro로 새로 만들었음 - 우리 스타트업의 마케팅 사이트를 NextJS에서 **Astro**로 옮겼는데 매우 만족함 정적 중심이지만 필요한 경우 백엔드 로직도 쓸 수 있음 NextJS는 단순한 사이트에 비해 너무 복잡했음