서론

클라썸에 인턴을 지원하게 되며 처음으로 입사 과제를 진행했다. 일주일이라는 시간 동안 주어진 주제 및 기술로 토이 프로젝트를 구현해야했다.

자세한 과제 내용은 대외비라 이야기 하지 못하지만, 공식 홈페이지에 Redux & React 를 사용해 과제를 구현한다는 내용은 적혀 있으므로 이와 관련한 회고를 진행할 예정이다.

아쉬운 점

첫 과제라 그런 건지, 아니면 정답 자체가 없는 문제여서 그런 건진 모르겠지만 뿌듯하다! 라는 느낌보단 아쉬운 점만 많이 남은 과제였다.

처음 써보는 Redux

데브코스를 진행하며 한 번도 Redux 를 써보지 않았던 점이 발목을 잡았다. 지원 페이지를 읽을 때도 Redux 를 사용해야 한다고 하길래 겁이 조금 났다. dispatch 와 actions... 그 많은 것들을 피하기 위해 Jotai 나 Recoil 을 택했지만 역시 실무 최강자는 Redux 였다. 🥹

그래도 Redux 가 어떻게 굴러가는 지 이론 상으로나마 알고 있었기 때문에 빠르게 적용할 수 있었다. 하지만...딱 거기까지, Redux 를 효율적이고 올바르게 사용하고 있다는 생각은 들지 않았고 다음 문제가 계속 거슬렸다.

• store 폴더 구조를 잘 관리하고 있는가?
• useSelector 로 필요한 state 만을 가져오고 있는가?
• 불필요한 렌더링이 발생하진 않았나?

이런 문제들 중 렌더링이 가장 크게 신경 쓰였다. 예를 들어 가장 좋아하는 음식들을 렌더링 해주는 FoodInfo 라는 컴포넌트가 있다고 가정하고, 그 때 사용하는 데이터는 아래와 같다.

person.favoriteFoods.map(food => <FoodInfo food={food} />);

const person = {
	name: '수연',
    favoriteFoods: [
		{
          name: '케이크',
          type: '디저트',
          location: ['00제과', 'XX빵집']
        },
        {
          name: '딸기',
          type: '과일',
          location: []
        }
    ]
}	

여기서 케이크 맛집 리스트인 location 에 장소를 하나 더 추가하면 케이크 와 관련이 없는 딸기 까지 렌더링 되는 문제가 있었다.

찾아보니 useSelector 의 equalityFn 으로 left 와 right 값을 비교해 값이 같다면 렌더링을 하지 않을 수 있다고 한다.

equalityFn?: (left: any, right: any) => boolean

이걸 이제서야 알았다니...! 더불어 useCallback 이나 useMemo 등을 적재적소에 활용하지도 못하기도 했다. 과제 구현 내용 자체가 렌더링이 아주 잦을 수 밖에 없었는데, 그걸 고려하지 못했기 때문에 아쉬움이 유독 많이 남는다.

컴포넌트 설계에 대한 아쉬움

데브코스의 과제를 진행하며 컴포넌트 구조 설계를 우선적으로 하는 습관이 들었지만 그게 늘 최선의 설계는 아니었다. 멘토님의 반응만 보아도 안다 🥹

이번 과제에서도 설계가 미흡하지 않았나, 싶다. 설계가 미흡하다 보니 다음과 같은 문제들이 있었다.

• 내가 지금 어디까지 구현했고, 다음은 어디를 구현할 차례인지 헷갈린다
• 중복되는 로직, 컴포넌트가 많다
• 폴더구조를 자주 바꿨다
• 렌더링 비용이 증가했다
• 필요한대로 로직을 이곳저곳에 끼워넣었다...

참... 부끄러운 코드가 되었다. 🥲

코딩 테스트를 풀 때도 어떻게 풀어야 할지 감이 잡히면 순서를 세워야 하는 타입인데, 그걸 잊고 무작정 부딪히혔다.

다음 과제가 주어진다면 반드시! 기능 구현 목록을 차례대로 정리한 뒤 하나씩 해치워 나가겠다고 다짐한다.

공통 컴포넌트 분리

CSS 를 일일이 내 손으로 입힐 시간이 없다보니 이번엔 Emotion + Chakra UI 를 사용해 컴포넌트를 구현했다.

자주 사용되는 컴포넌트들이 있었고, 일일이 프로퍼티를 작성하기 힘들었기 때문에 공통 컴포넌트로 분리했는데 또 다음과 같은 문제가 생겼다.

• 특정 컴포넌트는 공통 컴포넌트로 만들고, 특정 컴포넌트는 만들지 않았다.
• 가다 보니 공통 컴포넌트로 가는 property 의 개수가 증가했다.
• 그렇지 않은 경우 확장성이 약해졌다.

특히 프로퍼티가 증가하는 문제는 공통 컴포넌트를 만들 떄 항상 겪는 딜레마인 것 같다. 이것도 필요하고 저것도 필요한 컴포넌트가 되어버린다. 설계의 부족함과도 연결되었겠지만 말이다.

아무튼 이렇게 공통 컴포넌트로 또 한번 난항을 겪고 나니 이번에야 말로 Headless 🤯 컴포넌트 에 대해 공부할 필요가 있다고 느꼈다.

로직 분리에 대한 고민

비즈니스 로직과 UI 로직은 확장성과 재활용성, 그리고 가독성을 위해 분리해야 한다는 걸 알고 있다.

그런데 내가 배운 방법이 차마 몇개가 되지 않다보니 (1개... 정도?) hook 으로 분리시켜 버리는 게 다였다. 그렇게 로직을 마구마구 분리하다 보니 다음과 같은 생각이 들었다.

• 하나의 훅에 컴포넌트에서 사용하는 비즈니스 로직을 모두 작성하는 게 맞나?
• 이렇게 하면 코드가 읽기 편해지나?
• 어떤 걸 훅으로 분리하고 어떤 걸 분리하지 않아야 하지?

코드 작성의 기준을 여태 팀 프로젝트에 맞추어왔고, 본인만의 주관이 없다 보니 뒤늦게 이런 고민을 하게 되었다.

코드를 깔끔하게 정리하고 싶어하고, 그걸 중요시 여기지만 막상 그 방법은 모르는 것 같아 디자인 패턴과 비즈니스 로직 분리에 대해 다시 찾아 읽어야겠다.

결론...

나름대로 수정을 거듭해서 그래도 코드 꼴(?) 을 갖춘 프로젝트가 되긴 했지만 중간중간 일관성이 없는 코드를 볼 때마다 헛웃음이 나온다. ㅠㅠ

통과할 수 있을 거라는 자신감이 코드를 볼 때마다 사라져서 다음엔 이런 실수를 미연에 방지하자는 의미로 이렇게 회고를 남기게 되었다.

물론 이번 과제를 하며 얻은 경험도 무지 많다. 특히 여러 에러를 마주했고 이를 해결하는 과정은 다른 사람들에게 도움이 될지도 모르니까 추후에 정리해보려고 한다.

처음으로 입사 과제를 한 만큼 의미있고 보람찬 일주일이었다. 이런 기회를 제공해준 클라썸 회사 인사팀에게 감사하단 말씀을 전하고 싶다 😀