컬럼 이름 변경에는 30초가 걸립니다. 마이그레이션 스크립트는 1분 만에 완료됩니다. 스테이징 환경 배포는 오류 없이 통과합니다. 프로덕션 환경 배포도 오류 없이 통과합니다. 그런데 3시간 후, Java 서비스가 잘못된 형식의 응답을 반환하고, COBOL 배치 작업이 SQL 오류로 비정상 종료되고, 하위 보고 파이프라인이 레코드 로드를 중단했다는 모니터링 경고가 발생합니다. 컬럼 이름이 변경된 것입니다. 그런데 아무도 애플리케이션에 이 사실을 알리지 않았습니다.
이는 가상적인 상황이 아닙니다. 현대 정보 시스템은 데이터베이스를 중심으로 다양한 소프트웨어 애플리케이션이 의존하는 구조입니다. 엔터프라이즈 애플리케이션 통합 환경에서는 여러 독립적인 업체에서 제공하는 애플리케이션들이 데이터베이스를 공유하며, 이러한 애플리케이션 개발자들은 데이터베이스 스키마가 시간이 지남에 따라 어떻게 변화하는지에 대해 거의 또는 전혀 제어할 수 없는 경우가 많습니다. 데이터베이스와 소프트웨어 애플리케이션은 항상 동기화된 상태를 유지하지 못할 수 있으며, 이러한 불일치는 데이터 손실, 프로그램 오류 및 성능 저하로 이어집니다. 해결책은 릴리스 프로세스를 늦추는 것이 아닙니다. 마이그레이션 스크립트를 실행하기 전에 완벽한 영향 분석을 수행하는 것입니다.
스키마 변경 전에 모든 종속 항목을 파악하세요
SMART TS XL 마이그레이션 스크립트가 실행되기 전에 모든 애플리케이션, 파이프라인 및 언어 간 종속성을 매핑합니다.
자세히 알아보세요…모든 스키마 변경이 동일한 것은 아닙니다.
스키마 영향 분석의 첫 번째 단계는 제안된 변경 사항을 분류하는 것입니다. 테이블에 선택적 열을 추가하는 변경은 기존 열의 이름을 바꾸는 변경과 근본적으로 다릅니다. 두 변경 모두 동일한 ALTER TABLE 구문을 사용하지만, 전자는 하위 호환성을 유지하는 반면 후자는 원래 열 이름을 참조하는 모든 사용자에게 호환성을 깨뜨립니다.
호환성을 깨뜨리는 변경 사항은 소비자의 별도 조치 없이 기존 소비자에 오류를 발생시킵니다. 이러한 변경을 위해서는 조정된 배포가 필요하며, 모든 종속 구성 요소는 스키마 변경 전 또는 동시에 업데이트되어야 하거나, 소비자를 먼저 업데이트한 후 스키마가 따라잡을 때까지 호환성 계층 뒤에 배포해야 합니다.
호환성을 유지하는 변경 사항은 이전 버전과 호환됩니다. 기존 사용자는 변경 없이 계속 사용할 수 있습니다. 새로운 사용자는 필요에 따라 새로운 스키마 요소를 활용할 수 있습니다.
분류는 분석 범위, 필요한 배포 조정 및 롤백 복잡성을 결정합니다.
| 유형 변경 | 파괴 | 주요 영향 대상 | 위험 수준 |
|---|---|---|---|
| null 허용 열을 추가합니다. | 아니 | 새 코드만 해당 | 높음 |
| 기본값 없이 NOT NULL 열을 추가합니다. | 가능 | 모든 INSERT 문 | 결정적인 |
| 열 이름 변경 | 가능 | 이를 참조하는 모든 SELECT, INSERT, UPDATE 문 | 결정적인 |
| 열 삭제 | 가능 | 어디에 있든 모든 참조 | 결정적인 |
| 데이터 형식을 확장합니다(INT에서 BIGINT로). | 일부의 | 필드 길이 또는 유형을 확인하는 앱 | 중급 |
| 제한된 데이터 형식(VARCHAR 500~100) | 가능 | 앱이 새로운 제한보다 더 오랫동안 값을 저장하는 경우 | 높음 |
| 색인 추가 | 아니 | 성능 분석 전용이며, 쿼리는 계속 유효합니다. | 높음 |
| 드롭 인덱스 | 일부의 | 쿼리 성능에는 영향을 미치지만 정확성에는 영향을 미치지 않습니다. | 중급 |
| 테이블 이름 바꾸기 | 가능 | 어디에 있든 모든 참조 | 결정적인 |
| 외래 키 제약 조건을 추가합니다. | 일부의 | 기존 데이터는 제약 조건을 충족해야 합니다. | 중간 고 |
| nullable을 NOT NULL로 변경하세요 | 가능 | 앱이 해당 열에 NULL 값을 삽입합니다. | 높음 |
| 저장 프로시저 서명 수정 | 가능 | 절차에 참여한 모든 사람 | 결정적인 |
| 드롭 저장 프로시저 | 가능 | 절차에 참여한 모든 사람 | 결정적인 |
| 뷰 이름 변경 | 가능 | 그 견해의 모든 소비자 | 결정적인 |
| 보기 정의 변경 | 일부의 | 해당 칼럼의 소비자 | 중간 고 |
배포 규칙: 모든 중요 변경 사항은 배포 전에 종속 항목 목록을 완벽하게 작성해야 합니다. 모든 고위험 변경 사항은 단계별 배포를 통해 각 단계에서 검증을 거쳐야 합니다. 모든 중간 위험 변경 사항은 최소한 주요 영향 대상에 대한 검토를 거쳐야 합니다. 저위험 변경 사항은 표준 테스트를 통해 배포할 수 있지만, 변경 사항을 기록해야 합니다.
스키마가 삶에 영향을 미치는 네 가지 의존성 계층
스키마 변경 영향 분석에서 가장 중대한 실수는 이를 단순히 데이터베이스 문제로만 취급하는 것입니다. 컬럼 이름 변경의 영향은 데이터베이스 자체를 넘어 네 가지 계층에 걸쳐 있으며, 각 계층을 열거하기 위해서는 서로 다른 분석 기법이 필요합니다.
1단계: 데이터베이스 내부 종속성
가장 눈에 잘 띄는 계층입니다. 데이터베이스 자체 내에서 스키마 변경은 다음과 같은 영향을 미칠 수 있습니다.
변경된 테이블에서 SELECT 문을 사용하는 뷰 . 이름이 변경된 열을 SELECT 목록에 포함하는 뷰는 뷰가 구체화되었는지 여부에 따라 이름 변경 후 오류가 발생하거나 잘못된 결과가 반환될 수 있습니다.
SELECT, INSERT, UPDATE 또는 DELETE 문에서 해당 열을 참조하는 저장 프로시저 및 함수 .
테이블에 INSERT 또는 UPDATE 문이 삽입될 때 실행되고, 로직에서 특정 열 이름을 참조하는 트리거입니다 .
해당 열을 이름으로 참조하는 제약 조건 및 계산 열을 확인하십시오 .
컬럼 삭제로 인해 무효화될 수 있는 외래 키 관계 .
이러한 종속성은 데이터베이스 카탈로그에서 직접 쿼리할 수 있습니다. SQL Server는 다음을 제공합니다. sys.sql_dependencies sys.dm_sql_referenced_entitiesPostgreSQL은 다음을 제공합니다. pg_depend오라클은 제공합니다. ALL_DEPENDENCIES아래 쿼리는 특정 테이블 및 열에 대한 데이터베이스 내부 종속 항목을 나열합니다.
SQL
-- SQL Server: all objects referencing a specific column
SELECT
OBJECT_NAME(d.object_id) AS dependent_object,
o.type_desc AS object_type,
OBJECT_NAME(d.referenced_major_id) AS referenced_table,
COL_NAME(d.referenced_major_id,
d.referenced_minor_id) AS referenced_column
FROM sys.sql_dependencies d
JOIN sys.objects o ON o.object_id = d.object_id
WHERE d.referenced_major_id = OBJECT_ID('dbo.Customers')
AND d.referenced_minor_id = COLUMNPROPERTY(
OBJECT_ID('dbo.Customers'), 'CustomerName', 'ColumnId')
ORDER BY o.type_desc, dependent_object;SQL
-- PostgreSQL: views and functions depending on a specific column
SELECT
dep.classid::regclass AS dependency_type,
dependent.relname AS dependent_object,
a.attname AS referenced_column,
source.relname AS source_table
FROM pg_depend dep
JOIN pg_class source ON source.oid = dep.refobjid
JOIN pg_class dependent ON dependent.oid = dep.objid
JOIN pg_attribute a ON a.attrelid = dep.refobjid
AND a.attnum = dep.refobjsubid
WHERE source.relname = 'customers'
AND a.attname = 'customer_name';SQL
-- Oracle: full dependency chain for objects referencing a table
SELECT
name AS dependent_object,
type AS object_type,
referenced_name,
referenced_type
FROM user_dependencies
WHERE referenced_name = 'CUSTOMERS'
ORDER BY type, name;이 쿼리는 레이어 1 전체를 대상으로 하며, 레이어 2부터 4까지는 건드리지 않습니다.
2단계: 애플리케이션 코드 종속성
두 번째 계층은 대부분의 운영 장애가 발생하는 곳이며, 데이터베이스 카탈로그 쿼리를 통해서는 어떠한 가시성도 얻을 수 없습니다. 애플리케이션 코드는 다음 경로를 통해 데이터베이스와 상호 작용합니다.
Java 및 .NET 애플리케이션에서 JDBC 및 ODBC 쿼리를 사용할 때, 소스 코드에 포함된 SQL 쿼리에서 열 이름이 문자열 리터럴로 나타나는 경우.
Hibernate, Entity Framework, SQLAlchemy 및 ActiveRecord의 ORM 매핑 에서는 테이블 및 열 이름이 객체 필드에 매핑됩니다. 열 이름을 변경하려면 스키마 변경과 ORM 구성 변경이 모두 필요하며, 구성 변경이 누락되면 ORM이 새 열 이름을 이전 필드에 자동으로 매핑하여 null 값이나 매핑 오류를 발생시킵니다.
COBOL 프로그램의 내장 SQL은 COBOL 프로시저 디비전 코드의 EXEC SQL/END-EXEC 블록 내에 SQL이 나타나는 경우를 말합니다. 이는 엔터프라이즈 환경에서 가장 중요하면서도 가장 자주 간과되는 종속성 유형입니다. 해당 구문은 다음과 같습니다.
코볼
EXEC SQL
SELECT CUST-NAME, CUST-ADDR, CUST-PHONE
INTO :WS-CUST-NAME, :WS-CUST-ADDR, :WS-CUST-PHONE
FROM CUSTOMERS
WHERE CUST-ID = :WS-CUST-ID
END-EXEC이것은 SQL 문이 아니라, SQL 문이 내장된 COBOL 소스 코드입니다. 표준 SQL 종속성 도구나 데이터베이스 카탈로그 쿼리로는 이 참조를 찾을 수 없습니다. 왜냐하면 이 참조는 SQL 객체 정의가 아닌 COBOL 소스 파일에 존재하기 때문입니다. 이를 찾으려면 COBOL 소스 코드를 분석해야 합니다.
동적 SQL은 문자열 템플릿을 기반으로 구축되며, 열 이름은 런타임에 생성됩니다. 이러한 동적 SQL은 SQL 리터럴에 대한 정적 분석으로는 찾을 수 없으며, 동적 분석(테스트 환경에서 애플리케이션 실행) 또는 문자열 구성 패턴에 대한 세심한 수동 검토가 필요합니다.
GraphQL 리졸버 및 API 직렬화기 데이터베이스 열 이름을 응답 필드 이름에 매핑하는 API입니다. customerName 열에서 가져온 이름 customer_name 열 이름을 직접 매핑하는 방식은 애플리케이션의 SQL 쿼리가 업데이트되더라도 열 이름이 변경되면 작동하지 않습니다. 직렬화 매핑이 원래 이름도 참조하기 때문입니다.
3단계: ETL, 파이프라인 및 데이터 플랫폼 종속성
세 번째 계층은 변경된 테이블이나 열을 거치는 모든 데이터 이동 프로세스를 포함합니다.
ETL 작업 (사용자 지정 코드로 작성되었거나, Informatica, Talend 또는 SSIS로 관리되거나, Airflow DAG로 표현된 경우 모두 포함)은 변경된 테이블에서 데이터를 선택하여 변환하고 하위 시스템으로 로드합니다.
변경 데이터 캡처(CDC) 구성 (Debezium, Oracle GoldenGate, SQL Server CDC)은 소스 데이터베이스에서 행 수준 변경 사항을 스트리밍합니다. CDC 구성은 특정 테이블 및 열 이름을 참조하며, 열 이름이 변경되면 새 열 이름이 포함된 변경 이벤트가 생성되지만, 하위 CDC 소비자가 이를 인식하지 못할 수 있습니다.
관계형 구조를 컬럼형 형식으로 변환하는 데이터 웨어하우스 및 데이터 레이크 로드 프로세스가 있습니다. 소스에서 컬럼 이름을 변경하면 웨어하우스 스키마, 로드 스크립트, 그리고 해당 컬럼을 참조하는 모든 분석 쿼리 또는 대시보드에서도 이름을 변경해야 합니다.
Tableau 통합 문서, Power BI 데이터 세트, Looker LookML 정의와 같은 BI 도구에 포함된 보고 쿼리는 열 이름을 직접 참조하는 경우가 많습니다. 이러한 쿼리는 문서화되어 있지 않은 경우가 흔하며, 스키마 변경 후 보고서가 작동하지 않을 때 비로소 발견되는 경우가 많습니다.
4계층: 다운스트림 및 파트너 종속성
가장 바깥쪽 계층: 조직의 직접적인 통제 범위를 벗어난 시스템으로, 변경된 데이터베이스에서 파생된 데이터를 사용합니다.
외부 API 소비자 열 이름에서 매핑된 필드 이름을 포함하는 응답을 받는 경우. 공개 API에 다음이 포함되는 경우. customer_name 응답에서 해당 필드가 직접적인 열 매핑을 통해 생성되므로, 이름을 변경하면 모든 외부 소비자에 대한 API 계약이 위반됩니다.
파트너 데이터 피드 는 변경된 테이블에서 추출한 데이터를 플랫 파일, CSV 또는 XML 형식으로 수신하며, 필드 위치 또는 이름은 추출 스키마에 의해 정의됩니다.
특정 열 정의가 외부 기관과 합의된 규제 보고서 사양에 참조되는 규정 준수 및 규제 보고 시스템 .
애플리케이션 코드 종속성 찾기: 분석 기법
1계층은 카탈로그 조회를 통한 셀프 서비스 방식입니다. 2계층부터 4계층까지는 언어 및 아키텍처에 따라 서로 다른 기술이 필요합니다.
문자열 검색(빠르지만 불완전함): grep 또는 ripgrep을 사용하여 코드베이스 전체에서 테이블 이름, 열 이름 또는 둘 다를 검색합니다. 빠르고 자동화하기 쉽습니다. 동적으로 생성된 SQL을 놓치고 주석 및 문서에서 오탐을 발생시킬 수 있습니다.
세게 때리다
# Find all files referencing a specific column
rg "customer_name|CUST-NAME|customerName" \
--type java --type py --type cs --type cbl \
--glob "!**/test/**" \
-l # list files only, for scope assessment
# More precise: find SQL contexts specifically
rg "(?i)(SELECT|INSERT|UPDATE|WHERE).*customer_name" \
--type java --type pyAST 기반 분석(더 정확하고 언어별 맞춤): 소스 코드를 추상 구문 트리로 파싱하고 이를 탐색하여 SQL 문자열 리터럴, ORM 어노테이션 및 매핑 구성을 찾습니다. 문자열 검색보다 정확하지만 언어별로 별도의 분석기가 필요합니다.
의미론적 데이터 흐름 분석(가장 정확하지만 비용이 많이 드는 방식): 정적 프로그램 분석에서 데이터 흐름 분석을 사용하여 애플리케이션이 수행할 수 있는 모든 데이터베이스 상호 작용을 추출합니다. 이 기법은 IEEE의 스키마 변경 영향 분석 연구에서 정립되었으며, 데이터베이스 쿼리 구성부터 변수 할당을 거쳐 실행 시점까지 데이터를 추적하고, 완전한 리터럴 형태로 작성되지 않고 부분적으로 조합된 경우에도 SQL 열 참조를 식별합니다. 이 연구는 높은 정확도를 달성하기 위해 이 분석이 문맥에 민감해야 하며, 프로그램 분할을 통해 분석 시간을 크게 단축하면서도 완전성을 유지할 수 있음을 보여줍니다.
실질적인 권장 사항: 신속한 범위 평가를 위해 문자열 검색을 활용하십시오. 중요한 변경 사항을 적용하기 전에 권위 있는 열거를 위해 AST 또는 의미 분석을 사용하십시오. 문자열 검색에만 의존하여 열 이름 변경이나 열 삭제를 배포하지 마십시오. 오탐 위험이 너무 높습니다.
다국어 엔터프라이즈 환경에서 스키마의 영향
일반적인 최신 웹 애플리케이션(Java 백엔드, React 프런트엔드, PostgreSQL 데이터베이스)에서 스키마 변경의 종속성 범위는 애플리케이션 소스 코드로 제한됩니다. 열 이름 변경은 Java 레이어의 SQL 문자열과 직렬화기의 API 필드 매핑에 영향을 미칩니다. 둘 다 동일한 코드베이스에서 검색하여 찾을 수 있습니다.
기존 메인프레임 시스템을 사용하는 기업 환경은 모든 면에서 서로 다릅니다. 금융 기관의 핵심 뱅킹 시스템에 있는 DB2 컬럼은 다음과 같은 곳에서 참조될 수 있습니다.
- SQL이 내장된 COBOL 프로그램으로 일일 계좌 거래를 처리합니다.
- 컬럼 레이아웃에 매핑되는 추출 파일을 생성하는 JCL 작업 단계
- 열을 참조하는 저장 프로시저를 호출하는 Java 마이크로서비스
- JDBC를 통해 DB2에 직접 쿼리하여 보고서를 생성하는 Python 데이터 파이프라인
- BI 도구에서 경영진 대시보드에 사용되는 SQL 뷰
- 터미널 화면에 열 값을 표시하는 CICS 트랜잭션 프로그램
이러한 참조는 서로 다른 5개 언어로 작성되었고, 3개의 서로 다른 런타임 환경(메인프레임, 클라우드, BI 플랫폼)에서 관리되며, 서로 직접 소통하지 않는 팀들이 유지 보수합니다. 데이터베이스 팀과 Java 서비스 팀 간에 합의된 열 이름 변경 사항이 COBOL 팀, 보고 팀, BI 팀에게는 시스템 오류가 발생하기 전까지 알려지지 않을 수도 있습니다.
정적 프로그램 분석 기법은 데이터 흐름 분석을 통해 가능한 모든 데이터베이스 상호 작용을 추출함으로써 관계형 데이터베이스 스키마 변경이 객체 지향 애플리케이션에 미치는 영향을 파악합니다. 동일한 원리를 COBOL, JCL, Python 및 SQL에 동시에 적용하여 COBOL 소스 코드에 포함된 SQL, JCL 프로그램의 EXEC SQL 블록, Python 스크립트의 매개변수화된 쿼리, 데이터베이스의 SQL 객체를 분석함으로써 언어 간 스키마 변경 영향 분석을 용이하게 하는 완전한 언어 간 종속성 맵을 생성할 수 있습니다.
CI/CD 통합: 영향 분석 자동화
스키마 변경 전에 수동으로 영향 분석을 하는 것은 분석을 전혀 하지 않는 것보다 낫습니다. 하지만 CI/CD 게이트로서 자동화된 영향 분석을 수행하는 것이 수동 분석보다 훨씬 효과적입니다. 자동화된 분석은 개발자의 자율적인 관리 없이도 매번 실행되며, 분석이 완료되지 않은 경우 배포를 차단합니다.
얌
# GitHub Actions: schema impact gate
name: Schema Change Impact Analysis
on:
pull_request:
paths:
- 'migrations/**'
- 'schema/**'
- '**/*.sql'
jobs:
schema-impact:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Detect schema changes
id: detect
run: |
git diff origin/main...HEAD -- migrations/ schema/ \
> schema_changes.diff
# Classify: any breaking changes?
if grep -qiE \
"DROP COLUMN|RENAME|ALTER.*NOT NULL|DROP TABLE|DROP PROCEDURE" \
schema_changes.diff; then
echo "breaking=true" >> $GITHUB_OUTPUT
echo "Breaking schema changes detected"
else
echo "breaking=false" >> $GITHUB_OUTPUT
fi
- name: Block on breaking change without impact sign-off
if: steps.detect.outputs.breaking == 'true'
run: |
# Check for required impact analysis label on PR
if ! gh pr view ${{ github.event.pull_request.number }} \
--json labels --jq '.labels[].name' \
| grep -q "impact-analysis-complete"; then
echo "ERROR: Breaking schema change requires impact-analysis-complete label"
echo "Complete the impact analysis checklist before merging"
exit 1
fi
env:
GH_TOKEN: ${{ github.token }}
- name: Run catalog dependency check
run: |
psql ${{ secrets.DB_URL }} -f scripts/check_dependencies.sql \
| tee dependency_report.txt
if grep -q "DEPENDENT_COUNT > 0" dependency_report.txt; then
echo "Dependents found -- review dependency_report.txt"
fi위의 게이트는 세 가지 작업을 수행합니다. 첫째, 호환성을 깨뜨리는 변경 패턴이 있는지 감지합니다. 둘째, 병합이 허용되기 전에 검토자가 영향 분석을 완료하고 레이블을 지정해야 합니다. 셋째, 카탈로그 종속성 쿼리를 실행하여 데이터베이스 내부 종속성을 열거합니다. 레이블 지정 요구 사항은 핵심적인 인적 검토 단계이며 파이프라인에서 건너뛸 수 없습니다. 즉, 코드가 병합되기 전에 영향 분석이 수행되고 문서화되어야 합니다.
완벽한 스키마 영향 보고서에 포함되는 내용
스키마 영향 분석 결과는 변경 자문 위원회, 아키텍트 및 DBA가 배포를 승인하는 데 사용할 수 있는 구조화된 보고서입니다. 전체 보고서에는 다음 내용이 포함됩니다.
1. 제안된 변경 사항 정의 , 사용될 정확한 DDL 문, 영향을 받는 테이블 및 열, 그리고 변경 사유.
2. 위험 분류 체계에 따른 변경 분류 : 변경 사항의 심각성 여부, 위험 수준, 그리고 구체적인 영향 범주(데이터 손실 위험, 쿼리 실패 위험, 성능 위험).
3. 데이터베이스 내부 종속 항목 , 즉 카탈로그 쿼리의 출력: 변경된 개체를 참조하는 모든 뷰, 저장 프로시저, 함수 및 트리거와 해당 개체의 현재 정의 및 필요한 변경 사항.
4. 애플리케이션 코드 종속성 목록 (언어별, 파일 경로, 가능한 경우 줄 번호, 발견된 특정 SQL 참조 포함). 코드베이스를 관리하는 팀이 여러 개인 경우 팀 또는 서비스별로 정리합니다.
5. ETL 및 파이프라인 종속 항목은 파이프라인 이름, 작업 및 변경된 열 또는 테이블에 대한 특정 참조를 기준으로 합니다.
6. 시스템 이름, 데이터 피드 또는 API 계약별로 하위 시스템 및 파트너 종속 항목을 나열하고, 하위 시스템 인터페이스에 표시되는 필드 이름을 지정합니다.
7. 종속 항목별 필수 변경 사항: 발견된 각 종속 항목에 대해 스키마 변경 배포 후 정확성을 유지하기 위해 필요한 구체적인 변경 사항입니다.
8. 배포 순서 , 일관성을 유지하기 위해 종속 항목을 업데이트하고 스키마 변경을 배포해야 하는 순서. 일반적으로 호환성을 깨뜨리는 변경에는 다음이 필요합니다. (1) 호환성 계층 또는 기본값 배포, (2) 모든 애플리케이션 코드를 새 열 이름을 참조하도록 업데이트, (3) 애플리케이션 코드 배포, (4) 유효성 검사, (5) 스키마 변경 배포, (6) 유효성 검사, (7) 호환성 계층 제거.
9. 필수 테스트 케이스: 종속 유형당 하나의 유효성 검사 테스트와 수정된 저장 프로시저에 대한 회귀 테스트가 필요합니다.
10. 롤백 계획 , 역방향 DDL 및 배포를 되돌려야 하는 경우 이전 스키마 상태를 복원하는 데 필요한 모든 데이터 마이그레이션.
보고 체계: 영향 보고서가 존재하지만 조치가 취해지지 않는 것은 보고서가 없는 것보다 더 나쁩니다. 이는 실사를 수행한 것처럼 보이지만 실제 위험은 완화되지 않은 채로 남게 됩니다. 종속 항목 목록의 모든 항목은 배포 전에 업데이트되거나, 비상 계획을 수립하여 알려진 위험으로 명시적으로 인정되어야 합니다.
방법 SMART TS XL 언어 간 스키마 영향 분석을 제공합니다.
표준 데이터베이스 카탈로그 쿼리는 데이터베이스 내의 뷰, 저장 프로시저 및 트리거와 같은 1계층 종속 요소를 열거합니다. 애플리케이션 코드 검색 도구는 단일 언어 내에서 일부 2계층 종속 요소를 열거합니다. 모든 언어에 걸쳐 네 가지 계층 모두를 포괄하는 단일 도구는 없습니다.
SMART TS XL의 정적 코드 분석 COBOL 소스 파일의 내장 SQL, Java 서비스의 JDBC 쿼리 문자열, Python 파이프라인의 SQLAlchemy 모델 및 SQL 객체 정의를 동시에 구문 분석합니다. DB2 열의 이름 변경이 제안될 때, SMART TS XL 이 분석 도구는 전체 다국어 포트폴리오에서 해당 열을 참조하는 모든 COBOL EXEC SQL 블록, 열 이름을 포함하는 모든 Java JDBC 쿼리 문자열, 해당 열을 사용하는 모든 Python 쿼리, 그리고 해당 열을 참조하는 모든 SQL 뷰 또는 저장 프로시저를 한 번의 분석으로 식별합니다.
애플리케이션 종속성 매핑은 직접적인 열 참조를 넘어 구조적 종속성 체인까지 분석 범위를 확장합니다. 예를 들어 Java 서비스가 변경된 열을 참조하는 저장 프로시저를 호출하는 경우, 종속성 맵은 Java 서비스와 프로시저 간의 종속성 및 프로시저와 열 간의 종속성을 모두 나타내므로, Java 서비스 코드에 직접적인 열 참조가 없더라도 영향 범위에서 해당 서비스를 확인할 수 있습니다.
영향 분석 기능은 이러한 언어 간 종속성 그래프를 적용하여 모든 스키마 변경에 앞서 제기되는 특정 질문에 답합니다. 즉, 제안된 변경 사항이 적용될 때 모든 언어와 모든 계층에서 영향을 받는 모든 구성 요소를 열거하는 것입니다. 그 결과는 추정치나 개발자의 기억에 의존한 영향 요소가 아니라 실제 코드에서 도출된 구조화된 열거형 목록으로, 위의 영향 보고서 템플릿에 직접 매핑됩니다.
엔터프라이즈 검색 기능을 통해 변경 관리 수명 주기 전반에 걸쳐 종속성 목록을 쿼리할 수 있습니다. COBOL, Java, Python 및 SQL을 포함한 수백만 줄의 코드에서 특정 열을 참조하는 모든 프로그램을 동시에 몇 초 만에 찾을 수 있습니다.
다양한 환경에서 스키마 변경을 관리하는 팀을 위한 레거시 현대화 데이터베이스를 현대화 대상인 COBOL 메인프레임 애플리케이션과 이를 대체하는 최신 Java 서비스 간에 공유하는 프로그램의 경우, 언어 간 영향 분석은 필수적입니다. 현대화 전환 과정에서 레거시 시스템과 최신 시스템이 동시에 운영됩니다. Java 서비스 관점에서는 문제가 없는 스키마 변경이라도 함께 실행되는 COBOL 프로그램에서는 인식되지 않을 수 있습니다. SMART TS XL 그 경계의 양쪽을 동시에 본다.
스키마 변경 자체는 애플리케이션을 손상시키지 않습니다. 분석되지 않은 스키마 변경은 문제를 일으킵니다.
이 가이드 초반에 나오는 배포 실패 사례, 즉 Java 서비스, COBOL 배치 작업, 그리고 보고 파이프라인을 가동 3시간 만에 작동 불능 상태로 만든 열 이름 변경 문제는 마이그레이션 스크립트 자체에는 문제가 없었습니다. 스크립트는 올바르게 실행되었고, 열 이름도 의도한 대로 정확하게 변경되었습니다. 문제는 그 전에 수행되었어야 할 분석 작업, 즉 원래 열 이름을 참조하는 모든 애플리케이션을 열거하고, 각 애플리케이션이 업데이트되었는지 확인하고, 배포 순서가 데이터베이스와 모든 사용자 간의 일관성을 유지했는지 검증하는 작업에 있었습니다.
스키마 영향 분석은 단순한 형식적인 절차가 아닙니다. 이는 변경 사항의 불확실한 범위를 영향을 받는 모든 항목의 열거 가능하고 검증 가능한 목록으로 변환하여 위험한 배포를 안전한 배포로 전환하는 작업입니다. 마이그레이션 스크립트는 단 몇 분이면 완료되지만, 영향 분석에는 필요한 만큼의 시간이 소요됩니다. 하지만 이를 통해 예방되는 운영 환경 장애는 며칠이 걸릴 수도 있습니다.
