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