겉모습은 그대로지만 속은 완전히 바뀌었다 - 블로그 리팩토링 여정
블로그를 개발한지도 어느덧 1년, 그동안 쌓인 기술적 부재를 정리하고 싶어 리팩토링에 착수했다. 눈에 보이는 변화는 거의 없지만 내부적으로는 많은 개선이 있었다.
화이트제리 블로그 리팩토링 회고
화이트제리 블로그 개발을 시작할 무렵, Next.js의 앱 라우팅과 페이지 라우팅 중 무엇을 사용할지 고민했었다. 당시 버전은 Next.js 14였고 두 방식 모두 지원되고 있었다. 나는 좀 더 고전적인 구조부터 경험해 보자는 생각으로 페이지 라우팅을 선택했다.
시간이 흐르고 Next.js는 15버전을 출시했다. 이제는 앱 라우팅으로 전환할 때라는 생각이 들기 시작했지만 이라는 것이 어디 간단한가? 작업량이 상당할 것 같아 차일피일 미루기만 하다가 결국 2025년 7월, 모든 걸 하기로 결심했다.
1. 백엔드 개선: API 문서화와 예외 처리 고도화
가장 먼저 손댄 건 자바 기반의 API 서버였다. 혼자 개발하던 프로젝트였기에 API 문서화가 필요 없다고 느꼈었지만 이번에는 생각을 달리했다.
Swagger 도입: 모든 API를 시각적으로 문서화하여 개발자 기준에서의 가독성과 유지 보수성을 높였다.
RESTful 응답 세분화: HTTP 응답 코드를 목적에 맞게 더 세분화했다.
전역 예외 처리: 에러 발생 시 일관된 API 응답 구조를 반환하도록 공통 포맷을 갖추었다.
백엔드 리팩토링 성과
소요 시간: 30시간 이상
결과: 자잘한 버그 수정은 물론, 확장 가능한 안정적인 API 구조 확보
2. 프론트엔드 개선: 페이지 라우팅에서 앱 라우팅으로
이번 리팩토링의 가장 큰 메인 디쉬는 프론트엔드 구조 개편이었다. 기존의 페이지 라우팅을 과감히 걷어내고 앱 라우팅으로 전환하는 과정에서, 서버 컴포넌트의 활용 방식이 페이지 라우팅과 완전히 달라져 적지 않은 시행착오를 겪었다.
구조적 변화와 설계 고민
역할 분리: 를 적극적으로 활용하고, 커스텀 훅을 대거 추가하여 비즈니스 로직(기능)과 뷰(화면)의 역할을 명확히 분리하려고 노력했다.
반복된 설계 수정: 컴포넌트를 어디까지 분리할 것인지 결정하는 아키텍처 설계는 예상보다 훨씬 어려웠다. 오랜 시간 들여 작성한 코드가 마음에 들지 않아 다시 뜯어고치는 과정을 수차례 반복했다.
의존성 다이어트: Next.js 최신 버전과 호환성 문제를 일으키는 일부 라이브러리는 과감히 제거했다. 가급적 최신 버전을 유지하고 싶었기에, 충돌이 나는 기능은 필요한 만큼 직접 구현하여 대체했다.
프론트엔드 리팩토링 성과
소요 시간: 최소 150시간 이상
결과: 라이브러리 의존성을 낮추고, 컴포넌트 결합도를 낮춘 클린 코드 달성
에필로그: 보이지 않지만 중요한 변화
리팩토링은 사용자보다는 개발자 자신을 위한 작업이라는 말에 깊이 공감한다.
실제 서비스 화면에서 눈에 보이는 변화는 거의 없다. 하지만내부적으로는 프로젝트 구조가 훨씬 정돈되어 확장성과 유지 보수성이 크게 향상됐다. 기존 코드가 동작하는 데 큰 문제는 없었지만, 이제는 기능이 추가될수록 복잡도가 올라가는 것이 아니라 오히려 더 정돈된 형태로 유지될 수 있는 단단한 기초 설계를 완성했다.
이번 도전을 통해 보이지 않는 변화가 얼마나 중요한지, 그리고 그 고뇌의 과정을 기록하는 일의 의미에 대해 다시 한번 생각하게 되었다.
다음번에는 사용자들도 체감할 수 있는, 조금 더 눈에 띄는 개선으로 또 한 걸음 나아가고 싶다.