06.20
주요뉴스
뉴스홈 > 기획특집
[IT산업 20년 전] 범용 객체모델로 급부상한 ‘XML’1999년- 웹 개발 및 애플리케이션 통합 단순화
   
 

[컴퓨터월드] 웹 구축 환경에 대한 플랫폼, 웹 언어들은 계속 발전하고 있다. 과거 ‘XML’언어가 있었다면 요즘 각광받고 있는 언어는 HTML5이다. 과거 크로스 플랫폼 기능을 갖춘 XML이 부상했던 것처럼 현재는 크로스 브라우징을 갖춘 HTML5이 대세로 떠오르고 있다.

정부에서 추진 중인 논 액티브X에 적절성을 갖춘 HTML5가 주목받고 있으며 노 플러그인(No Plug in)으로 가는 과정에서 대체방안으로 실행파일(.exe)을 채택해 사용 중에 있다. 사용자들은 액티브X와 큰 차이를 느끼지 못해 불편함을 표하고 있다. 20년 전의 XML에 대해 살펴보고, 논 액티브X의 차원에서 HTML5를 조명해본다.


웹 문서로서 효율과 네트워크를 제대로 인지할 수 있는 XML

XML은 IP네트워크상 클라이언트와 서버 간에 데이터를 포맷하고 서로 교환하는 방식을 기술하는 메타언어다. 이 언어는 HTML의 확장으로 간주됐는데 하나의 애플리케이션에서 지속적으로 정보를 포맷, 구조화, 검색하는 데 사용될 수 있는 프로그래밍 태그를 많이 제공했다.

XML은 정적인 웹 콘텐츠를 개발하고 전개하는 데 HTML에 크게 의존했던 초기 시스템보다 상호작용성이 큰 역할을 하는 차세대 웹 애플리케이션의 개발에 사용되고 있었다. XML언어는 웹과 클라이언트-서버 및 레거시 시스템을 연계해야하는 기업들에 의해 다양한 방식으로 진행되고 있었고, 애플리케이션 통합 작업에 있어 매우 핵심적인 구성 요소로서 활용되고 있었다. XML과 그와 관련된 일부 기술들은 기업들이 파일 유형을 넘나들며 포맷된 데이터를 서로 교환할 수 있는 분산 애플리케이션을 쉽게 개발할 수 있도록 만들어줬다.

특히 당시 XML은 웹에 최적화 돼있고, 웹 개발에 의해 주도되고 있기 때문에 광범위한 토대를 가진 애플리케이션 개발 툴이나 시스템 관리 및 메인프레임 애플리케이션과 같이 인터넷을 초월하여 각종 시스템에 응용될 것으로 예상됐다.

XML이 개발된 계기는 SGML(Standard General Markup Language)에 대해 웹 문서로 이용되기에는 너무 복잡하기 때문에 조금 더 효율적이고 네트워크를 제대로 인지할 수 있는 사양의 필요성이 대두돼서 였다. W3C에서는 XML을 표준으로 제안했다.

XML은 데이터 표준 및 HTML의 대체 언어로서의 잠재력을 최대한 발휘하기 위해서는 기능적으로 보완이 필요했다. 하지만 XML은 IBM과 마이크로소프트, 오라클 및 썬 마이크로시스템즈 등 세계적인 IT업체들로부터 인정을 받고 있었다. 이들 업체는 개발 툴과 웹 유틸리티, DB 및 업무용 애플리케이션에 XML지원을 추가했었고, ‘오브젝트 디자인(Object Design)’과 ‘블루스톤 소프트웨어(Bluestone Software)’사가 XML서버를 발표하기도 했다.

HTML은 우선적으로 웹에서 검토할 수 있게 문서를 포맷하는 데 사용되고 있다. 반면 XML은 대부분의 언어와 애플리케이션과는 달리 이해하기 쉬운 포맷으로 데이터를 제시하는 데 있어 탁월한 기능을 갖고 있었다.

   
▲ HTML과 SGML, XML의 비교


어떠한 앱도 포맷 추출 가능

