DevLog
개인 블로그 리뉴얼 회고: Next.js 16 + DaisyUI + MDX로 처음부터 다시 만들기
2026년 03월 03일5분 읽기
DevLog
기존 블로그가 있었지만 디자인이 마음에 들지 않았고, 기술 스택도 업데이트하고 싶었습니다. 이번에 Next.js 16 + DaisyUI + MDX 조합으로 블로그를 처음부터 다시 만들면서 배운 점과 삽질 기록을 정리합니다.
기존 블로그의 문제점은 명확했습니다.
목표는 분명했습니다. "기술 블로그이자 포트폴리오가 되는 사이트를 만들자."
| 영역 | 선택 | 대안 | 선택 이유 |
|---|---|---|---|
| Framework | Next.js 16 (App Router) | Gatsby, Astro | RSC 지원, 익숙함, Vercel 배포 편의성 |
| UI Library | DaisyUI 5 | shadcn/ui, Chakra UI | 빠른 프로토타이핑, 테마 시스템 내장 |
| Styling | Tailwind CSS 4 | SCSS, styled-components | DaisyUI와의 궁합, 유틸리티 퍼스트 |
| Content | MDX (next-mdx-remote) | Contentlayer, Notion API | 파일 기반 관리, 유연한 커스터마이징 |
| Animation | Framer Motion | GSAP, CSS Animation | React 생태계 통합, 선언적 API |
| Theme | next-themes | 직접 구현 | SSR 호환, 깜빡임 방지 내장 |
전체 리뉴얼 과정을 커밋 히스토리 기준으로 돌아봅니다.
초기에 RotatingText 컴포넌트부터 만든 것은 좋은 선택이었습니다. 랜딩 페이지의 핵심 요소를 먼저 프로토타이핑하면서 프로젝트의 분위기를 잡을 수 있었습니다.
가장 오래 걸린 부분은 Typography 스타일링이었습니다. rehype-pretty-code가 생성하는 코드 블록의 HTML 구조에 맞춰 CSS를 커스터마이징하는 작업이 예상보다 복잡했습니다.
가장 빈번하게 만난 에러입니다. 서버에서 렌더링한 HTML과 클라이언트에서 렌더링한 HTML이 다르면 발생합니다.
주요 원인:
useTheme()으로 가져온 테마값을 서버 렌더링 시 사용 → 서버에는 테마 정보 없음Date 객체의 로케일 차이 → 서버(UTC)와 클라이언트(KST)의 날짜 포맷이 다름window 객체 접근 → 서버에는 window가 없음해결 패턴:
const [mounted, setMounted] = useState(false);
useEffect(() => { setMounted(true); }, []);
if (!mounted) return null; // 또는 스켈레톤 UI모든 클라이언트 전용 로직은 이 패턴으로 감싸야 합니다.
개발 환경에서는 잘 되는데 빌드만 하면 실패하는 경우가 있었습니다. 주로 import 경로가 대소문자와 일치하지 않거나, tsconfig의 path alias가 제대로 설정되지 않은 경우였습니다.
// tsconfig.json - path alias 설정
{
"compilerOptions": {
"paths": {
"@components/*": ["./src/components/*"],
"@lib/*": ["./src/lib/*"],
"@config/*": ["./src/config/*"]
}
}
}rehype 플러그인의 실행 순서가 결과에 영향을 줍니다. rehypePrettyCode가 rehypeSlug보다 먼저 실행되어야 코드 블록 내의 텍스트가 heading으로 잘못 인식되는 것을 방지할 수 있습니다.
CMS 없이 MDX 파일만 추가하면 되는 구조 덕분에 글쓰기 진입장벽이 매우 낮습니다. IDE에서 바로 글을 쓰고, git push하면 배포까지 자동으로 됩니다.
반투명 유리 느낌의 디자인을 일관되게 적용한 것이 사이트의 아이덴티티가 되었습니다. Tailwind의 유틸리티 클래스로 재사용 가능한 스타일 패턴을 만든 것도 좋은 접근이었습니다.
DaisyUI + next-themes 조합으로 깜빡임 없는 테마 전환을 구현했습니다. 코드 블록, 로고, 배경 모두 테마에 맞춰 자연스럽게 전환됩니다.
블로그를 직접 만들면서 가장 크게 느낀 점은, "완벽하게 만든 뒤에 글을 쓰자"는 생각이 잘못이라는 것입니다.
처음에는 모든 기능을 다 만들고 나서 글을 쓰려고 했지만, 결국 글을 쓰면서 필요한 기능이 보이고, 그 기능을 만들면서 또 글감이 생깁니다. 콘텐츠와 플랫폼을 동시에 발전시키는 것이 가장 효율적인 방법이었습니다.
또한 블로그 자체가 포트폴리오가 된다는 점에서, 프론트엔드 개발자에게 자체 블로그는 최고의 사이드 프로젝트입니다.
리뉴얼은 끝이 아니라 시작입니다. 앞으로도 글을 쓰면서 블로그를 계속 발전시켜 나갈 예정입니다. 비슷한 고민을 하시는 분들에게 이 회고가 참고가 되었으면 합니다.
개발 블로그의 가장 큰 가치는 완성도가 아니라 꾸준함에 있다고 생각합니다.