[프로젝트] DANGO 4주 프로젝트 회고

🍡 지역기반의 재능 공유 서비스 - DANGO

2주프로젝트가 끝나고 코드스테이츠 크루분 중 한분이 이렇게 말씀하셨다.
'2주 정말 짧았죠? 4주는 더짧습니다.'

정말이었다.
4가 2보다 작아지는 신비한 마법에 걸린 듯한 기분이다.
나도 하나의 서비스를 만들 수 있다는 성취감과 자신감, 그리고 그만큼의 부족함을 느끼게 해준 4주 파이널 프로젝트에 대해 적어보려 한다.
이번회고에서는 서비스에 대한 설명보다는 (궁금하신 분은 위의 링크로 들어가셔서 이용해주세요 😃)
프로젝트를 진행하면서 내가 마주한 문제들과 이를 해결한 과정들, 그리고 배운점 중심으로 적어보려 한다.

4주간 블로깅을 하지는 못했지만, 문제해결과정과 느낀점들을 틈틈이 노션에 적어놓았기때문에
해당 글들을 정리하고 다시 회고해보는 것이 이 글의 목적이 될 것 같다.

---

🙈 코드는 문제를 만들고 문제를 해결한다.

개발자라는 직업을 이야기하는 글을 읽거나 영상을 보면
개발자는 문제를 해결하는 직업이라는 말을 쉽게 들을 수 있었다.
나는 프로젝트 전까지 저 말이 그렇게 공감되지는 않았다.

문제를 해결하는 직업?? 기능을 구현하는게 개발자 아닌가??

이제는 저 말이 무슨말인지 조금은 알 것 같다.
기능구현을 목적으로 한 코드들은 돌아보면 문제가되었고 밥먹고나면 또 문제가 되었다.
그러한 문제들을 해결한 뒤에야 비로소 기능을 구현했다고 말할 수 있었고,
이 과정에서 단순히 기능을 구현했을 때보다 훨씬 많은 것들을 배울 수 있었다.

지금부터 4주간 내가 문제를 해결하면서 배운 점들에 대해 회고해보도록 하겠다.

1. Redux Toolkit에서의 return

배경

2주프로젝트 때 Redux를 사용하면서 느낀 불편함이 2가지 있었다.
Redux 사용을 위해 액션 타입, 액션 생성함수, 리듀서 이렇게 세 종류의 코드를 준비해야한다는 점과
관리하는 상태가 많아질수록 불변성을 유지해야한다는 번거로움이 커졌다는 점이었다.
Redux-Toolkit은 이 두가지 불편함을 해소해주고 좀더 직관적인 코드를 짜게 해줄 것이라는 판단에 사용해보자는 의견을 내었고 팀원들도 적극 동의하여 사용하게되었다.

문제해결 및 배운점

    getChattingData: (state, action: PayloadAction<getChattingDataPayLoad>) => {
      const newState = { ...state, render: [...action.payload.data, ...state.render] };
      return newState;
    },
    setIsJoined: (state, action: PayloadAction<setIsJoinedPayLoad>) => {
      state.otherId = action.payload.otherId;
      state.roomId = action.payload.roomId;
      state.isJoined = action.payload.isJoined;
    },

위의 코드를 보면 리듀서 함수를 쓸 때, return을 쓸 때가 있고 안쓸 때가 있는 것을 볼 수 있다.

Redux Toolkit을 사용하면 불변성을 신경쓰지 않고 mutate한 가공을 할 수가 있었는데,
불변성을 유지했는지 하지 않았는지에 따라 return을 사용해야한다는 것을 프로젝트 시작할때에는 알지못해서 처음 리듀서함수를 만드는 과정에서 헤맸던 기억이난다.

불변성을 유지했다면 새로운 상태를 return해줘야 하며, 유지하지 않았다면 Redux Toolkit에서 리듀서를 생성할 때 내부적으로 사용하는 immer라이브러리에 불변성을 맡기면 된다.

---

2. A non-serializable value was detected

배경

아래의 에러메시지를 프로젝트동안 2번 볼 수 있었다.
A non-serializable value was detected in an action, in the path: register. ...

한번은 Kakao Map API로 생성한 map 인스턴스를 리덕스 스토어에 저장하려고 했던 경우이고,
다른 한번은 모달창에서 실행할 함수를 스토어에 저장하려고 했던 경우이다.

문제해결 및 배운점

