언어지향프로그래밍으로 코드 재사용 비교 연구

초록

본 논문은 외부 DSL을 지원하는 MPS와 내부 DSL을 지원하는 Cedalion 두 LOP 도구를 이용해 계산기 제품군(SPL)을 구현하고, 각각의 DSL 구현 방식이 코드 재사용성, 개발 비용, 유지보수성에 미치는 영향을 정량·정성적으로 비교한다.

상세 분석

이 연구는 LOP(Language Oriented Programming)의 핵심 가정인 “고수준 개념을 DSL 형태로 재사용하고, DSL 구현이 저수준 코드 변환을 담당한다”는 전제를 실험적으로 검증한다. 먼저 저자들은 추상적인 개념(문법, 평가 로직)을 두 단계로 분리한다. DSL 코드(제품별 정의)는 매우 간결하며, DSL 구현(메타레벨)은 복잡하지만 다수 제품에 공통적으로 재사용된다. 외부 DSL 접근법(MPS)은 프로젝션 기반 편집기를 제공하고, DSL 구현은 Java 기반 코드 생성기로 수행한다. 이 방식은 문법 자유도가 높고, 파서·코드 생성 파이프라인을 완전히 제어할 수 있다는 장점이 있다. 그러나 DSL 구현을 위한 템플릿 작성, 코드 생성 규칙 정의, 그리고 MPS 자체 메타모델링(Concept, Property, Reference 등) 작업이 상당히 무거운 초기 투자 비용을 요구한다. 특히, LR 문법을 지원하려면 복잡한 변환 로직을 직접 구현해야 하며, 이는 DSL 설계자에게 높은 전문성을 요구한다.

반면 내부 DSL 접근법(Cedalion)은 논리 프로그래밍 기반의 선언적 메타언어 위에 DSL을 정의한다. Cedalion은 정적 타입 시스템을 통해 DSL 스키마를 선언하고, 프로젝션 편집을 Eclipse 플러그인 형태로 제공한다. 내부 DSL은 호스트 언어(논리 프로그래밍)의 구문·의미 체계를 그대로 물려받아 구현 난이도가 낮다. 예를 들어, 규칙‑패턴‑감소식(Reducible) 구조를 논리 규칙으로 기술하면, 파싱·평가 로직이 자동으로 해석기에 의해 실행된다. 따라서 DSL 구현 단계에서의 코드량이 크게 감소하고, 새로운 연산자나 함수 추가가 비교적 간단하다. 그러나 내부 DSL은 호스트 언어의 제약을 피할 수 없으며, 복잡한 문법(예: LR 파서) 구현이 어려울 수 있다. 또한, 외부 DSL에 비해 생성된 실행 파일이 호스트 런타임에 종속적이기 때문에 성능 및 배포 측면에서 제한이 있다.

두 접근법을 동일한 계산기 SPL에 적용한 결과, 초기 설계·구현 시간은 Cedalion이 MPS보다 약 30~40% 빠른 것으로 나타났다. 재사용 측면에서는 두 시스템 모두 DSL 구현을 공유함으로써 제품 간 중복 코드를 크게 감소시켰다. 그러나 유지보수성에서는 MPS가 메타모델 수준에서 강력한 타입 검증과 IDE 지원(자동 완성, 리팩터링 등)을 제공해 장기적인 프로젝트에 유리한 반면, Cedalion은 아직 연구 단계 도구라 문서·커뮤니티 지원이 부족해 실무 적용에 제약이 있다.

결론적으로, 외부 DSL(MPS)은 높은 표현력과 독립적인 실행 파일 생성이 필요할 때 적합하고, 초기 투자 비용을 감수할 수 있는 대규모 조직에 유리하다. 내부 DSL(Cedalion)은 빠른 프로토타이핑과 학습 곡선이 완만한 소규모 팀에 적합하지만, 복잡한 문법 지원이나 성능 최적화가 요구될 경우 한계가 있다. 이 논문은 두 접근법의 트레이드오프를 명확히 제시함으로써 LOP 도입을 고려하는 실무자에게 실질적인 선택 기준을 제공한다.