프론트엔드 컴포넌트 설계와 컨벤션에 대한 고민: 통합 vs 분리, 어떤 것이 정답일까?

들어가며

프론트엔드 개발을 시작한 지 얼마 되지 않은 개발자라면 누구나 한 번쯤은 고민하게 되는 문제가 있습니다. "컴포넌트를 어디까지 나눠야 할까?"
저 역시 기존 보일러플레이트를 활용한 개발에서 점점 커져가는 컴포넌트와 늘어나는 중복 코드를 보며 같은 고민에 빠졌습니다. 그리고 최근 팀 내 동료 개발자들과 나눈 논의를 통해 중요한 인사이트를 얻을 수 있었습니다.

 

거대해져 가는 컴포넌트

현재 상황

• 남이 만든 보일러플레이트에서 복사-붙여넣기로 시작한 개발
• 나름대로 컴포넌트화를 시도했지만 중복 코드가 계속 증가
• 하나의 컴포넌트에 모든 기능을 담으려다 보니 관리가 점점 어려워짐

실제 예시를 들면, 프로젝트를 진행하면서 다양한 화면에서 검색 기능이 필요했습니다. 각 화면마다 조금씩 다른 검색 조건들이었습니다.

• A 화면: 검색어 입력 + 날짜 범위
• B 화면: 검색어 입력 + 상태 필터
• C 화면: 검색어 입력 + 날짜 범위 + 상태 필터 + 카테고리 필터

이런 상황에서 저는 "모든 검색 조건을 포함한 하나의 통합 검색바 컴포넌트를 만들고, 각 화면에서 필요한 기능만 on/off 하면 되지 않을까?"라고 생각했습니다.

<SearchBar 
  showTextInput={true}
  showDateRange={true}
  showStatusFilter={false}
  showCategoryFilter={false}
  onSearch={handleSearch}
/>

 

 

동료 개발자는 이렇게 말했습니다.

"통합형으로 하면 유지보수가 힘들어요. 최소 단위로 나눠서 작업하는 게 좋습니다."

 

두 가지 접근 방식의 대립

1. 통합형 접근 방식

장점:

• 한 곳에서 모든 검색 관련 로직 관리
• 일관된 UI/UX 제공
• 새로운 검색 조건 추가 시 한 컴포넌트만 수정

단점:

• 컴포넌트가 점점 복잡해짐
• 사용하지 않는 기능도 항상 로드됨
• 테스트 작성이 어려워짐
• 한 부분의 수정이 전체에 영향을 줄 수 있음

2. 분리형 접근 방식

// 동료가 제안한 방식
<SearchContainer>
  <TextInput onTextChange={handleTextChange} />
  <DateRangePicker onDateChange={handleDateChange} />
  <StatusFilter onStatusChange={handleStatusChange} />
</SearchContainer>

장점:

• 각 컴포넌트가 단일 책임을 가짐
• 재사용성이 높음
• 개별 테스트가 용이함
• 필요한 기능만 조합해서 사용 가능

단점:

• 초기 설계가 복잡할 수 있음
• 컴포넌트 간 데이터 전달 고려 필요
• 컴포넌트 수가 많아짐

 

왜 나눠서 작업하는게 더 나은 선택일까?

1. 유지보수성: 각 컴포넌트의 역할이 명확하여 버그 추적과 수정이 쉬움
2. 재사용성: 다른 프로젝트나 다른 화면에서도 독립적으로 사용 가능
3. 테스트 용이성: 작은 단위의 테스트 작성으로 안정성 확보
4. 협업 효율성: 여러 개발자가 동시에 다른 컴포넌트를 작업할 수 있음

 

컴포넌트 분리의 기준

언제 분리해야 할까?

1. 단일 책임 원칙 위반: 하나의 컴포넌트가 여러 가지 일을 하고 있다면
2. 재사용 가능성: 다른 곳에서도 사용될 가능성이 있다면
3. 테스트 복잡도: 테스트 작성이 어려워진다면
4. 파일 크기: 100줄을 넘어가기 시작한다면 (절대적 기준은 아님)

언제 통합을 유지해야 할까?

1. 강한 결합: 분리했을 때 오히려 복잡해지는 경우
2. 성능 고려: 불필요한 리렌더링이 발생할 수 있는 경우
3. 간단한 로직: 분리할 만큼 복잡하지 않은 경우

 

결론

논의 중에 동료가 한 말이 인상적이었습니다.

"지금 고민하시는 내용이 제가 저연차일 때 고민하던 부분이에요."

이 말에서 깨달은 것은, 제가 현재 겪고 있는 고민이 프론트엔드 개발자라면 누구나 거쳐가는 성장 과정이라는 점이었습니다.

이번 논의를 통해 깨달은 것은 "정답은 없지만, 더 나은 선택은 있다"는 점입니다.
초보자일 때는 당장 동작하는 코드를 만드는 것에 집중하게 됩니다. 하지만 경험이 쌓이면서 유지보수, 확장성, 협업 등을 고려한 코드를 작성하게 되죠.
제가 선호했던 통합형 접근 방식도 틀린 것은 아닙니다. 프로젝트 초기나 프로토타이핑 단계에서는 빠른 개발이 더 중요할 수 있으니까요. 하지만 장기적인 관점에서는 분리형 접근 방식이 더 많은 이점을 제공한다는 것을 배웠습니다.

앞으로의 계획

1. 기존 거대한 컴포넌트들을 점진적으로 리팩토링
2. 새로운 기능 개발 시 처음부터 작은 단위로 설계
3. 팀 내에서 컴포넌트 설계 원칙 공유 및 코드 리뷰 강화

경험 있는 동료와의 논의가 제게 새로운 관점을 제공해 주었듯이, 이 글이 비슷한 고민을 하는 다른 개발자들에게도 도움이 되기를 바랍니다.
결국 좋은 코드는 혼자서는 만들어지지 않는다는 것, 그리고 끊임없는 학습과 개선의 자세가 중요하다는 것을 다시 한 번 느꼈습니다.

 

 

 

이 글은 실제 개발 경험을 바탕으로 작성되었으며, 프론트엔드 컴포넌트 설계에 대한 개인적인 견해를 담고 있습니다. 프로젝트의 성격과 팀의 상황에 따라 최적의 접근 방식은 달라질 수 있습니다.