'[03] News'에 해당되는 글 2건

Peter Seebach, 자유기고가, Freelance

2008 년 3 월 18 일

OOXML 명세를 놓고 상당한 비평과 찬사가 동시에 쏟아졌습니다. 덕택에 많은 사람이 무슨 영문인지 의아해 하고 있습니다. 이 기사는 (정치적인 입장이 아니라) 기술적인 측면에서 OOXML을 표준으로 취급해서 안 되는 이유를 밝힙니다.

나는 (지난 10여년 동안 ISO C 표준 위원회에 자원하여 활동한 경험까지 포함하여) 오랫동안 표준화에 관심을 쏟아 왔다. 표준화에 관심 있는 사람이라면 거의 누구나 마이크로소프트(Microsoft®) 사가 제안한 XML 문서 형식인 OOXML(Office Open XML)을 놓고 나름대로 의견이 있으리라. 보통은 내 이야기로 기사를 시작하지 않지만, 최근 IBM 사가 OOXML을 무산시키려 했다는 혐의를 받고 있는 터라, 한 가지 사실을 분명히 밝히고 시작하겠다. 나는 IBM® 직원이 아니며 이 기사는 어디까지나 내 개인 의견이다. 나는 이 문제에 대해 IBM 입장과 무관하게 내 생각을 피력할 뿐이다.

OOXML 표준은 많은 이유에서 상당한 주목을 끌고 있다. 표준화 절차가 정치적 사안이 되어버린 책임을 누구 탓으로 돌리든, 현재 표준화 절차에 정치적 입김이 강하게 몰아치고 있다는 사실은 부인하기 어렵다(참고자료를 읽어본다). 그러나 표준화 절차는 모든 정치적 분쟁을 넘어서 (표준으로서 XML이 올바른 선택인지 여부부터 표준화를 하는 목적에 이르기까지) 중요한 기술적 사안을 고려해야 한다. OOXML을 둘러싼 관심과 흥분은 내가 단상에 올라가 좋은 표준이 무엇인지 주장할 멋진 기회가 되었다.

표준을 정립하는 목적은 무엇인가?

표 준은 상호운용성(interoperation)을 제공할 목적으로 존재한다. 내 문서 편집기와 여러분의 문서 편집기가 같은 파일을 열 수 있다면, 우리는 문서를 쉽게 공유할 수 있다. 그렇지 않다면 문제가 생긴다. 즉, 표준이 없다면 공유할 문서 형식이 다른 탓에 모두가 엄청난 시간과 노력을 낭비하게 된다. 문서 편집기 개발업체는 타사 문서 형식을 자기네 편집기로 읽어들여 저장된 형태를 비슷하게 보기를 기대하는 사용자를 위해 역공학에 대단한 시간과 노력을 소모하게 된다.

표 준이 거의 모두에게 이롭다는 사실은 자명하다. 단, 문서 형식 표준은 해당 업계를 주도하는 기업들에게 별로 달갑지 못한 듯 보인다. 사실, 이들 입장에서는 표준이 없는 편이 더 낫다. 자기네 표준이 사실상 업계 표준으로 받아들여질 가능성 때문이다. 그렇게만 되면 기업은 두 가지 측면에서 경쟁적 우위를 확보한다. 다른 업체들이 사실상 업계 표준을 지원하느라 시간과 돈을 투자해야 하고, 그렇다 해도 타업체가 사실상 업계 표준을 완벽하게 지원하기란 불가능하기 때문이다.

정 의만으로 따져보면 우수한 교환 표준은 모든 개발업체가 제공하는 기능을 전부 명세하지 못한다는 사실에 주목한다. 반면, 모든 개발업체는 표준이 정의하는 모든 기능을 지원해야 한다. 즉, 표준에 들어가는 기능은 모든 개발업체가 구현해야 한다는 뜻이다. 확장 기능이나 추가 기능은 표준 형식 문서에 인코딩하지 못하도록 아예 금하는 편이 낫다. 사용자 입장에서는 명세가 지나치게 복잡해 편집기마다 다른 결과를 얻느니 차라리 어디서나 같은 결과를 내놓는 표준 문서가 확실히 더 낫기 때문이다.

오 피스 문서 형식을 표준화해야 한다는 목소리가 점차 커지고 있다. 일반 기업에서 정부 조직에 이르기까지 많은 단체가 개방형 문서 저장 표준을 지원하는 소프트웨어를 규정상 요구하기 시작했다. 누구도 한 개발업체에 묶이고 싶어하지 않으며, 여기서 표준은 자유를 제공한다. 이러한 사실을 염두에 두고, 이제 마이크로소프트 사가 제안한 OOXML 표준을 기술적인 측면에서 살펴보자.

