위험한 빅뱅 재작성 없이 레거시 시스템을 현대화하는 방법

MercTechs Team

엔지니어링 팀

게시일

2026년 8월 19일

읽기 시간

5 분 읽기

모든 CTO는 언젠가 그것을 물려받게 됩니다. 여전히 비즈니스를 굴리고 있지만, 모든 새로운 아이디어를 굼벵이 속도로 만들어 버리는 10년 묵은 시스템 말입니다. 원래 벤더는 사라졌고, 그것을 만든 개발자들도 떠난 지 오래이며, 릴리스 하나하나가 마치 기도처럼 느껴집니다. 어느 시점에 이르면 이사회의 한 임원이 자연스러운 질문을 던집니다. "그냥 새로 만들면 안 됩니까?" 그 한 문장의 질문이, 그 어떤 해킹이나 장애보다도 더 많은 IT 예산을 태워 왔습니다. Standish Group과 McKinsey의 연구는, 대규모 전면 재작성 프로젝트가 실패하거나 예산을 대폭 초과하는 비율이 3분의 2를 넘는다는 사실을 반복적으로 보여 주었습니다. 실패의 양상은 언제나 같습니다. 18개월이 지난 시점에서, 수백만 달러를 썼지만 프로덕션에는 아무것도 배포하지 못했고, 여전히 청구서를 지불하는 것은 옛 시스템입니다.

백지 재작성이라는 신화

빅뱅 재작성은 깨끗한 단절을 약속하기에 매혹적입니다. 지저분한 것은 버리고, 새 팀을 고용하고, 최신 도구를 사용하고, 1년 뒤에 아름다운 새 시스템을 들고 다시 나타난다는 것입니다. 실제로는 그 1년이 계획대로 끝나는 일은 거의 없습니다. 옛 시스템은 단순한 코드가 아니었습니다. 그것은 10년치의 비즈니스 규칙, 예외 케이스, 규제 대응 패치, 그리고 아무도 문서화하지 않은 조용한 우회 처리들이었습니다. 재작성은 소프트웨어가 무엇을 하고 있다고 비즈니스가 생각하는 바를 기술한 명세로부터 출발할 뿐, 실제로 무엇을 하고 있는지에서 출발하지 않습니다. 마이그레이션 도중 발견되는 잊혀진 규칙 하나하나가 몇 주씩을 더합니다. 그 사이 옛 시스템은 계속 진화합니다. 비즈니스는 멈출 수 없기 때문입니다. 그리고 새 시스템은 아직 단 하나의 기능도 출시하기 전에 점점 더 뒤처지게 됩니다.

더 나은 사고 모형이 있습니다. 레거시 시스템을 헐어 버리는 집이 아니라, 차들이 여전히 건너고 있는 동안 한 차선씩 교체하는 다리처럼 다루십시오. 목표는 최종 상태에 더 빨리 도달하는 것이 아닙니다. 목표는 그 여정의 매주 매주 동안 비즈니스가 계속 굴러가도록 유지하는 것입니다.

현대화는 하나의 결정이 아니라 네 가지 결정입니다

계획을 선택하기 전에, 대개 하나로 묶여서 한꺼번에 내려지곤 하는 결정들을 분리하십시오.

1. 코드를 현대화할 것인가, 아키텍처를 현대화할 것인가? 같은 모놀리스를 새로운 언어로 다시 쓰는 것은 얻는 것이 매우 적습니다. 책임을 독립적으로 배포하고 확장할 수 있는 서비스들로 분할하는 지점에 진짜 비즈니스 레버리지가 존재하지만, 이는 도메인이 잘 이해되어 있을 때에만 성립합니다. 코드 작업 이전에 아키텍처 작업을 하십시오.

