KDM으로 레거시 시스템 지식을 표준 모델로 추출하는 방법

코드와 산출물에 흩어진 지식을 공통 모델로 옮기기

레거시 시스템의 문제는 오래된 언어 자체보다도, 코드와 산출물 곳곳에 흩어진 구조와 비즈니스 로직을 한눈에 파악하기 어렵다는 데 있다. KDM(Knowledge Discovery Metamodel)은 이런 자산을 언어와 플랫폼에 독립적인 형태로 표현하기 위해 OMG(Object Management Group)가 정의한 표준 메타모델이다.

소스 코드, 데이터베이스 스키마, 사용자 인터페이스, 물리적 배포 구조를 하나의 관점에서 다룰 수 있으므로 분석·리팩터링·마이그레이션 과정에서 시스템 지식을 연결하는 기반이 된다. 여러 프로그래밍 언어와 프레임워크가 공존하고 문서화되지 않은 업무 규칙이 코드에 남아 있는 환경에서 특히 의미가 있다.

분석 결과를 도구와 플랫폼으로부터 분리하는 이유

소프트웨어 개발 산출물은 텍스트, 다이어그램, 코드처럼 형태가 제각각이다. 이들을 검색하고 연결하려면 일관된 접근 방식이 필요하다. KDM은 산출물의 의미론적 정보를 추상화해 통일된 검색과 접근의 기반을 제공한다.

통합 분석에는 언어 중립성도 필요하다. 자바(Java) 프론트엔드와 코볼(COBOL) 백엔드가 함께 운영되는 시스템은 개별 언어 전용 도구만으로 전체 구조를 파악하기 어렵다. KDM은 결과물을 원래 언어와 플랫폼에서 분리해 표현함으로써, 서로 다른 기술로 구현된 자산을 같은 분석 환경에서 다룰 수 있게 한다.

코드 상세에서 비즈니스 지식까지 이어지는 계층

KDM은 시스템 정보를 4개의 주요 레이어와 12개의 패키지로 나눈다. 하위의 코드 상세 정보에서 출발해 상위의 비즈니스 인벤토리까지 추상화 수준을 올리는 구조다.

⤢✕

인프라스트럭처 레이어는 모델링을 위한 핵심 구성 요소와 확장 메커니즘을 정의한다. 이 계층의 Core 패키지는 시스템 인벤토리를 관리하고 구성 요소 사이의 관계를 설정한다.

프로그램 레이어는 변수 선언, 데이터 타입, 제어 흐름(Control Flow)처럼 소스 코드의 구문적·의미적 요소를 추상화한다. 언어가 달라도 코드 구조를 KDM의 공통 표현으로 옮길 수 있는 영역이다.

리소스 레이어는 프로그램이 외부와 상호작용하는 자원을 다룬다. 데이터베이스 스키마와 접근 로직은 Data 패키지로, 사용자 인터페이스 구조는 UI 패키지로, 배포 환경은 Platform 패키지로 표현한다.

추상화 레이어는 기술 구현을 넘어 비즈니스 관점의 지식을 모델링한다. 시스템이 제공하는 비즈니스 기능(Functionality)은 Conceptual 패키지로, 시스템 사이의 아키텍처 관계는 Structure 패키지로 다룬다.

현대화와 변경 영향 파악에 쓰는 방식

레거시 현대화에서는 기존 시스템을 분석해 모델로 바꾸는 역공학(Reverse Engineering)의 표준으로 KDM을 활용할 수 있다. 생성된 KDM 모델은 MDA(Model Driven Architecture)를 통해 새로운 언어 또는 플랫폼의 코드를 자동 생성하는 근거가 된다.

변경 영향도 분석에도 같은 모델이 유용하다. 특정 비즈니스 로직이나 데이터 구조를 바꿀 때, 코드·데이터베이스·화면까지 연결된 관계를 추적할 수 있다. KDM의 추적성(Traceability)은 변경 범위를 확인하고 장애 위험을 줄이는 데 쓰인다.

여러 플랫폼에서 운영되는 시스템을 통합하거나 마이그레이션할 때는 각 시스템의 지식을 공통 언어로 치환해 비교할 수 있다. 클라우드 네이티브 아키텍처로 전환하는 과정에서도 기존 자산을 전략적으로 재사용할 수 있는 분석 기반이 된다.

ASTM과 KDM은 분석 범위가 다르다

OMG의 ASTM(Abstract Syntax Tree Metamodel)은 AST(Abstract Syntax Tree) 메타모델로서 코드의 구문적 상세 구조를 세밀하게 표현하는 데 집중한다. 반면 KDM은 코드뿐 아니라 시스템 구조, 자원, 비즈니스 의미까지 포괄하는 지식 추출 모델이다.

두 표준은 경쟁 관계라기보다 역할이 다르다. 현대화 프로젝트에서는 ASTM으로 코드를 파싱하고, 그 결과를 KDM으로 통합해 시스템 전체 모델을 구축하는 방식으로 함께 사용할 수 있다.

모델을 만들기 전에 정해야 할 운영 기준

KDM 도입에서 먼저 확인할 대상은 KDM 추출기(Extractor)의 품질이다. 기존 소스 코드를 모델로 정확히 옮기려면 지원 언어의 문법과 라이브러리 사용 패턴을 얼마나 정확하게 해석하는지가 중요하다. 추출 품질은 이후 모델의 신뢰도에 직접 영향을 준다.

대규모 엔터프라이즈 환경에서는 모델 자체의 크기도 관리 대상이 된다. 목적에 맞는 추상화 수준을 정하고 필요한 영역을 선택적으로 모델링해야 한다.

마지막으로 모델을 읽고 현대화 전략으로 연결할 아키텍트가 필요하다. 도구의 자동화 기능만으로는 충분하지 않으며, 시스템과 도메인을 이해하는 사람이 추출 결과를 해석해야 한다.