다운타임 없는 리팩토링: 오프라인으로 전환하지 않고 시스템을 리팩토링하는 방법

운영 시스템은 중단될 수 없습니다. 새벽 2시에 거래를 처리하는 금융 플랫폼, 여러 시간대에 걸쳐 의료진에게 의료 기록을 제공하는 의료 시스템, 대륙을 넘나드는 배송을 추적하는 물류 애플리케이션 등 그 어떤 시스템도 리팩토링 작업을 위한 유지보수 시간을 확보할 수 없습니다. 그럼에도 불구하고 이러한 시스템들은 모두 기술 부채를 축적하고, 이전의 제약 조건 하에서 결정된 아키텍처를 유지하며, 결국 유지보수성, 확장성 및 보안성을 유지하기 위해 구조적 변화가 필요합니다. 무중단 리팩토링은 이러한 문제를 해결하는 방법입니다. 즉, 서비스 제공을 중단하지 않고 운영 중인 시스템을 발전시키는 것입니다.

이 문제는 단순히 기술적인 문제에 그치지 않습니다. 조직적이고 아키텍처적인 문제입니다. 오프라인 상태를 유지할 수 없는 시스템을 리팩토링하는 것은 개발 중인 시스템을 리팩토링하는 것과는 전혀 다른 사고방식을 요구합니다. 모든 변경 사항은 호환성이 유지되어야 하며, 모든 구조적 전환은 되돌릴 수 있어야 하고, 모든 검증은 가상 테스트가 아닌 실제 트래픽을 대상으로 이루어져야 합니다. 이러한 요구 사항을 충족하는 기술로는 블루-그린 배포, 기능 토글, 스트랭글러 피그 패턴, 확장-축소 데이터베이스 마이그레이션, 멱등성 이벤트 기반 아키텍처 등이 있으며, 각각은 잘 알려져 있습니다. 하지만 이러한 기술들이 어떻게 통합되어, 시스템 전반에 걸쳐 사용자에게 서비스를 제공해야 하는 상황에서 지속적이고 안전한 구조적 변화를 위한 전략으로 작용하는지에 대해서는 충분히 논의되지 않고 있습니다.

다운타임 없는 변경을 위한 아키텍처는 어떤 모습이어야 할까요?

무중단 리팩토링을 진행할 때 팀들이 가장 많이 묻는 질문은 아키텍처에 관한 것입니다. 리팩토링을 시작하기 전에 시스템 구축 방식에서 무엇을 바꿔야 할까요? 답은 단 하나의 패턴이 아니라, 운영 중 리팩토링을 안전하게 수행하기 전에 시스템이 갖춰야 할 일련의 구조적 속성입니다. 이러한 속성을 이해하는 것은 이 가이드의 나머지 내용을 이해하는 데 필수적입니다.

첫 번째 속성은 독립적인 배포 가능성입니다. 리팩토링될 모든 구성 요소는 종속 구성 요소의 동시 배포 없이 배포 가능해야 합니다. 서비스 A를 변경하기 위해 서비스 B와 서비스 C를 동시에 변경해야 하는 경우, 서비스 A의 무중단 배포는 구조적으로 불가능합니다. 세 서비스는 저장소의 수와 관계없이 사실상 단일 배포 단위로 간주되기 때문입니다. 독립적인 배포 가능성을 위해서는 하위 호환성을 유지하는 인터페이스, 버전 관리되는 계약, 그리고 서비스 간의 배포 조정 요구 사항 제거가 필요합니다.

두 번째 속성은 가역성입니다. 실제 운영 환경을 변경하는 모든 배포는 몇 시간이 아닌 몇 분 안에 되돌릴 수 있어야 합니다. 가역성은 단순히 이전 바이너리를 사용할 수 있도록 유지하는 것만을 의미하지 않습니다. 새 버전에서 수정된 데이터베이스 상태, 캐시 상태, 세션 상태 및 모든 외부 시스템 상태가 이전 버전과 호환되어야 합니다. 새 버전이 이전 버전에서 읽을 수 없는 형식으로 데이터를 기록하는 경우, 배포는 본질적으로 되돌릴 수 없으며, 롤백 시 오류가 발생하므로 무중단은 불가능합니다.

세 번째 속성은 관찰 가능한 상태 전환입니다. 두 경로 모두에서 관찰 가능한 메트릭 없이 동작을 한 코드 경로에서 다른 코드 경로로 이동시키는 리팩토링 작업은 맹목적으로 진행하는 것과 같습니다. 팀은 전환이 성공하는지 실패하는지 알 수 없고, 회귀를 조기에 감지할 수 없으며, 마이그레이션을 가속화하거나 중단해야 할 시점에 대한 데이터 기반 결정을 내릴 수 없습니다. 관찰 가능성은 문제가 발생한 후에 추가하는 것이 아니라 리팩토링이 시작되기 전에 확보해야 합니다. 이러한 맥락에서 살펴보겠습니다. 점진적 리팩토링과 기술적 부채코드의 기능과 코드에 대한 의존성을 구조적으로 명확하게 파악하는 것은 프로덕션 환경에서 실패해서는 안 되는 모든 변경 사항을 계획하는 데 있어 기본 토대가 됩니다.

청록색 배치: 기본 패턴

블루-그린 배포는 무중단 릴리스를 위한 기본 패턴입니다. 두 개의 동일한 프로덕션 환경이 존재합니다. 하나는 실제 트래픽을 처리하는 블루 환경이고, 다른 하나는 새 버전을 수신하는 그린 환경입니다. 새 버전은 블루 환경에서 배포, 테스트 및 검증되는 동안 블루 환경은 중단 없이 사용자에게 서비스를 계속 제공합니다. 그린 환경의 검증이 완료되면 트래픽이 원자적으로 전환됩니다. 롤백은 그 반대 과정입니다. 트래픽을 블루 환경으로 되돌리면 블루 환경은 중단 없이 계속 사용 가능합니다.

이 패턴은 간단해 보이지만, 실제로는 데이터베이스 계층에서 어려움이 있습니다. 두 환경 모두 동일한 데이터베이스에서 읽고 써야 하는 경우, 데이터베이스 스키마는 두 버전 모두와 동시에 호환되어야 합니다. 열을 삭제하거나, 필드 이름을 바꾸거나, 데이터 형식을 변경하는 마이그레이션은 실행되는 순간 기존 환경을 손상시킵니다. 이것이 바로 블루-그린 배포가 이 가이드의 데이터베이스 섹션에서 설명하는 확장-축소 스키마 마이그레이션 패턴과 불가분한 관계에 있는 이유입니다.

