개발기초 Vue.js 컴포넌트 (구조 설계, 데이터 흐름, 상태관리)

솔직히 저는 Vue.js 컴포넌트를 처음 접했을 때 "HTML 파일을 잘게 나눠놓은 것 아닌가?" 정도로 생각했습니다. 그냥 화면 조각을 재활용하는 도구 정도로 봤던 거죠. 그런데 제조 MES(Manufacturing Execution System) 프로젝트를 실제로 운영하면서 그 생각이 완전히 뒤집혔습니다. 컴포넌트는 UI 조각이 아니라 데이터 흐름과 책임을 분리하는 구조라는 걸, 직접 겪어보고 나서야 비로소 이해했습니다.

컴포넌트 구조 설계, 왜 기준이 중요한가

Vue.js의 컴포넌트(Component)란 UI와 로직을 하나의 단위로 묶어 독립적으로 재사용할 수 있게 만든 블록입니다. 쉽게 말해, 버튼 하나, 입력 폼 하나를 독립된 파일로 관리하고 여러 화면에서 가져다 쓰는 방식입니다.

제가 직접 써봤는데, 이게 처음엔 정말 편했습니다. 예전에 jQuery 기반 프로젝트에서는 버튼 하나 수정하려면 비슷한 코드가 흩어진 10개 화면을 일일이 찾아다녀야 했습니다. Vue.js로 넘어오고 나서는 공통 컴포넌트 하나만 고치면 연결된 화면 전체에 반영됐습니다. 처음에는 이게 단순한 '재사용성' 정도의 장점이라고 여겼는데, 시간이 지나면서 그게 핵심이 아니라는 걸 깨달았습니다.

진짜 문제는 컴포넌트를 '무조건 잘게 나누는' 방식에서 생겼습니다. 초반에 저도 컴포넌트화 = 좋은 코드라는 공식을 믿었습니다. 그래서 역할 기준 없이 화면을 잘라냈는데, 운영 단계에 들어서자 props(부모 컴포넌트에서 자식 컴포넌트로 데이터를 전달하는 속성) 전달 구조만 4~5단계로 깊어지면서 데이터 흐름을 따라가는 것 자체가 고통이 됐습니다. 이른바 "props drilling" 문제입니다. 여기서 props drilling이란 데이터를 전달하기 위해 여러 단계의 컴포넌트를 거쳐 불필요하게 props를 내려보내야 하는 상황을 말합니다. 수정 포인트를 찾는 데 코딩보다 더 오랜 시간이 걸리기 시작했고, 그제야 설계 기준이 없으면 컴포넌트 분리가 오히려 독이 된다는 걸 몸으로 느꼈습니다.

PLM(Product Lifecycle Management), 즉 제품의 설계부터 생산·폐기까지 전 주기를 관리하는 시스템처럼 화면 수가 수백 개에 달하는 엔터프라이즈 환경에서는 이 차이가 더 극명하게 드러납니다. 공통 UI와 상태 흐름을 얼마나 체계적으로 잡느냐가 유지보수 난이도를 결정합니다. Vue.js가 컴포넌트 구조를 강제하는 건 맞지만, 그 구조 안에 어떤 기준을 담느냐는 온전히 개발자 몫입니다.

Vue.js 컴포넌트를 설계할 때 실무에서 도움이 됐던 기준을 정리하면 다음과 같습니다.

• 하나의 컴포넌트는 하나의 책임만 가지도록 분리한다
• 상태(state)는 해당 데이터를 실제로 사용하는 가장 가까운 상위 컴포넌트에서 관리한다
• props 전달이 3단계 이상 깊어지면 Vuex나 Pinia 같은 상태관리 라이브러리 도입을 검토한다
• 비슷해 보여도 역할이 다르면 재사용 컴포넌트로 합치지 않는다

이 기준들이 처음에는 번거롭게 느껴졌습니다. 그런데 6개월 뒤 다시 코드를 봤을 때, 이 기준을 지킨 화면과 그렇지 않은 화면의 차이는 정말 컸습니다.

데이터 흐름을 이해해야 Vue.js가 보인다

