Zero-configuration: automatic lookup

Zero Configuration: Simple is best는 어렵다.에서 언급한 바와 같이, 현재 제작중인 소프트웨어의 모듈/시스템수는 엄청나게 증가해버렸다. 서로 연동해야하는 모듈이 많으니 이리저리 입력해야하는 네트워크 정보(각 노드의 IP와 Port)가 매우 많다. (제어UI에는 8개정도지만, 세밀하게 조정에 들어가면 셀수 없이 많다.) 이런 상황에서 각 노드들을 효율적으로 관리하려면 어찌해야 할까?

각 노드마다 설정을 전부 해야한다고 생각하면, 그 복잡도는 노드가 추가될 때마다 선형적으로 증가하며, 각 노드에서 필요한 기능-설정이 추가될 때 마다 기하급수적으로 증가한다. 언제까지 이런 설정을 반복하고 있을 수는 없다. 쉽게 생각할 수 있는 해결책은 중앙집중관리노드를 도입해서 실제로 기능을 수행하는 각 노드들이 중앙 노드를 바라보고 있는 Star형 토폴로지를 구현하는 것이다. 이러면, 문제가 해결될 것 같지만 크게 2가지 관점에서 결정적인 단점을 가지고 있다.

  1. 전체 시스템의 복잡도는 전혀 줄어들지 않으며, 다만 중앙 노드로 압축될 뿐이다.
  2. 중앙 노드에 장애가 발생할 경우, 전체 시스템이 동작하지 않는다.

이런 단점을 최소화하는 모델이라면, 전화번호부 모델이 있다. Java Jini나 Web Service에서 활용하는 Naming 서비스 혹은 Directory서비스가 대표적인 사례인데, 필요한 노드(서비스)의 위치를 관리하는 Naming 서비스를 도입하여, 각 노드간 통신을 위해 필요한 위치정보를 URL 혹은 그와 유사한 형태로 저장하여 서로 Lookup을 하게 하는 것이다. Respository나 Directory 서비스의 복잡도는 상대적으로 낮은 편이다. 권한이나 인증같은 부분을 제외하고 생각하면, 등록과 조회만 있으면 된다. TCP/IP네트워크에 익숙하다면, DNS를 생각하면 된다.

실제 데이터를 주고 받기 위한 통신 채널은 각 노드사이에서 형성되므로 Naming 서비스는 단지 ‘전화번호부’의 역할만을 수행한다. 각 노드들 역시 Naming 서비스의 위치만 설정해주면 되므로, 설정은 더더욱 간편해진다.

중앙 노드로 압축되는 복잡도의 문제는 어느정도 해소가 가능해졌지만, 중앙 노드의 장애에 대한 문제점은 아직 남아있다. Naming 서비스의 이중화로 해결할 수 있는 문제일 수도 있겠지만, Naming 서비스의 조회결과를 로컬에 캐쉬하는 방법도 있다. 노드들이 급격하게 위치를 변경하는 시스템이라면 독이 될 수 있지만, 위치가 그렇게 급격하게 변하지 않는 다소 정적인 시스템이라면 충분히 위력을 발휘할 것으로 생각된다.

멋져 보이지만, 마지막 결정타가 하나 남아있다. 이건 ‘Zero-Configuration’ 이 아니다. 여전히 사용자는 Naming 서비스의 위치를 ‘설정’해주어야 한다. TCP/IP에는 Broadcasting이라는 멋진 방법이 존재한다. 각 노드들에 Naming 서비스를 설정하지 않아도 Broadcasting으로 Naming 서비스를 찾아낼 수 있다. 물론, 수동 설정도 가능해야 하겠지만 말이다. 🙂

XML, XPath 그리고 소프트웨어 테스팅

보통 TDD(Test-driven development)는 잘 짜여진 테스팅 케이스를 이용해 소프트웨어의 수행 결과를 점검하는 형태로 이루어진다. 문제는, 이 방식의 접근은 처음부터 TDD를 하지 않으면 적용하기 힘들다는 거다!

게다가 최근 TDD가 없이는 개발이 불가능한 상황에 봉착했다. 입력 데이터의 종류는 수없이 많고, 이 데이터의 조합에 따라 서로 Side-effect를 발생시키는 골머리아픈 상황이다. (소프트웨어 설계가 잘못된건 아니다. 애시당초 풀어야할 문제가 이렇게 꼬여있다.) 설상가상으로 데이터의 종류가 무엇인지 알지 못하는 상황에서 종류를 guessing하고 조합해서 문제를 풀어야 할 정도니 말 다했다. 그리고, 출력되는 결과물도 굉장히 다양하다. (그 입력만큼이나 복잡하다)

프로게이머도 아닌데 엄청난 키보드+마우스 컨트롤을 자랑하며 테스팅을 할 수는 없는 노릇이고 해서, 간단한 테스팅 프로그램을 도입해서 문제를 해결하기로 생각하였다. 입력데이터를 잘 준비해두면 생성된 결과물을 잘 검사하기만 하면 되는 일 아니겠는가?

이 정도만 되면, 문제를 해결하기는 쉬울 것이지만 검사해야 할 항목들이 자주 변한다는 사실을 깨달았다. 입력데이터별로 차이도 존재하고, 데이터 종류에 따라, 또 그 조합에 따라 항목은 계속 바뀌어야 한다. 이쯤되면, 간단한 스크립트 언어를 만들어서 검사항목을 쉽게 변경할 수 있게 하면 되리라는 생각이 든다. 어머나. 배보다 배꼽이 커져버렸다. 🙂

그래서, XML과 XPath를 도입하기로 했다. 수행결과를 XML로 남기고, 남겨진 XML파일이 가져야할 조건, 즉 정상적인 생성물의 조건을 XPath 표현식으로 작성하는 것이다. TDD의 용어로 말하면, XPath 표현식은 Test case가 된다.

시험적으로 전체 시스템의 일부에만 적용해 보았는데 아주 마음에 든다. 물론, 서로 의존관계에 있는 XPath 표현식을 계층적으로 처리해주는 작업을 해야하긴 하지만, 그건 천천히 해도 될 것 같다. 🙂

ps. 관련된 코드와 예제를 공개하고 싶지만, 작업하다보니 대외비 코드가 너무 많이 들어갔네요. T_T