개요

어쩌다가 Next.js를 13.4로 올리면서 바뀐 부분을 체크해 보면서 느낀 점들을 정리해 보자.

배경

그르니까 내가 원래는 Graphql client를 기존 코드에 붙이려고 여기저기 찔러보고 있는데 말야… 웹페이지 중 일부 영역에만 적용하게 될 것 같은데 전역 Context에 Client를 때려넣는 건 조금 이상하잖아? 그래서 찾아보니까 Next.js를 13.4로 업그레이드하면 subpath에서 부분적으로 Context를 정의할 수 있다고 하는게 아니겠어? 그래서 한번 13.4로 업그레이드하고 이걸 써보려고 했는데 글쎄 이 기능을 쓰려면 App router라는걸 써야하고 서버 측에서 렌더링을 뿌려주는 거라는 거 있지?

느낀점들

1. 클라 최적화를 했으면 이거 다 쓸모없다

어차피 나만 쓰는 앱이니까, 나한테 맞춰서 많은 최적화를 해 뒀단 말이지. 이를테면 컨텐츠를 보여줄 때, 다음 내용도 몇페이지씩 미리 불러놓고 바로 바로 보여주고, 그렇게 캐시해놓은 내용이 몇페이지 안남았으면 미리 다음내용 땡겨서 불러놓고 해서 인터넷이 잠깐 끊겨도 대부분의 경우 1ms 내에 페이지 넘김이 가능하게 다 짜놨단 말야.

근데 서버 사이드 렌더링을 염두에 두니까 이런 최적화가 다 이상해지는거야. 처음 렌더링 시점에야 딱 보이는 컨텐츠를 서버에서 렌더링해서 바로 보내주니까 조금 빨라질 수 있을 거라고 생각해. 근데 그 다음에 페이지 넘어갈 땐? 서버에서 캐시까지 미리 다 채워서 보내주는건 좀 이상하지 않아?

2. “use client”는 진짜 이상해 보인다.

사실 개발자 입장에선 ‘use strict’도 안쓴다. 그냥 모든 코드는 기본적으로 strict고, typescript에서 알아서 강제해주니까 그냥 내버려 두는 거지…

좀 더 명시적으로 서버/클라를 지정하는 게 좋지 않았을까? 코드 자체적으로 자기가 어디서 렌더링되는 지 모르고 자기를 import하는 녀석이 ‘use client’를 쓰냐 마냐에 따라 결정되는 구조는 쓰는 사람이 많은 노력을 기울이게 만든다.

3. Graphql은 쓸 필요가 없어짐. 못쓰는건 아니지만…

서버에서 이미 복잡한 데이터 다 정리해서 딱 보여줄 페이지만 보내주도록 했으면 클라에서 다시 복잡한 데이터를 요청할 이유가 상당부분 사라짐. 그러고 나면 대개 한 종류의 데이터만 필요한 경우가 대부분이니 REST API로도 적당히 처리가능하다고 생각됨. 그치만 이미 API 서버를 Graphql로 구성했다면 이미 내친 걸음이니 계속 그렇게 써야지 뭐.

4. Context는 쓰기 어렵다

서버 렌더링 하는 시점에서 Context는 매번 페이지 요청 시마다 새로 계산하는 것이나 다름없게 된다. Client 렌더링을 딱 정해서 거기 안에서만 Context를 써야 하는데 첫인상에는 그거 설정하는게 여러모로 쉽지 않아보였다.

5. 얘네가 서버 팔아먹으려고 작정했구나

물론 서버 렌더링이 경우에 따라 레이턴시도 적게 나오고 좋을 수 있다는 거 이해해. 근데 어느정도 선택권을 주면서 약을 팔아야지 서버 렌더링을 기본값으로 놓고 standalone 배포를 거의 막다시피 하는 방향으로 버전업을 한다는건 얘네가 이걸 팔아먹는 데 사활을 걸었다는 소리인데… 자기네 서버 상품 팔려고 이렇게 하나? 싶은 의구심이 든다.

결론

아 진짜 시간 낭비했고 그냥 전역 컨텍스트 빵빵 쓰면서 마구 무겁게 짜버릴 테다.