덜 기술적인 사용자를 위해 도메인 특화 언어를 만들면 인력을 대체할 수 있다는 기대가 왜 현실에서 실패하기 쉬운지, 최선·최악의 시나리오와 조직 규모·지속적 유지보수의 문제를 통해 설명한다.
Haskell for all: 도메인 특화 언어의 유혹
===============
2024년 2월 29일 목요일
도메인 특화 언어의 유혹
===============
나는 많은 엔지니어링 팀이 예산 내에서 덜 기술적인 사용자들을 위해 도메인 특화 언어(DSL)를 만들 수 있다고 착각하는 것을 보아 왔다. 특히 그들은 이 도메인 특화 언어만 만들면 덜 기술적인 사용자들이 별 생각 없이 그 언어로 코드를 잔뜩 찍어낼 수 있고 아무 문제도 없을 것이며, 그러면 자신들은 다음 프로젝트로 넘어갈 수 있으리라 믿는 듯하다. 이런 일은 사람들의 기대처럼 거의 전개되지 않는다.
최상의 시나리오에서는, 덜 기술적인 사용자들이 당신의 도메인 특화 언어로 엄청난 양의 코드를 쏟아내고(바로 당신이 바라던 일!) 그 코드 말뭉치가 그 언어가 감당할 수 있는 한계를 밀어붙이게 된다(예: 성능, 컴파일 속도, 기능, 통합 지원 등). 사용자 기반이 클수록, 언어를 갖가지 방식으로 개선하라는 요구는 더욱 커진다.
최악의 시나리오에서는, 당신이 최선을 다했음에도 사용자들은 그 언어로 일을 그르치는 점점 더 터무니없는 방법들을 찾아낼 것이고, 당신이 “사용자들은 머리 쓸 필요가 없다”라는 전제로 프로젝트를 팔았다는 이유로 그 엉망진창을 수습하라는 기대를 받게 된다.
…그리고 어느 쪽이든 이 과정은 끝나지 않는다. 프로젝트는 결코 “완료 상태”에 도달하지 못하고 상시 인력이 필요해진다. 심지어 이 언어 지원을 위해 전담 팀을 꾸린다 해도, 덜 기술적인 사용자들의 요구를 따라잡는 일은 여전히 고된 싸움이 된다.
그럼에도 이런 트레이드오프는 기업을 유혹한다. 숙련 인력을 비숙련 인력으로 대체하는 발상이 매력적으로 보이기 때문이다. 즉, 더 숙련된 소수의 인력(도메인 특화 언어의 저자)에게 소액을 투자하면, 덜 숙련된 더 큰 풀(비기술 사용자)이 대부분의 일을 해줄 것이라는 논리다. 그러나 현실에서는, 이 더 큰 집단의 비기술 사용자들이 언어를 만든 엔지니어들의 지속적인 도움 없이는 자주 막힌다는 사실을 종종 목격하게 된다.
따라서 실제로는 숙련 인력을 비숙련 인력으로 대체하는 것이 아니다. 오히려 숙련 인력을 비숙련 인력으로 “세탁”해 보이게 만들고, 엔지니어들이 실제보다 더 대체 가능해 보이도록 그들에게 더 많은 일을 떠넘길 뿐이다.
물론 도메인 특화 언어가 말이 되는 상황도 있다. 하지만 보통은 소프트웨어 엔지니어링 조직 규모나 심지어 소규모 제품 수준에서도 잘 맞지 않는다. 개인적으로 이런 분업은 규모의 경제를 충분히 누릴 수 있는 오픈 소스 생태계 수준에서만 대체로 작동한다고 본다.
게시자: Gabriella Gonzalez 오전 4:47
이메일로 보내기블로그에 게시!X에 공유Facebook에 공유Pinterest에 공유
MrNycticorax2024년 2월 29일 오전 10:31
Dhall은 도메인 특화 언어가 아닌가요? 아니라면 왜 아닌가요? 맞다면, Dhall이 작은 회사의 소수 팀에 의해 작성된 가상의 세계에서는 무엇이 문제가 되었을까요?
1.  [Knut Anders](https://www.blogger.com/profile/02523879713754996103)[2024년 3월 8일 오전 4:43](https://www.haskellforall.com/2024/02/the-siren-song-of-domain-specific.html?showComment=1709901833813#c9178256416650039879)
저는 Dhall이 다르다고 생각합니다. 덜 기술적인 사용자를 대상으로 한 언어가 아니니까요.
[답글](javascript:;)
누구든 어떤 언어로든 코드를 쓰기 전에 먼저 사고(논리적으로)하는 법을 배워야 합니다.
[답글](javascript:;)
구독: 게시물 댓글(Atom)