그리고 프레임워크에 대한 생각
내가 가장 선호하는 웹 앱 프레임워크는 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는 여전히 훌륭한 프레임워크이고, 그 영향력은 부정할 수 없다.
하지만 프레임워크가 더 많은 기능을 품을수록, 개발자가 짊어져야 할 복잡성의 무게도 커진다.
나는 프레임워크가 개발자의 자유를 제한하지 않고, 단순함을 유지하는 방향으로 진화하길 바란다.