3.6 레거시 현대화

개요와 동기

레거시 시스템은 세상을 움직이는 시스템입니다. 사회가 의존하는 핵심 은행 원장, 세금과 급여 엔진, 항공 교통 및 국방 시스템, 보험 계약 관리, 정부 등록부는 흔히 수십 년 되었습니다. 많은 것이 COBOL(Common Business-Oriented Language)이나 다른 오래된 기술로 쓰여 있으며, 여전히 핵심 거래의 대다수를 처리합니다. “레거시”는 모욕이 아닙니다. 시스템이 살아남을 만큼 가치 있고, 실패가 파국적일 만큼 핵심적이며, 안전하게 바꾸기 어려울 만큼 오래되었다는 뜻입니다. 레거시 현대화는 이런 시스템이 제공하는 필수 서비스를 깨뜨리지 않고 개선, 이전, 교체하는 규율입니다.

이것은 불균형하게 기업과 정부의 문제이며, 가장 크고 가장 공개적인 IT 실패가 일어나는 곳입니다. 전 세계 주요 거래의 막대한 몫이 여전히 메인프레임 시스템에 닿습니다. 대형 기관의 프로덕션 코드 상당 부분은 나이 들어 가고 줄어드는 전문가 집단이 유지하는 오래된 언어로 되어 있습니다. 정부가 가장 무거운 짐을 집니다. 수십 년에 걸쳐 인코딩된 법정 의무, 정권보다 오래가는 조달 및 예산 주기, 중단될 수 없는 시민 서비스입니다. 지배적인 위험은 이런 시스템이 오래되었다는 것이 아닙니다. 많은 것이 훌륭하게 돌아가기 때문입니다. 그것을 유지할 지식이 은퇴하고 있고, 플랫폼은 점점 비용이 많이 들고 제약이 커지며, “그냥 다시 쓰자”는 유혹이 이 분야 역사상 가장 비싼 실패 몇 가지로 이어진다는 것입니다.

이 장은 실제로 통하는 점진적 현대화 패턴(교살자 무화과와 추상화에 의한 분기), 레거시 위험을 평가하고 우선순위를 매기는 방법, 메인프레임과 COBOL 자산의 관리, 데이터 이전과 이중 운영의 규율, 무엇보다 대규모 재작성의 유혹에 저항하는 방법을 다룹니다. 중심 신념은 성공적인 현대화가 거의 항상 점진적이고, 증거 기반이며, 지속적으로 가치를 전달한다는 것입니다. 여러 해에 걸친 빅뱅은 결코 아닙니다.

핵심 원칙

레거시는 단지 오래된 것이 아니라 가치 있고 기초적인 것을 뜻합니다. 건드리기 전에 시스템이 하는 일을 존중하십시오. 수십 년간 어렵게 얻은 비즈니스 규칙이 담겨 있습니다.
점진이 빅뱅을 이깁니다. 거의 항상. 안정된 인터페이스 뒤에서 조각조각 교체하고, 가치를 지속적으로 전달하고, 위험을 작게 유지하십시오.
대규모 재작성은 기본 실패 방식입니다. 전면 재작성은 일상적으로 초과하고, 미달하고, 취소됩니다. 그 충동을 깊이 의심하십시오.
이해하지 못하는 것은 현대화할 수 없습니다. 교체하기 전에 동작(문서화되지 않은 규칙 포함)을 리버스 엔지니어링하고 문서화하십시오.
데이터 이전은 프로젝트가 죽는 곳입니다. 데이터는 누구의 예상보다 오래되고, 더럽고, 얽혀 있습니다. 일급 노력으로 계획하십시오.
신뢰를 쌓으려고 옛것과 새것을 병렬로 운영하십시오. 이중 운영과 비교가 전환 전에 불일치를 잡습니다.
나이가 아니라 위험과 가치로 우선순위를 매기십시오. 단지 가장 오래된 것이 아니라 가장 위험하고 가치 있는 것을 먼저 현대화하십시오.
엔진을 바꾸는 동안 불을 켜 두십시오. 서비스는 내내 계속 돌아야 합니다. 핵심 시민 또는 금융 시스템에 허용되는 다운타임은 없습니다.

권장 사항

