본문 바로가기
스터디/publishing

[HTML] 홈페이지 태그(Tag) 를 만든이.

by 깝태 2010. 1. 8.


1990년대 초 데이브 홀랜더는 CD-롬 브라우저용 마크업 언어를 고안했다. 이 언어는 초기 월드와이드웹과 함께 사용하는 것에 관해 일찍부터 논쟁이 됐지만, 그 당시 홀랜더의 고용주였던 HP는 지적재산권을 엄격하게 제한했다. 그 결과 HTML이 성공했다.


그러나 역사는 순환하기 마련이어서, 10년 후 HTML(Hypertext Markup Language)은 XML에 기반해 HTML을 대용하는 홀랜더의 또 다른 창작품인 XHTML이라는 언어에 그 자리를 내주고 있다.


홀랜더가 전자상거래와 웹서비스 분야의 데이터 집중 작업을 위한 문서 기반 테크놀러지에서 떠난 이후 오랜 시간이 흘렀지만 XML(Extensible Markup Language)에 대한 그의 초창기 작업이 웹을 그가 처음에 웹을 위해 계획했던 것 같은 것, 즉 기계가 더 잘 판독할 수 있는 모델로 되돌려놨다.


뉴욕 발드윈스빌 출신인 홀랜더는 미시간 테크에서 과학 학사 학위로 졸업하기 전까지 트럭 운전같은 임시 직업으로 돈을 충당해 학교를 다녔다. 요즘 그는 콘티보(Contivo)에서 CTO로 일하고 있다.


또한 46살의 홀랜더는 'XML 애플리케이션'의 공동 집필자이며, 'XML 스키마'의 기술 편집자이자, OAGI, 로제타넷, OBI, ECO 프레임워크 등을 포함한 표준화 작업에 조력하고 있다.


그는 W3C(World Wide Web Consortium)의 웹서비스 아키텍처 워킹그룹은 물론 XML 스키마 워킹그룹의 공동 의장이며, W3C의 권고 사항인 'XML에서 네임스페이스'의 공동 저자이다.


홀랜더는 콜로라도 러브랜드에 있는 자신의 집에서 CNet 뉴스닷컴과 데이터 통합과 웹서비스에 관한 그의 생각과 작업에 대해 얘기했다.


XML 개발에서 당신은 어떤 역할을 했는가?


90년대 초반으로 돌아가 보면, 나는 HP에서 CD-ROM에 관해서 (유닉스를 비롯한 여러 가지) 모든 매뉴얼 출판 작업을 관장했다. 이것이 웹의 초기 작업이었다. 그리고 나는 SDL(Semantic Delivery Language)이라는 언어를 개발했는데, 이 언어는 시맨틱 웹에서 할 수 있는 것이 없다!(웃음).


그 당시 SGML 언어가 있었는데 우리는 SGML 언어를 CD-ROM에 사용할 수 없었다. 그래서 SDL이 CD-ROM 브라우저에서 읽혀질 수 있는 매개 언어였는데, 그것이 나에게 하이 레벨 SGML을 컴퓨터에 더 밀접한 것으로 바꿔놓는 좋은 토론거리를 제공했다.


나는 월드와이드웹의 창시자이며 W3C 책임자인 팀 버너스-리를 포함한 내 동료들과 얘기했고, 우리는 그것을 이용해 웹에 접속할 수 있을 것이라고 생각했다. 그 당시 팀은 CERN(유럽핵연구위원회) 환경 내에서 웹의 선봉으로 작업하고 있었다.


팀은 웹에 대한 폭넓은 지원을 얻으며 작업하고 있었지만, 오늘날 우리가 알고 있는 것 같은 웹은 존재하지 않았다. 우리는 심지어 94년 4월까지도 상업적인 트래픽은 생각하지 못했다.


91년 데이븐포트 그룹(Davenport Group)이라는 비공식 단체가 있었지만, 나는 HP로부터 SDL 사용에 대한 (지적 재산권) 허가를 얻을 수 없었다. 그렇게 그들은 HTML 프로젝트를 시작했다. 그리고 우리가 이 문제가 분명해질 때까지 그 프로젝트는 잘 진행됐다.


