수십 년에 걸친 데이터 시스템을 위한 메타데이터 관리

필드 TRANS-AMT-CD COBOL 프로그램으로 작성된 이 문서는 1981년부터 생산에 사용되었습니다. FD 항목에서는 이를 다음과 같이 정의합니다. PIC S9(9)V99 COMP-3TRANS-AMT-CD는 11자리 숫자로 구성된 부호 있는 숫자 필드이며, 소수점 이하 두 자리가 암시적으로 표시됩니다. 이것이 기술적 메타데이터입니다. 하지만 비즈니스 메타데이터, 즉 TRANS-AMT-CD가 실제로 무엇을 의미하는지, 어떤 통화로 표시되는지, 암시적인 소수점 두 자리가 센트를 의미하는지 베이시스 포인트를 의미하는지, 음수 값이 크레딧을 나타내는지 데빗을 나타내는지, 그리고 0 값을 어떻게 해석해야 하는지에 대한 정보는 코드베이스 어디에도 존재하지 않습니다. 이 정보는 1981년에 인쇄되어 서류 캐비닛에 보관된 기능 사양 문서에만 존재했으며, 그 이후로는 다시 볼 수 없었습니다. TRANS-AMT-CD의 의미를 최초로 알고 있던 두 개발자는 모두 2014년에 은퇴했습니다.

이는 수십 년 된 데이터 시스템을 보유한 모든 조직이 직면하는 메타데이터 문제이며, 최신 데이터 거버넌스 프레임워크가 해결하도록 설계되지 않은 문제이기도 합니다. Collibra, Alation, Atlan을 비롯한 모든 엔터프라이즈 데이터 카탈로그 플랫폼은 이미 기술된 데이터, 즉 문서화된 스키마를 가진 클라우드 데이터베이스, 정의된 열 의미론을 가진 데이터 웨어하우스, OpenAPI 사양을 갖춘 API 엔드포인트에 대한 메타데이터 관리에는 탁월합니다. 하지만 이러한 플랫폼은 공식적으로 기록되지 않았고, 메타데이터 관리가 하나의 분야로 자리 잡기 전에 작성된 프로그램의 동작에만 존재하며, 40년 동안 수십 명의 개발자가 수정했지만 각 필드의 의미를 중앙 기록으로 업데이트한 사람이 아무도 없는 메타데이터를 재구성하도록 설계되지 않았습니다.

수십 년 된 데이터 시스템의 메타데이터 관리는 최신 시스템의 메타데이터 관리와는 다른 문제입니다. 근본적으로 다른 접근 방식이 필요하며, 연결된 시스템에서 메타데이터를 수집하는 것이 아니라 원본 아티팩트에서 메타데이터를 추출하는 것부터 시작해야 합니다.

기존 메타데이터의 세 가지 계층

수십 년에 걸쳐 운영되어 온 시스템의 메타데이터 문제를 이해하려면 이러한 환경의 메타데이터가 추출 가능성, 완전성 및 거버넌스 측면에서 각각 다른 세 가지 계층으로 존재한다는 점을 인식해야 합니다.

기술 메타데이터는 추출하기 가장 쉬운 계층입니다. 이는 데이터의 물리적 구조, 즉 필드 이름, 데이터 유형, 길이, 레코드 내 위치, 숫자 정밀도 사양, 레코드 레이아웃 내 필드 간의 관계 등을 설명합니다. COBOL 환경에서 기술 메타데이터는 소스 코드 아티팩트에 존재합니다. FD 항목은 레코드 레이아웃을 정의하고, COPY 멤버는 재사용 가능한 데이터 구조를 정의하며, SELECT 절은 파일 구성 및 접근 방식을 정의하고, JCL DD 문은 각 프로그램 실행과 관련된 데이터 세트를 정의합니다. 원칙적으로 이 계층은 기계가 읽을 수 있으며, COBOL 구문을 이해하는 파서는 소스 코드에서 추출할 수 있지만, 스키마 레지스트리에 중앙 집중화되어 있지 않고 수천 개의 소스 파일에 분산되어 있습니다.

