Open XML을 이미 한 번 투표에서 부결된 적이 있습니다. 이번 달 하순에 2차 국가별 투표가 열리는데, 이번에도 부결되면 최종적으로 표준 통과에 실패하게 됩니다.
MS는 또한 바이너리 오피스 문서를 Open XML로 변환하는 프로젝트를 소스포지에 개설했습니다. 라이선스는 BSD입니다.
지금까지 오픈오피스(OpenOffice.org) 등은 이러한 바이너리 오피스 포맷을 읽기 위해 자체적으로 분석한 결과물을 사용했습니다. 엄청난 노가다지요. 100% 호환되는 것도 아니고요. 그래서 이번 공개로 오픈오피스 등의 MS 오피스 포맷 호환성을 높일 수 있지 않을까 하는 기대가 있습니다.
단, 몇 가지 집고 넘어갈 게 있는데...
모든 포맷은 MS 오픈 스펙 계약(Microsoft Open Specification Promise)으로 보호됩니다. 그런데 이게 GPL 내지는 다른 오픈 소스 라이선스와 충돌하는지 안 하는지 아직 불확실하다고 하는군요. 따라서 오픈 소스 진영이 이번 공개로 이득을 볼 수 있는지 여부를 확인하려면 좀 더 시간이 필요합니다.
하지만 더욱 심각한 것은, 이렇게 공개된 MS 오피스 포맷이 실제로는 아무런 쓸모도 없을 것이라는 주장이 제기되고 있다는 점입니다.
예를 들어, 엑셀 포맷 스펙은 PDF로 349쪽입니다. 그렇다면 이것만 읽으면 구현이 가능한 것일까요? 아닙니다. 스펙을 보면 다음과 같은 재미난 문장이 있습니다.
"엑셀 워크북은 Compound File에 저장됩니다."
Compound File은 파일 시스템을 단일 파일에 구현하는 이미지 파일 형식입니다. 따라서 엑셀 포맷을 제대로 다루려면 9페이지 남짓의 스펙을 더 읽어야 한다는 결론이 나옵니다.
조엘 온 소프트웨어에 따르면, 여러분이 워드 문서를 블로그에 업로드하는 멋들어진 코드를 작성하기 위해, 주말을 투자하여 MS 오피스 스펙 문서를 읽으려 한다면, 스펙의 복잡함과 방대함이 그 즉시 여러분을 그러한 욕망에서 벗어나게 할 것이라는군요.
또한 어떤 프로그래머이든 오피스 바이너리 포맷을 보면 이러한 결론을 낼 것이라고 합니다:
* 고의로 꼬여있다.
* 스타트렉에 나오는 미친 보그가 만든 것이다.
* 심각하게(insanely) 수준 미달인 프로그래머가 만들었다.
* 제대로 읽거나 만들 수가 없다.
하지만, 조엘에 따르면, 사실 이렇게 된 이유는 따로 있습니다. MS 오피스 바이너리 포맷은 HTML 같은 표준 스펙과는 완전히 다른 목적으로 디자인된 것이기 때문입니다:
* 저사양 컴퓨터에서도 원활히 돌아갈 수 있도록 하기 위해 온갖 최적화를 했습니다: 엑셀 초기 버전은 1MB 램에 20MHz 386 CPU에서 동작해야 했습니다. 따라서 파일을 빠르게 읽고 쓸 수 있도록 하기 위해 수많은 최적화(=꼬아놓기)가 이루어졌습니다.
* 기존 라이브러리을 이용하도록 디자인되었습니다: 윈도우에는 메타파일 그림, OLE 같은 라이브러리가 있고, MS 오피스는 이러한 것을 이용합니다. 따라서 이를 윈도우가 아닌 환경에 적용하려면, 처음부터 관련 라이브러리를 다시 작성하는 노력이 필요합니다. 우선 리눅스에 OLE 구현부터 해야 할 것입니다. 미친 짓이죠.
* 상호 운용(연동)을 고려하지 않았습니다: SGML, HTML 같은 표준 포맷과는 달리, MS 오피스 포맷은 지금까지 MS 오피스에서만 이용하면 충분했습니다. 따라서 다른 프로그램과 연계될 것이라는 가정은 하지 않았습니다. MS 워드가 지원하는 포맷 중 RTF가 있는데, 이것은 지금도 여전히 사용 가능하지요.
* MS 오피스의 역사가 반영되었습니다: MS 오피스 버전이 올라가면서, 하위 호환성을 유지하고 새 기능을 추가하기 위해 포맷이 전체적으로 매우 꼬이고 말았습니다. 따라서 MS 오피스 클론을 만들려는 사람은, MS가 지금까지 15년 동안 해왔던 삽질을 똑같이 따라해야 할 것입니다.
전체적으로 MS 오피스 바이너리 포맷은 낡았기 때문에 이러한 문제는 필연적입니다. 따라서 위에서 말한 것처럼, 이번 공개가 실질적으로 쓸모가 있는지는 좀 더 두고봐야 할 것 같네요.
Microsoft Office Binary (doc, xls, ppt) File Formats
Posted by 랜덤여신