이제 10년이 지났고, W3C는 HTML에서 XML에 기반한 대안인 XHTML로 옮겨가려 애쓰고 있다. 만약 HP가 IP 인증을 당신에게 줬다면? 우리가 이러한 변화를 겪지 않아도 돼지 않았을까?


아마도 힘은 덜 들었을 것이다. 이것은 일반적으로 커뮤니티가 별도로 정보를 처리하고, 마크업과 메타 데이터의 개념을 이해하기 시작하고, 그리고 컨텐트 뿐만 아니라 데이터에 대한 양상에 대해 관심을 가지기 위해 겪어야 하는 학습 과정이다.


내가 HP닷컴을 만들고 있을 때, 우리에게는 검색 엔진에 필요한 근본적인 메타데이터 세트가 있었다. 그리고 내가 그것을 계약에 추가할 수 있는 매니저가 될 때까지 그들은 페이지가 괜찮아 보이는 한 그것에 대해 걱정하지 않았다. 세계는 웹페이지가 고찰해볼 만하다는 것을 이해하기 시작했지만, 그것을 컴퓨터로 작업하기가 어려웠을 것이다. 사람들은 이제 웹 페이지 고찰의 필요성을 이해한다.


그래서 어떻게 HTML로부터 XML이 나왔는가?


1992년 제2회 W3C 컨퍼런스에서 였다. 그때 나는 내가 시작했던 HP닷컴의 웹마스터였다. 우리는 시카고에 가서 HTML 2.0을 다뤘고, 나는 웹 출판업자로서 적절한 기술을 찾지 못했다. 공항으로 돌아오는 길에 나는 (썬마이크로시스템 기술자인) 존 보삭과 택시를 함께 탔고, SGML보다 더 제한된 어떤 것이 있어야 한다는 데 생각을 같이 했다.


제한된다는 것이 무슨 뜻인가?


그것은 SGML에서는 사용되지 않았던 많은 것, 즉 웹에서 구현될 수 없었던 기능을 가진 깊고 풍부한 스펙을 의미한다. 오늘날 당신은 XML 툴과 파서를 어디서나 찾을 수 있다. SGML의 경우 겨우 3개가 있고, 구입하기에 매우 비쌌다.


우리는 계속 메타 언어를 갖는 아이디어를 가질 수 있기를 원했고, 다른 누군가의 시맨틱을 사용하고 싶지 않았으며, 고유 언어를 개발할 수 있기를 바랬다. SDL이나 HTML보다 더 심오한 더 높은 수준의 것. 몇 개월 내에 존은 함께 일했던 사람들로 팀을 구성했고 우리는 무엇이 XML이 되는 지에 대해 기안을 하기 시작했다.


우리는 우리 스스로 이 작업을 했다. 우리는 몇 개월 동안 토요일 아침마다 만나서 우리의 목표와 원칙을 계획했다.


그후 어떤 일을 했나?


나는 HP에서 커머스넷(CommerceNet)으로 옮겼다. 그들의 헌장에 대한 내 이해는 회사가 어떻게 사업을 하고 어떻게 보안, 임금 표준 등에 관련된 거대한 결함을 보완하는지를 조사하기 위해 회사간의 여백을 탐구하는 것이었다.


나는 카탈로그, 임금 분야에서 많은 일을 하려고 했고, 이런 B2B 트랜잭션 종류의 사업을 하는데 도움이 되는 XML 표준을 규정하기 위해 노력했다. 나에게 그것은 문서와 매뉴얼에 대한 생각을 멈추고 우리가 매일 사업에서 사용하는 툴이 되는 그런 것에 대해 생각하기 시작하는 방법이었다.


그후 나는 커머스넷에서 콘티보로 옮겼다. 도큐먼트든 B2B든 나에게 가장 큰 이슈는 변환이었다.


변환은 무엇을 의미하는가?


