MS의 "Open XML"을 반대해야 하는 이유

권순선의 이미지

오픈소스 관련된 이슈가 그다지 큰 관심을 끌지 못하는 우리나라에서는 별다른 이슈가 되지 않았지만, 지난 몇 주 동안 나라 밖에서 꽤 논란이 되었던 것이 바로 MS의 Open XML과 관련된 내용들입니다. 일단 다음 slashdot 기사들을 참고하십시오.

Open XML은 MS가 차기 오피스 파일 포맷 표준(?)으로 밀고 있는 스펙입니다. 제가 여기서 '표준(?)'이라고 표기한 이유는 이와 관련해서 오픈소스 커뮤니티 내부는 물론 외부로부터 우려의 목소리가 많이 들리고 있기 때문입니다. 아래 링크들을 참고하세요.

위의 두 글에서 공통적으로 지적하고 있는 것은 MS의 Open XML이 'open', 'standard', 그리고 'xml' 등 기존의 'closed', 'proprietary' 등으로 대변되던 MS의 전략과 상반되는 것처럼 보이지만 실제로는 전혀 그렇지 않으며 기존의 전략의 연장선상에서 진행되고 있다는 것입니다.

가장 큰 이유로는 Open XML 스펙의 분량이 무려 4000여 페이지에 달한다는 것입니다. 이게 왜 이렇게 방대하냐면 Open XML 이 결국 'open', 'standard', 'xml' 등의 듣기 좋은 껍데기를 씌웠을 뿐 내부적으로는 기존의 오피스 파일 포맷과 관련된 내용들을 거의 대부분 포함하고 있기 때문이라고 합니다. 이정도 되는 분량의 스펙을 100% 정확하게 만족시키기는 현실적으로 매우 어렵고, 더구나 스펙 자체가 100% 클리어하게 작성되어 있지 않아 결국 세세한 내용에서는 MS만이 이해할 수 있는 내용들이 포함되어 있을 것이라고 하는데, 그 근거로 Open XML은 SVG나 MathML과 같은 공개 표준들을 수용하지 않고 있는 것을 들고 있습니다. 그래서 결국 이를 만족하는 소프트웨어는 오직 MS만이 만들 수 있기 때문에 오픈소스 진영에서는 아무리 잘 해도 기껏해야 Open XML의 오직 일부분만을 만족시키는 것에 그친다는 것입니다. 그러면 결국 ODF --> Open XML로의 수렴 현상은 쉽게 일어나지만 Open XML --> ODF 로의 수렴 현상은 기대하기 어렵겠죠. (MS로서는 일면 당연한 선택이라고 할 수 있겠습니다만 MS는 아직까지도 MS 오피스에서 ODF 파일을 자유롭게 읽고 쓸 수 있는 기능을 지원하지 않고 있습니다.) 그렇기 때문에 아직까지는 많은 사람들이 Open XML에 대해 껍데기만 뒤집어쓴 closed proprietary 기술이라고 보고 있고, 그래서 MS와 손잡고 Open XML을 오픈오피스에 구현한 Novell을 비난하는 목소리가 주류를 이루고 있습니다.

사실 ODF와 Open XML 중 어느 것이 더 구현하기 어려운지, Open XML이 위의 저자들이 이야기한 것처럼 그렇게 현실적으로 구현이 불가능한 정도인지는 저도 직접 보지 않았기 때문에 잘 모릅니다. 그렇지만 위와 같은 우려는 충분히 생각해볼 만한 사항들이라, Open XML이 'open', 'standard, 'xml' 등 듣기 좋은 말들로 포장만 되어 있는 것인지, 아니면 정말로 'open standard xml' 인 것인지는 깊이 생각해보아야 할 것입니다.

댓글

권순선의 이미지

수동 트랙백: http://kldp.org/node/76078

:-)

moonend의 이미지

open xml이라는 명세에 대한 이야기를 들어보니, 정말로 큰일이라는 생각이 듭니다.
인간이 얼마나 대단할지는 몰라도, 불명확하고 이해하기 힘든 명세서는 미친 짓입니다.
프로그래머가 천년만년하는 직업도 아니고... 기술 전수에 대한 것은 신경도 쓰지 않는군요.

