더 줄게 팀 프로젝트 중간 회고

3명이라는 적은 인원으로 팀 프로젝트를 시작했다. 부족한 인력으로 1월 5일 기능 마감 기한 내에 완성하기 위해 개발 속도를 극대화할 전략이 필요했다. 프로젝트의 절반이 지난 시점에서, 기술적 선택의 결과와 협업 과정에서 겪은 문제를 점검했다.

UI 컴포넌트 라이브러리 도입의 트레이드오프

초기 목표는 UI 컴포넌트 라이브러리를 적극 활용해 뷰(View) 구현 시간을 단축하고, 비즈니스 로직에 집중하는 것이었다.

실제로 모달, 인풋 필드 등을 빠르게 구현하며 초기 개발 속도를 크게 높였다. 덕분에 내 담당 파트를 조기 완료하고, 다른 팀원의 도메인(사장님 기능)까지 추가로 지원할 수 있었다.

하지만 디자인 커스터마이징 단계에서 문제가 생겼다 피그마에 정의된 디자인 요구사항에 맞춰 MUI 데이터 테이블의 페이지네이션을 수정하려다 보니 난이도가 높고 작업량이 적지 않았다. 결과적으로 UI 라이브러리는 초기 뼈대를 잡는 데는 압도적으로 유리하지만, 세밀한 커스텀이 필요한 B2C 서비스보다는 백오피스나 대시보드에 적합하다는 사실을 체감했다.

서버 상태 관리와 기술 설득의 한계

우리 서비스는 인증 기반이며, 사장님과 일반 회원 도메인 간 데이터 갱신이 빈번하다. 이 과정에서 서버 상태를 일일이 동기화하는 것은 비효율적이라 판단해 TanStack Query 도입을 제안했다.

하지만 아직 정규 교육 과정에서 다루지 않은 기술이라는 점 등의 이유로 팀원들의 반대에 부딪혀 도입하지 못 했고 서버 상태 관리 로직을 직접 구현하느라 불필요한 시간이 소요되었다.

이번 경험을 통해 팀에 새로운 라이브러리를 도입하려면 단순한 필요성 주장이 아니라 현재 우리 프로젝트의 문제점을 어떻게 해결하고 시간을 얼마나 단축할 수 있는지에 대한 명확한 근거와 논리가 필요하다는 점을 배웠다.