OOXML 표준

ECMA(유 럽정보통신표준단체)에서 승인한 OOXML 표준은 대략 6000쪽에 달하는 PDF 문서 집합이다. 상당한 분량에다 아주 상세하다. 표준이 이렇게 두꺼운 이유는 간단하다. OOXML은 마이크로소프트 오피스 응용 프로그램이 파일에 저장할 가능성이 눈꼽만치라도 존재하는 자료 전부를 빠짐없이 기술한 문서이기 때문이다.

기술적인 측면에서 OOXML을 둘러싸고 온갖 불평이 들끓는다. 그런데 모든 불평이 근본적으로는 한 가지로 귀결된다. OOXML이 합리적이고 일반적인 교환 형식을 정립하기보다 마이크로소프트 오피스 기능을 몽땅 명세했다는 점이다. 심지어 버그 호환성까지. 따라서 다른 개발업체에게는 너무도 불합리한 (사실상 불가능한) 부담이 생긴다. 반면, 마이크로소프트 사는 이미 표준에 딱 맞는 제품을 판매 중이다. 그러니 우려의 목소리가 터져 나오지 않을 수 없다.

마이크로소프트 사가 몇 걸음 앞섰다고 불평하는 게 아니다. 마이크로소프트 사가 구현했더라도 작고, 설계가 올바르고, 모두가 따르기 쉬운 표준이었다면 별다른 논란 없이 받아들여졌을 터이다. OOXML에서 표준을 망가뜨리는 기능은 크게 세 범주로 나눠진다. 첫째는 비합리적으로 구현하기 어려운 기능, 둘째는 명세가 불충분한 기능, 셋째는 마이크로소프트 오피스에만 필요한 기능이다. 여러 범주에 속하는 기능도 있지만, 각 범주는 서로 다른 이유로 표준이 되기에 부적합하다.

불합리한 요구사항

전 통적으로 표준은 합리적인 선에서 정의와 범위가 분명한 문제를 구현자에게 내놓는다. 구현자는 12가지나 되는 문단 정렬 방식을 구현해야 할지도 모르지만, 모두 명세가 분명하고 범위가 합리적인 한 문제는 없다. 그러나 OOXML은 다분히 해석이 자의적인 요구사항을 포함한다. 예를 들면, 페이지 머리글에 "글꼴 이름과 글꼴 유형 둘 다 지역화된 값을 사용해도 좋다"라고 명세한다. 아주 간단한 문장으로 보이지만 (Steéphane Rodrigue가 지적하듯이) 논란의 소지는 엄청나다(참고자료를 읽어본다).

사 용할 수 있는 로케일은? 이 명세를 구현하는 업체가 사용할 만한 로케일을 몽땅 고려해야 할까? 글꼴 이름이나 글꼴 유형을 지역화하는 온갖 방법은? 만약 의욕에 찬 업체가 생전 듣도 보도 못한 언어로 글꼴 이름과 글꼴 유형을 표기하기로 작정했다면?

추 측컨데, 과거 언젠가 마이크로소프트 오피스는 사용자가 선택하는 혹은 사용자에게 표시하는 지역화된 값을 저장하기로 결정한 모양이다. 불행하게도, 상당한 양의 명세를 추가하지 않고는 (적어도 가능한 로케일 목록 전체와 사용 중인 로케일을 판단하는 방법을 명세하지 않고는) 구현이 거의 불가능하다. 이 기능은 과거에서 내려온 유물일 뿐이지, 모든 구현에서 공유할 표준 형식으로는 적합하지 못하다.

불충분한 명세

일 부 마이크로소프트 오피스 문서는 VML이라는 벡터 언어로 그려진 그림을 사용한다. 그래서 OOXML도 VML 그림을 저장하는 방법을 명세한다. 즉, 구현하려면 VML 그림을 읽어야 한다는 뜻이나 불행하게도 구체적인 명세가 없다. VML 형상은 특정 항목 내에 문자열로 존재한다.

그렇다면 정확히 허용되는 값은 무엇인가? 답은 명쾌하다. "이 속성에 사용할 수 있는 값은 XML 스키마 문자열 자료 유형이다." 한 마디로 문자열이라는 말이다. VML 라이브러리만이 의미를 판독할 수 있는 임의의 문자열을 사용하면 된다. 그러니까 VML 라이브러리가 없다면 구현도 못한다는 뜻이다.