카나리 릴리스 및 단계적 출시 기법

카나리 릴리스는 모든 트래픽을 한 번에 전환하는 대신 트래픽의 일부를 새 버전으로 라우팅하는 방식으로 블루-그린 모델을 확장합니다. 카나리 배포는 사용자 그룹의 1%로 시작하여 오류율, 지연 시간 및 비즈니스 지표를 관찰한 다음, 비율을 5%, 20%, 50%, 100%로 점진적으로 늘릴 수 있습니다. 각 단계에서 자동화된 게이트를 통해 주요 지표가 정의된 임계값을 초과하여 저하되지 않았는지 확인합니다. 게이트에서 오류가 발생하면 배포가 중단되고 카나리 비율은 0%로 줄어듭니다.

단계별 배포 기법은 이러한 진행 과정에 타겟팅 로직을 추가합니다. 단순히 비율에 따라 트래픽을 라우팅하는 대신, 사용자 코호트, 지역, 구독 등급 또는 세션 특성에 따라 트래픽을 세분화할 수 있습니다. 이를 통해 특정 사용자 집단을 대상으로 새 버전의 성능을 검증한 후, 해당 집단에 대한 마이그레이션을 완료할 수 있습니다. 핵심 요구 사항은 로드 밸런서, API 게이트웨이 또는 서비스 메시와 같은 라우팅 인프라가 배포에 필요한 세분화된 타겟팅을 지원해야 한다는 것입니다.

카나리 게이트를 관리하는 지표는 배포 시작 전에 정의해야 합니다. 오류율, p99 지연 시간, 데이터베이스 쿼리 시간, 전환율 또는 결제 성공률과 같은 비즈니스별 지표는 모두 유효한 게이트 기준이 될 수 있습니다. 게이트 임계값은 이론적인 목표치가 아닌, 유사한 부하 조건에서 기존 버전을 기준으로 측정한 실제 데이터를 기반으로 설정해야 합니다. 트래픽의 2%에서 게이트를 통과했지만 20%에서 실패한 배포는 검증된 것이 아닙니다. 카나리 배포 규모가 너무 작아 대표성을 확보하지 못한 것입니다. 적절한 단계별 배포를 위해서는 각 단계에서 통계적으로 의미 있는 비교를 위해 충분한 트래픽 노출이 필요합니다.

기능 토글 및 킬 스위치

기능 토글은 코드 배포와 동작 활성화를 분리합니다. 리팩토링된 코드 경로는 비활성 상태로 배포되며, 토글을 통해 어떤 사용자 또는 요청이 새로운 로직을 실행할지 결정할 수 있습니다. 토글은 단계적으로 활성화하거나, 특정 그룹을 대상으로 하거나, 재배포 없이 즉시 되돌릴 수 있습니다. 따라서 기능 토글은 인프라 변경 시 블루-그린 또는 카나리 패턴이 더 적합한 것과는 달리, 비즈니스 로직을 다운타임 없이 마이그레이션하는 데 가장 적합한 메커니즘입니다.

킬 스위치는 기능 토글의 방어적 대응 개념입니다. 새로운 동작을 활성화하는 것이 아니라, 오작동 시 즉시 비활성화하는 것을 목적으로 합니다. 재구성된 청구 계산 방식, 새로운 인증 흐름, 또는 대체 데이터 액세스 계층에 킬 스위치를 적용하면, 당직 엔지니어는 배포, 데이터베이스 롤백, 또는 팀 간 협업 없이도 단일 조치로 문제를 복구할 수 있습니다. 킬 스위치는 API 호출, 기능 플래그 관리 콘솔, 또는 자동화된 알림 통합을 통해 작동하도록 시스템에 구성되어야 하며, 작동 지연 시간은 분이 아닌 몇 초 이내여야 합니다.

토글 관리는 실질적인 운영상의 문제입니다. 정리되지 않은 토글은 코드베이스에 누적되어 제어 흐름을 파악하기 어렵게 만들고, 토글 상태와 데이터 상태 간에 암묵적인 의존성을 생성합니다. 모든 토글에는 문서화된 담당자, 계획된 만료일, 그리고 정리 티켓이 있어야 합니다. 토글 부채는 다른 기술 부채와 마찬가지로 심각한 문제이며, 토글이 시스템에서 가장 활발하게 변경되는 부분을 보호하는 역할을 하기 때문에 더욱 빠르게 누적됩니다.

다운타임 없이 데이터베이스 리팩토링

데이터베이스 변경은 무중단 리팩토링에서 가장 어려운 부분입니다. 데이터베이스는 상태를 저장하고, 공유되며, 대규모로 수정할 때 속도가 느리기 때문입니다. 애플리케이션은 몇 분 안에 배포하고 롤백할 수 있지만, 수억 개의 행이 있는 테이블을 변경하는 데이터베이스 마이그레이션은 몇 시간이 걸릴 수 있으며, 일단 커밋되면 되돌리기가 어렵고, 마이그레이션이 진행되는 동안 읽기 및 쓰기를 차단하는 락이 발생합니다. 데이터베이스 리팩토링을 제대로 하려면 애플리케이션 코드 리팩토링과는 다른 접근 방식이 필요하며, 대부분의 팀은 운영 중인 고트래픽 테이블의 스키마 변경을 처음 시도할 때 이 점을 깨닫게 됩니다.

핵심 원칙은 모든 데이터베이스 변경 사항이 이전 버전의 애플리케이션이 더 이상 배포되지 않을 때까지 이전 버전과 하위 호환성을 유지해야 한다는 것입니다. 이는 당연해 보이지만, 간과하기 쉬운 의미를 내포하고 있습니다. 열 이름을 변경하려면 이전 이름을 제거하기 전에 새 이름을 별칭이나 복제본으로 추가해야 합니다. 열 유형을 변경하려면 이전 열을 삭제하기 전에 새 유형의 섀도우 열을 병렬로 생성해야 합니다. 테이블을 삭제하려면 배포된 애플리케이션 버전 중 어느 것도 해당 테이블을 읽지 않는지 확인해야 합니다. 이러한 각 작업은 한 번 실행되는 단일 마이그레이션이 아니라 여러 배포에 걸쳐 수행되는 다단계 프로세스입니다. 더 넓은 맥락에서 논의된 바와 같이 기존 데이터 구조 전반에 걸친 COBOL 리팩토링여러 프로그램과 시스템에서 공유되는 데이터 구조를 조정된 전환 없이 진화시키는 것은 기업 규모 리팩토링의 주요 난제 중 하나입니다.

