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

imyejin의 이미지

http://www.zdnet.co.kr/news/enterprise/server/0,39031193,39167140,00.htm

zdnet 기사에 보면 분위기가 될 것 같다고 합니다.
M$말고 OOXML 표준을 구현할 수 있는 곳이 있긴 한가요?
그런데도 국제표준으로 삼으려고 최종 투표까지 올라온다는 것 자체가
M$ 독점의 폐혜가 얼마나 막강한지 새삼 느끼게 합니다.

한글문서를 검색해서 추가합니다.
IBM 사이트에서 정리해 놓은 OOXML의 의의와 문제점입니다. (한글 문서입니다.)

http://www.ibm.com/developerworks/kr/library/x-ooxmlstandard.html

요컨대, OOXML은 그저 M$에서 지금 만들어 팔고 있는 물건이 다루는 문서를 XML로 기술했다는 점에서는 의의가 있지만 이걸 호환가능한 시스템을 만드는 표준으로 사용한자는 것은 그저 어처구니가 없다는 것입니다. 어떤 한 시스템을 자세하고 철저하게 기술하는 일과, 모두가 기준으로 삼고 따르기에 적당한 표준을 만드는 것과는 별개의 문제입니다. 현실적으로 OOXML표준을 제대로 만족하는 구현이 가능한 곳은 이미 다 만들어 놓은 M$ 뿐이라는 거죠. 그냥 M$ 오피스 개발팀의 스펙으로나 쓸 문서를 표준이라고 등록시키려는 황당한 짓은 좀 말려야 합니다. -_-

linlin의 이미지

기사의 이 부분이 핵심 아니겠어요.

Quote:

결과를 보면, 전체 응답자의 88%는 반대를 하였고 12%는 찬성하는 것으로 결과가 나왔다. 반대자의 대부분은 대안 표준의 존재, 특허권 문제, 특정 벤더에 독점적 지위 부여, 플랫폼 종속적임을 그 이유로 들었다.

그렇다면 MS가 특허권으로 합법적인 시장 독점권을 보장받는 것을 포기하고, 플랫폼 종속적인 요소를 OOXML에서 제거한다면 OOXML을 표준으로 생각해 볼 수도 있는 일 아니겠어요?

문제는 대안 표준의 존재인데.. 아마도 ODF 얘기를 하는 거겠죠? 하지만 이 문제는 하지만 냉정하게 손익을 따져봐야합니다. 과연 ODF가 OOXML을 대치할만큼 충분한 성능을 제공하고 있는 것인지? 여기에 대한 대답이 yes가 나오지 않는다면 OOXML을 표준으로 하고 오피스 차세대 제품을 사서 쓰는게 오히려 낫습니다.

그리고 표준이라는 것은 많이 쓴다는 게 중요합니다. 안쓰이는 표준은 있어봐야 무용지물 아니겠어요? MS 오피스의 시장 점유율은 무시할 수 없고 또 오피스 패키지에 비록 상용이지만 이런 사실상의 표준이 존재하는 것은 실제 사용자들에게도 유리합니다. 플랫폼 종속에 끌려가니 이런건 사실은 배부른 불평이에요... 어쨌든 그런면에서 OOXML을 표준으로 삼자는 주장은 상당한 설득력이 있는 겁니다. 이걸 보고 MS의 독점의 폐해라고 생각하는 것은 성급하죠. 오히려 MS 독점의 바람직한 면이라는 표현이 더 어울릴겁니다.

imyejin의 이미지

OOXML 국제표준으로 제정하면 M$말고 대체 누가 이득을 보나요?

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

linlin의 이미지

MS의 이득이 곧 전세계 인민들의 이득이 됨을 생각해야죠. 일개 조그만 기업에서 오피스를 써도 MS 오피스를 쓰지 않고 어떤 대안이 있나요? 마찬가지로 ODF가 ISO 표준이 되면 MS 오피스 말고 다른 오피스를 써도 되는 새세상이 갑자기 펼쳐진답니까?

lain07의 이미지

MS의 이득이 곧 전세계 인민들의 이득이 됨을 생각해야죠.

이 말이 대체 뭔 소립니까? 제가 논리적이지 않아서 그런가요? 전혀 와닫지 않는데..
아니면 MS가 오피스를 무료로 배포하기라도 한다는 겁니까?

___________________________
I like Small Linux.


___________________________
I like Small Linux.

linlin의 이미지

MS 오피스 제품 자체의 우수성을 간과하지 마라는 얘기입니다. MS가 오피스 매출로 돈을 벌어 오피스 제품 기능을 향상시켰을 때 그것이 오피스를 구매해서 쓰는 사용자의 이득으로 돌아가는 순구조를 무시해서는 안되죠.

chungsy02의 이미지

항상 독과점 보다 경쟁이 더 훌륭한 제품을 만듭니다.
아마 MS Office의 경쟁 재품이 있다면
MS는 더 적은 매출액으로 훨신 더 좋은 MS Office를 만들게 될 것입니다.

AMD가 Intel의 시장을 빼앗아가지 않았으면
우리는 지금 더 좋은 Intel CPU를 쓰고 있을거라 생각하시나요?

밀가루값 오르면 빵값 올리고 밀가루값 내릴때는 빵값 안 내리는 제과회사 덕분에
우리는 더 질좋은 빵을 더 값싸게 먹게 되는건가요?

쥬유세가 내린만큼 기름값을 올려버리는 주유소들은 우리에게 어떤 이익을 주나요?

linlin의 이미지

규모의 경제 개념을 이해를 못하고 있네요. 모나미 볼펜을 예로 들어보죠.

모나미 볼펜 한 자루 사는데는 요즘 얼마하나요? 물가가 올라도 200원 안할겁니다.

그런데 님이나 저같은 일반 개인이 뜻한 바 있어 볼펜을 만들어 팔겠다고 나서 봅시다. 아무리 재주가 좋아도 200원 달랑 줘 놓고 볼펜을 만들어라면 죽었다 깨어나도못합니다.

그런데 모나미 같은 회사가 은행에서 돈빌려 공장 짓고 설비 들여오고 노동자들 모집하고 회사 돌리기 시작하면 볼펜을 한자루 200원도 안되는 가격에 만들 수 있는 겁니다.

여기서 모나미말고 바른손에서도 볼펜 시장에 뛰어들었다고 해 봐요. 당연히 두 회사가 경쟁을 하겠죠. 볼펜 가격은 경쟁으로 낮아질 것이구요.

그런데 이 경우 몇몇 산업은 공장의 규모를 늘이면 늘일수록 생산 단가가 낮아지는 특성이 있는 산업들이 있어요. 이렇게되면 어떤게 사회적으로 이익이 되나요? 당연히 사회 전체의 볼펜 수요를 한개의 커다란 기업이 담당하는게 가장 단가가 싼 볼펜 생산으로 이어지는 겁니다. 실제 이렇게 두 기업이 경쟁하다보면 결국은 시장에 한 기업만 남는 것으로 스토리가 진행됩니다. IT 산업이 대표적인 케이스가 되구요. 그래서 이동네가 표준표준 많이 따지는 겁니다. 표준의 독점이 이 동네에는 바람직한 상황 전개로 이어져요.

물론 여기서 시장에 한 회사만 남으면 독점 문제가 생깁니다. 가장 바람직한 것은 시장에 한 기업만 남기고 독점은 방지하는 것이겠죠. 그런데 사실상 여기서 독점을 방지하는 장치를 만들기가 많이 어렵습니다. 따라서 이 규모의 경제로 인한 비용 절감효과가 충분히 크다면 독점으로 인한 사회적 손실은 어느정도 감당하는 쪽으로 나가는 것도 현실적인 방법이 되고 또 진입장벽을 낮추어서 현재 기업은 시장을 독점하고 있지만 언제든지 새로운 기업이 뛰어들 수 있는 잠재적인 경쟁에 노출되도록 하는 방법도 차선책으로 많이 쓰고 있어요. 이런 건 법으로 규제가 가능하지만 독점기업이 단기간 저가공세를 펼치다 다시 경쟁자를 몰아낸 뒤 독점가격으로 돌아가는 것은 막기가 상당히 어렵습니다. SK 텔레콤의 휴대폰 서비스 가격을 정부가 나서서 안내리고 있는 게 이런 이유 때문이죠.

어쨌든 규모의 경제가 작용한다면 모나미가 독점을 하면 볼펜 가격이 예를들어 100원이 되겠지만 모나미와 바른손이 시장을 반씩 먹고 경쟁을 하면 볼펜가격이 예를들어 500원이 될 수 있는 겁니다. 모나미가 독점기업이라는 이점을 이용해 볼펜가격을 올리면요? 이론상으로는 예를들어 400원으로 올린다면 모나미의 독점을 용인해 주는 것도 괜찮은 선택이며 600원으로 올린다면 모나미와 바른손이 경쟁하도록 하는 것이 사회적으로 바람직한 일이 됩니다.

MS 오피스의 현재 가격이 실제 여기 모나미 볼펜이 400원에 팔리고 있는 것인지 600원에 팔리고 있는 것인지는 정확히 판단하기 어려워요. 하지만 사람들이 MS 오피스를 워낙 많이 쓰는 까닭에 오피스 가격이 충분히 내려간 것은 사실이고 또 사용자들도 덕분에 비싼 볼펜대신 싸고 질좋은 볼펜을 살 수 있듯이 성능 좋은 오피스를 괜찮은 가격에 구매할 수 있는 겁니다.

snowall의 이미지

플랫폼 종속적인 요소를 빼면 OOXML에서 뭐가 남는지 찾아봐야 할 필요가 있어 보입니다.

--------------------------
snowall의 블로그입니다.
http://snowall.tistory.com

피할 수 있을때 즐겨라! http://melotopia.net/b

khm8843의 이미지

다른 이야기지만 웹표준만 해도 그렇습니다.
인터넷 익스플로러의 경우도 대부분이 쓰고 있지만 표준이 아니다 보니 웹개발자 입장에서 표준에 입각해야 하기 때문에 문제가 많쵸.
하다 못해 얼마전까지 포털 사이트도 FF 에 오페라 등에서 사이트가 깨지는 현상이 있으니깐요.
진작에 IE나 아니면 다른걸 표준으로 과감히 했다면 지금같은 일이 벌어지지 않지 않았을까. 생각하네요.

비슷한 경우라 생각해서 잠시 끄적였습니당

김일영의 이미지

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

imyejin의 이미지

