기술을 뜯고, 사고를 담다.

6 분 소요

블로그를 다시 만들기로 했습니다

처음 개발 블로그를 선택할 때, 여러 블로그를 짧게 체험해봤습니다.
각각 장단점이 있었지만, 저는 GitHub Blog를 선택했습니다.

이유는 단순했습니다.
개발자들이 많이 사용하고, 직접 만들 수 있다는 점이 신기했고, 커스터마이징이 가능하다는 말에 끌렸습니다.
Github로 연동하여 제가 포스팅하는 것이 기록된다는 점도 매력적이었습니다. (흔히 말하는 잔디심기..)

그래서 유튜브에서 괜찮은 튜토리얼을 찾아 따라하며 블로그를 제작했고, 지금까지 잘 사용해왔습니다.
하지만 점점 문제가 하나둘 생기기 시작했습니다.

문제점

내 것인 줄 알았는데, 사실은 남의 것

처음에는 다른 개발자가 만든 테마를 그대로 가져와 사용했습니다. SCSS, HTML, JS로 구성된 구조였고, 많은 분들이 활용하던 테마였습니다.

하지만 블로그를 운영하면서 고민이 많아졌습니다. 레이아웃을 수정하고 싶을 때, 기능을 추가하고 싶을 때마다 “이게 어디서 정의된 거지?”, “무엇을 고쳐야 하지?” 라는 고민부터 시작해야 했고, 그 과정이 오래 걸렸습니다.

그러면서 이건 ‘직접 만든 블로그’가 아니라, 남이 만든 것을 ‘빌려 쓴 블로그’라는 것을 깨달았습니다.

Sass 경고문

어느 날부터 이런 경고문이 보이기 시작했습니다.

Deprecation Warning [slash-div]: Using / for division outside of calc() is deprecated

처음엔 단순한 경고라고 생각해서 넘기기도 했고, 한 번은 마음먹고 직접 수정해보려다 도중에 꼬여서 다시 원래대로 되돌린 적도 있습니다.

수정을 시도할수록 오류는 더 자주 터졌고, 경고는 줄어들지 않았습니다. 결국 ‘이 블로그, 이제 너무 낡았다’는 결론에 다다랐습니다.

블로그를 따라 만들 때까지만 해도, 작동하는 게 신기했고 기능을 찾아가며 나만의 블로그처럼 꾸미는 과정도 즐거웠습니다. 하지만 이번에는 처음부터 제대로 만들고, 구조를 직접 이해하며 유지할 수 있는 블로그를 만들고 싶었습니다.

유행을 쫓기 전에, 나만의 기준 찾기

요즘 개발자들 사이에선 Next.js, TailwindCSS, Zustand, Vercel 같은 스택이 유행처럼 사용되고 있습니다. 저도 처음 블로그를 다시 만들기로 했을 때, 이런 기술들을 아무 고민 없이 다 넣으려 했습니다. “요즘엔 이게 대세래~”라는 말만 믿고 말이죠.

하지만 어느 순간 멈춰서 생각하게 되었습니다.

“왜 나는 이 기술을 쓰려고 하는가?”

단순히 인기 있거나, 남들이 쓴다는 이유로 선택하는 것은 내가 진짜 만들고 싶은 블로그와는 거리가 멀었습니다. 그래서 기술 선택에 있어서 분명한 기준이 필요하다고 느꼈습니다.

분명한 기준 세우기

저는 블로그를 제가 이해하고 설명할 수 있는 구조로 만들고 싶습니다. 그래야 앞으로 직접 수정하고, 기능을 확장해나갈 수 있다고 생각합니다.

그래서 기술을 선택할 때 다음과 같은 기준을 세웠습니다.

✅ 내가 사용하는 기술의 선택 기준

  • 내가 만들고자 하는 블로그 목적에 잘 맞는가?
  • 이 기술이 어떤 목적에 적합한가?
  • 내가 직접 구조를 설명하고 유지할 수 있는가?

블로그 제작 목적

✔️ 프론트엔드 개발자로서의 기술 성장 기록을 담을 수 있는 공간
✔️ 커스터마이징이 쉽고, 유지보수가 가능해야 함
✔️ 기술 선택에 명확한 이유가 있어야 함
✔️ SEO, 퍼포먼스, 사용자 경험도 어느 정도 고려

기술 스택 선정

앞서 정의한 기준과 목적을 바탕으로, 블로그를 구성하기 위해 선택해야 할 기술 스택은 다음과 같습니다.

  • 프레임워크
  • 스타일링
  • 상태 관리
  • 콘텐츠 관리
  • 라우팅
  • SEO 및 메타 정보 관리
  • 배포
  • 버전 관리

각 항목별로 어떤 기술을 선택했는지, 그리고 왜 그렇게 결정했는지 아래에 자세히 설명하겠습니다.

프레임워크: Next.js

