NextJs의 Image컴포넌트 방식이 anti-pattern인 이유

저 역시 실제로 서비스하는 앱을 개발할때 nextJs로 시작했습니다. 아무래도 워낙 유명했기 때문이죠.

돌이켜보면 마케팅 등 사업 운영적인 부분이 vercel이 뛰어났던거 같습니다. 점점 더 이런 부분들도 기술의 흥망에 차지하는 비중이 커지는거 같아요.

무튼 저는 현재 여러 nextjs의 대안중 qwik이라는 framework를 사용중이고 실제 서비스를 개발해서 현재까지 만족스럽게 사용중입니다.

이번 글은 qwik에 대한 소개는 아니고 왜 NextJs의 Image컴포넌트 방식이 anti-pattern인지 설명하려고 합니다.

anti-pattern은 얼핏 엄청 좋아보이는데 기술부채가 빠르게 쌓이는 성향이 강한 방식이라고 정의하겠습니다.

앞서 말했듯 web-server의 성능에는 이미지 최적화가 정말 중요합니다.

여기에 nextjs는 프론트 앱 하나로 이미지 리소스를 가공해서 최적화된 여러 버전(앞으로 mutation뮤테이션이라고 부르겠습니다)으로 바꿔주고, 이를 매우 손쉽게 img tag랑 연결시킵니다.

저 역시 cdn이나 img tag의 srcset, sizes등에 대한 지식 없이도 자연스럽게 활용했으니 정말 편리하죠. 근데 이래도 되는걸까요?

이미지 처리는 기본적으로 고비용이고, 이미지 조회는 웹서비스에서 굉장히 자주 일어나는 일입니다.

그리고 이런 고비용의 일은 웹서버에서 분리해서 별도의 인프라로 구성하는 것이 안전하고 운영비용이 저렴합니다.

가격 정책상 웹서버 자체의 스펙을 올리는 것보다 웹서버 자체의 스펙은 최저로 두고 고비용 일들은 따로 최적화 시켜서 처리하는게 더 저렴하기 때문이죠.

실제로 제가 처음 다른 서비스를 런칭했을때 가끔 서버가 다운되는 일이 있었습니다. 정확한 이유를 못찾았는데, 알고보니 인피니티 스크롤 + nextjs 이미지 프로세싱이 만나면서 생긴 일이었죠.

당시 제 서버는 aws freetier의 1gb 메모리 ec2를 사용중이었죠. 인피니티 스크롤의 아이템 수가 저희가 업로드 하는거라 개수가 그렇게 많지 않다고 생각해서 페이지네이션을 따로 안했었는데, 이걸 위에서 아래로 스크롤을 쭉 해버리면 서버가 이미지 처리에 터졌던거였습니다.

물론 당시에 페이지네이션의 중요성을 깨달았던 계기였지만, 그에 못지않게 web-server에서 이미지 처리하는 것의 위험성을 알게되는 일이기도 합니다.

nextjs를 쓰는 입장에서는 이미 구현되어있고 너무 편하다는 것은 이해합니다만, 이게 전형적인 anti-pattern의 성향이죠.

전 성능을 좀 따지는 편이고 nextjs가 성능이 별로라고 생각해서 다시 쓰진 않을거 같지만 다시 쓰더라도 image처리하는 부분은 반드시 별도의 인프라로 구성할거 같습니다.

어차피 한번 해두면 손댈일이 없으니까요.