재테크 블로그 프로젝트 (2) - 기술선정

개요 

 

이번 프로젝트 만큼은 기술 선정 이유를 정하고 시작하기로 계획 했기에 본격적 개발 직전에 프레임워크와 기타 기술들 선정 이유들을 정리하고자 한다.

타이밍 좋게 학교 과제 중에서도 front-end 개발 기술스택을 정리해야하는 과제가 있다.

지라는 어렵다....

 

TypeScript 

이제는 선택이 아닌 필수가 되어버린듯한 타입스크립트 얼마 전 수업 중 리액트 실습하는 시간이 있었는데 일반 js로 파일을 작성하다보니 props 혹은 함수에 타입지정을 하지 않다보니 불러오거나 사용할 때 내부 요소가 뭐가 들어가야하고 타입 오타가 있는지에 대해 스스로 점검 해야하는 불편함이 있었다.

 

실습이니 망정이지, 프로젝트였다면 분명 엄청 번거로웠을 것이다. 그리고 이번 프로젝트의 경우 팀원 3명과 작업하기에 TypeScript가 필요한 이유는 더 없이 많다.

 

1. 타입 안정성: 함수, 변수, 객체등을 정의할 때 타입을 지정해 나중에 해당 요소들을 사용할 때 오류를 줄일 수 있다. 무엇보다 api 가져오는 타입을 interface로 선언해 가져올 때 정말 편리하게 사용한다. 무슨 값들이 어떤 type으로 들어가야하는지 선언하고 다른 api에서도 같은 타입이 사용되는 경우 재사용도 가능하기에 협업에도 유용하게 쓰인다.

 

2. 유지보수성 향상 : 여러 사람들과 작업하다보면 코드 스타일도 다르고, 회원가입시 필요한 정보를 다 따로따로 처리하는 사람도 있고, 한번에 객체로 묶어 처리하는 경우가 있는데 따로 타입을 지정할 경우 코드리뷰같이 서로의 코드를 볼 때 해당 타입의 존재를 인지하고 코드를 재사용이 가능하다. 또한, 향후 해당 파트에서 변경, 오류가 발생해도 같은 타입으로 지정한 코드들을 수정하기 편리해진다.

 

4. 도구 지원 : TypeScript는 Vscode 익스텐션에서 편리한 기능도 많고 기본적으로, 자동 완성, 타입 검사  리팩토링이 가능해지고 확실히 규모가 크면 클 수록 개발 속도가 빨라짐을 느낄 수 있다.

 

NextJS

다른 것보다 프레임워크를 선정할 때 많은 고민이된다. 그 이유는 어떤걸 쓸까보다 왜 이걸 내가 쓸건지에 대해서 ~가 좋다더라, ~가 지원된대 하더라도 막상 쓰다보면 결국 익숙한 스타일로 사용하게 된다. 그리고 이 방법은 효율, 신기능을 쓰기보단 최대한 간단하고 편리한 코드 작성을 우선시하다보니 늘 효율과는 거리가 먼 방법으로 작성된 코드가 남았다.

 

그래서 NextJS의 특징 중 재테크 블로그 서비스에 집중해 접목시킬 것들은 다음과 같다.

 

1. 서버 사이드 렌더링(SSR): 외부 주식 api를 통해 그래프가 가장 먼저 보여야하는 모의투자, 주가예측, 블로그 메인, 랜딩페이지의 경우 SSR을 통해 유저의 초기 경험을 개선할 수 있을거라 생각해 Next를 선택했다. 매번 코드를 작성하다 보면 결국 useclient로 덕지덕지가 된 페이지를 만들곤 했는데 이번엔 하이브리드 형태로 개발은 하되, 최대한 SSR을 사용해보는 것을 목표로 한다.

 