마 찬가지로 이 기능 역시 과거에서 내려온 유물이다. 교환 표준에서는 그림 형식을 (가능하면 하나로 제한하고) 완전히 명세해야 하며, 다른 그림 라이브러리를 사용하는 구현자는 모든 그림을 표준 형식으로 변환해야 한다. 반면, OOXML은 단순히 옛날 설계를 재활용하면서 (게다가 의도적으로 명세를 공개하지 않으면서) 모두가 이를 채택하리라 여긴다.

고유한 기능

많 은 표준 전문가가 가장 분노하는 부분이 바로 이 마지막 범주다. 단순히 구현하기 어려워서가 아니라(불가능하지 않으니 감지덕지할 노릇이다), 애초에 표준으로 부적합하기 때문이다. 이 범주에 속하는 기능은 완전히 그리고 철저하게 마이크로소프트 오피스에 종속적이다.

가장 유명한 예제는 "useWord97LineBreakRules"라는 선택적 설정이다. OOXML은 동아시아 문서에서 워드 '97에서 사용하던 행 분리 규칙을 사용하라고 명세한다. 앞서 소개한 예제와 마찬가지로 구체적인 명세가 없으므로 구현도 불가능하다. 사실 OOXML 표준은 이 기능을 구현하지 말라고 구현자들에게 경고까지 한다.


Listing 1. OOXML에서 제시하는 useWord97LineBreakRules 안내문
[안 내문: 이 기능을 완벽하게 구현하려면 워드 97이 동작하는 방식을 모방해야 한다. 가능한 방법은 매우 많으며, 이 Office Open XML 표준에서 충실하게 설명하기는 불가능하다. 이 기능을 구현하려면, 워드 97이 내놓는 결과를 살펴서 복제해야 한다. 그러나 출력과 관련한 문제기 때문에 기존 워드 97 문서와 호환성을 제공하는 목적 외에는 더 이상 사용하지 않으므로 의도적으로 이 기능을 구현하지 않도록 한다. 안내문 끝]

멋진 안내문이 아닌가! 명세도 없고 폐기되었으므로 당연히 구현할 필요가 없다. 그런데 잠깐만! 구현할 필요가 없다면 명세에는 왜 들어가 있을까? 기존 문서와 호환성은 자료 교환을 목적으로 하는 표준에 기능을 추가할 이유가 못 된다. 사용자들은 다른 프로그램에서도 자신의 문서가 열리기를 바라지, 행 분리 기호가 정확히 같은 위치에 놓여야 한다는 사실 따위는 염두에 없다.

이 기능이 명세에 들어 있는 이유는 OOXML이 문서 교환 형식이 아니기 때문이다. OOXML은 마이크로소프트 사의 역사적인 이진 형식을 주의 깊게, 하나도 빠뜨림 없이, 꼼꼼하게 XML 형식으로 복사한 결과물일 뿐이다.

그럼 XML이 적합하지 않다는 말일까?

OOXML 을 불평하는 소리에 일부 IT 전문가들은 XML이 표준으로 적합하지 못하다고 생각한다. 나로서는 아무래도 성급한 판단이라 여겨진다. 아니, 아예 그릇된 생각이라 믿는다. OOXML 문제는 XML 탓이 아니다. 여러 응용 프로그램이 공유하고 교환하기 쉽도록 일반적인 문서의 구조와 내용을 명세하는 대신, 기존 프로그램의 온갖 괴상한 동작 방식과 자질구레한 역호환성을 충실하게 재구성하려는 의도 탓이다.

XML은 문서 교환 표준으로 손색이 없다. OOXML의 가장 큰 경쟁자 역시 ODF(Open Document Format)라는 XML 표준이다. ODF도 절대로 간단하거나 작은 표준은 아니다. 버전 1.1은 738쪽에 달하는데, 표준을 개발 중인 그룹은 아직 완성본이 아니라고 여긴다. 예를 들어, 버전 1.1은 스프레드시트에서 사용하는 공식(formula) 언어를 정의하지 않는다(현재 버전 1.2에 넣으려고 작업 중이다). 그럼에도 불구하고 ODF 명세를 살펴보면, 구닥다리 응용 프로그램의 동작 방식을 묘사하기보다 문서 내용을 기술하려 한다는 사실이 드러난다.

