OOXML 정말로 ISO 표준이 되어 버리는 걸까요?

OOXML에 무슨 문제가 있는건지 모르겠군요.
적어도 제게는 '~카더라'말고 정확한 정보가 접할 수 있는 정보가 없습니다.
반대하시는 분들께서 근거 확실한 정보를 좀 공유해주시면 좋겠습니다.

누가 6000페이지에 달아는 저 책을 다 읽어보고 이해하고 구현할 수 있느냐 가 문제군요. 그사이에 또 새로운 형식이 나올테고요. 표준 만들어놓은 M$야 자기네들이 이미 구현해 놓은게 있으니 그거 갖다 쓰면 바로 만들 수 있고.

Written By the Black Knight of Destruction

궁금한 것이 OOXML이 표준으로 채택이 되면
MS가 구현 한 OOXML 파서만 표준인가요?

해당 기술이 표준이 되면 스펙의 취약점으로 인해 구현물간 혼란이 일어나도
어짜피 오픈오피스에서 생성하는 OOXML도 표준이고
MS 워드에서 생성하는 OOXML도 표준이고

단지 OOXML를 지원하는 프로그램들끼리 서로 호환이 안되는거 뿐일텐데요

설령 둘다 표준에 부합하는 구현을 했더라도요..물론 표준에 부합하는 이상 그 결과물들은 항상
호환되어야 한다라고 하면...네 그게 표준의 정의긴 한데

위에 몇 분이 말씀하신데로 스펙의 취약점으로 인해( 애매모호한 표현이라던지 )
문제점이 발생한다면 왜 그것이 MS의 독점으로 이어진다고 생각하시는 의문이 드네요.

만약 그렇게 된다면 관공서,기업등에서 OOXML 문서를 배포하거나 받아들일 때,
"MS word에서 생성한 OOXML 문서 입니다."
"KWord에서 생성한 OOXML 문서만을 받습니다." 등등

처럼 되서 표준을 제정한 의미가 사라지겠군요.

그런데..
그렇게 되면 MS가 독점하는 결과가 이어지는건가요?...( 정말 궁금해서 던지는 질문입니다. )

단지 그런결과를 야기 시킬만한( 표준에 부합하는데도 불구하고 결과가 다른 )
기술적 스펙을 받아들인 ISO의 잘못일 뿐입니다.

OOXML이 표준 문서 포맷으로 지정된 다는 것은
MS가 향후 자신들의 어플리케이션에 추가기능을 구현하고
지원한다고 해서 OOXML 표준 스펙이 바뀌는건 아니라고 생각합니다.
비표준 스펙으로 구현된 문서는 OOXML이 아닌거죠.

만약 MS가 새로운 비표준 기능을 표준에 넣고 싶으면 ISO를 통해 심사를 받고
스펙을 바꿔야 하겠죠.

OOXML포맷이 표준이 된 다는것이
향후 모든 변경 사항과 OOXML 표준 준수 인증시스템(??)을 전부 MS에게 맡기고
MS가 뭘 하든 무조건 ISO는 검토 없이 따라간다는 말을 의미하진 않는다고 생각합니다.

OOXML의 기술적 문제로 인한 비판들은 납득이 갑니다만

OOXML의 표준화가 MS의 독점을 야기 시킨다는 것이

ISO라는 단체에서 하는 표준화의 본래취지가 OOXML에는 적용되지 않을것이며
단지 MS가 ISO의 OOXML 전문 담당부서가 되서 걔네들이 모든 OOXML에 대한
결정권을 가진다는것은

아니라고 생각합니다.

그래서 독점에 대한부분이 OOXML에 대한 반대이유가 되는것에선 의문을 갖습니다.

기술적으로 플랫폼 의존적인 부분이 있다라던지 등의 이유는
독점 같이 정치적 이유보다 단지 기술적 결함이라고 생각합니다.
그런 점들은 충분히 비난받을만 하죠.

충분한 반대 이유가 될 수 있는 것은 그간의 MS의 행보때문입니다.

