Next.js 와 Astro 를 같은 회사에서 같이 쓴다
왜 프레임워크를 하나로 통일하지 않았는가 — Next.js와 Astro를 동시에 운영하는 이유와 각각의 역할을 공유한다.
“프레임워크는 하나로 통일해야 한다”는 말을 자주 듣는다. 학습 비용, 코드 공유, 팀 내 일관성. 다 맞는 말이다. 그럼에도 우리는 Next.js와 Astro를 같은 팀에서 함께 쓰고 있다. 이 글은 그 이유와, 실제로 운영하면서 어떻게 역할이 나뉘었는지에 대한 기록이다.
어쩌다 둘이 함께 쓰게 됐나
처음에는 Next.js 하나로 모든 것을 했다. 동적 웹 애플리케이션, 마케팅 페이지, 블로그. 하나의 저장소, 하나의 프레임워크. 그런데 블로그와 문서 페이지를 운영하다 보니 문제가 생겼다.
변경 빈도가 낮고 대부분 정적인 콘텐츠인데, Next.js 앱 전체를 거쳐야 배포가 된다. 콘텐츠 작성자가 글을 추가할 때마다 빌드 파이프라인이 돌아간다. 글을 한 편 올리기 위해 리액트 컴포넌트가 번들링되고 서버 사이드 로직이 포함된 전체 앱이 배포되는 것이 점점 비효율처럼 느껴졌다.
Astro를 시험해봤다. 기본적으로 JavaScript를 거의 보내지 않는 정적 사이트 생성기다. 마크다운 기반 콘텐츠 관리가 편하고, 빌드가 빠르고, 배포가 단순하다. 블로그와 문서 사이트를 Astro로 옮겼더니 배포 흐름이 훨씬 가벼워졌다.
역할 분리
지금의 기준은 이렇다.
Next.js: 인터랙션이 있고, 인증이 필요하고, 서버 사이드 로직이 들어가는 서비스. 사용자 계정이 있는 애플리케이션, 대시보드, API와 연결된 페이지들.
Astro: 콘텐츠 중심의 정적 사이트. 블로그, 문서, 회사 소개 페이지처럼 자주 바뀌지 않고 JavaScript가 많이 필요하지 않은 곳.
실제 운영에서 느낀 것
두 프레임워크를 함께 쓴다고 해서 학습 비용이 두 배가 되지는 않았다. Astro는 기본 문법이 단순하고, HTML과 마크다운에 익숙하면 빠르게 적응된다. 팀 내에서 Astro 작업은 주로 콘텐츠 수정이나 간단한 레이아웃 변경이라, Next.js에 익숙한 사람도 큰 무리 없이 할 수 있다.
코드 공유는 일부 타입 정의와 유틸리티 함수 정도다. 디자인 토큰(색상, 타이포그래피 변수)은 CSS 변수 형태로 두 곳 모두에 동일하게 적용해서 시각적 일관성을 유지한다.
한 가지 주의할 점은 두 프레임워크의 라우팅 방식이 다르다는 것이다. 이것 때문에 URL 구조 설계 초기에 혼란이 있었다. 지금은 서브도메인으로 완전히 분리해서 각자의 라우팅 규칙을 가지도록 했고, 그 이후로는 문제가 없다.
모든 팀이 이렇게 해야 한다고 생각하지는 않는다. 하지만 도구를 용도에 맞게 고르는 것이, 하나의 도구로 모든 것을 해결하려는 것보다 나을 수 있다는 것을 이 경험에서 배웠다.
— by slecs