운영 메타데이터는 시스템에서 데이터가 어떻게 이동하는지, 즉 어떤 프로그램이 어떤 데이터 세트를 생성하고, 어떤 프로그램이 어떤 순서로 어떤 변환 과정을 거쳐 이를 소비하는지를 설명합니다. 메인프레임 환경에서 운영 메타데이터는 JCL 작업 스트림(실행 순서 및 데이터 세트 연결 정의), 프로그램 호출 그래프(프로그램 간 데이터 흐름 정의), 스케줄러 구성(타이밍 및 종속성 정의)에 분산되어 있습니다. 이 계층은 소스 아티팩트에서 기계적으로 추출할 수 있지만, 추출을 위해서는 개별 프로그램뿐만 아니라 프로그램 간의 관계에 대한 이해가 필요합니다.

비즈니스 또는 의미론적 메타데이터 가장 추출하기 어렵지만 가장 가치 있는 계층입니다. 기술적 메타데이터로는 답할 수 없는 질문, 즉 '무엇을'이라는 질문에 답을 제시합니다. TRANS-AMT-CD 비즈니스 관점에서 실제로 의미하는 바는 무엇인가요? 의 유효한 값은 무엇인가요? ACCT-TYPE-CD 각 값은 무엇을 의미합니까? 어떤 비즈니스 규칙이 언제 값을 결정하는가? CUST-STATUS-FLG 전환 A 에 I이 계층은 존재한다면 명세 문서, 개발자의 기억, 은퇴한 직원들이 보유한 조직적 지식, 그리고 데이터베이스 제약 조건이 아닌 IF 문과 EVALUATE 블록을 통해 비즈니스 규칙을 적용하는 프로그램의 절차적 논리에 존재합니다.

수십 년에 걸쳐 발전해 온 시스템의 메타데이터 관리에서 가장 큰 어려움은 세 가지 계층(기술, 운영, 비즈니스)이 시스템 진화 과정에서 각기 다른 방식으로 관리되었거나 아예 관리되지 않았다는 점입니다. 기술 메타데이터는 소스 코드에 기록되었지만, 공식적인 데이터 사전으로 정립된 적은 없습니다. 운영 메타데이터는 JCL 작업 스트림에 암묵적으로 존재했지만, 계보 기록으로 문서화되지는 않았습니다. 비즈니스 메타데이터는 초기 개발 당시 명세서에 문서화되었지만, 시스템이 발전함에 따라 업데이트되지 않았습니다.

메타데이터 드리프트 문제

체계적인 메타데이터 관리 없이 수십 년간 운영되는 시스템은 매년 공식 문서에 존재하는 메타데이터와 시스템의 실제 현재 동작을 반영하는 메타데이터 간의 격차가 커집니다. 이러한 차이는 다음 네 가지 메커니즘을 통해 발생합니다.

분야는 진화를 의미합니다. 1978년에 하나의 사업적 의미로 정의되었던 분야가 이후 수십 년에 걸쳐 추가적인 의미를 축적해 왔을 수도 있습니다. ACCT-TYPE-CD 원래는 당좌예금과 저축예금을 구분하기 위해 사용되었을 수 있습니다. 40여 년에 걸쳐 머니마켓 계좌, 예금증서, IRA 계좌, 에스크로 계좌 등을 나타내는 추가 코드가 추가되었을 수 있으며, 각 추가 사항은 중앙 필드 정의가 아닌 해당 코드 값을 처리하는 프로그램 코드에만 기록됩니다. 필드의 이름과 유형은 변경되지 않았지만, 그 의미는 상당히 복잡해졌습니다.

조용한 용도 변경. 필드는 이름 변경 없이 용도가 변경되는 경우가 있습니다. 특정 용도로 사용되던 필드를 확장하기가 불편해지면, 개발자는 인접한 플래그 필드의 이전에 사용되지 않았던 값을 활용하여 다른 정보를 인코딩할 수 있습니다. TRANS-FLAG-1 이제 서로 다른 프로그램 컨텍스트에서 세 가지 다른 개념을 인코딩할 수 있으며, 이는 어떤 프로그램이 어떤 조건에서 해당 필드를 읽는지 살펴봐야만 구별할 수 있습니다. 기술 메타데이터(필드 이름, 유형, 길이)는 필드가 의미적으로 과부하되었다는 것을 나타내지 않습니다.