교살자 무화과 패턴으로 점진적으로 현대화한다

교살자 무화과(나무를 휘감아 점차 대체하는 덩굴에서 이름 붙임)는 안전한 현대화의 일꾼입니다. 레거시 시스템 앞에 라우팅 계층(API 게이트웨이, 퍼사드, 프록시)을 두십시오. 그다음 기능 하나씩, 현대적 시스템에 대체물을 만들고 그 조각의 트래픽을 그리로 돌리며 나머지는 레거시 시스템에 남겨 둡니다. 시간이 지나면서 새 시스템은 자라고 옛 시스템은 줄어, 퇴역시킬 수 있게 됩니다. 이는 가치를 지속적으로 전달하고, 각 변경을 작고 되돌릴 수 있게 유지하며, 위험한 전환을 피하고, 어느 시점에서든 멈추거나 우선순위를 다시 정하게 합니다. 빅뱅의 반대입니다. 레거시 시스템은 계속 돌아가며 그것을 둘러싸고 교체하는 동안에도 제 몫을 합니다.

내부 이음새에는 추상화에 의한 분기를 쓴다

시스템의 많은 부분이 의존하는 구성 요소를 교체해야 할 때는 추상화에 의한 분기를 쓰십시오. 기존 구현 위에 추상화 계층(인터페이스)을 도입하고, 호출자가 추상화에 의존하도록 이전하고, 같은 추상화 뒤에 새 구현을 만들고, 전환하고(흔히 기능 플래그 뒤에서 점진적으로), 마지막으로 옛 구현을 제거합니다. 이로써 큰 구성 요소를 수명이 긴 브랜치 없이 개발 주 라인에서 점진적으로 교체할 수 있고, 내내 시스템을 릴리스 가능하게 유지합니다. 교살자 무화과와 자연스럽게 짝을 이룹니다. 퍼사드는 외부 이음새를, 추상화에 의한 분기는 내부 이음새를 다룹니다.

레거시 위험을 의도적으로 평가하고 우선순위를 매긴다

현대화하기 전에 자산의 냉철한 목록과 위험 평가를 만드십시오. 각 시스템을 비즈니스 핵심성, 기술적 위험(노후화, 지원되지 않는 플랫폼, 보안 노출), 변경 빈도, 결정적으로 지식 위험(여전히 유지할 수 있는 사람이 몇이며 은퇴에 얼마나 가까운가)으로 점수 매기십시오. 시스템을 위험 대 가치 격자에 그리십시오. 위험이 높고 가치도 높은 것을 우선 현대화하십시오. 안정적이고, 변경이 적고, 잘 이해된 시스템은 오래되었더라도 내버려 두는 것을 고려하십시오. 아무도 바꿀 필요가 없는 동작하는 시스템은 비상이 아니기 때문입니다. 이 평가가 “모든 것이 낡고 무섭다”를 방어 가능한 순서가 있는 로드맵으로 바꿉니다.

메인프레임과 COBOL 자산을 단지 교체하지 말고 관리한다

모든 메인프레임이나 COBOL 시스템을 곧 교체해야 하거나 안전하게 교체할 수 있는 것은 아닙니다. 단기 우선순위는 흔히 관리(stewardship)입니다. 은퇴하기 전에 지식을 포착하는 것입니다. 코드가 인코딩한 비즈니스 규칙(대부분 문서화되지 않았고 대체 불가)을 문서화하고, 현재 동작을 못 박는 자동화된 테스트에 투자해 미래의 변경이 안전하도록 하고, 유지보수자를 채용하고 교차 훈련하며, 핵심이 제자리에 있는 동안에도 주변 전달 실천(소스 관리, 지속적 통합(CI), 자동화된 테스트)을 현대화하십시오. 현대화할 때는 첫 단계로 현대적 API를 통해 레거시 기능을 노출하는 것(캡슐화)을 선호하십시오. 자동 COBOL-현대 언어 번역은 주의해서 다루십시오. 돌아가기는 하는 코드를 만들지만, 이해할 수 없는 로직을 충실히 재현하는 경우가 많기 때문입니다. 가장 희소한 자원은 연산 능력이 아니라 이해입니다.

데이터 이전과 이중 운영을 프로젝트의 핵심으로 다룬다

