Mikado Method와 레거시 개선 계획을 짜보자

엄청난 레거시를 만질 땐 항상 이런 생각이 든다

 
 
레거시 시스템은 개발자들에게 늘 고통을 안겨줍니다.  기술 부채가 쌓인 코드베이스를 마주할 때마다
“이걸 고치기 시작하면 끝이 보이지 않을 텐데…”라는 생각이 들곤 합니다.
 
하지만 레거시를 방치할수록 시스템의 유지보수성과 확장 가능성은 악화되고, 이는 결국 비즈니스의 발목을 잡습니다.
결국은 개발자들은 기술 부채 상환을 위해 대규모 리팩토링을 제안하게 됩니다.
(슬픈 소방수의 삶)
 
그러나 우리는 개발자이기 전에, 회사에서 비즈니스 목표를 달성하기 위해 일하는 회사원이기도 합니다.
이 말은, 어떤 작업을 수행하든 명확한 근거와 체계적인 계획이 요구된다는 뜻입니다.
단순히 "더 좋은 코드"를 위해 리팩토링을 제안하는 것은 윗선의 설득력을 얻기 어렵습니다.
 

Mikado Method 란?

 
미카도 메서드는 복잡한 리팩토링을 단계적으로 수행하면서, 작업의 의존성과
리팩토링 실패 시 되돌아갈 지점을 명시하는 방법론입니다.
 
미카도 메서드는 일본의 미카도 게임에서 유래되었습니다. (서양에선 픽업스틱이라 부릅니다) 
나무 막대들을 테이블 위에 흩뿌린 뒤, 막대들을 하나씩 건드리지 않고 제거하는 게임입니다.
 

미카도 스피엘 픽업스틱

 
위의 스틱을 제거하지 않고, 아래의 스틱을 제거하면 구조가 무너지게 됩니다.
복잡하게 얽혀 있는 구조를 단계적으로 풀어간다는 점에서 리팩토링을 수행하는 방법론으로 적합합니다.
 

가이드라인

 
다음은 미카도 메서드의 간단한 가이드라인입니다.
 
 

• 준비하기
  • 종이와 펜을 준비하고, 목표를 그래프의 중심 또는 상단에 적습니다.
  • (저는 종이가 아닌 mermaid로 그려서 사용합니다.)
• 목표 시도
  • 목표 달성을 위해 타임박스(5~15분) 동안 생각해 봅니다.
• 실패했다면:
  • 변경 사항을 되돌립니다.
  • 실패 원인을 분석하고 필요한 작업을 하위 목표로 기록합니다.
  • 하위 목표를 그래프에 연결합니다.
• 성공했다면:
  • 변경 사항을 커밋합니다.
  • 목표를 체크 표시합니다.
• 반복하기
  • 그래프의 가장 끝(하위 목표)부터 시작해 반복합니다.
  • 최종 목표를 달성할 때까지 진행합니다.

 
 

예시 시나리오 

 
만약 2만 줄 정도 되는 JSP페이지를 리엑트 기반의 페이지로 전환하는 예시를 들어봅시다.
이 페이지는 회사에서 결재시스템의 일부이고 A, B, C 형태의 기안지가 하나의 JSP 파일 안에 있다고 가정합니다.
 
왜 전환해야 하냐면... 이런 문제가 있다고 해봅시다.
- 세 가지 종류의 기안지가 하나의 파일 안에 있어 유지보수에 어려움이 있음
- 담당자가 주기적으로 새로운 형태의 D, E, F... 기안지를 추가해 달라고 요구함 
- 하나의 기안지를 추가할 때마다 점점 시간이 작업시간이 길어짐
 
이럴 때 어떻게 개선해야 할까요?
기안지가 계속 추가돼도 작업시간에 문제가 없도록 해야 합니다.
그렇다면 목표를 "신규 기안지 추가 시간 단축"으로 정해봅시다.
 