REDEFINES 누적. VSAM 분석 컨텍스트에서 논의된 바와 같이, REDEFINES 절은 동일한 물리적 저장소에 서로 다른 필드 해석을 적용하여 중첩됩니다. 각 REDEFINES 변형은 시스템 이력의 서로 다른 시점에, 서로 다른 개발자에 의해, 서로 다른 비즈니스 목적으로 추가되었을 수 있습니다. REDEFINES 계층 구조의 완전한 의미, 즉 어떤 변형이 언제 적용되는지, 각 변형의 필드가 무엇을 의미하는지는 각 변형에 접근하는 모든 프로그램과 그 접근 조건을 분석해야만 재구성할 수 있습니다.

COBOL 카피북의 버전 차이. 표준 COBOL 카피북이 새로운 요구 사항을 수용하도록 수정될 경우, 해당 카피북을 포함하고 있지만 새 필드를 처리하도록 업데이트되지 않은 프로그램은 잘못 동작하거나 새 필드를 무시할 수 있습니다. 수십 년에 걸친 발전 과정에서 명목상 동일한 카피북이라도 여러 버전이 서로 다른 라이브러리에 존재하고, 각 프로그램이 서로 다른 버전을 사용하는 경우가 발생할 수 있습니다. 카피북에 정의된 필드의 메타데이터는 각 프로그램이 포함하는 카피북 버전에 따라 프로그램마다 다를 수 있습니다.

최신 메타데이터 도구가 기존 데이터에 대해 할 수 없는 일

기업 데이터 카탈로그 시장은 상당한 성숙기에 접어들었습니다. Collibra, Alation, Atlan, Microsoft Purview, Informatica Axon은 최신 데이터 환경 전반에 걸쳐 메타데이터를 관리하는 정교한 플랫폼입니다. 이 플랫폼들은 연결된 데이터베이스에서 스키마를 자동으로 검색하고, ETL 파이프라인에서 열 수준의 데이터 계보를 추적하며, 엄선된 용어 정의를 통해 비즈니스 용어집을 유지하고, 메타데이터 레코드와 함께 데이터 품질 지표를 제공하는 데 탁월합니다.

이러한 도구들이 수십 년 된 COBOL 및 메인프레임 시스템에 대해서는 할 수 없는 일:

카탈로그는 보이지 않는 것에는 연결할 수 없습니다. 최신 카탈로그는 커넥터, 데이터베이스와의 JDBC 연결, 클라우드 서비스와의 API 통합, 지원되는 플랫폼과의 스캐너 통합 등을 통해 메타데이터를 검색합니다. 하지만 VSAM 파일, COBOL 프로그램, JCL 작업 스트림에는 표준 카탈로그 커넥터가 없습니다. 따라서 카탈로그는 접근할 수 있는 메커니즘이 없는 것을 검색할 수 없습니다. 이러한 시스템에서 관리되는 데이터는 사실상 카탈로그에서 보이지 않기 때문에, 이 데이터에서 파생되는 하위 클라우드 분석을 위한 데이터 계보 기록이 불완전하거나 아예 존재하지 않습니다.

데이터 카탈로그는 코드에만 존재하는 메타데이터를 추출할 수 없습니다. DB2 데이터베이스에 연결된 데이터 카탈로그는 데이터베이스 스키마, 테이블 정의, 열 이름, 데이터 유형, 인덱스를 읽을 수 있습니다. 하지만 DB2 테이블에 데이터를 채우는 COBOL 프로그램을 읽어서 어떤 비즈니스 규칙이 데이터 입력에 적용되는지, 원본 레코드에 어떤 REDEFINES 변형이 있는지, 또는 88단계 조건 이름이 각 필드의 의미적 유효성을 정의하는지 등을 파악할 수는 없습니다. 레거시 데이터의 비즈니스 의미가 실제로 존재하는 코드 수준의 메타데이터는 카탈로그 스캔이 아닌 코드 분석을 통해 추출할 수 있습니다.

