한빛출판네트워크

저자: 에드 덤빌(Edd Dumbill), 역 전순재

XML 천국(Arcadia)에서는 모든 것이 만족스럽다. 열심히 일하는 착실한 코더들은 복잡한 결합을 두려워하지 않고 XML을 사용하면서, 존경하는 표준 수호자들이 조심스럽게 그리고 고심하여 그들의 필요 하나 하나를 예비해둔 것을 알고 안심을 한다. 한 프로젝트에 착수하기 전에, 누구라도 기존의 작업을 활용해서, 서로 간에 최대로 상호운용성을 지켜야 한다. 아무도 유니코드 말고는 어느 코드도 사용할 생각조차 해보려고 하지 않기 때문에, ASCII 코드와 ISO Latin 1 코드는 희미한 기억 속에만 남았을 뿐이다. XML 표준에서 한 발자국을 내딛을 때마다 XML 세계에서 효율성은 증가하고, 상호 이해는 더욱 증진되며, 충만한 행복감이 따른다.

이렇게 기쁨이 넘쳐나는 XML 세계의 비전은 누구에게나 친숙하지만 실제로 있을 법해 보이지 않는다. 이러한 비전이 누구에게나 친숙한 이유는 소프트웨어 시장 어디에서나 들을 수 있는 로고송이기 때문이다. 원한다면 "XML"을 "웹 서비스", "닷넷"이나 "자바"로 바꾸어도 좋다. 그러나 이것은 실현 불가능한 일이다. 잠깐만 생각해 보아도 전혀 그와 같지 않다는 것을 알 수 있기 때문이다.

사람들이 XML을 사용하는 시스템을 개발하면서 마주치는 가장 격렬한 질문은 대개가 ‘어떤 XML 테크놀러지를 사용해야 하는가?’라는 질문일 것이다(이 질문에서 내가 표현하고 싶은 말은 SAX나 XSLT과 같은 처리 API뿐만 아니라, RDF나 SVG와 같은 문서 처리 형태 역시 포함). 여러분은 기존의 표준을 선택할 것인가? 아니면 여러분의 목적에 적합한 것으로 개발할 것인가?

서드 파티 표준을 사용하는 것에 대한 찬반 양론은 많이 있다. 그리고 어느 정도까지는 기존의 도구모음을 사용할 것인지 아니면 자신만의 도구모음을 만들 것인지를 고민하는 개발자의 고충 또한 반영한다.

몇 년간의 XML 개발 경험으로 미루어보아, 개방 표준으로의 길이 그렇게 편안한 길이 아님을 알고 있다. 개방 표준(예를 들어 데이터 저장방법(data storage)이나 전송 포맷(transmission formats)의 불건전한 상업적 통치를 피하는 것)에 대한 분명한 변호에도 불구하고 단지 표준이라는 이유 때문에 현행 모든 표준에 맹목적으로 얽매이는 것은 합리적인 정책이 아니라는 것은 분명하다.

개방 표준에 대한 기대감은 표준이 출현하지 않으면 개발자가 앞으로 나아가기에 앞서 우선 무기력하게 기다려야만 한다는 인식으로 무너져 내렸다. 사실 XML에 대한 상당수의 비판은 이런 오해에 근거를 둔다. 어쨌거나 XML 1.0을 사용하기로 결정했다면 즉시 W3C, OASIS, 또는 기타 등등의 기구로부터 나온 것들에 신세를 져야 한다는 오해말이다.

XML 개발에 자기-중심적 접근법을 추구하는 것이 가능한가? 명백히 이타적인 협력적 표준 개발작업으로부터 출현한 그러한 이점들을 그대로 유지하면서 말이다.

이기적이 될 수 밖에 없는 이유, 제 1부

XML 시스템 개발에 이기적으로 접근하는 법을 고려하게 되는 이유들부터 먼저 시작해 보자. 특히, 표준을 경계해야 할 이유들을 먼저 살펴보자. 이 기사 전체를 통해서, 필자는 주로 W3C와 OASIS가 주도하는 표준을 염두에 두고 기사를 작성할 생각이다. 왜냐하면 일반적으로 그 표준들이 XML 공동체에 아주 적절하기 때문이다.

불확실한 지적 재산권의 상황

표준을 사용하면 로열티를 침해하지 않을 것이라는 것을 어떻게 알 수 있겠는가? 이러한 일들이 이전에 Unisys사와 LZW 특허권에 일어났다. 이 특허권은 GIF 이미지 포맷에 영향을 미친다. 그리고 그러한 일들은 다른 표준들에도 또 일어날 것이다. 한 표준의 이타적인 채택이 이루어지려면 모든 부문에서 같은 수준의 협조가 동의할 때만 가능하다. 특허권이 있는 한, 언제라도 이런 위험은 있을 것이다.

