브랜드 리브랜딩과 기술 부채 해소로 코드 구조 개선
목차
브랜드 네임이 바뀌면 코드베이스 전체에 파장이 생긴다. 눈에 보이는 건 UI의 로고나 텍스트지만, 실제로 손대야 할 곳은 훨씬 깊숙이 퍼져 있다. 컨트롤러 클래스명, 인터셉터 모듈 경로, 뷰 템플릿의 변수명, 심지어 주석까지. PANDA INTER로 리브랜딩하면서 이 작업을 진행했는데, 어차피 건드려야 하는 김에 묵혀뒀던 기술 부채도 같이 털었다.
기능 변경 없이 구조만 정리하는 날이 팀에서 가장 설명하기 어려운 날이다. 스프린트 리뷰에서 "이번에 뭐 했어요?"라고 물으면 딱히 보여줄 게 없다. 근데 안 하면 6개월 뒤 새 기능 붙일 때 두 배로 돌아온다. 이번에도 그 판단으로 시간을 냈다.
뭘 정리했나
사전에 대상 목록을 뽑았다. 코드 리뷰하거나 기능 추가하면서 // TODO: 나중에 정리 달아놨던 곳들, 그리고 리브랜딩 과정에서 네이밍이 뒤섞이게 생긴 곳들.
- 컨트롤러: 역할이 모호하게 커진 부분을 분리. 하나의 클래스가 두 가지 도메인 책임을 동시에 지고 있었음
- 인터셉터: 거의 동일한 로직이 두 군데 복사돼 있었는데, 한 쪽에서 수정하면 다른 쪽은 빠지는 구조였음. 통합
- 뷰 템플릿: 변수 네이밍 컨벤션이 일관되지 않아서 훑기 불편했음. 전부 통일
리브랜딩이 트리거가 됐지만, 사실 세 영역 모두 리브랜딩과 독립적으로도 건드렸어야 할 곳들이었다.
변경 분류별로 정리하면 이렇다.
| 변경 유형 | 건수 |
|---|---|
| 중복 제거 | 다수 |
| 이름 변경 | 다수 |
| 파일 삭제 | 일부 |
| 수정 파일 합계 | 6개 |
파일 수 자체는 많지 않다. 근데 변경이 여러 레이어에 걸쳐 있어서 연결 지점 추적이 좀 필요했다.
작업 방식: 작게 묶어서 단계별로
리팩토링에서 가장 위험한 건 범위를 너무 크게 잡는 것이다. "이왕 건드리는 김에 전부 다"라는 생각이 들 때가 있는데, 그 순간이 제일 위험하다. 변경 범위가 커질수록 검증이 어려워지고, 뭔가 깨졌을 때 원인 추적도 힘들어진다.
이번에는 논리적으로 연관된 것들끼리 묶어서 단계별로 진행했다. 커밋도 그 단위로 쪼갰다.
// 각 커밋에서 적용한 원칙
// 1. 제거: 실제로 호출되지 않는 dead code 먼저 삭제
// - 지우기 전에 참조 검색으로 확인, 테스트 돌려서 이상 없으면 제거
// 2. 이동: 공통 로직을 책임에 맞는 위치로 이전
// - 기존 위치에 deprecated wrapper 잠깐 남겨두고, 참조 다 옮긴 뒤 제거
// 3. 이름 변경: 의도가 드러나도록 rename
// - IDE 자동 리네이밍 활용, 수동 수정 최소화
// 4. 분리: 너무 커진 모듈을 적절한 크기로 쪼개기
// - 한 파일에 명확한 책임 하나만
dead code 제거를 가장 먼저 한 이유가 있다. 나중에 이동하거나 이름 바꿀 때 이미 삭제된 코드까지 신경 쓰면 머릿속이 복잡해진다. 없애야 할 건 없애고 시작하면 이후 작업이 훨씬 깔끔하다.
리팩토링 후기
변경 후 기존 기능 동작 확인했고, 가독성도 확연히 나아졌다. 수치로 말하긴 어렵지만 체감은 분명하다.
| 효과 | 체감 수준 |
|---|---|
| 코드 탐색 시간 | 줄었음 |
| 수정 범위 명확성 | 향상됨 |
| 버그 발생 가능성 | 낮아짐 |
같은 기능을 건드려야 할 때, 이전에는 관련 코드가 어디 있는지 몇 개 파일을 뒤져야 했다. 정리하고 나니까 수정 포인트가 명확해졌고, 그게 작업 시간으로 바로 이어졌다. 팀원이 처음 보는 영역을 수정할 때도 덜 헤맨다.
기술 부채를 미루면 이자가 붙는다는 표현이 딱 맞다. 그것도 복리다. 처음엔 "나중에 10분이면 정리할 수 있는데 지금은 급하니까" 싶은 것들이, 반 년 뒤엔 건드리기 무서운 레거시가 돼 있다. 그 사이 그 코드 위에 뭔가가 쌓이고, 누군가가 그 동작을 전제로 다른 걸 만들고, 그렇게 의존성이 얽힌다.
리팩토링을 자주 하면서 느끼는 건 코드는 처음부터 완벽할 수 없다는 거다. 요구사항도 변하고, 만든 사람의 이해도도 달라진다. 처음엔 맞는 구조였는데 시스템이 커지면서 맞지 않게 되는 경우도 있다. 그래서 주기적으로 다듬는 게 선택이 아니라 자연스러운 과정이다. '완성된 코드'라는 개념 자체가 없다고 생각한다. 그때그때의 최선이 있을 뿐이고, 나중에 더 나은 방향이 보이면 그때 바꾸는 거다.
리브랜딩 대응은 어차피 해야 했다. 거기에 부채 정리를 얹은 건 잘한 판단이었다고 본다. 건드리는 김에 같이 치우는 게, 따로 시간 내서 두 번 하는 것보다 낫다.
댓글 0
첫 댓글 달아줘.