기록되지 않은 의미는 재구성할 수 없습니다. 완벽한 기술적 메타데이터 추출이 이루어지더라도 공식적으로 문서화되지 않은 필드의 비즈니스 의미는 자동으로 재구성할 수 없습니다. 이러한 계층에서는 코드 분석(프로그램이 데이터에 적용하는 비즈니스 규칙, 즉 비즈니스 의미를 나타내는 지표를 파악하기 위해)과 사람 검토(기존의 지식이 여전히 존재하는 동안 재구성된 의미를 기관 지식과 비교하여 검증하기 위해)를 결합해야 합니다.

메타데이터 재구성 접근법

수십 년 된 시스템 중 공식적인 메타데이터가 전혀 수집되지 않았거나 현재 상황과 크게 차이가 나는 경우, 메타데이터 관리에는 거버넌스 단계에 앞서 재구성 단계가 필요합니다. 재구성 접근 방식은 복구 가능한 계층을 추출하고 인간의 전문 지식이 필요한 공백을 식별합니다.

1단계: 소스 아티팩트에서 기술 메타데이터 추출.

모든 COBOL 필드 함수 항목, COPY 멤버, SELECT 절 및 JCL DD 문을 구문 분석하여 필드 수준의 기술 메타데이터 목록을 생성합니다.

코볼

* Source FD entry -- technical metadata extraction target
FD  TRANSACTION-FILE
    LABEL RECORDS ARE STANDARD
    RECORD CONTAINS 200 CHARACTERS.
01  TRANSACTION-RECORD.
    05  TRANS-DATE          PIC 9(8).          *> YYYYMMDD format
    05  TRANS-TYPE-CD       PIC XX.            *> See 88-level values
        88 TRANS-PAYMENT    VALUE 'PM'.
        88 TRANS-REFUND     VALUE 'RF'.
        88 TRANS-ADJUSTMENT VALUE 'AJ'.
        88 TRANS-REVERSAL   VALUE 'RV'.
    05  TRANS-AMT-CD        PIC S9(9)V99 COMP-3.
    05  TRANS-CURRENCY-CD   PIC X(3).          *> ISO 4217
    05  TRANS-DETAIL        REDEFINES TRANS-TYPE-CD.
        10  TRANS-MERCH-ID  PIC X(12).
        10  TRANS-AUTH-CD   PIC X(6).
        10  FILLER          PIC X(84).

이 단일 FD 항목에서 기술 메타데이터를 추출하면 필드 이름, 데이터 유형, 길이, 위치, 팩형 소수점 정밀도가 생성됩니다. TRANS-AMT-CD (9자리 숫자, 소수점 이하 2자리, 부호 있음), 네 가지 의미 값 TRANS-TYPE-CD 88단계 조건 이름에 의해 정의된 대로, 그리고 레코드의 10~105번째 바이트에 대한 두 개의 중복된 해석을 생성하는 REDEFINES 구조.

88단계 조건명은 메타데이터로서 특히 가치가 높습니다. TRANS-PAYMENT, TRANS-REFUND, TRANS-ADJUSTMENT, TRANS-REVERSAL COBOL 코드 자체에서 제공하는 비즈니스 용어 네 가지는 기본 코드보다 더 의미가 있습니다. PM, RF, AJ, RV 데이터베이스를 스캔하는 데이터 카탈로그가 보게 될 값들입니다.

2단계: 프로그램 종속성으로부터 운영 메타데이터 추출.

프로그램 종속성 그래프를 통해 데이터 흐름을 추적하여 운영 계보 지도를 구축합니다.

• 어떤 프로그램이 쓰기를 TRANSACTION-FILE (제작자)
• 어떤 프로그램이 다음에서 읽어오나요? TRANSACTION-FILE (소비자)
• JCL 작업 단계 중 어떤 단계에서 각 프로듀서와 컨슈머가 어떤 순서로 호출됩니까?
• 변환된 데이터는 어떤 하위 데이터 세트 및 데이터베이스로 전송됩니까? TRANSACTION-FILE

이 계보 지도는 데이터 카탈로그 도구가 계보 시각화를 위해 필요로 하는 운영 메타데이터이지만, 소스 프로그램 코드와 JCL에 접근하지 않고는 생성할 수 없습니다.

