넉스트(nuxt) 사용 후기

넉스트를 사용하면서 강좌를 하고 있는 이유는 실무에 실제 반영해보고, 좀 더 빠른 개발의 길로 이끌어 보고 싶은 마음에서 였습니다.

파이어베이스와 넉스트만 손잡으면 뚝딱 모던웹 사이트 하나 만들어지는 놀라움에 시작하게 된 것 같습니다.

여기서 정성을 조금만 더하면 충분히 실무에서 사용할 수 있다는 생각이 컸습니다.

이것 저것 시도해보고 느낀 점을 공유해봅니다.

장점

골격(스캐폴딩)

기본생성하고 일반적인 골격이 완성되어서 복잡하지 않은 사이트를 정말 순식간에 만들 수 있습니다.

페이지만 추가하고 몇가지 설정만 바꾸면 끝이라 정말 생산적입니다.

SEO 검색

SPA의 경우 결국 index.html 하나인 반면.. 넉스트는 검색을 위해 여러 페이지를 만들 수 있어서 블로그를 만들 수도 있습니다.

eg) x.com/19-06-17_어쩌고, x.com/about 등이 구글에서 검색이 가능합니다.

개발 편의

백/프론트를 같이 할경우 일관성있는 개발환경입니다.

단점

제가 느끼기에는 아직 문제점이 더 많아 보입니다.

사용자 수

느낌일 수도 있는데.. 생각보다 많이 사용자가 많지 않은 것 같습니다.

구글링이 결과가 많치 않아서 어렵습니다..

문제 해결(트러블 슈팅)

사용자 수가 많지 않다보니 공식홈에 의지 해야할 때가 많습니다.

대부분 해결 되는 문제가 많지만.. 아닌 경우가 문제 입니다.

예를 들어 파이어베이스 구글로그인을 하려고 signInWithPopup 이라는 함수를 공식 홈에 맞춰서 호출 했을 뿐인데 의문의 에러가 나오고 맙니다.

보통 정 안될 경우 에러내용으로 구글링을 할 경우(nuxt + 에러내용) 많은 개발자들이 걸쳐 있는 이슈에 걸려서 현재 버전에 뭐가 문제가 있구나 정도는 알아야되는데.. 아무것도 안나옵니다.

당장 기본 뷰cli3로 만들어서 테스트하니 잘 되었습니다.

모듈

@nuxtjs로 시작하는 넉스트 모듈중 @nuxtjs/recaptcha를 지난 강좌에서 사용했는데 제대로 동작하지 않아서 꼼수를 쓸 수 밖에 없었습니다.

비 인기 모듈이라 그럴 수도 있겠지만 설명이 부족한 것이 문제입니다.

그래서 플러그인 하나 설치할 때도 플러그인.js를 만들어야 되나 고민하게 만듭니다..

호환성

파이어베이스의 경우도 그러한데..

강좌에서는 파이어베이스 최신 버전이 맞지 않아서 어쩔 수 없이 5.5 버전을 사용했습니다.

파이어베이스 버전이 문제일 수도 있다는 생각에 최근 버전인 파이어베이스 6.2 버전으로 재설치했더니 역시나 안되었습니다.

결국 core-js라는 놈이 문제인데 3버전이 안맞는 것이죠..

결국 yarn add core-js@^2.0.0(2버전 최고)을 설치해서 해결은 했습니다.

이런 식의 땜빵식 설치는 제가 매우 싫어하는 행위입니다.

이러한 방법을 어딘가에 기술해야 하고.. 복잡도를 증가시켜서 관리의 어려움을 가지게 하기 때문입니다.

삼류 모듈도 아니고 실리콘밸리를 주름잡는 파이어베이스 같은 메이저 모듈이..

yarn add firebase로 설치가 안된 다는 것은 접근성에서 F학점입니다.

빌드 시간

백&프론트가 다되고 미려한 cli UI가 있는 것은 분명 매력이지만 너어무 느립니다.

특히 nuxt.config.js 등을 건들면 핫리로드가 안되서 다시 빌드해야 하는데 정말 우울합니다.

게다가 자원 점유도 상당해서 50% 이상의 확률로 쓰로틀링이 걸리는 지 맥북의 팬이 돕니다.

최근에 게임시간이 늘었습니다.. 빌드나 배포할 때마다 게임을 하는데.. 게임시간이 더 많아지고 있음..

난이도

페이지만 추가하면 자동으로 제네레이트 해서 라우팅되어 편리하고 쉬울 것 같지만..

생각보다 많은 지식을 가지고 있어야합니다.

우선 페이지 렌더링 원리부터 머리속에서 상상하면서 코딩해야합니다.

예를 들어 $vuetify라는 전역변수는 서버사이드가 아니기 때문에 클라이언트에서 만 구동하도록 no-ssr등의 태그가 필요하게 됩니다.

SSR의 개념을 모른 체로 막 만들어지니 신기하네 하고 덤비면 더욱더 깊은 나락으로 갈 수 있습니다.

왜?

하다보니 왜 넉스트를 써야하는 지 의문이 생겼습니다.

사실 순수 뷰CLI3로 작성해도 SPA만 되는 것은 아닙니다.

사실 뷰라우터를 안쓰던 다른 방법을 고안하면 그만입니다.

남은 건 편의성입니다.

편의성이라 함은 결국 시간을 단축 시켜줘야하는데.. 트러블슈팅 시간이 길어짐에 시간이 더 늘어나는 것 같습니다.

결론

넉스트의 장점을 활용할 프로젝트에서만 사용하면 될 것 같습니다.

제 생각에는 검색(SEO)이 필요한 포트폴리오용 사이트(회사 홈페이지, 블로그등)에 적합해보입니다.

빠르고 간편하게 스캐폴딩된 선에서 적당한 기능을 하는 사이트를 만들면 됩니다.

반대의 경우 추천하지 않습니다.

제가 짧은 지식에 제대로 못 다루기 때문에 문제가 있을 수 있습니다.

하지만 그 자체가 문제일 수도 있습니다.

플랫폼 전쟁의 승자는..

고수가 더 빨리 잘 하는 것이 중요한 것이 아닌 하수가 더 많이 유입되게 하는 것이 중요하다고 생각하기 때문입니다.

결국 생산성입니다.

잊지 말아야 합니다.

개발자는 뷰, 리액트, 파이썬, 노드, 데이터베이스등을 공부하는 것이 목적이어서는 안됩니다.

개발자는 무언가를 만드는 것이 목적입니다.