에러메시지로 구글링하여 찾아본 결과 Redux에는 직렬화할 수 있는 일반객체만을 저장할 수 있다는 것을 알 수 있었다.
직렬화란 무엇일까?

어떤 환경의 데이터 구조를 다른 환경에 전송 및 저장하기 위해 나중에 재구성할 수 있는 포맷으로 변경하는 과정을 직렬화라고 한다.
간단한 예로는 localstorage가 있다.
localstorage는 값으로 string을 가질수 있지만 object는 가질수 없다.
이럴때 우리는 json.stringify를 통해서 object를 스트링화 한다. 이것이 직렬화다.

Promises, Symbols, Maps/Sets, 함수들, 또는 클래스 인스턴스와 같은 직렬화-불가능한 것들을 리덕스 스토어의 상태나 디스패치되는 액션에 넣는 것을 피하라. 직렬화할 수 없는 데이터를 피함으로써 리덕스 개발자 도구로 디버깅하는 것과 같은 기능이 제대로 동작하게 하며 UI도 예상한대로 업데이트되게 할 수 있다. - 리덕스 공식사이트

실제로 에러메시지와 상관없이 라이브러리의 인스턴스나 함수를 액션에 넣어 스토어에 저장해도
기능은 잘 구현되는 것을 확인할 수 있었다.
그러나 이는 리덕스의 안정성을 위해서 지양해야하는 것으로 이해할 수 있었다.

따라서 map 인스턴스는 전역으로 관리하는 것이 아닌 부모컴포넌트에서 관리하며 props로 전달하는 방향으로 리팩토링했다.
반면 모달창의 경우 어떻게할 지 고민을 많이 했었다.

모달창은 상태를 리덕스에 저장함으로써 전역으로 관리하도록 하여, dispatch할때 action에 모달의 type과 text를 입력하면 모달을 띄울 수 있도록 구현한 상태였다.
이후 추가적으로 예/아니오 버튼을 눌렀을 때 어떤 버튼을 눌렀는지에 따라 다른 함수를 실행하고 싶었으나 리덕스에 함수를 저장할 수 없다는게 문제였다.
고민하다가 action에 callbackName과 callbackData를 추가하여 필요한 함수의 이름과 데이터만을 상태로 저장하고
모달 컴포넌트 내에서 callbackName에 따라 원하는 함수가 실행되도록 로직을 구성했다.

보완할 점

그러나 이후 사용하면서 외부 컴포넌트의 setState와 같은 작업들을 모달 컴포넌트에서 실행하기 힘들다는 점과
실행에 필요한 함수를 모달컴포넌트에서 실행하다보니 함수가 자신이 쓰이는 컴포넌트에 존재하는 것이 아닌 모달 컴포넌트에 모이게되었고 코드의 가독성이 떨어진다는 점을 모달컴포넌트의 부피가 커질수록 확연히 느낄 수 있었다.

최근 다시 찾아보니 리덕스에 직렬화가 불가능한 값들을 액션에 넣기위한 방법을 찾을 수 있었다.
방법은 미들웨어를 사용하여 리듀서에 도달하기 전, 액션을 미들웨어가 가로채서 중지시킨 뒤 Plain Object로 가공하여 리듀서에 전달하는 방법이었다.
따라서 리팩토링과정에서 Redux-thunk를 사용하여 해당 방법으로 모듈을 리팩토링할 예정이다.

---

3. kakao Map의 인스턴스와 talent Data 연결하기

배경

kakao Map method를 사용해서 서버에 저장된 위도,경도에 marker와 infoWindow를 생성한 상황에서
아래와 같이 marker와 infoWindow에 talent정보를 담고, 오른쪽하단의 재능리스트에서 하나를 클릭했을 때 해당하는 marker와 infoWindow를 띄우기위해서는 marker와 infoWindow 그리고 서버의 talent Data를 연결하여 지도가아닌 다른 컴포넌트에서 접근 할 수 있도록 해야했다.

문제해결 및 배운점

처음에는 카카오맵의 marker와 infoWindow 인스턴스에 직접 data를 넣는 방법을 찾아봤다. 그러나 방법을 찾을 수 없어서 고민끝에 infoWindowGroup이라는 이중배열을 새로운 상태로 만들고 그곳에 [talentData, marker, infoWindow]를 담았다. 이 배열로 id가 담긴 marker와 infowindow에 접근하여 이벤트를 걸 수 있었다.

 if (infowindowRef.current.length < talentData.length) {
            infowindowRef.current = [...infowindowRef.current, [talentData[i], infowindow, marker]];
          }