XML은 문서 내용을 기술하고 싶은 방식을 묘사하는 도구로서 가치가 있다. ODF 표준은 아직 미완성이지만 좋은 표준이 될 가능성이 존재한다.

결론

XML 은 새 문서 형식을 정의하는 강력하고 풍부한 도구지만, 프로젝트 범위를 잘못 정하는 실수까지 무마해 주는 만병통치약은 아니다. '참고할 문서가 없는 대형 독점 렌더링 라이브러리를 사용한다'는 플래그를 문서 형식에 넣는다면, 플래그를 문서 없는 이진 문자열 내 비트 하나로 명세하든 세 쪽짜리 <>으로 명세하든 상관이 없다. 이 명세는 어디까지나 독점이며, 단순히 XML로 감싸는 방법만으로는 렌더링이 불가능하다.

다양한 파일 형식을 일관되고 표준적으로 구문을 분석해낼 가능성이 충분한 XML이 OOXML의 결점 때문에 덩달아 비난을 받고 있는 현실은 참으로 안타깝다. 6000쪽에 달하는 OOXML 명세는 단순히 오늘날 문서 편집기가 제공하는 기능뿐만 아니라 옛날 문서 편집기가 제공하던 기능까지 기술한다. 그것도 일부 옛 기능은 슬쩍 맛만 보인다. 그나마 OOXML의 구현 가능성을 언급이라도 할 수 있는 이유는 순전히 기반 XML 표준이 탄탄하기 때문이다.

진짜 문제를 해결하려는 노력으로서 OOXML은 가상하다. '완전히 베일에 감싸여 10여년에 걸쳐 비대해질 대로 비대해진 기능을 제공하는 이진 파일'을 '완전히 똑같은 기능을 제공하면서 부분적으로 판독이 가능한 XML 파일'로 바꾸는 문제 말이다. 그러나 불행하게도 이 문제는 '사용성 있고, 구현 가능하며, 교환이 되는 오피스 문서 형식을 정의하는 문제'와는 전혀 다르다.

업계가 OOXML을 문서 표준으로 진지하게 받아들이기 바란다면, 마이크로소프트 사에게는 한 가지 길 밖에 없다. 마이크로소프트 오피스 모든 버전에 들어가는 모든 기능, 모든 문서가 사용할 만한 모든 플래그와 변종 기능 따위를 명세하지 말고, 좀더 작고, 군더더기 없고, 핵심 기능을 제공하는 교환 형식에 초점을 맞춰야 한다. 물론, 명세는 구현이 가능해야 하며 설명이 충분해야 할 터이다. 스프레드시트 자료와 공식을 단순히 복사하려는 사람들에게 엑셀(Excel®) 계산 순서 연쇄와 같이 불필요한 부담을 지워서는 안 된다. VML 라이브러리나 DrawingML 라이브러리 따위를 넣어서도, 아니 언급조차 해서도 안 된다. 대신 완전히 새롭고, 개방적이고, 구체적인 명세를 내놓아야 한다.

예전에 XML 표준과 명세에 관한 기사를 쓸 때 나는 "<bytes>ff ff 00 03 [. . .]</bytes>"와 같은 XML 형식을 대수롭지 않게 언급했던 적이 있다. 당시는 농담이라 생각했는데, 아무래도 아닌 듯 싶다.



참고자료

교육
신고

'[03] News' 카테고리의 다른 글

OOXML: 뭐가 그리 대단한가? (From IBM developerWorks)  (0) 2008.06.27
OOXML  (0) 2008.06.26
블로그 이미지

Moonistar moonistar

Tag OOXML

OOXML

[03] News 2008.06.26 14:33

OOXML 표준화 이슈가 남긴 것

