IT 임원들은 업체들의 말에 따라 잘 휘둘리고 우유부단한 경향이 있다며 기술 표준을 만드는 기관에 대해 험담하기를 즐겨한다. 하지만 표준은 정보 기술뿐만 아니라 비즈니스 IT를 형상화한다. 이에 일곱 가지 핵심 시장 부문에서 가장 문제가 되는 표준을 다룬다.

글 싣는 순서
1. 개요
2. 엔터프라이즈 애플리케이션
3. 보안
4. 서버 및 스토리지
5. 네트워크 관리
6. 무선
7. 인프라
8. 메시지 및 협업

사실 표준이 없다면 인터넷은 존재하지 않을 것이며, 기업간 통신은 불가능에 가깝고, 장비 업체의 통제 하에 놓이게 될 것이다(IBM SNA나 디지털 DEC넷을 돌이켜보라). 표준이 네트워크와 애플리케이션에 미치는 영향은 아무리 강조해도 지나치지 않다. 그리고 이것이 바로 우리가 주요 기술 영역들, 즉 엔터프라이즈 애플리케이션, 보안, 서버 및 스토리지, 관리, 무선 및 네트워크 인프라 등에서 핵심이 되는 표준을 집중적으로 다뤄보고자 준비한 이유기도 하다.
우리의 기술 전문가들은 비즈니스에 가장 큰 영향을 미치게 될 표준에 대해 논의를 했으며, 그 의제는 WSDL, SOAP 및 UDDI 등과 같은 웹 서비스 약어들이었다. 이러한 표준은 기간 비즈니스 애플리케이션들간에 전례없는 상호운용성을 가능하게 해줬다. 마찬가지로 중요한 사실은 이들이 BEA, IBM 및 오라클과 같은 주요 ISV로 하여금 특정 업체에 구속시키는 락인(lock-in) 전략을 사용하지 못하게 만든다는 것인데, 이는 곧 엔터프라이즈에서 단일 업체 스위트 만큼이나 간편하게 BoB(Best-of-Breed) 애플리케이션을 배치할 수 있다는 것을 의미한다.
한편 신용카드 업계에서 비롯된 데이터 보안표준은 민감한 데이터를 다루는 어느 조직에서나 적용을 시킬 수 있는 정보 보안 프레임워크를 제공한다. 또한 회사 운영에 영향을 미치게 될 새로운 개발품들에 대해서도 발빠른 정보를 담았다. ITIL과 같은 베스트 프랙티스 표준들은 운영의 효율성을 향상시킬 수 있으며, IT에서 엔터프라이즈에 비즈니스 가치를 전달하는 방식을 바꿔놓고 있다.
무선 기술은 인프라 배치에서의 일대 변화를 대변하는 것으로, 802.11n 표준은 초당 100Mb 이상의 원시 작업처리 속도를 약속하고 있다. 그리고 SIP와 SIMPLE은 진정으로 통합된 플랫폼에 대한 약속과 함께, 텔레포니와 메시징 부문을 혁신시키고 있다.

약어들, 그리고 그 배후의 힘
우리의 기술-정책 전문가들은 802.1x나 iSCSI와 같은 핵심 표준에 대해 필수적으로 알아야 할 교육 과정을 제시하고 있다. 이런 인프라의 버팀목들에서는 큰 변화가 거의 없지만, 새롭게 눈에 띄는 특징들이 있는데, 802.1x는 네트워크 허가 제어 시스템의 성공적인 배치를 뒷받침하고 있으며, iSCSI는 10기가비트 이더넷 덕분에 파이버 채널 SAN에 도전적인 존재로 부상하고 있다.
우리는 IEEE와 IETF 같은 기성 표준 기구들과 OASIS나 W3C 같은 신생 조직들을 대조시켜 봤다. 이런 비교적 새로운 조직들은 웹 서비스와 SOA의 등장 덕분에 막강한 영향력을 행사하고 있다. 하지만 그렇다고 오래된 이들을 무시해서는 안된다. 인프라에 역점을 두고 있는 이들이 애플리케이션 중심적인 사람들에게는 쓸모없어 보일지 모르지만, 이들은 관리, 무선 및 보안 쪽에서 여전히 왕성한 활동을 보여주고 있다. 그리고 아직 이런 조직에 가입하거나 참여하고 있지 않은 사람들은 일단 이 기사를 보고 나면 생각을 다시 하게 될 것이다.
우리는 또한 표준 기구의 내부 활동을 조명해 보았다. 사실 업체들이 자사의 이익을 위해 이러한 조직을 조정하려는 시도가 너무나 많이 이뤄지고 있다(가끔은 성공하기도 한다). 표준은 기술의 개발과 새로운 시장 형성에 큰 영향을 미치기 때문에, 이들은 내분, 중상모략, 괴롭힘, 강압 등과 같은 모든 종류의 음모들의 온상이기도 하다.

