2011년에 이 블로그를 시작할 때 2011년, Jekyll로 만들었다. Jekyll은 15년 동안 나를 잘 받쳐줬다. 속도도 충분히 빨랐고, 노트북을 바꿀 때마다 시스템을 다시 설치하는 데 한두 시간쯤 걸리긴 했지만 대체로 그냥 잘 돌아갔다. 그런데 작년 말 로컬에 설치된 모든 것을 각 런타임의 최신 버전으로 업데이트하고 있을 때 Jekyll을 Ruby 4로 업데이트하려 하자 되지 않았다. Jekyll 프로젝트는 결국 2월에 Ruby 4 지원(한 줄 수정)을 머지했다지만, 나는 그걸 떠나야 할 신호로 받아들였다.

사실 Jekyll을 몇 년 더 계속 쓸 수도 있었겠지만, 프로젝트가 느려졌다는 건 부정할 수 없고, 이 블로그를 위한 최적화 스택도 점점 더 복잡해졌다. 최적화에 더 중점을 둔 도구를 써서 툴체인을 단순화하면 좋겠다는 생각이 들었다.

그래서 11ty로 갈아탔다. 아니, 곧 Build Awesome이라는 이름으로 바뀌게 될 그것으로 말이다. 한바탕 소란이 일어나기 전에 이미 갈아타고 이 글을 쓰기 시작했는데, 할 말은 있지만 그건 지금 핵심이 아니다.

왜 macwright.com에 Eleventy를 선택했나?

이 바닥의 절대 강자는 Eleventy가 아니라 Astro다. hakyll(Haskell)이나 dodeca(Rust) 같은 다른 정적 사이트 생성기도 많다. 예전에 많은 사람들이 그랬듯 나도 직접 하나 만들 수 있었다.

이 사이트에는 다른 이해관계자가 없다. 누구에게 새로운 기술을 온보딩해야 할 필요도 없고, 내 결정으로 누구에게 인상을 남길 필요도 없다. 이 웹사이트에 대해 내가 중요하게 생각하는 우선순위는 몇 가지로 단순하다:

1. 단순성
2. 지속성
3. 속도

나는 내부와 외부의 단순성을 모두 중요하게 생각한다. API의 단순성뿐 아니라 구현 자체의 단순성까지도 그렇다. 어떤 도구든 언젠가는 고장 날 거라고 생각하기 때문에, 직접 열어 보고 문제를 찾을 수 있기를 바라기 때문이다. 또 복잡한 프로젝트는 유지보수가 훨씬 어렵기 때문에 지배적인 위치를 차지하지 못하면 수명이 짧아지는 경향이 있다는 점에서도 중요하다.

지속성을 예측하기는 어렵다. 린디 효과는 좋은 지름길이 된다:

기술이나 아이디어처럼 쉽게 사라지지 않는 것의 미래 기대 수명은 현재 나이와 비례한다

하지만 기술 분야에서는 가장 새로운 솔루션이 가장 좋은 것일 수도 있다. 어느 정도는 예측을 해야 한다. 기여자 수가 많은 것도 지표가 되지만, 여러 주체가 참여하고 있을 때만 그렇다. 같은 회사 소속 기여자가 많은 프로젝트는 해고라도 나면 금방 조용해질 수 있다. 여러 차례 지배 구조와 권력 교체 속에서도 살아남았는지 여부도 중요하다.

이 웹사이트에서는 개발 속도보다 최종 사용자의 속도를 더 중요하게 생각한다. 내가 Markdown 수정 사항을 미리 보는 데 100ms가 걸리든 아니든, 독자가 페이지를 불러오는 데 얼마나 걸리는지만큼 중요하지 않다. 어차피 쓸데없는 짓만 안 하면 대부분의 정적 사이트 생성기는 꽤 빠르다. 내 경험상 “빌드가 느린” SSG는 대부분 중첩 루프가 대부분의 시간을 잡아먹고 있었다.

Eleventy는 이런 조건들을 충분히 만족한다. 기여자 수는 꽤 적지만, Zach는 매우 끈질기고 온갖 일을 다 겪어 왔다. 웹사이트 빌드 자체도 빠르고, 웹사이트 최적화를 위한 도구도 많이 갖추고 있어서 내가 macwright.com을 위해 직접 작성했던 커스텀 코드를 대체할 수 있게 해준다. 그리고 Astro와 뚜렷이 대비되는 점은 내부 단순성을 우선순위에 두고 작성되었다는 것이다. 코드 라인 수 측면에서도 작은 프로젝트일 뿐 아니라 메가 의존성에도 의존하지 않는다. Astro를 새로 설치하면 Vite와 esbuild를 포함한 246개의 의존성이 딸려 온다. Eleventy는 그 절반 정도인 116개의 의존성이며, 용량도 87.9MB 대신 14.6MB다.

