부스트캠프의 그룹프로젝트 2주차를 마쳤다.
배운것
왜? 를 조금 더 날카롭게
사실 이전까지는 어떤 문제를 해결하는데 현재 상태로는 구현이 불가능하다 싶으면 찾아봤을때 가장 먼저 나오는 라이브러리를 아무 생각없이 다운로드 받아 사용하기 일수였다.
하지만 이번 프로젝트부터는 왜 이 라이브러리를 사용해야하는가? 를 조금 더 고민했다.
왜 이 라이브러리를 사용해야하는가? 를 고민해야하는 이유는 여러가지를 되짚어보며 명확히 할 수 있기 때문이다.
1. 우리가 하고자 하는 것은 무엇인가?
2. 현재 우리가 겪고 있는 문제는 무엇인가?
3. 우리가 겪는 문제의 본질은 무엇인가?
4. 그 문제의 본질을 이 라이브러리가 해결해 줄 수 있는가?
5. 이 라이브러리보다 더 여러 가지 기준에서 더 나은 라이브러리는 없는가?
6. 혹은 라이브러리를 작성하지 않고 직접 기능을 구현하는 것이 더 효율적인가?
이렇게 하다보면 프로젝트, 그리고 내가 겪는 문제에 대한 메타인지가 높아지고, 이에 대한 해결책을 얻을 수 있게된다.
예를들어 이번 주차에는 전역상태 라이브러리를 선택해야만 했다.
하나씩 흐름을 확인해보자.
1. 우리가 하고자 하는 것은 무엇인가?
마이크 on/off, 카메라 on/off옵션을 설정 화면과 Room내부에 접속해서도 변경할 수 있어야 하고 두 상태는 공유되어야한다.
2. 현재 우리가 겪고 있는 문제는 무엇인가?
이걸 상위 컴포넌트에서 상태를 만들어서 내려주면 구현할 수 있겠지만, props drilling이 생기게되어 가독성이 나빠지고, 관리하기 힘들어진다.
3. 우리가 겪는 문제의 본질은 무엇인가?
하나의 상태를 여러 컴포넌트간에 공유해야하는데, 그것을 구현하는 것이 기존의 코드로는 힘들다.
4. 그 문제의 본질을 라이브러리가 해결해 줄 수 있는가?
그렇다. 전역 라이브러리는 redux, recoil, jotai, zustand등이 있다.
5. 이 라이브러리보다 더 여러 가지 기준에서 더 나은 라이브러리는 없는가?
이전 같았으면 이전에 사용해본 기술이고, 잘 사용할 줄 안다는 이유 하나로 recoil을 택했겠지만, 지금은 여러가지 기준을 세워 우리 프로젝트의 상태에 맞는, 적절한 상태관리 라이브러리를 선택할 수 있었다.
아래 표가 그 기준이었다.
| recoil | zustand | |
| 번들사이즈 | 2.17MB | 187KB |
| 상태관리방식 | 상태 위주의 관리 | 상태와 상태를 변경하는 함수를 따로 작성하여 관리 |
번들사이즈가 작고, recoil은 프로젝트 사이즈가 커지게되는 경우 전역상태를 결국 action을 담은 custom Hook으로 만들어 사용하게 된다고 하기에 zustand를 택하게 되었다.
6. 혹은 라이브러리를 작성하지 않고 직접 기능을 구현하는 것이 더 효율적인가?
react 에서는 Context라는 API를 제공한다. 다만, 단점이 명확하기에 선택하지 않았다. 특히 이 단점은 우리 프로젝트의 컴포넌트 구조에서는 더욱 치명적으로 작용할 수 있엇다.단점은 여기를 참고하면 좋을 것 같다.
회고의 힘
개인적으로 글을 쓰며 회고하는 방식은 챌린지때부터 시도하면서 지속해오고 있는 방법이라 그 효과를 너무나도 잘 알고 있었는데, 이번에 프로젝트 팀단위의 회고를 제대로 진행하면서 이부분을 크게 느낄 수 있었다.
좋았던 점들을 나누고, 부족한 점들을 각자 제시한 뒤에 개선방안까지 제시하는 형태로 진행했는데, 덕분에 각자의 의견을 합쳐서 새로운 시스템을 만들어 낼 수 있었다.
우리 팀은 두가지 문제를 공통적으로 느끼고 있었는데,
1. 구현량, 코드 작성량이 많다보니 분업에 가깝게 진행되었다.(공유, PR리뷰의 부족함)
2. 문서화의 부족함
이 두 가지 문제를 해결하고자 새로운 PR시스템을 만들어냈다.
기존의 PR로직은
이런 과정이었다면, 개선된 PR로직은
요런식이다!
그리고 이걸 서로가 케어해주는 형태로 진행해보기로 했다.
놀랍게도 이런 문제를 팀원 대부분이 느끼고 있었다.
회고를 하지 않았다면 아마 우리 팀은 알면서도 누군가 말하기 전까지는 이 문제를 해결하지 못했을 것이다. 회고하는 시간을 반드시 가져야겠다고 다짐했다.
개선해야할 점
조금 더 체계적으로 작업하기
이전에는 더 심했지만, 나는 우다다다 개발하는게 너무 문제다.
크게 봤을때 프로젝트 관리부분에 대해서는 백로그를 사용하는 형태로 개선하여 주단위로 체계적으로 작업할 수 있었다.
하지만, 하루단위로 들어가면 나는 여전히 우다다다 작업을 하고있다.
이 때문에 A를 하다가도 문제가 생기면 B를 해버리는 경우가 간혹 있었다.
이러면 설계도 제대로 안되고, 정리도 제대로 되지 않는다.
지금까지는 그래도 얼레벌레 둘다 해냈지만... 다음주에는 A도 못하고 B도 못하는 상황이 올 수 있다.
그래서 이건 개선이 필요하다.
오늘 할 일을 정해놓고, 이걸 체크해가면서 개발하는 형태로 개선해볼 생각이다.
또한 하나의 일을 체크했을때, 얼마나 걸리는지도 좀 더 정확하게 측정해서 나의 작업 효율이 얼마나 되는지도 확인해보려고 한다.
개선한 로직을 잘 실천하기!
나는 회의해서 결정한 내용, 하기로 했던 내용을 까먹는 경우가 잦다...
그래서 의식적으로 이걸 계속해서 확인하고, 실천할 필요가 있다.
의식적인 문서화
개발할때의 고민을 조금 더 짧은 주기로 남겨서 문서화하자. 지금도 하고 있기는 하나 까먹기 일수다.
문서화를 해야 그 과정에서 기술적으로도 도움이 되고, 협업시에 공유도 되며, 회고할 때도 그때의 사고를 되짚어볼 수 있다.
이제 그룹프로젝트도 4주밖에 남지않았다.
다음주는 온전히 기능개발에 몰두하여 대부분의 기능을 구현해볼 계획이다. 이후 남은 2주간 우리의 기능을 좀더 날카롭게 벼려낼 것이다.
다음주도 화이팅!
