팀 레거시 개선 (3) 쏘카존 관리 시스템 - 6년간 이어진 레거시 코드와 문서 개선기

쏘카 자산개발(Asset)팀은 존 관리 시스템을 포함한 내부 시스템을 운영하며, 비즈니스를 멈추지 않는 방식으로 6년간 레거시를 조금씩 고쳐 왔다. 그 과정에서 20여 개 테이블, 400여 개 컬럼 구조를 개선했고, 테스트는 0개에서 350개, 커버리지는 **0%에서 약 10%**까지 올렸다.

핵심 문제는 두 가지였다. 테이블 구조 노후화와 지식의 속인화다. 한 테이블에 서로 다른 문서 유형이 모두 들어가 있어 type에 따라 대부분의 컬럼이 NULL이었고, M:N 관계조차 type 값에 따라 완전히 다른 의미로 쓰였다. ERD만 봐서는 비즈니스 흐름을 읽을 수 없었고, 시스템 이해가 특정 담당자에게 종속됐다.

테스트를 시작하려 해도 구조가 발목을 잡았다. 컬럼이 70~100개인 entity를 매번 세팅해야 해서 테스트 하나를 만드는 데도 큰 비용이 들었다. 결국 테스트를 늘리려면 먼저 ERD와 코드 구조를 정리해야 했고, 비즈니스, 코드, ERD가 서로 일치하는 구조로 바꾸는 일이 선행됐다.

레거시 개선의 가장 큰 난관은 기술보다 허락이었다. 테이블을 나누고 바꾸는 동안 기존 구조와 새 구조가 공존하는 이원화 기간이 필요했고, 이 기간의 리스크를 조직이 감수해야 했다. 이를 위해 매번 아래 3가지를 문서로 남겼다.

• 현재 상태: 기존 테이블 구조와 의존 관계
• 목표 상태: 변경 후 구조
• 롤백 방법: 담당자가 없어도 되돌릴 수 있는 절차

컬럼 삭제도 같은 원칙으로 처리했다. 먼저 코드에서 해당 컬럼 참조를 제거하고 배포한 뒤, SELECT * 제거 여부와 이원화 데이터 정합성, 코드 참조 전수 확인을 거쳤다. 이후 MySQL 8.0의 Online DDL로 DROP COLUMN을 수행했다. 핵심은 DDL 자체가 안전한 것이 아니라, DDL을 실행해도 안전한 상태를 먼저 만들어 두는 것이었다.

TL이 된 뒤에는 장애 대응 역량을 높이기 위한 문서화에 집중했다. Postman Team Workspace를 만들어 시스템별 API와 장애 대응 순서를 정리했고, 10개 시스템 ERD를 Confluence에 올려 누구나 데이터 구조를 볼 수 있게 했다. 그 결과 장애 판단과 대응의 병목이 사람에서 문서로 옮겨 갔고, PM과 사업 담당자까지 실무에서 활용하게 됐다.

남은 결론은 단순하다. 레거시는 한 번에 고치는 것이 아니라 매일 조금씩 고치는 것이고, 그 기준은 네 가지로 정리된다.

• 구조가 먼저: 테스트를 짤 수 있는 구조를 만든다
• 조직의 신뢰: 긴 이원화와 리스크를 감수할 수 있어야 한다
• 안전한 순서: 코드 먼저, 스키마 나중
• 문서화: 지식을 사람에서 분리한다