1엔터프라이즈 애플리케이션

‘떠오르는 SOA’… 전례없는 상호운용성 보장
서비스 지향형 아키텍처 애플리케이션 표준으로의 이동 덕분에 ISV나 기업, 양쪽 다 이러한 기반 표준을 지원하는 애플리케이션들간의 전례없는 상호운용성을 향유하고 있다.

조직들은 같은 언어로 얘기하지 않는 애플리케이션을 통합하는 데 진저리를 내고 있다. 하지만 JDBC나 ODBC 및 JMS와 같은 오래된 애플리케이션 표준들은 너무도 막연해 어떠한 두 가지 이행이든 상호운용되지 않기 때문에 표준을 처음 마련함으로써 생기는 이점이 무시된다.
이러한 상황은 이제 엔터프라이즈 애플리케이션 업체들에 의해 재정비되고 있다. 이들은 단순히 특정 사양을 따르는 대신 이니셔티브의 정신을 고수하는 방식으로 표준을 이행한다.
SOA(Service Oriented Architecture) 애플리케이션 표준으로의 이동은 ISV나 엔터프라이즈 모두에게 있어 그 기반 표준을 지원하는 애플리케이션들간에 전례없는 상호운용성을 제공하고 있다. SOA는 애플리케이션들과 커뮤니케이션을 하는 데 필요한 인터페이스에 초점을 둔다.
그 결과 신기술과 구기술들은 비슷한 종류의 애플리케이션과 상호운용될 뿐만 아니라, 가지각색의 비즈니스 서비스를 이용하고, 액세스를 제공하는 것들과도 상호운용이 가능하게 됐다. BPM(Business Process Management)과 SOBA(Service-Oriented Business Applications)는 UDDI, WSDL 및 SOAP 등과 같은 표준을 이용함으로써 ESB(Enterprise Service Bus)와 서비스 지원 레거시 애플리케이션의 혜택을 쉽게 맛볼 수 있다. 관리와 거버넌스(governance) 애플리케이션은 애플리케이션 전용 클라이언트 빌드를 재구성하거나 배포할 필요없이 자신들이 제어하는 서비스와 일반적인 클라이언트 사이를 중재할 수 있다.
SOA 기반 개념의 수용 덕분에 모듈러 엔터프라이즈 등급 애플리케이션이라는 개념이 현실화됐다. 코어 SOA 표준을 사용함으로써 진정한 플러그 앤 플레이를 얻을 수 있으며, 퓨전(Fusion) 이니셔티브의 오라클, 아쿠아로직(Aqua Logic) 제품군의 BEA, 그리고 웹스피어(WebSphere) 라인의 IBM 등과 같은 엔터프라이즈 서비스 플랫폼 업체들로부터 이런 아키텍처의 모습을 엿볼 수 있다.
장기적인 매출 흐름을 제공하기 위한 전략으로서 업체 락인(Lock-in)은 고객들이 계속해서 이러한 고정화를 거부하고 있기 때문에 ISV들에게는 급속히 과거의 물결이 돼어가고 있다. 오라클과 BEA는 SOA의 혜택을 보기 위해 자신들의 제품 아키텍처를 리엔지니어링하는 데 앞장서는 대표적인 업체들이며, 고객들은 한때 단일 업체 솔루션에서 가능했던 만큼이나 수월하게 BoB(Best of Breed)솔루션을 배치할 수 있는 혜택을 맛보고 있다.

