우당탕탕 블로그 제작기 (1)

블로그를 제작하게 된 계기

관심이 가는 프로젝트를 진행하면서 소스 코드를 느낌 가는 대로 만들고 정리하다 보니 문서화의 필요성을 자주 느끼게 되었다. 왜 만들었는지와 어떻게 동작하는지를 함께 기록해 두지 않으니 다시 프로젝트를 진행하려 할 때 어려움을 많이 겪었기에 더더욱 그랬다. 그러다 보니 결국에는 내 글과 코드를 차곡차곡 쌓아 둘 수 있는 나만의 블로그가 필요하다는 결론에 이르렀다.

물론 많은 개발자들이 현재 티스토리나 velog에서 연재 중이고, 이러한 기존 플랫폼이 있는데 왜 굳이 직접 블로그를 만들었는지 많은 사람들이 의구심을 가지고 있다.

이러한 플랫폼은 빠르게 글을 작성하기에는 좋지만 내가 원하는 방향과는 미묘하게 어긋나는 부분들이 있었다. velog는 비교적 가볍고 편하게 글을 올리기에는 좋지만, 상업 플랫폼의 성격이 강해서 광고가 보이는 점이 마음에 걸렸다. 티스토리는 구조상 개발자가 코드와 기술적인 내용을 중심으로 다루기에는 적합한 플랫폼이 아니다. 그래서 결국에는 직접 만드는 편이 내가 원하는 방향에 더 가깝다고 판단했다.

무엇보다도 내 공간이라고 부를 수 있는 블로그를 하나쯤 가지고 싶다는 마음이 컸다. 사실 이 프로젝트를 시작하게 된 가장 큰 이유는 그것이었다. 플랫폼 위에 글을 올리는 느낌보다, 내가 직접 관리하는 공간에 글을 쌓아 나가는 느낌이 더 좋았다.

그래서 이 글에서는 왜 내가 Astro.js + SolidJS 조합으로 블로그를 만들게 되었는지 가볍게 정리해 보려고 한다. 코드나 세세한 구현을 설명하기보다는, 어떤 기준과 생각으로 이 선택을 하게 되었는지에 조금 더 초점을 맞추고 싶다.

Hugo vs. Jekyll vs. Astro.js

블로그를 정적 페이지로 운영하려고 보면 선택지는 생각보다 많다. 예전에는 Jekyll이 대표적인 도구로 자주 언급되곤 했고, 한때는 정적 블로그를 만든다고 하면 거의 기본 선택지처럼 여겨지던 시기가 있었다.

여러 사례를 찾아보다 보니, 최근에는 Go 언어 기반의 Hugo가 Jekyll의 자리를 어느 정도 대신하고 있는 듯했다. 빌드 속도나 생태계 측면에서 Hugo를 추천하는 경우도 꽤 많았다.

예전에 Jekyll을 써 보았을 때는 속도 면에서 아주 만족스럽지는 않았다. 게다가 테마를 다루는 방식도 내 기준에서는 다소 불편했다. 웹 개발자 입장에서는 블로그를 만들기 위해 Jekyll 자체의 문법과 흐름을 따로 익혀야 한다는 점이 꽤 큰 진입 장벽처럼 느껴졌다. 블로그를 만들고 싶은데, 정작 블로그 엔진을 공부하는 데 더 많은 시간을 써야 하는 구조처럼 보였다.

이런 맥락에서 보면 Hugo도 크게 다르지는 않았다. 물론 성능이나 편의성 면에서 장점은 분명했지만, 내가 원하는 스타일의 블로그를 만들려면 결국 테마를 손봐야 했고 그 과정 역시 만만하지 않았다. 그렇다면 차라리 내가 익숙한 방식으로 정적 페이지를 직접 만드는 편이 더 낫겠다고 생각했다. 그렇게 해서 블로그를 Astro.js 기반으로 직접 만들게 되었다.

참고로 이 블로그는 처음부터 Astro.js로 시작한 것은 아니다. 초반에는 Hugo로 작업하고 있었지만, 만들면서 점점 방향이 바뀌었고 지금은 완전히 Astro.js 기반으로 옮겨와 개발하고 있다.

GitHub Pages 배포

