영향 분석 도구: 작동 방식 및 기업 팀을 위한 최적의 선택지

운영 시스템에 대한 모든 변경 사항은 변경된 구성 요소를 넘어 광범위한 영향을 미칩니다. 공유 함수를 수정하면 이전 동작에 의존했던 호출자가 제대로 작동하지 않게 됩니다. 데이터베이스 스키마가 변경되면 변경된 열을 참조하는 모든 쿼리가 자동으로 무효화됩니다. COBOL 카피북을 업데이트하려면 해당 카피북을 포함하는 모든 프로그램을 다시 컴파일해야 하는데, 이 범위는 수십 개의 작업 스트림에 걸쳐 수백 개의 프로그램에 영향을 미칠 수 있으며, 모든 프로그램은 운영 환경으로 전환하기 전에 테스트를 거쳐야 합니다. 영향 분석은 변경 사항에 결과가 발생하는지 여부가 아니라 정확히 어떤 구성 요소가 영향을 받는지, 변경된 요소와 어떻게 연결되어 있는지, 그리고 변경 사항을 안전하게 배포하기 전에 어떤 범위의 검증이 필요한지를 파악하는 데 중점을 둡니다.

영향 분석이 없다면, 그 질문에 대한 답은 추측에 의존하거나, 변경을 수행한 개발자에게 문의하거나, 전체 테스트 스위트를 실행하고 오류가 적절한 부분에 집중되기를 바라거나, 사용자가 오류를 보고할 때 영향을 받는 구성 요소를 배포하고 발견하는 방식으로 얻게 됩니다. 영향 분석 도구는 추측 대신 구조적 증거를 제공합니다. 소스 코드를 분석하고, 종속성을 매핑하고, 제안된 변경 사항이 영향을 미칠 모든 구성 요소의 목록을 생성합니다. 이 가이드에서 다루는 도구는 정적 분석 플랫폼부터 테스트 선택 엔진, 엔터프라이즈 종속성 매퍼에 이르기까지 다양하며, 각각 영향 분석 문제의 서로 다른 측면을 다룹니다.

소프트웨어 엔지니어링에서 영향 분석이란 무엇인가요?

소프트웨어 엔지니어링에서 영향 분석은 제안된 변경 사항으로 인해 직간접적으로 영향을 받는 시스템의 모든 구성 요소를 식별하는 프로세스입니다. 즉, "이 부분을 변경하면 다른 어떤 부분이 변경될까?"라는 질문에 대한 답을 찾는 것입니다. 영향 분석은 구현 전에 계획, 설계 및 변경 승인 단계에서 수행되며, 테스트 또는 사고 대응 단계에서 사후적으로 수행되는 것이 아닙니다.

이 용어는 분석 대상과 시점이 서로 다른, 관련은 있지만 구별되는 여러 활동을 포괄합니다.

변경 영향 분석은 코드 변경을 실행하기 전에 해당 변경 사항의 범위를 파악하는 과정입니다. 이를 통해 제안된 변경으로 인해 수정 또는 재테스트가 필요한 모듈, 함수, 데이터베이스 테이블 및 종속 시스템을 식별합니다.

테스트 영향 분석(TIA) 은 코드 변경에 따른 영향을 분석하는 특정 방법으로, 주어진 코드 변경과 관련된 기존 테스트를 식별합니다. TIA는 전체 테스트 스위트를 실행하는 대신, 변경된 코드와 그 종속성을 포함하는 최소한의 테스트만 선택하여 테스트 실행 시간을 단축하고 영향을 받는 범위의 테스트 범위를 유지합니다.

요구사항 영향 분석은 요구사항이 변경될 때 어떤 요구사항, 설계 요소 및 하위 산출물이 영향을 받는지 파악합니다. 규제 산업에서 이는 변경된 요구사항에 의존하는 모든 하위 산출물이 업데이트되고 재검증되도록 보장합니다.

이 세 가지 모두 공통된 기반을 공유합니다. 즉, 구성 요소 간의 관계를 나타내는 종속성 모델과 시작점(변경된 구성 요소)에서 해당 모델을 탐색하여 도달 가능한 모든 것을 열거하는 메커니즘입니다.

영향 분석의 세 가지 유형

영향 분석 기법은 의존성 정보를 수집하는 방식에 따라 분류됩니다.

