[항해 77일차] WIL_실전 프로젝트 MVP 중간보고 피드백

들어가며

10/04 부터 시작된 실전 프로젝트가 어제 10/28, MVP 중간보고를 가졌습니다.

우선, 제가 준비한 프로젝트에 대해 간략하게 말씀드리겠습니다.

쿠팡에서 애플 상품을 스크래핑해 와 상품의 가격정보(기존가격, 할인된 현재가격, 할인율 등)와

최근 일주일 가격 동향을 알려주고,

상품을 알림설정한다면, 해당상품의 최근 가격동향을 파악해 최저가로 떨어지면,

카카오톡 메신저로 알림을 보내는 기능이 프로젝트의 주요 기능이라고 할 수 있습니다.

또, 매거진 기능을 추가해 CRUD 기능을 구현해보고,

매거진에 관리자 권한을 추가해 일반 유저들에겐 수정, 삭제 기능에 접근하지 못하도록 구현해보았습니다.

이번 글은 중간보고에서 담당 멘토님에게 들었던 주요 피드백과

이에 대한 저의 답변에 대해 기록해보겠습니다.

 

 

Q1. 프론트엔드 같은 경우엔, 개인 브랜치에서 dev 로 한 번 merge 를 한 다음에, dev 에서 main 으로 바로 merge 를 하고 계신데, main 브랜치에서 바로바로 배포해야해서 이렇게 진행되고 있는 걸까요?

→  네, 이런 방법을 선택한 이유는 두 명이 작업을 동시에 진행되어야 하고, 서로의 작업물을 공유해야 하기 때문에 각자 개인 브랜치를 사용하고, 이를 dev 에 merge 하고 있습니다. main 브랜치는 일반적으로 배포 가능한 안정한 버전을 유지하고, 혹시 모를 실수로 작업한 코드가 담긴 브랜치를 잘못 건드릴 경우를 대비해 백업용으로 사용하고 있었습니다.

(멘토님) 네. 잘하셨구요. 잘하셨는데, 한 번에 Pre-quest 를 두 번씩 처리하는 게 귀찮으실 것 같아서 말씀드리는거예요. dev 브랜치로 모두 합쳐놓았다가 나중에 이제 배포할 때만, dev 에 있는 내용을 한 번에 올리셔도 되거든요. 그치만, 나중에 user-test 를 진행하게 되면, 개별 배포하는 경우도 있을 겁니다.

 

 

Q2. vite 에 대한 기술적 의사결정을 잘 설명해주셨는데, cra 의 빌드 방식이랑 vite 의 빌드 방식이 어떻게 다르길래 cra 가 vite 보다 느린가요? 

→  먼저, cra 는 Webpack 을 기반으로 하고, 모든 애플리케이션 코드를 하나의 큰 번들로 묶는 것을 의미합니다. 반면, vite 는 "온 디맨드" 번들링이라는 개념을 채택하고 있고, 이 온 디맨드 번들링은 필요한 모듈만 번들로 만든다는 아이디어를 갖고 있기 때문에 코드 수정이 발생할 때 전체 애플리케이션을 다시 빌드하는 대신, 수정된 모듈만 다시 빌드해 빠른 피드백을 제공합니다. 

(멘토님) 그럼 비트는 변경된 일부 변경에서 바로바로 적용이 되는데, cra 는 일부만 변경되도 전부 변경이 되어서 그렇다는 거죠?

→ 네 맞습니다.

 

 

Q3. Carousel 을 직접 만들어 주셨어요. 직접 만들어주셨는데, 이 기능이 반응형일 때도, 정상적으로 동작을 하나요?

→ 저희가 준비한 프로젝트가 모바일을 대상으로 준비한 프로젝트여서 애플리케이션 가로 넓이가 '375px' 입니다. 이 넓이는 제일 작은 휴대폰을 기준으로 했을 때에도 반응형을 준비하지 않아도 될 만큼의 크기라고 생각해서 반응형 스타일을 따로 준비하지 않았고, 크기가 고정이 되어 있어서 확인을 하지 못했습니다.

(멘토님) 그니까 carousel 의 가로 넓이가 바뀌어도 정상적으로 잘 동작하는지?

→ 그 부분은 아직 확인하지 못했습니다.

 

 

Q4. 그럼 만약 추가적으로 아이템들이 총 10개가 있다면, 마지막 10번째 아이템을 보고, 또 오른쪽으로 보면, 첫 번째 carousel 이 보이는 거죠. 그래서 무한으로 반복되는 carousel 을 만들어 달라는 요구사항이 온다면, 어떻게 구현하시겠어요?

→ 지금 현재 구현한 carousel 이 해당 기능을 구현하고 있고,

(멘토님) 아, 이미 그렇게 구현하셨어요? 그럼 어떻게 구현하셨어요?