M$는 '블루 스크린'의 악몽을 또다시 만들어내고 있습니다. 그것도 스스로...

권순선의 이미지

참고로, finalize 되는 시점이 되면 6000페이지 정도가 될거라고 합니다.

Necromancer의 이미지

win32 api도 그렇지 않나요.

함수 만개에다가
함수 하나하나가 다 십여개씩의 인수를 덕지덕지 달고다니니.

mfc나 vb같은 자기네들만의 툴과 라이브러리 아니면 쓰지말라 식이죠.

Written By the Black Knight of Destruction

7339989b62a014c4ce6e31b3540bc7b5f06455024f22753f6235c935e8e5의 이미지

노벨, compiz하고 Xgl 때문에 좀 사랑해주려고 했더니 안되겠네요. ㄱ-
역시 레드햇과 우분투를...

winner의 이미지

정말 최악이군요.

Win32 API 는 일단 다 공개하니까...(공개 안 한 부분도 있을거다라는 의혹도 있지만...)
자기들도 쓰기 불편할 테고...

개발도구 경쟁이 불공정한 면이 강하긴 합니다만.

jachin의 이미지

그게 4000페이지나???

처음 XML 규격으로 문서포멧을 만든다고 할 때는

'MS도 오픈소스에 점점 가담하려나 보다...' 하고 생각했더니,

역시나군요. 역시 MS 답습니다. MS 가 그걸 따르기만 한다면 문제되지 않겠습니다만,

자기들도 따르지 못하는 포멧을 괜히 만드는게 아닌가 모르겠습니다.

(정말 자기네들도 거기에 100% 맞추면 언젠간 그 문서포멧 파서를 만들지 않을까요?)
====
( - -)a 이제는 학생으로 가장한 백수가 아닌 진짜 백수가 되어야겠다.

moonhyunjin의 이미지

역시 믿을 건 ODF 밖에 없네요.

<- 이거면 안되는 게 없어~
정품 소프트웨어 사용 캠패인

<- 이거면 안 되는 게 없어~
정품 소프트웨어 사용 캠패인

용이의 이미지

결국 현재의 독점이라는 아성을 지키겠다는 거네요.
공유와 개방의 시장에서는 MS식 독점이 무너진다는걸 알고 있다는 소리고
진짜 오픈소스 진영과 본격적인 싸움을 하겠다는 선전포고인 셈이네요.

budle77의 이미지

좀 벗어난 얘기지만요.
MS의 이런 모습때문에 X-Box 360을 사기가 망설여집니다.
결국엔 게임기 시장에서도 난리칠것 같아서요.
그나저나 SCO다음엔 Novel인가요?

미션임파서블에보면 비밀요원들을 배신하게 만드는 어둠의 브로커가 등장하죠. MS가 딱 그놈...(참 놈이 아니었죠!!)이네요.

===========================================
개발과 관리가 가능한 DBA를 목표로...

익명사용자의 이미지

하나의 포맷만으로 통일이 된다면 과연 새로운 기능이 하나 추가되기 위해서는 얼마나 많은 시간이 걸릴까요 ?
스펙의 문서량이나 구현의 여부를 떠나서 MS 의 입장에서는 이전 버전과의 호환. 새로운 기능들의 추가등을 생각하면
단일 문서 포맷으로의 통일은 힘들지 않을까요 ?

ODF 나 DOC, HWP 등의 문서 포맷은 모르지만 그 안에 들어있는 여러가지 설정(스타일, 매크로 등등..)들을 하나의 파일에
포함을 시킬려면 표준만으로 충분할지 의문이 듭니다.

전 솔직히 ODF 란 포맷이 표준으로서 꼭 존재해야만 하는건지 의문이 듭니다.
이미 문서 공유(읽기) 에는 PDF 란 훌륭한 표준이 있지 않습니까 ?

문서 작성은 아래아한글이든, MS 워드든 OO 이든, 개인이 만든 프로그램이든 상관은 없지만 작성자가 공유시에만
PDF 로 변환한다면 크게 문제가 될 것은 없다고 생각합니다.

