기본 콘텐츠로 건너뛰기

[ DSL ] Domain Specific Language - #1 DSL

  이번에는 프레임워크 구성의 실질적인 중심이 될 수 있는 DSL 에 대해서 여러 가지 자료를 검색해 본 결과를 기준으로 나름대로 하나씩 정리를 해 나가도록 한다. 이 글을 정리하고 있는 현재도 아직 뚜렷한 대상이나 구분이 명확하게 인식된 것이 아니기 때문에 좀 더 많은 글들과 사례들을 확인해 볼 필요가 있다.

DSL 이란?

  Domain Specific Language (DSL) 은 특정한 도메인(산업, 분야등 특정 영역)에서 발생하는 문제점을 해결하는 것에 중점을 두고 도메인을 기준으로 모든 것을 풀어나가기 위해서 제공되는 언어라고 생각하면 된다. 즉, 특정 영역의 해결에는 그 영역에 맞는 특화된 도구를 사용하자는 의미다. 이와 연관되어 나오는 단어는 DDD (Domain Driven Design) 이라는 것으로 모두 처음 발표된지 이미 최소한 10년 정도의 시간이 경과한 기술이며 정의이다.

  현실에서도 많이 구현되어 사용되고 있지만 아직도 DSL 에 대한 정의 자체부터 논란이 있다. 단어 자체로는 "특정 문제에 맞는 언어"라고 볼 수 있지만, 보는 입장에 따라서, 그리고 구현되는 방식에 따라서 다양한 형태로 정의될 수 있기 때문일 것이다.

  DSL 에 대해서 가장 잘 정리된 글은 마틴 파울러의 글을 참고하면 된다. 외부 OOPSLA 컨퍼런스에서 Domain-Specific Modeling 에 대한 워크샾등으로 많은 논의가 되었던 것으로 알고 있다.

  DSL 이 도메인 전문자 (Domain Expert) 의 입장에서 작성이 되려면 High-Level 언어로 작성이 되고, 이를 Code Generator를 통해서 일반 언어로 변환이 되어야 한다. 그러나 이런 경우에 코드의 최적화가 어렵고, 프로그래머가 작성하는 DSL 에 비해서 유연성이 떨어질 수 밖에는 없다. 그리고 프로그래머가 작성하는 DSL 도 Internal 과 External 에 따라서 테스트 용이성이나 통합 비용 등에 차이가 날 수 있다.

  DSL 에 대해서 개념을 잡기 위해서는 Introduction to Domain Specific Language 비디오를 보는 것이 좋다. 실제 도메인 전문가가 직접 코드를 작성하지 않더라도 코드를 이해할 수 있다면 정확한 문제를 해결하는데 큰 도움이 된다. 예를 들어 금융이나 보험 관련 프로젝트에서 도메인 전문가가 JUnit 을 이해하고 같이 테스트 케이스를 만들 수 있다면 정확하게 무엇을 테스트하고, 어떤 절차를 거쳐서 개발이 진행되어야 하는지 등에 대한 직접적인 도움을 얻을 수 있기 때문이다. 마틴 파울러는 자연어와 유사한 Ruby를 이용한다고 한다.

  또한 AOP 과 프레임워크의 발전으로 인해서 DSL 이 좀 더 실용적으로 활용될 수 있는 토대가 마련되었다. 예를 들어 AOP 에 사용할 서비스 모듈이나 컴포넌트를 DSL 로 작성하고 이를 통합하는데 AOP를 이용할 수 있다는 것이다. 즉, 각 모듈들은 모델의 역할을 충실히 수행하고, 그 외의 로깅, 모니터링 등의 Cross-Concern 들은 AOP 로 통합하여 관리할 수 있는 환경이라는 것이다. 또한 Spring 과 같은 프레임워크는 Dynamic Language를 지원하기 때문에 쉽게 External DSL 을 활용할 수도 있다. 통합된 프레임워크 기반 위에 각 도메인 영역을 구현한 DSL 을 올려 놓는 방법도 생각해볼 수 있다.

  이미 웹 개발에도 DSL 이 적용되어 WSL (Web Specific Language) 도 생겨났다. 대표적인 사례는 CMS (Content Management System) 로 큰 규모의 사이트라면 독자적인 CMS를 개발하여 사용하고 있을 것인데 DSL 개념을 통해서 접근한다면 좀 더 쉽게 동적이고 유연한 기능을 제공할 수 있을 것이다. 문제는 HTML 자체가 계층적이며 실수하기 쉬운 언어이기 때문에 WSL 의 적용이 어려울 수도 있다. 이런 문제를 극복하기 위해서 WebDSL 과 같은 다양한 시도가 진행 중인 것으로 알려진다.

  DSL 은 고객을 중시하고, 상호작용을 증대시키며, 비즈니스에 초점을 맞춘 개념이다. 각 도메인마다 새로운 언어를 만든다면 비 생산적인 상황이 되겠지만, 도메인 전문가와 개발자를 모두 만족할 수 있는 DSL 을 사용한다면 복잡하고 특정한 영역에서 발생하는 문제들을 빠르고 정확하게 해결할 수 있는 새로운 패러다임이 될 수도 있을 것이다.

