KEYNUT - 전자기기 중고거래 사이트(회고)

첫 커밋 - 2024.05.28

마지막 커밋 - 2024.08.14

 드디어 프로젝트가 끝이 났다. 최근에 커스텀 키보드에 빠져서 커스텀 키보드를 중심으로 중고거래 사이트를 만들고 싶었다. 번개장터, 중고나라 등이 있었지만 키보드에 대한 세세한 카테고리가 없어서 프론트엔드 친구 한 명을 붙잡고 같이 프로젝트를 하자고 했고, 그로부터 두 달 반 정도가 지난 뒤 프로젝트가 마무리 됐다.

 

 사이트의 이름은 keynut으로 정했다. 'keyboard' + 'nut' 의 합성어로 키보드에 미친 사람... 이런 느낌이다.

 

 제대로 배포를 하려고 만든 사이드 프로젝트는 처음이어서 처음에 뭘 어떻게 해야 할지 고민이 정말 많았다. DB는 뭘 써야 하지, 어떤 프레임워크와 라이브러리를 사용할까, 백엔드는 어떻게 구하지 등등 시작이 너무 막막했다.

 

 가장 큰 문제가 프론트엔드 두 명이서 풀스택 개발을 할 것인지 아니면 백엔드를 구해서 프론트에만 집중을 할 것인지 두 선택지에 가장 오래 고민을 했던 거 같다. 한참 고민을 하다가 백엔드 개발자까지 필요한 프로젝트는 아닌 것 같고, 취준생인 내가 나중에 어떤 회사에 가서 어떤 일을 할지 모르는 상황이기에 백엔드 없이 프론트엔드 개발자 두 명이서 풀스택으로 개발을 하기로 했다.

 

 DB는 MongoDB로 정했다 기존에는 MySQL을 주로 사용했는데 이번 프로젝트에서는 빠른 개발을 위해 몽고디비를 선택했다. 이번 프로젝트에서 처음 사용해 보았는데 진짜 말도 안 되게 편했다. 일단 스키마가 없어 유동적으로 데이터를 내가 원하는 형태로 저장을 할 수 있었다. 프로젝트를 진행하면서 처음으로 중고거래 사이트를 만들다 보니 데이터의 형태가 엄청 많이 변경이 됐는데 아마 관계형 DB를 사용했다면 계속 DB를 뒤집어엎었어야 했을 거다...

 

 그리고 처음 사용하는 MongoDB가 더 편했다. 사용하기 전에는 '개발 속도가 빨라져 봐야 얼마나 빨라지겠어'라고 생각했는데, 정확한 수치로는 표현을 못하겠으나 관계형 DB를 사용했으면 지옥을 경험하고 있었을 거 같다.

팀원과 개발을 시작하기 전에 피그마로 사이트를 만들어봤는데 어디 내놓기 부끄러운 수준

나 - 상품 판매 페이지, 상품 페이지, 로그인 기능

팀원 - 상품 리스트 페이지, 메인 페이지, 프로필 페이지

 

이렇게  어느 정도 파트를 나누고 프로젝트를 진행했다.

반응형

 이번 프로젝트의 목표가 모든 기기에서 완벽한 사이트를 만들자!!! 였었다. 초반에 파워 코딩을 하면서 그냥 768px에 브레이크 포인트 걸고 줄이면 끝이잖아~ 하고 개발을 다 끝냈다. 그땐 몰랐었다.. 아이패드가 768px이 넘는다는 걸.. 아이패드로 처음 우리 사이트를 들어갔을 땐 지옥 그 자체였다. 내가 못한 건데 너무 화가 났었다. 또 왜 애플은 아이패드의 정보를 데스크탑과 통일을 한 걸까?? 그것도 아이패드로 사이트를 들어가고 처음 알았다.

 

 그래도 괜찮았다. 그냥 768px에 브레이크 포인트 건 것 ctrl + shft + f로 960px로 바꾸면 되니까!!!!!!!!!!! 진짜 헬게이트가 열렸다... 팀원의 페이지도 찰흙이 됐다. 엄청 혼났다. 그냥 commit 되돌리면 되는 거 아니야?라고 생각할 수 있는데 이전에 한참 작업을 하다가 commit을 따로 해두지 않고 냅다 사고를 쳐버려 되돌릴 수도 없었다. 뭐 어쩔 수 있나. 모든 코드를 검토하면서 하나하나 정성껏 수정을 다시 했다. 드디어 모바일, 패드, 데스크탑에서도 깨지지 않는 사이트가 만들어졌다. 진짜 여기서 많은 걸 배웠다. 도와준다고 나섰다가 오히려 엎을 수 있다는 걸 도와주기 전에 한 번 더 생각을 하고 직접 부탁을 한 게 아니면 아예 안 도와주는 게 나을 거 같다.

 

 사용자들이 이용할 서비스를 만드는 건 정말 신경 써야 할 부분이 많다는 생각이 든다. 브라우저마다 조금씩 다르고, 같은 아이폰이나 갤럭시도 펌웨어 버전에 따라 동작이 달라진다. 이런 문제를 프로젝트 막바지에 발견하게 되면 정말 멘붕이 온다. 또다시 갈아엎어야 하다니.

 

 어디서 봤는데 정말 잘하는 개발자도 최소 3번은 갈아엎는다고 했다. 그렇다면 나는 100번은 갈아엎어도 괜찮을 거 같다.