2. API 라우팅 기능: 주가 예측이나 모의투자 기능을 위한 API를 Next에서 권장하는 api routing + fetch 방식을 활용해 받아올 예정이다. 추가로, socket.io를 넥스트에서 사용하지 못하기에 NodeJS에서 서버를 만들어 받아와야 한다는데 socket.io 공식문서에서 제공하는 방식이기에 난이도도 높지않을 것 같아서 잠시 고민했으나 Next를 선택했다. 추가로 이번에 무한 스크롤을 구현해야하는데 react-query에서 제공하는 캐싱기능을  Next api를 요청 할 때도 사용할 수 있다기에 이 점도 한번 활용해보려한다.

 

3. SEO 최적화: 검색엔진 이슈는 실제 서비스를 하지 않는다면, 의미가 크게 없을 수도 있지만, 실제 서비스를 할지도 모르는거고, 앞으로 내가 분명 검색엔진 최적화를 해야할 일은 많을 것 같아서 지금 미리 미리 배우고 사용하는게 좋을게 분명하기에 Next를 선택했다. 아무래도 초기에 렌더링되는 페이지에 검색엔진에 유리한 키워드와 정보들을 집어넣는 것을 목표로 한다.

 

4. 사용자 경험 개선: 페이지 간의 빠른 전환과 최적화된 사용자 인터페이스를 제공할 수 있어 사용자 경험을 향상시킬 수 있는 어떻게 보면 흔하고 당연한 기능일지도 모르겠지만 이번 프로젝트에선 Loading이나 Error와 같은 사용자가 서비스를 이용하는데 있어 예외 상황에 대한 처리를 좀 상세하게 처리해보고자 Next를 선택했다 (fallback, erorr핸들링) 추가로 동적 경로를 많이는 사용해보지 않았는데 주가 id에 따른 동적경로가 더 효율적이라면 이 방법으로 구현해보고자 한다.

 

5. 넥스트만의 폴더구조: Socket.io 때문에 리액트를 잠깐 생각했으나, Next의 app routing폴더 구조가 너무 편리하고 그 안에서 사용가능한 Link와 같은 기능들을 포기할 수 없어 선택했다.  또한 개발 초심자 입장에서도 Next의 파일기반 라우팅은 협업하는데 있어 폴더, 라우팅 구조가 직관적으로 느껴질거라고 생각이 들어 선택했다.

 

Zustand

이번 서비스의 경우 한페이지에서 많은 정보들이 오가고 사용되기보단 외부 api에 의해 변경되는 일이 잦아 상태관리를 많이 쓰일지는 모르겠다. 아마 컴포넌트간 깊이가 깊어지지 않는다면 props로 전달하곤 할 거 같은데 결국 한 번을 쓰일 것이라 생각하기에 상태관리 라이브러리도 선정했다.

 

팀원 중 한 명은 리코일, 한 명은 상태관리 라이브러리 경험이 없다. 내가 Zustand르 저번 프로젝트에 사용하며, 리코일과 나름 유사하다고 느끼고 난이도 또한 어렵게 사용하지 않는 선에선 충분히 쉽다고 느꼈다.

 

추가로 패키지 크기도 매우 작고 비교적 성능도 좋다는 장점도 있고, Recoil을 까는 것 같지만, 업데이트도 안되는 Recoil과는 다르게 꾸준히 업데이트도 되고 있으니 향후를 생각해도 Zustand의 선택은 옳다고 생각이 든다.

 

다만, Zustand에서 제공하는 여러 상세 기술들을 써본적이 없어 이번 프로젝트와 어울리는 기술이있다면 주저하지않고 사용해 볼 예정이다.

 

결론

기술 스택 선정에 있어 팀원 3명이 있음에도 개발경험이 거의 없어 혼자 선택을 하게 되었는데 이에 대하여 아쉬움도 크다. 다같이 알아보고 비교해보고 내가 안써본 다른 기술도 써보면 좋겠지만, 내가 경험이 제일 많다보니 아무래도 소극적인 선택과 그에따른 시작을 하게된 것 같다.

 

그럼에도 불구하고 내가 선택한 기술스택에 있어 내가 완벽히 이해하고 충분히 잘 다룬다고 생각하지도 않기에 이번 기회에 효율적으로 잘 사용해보면 좋은 경험이 될 것 같다. 화이팅