[깃허브] https://github.com/C54Kd/popspot
기획
요즘 팝업스토어가 굉장히 핫하다. 성수동이나 강남역에 가면 팝업스토어가 많다. 그러나 팝업스토어에 관한 정보를 한 곳에서 보고 예약까지 할 수 있는 서비스는 없다. 실제 유저의 니즈가 있을 것 같은 서비스를 프로젝트로 구현해보고 싶다는 생각이 들었다.
엘리스코딩 SW6기의 2차 프로젝트는 3주 동안 이루어진다. 이번에는 3주 동안 실제 상용화할 만한 서비스를 만드는 것이 목표다. 6명의 팀원이 풀스택으로 도전했다.
기획부터 꼼꼼하게 하려고 노력했다.
피그마로 디자인 컨셉을 먼저 정했다. 여러 로고가 나왔지만 팝업스토어가 대부분 알록달록하기 때문에 블랙 앤 화이트로 깔끔하게 가기로 했다.
그 다음 실제 구현하고 싶은 기능들을 리스트로 만들었다.
- 팝업스토어 정보를 한 곳에서 볼 수 있을것(필터 조건까지)
- 사전예약, 현장대기 기능을 이용할 수 있을것.
- 유저 뿐 아니라 업체 관리자도 이 애플리케이션을 통해 관리가 될 것.
리스트를 보고 피그마로 플로우차트를 그렸다.
각각의 페이지에서 유저가 어떤 선택을 하고, 그 선택에 따라 어떤 기능들이 구현되어야 하는지 플로우차트로 그리니 작업의 순서가 대충 그려졌다.
그 기능을 구현하기 위해 어떤 기능들을 쓸 것인지, 스택을 정하고 아키텍처를 만들었다.
최종 아키텍처는 위와 같다. Next.js가 프론트 페이지를 서버 사이드 렌더링으로 만들어 클라이언트에 전달해주고 서버는 node.js와 express로 구현했다. 하지만 처음에는 이와 같은 구조가 아니었다. 트러블 슈팅 부분에서 후술한다.
이번 프로젝트의 가장 큰 도전은 Next.js를 도입한 것이다.
Next.js 도입
엘리스코딩 SW 트랙에서 배운 것은 리액트다. Next.js는 배우지 않았다. 하지만 검색엔진 최적화(SEO)가 중요해지고 그로 인해 서버 사이드 렌더링을 하는 Next.js가 대세 프레임워크로 널리 쓰인다. 최종 프로젝트에서는 도전적인 목표를 정해 달성해보고 싶은 욕심이 있었다. 또 공식문서를 보고 새로운 기술을 학습하며 바로 작업에 반영해보고 싶었다. 그래서 팀원들을 설득해 Next.js를 통한 프로젝트에 도전하기로 했다.
공식문서를 통해 Next.js의 개념을 학습하고 코치님께 질문해가며 Next.js로 프로젝트를 시작했다.
Next.js는 리액트를 기반으로 하는 풀스택 프레임워크다. Next.js로 서버까지 하나의 레포지토리에 구성이 가능하다는 것이다. (하지만 최종 결과물에서는 서버를 분리했다. 후술)
서버 사이드 렌더링(SSR)과 클라이언트 사이드 렌더링(CSR)
next.js의 가장 큰 특징은 서버 사이드 렌더링을 한다는 점이다.
사실 이것은 신기술이라기보다는 리액트와 같은 클라이언트 사이드 렌더링 이전에 사용하던 방식이다. 구글과 같은 검색엔진에 노출되는데 더 유리하기 때문에 유행이 돌고 돌아 다시 돌아온 느낌이다.
간단히 설명하자면 SSR은 요청이 들어오면 node.js가 라우트를 통해 엔드포인트에 도달하고, 서버에서 HTML을 그린다. 페이지를 미리 구성한 다음 클라이언트에게 전달하는 것이다. 서버가 더 많은 작업을 하지만 랜딩페이지가 더 빠르게 로드된다.
반대로 CSR은 먼저 HTML을 클라이언트가 모두 받는다. 그 후, API 호출을 해서 서버에서 JSON을 받아서 브라우저에서 HTML을 렌더링 하는 것이다. CSR 방식을 사용하면 처음으로 페이지에 접속할때, 즉 랜딩페이지의 로딩속도가 느리다.
CSR과 SSR, 이 두가지에 더불어 SSG와 ISR이라는 개념도 배웠다.
SSG는 static site generation이라고 해서 빌드 단계에서 HTML을 생성해서 서버가 바로 클라이언트에게 전달하는 것이다. 이것은 완전히 정적인 페이지(위키나 블로그) 에 적합하다. 속도가 가장 빠르다.
ISR은 Incremental static regeneration이다. SSG와 비슷하지만 정해놓은 시간마다 HTML을 서버가 재생성하는 것이다. SSG가 빌드 후 변경된 데이터를 반영하지 못하기 때문에 시간을 정해놓고 그때마다 새로 각 페이지를 정적으로 생성하는 것이다.
속도의 차이는 SSG > ISR > SSR 이다. 어느 방식이 반드시 좋다고 할수는 없고 상황에 맞게 가장 적합한 방식을 쓰는 방식으로 현업에서 쓰인다고 한다.
이번 프로젝트를 통해 서버 사이드 렌더링에 관해서는 제대로 공부한 것 같다.
DB스키마, API명세서, 와이어프레임
구현
모든 페이지에 반응형을 구현했다.
랜딩페이지에서 팝업스토어들이 다양하게 보여지고 가입시 선택한 카테고리에 따라 관심 카테고리가 강조되어 표시된다.
마이페이지에서는 나의 관심팝업, 리뷰관리, 현장대기, 사전예약을 관리할 수 있다.
OAuth 2.0을 통한 카카오와 구글 로그인을 REST 요청을 통하여 라이브러리 없이 커스텀으로 구현하였다.
계획했던 대로 잘 구현된 것 같아 기쁘다. 마지막날까지 팀원들이 열심히 해주었고 나도 팀장으로 프로젝트 시작부터 배포까지 각 단계를 모두 파악하고 마지막 배포까지 최선을 다했다.
트러블 슈팅 - 서버 구성
맨 처음에 Next.js가 풀스택 프레임워크여서 서버까지 하나의 레포지토리로 구현할 수 있기 때문에 그렇게 하려고 했다.
하지만. Next.js 14버전이 10월 말에 나왔고 우리는 당연히? 최신 버전으로 작업을 하려는데 검색 결과 대부분 레퍼런스로 나오는 자료들은 1년도 더 된 구버전의 api routes 였다. 1년전에 나온 13버전부터는 app route라는 방식을 사용했는데 여기서부터 어려워지기 시작했다.
검색을 해도 참고할만한 자료가 많이 없었다. 백엔드 코치님께 최대한 질문을 많이 했지만 코치님도 구버전을 사용한 경험만 있을 뿐 app route를 잘 모르셨다. 여기서 깨달은 한가지
‘ 반드시 신기술이라고 하여 좋은 것은 아니다 ‘
그렇다. 새로 나온 기술이 이렇게 중대한 변화라면 그에 적응하는 것은 보통일이 아니다. 그리고 원래 프레임워크가 이렇게 크게 구조나 이름 등을 변경하면 안되는 것 아닌가? 서버를 하나로 가져가려고 며칠을 헤매다
Next.js에서 서버를 express로 만들 수 있는 커스텀 서버라는 기능을 쓰려고 했다. 그러나 그마저도 여의치가 않았다. 백엔드 코치님께 질문했는데 다음과 같은 답을 들었다.
‘생각보다 변경점이 많아서 next.js의 커스텀서버로는 원하는 서버 로직을 모두 구현하기에는 너무 힘들 것 같다. 서버의 레포지토리를 분리하고 익숙한 express로 구성하는 것이 낫겠다.’
그래서 결국 며칠이나 지연된 채로 서버를 Node.js와 express를 사용하여 분리했다. 신기술은 함부로 도입하는 것이 아니구나, 반드시 새로 나온 기술이라고 해서 좋은 것은 아니구나 체험으로 깨달았다.
분리하고 나서는 익숙하게 잘 구현했던 것 같다.
트러블 슈팅 - eslint와 prettier
우리팀은 처음 프로젝트 세팅할때부터 eslint와 prettier를 함께 사용하는 설정을 같이 하고 시작했다. vscode에서 저장을 하면 자동으로 코드를 정해둔 규칙대로 변경되어 저장되도록 했다.
이렇게 하면 팀원에 따라 각자 코드를 쓰는 방식(괄호를 쓰거나 세미 콜론 등을 하는 방식)을 통일할 수 있다.
prettier는 코드를 이쁘게 하는 방법, eslint는 자바스크립트의 틀린 로직을 고쳐주는 역할을 한다.
이를 동시에 쓰게 되면 충돌이 많이 일어나는데, 그것을 꼼곰히 설정해주어야 한다.
그런데 각자 버전이 올라가면서 이전에 정상적으로 작동했던 설정들이 얽힌 것 같다.
프로젝트 진행 때는 아무 문제가 없다가, 마지막에 배포를 하기 전 빌드 단계에서 충돌이 나며 빌드가 실패했다.
eslint와 prettier 때문이었다. lint가 안되는 코드를 수동으로 고치고, prettier는 따로 빼서 빌드 전에 모든 코드를 prettier로 수정하는 식으로 작업했다.
다시 돌이켜보면 설정을 정말 완벽하게 아는 것이 아니라면 이렇게 사용하는 것은 에러 가능성만 올리는 것 같다. 특히 prettier는 빌드 전에 한번에 모든 코드를 수정하는 것이 편한 것 같다.
편하기 위해 사용하는 라이브러리가 에러의 근원이 되면 안되니까..
회고
이번 프로젝트는 엘리스 트랙의 마지막 최종 프로젝트로 걱정이 많았다.
충분한 퀄리티의 결과물이 나와야 한다는 압박감도 있었고, Next.js 같은 새로운 도전을 성공시키고 싶은 욕심도 컸다.
그래서 처음부터 팀장을 맡아 제일 많이 노력하려고 했다. 노션을 통한 문서화와 게더, 피그마 같은 협업툴을 적극적으로 사용했고 최대한 팀원들끼리 소통을 많이 하도록 유도했다. 페어프로그래밍을 권장하거나 서로 질문하는 것을 개의치 않도록 권장했다.
풀스택으로 진행했기 때문에 직접 프론트 페이지를 구현하다 필요한 api를 바로 만들어서 이어지는 느낌이 들어 장점도 있었다. 웹개발 전반에 대한 이해도가 올라간 느낌이다. 하지만 역시 전문적으로 하나에 집중 하는것이 발전의 속도가 더 빠를 수 밖에 없을 것이다. 왜 프론트와 백엔드를 현업에서 나누는지 알것 같았다.
결과물 자체는 매우 잘 나와서 기쁘다. 모든 기능들이 정상적으로 작동하고 마지막에 팀원들 전부 모여 꼼꼼하게 만든 mock 데이터도 이쁘게 잘 들어갔다.
크롬 브라우저의 개발자 도구의 lighthouse로 측정한 사이트의 점수는 성능이 47점, 검색엔진 최적화는 100점이 나왔다. 랜딩페이지의 측정 속도이다. 성능을 더 높이기 위해서 이미지를 로드하는 방식에 스크롤을 내리면서 지연되면서 로드되는 방식(오프스크린 이미지 지연) 등을 사용하면 더 점수를 올릴 수도 있을 것 같다. 이미지 컴포넌트의 사용에 대해서 더 공부해야 할 것 같다.