라고 M$는 말하고 싶은가본데, 자세한 설명은 생략하고 그냥 한눈에 봐도 이게 말이 되는 소린가요? :(

보다 자세한 설명은 여기에
http://www.noooxml.org/forum/t-16529/ooxml-problems-in-75-slides

특정 업체(M$)만 제대로 구현할 수 있는 무식하게 장수만 많고 설계가 제대로 되었는지 제대로 검토조차 안되는 걸 표준으로 정하네 마네 최종 투표를 하고 있는 상황 자체가 이미 코미디죠.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

김일영의 이미지

척보니 너 인상 더럽게 생겼다 라는 말과 다른게 뭔가요?
MS 다니는 사람이 여기와서 댓글 달리도 없는데 M$ 운운하는 유치한 댓글이나 좀 달지 마시고...
MS 돈벌든 말든 나랑 상관 없거든요? 여하튼 근거를 확인하고 행동하는 당연한 개념 좀 장착합시다.
그냥 남들이 반대한다니까 우르르~ 그러지 말고요.

Darkcircle의 이미지

말이 안된다는게 유치하다기보단... 저건 CPU 데이터시트보다 더 두꺼운데요... 아니 프로그램 소스중에 프로그램 크기랑 비교도 전혀 안된다는 수만장의 컴파일러 소스를 앞뒤 양면으로 다 뽑아도 저렇게 많이는 안 나옵니다.
저게 무슨 "이지 투 임플러먼트"입니까? 저기에서 XML 엘리먼트랑 속성 다 찾아서 일일이 다 쓰라구요? 환장하겠네요... 그리고 설마 엘리먼트 레퍼런스 실제 내용이 저거의 1/3 밖에 안된다 하더라도 저건 무슨 대하드라마 장편 소설책이군요... 대체 뭐가 대단하길래 그렇게 책으로 떵떵거리는지...

XML 에디터 전문회사로 알려진 Altova 에서도 OOXML 표준화를 대비해서 몇몇 기능들이 추가가 되었는데 저거 때문에 프로그램 크기가 이전 버전과는 비교도 안되게 불어났습니다. 보도 듣도 못한 엘리먼트 속성들도 엄청 많구요. 쓰지도 않을 기능 팍팍 넣어가지고 당췌 뭘 어쩌라는건지 이해가 안가네요. 물론 사태원인의 본질은 MS가 다 벌여놓은거구요... 잘못하다간 OOXML도 ActiveX꼴 납니다. 네. 그러고 나서 뒷처리는 우리가 욕먹는걸로 해야 하나요?

저정도 제안서양만큼 표준으로서 써야 할 것들이 많다면 일반 XML 에디터로는 엔간해선 표현하는데 엄두도 안나겠군요. 거 과학시간에 "법칙의 공통된 특징"에 대해 배워보시진 않았습니까? 단순 무식한 것들이 더 유명해지고 더 널리 쓰이는 법이지요. OOXML은 단순 무식한게 아니라 복잡 난잡하고 유치뽕짝한게 디게 화려합니다. 네 보이는것도 화려하지만 안의 규모도 엄청나죠. 이런걸 표준으로 제정하면 복잡해서 쓸 엄두가 안나기 때문에 쓰는 사람이 첨에는 호기심에... 그랬다가 안쓰죠. WFP 쪽 하시는 분들 계실지 모르겠네요... 죽어납니다. 제 친구랑 같이 하다가 전 다른 일이 더 급해서 접었습니다. 생각보다 많이 빡세더군요. 이 상황에서 OOXML 표준? MS플랫폼 기반의 XML 프로그래머들은 다 자기손으로 목따라는얘기죠. 심지어는 MS 플랫폼 뿐만 아니라 리눅스 환경에서 쓸 수 있게 표준화가 되면 글쎄요... 저 같아도 XML 프로그래밍 접습니다.

프로그램이며 저런 기술을 손쉽게 써서 목숨을 보전하기 위해서는 프로그램을 구매하는것이 좋을텐데 그 프로그램 마저 구매하기 위한 비용이 엄청 들어가겠네요... 오피스 패키지랑 Altova XMLSpy 같은것들... 뭐 어차피 개인이야 돈이 없으니 마구 복사해다가 쓸지는 모르겠지만 기업체 같은 경우는 직원당 라이센스를 사야 하니 미친듯이 돈을 깨먹어야 하겠네요. 그런 표준때문에 누가 미쳤다고 돈을 들인답니까?
이거 때문에 작년 XML 프로그래밍 과목시간에 담당교수님께서 "표준아닌 표준을 멋대로 만들어다가 쓰는 기업체는 MS 말고는 없을겁니다..." 라더군요. 이런 OOXML 따위 말고 쓸 수 있는거 얼마든지 있으니까 여러분들은 비용을 되도록 안 들이는쪽으로 해서 최대한의 이익을 창출할 수 있는 일자리로 가라더군요.

OOXML 표준 제정 반대는 해본 사람들이 아니까 반대를 하는겁니다. IE에서는 XPath며 뭐며 아직 구현안된 표준에 대해서 제대로 구현하지도 못하는데 이런판에 얼어죽을 또 다른 XML의 표준화라니... 어이가 없군요. 기본부터 제대로 다 구현해놓고 OOXML을 내놓으라고 따져보죠.

---------------------------------------------------------------
피곤함 1테라톤을 가방 보따리에 주섬주섬 짊어메고 다니는 아이 . . . Orz

---------------------------------------------------------------
폐인이 되자 (/ㅂ/)

김일영의 이미지

OOXML 표준이 복잡하면 안 쓰시면 됩니다.
저 역시 같은 일을 하는데 복잡하면 안 씁니다.
단순 무식한 것이 더 유명해지고 좋은 것이고 OOXML은 복잡하다면
결국 다들 OOXML은 안 쓸텐데 뭐가 걱정입니까.

OOXML 표준 제정 반대는 해본 사람들이 아니까 반대를 한다고 하셨는데
"해본 사람들"이 누구신지요?

M$가 어쩌구 하는 쉬어터진 낚시도 살짝 지겹습니다만
원래 제가 댓글단 취지는 글자 그대로, 근거가 있으면 근거를 보여 달라는 것입니다.

반대를 하는, 반대를 하자는 분은 많은데
솔직히 왜 반대를 해야 하는지 근거가 뭔지 보여주시는 분은 왜 이리 없는 것입니까.

예를 들어 OOXML을 쓰면 한글 처리가 제대로 안된다든지 뭐 이런거 말입니다.

OOXML이 복잡하다고 하시는 분의 글이 제겐 더 복잡해 보입니다.

참고로 표준이 복잡한게 문제라면 디지털 방송이나 데이터 방송은 절대 보시면 안되겠습니다.
HDTV 보시면 벌 받아야 하겠습니다.
그게 무슨 상관이냐라고 생각하신다면, 표준이 복잡한 것은 문제가 아니라고 생각을 바꾸시길 바랍니다.

Darkcircle의 이미지

더도말고 딱 한가지 말입니다.
OOXML을 직접 써보시긴 했습니까? 아니 써보시려고 했든가 말이죠.

전 어? 이거 떴네? 써볼까? 하다가 복잡해서 접었거든요?
MS가 싫어서가 아닙니다. 전 MS 가 참 잘했다고 생각하는 부분중 하나가 C#의 표준화입니다.
닷넷 프레임워크 이걸 잘했다는게 아니고요. 다른건 둘째치고라도 이 C#을 배우면
C++도 그렇지만 Java도 배우기 쉽고 심지어는 델파이도 어느정도 이해하기 쉬워집니다.
잘한건 잘했다고 박수를 보내야 하겠지만 그래도 못한건 과감하게 따져야죠.

WPF가 사실 OOXML 과는 직접적 연관이 있는건 아니지만
OOXML 기술이 나오기 위해 XML기술로의 구현에 대하여
정당성을 강조하기 위한 기술 중 하나입니다.
지금은 Adobe로 넘어간 Flash를 대체하기 위해
MS가 이제는 프리젠테이션 기술과 애니메이션 기술을
동시에 잡아먹으려고 하고 있습니다.
물론 언급한것중에 빠진게 WPF에는 C#코드가 들어갑니다.
C# 코드는 Flash 에서 액션 스크립 같은 역할을 하죠.
오브젝트 속성 구현 파트는 XML이 되고요.
뭐 pptx같은 문서에서도 오브젝트 속성 구현 파트에 있어서는
XML이 담당을 하고 있죠. OOXML에서도 마찬가집니다.
이거 하나도 빠짐없이 일일히 기입해야
정상적으로 오브젝트 애니메이션이 보여집니다.

뭐 제가 직접 좀 해보다가 복잡해서 접었다면 그렇게 한걸로 아시지
뭐 구구절절이 말씀이 많으십니까? 아, 속된말로 꼬우면 직접 해보시든가...
원.. 참 따질건 잘 따지시는 분이 답답허네... 해보지도 않고 어떻게
짜증난다고 증거를 대보라 하시나... 네 제 자신과 제 친구가 증거입니다. 됐죠?
어쨌든 WPF 둘이서 하다 짜증나서 일단 접었으니...
OOXML은 당연히 손 댈 턱이 없겠고...말 되죠.

밥벌어먹기 위해 어쩔 수 없이 해야 하는 사람과, 이것을 하면
뭔가 돈이 생길 것 같고 업무상 속도라든지 데이터마이닝이라든지
이런 분야에 따른 혁신이 제대로 이뤄질 것이다 ... 라고
생각하며 고민하는 사람의 입장은 다를겁니다.
밥먹어먹기 위해 어쩔 수 없이 해야 하는 사람이라면
나중에 "전문적으로" 알고하는게 결국 그거밖에 없게 되거든요.
그거 안다고 다 아는건 아닐겁니다.

뭐 전 말싸움이고 뭐고 싸움이란 자체를 귀찮아하고 싫어해서 -_- ...

---------------------------------------------------------------
피곤함 1테라톤을 가방 보따리에 주섬주섬 짊어메고 다니는 아이 . . . Orz

---------------------------------------------------------------
폐인이 되자 (/ㅂ/)

김일영의 이미지

설득력이 있다고 생각하시는지 -_-
더 복잡한 표준도 얼마든지 있는데 복잡하다는 것이 표준이 되면 안될 이유라...
여하튼 MS 스스로도 OOXML이 내포한 내용을 '표준' 삼아 MS Office라는 제품을 개발하고 있을테죠.
유사 제품을 만드는 사람들에게는 OOXML이 도움이 되면 되지 나쁠 건 없어 보이는데요.
유사 제품을 만드는 사람 외엔 사실 표준이 되든 안되든 별 상관도 없지 않나요?
단, 예를 들어 한글 처리가 안된다든지 등등의 문제를 일으키지만 않는다면 말이죠.

전반적으로 여기 댓글들을 보니 정말 어떤 조치를 위해서라기보단 그냥 반대 성향을 배출하기 위한 것으로밖에 보이지 않네요.
기술표준원이 찬성표를 던진다는 기사를 인용했는데 거기엔 댓글 하나 없다는 것.
기술표준원이 찬성표를 던진다는 현실에 어떤 대응을 하고 싶은건 아니고 그저 반대의 온라인 배출을 하고 싶은 것 뿐이지 않나요.

여하튼 그것도 자유이긴 한데,
그래도 각자 나름대로 확신할 수 있는 근거는 말 할 수 있어야 엔지니어의 존심을 지키는게 아닐까...
그런 생각입니다.

kslee80의 이미지

channy 님께셔 올리셨던 OOXML 관련 쓰레드에 걸려있는 링크(OOXML 반대 서명 페이지)를 보시면 설명되어 있습니다.
MS 의 독점 우려로 인한 반대 이유들 보다는 더 표준안적인 측면에서의 반대 이유이죠.

그 내용을 보셨음에도 이렇게 글을 쓰시는 거라면,
그 내용을 '~카더라' 라고 생각하신다는 말씀이신데,
그렇다면 그렇게 생각하는 이유에 대해서 말씀하셔야 하는게 아닐까 싶군요.

Necromancer의 이미지

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

Written By the Black Knight of Destruction

Written By the Black Knight of Destruction

linlin의 이미지

그럼 ODF를 표준으로 한다면 MS은 ODF에 대해 어떤 정책을 취할까요? 표준으로 승격되지 못한 OOXML을 이제 priorietary로 돌려서 특허와 라이센스 건 다음 이를 MS 오피스의 시장점유율로 강제한다면 여러분들은 어떻게 할래요? 울며 겨자먹기로 또 MS 오피스 사서 쓸겁니까? 사용자는 어차피 살 오피스 그냥 사면 그만이지만 오피스 소프트웨어 제작업체들은요? MS에 라이센스비 줘야 하지 않나요?

이것보다는 OOXML을 표준으로 인정해 주고 부분적인 스펙이라도 그래도 필요하면 자유롭게 구현할 수 있게 하는 길을 확보하는 것이 현실적인 접근 방법이 될 수 있지 않나요? 물론, 어느 간 큰 업체가 OOXML을 모두 구현하려고 들겠어요? 하지만 MS 오피스로 작성한 문서 파일을 반드시 MS를 통하지 않고도 이용할 수 있는 길이 열리는 게 OOXML의 표준 제정 아니겠어요? 반대자들이 MS의 특허 문제를 중요하게 거론하는 것도 그런 이유에서일테구요.

어차피 OOXML은 오피스 최신버젼이 많이 쓰이게 되면 자동적으로 de facto standard가 될 수 밖에 없습니다. 아무리 ODF가 기능상 뛰어나고 표준으로 지정되더라도 세상에는 아무도 안쓰는 표준도 많죠. ODF를 그런 표준으로 만들고 싶은가요?

표준에서 "많이 쓰인다"는 문제는 기술적인 장점을 한참 능가하는 중요성을 갖고 있습니다. 많이 쓰이지만 떨어지는 기술과 우수하지만 많이 쓰이지 않는 기술을 대비하면 사용자 베이스가 넓은 놈이 당연히 이깁니다. 이걸 무시하면 절대 세상이 바뀌지 않습니다. 기술적으로 따지면 왜 리눅스가 여전히 윈도우를 축출하지 못하며 왜 맥오에스텐이 세상을 점령하지 못하나요?

imyejin의 이미지

상용으로 라이센스 돈 받아 먹으라고 하고요. M$도 그게 더 이익이면 굳이 표준으로 만들려고 하지도 않을 겁니다. OOXML 지금대로 표준으로 밀어붙이는 게 M$계산에 훨씬 이익이 되니 그런 것 뿐입니다.

아니면 OOXML 스펙을 간소화하고 문제점을 정리해서 말이 되게 한 다음에 M$도 구현을 고칠 건 고치던가요. 표준이란 게 어차피 부분적으로밖에 구현이 안된다면 그건 표준 제정 자체가 잘못된 거죠. 그렇다면 뺄 거 빼고 그 중 일부분만을 표준으로 정해야 하는 겁니다. 무슨 제대로 검토도 안되는 건 표준이라고 제정하려는지 linlin 님은 표준이란 단어 뜻을 다시 한번 사전에서 찾아보시기 바랍니다.

지금 세상을 모두 M$에 기준에 맞춰줘야 잘 살 수 있다는 말씀을 하시려는 건가요?
빠돌이도 이렇게 심한 M$ 빠돌이는 처음 보는군요.

그럼 윈도우즈 XP도 많이 쓰니 우리 아예 개인용 OS 표준으로 XP풀 스펙을 ISO 표준으로 정해야겠군요?

이게 지금 말이 된다고 생각하는 건지 ...
아무래도 일부러 낚시한다는 느낌이 듭니다.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

linlin의 이미지

아니뭐 MS좋은 얘기 좀 쓰면 이동네에서는 MS 빠돌이 소리 듣나봐요?

MS가 자사의 오피스에 가장 이익이 되는 방향으로 OOXML 표준 자체를 미는 것이 뭐가 나쁜가요? 기업이 자선단체도 아니고 그럼 경쟁사들의 제품에 도움이 되는 방향으로 OOXML 표준을 만들까요?

OOXML이 맘에 안든다면 OOXML이외의 대안을 밀어야지 OOXML스펙을 간소화하고 어쩌고.. 이런건 님 같은 사람들 개인 의견일 따름입니다. MS가 신경 쓸 건 투표에서 통과할 정도까지 반대표의 의견을 신경 써 주면 되는 겁니다. 그래서 MS가 님 마음대로 안움직인다고 M$는 악당이 되는 건가요?

또한 현재의 실질적 표준은 MS의 doc 파일과 xls 파일 포맷이에요. OOXML이 이들 파일과의 proprietary 호환성을 신경을 쓴다면 사용자 입장에서는 doc에서 OOXML로의 이주가 쉬울 수도 있습니다. 이게 바람직하나요 아니면 MS 오피스 2007용 새로운 doc 포맷으로의 이전이 바람직하나요?

이미 MS가 현재의 오피스 시장 점유율을 갖고 있다는 것은 프리미엄으로 인정해줘야 합니다. 그 머리가 안돌아가면 ODF니 오픈오피스니 뭐니 MS 오피스의 독점을 깨기는 어렵습니다.

imyejin의 이미지

이제 많이 낚으셨으니 다른 걸루 낚으세효 ㄱㅅ

@ 표준 제정이라는 게 위원회를 구성해 찬찬하고 세밀하게 검토하여 따져 볼 것은 따져 보고 고칠 것을 고치는 과정을 거쳐야 한다는 기본적인 과정 자체에 대한 이해가 부족하군요.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

linlin의 이미지

낚긴 뭘 낚습니까... 님이야말로 누군지 모르지만 그 여자 사진으로 맨날 사람들 낚고 있는 거 아니에요?

표준 제정이 위원회를 통해 만들면 에브리바디 다 따라갈 것이라고 믿는 그 개념부터 좀 바꿔야 하지 않을까 싶네요. 도데체 리눅스 쓰는 사람 맞습니까? RFC 프로세스부터 다시 보고 와요.

MasterQ의 이미지

감정적으로 접근하시네요. linlin님께서는 객관적으로 득실을 따지는 반면에 imyejin님은 MS가 OOXML에 표준으로 채택되면 무조건 라이센스를 통해서 돈벌이에 쓸 목적으로 추진한다고 생각하시는것 같습니다. MS는 여러번에 걸쳐서 이번 표준이 채택 되더라도 특허권을 강제하지 않겠다고 얘기하였습니다. 참고로 저는 중간적인 입장을 가지고 있습니다만 linlin님의 말대로 많은 분들과 다른 의견을 제시하면 일단 색안경을 끼고 보는 자세에는 문제가 있다고 봅니다.

lain07의 이미지

이런 거 아닌가요..
지금까지 많이 쓰니까 그냥 쓰자.는 식의 주장인 것 같은데
공정위의 저번 결정과 매우 부합하는 의견인데, 혹시 공정위에서 파견나오신 분은 아닌가요?

___________________________
I like Small Linux.


___________________________
I like Small Linux.

segfault의 이미지

이미 OOXML은 Ecma 376 표준입니다. ISO 표준으로 승격되지 못했다고 바로 proprietary로 전환하지는 못할 것입니다. 괜한 걱정을 하시는 것 같군요.

----
http://www.planetmono.org

linlin의 이미지

그래서 특허 문제를 거론하는거 아니에요? 특허는 기술을 공개하면서 동시에 시장 독점권을 보장받는 확실한 방법 아니겠어요.

Darkcircle의 이미지

특허랑 표준화는 별개의 문젭니다.
특허는 "독점권"에 있어 우위를 점하는 것이고
표준은 "우선권"에 있어 우위를 점하는 것입니다.

즉, 표준에 따라서는 "먼저 제대로 더 많이"
만들어 파는 사람이 돈을 더 많이 법니다.
단어의 우선권은 먼저 > 제대로 > 더 많이 죠.

특허에 대해선 먼저 만들던 나중에 만들던
"특허권"만 따내면 다른 기업체나 다른 생산자가
해당 기술을 구현하지 못하니 그냥 앉아서도 돈이 벌리구요.
혼자서만 열심히 만들어 팔고 아무개는 팔지 못하게 막는
"독점행위"도 특허권에 의해 합법화됩니다.
본래 "독과점"행위 자체가 헌법에 위반되는 것이지만
이 맹점을 이용해먹기 위해 "특허"라는게 존재하고 "특허법"을 만들어 이용해먹죠.
음... 뭐랄까... 사실 "특허"란게 본래 존재 목적이
"개인의 지적 재산을 보호"하기 위해 만든것인데
이게 좀 아이러니하죠.

어쩌면 특허법 존재 자체가 모순일지도 모르겠습니다. -_-

아 근데 얘기가 어딜로 어떻게 흘렀길래 이젠 인당수 뱃머리까지 왔을까...

p.s. 아... 말이 빠졌습니다. 표준은 (보편타당성에 따른)"우선권"에 의해 결정된다
라고 보는 것이 맞습니다. 수정합니다. 쩝...
그리고 중요한게... 일단 표준은 대다수의 지식인, 기술자들의 찬성 입장이 반영되는 것이고
표준이 되기 위한 기술적 보편성이 검증되어야 합니다.

---------------------------------------------------------------
피곤함 1테라톤을 가방 보따리에 주섬주섬 짊어메고 다니는 아이 . . . Orz

---------------------------------------------------------------
폐인이 되자 (/ㅂ/)

linlin의 이미지

잘못 이해하고 있는 것 아닌가요? 표준은 공개되어 있지만 예를들어 그 표준의 구현 측면에서 MS가 적절한 특허권을 가지고 시장 독점력을 행사하는 것과 같은 가능성을 얘기하는 겁니다. 가상의 예를들어, 공개키 알고리듬과 같은 유용한 기술을 MS가 개발해서 사회에 공짜로 공개했다고 칩시다. 그런데 MS가 이 공개키 알고리듬을 윈도우즈에 구현하는 방법을 어떻게 재주껏 특허를 취득했다고 칩시다. 그러면 실질적으로 MS가 공개키 알고리듬을 public domain으로 공개한 것 같지만 이 기술을 윈도우에서 싸야 하는 기업들은 MS에 특허료를 지불할 수 밖에 없고 MS의 시장 독점을 용인할 수 밖에 없습니다. 이를 막는 쉬운 방법은 아예 처음부터 MS로 하여금 우리 회사는 공개키 알고리듬과 관련한 어떠한 특허도 포기한다고 선언하도록 하는 것이죠.

ddoman의 이미지

궁금한 것이 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에 대한 반대이유가 되는것에선 의문을 갖습니다.

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

kyagrd의 이미지

오히려 그 반대입니다. 지나치게 상세하고 분량이 방대해서 문제입니다.
심지어 버그 호환성이라든가, 그냥 M$ 오피스의 풀 스펙을 그냥 기술하다시피 했다는 게 표준 제정의 가장 문제가 되고 있습니다.
그래서 현실적으로 표준을 제대로 지키는 구현은 이미 다 만들어 놓은 M$ 말고 대체 누가 할 수 있겠냐는 이야기가 나오는 겁니다.

--
There's nothing so practical as a good theory. - Kurt Lewin

--
There's nothing so practical as a good theory. - Kurt Lewin
"하스켈로 배우는 프로그래밍" http://pl.pusan.ac.kr/~haskell/

linlin의 이미지

그런데 이쯤되면 ODF의 장점이 상대적으로 부각되면서 OOXML의 대안으로 뜰만도 한데... 왜 ODF가 이 면에서 확고한 위치를 못 잡고 있는지 궁금하네요. ODF의 낮은 시장 점유율 문제말고 어떤 문제가 있나요?

지리즈의 이미지

단지 MS가 싫어 해서 문제죠.
왜냐하면 ODF로 경쟁하면 MS가 다른 후발업체들하고
동일선상에서 경쟁해야 하니까요.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

warpdory의 이미지

현실적으로 쓰이고 있는 오피스제품의 80% 이상을 차지하고 있는 MS Office 에서 odf 를 지원하지 않기 때문이겠지요.

사실 .. 저같은 end user 관점에서는 ooxml 이든 odf 든 hwp 든 뭐든 빨리 표준이 정리되고, 그것에 맞는 애플리케이션들이 나와서 문서 호환성이나 높아졌으면 좋겠습니다.

이거 뭐 문서 한번 취합해서 정리하려면 hwp, gul, doc 은 기본이고, 가끔 러시아 같은 데서는 팔란티어 워드로 된 걸 보내질 않나 -_-

---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.
http://akpil.egloos.com


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

체스맨의 이미지

저도 ooxml 반대 서명은 했습니다만...

정치적인 또는 기득권을 위한 견해 말고, 기술적으로 지적되는 포괄적인 문제나, 개별적이고 구체적인 문제점들이 해결된다면, ooxml 을 또 하나의 표준으로 하는데 문제가 없다고 생각합니다. 양이 많고 적음이 문제가 아니라, 그 문서를 따라 구현을 하면, 해석의 모호함이나 특허 같은 법적 문제 없이, 어떠한 플렛폼에서든 ( 해당 플렛폼의 한계 문제가 아니라면 ), 상호 운용이 가능한 응용 프로그램을 만들 수 있더라 하면 되는 문제라고 보니까요. 아무튼 지금 올라오는 뉴스 기사 및 관련 문건들로 판단하건데, 이 부분은 아직 ooxml 이 충족하지 못하고 있다고 판단하고 있고, 그래서 반대 서명을 했습니다.

특히 특허 문제 관련해서는 소송하지 않겠다와 같이 말을 흘리는 것보다는 공증된 문서, 또는 특허 포기가 필요하겠지요. 그런 것 없이 말로 넘어갈 수는 없는 일입니다.

ooxml 이 채택되어, MS 가 반사 이득을 보는 것에 대한 비판은 사실 별로 의미가 없는 것이라는 생각이 드네요. 어차피 이 문제의 중심에 있는 관계자들은, 기술적인 문제도 중요하지만, 결국은 자기 자신의 이득을 위해 움직이는 사람들이 핵심에 서 있을테니까요. 누가 이기든, 어느 한 쪽은 이익을 보게 돼 있습니다.

저 개인적으로는, 대안 표준이라 여겨지는 ODF 가 있는 것에 대해서는 크게 개의치 않습니다. 단지 이 문제에서는 ooxml 이 '표준'의 목적에 부합하고 있는지, 그렇지 않은지만 관심 있을 뿐이죠...

그리고, 위 의견 중에는 '표준'을 정립하는 목적을 확립하지 못한채 많이 쓰여서 표준이 되어야 한다던가, 이해하기 어려운 의견들을 내세우는 경우가 있는데, 우선 imyejin 님께서 원 발제글에 링크하신 두번째 문서에서 표준을 정립하는 목적을 읽어보신 다음 토론을 하셨으면 합니다.

Orion Project : http://orionids.org

지리즈의 이미지

충분한 반대 이유가 될 수 있는 것은 그간의 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.

There is no spoon. Neo from the Matrix 1999.

chungsy02의 이미지

사람들이 MS Office를 쓰는 이유는 office 프로그램 자체가 잘 짜여진 것도 있겠지만
다른 사람들이, 기업과 정부 기관이 MS Office를 사용하기 때문입니다.
기업과 정부기관이 MS Office를 사용하는 이유는 역시 사람들이 많이 사용하는 포멧이기 때문이죠.
이러한 독점적인 포멧의 악순환을 막기 위한 것이 공개된 표준을 정하는 것입니다.

이미 독점적인 시장 지위를 가진 회사는 표준이 존재하지 않는 것이 이익이 됩니다.
이러한 예는 웹브라우저 시장에도 나타납니다.
제가 가는 몇몇 사이트들은 IE에서만 제대로 보이기 때문에 결국은 IE를 사용할 수 밖에 없도록 합니다.
만약 제 컴퓨터에서 기술적으로 IE를 지울 수 있더라도 저는 그 사이트들을 가기 위해서 IE를 지울 수 없습니다.
MS는 원래 존재하던 표준을 약간 흐트려 놓음으로서 Firefox나 Safari로 고객들이 옮겨 가는 것을 막은 것입니다.
Firefox나 Safari에서만 잘 보이는 웹페이지가 없다는 것을 생각하면 이해가 빠를 것입니다.

각각의 office 프로그램에서 표준 문서가 약간씩만 다르게 보인다면 표준은 의미가 없어집니다.
OpenOffice와 Thinkfree Office는 라이센스를 통해 MS Office 문서를 지원하지만
'완전히' 똑같이 보이지 않기 때문에 절대 MS Office의 대체품이 될 수 없습니다.
OpenOffice에서 작성한 ppt 파일의 제목을 한 줄이 되도록 딱 맞춰놨는데
MS Office에서는 한 단어가 아래로 내려가기만 해도
OpenOffice에서 작성한 ppt파일을 갖고 학회에 프리젠테이션을 하러 갈 수 없습니다.
역시 E-mail로 누군가에게 파일을 보내 주는 것도 포기해야 합니다.

OOXML파일 역시 정확한 구현이 불가능해서 각각의 office 프로그램 마다 약간씩 다르게 보이기만 한다면
역시 우리는 MS Office를 쓸 수 밖에 없습니다.

왜 MS만 갖고 그러냐고 물으신다면
저는 '과점 시장을 이용해 밀가루값 오를때 과자 값 올리고 밀가루값내릴때는 과자 값 안 내리는 회사도 싫어하고,
과점 시장을 이용해 원가가 0에 가까운 문자메시지를 수십원씩 받는 회사도 싫어한다'고 대답하겠습니다.
거꾸로 묻겠습니다. 왜 제과회사와 이동통신사는 안 그런데 MS의 독점적 지위는 보호받아야 합니까?

김일영의 이미지

상관없는 일이라고 생각이 되는군요.
MS Office가 파일 포맷을 공개해서 독점이 강화된다? 말의 연결이 안되는군요.

linlin의 이미지

그런데... 이것이 예를들어 ODF 표준으로는 해결 가능한 일인지요? 오히려 ODF는 OOXML과는 달리거꾸로 스펙이 충분히 구체적이지 않아서 문제라는 것 같던데 그렇다면 ODF나 OOXML 모두 같은 문서라도 어플리케이션에 따라 "약간은" 다르게 보일 수 있는 가능성을 배제할 수 없는 것은 아닌가요? 같은 HTML페이지라도 브라우저마다 조금씩은 다르게 보이듯이 말입니다. 예를들어, 같은 표준을 준수해도 Safai와 firefox는 페이지를 약간은 다르게 디스플레이되쟎아요.

imyejin의 이미지

일부(어쩌면 상당히 많은?) 웹페이지에서 용도에 벗어나게 남용을 하고 있어서 그렇지,
원래 HTML 자체는 픽셀 단위로 정확한 레이아웃을 맞추려고 만든 언어가 아닙니다.
인쇄용 출력을 얻으려면 PS나 PDF같은 용도에 맞는 언어록 기술하는 것이 바람직합니다.
따라서 웹브라우저의 경우 어느 정도 다르게 보이더라도 둘 다 표준을 준수한다면 당연히 문제가 되지 않습니다.
(CSS 준수에 관해서라면 이야기가 좀 달라지겠습니다만요.)

하지만 ODF와 같은 도큐먼트 포맷의 경우, 특히나 프리젠테이션으로 활용하거나 하는 경우에는
이미 그 기능 자체가 상당히 세세한 페이지 레이아웃의 정확성을 요구하므로 HTML과는 용도 자체가 다르죠.

ODF가 스펙이 구체적이지 않다는 이야기가 무슨 뜻으로 하시는 말씀인지 모르겠지만,
확장성이 있다는 뜻이라면 그건 건 맞는 것 같은데, 페이지 레이아웃에 대한 스펙이
구체적이지 않은 부분이 있다는 건 아직 못들어봤거든요.
정확히 무슨 뜻으로 하시는 말씀인가요?

좀더 논점을 명확히 해 주셨으면 합니다.
만일 ODF 페이지 레이아웃에 모호한 부분이 있다면 그건 개선해야 할 문제가 될 것입니다.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

linlin의 이미지

ODF 표준을 각기 다른 회사의 어플리케이션에서 구현했을 때에도 충분한 완성도의 문서 호환성을 제공할 수 있는가의 여부가 궁금하다는 얘기입니다. 현재 실질적으로 ODF를 제대로 지원하고 있는 오피스는 오픈오피스밖에 없어요. 같은 MS 오피스로 만든 파일이라도 맥용 오피스에서 읽을 때와 윈도우용 오피스에서 읽을 때 약간의 차이가 나는 경우가 의외로 많아요. 즉, 오피스 문서 규격은 원래 특성 자체가 아주 세세한 곳까지 신경을 써야 하는 복잡한 표준이 아닌가 하는 점이죠.

만약에 님도 얘기하듯이 오피스 문서 규격이 세세한 부분까지 정확도를 요구하는 특성이 있다면 여기서 소위 600페이지밖에 안된다는 ODF규격에 비해 6000여 페이지에 달하는 OOXML 규격은 오히려 실제 어플리케이션 개발 측면에서는 실제 오피스 어플 개발에 충분한 기능을 제공하고 있기 때문에 분량이 커진 것이 아닌가 하는 의문을 가져볼 필요가 있습니다. 물론, MS가 자사 오피스 파일과의 호환성을 이유로 쓸데없이 집어넣은 스펙들은 제 3자의 입장에서는 당연히 짜증나겠지요. 하지만 그런 부분을 제외했을 때 과연 ODF가 OOXML에 비해 현업에 충분한 기능을 제공해 주고 있는 것인가요? 잠깐 ODF의 문제점을 구글링해봐도 여기에 대해서는 별다른 논의가 나오지 않아요. 반대로 ODF의 문제점에 대해서는 꾸준히 기능의 OOXML 대비 미흡함과 규격이 포괄적이라는 지적이 나오네요. 몇가지만 링크 붙여보죠.

http://en.wikipedia.org/wiki/OpenDocument#Criticism
http://rukxer.net/2460567
http://www.zdnet.co.kr/news/enterprise/etc/0,39031164,39162860,00.htm

지리즈의 이미지

어떤 표준이던 미흡한 점은 지속적으로 개정판이 나오면서 확장해 나가는 거죠.
프로토콜이던 표준이던 다 버전있는 것이 그 이유때문입니다.

OOXML이 ODF보다 세세하다고 해서,
ODF의 미흡한 점을 개선한 발전된 형태인가 하면 그렇게 말할 수 없습니다.

OOXML은 MS오피스가 진화해 온 발자취를 그대로 담고 있습니다.
즉, 처음부터 MS오피스의 최신 버전의 포멧을 목표로 발전해 온 것이 아니라,
매버전이 나올 때 마다 주먹구구식으로 기능이 첨가되어온 형태입니다.
코드로 이야기를 들면, 예외처리 상황이 발생했을 때,
if문 하나씩 추가하는 adhoc 스파게티 코드 같다는 이야기죠.

이런 식의 코드는 상세하고 구체적이긴 하지만,
유연성이 떨어지는 사상누각과 같습니다.

개체지향기술에 능숙한 경험많은 개발자들의 시각에서 보면 쓰레기일 뿐입니다.
당장 현실에서는 사용가능할지 몰라도 장기적인 안목에서 보았을 때는
발전방향도 없고, 언제가는 한번은 전체적으로 다 갈아엎을 필요가 있는 잔재일 뿐이죠.

물론 OOXML 모든 부분이 다 이런 것은 아닙니다.
큰 줄기자체는 유연하고 좋죠. 어쩌면 ODF 보다 나을 수 있습니다.
다만,줄기에 주렁주렁 달려 있는 쓰레기 때문에 악취날 뿐입니다.

그럼, 이런 쓰레기를 걷어 내면 될까요?
아마 2000페이지 정도 어쩌면 더 작은 수준으로 줄어들 수도 있을 겁니다.
그런데, 이렇게 줄면 사실 ODF와 큰 차이도 없어집니다.
플러그인 형태가 아니라, 프레임자체에서 서로 상호 호환될 수 있을 정도 유사해집니다.

그럼, OOXML을 굳이 표준으로 인정할 필요도 없어지고,
차라리 ODF를 개선하는 편이 더 빠르고 낫습니다.

절대로 MS가 쓰레기를 걷어 내는 것을 허용할 수는 없겠죠.
이런 쓰레기 덕뿐에 기존의 MS의 문서포멧들이 표준양식으로 인정받을 수 있거니와,
이 쓰레기들이 어쩌면 ODF와의 유일한 차이일 수도 있으니까요.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

linlin의 이미지

하지만 그것이 사용자의 입장에서는 MS 오피스 구버전과의 호환성 증대라는 측면에서 중요할 수도 있습니다. 따라서 MS가 이런 "스파게티 쓰레기 부분"을 표준으로 미는 것 자체를 claim 걸기는 무리수가 있지 않나 싶네요. 하위 호환성은 개발자에게는 피곤한 일이지만 사용자에게 이득이 될 수 있는 기능이니까요. 또한 ODF가 충분히 개선 가능성이 높다고 한다면 ODF 표준의 개선 작업은 OOXML의 표준 채택 여부와는 별개로 진행될 수 있는 사안입니다.

지리즈의 이미지

그러나 개발을 하다보면 하위 호환이 발목을 잡는 걸림돌이 되어서
나중에 시스템 전체가 엉망이 되는 일도 있습니다.
결국 어느 시점에는 이 하위을 포기해야 할 때가 있습니다.

사실 ODF가 ISO 표준을 인증받고,
관공서에서 이를 수용하기 시작한 시점은 이러한 것을 감수한 것이죠.

표준이라는 것은 앞으로 5~6년 쓰려고 만드는 것이 아닙니다.
50년 아니 100년 뒤에도 사용할 수 있어야 하는 거죠.

개발자들에게만 피곤일이 아닙니다.
이러한 유연성 부족이 지금 당장은 알 수 없지만,
전세계를 패닉으로 몰아 넣었던 y2k 문제처럼
심각해지지 말라는 보장이 없습니다.

예.. ODF 나름대로 발전할 가능성도 있어요.
그러나 제품의 표준으로서 가치는 없어진 것이죠.
사용자 입장에서는 장기적인 방향이나 안목이라는 것은 중요하지 않거든요.

사용하지도 않는 ODF가 이상적으로 발전할 동안,
경쟁자가 없어진 MS를 누가 견제하느냐 이거죠.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

alisol의 이미지

ooxml 이 표준으로 제정되지 않으면 독점이 해결될 것이라고 주장하는 글이 아니고, 그렇지 않아도 독점인데 더 심해질 것이다. 를 말하는 글이 아닐까요.

2012 세계협동조합의 해. http://social.un.org/coopsyear/
(사)한국협동조합연구소 - http://www.coops.or.kr/

협동조합 7원칙

1) 자발적, 개방적 조합원 제도 2) 민주적 관리 원칙 3) 조합원 경제 참여 원칙 4) 자율, 독립의 원칙 5) 교육, 훈련, 정보 제공의 원칙 6) 협동조합 간의 협동의 원칙 7) 지역사회에 대한 기여

