DSL이 LLM을 믿고 쓰게 만든다

TL;DR Highlight

작은 DSL과 검증기를 붙였더니 LLM이 의도대로 코드를 만든다

Who Should Read

LLM이 생성한 코드가 의도와 어긋나 리뷰 부담이 큰 백엔드 개발자

Core Mechanics

처음 쓴 스펙은 가설일 뿐
- 큰 시스템의 작은 설계 결정은 미리 다 알 수 없다.
- 제약과 엣지 케이스는 구현하면서 드러나므로 스펙을 반복해서 고쳐야 한다.
리뷰는 설계를 고민하게 만들지 않는다
- 생성된 코드를 읽는 것은 의도와 맞는지 확인하는 일이다.
- 코드를 직접 쓸 때는 책임 위치나 노출할 경계 같은 결정을 해야 한다.
DSL은 예시 몇 개면 충분하다
- Java 같은 범용 언어는 같은 의도를 표현하는 방법이 많다.
- DSL은 변형을 없애서 예시 몇 개만 줘도 올바른 문법을 만든다.
검증기가 에이전트의 하네스가 된다
- DSL에는 보통 파서, JSON 스키마, 타입 체커, 컴파일러 같은 검증기가 딸려 있다.
- 에이전트는 만들고, 검증하고, 에러를 보고 고치는 과정을 사람 없이 돈다.
- 에러가 "클라이언트를 고르기 전에 액션을 선택할 수 없다"처럼 도메인 말로 나온다.
LLM의 역할은 두 단계다
- 어휘를 만들 때는 브레인스토밍 파트너다.
- 어휘가 정해지면 그 어휘로 들어가는 자연어 인터페이스가 된다.

Community Reactions

DSL이 작게 유지된다는 전제가 핵심이라는 의견
- PlantUML은 학습 데이터가 많지만 새 DSL은 아니라서, 조합이 늘면 시스템 프롬프트 전체가 언어 설명이 된다는 지적이다.
- 검증기만으로는 부족하고 실제 컴파일러/실행기가 있어야 한다는 의견이다.
짧은 스펙으로도 충분했다는 경험
- 200줄짜리 DSL 스펙만으로 챗봇이 DSL을 다뤘다는 경험이다.
- 이미 만든 DSL에 프롬프트와 체커 도구를 붙이니 Gemma 12B QAT 같은 작은 모델도 좋은 스크립트를 만들었다는 경험이다.
SwiftUI에서는 효과가 없었다는 반론
- DSL이 자연어보다 형식적이어도 LLM과 소통하는 수단이 아니라 이점이 사라진다는 의견이다.
- 일반 언어 컴파일러가 더 많은 실수를 잡고, 추상화보다 풀스택을 보여주는 쪽이 낫더라는 경험이다.
검증이 정확성만 보면 부족하다는 경험
- GPU 커널을 에이전트로 생성했더니 컴파일되고 돌아가지만 기준보다 느린 코드가 나왔다는 경험이다.
- 속도 목표도 검증 조건에 넣어야 한다는 의견이다.
Goa DSL로 큰 서비스를 만든 경험
- Goa DSL과 코딩 에이전트로 OpenAPI 호환 서비스를 만들었더니 실수 범위가 좁아 막다른 길이 적었다는 경험이다.
- 보일러플레이트를 Goa 도구가 생성해서 모델이 안 써도 된다는 경험이다.

How to Apply

내 DSL/설정 스펙을 프롬프트에 붙여 돌려보기
- 오늘 쓰는 YAML이나 설정 포맷의 문법과 예시 2~3개를 LLM에 주고 새 항목을 만들게 하라.
- 결과를 기존 파서나 스키마로 검증해 통과율을 확인하라.
생성 결과를 검증기에 돌려 에러를 되먹이기
- 에이전트 루프에서 JSON 스키마나 타입 체커 결과를 그대로 다음 프롬프트에 넣어 재시도시켜라.
- 에러 메시지는 가능하면 도메인 말로 바꿔서 전달하라.
반복되는 도메인 개념을 타입과 함수로 이름 붙이기
- 프롬프트마다 다시 설명하던 스레딩이나 재시도 같은 결정을 라이브러리 타입으로 고정하라.
- 이후 프롬프트에서는 그 이름만 불러 로직만 쓰게 하라.
정확성 외 조건도 검증에 포함하기
- 성능 목표 같은 기준을 검증 단계에 넣어라.
- 통과해도 쓸모없는 결과를 걸러내라.

Try It

복사해서 바로 해보기

# Claude나 ChatGPT 대화창에 그대로 붙여넣기 (원문 방법의 간이 버전)

너는 아래 DSL의 자연어 인터페이스다. DSL 스펙과 예시에 맞는 결과만 출력하고, 설명은 붙이지 마라.

[DSL 스펙]
{{DSL 문법 설명}}

[예시]
{{요청 1}} -> {{DSL 출력 1}}
{{요청 2}} -> {{DSL 출력 2}}

요청: {{새 요청}}

이어서 해 볼 것: 출력을 파서나 스키마 검증기에 돌려 에러가 나면, 그 에러 메시지를 그대로 붙여 "이 에러를 고쳐서 다시 출력해"라고 요청해 보라.

Terminology

DSL한 도메인의 개념만 표현하도록 일부러 좁게 만든 언어다. SQL이나 Mermaid처럼 한 가지 일에만 쓰는 전용 도구다.

Semantic Model도메인의 개념과 설계 결정을 코드로 담은 모델이다. DSL 문법이 어떻게 실행되는지 정해 주는 설계도다.

Ubiquitous LanguageDDD에서 팀이 코드와 대화에서 함께 쓰는 공통 어휘다. 팀 사전 같은 것이다.

하네스(harness)LLM 출력을 일정한 틀 안에 붙잡아 두는 장치다. 말이 날뛰지 않게 하는 고삐 같은 역할이다.

in-context example프롬프트 안에 넣는 예시다. 모델을 다시 학습시키지 않고 문법을 보여 주는 용도다.