리팩토링이 왜 필요한가?
내가 제대로 이해했는가를 알고 싶으면 자신의 생각을 글로 쉽게 풀어서 설명할 줄 알아야 하죠. 그런 맥락에서 오늘은 면접 질문 중 하나인 리팩토링에 대해 정리해볼게요.
1. 리팩토링에 대해 알고 계신지요?
서비스의 비지니스 기능(로직)이 확장될때, 기존 코드의 변경범위를 최소화하기 위해 코드를 재구성하는 단계입니다.
백엔드 기준에서 살펴보면, 클라이언트 코드에 영향성을 주지 않는 범위에서 서버쪽 코드만을 변경해서 서비스를 추가 혹은 변경함을 포함하고 있습니다.
2. 목적
앞서 말씀 드린 기능 확장 뿐만 아니라 가독성, 유지보수 측면에서 리팩토링은 필수죠. 아래와 같이 정리해봤어요.
- 의존관계와 복잡도를 고려한 효율화 작업 (성능과 직결)
- 유지보수 유리하며 코드 재사용을 높이기 위함
- 클린 코드를 지향하며 가독성을 높이기 위함
- 예상 가능한 에러 발생률을 낮추고, 예측 불가능한 에러만 쉽게 필터링해 개선하기 위함 ★
개인적으로는 4번이 핵심이 아닐까 싶습니다. 기존 작업된 결과물들 가지고 새로 들어온 인원들이 appilcation하면서 서비스를 업데이트하는데요. 이때 부서마다, 모듈간 불필요한 리소스를 줄이기 위해 예상 가능한 에러를 최대한 줄여야합니다. 통합 테스트 한번 돌리는것도 아주 큰 리소스니까요.
3. 고려하거나 필요하다고 생각되는 사항이 있다면?
실무에서 리팩토링을 할때, 어떤걸 고려해야될지를 고민해보면 아래 세가지 사항으로 요약할 수 있겠습니다.
(협업과 문서화 등 베이스 요소들은 배제하고, 핵심이라고 생각되는 요소 3가지만 서술했습니다)
첫째. 성능
- 기능 추가시(확장성 고려), 기존 서비스의 성능 저하를 초래하면 안되며 최소한 이전 배포된 시스템의 성능수준은 보장할 수 있어야합니다.
- 성능을 고려한 리팩토링으로는 중복 코드를 제거한다거나 데이터 병목 구간에서의 트래픽 처리를 효율적으로 구현해야 합니다.
둘째. 테스트 및 품질 보증
항상 테스트 검증이 가능하도록 코드가 구현되어야 합니다.
결국 서비스는 지속적인 개선을 통한 배포가 이루어져야 합니다. 업데이트가 발생할때마다 단위검증, 통합검증을 통해 품질을 보증할 수 있어야 합니다. 서비스 제공자라면 더욱 책임이 중요해지죠.
셋째. 마이그레이션 및 레거시 시스템(필수는 아닐듯)
기술 트렌드는 계속해서 변화하고 있습니다. 표준을 따라잡기 위해 기존의 레거시 시스템을 점진적으로 리팩토링하거나 마이그레이션합니다. 당장은 필요없는 것처럼 보이지만 5년뒤, 10년뒤를 생각하면 리팩토링의 중요성은 높아집니다.
[출처]