Ubuntu 10.04 LTS

체스맨의 이미지

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

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

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

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

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

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

Orion Project : http://orionids.org

JuEUS-U의 이미지

Quote:
그것을 기술적인 문제 이외로 반대하는 것에 대해서는 저는 아니라고 생각하는 것입니다.

물론 그렇게 되야겠지만,,,
MS가 정치적으로 나왔기 때문에, 결국엔 그 쪽으로 대화가 퍼지는 듯 싶네요.
지리즈의 이미지

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

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

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

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

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

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

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

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

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

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

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

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

바라미의 이미지

제가 배우기로는 표준은 '공공'의 이익을 위해서 제정하는 걸로 알고 있습니다.

공곡의 이익을 위해 서로간의 성호작용성과, 소통을 위해서 열려있는 하나의 방침이 표준이라고 알고 있는데요.
여기서, MS의 포맷들이 de facto standard 가 될지언정, 정식 국제 표준이 될 수 없는 이유가, 열려있지 않다는 겁니다.

현재 OOXML이 어떻게 되어있는지는 잘 모르겠으나, 만약 OOXML의 일부분이라도, 열려있지 않고, 닫혀 있어,
그 누구도 구현을 할 수 없다면, 그건 국제 표준이 될수가 없죠. 말그대로 de facto standard이지요..

