기술 선정 및 도입 이유

• redux-logger

  redux 미들웨어를 사용해 개발을 할때 리듀서의 실행 전과 실행 후의 log 기록을 확인하기 어려운 부분이 있어 사용하게 되었습니다. 설치 후에 api의 호출 및 상태 변경 부분을 정확히 알 수 있어서 개발에 많은 도움이 되었습니다.

• Axios / Axios interceptors

  클라이언트와 서버간의 비동기 통신을 위해 Promise 객체로 리턴을 해주어 데이터 다루기가 용이한 axios를 선택하였습니다.

  로그인을 할 때 토큰이 있는 상태에서 다시 로그인을 할 경우 (아직 정확한 에러의 이유는 찾지 못했습니다) 에러가 발생하는 현상이 있어서 interceptors를 사용해 토큰 값을 미리 확인하고 에러를 방지할 수 있도록 하였습니다. 또한 토큰 재발급을 위해서도 사용하고 있습니다.

• CI / CD (Github Actions)

  코드의 수정 또는 여러 변경 사항등을 유저의 환경까지 지속적으로 제공하기 위해 사용하고 있습니다.

• styled components

  초기에는 tailwind라는 css 라이브러리를 사용하기로 결정했는데 스타일 적용 시 매번 클래스를 적어주어야 하는 번거로움이 발생했습니다.

  프로젝트 특성상 props를 통해 값을 내려받는 경우가 많고, 해당 prop에 따라 사용되는 컴포넌트 및 스타일이 달라져서 prop에 따라 스타일만 바꿀 수 있 컴포넌트를 재사용할 수 있어 이 방식이 저희 프로젝트에 적합하다고 생각돼서 선택했습니다.

• redux (@reduxjs/toolkit)

상태를 한곳에 몰아서 관리할 수 있다는 장점과. 기획 초기에 websocket도 사용할 예정이었고, chrome-extension에서도 getState와 dispatch를 활용하면 편리할 것으로 판단해서 선택했습니다.

리액트 자체에서도 상태 관리가 가능하지만 여러 컴포넌트에서 전역으로 상태를 관리해야 하는 부분이 있어서 redux 라이브러리를 사용하게 되었습니다. redux는 부분적으로 리렌더링이 가능하고 상태 업데이트 로직을 분리해 모듈화해서 정리하기가 편한 부분이 있어 유지 보수 부분으로 redux 라이브러리를 사용하였고 그 중에 개발 도구로 toolkit을 사용했는데 dispatch 관리로 thunk를 사용해야 하는데 toolkit에는 thunk, immer 등이 내장되어 있어 선택을 하게되었습니다.

• react-responsive

  저희 서비스는 반응형인데 UI 디자인이 웹과 모바일이 달라서 미디어쿼리로만 구현하기에는 어려운 점이 있어 라이브러리를 선택해 반응형웹을 구현하게 되었습니다.

• github / git-flow

  협업을 위해서 github을 사용하고 github 내에 프로젝트 칸반보드로 개발 상황을 서로 체크하였습니다. git 커밋을 할때 원할한 소통을 위해서 커밋메세지를 정하여 커밋을 하였고 브랜치 구성은 main - dev - 각 멤버 개인의 브랜치로 구성하였습니다.

  CI/CD 적용으로 github action을 통한 자동 배포를 적용하였습니다.

트러블 슈팅

• carousel(스와이프) 및 모달 등을 만들며

  처음엔 carousel과 모달, alert창을 하나의 라이브러리로 예쁘게 구현하기 위해 프레이머를 사용하려고 했지만 프레이머의 장점인 부드러운 애니메이션이 저희 프로젝트와는 어울리지 않았고, 라이브러리 자체도 무겁다는 느낌이 있었습니다. carousel은 react-slick, alert은 sweet-alert을 사용했습니다. 또 모달 및 드롭다운 등은 기존에 있는 라이브러리를 사용하면 커스텀하기 까다롭고 저희 프로젝트와는 어울리지 않아 직접 구현해서 사용하고 있습니다.

• chrome extension

  크롬 확장프로그램에서 북마크를 저장할 수 있도록 하려는데, 사용자의 db에 접근해야 하다보니 로그인이 필수였습니다. 하지만 저희는 카카오로그인을 사용하고 있었고, 카카오는 크롬 익스텐션의 프로토콜 형식은 지원하지 않았습니다. 로그인 방식을 구글로 바꾸기엔 일정상 무리였고요. 멘토링을 통해 서비스워커에서 저희 홈페이지를 연결한 뒤, 실질적인 작업은 이곳 서비스워커에서 이루어지도록 조언을 받았습니다. 그러나 저희는 토큰을 세션스토리지에 저장하고 있었고, 창이 달라지면 로그인이 풀려버려서 이 방식은 이용할 수 없었습니다. 그래서 토큰 저장방식을 로컬스토리지와 쿠키에 담을 수 있도록 수정하고 있고, 그때까지 임시 방편으로 <iframe> 태그를 이용해 크롬익스텐션 전용으로 작성한 페이지를 불러와 사용하도록 하고 있습니다. 또, 단지 화면을 불러오기만 할 뿐인 기능에 라이브러리를 설치하니 불필요하게 용량이 커져서 단순한 html을 사용해 다시 만들었습니다.

• s3 배포 시 환경변수 파일(.env) 파일 미적용

  환경변수(.env) 파일에 개발주소(로컬)와 도메인주소를 함께 넣어 사용중이었는데 s3로 배포가 될 때 주석처리 한 부분이 적용되지 않는 문제가 있었다.

  .env 파일을 .env.local 과 .env.production 으로 나누어 두어 배포시에는 .env.production 이 적용되도록 했습니다.