즉, 독점적 지휘을 바탕으로 표준을 준수하지 않고,
또한 자의적으로 표준을 확대하거나 곡해함으로서,
경쟁자들을 고립시키면서 독점을 돈독히 하는 것이
그들의 주된 전략이었기 때문이죠.

MS가 OOXML의 표준채택에 사활을 걸게 된 것은,
ODF가 ISO 인증 통과하면서 정부공문서의 표준 양식으로
채택되기 시작되면서 부터입니다.

사실 MS 오피스도 ODF를 플러그인 형태로 지원하면 됩니다.
실제로 그렇게 하고 있고, ODF의 부족한 부분 또한
MS 역시 다른 업체들과 협력하며 개정작업에 참여 하면 됩니다.
MS는 분명 이러한 위치에서도 충분히 다른 업체들과 경쟁할 수 있는 능력이 있는 회사입니다.

그런데 MS는 그것을 원하지 않지요.
이것은 그간 MS 자신만이 오피스의 개발방향을 결정하고
시장부터 모든 것을 리드하던 그러한 지휘를 상실한다는 것을 의미합니다.
즉, 독점적인 시장 리드를 지키기가 어려워 집니다.
이럴 경우 오피스가 쌓아온 모든 것이 사라지고,
다른 오피스군들과 동등한 위치에서 싸워야 합니다.

제가 OOXML이 표준 인증을 받는 것이 두려운 것은
저 6000쪽짜리가 문서가 아니라, 곧 오피스가 표준이 된다는 점입니다.
문서는 아무런 가치가 없다는 점입니다.

실제로 오피스의 기술규약서일 뿐이기 때문에,
아무리 저 규약서대로 구현하더라도 오피스에서 불러 와서 깨져보인다면
아무런 소용없다는 뜻이죠.

웹브라우저는 그나마 acid테스트 같은 것이 있어서 호환성 테스트나 하지만,
누가 MS 오피스에 대해서 규약서대로 준수하는지 테스트할 엄두를 내겠습니다.

OOXML의 주도적인 위치를 이용해서 MS는 신기술을 규약에 쉽게 반영시킬 수 있지요.
MS는 신기술이 규약에 반영되기도 전부터 시장에 언제나 다른 경쟁 업체 먼저 제품을
내놓을 수 있다는 의미가 됩니다.
여기에 또 다시 5000 페이지 짜리 문서하나 던저 주면,
다른 후발업체들은 이에 한동안을 매달려야 합니다.
이미 그 사이에 모든 시장은 MS가 다 찾이한 후가 되겠지요.

공정한 경쟁이 될 수가 없습니다.

MS가 자신의 규약을 준수할지 조차 저는 의문이 듭니다.
이것 저것 조금씩 확장시켜서 MS는 다른 문서들을 다 불러 올 수 있지만,
다른 오피스들은 MS 오피스의 문서를 제대로 불러오지 못하는 문제가
생길 수도 있습니다.

어떤 Closed 소프트웨어 업체가 독점적인 위치를 찾이 한 후
시장에 준 폐해는 이루 말도 할 수 없이 많습니다.
그 대표적인 역사의 중심에 MS가 서 있죠.

미국에서 공룡기업이 포함된 민사재판을 할 경우
상대에게 의무적으로 제출해야 하는 내부정보가 있을 때,
불필요한 자료를 한트럭 보내고 이 사이에 그 문서를 껴 넣는 전략이 있습니다.

저 6000페이지 속에 무슨 꿍꿍이가 있는지 의심스럽기 짝이 없습니다.

There is no spoon. Neo from the Matrix 1999.

지리즈님께서 말씀하신 우려에 대해서도 모르는 바는 아니고, 어떤 면에서 역으로 생각해보면, MS 가 바라보는 ODF 형식에 대한 관점도 조금 긴 시간을 두고보면 주요 골자는 거기에 있을거라는 생각을 합니다.