표준이 되면 어떠한 부분이라도 정확한 스펙을 공개해야 합니다. 하지만, 만약 비공개되어있는 부분에 의존하고 있는 부분이 조금이라도 있다면,
그 부분은 공공의 이익을 추구하는 것이 아니라, 사기업의 이익을 추구하기 위한 것이 되기에, 표준이 되서는 안된다고 하는 거지요.

말그대로 '표준'의 정의부터 생각해 봐야 될꺼죠..

그렇다면 de facto standard 와 de jure standard 를 구분할 필요가 없는거죠.

hexagon의 이미지

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

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

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

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

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

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

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

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

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

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

channy의 이미지

ECMA에서 작년 한국측 반대 코멘트를 거의 받아들이기로 한 문서로 인해 찬성입장으로 바꾸었다고 합니다.
솔직히 서명운동이 찬성 명분을 준 것이 아닌가 걱정이되기도 하는데... 바꾼다니 지켜봐야죠.
어느 수준 까지 바꿀지 믿음이 안가는데, 과거에 그랬다고 미래도 못 믿어준다는 건 너무 가혹하니 한번 믿어 보렵니다.

-----
기표원, MS 오픈XML 국제표준 지정 `찬성`

...기술표준원은 "산·학·연 관련 전문가 13명으로 구성된 전문위원회가 27일 저녁 투표를 통해 9 대 4로 찬성을 확정했다"며 "국제표준을 제안한 주체인 유럽컴퓨터제조사협회(ECMA)가 한국 측이 지난해 제시했던 요구 사안을 대부분 수용하겠다는 방침을 문서로 제출한 것이 확인된 것이 결정적 배경이 됐다"고 밝혔다....

http://media.daum.net/digital/others/view.html?cateid=100031&newsid=20080328095109043&cp=etimesi

Channy Yun

Mozilla Korean Project
http://www.mozilla.or.kr

Channy Yun

Mozilla Korean Project
http://www.mozilla.or.kr

지리즈의 이미지

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

AC/DC Highway To Hell

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

lain07의 이미지

문제가 생각보다 더 심각하다는 걸 깨닫게 되었습니다.

그런데 의문점 하나.

왜 지리즈님의 글과 비교되서, linlin'님'의 글은 설득력이 너무나도 부족한걸까요?
___________________________
I like Small Linux.


___________________________
I like Small Linux.

linlin의 이미지

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

어쨌든 그렇다면 줄여서 이슈는 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와의 경쟁을 유도하는 쪽으로 전략을 미는 것이 충분한 대안이 될 수 있다고 봅니다.

지리즈의 이미지

하나는 빨간불에 건너고, 다른 하나는 파란불에 건넙니다.

여기서도 누차 언급된바가 있지만,
두 가지 표준이 가지는 문제점은 위와 같은 것이고,
이것 저것 있어서 좋은게 절대 아닙니다.

표준을 정하는 이유는 표준을 준수했을 때
그것이 언제나 그것이 통한다는 것을 보증하는 것입니다.
만약 두가지 표준이 있으면 내가 하나의 표준을 따랐을때
다른 한쪽의 표준을 따르는 사람과 충돌하게 됩니다.

이러면 표준의 존재 의미가 없는거죠. -_-;;

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

linlin의 이미지

ODF와 OOXML의 관계는 하나를 쓰면 다른 하나를 쓰지 못하는 서로 대립되는 관계가 아닙니다. 도로에 비유하자면 한국에서는 차가 도로의 우측으로 달리지만 일본에서는 왼쪽으로 달리는 것에 가깝다고 봅니다. 물론, 한국에서 운전하던 사람이 일본으로 가면 적응기간이 걸릴 것이고, 자동차 수출 업체들은 핸들을 왼쪽에 설치할지 오른쪽에 설치할 지 고민해야 할겁니다. 하지만 이 정도의 비용은 충분히 감당할만하고 양 나라가 다른 표준을 갖고 있어도 충분히 interoperable 합니다.

마찬가지입니다. 실제 ODF를 쓰려면 사용자들은 오픈 오피스 패키지를 써야 하고 OOXML을 쓰려면 MS 오피스를 써야 하는 상황입니다. 따라서 오픈오피스에서 OOXML 문서를 충분히 다룰 수 있고 MS오피스에서 ODF를 충분히 다룰 수 있는 환경을 만드는 것이 현실적인 접근 방법이라고 봅니다.

지리즈의 이미지

관공서들이 표준인 ODF를 문서 포멧으로 정했기 때문입니다.

OOXML이 표준이 된 마당에 우위에 서 있는 MS가
자신의 경쟁상대인 ODF 포멧을 지원할 필요가 있습니까?

그리고, OOXML과 ODF의 거리가
일본과 한국의 거리 차이인가 입니다.
OOXML과 ODF 이 둘은 아주 밀접하게 붙어 있습니다.
한국내에 왼쪽으로 주행해도 되고, 오른주행도 되는 것과 같은 것이지,
일본에서는 왼쪽, 한국에서는 오른쪽 이런 거리가 존재하는 것이 아닙니다.

이를 테면, 재정부에서는 ODF를 쓰고, 금관원에서는 OOXML을 쓰는 것인데,
그럼 이 두 조직이 원할하게 의사결정이 진행될 수 있을까요?

그리고, 솔직히 이중적인 비용을 소모해가면서 두가지 표준을
모두 사용할 만큼 OOXML이 가치가 있는가?

제가 볼때는 아니라고 봅니다.

차라리, ODF를 표준에 누락시키고
OOXML만 표준을 제정하는 것이 더 바람직할 수도 있습니다.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

linlin의 이미지

OOXML이 표준이든 아니든간에 MS가 자신의 경쟁상대인 ODF 표준을 지원하지 않는 것을 claim할 수 있습니까?

또한 MS가 오피스에서 ODF 표준을 전혀 지원하지 않는다고 했을때 경쟁사인 아이비엠이나 썬에서 대응 방법이 전혀 없습니까? OOXML 표준이 공개되어 있다면 자사 제품에 OOXML 지원 기능을 넣어 MS의 사용자들을 흡수하고 ODF 파일을 퍼뜨려 MS 오피스 사용자들이 불편을 체감하게 할 일입니다. OOXML 표준을 MS가 공개하지 않는다면 마찬가지로 ODF만 지원하면 됩니다. 물론, 후자가 시장 점유율 때문에 아이비엠이나 썬에게는 불리하겠지요. 그런데 지금 전개되는 상황은 후자쪽은 선택지가 없어졌지 않습니까?

그리고 재경부와 금감원은 ODF나 OOXML 둘 중 하나를 선택할 일입니다. 이것까지 걱정해 주는 것은 지나치게 친절한 거에요. 그런데 이런 건 자유롭게 선택하도록 하더라도 둘 중 하나로 선택이 수렴하게 되어 있습니다. Battle of sex를 생각하면 쉽게 예측할 수 있겠죠. 남자 여자 데이트를 하는데 남자는 축구가 좋고 여자는 영화보는게 좋습니다. 둘 다 같이 가면 만족도가 높지만 각자 행동하면 만족도가 낮아지죠. 이 경우는 자연스럽게 둘의 결정이 축구 혹은 영화 하나로 통일이 됩니다.

ODF를 포기하고 OOXML만을 단수 표준으로 제정하는 것도 바람직해 보일 수 있습니다만 그렇다면 이럴 때 MS의 마켓파워 문제는 어떻게 해결할 수 있나요? ODF 단수 표준에 MS가 표준 물타기를 하는 것과 비슷한 위험이 발생하지 않을까요?

지리즈의 이미지

"OOXML이 표준이든 아니든간에 MS가 자신의 경쟁상대인 ODF 표준을 지원하지 않는 것을 claim할 수 있습니까?"

없습니다. 사실 그럴 필요도 없어요.
왜냐하면 ODF만 표준일 경우 관공서에서
ODF 표준을 지원하지 않은 MS 오피스는 관공서에서 쓰지 않을 것이기 때문입니다.
이러한 현상이 확산되면 누가 손해인지 손익계산을 해보세요.

"또한 MS가 오피스에서 ODF 표준을 전혀 지원하지 않는다고 했을때
경쟁사인 아이비엠이나 썬에서 대응 방법이 전혀 없습니까?"

없죠. 순수하게 사용자들이 선택할 부분입니다.

"OOXML 표준이 공개되어 있다면 자사 제품에 OOXML 지원 기능을 넣어 MS의 사용자들을 흡수하고 ODF 파일을 퍼뜨려 MS 오피스 사용자들이 불편을 체감하게 할 일입니다. OOXML 표준을 MS가 공개하지 않는다면 마찬가지로 ODF만 지원하면 됩니다. 물론, 후자가 시장 점유율 때문에 아이비엠이나 썬에게는 불리하겠지요. 그런데 지금 전개되는 상황은 후자쪽은 선택지가 없어졌지 않습니까?"

OOXML이 한두페이지라 누구나 뚝딱 만들 수 있는 것이면 맞는 말입니다.
저 스팩은 아무리 숙련된 기술자를 많이 가진 대기업조차 만들기 힘든 것입니다.
왜 오늘날 MS 오피스가 시장을 장악했는지 생각해 보세요.
저 스팩을 완벽히 구현할 수 있는 회사는 MS밖에 없습니다.
더 큰 문제는 이미 시장에 나왔있다는 점이죠.

"그리고 재경부와 금감원은 ODF나 OOXML 둘 중 하나를 선택할 일입니다. 이것까지 걱정해 주는 것은 지나치게 친절한 거에요. 그런데 이런 건 자유롭게 선택하도록 하더라도 둘 중 하나로 선택이 수렴하게 되어 있습니다. Battle of sex를 생각하면 쉽게 예측할 수 있겠죠. 남자 여자 데이트를 하는데 남자는 축구가 좋고 여자는 영화보는게 좋습니다. 둘 다 같이 가면 만족도가 높지만 각자 행동하면 만족도가 낮아지죠. 이 경우는 자연스럽게 둘의 결정이 축구 혹은 영화 하나로 통일이 됩니다.

ODF를 포기하고 OOXML만을 단수 표준으로 제정하는 것도 바람직해 보일 수 있습니다만 그렇다면 이럴 때 MS의 마켓파워 문제는 어떻게 해결할 수 있나요? ODF 단수 표준에 MS가 표준 물타기를 하는 것과 비슷한 위험이 발생하지 않을까요?"

OOXML이 표준으로 인정되면 ODF는 시장에서 살아 남을 수 없습니다.
서로 상반된 표준이 있을 경우 당연히 기반이 넓은 쪽은 선택하는 것이 순리이기 때문이죠.

이제 막 시작한 ODF가 OOXML에 대해서 유일한 가진 강점이 ISO 표준이었다는 점 뿐입니다.

이제는 MS의 마켓파워에 날개를 달아 준 셈이죠.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

linlin의 이미지

OOXML을 완벽히 구현해야 한다는 시각을 좀 바꾸어 볼 필요는 없나요? 그리고 과연 사용자들이 MS 오피스를 선택하는 주 이유가 OOXML을 완벽히 구현하기 때문인가요? 그렇지 않습니다. 적절한 수준의 호환이면 충분하고 사용자 누구도 MS 경쟁사의 제품을 쓰면서 MS 제품 수준의 완벽한 호환성을 기대하지 않습니다.

또한 MS 오피스 밖에 완벽한 OOXML 구현이 안되고 다른 회사는 OOXML에 손도 못댄다고 합시다. 어차피 그정도로 개발 비용이 많이 든다면 MS의 경쟁사들은 다들 ODF 쓰지 OOXML은 애초부터 포기하기 마련입니다. 매킨토시가 소수지만 임계점을 넘긴 시장점유율로 윈도우와 호환성이 없어도 생존에 문제가 없는 것 처럼 MS의 경쟁사들이 ODF로 선택을 수렴한다면 이는 MS의 마켓파워로도 무시하기 힘든 상황이 벌어질 가능성이 높습니다.

이전과는 달리 현재 ODF는 몇가지 이점을 갖고 있어요. 우선 OOXML 보다 먼저 표준으로 선정되었고 오픈오피스에 실제로 구현되어 있으며 IBM과 SUN이 ODF를 밀고 있습니다. 정부쪽에서 ODF를 선정하는 경우도 있고... 상용 포맷인 hwp가 정부 납품만으로도 여전히 생존에는 지장이 없는데 굳이 ODF의 미래를 비관적으로 판단할 필요가 있을까요?

뭐 어쨌든 전 OOXML의 표준 추진은 여러모로 볼 때 나쁘지 않다고 생각합니다. OOXML의 표준 승격을 막아야 할 구체적인 이유가 나오지를 않네요.

지리즈의 이미지

"OOXML의 표준 승격을 막아야 할 구체적인 이유가 나오지를 않네요"

