OOXML, OWPML 모두 공공문서 포맷으로 부적절

'전자문서 산업을 위한 학술 토론회' 관련 기사:

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20140725153903

OOXML은 ISO/IEC 29500 표준으로 MS 오피스의 포맷이고 (docx, pptx 등), OWPML은 KS X 6101 표준으로 한컴오피스2014부터 hwpx라는 이름으로 (아직은 시험적인) 포함된 포맷이다.

이 학술 토론회에서는 업체 사람들이 서로 자기 업체의 포맷을 가지고 자기 포맷이 더 개방적이고 표준으로 바람직한 공공문서 포맷이라고 주장하고 있으나, 사실 OOXML이든 OWPML이든 공공 문서 포맷이 되기에는 마찬가지 문제를 가지고 있다.

OOXML

OOXML의 문제는 이미 과거 표준화 과정에서부터 충분히 알려진 바 있다.

마이크로소프트 측은 6000 페이지의 문서로 구성된 표준을 급행으로 검토할 시간도 주어지지 않은 채 진행하면서, 그 전에 기존에 표준 결정 기구에 가입하지 않은 개발도상국가에 입회비를 지원한 스캔들이 있었다. 이들 개발도상국가가 표준안에 찬성표를 던진 것은 물론이다. (대한민국은 최종적으로 반대에 투표했다.)

http://www.zdnet.co.kr/column/column_view.asp?artice_id=00000039161482

기술적으로도 알려진 것만 해도 그렇다. OOXML은 기존의 바이너리 오피스 포맷을 가지고 XML을 컨테이너로 이용한 것 뿐이다. 이러면 XML 파서로 읽을 수 있을 뿐 기존 오피스 포맷과 다를 게 없다. 대표적인 예로 드는 useWord97LineBreaks attribute는 "Word97방식으로 렌더링하라"라고 지정되어 있고 그 Word97 방식이 무엇인지 설명하지 않는다.

http://msdn.microsoft.com/en-us/library/documentformat.openxml.wordprocessing.useword97linebreakrules%28v=office.14%29.aspx

OOXML은 마이크로소프트 사의 역사적인 이진 형식을 주의 깊게, 하나도 빠뜨림 없이, 꼼꼼하게 XML 형식으로 복사한 결과물일 뿐이다.

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

IBM Developer Works, "OOXML 무엇이 그리 대단한가 " 중에서, http://moonistar.tistory.com/m/post/16

OWPML

이 글을 쓰기 시작한 이유가 바로 이 포맷 때문이다. 올해 초에 직접 KS X 6101 표준 문서를 구입해서 한컴오피스 2014 체험판의 HWPX 결과물과 같이 검토해 봤기 때문이다.

바이너리 MS 오피스 포맷을 XML로 옮긴 게 OOXML이라면, 바이너리 HWP 포맷을 XML로 옮긴 게 바로 OWPML이다. 이것 뿐이다. XML의 파일 하나하나는 HWP에 있던 Compound Document의 스트림 하나하나에 대응하고, XML 태그 하나하나는 HWP에 있던 레코드 정보에 대응하고, XML 속성(attribute)은 레코드의 바이너리 데이터에 해당한다. IP over XML 같은 만우절 장난이라면 몰라도, 이런 포맷을 만드는 게 무슨 의미가 있는 걸까?

KS X 6101 역시 OOXML 포맷과 같은 오류를 저지르고 있다. 무엇무엇이 있다라는 설명만 하고 실제 어떻게 구현되는지 제대로 설명하지 않아 사실상 한글과컴퓨터의 구현만이 알 수 있게 되어 있다. 예를 들어 표준 7.1에 보면 XMLTemplate/ 이라는 폴더에 대해 언급했으면서 표준 문서 다른 어디에도 여기에 대한 설명이 없다.

또 한 가지 예를 들면 표준 문서 "8.2.4 호환성 정보"를 보면 "compatibleDocument" 태그가 있다.