3단계: 의미론적 메타데이터 프록시로서의 비즈니스 규칙 추출.

COBOL 프로시저 디비전 로직에 인코딩된 비즈니스 규칙은 비즈니스 의미를 나타내는 대리자입니다. 유효성을 검사하는 프로그램은 TRANS-AMT-CD 처리 전에 특정 범위 내에 속하는지 확인하는 것은 해당 필드의 유효 범위에 대한 증거를 제공합니다. 변환 프로그램은 TRANS-AMT-CD 하위 시스템에 쓰기 전에 다른 단위로 변환하는 것은 암묵적인 소수점 또는 단위 규칙을 드러내는 것입니다.

코드 분석을 통해 이러한 비즈니스 규칙을 추출하면 추론된 의미론적 메타데이터 세트가 생성됩니다. 여기에는 각 필드에 적용되는 유효성 검사 범위, 소스와 대상 간에 발생하는 변환, 그리고 다양한 코드 경로가 실행되는 조건이 포함됩니다. 이 추론된 의미론적 메타데이터는 정확하지 않습니다. 프로그램이 데이터를 어떻게 처리하는지를 보여줄 뿐, 데이터가 원래 의도했던 의미를 반드시 나타내는 것은 아닙니다. 하지만 원래 명세 문서에서는 복구할 수 없는 방식으로 코드에서 이러한 정보를 복구할 수 있습니다.

4단계: 사람의 검증 및 의미론적 보강.

추출된 기술 및 운영 메타데이터와 추론된 의미론적 메타데이터는 도메인 전문가 및 은퇴 예정 개발자와의 인간 검증 세션의 기초가 됩니다. 목표는 추론된 의미론을 확정된 의미론으로 변환하여 다음 사항을 검증하는 것입니다. TRANS-AMT-CD 코드가 암시하는 의미를 정확히 파악하고, 코드 동작이 더 이상 의도된 비즈니스 의미를 반영하지 않는 경우를 식별하며, 코드 분석으로는 복구할 수 없는 분야 이력에 대한 기관 지식을 포착합니다.

이 단계는 해당 분야 전문가의 가용성에 따라 시간적 제약을 받습니다. 해가 갈수록 이러한 지식을 보유한 사람들이 떠나가면서 지식도 점점 더 사라지기 때문입니다.

현대 시스템 경계에서의 기존 메타데이터 격차

수십 년 된 시스템으로 인해 발생하는 메타데이터 부족 현상은 기존 환경에만 국한되지 않습니다. 이는 하위 시스템으로 전파되어, 기존 시스템의 데이터를 사용하는 모든 분석 시스템, 데이터 웨어하우스 및 머신 러닝 파이프라인이 메타데이터 부족 문제를 그대로 물려받게 됩니다.

COBOL 배치 프로그램에서 매일 밤 플랫 파일 추출을 받는 클라우드 데이터 웨어하우스의 열 정의에는 데이터 엔지니어링 팀이 ETL 파이프라인을 구축할 때 지정한 열 이름이 그대로 사용됩니다. 원래 필드가 다음과 같았다면... TRANS-AMT-CD 그리고 ETL 개발자는 대상 열의 이름을 지정했습니다. transaction_amount데이터 웨어하우스에는 열 이름, 데이터 유형, 비즈니스 설명 등 완전한 메타데이터가 카탈로그에 추가된 것으로 보입니다. 하지만 카탈로그에 기록되지 않은 것은 다음과 같습니다. transaction_amount ~로부터 기원 된 TRANS-AMT-CD in TRANSACTION-FILECOBOL 프로그램으로 생성된 것입니다. TRNSRC01JCL 작업에서 실행됩니다. TRANSDAY 매일 밤 새벽 2시에 실행되며, 1987년에 하드코딩된 특정 환율 변환 공식을 적용하는데, 이 공식은 현재에도 유효한지 여부가 불확실한 당시의 환율 관행에 기반합니다.