그것은 수신인이 정보를 보낸 발송인의 의미를 어떻게 해석하는가를 의미한다. 생각하기 쉬운 예를 하나 들면, 언어의 경우 프랑스어 'rue'를 독일어 'strasse'로 해석하는 것이다. 그 의미를 이해하고 발송인이 의미하는 것을 수신인이 할 필요가 있는 것으로 바꾸면 변환이 된다.


시맨틱은 개념의 의도를 이해하는 것이다. 나는 그것을 데이터와 행동의 경계로 생각하는 것을 좋아한다. 만약 당신이 같은 데이터를 보내고 5개의 다른 답을 얻었다면, 그 데이터에는 관련된 5개의 다른 의미가 있는 것이다.


'rue'를 'strasse'로 변환하기 위해, 나는 이것이 거리라는 것과 거리, 고속도로 혹은 길로 구별된다는 것 같은 기본적인 변환을 이해해야 한다. 의미있는 변환을 위해서는 정보의 의미론을 이해해야 한다.


이 모든 것이 W3C의 시맨틱 웹 활동과 어떤 관련이 있는가?


시맨틱 웹은 약간의 기본적인 기술을 기반으로 하는 연구 프로젝트이다. 만약 당신이 시맨틱 웹 프로젝트에 자금을 투자할 것을 고려하고 있다면, 그것은 주로 입회금이 아닌 연구 보조금을 통해서 투자하게 될 것이다.


기반 기술은 RDF와 DAML이나 OWL같은 온톨로지 언어이다. 그러한 기술은 완성됐거나 증명되지 않았고, 나도 그것들을 상업 제품에 구축하는 방식이 명확하지 않다. 그것으로 연구 프로젝트를 하는 것은 적절하지만, 아직 증명되지 않은 기술에 대한 대량의 계정을 나가서 팔 수는 없다.


시맨틱 웹과 인공 지능 사이에는 어떤 유사점이 있다고 생각하는가?


많은 사람들은 그것을 역사적인 평행선이라고 지적한다. 판정은 여전히 시맨틱 웹 밖에 있기 때문에 나는 그렇게까지 생각할 수 있을지 확실치 않다. 그리고 비록 AI가 불명예를 얻었다 해도 그것은 모든 장소에서 존립할 수 있는 기술로서 나타날 것이다.


비즈니스 인텔리전스, 의학과 임상 분석에서 AI 시스템을 요구하지 않아도 당신은 결정 시스템에서 AI 기술을 사용한다. 그렇지만 개념적으로 AI의 기본은 일종의 지식 나무로 정보를 이해하고 분류하는 방법이다.


KIF는 지식을 구축하는 관계를 묘사하기 위한 프레임워크이며, DAML은 또한 관련된 정보를 저장하기 위한 계층적인 구조이다. 만약 당신이 핀이 날카롭다는 것을 발견한다면 그것은 당신에게 그 정보를 계급내의 어디에 저장하는지를 보여줘서 당신이 나중에 날카로운 물체로서 핀과 못을 연상할 수 있다.


당신은 W3C의 XML 스키마 워킹그룹에 속해 있다. 스키마가 무엇인가?


일반적으로 스키마는 어떤 것이 설계된 패턴으로 구조와 데이터 종류의 형식적인 설명이다. XML 스키마는 DTDs(document type definitions)보다 훨씬 강력한 방법이다. 스키마는 당신이 관계있는 데이터베이스에 있기 때문에 데이터 종류를 매우 정확하게 하는 방법이 있다.


DTD가 어떤 점에서 안좋은가?


DTD로는 0과 100 사이의 날짜나 달러 가치를 설명할 방법이 없다. 모든 것은 문자열이며 당신이 할 수 있는 것은 그 문자열의 존재 여부 확인이 전부이다. 스키마는 또한 정보를 매우 다르게 구성하는 능력을 제공한다. 스키마는 네임스페이스를 지원하기 때문에 나는 DTDs로는 어려웠던 내 문서에 있는 네임스페이스를 적극적으로 사용할 수 있다.


네임스페이스란 무엇인가?

보통 XML 네임스페이스의 공동 작가로서 이 질문에 대답할 때는 길게 논쟁을 하게 된다. 컴퓨팅에서 네임스페이스는 XML에서보다 더 일반적인 개념이다. XML 네임스페이스는 누가 그 태그 세트에 대한 관계자인지 확인하는 방법이다.