2. 재호스팅할 것인가, 리팩터링할 것인가, 교체할 것인가? 모든 모듈이 같은 처방을 받아야 하는 것은 아닙니다. 어떤 모듈은 안정적이고 지루하며, 단순히 최신 인프라로 옮기기만 하면 됩니다("재호스팅"). 다른 모듈은 그 자리에서 보존하고 정리해야 할 비즈니스 로직을 담고 있습니다("리팩터링"). 몇몇은 과거와 너무 강하게 결합되어 있어 새로운 구현만이 답이 됩니다("교체"). 시스템 단위가 아니라 모듈 단위로 선택하는 것이야말로, 18개월짜리 도박을 2개월짜리 승리들의 연속으로 바꾸어 놓습니다.

3. 데이터 먼저인가, 기능 먼저인가? 대부분의 레거시 시스템에서 진짜 레거시는 그 위에 얹혀 있는 코드가 아니라 데이터베이스 스키마입니다. 현대화 계획에 명시적인 데이터 전략이 없다면(새 스키마, 마이그레이션 경로, 전환 기간 동안의 이중 쓰기 또는 이벤트 기반 동기화), 두 시스템이 진실의 원천을 두고 이견을 보이는 첫 순간에 계획은 무너집니다.

4. 전환을 누가 소유하는가? 단일한 책임 있는 프로덕트 오너 없는 현대화 프로젝트는 표류합니다. 레거시 시스템에 새 기능을 추가하는 요청에 아니라고 말할 수 있고, 로드맵을 지켜 낼 수 있으며, "옛 시스템을 살려 두라"와 "새 시스템에 투자하라" 사이의 매일의 긴장을 중재할 수 있는 사람이 필요합니다.

strangler pattern, 평이한 언어로

실제 세계의 현대화에서 가장 신뢰할 만한 패턴은 Martin Fowler가 strangler fig 접근이라고 이름 붙인 것입니다. 발상은 단순합니다. 라우팅 계층, 일반적으로 API 게이트웨이 혹은 가벼운 오케스트레이터를 레거시 시스템 앞에 둡니다. 모든 새로운 역량은 새 아키텍처 위에 구축되어 그 라우터를 통해 제공됩니다. 기존 역량은 여러분이 의도적으로 마이그레이션할 때까지, 한 번에 잘 경계 지어진 조각 하나씩 레거시 백엔드 위에서 계속 실행됩니다. 수개월 혹은 수분기에 걸쳐 새 시스템은 옛 시스템을 서서히 감싸며 자라나고, 결국에는 단 한 번의 극적인 컷오버 주말 없이 이를 대체하게 됩니다.

이 패턴이 비즈니스에 미치는 영향이야말로 중요한 지점입니다. 프로덕션에는 언제나 동작하는 시스템이 존재합니다. 마이그레이션된 조각 하나하나가 그 자체로 가치를 전달합니다. 그 가치가 더 빠른 페이지든, 더 정돈된 리포트든, 새로운 통합이든 간에, 1년이 지나도 배포되지 않을 브랜치 위에 축적되지 않습니다. 무언가가 부서지면, 한 조각만 되돌리면 될 뿐, 회사 전체를 되돌릴 필요는 없습니다. 그리고 팀은 레거시 시스템의 실제 동작을 점진적으로 학습하게 되는데, 이는 그것을 정직하게 학습할 수 있는 유일한 방식이기도 합니다.

현장에서의 한 이야기

우리가 함께 일한 한 지역 소매업체는 자신의 전체 주문 및 재고 워크플로를 15년 묵은 ERP 위에서 굴리고 있었습니다. 성수기마다 시스템은 굼벵이 속도로 느려졌고, 전자상거래 채널을 추가하려는 모든 시도는 ERP가 그 부하를 감당하지 못해 실패했습니다. 이전의 두 벤더는 전면 교체를 제안했습니다. 12개월, 7자리 숫자의 예산, 9개월차 이전까지는 눈에 보이는 진전이 없음. 두 프로젝트 모두 취소되었습니다.