하지만 OOXML 이 그런 이해 관계를 떠나서, 표준이 갖춰야할 조건을 잘 갖추었다면 ( 분명히 이 부분은 제 생각에 현재로는 아니고, 짧은 시간에 해결할 수 있는 문제도 아니라고 생각하지만 ) 그것을 기술적인 문제 이외로 반대하는 것에 대해서는 저는 아니라고 생각하는 것입니다.

MS 의 독점적 위치를 표준으로 확고히 해주는데 찬성할 이유도 없고, 개인적으로도 좋은 일이라 생각지 않지만, 어쨌든 이 부분은 거기에 걸려있는 시장을 놓고 싸우는 사람들이 문제의 핵심에 있습니다. 누구 한 쪽이 이득을 보게 돼 있다는 말씀도 그런 맥락이고, 역으로 생각했을 때 MS 가 ODF 를 보는 관점도 마찬가지 아니겠느냐 역시 그런 맥락이죠.

표준의 분량에 대해서는, 표준이 정해지고 시간이 흐를수록 어차피 그 표준 가지고 새로 시작하려는 업체는 역시나 부담이 될 수 밖에 없는 것이라고 생각합니다. 이건 OOXML 뿐 아니라 ODF 도 마찬가지고, 이 문제를 떠나서 다른 분야도 그렇죠. 물론 제가 보기에도 6000 페이지는 crazy 스럽습니다. 하지만, 미리 얘기했듯이, OOXML 스펙이 기술적인 문제에 걸림돌이 없다면, 어떤 면에서는 기회일 수도 있겠다는 생각이 듭니다. 왜냐면 이미 OpenOffice 같은 소프트웨어 역시, 그런 노력은 하고 있지 않습니까? MS 오피스 파일과 호환되려고 무던히도 노력하지요...

아무튼 제 생각에 이 문제를 단시일내에 투표로 결정하는 방식은 지극히 그 자체로 정치적이고 이해관계에 따라 움직이는 방법입니다. 시간을 두고 실제로 그런 구현이 가능한지 검증될 시간이 있어야 합니다. 물론 이런 시간은 MS 가 바라는 바는 아니겠죠. MS 도 시간을 다투고 있을테니까요...

아무튼 지금은 결과를 기다리는 수 밖에 없는 때인 것 같군요.

기술적인 부분도 문제가 없는 것은 아니라고 봅니다.

기본적으로 MS는 여러버전의 오피스가 있고,
MS가 제출한 문서에는 하위호환을 "어느 정도" 기술하고 있습니다.

이게 하나의 잇슈라고 볼 수 있습니다. 즉, "어느 정도"라는 점이죠.
규약이 새 버전만을 표준으로 정하면 더 간결해질 수 있습니다.
다만, 이럴 경우 구버전의 오피스 문서는 제대로 읽어 들이지 못할 수도 있고,
심지어면 MS가 규약을 준수하기 위해 새 버전의 오피스부터는
일부의 하위 호환 포기해야 할수도 있습니다.
(사실 이게 바람직하다고 저는 생각합니다.)

다른 한편 하위호환에 대해서 수용하기로 한다면 이 내용이 부실하다는 점입니다.
즉, 하위호환을 표준으로 정하면서도, 이에 대한 기술규약부분을 제대로 제공받지 못하는 점이죠.

MS는 여기서 이득을 봅니다.

즉, 구오피스에서 생성된 문서들도 표준으로 인정 받으면서,
경쟁자들에게는 정확한 정보 제공을 하지 않는 것이죠.

만약에 구번전 호환이 표준이 아니라면,
표준문서로 변환해야 하는 의무가 사용자들에게 발생하긴 합니다만,
이미 ODF를 채택하는 정부단체가 있는 것을 고려하면
이는 문제가 아니라고 보입니다.

만약, 구번전들도 표준으로 채택된다면,
구버전에서 생성된 문서를 읽으려면 역시 MS오피스를 구입해야 합니다.
여기서 독점적인 우위를 MS가 가질 수 있습니다.