→ 제가 구현한 carousel 은 가운데에서 가장 많은 부분이 보이는 메인 아이템과 나머지 4개의 preview 아이템들로 구성으로 나머지 preview 아이템들을 overflow: hidden 으로 보여지지 않는 상태입니다. 우선, 10개의 아이템이 있다면, 10개의 요소를 갖는 배열을 만들고, 화면에 보여지는 5개의 아이템에 index 를 기준으로 morePrev, prev, index, nextIndex, moreNextIndex 값을 줘, 배열에 맞는 아이템들을 순서대로 보여주고 있습니다. 다음 아이템을 보여줄 때에는 이 index 값을 하나씩 더해서 index 의 상태값을 변화시키면서 보여주고 있고, 만약 메인에서 보여주고 있는 index 의 값이 마지막숫자라면, 삼항연산자를 사용해 nextIndex 의 값이 초기 숫자값으로 설정해서 무한으로 돌고 있는 carousel 처럼 보이게 구현했습니다.

 

 

Q5. install 이라는 dependency 가 있는데, 이건 뭐하는 역할인가요?

→ 그 부분에 대해서는 저희가 의도적으로 설치해서 사용하고 있는 부분이 아닌 것 같아서 어떤 역할을 하는지에 대해서는 잘 모르겠습니다.

(멘토님) package.json 안에 요게 있더라고요. 이게 아마도 이것저것 하시다가 'install' 이라는 패키지가 잘못 설치된 것 같아요. 느낌이. 근데, critical 한 건 아니지만, 간혹 가다가 저런 패키지가 악성 패키지라서 개발하시는 분 pc 의 정보를 빼간다던지, 그런 게 가능하기 때문에 정리를 한 번 해주시는 것이 좋습니다.

→ 네 알겠습니다.

 

 

Q6. 컴포넌트마다 React.lazy 를 통해서 lazy 처리를 하셨더라구요. 왜 이렇게 하셨고, 이렇게 했을 때, 얻을 수 있는 게 뭐가 있나요?

→  '코드 스플리팅' 에 대해서 고려해보게 된 건 'lighthouse' 라는 웹 성능검사기능을 통해 메인페이지에서 데이터 부하가 있다는 것을 알게 된 후인데요. 가뜩이나 메인페이지에서 960개 갸량되는 전제상품 정보를 조회하고 있기 때문에, 다른 컴포넌트들에서라도 lazy 를 통해 처음 페이지가 렌더링될 때 부하를 줄여보고자 사용해보았습니다. 코드 스플리팅은 애플리케이션 코드를 여러 청크로 나누는 기술인데, 초기 로딩 시 모든 코드를 한 번에 다운로드하는 대신, 현재 화면에 필요한 코드만 동적으로 로드해서 초기 로딩 시간을 단축시키는 역할을 합니다. 사용하고 있는 lazy 는 코드스플리팅을 구현하는 자바스크립트 메서드 중 하나인데, import 함수를 사용해 필요한 모듈을 지연 로딩하는 역할을 하고, suspense 는 비동기 작업을 처리하는 동안 로딩 상태를 관리하고, 컴포넌트 간의 데이터 의존성을 처리하는 데 사용되는 것으로 알고 이 두 방법을 사용했습니다.

(멘토님) 네 이해했습니다. 그럼 현재 메인페이지에서 900개 정도 되는 상품정보를 가져오는 건 동일하지 않나요?

→  네 맞습니다.

(멘토님) 그럼 그건 코드 스플리팅으로 처리할 수 있는 건 아니네요?

→  네 맞아요. 여전히 많은 양의 데이터를 불러와 메인페이지에 부하가 있어서 이 점을 개선하기 위해 백엔드 분들과 '무한 스크롤' 기능에 대해 논의를 하고 있습니다. 현재 구현하려고 하는 방법은 전체 상품 조회가 아닌, 전체 상품에서 8개씩 조회하고, 스크롤해서 어느 정도까지 내려가면, 그 기준을 프론트에서 트리거로 정해 백엔드에서 다시 8개의 상품을 조회하는 로직으로 중간보고 끝난 후, user-test 전까지 구현해보려고 합니다.

 

 

Q7. api 사용해서 accessToken 보내는 부분 있잖아요? 이게 api 를 호출하는 코드마다 들어가 있던데, 이 부분을 공통화해서 처리할 수 있는 방법이 없을까요?

→ 음.. 고민해서 찾아보도록 하겠습니다

(멘토님) 이 부분은 고민해서 수정해봐야 하는 부분 같아 보입니다.

→  네 알겠습니다.

 

 

위 질문에 대한 답변은 제가 맡았던 기능에 대한 질문과 저의 답변내용이었습니다.