2026년 10월 26일
인터넷은 빠르게 더 위험해지고 있다. 대규모 언어 모델(LLM)은 보안 문제를 더 잘 찾아내고 있으며, 이를 악용하는 사람도 늘고 있다. LLM이 결국 대규모 취약점을 없앨 것이라는 주장도 있지만, 나는 확신하지 못한다. 어느 쪽이든 온라인에서 해킹당할 수 있는 요소를 줄이는 편이 좋다. 정적 사이트 생성기를 사용하는 것이 한 방법이다.
지난주에는 보안 문제가 잇따랐다. 가장 주목받은 사례는 PHP2Shell로, 비전문가들 사이에서도 PHP가 화제가 됐다. Node2Shell은 Node에 내장된 Brotli 압축 기능을 악용했다. 그 밖에도 취약점이 많이 공개됐다.
위 그래프는 심각도가 ‘치명적’인 CVE만 보여준다. 전체 CVE를 보여주는 그래프도 있다. 지난 5월 이 문제를 걱정했을 때는 아직 수치가 낮았다. 가까운 시일 안에 상황이 나아질 것 같지는 않다.
나는 2000년대 초반부터 2010년대 중반까지 웹에서 많은 것을 만들었고, 주로 콘텐츠 관리 시스템(CMS)을 기반으로 사이트를 구축했다. 대부분의 기간에는 팀이 함께 사용하는 표준 플랫폼이 있었다. 팀에서 콘텐츠 작업을 많이 맡는 대형 사이트를 만들 때는 합리적인 선택이었다. 때로는 “고객이 직접 사이트를 수정하고 싶다고 한다”는 이유로 CMS를 쓰기도 했다.
고객마다 상황은 다를 수 있지만, 내가 만난 고객 가운데 CMS 기반 사이트를 실제로 수정하는 경우는 극히 드물었다. 보통은 팀이 이메일로 변경 요청을 받았다. 고객사에서 의욕적인 신입 직원이 한동안 직접 수정하더라도 그 직원이 떠나면 다시 이메일 요청으로 돌아가는 일이 많았다. 사이트를 꾸준히 직접 수정한 고객은 사내 개발팀이 있는 곳뿐이었다.1
최근에는 사실상 정적인 웹사이트를 위해 서버 측 기능을 갖춘 복잡한 Node 기반 시스템을 구축하는 사례를 많이 봤다. SSR이나 하이드레이션 같은 기술을 쓰는 식이다. 이런 방식 자체에 문제가 있는 것은 아니지만, 콘텐츠 중심 사이트에는 지나친 구성일 수 있다.
복잡한 웹 앱을 만든다면 서버가 필요할 가능성이 높고, 이를 유지 관리할 계획도 있어야 한다. 보안 패치를 적용할 사람이 필요하다는 점도 당연히 고려해야 한다. 반면 주로 정적인 콘텐츠를 제공하는 사이트라면 동적·서버 측 도구를 계속 써야 하는지 따져볼 필요가 있다.
사이트 콘텐츠는 실제로 얼마나 자주 바뀌는가? 기반 소프트웨어를 유지 관리할 계획이 있는가? 고객과 유지 보수 계약을 맺어 패치 작업에 드는 시간을 충당할 것인가? 앞으로 웹 소프트웨어를 관리하는 데 더 많은 주의가 필요해질 것으로 본다. CMS나 Node 기반 사이트를 6개월마다 패치하는 것으로는 부족할 수 있고, 고객은 청구서의 ‘보안 업데이트’ 항목을 의아하게 여길 수도 있다.2
그 대신 웹에 HTML을 올리기만 하면 어떨까?
정적 사이트 생성기(SSG)를 처음 들었을 때는 흥미로웠지만, 실제로 받아들이기까지는 시간이 걸렸다. 2012년에 이 사이트를 toto에서 Jekyll로 옮기면서 생각이 바뀌기 시작했다. 중요한 작업은 빌드 단계에서 모두 처리하고, 결과물은 90년대 웹사이트처럼 단순하게 만들면 어떨까? 그렇게 하면 페이지가 매우 빠르게 열리고 호스팅 비용도 저렴하다.3 실제로 이 사이트는 GitHub Pages에서 무료로 호스팅하고 있으며, 여러 차례 큰 트래픽 급증을 겪었지만 문제없이 처리했다. 무엇보다 보안 패치를 적용할 걱정을 한 적이 없다.4
블로그는 정적 사이트의 좋은 사례지만, 그다지 흥미로운 용도는 아니다.5 흔한 회사 소개 사이트도 마찬가지다. 하지만 SSG를 써온 뒤 다른 용도도 많이 발견했다. 고객 대시보드의 데이터가 몇 시간마다 바뀌는 정도라면 데이터베이스를 매번 조회하는 대신 JSON 파일을 만들어 두는 편이 저렴할 때가 많다. 맞춤형 데이터 시각화에도 SSG를 ETL 파이프라인에 넣어 좋은 결과를 얻었다. Hugo는 데이터 소스 기능 덕분에 이 작업에 큰 도움이 됐다.
다른 곳에서도 흥미로운 사례를 찾아볼 수 있다. Cloudflare는 여러 해에 걸쳐 문서를 다양한 SSG로 만들었고, 그 과정을 공개했다. V&A는 온라인 컬렉션을 정적 사이트로 전환한 과정을 소개했다. Fastmail은 WordPress에서 Eleventy로 옮긴 과정을 기록했다. 대규모 조직은 SSG를 통해 호스팅 비용을 크게 줄일 수 있다. 보안과 유지 관리 비용도 앞으로 더 아낄 수 있을 것으로 본다.
정적 사이트를 만드는 도구가 개발자만을 위한 것은 아니다. Publii는 그래픽 인터페이스로 정적 웹사이트를 만들 수 있는 무료 오픈소스 도구다. Bear Blog, Pika, Micro.blog 같은 호스팅 서비스도 고려할 수 있다. 보안 문제를 걱정하지 않고 웹 공간을 마련하고 싶다면, 그런 문제를 다른 곳에 맡기는 것도 나쁘지 않다.
동적 웹 소프트웨어를 만드는 것이 잘못이라는 뜻은 아니다. 다만 웹의 상당 부분은 본래 정적인 콘텐츠로 이뤄져 있다. 정적 사이트는 매우 빠르고, 사실상 무료로 호스팅할 수 있으며, 보안상 취약해질 수 있는 요소도 아주 적다. 변경 요청을 이메일로 받을 가능성이 높다면 처음부터 정적 사이트 생성기를 사용해 자신과 고객이 겪을 수 있는 골칫거리를 줄일 수 있다.
이 경우에는 보통 우리가 처음 사이트를 구축한 뒤 고객에게 사용법을 교육했다. 출시 이후 소프트웨어를 최신 상태로 유지할 다른 팀이 있었기 때문에 이런 구축 방식이 잘 맞았다.↩
WordPress처럼 자동 업데이트를 지원하는 시스템도 있다. 하지만 버전 관리 시스템을 사용하면 기본적으로 업데이트가 적용되지 않는다. 플러그인도 자동 업데이트하고 있는가? 이 역시 별도의 고려가 필요하다.↩
안타깝게도 분석 서비스 제공자가 Google 봇의 트래픽을 차단해 PageSpeed에서 네 항목 모두 100%를 받지는 못한다. 일반 방문자에게는 100%에 가까운 경험을 제공할 것으로 본다.↩
정적 사이트도 완벽하게 안전한 것은 아니다. 예를 들어 사이트가 올라간 서버가 침해될 수 있다. 그래도 문제가 생길 요소가 훨씬 적고, 사고가 발생해도 사이트를 다시 만드는 비용은 사실상 0에 가깝다.↩
이 사이트는 과거에 내가 구축한 CMS나 Node 기반 사이트 다수보다 콘텐츠가 훨씬 많다.↩
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요