<compatibleDocument  targetProgram="MS_WORD">...

이런 식으로 쓰면 붙이면 MS-Word 방식으로 렌더링한다. 앞의 OOXML에 있던 useWord97LineBreaks 속성이 생각나는 부분이다. 이 MS-Word 방식이 무엇인지는 알 길이 없다. 원래 HWP 포맷에도 마찬가지의 호환성 문서 정보가 있는데 이 정보까지 OWPML에 그대로 구현해 놓은 것이다. 한컴오피스에서 MS-Word 문서가 상당히 잘 변환되는 비밀이 여기 있다. HWP 포맷에 MS-Word 호환 모드가 있고 한컴오피스에 MS-Word와 비슷한 렌더링 방식을 구현해 놓은 것이다. 이런 것까지 표준에 포함하면 표준 구현은 한컴오피스가 한 것처럼 MS-Word 렌더링 방식까지 따라해야 한단 말인가?

이런 문제점을 지적해야 할 표준 심의 과정도 문제였다. KS X 6101:2011 문서의 해설에 기록되어 있는 표준 제정 과정의 7가지 심의 의견 중에서 문제를 지적한 의견이 6가지인데, (1) 표준 제목 수정 (2) 오타 수정 (3) HWP 약자 설명 추가 (4) ODF, OOXML 상호운용성 추가 (5) ODF, OOXML 인용 추가 (6) 수식, 화학식 누락. 이 중에서 (1)(2)(3)(5)은 단순 수정이고, (4)는 이 표준에서 해당하지 않는다고 조치했고, (6)에서 수식이 추가 된 게 그나마 유일하게 의미 있는 문제점 수정 사항이었다. 한글과컴퓨터에서도 최근 한컴오피스2014에서 처음 구현했으니 검증될 기회도 없었다.

OOXML과 마찬가지로 똑같은 포맷을 XML로 감싼다고 해서 구현할 수 있는 건 아니다. 검토했던 결과를 다음 페이지에 기록해 놓았다.

https://docs.google.com/spreadsheet/ccc?key=0AjxIVzS0OjQTdEc5V1dhLWJwenhSTEpPWGNMdy12NUE&usp=sharing

기록한 것과 같이 OWPML은 표준에도 오류가 있는데, 이 포맷을 최초로 구현한 한컴오피스 2014의 HWPX 포맷에서도 표준에 없거나 표준과 다르게 사용하고 있다.

ODF 뿐이다

아무리 OOXML과 OWPML이 표준으로 인정받았더라도, 의도적이든 아니든 사실상 특정 업체 독점적이 될 수밖에 없도록 기술된 포맷은 공공문서의 포맷이 되면 안 된다. 현재 나와 있는 해법은 ODF 뿐이다. ODF는 다들 좋아하는 그 표준을 국제/국내 모두 오래전에 획득했다.

물론 같은 학술 대회에서 다음과 같이 한컴 측이 주장한 것과 같이 ODF도 구현별로 차이가 나는 것도 사실이다.

또 국제표준이 만능이 아니라고 반박했다. 그는 “MS 오피스도 환경에 따라 레이아웃이 깨지는 경우가 많고, ODF도 오픈오피스, 심포니, MS 오피스 등 구현회사마다 조금씩 차이가 있다”고 말했다.

http://www.ddaily.co.kr/news/article.html?no=120789