타입	방법	발견한 것	언제 사용 하는가?
정적 충격 분석	소스 코드를 실행하지 않고 구문 분석합니다.	모든 구문 참조: 함수 호출, 가져오기, 필드 접근, 스키마 참조	구현 전, 변경 계획 단계; 모든 코드베이스에서 작업 가능
동적 영향 분석	실제 실행 경로를 관찰하기 위해 코드를 실행하는 도구를 사용합니다.	테스트 실행 중에 실제로 작동된 구성 요소만 해당됩니다.	런타임별 종속성; 정적 분석에서 놓칠 수 있는 경로를 식별합니다.
요구사항 기반(의미론적)	요구사항, 설계 및 코드 간의 추적성 연결을 추적합니다.	요구사항 변경으로 인해 영향을 받는 상위 및 하위 아티팩트	규제 산업; 시스템 엔지니어링; 안전 필수 소프트웨어

정적 영향 분석은 실행 중인 시스템이나 테스트 인프라 없이 소스 코드만으로 작동하기 때문에 가장 널리 사용되는 기법입니다. 이 가이드에 소개된 도구들과 다른 여러 도구들이 사용하는 기법이기도 합니다. SMART TS XL 엔터프라이즈 코드베이스 분석을 위해 동적 분석은 정적 분석을 보완합니다. 동적 분석은 소스 코드만으로는 파악할 수 없는 런타임 동작(예: 동적으로 생성되는 쿼리 또는 지연 바인딩되는 함수 호출)을 포착합니다. 실제로 대부분의 프로덕션 영향 분석 프로그램은 두 가지 방식을 모두 사용합니다. 정적 분석은 기준 종속성 맵을 제공하고, 동적 프로파일링은 관찰된 런타임 동작을 기준으로 이를 검증합니다.

정적 충격 분석과 동적 충격 분석의 주요 차이점

정적 영향 분석은 보수적인 접근 방식입니다. 코드에 존재하지만 실제로 실행되지 않는 종속성을 포함하여 영향을 받는 범위를 과대평가할 수 있습니다. 동적 영향 분석은 관찰된 내용에 대해서는 정확하지만 불완전합니다. 계측된 세션 동안 실제로 실행된 부분만 포착하므로, 다른 입력이나 구성에서 실행되는 경로는 누락됩니다. 정확성보다 완전성이 중요한 운영 시스템에서는 정적 분석이 더 안전한 기본 접근 방식입니다.

영향 분석 프로세스: 단계별 안내

체계적인 영향 분석 프로세스는 사용되는 도구와 관계없이 일관된 순서를 따릅니다.

1단계: 변경 사항을 정의합니다. 변경되는 내용을 정확히 파악합니다. 구체적인 함수, 필드, 클래스, 모듈, 카피북 또는 데이터베이스 열을 명시해야 합니다. 이 단계에서의 정확성은 이후 모든 단계의 정확성을 좌우합니다. "결제 모듈을 수정합니다"와 같이 모호한 변경 정의는 모호한 영향 결과를 초래합니다.

2단계: 의존성 모델을 구축하거나 조회합니다. 의존성 모델은 시스템 내 모든 구성 요소 간의 관계를 나타냅니다. 자동화 도구를 사용하는 경우 소스 코드를 분석하여 이 모델을 구축합니다. 소규모 시스템에 대한 수동 분석의 경우 문서 형태로 유지 관리할 수 있습니다. 모델은 최신 상태여야 합니다. 오래된 의존성 문서는 부정확한 영향 평가를 초래할 수 있습니다.

3단계: 변경 지점에서 의존성 그래프를 따라 이동합니다. 변경된 구성 요소에서 시작하여 들어오는 의존성 간선(변경된 구성 요소에 의존하는 구성 요소)과 나가는 간선(변경된 구성 요소에 의존하며 변경 후 동작이 달라질 수 있는 구성 요소)을 모두 따라갑니다. 도달 가능한 모든 의존 구성 요소를 열거할 때까지 전이적으로 계속 진행합니다.

4단계: 영향을 받는 구성 요소를 위험도에 따라 분류합니다. 모든 영향을 받는 구성 요소의 위험도가 동일하지는 않습니다. 변경된 함수를 직접 호출하는 구성 요소는 종속성 수준이 5단계 떨어진 구성 요소보다 위험도가 높습니다. 수정 작업에 집중하기 위해 근접성, 중요도 및 테스트 적용 범위에 따라 발견 사항을 분류합니다.

