||
안녕하세요. 전시개발팀 시나몬입니다. 이번 글에서는 여기어때 서비스에서 사용 중인 동적 필터의 리팩토링 과정과 그 결과로 얻은 구조적 개선점에 대해 소개해 보려고 합니다.
1. 동적필터란?
동적 필터란 사용자가 선택한 조건에 따라 이용 가능한 제휴점 수가 실시간으로 반영되어 노출되는 필터를 의미합니다. 사용자가 필터를 선택할 때마다 해당 조건을 만족하는 제휴점 수를 기준으로 필터 상태가 동적으로 변경되며 이를 통해 보다 직관적인 탐색 경험을 제공합니다.
특히 동적 필터는 다중 카테고리를 동시에 선택할 수 있어, 사용자가 여러 카테고리에 걸친 필터 정보를 한 번에 확인할 수 있는 사용자 편의 기능입니다.
예를 들어 모텔과 호텔을 동시에 선택한 경우 두 카테고리에 모두 적용 가능한 필터만 노출되도록 구성되어 있습니다.
또한 사용자가 선택한 필터 조건에 해당하는 제휴점이 존재하지 않으면 해당 필터 칩은 비활성화(disabled) 상태로 노출됩니다. 이를 통해 사용자는 선택해도 결과가 없는 필터를 미리 인지할 수 있고 불필요한 탐색 과정을 줄일 수 있습니다. 결과적으로 동적 필터는 사용자의 탐색 시간을 감소시키고 보다 효율적인 검색 경험을 제공하는 역할을 합니다.
2. AS-IS: 단순하지만 확장이 어려운 구조변경 전 구조 / 조건문을 제거하기위해 파생된 중복 클래스
기존 동적 필터 구조에서 가장 큰 문제는 페이지마다 필터의 노출/미노출 정책을 결정해야 했다는 점이었습니다.
페이지 타입에 따라 특정 필터를 숨기거나 노출해야 하는 요구사항이 생길 때마다 이를 처리하는 방식은 점점 일관성을 잃어갔습니다.
단순한 조건의 경우
→ AnchorMapper 내부에 조건문을 추가
조건이 복잡해질 경우
→ Creator 단계에서도 페이지 타입 조건을 함께 처리
정책이 크게 다른 경우
→ 기존 AnchorMapper를 복사해 페이지 전용 Mapper를 생성
이러한 방식은 단기적으로는 요구사항을 빠르게 반영할 수 있었지만
장기적으로는 구조적인 부담을 빠르게 증가시켰습니다.
특히 다음과 같은 문제가 반복적으로 발생했습니다.
페이지 타입별 정책이 Mapper와 Creator 곳곳에 분산
같은 역할의 Mapper가 페이지마다 다르게 존재
정책 변경 시 “어디를 고쳐야 하는지” 한눈에 파악하기 어려움
새로운 페이지 타입이 추가될수록
→ 조건문 증가 또는 Mapper 복사라는 선택지밖에 남지 않음
결과적으로 필터 정책은 점점 늘어나는데 이를 수용하는 구조는 확장보다는 복제에 가까운 방향으로 발전하고 있었습니다.
이 시점에서 문제는 명확해졌습니다.
필터 생성 로직 자체는 거의 동일한데,
페이지 타입에 따른 노출 정책 때문에 생성 파이프라인이 계속 갈라지고 있다.
이 문제를 해결하지 않으면 페이지 타입이 하나 추가될 때마다 비슷한 Mapper와 조건 분기가 계속 늘어날 수밖에 없다고 판단했습니다.
3. 리팩토링을 통해 가져가고자 했던 방향
리팩토링을 결정하면서 가장 중요하게 생각한 방향은 다음 세 가지였습니다.
3.1 정책과 생성 흐름을 분리한다
필터를 어떻게 조립할 것인가와 어떤 필터를 노출할 것인가는 성격이 전혀 다른 책임이라고 판단했습니다.
필터 노출 정책 → 변경 가능성이 높은 영역
필터 생성 흐름 → 안정적으로 유지되어야 하는 영역
따라서 노출 정책은 전략으로 분리하고
생성 흐름은 하나의 공통 파이프라인으로 고정하는 방향을 선택했습니다.
3.2 페이지 타입별 정책을 구조적으로 드러낸다
기존 구조에서는 페이지 타입에 대한 정책이 코드 전반에 암묵적으로 흩어져 있었기 때문에 특정 페이지의 정책을 한눈에 파악하기 어려웠습니다.
개선된 구조에서는 페이지 타입별 정책을 enum 단위로 명시적으로 드러내는 것을 목표로 했습니다.
이를 통해:
페이지 타입이 하나의 “정책 단위”로 인식되고 정책 변경 시 수정 지점이 명확해지며
새로운 페이지 타입 추가 역시 구조적으로 자연스럽게 이루어질 수 있도록 했습니다.
3.3 확장은 ‘복사’가 아니라 ‘조합’으로 해결한다
이전 구조에서는 정책 차이가 커질수록
전시 동적필터 리팩토링
생성 일시
2026/01/09 02:07
최종 편집 일시
2026/01/09 02:07
태그
여기어때
파일과 미디어