WSDL
WSDL(Web Services Description Language) 파일은 클라이언트가 이해할 수 있는 용어(호스트 이름, 포트, 사용 가능한 운영 및 필요한 메시지 포맷 등)로 원격 서비스를 설명함으로써, 클라이언트가 원격 서비스를 인보크(invoke)할 수 있게 해주는 계약을 맺는다. WSDL에는 데이터 포맷(스키마), 운영(원격 서비스), 바인딩(프로토콜 설명), 그리고 종단지점(서비스 로케이션) 등에 대한 정의가 포함된다.
WSDL은 SOA의 느슨히 결합된(loosely coupled) 역동적 속성을 가능하게 해주는데, 이는 일반적 SOAP 클라이언트가 WSDL을 로딩하고, 그 WSDL을 기반으로 원격 서비스를 인보킹할 수 있기 때문이다.
WSDL 사양에서는 종단지점과의 통신용 HTTP만이 설명돼 있지만, 많은 업체들이 이미 JMS(Java Messaging Service)와 같은 추가 프로토콜을 지원하고 있으며, 이것은 SOAP용으로 신뢰할 수 있는 메시징을 이행하는 데 있어 베스트 프랙티스로 간주되고 있다. 지난해 본지에서 실시한 ESB 및 BPM 스위트 테스트에서는 WSDL에서 지정된 JMS 종단지점에 대한 지원이 늘어가고 있다는 사실이 밝혀졌다.
오라클, BEA, IBM 및 아파치 등이 모두 WSDL로의 JMS 익스텐션을 지원하고 있다. 하지만 JMS에서는 업체들간 이행에 약간씩의 차이가 있다는 게 문제다. 이로 인해 하나의 일반적 클라이언트를 배치할 수 있는 능력이 제한되며, 서비스 전용 클라이언트 배포가 요구된다. SOA는 전통적인 클라이언트-서버 배치 모델로 한정되기 때문에 이것은 말 그대로 심각한 문제가 될 것이다.
WSDL은 일반적인 업체 중립적 JMS 바인딩을 지원하게 될 것이며, 이로 인해 SOA 순수주의자들의 근심은 경감될 것이다. WSDL이 이런 프로토콜을 지원하도록 발전할 수 있다는 것은 이것이 가까운 시일 안에는 다른 메커니즘으로 대체되지 않을 것이라는 의미기도 하다. WSDL은 계속해서 SOA 스택의 모든 레이어를 함께 연결해 주는 느슨한 접착제의 역할을 하면서, 이를 통해 클라이언트가 원격 서비스로 액세스를 할 수 있는 표준 기반의 메커니즘을 제공할 것이다.
>> W3C 표준, 버전 1.1, w3.org/TR/wsdl

SOAP
SOAP(Simple Object Access Protocol)는 SOA 표준 기반에 놓여 있는 두 번째 초석으로서, 플랫폼과 업체 중립적인 형태로 커뮤니케이션을 하는 역할을 한다. 이것은 어떠한 레이어 7 프로토콜을 통해서든 전송이 가능하며, 단 주 프로토콜 전송수단은 HTTP와 JMS다.
가장 최신 버전인 SOAP 1.2에는 SOAP 메시지를 첨부해서 보낼 수 있는 능력이 포함돼 있는데, 이로 인해 많은 기업들이 HTTP를 통해 문서를 전송하기 위해 FTP 대신 첨부파일이 있는 SOAP를 선택하게 됐다.
SOAP는 WS-시큐리티(WS-Security), WS-폴리시(WS-Policy) 및 WS-어드레싱(WS-Addressing)과 같은 익스텐션을 통해 계속해서 진화하고 있다. 이러한 익스텐션들은 보안과 같은 기능성을 확장시키기 위해 SOAP의 포맷 유연성을 활용하며, 이러한 기능성을 지원하지 못하는 기존의 클라이언트를 깨뜨리지 않는다. SOAP는 당분간은 큰 변화 없이 지금의 상태를 그대로 유지할 것 같다.
>> W3C 표준, 버전 1.2, w3.org/TR/soap12-part1/

UDDI
UDDI(Universal Description Discovery and Integration)는 나온 지가 좀 됐지만 최근에 SOA 퍼즐에서 없어서는 안될 조각이 되면서 다시금 관심을 끌고 있다. UDDI는 원래 클라이언트가 원격 서비스의 로케이션과 정의를 찾을 수 있게 해주는 서비스의 레지스트리, 혹은 서비스의 카탈로그다. 클라이언트는 UDDI를 이용해 서비스를 룩업한 다음, WSDL을 확보해 서비스로 보낼 SOAP 메시지를 만든다.
UDDI v2는 가장 널리 지원이 되며, v3는 지난 몇 해 동안 세력을 확장해 가고 있다. 레지스트리는 최근에 보통 레지스트리/리포지토리, 혹은 거버넌스로 불리는 일련의 제품들로 성장해 왔다. UDDI를 기반으로 만들어진 이러한 새로운 제품들은 카탈로깅 기능성을 제공할 뿐만 아니라, 서비스 정책 감시와 서비스 수명 관리 기능을 제공한다.
시스티네트(머큐리인터액티브), SOA 소프트웨어 및 인프라비오(Infravio) 같은 업체들은 계속해서 UDDI 레지스트리의 역할을 확장시키고, 다양한 사양을 제공하도록 제품 내 기능성을 강화하고 있으며, 이 모든 것들은 UDDI 표준에 의해 지원된다. 장차 UDDI를 지원하는 제품들이 보다 보편적으로 채택이 됨에 따라 UDDI 거버넌스의 역할도 확장될 전망이다.
≫ OASIS standard, version 3
>> OASIS 표준, 버전 3, oasis-open.org/committees/uddi-spec/doc/spec/v3/uddi-v3.0.2-20041019.htm
>> uddi.org