그래서 XHTML 2에서, 페이지 중간에 (P)라고 써있는 태그가 있다면 그것이 누구의 단락 태그인가? 누가 컨텐트가 무엇일 수 있다고 말하는가? 네임스페이스를 사용하면 나는 XHTML과 그날의 이상한 언어를 구별할 수 있다. 네임스페이스는 우리가 스키마를 만들기 전까지 완전히 사용할 수 없었던 매우 강력한 툴이다.


우리는 문서의 종류를 설명하기 위해 XML 스키마를 사용한다. 나는 구입 주문이나 내 웹사이트의 연구 페이지를 가리키는 목록이 연결돼 있는 여러 페이지를 설명하기를 원한다. 그래서 나는 내 연구 기록과 도서 목록의 참조를 포착할 스키마를 만들었다.


그것은 모든 종류의 문서를 설명한다. 그것들은 일정한 구조와 예시를 갖고 있다. 나는 내가 데이터와 가지고자 하는 적절한 데이터를 포착한다는 것을 확신할 수 있다. 사업 관계에서 그것은 계약의 기초가 될 수 있다. 만약 당신이 나에게 이러한 압박에 관련된 모든 정보를 보낸다면 우리는 이런 종류의 거래를 하고 그런 것에 대한 출시 통지를 보내는데 있어 법적인 의미를 갖게 된다.


스키마와 웹서비스의 관계는 무엇인가?


매우 흥미로운 질문이다. 이 질문은 웹서비스 커뮤니티가 서로 상충하고 있는 근원에 대한 것이다. 현재 웹서비스 커뮤니티에는 두 개의 당이 있다. EDI, 즉 B2B 트랜잭션과 비슷한 것으로 생각하는 사람들과 시맨틱 웹의 전망으로 스키마를 생각하는 사람들.


웹을 좌우하는 원칙 중 하나는 부분적인 이해이다. 내가 완전히 이해할 수 없는 메시지를 받더라도 여전히 그것을 처리할 수밖에 없다. 사업 즉 상거래에 있어서, 내가 전체 메시지를 이해하지 못하거나 구입 주문서를 보내고 거리 주소나 제품 설명을 이해하지 못한다면, 당신은 최선을 다하지 못할 것이고, 우리가 이해할 때까지 그것을 되돌려보낸다.


당신이 웹에서 자전거에 관한 사이트를 찾아볼 때, 당신은 적당한 페이지로 가서 해결할 문제를 해결할 것이다.


문제는 웹서비스가 상거래 트랜잭션과 같은 역할을 할 것인가, 혹은 이런 것들을 시간보다 빨리 설치하는 방법에 대한 가능성은 없는가와 당신이 정보가 표현되는 방식에 최선을 다할 수 있는가 하는 것이다.


상업과 관련해서 스키마를 생각하는 사람들에게 스키마는 그러한 접촉을 만드는 방법이다. 이 정보를 나에게 보내면 나는 받았다는 통지로 구입 주문서같은 다른 정보 세트로 대답할 것이다. 나에게 주식 시세 요청을 보낸다면, 나는 당신에게 주가 정보를 보낼 것이다.


웹서비스 아키텍처 워킹그룹의 목표와 WS-I(Web Services Interoperability) 조직의 목표 사이에는 어떤 차이가 있는가?


WS-I(나는 회원이 아니다)의 목표는 이 새로운 기술이 상호운영이 가능한 방식으로 나타나는 것을 보증하는 것이다. 그들은 개발자의 표준이 되는 것을 목표로 하지 않는다. W3C의 목표는 업계 실행에 기반한 표준을 개발하는 것과 두번째로 전자통신에 관한 연구를 하는 것이다. 그리고 현재 상호운영이라는 목표를 달성하기 위해 함께 작업할 수 있는 최선의 방법을 찾기 위해 조직 간에 활발한 대화가 이뤄지고 있다.


