공통 컴포넌트 설계 여정

🎯 개요

최근 회사에서 공통 컴포넌트를 분리하는 리팩토링 작업을 하면서 느꼈던 공통 컴포넌트 분리할 때 고려해야 하는 것들, 재사용성을 높이기 위한 노력들, 그 과정에서의 실수와 고민거리 등등을 정리했습니다.

 

---

 

📒 과거의 나의 실수

📌 UI가 비슷해보이면 무조건 하나로

똑같은 코드가 중복되는 건 무조건 나쁜 코드(?)인 줄 알았습니다. UI만 비슷해 보이면 이건 앞뒤 잴 필요도 없어 무조건 공통 컴포넌트로 분리해야 하는 코드로 정의했습니다. 이건 연쇄적인 문제점들을 떠안고 왔는데요.

 

📌 눈덩이처럼 불어나는 나의 공통 컴포넌트

서비스에서 사용되는 모든 UI들을 하나의 컴포넌트로 묶어야 한다는 강박에 억지로 props, emits들을 끼워 맞추게 되고, 오만가지 분기처리와 예외처리들이 생겨났습니다.

처음에는 아무 문제없어보여도 서비스를 디벨롭해나가면서 요구사항이 복잡해지니 나중에는 특정 도메인에서만 사용되는 props를 만들어버리는 지경까지 이르렀습니다. (지금은 당연히 없어진)

 

📌 세상에서 제일 무서워진 UI 변경 요구사항

당연히 UI 변경 요구사항이라도 생기면 아무리 사소해도 신경써야할 부분들이 많아지고 이미 거대해진 컴포넌트를 어떻게 건드려야할지 막막하기만 해 스불재(스스로 불러온 재앙)가 되었습니다. 어떤 사이드 이펙트가 생길지 예상하기도 힘들어졌습니다.

 

📒 깨달은 점

📌 UI가 비슷해보인다고 다 공통으로 만드는게 좋은 것은 아니다

이런 거대 공통 컴포넌트를 만들지 않으려면 UI가 비슷해 보인다고 무조건 공통으로 만드는 것이 아니라 일단 UI를 기준으로 비슷해 보이는 것들을 묶어보고, 이것들을 도메인(관심사)의 관점에서 다시 봐야 합니다.

 

Input 컴포넌트의 UI가 비슷해 보인다고 로그인/회원가입의 Input 컴포넌트와 서비스의 다른 도메인의 Input 컴포넌트를 하나의 공통으로 묶는 것이 아니라 분리해야 한다는 점입니다. 

 

도메인이 다르기 때문입니다.

 

📌 UI와 로직을 분리하자

그래서 공통 컴포넌트를 만들 때는 기능은 없고 UI만 있는 컴포넌트를 만들면 중복 코드를 줄일 수 있습니다.

 

처음부터 UI가 비슷하다면 그 비슷한 UI만을 갖고 있는 컴포넌트를 만들고,

그 컴포넌트를 사용하는 쪽에서 커스텀 훅을 통해 로직을 주입해 주면 됩니다.

 

 

---

 

🎯 마무리

UI만 보고 무조건 공통으로 분리하는 것보다 도메인(관심사)를 보고 분리하면 중복 코드를 줄이면서도 재사용성도 높이는 컴포넌트 설계를 할 수 있습니다.

이런 관심사의 분리가 아직 익숙하지는 않지만 꾸준히 의식적으로 노력하다 보면 언젠가 자연스럽게 관심사를 분리하고 있는 내가 되어 있지 않을까요 ?!