적절한 계획 및 거버넌스는 현대화에 매우 중요합니다. 이 단계에서는 적용할 현대화 접근 방식과 이를 수행하는 방법을 결정합니다. 신중한 계획은 실행 중에 예산 초과, 범위 크리프 또는 서비스 중단 가능성을 줄입니다.
현대화 전략 선택
워크로드를 현대화한다는 것은 현재 비즈니스 목표, 기술 표준 및 클라우드 기능에 더 잘 맞게 워크로드를 업데이트하는 것을 의미합니다. 복잡성과 가치의 연속체에는 세 가지 기본 전략(다시 배치, 리팩터링 및 다시 아키텍처)이 있습니다. 대부분의 현대화 작업은 이러한 접근 방식의 조합을 사용합니다.
핵심은 목표, 타임라인 및 사용 가능한 리소스를 고려하여 각 구성 요소의 특정 요구 사항에 전략을 일치시키는 것입니다. 지나치게 현대화하려는 유혹을 피하십시오. 새로운 기술은 흥미롭지만 모든 결정은 비즈니스 가치에 기반을 두어야 합니다.
| 현대화 전략 | Definition | 사용 시기 | Pros | Cons |
|---|---|---|---|---|
| 플랫폼 전환 | 최소한의 코드 변경으로 애플리케이션을 클라우드 플랫폼으로 이동합니다(IaaS에서 PaaS로). | 최소한의 중단이 필요한 빠른 승리. 현재 코드는 작동하지만 작업 부담이 높습니다. | 빠른 구현. 유지 관리 작업을 줄입니다. 더 나은 인프라를 통해 안정성을 향상시킵니다. | 제한된 기능 향상. 핵심 애플리케이션은 변경되지 않습니다. |
| Refactor | 기능을 유지하면서 기존 코드를 수정하여 구조, 성능 및 클라우드 최적화를 개선합니다. | 기술적인 문제로 인해 문제가 발생하거나 코드가 클라우드에 최적화되지 않습니다. | 유지 관리 효율성, 성능 및 보안을 향상시킵니다. 향후 향상된 기능을 더 쉽게 사용할 수 있습니다. | 상당한 개발자 노력과 테스트가 필요합니다. 사용자에 대한 즉각적인 새 기능이 없습니다. |
| Rearchitect | 클라우드 네이티브 패턴(마이크로 서비스, 서버리스, 이벤트 기반)을 사용하여 애플리케이션 아키텍처를 다시 디자인합니다. | 현재 아키텍처는 증가 또는 클라우드 최적화를 제한합니다. | 기본적인 확장성 문제를 해결합니다. 고급 클라우드 서비스를 사용하도록 설정합니다. 장기적인 혁신을 위한 토대를 설정합니다. | 가장 복잡하고 시간이 많이 소요됩니다. 높은 선행 비용 및 위험. 광범위한 테스트 및 병렬 작업이 필요합니다. |
단계별 현대화 계획
한 번의 작업으로 전체 복잡한 워크로드(또는 여러 워크로드)를 현대화하는 것은 위험합니다. 작업을 논리적 단계로 나타 둡니다. 단계적으로 사용하면 증분 값을 제공하고, 관리 가능한 청크를 처리하여 위험을 줄이고, 학습한 내용에 따라 단계 간 과정을 조정할 수 있습니다.
현대화를 논리적 단계로 나눕니다. 작업을 분할하는 방법을 결정합니다. "올바른 방법"은 하나도 없습니다. 아키텍처 및 팀 구조에 적합한 분석을 선택합니다. 목표는 각 단계가 압도적인 복잡성 없이 실행 및 테스트할 수 있을 만큼 작지만 가치를 제공할 만큼 의미가 있다는 것입니다. 단계를 세분화하는 일반적인 방법:
나누기 방법 Description Example 구성 요소 또는 계층별 워크로드 계층 또는 워크로드 경계에 따라 별도의 단계 1단계: 데이터베이스 마이그레이션, 2단계: 애플리케이션 리팩터링, 3단계: UI 현대화 우선 순위 및 복잡성별 저위험에서 고위험 변경으로 작업 구성 1단계: 비임계 서비스, 2단계: 핵심 비즈니스 논리, 3단계: 고객 관련 기능 비즈니스 기능별 애플리케이션 또는 기능 경계를 둘러싼 구조 단계 1단계: 사용자 관리 워크로드, 2단계: 결제 처리, 3단계: 보고 서비스 위험 수준이 낮고 값이 높은 변경으로 시작합니다. 1단계의 경우 달성 가능한 항목을 선택하고 실질적인 승리를 제공하지만 문제가 발생할 경우 비즈니스를 위험에 빠뜨리지 않습니다. 예를 들어 고객 관련 웹 사이트가 아닌 백 엔드 서비스 또는 내부 도구를 먼저 현대화합니다. 첫 번째 단계를 증명 포인트로 빠르게(한두 달) 완료하는 것을 목표로 합니다. 초기 성공은 후속 단계에 대한 팀 신뢰도 및 관련자 지원을 구축합니다.
값 및 종속성별 나머지 단계 시퀀스입니다. 첫 번째 단계 후에는 비즈니스 가치 및 기술 종속성에 따라 후속 단계의 순서를 계획합니다. 각 단계에 정의된 범위가 있고 중요한 구성 요소의 지원 요소가 이미 현대화되거나 호환되도록 하는 로드맵을 빌드합니다.
- 취약한 영역을 해결합니다. 워크로드가 현재 상태에서 취약한 경우 1단계에서 현대화하는 것이 안전하도록 현재 위치에서 안정화하기 위해 예비 "0단계"가 필요할 수도 있습니다(이전 환경에서 긴급 수정 적용).
- 먼저 선결 조건을 해결하십시오: 워크로드 B의 현대화가 워크로드 A의 현대화(또는 적어도 안정적인 상태)에 달려 있는 경우, 워크로드 A를 먼저 수행하십시오.
- 비즈니스 가치와 위험 비교를 고려합니다 . 팀에 대한 부하와 비즈니스에 대한 위험의 균형을 맞추기 위해 한 단계에서는 높지만 위험한 부분을 번갈아 가며, 다음 단계에서는 위험 수준이 낮은 부분을 수행하도록 결정할 수 있습니다.
각 단계에 대한 성공 조건을 정의합니다. 각 단계에 대해 완료되고 성공적인 시기를 결정합니다. 명확한 종료 기준을 설정하면 단계에서 범위 확장이 방지됩니다. 성공 조건에는 다음이 포함될 수 있습니다.
성공 조건 유형 Examples 기술 목표 • Service X는 Azure App Service에서 실행되고 20개% 더 많은 부하를 처리합니다.
• 데이터베이스 Y는 이전 기준보다 10% 이내의 데이터 손실 및 성능이 없는 Azure SQL로 마이그레이션합니다.품질 게이트 • Sev-1 버그가 열리지 않음
• 모든 자동화된 테스트 통과
• 보안 검사에서 중요한 취약성이 전혀 표시되지 않습니다.타이밍 및 예산 제약 조건 • 3개월 이내에 완료되며 예산의 5% 이내
• 예약된 유지 관리 기간 동안 배포결과에 따라 계획을 조정합니다. 단계를 완료한 후 학습된 결과 및 단원을 검토합니다. 일부 가정이 잘못되었거나 일부 작업이 예상보다 더 쉽거나 어려웠을 수 있습니다. 단계 추가, 결합 또는 재지정과 같은 향후 단계에 대한 계획을 적절하게 조정합니다. 단계별 접근 방식은 유연해야 합니다. 중요한 것은 모든 것을 한 번에 시도하는 것이 아닙니다.
현대화 거버넌스 계획
현대화는 중요한 워크로드에 중요한 변경 사항을 도입하는 경우가 많으므로 위험을 관리하려면 강력한 거버넌스가 필요합니다. 현대화 거버넌스에는 변경 관리 프로세스, 동결 및 제어 범위가 포함됩니다.
공식적인 변경 승인 워크플로를 설정합니다. 모든 현대화 관련 변경 내용에 대한 구조적 승인 프로세스를 정의합니다. 기존 CAB(변경 자문 위원회)와 통합하거나 전용 현대화 검토 보드를 만듭니다. 변경 범주에 따라 승인 기관을 할당하고 프로젝트 계획의 전체 워크플로를 문서화합니다. 자세한 내용은 변경 관리를 참조하세요.
필요한 경우 변경 내용을 고정합니다. 주요 배포 이벤트 전후에 해당 워크로드의 다른 변경 내용을 중지합니다. 변경이 중단되면 리드업 및 배포 중에 해당 워크로드에 관련 없는 다른 변경이 수행되지 않습니다. 환경을 안정화하여 변동이 심한 목표를 피할 수 있도록 합니다. 동결 기간을 모든 관련 팀에 전달합니다.
범위 확장 방지 스코프 크리프는 현대화 프로젝트에서 주요 도전 과제입니다. 평가 및 승인 단계를 진행하려면 합의된 현대화 범위에 대한 제안된 변경이 필요합니다. 대부분의 요청은 중요하지 않은 한 연기되어야 합니다. 프로세스를 사용하여 추가 작업을 수행하도록 "아니요, 지금이 아님"을 공식화합니다. 현재의 현대화가 완료되면 미래의 혁신 프로젝트에 공급할 수 있는 좋은 아이디어의 백로그를 유지 관리합니다. 이해 관계자는 자신의 아이디어가 손실되지 않는다는 것을 알아야합니다.
배포 전략 정의
중요한 실행 결정은 현대화된 구성 요소를 프로덕션으로 롤아웃하는 방법입니다. 두 가지 주요 전략이 있습니다. 현재 위치 배포에서는 기존 설정을 업그레이드합니다(예: 집에 거주하는 동안 주택 개조). 병렬 배포에서는 함께 새 설치 프로그램을 빌드합니다(예: 새 주택 건설, 입주 등). 각 단계 또는 워크로드에 대한 변경 및 위험 허용 오차 수준에 맞는 전략을 선택합니다. 종종 현대화의 각 단계에서 다른 전략을 사용할 수 있습니다. 예를 들어 1단계(사소한 변경인 경우)에 대한 현재 위치와 2단계에 대한 병렬(주요 데이터베이스 정비가 포함된 경우)을 선택할 수 있습니다.
위험 수준이 낮고 되돌릴 수 있는 변경에는 현재 위치 배포를 사용합니다. 현장 배포는 유지 관리 기간 동안 현재 프로덕션 환경에 직접 변경 내용을 도입할 수 있습니다. 이 전략은 인프라 오버헤드를 최소화하지만 가동 중지 시간 위험을 증가합니다. 변경 내용이 작고 격리되어 쉽게 되돌릴 수 있는 경우에만 현재 위치 배포를 사용합니다. 예를 들어 소스 제어 또는 백업을 사용하여 신속하게 롤백할 수 있는 부 코드 업데이트 또는 스키마 변경이 있습니다.
복잡하거나 위험 수준이 높은 변경에 병렬 배포를 사용합니다. 이 모델에서는 이전 워크로드가 계속 실행되는 동안 현대화된 워크로드에 대한 새 환경을 설정합니다. 데이터가 복제 또는 마이그레이션 프로세스를 통해 동기화된 상태로 유지되므로 준비가 되면 이전 환경에서 새 환경으로 전환할 수 있습니다. 가동 중지 시간을 최소화해야 하는 복잡하거나 위험 수준이 높은 변경에 사용합니다. 주요 데이터베이스 마이그레이션 또는 새 인프라를 포함하는 다시 설계를 수행하는 경우 병렬이 일반적으로 그 방식입니다. 또한 워크로드가 중요 업무용이고 몇 분 이상의 가동 중지 시간을 가질 수 없는 경우 병렬(복제 및 빠른 중단 포함)이 필요합니다.
Strategy Description 사용 시기 Pros Cons 직접 배포 현재 프로덕션 환경에 직접 변경 내용 배포 유지 관리 허용 범위 내에서 작고 되돌릴 수 있는 변경 사항 중복 인프라 없음, 더 빠른 배포 위험이 높고 가동 중지 시간이 필요하고 롤백 속도가 느려집니다. 병렬 배포 전환 중에 기존 워크로드와 함께 새 환경 실행 복잡한 변경, 최소한의 가동 중지 시간이 필요한 중요 업무용 워크로드 보다 안전한 배포, 거의 0에 가까운 가동 중지 시간, 즉각적인 대체 중복 인프라 비용, 복잡한 데이터 동기화, 서비스 해제 작업
현대화 위험 완화 계획
최고의 계획과 테스트가 있더라도 모든 변화가 완벽하게 진행되는 것은 아닙니다. 현대화에는 종종 복잡한 변경이 수반되며, 배포에서 문제가 발생하거나 프로덕션에서 예기치 않게 동작할 위험이 항상 있습니다. 준비가 잘 된 팀의 특징은 각 변경 또는 단계에 대한 견고한 롤백 계획을 가지고 있다는 것입니다.
점진적 배포 기술을 사용합니다. 플랫폼이 허용하는 경우, 카나리아 릴리스 또는 점진적으로 트래픽을 애플리케이션의 현대화된 부분으로 전환하십시오. 예를 들어 새 버전을 이전 버전과 함께 배포하고, 모니터링하는 동안 처음에는 5%의 사용자만 새 버전으로 보냅니다. 이 방법은 대부분의 사용자가 영향을 받지 않는 동안 문제를 발견할 수 있습니다. 메트릭이 좋으면 %50까지 증가하고, 그 다음에는 %100까지 증가합니다. 문제가 발생하면 신속하게 0% 새 상태(롤백)로 되돌립니다.
모든 주요 변경 내용에 대한 롤백 프로시저를 만듭니다. 모든 주요 변경 또는 단계 결과물에 대해 단계별 롤백 절차를 작성합니다. 변경을 실행 취소할 각 작업, 각 단계를 담당하는 사용자 및 소요 시간을 명확하게 나열합니다. 롤백 후 정상으로 돌아왔음을 확인하는 데 필요한 검사 항목을 포함하세요.
가능한 경우 롤백을 자동화합니다. 자동화된 롤백 스크립트 또는 코드로서의 인프라는 복구를 빠르고 안정적으로 만들 수 있습니다. 코드로서의 인프라 도구(Terraform, ARM 템플릿, Bicep)를 사용하여 알려진 양호한 상태를 다시 배포합니다. 청록색 또는 카나리아 배포는 기본적으로 필요한 경우 이전 버전으로 "다시 전환"을 허용합니다. 스테이징에서 이러한 메커니즘을 테스트합니다. 목표는 수동 작업(인시던트 발생 시 오전 3시)을 스크립트된 작업으로 줄이는 것입니다. 배포 단계와 함께 롤백 단계를 작성하므로 쉽게 롤백할 수 있습니다.
배포 중 및 배포 후 지원이 대기 중입니다. 가능한 경우 트래픽이 적은 기간(주말 또는 하룻밤) 동안 배포를 계획하지만 관련 전문가를 사용할 수 있는지 확인합니다. 주요 팀원이 휴가 중일 때는 하지 마세요. 개발자와 함께 배포한 직후에 연장된 지원(하이퍼케어) 기간을 가지며 대기 중인 작업을 통해 문제를 조기에 파악할 수 있습니다. 주요 시스템 출시의 경우, 일부 조직은 24-48시간 동안 집중 모니터링을 실시합니다.
관련자 승인 보호
이 시점까지는 기술 계획에 집중했습니다. 동일하게 중요한 것은 비즈니스 및 기술 리더십의 이해관계자로부터 지지를 얻는 것입니다. 현대화에는 상당한 투자가 필요한 경우가 많으므로 매력적인 사례를 제시하고 이해 관계자를 계속 참여시켜야 합니다.
각 대상에 맞게 가치 제안을 조정합니다. 이해 관계자가 서로 다른 결과를 중요하게 생각하고 있습니다. 메시징 사용자 지정:
- 기술 팀은 운영 효율성( 유지 관리 감소, 가동 시간 향상 및 에스컬레이션 감소)을 우선 순위로 지정합니다.
- 비즈니스 리더는 더 빠른 출시 시간, 향상된 고객 환경 및 비용 절감과 같은 결과에 초점을 맞춥니다.
중요 시점을 사용하여 구조화된 계획을 문서화합니다. 이해 관계자는 명확한 로드맵을 볼 경우 더 편안합니다. 앞에서 결정한 대로 계획한 단계와 각 단계가 달성해야 하는 작업을 대략적인 타임라인으로 제시합니다. "6주 이내에 X 구성 요소를 현대화하고 성능을 20%향상하는 것을 목표로 합니다."와 같은 조기 승리를 강조합니다.
현대화 값을 정량화합니다. 몇 가지 전후 메트릭 및 대상 개선 사항을 준비합니다. 메트릭 및 일반적인 개선 범위의 예(업계 벤치마크 기준)는 다음과 같습니다.
Category 예제 메트릭 일반적인 값 범위 비용 절감 인프라, 유지 관리, 라이선스 20-40% 연간 절감액 생산성 향상 배포 빈도, 해결 시간 50-80% 개선 위험 완화 가동 중지 시간 방지, 보안 사고 예방 $100K-$ 1M+ 비용 회피 Revenue 더 빠른 출시 시간, 고객 보존 10-25% 수익 가속화 프로젝트 위험을 해결합니다. 잠재적인 문제를 식별하고 특정 완화 전략을 통해 준비 상태를 보여 줍니다. 일반적인 위험에는 데이터 복제, 성능 저하 및 통합 문제가 포함됩니다. 자동화된 롤백 절차, 포괄적인 테스트 프로토콜 및 전문가 상담 가용성과 같은 솔루션을 제공합니다. 투명한 위험 토론은 프로젝트 리더십 및 계획 철저성에 대한 이해 관계자의 신뢰를 구축합니다.
정기적인 통신 주기를 유지합니다. 정의된 성공 조건에 대해 진행 상황을 보고하고, 완료된 결과물을 강조 표시하고, 예정된 중요 시점을 전달합니다. 적극적으로 피드백을 요청하고 문제를 해결하여 현대화 프로세스 전반에 걸쳐 지원을 유지합니다.