ZDNet, Microsoft, OpenXML9월 18th, 2007
지난 9월 2일, 전 세계 IT업계의 이목은 국제 표준화 단체인 ISO에 모아졌다. 마이크로소프트사가 ECMA를 통해 제출한 오피스 문서 포맷 표준인 Office Open XML(이하, OOXML)을 ISO 표준으로 제정할 것인지를 묻는 국가별 찬반 투표 마감날이었다.
이 투표가 관심을 끈 이유는 IBM과 SUN을 비롯한 오픈 진영과 마이크로소프트가 다시 한번 공개 표준의 장에서 격돌한 때문이다. IBM은 또 다른 표준단체인 OASIS를 통해 Open Document Format(이하, ODF)이라는 오피스 문서 표준을 ISO에 제출하여 전 국가 만장일치로 통과시켰다. 이른바 반 MS 진영은 마이크로소프트가 상용 소프트웨어 시장을 독점하는 것을 막기 위해 오랜 기간 동안 오픈 소스 진영을 후원해왔고 공개 플랫폼과 공개 표준들을 지지해왔다. 최근 10여 년간 이러한 후원과 수 많은 개발자 및 사용자들의 적극적인 참여로 인해 공개 소프트웨어는 놀라울 만한 성장을 거듭해왔다. 이로서 소프트웨어 업계에서는 파이어폭스, 오픈오피스, 아파치 웹 서버 등 상용 소프트웨어를 대체할 수 있는 수 많은 공개 소프트웨어 걸작품들을 배출 했다. MS사는 이러한 변화로 인해 자사의 생태계가 위협 받고 있음을 깨닫고 수 년 전부터 개방된 자세로 오픈 소스 기업 및 커뮤니티와 소통하는 일을 시작했다. MS가 자사의 주요 캐시카우라고 할 수 있는 오피스 제품의 사양을 XML이라는 공개 표준으로 제출한 것은 이러한 노력의 결과물이라 할 수 있다.


ISO에서 격돌한 오픈 소스 vs 상용 소프트웨어 진영
지난 2월 MS가 자사의 OOXML 표준안을 ISO의 빠른 심사 과정(Fast Track)을 거쳐 표준화 시키려고 하자 즉각 오픈 진영의 거부 운동이 시작 되었다. 이들은 OOXML 표준안이 전 세계 각 국 정부의 표준 채택에 영향을 미치는 ISO 국제 표준이 되기에는 부족한 점이 많다고 지적한다. MS사의 이러한 즉각 행동은 각 국 정부와 미국 일부 주정부가 ODF를 표준 문서 포맷으로 지정하고자 한 것과도 무관하지 않다.
IBM, 구글, 리눅스 재단 같은 오픈 진영에서는 이미 대체 및 보완 가능한 기 ISO 표준인 ODF가 존재할 뿐만 아니라 표준안 내에는 MS 오피스에서만 완벽히 구현한 각종 사양들이 대거 들어 있는 등 수백 가지의 기술적 문제가 있다고 밝혔다. 특히, 이들 중 대부분은 MS사의 특허권과 맞물러 있어, MS가 단순히 소송하지 않겠다는 선언적 약속을 믿기 어렵다는 이유로 반대 의사를 분명히 했다.
특히, MS사가 OOXML 스펙을 기존 업체들이 이미 많이 구현하고 있다고 예를 들은 회사들대부분은 MS와 특허권 계약을 한 회사들이다. 이 때문에 OOXML이 ISO 표준이 되는 경우, 소프트웨어 업체들이 자유로운 구현을 할 수 없을 것이라는 입장을 나타내었다. 몇몇 웹 사이트에서는 각 국 대표단이 반대표를 던질 것을 호소하는 서명 운동을 벌이기도 하였다.
이에 대한 MS사의 반격 또한 만만치 않았다. ‘오픈XML 커뮤니티’를 통해 정부 기관에서 기 작성되었거나 지금 가장 많이 사용하는 문서 형식을 변환하여 장기 문서 보존 형식으로 사용 가능하다는 점을 홍보하고 역시 각 국에서 찬성표를 던져 줄 것을 요청하는 서명 운동을 벌였다.

스캔들 및 정치적 로비까지 불사
MS사의 대외 로비는 투표가 가까우면서 보다 강하게 나타났다. ISO에 참여한 국가들은 자국의 관련 표준 기관이나 대표 위원회 내에 학계와 업계를 회원으로 참여시켜 토론 후 내부 투표를 거쳐 마지막으로 찬반 여부를 제출하게 된다. 그런데, 스웨덴 등 일부 국가에서 MS사가 입회비나 마케팅비를 지원하는 조건으로 제휴사를 개별 국가나 의사 결정 기관에 회원으로 대거 영업 시켜 자국 내 의견을 찬성쪽으로 돌렸다는 의혹이 제기 되기도 했다.
또한, 투표 한두 달 전부터 결과에 결정적인 영향을 미칠 수 있는 정식(P)멤버로 승격 요청을 한 국가들이 많았고, 이들 중 대부분은 찬성표를 행사했다는 점이 영향을 미쳤다는 분석도 나왔다. 올해 초 기존 30개국에 불과했던 P멤버가 JTC-1과 SC34에 각각 11개국 15개국이 늘어났으며 이들 중 각각 9개국, 12개국이 찬성표를 던졌다. 기존 P멤버 30개국의 찬성표는 8개국, 반대는 14개국이지만 신규 회원국들의 반대표는 단 1표에 불과했다.
한발 더 나아가 EFFI(핀란드전자선구자재단)가 국제 투명성 단체가 발표하는 국가별 부패 지수(CPI)와 이번 투표 국가의 상관 관계를 조사한 결과, 부패 국가들의 찬성 투표 수가 압도적으로 높았다. 여기에는 동구권, 중남미 및 아프리카 일부 나라들이 포함되어 있다. 찬성 국가 대부분인 20개국은 부패 지수가 2~3 정도로 낮았으며 6점 이상을 받은 28개국 중에는 한 표의 찬성도 없이 기권 및 반대만 있었다. 이들 국가 중 일부는 빌게이츠 재단이 직접 구호활동을 펴는 곳도 있다.