확장-수축 패턴

확장-축소 패턴은 스키마 변경에 대한 다단계 접근 방식을 공식화합니다. 확장 단계에서는 새로운 스키마 요소가 기존 요소에 점진적으로 추가됩니다. 예를 들어 기존 열 옆에 새 열을 추가하고, 기존 테이블 옆에 새 테이블을 추가하고, 기존 인덱스 옆에 새 인덱스를 추가합니다. 애플리케이션은 기존 구조와 새 구조 모두에 데이터를 쓰도록 업데이트되지만, 읽기는 기존 구조에서 계속 수행합니다. 데이터 손실이나 기존 쿼리 오류는 발생하지 않으며, 기존 스키마 요소가 여전히 존재하기 때문에 이전 버전의 애플리케이션도 계속 작동합니다.

새 버전이 완전히 배포되고 검증된 후 별도의 배포 과정에서 진행되는 축소 단계에서는 이전 스키마 요소가 제거됩니다. 이 시점에는 실행 중인 애플리케이션 버전이 더 이상 이전 스키마 요소에 의존하지 않습니다. 이러한 제거는 계획을 통해 가정한 것이 아니라 관찰을 통해 검증되었으므로 안전합니다.

확장-축소 패턴은 배포 순서에 대한 엄격한 준수를 요구합니다. 새 열을 추가하는 데이터베이스 마이그레이션은 해당 열에 쓰는 애플리케이션 버전보다 먼저 배포되어야 합니다. 기존 열을 삭제하는 데이터베이스 마이그레이션은 해당 열에서 읽는 모든 애플리케이션 버전이 사용 중지된 후에 배포되어야 합니다. 이러한 순서 요구 사항은 배포 파이프라인에 명시되어야 마이그레이션이 순서대로 적용되지 않는 것을 방지할 수 있습니다.

기존 데이터 파이프라인을 코드 재작성 없이 리팩토링하는 도구

특히 배치 처리 프레임워크, ETL 도구 또는 메인프레임 기반 데이터 이동을 기반으로 구축된 기존 데이터 파이프라인은 다음과 같은 특수한 문제점을 안고 있습니다. 이러한 파이프라인은 데이터를 지속적으로 변환하고 이동하며, 마이그레이션 기간 동안 중단할 수 없고, 종종 문서화가 부족하여 문제가 발생하기 전까지는 전체적인 작동 방식을 파악하기 어렵습니다. 파이프라인을 완전히 재작성하지 않고 리팩토링하려면 현재 파이프라인의 동작을 관찰하고, 리팩토링된 버전이 동일한 출력을 생성하는지 검증하며, 갑작스러운 전환이 아닌 단계적인 전환을 가능하게 하는 도구가 필요합니다.

변경 데이터 캡처(CDC)는 실시간 파이프라인 리팩토링에 가장 널리 적용 가능한 도구입니다. CDC는 소스 테이블의 모든 쓰기 작업을 이벤트 스트림으로 캡처하여 기존 파이프라인과 새로운 대체 파이프라인 모두에 동일한 소스 데이터를 수정할 필요 없이 공급할 수 있도록 합니다. 기존 파이프라인은 계속 실행되고, 새로운 파이프라인은 동일한 이벤트 스트림을 대상으로 병렬로 실행된 후 출력 결과를 비교합니다. 불일치가 발견되면 올바르게 재구현되지 않은 변환 로직을 식별할 수 있습니다. 두 파이프라인의 동일성이 확인되면 기존 파이프라인은 더 이상 사용되지 않습니다.

Liquibase 및 Flyway와 같은 스키마 마이그레이션 도구는 버전 관리 및 순차적 마이그레이션을 제공하며, 확장-축소 원칙과 결합하면 점진적으로 적용하고 롤백할 수 있습니다. 이러한 도구는 각 환경에 어떤 마이그레이션이 적용되었는지 추적하고 순서가 잘못된 적용을 방지합니다. 메인프레임 또는 VSAM 기반 데이터 저장소에서 실행되는 기존 파이프라인의 경우, 이와 동등한 기능은 다른 방식으로 관리됩니다. JCL 확장 및 데이터셋 관리 이는 전환 과정에서 프로그램이 데이터에 접근하는 방식을 제어하여 기존 프로그램과 새 프로그램 모두 호환되지 않는 데이터셋 레이아웃을 사용하여 실행되지 않도록 보장합니다.

시스템 다운타임 없이 기존 데이터베이스를 현대화하는 방법

레거시 데이터베이스를 현대화하는 구체적인 과제, 즉 메인프레임 DB2 스키마에서 클라우드 호스팅 환경의 관계형 데이터베이스로의 전환, 파일 기반 VSAM 구조에서 관계형 스키마로의 마이그레이션, 또는 여러 레거시 데이터베이스를 새로운 통합 저장소로 통합하는 작업에는 위에 언급된 모든 기술을 장기간에 걸쳐 순차적으로 적용해야 합니다.

일관되게 효과적인 접근 방식은 다음과 같습니다. 먼저 읽기 동등성을 확보한 다음 쓰기 동등성을 달성하고, 그 다음 읽기 마이그레이션을 진행하고, 마지막으로 쓰기 마이그레이션을 진행한 후 기존 저장소를 폐기합니다. 읽기 동등성이란 새 저장소에 기존 저장소의 모든 데이터가 포함되어 있고 애플리케이션에서 수행하는 모든 쿼리를 처리할 수 있음을 의미합니다. 쓰기 동등성이란 애플리케이션이 기존 저장소에 수행하는 모든 쓰기 작업이 애플리케이션 내의 이중 쓰기 또는 CDC 복제를 통해 새 저장소에도 적용됨을 의미합니다. 운영 환경에서 두 동등성 조건이 모두 확인되면 읽기 마이그레이션을 새 저장소로 진행하고(출력 유효성 검사), 그 다음 쓰기 마이그레이션을 진행한 후 기존 저장소를 폐기할 수 있습니다.

이 과정의 어떤 단계에서도 서비스가 중단되지 않습니다. 각 단계에서 읽기 또는 쓰기 작업을 이전 저장소로 되돌려 이전 상태를 복원할 수 있습니다. 각 단계의 소요 시간은 고정된 날짜가 아니라 유효성 검사를 통해 얻은 신뢰도에 따라 결정됩니다.

