회사에서 허락되는 리팩토링

1. 배경

• 대부분 회사에서 개발자의 목표는 한결같다.
  • 높은 수준의 제품을 빠르게 출시해서 사용자를 유인해 경제적인 효과 목표로한다. 
  • 짧은 리드타임, 큰 경제적 가치 창출이 전부다. 
• 리팩터링은 '빠르게 출시'에 위반하는 행위이며 허락되지 않는다.

https://www.thestartupbible.com/2024/03/business-before-technology.html

참고 : 개발자도 회사의 조직원이다

 

 

2. 허락되는 리팩터링

• 리팩토링은 (시간 + 비용 + 버그 리스크) < 리팩토링 효익이 성립되지 않으면 비즈니스적으로 후순위로 밀린다.
• 리팩토링을 해야 한다면 아래의 이유일 것이다.
  • 서비스에 크리티컬한 문제가 있을때
    • 법적 이슈
    • 보안 이슈
    • 서비스 운영 이슈 - ex. 멈춤, 크래시, 버그
    • 고객 이탈
  • 비지니스 전개에 병목이 될 때
    • 경쟁사 보다 시장 출시가 느리다.
    • 경쟁력이 없다. 비즈니스적 기회를 잃는다.
    • 개발 입장에서 병목이 발생하는 이유
      
      • 평균보다 높은 비용으로 개발이 진행되어 요구사항을 다 수용할 수 없다.
      • 변경해야할 곳 파악, 변경으로 인한 기능 변경파악이 어렵다.
      • 기술, 라이브러리의 낙후 
      • 아키텍처적으로 부족하다. 변경에 느리고 배포할때마다 사이드이펙트가 엄청나다.
• 참고) 표 - 클린코드가 필요한 이유

 

결론적으로 아래 2가지 경우에만 리팩토링이 허용된다. 

• 장기적으로 필요한 것 - 비지니스 전개에 병목 해결
  • 아키텍처, 높은 품질의 코드
  • 비즈니스 가치가 큰 서비스를 빠르게 출시할 수 있는 서비스 구조
  • 대량의 트래픽을 안정적으로 처리하면서도 시스템의 장애나 버그가 발생하지 않는 서비스 구조
  • 팀의 개발 표준 가이드를 정비하고 일상적인 배포와 모니터링
• 단기적으로 필요한 것 - 서비스에 크리티컬한 문제
  • 지금 하지 않으면 위험한 부분

 

그러나, 위 2가지 경우는 돈을 벌고 있다는 것을 가정한다. 아니면 너무 늦었다. 

고치는 동안 결국 신규 기능 출시, 마켓 실험, 경제적 창출 업무에 제약이 생긴다.  

 

3. 이상적인 리팩터링

• 개인적인 조치
  • 보이스카웃 정신
    
    • 개인이 평소에 깨끗하게 작성하려 노력한다. (https://johngrib.github.io/wiki/jargon/boy-scout-rule/)
    • 개인의 노력, 장인 정신이 다른 팀원에게 전파되길 기대한다. 
• 조직적인 조치
  • 조직내에서 계획을 수립할때 연간, 분기별 기술부채 해결을 목표로 잡는다.
  • 코드 리뷰, 코딩 컨벤션, 정적 분석, AI와 같은 규칙, 도구의 힘을 빌린다.
  • 허용하지 않는 경계선을 만들고 모두가 지키도록 강제한다. 

 

 

Reference 
- https://engineering.linecorp.com/ko/blog/about-demaecan-recode-project

일본 1위 배달 앱, 바닥부터 다시 짠다 - Recode 프로젝트