정적 페이지를 배포하는 방법 역시 다양하다. 사실 요즘은 어디에 올리느냐에 따라 개발 경험이 꽤 달라지기 때문에, 이 부분도 생각보다 중요하게 느껴졌다.

가장 먼저 떠오르는 선택지는 역시 GitHub Pages였다. 개인 블로그나 프로젝트 페이지를 올리는 용도로는 이미 충분히 검증되어 있고, GitHub 저장소와 자연스럽게 연결된다는 점이 큰 장점이었다. 특히 이 블로그처럼 저장소 자체가 곧 작업의 중심이 되는 경우에는 코드와 배포가 같은 맥락 안에 있다는 점이 편하게 느껴졌다.

물론 다른 선택지도 충분히 매력적이었다. Netlify의 경우에는 정적 사이트 배포 경험이 꽤 깔끔하고 폼 처리나 미리보기 배포 같은 기능도 무료이며 잘 갖춰져 있다. 정적 사이트를 올리는 경험 자체만 놓고 보면 상당히 잘 정리된 서비스라는 인상이 있다. 실제로 블로그처럼 빌드 결과가 단순한 프로젝트에서는 Netlify도 충분히 좋은 선택지라고 생각한다.

Vercel도 마찬가지다. 특히 Next.js 같은 프레임워크를 다룰 때면 항상 고려할 수밖에 없는 플랫폼이고, 배포 속도나 프리뷰 환경도 굉장히 편하다. 다만 이번 프로젝트는 SSR 중심의 애플리케이션이라기보다는 정적 블로그이기 때문에 Vercel의 장점을 끝까지 활용하는 그림은 아니라고 느꼈다. 물론 Astro 프로젝트도 쉽게 배포할 수 있지만 이 경우에는 다른 플랫폼에 비해 기능이 너무 과하다는 생각을 떨칠 수 없었다.

Cloudflare Pages도 꽤 인상적인 선택지였다. 배포 자체도 빠르고, 정적 페이지를 다루는 경험도 좋다. Cloudflare의 타 서비스와의 연동성을 고려했을 때에도 정말 좋은 선택지이다. 다만 GitHub Pages와 비교했을 때 세팅 방식 또한 번거로우며, 이러한 플랫폼을 배포하기에는 적합하지 않았다.

이 프로젝트는 개발 블로그라는 성격이 강했고, 결국 GitHub 저장소와 함께 관리하는 흐름이 가장 자연스러웠다. 저장소 단위로 Pages를 관리할 수 있고 GitHub Actions와 연계해서 배포 흐름을 단순하게 유지할 수 있다는 점도 마음에 들었다. 무엇보다 플랫폼을 따로 이해하고 관리하는 데 에너지를 쓰기보다 GitHub 안에서 대부분의 흐름을 해결할 수 있다는 점이 내게는 크게 다가왔다.

그래서 최종적으로는 GitHub Pages를 기준으로 블로그를 구성하게 되었다. 아주 화려하거나 기능이 많은 선택은 아닐 수 있지만, 적어도 지금의 내 블로그에는 가장 단순하고 안정적이며 목적에 잘 맞는 선택이라고 생각한다.

AI 사용

앞의 기술 스택 파트에서도 이야기했듯이, 내게 블로그는 어디까지나 글을 쓰기 위한 플랫폼이지 개발 자체가 목적이 되는 것은 모순이라고 생각한다.

물론 블로그를 직접 제작한다는 것이 Arch Linux나 Linux From Scratch 처럼 직접 구성해 나가는 재미 또한 있다. 하지만 이번에는 그런 방향으로 시간을 오래 쓰고 싶지 않았다. 내게 더 중요한 것은 가능한 한 빠르게 블로그를 완성하고, 그 위에 글을 꾸준히 올릴 수 있는 상태를 만드는 일이었다.

그래서 이번 작업에서는 AI를 적극적으로 활용했다. 그렇다고 해서 모든 것을 AI에게 맡겼다는 의미는 아니다. 오히려 내가 중요하게 본 것은 “어떤 구조로 사이트를 짤 것인가”, “어떤 컴포넌트가 재사용 가능해야 하는가”, “어떤 부분은 직접 판단해야 하는가” 같은 기준을 먼저 세우는 일이었다. 그런 기준을 정한 뒤, 반복적이거나 초안 작성에 가까운 작업에서 AI의 도움을 받는 방식으로 진행했다.