전 문서 포맷보다는 라이센스 정책을 좀 바꿨으면 좋겠습니다.
one-pc one-copy 에서 벗어나 one-person one-copy 로 바꿨으면 좋겠군요.
정품을 사고도 사용하는 컴퓨터가 여러대면 불법 사용자가 되어버리는 것이 안타깝습니다.

마잇의 이미지

보는 용도의 문서 표준으로 PDF는 좋습니다. 하지만 수정도 해야 되는 문서의 호환성도 있어야 하지 않겠습니까?
--
마잇


--
마잇

coremaker의 이미지

ODF 는 단지 word process용 document 표준만을 염두해 둔 것이 아닙니다..
ODF 스펙을 잠깐 본적이 있는데.. 스프레드쉬트.. 프리젠테이션.. 애니매이션.. 3D.. 그래픽... 등..
많은 부분에 대한 "편집" 및 표현 방법을 정의해 놓았습니다..
그런 부분에서 필요하지 않을까 싶습니다...

s의 이미지

제가 전에 ODF에 관한 세미나를 들었는데요.
PDF파일도 표준이기하지만 adobe에 상당히 치우쳐 있고
ODF가 지향하는 방향이랑은 좀 틀리다고 알고 있습니다.

corean의 이미지

MS가 크게 잘못한 것은 없지만, 표준을 바꿔버리는...일이 많았죠.

coremaker의 이미지

Web OS 로의 진화 중 가장 필수적인 요소가 Web Office 가 되겠습니다..
Web Office의 가장 중요한 덕목은 호환성이 되겠구요... 그러기에 Standard가 있어야 합니다..
Standard의 중심에 있다면 얼마든지 좌지주지 할 "Power"가 생기고..
그 "Power"로 Money가 생기게 되는 것이죠....
MS는 현재 장외에서 표준과의 전쟁을 선포하고 있습니다...

7339989b62a014c4ce6e31b3540bc7b5f06455024f22753f6235c935e8e5의 이미지

웹 오피스라면 출력된 파일의 포맷은 당연히 HTML이겠죠. 웹이니까요. =3

coremaker의 이미지

라곤 생각할 수 있겠지만..
일반적으로 'Format'은 사뭇 각자의 목적성에 맞게 설계 되어 있습니다..
현 HTML에서 다양한 Date에 대한 대응이 상당히 어렵기 때문에..
확장을 하거나 해야하는데.. 그건 사람들의 반응이 회의적인 것 같습니다..
(정확히는 언급할 만한 정도는 아닙니다만 ;;)

현재 W3C에서도 HTML을 대체 또는 병용할 기준으로 XML을 이미 제시했구요..
결국엔 XML을 기준으로한 다양한 데이터 전송기법들이 나오고 있습니다..

그런면에서 국제 표준 문서 규격을 정하게 되었고..
우연히도 이런 부분과 발맞추어.. XML 기반의 ODF가 선정이 되었죠..
(MS에서는 자기네 것으로.. 이 표준을 자기들이 주무르려고 했으나.. 역시나 폐쇄성이 짙단 이유로..
거절당했습니다... 라고 알고있습니다..)

생각보다 상당히 복잡한 부분이 있는 것 같습니다..

뭐 실례로 현재 구글에서 제공하는 Web Wordprocess 나 spread sheet 같은 것등은..
ODF 표준을 제안한 Open office의 ODT 양식을 저장 포맷으로 이미 지원하고 있습니다..

익명사용자의 이미지

현재 많은 사람들이 WEB 2.0, WEB OS 라는 단어를 사용하는데
WEB OS 의 정확한 정의가 어떤 것인지 아직 감이 잡히지 않습니다.
Web Office 는 충분히 이해가 가지만 Web OS 는 아직 감이 잡히질 않습니다.

Web OS 는 결국 현재의 Telnet 과 같은 터미널 서비스와 연결이 되질 않을까 합니다.

coremaker의 이미지

WEB2.0 이라던지 WEB OS는 윤곽을 현재도 잡아가고 있는 중이라고 알고 있습니다..
단지.. 그러한 발전의 한단계 한단계가 현재 진행 중이고..
그 진행 과정 중에.. 발생하는 이슈들이라고 전 생각하고 있습니다....

wafe의 이미지