기존 코드를 다시 작성하지 않고 레거시 시스템을 리팩토링하는 도구

기존 시스템을 처음부터 다시 작성하는 것은 점진적으로 리팩토링하는 것보다 거의 항상 비용이 많이 들고 위험합니다. 완전 재작성은 기존 시스템을 운영 환경에서 유지하면서 동시에 유사한 기능을 갖춘 대체 시스템을 구축하고, 두 시스템 간의 기능 격차를 관리하며, 사실상 다운타임 없이 완전히 다른 시스템으로 전환하는 작업을 수행해야 합니다. 완전 재작성을 시도하는 대부분의 조직은 진행 과정에서 기존 시스템에 문서화되지 않은 동작이 포함되어 있거나, 대체 시스템이 아직 이를 재현하지 못하거나, 사용자가 의존하는 부분이 있다는 사실을 발견합니다.

적절한 도구를 사용한 점진적 리팩토링은 기존 시스템을 변경하기 전에 가독성을 높여 이러한 함정을 피합니다. 시작점은 구조 분석입니다. 즉, 기존 시스템의 모든 구성 요소가 무엇을 하는지, 무엇이 그 구성 요소에 의존하는지, 그리고 그 구성 요소가 무엇에 의존하는지를 파악하는 것입니다. 이러한 분석은 문서(레거시 시스템의 경우 일반적으로 없거나 부정확함)를 읽거나 대규모 코드를 수동으로 읽는 것만으로는 수행할 수 없습니다. 기존 코드를 분석하고, 의존성 그래프를 구성하고, 해당 그래프를 쿼리할 수 있도록 하는 자동화된 도구가 필요합니다. 이는 앞서 설명한 맥락에서 이해할 수 있습니다. 기존 시스템 통합 문제 관리레거시 시스템 리팩토링 프로그램의 첫 번째 단계는 사람이 관리하는 어떤 산출물에도 존재하지 않는 구조적 가시성을 확보하는 것입니다.

모놀리스용 스트랭글러 피그 패턴

스트랭글러 패턴은 전체적인 재작성이나 전환 작업 없이 모놀리식 아키텍처를 점진적으로 교체하는 데 가장 널리 사용되는 아키텍처 전략입니다. 새로운 기능은 기존 모놀리식 아키텍처와 함께 독립적인 서비스로 구축됩니다. 라우팅 계층(일반적으로 API 게이트웨이 또는 리버스 프록시)은 들어오는 요청을 가로채서 라우팅 규칙에 따라 모놀리식 아키텍처 또는 새로운 서비스로 전달합니다. 모놀리식 아키텍처는 아직 마이그레이션되지 않은 모든 트래픽을 계속 처리합니다. 새로운 서비스는 명시적으로 자신에게 라우팅된 트래픽만 처리합니다.

시간이 지남에 따라 라우팅 규칙이 추가되고, 새로운 서비스로 향하는 경로가 늘어납니다. 모놀리식 시스템은 전체 트래픽 중 점점 더 적은 부분을 처리하게 되고, 결국에는 아무것도 처리하지 않게 되어 폐기될 수 있습니다. 이 과정에서 발생하는 단일 배포는 심각한 위험을 초래할 만큼 규모가 크지 않습니다. 각 라우팅 규칙 변경은 개별적으로 테스트 가능하고, 개별적으로 되돌릴 수 있습니다. 스트랭글러 방식은 빠른 변환을 위한 기술이 아니라, 시스템의 복잡성에 따라 몇 주, 몇 달 또는 몇 년에 걸쳐 안전하게 변환하기 위한 기술입니다.

스트랭글러 피그 패턴의 핵심 구현 요건은 라우팅 계층이 모놀리스와 새로운 서비스 모두로부터 분리되어야 한다는 것입니다. 모놀리스에 내장된 라우팅 계층은 모놀리스에서 트래픽을 다른 곳으로 라우팅할 수 없습니다. 프록시는 두 시스템 모두 앞에 위치해야 하며, 모놀리스나 새로운 서비스를 수정하지 않고도 설정을 변경할 수 있도록 구성에 따라 트래픽을 어느 쪽으로든 전달할 수 있어야 합니다.

다운타임 없이 기존 레거시 API를 클라우드 네이티브 서비스로 리팩토링하기

기존 API를 클라우드 네이티브 API로 마이그레이션하는 것은 추가적인 제약 조건이 있는 스트랭글러 피그 패턴의 특정 적용 사례입니다. 기존 API는 동시에 업데이트할 수 없는 소비자를 가질 수 있고, 전환 과정 전반에 걸쳐 API 계약을 유지해야 하며, 클라우드 네이티브 API는 예상치 못한 방식으로 소비자에게 영향을 미치는 기존 API와 다른 성능 특성을 가질 수 있습니다.

일반적인 접근 방식은 기존 API와 동일한 API 계약을 사용하여 클라우드 네이티브 대체 API를 배포하고, 카나리 기법을 통해 트래픽의 일부를 대체 API로 라우팅한 다음, 해당 트래픽 비율에 대해 출력 동등성을 검증하고, 라우팅 비율을 점진적으로 늘리는 것입니다. API 계약이 그대로 유지되므로 사용자는 전환 과정에서 아무것도 변경할 필요가 없습니다. 라우팅 계층이 전환을 투명하게 처리합니다.

이 글의 검색 콘솔 데이터에서 높은 의도를 가진 쿼리로 나타나는 핵심 통합에서 미들웨어 API로의 무중단 전환은 바로 이러한 시나리오를 의미합니다. 즉, 라우팅 계층이 업데이트되어 모든 트래픽이 새 시스템으로 전송되고 기존 API가 더 이상 사용되지 않게 되는 순간을 말합니다. 이러한 전환은 절대 단일한 이벤트로 발생해서는 안 됩니다. 점진적인 배포 과정의 마지막 단계로, 점진적으로 증가하는 트래픽 비율에서 새 시스템의 유효성을 검증해야 합니다. 최종 전환이 이루어질 때쯤이면 새 시스템은 이미 전체 트래픽 볼륨을 처리한 상태여야 하며, 전환은 단순히 더 이상 필요하지 않은 대체 경로를 제거하는 작업일 뿐입니다.

리팩토링된 시스템에서의 멱등성, 재시도 및 장애 조치