5단계: 테스트 범위를 정의합니다. 영향 집합(영향을 받는 구성 요소의 전체 목록)은 최소 테스트 범위를 정의합니다. 영향 집합에 포함된 구성 요소 중 자동화된 테스트 범위가 부족한 구성 요소는 테스트를 추가하거나 수동 검증을 통해 해결해야 하는 위험 요소입니다.

6단계: 문서화 및 검토. 변경 승인의 근거로 영향 평가 결과를 변경 자문 위원회(CAB) 또는 관련 이해관계자에게 제시합니다. 위험 분류가 포함된 열거된 영향 범위는 개발자의 추정치를 구조적 증거로 대체합니다.

테스트 영향 분석: CI/CD에서의 작동 방식

테스트 영향 분석(TIA)은 테스트 문제를 구체적으로 분석하는 데 있어 영향 분석을 적용합니다. 즉, 코드 변경이 주어졌을 때 어떤 테스트를 실행해야 하는지를 판단하는 것입니다. TIA가 없다면 CI 파이프라인은 모든 커밋마다 전체 테스트 스위트를 실행합니다. 테스트가 50,000만 개 있고 테스트 스위트 실행에 45분이 소요되는 코드베이스의 경우, 모든 풀 리퀘스트가 45분 동안 차단됩니다. 이 때문에 개발자들은 결과를 기다리지 않고 여러 커밋을 푸시하는 방식으로 문제를 해결하려 하고, 테스트의 본래 목적인 피드백 루프를 놓치게 됩니다.

TIA는 코드와 테스트 간의 매핑, 즉 어떤 코드 라인이 어떤 테스트에 의해 커버되는지를 추적함으로써 이러한 문제를 해결합니다. 커밋으로 특정 라인이 변경되면 TIA는 해당 라인과 그에 종속된 라인을 커버하는 테스트만 선택합니다. 5만 개의 파일 중 3개 파일만 변경하는 경우 5만 개의 테스트가 아닌 200개의 테스트만 필요할 수 있습니다. 결과적으로 파이프라인 실행 시간이 몇 분이 아닌 몇 초로 단축됩니다.

이 매핑은 테스트 실행을 계측하여 코드 커버리지 데이터를 기록한 다음, 해당 커버리지 데이터를 커버하는 코드별로 인덱싱하여 저장함으로써 구축됩니다. 새 커밋이 발생할 때마다 TIA:

1. (git diff를 통해) 어떤 파일과 함수가 변경되었는지 확인합니다.
2. 해당 파일과 함수를 다루는 테스트가 무엇인지 찾아봅니다.
3. 변경된 코드의 정적 종속성 그래프에 있는 모든 구성 요소를 다루는 테스트를 추가합니다.
4. 선택된 하위 집합을 실행하고, 나머지 모든 테스트는 영향이 없는 것으로 간주하여 통과합니다.

TIA(테스트 영향 분석)를 구현하는 도구로는 Microsoft Visual Studio의 TIA 기능, Parasoft의 TIA 엔진, Gradle의 테스트 선택 기능, 그리고 Jest, pytest 및 기타 테스트 실행기를 위한 여러 CI 통합 플러그인이 있습니다. TIA의 정확도는 의존성 모델의 정확도에 따라 달라지는데, 의존성 탐색 없이 직접적인 코드 커버리지만 추적하는 도구는 변경 사항에서 세 단계 떨어진 구성 요소를 다루는 테스트를 놓칠 수 있습니다.

실제 TIA 사례: 전후 비교

일반적인 엔터프라이즈 백엔드 서비스에서 TIA를 활성화하면 평균 풀 리퀘스트당 테스트 실행 시간이 60~80% 단축됩니다. 하지만 공유 유틸리티, 기본 클래스 또는 널리 사용되는 구성과 같은 매우 큰 변경 사항의 경우 여전히 대규모 테스트 하위 집합이 실행될 수 있다는 단점이 있습니다. TIA는 변경 사항이 로컬에 국한되는 기능 개발 및 버그 수정에 가장 큰 효과를 발휘합니다. 프레임워크 업그레이드 또는 공유 스키마 수정과 같은 횡단적 변경 사항의 경우 전체 테스트를 실행하는 것이 더 안전한 선택입니다.

