오늘은 이전의 프로젝트를 하면서 부족했던 점들을 보완하여 새로운 규칙을 정하고 새로운 프로젝트의 방향을 정하는 회의를 했다. 팀룰에서 수정하고 싶었던 룰들을 수정했다. 처음 정하고 사용해보니 불편했던 부분이나 더 원하는 룰이 있다면 추가하면서 더 우리 팀에 맞는 규칙들을 정했다. 그리고 우리는 기존의 프로젝트를 보강하고 싶었기 때문에 어떤 기능을 추가하고 어떤 기능들을 보강하고 추가, 보강할 기능들에는 어떤 기술들이 필요한지 그 기술들은 어떤 점때문에 필요한지 나눠봤다. 그런데 기획부분도 어떤 순서로 해야 하는지에 대해서 막연했던 부분이 많았는데 이번에도 부족하긴 했지만 지나면서 생각해보면 와이어프레임을 보면서 의견을 나누니 수월하게 진행된 부분이 있었다. 정해진 부분이 적으면 상상이 어렵고 오히려 어느정도 구체화가 되어야 의견이 더 잘 나오는 것을 경험했다. 부족함일 수도 있지만 틀을 잡는 작업이 필요함을 알 수 있었다. 디자인 부분을 나눠보면서 이때는 이런 기능 저때는 저런 기능 이야기를 하면서 구체적인 화면 구성을 나누고 기능들도 생각하면서 프로젝트의 구상을 모두의 머리 속에 비슷하게 그릴 수 있었다. 와이어 프레임이 없다면 각자가 다른 구상이 머리속에 있을지 모른다. 그렇게 이야기를 나누고 그 기능들과 화면 구성들을 토대로 기능 플로우를 구성했다. 수정될 수 있는 부분이지만 수정될 수 있다고 구성하지 않는 것과는 정말 다른 결과를 가져올 수 있음을 알았다. 구성해서 보이는 부분이 있어야 진행도 수월하고 같은 방향성을 인식한 상태로 일할 수 있기 때문이다. 그렇게 정해진 기능 플로우와 그것을 토대로 DBschema를 작성하고 전체적으로 필요한 데이터들을 정리했다. 이 작업들이 같이 회의로 정하다보니 많은 시간이 걸렸다. 우리조는 저번도 그렇고 이번도 회의시간이 정말 길게 걸렸다. 같이 나눠보면 더 좋은 이야기들과 의견들이 나왔기 때문이다. 4명 모두 필요한 의견들을 적절하게 그리고 동의를 구하면서 이해도 되고 상황을 모두 공유하고 있으니 모든 것이 정해지고 작업을 시작하면 더 효율적으로 일할 수 있다고 생각한다. 그래서 자주회의를 하는 편인데 때로는 오랜 회의로 피곤하기도 하다. 이럴때는 적당히 끊어서 지루함과 피곤함을 달래면서 해야겠다고 생각했다. 모임이 싫어지면 아이디어도 잘 나오지 않을 수 있기 때문이다. 이것도 잘 조절해서 회의도 의견도 나눠야 겠다.
회의를 마치면서 스택에 대한 부분을 공부해보기로 했다. next.js 부분이다. next.js를 공부해보면서 알게 된 부분이 우선 next.js의 장점을 알아봤다. 기존의 React의 단점으로 볼 수 있는 부분이 CSR의 단점이다. SPA를 구현하는 React는 CSR로 클라이언트에서 서버가 전달해준 html, js등등의 소스코드들을 가지고 클라이언트에서 랜더링하여 보여지게 된다. 이렇게 되면 클라이언트에서 필요한 페이지를 랜더링 하여 표시하기 때문에 속도가 빠르고 변화된 부분을 VDOM으로 감지하여 변화된 부분만 랜더링 하는 방식으로 유저 경험을 좋게 할 수 있어서 웹서비스를 애플리케이션 처럼 사용할 수 있는 장점이 있다. 그러나 동적으로 움직이는 처리가 많아지면 많아질수록 서버에서 처음 다운로드 받는 파일들의 크기가 커져서 첫 로딩할때의 시간이 오래걸린다는 단점이 있다. 이 단점이 있다. 우리 프로젝트가 CSS나 애니메이션 부분이 필요한 부분이 많다보니 첫로딩의 시간을 줄이는게 좋지 않을까하는 생각이 들어서 이를 해결하려면 어떤 방법이 있는지 알아보다가 next.js를 찾아보게 되었다. next.js가 이전에는 SSR을 지원해지만 요즘은 SSR + CSR도 지원하고 있는 부분을 보았다. 오늘은 이 부분을 공부하였고 SSG가 어떻게 구현되는지는 내일 공부해봐야겠다.