단지 우리가 너무 널리 사용하나로 있다는 이유하나로 수용할 뿐이지,
OOXML은 하위호환이라는 병균에 썩어가고 있는 악취나는 쓰레기일 뿐입니다.
표준으로서는 함량 미달입니다.

그런데, 당장 눈앞의 엄청난 비용이 절감되기 때문에
이 문제를 직시하는 사람은 별로 없습니다.

다른 정치적인 이유들도 있지만, 이게 가장 OOXML이 표준이 되지 말아야할
기술적인 이유를 요약한 것입니다.

다른 이유는 다 제쳐놓고 이정도면 충분한 이유가 되지 않나요?

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

linlin의 이미지

소프트웨어가 널리 사용된다는 것은 아주 중요한 요소이고 장기적으로도 사회적 비용 절감에 기여합니다. 단지 널리 사용하고 있다는 이유 하나로 무시할 것이 아닙니다. 멀리 갈 것도 없이 리눅스는 왜 여전히 수십년 전의 유닉스와 하위 호환성을 유지하고 있나요? 윈도우 사용자들이 리눅스 쉘의 command prompt 입력방식의 이점을 잘 알지도 못하고 비난하는 실수를 똑같이 하고 있는 건 아니에요?

지리즈의 이미지

구체적으로 볼 필요가 있습니다.

ODF는 사실상 오피스의 표준을 정립할 수 있을 만큼의 기반되는 기술이
성숙한 다음에 나온 것입니다. 구체적인 부분들은 다른 표준에 의지하지요.
이를 테면 문자 인코딩은 UTF-8에 의존한다는 식이죠.

그런데, OOXML은 이러한 기반이 성숙하지 못한 시점부터 이어져 온 것입니다.
즉, 부족한 기반에 대해서 스스로 정의할 필요가 있었고,
그러한 부분이 모두 포함있습니다.

문제는 이 부분이 오늘날에는 다른 표준들이 엄연히 존재하고 있으며
OOXML의 정의하고는 다를 수 있다는 점입니다.
또한 이 표준이 변하면, OOXML 또한 변화해야 하는데, 이를 정의하고 있기 때문에
OOXML은 여기에 묶이게 됩니다.

단순히 OOXML이 ODF와 상충되는 것이 아니라,
잠재적으로는 비슷한 기능을 정의하고 있는
많은 표준들과도 상충될 수도 있는 것이죠.

단순히 MS워드 97만을 읽기 위한 규정만이 존재하는 것이 아닙니다.
이러한 것들을 다 읽어 들이기 위해서는 당시는 표준이 아니였지만
현재에는 표준인 여러 작은 규약들에 상충되는 내용을 포함해야 한다는 점이죠.
따라서, 오피스용 라이브러리와 표준라이브러리를
이중적으로 개선해 나가야 한다는 것이고, 단순히 오피스 시장만의 문제는 아니게 되는 것이죠.

결국 이러한 것이 표준이 된다면, 앞으로 크고 작은 골치 아픈 문제들을
계속 짊어 지고 가야 합니다. 단기적으로는 이득이 되지만, 장기적으로는 재앙입니다.

그래서 새롭게 정의될 수 있다면, 정의하는 편이 바람직합니다.
물론 더디고 힘들죠. 그렇지만, 지금 바로잡지 않으면 먼 훗날 크게 당하게 됩니다.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

linlin의 이미지

안쓰이는 표준도 많습니다. 쓸모가 없는 표준은 안쓰이고 사문서화됩니다. 지리즈님 주장은 계속 표준은 정해지면 100% 준수되어야 한다는 가정에 기반하네요.

하위 호환성은 당장 지원 비용이 증가하더라도 디폴트로 지원하는 것이 맞습니다. deprecated api가 대표적인 예입니다. 새 api 규약과 상충되며 혼동을 주는 deprecated api를 왜 굳이 비용을 들여서 지원합니까?

MS 오피스의 구버전 파일 포맷 지원도 마찬가지입니다. 여기에 사용자 베이스라는 항목을 넣어봐요. 님 얘기대로 당장은 불편하지만 일단 하위 호환성을 버리는 불편을 감수하고 하위 호환성을 배제한 표준을 채용해 오피스 구버전 파일의 설계 문제에서 나올 장기적인 재앙을 예방한다고 해 봅시다. 그런데 여기서 이미 많은 사람들이 쓰고 있다는 점을 고려해봅시다. 개인 단위로 보면 별다른 불편이 아닐 수도 있지만 사회 전체로 보면 비용 지출의 규모가 커집니다. 또한 이 이전은 단기간에 일어날 필요가 있습니다. 따라서 장기적으로 사용자들 전체에 이익이 되더라도 이는 이미 현재 지나친 이전 비용을 지불하는 것을 전제로 하기 쉽상입니다. 게다가, 미래에 대한 예측은 자주 틀리기 마련입니다.

그렇다면 앞으로 크고작은 골치아픈 문제를 짊어지고 가더라도 단기적으로는 이득이 되고 장기적으로는 재앙이 되는 선택을 해 봅시다. 단기적으로 이득이 되기 때문에 아까처럼 대규모의 이전 비용 문제는 발생하지 않습니다. 그리고 장기적으로 문제가 나타나면 문제가 나타나는 정도에 따라 고쳐 쓰든지, 혹은 안쓰게 되든지 상황이 발생하기 마련입니다. 정말로 버려야 할 표준이라면 그 때가서 "쓰이지 않는 표준"임을 확인하고 버려도 늦지 않습니다. 따라서 대규모의 이전 비용을 지출하지 않고 잘못된 미래예측으로 발생할 수 있는 비용 역시 예방할 수 있으며 표준 변경 과정에서 사용자들의 저항이 적기 마련입니다.

간단히 y2k예를 들어볼까요? 전자제품이 많이 개발되던 초창기에 연도를 두자리만 쓰게 된 것은 비용문제가 컸을 겁니다. 이것을 그럼 2000년 이후에는 y2k 문제가 심각할 것이니 예를들어 1970년대에 누군가가 표준을 제정해 네자리 연도표시를 하자고 정했다고 쳐요. 이건 방향을 잘 잡은 예측이겠지만 이전 비용 문제가 생깁니다. 또한 이전 작업이 사회적으로 동시에 진행되지 않으면 기존 시스템과의 호환성 문제도 생기기 마련이죠.

하지만 y2k 문제를 그냥 놓아둬 봅시다. 2000년이 다가올 즈음이면 자연히 사람들이 이 문제에 신경을 쓰게 되어 있습니다. 게다가, y2k 문제에 영향을 받을 수 있는 시스템들이 대부분이다보니 역설적으로 이 문제 해결에 관심있는 사람들의 숫자 역시 많고 따라서 규모의 경제 효과 덕분에 해결책이 상대적으로 싼 비용으로 만들어집니다. 또한 만들어지는 솔루션들이 예측하기 힘든 미래의 환경을 고려하기보다는 문제가 발생하는 현재의 환경을 충분히 고려해서 만들어질테니 적용이 효과적일겁니다.

y2k 문제는 결국 핵폭탄이 터질 수도 있다는 우려와는 달리 별 문제 없이 지나갔습니다. 이것은 사용자 숫자가 많으면 버그는 없어지기 마련이라는 오픈소스의 작동 메커니즘이나 별반 차이가 없습니다.

하지만 이걸 장기적인 재앙을 막는다는 이유로 표준을 미리 정하는 것은 결국 예측을 제대로 했더라도 사용자들의 이전 비용을 줄이지 못하며 사용자들의 숫자가 많으면 이 이전비용 지출의 합이 미래의 불확실한 편익을 능가하기 쉽상입니다.

OOXML도 마찬가지죠. 아무리 OOXML의 하위호환성 규약이 X판으로 기술되어 있다고 가정하더라도 오피스와 같이 사실상 전 지구인들이 오랫동안 써 온 소프트웨어의 하위 호환성은 무엇보다도 중요하게 고려되어야 합니다. 새 표준으로의 이전 비용은 가능한한 0에 가깝게 최소화 하는 것이 특히 사용자가 많은 경우는 중요할 수 밖에 없는 겁니다. 경쟁사의 입장에서 OOXML의 구버전 파일 포맷 하위호환을 위한 규약 구현은 고충이지만, 표준이 중요하게 여기는 공공의 이익, 즉 사용자의 편익을 고려한다면 이를 표준화시키는 것은 사회적으로 바람직한 일입니다. 정말 버려야 하는 표준이라면 쓰이지 않게 된 뒤 버려도 문제가 없고, 그렇게 해야 소위 새로운 표준 패러다임으로 넘어가야 할 유인이 사회적으로 작동하게 되는 겁니다. 모두가 안쓰는 표준이라면 그만큼 대부분의 사람들에게 비용 지출이 크다는 얘기이니 새로운 표준을 들이대면 저항없이 이전이 이루어지기 마련입니다.

그리고 하나 더. ODF가 만약 OOXML에 비해 확고한 대안이라면 이미 실제 ODF의 쓰임이 급격하게 늘어나기 마련입니다. 이건 사용자 베이스를 고려한 비용편익 문제이니까요. 소프트웨어는 항상 시장을 선점한 업체가 독점을 유지할 것 같지만 일단 사용자의 스위치가 일어나면 순식간에 급격히 발생합니다. 사용자들도 바보가 아닌이상, 오픈오피스가 MS 오피스보다 월등히 낫다면 스위치를 주저하지 않습니다. 그 뒤집기 임계점까지의 편차가 커서 문제일 따름입니다.

hexagon의 이미지

제가 표준의 가치라는 말을 앞선 댓글에서 언급한적이 있습니다.

그렇다면 가치 없는 표준의 제정을 막는것과 가치 있는 표준의 준수 양쪽다 중요한 일이 아닐까 생각합니다.

틀림없이 표준이란건 기본적으로 표준으로써의 가치를 가질 수 있도록 제정되어야되고 그렇게 제정된 표준을 100% 준수하는것을 가정하는 것이 바람직하다고 봅니다.

그런부분에서 지리즈님의 의견은 타당하다고 생각됩니다.

새로 제정될 표준이 과거에 제정된 가치있는 표준의 가치를 홰손 시킬 우려가 있다면 주의해서 나쁠 것은 없습니다.
복수의 표준이란건 사실 비용의 절감과는 거리가 머니까요.

ODF가 가치 없는 표준이라고 생각하신다면 OOXML을 지지하는게 옳지만 그렇지 않다면 이미 표준이 된, ODF의 표준으로써의 가치를 홰손 시킬 수 있는 복수 표준에 대한 논쟁은 소모적이라고 봅니다.

표준이란 것은 범세계적으로 통용될 수 있는 수단이면서, 비용절감의 효과도 고려해야된다고 한다면 복수표준은 꼭 필요한 경우가 아니면 바람직하지 않다는게 저의 사견입니다.

사실 OOXML이 플랫폼 종속적이란것과 지리즈님이 말씀하신 몇몇 기술적 문제(하위호환으로 인한..., 기존 표준에 대한...)들이 개선된 상태에서 ODF보다 먼저 표준으로 지정되었다면 전 ODF의 표준 지정을 반대하는 입장에 설겁니다.

하지만 현재 OOXML이 가지고 있는 기술적 문제점은 IE와 비슷한 잠재적 위험을 안고있다는 점에서 표준제정을 위해서 절대적으로 수정되어야될 사항이라고봅니다.

물론 지금은 제기된 기술적 문제에대한 수정이 이루어져서 한국정부가 찬성에 투표한다고 하니 복수 표준은 달갑지 않더라도 지켜 볼수 밖에요...

정치적, 사업적 문제에 대해서는 사실 우려가 되지만 표준 제정에 있어서 정도 이상으로 고려되는 것도 문제가 있다고 봅니다....(특허라는게 문제긴한데....흠...)

아무튼 linlin님의 표준에 대한 인식이 저와 다른 것 같아서 이렇게 생각해보면 어떨까 하는 생각으로 적어봅니다.

linlin의 이미지

아니죠... 지금 ODF 표준도 문서 표준의 needs를 만족스러운 수준으로 충족시키지 못하고 있고 OOXML 표준도 마찬가지 상황입니다. 한쪽이 다른쪽을 대체해도 될만큼 뛰어나지 않아요. 이런 경우에는 복수 표준을 인정하고 개발자들이게 복수 선택을 준 다음 전개되는 상황에 따라 차후에 복수 표준을 하나로 통합시킬수도 있는 겁니다.

이 경우 복수 표준은 개발사마다 각 회사 고유의 문서 포맷을 만드는 것 보다는 훨씬 사회적 비용 절감에 기여합니다. 포맷의 난립을 적어도 두개로 줄여 줄 테니까요. 최근 blu-ray와 hd-dvd도 결국 하나로 통합되고 있지 않습니까? 경우에 따라서는 단일 표준으로 가기위해 이런 프로세스가 필요한 겁니다. 리눅스에서도 Gnome 데스크탑과 KDE 데스크탑이 사실상 양대 표준인데 분명 Gnome이나 KDE모두 다른쪽을 충분히 대체할 수 있는 환경은 아닙니다. 단적으로, GTK2+의 LGPL라이센스와 Qt의 라이센스만 해도 리눅스 어플을 개발하는 기업들에게는 선택의 대상이 될테니까요.

지리즈의 이미지

오직 오피스하나라면 옳은 말이겠죠.

하지만, 오피스는 많은 소프트웨어 중에 하나일 뿐이며,
다른 많은 소프트웨어들과 공통된 기술을 공유할 수밖에 없습니다.

그런데, 이러한 공통된 기술에 대한 고려가 빈약한 표준을
단순히 하위호환이라는 명목하에 수용할 경우,
오피스 시장에서야 사회적 이득이겠지만,
전 분야에 걸쳐서 주는 피해는 막심해질 수 있습니다.

표준이란 장기적 방향을 예상할 수 있어야 하는 것이 아니라,
예상할 수 없는 문제에 대해서 대처할 수 있도록
유연성을 가져야 하는 것이 중요합니다.
그렇지만, OOXML은 지나치게 세세하고 또한 하위호환 문제때문에
그렇지 못하다는 것을 지적하고 있습니다.

y2k가 본인입장에서야 요란한 빈수레처럼 지나간 것처럼
느껴질 수 있겠지만, 당시 발생한 사회적인 비용은 엄청났습니다.
이러한 비용이 소모되었기 때문에 여러 비극적인 사태를 막을 수 있었던 것이죠.

ODF가 낫다면 OOXML을 대체하겠죠.
하지만, 제가 볼때는 언제나 그랬던 것처럼
OOXML에 묶여 있는 기술들 때문에 다른 분야의 기술조차
MS에게 휘둘릴 가능성이 더 높아 보입니다.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

linlin의 이미지

그렇다면 MS 오피스를 배제하고 어떻게 사용자들을 차세대 문서 표준 --- 그것이 ODF는 OOXML이든 무엇인든간에 --- 으로 이끌 수 있죠? 그동안 만들어진 수많은 오피스 파일들은 버려도 되는 것이며 MS 오피스에 익숙해진 사용자들이 그동안 MS 독점 문제의 폐해를 고려해 기꺼이 새로운 오피스 패키지를 쓸려고 한답니까?

현재의 상황을 고려하지 않은 표준은 결코 널리 쓰이지 않습니다. ODF의 느슨한 규약이 님 얘기대로 그렇다면 미래의 확장성이라는 측면에서 유연성을 잘 제공해 준다고 칩시다. 하지만 일단 사람들이 ODF로 넘어와야 그것도 가능해지는 얘기 아니겠어요? 기술적으로는 잘 디자인되었어도 안쓰이는 표준은 널리고 널렸습니다.

그리고 MS 핑계는 솔직히 좀 그만들었으면 싶습니다. 이쪽 분야에서 사용자 베이스가 엄청난 위력을 발휘한다는 것은 다 아는 사실입니다만 기술적으로 뛰어나면 자연히 사람들이 많이 써 줄 것이라고 기대하는 뜬금없는 태도도 좀 버려야 될 때가 되지 않았나요? 솔직히 ODF가 그럼 기존의 MS 오피스로 만들어진 파일과의 호환성 확보를 위해서는 뭘 하고 있습니까?

