20조 REWIND Frontend

Team

• Frontend : 오세명,한우석 (REACT)
• Backend : 오준석,최선강 (SPRING)
  
  
  

REWIND란?

• 그 동안 Backend,Frontend가 공부하고 정리했던 내용들을 각 프레임워크별 (Spring,React,Node.js)로 모두 공유할 수 있는 게시판을 구현하려고 합니다. 게시판은 기본적으로 메인페이지에 모든 프레임워크들의 게시글들이 한번에 보여지며 각 카테고리속에는 그에 해당하는 게시글들만 보여집니다. 유저는 로그인을 하여야 기본적인 서비스를 이용할 수 있습니다.

프론트엔드 작업을 하면서 느꼈던 것

GlobalState의 볼륨과 서버 요청 사이의 갭

비록 프로젝트의 단위가 작지만 클라이언트가 어떤 수준으로 state를 관리하면 좋을지 논의를 하였다. 이야기를 한 배경은 다음과 같다.
루트 페이지로 GET을 보내게 된다면 비즈니스 로직에 필요한 데이터를 서버로부터 제공받는다. 이 데이터는 GET을 보내는 시점에 국한된 staleValue이다. 그런데 유저가 상세 페이지로 이동을 할 때는 staleValue가 아닌 freshValue을 제공해야한다고 생각했다. 그래서 매 번 페이지로 이동할 때마다 어차피 새로운 값을 받는다면, 상세페이지 컴포넌트에서 localState로 데이터를 관리하고, redux에서 관리하는 globalState의 볼륨을 줄이자는 결론을 도출하였다.
처음 내린 결론을 토대로 로직을 리팩토링하고난 다음 프론트엔드에서는 어차피 정보의 최신성을 보장할 것이라면 루트 페이지로 이동할 때마다 API call을 보내는 것이 좋지 않은가? 라는 질문을 가지고 회의를 진행하였다.
정보의 최신성 보장과 API Call Cost 사이에서 뚜렷한 결론을 내리지 못한 저희는 항해99 리액트 멘토님께 자문을 구하였다.

멘토님께서는 매 프로젝트마다 다르며, 타겟 유저에 따라 다르다고 답변을 해주셨으며, 이에 관하여 저희 프로젝트에서 과연 어떤 유저를 타겟으로 설정하였는지에 대해 되돌아보게 되었다. 처음 프로젝트 회의를 할 때 이 부분에 대해 논의를 하지 않았다는걸 알게된 후, 비용의 관점으로 생각을 전환하였다. 오랜 숙고와 이야기를 끝으로 루트 페이지에서 최초에 접속했을 때, 새로고침을 하지 않는 이상 API call을 하지 않고 state으로 관리하자는 결론을 내리고 로직을 그대로 두었다.

이런 결론을 내린 이유는, 기업의 관점에서 생각했을 때 서버 역시 하나의 비용이며, 매 번 요청을 보낼 때마다 돈이 나간다고 생각을 한다면 고객에게 서비스를 제공함으로써 얻는 이익보다도 서버 유지를 위한 비용이 더 많이 들 것이라고 생각했기 때문이다.

프론트엔드 협업을 처음 진행하면서 기능 구현에만 집중하지 않고, 서비스적인 측면에서 생각하여 로직을 전개했던 좋은 경험이 되었다.