개인적으로 AI를 사용할 때 가장 유용하다고 느끼는 지점은 생산성에 있다. 물론 초기 세팅이나 기본 뼈대를 잡는 일은 아직까지는 직접 하는 편이 더 낫다고 생각한다. 하지만 어느 정도 방향이 정해진 뒤에는, AI가 반복적인 코드나 비교적 표준적인 구조를 빠르게 만들어 주는 것이 꽤 큰 도움이 되었다. 내가 원하는 것은 “내가 이해할 수 있고 유지보수할 수 있는 구조를 빠르게 만드는 것”이었고, 그 점에서 AI는 꽤 잘 맞는 도구였다.

사람마다 이 부분에 대한 생각은 다를 수 있다. 누군가는 AI를 최대한 배제한 채 처음부터 끝까지 직접 만드는 과정 자체를 더 중요하게 여길 수도 있다. 그 역시 충분히 의미 있는 방식이다. 다만 나는 이번 프로젝트에서 “블로그를 만드는 경험”보다 “블로그를 운영할 수 있는 상태에 빨리 도달하는 것”을 더 중요하게 보았고, 그래서 AI는 꽤 합리적인 도구였다.

요즘은 Prompt Engineering이나 Harness Engineering처럼 여러 방식이 이야기되지만, 이번 프로젝트에서는 그렇게까지 복잡한 접근을 쓰지는 않았다. 대신 필요한 작업을 비교적 구체적으로 잘게 쪼개어 요청하는 쪽을 택했다. 예를 들어 Giscus를 붙일 때는 아래와 같이 요구사항을 정리해서 전달했다.

Giscus 컴포넌트를 src/components/ 경로에 새로 만든 다음 src/layouts/PostLayout.astro에 적용하도록 해. 아래 코드는 Giscus script 코드이고, 이를 기반으로 src/components/ThemeToggle.tsx에서 theme이 light일 경우 catppuccin_latte를, theme이 dark일 경우 catppuccin_mocha를 Giscus script element의 data-theme 속성에 적용하도록 해줘.

물론 모든 것을 AI에 의존하는 방식은 금전적으로나 기술적으로도 그리 좋은 선택이라고 생각하지 않는다. 무엇보다 그렇게 쌓인 코드는 나중에 이해 부채로 돌아오기 때문에 재사용성을 높여야 하는 이 프로젝트에서는 더더욱 부적합한 접근 방식이다. 그래서 나는 AI가 대신 결정하게 두는 것보다는 “내가 결정한 방향을 바탕으로 코드를 빠르게 생성하게 하는 것”에 가깝게 사용하려고 했다.

특히 AI를 활용할 때 React 같은 프로젝트에서는 버전 충돌로 인해 자꾸 버전을 다운그레이드 하는 대참사를 일으키는데, 이러한 부분에서는 버그 수정을 직접 하는 것이 훨씬 빠르고 토큰 소모도 적고 무엇보다도 스트레스를 적게 받았기 때문에 프로젝트 전반에 사용하는 것은 더더욱 회의적이다.

구조를 정하고 방향을 선택하는 것은 여전히 내 몫이었고, AI는 그 선택을 더 빠르게 구현하게 도와주는 도구였다. 적어도 이번 프로젝트에서는 그 정도 거리감이 가장 적절했다고 “느꼈다”.

블로그 제작이 25년도 12월부터 시작했고, 그 때는 당연하게도 그렇게 생각했으나 Codex와 Claude Code, Antigravity 같은 AI IDE가 발전하고 자주 사용하고 있는 지금에서는 이러한 생각이 많이 바뀌게 되었다. 만약 가능하다면 블로그 프로젝트는 아니어도 직접 구조 설계부터 AI를 활용하는 것이 훨씬 효율적이라는 생각이 강하게 들고 있으므로 이를 테스트해 볼 필요가 있다고 생각한다.

다음 문서에서는…

아직 이 문서에서는 내가 왜 이러한 블로그를 “직접” 개발하게 되었는지 같은 간단한 생각만 정리했다. 다음 문서에서는 기술적인 측면을 바탕으로 블로그를 어떤 식으로 개발하게 되었는지, 어떤 우여곡절이 있었는지 서술해 보고자 한다.