W3C의 새 특허 정책의 의도는 최소한 이런 위험을 분명한 선험적 지식(a priori)으로 만들어서, 불확실한 지적 재산권의 상황의 불확실성을 제거하려고 하는 듯하다.

관계자들에 의해서 동요하는 표준

어떤 표준에서 일어날 수 있는 더욱 미묘한 효과는 표준이 움직이는 방향이 특정한 참여자들의 사업을 방해할 수도 있다는 것이다. 실제로 이 사실은 거의 항상 맞는 말이다. 그렇지 않으면 참여자들이 표준 개발에 관여하고자 하는 이유를 알기 어렵다. 표준화된 테크놀러지가 참여자들의 사업을 떠들석하게 지원하지 않는다고 하더라도, 참여자들의 정치적 이해관계에 의해서 영향을 받을 가능성이 높은 것이다.

XML 세계에서, XML 스키마(Schema)가 바로 이러한 예를 보여준다. XML 스키마가 처음 시작 되었을 때, 사람들은 마이크로소프트사가 참여를 거부하고 대신에 계속해서 독자적인 XML 스키마 테크놀로지인 XDR을 추구할까봐 몹시 걱정을 했다. 마이크로소프트사의 협력은 당연하게도 곧 참여하면 상업적 이점이 있다는 것을 의미한다(이 사실은 커머스 원(Commerce One - 세계적인 웹 서비스회사)사나 이미 XML 스키마 언어에 금전적 관심이 있는 다른 회사들에도 마찬가지로 적용됨). 그리하여 중요한 핵심 테크놀러지인 XML 스키마는 문제에 대해서 최선의 해결책이라고 생각되는 공정한 위치에서 시작한 것이 아니라, 정치적 합의의 위치에서 시작하였다. XML 스키마의 최종 결과는 사용하려면 맨 먼저 어느 정도는 상업적 소프트웨어의 사용이 요구될 정도의 이해하기 어려운 테크놀로지가 되었다. (그렇다, 오픈 소스 유효성검사기들이 있다. 그러나 XML 스키마의 디자인은 손으로 처리하기에는 한심할 정도로 어렵다.)

도입된 과대확장(bloat)

본래 특성상, 표준화된 테크놀러지는 광범위하게 요구사항들을 지원한다. 표준은 여러분이 필요로 하는 것 그 이상이 거의 확실하다. 표준을 채택한다는 것은 여러 가지를 의미한다. 첫째, 테크놀로지를 배우는데 시간을 들여야만 그 유용성을 판단할 수 있다. 둘째, 채택이란 필요한 것 이상을 다루기 위해 테크놀로지의 구현(이나 도입)을 의미하거나 또는 불필요한 것을 의도적으로 구현하지 않기로 하는 결정을 의미한다.

학습 곡선 문제는 여러 가지 면에서 중요하다. 많은 테크놀로지가 편리함의 증진을 약속하지만 사용법을 배우는데 드는 비용은 숨기고 있다. 이 사실은 컴퓨팅 플랫폼의 세계에도 적용된다. 기본 수준의 기능이 구현된 환경을 제공받는다고 하더라도 그 플랫폼을 배우려면 비용이 든다. 그리고 다시, 배우는데 들어가야 할 비용때문에 종종 다시 과거 플랫폼에 얽매이곤 한다. XML 세계에서 지금 일어나고 있는 유사한 예로는 SOAP가 있을 것이다. 메시지-처리 코드를 덜 작성해도 된다는 점에서 여러분은 더 편리해졌지만, 생각치 못한 사이에 방화벽이나 캐시와의 상호작용과 같은 고질적인, 그렇지만 아직 해결되지 않은 문제들에 깊숙히 의존하게 되는 것이다.

그래서 이기적인 관점으로 본다면, 복잡한 새 표준보다 간단한 예전 표준이 더 안전한 투자가 될 수 밖에 없는 실정이다.

이기적이 될 수 밖에 없는 이유, 제 2 부

지금까지 우리는 표준을 사용하는데 있어서의 위험요소들을 살펴 보았다. 표준을 맹목적으로 사용해서는 안된다. 그렇지만 표준을 사용하면 부인할 수 없는 혜택이 있다. 그러나 이는 철저하게 자신에게 이익이 되도록 해야 할 것이다. 이제부터는 이처럼 이기적이 되었을 때 어떤 긍정적인 측면이 있는지 살펴 보자. 수레바퀴를 다시 발명하려 한다는 오명에도 불구하고 "직접 고안한 바퀴를 굴리면" 많은 혜택이 있다. 물론, 그렇게 하지 않는 것이 현명할 때도 많다.