대부분의 현대화 노력에서 가장 어렵고 위험한 부분은 데이터입니다. 양이 방대하고, 품질이 나쁘고 일관되지 않으며, 수십 년에 걸쳐 쌓인 문서화되지 않은 의미로 가득합니다. 프로파일링하고 정제하며, 옛 스키마와 새 스키마를 명시적으로 매핑하고, 아무것도 잃거나 바뀌지 않았음을 입증할 수 있도록 완전한 조정(개수, 체크섬, 비즈니스 합계)을 갖춘 반복 가능한 자동 이전을 만드십시오. 이중 운영(병렬 운영)으로 전환의 위험을 낮추십시오. 옛 시스템과 새 시스템을 같은 입력에 나란히 운영하고, 새 시스템이 신뢰 임계값까지 옛것과 일치할 때까지 출력을 비교합니다. 그런 다음에야 전환하고, 롤백 능력을 유지하십시오. 정말 핵심적인 시스템은 한꺼번에가 아니라 조각 단위로 이전하고 전환하십시오.

대규모 재작성의 유혹을 다룬다

지저분한 옛 시스템을 버리고 처음부터 깨끗한 새것을 만들고 싶은 본능은 강력하고, 크고 핵심적인 시스템에서는 거의 항상 틀립니다. 전면 재작성은 “못생긴” 코드에 숨은 가치(엣지 케이스, 규제 규칙, 실제 사용자가 의존하는 버그 호환 동작)를 과소평가하고, 예상보다 훨씬 오래 걸리고, 끝까지 가치를 전달하지 못하며, 막대한 지출 뒤에 자주 취소됩니다. 기본으로 점진적 현대화를 택하십시오. 재작성은 플랫폼이 진정으로 지속 불가능하고 점진적 경로가 소진된 경우에 남겨 두십시오. 그때에도 단일한 빅뱅 릴리스 대신 교살자 패턴으로 재작성을 독립적으로 전달 가능한 조각으로 분해하십시오. 리더십이 전면 재작성을 밀어붙일 때는 질문을 고집하십시오. 처음 석 달 안에 어떤 가치가 출시되며, 프로그램이 중간에 멈추면 어떻게 됩니까?

장단점

접근 방식	장점	단점
교살자 무화과 (점진적)	지속적 가치. 낮은 위험. 되돌릴 수 있음. 서비스 유지	전체 일정이 더 길다. 두 시스템을 병렬로 운영해야 함. 통합 오버헤드
빅뱅 재작성	백지. 새 코드에 레거시 제약 없음	매우 높은 실패율. 끝까지 가치 없음. 막대한 비용. 비즈니스 규칙 소실
캡슐화 (API로 감싸기)	빠르고 위험이 낮음. 핵심을 건드리지 않고 접근을 현대화	핵심은 레거시로 남음. 근본 위험을 해결하지 않고 미룸
그대로 두기 (관리)	프로젝트 위험 없음. 단기적으로 가장 쌈	지식과 플랫폼 위험이 계속 쌓임. 결국 강제 조치

근본적 트레이드오프는 변혁의 속도 대 실패의 위험이며, 레거시 현대화는 그 거래가 가장 한쪽으로 기운 영역입니다. “빠르고 깨끗한” 빅뱅 재작성은 신기루로, 모든 것 중 가장 느리고 비싼 결과를 되풀이해 만들어 냅니다. 취소된 프로그램과 여전히 현대화되지 않은 시스템입니다. 점진적 접근은 더 느리게 느껴지고 두 시스템을 병렬로 운영해야 하지만, 내내 가치를 전달하고, 위험을 작고 되돌릴 수 있게 유지하며, 경험적으로 믿을 만한 길입니다. 진짜 판단은 안정적인 레거시 시스템을 조금 더 관리할지 지금 점진적 교체를 시작할지 사이에 있습니다. 오래된 기술에 대한 불편함이 아니라 위험의 궤적, 특히 지식 위험이 그 판단을 이끌게 하십시오.

팀과 논의할 질문