나는 Eleventy가 불필요한 마이크로 의존성을 포함한 오래된 의존성 몇 개만 잘라내도(이 글을 쓰는 동안 그 방향으로 작은 PR을 만들기도 했다) 더 단순해질 수 있다고 생각한다. 의존성을 제거하고 줄이려는 e18e 프로젝트는 정말 필요한 일이다!

SSG로 먹고살기는 어렵다

물론 이런 소식도 있다: Eleventy가 이제 Build Awesome이 되었다. 이는 다른 프로젝트들의 비슷한 발표가 잇따른 뒤에 나온 소식이다:

• Cloudflare가 Astro를 인수했다
• Netlify가 Gatsby를 인수했다
• Shopify가 Remix를 인수했다
• Vercel이 Nuxt를 인수했다
• Sanity가 Begin을 인수했다

이들은 오픈소스 프로젝트이기 때문에 “인수”라는 단어에는 별표가 필요하다. 보통은 팀을 채용하고, 어쩌면 상표권을 가져오고, 기존에 있던 비즈니스 라인을 인수하는 정도다.

Zach는 이 결정 때문에 좀 비판을 받았다. ‘Build Awesome’이 밀레니얼 감성처럼 들리고 Eleventy가 더 멋진 이름이었다는 데는 나도 동의한다. 리브랜딩은 좀 어색했다.

하지만 전체적으로는 이해가 간다. 큰 전략과 제품 출시를 조금씩 흘려가며 모두와 상의할 수는 없는 노릇이다. Eleventy는 Web Awesome의 다른 제품군, 즉 아이콘, 웹 컴포넌트, 정적 사이트 빌더와도 꽤 잘 어울린다. 이들은 모두 프론트엔드 맥시멀리즘보다는 전통주의에 가까운 좋은 웹 도구들이다.

우리가 봐 왔듯, 로우레벨 툴링으로 수익을 내는 건 엄청나게 어렵다고 생각한다. 큰 이유는 모든 개발자가 어떤 이유에서든, 혹은 이유 없이도 그냥 재미있는 사이드 프로젝트처럼 들린다는 이유만으로 언제든 자신만의 SSG를 만들기 시작할 준비가 되어 있기 때문이다. 더 상위 레벨의 콘텐츠 툴링은 수익화가 가능하다. Kirby, Sanity를 비롯해 CMS 컴포넌트를 갖춘 몇몇 사이트 생성기들은 그렇게 해서 작지만 지속 가능한 비즈니스를 만들었다. 하지만 정확히 Eleventy 같은 형태로는 작은 제품 비즈니스로는 성립하지 않는다. 최소한 서비스 비즈니스를 해야 한다.

그래서 가능한 결과는 대략 이렇다:

1. 어딘가 크고 어쩌면 상장된 회사에 인수되어 그들의 호스팅/CDN 제품 플랫폼을 키우는 수단이 된다. Astro, Nuxt, Gatsby, Remix, 그리고 어느 정도는 Begin의 운명이 그랬다. Jekyll은 처음부터 그랬다. GitHub의 Tom Preston-Werner가 만들었고, GitHub Pages를 성공으로 이끈 연료가 되었다.
2. 메인테이너가 전업으로 전환하지 않고 가벼운 본업이나 간접적인 수익 수단을 유지한다. 나는 이 경우를 복지 국가가 탄탄하고 의료비가 저렴한 나라에 사는 즐거움과 강하게 연관 짓는다. 이 시나리오에서 얼마나 많은 장기적이고 고품질의 소프트웨어가 나오는지 정말 감사하게 생각하지만, 매달 익스체인지에서 의료보험을 사야 하는 게 얼마나 힘든 일인지 아무리 강조해도 지나치지 않다.
3. 도구 자체와 직접 연관된 회사를 세우려 시도한다. Remix는 초기에 라이선스를 판매하며 이를 시도했고, Astro도 몇 가지 제품을 출시하려 했다. Eleventy는 CMS와 몇 가지 다른 기능을 출시하는 것과 함께 이를 시도하고 있다.