다운스트림 메타데이터 레코드는 완전해 보입니다. 계보는 레거시 경계에서 단절되었습니다. 출처와 의미를 이해하는 데 의존하는 모든 분석 또는 AI 워크로드는 이 문제에 직면하게 됩니다. transaction_amount 해당 값의 실제 기원에 대한 기록이 없는 공백이 있습니다.

가트너의 조사에 따르면 AI에 적합한 데이터가 부족한 AI 프로젝트의 60%가 2026년까지 중단될 것이라고 하는데, 이는 부분적으로 메타데이터와 관련된 내용입니다. AI 모델은 이러한 메타데이터를 활용합니다. transaction_amount 해당 데이터가 암시적 소수 자릿수를 가진 압축 십진수 COBOL 필드에서 유래되었고, 1987년 환율 체계를 사용하여 변환되었을 수 있는 통화로 표시된다는 사실을 알지 못한 채, 출처가 불투명한 데이터를 기반으로 학습하고 있습니다. 모델은 이러한 맥락을 인지하고 조정해야 할 필요성을 알 수 없습니다. 왜냐하면 모델이나 데이터 파이프라인이 접근할 수 있는 어떤 카탈로그에도 이러한 맥락을 알려주는 메타데이터가 존재하지 않기 때문입니다.

레거시 시스템을 위한 메타데이터 관리 프로그램 구축

수십 년에 걸친 데이터 시스템을 위한 메타데이터 관리 프로그램은 표준 엔터프라이즈 데이터 카탈로그 구현과 다른 네 가지 구성 요소를 가지고 있습니다.

구성 요소 1: 소스 코드 메타데이터 추출. 카탈로그 도구가 레거시 메타데이터를 관리하려면 먼저 메타데이터가 저장된 소스 아티팩트에서 추출해야 합니다. 이 추출에는 다음이 포함되어야 합니다. FD 항목 및 카피북(데이터 구조에 대한 기술 메타데이터), SELECT 절(파일 구성 및 액세스 방법), JCL DD 문(데이터 세트 연결 및 파일 특성), 88 레벨 조건 이름(소스 코드에 포함된 의미 값 어휘). 출력은 비즈니스 보강을 위한 시작점으로 카탈로그에 로드할 수 있는 필드 수준 메타데이터 목록입니다.

구성 요소 2: 데이터 계보 재구성. 레거시 시스템의 데이터 계보는 ETL 도구의 계보 추적이 아닌 프로그램 종속성 분석을 통해 재구성해야 합니다. 계보 맵은 데이터가 생성된 COBOL 프로그램부터 중간 변환 프로그램을 거쳐 최종 소비자(최신 분석 시스템으로 데이터를 전달하는 ETL 프로세스 포함)에 이르기까지의 경로를 추적합니다. 이러한 재구성을 통해 레거시 시스템과의 경계에서 데이터 계보의 간극을 해소하고, 문서화된 프로그램 종속성 체인을 통해 클라우드 데이터 웨어하우스의 컬럼 메타데이터와 COBOL FD 항목 메타데이터를 연결합니다.

구성 요소 3: 도메인 전문 지식을 활용한 의미론적 풍부화. 추출된 기술 메타데이터는 구조를 제공하며, 비즈니스 의미를 확인하려면 해당 분야의 전문 지식이 필요합니다. 데이터 보강 과정에서는 기술 메타데이터를 전문가 인터뷰를 위한 구조화된 질문으로 활용합니다. 예를 들어, "이 필드는 다음과 같이 정의됩니다."와 같이 질문할 수 있습니다. PIC S9(9)V99 COMP-314개 프로그램에서 음수가 아닌 것으로 검증되었고, 하위 데이터베이스에 기록하기 전에 다른 척도로 변환되는데, 이것이 무엇을 나타내는지, 그리고 변환이 무엇을 의미하는지 확인해 주시겠습니까? 이 구조화된 접근 방식은 코드 분석을 사용하여 각 전문가 상호 작용의 정보 가치를 극대화함으로써 비구조화된 문서 검토보다 더 빠르고 완벽한 정보 보강을 가능하게 합니다.