레거시 시스템 앞에 라우팅 계층을 둘 자리가 있으며, 없다면 만드는 데 무엇이 필요합니까? 교살자 무화과는 이음새에 달려 있습니다. 한 번에 한 기능씩 새 구현으로 돌릴 수 있는 API 게이트웨이, 퍼사드, 프록시입니다. 많은 옛 시스템에는 그런 이음새가 없어서 첫 현대화 증분이 흔히 가로채는 지점을 만드는 것 자체이며, 그 일은 과소평가하기 쉽습니다. 현재 통합 지도를 가져와 빅뱅 전환 없이 기능별로 트래픽을 어디서 가로챌 수 있는지 물으십시오. 어디에도 없다면 내부 이음새에 대한 추상화에 의한 분기가 대신 시작점일 수 있습니다. 라우팅 계층이 없으면 점진적 경로가 없고, 바로 그것이 조직을 대개 실패하는 재작성 쪽으로 되밀게 되는 방식입니다.
자산을 위험 대 가치 격자에 실제로 그려 보았습니까, 아니면 로드맵이 어느 시스템이 가장 오래돼 보이는지로 이끌립니까? 이 장은 위험이 높고 가치도 높은 것을 먼저 현대화하고, 안정적이고 변경이 적고 잘 이해된 시스템은 아주 오래되었더라도 의도적으로 내버려 두라고 주장합니다. 명시적 격자가 없으면 주의는 가장 큰 불평이나 가장 덜 유행하는 기술로 흐르고, 진짜 시한폭탄(은퇴가 가까운 유지보수자가 둘뿐인 핵심 시스템)은 기다립니다. 각 시스템을 비즈니스 핵심성, 기술적 위험, 변경 빈도, 지식 위험으로 점수 매기고 오른쪽 위 모서리부터 순서를 정하십시오. 그 격자를 공유된 지도로 회의에 가져오십시오. 지식 위험이 가장 무거운 비중을 받을 만합니다. 나빠지기만 하고 사람들이 떠나면 되살 수 없는 유일한 입력이기 때문입니다.
전환할 때 단 하나의 레코드도 잃거나 바뀌지 않았음을 어떻게 입증하며, 누가 그 증거를 승인합니까? 데이터 이전은 이런 프로젝트가 죽는 곳이며, 신뢰는 조정에서 옵니다. 옛것과 새것 사이에 일치하는 행 수, 체크섬, 비즈니스 통제 합계와, 같은 입력에 대한 출력을 높은 임계값까지 일치할 때까지 비교하는 이중 운영입니다. 급여나 원장 시스템에서 불일치는 적게 지급된 시민이나 잃은 한 푼이므로, 증거는 엔지니어뿐 아니라 감사자를 만족시켜야 합니다. 어떤 합계를 조정할지, 어떤 신뢰 임계값이 전환을 촉발할지, 옛것과 새것을 얼마나 오래 병렬로 운영할지 지금 결정하십시오. 내내 롤백을 가능하게 유지하고, 한꺼번에가 아니라 조각 단위로 전환하십시오. 이중 운영 중에 찾는 불일치는 대개 보존해야 하는 문서화되지 않은 레거시 규칙이므로, 각각을 단지 결함이 아니라 발견으로 다루십시오.
레거시 시스템 중 어느 것을 관리하고 어느 것을 적극 교체하며, 어느 쪽인지는 누가 결정했습니까? 이 장은 제자리에서 안정화할 가치가 있는 시스템(규칙 문서화, 특성화 테스트 추가, 유지보수자 교차 훈련)과 점진적으로 교체할 가치가 있는 시스템 사이에 의도적인 선을 긋고, 둘은 매우 다른 재원과 인력을 요구합니다. 대규모 조직에서 위험은 표류입니다. “당분간 관리”로 분류된 시스템이 마지막 유지보수자가 은퇴하고 위기 속에서 선택이 대신 내려질 때까지 조용히 “영원히 관리”가 됩니다. 상충하는 고려는 한쪽의 관리 비용과 플랫폼 노후화, 다른 쪽의 교체의 위험과 혼란이며, 지식 위험은 나빠지기만 하므로 저울을 기울여야 합니다. 위험 대 가치 격자, 각 시스템의 유지보수자 인원과 은퇴 전망, 관리 또는 교체 결정의 명시적 소유자를 가져오십시오. 기업과 정부 자산에서는 각 시스템에 검토 주기와 책임 담당자를 지명하십시오. 아무도 다시 보지 않는 분류는 아무도 내리지 않는 결정이기 때문입니다.
리더십이 전면 재작성을 요청할 때 상시 답은 무엇이며, 점진적 경로가 처음 석 달에 무엇을 출시하는지 보일 수 있습니까? 빅뱅 재작성은 기본 실패 방식이지만 계속 재원을 받습니다. 백지는 팔기 쉽고 교살자 무화과는 그렇지 않기 때문입니다. 큰 팀에는 리허설된 대응이 필요해서, 논쟁이 방에서 가장 직급이 높은 사람이 아니라 증거로 이기게 해야 합니다. 진짜 긴장은 일부 플랫폼이 실제로 지속 불가능하고 재작성이 정당할 수 있다는 점이므로, 답은 전면 거부일 수 없습니다. 점진적 이음새가 여전히 존재하는지를 옛 플랫폼을 살려 두는 진짜 비용과 저울질해야 합니다. 점진적 첫 증분이 줄 가치, 비슷한 재작성의 과거 실패율, 제안된 재작성을 독립적으로 출시 가능한 조각으로 분해한 것을 가져오십시오. 취소된 수년짜리 프로그램이 공공 자금을 모두가 보는 앞에서 태우는 정부에서는, 어떤 재작성이든 일찍 가치를 전달하고 중간에 멈춰도 전체 손실 없이 살아남도록 요구하십시오.
가장 오래된 코드에 갇힌 비즈니스 규칙을 그것을 이해하는 사람들이 떠나기 전에 어떻게 포착하겠습니까? 레거시 시스템 가치의 상당 부분은 수십 년의 엣지 케이스, 규제, 버그 호환 수정이 쌓인 문서화되지 않은 동작이며, 어떤 서면 기록이 아니라 줄어드는 은퇴 전문가 집단에게 있습니다. 대규모 조직에서 이것은 사람들이 떠나면 되살 수 없는 유일한 위험이므로, 더 눈에 띄는 플랫폼 작업보다 먼저 재원을 받을 만합니다. 상충하는 끌림은 지식 포착(문서화, 특성화 테스트, 리버스 엔지니어링, 교차 훈련)이 아무것도 출시하지 않는 오버헤드처럼 느껴져 바로 그래서 미뤄진다는 것입니다. 누가 핵심 지식을 지녔는지, 떠날 때가 얼마나 가까운지, 오늘 현재 동작을 못 박는 테스트 커버리지가 무엇인지 목록을 가져오십시오. 규제되고 공공의 환경에서는 옛 코드에 인코딩된 법정 규칙을 컴플라이언스 자산으로 다루십시오. 조용히 잃는 것은 기술 부채가 아니라 법적 노출입니다.

