많은 기업들이 외주개발과 개발자 채용을 고민합니다. 초창기 서비스이고, 개발자 채용이 힘든 경우에는 외주개발이 좋은 선택일 수 있습니다. 하지만 기업 내부에 개발자가 필요한 이유 중에 하나는 '코드 품질 관리를 유지하기 위해서'입니다. 그리고 코드 품질을 언급할 때 리팩터링이라는 개념을 뺄 수 없습니다. 이번 글은 이 '리팩터링'에 대해 개념정리를 해보도록 하겠습니다.
목차
- 왜 리펙터링이야
- 리펙터링 하는 이유
- 언제 리펙터링 하면 될까?
- 리펙터링 하려면
- 마무리
왜 리펙터링이야?
앞선 포스팅에서 코드 품질에 대한 이야기를 나눴습니다. 그 일환 중에 하나가 바로 리팩터링(Refactoring)입니다. 컴퓨터 공학에서 리펙터링은 결과의 변화 없이 구조를 재조정하는 작업을 말합니다. 우리가 개발자와 업무 이야기를 나누다 보면, 개발자가 입버릇처럼 하는 말이 있습니다.
"다 뜯어고쳐야 해요. 코드가 너무 복잡해요"
아니 개발한지 얼마 됐다고, 또 고쳐야 한다는 걸까요. 눈에 보이는 동작은 잘하고 있고 문제가 없어 보입니다. 지금 할 일이 얼마나 많은데 또 일을 벌이려는 걸까요. 🤷♀️
우리는 기술부채 잡는 품격 있는 코드 글을 통해서 코드품질이 얼마나 중요하고 회사에 어떤 손실을 가져다줄 수 있는지를 간략하게 봤습니다. 새로운 기능을 만드는 만큼 기존의 기능을 유지 보수하는 일은 중요합니다. 실제로 개발 중에 10분의 8이 기존의 기능을 유지하고 보강하는 작업이라고 해도 과언이 아닙니다.
우리가 집도 지어놓고 계속 보수하고 리모델링도 하며 관리하듯이 소프트웨어도 지속적인 관리가 필요합니다. 저는 코드품질에 한해서만 리팩터링을 언급하고 있지만 사실 더 큰 차원에서 리팩터링을 지속적으로 해야 합니다. 그래야 시간이 지나도 많은 작업자들이 쉽게 일할 수 있고, 이는 서비스 품질로 이어지게 됩니다.
리펙터링을 하는 이유
좀 더 깊게 파고들어보죠. 리펙터링을 하는 이유를 마틴 파울러의 '리펙터링' 도서를 참고하여 나열해보겠습니다.
- 소프트웨어 설계가 좋아진다.
- 소프트웨어 이해하기 쉬워진다.
- 버그를 쉽게 찾을 수 있게 된다.
- 개발 속도를 높일 수 있게 된다.
- 리펙터링 책 참고 -
책에서는 리팩터링을 해야 하는 이유를 4가지로 나눠놨지만, 저 4가지는 결국 한 가지 목표를 만족시키기 위한 조건들입니다. 바로 '개발 생산성을 유지 또는 극대화'하기 위함입니다. 개발 생산성은 기업의 이윤과 직결됩니다. 개발 생산성이 낮으면 어떤 일이 일어나길래 기업 이윤과 직결된다고 하는 걸까요? 한번 나열해 보겠습니다.
- 개발 속도가 느려집니다.
- 간단한 기능 추가도 어려워집니다.
- 여기저기 버그/오류가 빵빵 터집니다.
- 서비스 성능이 점점 떨어집니다.
- 작업자들의 이직이 잦아집니다.
위와 같은 현상은 아마 개발자뿐만이 아니라 기업을 이끌어가는 모든 구성원들이 바라는 방향이 아닐 것입니다. 가장 좋은 방법은 위와 같은 현상이 눈앞에 닥치기 전에, 틈틈이 리펙터링을 진행해서 소프트웨어의 코드 품질을 일정 수준 유지해 가는 것입니다. 코드가 건강해야 서비스도 건강을 유지할 수 있는 거죠.
언제 리펙터링 하면 될까?
큰 답은 이미 나왔습니다. 리펙터링은 시간 날 때마다 하는 겁니다. 하지만 이는 너무 성의 없는 결론입니다. 좀 더 구체적으로 명시해 보죠! 여기서도
'리펙터링'에서는 어떤 기준을 세웠는지 보겠습니다.
3의 법칙
- 처음에는 그냥 한다.
- 비슷한 일을 두 번째로 하게 되면, 일단 계속 진행한다.
- 비슷한 일을 세 번째로 하게 되면 리팩터링한다.
- 리펙터링 책 참고 -
이는 '돈 로버츠'라는 개발자가 '마틴 파울러'에게 제시한 기준이라고 합니다. 저는 위와 같은 기준을 중복된 작업이 2번 이상 발견됐을 때, 리팩터링을 하라고 이해했습니다. 더 간단하게 말하면 중복이 보이면 리팩터링 해라입니다.
하지만 여기에 저는 2가지를 더 추가하고자 합니다. 앞서 기술부채 잡는 품격 있는 코드에서도 다뤘지만, 코드의 표현력이 좋지 않거나 간단한 추상화로 이득을 볼 수 있을 때입니다.
정리해 보죠
최종정리! 리팩터링이 필요할 때
- 코드의 중복이 보일때
- 코드 가독성이 떨어질 때
- 간단한 추상화로 품질향상이 가능해 보일때
위와 같은 위압감을 느끼면 리팩터링을 진행하는 겁니다. 고개는 끄덕여지지만 아직 구체적이지 않습니다. 그래서 마틴파울러는 '코드에서 나는 악취'라는 타이틀로 리팩터링이 필요한 구체적인 사례까지 소개하고 있습니다. 추후 포스팅에 구체적으로 다뤄 보겠습니다.
TMI일 수 도 있겠지만 무조건 이게 정답이다!라고 생각하진 않습니다.
코드의 중복만 놓고 봤을 때, 때론 서비스의 안정성을 고려해서 코드의 중복을 잠깐 허용할 때도 있습니다. 그리고 점진적으로 그 중복을 제거해 가는 거죠.
추상화도 마찬가지입니다. 무조건 추상화를 시도하지 않습니다. 추상화는 코드 간의 의존성을 느슨하게 하는데 큰 역할을 합니다. 단 너무 추상화하면 가독성을 떨어트리기도 합니다. 적절한 타협이 있어야겠죠.
그래서 어쩌라고? 🤷♂️
라는 생각이 드실 것 같습니다. 결국 리팩터링의 목표는 동료들과의 논의를 통해 모두가 동의할 수 있는 수준의 코드를 만드는 것이라고 생각합니다. 그러기 위해서는 리팩터링과 함께 코드리뷰가 함께 진행되어야 합니다.
리팩터링을 하려면
리팩터링은 이렇게 중요한 작업임에도 불구하고 잘 진행되지 않습니다. 조직적인 공감대를 얻기가 쉽지 않아서, 리팩터링을 위한 일정을 할당받기가 쉽지 않습니다. 개발자가 아닌 이상 서비스가 정상동작만 한다면, 괜찮다는 게 일반적인 생각입니다. 다른 직군 입장에서 생각해 보면
👩🏻🎨 디자인:
"UI/UX가 주관심사이고 코드의 품질 고친다 해도 바뀌는 게 없다"
👨🏻💼 사업가:
"당장 투자받고 하려면, 빨리빨리 새 기능 만들고, 보이는 게 있어야 하는데, 리팩터링 한다고 투자받을 수 있는 게 없다"
🧑🏻💼 기획자:
"사용자 지표가 좋지 않은데, 리팩터링을 꼭 해야 하나?"
이런 분위기 속에서 개발자가 리팩터링 진행이 힘든 이유는 바로 일정 때문입니다. 일정이 매번 타이트하게 잡히면 코드품질까지 챙겨가며 개발하기가 쉽지 않습니다. 그래서 저는 아래와 같은 상황에서 리팩터링을 진행하곤 했습니다.
리팩터링을 해야 한다면,
- 작업을 빨리해서, 시간이 좀 남았을 때
- 과거에 해봤던 작업영역을 다시 한번 더 진행하게 되었을 때
- 애초에 리펙터링을 각오하고 일정을 더 잡았을 때
- 여유가 생겨서 시간이 있을 때
가장 좋은 건 애초에 리팩터링을 일정에 포함시키거나, 여유시간이 생겨서 리팩터링에 온전히 집중할 수 있을 때입니다. 하지만 자주 오는 기회가 아니므로 변수이름, 함수이름 등등의 소소한 리팩터링조차도 틈틈이 진행하는 것이 좋은 것 같습니다.
마무리
지금까지 리팩터링에 대한 개념과 해야 하는 이유, 해야 한다면 언제 어떻게 해야 하는지 등등을 가볍게 이야기해 봤습니다. 공부한 내용과 실제 업무에서 겪어본 경험을 바탕으로 쓴 주관적인 글이라 어느 정도 공감하실지는 모르겠습니다.
하지만 SW(소프트웨어 줄임말) 개발에 있어서, 리펙터링은 중요한 개념입니다. 이 글을 통해 저희 개발자들 뿐만 아니라 기획자, 디자이너, 더 나아가서 경영자까지 제품의 품질에 인식을 하게 되는 계기가 되었으면 좋겠습니다.
'Dev.' 카테고리의 다른 글
| E2E 테스트로 왜 Playwright 선택했는가? (0) | 2023.05.27 |
|---|---|
| E2E 테스트 도구(tool)들 분류하기 (0) | 2023.05.27 |
| [실전] 프론트 기존 컴포넌트를 개선한 경험 공유 (0) | 2023.05.27 |
| TDD 는 코드 설계를 위한 도구이다. (0) | 2023.05.27 |
| 리팩터링 할려고? 그래.. 테스트코드는 있고? (0) | 2023.05.27 |