최적화

 진행을 하면 할수록 어떻게 해야 할지 감이 안 잡혔다. 개발을 할 때 항상 우리 사이트가 대박이 난다는 전제 조건으로 개발을 진행을 하는데 이게 백엔드의 역할까지 내가 하려다 보니 어떤 날은 고민하다가 함수 하나도 못 만들고 지나는 날이 있었다.

 

 그리고 내 성격이 하나에 빠지면 대충 끝내지 못하는 성격이라 정신 차려 보면 팀원이 거의 프론트를 다 끝냈다.. 나는 딱 위에 있는 내 역할과 추가로 어드민 페이지를 만들었다. 또 실 사용자가 있는 서비스를 만들고 있기 때문에 최적화 쪽으로 엄청 많이 신경을 썼던 거 같다.

 

 이게 옳은 방법인지는 잘 모르겠는데 최대한 서버에 요청을 진짜 최대한 줄이고 싶어서 react query를 사용하면서 동시에 next tags를 사용했는데 서버 사이드에서 react query를 사용해서 데이터를 프리패칭하고 클라이언트 사이드에서는 useQuery의 staleTime을 Infinity로 설정해 추가적인 서버 요청을 막았다. 새로운 상품 등록이나 수정 등의 변경이 있을 때만 재검증을 통해 서버 사이드에서 최신 데이터를 받도록 했다. 이렇게 하면 서버에서 한번 데이터를 캐시하고 나면 여러 명의 사용자가 요청을 해도 캐시 된 데이터를 계속해서 서빙할 수 있고, 서버 부하를 최소화할 수 있게 로직을 작성했는데, 한 가지 아쉬운 점은 A라는 사용자가 상품을 올리면 B 사용자는 A의 상품을 보기까지 약간의 텀이 있다는 건데 약간의 텀보다 득이 더 많을 거라고 판단을 했다.

tailwind CSS

 이번에 테일윈드를 처음으로 프로젝트에 도입을 해봤다. 사용하기 전에는 뭐야 저게 가독성 최악이다. 차라리 클래스 이름을 고민하는 게 낫겠어라고 라고 생각을 했는데 막상 사용을 해보니 너무 사용하기 편했다. 가독성을 버리고 충분히 사용할만했다.

해결 하지 못한 문제

 해결하지 못한 문제가 딱 한 가지가 있다. 모바일 환경에서 일어난 일이다. footer에 env(safe-area-inset-bottom) 만큼 바텀 패딩을 주고 Link 태그를 터치해서 다음 페이지로 이동을 하면 스크롤이 페이지의 최상단을 가리키는 게 아닌 최하단을 가리킨다는 것이다. 하단에 Nav가 있어서 footer를 정상적으로 보이게 하려면 하단 nav의 높이와 env(safe-area-inset-bottom)의 크기만큼 패딩이나 마진을 줘야 되는데 env(safe-area-inset-bottom)만 스타일에 넣으면 문제가 발생했다. 그래서 모바일, 패드, 데스크탑에 따로 임의의 padding을 줬다. Next.js의 깃허브 issue나 stackoverflow에 이와 유사한 글들을 전부 읽은 거 같은데 결국 해결하지 못했다. 

 

 두 달 반 동안 하루도 쉬지 않고 열심히 만들었는데 어떻게 홍보를 하는지 모르겠어서 그냥 방치 상태로 있다. 아무도 사용 안해줘도 평생 404 안뜨게 해줄게

https://keynut.co.kr

KEYNUT - 키넛