비즈니스 연속성 계획은 위기 상황이 아니라 위기 발생 전 평가 단계에서 실패하는 경우가 가장 많습니다. 조직은 비즈니스 영향 분석을 완료하고, 복구 시간 목표(RTO)를 문서화하고, 포괄적인 복구 플레이북을 구축하지만, 최악의 순간에 겉보기에는 중요하지 않아 보이는 기존 인증 서비스가 전체 전자상거래 플랫폼의 단일 장애 지점이라는 사실, 모두가 우선순위가 낮다고 생각했던 COBOL 배치 프로그램이 실시간 결제 검증 서비스에 데이터를 제공하고 있다는 사실, 또는 동일한 복구 계층이 지정된 두 애플리케이션 사이에 문서화되지 않은 종속성이 있어 순차적 복구가 불가능하다는 사실을 발견하게 됩니다. 평가는 완료되었지만, 종속성은 파악되지 않은 것입니다.
애플리케이션 중요도 점수 산정은 조직 포트폴리오 내 각 애플리케이션에 정량적 또는 계층적 중요도 척도를 부여하는 프로세스입니다. 이 척도는 애플리케이션의 복구 우선순위, 이중화 투자 수준, 변경 관리 요구 사항 및 재해 복구 순서에서의 위치를 결정합니다. 비즈니스 영향 설문 조사와 애플리케이션 소유자 인터뷰에만 기반한 점수 산정은 사람들이 애플리케이션의 기능에 대해 가지고 있는 인식만을 반영합니다. 하지만 애플리케이션의 실제 기능, 누가 누구를 호출하는지, 어떤 데이터가 어떤 프로그램을 통해 흐르는지, 여러 우선순위가 높은 시스템의 중요 경로에 어떤 공유 구성 요소가 있는지 등에 대한 구조적 분석을 기반으로 할 때, 비로소 운영 현실을 반영하게 됩니다.
믿음과 현실 사이의 간극이 바로 비즈니스 연속성 계획이 실패하는 지점입니다.
애플리케이션 중요도 점수는 실제로 무엇을 측정하는가?
중요도는 단일한 차원이 아닙니다. 기업 애플리케이션의 중요도 점수를 결정하기 위해서는 전략적 비즈니스 요구사항에 미치는 영향, 비즈니스 파트너에 미치는 영향, 고객 상호작용, 그리고 다른 기업 애플리케이션에 미치는 영향 등 사용자의 의견을 종합적으로 고려하여 애플리케이션의 중요도를 평가할 수 있습니다. 이러한 각 차원은 "중요하다"는 것의 다양한 측면을 나타냅니다.
비즈니스 영향 이란 조직이 시스템 다운 시간당 잃는 손실을 의미합니다. 매출 손실은 가장 눈에 띄는 부분입니다. 시간당 1천만 달러를 처리하는 결제 처리 시스템의 경우, 시스템 장애 1분당 발생하는 비용은 수치화할 수 있습니다. 하지만 비즈니스 영향은 매출 손실뿐만 아니라 규제 준수 의무(시스템 장애로 인해 어떤 법규 준수 의무가 발생하는가?), 평판 손상(고객에게 직접적인 영향을 미치는가?), 계약상 위약금(서비스 수준 계약(SLA)에 따라 위약금 조항이 발생하는가?) 등 다양한 측면을 포함합니다.
운영상 의존성은 다른 시스템이나 프로세스가 이 애플리케이션에 얼마나 의존하는지를 나타냅니다. 직접적인 비즈니스 영향은 낮더라도, 다른 애플리케이션과의 의존 관계 경로에 위치하여 직접적인 영향이 큰 애플리케이션과 연결되어 있다면 중요도가 높을 수 있습니다. 모든 고객 대면 애플리케이션에 필수적인 인증 서비스는 그 기능 자체의 중요성보다 훨씬 더 높은 비중을 차지합니다.
복구 복잡성은 애플리케이션을 복원하는 데 얼마나 어렵고 시간이 많이 걸리는지를 나타냅니다. 비즈니스 영향이 중간 정도이고 복구 시간이 48시간인 애플리케이션은 비즈니스 영향이 크고 복구 시간이 2시간인 애플리케이션보다 전체 다운타임 위험이 더 크기 때문에 이중화에 더 많은 투자가 필요할 수 있습니다.
규제 의무는 애플리케이션이 규제 연속성 요건의 적용을 받는다는 것을 의미합니다. DORA(디지털 권리 보호법)의 적용을 받는 금융 기관은 중요 기능이 특정 장애 시나리오에서도 유지될 수 있음을 입증해야 합니다. HIPAA(미국 의료정보 보호법)의 적용을 받는 의료 기관은 보호 대상 의료 정보가 포함된 시스템의 가용성을 보호해야 합니다. 특정 애플리케이션의 경우 규제적 측면이 비즈니스 영향 평가보다 우선시될 수 있습니다.
중요도 점수는 조직의 특정 위험 허용 수준, 규제 환경 및 비즈니스 모델에 따라 가중치가 부여된 네 가지 차원의 종합적인 결과입니다.
표준 중요도 등급
대부분의 기업 애플리케이션 포트폴리오는 4단계 중요도 모델을 사용합니다. 애플리케이션 중요도 매트릭스의 중요도 범주는 미션 크리티컬, 비즈니스 크리티컬, 비즈니스 운영 및 관리로 구성됩니다. 아래 정의는 ISO 22301(비즈니스 연속성 관리 시스템) 및 비즈니스 연속성 연구소(BCI)의 모범 사례 지침에 부합하는 현재 업계 관행을 반영합니다.
1등급 핵심 임무 애플리케이션은 장애 발생 시 즉시 핵심 비즈니스 운영이 중단되거나 허용할 수 없는 규제 또는 안전 위험을 초래합니다. 복구 시간 목표(RTO): 일반적으로 0~4시간. 복구 시점 목표(RPO): 일반적으로 0~1시간. 예: 핵심 은행 거래 처리, 실시간 거래 시스템, 긴급 출동 시스템, 산업 제어 인터페이스, 결제 승인 시스템. 이러한 애플리케이션에는 최고 수준의 인프라 투자가 필요합니다. 즉, 액티브-액티브 이중화, RPO가 0인 복제, 자동 장애 조치, 그리고 가장 엄격한 변경 관리가 요구됩니다.
2단계는 비즈니스 운영에 심각한 지장을 초래하지만 즉시 중단시키지는 않는 비즈니스 핵심 애플리케이션입니다. 복구 시간 목표(RTO): 일반적으로 4~24시간. 복구 시점 목표(RPO): 일반적으로 1~4시간. 예시: CRM 시스템, ERP 모듈, 주문 관리 시스템, 급여 지급 기간의 인사 시스템, 규제 제출 기간의 보고 시스템. 이러한 애플리케이션에는 고가용성 인프라, 정기적인 장애 조치 테스트, 우선순위 복구 순서가 필요합니다.
3단계는 비즈니스 운영을 지원하는 비즈니스 운영 애플리케이션으로, 일시적인 장애 발생 시 수동 해결 방법을 통해 관리할 수 있습니다. 복구 시간 목표(RTO): 일반적으로 24~72시간. 복구 시점 목표(RPO): 일반적으로 4~24시간. 예: 내부 협업 도구, 고객에게 공개되지 않는 보고서, 관리 포털, 교육 플랫폼. 표준 백업 및 복구 절차를 적용하는 것이 적합합니다.
4단계, 운영에 직접적인 영향을 미치지 않는 관리 기능을 지원하는 관리 애플리케이션. 복구 시간 목표(RTO): 일반적으로 72시간 이상. 복구 시점 목표(RPO): 24시간 이상 또는 마지막 백업 시점. 예: 내부 문서 위키, 필수적이지 않은 개발 도구, 이력 보고서. 필요에 따라 백업에서 복원합니다.
등급 지정은 영구적이지 않습니다. 연중 대부분 기간 동안 3등급인 애플리케이션도 월말 재무 결산, 규제 보고 기간 또는 거래 성수기에는 2등급으로 변경될 수 있습니다. 운영 일정에 따라 등급 지정이 변경되는 동적 중요도 관리는 성숙한 BCP 프로그램을 갖춘 조직이 기본 등급 구조를 설정한 후 구현하는 개선 사항입니다.
점수 산정 방법론: 차원을 숫자로 변환하기
체계적인 평가 방법론은 네 가지 중요도 차원을 수치 점수로 변환하여 조직 내 정치적 고려가 아닌 객관적인 기준으로 등급을 배정합니다. 아래 접근 방식은 가중 기준을 사용하여 0~100점 범위의 종합 점수를 산출합니다.
차원 1: 사업적 영향 (가중치: 35%)
| 가동 중단 시간당 수익 영향 | 점수 |
|---|---|
| 시간당 1만 달러 이상 | 35 |
| 시간당 1만 달러~100만 달러 | 28 |
| 시간당 10달러~100달러 | 21 |
| 시간당 1달러~10달러 | 14 |
| 시간당 1달러 미만 | 7 |
| 직접적인 수익 영향 없음 | 0 |
규제 영향(DORA, HIPAA, PCI-DSS, SOX 준수 의무 등 장애로 인해 발생하는 규정 준수 의무)은 이 항목에 10점을 추가합니다.
차원 2: 운영 의존성 (가중치: 30%)
| 팬인: 이 애플리케이션에 의존하는 애플리케이션 | 점수 |
|---|---|
| 종속 애플리케이션 20개 이상 | 30 |
| 10-20개의 종속 애플리케이션 | 24 |
| 5-9개의 종속 애플리케이션 | 18 |
| 2-4개의 종속 애플리케이션 | 12 |
| 1개의 종속 애플리케이션 | 6 |
| 부양가족 없음 (단독 소유) | 0 |
여기서 팬인 카운트는 구조적 의존성, 즉 이 애플리케이션을 호출하거나, 출력을 읽거나, 데이터에 의존하는 애플리케이션의 수를 나타내는 것이지 사용자 수나 인지된 중요도를 나타내는 것이 아닙니다. 애플리케이션 소유자가 모든 하위 사용자들을 알지 못하기 때문에 설문 조사에서 가장 자주 잘못 계산되는 부분이 바로 이 팬인 카운트입니다.
차원 3: 복구 복잡성 (가중치: 20%)
| 사전 구축된 재해 복구(DR) 없이 예상 복구 시간 | 점수 |
|---|---|
| > 72 시간 | 20 |
| 24-72 시간 | 16 |
| 8-24 시간 | 12 |
| 2-8 시간 | 8 |
| 2 시간 미만 | 4 |
| 자동 장애 조치 (15분 미만) | 0 |
차원 4: 데이터 민감도 및 규제 의무 (가중치: 15%)
| 데이터 분류 및 규제 요건 | 점수 |
|---|---|
| 명확한 복구 시간 의무가 있는 규제 대상 개인 식별 정보/개인 건강 정보/인간 건강 정보 | 15 |
| 복구 시간 의무가 없는 규제 대상 데이터 | 12 |
| 민감한 내부 데이터(영업 비밀, 재무 기록) | 9 |
| 내부 운영 데이터 | 6 |
| 민감하지 않은 내부 데이터 | 3 |
| 데이터가 저장되지 않았습니다 | 0 |
종합 점수를 등급별로 매핑:
| 종합 점수 | 티어 할당 |
|---|---|
| 75-100 | 1단계, 임무 필수 |
| 50-74 | 2단계, 비즈니스 핵심 |
| 25-49 | 3단계, 사업 운영 |
| 0-24 | 4단계, 행정 |
의존성 문제: 설문조사 기반 점수 산정 방식이 잘못된 이유
운영 의존성 차원은 가장 잘못 계산될 가능성이 높은 부분이며, 잘못 계산될 경우 가장 큰 결과를 초래하는 부분이기도 합니다. 겉보기에는 중요하지 않아 보이는 기존 인증 서비스라도 전체 전자상거래 플랫폼의 단일 장애 지점이 될 수 있으며, 해당 서비스의 장애는 모든 수익 창출 거래를 중단시킬 수 있습니다. 이 과정은 추상적인 위협을 넘어 서비스 수준 계약에 구체적이고 측정 가능한 영향을 미칩니다.
애플리케이션 소유자는 자신이 호출하는 상위 시스템, 즉 직접적인 상위 종속성은 알고 있습니다. 하지만 자신을 호출하는 하위 시스템, 즉 하위 종속성 전체를 아는 경우는 드뭅니다. 예를 들어, 내부 사용자 인증 서비스는 소유자 입장에서는 중요도가 낮은 서비스로 여겨질 수 있습니다(수익을 창출하지 않고, 단순하며, 오류 발생률이 낮기 때문입니다). 그러나 이 서비스는 12개의 고객 대면 애플리케이션에서 모두 1등급 시스템으로 분류되어 의존하고 있습니다. 인증 서비스의 실제 중요도가 1등급인 이유는 서비스 자체의 기능 때문이 아니라 상위 시스템과의 종속성 그래프에서의 위치 때문입니다.
설문조사 기반 중요도 평가 방식은 이러한 오류를 체계적으로 발생시킵니다. 애플리케이션 소유자에게 "이 애플리케이션은 얼마나 중요합니까?"라는 질문을 던집니다. 인증 서비스 소유자는 서비스 기능에 따라 "낮음~중간"이라고 답합니다. 하지만 종속 애플리케이션 12개의 소유자는 인증 서비스에 대한 설문조사가 아니라 각자의 애플리케이션에 대한 설문조사에 답합니다. 따라서 종속 관계가 제대로 파악되지 않습니다.
그 결과는 복구 순서에 나타납니다. BCP(사업 연속성 계획)는 설문 조사에서 도출된 중요도 점수를 기반으로 복구 순서를 정의하며, 인증 서비스는 3단계 복구 대상으로 지정됩니다. 실제 장애 발생 시, 먼저 복구되어야 하는 1단계 애플리케이션은 해당 애플리케이션이 의존하는 인증 서비스가 복구되지 않았기 때문에 복구할 수 없습니다. 복구 순서는 가장 중요한 의존 지점에서 실패하게 됩니다.
설문조사에서 일관되게 놓치는 세 가지 유형의 의존성:
숨겨진 공유 구성 요소. 세 가지 개별 비즈니스 프로세스의 통화 변환을 처리하는 내부 COBOL 프로그램은 조사에서 구성 요소를 공유하는 것으로 확인되지 않았지만, 세 가지 프로세스 모두의 복구에 영향을 미치는 숨겨진 종속성입니다. 통화 변환 프로그램이 3단계 중요도이고 세 가지 비즈니스 프로세스 중 하나라도 1단계 중요도인 경우, 통화 변환 프로그램의 실질적인 중요도는 1단계가 됩니다.
데이터 파이프라인 종속성. 다른 애플리케이션에서 배치 처리된 데이터를 사용하는 애플리케이션은 실시간이 아닌 시간적 종속성을 갖습니다. 위험은 동시 장애가 아니라 순차적 장애입니다. 하위 애플리케이션은 복구되지만 데이터 소스가 동일한 복구 시점으로 복원되지 않아 오래된 데이터를 사용하는 것처럼 보일 수 있습니다. 이러한 유형의 종속성은 데이터 흐름 자체를 추적하지 않는 한 네트워크 토폴로지 맵이나 호출 그래프 분석에 나타나지 않습니다.
공유 구성 및 스키마 종속성. 데이터베이스 스키마, 구성 서비스 또는 ID 공급자를 공유하는 애플리케이션은 서로 직접 호출하지 않더라도 암묵적인 종속성을 갖습니다. 공유 데이터베이스의 스키마 변경은 여러 애플리케이션에 영향을 미칠 수 있습니다. 스키마 손상 후 하나의 애플리케이션만 복구하고 해당 스키마를 공유하는 모든 애플리케이션을 복구하지 않으면 애플리케이션 포트폴리오 전체에 걸쳐 일관되지 않은 상태가 발생합니다.
BCP 통합: 중요도 점수가 복구 결정에 미치는 영향
중요도 점수는 6가지 특정 BCP 설계 결정에 대한 입력값입니다.
1. 복구 순서 정의. 애플리케이션은 중요도 순서대로 복구됩니다. 즉, 1단계 애플리케이션이 2단계 애플리케이션보다 먼저, 2단계 애플리케이션이 3단계 애플리케이션보다 먼저 복구됩니다. 하지만 각 단계 내에서는 종속성 그래프에 따라 복구 순서가 결정됩니다. 다른 애플리케이션에 종속되지 않는 애플리케이션은 해당 단계 내에서 어떤 순서로든 복구될 수 있습니다. 팬인(fan-in)이 높은 애플리케이션은 단계 내에서의 상대적인 중요도와 관계없이 종속 애플리케이션보다 먼저 복구되어야 합니다. 따라서 복구 순서는 각 단계 내에서 종속성 제약 조건이 적용된 하위 순서에 단계 순서가 적용되는 방식입니다.
2. RTO 및 RPO 목표 설정. 중요도 점수는 RTO 및 RPO 목표를 설정하는 데 활용됩니다. 각 운영 애플리케이션에 대한 최대 허용 다운타임(MTD)과 복구 시점 목표(RPO)는 전체 비즈니스 연속성 전략의 기술적 기반을 형성합니다. MTD는 비즈니스에서 애플리케이션을 사용할 수 없는 최대 시간을 의미합니다. RTO는 MTD보다 짧아야 합니다. RTO와 MTD 사이의 차이는 안전 여유 공간입니다. 다운타임 시간당 비즈니스에 미치는 영향이 큰 Tier 1 애플리케이션은 MTD/RTO 여유 공간이 좁으므로 신속한 자동 복구를 위해 설계된 인프라가 필요합니다.
3. 인프라 투자 조정. 중요도 점수는 재해 복구(DR) 인프라 투자 결정에 직접적인 영향을 미칩니다. 1단계 애플리케이션은 액티브-액티브 다중 지역 이중화가 타당합니다. 2단계 애플리케이션은 검증된 페일오버를 갖춘 액티브-패시브 구성이 타당합니다. 3단계 애플리케이션은 문서화된 복구 절차를 갖춘 정기 백업이 타당합니다. 4단계 애플리케이션은 표준 백업 정책을 사용할 수 있습니다. 중요도 점수가 없으면 인프라 투자 결정은 일률적인 과잉 투자(비용 부담) 또는 일률적인 과소 투자(위험)로 귀결됩니다.
4. 변경 관리 요구 사항. 중요도 점수가 높은 애플리케이션일수록 더욱 엄격한 변경 관리가 필요합니다. 즉, 변경 동결 기간을 늘리고, 승인 의무자를 늘리고, 변경 전 테스트를 더욱 광범위하게 수행하고, 롤백 절차를 더욱 보수적으로 적용해야 합니다. 중요도 4단계 애플리케이션에 1단계 변경 관리 방식을 적용하면 엔지니어링 시간이 낭비됩니다. 반대로 중요도 1단계 애플리케이션에 4단계 변경 관리 방식을 적용하면 용납할 수 없는 위험이 발생합니다.
5. 테스트 및 검증 빈도. 비즈니스 연속성 계획(BCP)은 복구 절차에 대한 주기적인 테스트, 모의 훈련, 구성 요소 수준의 장애 조치 테스트 및 전체 재해 복구 시뮬레이션을 요구합니다. 중요도 점수에 따라 테스트 빈도가 결정됩니다. 1단계 애플리케이션은 분기별 재해 복구 테스트가 필요하고, 4단계 애플리케이션은 연간 테스트가 필요합니다. 모든 애플리케이션을 동일한 빈도로 테스트하는 것은 현실적으로 불가능하며 필요하지도 않습니다.
6. 공급업체 SLA 요구 사항. 타사 서비스에 의존하는 애플리케이션의 경우, 중요도 점수에 따라 공급업체 계약에 포함되어야 하는 SLA 요구 사항이 결정됩니다. 4시간의 RTO(복구 목표 시간)를 가진 Tier 1 애플리케이션은 해당 RTO에 부합하는 가용성을 보장하는 타사 SLA가 필요합니다. 하지만 Tier 4 애플리케이션은 그렇지 않습니다.
기존 시스템의 문제점
기존 시스템은 최신 애플리케이션 포트폴리오 관리 프레임워크가 제대로 해결하지 못하는 방식으로 중요도 평가를 복잡하게 만듭니다. 표준 중요도 평가는 애플리케이션 소유자가 자신의 애플리케이션이 무엇을 하는지, 그리고 어떤 프로세스가 해당 애플리케이션에 의존하는지 알고 있다고 가정합니다. 그러나 여러 세대의 개발자가 유지 관리해 온 COBOL 프로그램, 2008년에 마지막으로 종속성 문서가 작성된 JCL 작업 스트림, 현재 조직에서 아무도 작성하지 않은 프로세스에서 사용되는 출력 파일을 생성하는 RPG 프로그램과 같은 기존 시스템의 경우 이러한 가정은 성립하지 않습니다.
레거시 시스템의 실제 의존성 구조는 코드 자체에서만 확인할 수 있습니다. 예를 들어, 12개의 하위 프로그램이 읽는 데이터 세트에 쓰는 COBOL 프로그램은 12개의 하위 프로그램에 의존하지만, 프로그램 소유자는 프로그램의 기능(일일 거래 처리)만 보고 구조적 역할(다른 12개 프로세스가 실행할 수 있는 데이터 세트를 생성)은 인지하지 못할 수 있습니다.
레거시 시스템의 경우, 중요도 점수 산정 시 의존성 차원을 고려하려면 소유자 설문 조사보다는 코드 분석이 필수적입니다. COBOL 프로그램의 팬인(fan-in) 횟수는 환경 내 다른 모든 프로그램을 검토하여 해당 프로그램의 출력 데이터 세트, 호출 규칙 또는 공유 카피북을 참조하는 프로그램을 파악해야만 산출할 수 있습니다. 이러한 분석은 구조적 코드 분석 플랫폼에서 제공하는 기능이며, 이러한 분석 없이는 레거시 프로그램에 할당된 중요도 점수의 의존성 차원은 기껏해야 추측에 불과합니다.
레거시 애플리케이션의 중요도를 잘못 판단할 경우 그 결과는 특히 심각합니다. 레거시 시스템은 일반적으로 매우 중요하면서도(수십 년에 걸쳐 축적된 핵심 비즈니스 로직을 포함하는 경우가 많음) 평가 점수가 낮게 책정되는 경향이 있기 때문입니다(시스템 소유자가 해당 시스템에 의존하는 요소가 무엇인지 명확히 설명하지 못하여 보수적인 점수를 부여함). 그 결과, 실제로는 1단계 비즈니스 프로세스의 핵심 경로에 있는 레거시 프로그램이 3단계로 분류되는 경우가 발생하며, 이는 실제 장애 발생 시 복구 시퀀스 실패에서 나타나는 정확한 오류 유형입니다.
방법 SMART TS XL 중요도 점수 산정을 위한 의존성 근거를 제공합니다.
SMART TS XL 본 연구는 설문 조사 기반 접근 방식의 신뢰도가 가장 낮은 애플리케이션 유형에 대해 애플리케이션 중요도 평가의 의존성 차원을 직접적으로 다룹니다.
애플리케이션 종속성 매핑 기능은 환경 내 모든 언어에 걸쳐 완전한 종속성 그래프를 구축합니다. 여기에는 다른 모든 COBOL 프로그램을 호출하는 모든 COBOL 프로그램, 하위 프로그램에서 소비하는 데이터를 생성하는 모든 JCL 작업 단계, 직접 호출하지 않는 프로그램 간에 암묵적인 종속성을 생성하는 모든 공유 카피북, 생산 프로그램과 소비 프로그램 간에 흐르는 모든 데이터 세트가 포함됩니다. 이 그래프는 중요도 점수 산정, 팬인 카운트, 공유 구성 요소 식별, 설문 조사로는 확실하게 파악할 수 없는 숨겨진 데이터 파이프라인 종속성 등 종속성 차원에 대한 구조적 근거를 제공합니다.
영향 분석 기능을 통해 BCP(비즈니스 연속성 계획) 수립을 위한 종속성 그래프를 조회할 수 있습니다. 포트폴리오 내 모든 애플리케이션에 대해 직접 또는 간접적으로 종속되어 가용성 요구 사항을 상속받는 다른 모든 애플리케이션을 열거할 수 있습니다. 예를 들어, 직접 종속 프로그램이 3개 있고 간접 종속 프로그램(직접 종속 프로그램에 의존하는 프로그램)이 20개 있는 COBOL 프로그램의 유효 중요도는 해당 프로그램이 속한 23개 프로그램의 중요도를 반영하며, 단순히 자체 기능의 중요도만을 반영하는 것이 아닙니다.
정적 코드 분석 기능은 복구 복잡성 차원을 결정하는 데 중요한 구조적 복잡성 지표를 제공합니다. 이러한 지표에는 순환 복잡도, 결합도, 데드 코드 비율, 기술 부채 지표 등이 포함되며, 각 애플리케이션의 복구에 소요되는 시간과 위험도를 예측합니다. 복잡성이 높고 결합도가 높은 애플리케이션은 동일한 기능을 수행하지만 아키텍처가 깔끔한 애플리케이션에 비해 복구 비용이 더 많이 들고, 차원 3 복구 복잡성 점수도 더 높습니다.
엔터프라이즈 검색 기능을 통해 BCP(비즈니스 연속성 계획) 수명 주기 전반에 걸쳐 전체 종속성 목록을 조회할 수 있습니다. 특정 데이터 세트에 액세스하는 모든 프로그램(해당 데이터 세트의 가용성에 의존하는 모든 프로그램 식별), 특정 카피북을 공유하는 모든 프로그램(해당 카피북의 가용성에 영향을 받는 모든 프로그램 식별), 특정 배치 기간에 실행되는 모든 JCL 작업(해당 기간이 시작되기 전에 복구해야 하는 모든 프로그램 식별) 등을 찾을 수 있습니다. 이 검색 기능은 연간 중요도 점수 검토 및 애플리케이션 포트폴리오의 변화에 따라 점수를 최신 상태로 유지하는 업데이트 프로세스를 지원합니다.
조직이 수행하는 경우 레거시 현대화 BCP 개발과 병행하는 프로그램, SMART TS XL'의 분석은 두 가지 목적을 동시에 달성합니다. 중요도 점수 산정에 사용되는 종속성 맵은 마이그레이션 순서를 결정하는 데에도 사용되며, 복구 복잡성 점수 산정에 사용되는 복잡성 지표는 현대화 노력 추정치를 결정하는 데에도 사용됩니다.
점수를 최신 상태로 유지하기: 연례 평가 주기
비즈니스 연속성 성숙도 평가는 다음 세 가지를 달성하는 데 도움이 되어야 합니다. 현재 상태를 이해하고, 가장 중요한 격차를 파악하며, 현실적인 개선 방안을 수립하는 것입니다. 바로 이러한 점이 성숙도 점수 산정을 더 나은 프로그램으로 만드는 요소입니다.
조직이 변화함에 따라 애플리케이션 중요도 점수는 현실과 동떨어지게 됩니다. 새로운 애플리케이션이 추가되고, 기존 애플리케이션은 사용 중단되지만 완전히 폐기되지는 않습니다. 이전에는 서로 의존성이 없었던 애플리케이션 간에 통합이 구축됩니다. 비즈니스 프로세스가 변경되고, 그에 따라 해당 프로세스가 의존하는 애플리케이션도 변경됩니다. 규제 요건이 진화하면서 새로운 복구 의무가 부과됩니다.
중요도 점수에 대한 연례 검토 주기에는 다음 사항이 포함되어야 합니다.
구조적 재분석. 마지막 검토 이후 새로 발생한 종속성을 식별하기 위해 종속성 매핑을 다시 실행합니다. 이전에는 독립형이었던 애플리케이션이 이제 종속성으로 인해 중요도가 높아졌을 수 있습니다. 반대로, 의존도가 높았던 애플리케이션은 사용자가 새로운 시스템으로 마이그레이션하면서 중요도가 낮아졌을 수 있습니다.
비즈니스 영향 재평가. 매출 및 운영 영향 수치는 비즈니스 성장과 애플리케이션 포트폴리오의 진화에 따라 변화합니다. 3년 전 시간당 1,000달러의 비즈니스 가치를 창출했던 애플리케이션이 비즈니스 성장 후에는 10배의 가치를 창출할 수도 있습니다.
복구 테스트 결과 반영. 재해 복구(DR) 테스트는 예상 복구 복잡성과 실제 복구 복잡성 간의 차이를 드러냅니다. 초기 평가에서 복구 복잡성 점수가 낮게 나온 애플리케이션이라도 모의 훈련에서는 저조한 성능을 보였을 수 있으며, 이 경우 점수 상향 조정이 필요할 수 있습니다.
규제 변경 검토. 새로운 규정이나 기존 규정의 변경으로 특정 애플리케이션에 새로운 복구 시간 의무가 부과될 수 있습니다. 예를 들어, EU 금융 기관에 대한 DORA 규정의 운영 복원력 요건은 "핵심 또는 중요 기능"에 대해 특정 RTO 의무를 부과했는데, 이는 DORA 이전의 중요도 점수에는 반영되지 않았을 수 있습니다.
성숙한 BCP 프로그램을 갖춘 조직은 중요도 점수 산정을 일회성 작업이 아닌 지속적인 프로세스로 간주합니다. 즉, 애플리케이션 종속성, 비즈니스 영향 또는 규제 의무에 중대한 변경 사항이 발생할 때마다 점수를 업데이트하고, 체계적인 검토를 통해 매년 검증합니다.
점수의 유효성은 의존성 증거의 질에 달려 있습니다.
애플리케이션 중요도 평가는 설문 조사보다는 구조적 증거에 기반한 의존성 차원을 고려할 때 가장 큰 가치를 제공합니다. 비즈니스 영향 및 규제 의무 차원은 인터뷰와 비즈니스 프로세스 분석을 통해 신뢰할 수 있게 평가할 수 있습니다. 그러나 운영 의존성 차원은 각 애플리케이션에 무엇이 의존하는지 파악해야 하므로 이러한 방식으로는 평가할 수 없습니다. 애플리케이션 소유자는 일반적으로 하위 사용자와의 의존성을 과소평가하는 경향이 있기 때문입니다.
실패 모드는 예측 가능합니다. 설문조사를 통해 도출된 중요도 점수를 기반으로 구축된 복구 시퀀스가 숨겨진 종속성에서 실패하는 경우입니다. 기존 인증 서비스가 복구되는 데 시간이 오래 걸리고, 해당 프로그램에 의존하는 애플리케이션이 복구를 시도할 때 COBOL로 작성된 통화 변환 프로그램이 오프라인 상태인 경우도 있습니다. 공유 데이터베이스 스키마가 해당 스키마에서 데이터를 읽는 애플리케이션과 다른 복구 지점에 있는 경우도 있습니다. 이러한 각각의 실패는 구조 분석이 제공하는 종속성 정보를 통해 예방할 수 있으며, 실제 사고 발생 시에는 모의 훈련보다 훨씬 큰 손실을 초래할 수 있습니다.
평가 방법론은 확립되어 있고, 프레임워크도 존재합니다. 대부분의 조직이 가진 격차는 평가 프레임워크 자체가 아니라, 가장 중요한 차원에 대한 근거 자료의 부족에 있습니다. 다음번 사고 발생 시 비즈니스 연속성 계획(BCP)이 작동하기 전에 구조적 분석을 통해 이러한 격차를 해소해야 합니다.