쉬운 일이 아니다. 미국에 살면서 가족이 있다면 #2를 이루기 어렵고, #1은 어쩌면 ‘모르는 게 약’ 같은 해법이다. 오픈소스가 그저 미끼 상품일 뿐이라면 정말로 지속 가능하지 않기 때문이다.

지금까지의 Eleventy

어쨌든 1월부터 Eleventy를 써 왔는데, 어떤가?

대체로 좋다! 몇 가지 하이라이트로는 Image 플러그인을 써서 이미지를 예전보다 더 최적화한 것, 그리고 작은 최적화 플러그인으로 HTML 압축을 빌드 과정에 바로 넣은 것을 들 수 있다. 사이트 빌드도 예전보다 조금 빨라졌고, Eleventy의 강력하지만 헷갈리는 디렉터리 데이터 파일을 활용해 각 블로그 포스트를 단순화했다. 카테고리를 frontmatter 대신 디렉터리로 관리하게 된 것이다.

템플릿 작업은 재미있다. Vento 템플릿을 쓰는 건 대부분 만족스럽다. 템플릿 안에서 임의의 JavaScript를 작성할 수 있게 해주기 때문이다. 그리고 Liquid와 달리 조용히 실패하지도 않는다.

WebC는 내게 기쁨이자 고통이다. 한편으로는 정말 황금 같은 도구다. 페이지에 컴포넌트를 포함하면서 서버 사이드 렌더링, 자동 번들링, 뛰어난 성능을 제공한다. 게다가 단순하기까지 하다! 패키지가 작은 이유는 esbuild 같은 큰 JavaScript 트랜스파일러를 끌어오지 않기 때문이다. 최근에는 In the Atmosphere 글의 차트와 Color dithering 글의 데모에 WebC를 사용했다.

하지만 고통도 있다. 제약이 많은 매우 독특한 도구라 뭔가 잘못하면 크게 실패한다. 문서는 그 잠재력을 살짝 비추기만 할 뿐 수많은 질문을 답 없이 남겨둔다. 이미 꽤 훌륭하지만 더 놀라워질 수 있다고 생각하며, Zach도 최근 강연에서 인정했듯 훨씬 더 많은 손길이 필요하다.

WebC와 Eleventy 모두에서 TypeScript를 채택하지 않은 것에 대해서는 복잡한 심정이다. WebC에는 TypeScript라면 쉽게 잡아낼 수 있었던 버그나 심지어 린터만 있어도 잡을 수 있는 버그가 있었다. 이 프로젝트들의 툴링은 훨씬 더 좋아질 수 있다고 생각한다.

하지만 불평은 과대평가되어 있다. 나는 프로젝트에 기여하려고 노력해 왔다. 대부분은 아직 손이 많이 필요한 문서에 기여하는 것이었다. Eleventy의 상업화가 이를 복잡하게 만드는데, 2월 이후 문서 업데이트가 멈춘 이유도 부분적으로는 그 때문이다. 뛰어난 유급 문서 기여자가 나타나 내가 한 일을 모두 무의미하게 만들지 않을까 하는 의문이 생기기 때문이다. 어쩌면 Kickstarter 캠페인이 크게 성공해서 여러 명의 유급 메인테이너가 생기거나, 적어도 Zach가 안정적으로 전업으로 일할 수 있게 될지도 모른다. 적어도 11ty와 관련 프로젝트들이 풀 리퀘스트를 많이 리뷰하고 머지할 시간을 확보하게 되길 바란다. 안타깝게도 그쪽 속도는 느렸기 때문이다.

Eleventy를 써야 할까? 그럴 수도 있다! 새로운 정적 사이트 생성기를 처음부터 만드는 것도 재미있지만, 커뮤니티에 참여해 인기 있는 도구를 개선하는 것은 전혀 다른 방식으로 보람 있다.

Eleventy는 Astro보다 화제성이 훨씬 적다. 그리고 자체적인 문제도 많다. 하지만 다른 소프트웨어와 마찬가지로, Eleventy도 하나의 비전과 여러 가치의 표현이며, 그중 많은 부분이 나와 공감대를 이룬다. 이것이 올바른 종류의 소프트웨어이기를 바라며, 15년 후에도 계속 쓰고 있기를 바란다.

아, 그리고 Build Awesome 출시에 기대가 된다면 Kickstarter에 등록해 보길 바란다. 나도 아마 조금 후원할 예정이다.