🚀 머플러 리팩토링 - 3. MVVM 전환 과정에서의 고민과 새로운 접근

 

🚀 머플러 리팩토링 - 2. MVC에서 MVVM으로의 전환 (feat. swiftLint)

 

머플러 리팩토링 2에서는 MVVM 아키텍처로 뷰를 전환하는 계획을 세웠지만, 실제로 작업을 진행하면서 많은 시행착오를 겪고 있다는 생각이 들었습니다. 약 4시간의 작업 끝에 뚜렷한 성과를 얻지 못하면서, 과연 지금의 방식이 최선인지 고민하게 되었습니다.

 

단순한 함수 정리의 한계

물론 뷰를 정리하는 것 자체에는 의미가 있습니다. 하지만 전체적인 관점에서 봤을 때, 단순히 함수를 분리하고 재정리하는 것만으로는 유지보수성과 확장성을 확보하기 어렵다는 걸 깨달았습니다.

3월 상반기 공채 전에 리팩토링을 마무리하고 싶지만, 퇴근 후 한정된 시간에 진행하는 개인 프로젝트라는 점에서 더 효율적인 방법이 필요했습니다.

 

문제의 원인: 부족한 설계와 협업

 

머플러 개발 당시 홈, 목표, 추가하기, 마이페이지 등의 주요 기능을 네 명의 개발자가 나눠 개발했습니다.

하지만 중복된 뷰가 많았음에도 불구하고 공통 컴포넌트를 정의하지 않고 각자 구현한 경우가 많았습니다. 이는 소통 부족과 초기 설계 부재로 인해 발생한 문제였습니다.

결과적으로 코드가 중복되고 복잡도가 증가하여 유지보수가 어려운 상황이 되었습니다.

 

새로운 접근: 뷰 중심의 플로우 차트 작성

 

문제의 본질을 빠르게 파악한 후, 우선 뷰를 중심으로 플로우 차트를 그려보았습니다.

이를 통해 중복되는 뷰를 식별하고, 공통 컴포넌트를 정의하여 재사용성을 높일 계획입니다. 이렇게 하면 유지보수성뿐만 아니라 개발 효율성도 개선될 것입니다.

리팩토링 계획

1. 플로우 차트 기반 뷰 구조 정리

- 중복되는 뷰 파악 및 공통 컴포넌트 설계

- 뷰 간 데이터 흐름을 시각화하여 구조적 문제 발견

2. 도메인 및 데이터 레이어 재설계

- 플로우 차트를 기반으로 도메인 및 데이터 레이어까지 설계 범위를 확장

- MVVM 패턴에 맞는 명확한 책임 분리 진행

3. 코드 분석 및 최적화

- 기존 코드 및 파일 구조 분석

- 불필요한 코드 제거, 필요한 기능 추가

- 전체적인 구조를 고려한 리팩토링 진행

 

마무리하며

 

이번 리팩토링은 단순히 코드를 깔끔하게 정리하는 것이 아니라, 유지보수성과 확장성을 높이는 구조적 개선이 목표입니다.

실패와 시행착오는 결국 더 나은 개발자로 성장하는 과정이라고 생각하며, 이번 경험을 통해 얻은 인사이트를 공유할 수 있어 기쁩니다.

 

다음 포스팅에서는 실제 플로우 차트와 리팩토링 진행 과정을 더 구체적으로 다뤄보겠습니다. 🚀