요구사항 및 변경 관리에서의 영향 분석

시스템 엔지니어링 및 규제 대상 소프트웨어 개발에서 영향 분석은 코드뿐 아니라 요구사항, 설계 명세서, 테스트 케이스, 위험 평가 및 검증 증거를 포함한 전체 산출물 체인에까지 확장됩니다. 요구사항 변경은 코드에만 영향을 미치는 것이 아니라 해당 요구사항을 구현한 모든 설계 요소, 이를 검증한 모든 테스트 케이스, 이를 가정한 모든 위험 평가, 그리고 이를 참조한 모든 규정 준수 문서에 영향을 미칩니다.

요구사항 기반 영향 분석은 추적성 링크를 사용하여 하위 범위에 대한 재검증을 열거합니다. 각 요구사항을 구현 설계 요소, 테스트 케이스 및 검증 증거와 연결하는 추적성 매트릭스를 통해 모든 요구사항 변경으로 인해 필요한 재검증의 전체 범위를 파악할 수 있습니다. FDA 21 CFR Part 11에 따른 의료기기, DO-178C에 따른 항공 소프트웨어, ISO 26262에 따른 자동차 소프트웨어와 같은 규제 산업에서는 이러한 재검증 범위가 선택적인 품질 관리 관행이 아니라 규제 요건입니다.

요구사항 영향 분석과 코드 영향 분석 간의 연결 고리는 추적성입니다. 요구사항이 특정 소프트웨어 구성 요소로 연결되고, 해당 구성 요소가 코드 수준 영향 분석에서 식별되면, 영향 분석 결과를 활용하여 해당 구성 요소를 검증하는 특정 테스트 케이스에 재검증 노력을 집중할 수 있습니다. Jama Connect 및 IBM DOORS와 같은 최신 요구사항 관리 플랫폼은 이러한 추적성을 지원하고 요구사항 수준에서 내장된 영향 분석 기능을 제공합니다.

대규모 및 레거시 코드베이스에 대한 영향 분석

대규모 코드베이스, 특히 수십 년에 걸쳐 성장해 온 엔터프라이즈 시스템에 대한 영향 분석은 10,000만 줄짜리 서비스에 대한 영향 분석과는 질적으로 다릅니다. 규모의 차이는 단순히 양적인 차이만이 아닙니다. 대규모 레거시 코드베이스는 팀 구성원 누구도 완전히 이해하지 못하는 복잡한 의존성 구조를 가지고 있습니다. 공유 데이터 세트를 통해 암묵적으로 연결된 수천 개의 프로그램, 수백 개의 프로그램에서 동시에 포함되는 카피북, 런타임 전용 의존성을 생성하는 복잡한 조건부 실행 로직을 포함하는 JCL 작업 스트림 등이 그 예입니다.

대규모 코드베이스의 몇 가지 특성으로 인해 수동 영향 분석은 신뢰할 수 없습니다.

암묵적 종속성. COBOL 시스템에서 300개의 프로그램에 포함된 카피북은 개발자가 찾아볼 필요성을 인지하지 못하면 보이지 않는 종속성을 생성합니다. 필드 이름 변경처럼 보이는 카피북 멤버 변경만으로도 300개 프로그램 전체를 다시 컴파일하고 테스트해야 할 수 있습니다. 자동화된 분석이 없다면 이러한 문제는 점진적으로 발견되며, 새로운 오류가 발생할 때마다 누락된 종속성이 드러납니다.

언어 간 종속성. COBOL 프로그램이 DB2 테이블에 데이터를 쓰고, Java 서비스가 같은 테이블에서 데이터를 읽습니다. Python 파이프라인은 Java 서비스의 출력을 처리합니다. DB2 스키마가 변경되면 이 세 계층 모두에 영향을 미칩니다. 단일 언어 정적 분석 도구로는 이러한 언어 간 종속성을 추적할 수 없습니다. 세 가지 언어를 모두 이해하고 통합된 종속성 모델로 연결하는 도구가 필요합니다.

