BleShop
해당 프로젝트를 시작한 목적은 세 가지였습니다.
첫 번째는 모바일 형태의 레이아웃을 데스크탑에서도 적용되도록 구현하는 것
두 번째는 조금이라도 실제 결제 기능을 사용해보는 것
세 번째는 가독성 좋은 코드와 적절한 타입 선언과 경고/에러가 전혀 없는 코드를 작성하는 것
결과물을 제가 보고 판단하긴 했지만 어느 정도 원하던 결과물이 나왔다고 생각합니다.
모바일 ~ 데스크탑까지 모든 사이즈에 반응하는 앱 같은 레이아웃을 적용했고, 테스트 결제긴 하지만 결제가 되고 결제 기록을 등록할 수 있는 로직을 작성했고, 타입을 구분하고 유틸리티 타입을 사용해서 나름 적절하게 타입을 사용했다고 생각합니다.
사용한 라이브러리
1. Next.js
React.js의 프레임워크인 만큼 많은 기능들을 쉽게 사용할 수 있도록 지원해주고, 사용자에 의도에 따라서 적절하게 SSG, SSR, CSR을 적용할 수 있도록 도와주기 때문에 선택했습니다.
대부분 SSG or SSR을 적용했고, 적용의 근거는 SEO나 렌더링에 사용하는 데이터가 자주 변하는지 여부입니다.
예를 들어서 로그인/회원가입 페이지 같은 경우에는 데이터의 변화가 없고 SEO가 필요하지 않아서 SSG를 적용했습니다.
메인/특정 게시글 페이지같은 경우에는 렌더링 데이터가 자주 바뀌고, SEO가 필요하므로 SSR을 적용했습니다.
추가로 내 정보 페이지 같이 데이터가 자주 변하지만 SEO가 필요 없는 페이지들은 CSR이나 SSR 중에 선택이라고 생각하는데 현재는 SSR로 구현했습니다. 하지만 SSR은 서버에 부담을 주기 때문에 다음에 CSR로 바꾸려고 합니다.
2. Recoil
상태 관리 라이브러리로 사용하기 위해서 선택했습니다.
리액트의 훅과 사용법이 거의 비슷하기 때문에 러닝커브가 매우 낮고, Redux처럼 어디든 호환하지 않고 React.js 전용이기 때문에 세팅하기도 매우 간단하기 때문에 빠르게 공부하고 사용할 수 있다고 판단해서 선택했습니다.
다만 사용하면서 얻은 이점보다는 불편함이 더 많다고 느꼈습니다.
Redux처럼 정보가 많지 않고, Next.js와 사용하면 SSR에서 키 중복 경고가 발생하는 것, SSR에서 사용 시 쿠키 문제 등의 문제가 있어서 불편했습니다. 물론 사용이 미숙해서 그렇겠지만 그것을 극복할 만큼의 많은 정보가 없다고 느꼈습니다.
결과적으로는 비동기 selector를 모두 없애고 컴포넌트간의 데이터 공유를 위해서만 사용했습니다.
3. next-auth
로그인을 처리하기 위한 인증 로직을 위해 선택했습니다.
여러 가지 로그인 방식을 지원해주고 그중에서 Credentials 방식을 선택했습니다. ( email, password를 이용한 인증 방식 )
기존에 이용해봤던 passport보다는 더 쉽다고 느껴졌고, 프론트/서버에서 상황에 맞게 로그인한 유저의 정보를 가져올 수 있어서 좋았습니다.
4. prisma
데이터베이스를 관리하기 위해서 선택했습니다.
sequelize보다 더 쉽고, typescript에서 사용 시 작성한 모델에 맞는 타입을 자동으로 생성해주기 때문에 정말 좋습니다.
데이터의 CRUD를 처리할 수 있는 메서드들을 모두 지원해주고, _count, skip, orderBy 등의 유틸 기능들까지 지원해줘서 편합니다. 또한 TypeScript를 이용하면 타입이 적용되어 자동 완성을 지원해주고, 모델 타입 + TypeScript utility를 활용하여 원하는 타입을 쉽게 만들고, 타입 변화에 맞게 자동으로 업데이트되어서 사용하기 정말 편합니다.
5. tailwindcss
css를 쉽게 적용하기 위해서 사용했습니다.
아직 styled-components밖에 사용해보지 않았지만 다른 css 전처리기, 프레임워크, css-in-js들 중에서 가장 편하지 않을까 생각합니다.
처음에 적응하기가 조금 불편할 수 있지만 css를 어느 정도 안다면 예측 가능한 이름이고, 검색하면 충분히 결과를 얻을 수 있습니다. 또한 플러그인을 설치하면 자동 완성을 지원해주고, 커스터마이징하고 쉽고, styled-components처럼 새로운 컴포넌트를 만들 필요가 없어 코드가 적고, 이름이 이미 정해져 있어서 네이밍을 생각하지 않아도 되는 이점이 있습니다.
아무튼 만족도가 매우 높은 css 프레임워크입니다.
6. AWS-S3
정적 파일인 이미지를 저장하기 위해 선택했습니다.
이미지는 파일의 변화는 없지만, 서버에 저장하게 되면 용량을 크게 차지하게 됩니다. 유저는 개인이지만 서버는 하나를 사용하기 때문에 하나의 서버에 모든 유저의 이미지를 저장하면 그만큼 서버의 메모리를 사용하기 때문에 프리티어 AWS-EC2를 사용하는 입장에서는 서버의 메모리가 충분하기 않기 때문에 다른 저장 공간을 찾다가 알게 되어서 선택했습니다.
프리티어 기간동안 정해진 용량은 무료로 사용할 수 있고, presigned Url 기능을 지원해주기 때문에 실제로 사용하는 서버에는 이미지를 전달하는 큰 작업을 하지 않아도 되기 때문에 서버의 부담을 줄일 수 있어서 유용하다고 생각합니다.
- 이미지 처리 흐름
1. 브라우저에서 이미지 업로드 시presigned Url을 얻어서S3의temporary폴더에 이미지 저장
2. 저장된 이미지url을 이용해서 브라우저에 이미지 프리뷰 생성
3. 이미지 사용 확정 시 이미지를temporary폴더에서 사용 폴더로 이동 (user,product,benner,review등 )
4. 이동된 이미지url을DB에 저장
5. 이미지 제거 시remove폴더로 이동
7. iamport
결제 기능을 처리하기 위해 선택했습니다.
문서가 한글로 사용법에 따라서 정리가 잘되어 있어서 쉽게 사용할 수 있습니다.
실제 결제는 아니고 테스트 결제 기능까지만 구현했습니다. 돈이 나가지는 않지만 실제 결제처럼 결제 기록은 생기고, 결제 기록을 DB에 저장하도록 구현했습니다.
데스크탑과 모바일의 동작 방식이 약간 다르기 때문에 배포 후에 모바일로 테스트하다가 문제를 발견해서 해결했습니다.
8. 나머지 라이브러리들
react-hook-form:form관련 코드를 편하게 사용하기 위해서 선택axios: 비동기 처리를 편하게 사용하기 위해서 선택react-slick:carousel구현을 위해서 선택react-toastify:toast-message를 위해서 선택
구현한 기능들
- 유저 CRUD
- 상품 CRD
- 리뷰 CRD
- 장바구니 CRD
- 찜하기 CRD
- 결제 기능 CRD
- 결제 기록 CRD
- 상품 검색
- 카테고리, 필터링
🚀 배포
배포 방법은 위 링크에 정리한 대로 실행했습니다.
무료로 사용할 수 있는 AWS-EC2를 사용했으며, 배포하면서 두 가지 문제가 발생했습니다.
첫 번째는 메모리 부족으로 빌드가 안 되는 문제입니다.
빌드하면 서버가 자꾸 멈추거나 렉이 걸려서 강제 중지하고 다시 실행해야해서 일단 빌드 최적화를 적용했습니다. 하지만 빌드 최적화를 적용해도 호전되긴 했지만 빌드가 안 되는 문제는 그대로여서 결국 빌드 결과물을 GitHub에 올려서 받아 쓰는 방법을 사용했습니다.
두 번째 문제는 정상 작동하다가 서버가 갑자기 멈추는 문제입니다.
에러 로그 조차 남기지 않아서 뭐가 문제인지 알아내기 힘들었지만 이것 저것 적용해본 결과 프리티어를 사용하기 때문에 AWS-EC2의 RAM이 부족해서 생기는 문제인 것으로 결론지었습니다. AWS-EC2 메모리 스왑을 보고 그대로 적용해본 결과 문제없이 동작했습니다.
