마틴 파울러

1. 개요

마틴 파울러는 영국의 소프트웨어 개발자이자 작가이다. 1980년대 초부터 소프트웨어 업계에서 활동하며, 2000년부터 컨설팅 회사 ThoughtWorks의 최고 과학자로 재직하고 있다. 그는 애자일 소프트웨어 개발 선언 작성에 참여했으며, 블로그와 위키를 결합한 블리키를 운영한다. 주요 저서로는 《분석 패턴》, 《UML 정수》, 《리팩토링》 등이 있으며, 특히 《도메인 특화 언어》를 통해 DSL(Domain-Specific Language) 개념을 소개했다.

2. 경력

영국 월솔에서 태어나 퀸 메리스 그래머 스쿨을 거쳐 1986년 런던 대학교를 졸업했다. 대학 졸업 후 1986년부터 1991년까지 쿠퍼스 & 리브랜드에서 소프트웨어 개발자로 근무했다. 1994년 미국으로 이주하여 매사추세츠주 보스턴 근교 멜로즈에 거주하고 있다. 2000년부터는 시스템 통합 및 컨설팅 회사인 ThoughtWorks에 합류하여 최고 과학자(Chief Scientist)로 활동하고 있다.

2.1. 주요 활동 및 기여

파울러는 1980년대 초반부터 소프트웨어 개발을 시작했으며, 1980년대 중반부터는 객체 지향 기술에 관심을 가졌다. 1986년 런던 대학교 졸업 후 1991년까지 쿠퍼스 & 리브랜드에서 소프트웨어 개발자로 일했다. 2000년 3월부터는 시스템 통합 및 컨설팅 회사인 ThoughtWorks에 합류하여 최고 과학자(Chief Scientist)로 활동하고 있다.

그는 소프트웨어 개발 분야에서 9권의 책을 저술했으며, 스몰토크에 능숙한 프로그래머이기도 하다.

파울러는 애자일 연합의 회원이기도 하다. 2001년에는 16명의 동료 서명인들과 함께 애자일 소프트웨어 개발 선언을 만드는 데 기여했다.

또한 제어 반전(Inversion of Control)의 한 형태로서 의존성 주입(Dependency Injection)이라는 용어를 널리 알리는 데 기여했다. 그는 블로그와 위키의 특징을 결합한 형태의 웹사이트인 블리키를 운영하고 있다.

3. 저서

마틴 파울러는 소프트웨어 개발 분야에서 영향력 있는 여러 권의 책을 저술했다. 그의 저서들은 객체 지향 프로그래밍, 애자일 소프트웨어 개발 방법론, 특히 리팩토링과 디자인 패턴에 대한 깊이 있는 통찰을 제공하며 전 세계 개발자들에게 널리 읽히고 있다. 그의 책들은 여러 언어로 번역되었으며, 한국에서도 다수의 저서가 번역 출간되어 많은 개발자에게 영향을 주었다.

3.1. 주요 저서 목록

* 1996년: 분석 패턴: 재사용 가능한 객체 모델(Analysis Patterns: Reusable Object Models)
* 1997년: UML 정수: 표준 객체 모델링 언어에 대한 간략한 안내(UML Distilled: A Brief Guide to the Standard Object Modeling Language)
* 1999년: 리팩토링: 기존 코드의 설계를 개선하라(Refactoring: Improving the Design of Existing Code) - 켄트 백, 존 브랜트, 윌리엄 옵다이크, 돈 로버츠 공저
* 2000년: 익스트림 프로그래밍 계획하기(Planning Extreme Programming) - 켄트 백 공저
* 2002년: 엔터프라이즈 애플리케이션 아키텍처 패턴(Patterns of Enterprise Application Architecture) - 데이비드 라이스, 매튜 푀멜, 에드워드 히아트, 로버트 미, 랜디 스태포드 공저
* 2010년: 도메인 특화 언어(Domain-Specific Languages) - 레베카 파슨스 공저
* 2012년: NoSQL 정수: 폴리글랏 영속성의 새로운 세계에 대한 간략한 안내(NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence) - 프라모드 사달라지 공저
* 2013년: 리팩토링: 루비 에디션(Refactoring: Ruby Edition) - 켄트 백, 셰인 하비, 제이 필즈 공저
* 2018년: 리팩토링: 기존 코드의 설계를 개선하라, 2판(Refactoring: Improving the Design of Existing Code, Second Edition) - 켄트 백 공저

4. 도메인 특화 언어 (DSL)