데이터를 통한 간접적 의존성. 서로 직접 호출하지 않는 두 프로그램이라도 공유 파일을 통해 연결될 수 있습니다. 프로그램 A는 데이터셋 X에 데이터를 쓰고, 프로그램 B는 데이터셋 X에서 데이터를 읽습니다. 데이터셋 X의 레이아웃 변경은 두 프로그램 모두에 영향을 미치지만, 이러한 의존성은 함수 호출이 아니라 JCL DD 문과 COBOL FD 정의를 통해 표현되는 데이터 계약입니다. 함수 호출만 추적하는 구조 분석은 이러한 유형의 의존성을 완전히 놓칩니다.

사용되지 않는 코드와 도달 가능성. 대규모 코드베이스에는 정의되었지만 호출되지 않는 코드, 제거된 기능에서 남은 함수, 대체되었지만 삭제되지 않은 프로시저 등이 축적됩니다. 사용되지 않는 코드를 영향 범위에 포함하는 영향 분석은 변경 범위를 과대평가하고 실제 운영 환경에서 절대 도달하지 않을 구성 요소에 테스트 노력을 집중하게 만듭니다.

이러한 환경을 위한 레거시 현대화 분석 솔루션은 다음 모든 경우를 처리해야 합니다. 즉, 실제로 사용 중인 언어(COBOL, JCL, PL/I, RPG, 어셈블러, DB2 포함)를 분석하고, 공유 데이터 구조를 통해 암묵적인 종속성을 해결하고, 언어 간 연결 고리를 추적하고, 도달 가능한 코드와 도달 불가능한 코드를 구분해야 합니다.

영향 분석 도구: 비교 분석

아래 도구들은 소프트웨어 개발에서 발생하는 영향 분석의 주요 범주를 다룹니다. 각 도구는 분석 대상, 지원 언어, 그리고 어떤 유형의 영향 분석 문제를 가장 잘 해결하는지를 기준으로 평가됩니다.

수단	1차적 접근 방식	언어	지원 기기
SMART TS XL	정적 + 언어 간 의존성 매핑	COBOL, JCL, Java, Python, .NET, RPG, SQL	기업 및 메인프레임 다국어 환경 영향 분석
SciTools로 이해	정적 분석, 호출 그래프, 의존성 시각화	70 개 이상의 언어	다국어 코드 이해 및 영향 세트
구조101	아키텍처 분석, 의존성 그래프	자바, C#, JVM/.NET	Java/C# 엔터프라이즈 애플리케이션의 구조적 영향
캐스트 에이프	애플리케이션 인텔리전스, 기술 부채, 영향	자바, .NET, COBOL, SQL	포트폴리오 수준의 비즈니스 및 기술적 영향 분석
액시비온 스위트	C/C++용 의미론적 의존성 그래프	C, C ++	안전 필수 시스템, MISRA 준수, 임베디드
파라소프트	테스트 영향 분석, CI/CD 통합	자바, C/C++, .NET	규제 산업에서의 TIA, 안전 필수 테스트
자마 커넥트	요구사항 추적성, 산출물 영향	언어에 구애받지 않음(요구사항 수준)	시스템 엔지니어링, 규제 산업, DO-178C/ISO 26262
소나큐브	코드 품질, 언어 내 의존성 분석	30 개 이상의 언어	코드 품질 게이트; 제한적인 시스템 간 영향 분석
IntelliJ IDEA / Eclipse	IDE 호출 계층 구조, 참조 분석	자바, 코틀린, 파이썬	프로젝트 내 개발자 수준의 지역 영향 분석

SciTools의 Understand는 최신 프로그래밍 언어로 개발하는 소프트웨어 팀을 위한 가장 포괄적인 영향 분석 도구입니다. 이 도구의 Impact Sets 기능은 특정 변경 사항의 영향을 받는 모든 코드 엔티티(시작점에서 종속성 그래프를 통해 도달 가능한 모든 함수, 클래스 및 변수)의 전이적 폐쇄를 계산합니다. 70개 이상의 언어를 지원하며 상세한 호출 그래프, 데이터 흐름도 및 엔티티 관계도를 생성합니다.

Structure101은 Java 및 C# 아키텍처 수준의 영향 분석을 위한 가장 강력한 도구입니다. 패키지 및 클래스 종속성 구조를 대화형 지도로 시각화하고, 제안된 변경 사항이 아키텍처 경계를 위반하거나 종속성 그래프에 새로운 순환 구조를 생성하는 위치를 식별합니다.

