2008. 10. 23. 20:42

디바이스 미들웨어 사용 아키텍처 - ALE 정확히 알기

RFID 시스템을 꾸밀때 RFID Middleware를 사용하느냐 마느냐의 문제로 설왕설래가 많다. 초기 RFID 프로젝트가 진행될때는 누구나 RFID Middleware를 써야한다고 알았다. 아니 알았다기 보다 잘 모르지만 어려운 RFID를 사용하기 위해서는 Middleware라는 소프트웨어를 반드시 써야만 하는 것으로 막연히 설득을 당한 것이다. 그 가격도 작게는 2,000만원에서 많게는 몇억까지도 비용으로 책정하기도 했다.
하지만 그러면서도 하는 일을 보면 RFID 리더에서 태그 데이터 읽어 들이는 역할이 고작이었으며 그렇다고 태그의 100% 신뢰성을 보장하지도 못했고 무엇인가 현장의 요구사항이 있으면 이건 할 수 없다라는 대답을 듣기 일쑤였다.
그렇게 된 원인은 RFID Middleware의 정의와 구현도 제대로 하지 못했을 뿐 아니라 그것을 현장에 적용하는 인력들의 자질 문제가 무엇보다 더 컸었던 것 같다. 단순한 실험실의 연구용과 기업 현장에 적용하는 실제 환경은 매우 큰 격차가 있다.

일이 이 지경이 되다 보니 초반에 비싼 비용을 지불하고 무용지물(?)에 우롱당한 고객들은 RFID Middleware라고 하면 무조건 필요 없다라는 반응을 보이곤 한다. 더욱이 초반 RFID 개념에 대해 교육을 하면서 RFID Middleware에 대해 설명을 할 때 어떤 이는 이른바 표준이라고 하는 EPCglobal의 과거 Savant 와 현재의 ALE 만을 논하면서 이론적으로만 가르치거나(주로 연구소 또는 연구소에서 창업한 회사) 또는 그에 대한 반대 급부로 RFID Middleware 무용론을 설파해 교육을 받는 이들로 하여금 혼란만을 주었다. (본인도 그 중에 한명이라서 그 분들에게 미안하다.)

하지만 이에 대한 정리는 여전히 제대로 되고 있지 않은 듯 하다. 이를 정리하려면 RFID Middleware 를 어떻게 사용해야 하는지 그 구성 아키텍처를 이해해야만 할 것이다. 기업내의 시스템 아키첵처에 대해서는 앞선 글에서 이미 논의되었고 이에 대한 이해가 있어야만 앞으로의 글들도 이해가 될 것이다.

먼저 많은 사람들이 RFID Middleware 는 곧 EPCglobal의 ALE (Application Level Events)라는 등식으로 오해하는 경우가 많은데, 이 부분에 대해 자세히 짚고 넘어 가자.

ALE 라는 것은 앞에서도 언급한 바와 같이 애플리케이션과 미들웨어간의 통신을 위한 인터페이스 표준이라고 할 수 있다. 다시 말하면 애플리케이션이 리더나 디바이스에서 데이터를 읽어 들이고자 할때 어떤 식으로 서로 데이터를 주고 받을 것인지를 먼저 정의해야 하는데 (이를 통신 프토토콜이라고 한다.) 이를 표준화한다면 새롭게 정의하고 그를 검증하고 하는 절차가 줄어 드니 얼마나 편리하고 믿을 수 있겠는가? ALE의 유용성은 거기에 있는 것이다. 즉, 지금 새로운 RFID 애플리케이션을 개발하고자 하는데, RFID 리더에서 데이터를 읽어 들이고자 하면 ALE 인터페이스를 제공하는 미들웨어를 사용하여 데이터를 읽어 들일 수 있고, 나는 표준에 정해진 데이터 구조를 해석해 처리하는 방식이다.

사용자 삽입 이미지
<그림 1> ALE 사용 구조

ALE 가 사용되는 구조에 대한 설명이 <그림1>에 보이고 있다. ALE는 RFID 애플리케이션과 RFID Middleware 사이에 연결되는 방법이다. 그런데 여기에서 몇가지 문제점이 숨어 있다.