y2k의 사회적 비용이 엄청났다구요? y2k를 예를들어 20년 전에 표준 제정으로 예방하겠다고 사람들이 나섰다 해 보세요. 아마 y2k 문제 홍보비로 더 많은 돈이 나갔을겁니다. 규모의 경제로 인한 비용 절감을 너무 만만하게 보고 있는 것 아닌가요?

하위호환은 "단순한" 하위호환이 아닙니다. 리눅스가 그나마 이정도라도 쓰이고 있는 것은 수십년동안 축적되어온 유닉스 진영의 자산 소스코드를 그대로 물려받고 유닉스에 친숙함을 느끼는 사용자들이 쉽게 리눅스로 많이 이전해 왔기 때문임을 잊어서는 안됩니다. 특히 MS는 하위호환에 변태스러울 정도의 집착을 보이기로 유명한데 MS의 윈도우 개발자들은 심지어 구버전 윈도우의 버그까지도 똑같이 구현하는데 시간을 낭비하고 있다고 하더군요. MS도 바보가 아닌이상 왜 그딴 짓거리를 하고 있는지 좀 생각해봐야 할 것 같네요.

지리즈의 이미지

MS오피스의 ODF 지원 문제지 OOXML이 표준이 안된다고
MS 오피스를 못 사용하는냐 그것은 아니죠.
단지 기존의 MS 오피스 포멧이 표준문서가 아닐 뿐입니다.
기존 문서를 그럼 못읽게 되는가? MS가 계속 지원하는데, 걱정할 일이 아니죠.
문제는 향후에 작성되서 앞으로 사용해 나가야할 문서 포멧이 중요한 것이죠.

사용자에게 있어서 새표준으로 작성된 문서는
구소프트웨어에서는 읽어들일 수 없는 문제가 존재하지만,
OOXML의 표준상관없이 최신버전 오피스작성된 문서가
워드 98에서 읽어 들일 수 있느냐 그것도 아닙니다.

기존 포멧이 표준일 될 경우, 새 포멧으로 전환하는 비용이 절약되긴 하지만,
그렇다고 해서 향후의 표준에 따라서 기존 포멧이 새 포멧으로
전환될 필요성 발생될 가능성이 전혀 없는 것도 아닙니다.

결국은 새로운 표준이 뭐냐는
일반 사용자에게 있어서 큰 상관이 있는 것이 아닙니다.

OOXML 표준이 되더라도, 지금 현재 6000페이지 분량의 문서만으로는
구포멧을 기술하는데 부족하고 더 자세해지면 다른 벤더들이 이에 대한
기술지원것이 어려워지기 때문에 결국은 OOXML이 표준이 되던 안되던
MS의 구포멧은 MS오피스만 읽을 수 있을 가능성이 농후합니다.

중요한 것은 표준을 제대로 준수하는
소프트웨어를 만들 수 있는 회사가
오직 MS만 존재하게 된다는 것이 문제죠.
이것은 절대로 우리에게는 이득이 안됩니다.

그리고, 리눅스 유닉스 이야기를 계속하는데,
중요한 것은 리눅스는 POSIX와 같은 표준을 준수한 것이고
그것이 더 의미가 있는 것이지 유닉스의 리거시를
단순히 따라한 것이 중요한 것이 아닙니다.
만약 애초에 MS도스나 윈도우 초기 버전들이
POSIX와 같은 여러 표준을 준수했다면
지금 처럼 윈도우용/유닉스용 소프트웨어들이
이중화되는 문제는 없었겠죠.
그리고, 운영체제 가리지 않고 다양한 운영체제에
이식가능한 포멧으로 소프트웨어가 존재했다면
MS의 독점이 시작됐을까요?

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

linlin의 이미지

사용자들이 MS 오피스를 버리고 ODF로 이주할만한 이유가 뭐가 있나요? 지금 지리즈님이 주장하고 있는 것은 ODF를 표준으로 하는 것이고 이것은 사용자들이 ODF를 오피스 포맷 대신 쓰는 것을 의미하는 거 아니에요?

또 다른 한편으로, MS 오피스가 경쟁상대인 오픈오피스가 채택하고 있는 ODF를 지원할 이유가 도데체 무엇이 있느냐는 말이죠.

그렇다면 ODF를 오피스 포맷 대신에 표준으로 선정하더라도 사용자들이 ODF로 이전해갈 이유가 마땅치 않으며 MS가 ODF를 전면적으로 지원할 이유 또한 없어요. 이런상황에서 ODF가 과연 쓰이지 않는 표준으로 전락하지 않을 구체적인 방법이 정말 있기는 해요?

환자가 돈이 많아도 병원과 의사가 없으면 병을 못고치고 병원과 의사가 있어도 돈이 없으면 병을 못고치게 마련입니다. 두 경우 모두 줄이면 병을 고치는 길은 없는 겁니다. 자꾸만 ODF가 표준이 되면 MS의 독점을 해결할 수 있을 것 같은 환상을 전개하지 말아 줬으면 하네요.

하던 얘기 또 반복입니다만 결국 OOXML에서 개발사의 부담은 하위 호환성이 복잡해서라면서요? 그러면 그 부분은 MS 이외의 회사들은 구현을 포기하면 됩니다. 그거 구현 안했다고 사용자들 도망 안갑니다. 100% 호환이라고 해도 사람들이 MS 브랜드 쓰지 누가 다른 회사 제품 쓰나요?

다만 OOXML이 등장하면서 적어도 기존 문서와의 호환성이라는 필요성을 제시한 것은 중요하게 볼 필요가 있어요. 그래도 OOXML 규격이 정해져 있으면 써드파티 업체가 기존 MS 오피스 파일과의 호환성이 필요할 때 이 표준을 따라서 구현을 하면 되니까요. 이런 가능성이 OOXML표준으로 열리는 것이 좋나요 아니면 예전처럼 각개전투로 알아서 하위호환성을 유지하는게 좋나요?

그리고 지금부터 MS가 OOXML을 포맷으로 쓴다면 하위 호환성을 배제한 나머지 부분에서는 써드파티업체와 MS 오피스간의 파일 호환이 가능해지는 상황이 열리는 것 아니겠어요? 이건 분명 MS의 경쟁사들에게 괜찮은 상황 전개이고 MS도 마켓파워를 유지하면서 독점의 비난에서 벗어날 수 있는 좋은 상황전개에요. 또 현실적으로도 충분히 전개하기가 어렵지 않구요. Thinkfree가 할일이 없어서 먼저 OOXML을 구현하고 있었다고 생각되지 않습니다. 결국, 두 경우 모두 OOXML이 표준이 되면 경쟁사들의 비용을 절감하는 효과가 따라와요. OOXML이 표준이 되지 않으면 개발 비용 증대를 감당해야 하는 것은 경쟁사들입니다. 다시 강조하지만 여기서는 포맷의 100% 호환이 중요한 것이 아닙니다.

그리고 posix 표준표준 하는데 아니 리눅스가 posix 표준을 따른게 의미가 있어요? Posix 표준은 윈도우 NT도 지원한다고 대문짝하게 광고하덥디다. 표준만 따른다고 하위호환 문제가 끝나는게 아니에요. 기존에 쓰던 소프트웨어들 다 포팅하고 또 기존 환경을 쓰던 사람들이 쉽게 리눅스에 적응할 수 있어야 하위호환이 제대로 구현되고 있는 겁니다. posix는 단지 reference manual일 따름이에요. posix역시 따라가야 할 표준이라기 보다는 역사가 쌓이면서 확립된 표준이고 불문율에 가까운 속성이 있어요. 표준은 대뜸 하나 쓴다고 투표해서 정하면 그걸로 끝나는게 아닙니다. 쓰이지 않는 표준은 쓸모가 없어요.

MS 도스나 윈도우가 왜 Posix 표준을 준수안했냐구요? 그 당시 8086 시피유 256Kb 메모리에서 어느 재주 좋은 개발사가 posix 구현을 합니까? 미닉스 돌린다고 자랑하던 사람 컴퓨터가 80286에 4메가 메모리였던가 했는데 그때에도 세상은 MS 도스 겨우겨우 돌리던 시절이에요. 유닉스를 알던 사람은 언제쯤 좋은 세상이 올까 손만 빨고 있던 시절이에요. 이럴바에는 차라리 애플2 더러 posix 왜 지원하지 않았는지 책임을 묻고 매킨토시더러 왜 처음부터 유닉스로 가지 않았냐고 비난해야겠군요.

그리고 그 당시에 "운영체제 가리지 않고 다양한 운영체제에 이식가능한 포맷"을 구현하고 있던 오에스나 어플이 있으면 좀 알려주시죠. 이당시 이식성을 고려했던 유닉스를 쓰려면 적어도 워크스테이션 한대 전산소에서 도입해주지 않으면 방법이 없던 시절이에요. 리누스 토발즈가 피씨에서 도는 유닉스를 갖고 싶어서 리눅스 개발을 시작한 것이 이보다 한참 뒤 얘기입니다. 그런 환경에서 MS 독점 운운하는 건 있을수도 없는 가능성을 만들어 내는 겁니다.

뭐 MS가 아니었더라도 피씨 운영체제 시장에서의 독점은 당연히 이루어지는 일이에요. 플랫폼 별로 잘 봐요. 매킨토시 플랫폼은 애플이 잡고 있고 지금은 쓰지 않지만 아미가는 아미가가 잡고 있지 않았어요? PS2에서 닌텐도 개발킷이 돌아가던가요? 오래전 Palm 제품들도 사실 오에스 공급사는 하나에요. 문제는 어떤 독점을 만들어 나갈 것인지이지 누가 독점을 하는지는 별로 중요하지 않아요. MS가 비난을 받을 일이 있다면 그것은 오래전 Digital Research니 netscape 같이 MS 플랫폼에 도전한 회사들을 마켓 파워로 시장에서 축출한 과정이지 독점 자체는 비난해서는 안되고 또 표준에서 볼 수 있는 것과 같이 이러한 독점은 규모의 경제 측면에서 사용자에게 바람직한 겁니다. 현재 만약 posix 표준이 세상을 점령하고 있다고 해 봐요. 저 같은 사람이야 유닉스 세상이니 편하겠지만 일반인들은 상대적으로 불편한 GUI 환경을 쓰고 있겠죠. 일장일단이 있는 겁니다.

어쨌거나 OOXML 이라는 reference platform이 있는것과 없는 것은 큰 차이가 납니다. 오히려 지금 상황에서는 OOXML을 표준으로 넣고 현재 MS의 지분을 적절히 인정해 준다음 대신 경쟁사에 적절한 호환성을 OOXML에 보장해 주는 것을 요구할 필요가 있어요. MS도 계속 반독점 시비에 휘말리면 괴롭고 경쟁사들도 언제까지 MS 뒤꽁무니만 쫓아가기가 괴로운 건 마찬가지입니다. OOXML의 완벽한 구현 필요성은 MS의 독점을 근거없이 두려워하는 사람들의 핑계일 뿐입니다.

상황을 좀 정리해 보니.. .결국 ODF는 오픈오피스를 쓰다보니 나온 문서 포맷중의 하나일 뿐이군요. 자료를 검색하면할수록 ODF는 도데체 오픈 오피스가 공짜고 IBM과 썬이 뒤를 받치고 있다는 것 외에는 사용자층을 늘여 나갈 별다른 방법이 없어요. OOXML이 표준에서 탈락하더라도 ODF가 과연 OOXML과 경쟁이 될른지? 솔직히 많이 회의적입니다. 삼성에서 훈민정음 쓰듯이 정부에서는 ODF쓰고 밖에서는 모두 OOXML쓰는 상황이 벌어지는 것 아닌지 모르겠군요.

지리즈의 이미지

OOXML이 표준이 아니면, ODF는 사장될 운명이다.

이 대답에 대한 답변은 노입니다.

왜냐하면, 정부와 같은 다양한 정보를 저장해야할 기관에서 독점적인 포멧일 경우 향후 이 포멧을 제공하는 업체에 의해서 이런 단체가 영향을 받을 수 있기 때문에 공개표준문서를 저장할 필요가 있습니다. 그렇기 때문 각종 정부단체들이 ODF를 문서 표준으로 채택하기 시작한 것입니다.

만약, MS 오피스가 ODF를 지원하지 않기로 끝까지 버틴다면 어떨까요? 이는 자멸의 길입니다. 국가정부기관에는 납품할 수가 없게 되고, 교육기관도 마찬가지가 될 것이고, 이러한 정부와 교류하는 모든 업체들도 결국은 ODF를 지원하는 오피스를 사용하게 됩니다. 특히 교육기관에서 학생활인을 아무리해줘도 오픈오피스를 쓴다고 생각해 보십쇼. 얘들은 장래에도 오픈사용자들이 될겁니다. 이러 추세가 확산되면 결국은 MS는 그 위상을 잃을 수 밖에 없지요. 결국 MS는 OOXML이 통과되지 않는다면 선택의 여지가 없이 ODF를 지원해야 합니다.

이 부분은 이견이 있을 수가 없다고 봅니다.

그렇기 때문에 MS가 이 시점에 OOXML을 들고 나온 것이죠. ODF를 지원하지 않을 수가 없기 때문입니다. 선택의 여지가 없는 것이죠. 그런데, ODF 포멧을 지원하는 것으로는 자신들이 시장을 리드할 수 없습니다. 자신들의 마음대로 포멧을 결정할 수 없다는 이야기죠. 따라서 평소와 다르게 MS가 관련된 특허에 대해서 "자신들이 생각할 때" 합리적인 수준으로 공개하는 것과 같은 강수를 둘 수 밖에 없는 것이 OOXML이 통과되지 않고서는 MS 또한 ODF를 따르는 그냥 그런 오피스업체가 되기 때문입니다.

합리적인 수준의 공개 이것도 제가 볼때는 "사기"입니다. 특허 완전 공개인 것 같습니까? 아닙니다. 만약, 내가 MS포멧을 가지고 유료오피스 프로그램을 만들면, 기술 로열티를 MS에 지불해야 합니다. 오직 오픈소스로만 "배포"할 때만 공짜입니다. 이것도 웃긴게, "배포"할 때일 때는 공짜이겠지만, "사용"할 때는 공짜가 아닐 수 있어요. 내가 오픈소스를 가지고 유료서비스를 하죠? 이것도 알 수 없습니다. 피씨방마다 오픈오피스깐 PC에 대해서 로열티 걷지말라는 보장이 없어요. 또한 오픈소스가 아닌 경쟁사가 볼잘 것 없는 금액으로 판매할때는 로열티를 얼마 받지 않거나 아에 문제 삼지 않을 수 있지요. 그런데, 이게 자신의 시장점유율에 심각히 위협된다고 판단된다면 얼마든지 이 합리적인 수준이라는 것은 확장되고 왜곡될 수 있습니다. 즉 경쟁상대를 위협하는 구실로서 충분한 무기가 된다는 것이죠. 그리고, 누군가 MS특허를 오피스가 아닌 다른 용도로 활용하죠? 이것도 보호해 주지 않습니다. 결론은 전형적인 FUD이고 기만행위일 뿐입니다. 사실상 애초부터 이런게 표준으로 제시될 수 있는 풍토가 웃긴 일이죠.

"환자가 돈이 많아도 병원과 의사가 없으면 병을 못고치고 병원과 의사가 있어도 돈이 없으면 병을 못고치게 마련입니다. 두 경우 모두 줄이면 병을 고치는 길은 없는 겁니다. 자꾸만 ODF가 표준이 되면 MS의 독점을 해결할 수 있을 것 같은 환상을 전개하지 말아 줬으면 하네요."