이벤트 기반 아키텍처, 메시지 큐 또는 분산 서비스 호출을 사용하는 시스템을 리팩토링하면 배포에만 초점을 맞춘 패턴으로는 해결할 수 없는 문제가 발생합니다. 서비스가 이전 버전에서 새 버전으로 전환될 때 진행 중인 작업은 어떻게 처리해야 할까요? 이전 버전에서 발행된 이벤트가 새 버전에서 실행되는 핸들러에 도달할 수 있습니다. 이전 API를 대상으로 시작된 요청이 이미 새로운 내부 구조로 리팩토링된 핸들러에 도달할 수 있습니다. 이전 로직에서 부분적으로 완료된 트랜잭션이 새 로직에서 완료되거나 보완되어야 할 수 있습니다.

이러한 모든 문제에 대한 해답은 멱등성입니다. 즉, 모든 연산이 한 번 실행되든 여러 번 실행되든 동일한 결과를 생성하도록 설계하는 것입니다. 배포 전환 중에 중복된 이벤트를 수신하는 멱등성 핸들러는 이벤트를 정확히 한 번 수신하는 핸들러와 동일한 출력을 생성합니다. 롤백의 일부로 다시 실행되는 멱등성 쓰기 연산은 원래 쓰기와 동일한 데이터베이스 상태를 생성합니다. 멱등성은 단순히 리팩토링 시 고려해야 할 사항이 아니라, 복원력이 뛰어난 분산 시스템의 일반적인 속성입니다. 하지만 리팩토링 전환 과정에서 멱등성이 결여되면 가장 눈에 띄는 오류가 발생합니다.

대규모 리팩토링 없이 재시도 및 공급자 장애 조치 기능 추가하기

이 글의 검색 콘솔 데이터에서 가장 자주 나오는 질문 중 하나는 대대적인 리팩토링 작업 없이 기존 애플리케이션, 특히 Rails 또는 유사한 프레임워크 애플리케이션에 재시도 및 장애 조치 기능을 추가하는 방법입니다. 답은 개별 서비스 구현을 수정하지 않고도 인프라 계층에서 횡단 관심사로 재시도 및 장애 조치 기능을 추가할 수 있다는 것입니다.

인프라 계층에서 Istio 또는 Linkerd와 같은 서비스 메시를 구성하면 정의된 재시도 횟수까지 실패한 요청을 자동으로 재시도할 수 있으며, 지수 백오프와 지터를 적용하여 '썬더링 허드(thundering herd)' 현상을 방지할 수 있습니다. 재시도 동작은 모든 인바운드 및 아웃바운드 요청을 가로채는 사이드카 프록시에서 구현되므로 애플리케이션 코드를 변경할 필요가 없습니다. 공급자 장애 조치도 유사하게 구현할 수 있습니다. 기본 공급자가 임계값 이상의 오류를 반환하는 경우, 기본 공급자가 복구될 때까지 메시는 후속 요청을 보조 공급자로 라우팅합니다.

애플리케이션 계층에서 인프라 수준의 재시도만으로는 충분하지 않을 때, 즉 재시도 로직이 비즈니스 상태를 인식해야 할 필요가 있을 때, 애플리케이션 내부 구조를 변경하지 않고도 애플리케이션과 외부 종속성 사이의 경계에 경량 재시도 라이브러리 또는 작업 큐를 도입할 수 있습니다. 핵심은 재시도 및 장애 조치 로직을 비즈니스 로직 계층 전체에 분산시키는 대신 통합 경계에 격리하는 것입니다. 이렇게 하면 핵심 애플리케이션 구조를 건드리지 않고도 재시도 동작을 가시화하고, 테스트하고, 구성할 수 있습니다. 이는 앞서 논의된 맥락에서 볼 수 있습니다. 애자일 리팩토링 실무비즈니스 로직을 리팩토링하기 전에 인프라 수준의 안정성 패턴을 도입하면 각 변경 후 검증해야 하는 영역을 줄일 수 있습니다.

Redis Streams를 사용한 이벤트 기반 아키텍처에서의 멱등성

Redis Streams 또는 유사한 기술을 사용하는 저지연 이벤트 기반 아키텍처는 리팩토링 중에 특정 멱등성 문제에 직면합니다. 소비자 그룹이 이벤트를 처리하는 속도가 다를 수 있고, 새 버전에서 이벤트를 읽는 소비자가 이전 버전에서 처리하지 않은 이벤트를 이미 처리했을 수 있으며, 재생 또는 복구 작업으로 인해 중복 처리를 위해 설계되지 않은 핸들러에 동일한 이벤트가 여러 번 전달될 수 있습니다.

일반적인 접근 방식은 이벤트 발생 시점에 모든 이벤트에 고유 식별자를 할당하고 처리된 이벤트 식별자를 영구 저장소에 저장하는 것입니다. 이벤트 핸들러는 이벤트를 처리하기 전에 해당 식별자가 이미 처리되었는지 확인합니다. 이미 처리된 경우, 이벤트는 승인되고 재처리 없이 폐기됩니다. 아직 처리되지 않은 경우, 이벤트가 처리되고 식별자가 기록됩니다. 이러한 중복 제거 로직은 원자적이어야 합니다. 핸들러가 이벤트를 처리하지만 식별자를 기록하기 전에 실패하면 다음 전달 시 이벤트가 다시 처리됩니다. Redis의 원자적 작업 또는 트랜잭션 쓰기를 사용하여 처리 작업의 일부로 식별자를 기록하면 이러한 경쟁 조건을 방지할 수 있습니다.

소비자 로직이 변경되는 리팩토링 전환 과정에서 멱등성 식별자는 추가적인 이점을 제공합니다. 이를 통해 새로운 소비자 로직에 대해 이벤트 스트림을 재생하고 이전 소비자 로직의 기록된 출력과 비교할 수 있으므로, 사용자에게 새로운 로직을 노출하지 않고도 비교 테스트를 수행할 수 있습니다.

CI/CD 파이프라인에서 리팩토링 자동화

무중단 리팩토링이라는 원칙은 수동 프로세스로는 지속될 수 없습니다. 무중단 프로그램의 모든 배포에는 일련의 검증 과정이 필요합니다. 배포 전 새 버전이 현재 데이터베이스 상태와 호환되는지 확인하는 검사, 트래픽 증가율에 따른 카나리 게이트 평가, 기존 코드 경로와 새 코드 경로의 출력 자동 비교, 그리고 배포 후 주요 지표가 저하되지 않았는지 확인하는 검증 등이 포함됩니다. 모든 변경 사항에 대해 이러한 단계를 수동으로 수행하는 것은 운영상 지속 가능하지 않으며, 프로세스에서 가장 중요한 지점에서 인적 오류가 발생할 가능성을 높입니다.