통제의 확보

자기 일은 자신이 가장 잘 아는 법이다. 가능한 많은 변수들을 통제할 계획을 세운다면 이 사실이 가장 필수적이다. 정보 배달을 시작하고 싶다면 표준이 완성될 때까지 6개월을 기다려야 할지, 아니면 사업에 필요한 요구조건들을 충족하도록 직접 문서의 구조를 정의해야 할지 선택의 기로에 봉착할 수도 있다.

제삼자가 개발한 표준에 사업을 맡길 경우, 이타주의를 훨씬 넘어서는 설득력 있는 사례가 있어야만 한다. 제삼자의 표준에 의존할 명분이란 새로운 사업을 구성하는데 그렇게 하는 것이 유용하든가 혹은 비용을 절감해줄 때를 말한다. 불필요한 재발명은 맹목적 채택만큼이나 우둔한 짓이다.

표준은 디자인이 잘 된 것과는 다르다

경제학을 제쳐 놓더라도, 개발자들은 시스템의 훌륭한 디자인에 강렬한 관심이 있다. 좋은 디자인은 외부의 종속성 때문에 위험에 처할 수 있다. 표준 테크놀로지가 좋은 디자인을 가지지 않을 수도 있으며 앞으로의 표준의 개발이 정상적인 방식으로 진행된다는 보장을 하지 않을 수도 있다.

만약 여러분이 좀 더 잘할 수 있다는 것이 확실하다면, 그리고 그렇게 하는게 여러분의 일을 거스르지 않는다면, 그렇다면 그 표준을 무시하는 것이 합리적이다. 반면, 표준을 채택해야 하는 상황이라면, 좀더 신중해 질 것을 추천하는 바이다.

한 표준의 채택이 여러분에게 미치는 영향의 정도는 제일 처음에 시스템을 어떻게 디자인하는가에 달려 있다. 대부분의 XML 표준에 내재한 불안정성 때문에 표준 그 자체를 중심으로 시스템을 구축한다면 장기적으로 보아 그 시스템의 건강에 해로울 수도 있다. 대신, 항상 독자적인 사업 데이터와 처리 모델을 중심으로 시스템을 구축하는 것이 합리적일 것이다.

표준을 가장 강력하게 주도하는 것은 기술이 아니라, 사업이라는 사실을 우리는 이해해야 한다. 결론적으로 다른 누군가의 사업이 여러분의 사업에 직접적으로 영향을 미치게 방치하는 것은 멍청한 짓이다. 표준과 교섭할 능력은 유지하되, 표준을 여러분의 중심전략 안으로 받아들이지는 말자. 만약 표준에 깊이 관련되어야 한다면, 표준의 개발에도 역시 깊이 관여하여야 할 것이다.

나중으로 미루자

시스템 개발의 위험요소중의 하나는 과도하게-규격화하는 것이다(over-specification). 다시 말해 미래에 필요한 것들을 예견하고 그것들을 완수하기 위해 시스템을 너무 복잡하게 만드는 것이 그 예라고 할 수 있다. 여러 가지 상황에서, 그러한 미래의 요구사항들은 실제로 일어나지 않을 가능성이 높다. XP(Extreme Programming, 소프트에어 개발 방법론 중의 하나)를 하는 사람들은 이것을 ‘과도한 최상위 디자인(BUFD, Big Up-Front Design)’이라고 부른다.

BUFD에 대한 교정수단은 꼭 필요한 것들만 구축하고, 다양한 요구에 응답하도록 시스템을 변경하는 능력을 보유하는 것이다. 예를 들어 위젯(widgets)을 제조하는 회사라면 ebXML 프로젝트의 결과로 설립된 테크놀러지를 이용하는 사업의 운영능력에 관심을 가질 것이다. 이런 회사는 내부 시스템을 개발할 때 이런 요소를 고려하고 싶겠지만, 어떻게 생각해 보더라도, 그런 시나리오는 아마도 2년은 걸릴 것이다. 합리적인 정책이라면 자신들의 직접적인 필요에 알맞게 XML 테크놀러지를 사용하는 것보다는, 오히려 전자 주문 수행에 필요한 광범위한 필수조건들을 알아내서, 이 비용때문에 나중에 구현하는데 방해가 되지 않도록 미리 대비를 해두는 것이 좋다.