전혀 이상한 말도 안되는 논리인데, ODF가 표준이 된다면이 아니라, ODF는 이미 표준입니다. 환상이 아니죠. MS독점에 상당한 위협을 준것도 사실이기 때문에 OOXML을 MS가 들고 나온 겁니다. ODF가 표준을 통과하지 않았고, 정부단체가 ODF를 채택하지 않았다면, OOXML을 MS가 들고 나왔을 것 같습니까? 특허사용도 크게 양보하면서? (MS 입장에서는 오픈소스 진형을 공격하는 최후의 수단인 특허를 포기한 것이기 때문에 얘네들 입장에서는 정말 정말 큰 희생이라고 생각할 겁니다. 적어도 합리적 수준이라는 단서를 붙이면서 다른 상용 소프트웨어 경쟁상대는 일단 견제할 수단은 남겨 났긴 했죠.. 큰 선심쓰듯 과감한 결단을 내린 것처럼 기사가 나왔는데... 진짜 역겹더군요. -_- 진짜 가증스러운 것들입니다.)

뻔한 것 아니겠어요? MS 전략이? MS의 FUD에 그간 그렇게 당하고도 또 속는 것을 보면, 순진한 것은 우리나라 사람들만은 아닌 것 같습니다.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

linlin의 이미지

ODF는 이미 표준이니 생존자체에는 문제가 없어요. 하지만 적어도 현재로서는 ODF와 OOXML은 양자를 서로 대치할 수 없어요. 따라서 현 상황이라면 ODF나 OOXML 한쪽 포맷이 없어지는 일은 시간이 지나도 발생하기 어렵다는 전개가 나와요. 여기까지는 지리즈님도 오케이인가요?

이렇다면 문제는 어느 표준이 더 많이 쓰이나에요. ODF만을 표준으로 한다고 해서 ODF의 시장점유가 확대되지 않습니다. 정부 섹터가 크고 MS로서도 놓치고 싶지 않은 고객이겠지만 정부가 모두 ODF로 전환한다고 민간까지 그 효과가 확대되지는 않아요.

따라서 MS가 정부기관에 납품을 못한다고 자멸하리라고 보는 것은 지나친 억측인 것 같네요. 왜냐하면, ODF의 사용을 명시하지 않는 민간 부문에서는 OOXML표준도 아닌 MS 오피스를 쓸테니까요. 결국 그러면 정부에서는 ODF를 쓰고 민간에서는 OOXML을 쓰는 것으로 균형이 잡힐 겁니다. 지금도 그렇지 않나요? 한국 정부에서는 hwp를 쓰고 민간기업은 모두 오피스를 쓰니까요.

그런데 이렇게 통하지 않는 두 표존이 혼재하는게 과연 바람직한 균형인가요? 여기서 지리즈님은 어떻게 ODF가 싱글 표준으로 자리잡을 수 있는지, 혹은 그게 안된다면 차라리 OOXML 싱글 표준을 자리잡도록 하는게 바람직하다고 생각하는 거에요? MS가 OOXML을 포기하든가 정부가 ODF를 포기하든가 해야 하는 것 외에 어떤 방법이 가능해요?

그래서 어차피 이런 균형으로 간다면 현재 OOXML을 찬성하는쪽에서 주로 보이는 의견이 MS의 독점 행위를 막을 수 있는 장치를 확보하고, ODF와 OOXML사이의 상호 운용성 (interoperability)를 확보해준다면 OOXML 표준을 받아 들일 수 있다는 것 아니겠어요? 특허 문제도 지금 MS의 시장 독점력 행사를 막는데 초점을 두고 논의중이구요. 여기에 뭐가 우려할 것이 있나요?

이렇게되면 ODF와 OOXML이 같이 쓰이더라도 적어도 ODF와 OOXML이 서로 통하지 않는 불편함은 애초에 제거할 수 있고 이게 중요한 포인트가 되는 겁니다. 이렇게 되면 통하지 않는 두 표준이 시장에서 경쟁할 상황이 적당히 통하는 두 표준이 시장에서 경쟁하는 까닭에 MS의 독점을 경쟁을 통해 막을 수 있는 길도 열리구요. 이거 지리즈님이 가장 우려하던 MS의 독점 문제를 해결하는 방법 아닌가요? 님은 MS의 가증스러움에 대해서는 이런저런 얘기를 잘 하는데... 그걸 어떻게 해결할 것인지는 전혀 제안이 안나와요. 정말로 ODF만 쓰면 MS가 자멸하는 것 맞아요?

실제 MS가 신경을 쓰고 있는 것은 IBM과 썬일겁니다. 이네들은 ODF를 실제적으로 많이 쓰이도록 추진할 파워를 갖고 있으니까요. 안그래도 MS가 IBM이 각국 정부를 돌아다니며 ODF를 로비하는데 공개적인 비난성명을 내놓았죠.

그리고 MS가 이제는 반독점 소송에도 신경을 써야겠죠. 아마도 MS가 ie나 썬의 자바 물타기 같은 전력이 없었으면 이미 MS는 ODF지원을 선언했을 겁니다. 오픈소스 진영은 MS의 ODF 표준 채택에 환호하고.... 그리고 그 결과는 몇년뒤 ODF 물타기가 될 테구요.

그런까닭에 전 ODF가 OOXML을 필두로 한 MS의 독점 음모에 결국 희생될 것이다... 그다지 신뢰하지 않습니다. 오히려 ODF쪽의 엄살이라고 봅니다. ODF가 걱정해야할 것은 상대적으로 OOXML에 비해서 떨어지는 기능이라고 봅니다. 허접한 표준이 정부에 채택되면 결국 낭비되는 것은 세금밖에 없어요. 장기적으로 OOXML 차기 규약에도 밀릴 수 밖에 없구요. 물론 여기서 기능이 떨어져서 특정 포맷이 시장에서 퇴출되는 것과 독점 기업의 마켓파워 남용으로 축출되는 것은 혼동하지 말아 주었으면 하네요.

지리즈의 이미지

"ODF는 이미 표준이니 생존자체에는 문제가 없어요. 하지만 적어도 현재로서는 ODF와 OOXML은 양자를 서로 대치할 수 없어요. 따라서 현 상황이라면 ODF나 OOXML 한쪽 포맷이 없어지는 일은 시간이 지나도 발생하기 어렵다는 전개가 나와요. 여기까지는 지리즈님도 오케이인가요? "

공감할 수 없네요.

ODF가 이미 표준이라고 하지만, 아직 자리잡기 시작했을 뿐이고, 이제는 ODF를 표준으로 한 정부기관도 굳이 ODF만을 표준으로 할 필요가 없어지죠. 한단체 내에서 두가지 표준을 모두 쓰지는 않을 것 아닙니까? 그럼 당연히 OOXML을 쓰겠죠.

그리고, MS가 정부기관에 납품을 못한다고 자멸하리라고 보는 것은 지나친 억측이라구요? 그럼 왜 OOXML을 MS가 들고 나왔을까요? 그럴 필요가 없죠. 위기감을 느꼈기 때문에 그렇게 하는 겁니다.

"그래서 어차피 이런 균형으로 간다면 현재 OOXML을 찬성하는쪽에서 주로 보이는 의견이 MS의 독점 행위를 막을 수 있는 장치를 확보하고, ODF와 OOXML사이의 상호 운용성 (interoperability)를 확보해준다면 OOXML 표준을 받아 들일 수 있다는 것 아니겠어요? 특허 문제도 지금 MS의 시장 독점력 행사를 막는데 초점을 두고 논의중이구요. 여기에 뭐가 우려할 것이 있나요? "

글쎄요. 저는 MS나 소프트웨어 특권를 지지하는 미정부의 파워로 부터 자유로울 수 없는 현실에 제대로 이러한 MS에 제동장치가 가능하냐 이겁니다. 이번 특허만해도 그래요. 완전하고 투명한 개방이 아니잖아요. 그나마 이렇게 특허에 대해서 양보를 얻어 낼 수있었던 것도 MS가 저번 투표에서 실패했기 때문이죠. 얼마나 뻔뻔 스럽습니까? 애초부터 특허에 대해서 양보한게 아니란 말입니다. 그렇지만, 양보한 지금조차 부족하다고 보입니다.

OOXML이 통과되면 시끄러울 겁니다. 한동안 악취나는 규약의 분량과 특허에 대한 MS에 반독점위반에 조사는 유럽에서 계속될것이고, 그러는 와중에 특허문제로 크고 작은 재판들이 수도 없이 일어나겠죠... 이런 혼란을 왜 자초합니까?

깔끔하게 OOXML 채택안하면 되는 거죠. 아니면, MS가 모든 특허를 포기하고, 군더더기를 싸그리 제거한다던가요.

"MS가 이제는 반독점 소송에도 신경을 써야겠죠. 아마도 MS가 ie나 썬의 자바 물타기 같은 전력이 없었으면 이미 MS는 ODF지원을 선언했을 겁니다. 오픈소스 진영은 MS의 ODF 표준 채택에 환호하고.... 그리고 그 결과는 몇년뒤 ODF 물타기가 될 테구요."

한번 당하지 두번당하겠습니까? 이제는 MS의 M.O.를 확실히 알기 때문에 이전보다는 견제가 가능하죠. 판결이 있으니까요. 지금까지 MS는 표준이나 기존 업체가 가지고 있는 특허에 대해서 도전하는 것이 아무런 도움이 안된다는 것을 몇번 재판의 패소로 깨달았고, 결국 그래서 MS 스스로가 표준을 만들어 내려고 하는 것 아닙니까?

IBM,썬이 오피스시장을 독식할까 걱정입니까? 제가 볼때는 이 두 회사가 밀고 있는 오픈오피스가 제발 시장을 독식해줬으면 좋겠습니다. Free에다가 Free입니다. 오픈소스거든요. 독점이라도 독점이 아닌거죠.

이글 말고 다른 글에서 말했지만....
저도 MS라고 무조건 반대하는 것이 아닙니다.

오피스관련 규약에 관련된 특허 및 소스에 대해서 완전히 투명하게 공개하고,
만약, 플렛폼 의존적인 부분이 있으면 이 부분의 특허 및 소스 또한 공개한다면
저는 기꺼이 쌍수들고 환영하면서 찬성할 겁니다.

하지만, 이 수준이 안되기 때문에 반대할 뿐입니다.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

지리즈의 이미지

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

끝이죠.

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

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

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

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

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

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

linlin의 이미지

그런데 이번 ISO의 표준 선정 방식은 저도 좀 의문이긴 합니다. ISO 표준을 정하는데 왜 투표라는 과정이 필요한지는 이해가 잘 안되네요.

지리즈의 이미지

국제 표준을 정하는데, 국제적인 동의없이 진행할 수 있겠습니까?

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

linlin의 이미지

투표라는 과정은 기본적으로 찬반입니다. 안그래도 OOXML이 군더더기가 많다는 평이 많은데 이를 시정하려면 투표를 반복해 나가는 것보다 rfc 방식으로 직접 OOXML 표준을 고쳐나가는 표준 정립 프로세스가 더 바람직하지 않냐 이거죠.

지리즈의 이미지

어떤 국가는 특정한 기술에 대해서 우월한 지위를 가지고 있고,
다른 나라는 다른 기술에 대해서 그럴 수 있지요.
이러한 이해관계가 충돌하는 현실에서 의원회의 직권으로
표준을 제정하는 것은 문제가 많습니다.

ISO는 사실상 투표만 반복하는 것이 아니라,
반대를 던질때 반드시 반대 사유를 직시하게 되어 있습니다.
그래야, 제안하는 측에서 보완할 수 있기 때문이죠.
반복되는 투표과정을 통해서 내용이 다듬어져 가는 것이죠.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

linlin의 이미지

아마도 그렇게 투표과정을 보완해 놓고 있겠죠. ISO도 하루 이틀에 만들어진 체제가 아닐테니까요. 하지만 ISO의 표준 제정 방식이 달랐다면 애초에 OOXML의 표준 추진이 이렇게 심각한 논의 대상이 되지는 않았을 거라는 생각이 듭니다.

지리즈의 이미지

ISO에 기술지원 명목으로 MS가 천만달라 정도 기부하고,
바로 표준이 되었을 테니까요.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

linlin의 이미지

뭐 선거인들 일일이 찾아다니면서 적당히 뒤에서 쑤셔주는 것보다는 앞에서 한방에 뿌리는게 낫긴 하겠네요.

liberta의 이미지

(sigh)

미친눅대의 이미지

바닥에 있는 링크를 클릭하시면 editor가 쓴 편지를 읽을 수 있습니다.

ODF Editor Says ODF Loses If OOXML Does
Posted by kdawson on Wednesday March 26, @02:58AM
from the strange-bedfellow dept.

An anonymous reader writes "The editor of the Open Document Format standard has written a letter (PDF) that strongly supports recognizing Microsoft's OOXML file format as a standard, arguing that if it fails, ODF will suffer. 'As the editor of OpenDocument, I want to promote OpenDocument, extol its features, urge the widest use of it as possible, none of which is accomplished by the anti-OpenXML position in ISO,' Patrick Durusau wrote. 'The bottom line is that OpenDocument, among others, will lose if OpenXML loses... Passage of OpenXML in ISO is going to benefit OpenDocument as much as anyone else.'"

http://tech.slashdot.org/article.pl?sid=08/03/25/2150226

linlin의 이미지

상당히 재밌는 글인데... 이 글에는 다들 관심 없나요? ODF와 OOXML의 상호 의존 필요성을 얘기하고 있는데 말입니다.

only2sea의 이미지

관심이 있습니다. 그냥 대충 훑어봤는데 결국 OpenDocument에
있는 부족한 부분들을 채우는데 OpenXML이 도움이 될 것이고,
과거 MS 오피스의 문서들을 지원하는데 도움을 줄 것이라는
얘기군요. 이미 널리 퍼져있는 MS 오피스와 호환되지 않아서
생길 혼란 등에 대한 걱정도 있는 것 같구요.

이것이 잘 정비되어 OpenXML을 OpenDocument로 매핑할 수
있게 되어 OpenDocument가 기존 MS 워드 문서들을 지원할
수 있게 되고, OpenDocument를 원전하게 하는데 도움을 줄
수 있다면 좋겠습니다.

그렇다면, OpenXML은 하위 호환성에 대한 스펙으로 두고,
OpenDocument로 매핑될 수 있게 하여, 기존 문서들을 ODF로
깔끔하게 변환할 수 있게 되는 것을 생각해 봅니다.

그러나 여전히 문제는 OpenXML을 단지 OpenDocument를 서포트하는
정도의 위치로 두려고 할지에 대한 것입니다. 그리고 결국
구버전의 MS 오피스 포맷들을 제대로 ODF로 변환할 수 있는
자는 당분간 MS 뿐일 겁니다.

여튼, 생각하면 머리가 복잡해 집니다. 단순하게 생각하면 비교적
잘 정비된 ODF만을 이용하면 좋을 것 같습니다. 다른 표준들의
기반 위에 올라가 있어 훨씬 깔끔해 보입니다. 그러나 그렇다고
해서 MS 오피스가 기본 포맷을 ODF로 할 수는 없는 것이지요.

MS 역시 이윤을 추구하는 기업이라는 입장에서 볼 때 생각을 다시
해 봐야 할 것 같습니다. 게임이론에서 말하듯이 경쟁자가 있기
때문이죠.

어찌되었던 간에 ODF가 압도적으로 쓰이기는 당분간 어려울 것
같습니다. 그런 입장에서 OpenXML의 채택은 잘 되면 OpenDocument에
큰 도움이 될 수 있을 것 같습니다.

그러면 OpenXML이 채택되어 가장 좋은 시나리오가 되는 것과
OpenXML이 채택되지 않아서 가장 좋은 시나리오가 되는 것 중에
어느 쪽이 더 가망이 있을까요...? 잘 모르겠네요.

블로그: http://turtleforward.blogspot.com

linlin의 이미지

