(작성 중..)
저희 Web41팀은 이번 리팩토링 기간에 새로 구성된 신생 팀입니다. 이로 인한 우여곡절도 있고, 또 그만큼 보람이 있었던 3주를 보냈는데요, 저희가 발표를 하게 될 것이라고 생각치 못했는데,
데나무는 분산된 개발 콘텐츠를 한 곳에서 편리하게 볼 수 있는 RSS 기반 기술 블로그 큐레이션 플랫폼입니다. 초기 버전을 잘 구축해주신 Web05팀 선생님들의 작업을 이어받아, 개선 작업을 진행하게 되었습니다.
보고서에는 기재하지 않았지만, 여러 프로젝트 중 이 데나무를 선택한 이유를 간단히 언급드리고 시작하고자 합니다. 우선 그룹프로젝트 기간이 끝난 이후에도 꽤 많은 수의 실 사용자가 서비스였기에 직접 사용해보며 개선할 점을 찾아볼 수 있지 않을까 생각했습니다. 또한 정말 좋은 소재라는 생각에, 이를 바탕으로 기능을 확장할 수 있는 여지도 많다고 생각이 들었습니다.
이렇게 프로젝트를 선정한 뒤, 팀의 공통 목표로서 데이터 처리 최적화와 사용자 경험 강화를 설정했습니다. 등록된 블로그가 늘어남에 따라 포스트가 많아지는 상황에서도, 대규모 데이터를 효율적으로 처리하고, 사용자에게 안정적인 서비스를 제공하는 것이 중요하다고 판단했기 때문입니다.
이어서 프론트엔드 파트의 리팩토링 작업 내용을 공유드리겠습니다.
먼저 기존의 문제 상황을 말씀드리면, 데이터 관리와 사용자 경험 측면에서 개선이 필요했습니다. 데이터 관리에서는 단일 레벨의 쿼리 구조로 인해 데이터 상태 구분이 모호했고, 선택적 갱신이 불가능했습니다. 또한 데이터 특성을 고려하지 않은 일괄적인 캐시 정책으로 불필요한 네트워크 요청이 발생하고 있었습니다. 사용자 경험 측면에서는 페이지 새로고침이나 이동 시 작성 중이던 폼 데이터가 초기화되는 문제와, offset 기반 페이지네이션으로 인한 느린 검색 속도가 있었습니다. 이러한 문제들을 해결하기 위해 TanStack Query와 Zustand를 활용한 개선 작업을 진행했습니다. 첫째, 데이터 관리 최적화를 위해 RSS 데이터의 상태별 관리를 위한 쿼리 키 계층화를 구현했습니다. 대기 중, 승인됨, 거부됨 등의 상태별로 쿼리 키를 분리하여 선택적 갱신이 가능하도록 했습니다. 또한 데이터 특성에 따라 캐싱 전략을 차별화했는데, 전체 차트는 5분의 staleTime을, 실시간 차트는 1분의 staleTime과 30초의 refetchInterval을 적용했습니다. 둘째, 사용자 경험 개선을 위해 Zustand persist 미들웨어를 도입했습니다. RSS 등록 폼의 데이터를 localStorage에 선택적으로 저장하고, 복구 시 알림을 표시하여 사용성을 향상했습니다. 또한 검색 기능을 커서 기반 페이지네이션으로 개선하여 대규모 데이터의 안정적인 탐색이 가능하도록 구현했습니다. 이러한 개선 작업의 결과로 다음과 같은 성과를 얻을 수 있었습니다. 기술적으로는 데이터 특성에 맞는 캐시 최적화로 불필요한 API 호출이 감소했고, 계층화된 쿼리 키를 통한 선택적 데이터 무효화로 메모리 사용이 효율화되었습니다. 사용자와 개발자 경험 측면에서는 브라우저 새로고침이나 이동 후에도 입력 데이터가 유지되고, 커서 기반 페이지네이션으로 대규모 데이터 처리 성능이 향상되었습니다. 또한 계층화된 데이터 구조로 유지보수 용이성을 확보할 수 있었습니다.