분야별 관점

스타트업. 여러분의 레거시는 메인프레임이 아니라 서둘러 만든 자체 MVP입니다. 이제 매출을 지고 있고 모두가 건드리기를 두려워하는 프로토타입입니다. 다시 쓰지 마십시오. 가장 무서운 모듈을 깨끗한 인터페이스 뒤에 감싸고, 특성화 테스트를 추가해 동작을 못 박고, 각 작은 릴리스가 가치를 출시하고 위험을 줄이도록 기능을 점진적으로 떼어 내십시오. 처음부터 다시 만들 런웨이가 없으니 우아함보다 선택 가능성이 더 중요합니다.

소기업. 현대화 팀도 빠듯한 예산도 없으니 실용적인 수는 대개 동작하는 시스템을 계속 동작하게 하는 것입니다. 그것을 이해하는 한 사람이 아는 것을 포착하고, 소스 관리와 몇 개의 자동화된 테스트를 갖추고, 맞춤 재구축보다 벤더나 패키지 제품에 기대십시오. 결정을 사느냐 만드느냐로 보고, 기능이 범용품일 때는 사는 쪽을 선호하십시오. 제한된 노력을 단지 가장 오래돼 보이는 것이 아니라 실패하면 비즈니스가 멈출 단일 시스템에 쓰십시오.