제가 보기에는 이렇습니다. 솔직히, 지금 상황에서 ODF나 OOXML모두 표준으로는 부족하지 않냐는 생각이 들어요. ODF와 OOXML이 일단 표준 경쟁을 한 다음에 승자가 문서 표준으로 입안 되는 것이 좋지 않나 싶습니다만 이건 선택지에서 이미 사라진지 오래구요... 대강 짐작을 해 볼때 아마도 IBM이 오피스 시장 진입을 위해 ODF를 한발짝 빨리 표준으로 밀어서 교두보를 확보하고 각국 정부에 로비를 해서 ODF에 필요한 최소한의 시장 점유율을 확대해가고 있지 않은가 하는 느낌이 들거든요. MS입장에서도 IBM은 상대하기가 상당히 껄끄러울 것이고 아직은 미지수이지만 구글 어플리케이션의 행보도 관건이구요.

결국 저 문서에서 관심을 둬야 할 부분은 이 부분인데요...

Quote:

OpenDocument currently lacks formula definitions for spreadsheets.

OpenDocument does not presently support legacy features of Microsoft formats.

OpenDocument does not have a robust mapping to the current Microsoft format.

즉 ODF 역시 현실적으로 어떤 형태로든 MS 오피스와의 호환을 고려하고 있다는 얘기입니다. 하지만 이 부분을 해 줄 수 있는 당사자는 결국 MS이고 MS가 표준의 형태로 이 정보를 제공하는 것이 가장 유리하지 않느냐라는 주장인데요.

그렇다면 ODF 진영에서 현실적인 방법 중의 하나는 OOXML의 시장점유율을 이용해서 ODF의 시장점유율을 같이 확대하는 방법인데 이를 위해서 어떤 방법이 좋은지는 저도 잘 모르겠네요. OOXML에 ODF와의 변환 표준을 집어넣어버리면 도움이 되는 것인지, 혹은 OOXML을 구버전 오피스에 종속적인 스펙과 아닌 부분을 분리시키면 가능한 것인지.. 여러가지 가능성이 있을 것 같습니다만 일단 현재 OOXML의 기능상의 풍부함과 기존 오피스의 시장점유율은 고려하지 않을 수 없는 상황이라고 봅니다.

linlin의 이미지

자꾸 re: re: re: 달리니 보기도 불편하고 그렇네요. 아랫쪽으로 내려왔습니다.

그런데... 정부의 문서표준 requirement가 어떻게 되는 겁니까? 이미 ODF로 선정 되었으면 그것으로 끝 아닌가요? 저야 정부는 표준은 어떤 것이든 지원만하면 업체들이 입찰을 할 수 있어야 한다고 생각하지만 ODF하나로 이미 정부가 결정났다면, 혹은 적어도 ODF가 정부 내의 문서포맷 독점을 획득했다면 이것만 해도 ODF가 생존하는 데는 확고한 기반을 잡은 것 아닌가요? 아래아한글도 정부 납품으로 잘 생존하고 있어요. 정부내에서 아래아한글만 쓰고 기타 오피스 패키지는 쓰면 안된다는 법도 없는데 말이죠.

깔끔하게 MS가 OOXML을 포기하면 된다고 생각하는데 미안하지만 이 옵션은 존재하지 않습니다. MS가 자선업체라면 또 몰라도 이익을 추구하는 업체가 어떻게 자사의 flagship 제품의 문서 포맷을 포기합니까? MS가 OOXML을 포기하게 만들려면 ODF가 OOXML가 제공하는 기능을 충분히 커버해야 해요. 그럴려면 적어도 ODF에서 앞으로 ODF에서 부족한 OOXML의 이런저런 기능들을 ODF쪽에서 추가하겠다는 명세서라도 내어 놓고 우리가 ODF 제대로 만들어 줄테니 MS 너네들 OOXML그냥 포기해라 주장을 해야죠. 그런데 여기서 ODF쪽 주장은 한결같이 OOXML의 스펙은 지나치게 구체적이고 구현에 비용이 많이들어간다는 반응이에요.

그리고 IBM이나 SUN을 그렇게 믿는 까닭은 뭐죠? 기업들은 모두 이윤동기에 의해 움직이고 가능한한 시장독점을 추구합니다. 만약 ODF가 차세대 표준으로 널리 쓰이게 된다면 IBM이나 SUN이 ODF에 물타기를 할 가능성을 어떻게 배제할 수 있는지 모르겠네요. 갑자기 IBM에서 오픈오피스 코드를 쓰지 않은 오피스 XXX 제품을 출시하면요? 오래전에 HTML이 나온지 얼마 안되었을때 netscape가 갑작스런 버전업에 많은 기능이 추가 되면서 mosaic나 그 당시 HTML표준에 본의아닌 표준 물타기를 한 것과 비슷한 상황은 언제든지 나올 수 있어요. 오픈오피스가 mosaic 꼴이 되는 것은 시장에서의 ODF의 인기 여부에 달려 있는 겁니다. 오픈오피스는 꽤 괜찮은 제품이지만 killer application으로 불리기는 부족한면이 많아요.

또.. OOXML이 통과되면 오히려 MS에 대한 반독점 소송은 없어집니다. 표준 제정 자체가 경쟁사에게는 진입장벽을 낮추는 결과로 이어지니 반독점 소송은 처음부터 할 수 없어요. 사실 MS는 이것을 거래 조건으로 내걸고 있다고 봐요. 규격을 너네들이 믿을 수 있을 정도까지 오픈할테니까 우리네의 현재 시장점유율 파워는 인정해 달라는 것이죠.

뭐 이미 지금 투표 과정에서 님이 얘기하는 MS 오피스 관련 규약의 특허의 문제는 이미 claim이 제기되어 있고 플랫폼 의존적인 부분 역시 claim이 들어가 있습니다. 한국 대표단이 이를 조건으로 찬성표를 던질 정도면 다른 나라라고 사정은 다르지 않을 거라고 봅니다. 그렇다면 상황은 님이 이걸 "쌍수들고 환영"해도 되는 쪽으로 가고 있는거에요.

어쨌든 전 도통 이해하기 어려운 것이 어떻게 MS가 자사의 제품에서 자기네의 문서포맷을 포기할 것을 타인들이 강요할 수 있는가 하는 점입니다. 이건 원래 가능한 일도 아니고 실제 그렇게 했을때 일반 유저들이나 개발자들에게 도움이 되지도 않습니다. 또한 MS정도로 기능적으로 우수한 오피스 제품을 만들어 온 회사라면 문서 표준을 제안할 자격 역시 충분합니다. 시장 독점의 우려는 그 다음에 고려하는게 타당합니다.

imyejin의 이미지

Quote:
또.. OOXML이 통과되면 오히려 MS에 대한 반독점 소송은 없어집니다. 표준 제정 자체가 경쟁사에게는 진입장벽을 낮추는 결과로 이어지니 반독점 소송은 처음부터 할 수 없어요. 사실 MS는 이것을 거래 조건으로 내걸고 있다고 봐요. 규격을 너네들이 믿을 수 있을 정도까지 오픈할테니까 우리네의 현재 시장점유율 파워는 인정해 달라는 것이죠.

아놔 진짜 말귀를 못알아들으시는데, 그게 바로 문제라는 겁네다. 표준을 제정해도 독점적으로 그 표준을 구현할 수 있는 건 M$ 밖에 없는 수준으로 표준안을 쓰레기처럼 만들어 와서 한참 청소하고도 아직 더 청소해야 있을지 모르는 식으로 무식하게 가져온 걸 표준으로 우겨넣으면서 반독점 소송마저 못하게 면피하려는 거잖아요. 본인 입으로 문제를 실토하면서도 뭐가 문제인지 알지 못하니 정말 작정하고 낚시하자는 건지 뭔지 ...

MS 오피스가 우수한지 아닌지는 판단을 일단 보류하고 님 말대로 매우 우수한 제품이라 치더라도, 어떤 회사가 만든 하나의 제품이 매우 우수하다고 하여 그 회사가 작성안 표준안이 거지같지 않으라는 법은 절대로 없습니다. 그리고 제품 상세 스펙과 버그목록이랑 표준과는 뭐가 다른지부터 복습하시는 건 이 글타래만 제대로 읽었어도 이미 다 학습이 되셨을 텐데 말이죠.

플랫폼 의존적인 것만이 문제가 아니라 OOXML 디자인 철학 자체가 좀 황당합니다. XML을 비상식적으로 사용하는 경우도 많고요. 그나마 OOXML보다는 단순하다는 ODF마저도 XML의 장점과 W3C에서 권장하는 Xpath 등의 XML활용 표준을 십분 활용하지 못하다고 비판을 받고 잘 고쳐 나가자는 상황이었는데 OOXML로 완전히 깽판을 놓겠다는 건지 뭔지.

linlin 님이 그렇게 열내지 않고 비표준이 되어도 MS는 반독점법에 변호사나 열심히 사서 쓰면서 오피스 장사 하면 되는데 뭘 그리 걱정(?)하시면서 표준의 자격이 안되는 걸 표준이 되어야 한다고 강변하시는지 모르겠군요. 제가 말씀드렸잖아요 그냥 de facto standard 를 당분간 유지하면 된다고요. 인내심이 많으신 지리즈님께서 열심히 설명을 해 줘도 계속 똑같은 말만 앵무새처럼 반복하면 어쩌자는 것입니까? -_-

국제 표준 저렇게 아무렇게나 만들 거면 C나 C++ 표준 만드는데는 뭐하러 십여년씩이나 걸리고 최근까지도 개정안 나오나요? 그냥 많이 쓰던 gcc 나 msc 컴파일러 매뉴얼을 표준으로 하면 되지. 이건 뭐 완전 여태까지 표준안 만들던 위원회를 바보 만드는 것도 아니고 ... 이런 황당한 표준을 이렇게 열성적으로 옹호할 수 있다는 것 자체가 대단히 놀랍습니다.

제발 표준에 대한 개념부터 제대로 탑재하고 와서 토론을 하시길 바랍니다. 표준이라는 게 대체 어째서 M$ 오피스가 구현하는 모든 기능을 다 구현해야 합니까? 내 듣다 듣다 이런 무개념한 말은 또 처음 듣습니다. 표준은 공통적이로 확고한 사항만을 반영해서 일단 만들어서 구현하는 업체나 사람들이 일단 그것을 만족하고 난 다음, 필요에 따라 널리 쓰이는 확장 기능을 표준에 반영해 추가해 나가는 것이 일반적인 표준안 개정 과정이랍니다. (이런 것까지 설명해 줘야 하나요?)

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

linlin의 이미지

Quote:

아놔 진짜 말귀를 못알아들으시는데, 그게 바로 문제라는 겁네다. 표준을 제정해도 독점적으로 그 표준을 구현할 수 있는 건 M$ 밖에 없는 수준으로 표준안을 쓰레기처럼 만들어 와서 한참 청소하고도 아직 더 청소해야 있을지 모르는 식으로 무식하게 가져온 걸 표준으로 우겨넣으면서 반독점 소송마저 못하게 면피하려는 거잖아요. 본인 입으로 문제를 실토하면서도 뭐가 문제인지 알지 못하니 정말 작정하고 낚시하자는 건지 뭔지 ...

말귀를 못 알아듣긴요. 그게 어떻게 문제가 됩니까? 님 얘기는 표준이라는 공공재를 MS가 사실상 "독점"할 것이라는 주장이잖아요.

그런데 MS얘기는 이제 OOXML은 doc이나 xls 포맷처럼 "독점" 안 할 테니 이제 우리를 좀 믿어달라는 취지아니겠어요? 좋아요. 여기서 님 같은 사람들이 MS너네들 또 사실상 "독점"을 하지 않는다는 것을 어떻게 믿냐? 당연히 의문을 제시하겠죠. 여기에 MS 대답은 그럼 너네가 우리를 믿을 수 있도록 OOXML 규격을 MS 소유로 두지 말고 아예 표준으로 해서 공공재화 시키면 되지 않겠느냐에요. 그럼 님은 여기에 어떤 답변을 할래요? 이렇게 해도 왜 MS가 표준이 된 OOXML을 독점할 수 있는지 근거를 대 보세요. 뭐 여기에 아마도 스펙 구현이 100% 되는 곳은 MS 밖에 없으니 사실상 독점이다 답변이 나오겠지만 어쨌든 한번 근거를 좀 대 보세요.

Quote:

제발 표준에 대한 개념부터 제대로 탑재하고 와서 토론을 하시길 바랍니다. 표준이라는 게 대체 어째서 M$ 오피스가 구현하는 모든 기능을 다 구현해야 합니까? 내 듣다 듣다 이런 무개념한 말은 또 처음 듣습니다. 표준은 공통적이로 확고한 사항만을 반영해서 일단 만들어서 구현하는 업체나 사람들이 일단 그것을 만족하고 난 다음, 필요에 따라 널리 쓰이는 확장 기능을 표준에 반영해 추가해 나가는 것이 일반적인 표준안 개정 과정이랍니다. (이런 것까지 설명해 줘야 하나요?)

그리고.. 덧붙여서 그럼 님 얘기대로 MS가 "M$ 오피스에서 구현하는 기능"의 상당수를 빼고 표준을 제시하면 누가 MS를 믿어 줄 수 있습니까? MS가 님 얘기대로 공통적이고 확고한 사항만을 반영해 표준 제안을 한다면 그것이야말로 MS가 이제는 표준까지 이용해서 시장 독점을 확고히하려는 의도에 대한 확실한 증거가 되는 것 아니에요? 님 얘기대로라면 실제 구현의 detail한 스펙들은 모조리 MS 멋대로인데 경쟁사들이 어떻게 이 표준을 구현할 수 있나요?

도데체 제가 무개념한건지 님이 무개념한건지 모르겠군요. 냉수라도 좀 먹고 오시길.

kslee80의 이미지

Quote:
말귀를 못 알아듣긴요. 그게 어떻게 문제가 됩니까? 님 얘기는 표준이라는 공공재를 MS가 사실상 "독점"할 것이라는 주장이잖아요.

그런데 MS얘기는 이제 OOXML은 doc이나 xls 포맷처럼 "독점" 안 할 테니 이제 우리를 좀 믿어달라는 취지아니겠어요? 좋아요. 여기서 님 같은 사람들이 MS너네들 또 사실상 "독점"을 하지 않는다는 것을 어떻게 믿냐? 당연히 의문을 제시하겠죠. 여기에 MS 대답은 그럼 너네가 우리를 믿을 수 있도록 OOXML 규격을 MS 소유로 두지 말고 아예 표준으로 해서 공공재화 시키면 되지 않겠느냐에요. 그럼 님은 여기에 어떤 답변을 할래요? 이렇게 해도 왜 MS가 표준이 된 OOXML을 독점할 수 있는지 근거를 대 보세요. 뭐 여기에 아마도 스펙 구현이 100% 되는 곳은 MS 밖에 없으니 사실상 독점이다 답변이 나오겠지만 어쨌든 한번 근거를 좀 대 보세요.

용어를 혼동해서 쓰고 있으시군요.
'사실상의 독점' 이라는 이야기에서의 독점의 의미와,
'포맷의 독점' 이라는 이야기에서의 독점의 의미가 같다고 생각하십니까?
지금 OOXML 에 대해서 독점 이야기가 나오는게 '포맷의 독점' 때문에 나오는 거라고 생각하시는 겁니까?

Quote:
그리고.. 덧붙여서 그럼 님 얘기대로 MS가 "M$ 오피스에서 구현하는 기능"의 상당수를 빼고 표준을 제시하면 누가 MS를 믿어 줄 수 있습니까? MS가 님 얘기대로 공통적이고 확고한 사항만을 반영해 표준 제안을 한다면 그것이야말로 MS가 이제는 표준까지 이용해서 시장 독점을 확고히하려는 의도에 대한 확실한 증거가 되는 것 아니에요? 님 얘기대로라면 실제 구현의 detail한 스펙들은 모조리 MS 멋대로인데 경쟁사들이 어떻게 이 표준을 구현할 수 있나요?

경쟁사중에 OOXML 을 구현한 곳이 있습니까?

페이지