XML문서의 데이터는 파싱 가능한 애플리케이션을 모든 포맷으로 추출, 분석 및 제시할 수 있었다. 가령 오른쪽 디스플레이의 Figure가 XML로 마크업 된 세익스피어의 희곡 ‘햄릿’ 텍스트를 디스플레이 해 줌으로써 각 텍스트 문자열이 포함하고 있는 콘텐츠의 종류를 확인할 수 있다. 또 다른 애플리케이션이 데이터를 읽고 주석을 단 스크립트를 만들 수 있으며, 다른 애플리케이션은 등장인물 설명을 무시하고 대사 패턴을 분석할 수 있다.

   
▲ 희곡 ‘햄릿‘의 연극에 등장하는 각각의 파트를 보여주도록 XML로 마크업(컴퓨터월드)

당시 웹은 본래 이미지나 사운드 파일과 같은 객체를 조잡하게 응용한 텍스트 기반의 매체라고 생각했다. 하지만 XML로 마크업 된 텍스트는 크로스 플랫폼 혜택을 누릴 수 있으며 이해하기도 더 쉬웠다. 또한, 유연한 데이터 구조와 국제적으로 통용되는 특성들을 지원했다.

   
▲ XML의 텍스트 기능(출처:컴퓨터월드)


두 개 표준과 결합되면 풍부한 언어 기술 가능

XML은 XSL(eXtension Style Language)과 XLL(XML Linking Language)등 당시 부상하던 2개 표준과 결합될 경우 유연하고 확장 가능한 마크업 언어를 기술할 수 있을 것이라고 판단됐다. 또한, 웹 페이지의 데이터 포맷과 항해(link를 타고 들어가는 행위)를 서로 분리시킬 수 있었으며, 이러한 분리를 통해 시스템과 업무 요구에 따라 애플리케이션을 만들고 변경하는 작업이 훨씬 쉬워질 것으로 예측했다.

XSL은 캐스케이드 스타일 시트(Cascade Style Sheet)의 슈퍼셋(Superset)으로 HTML 파일을 유연하게 포매팅 해주는 표준으로 제안됐다. CSS가 HTML의 코드를 처리한다면 XSL은 XML 페이지 안에 포함된 데이터를 위한 거의 전적인 프로세싱 언어로서의 역할을 수행할 수 있었다. XSL은 단순한 구문(xsl: choose)과 특정 조건을 토대로 코드를 실행하는 프로그램 식 구조를 제공했다.

또한, 조건적인 가지치기(xsl: if)와 특정 조건이 사실일 때 그 코드 블록을 반복하는 조건 및 루프 테스트(xsl: for-each)를 지원했다. XSL 사양에는 두 가지의 부분이 있는데, 하나는 XML 문서를 변형하는데 사용되는 것이었고, 또 하나는 의미구조를 포매팅 하는데 사용됐다. XML문서를 변형하는 작업은 연관 패턴을 XML 문서 내에 포함된 소스 트리를 불러들이는데 XSL 템플릿을 사용하게 된다.

이것은 HTML로 포맷된 웹 페이지를 비롯하여 데이터를 모든 포맷으로 전환시키는 완벽한 유연성을 제공했고 XSL의 가장 큰 특성이었다. 나머지 XSL 사양은 사용자가 유연한 포매팅을 위해 설정할 수 있는 속성을 가지고 객체를 포매팅 하는데 사용될 수 있는 부분이었다.

XSL의 포매팅 객체는 여러 워드프로세서의 스타일 시트와 흡사하게 작동하므로, 그 사양이 요구한 포매팅 어휘를 사용했다. 또한 각각의 객체는 특정한 행위를 대표하는데, ‘페이지 숫자 객체’로 페이지 번호를 매기거나 ‘목록 흐름 객체’를 가지고 번호가 매겨진 목록을 포매팅 하는 것 등을 그 예로 들 수 있다.

   
▲ 포매팅 객체들(출처:컴퓨터월드)

XML과 XSL은 공히 커스터마이즈가 가능한 HTML에 상응하는 볼륨을 제공했다. 따라서 웹 디자이너들은 데이터를 포매팅으로부터 독립적으로 유지하면서 동시에 그것이 제대로 돼 있는지 확인할 때 그 언어를 확장하기 위해 마이크로소프트나 넷스케이프에 의존할 필요 없이 자신의 태그를 구별해낼 수 있다.