반복문을 순회하면서 useRef를 사용하여 talentData,marker,infoWindow를 한쌍의 배열로 만든 다음 이 값을 infoWindowGroup이라는 상태에 저장하여 외부 컴포넌트에서 사용할 수 있도록 했다.

useRef를 사용한 이유는 useRef에 대해서 공부했을 때 기록한 아래의 특징때문이었다.

리액트 컴포넌트에서의 상태는 상태를 바꾸는 함수를 호출하고 나서 그 다음 렌더링 이후로 업데이트 된 상태를 조회 할 수 있는 반면, useRef 로 관리하고 있는 변수는 설정 후 바로 조회 할 수 있다.

위와 같은 특징을 이용하면 랜더링에 상관없이 안정적으로 세 가지 데이터를 담을 수 있을거라고 생각했다. 또한 벨로퍼트님의 useRef 글에서 useRef를 사용한 변수관리의 예시에 외부라이브러리를 사용하여 생성된 인스턴스가 포함되어있던 것도 하나의 사용이유였다. 이유를 생각해보니 아마 라이브러리로 생성된 인스턴스같이 무거운 객체를 저장할 때는 가변값을 유지할 수 있는 useRef를 사용하면 안정적으로 저장할 수 있기때문이라는 생각을 했고 이러한 이유로 useRef를 사용하여 값을 저장하였다.

이전까지는 useRef를 오직 특정 DOM 을 선택하는 용도로만 사용해왔었는데, 이때의 경험 이후로 컴포넌트 안에서 가변값을 유지하기 위한 변수를 선언할 때 useRef를 유용히 사용할 수 있었다.

---

4. React-router-dom을 쓸때 App에서 Props 전달하기

배경

채팅방을 만들었을 때 상대방의 채팅목록이 실시간으로 업데이트되어야하는 상황이었다.

즉 채팅방을 만드는 재능상세페이지에서 소켓 이벤트를 보낼 수 있어야 했는데 당시 소켓을 생성하는 코드와 소켓에 이벤트를 등록하는 코드가 채팅페이지에 들어가있었다.
따라서 소켓의 코드들을 재능상세페이지와 채팅페이지의 공통부모 컴포넌트인 App.tsx로 옮겨야 하는 상황이었다.

문제해결 및 배운점

처음에는 단순히 아래처럼 Props로 내리면 되지 않을까? 했지만 props가 전달되지 않았다.

<Route path="/detail/:talentId" component={TalentDetailPage} connectSocket={connectSocket} />

conponent에 props를 전달받는 TalentDetailPage를 리턴하는 함수를 넣는 방법도 있었지만, 해당 방법은 해당 컴포넌트를 렌더링할 때마다 언마운트 후 새로운 컴포넌트를 마운팅하는 방법이라 다른 방법이 필요했다.
이후 찾아보니 라우터를 통해 렌더된 컴포넌트에 props를 전달할 때는 component prop 대신 render prop을 사용하면 된다는 것을 알 수 있었다. render prop을 사용하여 functional component를 라우팅 할 수 있었다.