많은 개발자들이 React를 기반으로 프로젝트를 시작합니다. React는 훌륭한 라이브러리지만, 기본적으로 CSR (Client Side Rendering) 방식입니다. 즉, 사용자의 브라우저에서 자바스크립트가 실행된 뒤에야 콘텐츠가 보이기 때문에,

초기 로딩 속도가 느리고, 검색 엔진 크롤러가 콘텐츠를 즉시 인식하지 못하는 단점이 있습니다.

물론 React에서도 메타 태그를 설정하거나, SSR 환경을 별도로 구성해 SEO에 대응할 수 있습니다. 하지만 이는 추가 설정이 많고, 유지보수가 번거로운 방식입니다.

반면, Next.js는 기본적으로 정적 생성(SSG)과 서버 사이드 렌더링(SSR)을 지원합니다.
즉,

처음부터 SEO를 고려한 구조를 가질 수 있고,
렌더링 완료된 HTML이 전송되기 때문에 검색 노출에 유리합니다.

스타일링: Tailwind CSS

프로젝트를 진행하면서 저는 styled-components나 emotion 같은 CSS-in-JS 방식을 자주 사용해왔습니다. 동적 스타일링에 강하고, 컴포넌트 단위로 스타일을 관리할 수 있어 매우 유용한 도구들이었죠.

하지만 이번 블로그 프로젝트에서는 Tailwind CSS를 선택했습니다. 그 이유는 단순히 트렌드가 아니라, 다음과 같은 분명한 목적 때문입니다.

1. 디자인 시스템

Tailwind는 기본적으로 theme 설정이 강력해서 컬러, 폰트, 간격, radius 등 UI의 구성 요소들을 초기 단계에서 체계적으로 정의할 수 있습니다.

styled-components나 emotion에서도 테마를 구성할 수는 있지만, Tailwind는 config 중심의 명시적인 구조로 디자인 시스템을 빠르게 설계할 수 있는 점이 인상적이었습니다.

사실 저는 지금까지 디자인 시스템을 UI를 일정하게 유지하기 위한 규칙 정도로만 이해하고 있었습니다. 하지만 이번 블로그 프로젝트를 통해 단순한 UI 통일을 넘어서, ‘어떤 요소를 왜 이렇게 설계할 것인가’를 고민해보는 계기를 만들고 싶었습니다.

Tailwind의 theme 구조는 그런 질문을 직접 설정하고 체험해볼 수 있는 환경을 제공해주기 때문에, 이번 경험을 통해 ‘디자인 시스템’이라는 개념을 좀 더 깊이 이해하고, 기준을 잡아가고 싶습니다.

2. 생산성과 유지보수

Tailwind는 유틸리티 클래스 기반이기 때문에 스타일링에 필요한 클래스를 바로 HTML 요소에 붙여 사용할 수 있습니다. 이 방식은 컴포넌트를 빠르게 만들고, 반복적인 스타일을 손쉽게 재사용할 수 있어 혼자 개발하는 프로젝트에서 특히 효율적이라고 느꼈습니다.

유틸리티 클래스 기반이란?

한 가지 목적만 가진 아주 작은 CSS 클래스를 조합해서 스타일을 만드는 방식

styled-components / emotion은 컴포넌트 기반 스타일링 (Component-Scoped Styling)

3. 런타임 부담 없이 정적 최적화

CSS-in-JS 방식은 런타임에 스타일을 주입하는 구조입니다. 이로 인해 필요하지 않은 스타일이 함께 로딩되거나, 초기 렌더링 시점에 퍼포먼스 저하가 발생할 수 있습니다.

반면 Tailwind는 빌드 시점에 사용된 클래스만 추려내어 CSS를 생성하기 때문에 정적 사이트인 블로그에서 훨씬 가볍고 빠른 성능을 제공합니다.

4. 자유도보다 일관성을 우선

styled-components와 emotion은 자유롭게 스타일을 구성할 수 있는 장점이 있습니다. 하지만 블로그는 복잡한 동적 스타일링보다, 일관된 시각 구조와 빠르게 구축할 수 있는 생산성이 더 중요하다고 판단했습니다.

Tailwind는 “제한된 규칙 안에서 빠르게 디자인할 수 있게 도와주는 도구”로, 이번 프로젝트의 성격에 잘 맞는 선택이었습니다.

상태 관리: Zustand

블로그에서 상태 관리가 필요한 경우는 많지 않습니다.
다만 다크모드 토글, 검색 상태, 카테고리 필터 등 전역적으로 공유되어야 할 상태가 생길 수는 있습니다.

이때 불필요하게 무거운 Redux나 Context API를 쓰는 대신,
Zustand는 가볍고 간단하게 전역 상태를 관리할 수 있습니다.

  • 보일러플레이트가 거의 없음
  • 직접적인 getter/setter 방식으로 사용 가능
  • React와 결합도도 낮아서 유지보수에 부담이 적음

콘텐츠 관리: MDX (.mdx) + Contentlayer