웹 페이지의 가장 중요한 특성은 일반적인 통념상 하이퍼링크를 통한 웹 페이지간의 이동이라고 생각한다. 하지만 당시 XML이나 XSL은 하이퍼링크를 사용하지 못하게 구성됐고, 이런 부분을 보완하기 위해 XLL이 개입된다. 이 XLL은 기존 HTML이 제공하던 문서 간 링크 및 문서 부문 간 링크보다 탁월한 웹 페이지를 제공할 수 있었다.

   
▲ 사용자들은 다양한 형태로 데이터를 디스플레이하기 위해
XSL 템플릿을 만들 수 있었다(출처:컴퓨터월드)

2개의 부문 중 Xlink는 문서에 복수의 목적지나 양방향성을 지닌 링크 혹은 고객 행위가 동반된 링크와 같이 진보적인 링크 기능을 제공할 수 있었다. 다른 XLL 부문인 XPointer(XML Pointer Language)는 특별한 태그나 페이지 구성요소와 배열, 임의 선택에 대한 광범위한 주소를 줄줄이 표시하지 않고 문서 내 각 위치에 대한 링크만을 제공했다. 웹 개발자 들은 문서 간 관계에 대한 통제력을 강화하고 싶을 때 이 기능을 활용할 수 있었다.

결론적으로 당시 XSL과 XLL 사양은 불완전했다. 하지만 이들 3가지 사양을 결합하면 HTML 문서나 소스 데이터를 서로 다른 포맷이나 거의 관계없는 문서 유형으로 처리해 넣은 잘 포맷된 XML문서를 생성할 수 있게 됐다.


접두사로 네임스페이스 문제점 해결

당시 XML의 장기적인 활약을 보장하는 징표들은 여기저기에서 나타났다. 가령 추론 표준으로서, 기타 표준의 토대로서, 다양한 소프트웨어 제품을 지원하는 것 등으로 활용됐다. IBM과 유니시스 및 기타 협력업체들은 자신들이 그간 협력해온 XML 메타데이터 인터체인지 프로토콜을 공개했다. UML(Unified Modeling Language)는 소프트웨어 프로젝트와 OMG의 메타 오브젝트 퍼실리티 리포지토리 표준을 모델링하는 방식으로 부상했다.

하지만 XML의 문제점이 있었는데, 이는 이름공간(Namespace)이 부족하다는 것이었다. 네임스페이스란 독특한 태그 이름이 부여되는 경계라고 할 수 있다. 예를 들어 <place>라는 태그는 고객의 위치나 지리적 위치를 의미하는 것이다.

이러한 부분에 대한 해결책은 접두사(Prefix)의 사용이다. 접두사가 특정 XML 소스 문서에 속한 태그를 독특하게 구별할 수 있는지 그 방법을 기술하고 제안한다. 각각의 접두사는 소스 문서의 태그 셋의 위치를 알려주는 메타데이터를 기술함으로써 지원된다.

   

▲ 예제1- XML 네임스페이스작업 초안 문서에서 발췌한 것으로 네임스페이스가 태그 이름의 xmlns 속성을 사용하는 하나의 문서를 통해서 도중에 어떻게 변경되는지를 보여준다
▲ 예제2- 설명 다음에 나열하는 XML 네임스페이스인 bk, isbn 또한 각각의 태그를 동반함으로써 혼합될 수 있다


쉬운 데이터 공유로 애플리케이션 통합

당시 XML의 가장 큰 장점은 데이터 공유를 쉽게 하며 애플리케이션을 통합하는데 있었다. XML은 인터넷상에서 콘텐츠와 객체를 통신하는 사실상의 표준으로 확립될 수 있는 잠재력을 가지고 있었고, 데이터를 기술할 수 있기 때문에 애플리케이션 간에 이동시키기 위한 데이터 수집은 큰 일이 아니었다. 또한 개발자들은 서로 다른 플랫폼에 있는 포맷 간에 데이터를 이동시킬 필요가 없었고, 그 대신 데이터는 XML로 출력돼 XML을 인식하는 애플리케이션으로 입력됐다.