조심해야 할 표준 하이재킹 기법
업체들은 IT 표준 기구들과 복잡한 관계를 맺고 있다. 참가에는 많은 돈과 시간이 들어가며, 표준은 업체들로 하여금 표준의 개발 진행 상태에 소프트웨어나 펌웨어를 동기화시키도록 강요한다.
한 가지 솔루션은 표준을 하이재킹하는 것인데, 여기에는 두 가지 잘 알려진 기법이 있다. 첫째는 디펙토(de facto) 표준으로 여기서는 강력한 한 업체가 시장의 영향력을 활용해 사양의 기본 규정을 만들고 참가에 대해 강력한 제어권을 행사한다.
시스코의 NAC(Network Admission Control)나 썬의 자바 같은 디펙토 표준은 선두권 업체들에게서 더 쉬운데, 그 이유는 의사결정이 보다 빨리 이뤄지고, 어떤 사양이 전달되든 참가자들이 쉽게 도장을 찍기 때문이다. 하지만 이들은 경쟁을 방해하며, 한 회사(와 그 수혜자들)에의 제어권에 놓이게 된다는 단점이 있다.
오픈소스 소프트웨어 표준은 원래 처음에는 디펙토 표준이다. 오픈소스 애플리케이션이 인기있음이 입증이 되면 디펙토 표준이 존재하게 되기 때문이다. 오픈소스 소프트웨어 표준 기구들이 있긴 하지만, 이들은 특정 문제에만 집중을 하며, 누구도 오픈소스 커뮤니티에 의해 공표되는 모든 디펙토 표준을 다루려 하지는 않는다(그래서도 안되지만).
좋은 소식은 일단 애플리케이션이 발표되면 오픈 소스 커뮤니티에서 막대한 인풋을 가지며, 변화를 만들기 위해 나오고 나면 오픈 소스 커뮤니티가 막강한 권한을 가지며, 그 영향력을 행사해 변화를 만들어낼 수 있다는 사실이다.
디펙토 표준의 변종으로, 최종 표준이 갖출 듯한 모습을 예견한 ‘프리스탠다드’ 제품을 발표하는 게이 있다. 업체들은 퍼스트 투 마켓(first-to-market) 제품이 최종 사양을 결정지을 만큼 충분히 큰 점유율을 확보하기를 희망하며 이러한 행동을 한다. 예를 들어 초기 무선 표준은 이것 때문에 진통을 겪었는데, 결과적으로 상호운용에 실패한 여러 업체 장비들이 나오고 말았다.
두 번째 표준 하이재킹 기술은 이것을 ‘수용 후 확장(embrace and extend)’하는 것이다. 그 목표는 유용한(하지만 전용인) 컴포넌트를 개방형 표준에 추가함으로써 기업들을 한 업체의 솔루션에 구속시키고자 하는 것이다.
수용 및 확장은 언제나 이기적인 방식이지만 반드시 불손한 동기에서 시작했다고 하기 힘든 경우도 있다. 마이크로소프트가 처음 마이크로소프트 파운데이션 클래스(Microsoft Foundation Classess)를 발표했을때, 이것은 C++의 확장판이었다. 하지만 C++에는 유저 인터페이스 디자인(User Interface Design)용 표준이 없었기 때문에 마이크로소프트는 윈도에서 이것을 처리할 수 있는 라이브러리를 만들었다. 역시 수용 후 확장의 케이스긴 하지만, 마이크로소프트가 이렇게 한 것은 UI 클래스 라이브러리에 대한 필요를 충족시키기 위해서다.
물론 누구도 익스텐션을 사용해야 한다고 강요당하지는 않지만, 실제로 이들은 시간을 크게 절약해 주며, 이는 곧 이들이 사용이 되고 업체 락인이 계속된다는 것을 의미한다.
기업들이 언제나 표준 하이재킹을 피해갈 수 있는 것은 아니지만, 이들은 몇몇 업체에 의해 지배당할 수 없다는 것을 반복해서 보여주고, 우수한 표준을 일관성 있게 발표하며, 부족한 점들은 완성된 제품에서 합리적으로 대응하는 표준 기구들을 지원할 수 있다.
Don MacVittie·dmacvittie@nwc.com

데이터넷 관리자