또한 MS가 이 규약에 관련된 특허에 대해서 권리를 행사하지 않겠다고 했는데,
이것이 무조건적인 것이 아닙니다. 합리적인 조건하에 라는 단서가 붙습니다.

예상컨데, 이러한 특허가 오피스에서 사용되는 것은 MS가 말한바가 있기 때문에
소송을 걸지 않을 겁니다. 다만, 오피스 오픈소스 중 일부가
다른 용도의 프로젝트에 사용될 경우 MS의 대처가 불명확합니다.
즉, 오픈오피스 소스를 가져다 썼다가 MS에게 소송당할 수 있다는 점이죠.
게다가 문제는 어떤 부분이 특허에 관련된 소스인지 구체적으로 알수 없기 때문에
오픈오피스 소스를 전부다 묶어 버릴 수 있는 장치로서 활용될 수도 있습니다.

이러한 문제점들이 해결되지 않는다면 MS에 놀아날 수 있다고 저는 생각합니다.

There is no spoon. Neo from the Matrix 1999.

다른 사람들이 뭐라하건 여긴 KLDP입니다. 리눅스 커뮤니티란 거죠..

그렇기 때문에 플랫폼 종속적인 표준 채택에 더 분게하는것이고, 사실 표준이란게 플랫폼 종속적이란게 말이 안돼는거죠..

"~카더라"라고 하신 분도있는데...플랫폼 종속적이란게 확실한 근거가 아닙니까?

표준이란건 가장 광범위하게 쓰여야되는데...어떤 시스템에선 되고 어떤 시스템에선 안된다는것 자체가 말이 안되는 소리죠.

플러그인으로 제공하겠다. 이것도 말이 안되는 겁니다. 6000페이지에 달하는 스펙문서를 그대로 구현한 플러그인을 Openoffice용으로 만들고, Koffice용으로도 만들고, 새버전 나오면 거기에 마춰서 새로 코딩하고, 그리고 기업제품(staroffice, 한컴오피스)은 기업제품 대로 또 삽질을 시작해야되는건 상상이 안되십니까?

여기 까지는 순수하게 기술적 문제구요.

이러한 기술적 문제때문에.... MS가 시장지위 확보에 대한 어드밴티지를 갖게된다는 정치적 문제도 걸리게되는거죠.

IE사태를 격어보셨겠지만 표준도 뭣도 아닌 ActiveX덕분에 국내 웹환경은 엉망 진창이 되어 버렸고, IE자체는 독점적 지위를 이용해서 표준이고 뭐고 다 무시해서 다시 한번도 국내 웹환경을 쑥대 밭으로 만들어 버렸습니다.

그리고 이제와서는 IE 8부터는 비표준을 버리고 ActiveX도 버리겠다고 합니다. 이렇게 휘둘리는 이유가 표준이 뭔지, 표준이 어떠해야되는지...에대한 의식부족탓입니다.

물론 OOXML이 표준이 된다면 IE처럼은 안돼겠지...라고 생각하실수도 있습니다. 하지만 IE는 표준이 정해 지고 나서도 독자 노선을 걸었고, 그런 독선이 MS에 잔제하는한 OOXML은 위에 어느 분이 말씀하신데로 MS의 독선에 힘을 실어주고 자신들이 정한 표준마저 마음데로 휘두르면서 시장 지위와 표준이란 무기를 필두로 새워서 IE 보다 더 횡포를 부리지 않을거라고 장담 할수 없다면...(없다면이 아니라 특허문제를 고려해볼때 확실히 장담할수 없는거겠죠..) 어떠한 여지도 주지 않는 것이 표준의 가치를 홰손시키는 것을 막는 방법이라고 봅니다.

기분이라도 풀어 보자구요.
.
.

AC/DC Highway To Hell

There is no spoon. Neo from the Matrix 1999.

뭐 설득력이 부족하다고 하니까 좀 길게 늘여써보죠.