합리적 과정과 충분한 검토를 거쳐야
세계 IT업계의 이목이 집중된 가운데 나온 투표 결과는 결국 OOXML 표준안 부결이었다. 32개국 P멤버 중 17개국만 찬성을 던져 2/3 채우지 못했고, 69개국의 전체 국가 중 18개국이 반대하여 1/3을 넘어섰다. 특히, 반대표의 경우 1표 차이로 가까스로 부결 되었다. 반대 국가 대부분이 OOXML에 대해 우려를 표시한 코멘트를 제출했으며, MS사가 ECMA를 통해 이를 보완해 수정안을 다시 제출하면 내년 2월에 재투표를 실시한다.
MS사는 전체 유효 투표의 74%인 51개국이 찬성의사를 나타냈다며 한껏 고무된 모습이다. 이전 ISO에서 32개국이 지지한 ODF와 15개국이 지지한 PDF에 비해 참여 국가수와 찬성표가 늘어난 데 특별한 의미를 부여하며 전 세계적으로 OOXML을 지지하고 있다고 밝혔다.
사실 OOXML 표준안 투표 과정에서 나타난 현상을 보면 전 세계적인 표준으로서 기술적인 검토와 충분한 토론은 실종되고 각 진영간의 정치적 이슈가 첨예하게 대립되었다고 볼 수 있다. 이는 OOXML 표준안이 6,000여장이라는 사상 초유의 방대한 표준안으로 각 국에서 검토할 만한 충분한 시간이 주어지지 않았기 때문에 양쪽 진영의 수박 겉핱기씩 공방을 확인하는 수준 밖에 없었다. 실제로 OASIS 표준안이 나온 후, 다양한 소프트웨어에서 온전한 구현 결과를 낸 ODF와 달리 OOXML은 전체 스펙을 모두 구현한 제품이 단지 MS 오피스뿐이기 때문에 이러한 결과가 나올 수 밖에 없었다.
ISO나 다른 국제 표준 단체에서 활동 하다 보면 여러 가지 정치적 이슈와 이상과 현실적(상업적) 이슈들이 충돌하게 된다. 산업 표준을 수용해 주기 위해 단일 분야의 복수 표준이 나올 수도 있고, 선도 기술을 가진 나라들의 정치적인 입김도 크게 좌우될 수도 있는 곳이다. 국제 표준이라는 것은 권고 사항 내지 판단의 근거이지 절대적인 것은 아니기 때문이다.
하지만 표준이 되는 과정에서 편법과 정치만 난무하고 제대로 된 검토가 허술하다면, 그나마 가지고 있는 권위를 잃을 수도 있다. 이번 OOXML 표준안 처리 과정이 이러한 점을 단적으로 보여 주었다고 할 수 있다. 표준안에 대한 충분한 검토와 논의 합리적인 절차를 거치는 모습을 보여야만 진정한 표준으로서 의미가 있을 것이다. 이런 점에서 OOXML안이 부결된 것은 오히려 그 자체로 약이 될 수도 있다. OOXML 표준안은 아직도 현재진행형이다. ISO가 어떻게 이 뜨거운 감자를 해결해 가는지 전 세계가 지켜 보고 있다는 점을 명심해야 할 것이다.
신고

'[03] News' 카테고리의 다른 글

OOXML: 뭐가 그리 대단한가? (From IBM developerWorks)  (0) 2008.06.27
OOXML  (0) 2008.06.26
블로그 이미지

Moonistar moonistar

Tag OOXML