어쨌거나, ECMA 표준으로 받아들여졌군요. 근데 ECMA 표준으로 채택되었다고 안심할 수는 없는거죠? MS가 늘 해오던 짓이 표준의 확장 기능을 제공해서 물거품 만들기였으니까요.

Heejoon Lee

Open XML 옹호자의 이미지

좀 답답하군요.
다른 면에서 생각을 해볼 필요가 있습니다.
OpenOffice나 StarOffice 써 보셨나요 ? 무지 불편하고 기능 떨어집니다.
OpenOffice의 프리젠테이션이나 스프레드쉬트도 써 보셨나요 ? 짜증납니다.
이런것 기반 위에서 ODF 스펙이 만들어졌습니다.

Open XML은 MS 오피스 기반에서 만들어졌습니다.
당근 완성도 측면에서 ODF보다 훨씬 낫습니다. 스펙 분량 ..당연히 많습니다.
ODF 스펙의 많은 부분은 소위 "to be continued" 입니다.
외부 자료 보시면 완성도가 높아 Open XML 높이 쳐줍니다.
얼마전 발표한 IDC 자료에서는 Open XML이 대부분의 영역에서 ODF보다 높은 점수를 받았습니다.
이번에 OSI Fast Track을 통과하여 Open XML도 본격 표준을 위한 기술 검증에 착수했습니다.
ODF가 Open XML과 겹치는 표준이었다면 OSI가 문서 표준에 두 개를 넣으려고 했겠습니까 ?

SVG 등 표준을 안 쓴다구요 ?
국제 표준으로 등록한 이상, 이미 ECMA 표준이며 ECMA가 스펙 관리하기 때문에 MS가 고칠 일 있으면 ECMA 프로세스 밟아야 합니다. 뒤집어 얘기하면, SVG 지원 여부를 표준 프로세스 밟아 넣으면 됩니다. 그게 국제 표준으로 삼는 이유구요.

문서 표준이 하나 이어야 할까요 ?
전세계 이미지 표준이 jpeg 하나 인가요 ? 압축지원하는 포맷으로 png도 있습니다.
나름 용도가 조금씩 다르면 사람들에게, 선택의 폭을 넓혀줍니다.
ODF와 Open XML은 서로 상충되어 하나가 깨져야 하는 모순된 표준도 아닙니다.
필요에 따라 적합한 표준을 선택해 사용하면 그 뿐입니다.

ODF와 Open XML은 원 제작자의 손을 벗어나 공인 표준화 기구의 프로세스에 따라 움직이고 있습니다.

ODF이어야 하는 이유가 무엇인지 누가 정확히 가르쳐 주세요.
제발 ~~

예진아씨의 이미지

그거 그냥 MS Office 문서 기능을 그냥 다 포함해서 내놓은 거 아닌가요?

MS 말고 누가 쓰나요? 그리고 누가 쓰기나 할까요?

여기 있는 글을 따라가며 읽어보세요.

http://opendocumentfellowship.org/introduction/odf_vs_oxml

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

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

acroama의 이미지

Open XML 기반의 문서 저작도구가 현재로는 MS 오피스 하나지요.
하지만, ODF로 만들어진 문서보다 훨씬 많은 양이 Open XML과 호환되는 포맷으로 오늘도 만들어지고 있습니다.
Open XML은 오피스 xp, 2003, 2007 까지 호환됩니다.
오피스 xp 시절부터 xml 표현 방식을 제공하다가 2007에서는 완전히 open xml이 기본 포맷이 된 거죠.
지금까지 그 많은 양의 문서와의 호환성에 대해서 ODF는 한마디도 안하고 있는 것으로 압니다.
이미 현재 버전의 쌍방향 컨버터는 나와 있지요 ? 아마..

공개 표준,
정말 중요하지요.
아래 한글은 안타깝지만, 공개 문서 표준을 지키지 않는다면 공공 부문에서 과감히 퇴출시켜야지요.

ODF와 Open XML은 각기 하고 싶은 말이 많고 내세울 장점도 많을 겁니다.
제가 만나본 그 누구도 그 두 가지를 제대로 비교하지 못하더군요.
그래서 표준화 단체를 두어 심사를 하고 각종 전문 리서치 회사가 있는 거겠죠.