어쨌든 그렇다면 줄여서 이슈는 MS의 OOXML 표준 추진은 오래전 MS가 ie 로 저질렀던 웹 표준에 대한 "물타기"와 같은 식이 아니냐 하는 우려인데요.

MS의 원죄는 많습니다.... 대표적인 물타기 케이스가 ie를 윈도우에 끼워 넣고 ie 전용 문법을 은근히 퍼뜨리며 Netscape 브라우저를 윈도우에서 축출한 것과 java를 sun에서 라이센스 받아 윈도우에 탑재시킨다음 Sun의 자바 VM과의 호환을 어렵게 해서 자바를 물먹였죠.

하지만 지금 MS가 OOXML을 미는 것을 과연 예전의 MS의 이러한 행태의 반복이라고 판단할 수 있을까요? 우선, MS는 ODF가 아닌 OOXML이라는 별개의 표준을 밀고 있습니다. 적어도 지금 MS의 행보는 예전과 같은 방식으로 윈도우나 오피스의 마켓파워를 토대로 ODF표준을 물먹이고 자기네 것인 양 변질시킬 수 있는 환경은 아니라고 봅니다. 오히려 OOXML를 ODF와 경쟁시키겠다는 전략으로 판단할 수 있고 이를 뒷받침하는 것은 현재 MS가 갖고 있는 오피스 시장의 높은 시장점유율에 기반하고 있는 것이지요.

그런데 여기서 이러한 MS의 행동이 과연 기업으로서는 해서는 안되는 반독점 행위에 속하는 것인가요? ie와 java의 경우는 실제 판결은 MS쪽에 유리하게 나긴 했지만 MS가 반독점 소송을 당할만한 정황은 충분합니다. 하지만 기업이 자사의 제품에 유리한 표준을 미는 것 자체를 백안시 할 필요는 없고 또 근거도 부족합니다. 오히려 지금까지 MS의 행태로 봐서는 ODF에 편승하는 것이 실제 ODF 표준에는 해악일 가능성이 더욱 높습니다. 윈도우와 MS Office의 시장 점유율을 소위 레버리지(leverage)해서 일단 ODF에 편승한 다음 예전 ie나 java VM의 경우처럼 ODF 표준 자체를 물먹이는 가능성이 더 위험한 것 아닐까요?

또한, MS가 OOXML로 경쟁업체들에 대해 진입장벽을 치고 있을 수도 있습니다. 하지만, 여기서도 MS가 오피스제품에서 갖는 비교우위에서 발생하는 경쟁력과 MS가 마켓파워를 악용한 진입장벽은 구분해줘야 합니다. 100m 달리기로 치면 달리기를 잘 하는 것과 달리다가 옆 레인의 선수를 한 방 먹이는 것은 구분하자는 것이죠. 물론 이것 역시 둘 사이의 정확한 boundary는 제시하기 어렵겠지만 양쪽 스펙트럼 끝은 고려해 볼 필요가 있어요. 적어도 MS가 오피스라는 쓸만한 제품을 그동안 판매하면서 쌓아온 시장 점유율 그 자체는 소위 그네들의 프리미엄으로 인정해 줄 필요가 있고, MS가 마켓파워를 악용할 수 있는 환경이 조성되는 것은 애초부터 막을 필요가 있습니다. 따라서 일단 MS는 그 정도 수준의 제품과 시장 점유율이면 충분히 OOXML 표준을 밀 자격은 충분하다고 볼 수 있을 것이며 특허나 기타 MS가 마켓파워를 악용할 수 있는 가능성이 높은 환경은 애초부터 MS에 포기를 요구하는 것이 바람직할 겁니다. 그런데 이미 이것은 진행중인 사안이 아니냐는 것이죠. 바로 위 channy님의 글에서도 볼 수 있듯이 한국의 OOXML 찬성표는 요구사항이 어느 정도 만족되었기 때문에 던지는 조건부 찬성아니겠어요.

