Zero-configuration이란 말을 처음 접했던 건, 한국에서 널리 사용되는 자막 파일인 SMI에 대한 지원을 Mac OS X용 통합 코덱(?)인 Perian에 넣을 수 없다는 애플포럼의 한 쓰레드 때문이었다. 요지는, SMI를 지원하기 위해서 자막의 인코딩 셋업같은 별도의 세팅이 필요하기 마련인데, 이게 Zero-configuration에 위배되기 때문에 SMI에 대한 지원을 넣을 수 없다는 내용이었다. (물론 이유가 이것만 있는 것은 아니었다.)

Zero-configuration은 말 그대로 설치 이후 설정이 필요없는 소프트웨어의 특성을 의미한다. 가장 많이 사용되는 분야는 네트워킹쪽인듯 한데, DHCP를 이용해서 랜선을 꽂거나 네트워크에 접속만 되면 IP부터 각종 네트워크 설정들을 알아서 세팅해주는 형식으로 구현된다. 뭐, 집에서 무선랜 환경을 구축하면서 이렇게 사용해보고 있는데 편하긴 무지 편하다. 묘하게 잘 작동하지 않는 윈도우 파일 공유 시스템과는 달리, Mac OS X의 파일 공유 시스템이 잘 작동하는 것도 한가지 이유이긴 하지만 말이다. (Mac OS X의 파일 공유 시스템 역시 Zero-configuration에 가깝다. 별다른 설정을 한 것도 아닌데, 바로 옆에 있는 iMac 17인치나 Macbook이 iMac 24인치에서 바로 잡히는 것을 보면 말이다.)

뜬금없이, 이 녀석 이야기를 꺼내는 이유는 역시 회사 제품 때문이다. 뭐, 이 문제가 두드러지기 전에도 이미 담당하고 있는 시스템이 보유한 모듈의 수가 100개를 훌쩍 넘어버렸고 그에 수반하는 옵션의 수가 엄청났다. 게다가, 각종 기능이 추가되면서 모듈간 통신(in-process)이 극도로 복잡해져버렸고, 이 시스템이 연동해야 하는 시스템의 수도 엄청나게 늘어버렸다. 이렇게 복잡해진 시스템으로 BMT시즌을 맞이 해보니 이건 난리도 아니다. 늘어난 기능, 모듈, 컴포넌트, 시스템의 수는 필요한 설정의 수를 폭발적으로 증가시켰고, 복잡한 레퍼런스가 없이는 시스템을 제대로 구동시킬 수도 없는 지경에 이르렀다.

물론, 잘 작성된 기본값들로 처리할 수 있는 문제일 수 도 있겠지만, 각 구성요소들이 어떻게 연동되느냐에 따라 기본값이 달라져야하는 상황은 참 머리 아플 따름이다. 이쯤 되면 2001년에 IBM에서 주창하기 시작한 자율적 컴퓨팅autonomous computing이 생각난다. 자율적 컴퓨팅은 Self-configuration, Self-healing, Self-optimization, Self-protection의 4가지 기조를 세우고 있는데, 이중 Self-configuration이 Zero-configuration과 맥이 닿아있는 듯 하다. 둘다 사용자가 머리아프게 설정하는 것이 아니라, 현재 상황에 알맞는 설정값을 세팅하는 것이니 말이다.

이런 상황은 딱히 현재 개발하고 있는 소프트웨어에 국한되어 있는 것은 아니라고 생각된다. Web 2.0이 도입되면서, 웹서비스를 이용한 inter-site 연동이 점차 부각되고 있는 상황을 고려해보면, 멀지 않아 개발자를 엄습할 공포가 아닐까?

아직 깊게 생각해보진 않았지만, 이 설정들을 처리하기 위해서는 과거에 연구되던 전문가 시스템의 설계에 입각한 작업이 필요하지 않을까 생각된다. 기존의 데이터(패턴 혹은 설정값)을 기반으로 연역적 추론을 통해 결론을 내리던 전문가 시스템의 특성은 이쪽에도 적용될 수 있지 않을까? 시스템이 어떤 식으로 구성되어 있는지를 입력받아 적절한 설정값을 만들어주는 기능을 추가해야할 시점이 된 듯 하다.

다행이라고 할 수 있을만한 것은, 과거에는 레지스트리와 ini파일에 의존해서 설정을 관리했지만, 현재 개발중인 시스템은 Property Script라고 하는 Java의 Property에서 영향을 받은 XML형태의 간단한 스크립트를 이용해 설정을 관리하고 있다. 레지스트리나 ini파일을 읽을 수 도 있고, 간단한 문자열 연산(replace나 substring따위)도 가능하다. 이 스크립트에 제어구문(제어 태그)을 추가해주면 문제의 해결에 도움이 될 수 있을 것 같다. 생각해보니, 다른 일로 논리구문(and나 or따위)을 XML로 구현해놓은 녀석이 이미 있다. XML의 장점이 무엇인가? 서로 다른 표준의 유연한 융합아니던가? 이 녀석들을 잘 조합해서 사용하면, 멋진 작품이 나올 수도 있겠다.

하지만, 복잡한 설정을 해결하는 로직을 설정파일에 도입하여, 그 복잡도를 증가시키는 것이 과연 옳은 일인지는 모르겠다. 자칫 잘못하면, 빠져나올 수 없는 무한루프의 수렁에 진입할 수도 있다. 또한, 제품을 지원하는 엔지니어들이나 고객들이 이해하기 어려운 설정파일도 피해야한다. 이쯤되면 나오는 건 한숨이다.

이런 난관이 존재함에도 불구하고, Zero-configuration은 반드시 지향해야 할 점이다. 언제까지 본사 기술자들이 나가서 설치할 수는 없는 노릇 아닌가? 글로벌한 소프트웨어를 위해서는 반드시 넘어야할 벽이다. Simple is best. 참 쉽지만 어려운 말이다.

Zero-configuration: Simple is Best는 어렵다.

Zero-configuration: Simple is Best는 어렵다.”에 대한 5개의 생각

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.