CAST AIP는 포트폴리오 수준에서 작동하며 COBOL, Java, .NET, SQL 및 기타 언어를 포함한 전체 애플리케이션 환경을 분석하여 기술적 영향 분석과 함께 비즈니스 영향 점수를 산출합니다. 이는 일반적으로 인수합병 실사 및 포트폴리오 합리화 프로그램에 사용됩니다.

Axivion Suite는 규제 요건(ISO 26262, DO-178C, MISRA)을 충족하고 분석 완료에 대한 공식적인 증거를 제시해야 하는 영향 분석이 필요한 안전 필수 C 및 C++ 개발을 대상으로 합니다.

Parasoft는 규제 산업을 위한 가장 강력한 TIA 솔루션으로, CI/CD가 통합된 테스트 선택 엔진을 통해 문장 수준까지 코드 커버리지를 추적하고 정확한 종속성 탐색을 기반으로 테스트 하위 집합을 선택합니다.

SonarQube는 프로젝트 내 종속성 분석 및 코드 스멜 감지 기능을 제공하지만, 시스템 간 또는 언어 간 영향 분석을 위해 설계된 것은 아닙니다. SonarQube는 종속성 매핑 도구라기보다는 변경된 구성 요소 중 어떤 것이 새로운 품질 또는 보안 문제를 야기하는지 식별하는 품질 게이트 역할을 한다는 점에서 영향 분석 스택에서 중요한 가치를 지닙니다.

IDE 기반 도구 (IntelliJ의 호출 계층 구조, Visual Studio의 참조 분석, Eclipse의 호출 그래프)는 프로젝트 내에서 개발자가 직접 확인할 수 있는 로컬 영향 분석을 제공합니다. 이러한 도구는 모듈 내에서 변경 사항이 어떤 영향을 미치는지 파악하는 데 효과적이지만, 프로젝트 간, 언어 간 또는 메인프레임 간의 종속성을 추적할 수는 없습니다.

방법 SMART TS XL 영향 분석을 수행합니다.

SMART TS XL 환경 내의 모든 소스 파일, COBOL 프로그램, JCL 작업 스트림, 카피북, SQL 스키마, Java 클래스, Python 모듈, RPG 프로그램 등을 분석하여 영향 분석을 수행하고, 모든 언어에 걸쳐 구조적 관계를 나타내는 통합 종속성 모델을 구축합니다. 이 모델은 기반이 되며, 영향 분석은 임의의 구성 요소에서 시작하여 종속성 그래프를 따라가며 영향을 받는 모든 항목을 열거하는 쿼리입니다.

팀에서 COBOL 카피북 멤버 변경을 제안할 때, SMART TS XL의 영향 분석 답변: 이 카피북을 포함하는 프로그램은 무엇입니까? 해당 프로그램 중 어떤 프로그램이 어떤 JCL 작업 단계에서 호출됩니까? 해당 프로그램은 어떤 DB2 테이블을 읽거나 씁니까? 어떤 Java 서비스가 해당 테이블을 사용합니까? 어떤 테스트 케이스가 해당 프로그램을 다룹니까? 답변은 추정치가 아니라 파일 이름, 프로그램 이름, 작업 이름 및 줄 번호를 포함하여 실제 코드 구조에서 도출된 완전한 열거형 목록입니다.

애플리케이션 종속성 매핑 기능은 변경된 구성 요소를 중심으로 종속성 그래프의 시각적 다이어그램을 생성하며, 색상 코드를 사용하여 직접 종속성과 간접 종속성을 구분하고 위험도가 가장 높은 연결을 강조 표시합니다. 이러한 다이어그램은 CAB 검토를 위한 근거 자료이자 테스트 계획 수립을 위한 로드맵 역할을 합니다.

JCL 확장 기능은 분석 전에 PROC의 기호 매개변수 치환을 해결하여 종속성 모델이 해결되지 않은 템플릿 참조가 아닌 실제 런타임 실행을 반영하도록 합니다. 기호 매개변수에 따라 다른 프로그램을 호출하는 PROC는 모든 호출자에 걸쳐 실제로 호출하는 모든 프로그램으로 해결되므로 기호 매개변수를 인식하지 못하는 도구에서 놓치는 완벽한 커버리지를 제공합니다.