그리고 OOXML이 정말로 MS가 의도적으로 경쟁업체에 피해를 주기 위해 복잡하게 디자인되었다고 칩시다. 그런데 과연 MS 오피스의 경쟁 제품들이 OOXML 스펙을 완벽하게 구현할 필요가 있나요? 실제 사용자들이 필요로 하는 것은 완벽한 호환이 아니라 기본적인 수준의 호환입니다. 예를들어 파폭 1.0버전이 파폭 2.0 버전에 비해 웹 표준 지원은 분명 떨어질 겁니다. 하지만 파폭 1.0을 지금도 쓰는 사용자가 있다고 할 때 이 사람은 파폭 2.0으로의 업그레이드 필요성을 얼마나 느낄까요? 표준의 이런 특성이 있는데 MS의 경쟁 기업들은 언제까지 OOXML의 완벽한 구현이라는 문제에 집착해 스스로 과도한 개발 비용을 자초해서 짊어지고 경쟁을 해야 하나요? 이것은 OOXML의 적절한 수준의 구현에서 해당 기업이 선택할 수 있고 사용자도 충분히 만족할 수 있다고 봅니다. 그리고 OOXML이 이것마저도 물먹일만큼 문제많은 표준은 아니라고 봅니다. 만약 그랬다면 ECMA 표준 승인을 통과조차도 하지 못했겠죠.

또한, 경쟁사 개발자의 입장에서 생각해 봅시다. 비공개 포맷인 doc이나 xls 포맷을 분석하는 것이 개발 비용 측면에서 유리합니까 아니면 6000페이지라도 공개되어 있는 OOXML 규격을 참고하는 것이 유리합니까? 당연히 후자가 개발자에게는 유리합니다. 그리고 이를 MS가 제안했다는 것은 반독점의 측면에서나 MS 경쟁사의 입장에서도 오히려 바람직한 상황 전개라고 판단하는게 자연스럽지 않나요?

덧붙여 또 ODF는 오픈소스가 위주인 오픈오피스 진영에서 가장 많이 쓰기는 하지만 현재 Sun과 IBM에서 밀고 있습니다. 즉, ODF와 OOXML이 시장에서 표준 주도 싸움이 벌어진다고 하더라도 ODF는 든든한 기업 후원이 없기 때문에 애초부터 경쟁에서 밀릴 수 밖에 없는 상황이 아닙니다. 오히려 IBM이나 SUN과 같은 거대기업이 ODF를 밀어 MS의 OOXML과 싸움이 붙으면 사용자나 개발자의 입장에서는 유리합니다. 인텔과 AMD가 서로 경쟁하는 것이 값싸고 좋은 시피유 생산으로 이어지듯이 말이지요.

이렇게 여러 측면에서 볼 때 OOXML 표준을 MS의 현재 마켓파워와 앞으로 있을지 모를 마켓파워 남용의 가능성을 이유로 반대하기가 상당히 어렵습니다. 오히려 MS의 위험이 지나치게 높게 평가된 측면이 많다고 봅니다. 이것보다는 차라리 적극적으로 MS의 전력을 약점으로 잡아 독점의 가능성을 애초부터 막은 다음 OOXML의 ODF와의 경쟁을 유도하는 쪽으로 전략을 미는 것이 충분한 대안이 될 수 있다고 봅니다.

사실상 ODF는 폐기나 마찬가지 입니다.

끝이죠.

공존 이런 건 이상적인 세상에 존재하는 거죠.

IBM이 모 변방국가 내부에서 진행되는
투표과정이 투명하지 않았다고
그 국가 검찰에 고소하는 등 지저분할 정도
처절하게 대응하는 것도 다 이런 이유 때문입니다.

그래도, 웹은 W3C가 있어서, 견제나 되었기 때문에
우리나라는 아니지만, 그나마 다른 나라에서는
브라우저들이 살아 남아 있었던 거죠.

W3C의 영향력이 없는 한국 상황을 보세요.. 어떤가...

오피스 시장도 이제 마찬가지 입니다.

There is no spoon. Neo from the Matrix 1999.