2025-08-31 12:54
Tags: 소프트웨어 공학
리팩토링
“결과의 변경 없이 코드의 구조를 재조정함”
- 겉으로 보이는 기능 변화 없이 코드의 내부 구조를 개선하여 가독성을 높이고 유지보수를 용이하게 만드는 과정
- 체계적인 절차와 테스트 코드에 기반하며, ‘코드 스멜’이라는 나쁜 징후를 식별하고 해결하는 방식으로 진행
- 단기적인 비용이 들 수 있지만, 장기적으로는 버그 감소, 개발 속도 향상 등 더 큰 가치를 제공하는 필수적인 개발 습관
- 일단 작동하게 만들자는 생각과 마감, 능력 부족 등 → 기술 부채 → 이후 수정, 이해, 확장 어려움 → 리팩토링
- 리팩토링에는 초기에 시간이 더 소요될 수 있고, 때로는 경영진이나 관리자를 설득해야 하는 어려움도 있다.
- 장기적으로는 버그를 줄이고, 유지보수 비용을 절감하며, 팀 전체의 개발 속도를 향상시키는 가장 확실한 투자
언제 할까?
- 3의 법칙 (The Rule of Three): 처음에는 그냥 코드를 작성합니다. 두 번째로 비슷한 일을 하게 되면, 복사-붙여넣기를 할 수도 있습니다. 하지만 세 번째로 비슷한 일을 하게 된다면, 그때는 중복을 제거하기 위해 리팩토링을 해야 합니다.
- 기능을 추가하기 전: 새로운 기능을 추가하기 전에 기존 코드를 정리하면, 새로운 기능을 더 쉽고 명확하게 추가할 수 있습니다. 지저분한 땅에 새 건물을 짓기보다, 땅을 평평하게 고르고 짓는 것이 더 효율적인 것과 같습니다.
- 버그를 수정할 때: 버그를 수정하기 위해 코드를 깊이 들여다볼 때, 코드의 구조적인 문제점이 눈에 잘 들어옵니다. 이때가 바로 리팩토링을 통해 코드 품질을 개선할 절호의 기회입니다.
- 코드 리뷰를 할 때: 동료의 코드를 리뷰하거나, 내 코드를 리뷰 받을 때 리팩토링의 기회를 포착할 수 있습니다. “이 부분은 이렇게 개선하면 더 명확해지겠네요”와 같은 피드백은 훌륭한 리팩토링의 시작점이 됩니다.
어떻게 할까?
- 테스트 코드 확보: 리팩토링의 가장 중요한 전제 조건은 ‘안전망’입니다. 내가 코드를 변경해도 기존 기능이 깨지지 않았다는 것을 보장해 줄 자동화된 테스트 코드가 반드시 필요합니다. 테스트 코드가 없다면 리팩토링을 시작해서는 안 됩니다.
- 작은 변경: 한 번에 하나의 작은 리팩토링 기법만을 적용합니다. 예를 들어, ‘메서드 추출’ 하나만 수행합니다.
- 테스트 실행: 변경을 가한 직후, 바로 단위 테스트나 통합 테스트 등 전체 테스트를 실행하여 모든 것이 여전히 정상적으로 동작하는지 확인합니다.
- 반복: 위 2, 3번 과정을 계속 반복하며 점진적으로 코드를 개선해 나갑니다.