개요
개인적으로 당연히 취향과 선호도가 있긴 하지만, 개발이라는 분야를 한정한다면 그런 것이 무뎌지고 있긴하다.
2010~2012년까지만해도 C++ 이외의 언어는 고르고 싶지도 않았지만, 다양한 언어와 기술을 쓰다보니 더더욱 기술에 대한 편견은 사라지고 가능하면 많은 언어나 프레임워크를 접해서 시야를 넓히는 것이 좋다고 생각하고 있다.
그렇다보니 Unity 3D나, Vue.js 등을 가볍게 다룰 수 있었고, Flutter도 사용해보는 등 백엔드나 서버 한정적인 접근 보다는 조금 더 다양한 것을 하는 것을 즐기는 편이다.
그런 성향이기도 했지만, 회사와 속한 팀의 성향상 프론트엔드 개발자가 부족했고, 반은 강제, 반은 호기심으로 부담감은 조금 가진 상태에서 Next.js 를 접하게 됐다.
부담감
부담감이 있었던 이유는 React.js가 Vue.js 보다 어렵다는 이야기를 들었기 때문이고, Vue.js 를 쓰긴 했지만 그 기간도 짧았고, Vue.js를 적응하기 위해 만들었던 토이 프로젝트도 가볍게 진행했으나 그 깊이도 깊지 않았으며, 자바 스크립트라는 언어 자체에 대한 선호도가 높지 않았다보니 토이 프로젝트의 수 자체도 부족했다.
DOM과 css를 적용하는 것은 이전에는 퍼블리셔가 있었다 보니 css+DOM까지 작성해서 전달 받았었고, 로직을 그 위에 얹는 작업이 주였기 때문이었고, Admin 웹의 경우에는 디자인 적용에 디테일은 포기해도 됐기 때문에, css를 다루는 역량이 필요 없었기에 css를 잘 다루지 못했다보니 이 부분에 대한 걱정이 좀 더 컸다.
아무래도 Public 웹의 경우 css도 아주 중요한 요소가 되기에 이러한 부분에 부담감이 좀 있었는데, 동료의 도움을 받아서 Vue.js를 학습 했을 때 보다 훨씬 더 많이 적응이 된 좋은 계기가 됐다.
장점
서버 사이드 렌더링이 포함된 프레임워크라는 장점이 꽤 있었다.
사용자에게는 노출하고 싶지 않은 처리를 할 수 있는 장점은 아주 크게 다가왔다.
React 기반이라는 것도 장점인데, 관련된 레퍼런스도 아주 많아서 좋았다.
routing 구조가 파일이름이나 디렉토리 구조에 매핑되다보니 해당 로직을 처리하는 코드를 찾아가기 쉬웠다.
단점
훅의 순서 조정이 원하는 대로 되지 않았다.
그렇다 보니 훅을 통한 순서 제어로 데이터를 필터 혹은 변환하고 이를 받아서 적용하는 방식은 어려웠다.
관련된 작업이 필요할 경우는 직접적인 함수 호출을 하는 것이 좋다고 볼 수 있었다.
또한 서버가 필요한 구조다보니 관리 코스트가 추가적으로 발생한다.
물론 대부분 서버 사이드 렌더링 과정에서 하는 일이 request, response, 변환, 예외 처리 등이지만 그러한 작업 자체도 클라이언트 사이드가 아니다보니 성능 이슈가 발생할 여지가 있는 서버, 스케일 업/아웃이 필요한 관리 코스트와 서버 비용 자체가 발생할 수 있음을 의미하기도 한다.
Type Script
타입 스크립트를 적용하기는 처음이었다.
자바 스크립트가 필요한 경우에도 그냥 자바 스크립트를 썼을 뿐, 타입 스크립트를 써보지 않았었는데 그 만족도가 강타입 기반 언어 만큼은 아니지만 꽤 높았다.
조금 더 적극적으로 사용하면 강 타입 기반 언어의 장점을 꽤 누릴 수 있을 거라는 기대감도 들 만큼 만족스러웠던 부분이다.
마치며
JScript (윈도우에 오래된 자바 스크립트 내장 엔진)으로 처음 접했던 자바 스크립트에 대한 편견이 (Vue.js를 종종 썼음에도) 남아 있다 보니 시간을 내서 별도로 학습이나 사용한 경우도 적었기에 능숙하다고 말하긴 어려운 상태였다.
내 관심사가 자바 스크립트를 잘 쓰는 것 보다는, 다른 언어나 프레임워크를 배우거나 사용하는 것을 선호했던 것도 영향이 컸다고 볼 수 있겠다.
부담감은 조금 갖고 접하게 됐지만, 적응하고 나니 확실히 여러가지 장점이 있는 것 같다.
특히 타입 스크립트의 사용 경험도 아주 좋아서, 가볍게 만드는 토이 프로젝트도 Next.js로 해보고 싶은 마음도 생겼고, 조금 더 다 방면의 경험을 하게 된 것도 좋았던 시간이었다.