마틴 파울러는 그의 저서 도메인 특화 언어(Domain-specific languages)를 통해 도메인 특화 언어(DSL)의 개념과 활용 방안에 대해 깊이 있게 논의했다. 그는 DSL을 특정 문제 영역(도메인)에 맞춰 표현력을 제한한 프로그래밍 언어로 정의하며, 이를 통해 프로그래머의 부담을 줄이고 도메인 전문가와의 소통을 원활하게 하여 생산성을 높일 수 있다고 보았다. 하지만 새로운 언어 학습 및 도구 구축 비용, 여러 언어 사용으로 인한 사일로 현상 발생 가능성, 특정 작업에 DSL의 추상화가 부적합할 수 있다는 단점도 함께 지적했다.

파울러는 DSL을 크게 호스트 언어 내부에 존재하는 내부 DSL(Internal DSL)과 독립적인 문법을 가진 외부 DSL(External DSL)로 구분하였다. 또한 DSL의 실행 방식을 정의하는 의미 모델(Semantic Model) 개념을 제시했으며, graphviz, CSS, HQL, XAML 등 다양한 DSL의 실제 사례들을 소개했다.

책에서는 외부 DSL 구현을 위한 파서, 렉서, 추상 구문 트리, 코드 생성 등의 기술("구문 기반 변환")과 더 간단하지만 덜 강력한 "구분자 기반 변환" 방식을 설명한다. 내부 DSL 구현 방법으로는 중첩 함수 호출, 함수 호출 시퀀스, 메소드 체이닝 등을 소개했다.

4.1. DSL의 정의 및 장점

마틴 파울러는 그의 저서 도메인 특화 언어(Domain-specific languages)에서 도메인 특화 언어(DSL)를 다룬다. 그는 DSL을 특정 개별 도메인에 초점을 맞추고 표현력이 제한된, 조립 가능한 프로그래밍 언어로 정의한다. DSL은 프로그래머가 전체 프로그래밍 언어를 이해해야 하는 부담을 줄여주고, 도메인 전문가와의 효과적인 의사소통 수단을 제공한다. 또한 작업 실행 방식을 작업 정의 자체와 분리함으로써 생산성을 높일 수 있다고 주장한다.

4.2. DSL의 종류

마틴 파울러는 도메인 특화 언어(DSL)를 크게 두 가지 종류로 구분한다.

* 내부 DSL (Internal DSL) 또는 임베디드 DSL (Embedded DSL): 다른 프로그래밍 언어(호스트 언어)의 하위 집합으로 존재하는 DSL이다. 이는 호스트 언어의 기존 도구를 그대로 사용하여 실행할 수 있다는 특징이 있다. 루비(Ruby)나 Lisp과 같은 언어에서 내부 DSL이 자주 활용된다.
* 외부 DSL (External DSL): 호스트 언어에 의존하지 않고 독립적인 문법과 의미 구조를 가진다. 따라서 외부 DSL을 처리하기 위해서는 별도의 파서, 렉서, 코드 생성 도구 등을 만들어야 한다.

4.3. DSL 구현 방법

마틴 파울러는 그의 저서 도메인 특화 언어에서 외부 도메인 특화 언어(DSL)를 구현하는 방법으로 "구문 기반 변환"과 "구분자 기반 변환"을 제시한다.

* 구문 기반 변환은 파서, 렉서, 추상 구문 트리, 코드 생성과 같은 도구를 사용하여 외부 DSL을 구현하는 방식이다.
* 구분자 기반 변환은 언어를 구분자를 기준으로 분할하고, 개별 항목에 따라 로직을 전환하여 해석하는 방식으로, 구문 기반 변환보다 간단하지만 기능적으로는 덜 강력하다고 평가된다.

내부 DSL의 경우, 다음과 같은 다양한 방법들을 통해 구현할 수 있다고 설명한다.
* 중첩된 함수 호출
* 함수 호출 시퀀스
* 메소드 체이닝

4.4. DSL 예시

파울러는 그의 저서 도메인 특화 언어에서 다음과 같은 다양한 도메인 특화 언어(DSL)의 예시를 제시한다.

4.5. 비판적 관점

마틴 파울러는 도메인 특화 언어(DSL)가 여러 이점을 제공하지만, 동시에 다음과 같은 단점이나 비용이 발생할 수 있다고 지적한다.

* 학습 및 구축 비용: 새로운 언어를 배우고 해당 언어를 지원하는 도구를 개발하는 데 시간과 노력이 필요하다.
* [[사일로 효과|사일로 현상]]: 프로젝트 내에서 여러 DSL을 사용하게 되면, 각 언어 사용자 그룹 간의 소통 단절이나 정보 고립(사일로 현상)이 발생할 수 있다.
* 추상화의 한계: DSL이 제공하는 추상화 수준이 특정 작업의 요구사항과 맞지 않아 오히려 개발을 어렵게 만들거나 비효율을 초래할 수 있다.