개발기초 Vue.js 실무 프로젝트에서 상태관리 때문에 고생했던 이야기 (원인과 해결 과정)

Vue.js로 사내 관리자 페이지 프론트엔드 를 개발하면서, 초반에는 몰랐는데 프로젝트 규모가 커지면서 상태관리 문제로 꽤 고생했던 경험이 있습니다. 이번 글에서는 그 과정에서 겪었던 문제와 해결 방법을 정리해보겠습니다.

상황: 처음엔 props/emit만으로 충분하다고 생각했다

프로젝트 초반에는 컴포넌트 개수가 많지 않아서 부모-자식 간 props와 emit만으로도 데이터를 잘 주고받을 수 있었습니다. "굳이 상태관리 라이브러리까지 필요할까"라고 생각했습니다.

문제 1: 컴포넌트 계층이 깊어지며 생긴 Props Drilling

기능이 추가되면서 컴포넌트 계층이 3~4단계 이상 깊어졌고, 최상위 컴포넌트에서 관리하던 데이터를 하위 컴포넌트까지 전달하기 위해 중간 컴포넌트들이 필요 없는 props를 계속 전달만 해주는 상황이 발생했습니다.

증상: 중간 컴포넌트를 수정할 때마다 관련 없는 props까지 신경 써야 했고, 코드 리뷰에서도 "이 컴포넌트가 왜 이 props를 받는지" 계속 질문이 나왔습니다.

해결: 전역적으로 공유해야 하는 데이터([예: 로그인 사용자 정보, 공통 설정값])를 Vuex(또는 Pinia)로 옮기고, 정말 해당 컴포넌트 트리 안에서만 쓰이는 데이터는 그대로 props로 남겨두는 기준을 세웠습니다.

문제 2: 여러 컴포넌트에서 같은 데이터를 다르게 수정하면서 생긴 동기화 문제

상태관리 라이브러리를 도입한 초반에는 여러 컴포넌트에서 직접 state를 변경하도록 코드를 작성했는데, 이로 인해 어느 시점에 어떤 컴포넌트가 데이터를 바꿨는지 추적이 안 되는 문제가 생겼습니다.

증상: 특정 화면에서 데이터가 예상과 다르게 표시되는 버그가 있었는데, 원인이 되는 코드를 찾는 데 상당히 오래 걸렸습니다.

해결: 컴포넌트에서 state를 직접 변경하지 않고, 반드시 정해진 mutation(또는 action) 함수를 통해서만 변경하도록 규칙을 정했습니다. 이후로는 동일한 문제가 생겨도 mutation 함수 이름으로 바로 원인 위치를 찾을 수 있게 됐습니다.

문제 3: computed 속성 과다 사용으로 인한 성능 저하

반응형 데이터를 다루다 보니 computed 속성을 편하다는 이유로 여기저기 남발해서 사용했는데, 특정 화면에서 렌더링이 느려지는 문제가 발생했습니다.

원인: 불필요하게 무거운 연산이 들어간 computed 속성이 관련 없는 다른 상태 변경에도 반복적으로 재계산되고 있었습니다.

해결: 꼭 필요한 곳에만 computed를 쓰고, 자주 바뀌지 않는 값은 별도로 캐싱하거나 watch로 필요한 시점에만 계산하도록 리팩토링했습니다.

마무리하며

이 과정을 겪으며 느낀 건, 상태관리 라이브러리는 "도입하면 끝"이 아니라 **"어떤 데이터를 전역으로 둘지, 어떻게 변경할지에 대한 규칙을 팀 안에서 명확히 정해야 한다"**는 것이었습니다. 다음에 비슷한 프로젝트를 하게 된다면, 초반부터 이런 기준을 문서화해서 팀원들과 공유할 것 같습니다.

Vue.js로 규모가 커지는 프로젝트를 진행 중이시라면, 지금이라도 전역 상태와 로컬 상태를 명확히 구분해보시는 걸 추천합니다.