빅뱅 리라이트를 피하며 레거시 시스템을 현대화하는 방법

가장 걱정되는 시스템은 보통 작동하고 있는 시스템입니다. 주문을 받고 장부를 마감하며, 아무도 그 시스템의 전원을 끄는 사람이 되고 싶어 하지 않습니다. 이것이 우리가 비즈니스가 계속 운영되는 동안 플랫폼과 같은 것을 한 조각씩 교체하는 방식입니다.

빅뱅 리라이트가 실패하는 이유

일반적인 계획은 깔끔하게 들립니다. 기존 시스템을 동결합니다. 18개월에서 2년 동안 대체 시스템을 구축합니다. 주말을 정해 모든 것을 옮기고, 월요일에 기존 시스템의 전원을 끕니다.

실제로는 기존 시스템이 결코 완전히 동결되지 않습니다. 비즈니스는 계속해서 변경 사항을 요구하고, 팀은 두 개의 시스템을 유지하게 되며 새 시스템은 움직이는 목표를 추격합니다. 요구사항은 수년 동안 아무도 읽지 않은 코드 속에 존재합니다. 그리고 전환 주말은 모든 것이 한 번에 완벽해야 하는 단 하나의 순간이 됩니다.

• 디지털 전환의 70%가 목표 달성에 실패합니다 (BCG, 2020).
• 글로벌 2000 기업 전반의 다운타임으로 인해 매년 $600B가 손실되며, 이는 2년 만에 50% 증가했습니다 (Splunk and Oxford Economics, 2026).
• 빅뱅 전환은 모든 것을 한 번에 맞추기 위해 단 하나의 주말만을 제공합니다.

따라서 문제는 현대화할지 여부가 아닙니다. 현상 유지는 그 자체로 비용이 발생하며, 오래된 플랫폼은 현재 팀이 본 적 없는 방식으로 최대 부하에서 실패하는 경향이 있습니다. 문제는 비즈니스를 단 하나의 주말에 걸어 베팅하지 않으면서 어떻게 할 것인가입니다. 답은 기존 시스템이 계속 작동하는 동안 슬라이스(slices) 단위로 시스템을 교체하는 것입니다.

한눈에 보는 방법: 학습하고, 정리하고, 슬라이스로 교체하기

평가는 기존 시스템을 사실들로 만듭니다. 각 구성 요소가 결정을 받습니다. 대체할 가치가 있는 것들은 이전 플랫폼이 마지막 조각까지 운영될 때까지 한 슬라이스씩 움직입니다.

Diagram: the assessment produces a platform map, a business rules catalogue, a controls and risk map, options and a wave plan. Those lead to a keep, wrap or replace decision for each component. Kept components are documented and monitored, wrapped components get an API, and replaced components move one slice at a time: built beside the old system, run in parallel, then cut over. The old piece is retired and the next slice starts.

Step 1: 시스템이 실제로 무엇을 하는지 파악하기 (Learn what the system actually does)

모든 실패하는 현대화 작업은 같은 가정에서 시작됩니다. 즉, 우리는 이 시스템이 무엇을 하는지 안다고 생각하는 것입니다. 여러분은 이 시스템이 설계된 목적을 알고 있습니다. 하지만 수년 동안 이 시스템은 아무도 기록하지 않은 가격 예외(pricing exceptions), 지역 규칙(regional rules), 월말 수정 사항(month-end fixes) 및 통합 기능들을 흡수해 왔습니다.

A tangled, amber-lit legacy server block passing through a plane of cyan light and coming out the other side as a clean, orderly map of connected blue and green nodes

6~10주간의 평가 기간. 다섯 가지 결과물.

• 플랫폼 맵(Platform map). 이 시스템을 호출하는 모든 시스템, 이 시스템이 호출하는 모든 시스템, 그리고 그 사이에 있는 모든 파일, 큐(queue), 테이블까지 포함합니다.
• 비즈니스 규칙 카탈로그(Business rules catalogue). 코드에서 추출하고 실제 프로세스를 운영하는 사람들을 통해 확인받은 목록입니다.
• 통제 및 위험 맵(Controls and risk map). 지원되지 않는 구성 요소, 단일 실패 지점(single points of failure), 그리고 오직 한 사람만이 이해하는 부분들입니다.
• 옵션 및 권장 사항(Options and a recommendation). 각 주요 구성 요소에 대해 유지할지(Keep), 래핑할지(Wrap) 또는 교체할지(Replace) 결정합니다.
• 웨이브 플랜(Wave plan). 슬라이스가 이동할 순서와 첫 번째 웨이브에 대한 고정 가격을 포함합니다.

여기가 AI가 경제성을 가장 크게 바꾼 지점입니다. 예전에는 오래된 코드를 읽는 것만으로도 프로그램의 첫해 비용을 다 써버리곤 했습니다. 이제 모델은 코드를 읽고, 의존성(dependencies)을 추적하며, 비즈니스 규칙들을 몇 주 만에 초안 작성할 수 있습니다. 이 규모는 이미 대기업 내부에서 입증되었습니다. Amazon은 AI 어시스턴트가 Java 애플리케이션 업그레이드 과정에서 4,500 개발자년(developer-years)을 절약했다고 추정합니다(AWS, 2024). Google의 대규모 코드 마이그레이션 사례에서는 AI가 코드 변경 사항의 80%를 작성했으며, 엔지니어들이 나머지 부분을 작성하거나 편집했습니다(Google, 2025).