IDC에서는 다음과 같은 얘기를 했네요.
http://openxmldeveloper.org/archive/2006/11/27/IDC_Open_Document_Standards.aspx

대부분의 영역에서 Open XML이 ODF보다 높은 점수를 얻었습니다.
기업 입장에서 ODF보다 Open XML에 더 후한 점수를 주었습니다.
개발자 입장에서는 비슷하지 않을까요 ?
어차피 XML/XSLT/XLINK/XPATH 범주를 벗어나지 않되 다루는 스키마만 다르지않나요 ?
사용자 입장에서는 쉽고 빠르고 편하고 능력 좋은 놈을 그냥 선호하면 되겠지요.

결과는 좀 더 지켜봐야 겠군요.

예진아씨의 이미지

> 지금까지 그 많은 양의 문서와의 호환성에 대해서 ODF는 한마디도 안하고 있는 것으로 압니다.

이 말씀과

> 이미 현재 버전의 쌍방향 컨버터는 나와 있지요 ? 아마..

이 말씀은 모순 아닌가요? 현재 버전의 쌍방향 컨버터가 있다면 걱정할 게 뭡니까?
오래 된 MS문서를 새로운 MS오피스에서 열어서 오픈 XML로 저장하고 그걸 ODF로 변환하면 되는거잖아요.
대량으로 해야 할 일이 있다면 그 기능만 떼어서 유틸로 만들면 되고요.
그게 왜 ODF가 고려해야 하는 일인지 모르겠습니다.

> Open XML은 오피스 xp, 2003, 2007 까지 호환됩니다.

이 부분은 좀 아닌 것 같습니다. 한글 97문서는 한글 2002, 2005, 2007 에서도 호환된다는 말과 별로 다를 바 없습니다.

그리고 개발자에게 있어서는 당연히 ODF가 편합니다. ODF는 기존 표준에 있는 기능과 컨벤션을 그대로 따르며 그것을 재사용하고 있습니다. 제가 링크해 드린 글을 따라가서 읽으시면 "어차피 XML/XSLT/XLINK/XPATH 범주를 벗어나지 않되"라고 말씀하신 부분에서 ODF 가 더 낫다는 것을 실제 예제를 들면서 설명합니다.

         임예진 팬클럽 ♡예진아씨♡

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

acroama의 이미지

모순이 아니구요,
기존에 축적된 그 많은 정보에 대한 배려가 없다는 거지요.
ODF에서는 MS 오피스 기능을 빌리지 않고서 예전 문서를 읽을 수 없다는 거지요. 결국..지금은.
지금껏 축적해온 정보에 대해서 어떤 식으로던 활용할 수 있는 표준이 문서 표준으로 자리 잡아야 한다는 것입니다. 안그러면 노가다성으로 누군가가 일일이 바꾸어줘야 하겠지요.

예전 버전 오피스 호환 얘기는, 오피스는 아무 부가 기능 안해줘도 예전 정보를 그대로 활용할 수 있다는 차원에서 윗 얘기 연장선상에서 드린 겁니다. 단순히 오피스의 backward compatibility를 논한 것은 아니구요, 기존 축적된 정보 자산을 그대로 활용할 수 있다는..

개발자는 결국 어느 포맷을 기준으로 개발하던지, XML관련 지식을 갖고 노가다성 작업을 하는 수 밖에 없는 게 현실이지요. 제가 드린 말씀은 두 포맷 개발자 사이의 차이점은 스키마 차이가 가장 크지 않나 하는 것입니다. 기본적인 기술셋은 동일하고, 스키마만 다르지 않은가하는.. Open XML도 XML 언저리를 벗어나지 않습니다. 즉, 국제 표준에 근거한 방식입니다. 개발시 우수성을 논하기는 ... 스키마나 스펙이 간소하면 개발자가 편하긴 하겠지요. :)

Open XML이 낫다(?)라는 근거라면 IDC 자료가 그 중 하나겠지요.
실제 유럽 회사를 조사해서 발표한 것이라니.. 어느 정도 신빙성이 있지 않을까요 ?

Scarecrow의 이미지

acroama wrote:

개발자는 결국 어느 포맷을 기준으로 개발하던지, XML관련 지식을 갖고 노가다성 작업을 하는 수 밖에 없는 게 현실이지요.