이로써 애플리케이션의 유연성이 향상됐으며 데이터는 애플리케이션의 종류에 상관없이 어디서나 이용될 수 있었다. 각각의 애플리케이션은 더 이상 상대방 애플리케이션의 포맷을 이해하지 않아도 되기 때문이었다. 당시 기준 이전에는 전용 PC파일 포맷으로 된 여러 가지 데이터 포맷을 편집하는 작업은 너무 어려웠다. XML은 그러한 포맷 간에 다리 역할을 했기에 1999년 당시 프로젝트 수행에 도움이 됐다.

XML의 또 다른 이점은 웹 애플리케이션이 데이터를 단순히 포매팅 해 제시하기 보다는 국지적으로 데이터를 조작하는 역할을 할 수 있다는 것이었다. 서로 다른 XML문서를 만듦으로써 데이터는 클라이언트 애플리케이션에 의해 여과돼 서로 다른 방식으로 정제될 수 있었다. 이러한 국지 계산 방식은 서버를 반복 호출하는데 따른 대역폭 소모를 줄여준다.

XML로 마크업 된 원래 데이터는 처리를 위해 클라이언트에 한 번만 전송되기 때문이었다. XML이 이러한 장점을 가지고 있다고 해서 그것이 ‘만병통치약’이라는 의미는 아니었고, 이러한 혜택은 업계와 데이터 활용에 대한 상호 협조적이고 효율적이며 표준적인 데이터 어휘에 달려 있었다.

당시 특정 업계 차원에서 다양한 노력이 행해졌고, 일례로 호주와 뉴질랜드 토양정보위원회는 두 나라의 지리 및 공지 데이터를 XML기반의 시스템에서 사용할 수 있는 유형으로 기술하는 작업을 함께 벌이기도 했다. 또한, ‘에듀콤’의 인스트럭셔널 매니지먼트 시스템즈 프로젝트는 인터넷을 통해 학습 자료를 교환하기 위한 포맷을 개발하기 위해 다양한 교육단체가 참여했다. 또 유타 일렉트로닉스 로우 프로젝트는 인터넷을 통해 법률문서를 주고받기 위한 표준을 개발하기 위해 노력했다.

이런 XML의 잠재적인 장점을 내세워 업계 차원의 다양한 시도들이 행해졌고 XML이 주류로 부상되며 다른 업계에서도 이를 답습할 것으로 예상했다.


과도기적인 HTML5 보안문제 야기

과거 XML이 범용 객체모델로 부상했다면 2019년 현재는 HTML5가 급부상하기 시작했다. 또한 W3C에 의해 웹 표준으로 지정됐다. 그 이유는 별도의 설치 없이 높은 그래픽 효과를 구현할 수 있기 때문이다. 반면 과거에는 기능을 위해 액티브X(Active-X)의 설치가 필요했지만 최신 규격이 된 HTML5는 액티브X의 설치 없이 어도비 플래시, 실버라이트, 자바FX와 같은 그래픽 기능을 효율적으로 낼 수 있다.

HTML5의 장점 중 하나인 크로스 브라우징은 방법론적 가이드라고 말할 수 있다. 크로스 브라우징이란 여러 기종 혹은 플랫폼에 따라서 다르게 구현되는 브라우징 기술들을 어느 한 쪽에 치우치지 않고, 공통 요소와 표준 웹 기술을 기본으로 하여 모든 브라우저에서 통용될 수 있도록 웹 페이지를 제작하는 기법이다. 가령 구글의 크롬을 사용하는 사용자의 화면과 매킨토시의 사파리를 사용하는 사용자의 화면을 예로 들 수 있다. 다른 운영체제에서 각각의 다른 웹 화면이 나오는 것은 당연하다. 하지만 크로스 브라우징을 이용해 다른 운영체제에서도 동일한 웹 화면을 출력하게 된다.

이와 같이 고도화된 HTML5는 문재인 정부에 들어서 더욱 중요하게 인식되고 있다. 현재 정부는 2020년까지 모든 공공기관의 웹 사이트에서 액티브X를 제거한다고 발표했다. 이를 위해 정부는 대표적인 30대 공공 웹 사이트에서 액티브X를 제거할 계획이다. 정부는 이번 액티브X 제거를 위해 HTML5 방식을 채택하는 부분을 강조하고 있다.

