본문으로 건너뛰기

Next.js에 대한 생각

· 약 2분

그리고 프레임워크에 대한 생각

내가 가장 선호하는 웹 앱 프레임워크는 Next.js이다.

풀스택 웹 앱을 개발할 때, Next.js + Supabase 스택이 "가장 간단한 엔지니어링" 이라고 믿었기 때문이다.

참고로 나는 인스타그램 초기 엔지니어링 팀이 따랐던 핵심 소프트웨어 개발 3원칙을 굉장히 좋아한다.

1. 간단하게 유지할 것 (Keep things very simple)
2. 바퀴를 재발명하지 말 것 (Don’t re-invent the wheel)
3. 가능하면 입증된 견고한 기술을 사용할 것 (Use proven, solid technologies when possible)

나는 엔지니어링의 고통이 복잡함에서 발생한다고 생각하기 때문에, 이 3가지 원칙을 굉장히 중요하게 생각한다.

그런데 최근 Next.js 16 릴리즈를 보니 그들은 "엔지니어링 고통의 총량"을 줄이는 것에는 큰 관심이 없는 것 같다고 느꼈다.

Next.js가 아쉬운 지점​

1) 과도한 기능으로 인한 복잡도​

Next.js는 CSR, SSR, SSG, ISR 등 모든 렌더링 방법을 한 프레임워크에서 사용할 수 있도록 했지만, 이는 단순성을 잃게 했다고 본다.

개발자는 코드의 런타임이 빌드 시점인지, 서버 사이드인지, 클라이언트 사이드인지를 매번 고민해야 하기 떄문이다.

2) 강결합​

수십 년간 소프트웨어 공학에서 검증된 원칙은 느슨한 결합과 명확한 계층형 구조이다.

하지만 Next.js는 라우터, 번들러, 런타임이 강하게 결합되어 있다.

File system 기반 라우팅, Server component, Server action, Route segment config 등 너무나 많은 기능들이 Next.js에 종속적인 기능이다.

3) 안정성​

Next.js는 여러가지 문제 해결을 돕는 훌륭한 프레임워크다. 하지만 아직도 너무 많은 버그가 존재한다.

실제로 제품을 만드는 것보다 Next.js 버그를 해결하기 위한 시간이 더 많이 소비되는 일도 허다하다.


맺으며​

Next.js는 여전히 훌륭한 프레임워크이고, 그 영향력은 부정할 수 없다.

하지만 프레임워크가 더 많은 기능을 품을수록, 개발자가 짊어져야 할 복잡성의 무게도 커진다.

나는 프레임워크가 개발자의 자유를 제한하지 않고, 단순함을 유지하는 방향으로 진화하길 바란다.

참고한 글​