3주 동안 NodeJS + ReactJS + TypeScript 기반의 팀 프로젝트에 프론트엔드 팀원으로 참여하면서 많은 것을 배우고, 느낄 수 있었다. 이번 팀 프로젝트에서 얻은 것을 정리하고, 앞으로 나는 어떻게 성장해갈 것인지에 대해 정리하기 위해 회고를 작성한다.
1. 와이어프레임 작성의 중요성
기존에는 프로젝트 초기 단계에서 와이어프레임을 작성하는 것이 단순하게 앱의 UI가 어떻게 구성될지 결정하는 것이라고만 생각했다. 하지만 이번 프로젝트를 React로 진행하면서 와이어프레임을 자세히 작성하는 것이 React와 같은 컴포넌트 단위로 화면을 구성하는 웹 프레임워크를 사용할 경우에 더 중요해진다는 것을 알게되었다. React는 컴포넌트 단위로 화면을 구성하기 때문에 자연스럽게 각 페이지마다 사용되는 공통 컴포넌트가 생긴다. 와이어 프레임을 자세히 작성하면 React 개발 초기에 공통 컴포넌트로 분리할만한 것이 뭐가 있는지 찾을 수 있으며, 개발 초기부터 해당 컴포넌트를 공통 컴포넌트로 구현할 수 있게되는 장점이 있다는 것을 깨닫게 되었다.
2. 유저플로우의 중요성
유저가 서비스를 이용하는 흐름을 상세하게 정의해두어야 특정 상황에서 유저가 의도하는 페이지 이동 또는 원하는 서비스의 사용이 가능한지 점검할 수 있다는 것을 알게되었다. 또한 와이어 프레임에서 의도한대로의 UI 변경을 컴포넌트의 생명주기를 담당하는 State로 관리할 수 있는지에 대한 파악이 한결 쉬워진다는 것을 알게되었다.
1. 팀원과의 소통의 중요성
이번 프로젝트에서 총 4명의 프론트엔드가 React를 이용해 하나의 앱을 구현했다. 4명이 각각 자신이 담당하는 도메인을 개발했다. 자신의 것만 신경써서 작업하다보니 자신의 작업물 말고 다른 프론트엔드 팀원이 개발한 코드에 대해 잘 알지 못했다. 자연스럽게 코딩 스타일도 4명의 스타일이 각각 반영되었고, 폴더 구조 또한 공통적으로 쓸 수 있는 컴포넌트를 모아두는 것이 아닌 각 도메인에 마다 필요한 컴포넌트를 해당 도메인의 폴더에 넣는 방식으로 구현하였기에 같은 코드를 여러번 작성하는 보일러 플레이트가 발생하기도 하였다. 사실 프로젝트 중간에도 이를 인지하고는 있었지만, 어디부터 얘기를 해야할지, 내가 얘기하는 것이 열심히 작업 중인 팀원을 방해하는 것은 아닌지 하는 생각 때문에 선뜻 얘기하지 못하였다. 앞으로 React로 다른 프론트엔드 팀원들과 개발을 하게 된다면, 어떤 컴포넌트를 공통 컴포넌트로 만들지, 현재 코드에서 보일러 플레이트가 발생하고 있지는 않은지를 수시로 얘기하고 내가 작성 중인 코드 뿐만 아니라 팀원이 작성 중인 코드도 참고하면서, 프로젝트 전반적인 이해를 높이기 위해 노력해야겠다고 생각했다.
2. 문서화의 중요성
팀 프로젝트를 진행하다보면 팀원 모두가 같은 주제로 이야기하는 경우는 스크럼 회의 시간 등을 제외하면 생각보다 많지 않다는 것을 알게되었다. 보통 특정 도메인을 담당하고 있는 백엔드 & 프론트엔드 개발자가 서로 1:1로 얘기하는 경우가 많다. 만약 1:1로 나눈 대화가 다른 프론트엔드도 알아야하는 것이라면, 이렇게 소수가 나눈 얘기들 중에서도 팀원들이 모두 알아야하는 내용이 있다면 간략하게라도 문서화해서 공유하는 것이 프로젝트 진행되고 있는 현황을 서로 알게되고, 어떤 부분에서 문제가 있는지 인지할 수 있고, 더 나아가 추후에 발생할 수 있는 문제를 미연에 방지할 수도 있으므로, 작은 것이라도 정리해서 공유하는 습관을 가져야겠다고 생각했다.
1. React 에 대한 이해
예전에 React + TS 로 웹 앱을 만드는 강의를 클론코딩해본 경험이 있다. 하나하나 이해하며 넘어가지 못하였고 어느 수준을 넘어서자 무작정 따라하는 것에 불과했던 경험이 있다. 이번 프로젝트 전에 한 달 간 엘리스가 제공하는 React 수업을 듣고, 따로 TS를 공부했다. 프로젝트 직전까지 열심히 공부했음에도 불구하고, 막상 프로젝트가 시작되니 무엇부터 만들어야 할지 몰랐다. React라는 도구의 사용법만 익혔지, React로 직접 집을 지어본 경험이 없으니 무엇부터 시작해야하는지 몰랐던 것이다. 그러다보니 초반에는 프론트엔드 담당 코치님께서 조언을 하시더라도 아예 다른 방향으로 이해한적도 있었다. 그래도 포기하지 않고, 좋은 React 구조에 대해서 찾아보고, 팀원들과도 어떻게 폴더 구조를 어떻게 잡아나갈지 등을 고민해나간 결과 React로 개발하는 방식에 대해 점차 익숙해져갔다. 프로젝트가 끝날 쯔음에는 상태관리 라이브러리인 Redux의 store, dispatch, action 개념을 완전히 이해하고, global state와 local state의 차이, 더 나아가서 Container Component와 Presentational Component 를 분리하는 등 더 좋은 구조의 React 앱을 만들기 위해 노력할 수 있었다.
2. React 의 핵심은 데이터 처리
이번 React로 프로젝트를 진행하면서 React의 핵심은 사용자가 각종 Event를 수행할 때마다, 각 Event에 대해 알맞은 UI을 그려내는 것이다. 결국 알맞은 UI을 그려내기 위해서는 UI에 영향을 주는 Event가 발생했는지의 여부를 State로 관리해야 하고, 해당 State의 값에 따라 적절하게 특정 컴포넌트를 생성하거나 소멸시켜야한다. 이러한 데이터 처리를 잘 수행하기 위해서는 다음 3가지를 잘 지켜야한다고 생각한다. 우선 첫번째로 사용자가 발생시킬 수 있는 Event 중에서 UI에 영향이 끼치는 것이 무엇인지를 파악해서 적절한 곳에 State를 사용하는 것, 두번째로 각 State들이 어느 상황에서 변경되어야 하는지 아는 것, 마지막으로 사용자가 Event를 발생시킬 때 State의 값 변경이 적절하게 이루어져야하는 것이다.
3. TypeScript 에 대한 이해
TypeScript 역시 이론 상으로만 공부하고 직접 프로젝트에 적용해본 적은 없는데, 이번 기회에 직접 사용하면서 많은 것을 이해할 수 있었다. TypeScript에서 가장 핵심이 되는 것은 TypeScript 입장에서 정체를 알 수 없는 값, 즉 어떤 타입의 데이터인지 확신할 수 없는 것에 타입을 지정해주어야 한다는 것이다. 대표적으로 함수의 매개변수와 React hook 같은 라이브러리가 반환하는 데이터의 타입 등이 있다. 논리적으로 문제가 있는 코드를 컴파일 단계에서 미리 찾아낼 수 있다는 점과 개발 시 auto-complete 기능 등으로 특정 부분에서는 오히려 개발 속도가 상승한다는 점에서 충분히 매력있는 언어이며, 앞으로 TypeScript에 더 깊게 공부하기 위해 이펙티브 타입스크립트라는 책을 공부해서 읽을 예정이다.
4. 백엔드 서버와 프론트엔드 서버가 분리되는 구조에 대한 이해
그동안 MPA, SSR 방식의 프로젝트를 진행해왔기 때문에, 서버가 직접 브라우저에 보여줄 화면을 렌더링하였기에 하나의 서버에서 데이터 관리 및 화면 렌더링까지 모두 담당했다. 하지만 리액트 같은 웹 프레임워크를 이용해 개발하는 경우, 백엔드 서버는 데이터만 관리하고, 프론트엔드의 요청에 따라 알맞은 데이터만 내려줄 뿐 렌더링과는 전혀 관계가 없는 서버가 되어버린다. 이렇게 브라우저에 렌더링을 수행하고 필요한 데이터를 요청하는 프론트엔드 서버와 데이터를 보관하고 알맞은 데이터를 제공하는 백엔드 서버가 나눠진 구조로는 이번에 처음 개발했다. 프론트엔드 서버와 백엔드 서버의 Port가 달라지다보니 브라우저에서 바로 백엔드 서버로 API 요청을 보낼 경우 CORS 에러가 발생하였다. 이를 프론트엔드 서버에 Proxy를 도입하는 방식으로 해결할 수 있었다. 만약 백엔드 서버로 API 요청을 보내야하는 경우가 있다면, 프론트엔드에서는 클라이언트가 "/api" 로 시작하는 end point 로 요청을 보내도록 설계하고, 프론트엔드 서버에서는 요청 주소가 "/api" 로 시작하는 요청을 받을 경우, 이를 백엔드 서버에게 보내야하는 요청으로 판단하여, Proxy로 이용해 해당 요청을 백엔드 서버로 보내는 방식으로 구현하였다. 이러한 방식을 사용하여 브라우저가 백엔드 서버에 직접 API 요청을 하는 것이 아니라 프론트엔드가 서버가 브라우저와 백엔드 서버의 중간에 껴서 request와 response를 전달해주는 방식으로 CORS 문제를 해결할 수 있었다. 이 외에도 배포 시에 하나의 Nginx에 두 서버가 존재해야한다는 점과, FE와 BE에서 request data 또는 response data의 타입을 정의하기 위해 사용되는 각종 type 또는 interface를 한 곳에 정의해서 공유해야 한다는 것 등에 대해 배울 수 있었다.
1. React + TS 로 프론트엔드 로직 구현
짧은 시간이었지만, 부족했던 React와 TS로 구현한 코드가 프론트엔드 코치님으로부터 꽤나 높은 수준으로 작성했다는 얘기를 들었다. 또한 상태 관리 라이브러리인 Redux를 도입한 것과 코치님의 조언으로 Container Component와 Presentatinoal Component의 분리했던 것도 쉽지 않았을텐데 잘 구현했으며, 전반적으로 변수나 함수의 네이밍도 적절하고, 코드를 이해하기 쉽게 짜서 좋았다는 얘기를 들었다. 이렇게 처음 다뤄보는 React + TS 였지만 제대로된 사용법을 익히기 위해 노력했다.
2. 팀 일정 관리
팀이 현재 잘못된 방향으로 나가고 있는 것은 아닌지, 우리의 속도가 너무 느린 것은 아닌지 등을 자주 체크하면서 각 스프린트 주기 별로 이뤘으면 하는 것을 구체화했다.
3. 팀 단위 의견 취합
팀원 모두의 의견을 소중하게 생각하고, 매번 팀원 모두의 의사결정이 필요할 때 마다 투표를 진행해 팀원의 의견이 무시되지 않기 위해 노력했다.
4. 백엔드 팀원들과의 의사소통
프론트엔드로서 백엔드 팀원들와 함께 협업하면서 내가 API로부터 받아오고자 하는 부분은 무엇이고 어떤 것을 전달할지 등에 대해 명확하게 전달하였고, 그 과정에서 백엔드 팀원들과의 충분한 소통을 진행하였다.
1. 공통적인 부분에 대한 기여
비교적 나보다 다른 프론트엔드 팀원들이 API 요청이 많은 도메인을 담당했기 때문에, 구현하는 데 더 시간이 걸렸을 것이다. 내가 좀 더 많은 도메인을 맡긴 하였지만, 전반적으로 백엔드에 API 요청을 보내는 코드는 더 적었고, GET 요청만 있었기 때문에 시간 상 여유가 더 있었다. 따라서 내가 공통으로 사용되는 컴포넌트 분리, 각종 constants 정리, custom hook 생성, redux 구현 등 다른 도메인에서도 공통적으로 사용하는 부분을 내가 구현해서 다른 팀원들의 시간적 부담을 줄여줬으면 더 좋았을 거라는 아쉬움과 미안함이 든다. 다음 팀 프로젝트에서는 내가 먼저 나서서 공통적인 부분에 대해 얘기하고 구현해볼 계획이다.
2. 프론트엔드 팀원과의 소통
내가 작성한 코드가 어느 정도 완성되었음에도 불구하고, 시간을 내서 같은 프론트엔드 팀원들이 작성 중인 코드를 보지 못하였고, 그저 내 코드를 좀 더 완벽하게 짜기 위한 구상만 진행했다. 팀 프로젝트의 한 일원으로써 같은 팀원이 어떻게 만들고 있는지 도움을 줄 수 있는 부분이 없는지 등을 먼저 물어봐야 하는게 맞았다고 생각한다. 앞으로 팀 프로젝트를 진행하면서 이러한 부분을 놓치지 않도록 노력해야겠다.
3. 도전 정신
내가 구현한 부분은 코드를 정갈하게 짜려고 노력하다보니 코드는 정갈하지만, 깊이가 깊지 않는 코드가 되었다고 생각한다. 나는 왜 다른 팀원들처럼 다양한 것을 시도해보고, 부딪혀보는 경험을 하지 못했을까 하는 아쉬움이 남는다. 다음 팀 프로젝트에서는 다양한 시도를 많이 해보아야겠다고 생각했다.
4. 좋은 UI/UX 에 대한 이해
2차 팀 프로젝트 최종 발표 시간에 다른 팀들이 발표하는 것을 보면서 같은 기능이어도 다양한 방식으로 구현할 수 있고, 다양한 UI/UX가 존재할 수 있다는 것을 깨닫게 되었다. 일례로 화면 좌측 상단에 Hamburger 버튼을 클릭할 경우 화면 절반을 차지하는 Drawer가 나오게 한 팀도 있는 반면, Dropdown이 나오게 해서 화면 상의 공간을 더 확보한 팀도 있었다. 이렇게 같은 기능 구현했다고 할지라도, 상황에 맞는 좋은 UI/UX로 구현하지 못한다면 반쪽짜리 기능이라고 밖에 볼 수 없다고 생각한다. 따라서 앞으로는 시중에 나와있는 다양한 웹 앱 또는 모바일 앱을 직접 사용해보면서 다양한 UI/UX에 대해 경험해보고, 해당 기능을 어떻게 구현했을지 생각해보며 직접 구현해볼 예정이고, 궁극적으로 유행하는 UI/UX에 대한 감을 찾을 예정이다.
1. 다양한 개발 패러다임에 대한 공부
React 앱을 만들 때 사용되는 다양한 개발 패러다임에 대해 공부하면서, 같은 React 앱이라도 구조 상 더 좋은 앱을 만들기 위해 노력할 것이다.
2. 좋은 개발자들의 코드 참고
그동안 개발 시에 애매하다고 생각하는 부분(폴더 구조를 잡는다거나, 컴포넌트 구조를 잡는다거나 등)에 있어, 확신이 들지 않더라도 내가 생각하는 좋은 방식대로 진행했었다. 앞으로는 인터넷에서 좋은 구조를 더 찾아보고 왜 그 구조가 좋은지 등을 따져가며 개발을 진행해야겠다고 생각했다.
3주 간 React + TS로 프로젝트를 진행하면서, React로 개발 시에 알아야 하는 다양한 개념들에 대해 배울 수 있었다. 그동안 Frontend와 Backend 중에서 어느 분야를 선택할지에 대한 고민이 많았는데, 이번 React를 배우면서 나는 Frontend 작업을 할 때 좀 더 즐겁고, 몰입이 된다는 것을 깨닫게 되었다. React에 대해 더 공부하고 익히면서 좋은 Frontend 개발자가 되기 위해 노력할 것이다.
3주 동안 밤새며 같이 고생한 팀원들과, 항상 좋은 방향으로 갈 수 있게끔 조언해주신 코치님들께 감사 인사를 전하며, 마지막에 있을 데모데이까지 열심히 해서 유종의 미를 거뒀으면 좋겠다.