오랜 기간 쌓인 기술 부채를 분석하고 새로운 기술로 재구성하는 작업에 참여해본 경험이 있다면, 어떤 기준으로 우선순위를 정하고 어떻게 접근했는지 말씀해주세요.

기술 부채를 다룰 때 비즈니스 임팩트와 연결하지 않으면 우선순위 싸움에서 밀리는 경우가 많습니다. 캡스톤 프로젝트에서 하나의 서비스 모듈 안에 여러 기능이 얽혀 있어 특정 기능 수정이 다른 기능 오류로 이어지는 구조를 정리하는 작업을 했습니다. 우선순위를 정할 때 고객에게 직접 노출되는 경로에 있는 기능부터 분리하기로 했습니다. 내부 관리 기능보다 트랜잭션이 자주 일어나는 경로의 코드가 터지면 영향이 즉각적이기 때문입니다. 접근 방식은 기능별 경계를 먼저 그리고 데이터 흐름을 추적한 뒤, 상태를 공유하는 지점을 인터페이스로 뽑아내는 순서였습니다. 한 번에 모두 바꾸지 않고, 분리한 기능 단위를 기존 코드와 나란히 두고 호출을 조금씩 이전하는 방식으로 진행했습니다. 분리가 완료된 영역은 독립적으로 테스트할 수 있게 됐고, 수정 이후 사이드 이펙트를 추적하는 시간이 절반 이하로 줄었습니다. 기술 부채도 구조를 설명하는 언어가 없으면 팀 설득이 어렵다는 걸 이 작업에서 배웠습니다.