DMARF와 GIPSY 아키텍처 품질 분석

초록

본 논문은 오픈소스 프레임워크인 DMARF와 GIPSY의 고수준 아키텍처와 요구사항을 분석하고, ISO 품질 표준에 기반한 메트릭을 활용해 코드 구조와 품질 특성을 평가한다. SonarQube를 이용해 클래스·메서드 수를 측정하고, 이해관계자와 유스케이스를 도출한 뒤 도메인 모델과 클래스 다이어그램을 설계한다. 분석 결과를 토대로 리팩터링 방안을 제시하고, 테스트 케이스를 통해 기능 변화를 최소화한다.

상세 분석

DMARF와 GIPSY는 각각 음성 인식과 인텐셔널 프로그래밍을 지원하는 Java 기반 오픈소스 시스템이다. 논문은 두 시스템의 구조적 차이를 파악하기 위해 먼저 고수준 아키텍처를 도식화하고, 핵심 컴포넌트와 데이터 흐름을 식별한다. DMARF는 모듈형 파이프라인으로, 오디오 전처리, 특징 추출, 분류기 등 단계별 모듈이 독립적인 서비스로 배포된다. 이때 각 모듈은 RMI 혹은 CORBA를 통해 원격 호출이 가능하도록 설계돼 확장성을 확보한다. 반면 GIPSY는 의도적 프로그래밍 언어를 실행하기 위한 런타임인 GEE와 컴파일러인 GIPC, 그리고 분산 실행을 담당하는 DGT, DST, DWT 등 다중 계층 구조를 갖는다. 특히 GIPSY는 “점진적 평가”와 “다중 차원 스트림” 개념을 도입해 복잡한 의존성을 효율적으로 관리한다.

품질 평가 단계에서는 ISO/IEC 25010 품질 모델을 기준으로 기능성, 신뢰성, 효율성, 유지보수성, 이식성을 측정한다. SonarQube를 이용해 클래스 수, 메서드 수, 복잡도(Cyclomatic Complexity), 중복 코드 비율, 코드 냄새(Code Smell) 등을 정량화하였다. DMARF는 클래스가 420여 개, 메서드가 3,800여 개로 비교적 규모가 크며, 복잡도 평균이 12.4로 높은 편이다. 이는 모듈 간 결합도가 높아 유지보수 비용이 증가할 위험을 시사한다. GIPSY는 클래스 310개, 메서드 2,950개이며 복잡도 평균이 9.8로 다소 낮다. 그러나 의도적 언어의 특성상 런타임 메타데이터 관리 로직에 중복이 발견돼 리팩터링 대상이 된다.

이해관계자 분석에서는 개발자, 최종 사용자, 유지보수 팀, 오픈소스 커뮤니티를 주요 배우로 정의하고, 각각의 목표와 제약을 매핑했다. 이를 토대로 완전한 유스케이스(Full‑Dressed Use Case)를 작성했으며, 특히 “새 알고리즘 추가”와 “분산 실행 노드 추가” 같은 확장 시나리오에 초점을 맞췄다. 도메인 모델링 단계에서는 DMARF의 AudioSample, FeatureExtractor, Classifier, Pipeline, Node 등 핵심 엔터티와 GIPSY의 IntentionalValue, Context, Demand, Tier, Worker 등을 식별하고, 연관 관계와 책임을 명시했다. 결과적으로 두 시스템 모두 SOLID 원칙을 일부 위반하고 있음을 확인했으며, 특히 DMARF의 Pipeline 클래스가 다중 책임을 지고 있어 SRP 위반이 두드러졌다.

리팩터링 전략으로는 DMARF에서 Pipeline을 전략 패턴(Strategy Pattern)으로 분리하고, 공통 인터페이스를 정의해 모듈 간 결합도를 낮추는 방안을 제시한다. 또한 복잡도가 높은 메서드를 추출(Extract Method)하고, 중복 로직을 템플릿 메서드 패턴으로 통합한다. GIPSY에서는 Demand 객체 생성 로직을 팩토리 패턴으로 캡슐화하고, DGT와 DWT 사이의 데이터 전달을 옵저버 패턴으로 재구성해 비동기성을 강화한다. 마지막으로 두 프로젝트 모두 자동화된 단위 테스트와 통합 테스트를 강화하고, 리팩터링 전후의 메트릭 변화를 지속적으로 모니터링하도록 CI 파이프라인에 SonarQube와 JaCoCo를 연동한다.