HTML5는 정부가 주창하는 논 액티브X의 취지와 가장 적합한 웹 표준이다. 별도의 설치 없이 HTML5 자체적으로 기능을 사용할 수 있기 때문이다. 하지만 이러한 HTML5를 적용해도 문제가 완전히 사라진 것은 아니다.

많은 문제가 있지만 정보기술 패러다임의 시각에서 보안의 위협을 들 수 있다. 첫 번째로 HTML5의 신규 태그 및 속성들은 보안의 관점에서 보면 공격자들이 악용할 수 있는 공격 범위를 더 넓게 만들었다. 가령 Onfocus, Autofocus 등의 속성들은 기존 CSS(Cross-site Scripting) 필터에 포함되지 않으면서 자바스크립트를 실행하는데 사용될 수도 있다.

두 번째는 CORS(Cross Origin Resource Sharing)이다. XHR(XMLHttpRequest)을 다른 도메인으로 발생시킬 때 사용자에게 허가 요청을 받지 않는다는 것이다. 이러한 문제는 사용자의 세션을 오용한 접근제어와 관련된 보안 문제를 야기할 수 있다. 공격자가 사용자의 세션을 오용할 수 있게 된다는 것은 접근제어를 우회하여 허가되지 않은 리소스에 접근할 수 있다는 의미이다.

   
▲ HTML5의 장점(출처:컴퓨터월드)

이런 문제 해결을 위해 지난 2014년 정부 측은 임시방편으로 대체 수단을 실행파일(.exe)로 선정했다. 이 방법은 공공 및 금융기관, 결제를 필요로 하는 쇼핑몰 업체 등에 액티브X를 제거하고 실행파일 방식의 보안 및 결제 프로그램을 별도로 운영체제에 귀속, 설치하는 것이다. 그러나 사용자들의 반응은 좋지 않았다. 불편함의 이유가 웹에서 많은 프로그램을 설치한다는 것이었는데, 실행파일을 설치해야 한다는 점 때문에 별반 이점을 느끼지 못한 것이다.

대부분의 사용자들은 논 액티브X 대체를 쉽게 체감하지 못했으며, 부정적인 인식을 가진 국내 사용자들에게 실행파일 형태의 프로그램은 이름만 상이한 제2의 액티브X에 지나지 않았다. 일부에서는 액티브X에 비해 보안상 더 위험한 것이 아니냐고 우려의 목소리를 내기도 했다.

이에 대해 업계 전문가는 "두 가지 방식의 차이는 별도의 설치 과정을 거쳐야 한다는 것은 같지만, 실제로는 제공하는 기능과 권한에서 차이가 있다"고 말했다. 액티브X는 인터넷 익스플로러에 종속돼 브라우저가 실행중일 때만 작동한다. 따라서 크로스 브라우징이 근본적으로 불가능한 기술이라고 볼 수 있다.

반면 실행파일 방식은 브라우저가 아닌 운영체제에 귀속돼 브라우저의 실행 여부와 관계없이 운영체제 상에서 실행되며 자율적 작동이 가능하다. 이는 액티브X와 달리 크로스 브라우징이 가능하다고 볼 수 있다. 이러한 측면에서 액티브X의 대체로 실행파일로 선정된 것이다.

액티브X 청산은 지난 정부부터 현 정부에 이르기까지 중요한 목표 중 하나로 다뤄지고 있다. IE의 높은 보급률로 액티브X에 의존적인 인터넷 환경을 구축해온 우리나라는 해외에 비해 웹 표준 준수가 잘 이뤄지지 않는 실정이다.

현재는 논 액티브X로 가는 과도기적인 시점이다. 하지만 과도기가 있어야 안정된 시기가 올 수 있듯 반드시 거쳐야 할 시기라면 사용자들의 불만을 최소화 시켜야 HTML5로 무사히 안착할 수 있을 것이다.

여백
컴퓨터월드 추천기업 솔루션
인기기사 순위
IT Daily 추천기업 솔루션
(우)08503 서울특별시 금천구 가산디지털1로 181 (가산 W CENTER) 1713~1715호
TEL: 02-2039-6160  FAX: 02-2039-6163   사업자등록번호:106-86-40304
개인정보/청소년보호책임자:김선오  등록번호:서울 아 00418  등록일자:2007.08  발행인:김용석  편집인:김선오