무중단 리팩토링을 위한 CI/CD 파이프라인은 단순히 빌드 및 배포 파이프라인이 아닙니다. 이는 검증 파이프라인으로, 변경 사항이 다음 배포 단계로 넘어가기 전에 모두 통과해야 하는 일련의 자동화된 관문입니다. 각 관문은 구체적이고 측정 가능한 기준입니다. 관문을 통과하지 못하면 파이프라인이 중단되고 경고가 발생합니다. 모든 관문을 통과하면 배포가 자동으로 다음 단계로 진행됩니다. 이는 더 자세한 설명에서 다루었습니다. 메인프레임 및 엔터프라이즈 환경을 위한 CI/CD 모범 사례핵심 요구 사항은 파이프라인이 변경 사항의 크기에 관계없이 모든 변경 사항에 대해 동일한 배포 규율을 적용해야 하며, 이러한 규율 적용이 개별 엔지니어의 주의에 의존하는 것이 아니라 자동화되어야 한다는 것입니다.

라이브 리팩토링을 위한 파이프라인 단계 게이트

단계별 게이트는 배포가 다음 단계로 진행하기 전에 통과해야 하는 유효성 검사 지점입니다. 다운타임이 없는 리팩토링 파이프라인의 최소 게이트 세트는 다음과 같습니다.

배포 전 단계: 스키마 호환성 검사를 통해 데이터베이스 마이그레이션이 현재 애플리케이션 버전과 하위 호환되는지 확인하고, 자동화된 계약 테스트를 통해 새 버전의 API 응답이 이전 버전의 계약과 호환되는지 검증하며, 정적 종속성 분석을 통해 새 버전에서 도입되는 종속성이 기존 환경에 필요한 종속성과 충돌하지 않는지 확인합니다.

카나리 배포 후: 카나리 트래픽과 기준 트래픽 간의 오류율 비교, p50, p95 및 p99에서의 지연 시간 비교, 변경된 코드 경로의 영향을 받는 모든 비즈니스 지표에 대한 비교, 그리고 트래픽 비율을 높이기 전에 카나리가 안정적으로 유지되어야 하는 최소 관찰 기간 설정.

전체 배포 후: 프로덕션 엔드포인트에 대한 회귀 테스트 스위트 실행, 이중 쓰기 또는 확장-축소 마이그레이션이 일관성을 유지했는지 확인하는 데이터베이스 일관성 검사, 그리고 이전 배포 아티팩트가 롤백을 위해 여전히 사용 가능한지 확인합니다.

규정 준수 중심의 리팩토링 및 시행

규정 준수를 위한 리팩토링은 파이프라인 게이트에서 반드시 준수해야 하는 추가적인 제약 조건을 도입합니다. 즉, 모든 변경 사항은 적용 가능한 규제 또는 조직 정책 요건과 명확하게 일치해야 합니다. 규제 산업의 경우, 이는 배포 파이프라인이 변경 내용, 배포 시점, 수행된 유효성 검사, 승인 담당자 등을 보여주는 감사 추적 기록을 생성해야 함을 의미합니다. 입력 상태, 게이트 기준, 통과/실패 결과 등을 포함하여 자체 실행 과정을 기록하는 자동화된 파이프라인 게이트는 수동 문서화 작업 없이 이러한 감사 추적 기록을 제공합니다.

팀 전체에 걸쳐 적용 가능한 스마트 리팩토링 플랫폼은 이 기사의 검색 콘솔 데이터에 나타나는 검색어로, 리팩토링 워크플로에 규정 준수 검증을 통합하는 도구입니다. 즉, 리팩토링 패턴이 팀 전체에 일관되게 적용되고, 더 이상 사용되지 않는 인터페이스가 다시 도입되지 않으며, 구조적 변경이 조직 수준에서 정의된 아키텍처 표준을 준수하는지 확인합니다. 이러한 기능은 CI/CD 파이프라인만으로는 제공할 수 없는 수준으로, 변경되는 코드의 의미론적 의미까지 이해해야 합니다. 이는 단순히 빌드 및 테스트 통과 여부만 확인하는 것이 아닙니다.

다운타임 없이 메인프레임 및 CICS 리팩토링

메인프레임 환경은 구조적 제약 조건 때문에 무중단 리팩토링에 가장 까다로운 환경을 제공합니다. 예를 들어, CICS 트랜잭션 프로그램은 새로운 컨테이너 이미지를 배포하고 로드 밸런서를 전환하는 것만으로는 교체할 수 없습니다. CICS에서 프로그램을 교체하려면 NEWCOPY 또는 PHASEIN 명령어를 사용해야 하며, 이 명령어들은 프로그램의 새 버전을 메모리에 로드합니다. NEWCOPY는 이전 버전을 즉시 교체하므로, 명령어 실행 후 시작되는 모든 트랜잭션에 영향을 미칩니다. 반면 PHASEIN은 이전 버전을 사용하는 모든 활성 트랜잭션이 완료될 때까지 기다린 후 프로그램을 교체하므로, 장시간 실행되는 트랜잭션의 경우 더 깔끔한 전환이 가능합니다.

두 메커니즘 모두 즉각적인 롤백을 제공하지 않습니다. 새 버전의 프로그램에 결함이 있는 경우, 이전 버전으로 되돌리려면 이전 로드 모듈을 사용하여 NEWCOPY 또는 PHASEIN 명령을 다시 실행해야 합니다. 이를 위해서는 이전 로드 모듈이 로드 라이브러리에 보관되어 있어야 하며, 롤백 절차가 문서화되고, 연습되고, 원래 개발자 없이도 온콜 팀이 실행할 수 있어야 합니다.

공유 VSAM 파일은 추가적인 제약 조건을 발생시킵니다. 여러 CICS 트랜잭션과 배치 프로그램이 동일한 VSAM 파일에 동시에 접근할 수 있습니다. 레코드 세그먼트를 추가하거나 확장하는 등 파일 레이아웃을 구조적으로 변경해야 하는 경우, 레이아웃 변경 전 또는 변경과 동시에 파일에 접근하는 모든 프로그램을 업데이트하거나, 전환 기간 동안 파일이 여러 레코드 형식을 지원해야 합니다. 이는 메인프레임에서 확장-축소 패턴과 유사한 개념입니다. 즉, 전환 기간 동안 새 레이아웃은 기존 프로그램과 호환되어야 하며, 기존 레이아웃이 폐기되기 전에 기존 프로그램을 업데이트해야 합니다. 데이터셋 레이아웃과 프로그램 접근 매개변수의 제어된 확장은 파일 교체 없이 이러한 호환 가능한 공존을 가능하게 하는 메커니즘입니다.

