# DSL (도메인 특화 언어)

**DSL(Domain-Specific Language, 도메인 특화 언어)**은 소프트웨어 공학에서 특정 문제 영역(Domain)을 해결하기 위해 설계된 특수 목적의 컴퓨터 언어이다.

## 1. 개요
DSL은 범용적인 문제를 해결하기 위해 설계된 **GPL(General-Purpose Language, 일반 목적 언어)**과 대조되는 개념이다. Java, Python, C++와 같은 GPL이 알고리즘 구현, 시스템 제어, 웹 서버 구축 등 거의 모든 소프트웨어 개발에 사용될 수 있는 반면, DSL은 데이터베이스 쿼리, 설정 파일 정의, 하드웨어 제어 등 매우 좁고 구체적인 영역에 최적화되어 있다.

DSL의 핵심 목적은 해당 도메인의 전문가(Domain Expert)가 프로그래밍 언어의 복잡한 문법에 얽매이지 않고, 도메인 지식을 직접적으로 표현하여 생산성을 극대화하는 데 있다.

## 2. DSL의 분류
DSL은 구현 방식과 호스트 언어와의 관계에 따라 크게 **외부 DSL**과 **내부 DSL**로 분류된다.

### 2.1 외부 DSL (External DSL)
독자적인 문법을 가지며, 이를 해석하기 위한 별도의 파서(Parser)와 컴파일러/인터프리터가 필요한 언어이다. 호스트 언어의 제약을 받지 않으므로 도메인에 가장 최적화된 문법을 설계할 수 있다.

### 2.2 내부 DSL (Internal DSL)
호스트 언어(Host Language) 내부에 구현된 언어이다. 호스트 언어의 문법을 활용하여 DSL처럼 보이게 설계하며, 별도의 컴파일러 없이 호스트 언어의 런타임을 그대로 사용한다.

### [표] 외부 DSL vs 내부 DSL 비교

| 구분 | 외부 DSL (External DSL) | 내부 DSL (Internal DSL) |
| :--- | :--- | :--- |
| **문법** | 완전히 독립적인 전용 문법 | 호스트 언어의 문법을 따름 |
| **구현 비용** | 높음 (파서, 컴파일러 개발 필요) | 낮음 (호스트 언어 라이브러리 형태) |
| **유연성** | 매우 높음 (최적의 가독성 설계 가능) | 제한적 (호스트 언어 문법 내로 한정) |
| **도구 지원** | 전용 IDE 플러그인 개발 필요 | 기존 IDE의 자동완성/디버깅 활용 가능 |
| **실행 방식** | 전용 인터프리터 또는 컴파일 | 호스트 언어에 의해 실행 |

## 3. 작동 원리 및 구현 방식

### 3.1 외부 DSL의 처리 과정
외부 DSL은 텍스트 형태의 소스 코드를 컴퓨터가 이해할 수 있는 형태로 변환하는 파이프라인을 거친다.
1. **Lexer (어휘 분석기):** 입력 문자열을 의미 있는 최소 단위인 '토큰(Token)'으로 분리한다.
2. **Parser (구문 분석기):** 토큰들의 배열을 문법 규칙에 따라 분석하여 **AST(Abstract Syntax Tree, 추상 구문 트리)**를 생성한다.
3. **Evaluator/Compiler:** 생성된 AST를 순회하며 실제 동작을 수행(인터프리팅)하거나, 다른 언어(예: Java Bytecode, Machine Code)로 변환(컴파일)한다.

### 3.2 내부 DSL의 구현 기법
내부 DSL은 호스트 언어의 특수한 기능을 활용하여 선언적인 문법을 흉내 낸다.
- **메서드 체이닝(Method Chaining):** 메서드가 자기 자신이나 관련 객체를 반환하여 `.` 연산자로 연결하는 방식 (Fluent Interface).
- **연산자 오버로딩(Operator Overloading):** 기존 연산자(`+`, `*` 등)에 새로운 의미를 부여하여 도메인 식을 표현하는 방식 (Kotlin, Scala 등에서 활용).
- **수신 객체 지정 람다(Lambda with Receiver):** 특정 객체의 컨텍스트 내에서 코드가 실행되도록 하여 `this` 생략이 가능하게 하는 기법으로, 계층적 설정 문법을 구현할 때 주로 사용된다.

## 4. 대표적인 DSL 사례 및 구현 예시

### 4.1 실무 사례
- **외부 DSL (External DSL)**
    - **SQL (Structured Query Language):** 관계형 데이터베이스 조작을 위한 대표적인 외부 DSL.
    - **HTML/CSS:** 웹 페이지의 구조와 스타일을 정의하는 외부 DSL.
    - **Regular Expression (정규 표현식):** 문자열 패턴 매칭을 위한 극도로 압축된 외부 DSL.
    - **Terraform (HCL):** 인프라 정의(IaC)를 위한 전용 언어.
- **내부 DSL (Internal DSL)**
    - **Gradle (Groovy/Kotlin DSL):** 빌드 설정을 위해 호스트 언어의 문법을 활용한 DSL.
    - **SwiftUI/Jetpack Compose:** UI 선언을 위해 호스트 언어 내에 구현된 DSL.

### 4.2 구현 코드 예시