Vue.js를 처음 배우는 분들 중에 computed나 watch, 그리고 문법 위주로 접근하는 경우를 많이 봤습니다. 저도 그랬고요. 그런데 제 경험상 이건 좀 다릅니다. 문법보다 먼저 이해해야 할 건 "데이터가 어디서 생성되고 어디로 흘러가는가"입니다.

Vue.js의 반응형 시스템(Reactivity System)이란 데이터가 변경되면 연결된 화면이 자동으로 업데이트되는 구조를 말합니다. 이 구조 덕분에 개발자가 DOM(Document Object Model, 브라우저가 HTML을 해석해 만드는 문서 구조)을 직접 조작하지 않아도 됩니다. 솔직히 이건 예상 밖이었습니다. jQuery 시절엔 화면 갱신을 위해 querySelector로 일일이 요소를 찾고 innerHTML을 바꿨는데, Vue에서는 데이터만 바꾸면 화면이 따라왔습니다.

그런데 이 편리함이 오히려 함정이 되기도 했습니다. watch를 남발하면 데이터 변경이 어디서 시작됐는지 역추적이 어려워집니다. 여기서 watch란 특정 데이터를 감시하다가 변경되면 콜백 함수를 실행하는 Vue의 옵션입니다. 제가 운영 프로젝트에서 버그를 잡다가 watch 체인이 3개 이상 엮인 코드를 마주친 적이 있었는데, 어디서 뭘 건드렸는지 파악하는 데만 반나절이 걸렸습니다. 그 경험 이후로 watch는 정말 필요한 경우에만 쓰고, 가능하면 computed로 대체하는 습관을 들였습니다.

Vue.js의 생태계 자체는 탄탄합니다. Vue.js 공식 문서에 따르면 Vue 3는 Composition API를 통해 로직 재사용성과 TypeScript 지원을 크게 강화했습니다(출처: Vue.js 공식 문서). Composition API란 컴포넌트의 로직을 기능 단위로 묶어 관리할 수 있게 해주는 Vue 3의 새로운 API 방식입니다. Options API가 데이터, 메서드, computed를 속성으로 나눠 관리했다면, Composition API는 관련된 로직을 하나의 함수 안에 모을 수 있어 코드 추적이 훨씬 쉬워집니다.

또한 Stack Overflow의 2023년 개발자 설문에서 Vue.js는 프론트엔드 프레임워크 사용률 상위권을 유지하며 꾸준한 커뮤니티 성장세를 보이고 있습니다(출처: Stack Overflow Developer Survey). 이는 Vue.js가 단순히 입문용 프레임워크에 머물지 않고 실무 환경에서도 충분히 검증된 도구라는 근거가 됩니다.

개인적으로 Vue.js의 진짜 강점은 '쉽다'는 이미지가 아니라 구조를 강제하는 방식에 있다고 봅니다. 반대로 말하면, 그 구조를 대충 활용하면 Vue도 결국 복잡한 코드 덩어리가 됩니다. 특히 팀 내 규칙 없이 자유도 높게 개발하면 같은 프로젝트 안에서도 컴포넌트 설계 방식이 제각각이 되는 경우를 여러 번 목격했습니다. 프레임워크가 잘해주는 게 아니라, 개발자가 데이터 흐름과 책임 분리를 얼마나 고민했는지가 코드 품질을 결정합니다.

Vue.js를 잘 쓴다는 건 computed와 watch를 많이 쓰는 게 아닙니다. 컴포넌트 책임이 명확한지, 상태가 어디서 관리되는지, 데이터가 어떤 경로로 흐르는지를 설명할 수 있는 코드를 만드는 것이라고 생각합니다. 제조 현장에서 수백 개 화면을 관리하면서 배운 가장 큰 교훈은 그것이었습니다.

Vue.js를 배우고 있다면 문법 습득과 함께 "이 데이터는 어디서 태어나서 어디로 가는가"를 먼저 그려보는 연습을 추천합니다. 그 흐름이 명확해지는 순간, 컴포넌트 분리 기준도 자연스럽게 따라옵니다. 구조 설계를 가볍게 보지 않는 것, 그게 Vue.js를 제대로 쓰는 첫걸음이라고 봅니다.

---

참고: https://dkkim2318.tistory.com/157