우리가 지켜야 할 원칙입니다. AI가 읽고, 사람이 판단합니다. 모델이 추출한 모든 규칙은 비즈니스를 아는 누군가에 의해 확인되어야 합니다. 왜냐하면 아무도 확인하지 않은 규칙은 여전히 추측일 뿐이기 때문입니다.

2단계: 유지(Keep), 래핑(Wrap), 또는 교체(Replace) 결정하기

모든 오래된 것을 바꿀 필요는 없습니다. 일부 구성 요소는 안정적이고, 운영 비용이 저렴하며, 거의 변경되지 않습니다. 이를 교체하는 것은 이득 없이 예산을 소진하고 위험을 추가합니다. 이 평가를 통해 각 주요 구성 요소를 세 가지 범주 중 하나로 분류합니다.

• 유지(Keep): 안정적이며 지원됨. 변경이 거의 없고, 보안 취약점이 아니며, 운영 비용이 저렴합니다. 그대로 둡니다. 문서화하고 모니터링하세요.
• 래핑(Wrap): 건전한 로직이지만 접근 방법이 없음. 로직 자체는 작동하지만 새로운 시스템에서 이를 호출할 방법이 없습니다. API를 앞에 두어 코드를 수정하지 않고도 새로운 시스템이 사용할 수 있게 합니다.
• 교체(Replace): 비즈니스를 가로막고 있음. 변경 비용이 많이 들거나, 지원되지 않거나, 로드맵을 늦추거나 감사 결과에 나타나는 경우입니다. 이를 새로운 구성 요소로, 조각별로 재구축합니다.

래핑은 과소평가되는 경향이 있습니다. 안정적인 오래된 구성 요소 앞에 API를 두는 것은 종종 수년의 시간을 벌어주며, 대부분의 교체 작업에서 첫 번째 단계가 되기도 합니다. 모든 것이 오래된 코드 대신 API와 통신하게 되면, 아무도 상위 시스템(upstream)에 알아차리지 못하는 사이에 그 뒤에 있는 것을 바꿀 수 있습니다.

3단계: 첫 번째 조각 선택하기

조각(slice)이란 자체적으로 움직일 수 있는 시스템의 한 부분을 말합니다. 이는 비즈니스 역량, 제품 라인, 지역 또는 특정 유형의 거래가 될 수 있습니다.

A wide platform of old amber-lit server blocks being replaced block by block by a wave of new glowing blue and green modules, with the old blocks still running ahead of the wave

비용이 많이 들거나 위험할 수 있지만, 한 분기 안에 완료할 수 있습니다.

• 가장 아픈 곳부터 고치세요. 가장 많은 비용이 들거나 가장 큰 위험을 수반하는 부분을 비즈니스가 주목하게 됩니다.
• 작게 유지하세요. 한 분기 안에 배포할 수 있는 규모는, 누군가 더 크게 베팅하기 전에 그 방법을 증명해 줍니다.
• 복잡한 부분은 나중으로 미루세요. 시스템에서 가장 어려운 부분은 프로그램이 멈추는 지점입니다. 이 부분은 작동하는 패턴과 이미 한 번 경험한 팀을 동원하여 처리하세요.

단계 4: 기존 시스템 옆에 구축하기 (Build beside the old system)

새로운 컴포넌트는 실행 중인 시스템을 대체하는 것이 아니라, 그 옆에 구축됩니다. 이것이 바로 strangler fig pattern이며, Martin Fowler가 나무 주변에 자라나 결국 스스로 설 수 있게 되는 덩굴 식물에서 이름을 따왔습니다.

• 앞단 라우터(router) 배치. 요청들은 라우팅 계층을 거치게 되며, 이 계층이 각 요청이 오래된 코드(old code)로 가야 할지 새로운 컴포넌트로 가야 할지를 결정합니다. 이는 나중에 트래픽이 한 조각씩 이동하는 방식입니다.
• 사전에 정의하고 완료하기. 해당 부분(slice)의 수용 기준(Acceptance criteria)은 작업 시작 전에 문서로 서명되어, '완료'가 무엇을 의미하는지에 대해 아무도 논쟁하지 않게 합니다.
• 라인마다 게이트를 두기. 테스트, 커버리지(coverage), 보안 검사 및 라이선스 확인은 병합되기 전 모든 변경 사항에 대해 실행됩니다. 이 변경 사항이 사람에 의해 작성되었든 모델에 의해 작성되었든 상관없습니다.

단계 5: 둘 다 실행하고 모든 차이를 설명하기 (Run both and explain every difference)

이것은 대부분의 팀들이 건너뛰는 단계이며, 이 방법론을 안전하게 만드는 핵심입니다.

