더 이상 토이 프로젝트를 만들지 않는 이유 (부제. 좋은 컴포넌트 만들기)
# 고민
나는 4번째 토이 프로젝트를 끝내고, 회고를 작성하면서 프로젝트에 대해 다시 생각해 보았다.
"무엇을 잘했고 무엇을 못했을까?"
가장 먼저 생각난 것은 내 코드의 유지보수의 불편함이었다. 그만큼 내가 결과물에 집착해서 개발을 했다는 것이다.
토이 프로젝트는 나를 성장시키기 위한 도구일 뿐이다. 나는 현재 프론트 엔드 분야로 취업에 목말라 공장처럼 프로젝트를 찍어 내고 있었고, 그 결과 "좋은" 코드를 만드는 것보다 "구현"에만 집중한 코드를 만들고 있었다.
그렇게 내 코드는 똥💩이 되었다.
( 아... 이래서 지금, 모든 회사에서 서류 탈락하고 있구나? ㅋ )
나는 "재사용 가능한", "유지보수가 편리한" 컴포넌트를 만들어야 한다는 것을 안다. 하지만 코딩을 할 때는 이 이론은 머릿속에서 점점 잊혀 가고 결과에만 집중한 코드를 생산하게 되고, 결국 이 코드는 나중엔 큰 쓰레기🚮로 나에게 다시 돌아온다.
이 고민을 하고 난 후 나는 더 많은 프로젝트를 생성하는 대신, 기존 프로젝트를 개선해 나가기로 결심했다. 그리고 컴포넌트에 대한 다양한 영상을 찾아보았다.
# 핑계 - 망할 유튜브
내가 본 영상들이 나쁘다는 것은 아니며, 내가 봤던 강의들(강사들)이 별로다라는 것도 아니다.
영상들을 통해 프로젝트 구조, 다양한 라이브러리들, 다양한 훅들을 사용해보면서 다양한 접근 방법을 배웠 고 성장했다고 말할 수 있다.
나는 사실상 리액트를 유튜브로 배웠다고 말할 수 있다. 나는 Vue를 알고 있기 때문에 유튜브로 프로젝트를 만드는 영상들을 보면서 리액트를 배웠다. 일반적인 리액트 책들에서는 TODO 리스트, 게시판 같이 간단한 것만 예제로 나오지만, 유튜브에는 노션, Trello, 쇼핑몰 등 더 큰 규모의 사이트들을 만들기 때문에 "회사에서도 이런 구조로, 이런 방식으로 코딩하겠구나" 생각했다.
겉으로 보이는 것과 안은 다르다. 유튜브에 나오는 프로젝트 만드는 영상은 실제 회사에서 만드는 프로젝트들과는 다르다는 점을 인지하고 봤어야 했다. 분명히 실제 사이트는 훨씬 더 복잡한 코드로 구현되어 있을 것이다. 하지만 난 그 틀에 갇혀버렸다. 나는 유튜브 선생님을 믿고, 찬양했다. 그게 곧 답이다라고 생각했다.
# 성장 - 사랑해요 유튜브
가장 먼저 컴포넌트에 대해 고민했고, 어느 한 영상이 나를 이끌었다. 배민 유튜브 [10분 테코톡]이였다. 그 후 5~8개 정도의 컴포넌트 관련 영상을 봤다.
영상들 중에서 가장 와닿는 말은 이것이었다.
사용자가 제품을 어려움 없이 잘 사용해야 한다. 하지만 실제론 그렇지 않다. 그렇기 때문에 많은 변화를 겪는다.
제품은 변화를 겪으면서 올바른 방향으로 성장한다. 변경은 정해져 있는 것이 아니기 때문에 변경을 예측하지 말고 대응해야 한다.
- SLASH 22 Effective component 지속 가능한 성장과 컴포넌트
결국엔, 그러기 위해서는 "컴포넌트를 잘 활용해야 한다."는 것이다.
# 컴포넌트의 분리
컴포넌트를 분리하는 이유는 코드의 복잡도를 낮추고 모듈화하여 재사용이 가능하도록 하는 것에 있다. 컴포넌트가 중복되거나 적당히 커지면 분리하는 것이 아닌 컴포넌트를 분리하는 데는 이유가 있어야 한다.
# 변경에 유현한 컴포넌트
- SLASH 22 Effective component 지속 가능한 성장과 컴포넌트
- Headless 기반의 추상화하기 ( 변하는 것 VS 변하지 않는 것 )
- 스타일(UI)은 없는 컴포넌트
- 변하는 것 = UI / 변하지 않는 것 = Data
- 동작(상호작용)을 Hooks으로 추상화하기
- 한 가지 역할만 하기 또는 한 가지 역할만 하는 컴포넌트의 조합(Composition)으로 구성하기
- 도메인 분리하기 (도메인을 포함하는 컴포넌트와 그렇지 않은 컴포넌트 분리하기 )
- 일반적인 인터페이스로 분리하기 → 이유? 컴포넌트의 역할을 이해하기 쉽다.
- 사람들은 일반적으로 기존에 알고 있는 지식(배경지식)을 바탕으로 파악한다. 그래서 사람마다 배경지식이 다르기 때문에 일반적인 단어로 표현해야 의도를 들어내기 쉽다.
그리고 대부분의 영상이 관심사가 분리된, 재사용성이 높고 유지보수가 용이한 컴포넌트를 만드는 방법으로 크게 세가지 였다.
- Headless Component Pattern
- Composition Component Pattern
- Custom Hooks 이용
영상은 봤지만, 범용적인 예제를 확인해 보고 싶었다. 그리고 그 예시는 생각보다 쉽게 찾을 수 있었 다. 바로 내가 모든 프로젝트에서 사용했던 Shadcn/ui이다. 공식 홈페이지를 보면 "이건 라이브러리가 아니고, 재사용 가능한 컴포넌트이기 때문에 원하는 곳에 복붙 해서 입맛에 맞게 설정해서 사용하라"라고 설명되어 있다.
예를 들어 shadcn/ui에서 제공하는 tabs ui를 만드는 방법을 보면, 제공하는 컴포넌트들을 조합해서 입맛에 맞게 다양하게 탭을 만들 수 있도록 한다.
그리고 Shadcn/ui는 Radix ui위에 스타일을 입힌 ui이다. 따라서 따로 스타일을 적용하지 않아도 UI가 아름답게 꾸며져 있다. 그렇기 때문에 shadcn/ui에서 스타일을 수정하긴 쉽지 않다.
즉, 아래와 같은 패턴으로 만들어졌다고 볼 수 있다고 생각이 들었다.
- Radix UI → Headless Pattern
- Shadcn/ui → Composition Pattern
결국 나는 Headless와 Composition 패턴을 모두 보았고, 그게 이 방식인지 몰랐었을 뿐이었다. 🤔
# 결론 - 리팩토링
새로운 프로젝트를 만들어 보면서 다양한 에러/문제를 경험하고 헤쳐나가는 것도 좋은 성장 방법 중 하나이지만, 이번에는 더 이상 새로운 프로젝트를 만드는 것이 아닌 기존 프로젝트를 바꿔나가는 것이 좋을 것 같다는 생각이 들었다. 회사에 입사해서도 매번 새로운 프로젝트를 하는 것이 아닌 기존 레거시 프로젝트에 기능을 추가하거나 리팩토링 하는 작업이 대부분이기 때문이다.
물론 이 코딩 패턴이 정답은 아니다. 컴포넌트만 바꾼다고 완벽한 코드가 될 순 없다. 가장 간단한 프로젝트였던 내가 가장 처음 시작한 프로젝트부터 하나씩 바꿔보면서 너무 결과물에만 집중하지 말고 다양한 방식을 보며 다양한 것을 배우고 성장해 나가는 것에 목표를 두고 싶기에 시도해 보는 것이다.
그래서 당분간은 새로운 프로젝트 개발보다는 리액트라는 라이브러리에 또는 프런트엔드에 대해 좀 더 깊게 공부하는 시간을 갖도록 공부 방향을 바꿔볼 것이다.