소프트웨어 악취를 제거하는 리팩토링: 구조적 설계 문제를 풀어내는 최선의 실천법을 읽어보신 분들께서는 이미 알고 계시겠지만, 기술부채의 무서움은 상상을 초월한다. 하지만 대출도 적절히 잘 활용할 경우 유익한 점이 많듯이 기술부채 역시 잘만 활용하면 개발 생산성을 높일 수 있다. 오늘은 How To Use Technical Debt In Your Favor라는 글을 읽고나서 떠오른 몇 가지 사항을 정리해보겠다.
먼저 소프트웨어 개발 과정에서 핵심은 패턴 찾기라는 사실을 이해해야 한다. 프로그래밍 과정에서 학습이 진행되며 최선의 설계 방식을 이해하기 앞서 여러 해에 걸쳐 프로젝트를 진행해야 하므로 처음부터 기술부채를 쌓지 않고 완벽한 프로그램을 만들기란 사실상 불가능하다. 요구사항은 종종 바뀌기 마련이며 예측하기도 어렵다. 최소로 시작해서 요구사항의 변경에 따라 기존 소프트웨어를 변경해 이를 충족하는 방식으로 만들어 나가야 한다. 점점 더 명확한 도메인 요구사항 패턴을 발견함에 따라 리펙터링이 가능해진다.
하지만 일반적인 조직은 처음부터 완벽한 설계 작업을 진행해야만 한다고 가정한다. 하지만 패턴을 찾을 수 있을만큼 필요한 모든 요구사항을 알기 전까지 뭐가 최적의 설계안인지 알아낼 방법은 없다. 이게 바로 점진적인 개발 과정에서 가장 큰 장애물이다. 여기서 기술부채가 등장한다. 장래 벌어질 요구사항 변경을 모두 수용할 설계안이 없을 경우 리펙터링이 가능한 수준의 패턴을 찾기 전까지 리펙터링을 뒤로 미루면서 전진할 수 있는 수단이 바로 기술부채다.
수확체감의 법칙에 따라 너무 완벽하게 설계안을 구축하려는 시도는 불필요한 시간을 낭비하기 마련이다. 너무 복잡한 설계와 추상화는 역풍을 불러일으키며, 잘못된 추상화보다는 중복이 훨씬 좋다는 사실을 기억해야 한다.
요구사항 변경에 따라 코드를 고쳐야 하면, 설계 역시 개선되어야 한다. 요구사항이 어느 정도 안정화되고 나면 기술부채를 해소하는 작업에 들어가야 한다. 이 때 변경이 일어날 부분과 일어나지 않은 부분을 나눠 변경이 일어날 부분에 대해 집중적으로 기술부채를 줄이고 나머지 부분은 부채로 남겨 둔다(변경이 일어나지 않는데 굳이 개선해야 하는 이유는 없다). 이런 전략은 훌륭해 보이지만, 팀원들의 기술과 규율이 동일한 수준에 맞춰져 있어야만 가능하다. 만일 팀원들의 기술적인 격차가 너무 커지면 이면에 숨겨진 의도를 파악해 기술부채와 관련된 올바른 결정을 따르기가 무척 어려울 것이다.
작업 단계 끝에 너무 많은 기술부채를 남겨놓아 미래에 패턴을 발견하더라도 이를 수용하기 어렵게 만드는 실수를 흔히 볼 수 있다. 기술부채가 너무 많으면 어느 누구도 바로잡기 위해 수정할 시간과 의지를 내기 어렵다. 클린 코드의 중요성을 간과해서는 안 된다.
리펙터링과 관련한 내용으로 마무리한다: 리펙터링은 이미 알고 있는 과거의 산물을 대상으로 해야지 알지 못하는 미래의 변경에 적용해서는 안 된다. 리펙터링은 오래된 코드를 새로운 요구사항에 맞춰 적응하게 만드는 과정이지 더도 덜도 아니다.
EOB
댓글 없음:
댓글 쓰기