리팩토링도 마찬가지다. “결제 상태 관리를 한 곳으로 모은다”는 산출물이고, “결제 관련 작업이 처음 예상한 일정 안에 끝나는 비율을 3/8에서 6/8 수준으로 높인다”는 결과다. 그리고 여기까지 적고 나면 리팩토링이 비즈니스와 어떻게 연결되는지도 비로소 설명할 수 있게 된다. 결제 전환율 실험을 자주 돌리는 조직이라면, 결제 관련 작업이 예상 일정 안에 끝난다는 건 같은 기간 안에 결제 실험을 더 많이, 더 예측 가능하게 돌릴 수 있다는 뜻이 된다.
필자는 리팩토링의 비즈니스 가치가 대부분 이런식으로 드러난다고 생각한다. 리팩토링 자체가 매출을 만들지는 않지만 앞으로 일어날 변경의 속도와 안정성을 바꾼다. 그래서 리팩토링의 가치를 설명하려면 앞으로 그 코드에 어떤 변경이 얼마나 일어날 예정인지를 같이 이야기해야 한다. 이 연결을 설명하지 못하면 리팩토링은 개발자들의 취향 문제로 받아들여지기 쉽고, 반대로 이 연결을 설명할 수 있다면 리팩토링은 제품팀이 먼저 요청하는 일이 될 수도 있다.
하나의 완벽한 지표를 찾기보다는 불완전하지만 같은 방향을 가리키는 지표 두세 개를 함께 보는 편이 현실적이다. 성능 개선이라면 LCP p99, 이탈률, 상품 상세에서 장바구니로 넘어가는 비율을 같이 볼 수 있다. 셋 다 성능 외의 요인에 영향을 받지만, 셋이 동시에 같은 방향으로 움직인다면 우연일 가능성은 꽤 줄어든다.
“결제 모듈을 리팩토링하자”는 “결제 관련 작업 8건 중 3건만 예상 일정 안에 끝나고 있으니, 이걸 6건으로 늘려 결제 실험을 더 자주 돌리자”가 될 수 있다. “LCP p99를 2초 이하로 줄이자”는 “주문의 60%가 거쳐 가는 상품 상세 페이지에서 첫 화면이 3초를 넘긴 방문이 하루 2만 건이고 이 방문들의 전환율이 절반이니, 이 구간부터 줄이자”가 될 수 있다. 그리고 “조직의 생산성을 높이자”는 “기능이 배포되기까지 걸리는 3주 중 2주 넘게 차지하는 대기 시간을 줄이자”가 될 수 있다.
이건 무슨 문제를 해결하는 건가요?
그 문제가 실제로 존재한다는 건 어떻게 알 수 있나요?
왜 하필 그 방법인가요?
그 방법으로 문제가 해결됐다는 건 어떻게 알 수 있나요?