mermaid를 사용해서 미카도 메서드를 그려봅시다.
코드는 접은 글에 있습니다.
 

flowchart BT

 

최종목표((("신규 기안지 추가 시간 단축")))

 

단기목표((("

[단기목표]

신규 기안지 D 추가

")))

 

프론트교체(("JSP기반의 페이지를 리엑트 기반의 CSR로 변경"))

 

%% 프론트 개발

기안지_V2_프론트_개발(("

리엑트 기반의 기안지 V2 개발

"))

 

 

%% 프론트 개발 하위목표

도입_상태관리((상태관리 라이브러리 도입))

합의_컴포넌트_단위((팀간 컴포넌트 단위 합의))

합의_디렉토리_구조((디렉토리 구조 합의))

 

%% 백엔드 개발

기안지_V2_백엔드_개발(("DDD 기반의 백엔드 API V2 개발"))

 

 

%% 백엔드 개발 하위목표

도입_도메인_모델링((Aggregate Root 도출 및 도메인 모델링))

도입_ORM((JPA 및 QueryDSL 도입))

합의_팀원간_코드스타일((팀원간 코딩컨벤션 합의))

 

 

기존_기안지_병합(("기존 A,B,C 기안지를 기안지 V2로 재개발"))

 

 

기존_프론트_코드_제거(("기존 A, B, C 기안지 프론트 코드 제거"))

기존_백엔드_코드_제거(("기존 A, B, C 기안지 백엔드 코드 제거"))

 

 

기존_기안지_병합 --> 기안지_V2_백엔드_개발

기안지_V2_백엔드_개발 --> 도입_도메인_모델링

기안지_V2_백엔드_개발 --> 도입_ORM

기안지_V2_백엔드_개발 --> 합의_팀원간_코드스타일

 

 

기존_기안지_병합 --> 기안지_V2_프론트_개발

기안지_V2_프론트_개발 --> 도입_상태관리

기안지_V2_프론트_개발 --> 합의_컴포넌트_단위

기안지_V2_프론트_개발 --> 합의_디렉토리_구조

 

 

%% 단기목표

단기목표 --> 기안지_V2_프론트_개발

단기목표 --> 기안지_V2_백엔드_개발

 

 

%% 최종목표

프론트교체 -- 내년 1분기에 가능 --> 기존_기안지_병합

최종목표 --> 프론트교체

최종목표 --> 기존_프론트_코드_제거

최종목표 --> 기존_백엔드_코드_제거

 

%%%%

style 도입_상태관리 fill:#50C878

style 합의_컴포넌트_단위 fill:#50C878

style 합의_디렉토리_구조 fill:#50C878

style 기안지_V2_프론트_개발 fill:#ffde21

 

초록색이 완료, 노란색을 진행 중이라고 해보자.

 
그림을 보면 우리의 목표를 달성하기 위한 조건들
작업의 선후관계, 작업의 진행 시기 등을 한눈에 조망할 수 있습니다.

마치 픽업스틱들처럼 제일 밑에 있는 목표를 위해서
맨 위의 목표들을 하나씩 들어내는 거죠.
 
간단해 보이는 작업도 이렇게 여러 단계가 존재하지만

이걸 작업자의 머릿속에만 존재한다면 팀원들과 상황을 공유하기 어렵습니다.

팀원들은  단지 “레거시라 작업속도가 느리다” 정도로 느껴질 수 있습니다.
 

마치며

 
저는 이 미카도 메서드가 심플하면서도 활용도가 굉장히 높다고 생각합니다.
특히 레거시 개선과 같은 대규모 리팩토링에서 계획을 세우면 최종목표까지 얼마나 더 해야 하는지 
한눈에 확인하기 어려웠는데 명확하게 볼 수 있어서 좋습니다.
 
이렇게 계획을 정리하면 팀원들과 윗선..?을 설득하기 훨씬 더 쉽겠죠?
 

References

https://mikadomethod.info/