첫째, RFID 애플리케이션이 반드시 RFID Middleware의 존재를 알고 있어야 하며 ALE를 사용한 통신 방법에 대해 알고 있어야 한다는 점이다. 이것이 무엇이 문제이냐고 반문할 수 있겠으나 만일 기존에 RFID에 대해 전혀 알지 못하는 레거시 시스템을 사용한다고 가정하자. RFID를 이용하여 자동화에 따른 효율화를 위해 시스템 도입을 하게 되었으나 기존 레거시를 사용하지 못한다면 말이 안되지 않겠는가? RFID 애플리케이션이 새로운 업무 관리 애플리케이션이거나(이 경우에는 문제가 덜하다.) 기존의 레거시 시스템을 중계해주는 애플리케이션이 되어야 한다. 문제는 후자의 경우 괜히 쓸데없이 디바이스 미들웨어와 상위 애플리케이션 사이에 쓸데없이 또하나의 중계 애플리케이션이 존재하는 형태가 된다. 이는 하나의 병목 현상이 될 수 있으며 만일 이 애플리케이션이 제대로 동작하지 못할 경우 전체 시스템이 망가지는 구조가 될 것이다.
실제로 본인의 경험에 의하면 이 부분에 대해 간과하여 성능 좋은 RFID Middleware를 사용하였음에도 불구하고, 수많은 데이터를 수집했을 때 이 애플리케이션이 죽어서 데이터 수집이 되지 않을 뿐 아니라 성능에 대한 요구사항도 제대로 파악되지 않아 전체 시스템 성능에 매우 해악 요소가 되는 것을 보았다.
보통 이 애플리케이션을 코멘드 콘솔 프로그램으로 작성해 두고 이를 띄워놓는 경우가 많은데 윈도우 OS 환경에서 부주의하게 그냥 창을 닫는 바람에 전체 시스템을 죽이는 어처구니 없는 상황이 연출되는 경우가 매우 빈번하다. (심지어는 RFID Middleware 프로그램도 그런 경우가 많으니 정말 한숨이 나올 지경이다.) 이런 경우 이 애플리케이션은 반드시 daemon 형태이거나 윈도우 서비스 프로그램으로 작성하여야만 한다는 것을 잊지 말아야 한다.
또한 RFID Middleware에 해당하는 디바이스 미들웨어는 상위 애플리케이션이 어떤 형태의 데이터 구조를 요구하더라도 이를 지원하는 기능을 가지고 있어야만 한다.
무엇보다 이 애플리케이션 역시 시스템 안정성과 신뢰성 보장이 되어야만 한다. 사실 이런 역할을 하는 것이 디바이스 미들웨어의 상위 계층의 미들웨어 시스템이다. EAI (Enterprise Application Interface) 솔루션이나 ESB (Enterprise Service Bus) 등과 같은 솔루션이 될 수도 있고 미들웨어 서버 같은 형태가 될 수도 있다.

둘째, RFID 애플리케이션과 RFID Middleware의 위치도 잘 생각해 보아야 한다. 보통 RFID 리더는 당연히 현장에 놓일 것이다. 그러면 RFID Middleware 의 위치는 전산실과 현장 중 어디가 될까? 물론 둘다 가능하지만 디바이스 미들웨어가 가져야 하는 중요한 기능중 장비에서 수집된 데이터를 반드시 상위에 전달해 주어야 한다는 점을 고려해 보면 좀더 장비와 가까운 현장에 놓이는 것이 맞을 것이다. (이 부분에 대해서는 좀더 자세하게 다음 기회에 다룰 것이다.)
그렇다면 RFID 애플리케이션은 어떨까? 물론 현장쪽에 가까운 곳에 놓일 수도 있지만 이것은 좀더 중앙 집중적인 형태로 상위에 놓이게 될 것이다. 이때 ALE 방식은 <그림1>의 첫번째 ECSpec을 설정하기 위해 RFID 애플리케이션이 RFID Middleware에 접속하여야만 한다. (물론 ECSpec을 설정하는 대상과 ECReports를 받는 대상은 다를 수 있지만 어찌 되었든 누군가는 중앙에서 멀리 떨어진 RFID Middleware에 ECSpec을 설정해야만 한다.)
하지만 만일 RFID 리더와 미들웨어가 깊은 산골에 설치되어 있고 (국방부나 농림부 사례 대부분이 이런 경우이다.) RFID 애플리케이션은 중앙의 전산실에 있다고 생각해 보자. 일단 산골은 랜시설이 매우 열약하다. 겨우 ADSL 정도 쓸 수 있을까? 더군다나 더 큰 문제는 비공인 IP를 가진다는 것이다. 이것은 RFID 애플리케이션이 접근할 수 없다는 이야기이다. 만일 공인 IP를 가질 수 있다고 하더라도 보안상 문제가 있다. 반면에 방화벽으로 잘 둘러 싸여져 있는 RFID 애플리케이션은 공인 IP와 보안 관리가 나름대로 잘 되고 있을테고 전국에 설치된 RFID Middleware에서 잘 접근할 수 있을 것이다. 아니면 RFID Middlware가 ALE 방식이 아닌 (ECReports 데이터 구조를 사용할 수는 있겠으나 어찌되었든 ALE 표준 데이터 교환 방식은 아니다) 형태로 상위 애플리케이션으로 데이터를 전달할 필요가 있다.

셋째, 사용하는 방식에 따라 다를 수는 있지만, ALE가 웹기반의 XML 문서를 기본으로 사용한다는 것도 문제가 될 수 있다. 이것이 좀더 상위 애플리케이션 레벨끼리의 통신에는 매우 유용하지만 좀더 빠른 실시간성을 요구하는 수직축에 있어서는 성능에 많은 저하 요인이 되기도 한다. 이런 경우는 바이너리 포맷의 플랫 데이터 형태가 훨씬 빠른 성능을 제공할 것이다.

결론적으로 좀더 대규모의 분산된 실제 현장을 대상으로 시스템 아키텍처를 생각해 보면 ALE 방식이 그리 유용하지 않을 수 있다는 것을 알 수 있다. 미들웨어를 RFID 리더를 추상화하는 정도의 API 방식으로 사용한다면 매우 유용할 수 있으나 Application Integration에는 부족하지 않을까하는 생각이 든다. 일반적으로 표준이라는 것은 다양한 형태의 공통된 하나의 방법을 제시하는 것으로 특수한 모든 상황을 다 포용하지는 못하기 때문에 내가 구축하고자 하는 시스템이 매우 크리티컬하거나 성능에 많은 영향을 받는다거나 할 경우 ALE 사용을 고집할 것이 아니라 (표준을 지키지 못한다는 죄의식을 떨쳐 버리고) 과감히 자체 정의한 방법을 선택해야 할 것이다. 물론 그것에 대한 완성도는 스스로 보장해야만 한다.

Trackback 0 Comment 0