<Route path="/detail/:talentId" render={(props) => <TalentDetailPage {...props} connectSocket={connectSocket} />

이후 TalentDetailPage에서 props를 콘솔로 확인해 본 결과 react-router-dom의 3가지 객체 history,location,match가 함께 들어간 것을 확인할 수 있었다.

---

5. useEffect안에서의 비동기 처리

배경

프로젝트 중반쯤에 겪었던 문제였다. 당시 useEffect의 비동기에 대해 감을 못잡고 있었는데 이 문제를 해결하면서 많은 걸 공부할 수 있었다.

useEffect(() => {
    setRender([]);
    getChats();
  }, [curRoomId]);

const getChats = useCallback((page = 0) => {
                            ...
      server
        .post(`/chats/${curRoomId}`, body)
        .then((response) => {
          setRender([...response.data.data, ...render]);
                            ...
        })

당시 의도한 로직은
다른채팅방을 눌러서 curRoomId가 바뀔때마다 render를 초기화시킨 뒤, getChats를 실행시켜서 새로운방의 채팅내역을 렌더링하는 것이었다.

문제는 curRoomId가 바뀌어도 render가 초기화되지않고 이전채팅방의 render에 계속 쌓이는 것이었다.
render에 메시지데이터가 계속 쌓이면서 모든 채팅방의 메시지가 렌더링되었다.

문제해결 및 배운점

생각해보니 useEffect안의 함수들은 비동기적으로 실행되므로
setRender([])를 기다리지않고 getChats함수가 실행되어 setRender([...response.data.data, ...render]) 이 실행되었을때
초기화되지않은 render가 들어가게되고 이 setRender가 결국 render값을 결정하게된 것 같았다.

useEffect안에서 실행되는 getChats함수는 내부적으로 render와 setRender를 사용한다.
즉 render와 setRender의 변화에 의존성을 갖도록 작업해줘야했다. 이를 위해서 render 상태를 리듀서 스토어에 저장해서 전역으로 관리하고
채팅방목록중 하나를 클릭했을때 render를 초기화해주고 서버에서 채팅데이터를 받을때도 리듀서의 render에 저장하여 화면에 랜더링하는 방향으로 리팩토링했다.

이과정에서 useEffect안에서의 비동기처리에 대해 좀 더 생각하고 공부할 수 있었다.
useEffect에 어떤 함수나 setState를 넣는 것은, deps안의 값에 의존하여 변화를 주고싶기 때문이다.
그런데 같은 useEffect안에서 deps에 의존성을 갖는 함수가 여러개가 있다면 이들은 비동기적으로 작동하기때문에 반드시 비동기처리를 해줘야 한다.

따라서 useEffet안에 여러 함수나 setState를 실행할 때에는 이들간의 연관성을 반드시 체크해보고 연관성을 갖는다면 이들을 또 분리해서 비동기적으로 처리하여 의존성을 명확히 해줘야한다.

---

6. state는 state가 선언된 컴포넌트가 렌더될때 초기값으로 초기화된다.

배경

채팅방간의 메시지가 구분되지 않아서 A채팅방에서 B채팅방 내용이 렌더되는 버그가 발견되었다.
이를 해결하기 위해서 socket.io의 이벤트로 메시지를 받을 때 메시지를 보낸 채팅방의 roomId를 추가로 받았고
메시지가 하나 들어올때마다 lastChat상태에 저장한 뒤, lastChat.roomId와 현재 들어와있는 채팅방의Id상태를 저장한 curRoomId를 비교하여 이 둘이 같을때만 채팅방안에서 랜더링되게 리팩토링하였다.

useEffect(() => {
    if (lastChat && lastChat.roomId === curRoomId) {
      createNewChats(lastChat); // 이 함수가 실행되면 실제 채팅방에 렌더링된다.
    }
  }, [lastChat]);

문제는 채팅방에 마지막메시지가 두번 렌더링되는 것이었다.
분명 컴포넌트가 unmount될 때 useEffect의 cleanUp함수로 curRoomId를 빈문자열로 초기화시켰는데
왜lastChat.roomId와 일치하여 createNewChats 함수가 실행되는 건지부터 확인해야 했다.

문제해결 및 배운점

계속해서 디버깅해본 결과, curRoomId는 초기화되지만 lastchat이 초기화되지 않는 것이 문제였다.
채팅페이지를 나가도 소켓은 계속 연결되어 있으므로 lastChat 상태에 소켓의 마지막 메시지가 실시간으로 들어가게 된다.
그 뒤, 사용자가 채팅방에 들어가는 순간 curRoomId와 lastChat.roomId가 일치하게 되고 createNewChats 함수가 실행되어 렌더링되었던 것이다. 이와함께 서버에 저장되었던 메시지도 렌더링되기때문에 마지막메시지만 두번 렌더링 된다는 걸 확인할 수 있었다.
문제원인을 파악한 다음에는 채팅방을 클릭할 때 lastChat을 null로 초기화시킴으로써 간단하게 해결할 수 있었다.

위의 문제를 해결하면서 컴포넌트의 상태는 컴포넌트가 새로 렌더링될때 초기값으로 초기화된다는 개념을 다시 잡을 수 있었다.
[state 변수명, state를 변화시킬 함수] = useState(초기화값)

lastChat상태는 최상단인 App.tsx에서 선언된 상태이기때문에 임의로 처리해주지 않으면 따로 초기화되지 않았던 것이다.
해당 문제를 해결한 뒤에는 상태가 언제 초기화되는 지를 신경쓰면서 코드를 짜기 시작했다. 임의로 상태를 초기화시켜야 할때는 이벤트핸들러나 useEffect의 cleanup함수를 사용하여 상태를 관리하기 시작하니, 컴포넌트들의 훨씬 더 내 의도대로 작동하는 것을 보고 많은 공부가 되었다고 생각이 든 문제 중 하나였다.

---

7. 그 외

• 상태를 지엽적으로 관리할 지, Redux에 저장하여 전역으로 관리할 지는 컴포넌트간의 deps뿐만 아니라 얼마나 상태를 공유하는 지, 재사용할 컴포넌트인 지 등을 종합적으로 고려하여 결정해야한다.

• useEffect안에서 쓰인 props는 의존성배열(deps)안에 넣어주는것이 규칙이다.

• useCallback 의 deps 안에는 해당 함수에서 사용한 state와 props를 넣어준다. 이때 props로 내려받은 함수를 사용하였다면 해당 함수도 잊지말고 넣어준다.

• react-redux에 내장되어있는 shallowEqual를 사용하면 useSelector를 사용해서 구조분해할당을 하거나 객체,배열을 받을때 해당 값이 변화가있는지 얇은 비교를 알아서 해주기때문에 불필요한 랜더링을 보완할 수 있다.

• 돌아보면 초기에 타입스크립트의 타입을 정할때 ? 나 null, any등을 많은 생각없이 추가했던 것이 코드가 방대해질수록 많은 에러를 낳게 한 것 같다. 리듀서의 payload 타입을 정할때도 나중에서야 함수마다의 payload를 정하기 시작해서 ‘진작에 이렇게했으면’ 하는 생각이 절로 들었다.

---

👨🏻‍💻 Review

엊그제 20주간 달려왔던 코드스테이츠 소프트웨어 엔지니어링 과정이 끝났다.
일주일마다 적게는 한 명, 많게는 세 명의 새로운 페어와 페어프로그래밍을 하면서 나보다 훨씬 잘하는 수강생들도 많이 만났었다.
그럴때마다 어디서 주워들은 '그들이 투자한 절대적인 시간을 존중해야한다' 라는 말을 떠올렸다.

그 말을 되새기면서 그 절대적인 시간의 차이가 벌어지지는 않도록 내가 쏟을 수 있는 시간은 모두 쏟아 공부했던 것 같다.
친구들과의 약속도 모두 미뤄서 6월달에 약속이 참 많이도 쌓였고, 꾸준히 하던 운동도 하지못해서 몸무게는 6kg이나 빠졌다.
프로젝트를 시작하고나서는 보리와의 산책도 가족들에게 부탁했다. 보리야미안해...😢

프로젝트를 시작하기 전, 그동안 내가 배운것들을 제대로 활용해서 프로젝트에 녹아낼 수 있을까? 라는 걱정도 많았지만 프로젝트 중간중간 다양한 문제들에 부딪혔을 때 너무많은 도움이되었다. 특히 프로젝트전까지 매일 썼던 블로그 글들이 너무 도움이 많이 돼서 그때의 나를 매우매우 칭찬해주고싶다. 잘했어잘했어~

또한 팀원들한테도 너무 감사하다. 다시말하지만 당신들을 만난걸로 이번년도의 행운 전부..는 좀 그렇구 반정도는 쓴 것 같아...
팀원들과 프로젝트를 진행하면서 절대적인 시간량을 늘리는 것보다 중요한게 시간을 효율적으로 쓰는거라는걸 절절히 느꼈다.
팀원들의 의견을 따라 스프린트별로 일정을 세우고 매일아침 오늘의 목표를 작성하며 하루를 시작하니, 우선순위가 확실히 정리되고 작업속도가 빨라지는 것을 체감할 수 있었다.
나는 우선순위를 생각하지 못하고 계속 꼬리물기로 작업이 이어지는 경우가 많았는데 앞으로는 항상 우선순위를 생각하는 습관을 들여야겠다는 다짐을 했다.

이제 다음 스텝을 준비해야 한다. 돈받고 코딩하기!!💸
할 것들이 참 많다. 프로젝트에서 개념적으로 부족하다는 걸 많이 느꼈기때문에 기본부터 다시 제대로 공부해볼 생각이고,
프로젝트에서 미처 구현하지못했던 기능들의 구현, storybook 사용, redux-thunk를 사용하여 action에 함수를 전달하는 방향으로 모달창 리펙토링, 콘솔이아닌 debugger를 사용한 디버깅에 익숙해지기...

너무많이 쉬면 번아웃이 올 것 같다는 느낌이 강하게 들기에 조금만 쉬고 다시 시작해야겠다.
우선 정상적인 생활로 돌아가기부터 해야할 것 같다.😅
고생했고 고생하자~ (토닥토닥)
⛳️