Two parallel tracks carrying the same stream of light particles, one through an old amber module and one through a new green glass module, compared as they pass through a single ring of cyan light

동일한 트래픽. 두 개의 시스템. 모든 결과가 비교됩니다.

동일한 트래픽을 두 개의 시스템으로 처리하며 모든 결과를 비교합니다.

• 실제 트래픽, 두 경로. 새로운 컴포넌트가 역할을 맡기 전에, 기존 시스템과 병렬로 라이브 요청을 처리합니다.
• 모든 차이점은 이름이 있습니다. 일부는 새 코드의 버그입니다. 일부는 비즈니스가 조용히 우회하여 해결했던 오래된 버그입니다. 일부는 아무도 몰랐던 규칙일 수 있습니다.
• 완전한 비즈니스 주기. 월말 마감, 주간 배치 작업, 그리고 가장 바쁜 날까지 모든 것이 무언가 전환되기 전에 최소 한 번은 발생합니다.

이것이 중요한 이유. 병렬 실행(parallel run)은 '믿음에 의존하는' 전환을 증거에 기반한 결정으로 만듭니다. 트래픽이 이동할 때쯤이면, 새로운 컴포넌트는 이미 실제 워크로드를 처리했고 모든 차이점에는 이름과 담당자가 생겼습니다.

6단계: 전환하고, 그다음 오래된 부분을 폐기하기

전환(Cutover)은 라우팅 변경일 뿐, 주말 동안의 비상 회의실 운영이 아닙니다.

Streams of light rerouted around a dimming old amber module into a new green glass module, with a faint path still leading to the old module on standby

오래된 경로는 대기 상태를 유지합니다.

• 트래픽은 점진적으로 이동합니다. 보통 한 번에 일정 비율로, 전체 과정이 감시됩니다.
• 롤백(Rollback)은 또 하나의 라우팅 변경입니다. 재구축이나 백업 복원이 아닙니다.
• 그다음 오래된 부분이 사라집니다. 합의된 클린 런(clean run)을 거친 후 비활성화되며, 팀은 그 자리를 대체한 코드, 문서 및 운영 매뉴얼(runbook)을 받게 됩니다.

이 방식으로 작업하면 두 가지 이점이 있습니다. 모든 완료된 슬라이스(slice)가 프로덕션에서 실행되고 있기 때문에 어느 시점에서든 중단하고 지금까지의 결과물을 유지할 수 있습니다. 또한 오래된 플랫폼은 마지막 슬라이스가 폐기될 때까지 계속 작동하므로, 비즈니스는 단 한 번도 '모 아니면 도'인 순간을 겪지 않습니다.

비용 책정하기

많은 대기업들은 현대화에 대해 고정된 가격을 제시하지 않습니다. 레거시 코드는 예측 불가능하며, 아무도 미지수를 가격 책정하고 싶어 하지 않습니다. 구매자는 결국 끝이 정해지지 않은 청구서와 멈출 자연스러운 지점이 없는 프로그램을 갖게 됩니다. 이 문제를 해결하는 것이 바로 평가(assessment)입니다. 의존성(dependencies)을 매핑하고 규칙들을 문서화하면, 각 슬라이스(slice)는 알려진 양이 됩니다.

1. 평가에 대한 고정 가격. 범위와 가격을 사전에 책정하고, 1단계의 다섯 가지 산출물(outputs)을 결과물로 합니다.
2. 마일스톤당 고정 가격. 각 슬라이스는 작업 시작 전에 가격이 책정되며, 설정한 수용 기준(acceptance criteria)을 충족할 때 지불됩니다. 범위가 변경되면, 그 변경 사항은 먼저 서면으로 합의되어야 합니다.
3. 첫날부터 고객님의 코드, 고객님의 클라우드. 코드는 고객님의 저장소(repository)에 존재하며 고객님의 클라우드 계정에서 실행됩니다. 문서화와 운영 매뉴얼(runbooks)이 결과물이므로, 고객님의 팀이나 다른 회사도 어느 마일스톤에서든 인계받을 수 있습니다.

현대화를 지연시키는 다섯 가지 실수

1. 평가 단계를 건너뛰는 것. 비즈니스 규칙이 문서화되기 전에 구축을 시작하면, 그것들을 프로덕션 환경에서 발견하게 됩니다.
2. 모든 것을 교체하는 것. 유지하거나 래핑(wrap)해야 할 구성 요소들이 중요한 슬라이스에 필요한 예산을 소진시킵니다.
3. 가장 어려운 슬라이스로 시작하는 것. 프로그램이 어떤 것도 증명하기 전에 중단됩니다.
4. 병렬 실행 없이 전환하는 것. 새로운 시스템의 첫 번째 실제 테스트는 비즈니스가 의존하게 되는 순간이 됩니다.
5. AI 출력을 완성된 작업으로 취급하는 것. AI는 어떤 팀보다 빠르게 코드를 읽습니다. 하지만 여전히 자신이 발견한 것을 확인해 줄 비즈니스 지식을 가진 사람이 필요합니다.