구성 요소 4: 최신 카탈로그 플랫폼과의 거버넌스 통합. 기존 메타데이터를 추출, 재구성 및 보강한 후에는 최신 메타데이터 거버넌스 인프라와 통합해야 합니다. 이 통합을 통해 기존 메타데이터 인벤토리를 엔터프라이즈 데이터 카탈로그에 연결하여 COBOL 소스에서 클라우드 대상으로의 열 수준 계보, 기존 필드 정의에 연결된 비즈니스 용어집 용어, 그리고 최신 시스템 메타데이터와 동일한 거버넌스 프레임워크를 채우는 기존 데이터 세트용 데이터 품질 메타데이터를 제공합니다.

방법 SMART TS XL 기존 메타데이터를 추출합니다

SMART TS XL 이 프로젝트는 COBOL, JCL 및 카피북 포트폴리오 전체에 정적 분석을 적용하여 기존 메타데이터 관리 프로그램의 첫 두 구성 요소인 소스 코드 메타데이터 추출 및 계보 재구성을 해결합니다.

정적 코드 분석 기능은 COBOL 포트폴리오 전체의 모든 함수 선언(FD) 항목, COPY 멤버, SELECT 절 및 88레벨 정의를 구문 분석하여 필드 수준의 기술 메타데이터 목록을 생성합니다. 이 목록에는 환경 내 모든 프로그램과 카피북의 필드 이름, 데이터 유형, 길이, COMP 사양, REDEFINES 멤버십 및 88레벨 조건 이름이 포함됩니다. 수천 개의 COBOL 프로그램으로 구성된 포트폴리오의 경우, 이 추출 기능을 사용하면 수 시간 내에 기술 메타데이터 목록을 생성할 수 있으며, 이는 수동으로 문서를 작성할 경우 수년이 걸리거나 아예 작성이 불가능할 수도 있는 작업입니다.

애플리케이션 종속성 매핑은 운영 계보 맵을 구축합니다. 이 맵에는 모든 프로그램-데이터셋 관계(어떤 프로그램이 어떤 데이터셋을 생성하고 어떤 프로그램이 이를 소비하는지), 모든 프로그램 간 종속성(어떤 프로그램이 다른 프로그램을 호출하고 어떤 데이터가 프로그램 간에 흐르는지), 그리고 모든 JCL-프로그램 관계(어떤 작업 단계가 어떤 순서로 어떤 프로그램을 호출하는지)가 포함됩니다. 이 계보 맵은 기존 소스 시스템과 최신 데이터 카탈로그의 계보 기록 간의 격차를 해소하는 운영 메타데이터 계층입니다.

JCL 확장 기능은 모든 JCL 작업의 전체 실행 체인을 추적합니다. 여기에는 PROC 참조 해결, 기호 매개변수 확장, 각 데이터 세트의 생성 및 소비에 대한 전체 운영 메타데이터 구축, 스케줄링 컨텍스트, 종속 작업, 그리고 각 데이터 세트의 적시성과 최신성 특성을 결정하는 실행 순서가 포함됩니다.

엔터프라이즈 검색 기능을 통해 추출된 메타데이터 인벤토리를 메타데이터 관리 프로그램 전체에서 쿼리할 수 있습니다. 예를 들어, COMP-3으로 정의된 모든 필드(정밀한 대상 매핑이 필요한 정밀 필드), 특정 필드를 읽는 모든 프로그램(데이터 계보 및 의미론적 보강을 위해 특정 데이터의 모든 사용자를 식별), 특정 비즈니스 용어와 일치하는 모든 88단계 조건 이름(비즈니스 어휘를 기술 필드 정의에 매핑) 등을 찾을 수 있습니다. 이러한 검색 기능은 의미론적 보강 프로세스를 지원하여 도메인 전문가가 특정 필드 또는 값의 비즈니스 의미를 확인하기 전에 해당 필드 또는 값의 모든 사용 사례를 찾을 수 있도록 합니다.

