재개발에서는 새 구조를 먼저 설계하라

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

재개발은 기존 시스템이 잘 풀지 못하는 문제를 고치기 위해 한다. 그런데 마이그레이션 부담부터 붙들면 새 시스템이 새 코드로 다시 쓴 구 시스템이 되기 쉽다. 모든 설계 결정을 “기존 행을 어떻게 넣지?”에서 시작하면 손에 잡히는 유일한 모델이 레거시이기 때문에, 고치려던 문제까지 다시 설계의 기준이 된다.

더 나은 순서는 불편하다. 새 시스템이 어떤 모습이어야 하는지 먼저 세우고, 그 뒤에 기존 데이터를 옮기는 일이 어려울 수 있음을 받아들이는 것이다. 쉬운 마이그레이션은 장점이지만 재개발의 목적이 되어서는 안 된다.

먼저 어떤 변경이 필요한지 결정한다

재개발이라는 말 안에는 서로 다른 상황이 들어 있다. 변경하기 전에 회사가 비용을 들여 해결하려는 문제가 무엇인지 확인해야 한다. 기존 시스템을 잘 아는 개발자, PO, 기획자가 남아 있는가? 과거 데이터를 모두 유지해야 하는가? 문제는 애플리케이션 코드에 있는가, 데이터 구조가 필요한 변경을 막고 있는가? 새 시스템은 어느 정도의 유연성이 필요한가?

기존 스키마가 충분하다면 코드 일부만 바꾸는 것이 정직한 선택일 수 있다. 데이터 구조까지 다시 만드는 일에는 많은 시간과 인력이 든다. 그 투자를 하고도 거의 같은 시스템을 만든다면, 좁은 결과가 실제 비즈니스 문제를 해결하는 경우가 아닌 한 아쉽다. 이유나 지식이 충분하지 않은 전면 재설계보다 재개발하지 않는 편이 나을 때도 있다.

과거 데이터가 타협할 수 없는 조건인 경우도 있다. 거래 시스템을 바꾼다고 기존 이체 이력을 버릴 수는 없다. 다만 그 제약이 모든 옛 구조를 새 핵심 모델에 그대로 넣어야 한다는 뜻은 아니다.

목적지가 먼저 존재하게 한다

마이그레이션은 출발지의 데이터를 목적지로 옮기는 일이다. 초기 분석과 설계 단계에는 아직 목적지가 없다. 이때 마이그레이션을 기준으로 설계를 반복해서 바꾸면, 탈출하려는 구 시스템이 가장 강한 참고 모델이 된다.

대신 레거시 데이터가 없다면 이 도메인을 어떻게 표현할지 묻는다. 바로잡아야 할 문제, 정확성, 실제로 필요한 유연성을 기준으로 새 데이터 구조를 설계한다. 목적지가 구체적으로 보일 만큼 구현해 본다. 구 시스템을 아는 사람은 이 과정에서도 꼭 필요하다. 모든 테이블을 보존하기 위해서가 아니라, 새 시스템이 잃어서는 안 될 정책과 예외, 데이터의 의미를 설명하기 위해서다.

이렇게 초점을 나눠도 과거 데이터 보존 요구가 사라지는 것은 아니다. 어떤 이력을 계속 제공해야 하는지 정하고 구 시스템을 아는 사람과 함께 판단해야 한다. 다만 일대일 복사 방식이 새 도메인 모델의 형태를 먼저 결정하게 두지 말자는 것이다.

레거시 복잡성은 전환 계층에 드러내 둔다

목적지가 분명해지면 마이그레이션은 구체적인 작업이 된다. 어떤 옛 필드는 자연스럽게 들어가고, 어떤 것은 변환 규칙이나 매핑 테이블이 필요하다. 새 시스템은 더 이상 쓰지 않지만 보존해야 하는 값도 따로 둘 수 있다. 결과가 깔끔하지 않을 수 있다. 잘못된 구조를 바꾸면서 이력을 유지하려면 치러야 하는 정직한 비용이기도 하다.

이 호환 작업을 새 모델과 분리하고 눈에 보이게 관리하자. 데이터와 매핑이 레거시 문제임을 표시하고, 왜 남아 있는지와 언제 지울 수 있는지를 문서화한다. 구 시스템을 완전히 종료할 때, 과거 데이터 조회가 끝날 때, 혹은 낡은 계약을 쓰는 클라이언트가 사라질 때 매핑 테이블을 제거할 수 있다. 도메인에 따라 그 기간은 길어질 수 있다.

새 트래픽은 새 구조로 보내면서 옛 데이터는 조회 전용이나 매핑을 통해 유지할 수도 있다. 전환 방식은 서비스마다 다르다. 오래 가져갈 도메인 설계와 일시적인 호환 장치를 구분하는 것이 핵심이다.

앞으로 가능해진 변화로 재개발을 평가한다

마이그레이션이 어렵다고 새 설계가 좋다는 뜻은 아니다. 부주의한 목적지나 부족한 도메인 지식 때문에 어려울 수도 있다. 반대로 마이그레이션이 쉽다고 반드시 구 시스템을 복제한 것도 아니다. 둘 다 기계적인 판정 규칙이 아니라 다시 살펴볼 신호다.

처음 프로젝트를 시작한 이유로 결과를 검토해야 한다. 새 구조가 재개발을 정당화했던 제약을 제거했는가? 같은 데이터 문제를 되풀이하지 않고 새 동작을 추가할 수 있는가? 레거시 매핑이 새 모델과 분명히 분리되어 있고, 이를 제거할 구체적인 조건이 있는가? 어떤 레거시 타협이 임시적인지 팀이 설명할 수 있는가?

순서를 지켜야 두 책임을 함께 보호할 수 있다. 새 시스템은 앞으로의 일을 위해 설계해야 하고, 구 시스템의 이력은 안전하게 도착해야 한다. 마이그레이션을 두 모델 사이의 의도적인 다리로 다루되, 그 다리가 목적지를 어디에 지을지 결정하게 하지는 말자.