블로그의 핵심은 콘텐츠입니다.
저는 글을 쓸 때, 웹 에디터보다 로컬에서 직접 .mdx 파일로 작성하고 Git으로 관리하는 방식을 선호합니다.
MDX는 Markdown에 React 컴포넌트를 포함할 수 있기 때문에, 정적인 글부터 인터랙티브한 컴포넌트까지 모두 표현할 수 있습니다.

Contentlayer를 함께 사용하면 .mdx 포스트를 정적 데이터처럼 불러올 수 있어,
타입 안정성과 페이지 구성 유연성을 모두 확보할 수 있습니다.

라우팅: Next.js App Router

Next.js의 App Router는 폴더 기반 라우팅 시스템을 제공합니다.
이 방식은 라우팅 구조를 코드 구조와 일치시킬 수 있어서 직관적이고 유지보수가 쉽습니다.

또한 페이지별로 layout을 분리할 수 있고,
generateMetadata() 함수 등을 통해 페이지 단위로 메타 정보를 설정할 수 있어
SEO 대응에도 유리한 라우팅 구조를 가질 수 있습니다.

블로그처럼 글 상세 페이지, 카테고리, 검색 결과 등 다양한 라우팅이 필요한 프로젝트에서
App Router는 개발자 경험과 유연성 모두를 잡을 수 있는 선택이었습니다.

SEO 및 메타 정보 관리: next-seo, sitemap, robots.txt

앞서 설명했듯이, 이 블로그는 단순히 기록을 남기는 공간이 아니라, 저의 기술 성장 과정을 보여주는 포트폴리오이기도 합니다.

따라서 검색 엔진에 잘 노출되고, 페이지별로 메타 정보가 잘 설정되어 있어야 합니다.

이를 위해 next-seo 라이브러리를 사용해 title, description, OG(Open Graph), Twitter meta 등을 관리할 예정입니다.
또한 sitemap 생성기, robots.txt 설정 등을 통해 검색 엔진 최적화 환경을 기본 구조로부터 갖춰나갈 계획입니다.

배포: Vercel

Next.js 프로젝트에 가장 최적화된 배포 환경은 단연 Vercel입니다.

  • GitHub에 푸시하면 자동으로 빌드 및 배포
  • custom domain 설정도 간편
  • preview 기능으로 브랜치별 배포 확인 가능
  • 무료 티어로도 블로그 운영에 충분

Vercel은 특히 블로그처럼 빠른 피드백 루프와 지속적인 변경이 필요한 프로젝트에 잘 맞습니다.
저처럼 자주 글을 수정하고, 디자인을 업데이트하려는 개발자에게 매우 효율적인 배포 플랫폼입니다.

버전 관리: Git + GitHub

블로그의 소스 코드뿐 아니라 Markdown으로 작성된 포스트까지 모두 Git으로 버전 관리합니다.
이를 통해 언제든지 수정 이력을 추적하고, 한 줄의 문서 수정조차 기록되는 개발자다운 기록 구조를 유지할 수 있습니다.

또한 GitHub와 연동하면 Vercel 배포, Giscus 댓글, 오픈소스 기록까지 모두 연결되기 때문에 블로그가 곧 나의 활동 이력이자 포트폴리오의 일부가 됩니다.

🧩 내가 선택한 기술 스택 요약

이렇게 기준을 세우고, 제가 원하는 블로그의 목적에 맞춰 기술을 하나씩 골랐습니다. 어떻게 보면 결국엔 요즘 유행하고 있는 조합이 왜 많이 사용하는지 알 수 있었던 것 같습니다. 선택한 기술 스택은 다음과 같습니다.

항목 선택한 기술 선택 이유
프레임워크 Next.js SEO 대응 / 구조적 설계에 유리
스타일링 Tailwind CSS 빠른 스타일링 / 디자인 시스템 설계 가능
상태 관리 Zustand 가볍고 필요한 기능만 담을 수 있음
콘텐츠 관리 MDX (.mdx) + Contentlayer Git으로 버전 관리 가능 / MDX 기반으로 컴포넌트 사용 가능 / Contentlayer로 타입 안정성과 페이지 유연성 확보
라우팅 App Router (Next.js) 구조와 URL 일치 / SEO 메타 관리 용이
SEO 관리 next-seo + sitemap + robots.txt 검색 최적화 / SNS 공유 대응
배포 Vercel 자동화된 CI/CD / 빠른 피드백 루프
버전 관리 Git + GitHub 코드, 글 모두 추적 가능 / 협업 및 오픈소스 대응

이번 포스트에서는 블로그를 새로 만들게 된 배경과, 기술을 선택하는 과정에서 어떤 고민을 했는지 담았습니다.

어쩌면 이 블로그보다 더 나은 결과가 아닐 수도 있겠지만, 미리 겁먹기보다는 일단 시작해보려 합니다. 꾸준함이 제 무기가 되고, 익숙한 습관이 될 수 있도록!

카테고리:

업데이트:

댓글남기기

참고