#### [외부 DSL 예시: SQL]
```sql
SELECT name, email 
FROM users 
WHERE age >= 20 
ORDER BY created_at DESC;
```
*(설명: 일반 프로그래밍 언어처럼 루프나 조건문을 복잡하게 쓰지 않고, '무엇을(What)' 가져올지만 선언적으로 기술함)*

#### [내부 DSL 예시 1: 메서드 체이닝 (Fluent Interface)]
```java
// Java 기반의 쿼리 빌더 예시
Query query = new QueryBuilder()
    .select("name", "email")
    .from("users")
    .where("age >= 20")
    .orderBy("created_at DESC")
    .build();
```
*(설명: 메서드가 계속해서 빌더 객체를 반환함으로써 자연어 문장과 유사한 흐름을 생성함)*

#### [내부 DSL 예시 2: Kotlin 기반의 설정 DSL]
```kotlin
// 내부 DSL 구현: 호스트 언어(Kotlin)의 수신 객체 지정 람다 활용
server {
    port = 8080
    timeout = 30
    endpoint {
        path = "/api/v1"
        method = "GET"
    }
}
```
*(설명: Kotlin의 문법을 활용하여 마치 전용 설정 파일처럼 보이게 구현한 내부 DSL)*

## 5. DSL 도입의 장점과 한계

### 5.1 장점
- **생산성 향상:** 도메인 특화 문법을 통해 코드 양을 획기적으로 줄이고 개발 속도를 높인다.
- **의사소통 효율화:** 개발자가 아닌 도메인 전문가(기획자, 분석가 등)가 코드를 읽거나 직접 수정할 수 있어 요구사항 반영이 빠르다.
- **추상화 수준 제고:** 하위 수준의 구현 세부 사항을 숨기고 비즈니스 로직에만 집중할 수 있다.

### 5.2 한계
- **학습 곡선:** 새로운 언어(외부 DSL의 경우)를 배워야 하는 비용이 발생한다.
- **유지보수 비용:** DSL 자체의 문법이 변경되거나 버그가 발생했을 때, 이를 처리하는 파서나 컴파일러를 직접 수정해야 한다.
- **범용성 부족:** 특정 영역 외에는 사용할 수 없으며, 복잡한 일반 로직을 구현하려 할 때 오히려 제약이 된다.

## 6. DSL 설계 시 고려사항 및 방법론

### 6.1 도메인 분석 방법론
효과적인 DSL을 설계하기 위해서는 단순한 코딩 이전에 철저한 도메인 분석이 선행되어야 한다.
1. **용어 사전(Ubiquitous Language) 구축:** 도메인 전문가와 개발자가 공통으로 사용할 용어를 정의하여 언어의 키워드로 채택한다.
2. **핵심 개념 추출:** 도메인 내의 '엔티티(Entity)', '속성(Attribute)', '동작(Action)'을 구분하여 문법 구조를 설계한다.
3. **시나리오 기반 프로토타이핑:** 실제 해결해야 할 문제들을 텍스트 형태로 미리 작성해보고, 가장 간결하고 직관적인 문법 형태를 도출한다.

### 6.2 설계 가이드라인
- **가독성과 간결함의 균형:** 너무 짧은 키워드는 의미 전달이 어렵고, 너무 긴 키워드는 작성이 번거롭다.
- **호스트 언어와의 통합:** 내부 DSL의 경우, 호스트 언어의 문법을 너무 과하게 왜곡하면 IDE의 지원을 받지 못하거나 다른 개발자가 이해하기 어려울 수 있다.
- **에러 메시지의 명확성:** DSL 사용자가 어디서 잘못 입력했는지 정확히 알 수 있도록 상세한 구문 에러 메시지를 제공해야 한다.

## 7. DSL 선택 기준

### 7.1 결정 트리 (Decision Tree)
- **문제 영역이 매우 구체적이고 반복적인가?**
    - **No** $\rightarrow$ **GPL(일반 목적 언어) 사용**
    - **Yes** $\rightarrow$ (다음 단계로)
    - **도메인 전문가(비개발자)가 직접 코드를 읽거나 수정해야 하는가?**
        - **Yes** $\rightarrow$ **외부 DSL (External DSL) 고려**
        - **No** $\rightarrow$ (다음 단계로)
        - **개발 기간이 촉박하며, 호스트 언어의 생태계(IDE, 라이브러리)를 그대로 활용해야 하는가?**
            - **Yes** $\rightarrow$ **내부 DSL (Internal DSL) 선택**
            - **No** $\rightarrow$ **외부 DSL (External DSL) 선택** (완전한 자유도 필요 시)

### 7.2 도입 전 체크리스트
DSL 도입을 결정하기 전, 다음 항목들을 검토하십시오.
- [ ] 해결하려는 문제 영역이 명확히 정의되어 있는가?
- [ ] 해당 영역의 비즈니스 로직이 빈번하게 변경되어 유연한 수정이 필요한가?
- [ ] 도메인 전문가가 코드의 가독성을 통해 비즈니스 검증에 참여해야 하는가?
- [ ] (외부 DSL의 경우) 전용 파서와 컴파일러를 개발하고 유지보수할 리소스가 있는가?
- [ ] (내부 DSL의 경우) 선택한 호스트 언어가 DSL 구현에 적합한 문법적 유연성을 제공하는가?