현재의 경제적 환경에서는 어떤 사람도 향후 6개월간의 시장 상황이나 투자를 보증할 수 없다. 심지어 2년이라는 ‘짧은’ 기간조차도 상당히 길게 느껴진다. 최소로 필요한 것만을 구현하면서 변신능력을 유지하는 것이 그 어느 때보다도 더 합리적이다.

BUFD의 효과는 표준 그 자체에서도 역시 느껴진다. 표준에 더 전통적으로 접근하는 법은 테크놀로지의 특정 측면에 대하여 장기간에 걸친 합의에서 표준을 증류해 내는 것이다. ANSI C가 좋은 예이다. 그렇지만 XML 세계에서 우리가 현재 씨름하고 있는 상당수의 표준은 위원회에-의한-고안에 더 가까워서, 실험을 통해 검증된 확증이 부족하다. 태생의 특성상, XML 표준은 과도한-규격화에 몹시 취약하다.

그러한 표준 중 몇 개는 보편적인 요구사항에 손을 대지 않았기 때문에 시들어 버렸으며, 그렇지 않으면 경험에 의한 다음 세대의 조정 작업으로 넘겨졌다. 어느 경우든 초기에 선택했던 사람들에게는 상당한 비용이 들었다는 사실을 내제하고 있다. 따라서 개발자들은 조심스럽게 골라 선택해야 할 것이다.

이기적인 될 수 밖에 없는 이유, 제 3 부

만약 누구나가 위에서 언급한 신중한 자기-중심의 접근법을 채택했다면, 맨 먼저 XML을 가질 수 없지 않았을까? 솔직히, 내가 대략 기술한 이런 이기적인 정책은 희망찬 비전(visionaries)이라든가 신성한 미션(missionaries)으로 이어지지는 않는다. 그러나 개발자 공동체의 대다수는 세계를 변화시킬 준비가 되어 있지 않다. 대부분의 개발자들은 항상 보수를 받을 준비가 되어 있으며 그래서 그들은 먹고 살 수 있는 것이다.

사실, XML의 본질적인 특성 덕분에 이기적인 정책이 성공할 수 있는 것이다. XML 1.0과 네임스페이스(namespaces)을 사용함으로써, 여러분은 이미 다른 사람들과의 상호운용성에 상당히 연루되어 있는 셈이고 미래의 유연성을 보증받은 셈이다. 대부분의 경우에, 간단한 변환으로도 충분히 여러분은 외부와의 관계를 달성할 수 있을 것이다. XML의 주요 혜택은 시스템의 안쪽이 아니라, 바깥쪽에서 거두어 들이게 될 것이다.

반드시 이해해야 할 것은 XML이 플랫폼이 아니라는 것이다. 많은 회사들이 XML 시장을 하나로 만들고 싶어할지라도, 필요에 따라 더 많이 혹은 더 적게 사용하는 것이 전적으로 가능하다. 뿐만 아니라 이처럼 필요에 따라 사용하는 것은 매우 현명한 처사라 할 수 있다. XML이 주는 혜택은 중앙집중적인 방식으로 데이터를 교환하는 방법을 제공했다는 것이다. 이 방식에서 사람들은 자신들의 운명에 관한 통제권을 보유할 수 있다. 분명히 이것은 거대 기업의 일반적인 성향을 거스리는 것이다. 거대 기업들은 더욱 더 XML에 깊숙히 들어가서, 그래서 XML을 전부-아니면-아무것도-아닌 플랫폼으로 만듬으로써 우위를 회복하고 싶어한다.

이기적인(어떤 사람들은 실용적이라고 부르는 것을 더 선호함) 정책은 전적으로 XML을 사용하는 것과 같은 맥락에 서있다. XML을 채택하면 상호운용성(interoperability)과 유연성(flexibility)이라는 혜택을 당연히 누릴 수 있다. XML 1.0에는 표준화 기구들을 맹목적으로 따르는 전략을 준수하도록 강요하는 것은 전혀 없었으며, 현재도 강요하지 않는다. 표준은 자신을 채택한 사람들에게 가시적인 혜택을 제공하도록 제정되어야 하며, 또 그렇게 제공해야 한다. 그리고 통제를 추구하는 자들의 교활한 메커니즘이 되어서는 안된다.

마지막으로, XML 개발에서 이기적인 정책을 추구하는데 필요한 주요 권장사항들을 강조하면서 글을 맺겠다.

이기적인 선언

• 시간을 들여 자신의 필요를 이해하라
• 무언가가 "표준"이라는 이유로 자신에게 긴요한 기능을 포기하지 마라
• 자신의 필요에 알맞은 것을 골라서 선택하라
• 표준을 시스템의 핵심으로 묶지 마라
• 나중에 마음이 바뀔 때를 대비해서 차선책을 보유하라