대기업. 문제는 포트폴리오 규모입니다. 수십 개의 시스템, 많은 팀, 자산 전반의 지식 위험입니다. 공유된 위험 대 가치 평가를 실행하고, 점진적 패턴(교살자 무화과와 추상화에 의한 분기)을 표준화하고, 데이터 이전과 이중 운영을 모두가 신뢰하는 조정이 있는 일급 규율로 다루십시오. 현대화를 영웅적 프로젝트의 산재가 아니라 위험 궤적에 대한 지속적 포트폴리오로 다스리고, 어떤 핵심 시스템도 은퇴를 앞둔 단일 유지보수자에게 의존하지 않도록 관리와 지식 포착을 명시적으로 예산에 넣으십시오.

정부. 수십 년에 걸쳐 인코딩된 법정 의무, 조달 규칙, 중단될 수 없는 시민 서비스는 빅뱅 교체를 특히 위험하게 만듭니다. 조각 단위 전환을 갖춘 점진적 교살자 무화과 이전을 선호하고, 조정과 긴 병렬 운영으로 시민 레코드 하나도 잃거나 잘못 계산되지 않았음을 입증하고, 내내 롤백을 가능하게 유지하십시오. 조달은 불투명한 번역이 아니라 데이터 이식성과 비즈니스 규칙의 공개를 요구해야 하며, 어떤 다년 프로그램이든 감사 가능한 가치를 일찍 전달하고 중간에 멈추더라도 공적 정밀 조사를 견뎌야 합니다.

사례

스타트업. 3년 된 스타트업의 원래 MVP는 그 나름의 레거시가 되었습니다. 이제 실제 매출을 처리하고 모두가 건드리기를 무서워하는 서둘러 만든 프로토타입입니다. 재작성 대신 팀은 최악의 모듈을 깨끗한 인터페이스 뒤에 감싸고, 특성화 테스트를 추가해 현재 동작을 못 박고, 몇 달에 걸쳐 기능을 조각조각 그것에서 옮깁니다. 각 작은 릴리스가 가치를 출시하고 무서운 부분을 줄여, 스타트업은 감당할 수 없는 처음부터의 재구축에 회사를 걸지 않고도 유지보수 가능한 시스템을 얻습니다.

대기업. 한 대형 보험사가 믿을 만하지만 바꾸기 비싸고 은퇴를 앞둔 소수의 엔지니어가 유지하는 메인프레임 COBOL 시스템에서 계약 관리를 운영합니다. 재작성 대신 보험사는 메인프레임을 현대적 API로 감싸고 교살자 무화과를 적용합니다. 새 견적-구매 및 셀프서비스 기능은 현대적 플랫폼에 만들어 퍼사드를 통해 라우팅하고, 핵심 계약 기록은 메인프레임에 남습니다. 병렬로 팀은 비즈니스 규칙을 문서화하고 COBOL 둘레에 특성화 테스트를 추가합니다. 여러 해에 걸쳐 기능이 하나씩 메인프레임에서 옮겨 가고, 각 릴리스가 가치를 전달하여, 남은 핵심이 위기 속이 아니라 보험사의 조건으로 퇴역할 수 있게 됩니다.

정부. 한 사회보장 기관은 수백만 시민에게 지급하고 중단되거나 잘못 지급될 수 없는 수십 년 된 급여 계산 시스템을 현대화해야 합니다. 비슷한 실패한 프로그램을 연구한 뒤 빅뱅 교체를 거부합니다. 대신 데이터를 프로파일링하고 정제하고, 통제 합계에 대한 완전한 조정을 갖춘 자동 이전을 만들고, 새 급여 엔진을 여러 달 동안 옛것과 병렬로 돌리며 둘에 같은 청구를 넣고 모든 계산을 비교하며, 각 불일치(흔히 보존해야 하는 문서화되지 않은 레거시 규칙을 드러냄)를 조사합니다. 새 시스템이 옛것과 매우 높은 신뢰도로 일치하고 나서야 급여 유형별로 전환하며 내내 롤백을 유지합니다. 교살자 퍼사드 덕에 시민은 전환 전체에 걸쳐 하나의 연속된 서비스를 봅니다.

비즈니스 사례: 동기, ROI, TCO

