Fowler: DSL은 죽지 않았으며, LLM을 쓸모 있게 만드는 요소입니다.

DSL에 대한 Martin Fowler의 글은 이들을 다시 주목받게 했습니다. 큰 영감을 주기 위한 것이 아니라, LLM이 좁은 대상에서 회복 가능한 방식으로 실수할 수 있도록 하기 위함입니다.

간단히 말해

마틴 파울러의 논문(2026년 7월 15일 발표)은 간단하다: LLM은 비결정적이고 때로는 잘못된 코드를 생성한다는 것이다. 일반 언어는 이러한 오류를 허용하고 확산시킨다. 반면 특정 언어(DSL)는 가능한 출력 범위를 제한하여 검증이 쉬워지며, LLM이 코드를 생성하더라도 모든 줄을 다시 읽고 기도할 필요가 없게 만든다.

왜 지금 중요할까

두 가지 추세가 교차하고 있다:

1. LLM은 제한된 어휘(문법, JSON 스키마, EBNF)에서 오류가 거의 없이 코드를 생성할 만큼 충분히 발전했다.
2. 2023년 이후 소프트웨어 엔지니어링 커뮤니티는 DSL을 과도하게 비용이 많이 든다고 판단해 거의 포기했다.

사정이 바뀌었다. DSL 설계 비용은 동일하지만 그 혜택은 폭발적으로 증가했다. 잘 설계된 DSL은 "LLM이 코드를 작성하게 하는 것"을 "LLM이 구조화된 양식을 작성하게 하는 것"으로 바꿔준다. 신뢰성 면에서 한 단계의 차이를 만든다.

내부 메커니즘

• DSL은 절차적 로직(if/then, 제한된 루프)을 다룰 때 JSON 스키마보다 유용하다. 비즈니스 불변성을 문법 자체에 담기 때문이다.
• 가장 비용 효율적인 구현 패턴: LLM → DSL 출력 → 인터프리터 또는 액션으로 컴파일. 여러분은 엄격한 프로그래밍 언어를 결코 떠나지 않는다. DSL은 중간 매개체일 뿐이다.
• 통하지 않는 경우: 출력 범위가 열거 불가능한 창의적 작업(마케팅 텍스트 생성, 이름 brainstorming 등).

결론

아키텍트에게: "LLM의 자유 텍스트 출력을 파싱하고 희망을 걸어야겠다"는 결정을 재고하라. 대신 LLM → DSL → 런타임으로 전환하라. 오류가 침묵에서 요란한 상태로 바뀐다.

LLM 제품을 만드는 팀에게: 다음 엔지니어링 노력이 프롬프트 엔지니어링이 아니라, 여러분의 도메인이 허용하는 것을 포착하는 미니언어 설계에 있어야 한다. 이는 언어 설계자라는 직업의 부활이다.只不过 이름의 위상은 떨어질 뿐이다.

장기적 부채: 잘 설계된 DSL은 다음 모델 세대에서도 살아남는다. 거대한 프롬프트는 그렇지 않다.