또 하나의 지옥 – configuration hell.
2000년대 초 Windows Platform 기반하에 프로그래밍을 한 경험이 있다면 Dll Hell 을 들어보셨을 겁니다.
.NET이 나오고 나서 그 문제들이 해결 되었는데요.
요즘은 개발자들을 괴롭히는 새로운 Hell이 있으니 이름하여 Configuration Hell 입니다.
만약 여러분이 Configuration (설정부)를 사용하지 않고 프로그래밍을 즐겨 하신다면 별 감이 안오시겠지만..
.NET , Java 개발자라면 대부분 동감이 가는 단어일 것입니다.
위 플랫폼의 개발자들은 변화에 유연한 대처를 하기 위해 Metadata 지향적인 모델을 자주 사용합니다.
그렇다 보니 개발자는 많은 설정 영역들과 파일들을 만들어 내게 됩니다.
충돌없이 관리하는 것 부터 설정 기능등을 일일이 공부해야 되는 괴로움 다 아시죠!
그렇다고 설정 파일을 안 쓸수도 없구? 어떻게 해결 해야 될까요?
현재 나와 있는 해결사례들을 공유해 보도록 하죠
1. 꼭 필요할때만 쓰자 – 필요없는 부분들을 간략화 + 관리 툴.
spring 2.0은 configuration hell 문제를 해결하기 위해 기존의 namespace 체계를 많이 간략화 시켰습니다.
그리고 더불어 Eclipse와 같은 툴들을 통해 쉽게 설정 파일과 섹션들을 쉽게 탐색, 관리, 재편집 할 수 있는 기능을 추가했습니다.
Microsoft WCF 도 복잡한 설정 파일로 유명한 녀석입니다.
역시 Service Configuration Editor 라는 관리 툴을 제공함으로써 관리하는 방법을 제공합니다.
2. DSL (Domain Specific Language)
그중 또하나의 대안으로 DSL을 만들자는 것입니다.
도메인에 특화된 언어를 만듦으로써, 복잡한 설정 파일의 지옥에서 벗어나자는 것이지요.
하지만 여기에는 배보다 배꼽이 더 큰 상황이 발생합니다.
누가 DSL을 만들 것이냐? 이것이죠?
거기다 범용성을 가지며 모든이가 동의하는 DSL을 만들기란 쉽지 않을 것입니다.
나만의 DSL을 만들면 되지 않겠나라고 반문하실수 있겠지만?
DSL의 핵심 아이디어중 하나는 Domain에 집중해 재사용성을 높이는 것입니다.
각각의 밴더들이 나만의 DSL을 만들기 시작하면 새로운 DSL Hell이 탄생할지도 모릅니다.
3. 실행 가능한 Guideline을 제공하는 툴을 제공하자 !
설정 파일을 관리할수 있는 Editor 형태도, DSL도 역시 그리 효율적인 해결책이 아닙닏.
물론 아무것도 없던 시절보다는 더 나아졌기도 했지만요.
이것은 Channel9에서 WCF가 왜 널리 사용되지 못하느냐에 대한 질문에 대한 아키텍트(Richard Hale)의 대답이기도 합니다.
설정 파일 편집 프로그램으로도 결국 사용자의 높은 참여도를 이끌어 내지 못했다는 것이죠.
Configuration Hell 을 탈피할 방법은 없을까요?
C#과 Delphi의 아버지인 Anders Hejlsberg 가 이끄는 Microsoft Pattern&Practice 팀은 이러한 문제의 대안으로 Software Factory를 대안으로 내세웠습니다.
Software Factory의 핵심은 실행 가능한 Guideline들, 모델링, 자동화 등이 결합되어개발자들이 쉽게 Software를 개발할 수 있는 도우미 툴을 제공하자는 것입니다.
DEV021 – Web Client Software Factory
근래에 Modeling Edition으로 DSL 기능까지 추가 제공함으로써 지금으로는 가장 좋은 현실적인 대안이라고 할수 있습니다.
자 지금까지 Configuration Hell을 극복하는 업계들의 몇가지 사례들을 알려 드렸습니다.
누군가 혹시 더 좋은 아이디어가 없으신가요?
더 세련된 방법이나 좋은 아이디어가 있으신 분은 의견을 개진해 주시면 좋은 컨텐츠가 만들어질수 있도록 도와 드리겠습니다.
Architecture 101 
config 못지 않은 hell을 저는 project hell이라고 생각합니다. 대표적인 것으로 asmx 프로젝트 들이죠. 보통 이를 위해 Service Facade Agent를 만들어 정리해 버리는 방법을 사용하는데(물론, COM+ 역시 유사한 방법으로 정리) 놀라운 점은 주변에 있는 대 부분의 개발자들은 이에 부정적입니다. 🙂 (99% 이상의 처리가 Intranet / 동일 Config 구성을 사용함에도..)
그 점에서 OSLO + DSL에 대해서는 님과 달리 부정적입니다. 이유는 님이 처음 언급하셨던 이유에서입니다. 문제의 본질은 개발현장 보다는 “제품”이 그 제품이 가지는 “확장성”에 초점을 두고 개발하고 있는 개발사가 아닌가 라고 생각합니다. 실제 개발현장은 “과장 된 확장성의 필요”를 느끼지 않고 있음에도 불구 하고 말이죠.
예린아빠님 >.
안녕하세요. 좋은 의견 감사합니다.
저 역시 하신 말씀에 동의하는 편입니다.
실제 현업에서 높은 생산성을 주지 않는, 즉 개발현장에 도움이 되지 않는 모델링 툴을 싫어 하는 편입니다.
실제로 traceability를 유지한다면서도, 유지하지 못하는 툴들을 — 혐오하는 편이거든요.
그래서 개인적으로는 약간의 코딩을 통해 반복되는 일을 자동으로 생성하고 다양한 plugin을 지원하는 EA를 매우 사랑하는 편입니다. 이런 다른 애기를 너무 했네요.
이글은 oslo가 나오기 이전에 언급된 것이며, 제가 관심을 가진 부분은 software factory입니다.
software factory는 oslo와는 다른 것이니 좀더 자세히 봐주시길 부탁드립니다.
oslo에 대한 자세한 정보는 .net expert 이건복 부사장니의 http://keon.egloos.com/4709125 를 참고해 주세요
저 역시 각 도메인을 존중해야지 하나의 통합된 경험을 제공하는 m언어를 필두로 하는 oslo 는 회의적입니다.
사실 dsl을 ms가 밀었지만, 현재 vs2010부터는 정식적으로 uml들이 도입되기 때문입니다. 그 만큼 모델링에 defacto가 된 uml을 oslo방식이 밀기는 힘들것 입니다. 이 부분에서도 ms의 내부 개발자들간에 많은 충돌이 있습니다.
말씀하신 것처럼 단순히 dsl 하나로는 별도 프로젝트에 도움을 줄수 없습니다. 저역시 실행 가능한 가이드라인과 생산성을 더해줄 수 관점에서 software fatory툴들이 괜찮다고 포스팅했습니다. 실제 software factory는 분산쪽, DB쪽등 해당 분야의 전문가라면 쉽게 설계하고 바로 실행 가능한 소스코드로 떨구어 줄수 있습니다.
그리고 관련된 과다한 설정파일도 직접 작성 하는 것이 아닌 자동 생성해 준다는 점에서 기존의 configuration의 지옥을 벗어나게 해주니 훨 낫다고 생각되어 포스팅 한 부분입니다. 🙂
좀더 software factory를 자세히 봐주시길 부탁드립니다.
그리고 한국의 기형적인 SI 위주의 프로젝트 외에도 다양한 프로젝트 유형을 지원해야 하는 Microsoft 입장도 나름 이해해 주어야 될듯 합니다. 🙂
다양한 문화와 생각을 가진 고객들의 피드백을 두루 받아야 하기 때문이지요.