ODF는 그것을 실제로 사용하고 있는 프로그램의 소스코드를 참고할 수 있지요.
OpenXML의 경우에만 님의 말씀처럼 맨땅에 헤딩해야 합니다.

시그너쳐: ./configure --prefix=/usr; make; sudo checkinstall

JN의 이미지

Open XML은 오피스 xp, 2003, 2007 까지 호환됩니다.

이 제품들 모두 MS 의 제품들입니다. 어떻게 보면 MS의 OpenXML에 대한 이해, 또는 기술력은 오피스XP시절부터 축적되었다고 표현할 수도 있겠습니다.

왜 Open XML을 경계해야 하는지에 대한 순선님의 글에서 포인트는 "4000여 페이지에 달하는 Open XML의 방대한 분량"에 있습니다. 이게 MS에게는 전혀 부담이 되지 않죠. 이미 그들은 충분한 노하우를 가지고 있습니다.

자꾸 스펙 자체의 완성도를 이야기해서 원래 논점을 흐리지 마셨으면 합니다.

물론 그런 비교가 나쁘다는 말은 아닙니다. 그런 비교는 ODF에도 도움이 되겠지만, 이 글타래에서 원래 이야기하고자 했던 주제는 아닙니다. 굳이 하고싶다며 다른 글타래를 여는 것이 적당하다고 생각합니다.

acroama의 이미지

논점이 저는 같다고 생각하고 썼는데,
다르시다 하니 할 말이 없군요....

스펙이 방대하고 MS만 유리하다는 말을 뒤집으면,
ODF는 스펙이 작아서 (훌륭하다면야 문제 없겠지만), 기능이 떨어져도 구현 업체는 모두 같은 선상에서 출발해야한다는 식으로 이해될 소지가 다분합니다.

시간이 흘러가면 ODF도 Open XML 처럼 방대한 분량의 스펙이 되겠지요.
지금도 지속적으로 갱신을 하고 있다고 들었습니다.

어쨌거나 나름 ODF에 대해 많이 배웠습니다. 좀더 자료를 찾아보고 다음에 또 인사드리지요..

cwryu의 이미지

MS의 펀딩으로 먹고 사는 조사기관의 이야기는 그냥 참고자료로만 활용하시길..

IDC라면 리눅스 TCO 이야기 등 MS 대변자나 마찬가지입니다.

----
익명이나 오래전 글에 리플은 무조건 -1

bootmeta의 이미지

최근 응용프로그램이나 운영체제에서 pc상의 문서를 포함해서 얼마나 효율적으로 쉽게 정보를 검색하느냐가 화두입니다.

그런 관점에서 본다면 ODF와 같은 표준 문서 체계의 중요성은 단지 문서 호환 그 이상의 의미가 있습니다.
물론 MS의 OOXML 역시 호환 가능하다면 구태여 거부할 이유는 없습니다.
그러나 현실적으로 OOXML을 구현할 수 있는 업체는 MS외에 없으며, 응용 프로그램 역시 MS OFFICE만 되리라 보입니다. 그런 상황에서 OOXML이 표준으로 자리 잡게 된다면 단순히 작업 문서 포맷을 넘어 인터넷 상의 정보 검색과 운영체제 편중이 더 심화될 수 있습니다.
더우기 WEB 표준 관련 논쟁이나 JAVA등의 전례를 살펴보면 MS의 OOXML이 공정한 표준을 계속 지켜나갈지 낙관할 수도 없습니다.

이런 문제점들이 있음에도 ODF를 구현하고 있는 응용프로그램들이 상대적으로 MS-OFFICE보다 성능이 떨어진다는 점과 ODF의 스펙이 OOXML보다 단순하다는 점때문에 많은 분들이 OOXML 표준을 지지합니다.
그러나 문서 표준과 구현한 제품은 별개이며, ODF나 OOXML의 기본 골격은 XML로 되있다는 점을 고려한다면 현재 부족한 기능과 확장성의 문제는 해결될 수 있으리라 보입니다.
차라리 ODF 지지가 높아져서 MS OFFICE가 어쩔 수 없이 기본 포맷으로 ODF로 전환하도록 하는 것이 장기적인 안목으로 보면 더 유용해 보입니다.

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.