마틴 파울러, DSL이 LLM 코드 생성을 신뢰할 수 있게 만드는 이유 제시

DSL 논의에 빠진 게 있음. linter나 LSP 같은 도구가 LLM에 추가 컨텍스트를 주는 게 진짜 중요한데 그 얘기가 없음. 예를 들어 플로팅 라이브러리는 컬럼명이 stringly typed인데 플로팅 전용 DSL이 있으면 LLM에 즉각 피드백을 줄 수 있음

요즘 나도 딱 이렇게 씀. 챗봇도 200줄짜리 DSL 스펙 정도면 충분히 다룸. 학습 데이터가 없을 텐데도 짧은 스펙이면 대부분 통하더라

GPU 커널 생성에서 부딫힌 문제가 있는데, 에이전트가 만든 코드가 컴파일도 되고 실행도 되는데 베이스라인보다 느림. 검증기는 통과라고 하는데 결과물은 쓸모없음. 정확성만 체크하지 말고 속도 목표도 검증 항목에 넣어야 함

PlantUML 같은 DSL은 학습 데이터가 수백만 개라 잘 되는 거고, 내가 만든 새 DSL은 그런 데이터가 없음(특히 json/yaml이나 함수 체인 형태가 아니면 더 심함). 조합 가능한 요소가 많아지면 시스템 프롬프트 전체가 새 언어 설명으로 채워짐. 그리고 DSL을 진짜 구현으로 컴파일하게 시키면 결국 원점으로 돌아옴

나는 ad hoc DSL이나 liquidsoap 같은 흔치 않은 DSL로도 LLM 잘 써봤음. DSL 자체에 마법이 있는 게 아니라 LLM이 명확하고 단순한 구조에 잘 반응하는 거임. 컴파일/실행이 꼭 필요한 것도 아니고 선언적으로 워크플로우 단계 체크포인트용으로만 써도 됨

DSL이 json/yaml이면 확실히 도움 됨. 정적 타입 체크처럼 문법 오류를 통째로 없애줘서 LLM이 의미에만 집중하게 해줌. 그리고 DSL을 구현으로 컴파일해야 하는 경우는 드문 편임, 대부분은 이미 구현체에 접근 가능하니까

DSL은 애매한 스펙을 명확하게 만드는 좋은 중간 지점인데, 규율 없으면 결국 계속 커져서 그냥 최종 언어를 에이전트가 직접 쓰게 되는 상황까지 감. 컴파일러나 린터가 도움되는 에러 메시지를 줘야 궤도 유지가 됨, 순수 서술적 DSL은 그냥 컨벤션일 뿐이라 강제 문법 계약만큼의 신뢰성은 없음

저는 그냥 LLM한테 DSL을 만드는 도구를 짜게 시킴. 그러면 지저분한 코드는 생성기 쪽에만 남고 서로 의존하는 것들이 stale해지지 않음. LLM이 자기 내부 개념에 맞는 DSL을 직접 설계하게 두는 거임, 이게 꽤 잘 되긴 하는데 실용적이라기보단 그냥 재밌어서 하는 거임

시스템 프롬프트 전체가 새 언어 설명으로 채워지는 게 뭐가 문제임? 예시 데이터 양에 너무 집착하는 거 같음. 요즘은 self-play RL이 데이터 효율 면에서 훨씬 낫음

같은 저자가 쓴 llm-learning-loop 글이 LLM 관련 글 중 최고였음. what-is-code 글도 이 DSL 글의 좋은 사전 지식이 됨

Thoughtworks랑 일해봤는데 뭐든 과하게 복잡하게 만드는 데 집착하더라. 이게 컨설팅 업계 자체의 습성인지 모르겠음

한국 IT판에서는 Fowler가 거의 전설임. 근데 궁금한 게, 단순하게 구현된 것도 설명은 항상 복잡해지는 느낌이 있음. 이게 한국만의 시각인지 서양도 마찬가지인지 궁금함

아이러니하게 Fowler는 오히려 엔터프라이즈 복잡함에서 벗어나려던 흐름(TDD, Spring, Rails, Agile, Refactoring, GoF 패턴) 쪽 사람이었음. 근데 Thoughtworks 자체는 Fowler 브랜드로 돈 버는 컨설팅 회사고, Sears랑 Siemens에서 같이 일해봤는데 다른 컨설팅사들이랑 똑같이 사람 더 투입하려고 과잉설계하더라