조직이 수행하는 경우 레거시 현대화 프로그램 SMART TS XL메타데이터 추출은 마이그레이션 전 기반을 제공합니다. 여기에는 마이그레이션 도구가 소스 필드를 대상 스키마에 매핑하는 데 필요한 필드 수준의 기술 메타데이터, 마이그레이션 프로그램이 데이터 세트 마이그레이션 순서를 올바르게 지정하는 데 필요한 운영 계보, 그리고 COBOL 코드 값을 관계형 제약 조건 정의에 정확하게 매핑할 수 있도록 하는 88단계 의미 어휘가 포함됩니다.

지식이 사라지기 전에 메타데이터를 복구해야 할 시급성

메타데이터 복구 문제는 대부분의 데이터 거버넌스 문제에는 적용되지 않는 자연스러운 마감 시한을 가지고 있습니다. 바로 코드 분석으로는 복구할 수 없는 조직적 지식을 보유한 개발자들이 은퇴하는 시점입니다. 2030년까지 COBOL 프로그래머의 거의 3분의 1이 은퇴할 것으로 예상됩니다. 메인프레임 엔지니어의 평균 연령은 58.7세입니다. 체계적인 메타데이터 추출 및 의미론적 보강 없이 매년 시간이 흐를수록 복구된 메타데이터에 대한 인간의 검증이 가능한 기간은 점점 줄어듭니다.

기술적 메타데이터, 필드 정의, 유형 명세, 프로그램 종속성, 데이터 계보는 소스 코드가 존재하는 한 소스 코드에서 무기한으로 복구할 수 있습니다. 그러나 의미론적 메타데이터, 즉 각 필드가 비즈니스 측면에서 무엇을 의미하는지, 필드 설계의 배경이 된 역사적 결정 사항, 기술 명세에 명시되지 않은 암묵적인 관례는 해당 정보를 아는 사람으로부터만, 그리고 그들이 존재하는 동안에만 복구할 수 있습니다.

수십 년 된 시스템을 위한 메타데이터 관리 프로그램은 기술적 추출부터 시작하여 도메인 전문가가 여전히 활용 가능한 동안 의미론적 보강을 진행함으로써 완전하고 복구 가능한 메타데이터 기반을 구축합니다. 반면, 해당 전문가의 지식이 소멸된 후에 동일한 프로그램을 실행하면 기술적으로는 정확하지만 불완전한 메타데이터 기반만 생성하게 되는데, 즉 데이터 구조에 대해서는 정확하지만 그 의미에 대해서는 아무런 정보를 제공하지 못합니다.

메타데이터는 지도입니다. 수십 년 동안 이어져 온 시스템들이 그 지도를 묻어버렸습니다.

최신 시스템의 데이터 거버넌스는 최신 상태이고 접근 가능하며 최소한 부분적으로라도 문서화된 메타데이터에서 시작됩니다. 하지만 수십 년 된 시스템의 데이터 거버넌스는 수천 개의 소스 코드 파일에 분산되어 있고, 인터넷 이전 시대의 명세에 부분적으로만 문서화되어 있으며, 은퇴를 앞둔 개발자들의 기억 속에만 부분적으로 남아 있는 메타데이터에서 시작됩니다.

숨겨진 기술 메타데이터를 관리 대상으로 전환하는 과정은 추출, 재구성, 보강의 순서로 진행됩니다. 소스 코드에서 추출된 기술 메타데이터는 초기 인벤토리를 제공합니다. 프로그램 종속성으로부터 재구성된 운영 계보는 출처 지도를 제공합니다. 도메인 전문가의 검증을 거친 의미론적 보강은 기술 메타데이터에 비즈니스 의미를 부여하여 분석, 인공지능 및 거버넌스에 활용할 수 있도록 합니다.

최신 데이터 카탈로그 플랫폼은 이러한 메타데이터의 최종 목적지이지 시작점이 아닙니다. Collibra가 이를 관리하고 Alation이 이를 카탈로그화하고 데이터 과학자들이 이를 신뢰할 수 있게 되려면, 수십 년 된 시스템에 포함된 메타데이터를 먼저 함수 종속성(FD) 항목, 카피북, 88단계 조건 이름, 그리고 40년 동안 축적된 프로시저 디비전(PROCEDURE DIVISION) 로직에 인코딩된 비즈니스 규칙에서 찾아야 합니다.

지도는 존재한다. 단지 읽어야 할 뿐이다.