배치 윈도우 제거 전략

기존 메인프레임 배치 처리 방식은 배치 윈도우라는 개념을 전제로 합니다. 배치 윈도우란 온라인 트랜잭션 처리가 중단되고, 배치 작업이 경쟁 없이 실행되며, 결과 데이터가 다음 온라인 처리 기간에 사용할 수 있도록 준비되는 기간을 말합니다. 진정한 무중단 운영을 위해서는 배치 윈도우를 없애야 하는데, 이는 배치 작업이 공유 데이터를 손상시키지 않고 온라인 트랜잭션과 동시에 실행될 수 있도록 배치 처리 모델을 재설계해야 함을 의미합니다.

표준적인 접근 방식으로는 파일 수준이 아닌 레코드 수준에서 리소스 수준의 잠금을 사용하는 것, 대규모 워크로드를 주기적으로 처리하는 대신 소규모 워크로드를 지속적으로 처리하는 이벤트 기반 미니 배치 처리, 그리고 쓰기 접근을 위해 온라인 트랜잭션 처리와 경쟁하지 않고 배치 보고 워크로드를 처리하는 읽기 복제 데이터베이스 등이 있습니다. 이러한 접근 방식들은 각각 프로그램과 데이터 접근 패턴 모두에 대한 변경을 필요로 하지만, 전환 과정 동안 배치 처리 창을 유지할 필요는 없습니다. 전환 자체는 다른 운영 시스템 리팩토링에 사용되는 것과 동일한 이중 실행 검증 방식을 사용하여 단계적으로 진행할 수 있습니다.

영향 분석을 활용한 COBOL 프로그램 리팩토링

COBOL 프로그램을 안전하게 리팩토링하려면 변경하기 전에 해당 프로그램을 호출하는 다른 프로그램이 무엇인지, 다른 프로그램과 공유하는 카피북이 무엇인지, 읽고 쓰는 데이터 세트가 무엇인지, 그리고 해당 프로그램이 생성하는 데이터에 의존하는 하위 시스템이 무엇인지 정확히 파악해야 합니다. 이러한 구조적 지식이 없으면 프로그램 변경 시 알 수 없는 위험이 발생합니다. 리팩토링된 프로그램이 파악되지 않은 호출자를 손상시키거나, 하위 시스템에서 구문 분석할 수 없는 형식의 출력을 생성하거나, 동일한 카피북을 사용하는 다른 프로그램에 영향을 미치는 방식으로 공유 데이터 구조를 수정할 수 있습니다.

자동화된 영향 분석은 리팩토링이 시작되기 전에 COBOL 프로그램의 완전한 종속성 그래프를 구성하여 이 문제를 해결합니다. 이 그래프는 모든 호출자, 모든 공유 카피북, 모든 데이터셋 접근, 그리고 모든 하위 프로그램 사용자를 관계 유형과 특정 참조 위치별로 정리하여 보여줍니다. 리팩토링 계획은 영향 그래프에서 도출됩니다. 변경된 프로그램을 호출하는 프로그램은 새 버전에 대해 테스트해야 하고, 수정된 카피북은 해당 카피북을 포함하는 모든 프로그램에 대해 유효성을 검사해야 하며, 변경된 데이터셋 레이아웃은 동일한 데이터셋에 접근하는 모든 프로그램에 대해 유효성을 검사해야 합니다. (설명 참조) 영향 분석 솔루션 IN-COM이 제공하는 이러한 기능은 배포 후에 그 결과를 발견하는 리팩토링 프로그램과 배포 전에 그 결과를 정량화하는 프로그램의 차이를 만들어냅니다.

검증, 롤백 및 관찰 가능성

무중단 리팩토링은 지속적인 모니터링이 필요한 연속적인 결과물을 생성합니다. 이 모니터링은 모든 것이 제대로 작동했는지 사후적으로 확인하는 것이 아니라, 배포 프로세스의 모든 단계에서 능동적으로 작동하는 검증 절차이며, 사용자에게 미치는 영향을 방지하기 위해 문제를 조기에 감지하는 주요 메커니즘입니다.

무중단 리팩토링을 위한 검증 모델은 세 가지 계층으로 구성됩니다. 첫 번째는 합성 모니터링입니다. 이는 사용자 행동을 시뮬레이션하고 프로덕션 환경에서 지속적으로 실행되는 스크립트 트랜잭션으로, 주요 흐름이 성공적으로 완료되는지 검증합니다. 합성 모니터는 실제 사용자가 트래픽이 적은 기간 동안 실행하지 않을 수 있는 특정 코드 경로에서 발생하는 오류를 포착하고, 카나리 테스트 결과와 비교할 수 있는 기준 동작을 제공합니다.

두 번째 단계는 차분 모니터링입니다. 이는 오류율, 지연 시간 분포, 비즈니스 지표, 리소스 사용량 등 카나리 배포와 기준 배포 간의 다양한 지표를 실시간으로 비교하는 것입니다. 차분 모니터링은 절대적인 임계값을 필요로 하지 않고 상대적인 비교를 통해 이루어집니다. 카나리 배포에서 기준 배포보다 오류율이 2% 더 높게 나타난다면, 절대 오류율이 개별적으로 정의된 임계값을 초과하는지 여부와 관계없이 문제가 있는 것으로 간주됩니다.

세 번째 단계는 데이터 일관성 검증입니다. 이중 쓰기, 스키마 마이그레이션 또는 병렬 시스템 실행을 포함하는 모든 리팩토링 작업에서 기존 표현과 새로운 표현 간의 데이터 일관성을 지속적으로 검증해야 합니다. 체크섬 비교, 레코드 수 비교, 특정 필드 값을 예상 변환과 비교하여 검증하는 스팟 체크 쿼리는 모두 전환 과정에서 데이터 계층이 올바르게 작동하고 있음을 확신하는 데 기여합니다. 이러한 맥락에서 살펴보겠습니다. 영향 분석이란 무엇이며 왜 중요한가?구조적 리팩토링은 예측 불가능한 변경과 달리, 정의된 기대치에 비추어 변경의 결과를 검증할 수 있다는 점에서 차별화됩니다.

즉각적인 롤백 메커니즘