당신은 MS와 IBM이 맨 처음 만든 WS-I가 W3C의 방식을 가로채려고 한다고 생각하는가?


아무도 없는 곳에 갈등을 만드는 것은 커뮤니티에 전혀 도움이 되지 않는다. 두 그룹이 상호운용성을 성취하기 위해 노력하고 있기 때문에 본래부터 약간의 갈등은 있다.


W3C는 SOAP, WSDL, XML를 통해 기반을 확고히 하고 있고, 웹서비스는 W3C에서 적절한 위치에서 근본적인 토대를 보강하고 있다. 나머지 작업을 하기에 가장 생산적인 장소는 어디인가? W3C는 프로젝트의 목록을 가지고 있다. W3C는 이러한 것을 성공적으로 할 필요는 없지만 이것이 웹 진화의 일부분이라는 것을 알고 있으며, 그 일부가 되기를 원하고 있다.


보안과 트랜잭션 표준중 어디에 비중이 더 있는가? W3C의 작업이 MS와 IBM이 발표한 표준과 어떻게 맞물리는가?


적극적인 교섭에 모든 질문이 있다. XML 디지털 시그니처는 W3C를 통하고 있고, 시그니처는 어떤 보안 표준에도 기초적 요소이다. 아키텍처에서 어디서부터 우리가 선을 그리기 시작해야 하는가? ISO에는 7층의 스택이 있다. 우리는 웹서비스를 위해 하나를 가져야 할 것이다.


다른 그룹이 W3C가 제공하는 것 위에 더 높은 수준의 보안을 구축할 것인가? 우리는 기다려 봐야할 것이다. 그러나 좋은 점은 내가 업계의 모든 사람들로부터 이러한 것이 상호운용이 가능한 방식에서 일어나도록 만드는 것이 얼마나 중요한지에 대해 들은 것이다. 유일한 질문은 성공하기 위해 가장 효과적인 방법은 무엇인가 하는 것이다. 브라우저 전쟁 시대에는 그것은 진실이 아니었다.


W3C가 현재 다루고 있는 RAND(reasonable and nondiscriminatory) 대 사용료 무료라는 지적 재산권 문제에 대해서는 어떻게 생각하는가?


나는 그것이 현재 전체 표준이 직면하고 있는 가장 기본적인 문제라고 생각한다. 지적 재산권에 대해 조사해야할 작업이 많고, 진행 방법에 대해서도 혼란이 많다. 그들이 한 작업에 대한 보답과 공공 영역으로 두는 것 사이에는 미묘한 경계가 있다.


만약 그것이 당신에게 달려있고, 당신이 황제 군주 독재자라면 어떻게 그 문제를 풀겠는가?


나는 배심원처럼 모든 사람을 방에 넣고 그들에게 합의를 끌어낼 때까지 나오지 말라고 말할 것이다. 나는 협정이 어떻게 되든 상관없다.


잠깐, 당신은 정말로 어떤 방식으로 결론이 나든 상관이 없는가?


내가 그렇게 말한 것에는 물론 모든 것이 무료가 되기를 바란다는 것도 포함돼 있다. 그러나 한편으로 나는 무료라는 것은 없다는 것을 안다. 그리고 속도와 과정에 대한 그것의 가격을 고려해 볼 때 나는 아마도 기꺼이 지불할 수 있을 것이다.


XML에 대한 당신의 업적에 대해 보상을 받은 적이 있는가?


없다. 직접적으로는 보상받은 사람은 아무도 없다. 우리는 단지 우리가 고민하던 문제를 풀기 위해 노력했을 뿐이다. XML은 업계에 의해 강요받은 것이 아니었다. 우리는 회사로부터 개인적인 프로젝트 수준으로 지원을 받았다. 우리 그룹은 서로 잘 알고 있는 12명으로 구성됐다.


이제 W3C에는 XML 활동과 관련된 12개 이상의 워킹그룹이 있다. 각 그룹은 50∼70명의 사람들로 운영되고 있다. 모든 회사들이 웹서비스에 미래를 걸고 있다. 이는 우리가 XML 작업을 했던 94, 95년과는 아주 다른 환경이다.