몇 년 전, 내 개인 웹사이트를 내가 직접 만든 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에서 템플릿 시스템을 전면 개편했음
덕분에 내 블로그 빌드가 깨졌고, 문서도 아직 완전히 갱신되지 않음
변경 자체는 괜찮지만, 문서가 따라오지 않는 게 문제임
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는 단순한 사이트에 비해 너무 복잡했음
Hacker News 의견들
몇 년 전, 내 개인 웹사이트를 내가 직접 만든 Common Lisp 기반 정적 사이트 생성기로 옮겼음
처음엔 850줄 정도였는데 지금은 1500줄 정도로 커졌고, 블로그 포스트, 방명록, 댓글 페이지, 태그별 RSS 피드 등 거의 모든 걸 정적으로 렌더링함
모든 코드와 HTML, CSS를 직접 손으로 짜서 미학적인 통제력을 유지할 수 있고, 새로운 기능 추가도 빠름
예를 들어 ‘백링크’ 페이지를 추가하는 데 40줄 정도의 CL 코드와 15분이면 충분했음
지금은 매우 안정적이라 거의 손댈 일이 없고, 글쓰기에만 집중할 수 있음
블로그 엔진을 만지작거리는 데 시간을 다 써서 결국 글을 안 쓰게 됨
그래서 일부러 제어권이 적은 호스팅 솔루션으로 돌아갔음. 이제는 오직 글쓰기에만 집중할 수 있음
예전엔 Tclssg라는 공개 프로젝트를 운영했는데, 사용자 피드백 덕분에 문서화도 하고 기능도 많이 추가했음
하지만 공개 프로젝트라 마음대로 구조를 바꾸기 어려웠음
지금은 내 사이트 전용 Python(900줄) + Pandoc Lua(700줄)로 구성된 생성기를 쓰고 있음
기술적 변천사는 내 사이트에 정리해둠
지금은 TypeScript/Bun으로 다시 만들고 있는데, 여전히 LISP스러운 요소가 남아 있음
SQLite와 HTML 파싱을 내장하고 네이티브로 컴파일되는 가벼운 LISP/Scheme 방언을 찾고 있음
관련 정보는 여기에 정리함
수년이 지나도 1초 이내에 전체 사이트를 빌드할 수 있음
RSS 피드와 코드 하이라이팅 기능도 직접 넣었고, Chroma와 Blackfriday를 사용함
Hugo를 써봤지만 너무 복잡해서 직접 구현했음
예전에 svbtle에서 Hugo로 옮겼는데, 솔직히 후회하고 있음
테마를 포크했는데 Hugo가 자주 깨져서 유지보수에 너무 많은 시간이 듦
지금은 사이트가 아예 빌드되지 않음
조언하자면, 사이트를 빌드한 바이너리 버전을 소스 컨트롤에 함께 넣어두는 게 좋음
정적 사이트 생성기는 보안 이슈가 거의 없으니, 필요한 기능이 없다면 옛 버전 그대로 써도 됨
운영체제나 CPU가 크게 바뀌지 않는 한 문제없음
나도 이 설정을 참고해서 버전 고정함
작동하는 버전을 찾을 땐 이진 탐색으로 찾는 게 효율적임
로컬과 CI 모두 같은 Hugo 버전을 사용하니 문제 생길 일이 없음
${project}/bin/에 넣고.gitignore처리한 뒤, 체크섬을SHA256SUMS파일에 기록하면 됨Git LFS의 간단한 버전 같은 방식임
새 컴퓨터로 옮길 때 버전 맞추기가 두렵고, 결국 PHP로 포팅 중이지만 아직 미완성임
Markdown으로 글을 쓰는 사람이라면 Hugo 전환이 합리적임
나도 500개 넘는 Jekyll 포스트를 Hugo로 옮겼는데, 템플릿 문법이 가장 힘들었음
그래도 전반적으로는 이득이었음
전환 과정과 자동 변환 스크립트를 블로그 글에 정리했음
SSG는 정적 사이트에는 좋지만, 상호작용이 필요한 경우엔 서버가 필요함
어차피 서버를 돌릴 거라면 Markdown을 동적으로 렌더링하는 게 더 단순함
결국 SSG는 의존성과 깨질 요소만 늘림
Jeff가 나중에 댓글 같은 기능을 추가하려다 후회할 것 같음
개인적으로는 SSR 기반의 간단한 서버가 더 현실적인 해법이라 생각함
정적 페이지는 이런 위험이 없고, 대부분의 트래픽은 읽기 전용임
Jeff도 댓글 기능을 이슈에서 직접 구현하려는 듯함
Drupal 시절보다 코드 규모가 훨씬 작고 단순함
SSG를 선택할 때의 의사결정 과정이 궁금함
Hugo, Eleventy, Jekyll 등 주요 도구가 많고, Hugo는 특히 호환성 깨짐이 잦음
오래된 프로젝트라면 이제는 안정성을 보장해야 한다고 생각함
덕분에 내 블로그 빌드가 깨졌고, 문서도 아직 완전히 갱신되지 않음
변경 자체는 괜찮지만, 문서가 따라오지 않는 게 문제임
요즘 Pelican은 어떤지 궁금함. Python 진영에서는 Hugo와 Pelican이 양대산맥 같음
RSS보다 ActivityPub 통합이 매력적으로 보이기도 함
예전에 Nikola를 썼지만 의존성이 너무 많고 증분 빌드 불일치 문제가 있었음
Pelican은 단순함을 유지해서 좋음
문서화가 90%쯤 완성된 느낌이라 세세한 부분이 부족하지만, 기본 기능만 쓰면 훌륭함
매달 커밋이 있어서 프로젝트가 살아 있음
나는 지금 Hugo에서 Zola로 옮기려는 중임
Zola의 설정과 템플릿이 훨씬 직관적으로 느껴짐
GitHub Actions로 빌드와 배포를 자동화함
3년째 Hugo를 쓰고 있음
배운 점은 테마를 포크해서 직접 관리하라는 것
서브모듈은 피하고, 업데이트는 천천히 하는 게 좋음
댓글 기능은 여전히 까다로워 보임
나도 Drupal 테마를 옮기려다 포기했음
서브모듈보다 직접 포함 후 필요한 부분만 오버라이드하는 게 낫다고 생각함
작년에 Hugo로 블로그를 시작했는데, 18개 포스트 중 3/4이 빌드 오류로 고생했음
너무 불안정해서 실망스러웠음
Hugo 방식에 익숙해지기보다 내가 아는 언어로 빠르게 구현하는 게 훨씬 편했음
예전에 간단한 SSG를 직접 만들었는데, 최근엔 좀 더 체계적인 걸 찾다가 11ty를 써봤음
하지만 Liquid 템플릿이 너무 불편했음
JSX 기반 템플릿을 쓰고 싶었지만 11ty는 그걸 어렵게 만듦
NextJS SSG는 기능은 많지만 너무 복잡해서 과한 느낌임
Tempest 같은 프레임워크 위에 커스텀 SSG를 만드는 것도 고려 중임
나도 Punch 기반 사이트를 Eleventy로 옮겼고, 빌드 속도만 괜찮다면 Hugo보다 낫다고 느낌
지금은 Astro로 새로 만들었음
정적 중심이지만 필요한 경우 백엔드 로직도 쓸 수 있음
NextJS는 단순한 사이트에 비해 너무 복잡했음