DMARF와 GIPSY 리팩터링 연구 보고서

초록

본 보고서는 오픈소스 시스템인 DMARF와 GIPSY의 구조와 품질을 분석하고, Logiscope 도구를 활용한 메트릭 평가 결과를 바탕으로 리팩터링 가능성을 탐색한다. 두 시스템의 아키텍처, 모듈 구성, 의존성 및 코드 복잡성을 상세히 검토하고, 향후 유지보수와 확장성을 높이기 위한 개선 방안을 제시한다.

상세 분석

DMARF와 GIPSY는 각각 음성 인식과 다중 차원 프로그래밍을 목표로 하는 Java 기반 오픈소스 프레임워크이다. DMARF는 모듈형 오디오 인식 파이프라인을 분산 환경에서 실행하도록 설계되었으며, MARF(MODULAR AUDIO RECOGNITION FRAMEWORK)의 확장 버전으로서 데이터 전처리, 특징 추출, 분류 등 여러 단계가 독립적인 모듈로 구현된다. 이러한 모듈화는 재사용성을 높이는 장점이 있지만, 현재 구현에서는 모듈 간 결합도가 높아 유지보수가 어려운 구조적 문제가 존재한다. 특히, 인터페이스 정의가 불명확하고, 예외 처리 로직이 각 모듈에 중복 배치돼 코드 중복과 오류 전파 위험이 증가한다.

GIPSY는 Lucid 계열 언어를 컴파일하고 실행하기 위한 다중 차원 실행 환경을 제공한다. 핵심 컴포넌트는 GIPC(General Intensional Programming Compiler), GEE(General Eduction Engine), 그리고 다양한 런타임 어셈블러로 구성된다. GIPSY는 의도적 프로그래밍 모델을 지원하기 위해 추상 구문 트리(AST)와 의도적 흐름 그래프를 동적으로 생성한다. 이러한 동적 특성은 높은 유연성을 제공하지만, 코드 베이스가 복잡하고 클래스 간 상속 구조가 얕게 설계돼 있어 사이클 의존성이 빈번히 발생한다. 또한, 멀티스레드 환경에서 공유 자원에 대한 동기화가 충분히 보장되지 않아 잠재적인 레이스 컨디션 문제가 존재한다.

Logiscope를 이용한 정량적 분석 결과, 두 시스템 모두 평균 사이클 복잡도(Cyclomatic Complexity)가 15~20 수준으로, 유지보수 난이도가 높은 편이다. DMARF는 클래스당 평균 라인 수가 250줄을 초과하고, 메서드당 평균 파라미터 수가 4개 이상으로 설계가 과도하게 복잡함을 보여준다. GIPSY는 인터페이스 구현 수가 과다하고, 추상 클래스와 구체 클래스 간의 책임이 명확히 구분되지 않아 설계 원칙 위반이 다수 발견되었다.

리팩터링 관점에서 핵심 과제는 다음과 같다. 첫째, DMARF의 모듈 간 인터페이스를 명확히 정의하고, 공통 예외 처리 로직을 별도 유틸리티 클래스로 추출한다. 둘째, 불필요한 의존성을 제거하기 위해 의존성 주입(DI) 패턴을 도입하고, 모듈 테스트를 위한 목(mock) 객체를 제공한다. 셋째, GIPSY에서는 복잡한 상속 구조를 컴포지션으로 전환하고, 전략 패턴을 활용해 실행 엔진의 동적 행동을 캡슐화한다. 넷째, 멀티스레드 동기화 문제를 해결하기 위해 java.util.concurrent 패키지의 고수준 동시성 컬렉션과 락 프레임워크를 적용한다. 마지막으로, 코드 커버리지를 높이고 지속적인 품질 검증을 위해 CI 파이프라인에 Logiscope와 SonarQube를 연동한다. 이러한 리팩터링 전략은 시스템의 가독성, 테스트 용이성, 확장성을 크게 향상시킬 것으로 기대된다.