실행하는 데 30분이 걸리는 롤백 계획은 시스템 다운타임이 전혀 발생하지 않는 롤백 계획이 아닙니다. 롤백이 완료될 때쯤이면 이미 사용자에게 30분 동안 품질이 저하된 서비스가 제공되었기 때문입니다. 즉각적인 롤백을 위해서는 모든 배포가 처음부터 복구 가능하도록 설계되어야 하며, 문제가 발생한 후에 사후적으로 수정해서는 안 됩니다.

애플리케이션 배포에서 즉시 롤백이란 이전 배포 아티팩트를 그대로 유지하고, 미리 준비된 상태로 동일한 데이터베이스 상태를 가리키도록 하는 것을 의미합니다. 로드 밸런싱을 통한 트래픽 전환이나 API 게이트웨이 규칙 변경만으로 이전 버전으로 되돌릴 수 있어야 합니다. 이는 데이터베이스 상태가 이전 버전과 하위 호환될 때 가능하며, 데이터베이스 마이그레이션 계층에서 확장-축소 원칙을 적용함으로써 보장됩니다.

데이터베이스 마이그레이션에서 즉시 롤백을 구현하려면 확장 단계에서 적용된 모든 마이그레이션이 데이터 손실 없이 되돌릴 수 있어야 합니다. 확장 단계에서 추가된 열은 롤백 시 삭제할 수 있습니다. 하지만 파괴적인 방식으로 수정된 열은 백업 없이는 복원할 수 없습니다. 따라서 열을 삭제하거나, 호환되지 않는 방식으로 데이터 유형을 변경하거나, 정밀도를 낮추는 등의 파괴적인 스키마 변경은 새 버전이 완전히 배포 및 검증되고 이전 버전이 완전히 폐기될 때까지 절대 적용해서는 안 됩니다.

방법 SMART TS XL 시스템 다운타임이 없는 리팩토링 프로그램을 지원합니다.

SMART TS XL 이 플랫폼은 모든 무중단 리팩토링 실패의 근본 원인인 구조적 가시성 문제를 해결합니다. 즉, 팀이 시스템 구성 요소, 요소 간 상호 의존 관계, 그리고 계획된 변경 사항의 결과에 대한 완전한 정보 없이 운영 중인 시스템을 리팩토링하려고 시도하는 문제를 해결합니다. 이 플랫폼은 COBOL, JCL, Java, .NET, Python, JavaScript, SQL을 포함하여 환경 내 모든 언어 및 플랫폼의 소스 코드를 수집하고 전체 시스템의 구조적 관계를 나타내는 통합 상호 참조 모델을 구축합니다.

리팩토링 변경을 하기 전에, SMART TS XL이 기능의 영향 분석은 변경 대상 구성 요소에서 시작하여 모든 호출자, 공유 데이터 구조, 하위 시스템 사용자, 그리고 변경 사항의 영향을 받는 모든 프로그램에 이르기까지 종속성 그래프를 추적합니다. 그 결과는 일반적인 위험 평가가 아닌, 심각도와 구성 요소별로 정리된 구체적인 결과 목록입니다. 이 목록을 통해 다운타임 없는 리팩토링 순서를 정확하게 계획할 수 있습니다. 즉, 변경된 구성 요소를 배포하기 전에 어떤 사용자를 업데이트해야 하는지, 어떤 데이터베이스 마이그레이션을 어떤 애플리케이션 배포 전에 수행해야 하는지, 그리고 이전 버전을 폐기하기 전에 어떤 하위 시스템을 검증해야 하는지를 파악할 수 있습니다.

SMART TS XL이 도구의 코드 시각화 기능은 시스템의 모든 계층에 대한 깊은 이해가 없는 팀도 의존성 그래프를 쉽게 탐색할 수 있도록 해줍니다. 아키텍트는 연결 구조를 재설계하기 전에 구성 요소들이 어떻게 연결되는지 확인할 수 있습니다. 개발자는 함수의 시그니처를 변경하기 전에 어떤 함수가 해당 함수를 호출하는지 알 수 있습니다. 운영팀은 데이터셋의 레이아웃을 수정하기 전에 어떤 곳에서 데이터셋이 사용되는지 확인할 수 있습니다. 이러한 가시성은 시스템 중단 없는 운영에 필수적인 구조화되고, 되돌릴 수 있으며, 단계별로 진행되는 리팩토링 프로그램의 전제 조건입니다.

다운타임 없는 리팩토링을 지속적인 실천으로 구현하기

이 가이드에 소개된 기법들은 일회성 개입이 아닙니다. 이는 운영 시스템을 주기적으로 교체하는 것이 아니라 지속적으로 진화시키는 시스템으로 관리하기로 결정한 개발 조직의 운영 용어입니다. 블루-그린 배포, 카나리 릴리스, 기능 토글, 확장-축소 마이그레이션, 스트랭글러 피그 추출, 멱등 이벤트 처리, 파이프라인 기반 배포 게이트는 비상 절차가 아니라, 구조적 변경 사항을 안전하게 고빈도로 배포하는 팀의 표준 운영 절차입니다.

그러한 상태에 도달하려면 개별적인 리팩토링 이니셔티브를 넘어 도구, 인프라 및 조직 관행에 대한 투자가 필요합니다. 도구는 독립적인 배포, 관찰 가능한 상태 전환 및 즉각적인 롤백을 지원해야 합니다. 인프라는 트래픽 분할, 블루-그린 환경 및 CDC 기반 데이터 동기화를 지원해야 합니다. 조직 관행에는 배포 전 영향 분석, 배포 후 차이 모니터링, 그리고 실제 조건에서 롤백 경로가 제대로 작동하는지 확인하는 정기적인 롤백 연습이 포함되어야 합니다.

이러한 투자를 하는 조직은 관행이 성숙해짐에 따라 변경당 비용이 감소하는 것을 발견합니다. 지원 인프라가 이미 구축되어 있고, 팀이 어떤 변경에 어떤 게이트 임계값이 적절한지에 대한 판단력을 개발했으며, 도구에 대한 구조적 지식이 축적되었기 때문에 각 리팩토링은 이전보다 위험도가 낮아집니다. SMART TS XL 각 계획된 변경 사항을 이전 변경 사항보다 더 정확하게 범위가 지정되도록 합니다. 무중단 리팩토링의 목표는 단 하나의 변경 사항을 안전하게 적용하는 것이 아닙니다. 사용자에게 유지보수 기간을 요청하지 않고 모든 변경 사항을 안전하고 지속적으로 적용하는 것입니다.