재작성으로 사라지지 않는 기술 부채 - 새 시스템보다 종료 조건을 먼저 정하기

TL;DR

• 기술 부채에는 저절로 정리되는 시점이 없다. 기능 장애를 되돌려도 그 전에 쌓인 복잡성은 남는다.
• 재설계가 끝나기 전에 성과를 인정하면 새 구조와 기존 구조를 함께 운영하는 비용이 굳어진다.
• 마이그레이션 완료는 새 서비스 출시뿐 아니라 기존 사용 사례와 책임의 종료까지 포함해야 한다.

Source

There’s No Limit to How Bad Code Can Get

Knowledge

장애를 복구해도 복잡성은 남는다

Zach Kehs는 Amazon 주문 처리 조직의 경험에서 기술 부채가 저절로 해소되지 않는 이유를 찾는다. 기능을 깨뜨린 변경은 되돌리지만 그 전에 쌓인 간접 계층과 성능 저하는 남는다. 사업이 비용을 감당하면 시스템은 계속 운영된다. 코드의 악화와 기업의 생존을 같은 사건으로 취급하면 정리할 시점을 잘못 예상하게 된다.

당시 조직에서는 담당자의 이동으로 업무 규칙에 대한 지식이 사라졌다. 문서는 낡았고 동작을 추적하려면 팀 경계를 넘어야 했다. 이해하기 어려운 코드는 수정하기 두려워졌으며 단순화 작업은 충분한 보상을 받지 못했다. 장애 대응으로 기능은 유지했지만 구조를 바꾸는 데 필요한 이해는 쉽게 축적되지 않았다.

새 구조를 만드는 성과와 이전을 끝내는 책임

재설계에는 인력과 팀이 추가됐다. 그러나 시스템을 이해하는 데 필요한 시간과 빠르게 성과를 보여야 하는 압력은 충돌했다. 불완전한 정보로 출발한 시도는 기존 구조에 잔여물을 남겼고 고통스러운 이전 작업은 끝나지 않았다. 이는 세부를 생략한 개인의 회고이며 모든 재설계가 실패한다는 통계는 아니다.

별도 시스템으로 새로운 사용 사례만 처리하는 선택도 기존 책임을 지우지는 못한다. 이전 사용 사례는 옛 시스템에서 계속 살아 있다. 이후 요청을 어느 시스템에 넣을지 결정하는 조정 비용도 추가된다. 저자가 지적하는 재작성의 한계는 코드의 신선함보다 운영 책임이 실제로 사라졌는지에 있다.

종료 조건을 설계 문서에 넣는 방법

다음은 이 논점을 적용하기 위한 가상의 주문 시스템 예다. 신규 주문을 새 서비스로 넘겼더라도 과거 주문의 취소와 환불이 옛 서비스에 남으면 전환은 끝나지 않았다. 신규 주문의 성공률만 보면 새 서비스는 성공한 것처럼 보인다. 그러나 당직자는 여전히 두 서비스의 장애를 처리하고 개발자는 두 데이터 형식의 차이를 기억해야 한다.

이 경우 종료 조건은 과거 주문의 마지막 처리 경로까지 확인하도록 작성할 수 있다. 취소·환불의 담당 서비스와 데이터 검증 책임자를 정하고 옛 경로로 들어오는 요청이 사라졌는지 관찰한다. 비용 보고에는 새 서비스 운영비와 남은 옛 서비스 운영비를 함께 넣는다. 이렇게 하면 출시 일정과 별개로 남은 이전 작업을 드러낼 수 있다. 단순화의 성과도 새 코드의 양 대신 제거된 운영 책임으로 확인할 수 있다.

더 생각해보기

• 우리 마이그레이션의 완료는 새 서비스 출시인가, 기존 서비스 종료인가?
• 시스템을 단순하게 만들고 운영 대상을 줄인 성과는 어떻게 인정받는가?