검색 서비스에서 좋은 품질의 코드를 찾는 은하수 항해 기록

11번가가 63개 컬렉션을 보유한 검색 서비스의 PC/모바일 구현 불일치와 복잡성 증가 문제를 해결하기 위해 React + TypeScript 기반 프론트엔드 아키텍처를 재정립한 과정을 다룬다. 빠른 정책 변경에 대응 가능한 유연성을 목표로 컴포넌트 설계 원칙, 조건부 렌더링 책임 분배, 커스텀 훅 분리 전략을 실전 사례로 공유한다.

핵심 포인트

63개 이종 컬렉션의 PC/모바일 불일치를 해소하기 위해 Repository-Model-Store-View 4레이어 데이터 흐름 구조 도입
컴포넌트 props 설계 기준: 4개 이상 props가 필요한 경우 객체 전달, 소규모 컴포넌트는 명시적 props로 결합도 최소화
조건부 렌더링 책임을 부모/자식 중 어디서 처리할지 기준(is 접두어 props, 복수 자식 조율 여부)을 명시적으로 정의
CollectionVisibilityManager 클래스로 상품 유형·탭별 노출 규칙을 한 곳에서 관리해 분산된 조건 로직 제거
비즈니스 로직(타이머, 동영상 재생, 필터링)을 커스텀 훅으로 분리해 컴포넌트 복잡도 감소

상세 정리

검색 서비스 63개 컬렉션은 각기 다른 UI 구조와 정책을 가져 하나의 공통 컴포넌트로 추상화하기 어려운 구조
PC는 MobX 기반 Repository-Model-Store-View, 모바일은 React Hooks 기반으로 구현 방식이 달랐던 불일치를 통일
props가 4개 이상 필요한 컴포넌트에 전체 item 객체를 전달하면 API 변경 시 수정 범위를 최소화할 수 있음
조건부 렌더링 부모 처리: 여러 자식 컴포넌트가 동일 조건을 공유하거나, 컬렉션 의존적인 복잡한 조건인 경우
조건부 렌더링 자식 처리: 컴포넌트 내부 데이터만으로 판단 가능하고, 형제 컴포넌트와 독립적인 경우
CollectionVisibilityManager는 상품 유형별·검색 탭별 노출 규칙을 중앙 집중 관리해 단일 지점 수정으로 정책 반영 가능
GridColumn, Thumbnail, HeadLine 등 레이아웃 래퍼 컴포넌트로 동적 클래스명 생성과 태그 구조 유연성 확보
검색 서비스에서 좋은 코드는 단순성과 독립성이며, 빠르게 제거하고 수정할 수 있는 능력이 아키텍처 완성도보다 중요하다는 결론
레거시 코드 리팩터링 시 원래 요구사항과 설계 의도를 먼저 이해한 뒤 접근하는 것을 강조