2024년 작년 12월에 나의 최초의 웹사이트를 만들었다. 이름하여 solmee.xyz 1.0.0. 이제 이 블로그에는 139개의 마크다운 파일이 있다. 당시에도 충분히 잘 예상하고 있었던 것이지만, 반 년을 써보고 나니 그때 세운 가설들 중 맞는 것도 있고 아닌 것도 있다는 것을 알게 되었다. 반 년이라도 스스로 만든 시스템을 사용해 (아직 시원찮은 솜씨이긴 하나) (공개적인) 글 쓰는 습관을 들이는 데 성공했다는 것에는 나 자신을 칭찬하고 넘어가야겠다. 또 불편한 점이 넘쳐나긴 하지만, 편한 점은 편하기 때문에 의식하지 못해서 과소평가된다는 것도 잊지 말자.
그럼 이제부터 불평을 시작하겠다. 다음 버전에서는 어떻게 바꾸고 싶은지와 함께.
Vanilla CSS → Tailwind
CSS는 tailwind로 바꿔야겠다. 왜냐면 지난 반년동안 했던 프로젝트에서 tailwind를 써봤는데 돌아가고 싶지 않아졌다. 이 블로그를 만들 때 기획과 디자인 다음으로 날 고통스럽게 했던 것이 CSS였다. CSS 코드가 불어날수록 뇌 속 메모리에 저장해둬야 할 선택자가 많아졌고 서로서로 꼬이기 시작해서 나중에는 간단한 스타일을 고치기 위해 모든 맥락을 동시에 고려하는 Holistic Thinking을 해야 했다. tailwind는 스타일 하나를 고치려면 그 컴포넌트 하나만 기억하면 되니 좋다. 그리고 브라우저에서 inspect로 className 복사 후 에디터 검색창에 붙여넣어서 컴포넌트를 쉽게 찾을 수 있는 것도 좋다.
tailwind를 도입하기 전에는 이렇게 하면 적어야 하는 코드의 양이 더 많아지는 건 아닌가 걱정했지만 리팩터링을 잘 하면 컴포넌트 갯수가 그렇게 많아지진 않아서 아직까진 괜찮다. 근데 만약 아주 많은 양의 컴포넌트의 스타일을 한 번에 편집해야 하는 상황이 온다면? 뭐 그런 상황에 대한 대처법도 누군가가 이미 마련해 놨겠지.
그리고 역시 올해 반년동안 했던 프로젝트에서 clsx를 알게 됐다. .current 같은 pseudo class를 써가며 컨트롤했던 스타일을 상태와 바로 연동할 수 있으니 정말 좋았다.
Javascript → Typescript
타입스크립트는 공부하려 했었지만 문서를 읽는 것만으로는 머리에 잘 들어오지 않고 졸음만 와서 그냥 냅다 새 프로젝트에 설치하고 부딪히며 알아갔다. 초반 몇 달 동안은 타입에러가 너무 짜증났는데, 쓰다 보니까 함수 파라미터들의 타입을 지정해 주는 것이 자연스러워졌고 타입들을 한 파일에 몰아넣은 뒤 import해서 쓰는 등 좀더 효율적으로 하는 법을 알게 되었다. 그렇게 한창 타입스크립트를 쓰다가 블로그에 돌아와 자바스크립트를 보니 코드가 헐벗은 것 같고 코드 칠 때 에러가 안뜨면 어딘가 허전함을 느끼게 되었다.
Astro, Markdown → Cloudinary, CMS, JSON, GraphQL
Astro는 Gatsby, Jekyll 등 다른 SSG 프레임워크들이 밀려나면서 요즘 더더욱 블로그용으로 핫해지고 있는 것 같다. 튜토리얼도 잘 되어 있고, 편하고, 빌드도 빠르고, 여러가지 언어로 된 동적 컴포넌트도 추가할 수 있어서 훌륭한 도구임에는 틀림없다. 2025년에 블로그를 만든다면 다른 선택지는 거의 고려할 필요가 없을 정도로 좋은 도구다. 하지만 나는 블로그뿐만 아니라 앞으로 쓰임을 더 확장하고 싶기에, 그리고 지루해졌기에 Astro를 한번 떠나보려 한다. 이 블로그 만들때의 나는 웹개발에 대해서 거의 갓 태어난 뉴비였어서 (지금도 그렇지만…) Astro를 깊게 이해한 적도, Astro를 가지고 제대로 놀아본 적도 없다. 물론 다른 프레임워크에 대한 경험도 별로 없다. 그래서 더 불평이 많은 걸지도 모른다.
일단 Astro만의 고유 신택스가 있는 것이 마음에 들지 않는다. .astro, 레이아웃 슬롯, client:only="react" 같은 것 말이다. 마크다운 파일들을 src/pages/에 다 몰아넣어야 하는 것도 별로다.
이미지도 src에 때려넣어서 Markdown 파일 안에다가 상대경로로 연결해야 한다는 것이 별로다. 위처럼 이미지 한 장 넣을라면 ../../assets/라는 경로를 앞에 붙여야 하고 파일명을 기억해야 한다. Cloudinary 같은 데 이미지를 저장하면 SSG는 유지하면서 로컬에 이미지가 잔뜩 들어있다는 심리적 부담감을 피할 수 있고 관리도 편하게 할 수 있고 파일명이 아닌 사진을 보면서 import할 수 있을 것이다.
글들을 태그 같은 걸로 필터링할 때 frontmatter 객체를 사용해서 find로 찾는데, 편하지만 ‘내가 왜 한낱 프레임워크 따위가 정한 방식대로 필터링해야 하지?’ 라는 근거없는 반항심이 든다. 나는 블로그를 처음 만들 때 Markdown이 되게 순수한 데이터 형태라고 생각해서 좋아했다. 그런데 사용을 하다 보니 프론트매터의 양은 불어나고, 내부 링크 신택스, 이미지 링크 신택스, html 태그 등이 한데 섞이면서 더이상 순수하다고 할 수 없게 되었다. 아예 컴포넌트를 Markdown 안에 포함하기 위해서 mdx를 쓰는 사람들도 있었다. 하지만 난 텍스트와 컴포넌트가 섞인다는 게 영 찜찜했다. Strapi나 Sanity 같은 CMS를 사용해서 JSON 형식으로 데이터를 저장하면 텍스트와 컴포넌트가 섞이지 않을 것이다.
그리고 프론트매터로 메타데이터와 데이터를 구분하는 Markdown과 달리 JSON은 메타데이터와 데이터 사이 구분을 두지 않는다. 난 Markdown이 텍스트랑 컴포넌트를 섞을거면 왜 그 위에 메타데이터와 데이터 사이의 구분은 두는 건지 납득하고 싶지 않기 때문에 아예 다 평등하게 객체 안의 키-값 쌍으로 취급하는 JSON이 더 좋아 보인다. 그리고 JSON은 RestAPI나 GraphQL 같은, 적어도 Astro의 프론트매터 객체나 md, mdx를 파싱하는 스크립트들보다는 더 보편적인 방식으로 쿼리할 수 있다. 보편적인 방식으로 쿼리하는 게 뭐가 더 좋은건지는 아직 잘 모르겠으나 그게 더 땡긴다. api를 쓰면 역할 기반 권한 허용하기도 (개인웹사이트에서 역할을 나눌 필요가 있나 모르겠다만) 더 편할거고. GraphQL를 한 번 써보고 싶은 사심도 존재한다. RestAPI보다 더 정밀하고 깊게 쿼리하는 게 쉬울 것 같고, 잘 쓰면 api call 횟수도 줄일 수 있다고 한다.
Obsidian → ??
지금도 Obsidian에다가 이 글을 쓰고 있다, 정말 편한 도구이다. 하지만 Obsidian에 있는 모든 기능을 사용하지는 않는다. 나의 어쩌면 비합리적이라고 할 수도 있는 사고방식 중에 하나가 내가 사용하는 앱 안에 내가 실제로 사용하지 않는 기능이 있는 게 낭비라고 생각하는 것이다. (근데 그렇게 치면 네 조그만 개인 웹사이트에 Nextjs는 왜 쓰고 싶어하는 건데? → 그건 다른얘기고.)
처음에는 테마와 플러그인이 많다는 것에 환호했었는데, 생각보다 나와 같은 사용자가 만든 플러그인을 잘 안 믿고 잘 안 설치해 쓰게 된다. 불확실성 회피 성향이 있는 것 같다. 내가 초짜고 내가 만든 프로그램이 너무 잘 망가지기 때문에 다른 사람이 만든 프로그램도 곧 망가질 것 같고 거기에 내 시간과 정을 투자하는 리스크를 지고 싶지 않다.
그리고 이건 Astro와 Markdown과도 관련있는 건데, 각 블로그 포스트의 프론트매터 안에 진짜 한글 제목을 쓰고 파일명으로는 영어로 된 slug(url에 들어갈 문자열)를 써야 한다. 예를 들어 이 글의 내가 원하는 “진짜 제목”은 ‘반 년만에 블로그를 갈아엎고 싶어진 이유’인데 파일명은 ‘why-change-blog’이다. 초반에는 최대한 슬러그도 의미있게 잘 지으려고 노력했지만 점차 귀찮아져서 대충 적기 시작했다. 물론 슬러그를 자동으로 만들어주는 스크립트를 돌릴 수도 있다. 하지만 난 각 블로그 포스트마다 고유하고 바뀔 일 없는 id를 만들어줄 예정이고, 그게 있다면 굳이 slug를 만들 필요가 없지 않을까? slug도 가독성 있어야 한다고 주장하는 사람도 있지만 라틴 문자와 달리 한글은 ’-’ 문자로 단어와 단어 사이가 연결됐을 때 자연스럽게 보이지도 않고, 개인적으로 링크 안의 글을 읽으려고 시도한 적이 없어서 동의하지 않는다.
그리고 나는 내 블로그 시스템을 나만 쓰는 것이 아닌 템플릿화 해서 공유할 수 있게 하고 싶은 생각이 오래전부터 있었다. 만약 다른 사람도 이걸 쓴다면 그들의 컴퓨터에 Obsidian을 설치하고, 사용방법을 익히라고 강요할 수는 없겠지. 그리고 Obsidian으로 쓴 글이 웹사이트에 자동으로 들어가게 하려면 symlink를 걸어야 하는데 ‘컴퓨터 좀 잠깐 줘봐요’ 해서 걸어줄 수도 없고.
그리고 이제 어떤 서비스에 (내가 만든 것이 아닌) 눈에 보이는 인터페이스가 있다는 게 꺼려지기 시작했다. 어쩌면 이것은 내가 디자인과이기 때문일까? 실체가 없는 프레임워크, 라이브러리, api, 아이디어, 언어 같은거는 남의 거 잘 갖다쓰지만 남이 만든 화면만큼은 내 작업 파이프라인에 포함하고 싶지 않아진다. 그래서 Obsidian을 대체할 텍스트 에디터를 직접 만들까 생각중이다.
이 글에 내가 당시 Obsidian을 텍스트 에디터로 쓰기로 한 이유가 적혀 있다. (저 때 CMS와 텍스트 에디터를 헷갈렸나 본데 Obsidian은 CMS가 아니다…) 텍스트 에디터를 직접 만들기로 하니, 저 글에 쓴 ‘Obsidian에 의존할 이유’가 모두 사라졌다. 일단 내부링크 달 때 파일명이 아닌 unique한 id를 사용하면 자동 제목 수정 기능은 필요가 없어진다. 내부링크를 생성할 때 자동완성해주는 기능은 만들면 된다. CMS에서 컨텐츠 타입을 만들 것이니 프론트매터 템플릿 또한 필요 없다.
Figma 도입
지금 나는 웹사이트를 디자인할 때 종이에다 스케치하고 시각적인 모습은 대충 상상만 한 뒤 바로 개발에 들어가는데, 나중에 이게 직업이 된다면 협업을 해야 할텐데 계속 이렇게 해도 될까? 그리고 나중에 작업량이 많아지고 웹사이트가 복잡해져서 더이상 모든 계획을 머리속에 넣어둘 수 없고, 자동화가 필요해진다면? 2025년 현존하는 가장 디자인과 웹기술을 잘 통합하는 협업 툴은 피그마가 아닐까? 근데 이 피그마가 정말 배우기 귀찮다… 그래도 화면과 코드를 엄청 쉽고 빠르게 sync하는 기능이라던가 이런게 찾아보면 있을 것 같다. 유용한 툴이 아니라면 현업에서 쓰이고 있을 이유가 없겠지… 조만간 배워야겠다.
어떤 CMS를 써야 하나…
내가 지금까지 써본 CMS는 딱 하나, Strapi였다. Strapi와 Sanity는 둘다 Headless CMS다. 예를 들어 네이버블로그는 네이버블로그에서 글을 써야만 하고 네이버블로그에서 글을 읽어야만 하지만 Headless CMS는 말 그대로 머리통을 탈부착하듯이 프론트엔드와 컨텐츠를 분리할 수 있다. 그리고 그것은 사용자가 CMS기능만 쏙 빼먹고 프론트엔드는 마음대로 디자인하고 개발할 수 있다는 것을 뜻한다.
Strapi는 빌트인 프론트엔드 인터페이스가 있지만(쓰고 안쓰고는 자유다) Sanity는 직접 만들어 쓰는게 기본값인 듯 하다. Sanity Studio라는 것을 이용해서. 그러면 직접 만든 프론트엔드 앱은 서버앱이 아니기 때문에 Vercel이나 Netlify에 배포할 수도 있다고 한다. 근데 난 GraphQL을 쓰고 싶고, 블로그를 처음 만들 때 중요하게 여겼던 ‘내 데이터를 내가 소유하는 것’ 즉 내 데이터가 어떻게 저장되어 있는지 볼 수 있어야 하고, 언제든 마이그레이션할 수 있어야 하고, 데이터베이스를 내가 만들 서버에 띄워 보고 싶다. 하지만 Sanity는 고유한 api를 사용하고 데이터베이스는 따로 저장하는 곳이 있어서 접근할 수 없으며 셀프호스팅이 안된다.
내가 원하는 게 무엇일까? 100% 처음부터 짓는 건 아직 절대 못하고 잘하는 사람들도 다들 시간낭비라고 하지 말라고 한다. CMS가 백엔드는 맡아 해줬으면 좋겠고, 보안이랑 권한 설정 포함되어 있었으면 좋겠고, Rest/GraphQL 둘다 지원했으면 좋겠고, 셀프호스트 자유롭게 됐으면 좋겠다. 오픈소스고 가볍고 프론트 없고 CLI랑 configuration 파일 같은 것만으로 세팅해서 쓸 수 있는 무언가 🦄… 없나…? 찾아봐야겠다.
떠나기 전 한마디
불평을 하면서도 난 현재 옵시디언에다 글을 적고 있고, 커밋을 하면 아스트로가 페이지를 빌드해 주겠지. 익숙해졌기에 잊은 편한 점들을 떠나고 나서야 하나둘씩 자각하게 되겠지.