Internal vs. External DSL?

Internal DSL

  내부 DSL은 호스트되는 언어의 틀을 벗어나지 않으면서 DSL 을 구성하는 것을 의미한다. 따라서 해당 언어를 잘 알면 친숙하게 접근할 수 있다. 주로 다음과 같은 형태가 된다고 한다.

  • 메타 프로그래밍 형태로 미니 언어를 만들 수 있다.
  • 원래 호스트 언어의 새로운 구문으로 도입되어 언어 확장을 할 수 있다.
  •  인라인 코드 형태로 표현이 가능하다.
이런 형식으로 사용가능한 호스트 언어는 Lisp, Ruby, Smalltalk 등이다.


External DSL

  호스트 언어와는 다른 언어 (XML, ...) 를 통해서 생성된 DSL 을 의미하며, 확장 기능을 가진 툴과 같다고 생각하면 된다. 주로 다음과 같은 형태가 된다고 한다.

  • 실행 파일에서 DSL을 로드하여 적용이 가능하다.
  • DSL 컴파일러를 만들어서 표현이 가능하다.
  • 범용 개발 언어로 Generator를 만들어서 코드로 변환이 가능하다.
이런 형식으로 사용가능한 언어는 Java, C#, C++ 등이다.


Pros and Cons

  DSL을 이용하면 아래와 같은 장점들이 존재한다.

  • 반복이 제거되고 비슷한 유형들의 코드는 템플릿 기반으로 자동 생성이 가능하다.
  • 프로그래머가 처리할 코드의 양이 적고 가독성이 높다.
  • 개발 담당 프로그래머와 공유가 쉽다. (XML, CSS, SQL 등...)  

  그러나 단점도 아래와 같이 존재한다.

  • DSL 자체 설계가 어렵다.
  • 잘 설계되지 않으면 구성된 코드들을 이해하기 힘들게 된다.
  • 항상 하위 호환성을 유지해야 한다.
Examples

  이미 주변에는 알게 모르게 DSL 이 적용되어 사용되고 있는 것들이 존재한다.
  • Java - ANT, Maven, Strut-config.xml, Seasar2 S2DAO, HQL(Hibernate Query Language), JMock
  • Ruby - Rails Validations, Rails ActiveRecord, Rake, RSpec, Capistrano, Cucumber
  • Etc - SQL, CSS, Regular Expression, Make, graphviz

댓글

  1. 음 좋은글 써주셔서 감사합니다

    답글삭제
    답글
    1. 감사합니다. 오늘도 좋은 하루 되세요.

      삭제

댓글 쓰기