OOXML: 뭐가 그리 대단한가? (한글)

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 토론 영어원문  제안 및 의견 피드백

난이도 : 초급

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 표준은 이 기능을 구현하지 말라고 구현자들에게 경고까지 한다.

[안내문: 이 기능을 완벽하게 구현하려면 워드 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 파일'로 바꾸는 문제 말이다. 그러나 불행하게도 이 문제는 '사용성 있고, 구현 가능하며, 교환이 되는 오피스 문서 형식을 정의하는 문제'와는 전혀 다르다.

소셜 북마크 mar.gar.in Digg del.icio.us Slashdot

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

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

참고자료

• OOXML is defective by design: (Stéphane Rodriguez, 2008년 2월): OOXML로는 스프레드시트 형식을 구현하기 어렵다? 그건 빙산의 일각에 불과하다. 이 페이지는 다른 많은 문제를 상세히 논한다.
  
  
• 표준과 스펙: XML: 미완성 표준이라도 없는 것보다는 낫다! (Peter Seebach, developerWorks, 2006년 9월): 표준으로서 XML을 살펴보고 장단점을 소개한다.
  
  
• Office Open XML: OOXML을 소개하는 위키백과 설명이다.
  
  
• More Irregularities in the OOXML ISO Process Surface (Groklaw, 2007년 8월): OOXML이 ISO 표준이 될 뻔 했던 표준화 절차를 우려하는 목소리가 담겨 있다.
  
  
• Open Document Format (ODF): OOXML과 경쟁하는, XML 기반 표준인 ODF를 전반적으로 소개하는 위키백과 설명이다.
  
  
• IBM killed Open XML (Nick Farrell, the Inquirer, 2008년 1월): IBM이 OOXML을 죽인다고 비난하는 마이크로소프트 사를 냉정하게 다루는 기사다.
  
  
• Cruel truth surfaces in the OOXML war (ZDNet, 2008년 1월): OOXML 표준을 둘러싼 논란과 정치적인 색채를 짚어보는 기사다.
  
  
• IBM XML 인증: XML과 관련 기술 분야에서 IBM 인증 개발자가 되는 방법을 알려준다.
  
  
• XML 기술 자료: 기사와 팁, 튜토리얼, 표준, IBM 레드북 등 다양한 기술 자료를 제공한다.
  
  
• developerWorks 기술 행사와 웹캐스트: 최신 기술 동향을 파악할 수 있다.
  
  
• 기술 온라인 서점:다양한 기술 서적을 제공한다.
  
  
• XML 입문 (한글) 페이지: XML 존에서 새롭게 올라온 자료를 살펴보라.

• IBM 평가판 소프트웨어: IBM 평가판 소프트웨어를 developerWorks에서 바로 내려받아 프로젝트에 활용할 수 있다.
  
  

• 포럼에 참여하기.
  
  
• XML 포럼: XML과 관련하여 다양한 토론을 나눌 수 있다.
  
  
• developerWorks 블로그: 블로그를 읽고 developerWorks 공동체에 참가해 보라.
  
  

필자소개

		Peter Seebach는 오랫동안 표준화에 관심을 가졌으며, ISO C 위원회에 자원하여 10여년을 활동해 왔다. 그는 이미 여러 해 전부터 문서 교환 표준으로 XML을 사용하고 있다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

위로