Refactoring
리팩터링은 결과 변경 없이 코드를 수정하는 행위를 의미한다. 리팩터링을 해야 하는 이유보다 하지 않아도 되는 이유가 더 많기 때문에, 비즈니스 레이어에서 리팩터링의 필요성을 명확히 알고 있지 않다면 개발자만 답답함을 호소하는 경우도 있다.
한편 회사에서는 언제나 리소스가 충분하지 않고, 제품 요구사항을 급하게 구현하다 보면 의도한 대로 코딩하기 어려운 경우도 많아서 기술 부채는 쌓여간다.
대부분의 제품에는 적정 출시 시기라는 게 있고, 모든 걸 만족해서 출시할 수 없어 어느 수준의 기술 부채는 받아들일 수 있어야 하지만, 새로운 제품을 출시하고 운영 모드에 접어들어서조차 기술 부채가 쌓이고 있다면 그로 인해 또 다른 문제가 늘어날 수 있다.
이 글에서는 리팩터링의 테크닉 자체를 다루지는 않고, 리팩터링 태스크를 어떻게 관리하고 실행하는가에 대해서 초점을 맞추고자 한다.
문제 인지 능력
현재 코드에 문제가 있다는 걸 누군가는 인지하고 있어야 하고, 그 문제를 공유할 수 있어야 한다. 문제 공유는 개발팀 내부에서도 이루어지겠지만, 개발팀이 아닌 사업팀과 디자인팀과도 이루어져야 한다.
코드에 존재하는 문제를 추적하는 방법에는 여러가지가 있지만, 나는 팀원 모두가 사용하는 이슈 관리 도구를 사용하는 걸 추천한다. 작은 스타트업이라면 GitHub Issues나 Projects를 이용해서 관리할 수도 있고, Asana, Notion, Jira, Trello 등의 할 일 관리 도구를 사용할 수도 있다.
기술 부채와 관련한 문제는 개발팀에서 주로 이야기를 관리하겠지만, 같은 문제여도 개발팀, 사업팀, 디자인팀이 바라보는 관점이 모두 다를거라 생각한다. 그래서 문제를 관리할 때에는 여러 팀이 볼 수 있다는 걸 전제로 작성해야 한다.
예를 들어, 현재 제품에서 테스트 코드가 존재하고 동작도 하지만 커버리지는 낮은 상황이라고 생각해보자. 테스트 커버리지가 낮은 게 문제라는 건 개발자들은 어느 정도 공감하겠지만 이를 사업팀이나 디자인팀에서도 이해할 수 있을까?
이미 동작하고 있는 제품에서 가장 중요한 건 안정성이다. 테스트 커버리지가 높다는 건 최소한의 제품 안정성을 보장하는 것으로, 기존에 잘 동작하고 있던 기능을 잘 동작시키면서 새로운 기능을 추가할 수 있는 근간이 된다.
따라서 테스트 커버리지를 높이고자 한다면 태스크를 이렇게 작성할 수 있을 듯 하다. 아래 예시는 샘플이지 무조건 정답은 아니라는 점을 주의해주기를 바란다.
태스크 명 : 테스트 커버리지 향상
작성일 : 2020-07-07 08:19 AM
태그 : 리팩터링, 테스트태스크 내용 :
제품 XXX의 테스트 커버리지를 향상 시켜 제품 전체의 안정성을 높입니다.현재 제품 테스트 커버리지
- 전체 함수 149개 중 57개 테스트
- 컴포넌트 26개 중 12개 테스트문제점:
낮은 테스트 커버리지로 인해 향후 기능을 추가했을 때
기존 코드에서 발생할 수 있는 문제를 명확히 파악할 수 없습니다.이로 인해 새로운 기능을 추가하는 데 불필요한 검증 과정이 필요합니다.해결 방안:
전체 함수의 80% 이상 커버리지를 유지하고,
컴포넌트는 100% 커버리지를 가져가고자 합니다.기대:
테스트 커버리지를 높여서 불필요한 검증 과정을 줄이고,
새로운 기능을 추가할 때 태스크 처리 속도를 향상시킬 수 있으리라 생각합니다.예상 소요 기간:
태스크를 더 잘게 쪼개봐야해서 우선 5일로 잡아보겠습니다.
(Agile 그룹이라면 난이도로 쪼개도 무관)
위 태스크는 크고 추상적이지만, 현재 문제가 무엇이고 어떻게 해결해야하는 지에 대해서 잘 설명하고 있다. 실제로 작업할 때에는 더 작은 단위로 쪼개는 걸 추천하지만, 업무의 크기를 알 수 있도록 큰 태스크부터 관리하는 걸 추천한다.
실행하기
리팩터링을 위한 태스크를 어느정도 쌓아두었다면 동료들과 이야기할 시간이다. 개발팀 내부에서도 리팩터링에 대한 관점이 다양해서 개발팀 내부에서조차 합의를 얻어낼 수 없다면 외부 협의를 이끌어내기 어렵다.
무엇보다 조심해야하는 점은 개발팀의 이슈라고 개발팀 내에서 해결하고자 하면 안된다는 점이다. 리팩터링이 비록 제품에 영향을 주지 않는 걸 궁극적 목표로 하지만, 제품에 실제로 영향이 갈 지에 대한 여부를 완벽하게 파악하지 못할 수도 있다.
본격적으로 협의를 시작하기에 앞서, 개발팀이 생각하는 우선순위와 제품팀이 생각하는 우선순위가 다를 수 있다. 그래서 우선순위를 정하기에 앞서 난이도를 먼저 정하고, 난이도를 정한 후에 우선순위를 정하는 것도 좋은 접근 방법이다.
우선순위를 정할 때에는 서로의 언어로 컨텍스트를 이해시켜야 한다. 리팩터링이 제품에 어떤 영향을 주는 지, 이 영향도로 인해 개발팀이 얼마나 생산성을 높이고 제품 안정성을 높일 수 있는 지 설명할 수 있어야 한다.
한편 사업팀도 마찬가지로, 현재 구현해야하는 제품 요구사항이 왜 중요하고 지금 구현해야하는 이유를 설명할 수 있어야 한다. 그러니 결국 협의라는 건 서로의 언어를 이용해서 서로를 설득시키는 과정이다.
앞서 이야기한 태스크 관리 방식이 향후 설득을 위한 근거 자료로써 유용하게 쓰일 거라 생각한다. 무엇보다 당시 시점의 정확한 스냅샷을 어딘가에 보관하고 있어야, 실제 실행 시점이 되었을 때 스냅샷을 통해 상황을 이해할 수 있다.
그렇게 우선순위를 조율하였다면, 나머지는 실제로 구현하는 일밖에 남지 않았다. 리팩터링에 관한 다양한 기법에 대해서는 마틴 파울러의 리팩터링을 읽어보는 걸 추천한다.
마무리
모든 일을 한번에 처리하려고 하지 않았으면 한다.
제품을 만들어나가는 호흡은 짧게 가져가되, 목표는 장기 목표로 가져가는 게 중요하다. 내가 Agile 방법론을 선호하는 이유는, 제품을 만들어나가는 과정에서 많은 구성원 간의 합의를 얻는 데 초점을 맞추고 노력하기 때문이다.
여러분들이 리팩터링을 하는 데에 있어서도, 리팩터링이라는 과업을 한번에 긴 시간동안 처리하기 보다 프로젝트를 진행해나가는 중간 중간 과정에서 현재 백로그에 남아있는 리팩터링 태스크를 하나씩 처리하는 걸 권장한다.
제품 코드에 있는 문제점을 외면하다 보면 자연스럽게 문제점이 더 커져서 제품 전체를 삼키게 될 것이다. 문제점을 언제나 직시하고, 관리하고, 협의하는 문화를 만들어가자.
