항해 99 5주차 회고록 - 리액트와 전역 상태 관리, CSS 라이브러리와 리액트

5주차 주특기 심화과정이 끝났다. 음 .. 솔직히 이번주는 아쉬움이 많이 남은 주차인데, 다음주 처음으로 백엔드 분들과 팀을 이루어서 첫번째 미니 프로젝트를 진행한다. 도움이 되고 싶은데 민폐가 되지 않을까 걱정이다. 

같이 일하기 좋은 개발자란? 무엇일까?
스스로를 개발자라고 칭하기에도 부끄러운 수준이라 해당 내용에 대해 생각해 본 적은 없지만, 질문을 조금 바꿔서 같이 일하기 좋은 동료는? 에 대해 생각해본다면...

그 사람에게 질문을 하거나 말을 거는데에 타인이 서스럼 없어야 한다. 조금 풀어 설명하자면 타인이 용기있게 물어봐야 한다는 의미가 아니라 반대로 내가 다른 사람에게 편안한 사람이 되어야 한다고 생각한다. 말도 못하는 상황에서 좋은 팀워크가 이루어지지 않는다고 생각한다. 대학교를 다니고 군대를 다녀오면서 "편안한 사람, 내가 쉽게 질문할 수 있는 사람은 어떤 공통점을 가지고 있을까"를 많이 생각해봤는데, 그런 사람들의 공통점은 질문자의 생각을 리스펙한다는 점이다. 또한 자신의 생각도 틀릴 수 있다는 마인드가 있는 사람들에게 편안함을 느끼는 것 같다. 예를 들어 질문을 했는데 '에이 그것도 몰라요?,' '그건 말도 안되는 생각이지', '이건 무조건 이렇게 하는게 맞아', '그냥 모르면 내말좀 따라와' 라고 하는 사람들에게서 어쩔 수 없는 상황을 제외하고 두 번 이상 질문한 경험이 없는 것 같다. 

다음주 처음으로 하는 프로젝트에서도 이러한 마인드셋을 가지고 팀프로젝트를 임해야 할 것 같다. 글을 적다보니 항해에서 이번주 주제로 같이 일하기 좋은 개발자라는 내용을 선정했는지 알 것 같다.

최대한의 노력으로 최대한의 도움이 되자! 

 

리액트에서 전역 상태 관리가 왜 필요할까?

처음 듣는 전역 상태 관리라는 말은 너무 어렵게만 느껴졌다. "매번 개발자들은 어려운 용어를 만들어서 이해하기 어렵게 하는거지?"라고 생각했는데, 리액트를 공부하고 상태라는 것을 배워보니 "아.. 전역 상태 관리라는 단어만큼 딱 어울리는 단어가 없구나?"라고 생각이 든다. 

리액트에는 state와 props 라는 이름으로 데이터를 나누는데, 쉽게 말해서 자기 자신이 가지고 있는 데이터를 state 라고 하고, 부모로 부터 받은 데이터를 props 라고 한다. 

나도 아직 리액트를 공부한지 얼마 되지 않았지만, 생각해보면 뒤에 나올 rudux 혹은 다른 상태관리를 위한 라이브러리를 사용하지 않더라도 리액트의 상태를 관리할 수 있다. 하지만 그것이 효과적인 방법인지에 대해서는 확실히 아닌 것 같다. 

리액트는 여러가지의 컴포넌트로 구성되어 있다. 멘토님이 말하시길 100명의 개발자가 리액트를 활용해 개발을 한다면, 100개의 프로젝트 모두 다른 형태를 가질 만큼 리액트는 자유도가 높다고 하신다. 사람들이 정해놓은 어느정도의 규칙정도는 있겠지만 그것이 무조건적인 내용은 아니라는 것이다. 1개의 페이지를 100개의 컴포넌트로 나눠서 개발할수도 있고, 1~2개의 컴포넌트로 개발을 할 수 있다. 그렇다면 데이터는? 

만약 100개의 컴포넌트에 하나하나 state를 줘야할까? 만약 모든 state가 다르다면 상관 없겠지만, A 컴포넌트와 B 컴포넌트가 같은 state를 필요로 한다면? 같은걸 2번 적어야 할까? .. 그건 아무리봐도 비효율적이다.

그렇다면 A,B 컴포넌트의 부모 컴포넌트에 state를 주고 props로 내려받으면 될까? 그렇게 되면 결국 부모 컴포넌트에 없어도 될 state가 넘칠 것이고, B컴포넌트에서만 필요한 데이터를 굳이 props를 통해 받아야 할 것 이다. 깊은 depth를 가진 구조에서도 복잡한 경우가 생길 것이다.

그래서 컴포넌트의 상태를 전역에서 관리 할 필요가 있는 것이다. 매번 느끼지만 모든 기술들은 필요에 의해서 만들어지는 것 같다.

그렇다면 모든 데이터를 전역으로 관리하는 것이 좋을까?

여기에 대한 고민도 해봤다. 학창시절부터 시험을 보게 되면 문제지에 '무조건, 반드시, 모든, 분명히' 라는 키워드가 있는 선택지는 답이 아니였다. 이 경우에도 그러하다. 결론을 말하자면 모든 상태를 전역에서 관리하는 것은 옳지 않다.
상태 의존성이 높은 경우에는 전역 상태 관리를 하는 것을 추천하고 그렇지 않은 경우 (개별 컴포넌트에서만 필요한 경우) 에는 지역 상태로 관리하는 것이 redux의 경우 store의 부담도 줄이고 코드를 관리하는데 더욱 효율적이라고 생각된다.
action, action 생성함수, dispatch, reducer 등등.. 필요한 파일과 폴더도 많아지기도 하고 말이다. 

CSS 라이브러리와 리액트

사실 여기에 대해서는 크게 할 말이 없다. 항해에서 배우는 수업에서는 머테리얼 UI를 배워보는 시간도 있었는데, 만들어진 디자인을 가져와서 편하게 쓰는 것은 좋은데, 모든 부분이 내 마음에 들지도 않을 뿐더러 , 변경하고 싶은 내용을 변경할 때 이미 작성된 코드를 수정하는 작업이 나는 직접 작성하는 것보다 더 걸리는 것 같기 때문이다. 하지만 디자인을 참고할 때 분명 좋은 방법이라고 생각한다.