레거시 현대화는 특이한 비즈니스 사례를 갖습니다. 가장 큰 비용이 흔히 아무것도 하지 않는 비용이고 가장 큰 위험이 현대화 프로젝트 자체이기 때문입니다. 현대화하지 않는 누적 비용은 구체적입니다. 노후화된 플랫폼의 늘어나는 유지보수 및 라이선스 비용, 점점 희소하고 비싸지는 전문 인력, 새 규제나 서비스 요구에 빨리 대응하지 못함, 시스템을 이해하는 사람이 남지 않은 파국적 실패에 대한 늘어나는 노출입니다. 이에 비해 현대화 비용은 높고, 빅뱅으로 하면 진정으로 높은 실패 확률을 안습니다. 점진적 접근이 ROI에 중요한 이유가 정확히 이것입니다. 하나의 큰 베팅을 각각 가치를 돌려주고 멈출 수 있는 일련의 작은 베팅으로 바꿉니다.

리더십에게는 선택을 다시 구성해서 논거를 세우십시오. 질문은 “현대화하느냐 마느냐”가 아닙니다. “지금 점진적으로 현대화하느냐, 아니면 늘어나는 관리 비용을 치르고 나중에 위기 아래서 강제된 더 위험한 현대화를 맞느냐”입니다. 현상 유지의 TCO(플랫폼과 라이선스 비용, 희소한 기술의 프리미엄, 복구 불가능한 장애의 위험 가중 비용)를 정량화하고, 서비스를 계속 돌리면서 증분마다 위험과 비용을 줄이는 단계적 프로그램과 비교하십시오. 결정적으로, 제안된 모든 재작성이 일찍 그리고 자주 가치를 전달하도록 구성할 것을 요구하십시오. 3년간 아무것도 전달하지 않고 전체 손실로 취소될 수 있는 프로그램은 투자가 아니라 도박입니다. 교살자 접근을 위한 가장 강한 ROI 논거는 선택 가능성입니다. 가치가 지속적으로 출시되고 조직이 어느 시점에서든 방향을 조정할 수 있습니다.

안티패턴과 함정

빅뱅 재작성. 끝까지 가치를 전달하지 못하고 막대한 비용을 치르고 자주 취소되는 여러 해짜리 전부 아니면 전무의 교체.
이해 없는 재작성. 비즈니스 규칙이 문서화된 적 없는 코드를 교체하며 실제 사용자와 법이 의존하는 엣지 케이스를 조용히 떨어뜨리는 것.
데이터 과소평가. 프로젝트에서 가장 어렵고 위험한 부분인 데이터 이전을 사후 생각으로 다루는 것.
이중 운영 건너뛰기. 병렬 비교 없이 새 시스템으로 전환하고 실제 사람들에게 영향이 간 뒤에야 불일치를 발견하는 것.
해법으로서의 자동 번역. COBOL을 현대 언어로 기계 번역하고 일이 끝났다고 믿어, 옛 로직을 그대로 재현하는 이해할 수 없는 코드를 만드는 것.
위험이 아닌 나이에 따른 현대화. 오래되었지만 안정적인 시스템에 노력을 쓰는 동안 위험이 높고 변경이 많은 시스템이 기다리는 것.
지식 상실. 비즈니스 규칙을 포착하고 특성화 테스트를 추가하지 않은 채 마지막 유지보수자가 은퇴하게 두는 것.
롤백 없음. 새 시스템이 실제 부하와 실제 데이터에서 오동작할 때 돌아갈 길 없이 전환하는 것.

성숙도 모델