대안적 접근은 매우 다르게 보였습니다. 처음 6주 동안 팀은 ERP 앞에 얇은 API 계층을 두었고, 오직 상품 카탈로그 읽기 경로만을 제대로 된 검색 인덱스로 뒷받침되는 최신 서비스로 옮겼습니다. 스토어프론트의 페이지 로드는 3초에서 0.5초 미만으로 떨어졌습니다. 그 한 조각은 ERP의 쓰기 경로에는 전혀 손을 대지 않았기에 위험은 0에 가까웠고, 3개월간의 전환율 향상으로 다음 단계의 작업 비용을 스스로 충당했습니다. 뒤이어 주문 접수가, 그다음에는 재고 예약이, 그다음에는 리포팅이 이어졌습니다. 18개월 뒤 ERP는 예전에 하던 일의 4분의 1도 하지 않게 되었으며, 단 하루의 다운타임도 없이 모듈 단위로 조용히 은퇴했습니다.

실용적인 로드맵

오늘 여러분 자신의 레거시 시스템을 마주하고 있다면, 위험은 낮게 유지하고 추진력은 높게 유지하는 순서는 다음과 같습니다.

추측하지 말고 지도화하십시오. 2주에서 4주간 시간을 들여 모듈, 통합, 데이터 흐름, 그리고 각각에 의존하는 비즈니스 프로세스에 대한 정직한 목록을 만들어 내십시오. 기술할 수 없는 것은 현대화할 수도 없습니다.
가치가 높고 위험이 낮은 한 조각을 고르십시오. 비즈니스에 매일 고통을 주지만, 왕관의 보석에 해당하는 쓰기 경로에는 손을 대지 않는 그런 조각. 읽기 모델, 리포트, 고객을 향한 화면 같은 것 말입니다. 한 분기 안에 라우팅 계층 뒤에서 프로덕션에 배포하십시오.
모든 것을 계측하십시오. 로그, 메트릭, 그리고 에러 버짓. 여러분은 이제 두 시스템을 병렬로 굴리려 하고 있으며, 각각이 무엇을 하고 있는지 눈으로 볼 수 있어야 합니다.
쓰기 경로는 읽기 쪽이 지루해진 뒤에야 옮기십시오. 새 아키텍처가 안전하게 트래픽을 처리할 수 있음을 스스로 증명하고 나면, 이중 쓰기 혹은 이벤트 재생을 통해 전환 기간 동안 두 시스템의 일관성을 유지하면서 쓰기 경로를 옮기기 시작하십시오.
의도적으로 은퇴시키십시오. 레거시 모듈은 꺼지기 전까지는 끝난 것이 아닙니다. 각 조각에 대해 명시적인 종료 일자를 정하고 그 날짜를 지키십시오.

정직한 결론

현대화는 코드 프로젝트가 아니라 비즈니스 규율입니다. 성공하는 팀은 이를 분기별 수익이 발생하는 다년간의 투자로 다루며, 단 한 번의 영웅적 릴리스로 다루지 않습니다. 그들은 백지 재작성을 약속하라는 정치적 압력에 저항하고, 첫 분기부터 작지만 눈에 보이는 승리를 배포함으로써 신뢰를 쌓습니다.

여러분의 조직이 이 여정의 시작점에 있거나, 이미 멈춰 버린 재작성 프로젝트와 함께 살고 있다면, 상황을 재설정하는 가장 빠른 방법은 그 일을 이전에 해 본 팀을 불러들이는 것입니다. MercTechs는 SME 및 엔터프라이즈 고객이 레거시 플랫폼을 점진적으로 현대화하고, 전환 기간 동안 비즈니스를 보호하며, 매 단계마다 측정 가능한 가치를 전달하도록 돕고 있습니다. 그것이 또 한 번의 12개월짜리 약속보다 여러분이 필요로 하는 바에 더 가깝게 들린다면, 기꺼이 이야기 나누고 싶습니다.