10년 넘게 운용 중인 레거시 시스템이 하나 있습니다. 회사의 핵심 업무가 그 위에서 작동합니다. 그런데 기능 하나 추가하는 데만 두 달이 걸리고, 만든 개발자는 이미 퇴사했으며, 코드 한 줄 손대면 어디가 터질지 아무도 장담하지 못합니다.
"이번 기회에 아예 새로 구축하시죠."
견적을 받아보면 엄청난 비용과 함께 '2년'이라는 기간이 찍혀 나옵니다. 문제는 그 2년 동안 현업은 기존 시스템을 계속 써야 하고, 그 사이에도 새로운 요구사항은 끊임없이 쏟아진다는 점입니다. 결국 대부분의 전면 재구축 논의는 결론 없이 유야무야되고, 시스템은 다시 1년 더 낡아갑니다.
전면 재구축이 실패하는 4가지 구조적 이유
전면 재구축이 실무에서 어려운 이유는 기술 부족이 아니라 프로젝트의 구조적 한계 때문입니다.
- 완성 전까지 아무런 가치도 창출하지 못합니다: 2년짜리 프로젝트는 23개월 차까지 실제로 활용할 수 있는 산출물이 0입니다. 그 사이 조직의 우선순위가 바뀌거나 예산이 줄어들면 프로젝트 전체가 표류합니다.
- 요구사항이 문서가 아닌 '코드'에 묻혀 있습니다: 10년간 쌓인 예외 처리와 비즈니스 로직 중 상당수는 문서에 없습니다. 재구축 과정에서 이를 누락하면, 오픈 직후 현업에서 "이 기능이 왜 안 되냐"는 항의가 빗발칩니다.
- 기존 시스템은 멈추지 않습니다: 새 시스템을 만드는 동안에도 법 개정, 거래처 변경, 매출 구조 개편이 일어납니다. 동일한 변경 건을 기존 시스템과 새 시스템 양쪽에 중복 반영해야 하는 이중 부담이 프로젝트 내내 지속됩니다.
- 전환 시점에 모든 리스크가 집약됩니다: 오픈 당일 모든 것이 한꺼번에 바뀌기 때문에, 치명적인 장애가 발생하면 원복할 수 있는 방법이 사실상 없습니다.
조각 단위로 안전하게 옮기는 스트랭글러 패턴
대안은 시스템 전체를 한 번에 교체하는 대신, 기능을 하나씩 새 시스템으로 이전하는 것입니다. 오래된 거목을 덩굴식물이 감싸며 천천히 안쪽을 비워내는 구조와 유사해 스트랭글러 패턴이라 부릅니다.
- 앞단에 라우팅 창구를 둡니다: 사용자와 기존 시스템 사이에 요청을 중계하는 API 게이트웨이 계층을 배치합니다. 초기에는 모든 요청을 기존 시스템으로 100% 그대로 전달합니다.
- 기능 하나를 새 시스템에 구현합니다: 예컨대 '거래처 조회' 기능을 새 시스템에 구현합니다. 이후 라우팅 창구에서 거래처 조회 요청만 새 시스템으로 전환하고, 나머지는 기존 시스템이 처리하게 합니다.
- 문제가 생기면 즉시 원복합니다: 신규 기능에 오류가 발견되면 라우팅 설정만 되돌립니다. 사용자 입장에서는 수 분 내로 안정적인 기존 상태로 돌아갑니다.
- 이 과정을 반복합니다: 기능이 하나씩 이관되면서 기존 시스템의 비중이 줄어듭니다. 마지막에는 빈 껍데기만 남게 되며, 이때 기존 시스템을 안전하게 종료합니다.
이 방식의 핵심은 모든 단계를 되돌릴 수 있으며, 매 단계마다 실제로 작동하는 가치를 즉시 확보할 수 있다는 점입니다.
무엇부터 옮길 것인가: 우선순위 판단 기준
순서를 잘못 설계하면 첫 조각부터 병목이 생깁니다. 판단 기준은 크게 세 가지입니다.
- 변경 빈도가 높은 영역부터: 매달 수정 요청이 들어오는 기능을 먼저 이전하면 개발 속도 개선 체감이 즉각적입니다. 반대로 3년간 수정이 없던 기능을 먼저 옮기는 것은 비용 대비 효과가 떨어집니다.
- 의존성이 낮은 영역부터: 다른 모듈과의 결합도가 낮은 독립적 기능, 예를 들어 단순 조회 기능이 1순위입니다. 반면 정산, 마감처럼 여러 데이터가 복잡하게 얽힌 영역은 후순위로 미룹니다.
- 장애 발생이 잦은 영역부터: 상습적으로 오류를 일으키는 모듈을 먼저 개편하면, 이전 작업에 든 비용을 장애 대응 공수 절감으로 빠르게 회수할 수 있습니다.
Tip. 폐기가 예정된 기능이나 연간 사용 횟수가 극히 적은 기능은 굳이 옮기지 않고 레거시에 남겨두는 것이 훨씬 경제적입니다. 모든 것을 이관하는 것이 목적이 되어서는 안 됩니다.
데이터 동기화 전략: 단 하나의 원칙
과도기에는 두 시스템이 동일한 데이터를 바라봐야 하는 시점이 반드시 발생합니다. 가장 까다로운 이 단계에서 지켜야 할 철칙은 하나입니다.
"어느 쪽이 정본인지 명확히 정하고, 데이터 흐름을 단방향으로 유지한다."
양쪽 시스템에서 동시에 같은 데이터를 수정할 수 있게 두면 정합성이 깨져 어느 데이터가 맞는지 판단할 수 없는 불능 상태에 빠집니다. 이관 중인 영역의 데이터는 새 시스템을 정본으로 삼고 기존 시스템은 읽기 전용으로 설정하며, 미이관 영역은 그 반대로 경계를 명확히 분리해야 합니다.
단계별 실행 로드맵
- 1단계 — 현황 파악과 의존성 지도 작성: 어떤 기능이 어떤 데이터를 참조하고, 컴포넌트 간 의존성이 어떻게 얽혀 있는지 시각화합니다. 보통 2~4주가 소요되며, 이 단계에서 작성된 구조도는 프로젝트 전반의 이정표가 됩니다.
- 2단계 — 도메인 경계 정의: 업무 단위 및 조직 구조에 맞춰 시스템을 분할할 경계를 설정합니다.
- 3단계 — 첫 파일럿 조각 이관: 선정된 첫 번째 기능을 이전하고 롤백 가능성을 검증합니다. 첫 조각의 목적은 성과 창출보다 이관 프로세스 자체의 안정성 검증에 있습니다.
- 4단계 — 반복 이관: 파일럿에서 얻은 노하우를 바탕으로 남은 모듈들을 순차적으로 이관합니다. 예측 가능한 리스크 관리 단계로 접어듭니다.
비용과 리스크의 손익계산
점진적 현대화가 언제나 절대적 예산 면에서 더 저렴한 것은 아닙니다. 과도기 동안 두 시스템의 병행 운용 비용, 즉 서버 비용과 관리 공수가 이중으로 들고, 라우팅 계층 구축 비용도 추가되기 때문입니다.
그럼에도 점진적 전환을 선택하는 이유는 리스크 통제력에 있습니다.
- 대규모 일시 예산을 확보하지 않고 단계별로 집행할 수 있습니다.
- 중간에 프로젝트가 중단되더라도 이미 이관된 산출물은 그대로 활용됩니다.
- 실패의 영향 범위가 전체 시스템이 아닌 해당 조각으로 극소화됩니다.
전체 예산과 2년의 개발 기간을 확고히 보장받을 수 있고 그동안 현업의 요구사항을 동결할 수 있다면 전면 재구축이 빠릅니다. 그러나 이 중 하나라도 불확실하다면 점진적 현대화가 가장 현실적인 대안입니다.
기존 시스템과 새 서비스를 연결하는 구체적 아키텍처 관점은 레거시 시스템과 스타트업의 가교에서 다루고 있습니다.
인테그래빗이 레거시 현대화를 완수하는 방식
레거시 현대화 프로젝트에서 가장 위험한 순간은 시스템 간 의존성이 불명확한 상태에서 무작정 코드를 건드릴 때입니다. 예상치 못한 연쇄 장애로 이어지기 쉽습니다.
그래서 인테그래빗은 현황 분석과 아키텍처 진단을 독립된 1단계 과제로 수행합니다. 이 과정에서 도출된 의존 관계도와 이관 우선순위 보고서는 고객사의 영구적인 기술 자산으로 귀속되며, 추후 어떤 팀이 개발을 이어받더라도 명확한 이정표가 됩니다.
전면 재구축과 점진적 전환 중 귀사의 시스템에 최적화된 전략이 무엇인지 판단이 필요하시다면, 30분 무료 기술 상담을 통해 현재 아키텍처와 우선순위를 함께 정리해 드립니다.