1단계: 시작. 레거시 시스템이 두려움의 대상이고 얼어붙어 있으며 변경이 회피됩니다. 목록도 위험 평가도 없습니다. 현대화는 시도되더라도 좌절에 이끌린 즉흥적인 전부 아니면 전무의 재작성입니다. 지식은 은퇴를 앞둔 몇몇 머릿속에 있고 적힌 것이 없습니다.
2단계: 발전. 일부 팀이 목록과 위험에 대한 대략적인 감각을 갖고, 몇몇 레거시 시스템은 접근을 위해 API로 감싸져 있습니다. 점진적 패턴은 알려져 있지만 고르지 않게 적용되고, 생각은 여전히 빅뱅 재작성 쪽으로 표류합니다. 데이터 이전은 시도되지만 과소평가되고, 실천은 팀마다 크게 다릅니다.
3단계: 표준화. 시스템이 문서화된 조직 전체의 방법에 따라 위험과 가치로 우선순위가 매겨집니다. 점진적 패턴(교살자 무화과, 추상화에 의한 분기)이 시행되는 기본이고, 모든 현대화가 표준 플레이북을 따릅니다. 데이터 이전은 전환 전 이중 운영을 갖춘 계획되고 조정된 노력이며, 지식 포착과 특성화 테스트는 선택이 아니라 요구되는 실천입니다.
4단계: 관리. 현대화가 데이터로 측정되고 통제됩니다. 자산은 기준선을 지닙니다. 시스템별 유지보수자 인원과 은퇴 전망, 특성화 테스트 커버리지, 이전 조정 통과율, 이중 운영 불일치 수, 증분당 출시된 가치가 모두 목표에 대해 추적됩니다. 관리 또는 교체 결정과 전환 진행 여부 판단은 이 증거에 근거하고, 지식 위험 임계값을 넘어 표류하는 시스템은 위기를 기다리지 않고 조치를 촉발합니다.
5단계: 오케스트레이션. 현대화가 지속적이고, 비즈니스 및 위험 계획과 통합되어 있으며, 적응적입니다. 포트폴리오는 위험 궤적(특히 지식 위험)이 이동함에 따라 재균형되고, 점진적 교체는 일상적이고 극적이지 않으며, 모든 증분이 가치를 전달하고 되돌릴 수 있으며, 조직은 속도를 의도적으로 조정합니다. 각 이전의 교훈이 공유 플레이북에 되먹임되어 자산 전체가 시간이 지나며 개선됩니다.

논의를 위한 아이디어

가장 핵심적인 레거시 시스템을 아직 유지할 수 있는 사람이 몇이며, 그들은 떠날 때가 얼마나 가깝습니까?
어디에서 빅뱅 재작성에 끌리며, 점진적 접근이 대신 처음 석 달에 어떤 가치를 출시할 수 있습니까?
가장 오래된 시스템의 비즈니스 규칙은 얼마나 잘 문서화되어 있으며, 코드가 교체되면 그것들은 어떻게 됩니까?
이전해야 할 데이터를 프로파일링했으며, 실제로 얼마나 더럽고 얽혀 있는지 압니까?
안전하게 내버려 둘 수 있는데 현대화 에너지를 쓰고 있는 오래되었지만 안정적인 시스템은 무엇입니까?
새 시스템을 옛 시스템과 병렬로 운영하고 전환 전에 둘이 일치함을 입증할 수 있습니까?

핵심 요점

레거시는 가치 있고 기초적인 것을 뜻합니다. 바꾸기 전에 시스템을 존중하고 이해하십시오.
교살자 무화과와 추상화에 의한 분기로 점진적으로 현대화하고, 가치를 지속적으로 전달하며 모든 변경을 작고 되돌릴 수 있게 유지하십시오.
빅뱅 재작성을 기본 실패 방식으로 다루십시오. 진정으로 지속 불가능한 플랫폼에 남겨 두고, 그때에도 분해하십시오.
나이가 아니라 위험과 가치(특히 지식 위험)로 우선순위를 매기십시오. 일부 오래된 시스템은 교체가 아니라 관리하는 것이 최선입니다.
데이터 이전과 이중 운영이 노력의 핵심입니다. 프로파일링하고, 조정하고, 병렬로 운영하고, 롤백을 유지하십시오.
가장 강한 비즈니스 사례는 선택 가능성입니다. 점진적 현대화는 하나의 크고 위험한 베팅을 가치를 돌려주는 많은 작은 베팅으로 바꿉니다.

참고 문헌과 더 읽을거리

Michael Feathers, Working Effectively with Legacy Code
Martin Fowler, “StranglerFigApplication” and “BranchByAbstraction”
Sam Newman, Monolith to Microservices
Nicholas Carr / industry studies on mainframe and COBOL dependency (context on the scale of legacy estates)
Robert Annett, Working with Legacy Systems
Eric Evans, Domain-Driven Design (anti-corruption layer)
Gregor Hohpe, Enterprise Integration Patterns and The Software Architect Elevator
Standish Group CHAOS Report (evidence on large project and rewrite failure rates)