기술 실사, 레거시 시스템 현대화 계획 또는 여러 언어와 플랫폼에 걸쳐 있는 시스템의 변경 관리를 수행하는 엔터프라이즈 팀을 위해, SMART TS XL의 기업 검색 이 기능을 통해 종속성 모델을 쿼리할 수 있습니다. 어떤 규모의 코드베이스에서든 특정 필드의 모든 사용 사례, 특정 함수를 호출하는 모든 프로그램, 특정 데이터 세트를 생성하는 모든 JCL 작업을 몇 초 만에 찾을 수 있습니다.

영향 분석 모범 사례

코드를 작성하기 전에 영향 분석을 시작해야 합니다. 영향 분석의 목적은 변경 결정을 내리는 데 필요한 정보를 제공하고 그에 따른 작업 범위를 설정하는 것이지, 배포 후에 무엇이 잘못되었는지 설명하는 것이 아닙니다. 변경 작업이 이미 진행된 후에 수행되는 영향 평가는 사후 합리화에 불과하며 계획 도구가 아닙니다.

영향 평가의 범위를 명확하게 정의하십시오. 대규모 시스템의 영향 그래프는 거의 모든 것을 포함하도록 확장될 수 있습니다. 분석을 실행하기 전에 분석 범위, 최대 종속성 깊이, 제외할 데 없는 코드, 범위 외 시스템을 정의하십시오. 제약 조건 없이 탐색하면 기술적으로는 정확하지만 운영상 쓸모없는 결과가 나올 수 있습니다.

반드시 재테스트해야 하는 요소와 모니터링해야 하는 요소를 구분하세요. 영향 대상 요소 세트의 모든 구성 요소에 동일한 테스트 대응이 필요한 것은 아닙니다. 자주 사용되는 경로에서 변경된 함수를 직접 호출하는 구성 요소는 반드시 재테스트해야 합니다. 반면, 사용 빈도가 낮은 코드 5단계를 거쳐 변경된 함수에 도달하는 구성 요소는 프로덕션 환경에서 모니터링할 수 있습니다. 위험 분류를 통해 영향 목록을 테스트 계획으로 전환할 수 있습니다.

의존성 모델을 최신 상태로 유지하세요. 오래되었거나 불완전한 의존성 모델을 기반으로 수행되는 영향 분석은 분석을 전혀 하지 않는 것보다 더 나쁩니다. 잘못된 범위에서 잘못된 확신을 심어주기 때문입니다. 의존성 모델은 코드베이스에 중대한 변경 사항이 발생할 때마다 다시 생성하거나, 변경된 파일을 자동으로 재분석하는 CI/CD 통합을 통해 점진적으로 업데이트해야 합니다.

영향 분석을 변경 관리와 함께 활용하십시오. 영향 분석은 그 결과물이 공식적인 변경 관리 프로세스에 반영될 때 비로소 최대의 효과를 발휘합니다. 범위, 위험 분류, 테스트 요구 사항을 문서화한 영향 보고서는 변경 자문 위원회가 개발자의 추정치가 아닌 실제 시스템에 근거하여 승인 결정을 내리는 데 필요한 구조적 근거를 제공합니다.

레거시 시스템의 경우, 암묵적인 데이터 결합을 고려해야 합니다. 함수 호출만 추적하는 레거시 시스템 종속성 분석은 불완전합니다. 메인프레임 환경에서는 공유 파일, 데이터셋, 데이터베이스, 메시지 큐 등을 통해 프로그램이 결합되는 경우가 흔하며, 이러한 결합은 함수 호출만으로는 분석할 수 없습니다. 완전한 영향 범위를 산출하려면 종속성 모델이 데이터 수준의 결합을 고려해야 합니다.

영향 분석 인프라에 대한 투자는 전용 도구를 통해서든 다른 방법을 통해서든 이루어져야 합니다. SMART TS XLParasoft와 같은 테스트 영향 분석 엔진이나 Jama와 같은 요구사항 추적 플랫폼을 사용하는 데 드는 비용은 예상치 못한 문제를 일으키지 않은 변경 사항, 전체 테스트 스위트를 실행할 필요가 없었던 테스트, 그리고 장애를 발생시키지 않은 배포로 인한 비용을 통해 회수할 수 있습니다. 이러한 회수는 가상적인 것이 아닙니다. 발견되지 않은 종속성으로 인해 발생하는 모든 프로덕션 장애는 변경이 이루어지기 전에 분석이 이루어지지 않은 데 따른 직접적인 비용입니다.