하지만 구현 과정에서 조금 차이가 난 것과, 아예 기본적인 명세부터가 제대로 독립적으로 구현하기 힘든 것과는 천지 차이이다. (게다가 오픈오피스는 오픈소스이고, 심포니는 오픈오피스 기반으로 개발된 것이다. MS 오피스의 ODF 지원 기능은 외부에서 만든 플러그인이 더 낫다고 할 정도로 완성도가 낮아서 생긴 일이다.  http://en.wikipedia.org/wiki/OpenDocument_software#Microsoft_Office_2007_SP2_support_controversy )

ODF를 사용하도록 규칙을 제정하고, 공공에서 사용하는 한컴오피스에 대해 기본 포맷을 ODF로 저장하도록 하는 게 처음 한 걸음이 될 것이다. 문제가 되는 HWP 문서 생산을 멈춘 다음 과거 HWP 문서의 변환도 고민하자.

OSI approved 라이선스가 인정받지 못하는 케이스

최근의 오픈프론티어 오픈소스 라이선스 세미나에서 발표했던 사례,

http://www.slideshare.net/changwoo/20140715-37005257


예외적인 케이스에 대한 이야기는 보통 재미있다. 지금까지 갖고 있던 생각이 고정관념이 아니었나 한번 쯤 가다듬는 기회가 되기 때문일 것이다. 재미있는 케이스를 찾다 보면 지나치게 예외적인 이야기에 치중할 수도 있는데, 이 경우는 한번 OSI-approved 라이선스의 예외적인 경우를 지적해 보고 싶었다.

예로 들었던 예외는 NASA Open Source Agreement(NOSA)라는 라이선스이다. NASA(미항공우주국)는 유일무이한 일을 하는 기관이니만큼 다른 곳에서 보기 힘든 상당히 흥미로운 소프트웨어를 공개하고 있다.

http://ti.arc.nasa.gov/opensource/

여기 사용되는 라이선스가 이 NOSA 라이선스이다. 예외로 들었던 이유는 이 라이선스는 OSI approved 라이선스이지만, FSF나 데비안은 거절했기 때문이다.

http://www.gnu.org/licenses/license-list.html#NASA

문제되는 조항은 이 부분인데

G. Each Contributor represents that that its Modification is believed
to be Contributor's original creation and does not violate any
existing agreements, regulations, statutes or rules, and further that
Contributor has sufficient rights to grant the rights conveyed by this
Agreement.

문제되는 부분이 "original creation"으로, 수정을 할 때는 수정한 부분이 자기의 독자적인 창작물이어야 한다는 것이다. 다른 소프트웨어에서 (같은 NOSA 라이선스라고 해도) 붙여 넣는 것도 안 되고, 이 코드를 다른 소프트웨어에 붙여 넣는 것도 안 된다. 수정하는 방식을 이런 식으로 제한하는 일이 수정을 보장하는 것으로 볼 수 있을까? 수정하는 방식에 제한을 두면 가혹하다고 생각하지만, 어떻게든 수정을 보장하고 있으니까 오픈소스 아니냐고 하면 그럴듯하기도 하다. (GPL이나 다른 많은 라이선스는 수정한 부분의 라이선스를 제약하고 있지 않은가?)

OSI에서 허용했는데도 불구하고 FSF나 데비안에서 이 라이선스를 거절한 이유를 정해진 규정이나 원칙에서 찾기는 힘들다. 데비안이 거절한 것은 더 흥미롭다. Bruce Perens가 오픈소스정의(Open Source Definition)를 만들 때 데비안 자유소프트웨어 가이드라인(DFSG)을 가져다 만들었으니 OSI나 데비안이나 기본 원칙은 다르지 않다. 즉 이 결정은 오픈소스정의와는 상관없는 부분이라는 뜻이다.

오픈소스의 기준이 Open Source Initiative가 정한 것이므로, OSI approved면 오케이라는 생각은 대부분 맞겠지만, 이런 경우가 있으므로 절대적인 기준으로 삼기는 힘들 것이다. OSI approved라고 해서 특정 기관이나 특정 필드에서 쓰도록 설계된 라이선스를 그 외의 분야에서 가져다 쓰는 것도 바람직하지 않고 말이다. 대부분의 사람들이 동의하는 많이 쓰는 라이선스를 쓰는 것이 바람직하다고 할 것이다.

freshmeat이 망한 이유

Bad Voltage 팟캐스트 1x19 에피소드 중에서 freecode(freshmeat)와 관련된 얘기,

http://www.badvoltage.org/2014/06/26/1x19/ (33:20부터)

리눅스 배포판 개발과 사용에 있어서 생각할 만한 게 많은 것 같아서 해당 부분을 대략 번역한다.

<Jeremy> 며칠 전에 freecode, 과거에 freshmeat였던 사이트가 고정 웹사이트로 변했어요. 여러분이 옛날 freshmeat을 얼마나 쓰셨는지 모르겠지만, 제 생각에는 엄청나게 유명했던 곳이었어요. (모두 공감) 그런 점에서 몇 가지 의문이 드는데요. 진짜 이유가 무엇이라고 생각하시나요? 오늘날 리눅스 소프트웨어에 무슨 일이 일어난 걸까요? 앱스토어같은 것 때문일까요, 그냥 패키지가 잘 동작하기 (just work) 때문일까요. 무슨 일 때문에 이렇게 된 것일까요.

<Stuart> 그건 이제 아무도 GIMP 0.1 alpha를 다운로드하지 않기 때문이죠. (모두 웃음)

<Jeremy> 한 가지 지적할 점은 그 당시는 다른 어떤 사이트보다도 freshmeat이 소프트웨어의 최신 내용을 담고 있었어요. 심지어 메인테이너들이 자기 홈페이지보다 더 freshmeat에 먼저 발표하곤 했죠.

<Bryan> 네 그 점이 핵심이예요. 그 당시에는 신선(fresh)한 내용이었죠. 그런데 이제는 신선한 내용이 아니니까 아무도 신경쓰지 않게 됐죠.

<Jono> 그냥 고기(meat)죠. (웃음)

<모두> 네 오래된 고기(old meat)예요.

<Stuart> 네 바로 그 부분이에요. 재미있는 부분이 Jeremy가 말한 그대로예요. 10-15년 전에는 모든 소프트웨어 메인테이너들이 freshmeat를 썼어요. freshmeat이 유일한 수단이었죠. 하지만 더 이상 아니에요? 왜일까요?

<Bryan> 제 생각에 큰 부분은, 당시에는 패키지 관리는 새로운 개념이었어요. RPM 패키지 관리는 얼마 안 됐고 데비안은 패키지 관리가 당시에도 있었지만 데비안을 모두가 쓰지는 않았죠. 그래서 기준이 freshmeat로 가서 tarball을 다운로드한 다음에 빌드하는 거였어요. "./configure; make; make install"하는 거죠. 또, 제가 기억하기에는 freshmeat에 등재되는 게 일종의 훈장 같이 취급됐어요. "우와 freshmeat에 올라간 소프트웨어라니 멋지다"라고요. ("맞아요 맞아")

<Bryan> 그런데 그 일부분을 배포판들이 대체했어요. 또 소프트웨어를 직접 다운로드해서 설치하는 방식은 사용하지 않죠. 폰이나 데스크톱에서도 더 이상 그렇게 하지 않아요.

<Bryan> 또 한 가지 제 느낌에는, freshmeat을 소유한 회사에 대해서 잘은 모르지만 sourceforge도 인수했죠? 제 생각에 이건 리소스 낭비였어요. 이제 아무도 freshmeat을 신경쓰지 않아요.

<Jono> 저는 이게 리눅스만의 이슈가 아니라고 생각해요. 당시에는 맥의 경우에도 versiontracker라는 기본적으로 freshmeat과 똑같은 일을 하는 사이트가 있었어요. 당시에도 거기 가면 각종 업데이트된 정보가 들어 있었죠. 모든 맥 유저가 그 사이트를 봤어요. 윈도우 사이트도 마찬가지로 있었고요. 하지만 지금은 비슷한 일을 하는 오만가지 경쟁자들이 나타났고 중앙 집중적인 한 사이트가 이제 없어요. 어떤 사이트를 가도 최신 업데이트된 내용을 담고 있다고 확신할 수 없게 됐죠. 그러니 아무 것도 사용하지 않게 된 거고요. (...)

<Stuart> 네 같은 비극이 일어난 것 같네요. freshmeat 1개 사이트만 있을 때는 이 사이트에 모두 있는데,  누군가 "야 freshmeat같은 사이트를 만들면 돈을 벌 것 같아" 하면서 사이트가 2개 3개가 되면서 모든 사이트의 가치가 제로가 되고 더 이상 이용하지 않게 되는 거죠.

<Jono> 일반적으로는 동의해요. 다른 얘기를 하면 이제 데비안 패키지 저장소도 있고, 우분투도 있고 페도라도 있어요. freshmeat은 상당히 리눅스에 치우쳐져 있잖아요? 당시에는 크로스 플랫폼 이었어요. 모든 소프트웨어가 어떤 배포판에도 돌아갔죠. 직접 컴파일하니까요.

<Stuart> 정확히 말해서 크로스 리눅스겠죠?

<Jono> 아 미안해요. 네 크로스-리눅스배포판이죠. 그런데 점점 자기 소프트웨어를 데비안, 우분투 또는 페도라에서 컴파일하겠다라고 말하고 다른 배포판은 신경쓰지 않겠다라고 말하는 게 허용되는 분위기예요.

<Stuart> 거기에 대해서 일부 이유를 말하면, 우분투와 페도라가 상당히 달라요. 당시에는 예를 들어 슬랙웨어와 데비안은 별로 다르지 않았어요. 각종 설정 옵션이 다르기도 하고 네트워크 파일 방식이 다르고 그런건 있지만 기본적으로 어떤 배포판을 쓰든 같은 사용자 경험을 공유했죠. 분화되지도 않았는데, 이유 중 하나는 당시에는 달라져야 한다는 요구 사항이 별로 없었어요. 그럴 시간도 없고요.

<Jeremy> Jono의 의견에 동의해요. freshmeat은 "configure; make; make install"시대의 산물이죠. 한 가지 더 문제를 말씀드리면 제가 과거에 freshmeat 이용을 중지한 건 사이트를 개편하면서 부터에요. 사이트의 대부분의 기능을 없애 버렸죠. 당시에 제가 이용했던 건 trove 였는데.. trove는 잘 관리되고 있고, 예를 들어 파이썬으로 작성된 BSD 라이선스의 메일 클라이언트를 찾는 건 trove 계층에서 쉽게 찾을 수 있었어요. 그런데 freshmeat 사이트가 개편되면서 그 데이터를 통째로 잃어버렸죠. 그리면서 소프트웨어 센터, 패키지 관리 따위가 쓸만한 수준으로 좋아졌고요. 어쨌든 사이트를 개편한 게 큰 역할을 했어요.

<Stuart> 네 옛날에 "fm"이라는 freshmeat의 trove를 이용해 검색하고 결과를 출력하는 프로그램을 작성했던 기억이 있네요. 사이트가 개편되면서 동작을 안 했고요.

<Jono> 사이트 관리가 문제였던 것도 맞아요. 그리고 주인이 많이 바뀌었어요. 기억이 가물가물한데 slashdot과 합병했죠? ("네") 그리고 ("geeknet으로 갔다가, 그 다음엔 다시 sourceforge랑 합병하고.,."). 하고 싶은 말은 사이트의 자산이 회사를 거쳐가면서 이익이 되는 slashdot과 geeknet에 자원이 집중됐을거예요.

(...) 개인적으로 이제 저는 소프트웨어를 컴파일하는데 신경 쓰지 않아요. 여러분이 KDE에 기여하는 사람이라면 아마 KDE 컴파일에 신경 쓰겠지만 파이어폭스나 커널을 빌드하지는 않을 거예요.

<Bryan> 제 생각에 freshmeat이 이제는 의미가 없더라도, 고정 페이지로 남겨두고 최소한 과거 컨텐츠를 볼 수 있다는 건 괜찮은 것 같아요.

<Jeremy> 실제로 ESR이 다른 이름으로 freshmeat을 되살리려고 하는 거 알아요?

<Bryan> 진짜요?

<Jeremy> VA의 이사회 멤버라서 slashdot과 freshmeat을 인수하라고 설득한다는데요. 그래서 사이트를 다시 시작한다고요. ESR이 말하는 건 사람들이 다운로드하지 않는다고 해도, 패키징하는 사람은 패키징할 걸 어디서 찾아야 하지 않느냐는 거예요.

<Bryan> 음, 사실 중요한 부분이긴 해요. 알게 뭐예요. ESR이 그러고 싶다는데.

<Jono> 하하. 제가 배포판 작업을 하면서 한 가지 배운 게 있는데요. 배포판에서는, 항상 패키징할 게 있어요.

<Stuart> 아이고 ESR이 말하려고 하는 건 잘 알겠어요. ESR이 당시에는 유명한 사람이었고요. 그 당시의 방식을 좋아할 수도 있죠. 근데 지금 15년 전 웹사이트를 살리려고 하고 있어요. 오래 된 건 그냥 넘어가지.

<Bryan> 이봐요. 저는 아직도 BBS를 돌리고 있어요. 오래된 건 멋져. (웃음)

(2014.7.13 업데이트)

의미 있게 생각했던 이유는, 마치 "Video killed the radio star"와 같은 얘기를 듣는 것 같아서였다. 리눅스 배포판이 freshmeat을 죽였다. 딱히 내가 라디오 스타의 팬은 아니고, 오히려 죽이는데 일조했던 입장이지만.

사실 상업 운영체제에서 최근에서야 시작한 온라인 소프트웨어 배포 및 업데이트 시스템은 데비안이나 리눅스 배포판에서 먼저 생겨났다. 상업 운영체제에서 최근에 가능했던 이유는 독점적인 정책을 가진 운영체제나 디바이스를 가진 큰 회사가 등장했고 대규모 IT 인프라를 구축할 수 있었기 때문인데, 리눅스 배포판에서는 역설적으로 소스코드가 있으며 수정과 배포가 자유로웠기 때문에 얼마든지 일관성 있는 패키지를 노력만 하면 만들어 낼 수 있었고, 세계 곳곳의 미러사이트에 복사를 해 놓을 수 있었다. 결제나 사용자 정보를 신경 쓰지 않아도 됐고 말이다. 데비안에서는 패키지 업데이트 시스템인 APT가 1998년에 만들어졌고, 그 전에도 dselect라는 프로그램에 FTP나 HTTP를 통해 패키지 업데이트를 할 수 있었다. 그래서였는지 나는 당시에도 FTP 사이트에서 패키지 자동 업데이트를 했지 freshmeat에서 확인한 소프트웨어를 다운로드해서 설치하는 일은 별로 없었던 것 같다.

이 후 직접 데비안 개발자가 되고, 패키징을 하면서 날이 갈수록 더 배포판의 영향력은 커짐을 느꼈다. 상업적인 배포 시스템처럼 프로모션을 하는 건 아니지만, 배포판은 항상 앞에 나서서 소프트웨어를 선택하는 일을 했다. xfree86의 라이선스 변경에 반발한 리눅스 배포판들이 xorg를 선택한 결과 지금 xfree86은 홈페이지만 남아 있을 뿐이고, LibreOffice를 선택한 결과 Apache OpenOffice보다 (커밋 수로 보든 개발자 수로 보든) 몇 배 더 개발이 빠르게 진행되고 있다. 배포판이 기본으로 선택한 데스크톱 환경이 사용자가 급증하는 모습을 보이기도 했다. 처음 데비안 프로젝트는 데비안 홈페이지에 써 있는 것처럼 "Universal OS"를 만들려는 목적이었겠지만, 이제는 사용자의 선택에 영향을 미치는 소프트웨어 배포 채널이 되어 버렸다.