XML이 도대체 뭐길래?

geekforum의 이미지

요즘 여기저기서 XML을 외치고 다니는 경우를 수도 없이 보아 왔습니다. 뭐 좋은 얘기들은 많지요. 데이터 호환이네, 웹과의 연동성이네 어쩌고저쩌고.... 그런데 아무리 생각해 봐도 도통 이게 왜 좋은건지, 왜 이걸 중요하게 생각해야 할지 모르겠습니다.

XML에 대해 정말 많은 자료들을 찾아 보았고, 여러 다양한 기사들도 섭렵 했습니다. 그런데 뭐 하는 이야기들은 거의 대동소이하더군요. 데이터 호환이 잘 되고, 차세대 웹 환경이고 MS에서 적극적으로 밀고 있고(오피스 XP는 XML로 자료를 저장한다죠?) 등등....

그런데 꼭 제 입맛에 맞는 자료는 아직 찾지를 못했습니다. 과연 XML이 현재의 컴퓨팅 환경에 있어서 어떠한 장점을 가지는 놈인지....제가 찾아본 기술적인 문서들의 거의 대부분은 XML 파서와 관련된 이야기들이었고 조금 깊이 들어가면 DOM이니 XSL이니 하는 이야기들 정도....그런데 그러면서도 왜 XML이 좋은가? 하는 질문에는 특별히 할 말이 없더군요.

데이터 호환성만 하더라도 얼핏 생각해 보면 참 좋은 말이긴 하지만 이미 있는 데이터들을 굳이 XML로 변환하자면 또 그만큼의 작업을 해 줘야 할테고, 웹과의 연동성 문제도 현재로서는 XML을 지원하는 브라우저가 익스플로러 밖에 없는 것으로 아는데 솔직히 말해 그렇게 큰 장점으로 다가오지는 않네요. 특히 리눅스/유닉스 환경에서의 XML은 더더구나 XML을 직접적으로 지원하는 웹브라우저도 없는 상황에서, 인코딩 방식까지 UTF-8이라는 괴상망칙한(?)놈을 굳이 써야 하니(리눅스/유닉스 환경은 UTF-8과는 아직 거리가 멀지요.) 더더욱 정이 안갑니다.

과연 XML이 현 시점에 비추어 얼마만큼의 장점이 있는 걸까요? 실제로 "XML application"을 만들어 보신 분들의 이야기 또한 듣고 싶습니다. 제가 지금까지 찾아본 것들은 대부분 XML의 정의나 구조 등에 그쳤고, 실제로 이를 현업에 적용해서 얼마만큼의 효과를 보았는지에 대한 실례는 거의 없었습니다. XML에 대한 여러분의 생각은 어떠한가요?

댓글

익명 사용자의 이미지

우리나라에선 아직 XML 기반의 프로젝트가 거의 없는 것으로 알고 있습니다. 하지만 XML은 아주 큰 잠재 능력을 가지고 있지요.... 이것은 특정 벤더가 밀어서가 아니라 XML이 가져다 줄수 있는 성능과 표현의 향상에서 기인한다고 생각합니다.
XML의 마크업 언어이자 그자체가 DB의 역할을 할수 있습니다. 프리젠테이션과 데이타영역의 구분이 가져다 주는 장점을 생각해 보시면 XML의 미래에 어둡게 보시지는 못하실 겁니다. 사실 전 충격적으로 다가오더군요.
한 예로 요즘 웹 기반 프로그램의 문제점 Conection pool의 관리 방법이 큰 골치덩어리죠...
쓸때없이 DB의 비싼 자원을 낭비하는 일이 허다합니다. 이런 경우 XML은 좋은 케시역할을 해줄수 있습니다.
XML을 단순한 마크업 언어, HTML과 같게 생각한다면 구지 어려운 XML을 사용할 필요가 없죠....XML은 프레젠테이션을 위한게 아닙니다. 데이타의 표준화를 통해서 그 활용방법을 늘려 보자는 거죠.... 물론 하나의 XML 스키마에 따르는 프레젠테이션이 있어야 그문서가 가치가 있겠지요....
MS의 차기 툴인 .NET 스튜디오에서는 모든 결과물이 XML 문서화 되어 나오더군요. 앞으로는 거의 모든 자료가 XML로 될거라 봅니다. MS사는 거기서 돈 냄새를 맛은 거구요.

위 글중에 MS사가 XML을 밀어서 거부감이 생긴다고 했는데, 사실 XML은 MS의 기술이 아닙니다. W3C에 의해서 만들어진 스펙이죠. 여기에 sun, IBM, 등등 많은 회사가 참여하고 있는 걸로 압니다.
조선말의 우리 조상들의 페쇄적인 사고방식이 어떤한 결과를 가져왔는지 생각해 보아야 하지 않을지...

한정훈의 이미지

위의 게시판 메뉴에서 볼 수 있는 RDF파일도
XML DTD의 하나라고 보면 됩니다.
사용해본 적은 없지만 제가 요즘 읽고 있는 XML관련
서적에는 그렇게 나와있더군요.

익스플로러의 CDF(즉, "채널" 정의 포맷) 또한 XML
DTD의 한 분류이고요. 그럼..

'98th student of KW-Univ., Dept of CE.

익명 사용자의 이미지

제가 보는 XML의 용도는 DB인거 같습니다.
연동이 잘되는, 어디서든 연결되는 DB!
사로다른 목적의 프로그램이 파이프든 시그널이든 소켓이든 아무튼 무엇인가를 이용해서 서로의 정보(DB)를 교환한다고 했을때, 한 프로그램은 DB2로 된걸 쓰고 다른 하나는 SQL로 된걸 쓴다고 할때, DB2로 된 정보가 SQL이 쓰이는 프로그램에 가서의 처리되는 작업의 비효율성을 줄이기 위해 표준을 정한게 XML이라고 봅니다.
XML이 텍스트로 되어 있어, 용량이 커진다는 문제가 있지만, 검색에선 빠른결과를 줄 수 있는 장점도 있고, 또 웹에 연동되었을때, CSS나 XSL에 의해 HTML표준으로 그대로 브라우져에 뿌려질 수 있는 장점도 있죠.
하드디스크의 발전과 CPU의 속도향상, 네트워크속도의 향상을 생각한다면 Text로 만들어지므로 해서 커지는 용량은 그렇게 신경 쓸 정도는 아닌거 같습니다.

익명 사용자의 이미지

XML은 항상 HTML의 대체언어- 라는 식으로 소개되고 있기 때문에 다들 개념을 이해하는데 어려우신 것 같은데 XML과 HTML은 뭐랄까.. 레벨이 틀리다구나 할까고? XML은 SGML의 서브셋이지만- 그러니까 규모는 좀 작지만 어쨌든 동급이죠. 하지만 HTML은 SGML에 맞춘 하나의 구현- 태그셋에 불과하죠. XML은 HTML보다 한단계 상위의 것이라고 이해하심 될겁니다.
XML- 단점도 많겠죠. 같은 데이터를 써도 파일크기가 훨씬 늘어나는데다 XML파일은 일일이 텍스트 프로세싱하고 거기에 파싱까지 해야되니까 처리속도 장난아니게 느릴 것으로 사려됩니다. XML로 만든 게시판 뭐 이런 것도 보이던데 그런건 XML의 올바른 활용예가 아니라고 생각합니다. XML은 DB대신 쓸 수 있는건 아니죠. XML이 인덱싱이 되는 것도 아니고.. 게다가 데이터를 중간에 삽입한다치면.. 아마 전체 파일을 처음부터 다시 써야만 할겁니다. 결국 XML은 텍스트 파일이니까요.
어쨌든 구지 RDB 놔두고 데이터를 XML로만 저장해야 한다는 생각은 좀 오버라고 생각합니다. 필요하면 RDB의 데이터를 XML로 변환 출력시켜 쓰면 되는거 아니겠습니까..
아 어쨌든 XML은 훌륭하고 앞으로 다양한 응용예가 나오겠죠. 하지만 새 기술이고 좋은 기술이니까 '반드시 써야만 한다 배워야만 한다'라는 중압감은 필요없다고 생각합니다. 딴사람들 쓰는거 보다가 나한테도 필요하겠다 싶음 그때 배움 되죠.. 사실 XML은 그렇게 어렵지 않습니다. 우리가 무슨 파서를 직접 만들 것도 아니고..

박영록의 이미지

XML의 장점 중 가장 중요한 것은 데이타를 구조화해서 저장/교환할 수 있다는 점입니다. HTML과 비교를 한다면, HTML은 태그가 문서의 구조와는 거의 관련이 없고 외부 표현과 관련이 깊죠. 물론, 원래 태그 자체가 비구조적인 건 아닌데, 사람들이 그 태그들을 단순히 외양을 바꾸는데만 활용하고 있죠. 게다가 넷스케이프와 IE가 호환되지 않는 태그들이 상당히 많습니다. 그러나, XML을 이용한다면 표현과 내용을 분리해서 기술할 수 있죠. CSS도 이런 관점에서 나온 것이고 XML은 CSS와 결합할 때 HTML보다 훨씬 논리적인 구조를 갖추면서 외양도 쉽게 관리할 수 있죠.

머, 그렇다고 XML이 HTML을 당장 대체할 수 있다는 건 아닙니다. 그러나, 미래에는 대체하게 될 가능성이 높습니다. 그리고 이렇게된다면 리눅스 사용자들도 더 이상 IE에서 잘 보이는 페이지가 넷스케잎에서 안 보인다고 불평하지 않아도 되겠죠. 그리고 XML을 쓸 경우 PHP나 ASP, JSP 등을 써야하는 일이 대단히 줄어듭니다.

HTML을 예로 들었지만 XML이 대체할 수 있는 문서는 HTML 뿐만이 아닙니다. 모든 종류의 데이터 파일을 XML로 대체할 수 있고, 또 그것이 효과적일 겁니다. 그렇게 대체할 때의 변환 비용을 우려하셨는데, 패러다임이 바뀔 때는 어차피 그런 비용이 한 번은 발생하게 마련입니다. 게다가 XML은 아주 만들기가 쉽습니다. 이를테면, 한컴이 HWP 파일의 형식을 XML로 바꾼다고 할 때 들어가는 노력은 아주 작습니다. XML을 읽고 쓰는 건 파서 라이브러리를 쓰면 아주 간단한 일이기 때문이죠. 실제로 많은 문서들이 XML로 바뀌어가고 있습니다. GNU의 문서 파일들도 상당 수가 XML로 바뀌었죠. Glade 프로젝트 파일도 XML로 저장이 되던데.. 악보 파일 같은 것도 ScoreML이나 MusicML등 XML로 쓰이고 있고, 수식 같은 것도 MathML로 표현되죠. 이런 건 전부 XML의 응용입니다.
게다가 DB도 RDMBS에서 한 단계 진보된 ODBMS(Open이 아니라 Object-oriented임--;)로 활용할 수 있죠. DB 자체가 XML 파일로 저장되는 겁니다.

내용을 보기 쉽다는 게 보안에 문제가 있지 않나 하는 생각을 할 수도 있겠지만, 어차피 보안은 파일의 퍼미션 레벨에서 해결되어야할 문제이고, 윈도우에서도 파일에 접근만 할 수 있다면 어차피 다른 뷰어로 열 수 있기 때문에 XML로 한다고 해서 특별히 유저 입장에서 해가 될 건 없다고 봅니다. 파일 형식에 라이센스를 걸고 싶어하는 기업에게는 해가 되겠지만..

DOM이니 SAX니 하는 것들은 이러한 XML을 이용하는 도구입니다. 왜 XML을 이용하는지는 얘기하지 않고 이런 것들만 얘기했다면 그건 좀 안 좋은 사이트를 찾아보신 게 아닌가 싶군요.--; www.w3.org/xml에 가보셔서 거기서 여기저기 찾아다니시는 게 좋으리라 생각됩니다. 책을 추천하라면 Beggining XML을 추천하겠습니다. 무엇보다 XML의 장점에 대해 아주 명쾌하게 설명이 되어 있습니다. 그리고, 마지막에 실제 이용 사례도 상당히 풍부하게 나와 있고요. 사실, 책까지 사기는 돈이 좀 아까운데-_- 그냥 서점에 가서 한 10분 정도 넘겨 보시면 대강 파악할 수 있을 듯.

XML은 진보적인 자료 저장/교환 체계입니다. 그리고 이건 제 생각인데, 만약 MS의 독점을 무너뜨릴 수 있는 것이 있다면 GNU/Linux, Java, XML 이 세 가지일 겁니다. 게다가 Java와 XML, GNU/Linux와 XML은 꽤 친하죠. Java랑 GNU/Linux만 좀더 친해지면 되는데..--;

익명 사용자의 이미지

아파치 톰캣 프로젝트를 보시면 설정 파일이 XML로 되어 있습니다. 무척 좋더군요.
일단 일관성이 있고, XML자체에서 well formed 문서인지 체크하니까 오류도 줄어듭니다. GUI인터페이스를 붙이기에도 좋겠죠.

프로그래머 입장에서도 설정 파일을 파싱하고 어쩌고 하는 부분을 짤 필요없이 XML 클래스 라이브러리 가져다가 사용함으로써 간단하게 끝납니다.

웹에서도 아주 좋겠죠. 예를 들어 인트라넷 상에서
6월 매출 현황을 XML문서로 꾸며놓고 경우에 따라 표, 파이차트, 막대 그래프등으로 다양하게 보여줄 수 있습니다.
만약 엑셀에서 XML을 그대로 불러들일 수 있다면 웹브라우저에서 끌어다 놓고 바로 사용할 수도 있겠죠.

이 기종간에 데이타교환이라는 이상이 구체화되는게 아닌지?

마소 특집에 XML이 나온적이 있으니 한번보시죠...
응용은 무궁무진할 것 같은데요.....

익명 사용자의 이미지

일단, 제일 큰 장점은 텍스트로 정보 전달이 가능하기에 어느 한쪽의 서버를 열어줘야 하는 일이 필요 없다는 것이지요. 어느 한쪽이 DB를 열어줘야 하면 보안 문제 및 여러가지 신경 써야 할 일들이 있는데 그냥 텍스트를 날림으로써 바로 데이터를 전달하게 되는 것이죠.

익명 사용자의 이미지

유닉스 클론들 상에서 XML을 C로
재미있게 다루고 있습니다.

:-)

익명 사용자의 이미지

C로 어떤 분야에 어떻게 xml 을 재미있게 사용하고 계시는지요...?

익명 사용자의 이미지

특별한 성능의 향상이나 사용상의 편리함이 있다고는 생각되지 않습니다. 그래서인지 저같은 프로그래머 입장에서는 왜 사용해야만 하지? 라는 의문이 생기게 되는거죠. 없어도 뭔가를 구현해내는데 상관없으니까.
하지만 범용으로 사용할 수 있는 표준 데이터 포맷이 생기고 많은 어플들에서 이 포맷을 지원하게 되면 자연히 위력이 생기겠죠. 물이나 공기처럼 당연히 사용하는 것이 되겠죠.
이런 비슷한 위치의 포맷이 여럿 있다고 생각합니다. 데이터 교환을 위한 표준포맷.. 예를 들면 HTML, CSV, DBF, PDF, RTF, TXT, TIF 등등.. 더 좋은 포맷이 많지만 이런 포맷들은 주로 이기종끼리 데이터 교환하거나 호환성을 보장하기 위해서 지원하죠.
하지만 XML은 지금까지의 이런 포맷들과는 다르게 스스로 자신의 구조와 포맷을 다양한 모습으로 정의할 수 있으니까요 훨씬 여러가지 용도로 쓰일 수가 있는거죠. XML은 데이터를 구조적으로 저장하는 하나의 프로토콜이니까요. XML 이거 하나로 위의 파일포맷 모두를 대체할 수도 있을지도 모르죠..
실제 예를 하나 든다면.. 델파이하고 C++빌더의 프로젝트 파일 포맷이 기존엔 바이너리였는데 XML로 바뀌었습니다. 물론 그렇게 바꾸었다고 해서 성능이 개선된건 아무 것도 없죠. 하지만 XML로 바뀌고 나니까 프로젝트 파일의 구조가 한눈에 보이더군요. 전에 바이너리 파일이었을때는 그냥 다들 그러려니.. 하고 속의 파일포맷같은건 전혀 궁금해하지도 않고 썼지 않습니까?
근데 XML은 텍스트 에디터로 열어보기만하면 그 구조가 명확하게 드러나니까요.. 필요하면 간단히 고칠 수도 있구요.. XML 문법을 따르니만치 필요하다면 그 프로젝트 파일을 사용해서 어떤 일을 하는 프로그램을 직접 짤 수도 있죠. 왜냐면 구조를 쉽게 알 수 있고 구조에 맞춰 읽고 쓰는 API가 OS에 의해 기본제공되니까요.
제 생각엔 앞으로 텍스트 에디터들은 XML에디터의 기능을 겸용해야 할 것 같습니다. 많은 데이터들을 XML포맷으로 쓸테니까요..
이건 뒤집어 말하면 어떤 데이터 포맷을 역공학해내기가 되게 쉬워진다는 얘기입니다. 얘를 들면 지금 HWP나 DOC의 포맷이 명확히 공개가 안되있죠? 근데 이 파일포맷들이 XML로 바뀌었다고 생각해보세요.. 이제 어디서나 거의 100% 호환이 가능해질겁니다. 구조를 못숨기니까요.. 즉 보안상 파일포맷을 숨기고 싶다면 XML을 안사용하겠죠.. 과연 MS가 오피스 파일포맷을 XML로 바꿀런지? 안바꿀런지? 후훗... 오피스X에서 XML로 파일포맷이 바뀌었다는 얘긴 못들어봤는디.. 어쩜 MS는 제무덤을 파고 있는지도 몰라요.. 오피스 파일호환이 쉬워져서 MS한테 좋을게 뭐가 있겠어요?
글구 인터넷 익스플로러에서 지원한다는건 결국 윈도우즈에서 지원한다는 얘기하고 똑같고 그 얘기는 PC의 95%가 이미 XML을 지원하고 있다는거하고 똑같습니다. XML을 사용하기 위한 기반은 이미 충분히 보급되었다고 봐야겠죠. 나머지는 XML을 배우고 자기 프로그램에 응용하는 프로그래머들의 노력뿐...

익명 사용자의 이미지

허걱.. 오타발견.. 오피스X가 아니라 오피스XP이고..
오피스XP에서 XML로 데이터 저장이 된다네요..
전 모르고 있었는디..^^
아 그럼 진짜로 MS는 제무덤 파고있는거란 말인가..?
오피스XP에서 XML로 저장되면 오픈오피스에서의 파일호환이
더욱 완벽해질텐데..

익명 사용자의 이미지

MS의 주 수입원이 Office 그 자체라고 보시나요?
자세히 MS의 Product를 보면 Windows, Office는 그냥 하는 장사도구에 지나지 않는다는 것을 아실텐데...
MS가 보는 시장은 그 너머의 것입니다.
MS를 과소평가하지 마시길... 우리가 생각하는 것보다 훨씬 더 많은 일을 벌리고 있으니까요.

익명 사용자의 이미지

오피스 못팔아서 돈못버는건 중요하지 않은 문제죠.
어차피 오피스뿐만이 아니라 기존의 소프트웨어 패키지를 판매하는 사업모델 자체가 위협받고 있는 현실인걸요. 그래서 MS는 PostPC라던가 헤일스톰같은데 전력투구하고 있는 것이구요.
중요한건 결국 MS의 시장지배력의 근본은 윈도우에서 온다고 할 수 있고 그 윈도우를 강력하게 서포트해주는게 오피스입니다. MS는 맥용 오피스를 가지고도 애플을 얼마나 잘 갖고 노는데요. 과거 유저들을 도스에서 윈3.1로 강력하게 전환시킬 수 있었던 힘의 근본은 바로 오피스에 있었습니다. 그당시 버젼이 아마 4.2.. 였었죠? 물론 요즘에 와선 오피스의 영향력은 약해졌고 새로운 기술인 인터넷 익스플로러와 미디어 플레이어등에서 윈도우의 시장지배력이 온다고 보는게 맞겠지만요..
하지만 오피스 최강자의 자리는 쉽게 넘겨줄 수가 없는 것입니다. 오피스는 여전히 윈도우가 다른 OS에 대해 가지는 강력한 경쟁력이자 진입장벽인걸요.
근데 그러한 오피스의 파일포맷을 공개해버린다고 하는 것은 다른 오피스 패키지들이 더욱더 완벽하게 오피스와 호환될 수 있다는 뜻이고 그렇다면 비싼 오피스를 구지 사용할 필요가 없어지는거죠. 아예 공짜인 오픈오피스같은거하고 정면대결한다치면 재수없음 질 수도 있는거죠..
MS로선 구지 XML보급에 그렇게 목매달며 스스로 무덤을 팔 필요가 없다고 생각하는데.. 아마 저 밑에 어떤 분 말씀대로 디폴트는 XML이 아닐 것 같습니다. 그냥 XML로 저장시켜서 딴놈들하고 호환이 가능하다.. 이정도 수준의 지원이겠죠.

익명 사용자의 이미지

이젤의 노틸러스에서도 XML로 DATA를 다루고있습니다.
아마 XP에서 사용하게될 방식과 완전히 같을것 같은데요...

박응주의 이미지

된다 그래도 여전히 디폴트 포맷은 doc, xl 그대로
겠죠. 그럼 적어도 80%이상은 디폴트를 그대로 쓸거구...
MS는 별 손해갈게 없지 않을까요...

익명 사용자의 이미지


Office XP가 XML로 데이터저장하고
openoffice가 XML을 똑같이 뿌려내기만 한다면
기업환경이 많이 바뀔겁니다.
복잡한 문서작업이 많은 사람들한테만 office
사주고 나머지는 openoffice로 해결가능하니까요.
시장구도가 판이하게 달라지겠죠.
지금처럼 7~80만원씩 받아서는 경쟁력 없어질겁니다.
헤일스톰으로 차세대시장을 석권한다는 계획이지만
쉽게 될까요? 지금처럼 반MS세력이 많은 상황에서요.
뭐 그 때문에 미국의 보수정치가들에게 줄대고
있는 거겠지만 기업이 정치에 깊이 관여해서 뒷끝
좋은거 못봤으니까요.

박응주의 이미지

xml이 unix쪽에서 훨 잘되지 않나요?
gnome쪽에서는 몇년 전부터 대부분의 프로그램이 파일 저장 형식으로 xml을 사용하고 있었습니다.
글고 인코딩을 꼭 utf-8로 해야되는 것도 아닙니다. 선택할 수 있죠.
저는 주로 설정파일을 xml 형식으로 만들어 쓰는데요...
xml이 가지는 의미는 ascii 코드가 가지는 의미와 비슷하다고 생각됩니다.
예전에는 컴터마다 코드체계가 다 달라서 문제가 많았다고 합니다. ascii가 나오면서 대부분의 컴터가 같은 코드체계를 쓰면서 부터 정보 교환이 훨씬 쉬워졌죠.
xml도 마찬가지로 표현하려는 내용이 무엇이건 간에 문법은 모두 똑같으므로 처리하기가 그만큼 간편해지는 것 같습니다.

익명 사용자의 이미지

파일포맷의 표준화 내지는 비슷한 ... ^^;;머 그런 파워가 있는걸로 알고 있습니다만...

기존의 doc포맷이나.. hwp등등의 포맷을 하나로 통합할 수 있는 규격이기 때문에.. 중요한 거겠죠..

머 인터넷쪽으로 이야기의 초점이 많이 흐르고 있기는 합니다만.. 그와는 별도로 어떤 응용프로그램의 자료를 개방적으로 운용할 수 있는 장점이 있습니다.

익명 사용자의 이미지

저두 많이 궁금하던 찰나인데..

실제 유용성이나 프로젝트 참가기록등을 조금 올려주셨으면 합니다..

정말 이건 어떤 분야에 어떤 부분에 필요한건지 잘 감이 안오네요..

사이트를 아무리 뒤져봐도 너무 추상적인 말들 뿐이라서...

익명 사용자의 이미지

책을 한권 사보시고 직접 만들어 보시면

저희들이 피상적으로 말씀드리는 것보다 아주

빠른 이해가 올 겁니다.

-Venus-

ps. 제가 아주 잘 아는 사람 처럼 말해버렸네요.
안그런데 -.-; 죄송.

익명 사용자의 이미지

XML의 유연성은 받아들일만 한 것 같아요.

(후신: '~었'은 우리문법이 아니예요.
영문법 '~완료형' 표현이거든요.
예쁜 우리글을 쓰자구요. 미안해요)

Renn의 이미지

언제적인가... 아주 단순히 XML 을 잡아 볼 기회가 생겼었습니다. 그냥 문서를 만드는 것이었는데, XSL 인가? 하여간 문서의 요소에 해당되는, 즉 태그를 만들고 이를 이용해서 체계적인 문서 몸체를 따로 만들었었죠.

결론적으로, 이런 경험으로 보면, 쓸만하다고 말하고 싶네요. 꾸미는 부분이 따로 분리되어 있으니 유지보수 측면에서도 좋았습니다.

하지만, 이는 XML 의 1% 정도 사용했었을까요? 모르는것이 너무 많아서 어떻게 말하기도 힘들군요.

익명 사용자의 이미지

저도 실제로 XML 프로그램을 개발해본것은 아님을 먼저 밝히고 얘기를 시작하도록 하겠습니다. XML 사태(?)는 돈과 완전히 떨어져서 얘기를 할수가 없기 때문입니다. 인터넷이 폭발적으로 성장을 하면서 너도나도 모두 홈페이지를 만든건 잘 아실겁니다. 그와중에 MS-SQL, mySQL등의 점유율도 과거와 달리 많이 늘어나게된것도 사실이고요.
사실상 거의 모든 회사가 홈페이지를 구축하고 그를 위한 자신들만의 데이터베이스를 구축했습니다. 근데 만들고 나니까 본전생각도 나고 다른 용도로도 이너마를 써야 본전도 뽑고 그렇겠죠. 근데 자기가 필요한 정보를 사용하는곳과 자신의 데이터를 필요로 하는 다른 회사의 디비가 절대 같을 리가 없습니다. 그러다 보니 이걸 뭔가로 바꿔서 교환을 할 필요가 있게 됐다는 거죠. 새로운 표준이 필요하게 된겁니다. 이때 발벗고 나선 회사가 MS와 Oracle등의 회사입니다. XML을 이용해서 데이터를 교환하자는거죠. 결국 B2B니 하는 말들도 나오고 돈과 직결되는 문제가 되버린겁니다.

개인적으로 Linux쪽이 이쪽에 늦게 대처하게 되는건 모두 돈때문이라고 생각을 합니다. Linux 많이 쓰지만 대형 싸이트 (B2B같은 쪽에 뛰어들)들은 잘 쓰지 않는다는거겠죠. UTF-8이라는 요상한 포멧에 대한 대처도 결국 우리네 고유배포폰이 없는 관계로 그러하겠구요. 모든 리눅스 응용프로그램들이 대부분 영어문화권에서 만들어진채로 Windows달리 1바이트 문자만을 이용해서 만들어집니다. UTF-8 우리나라에서는 잘 안쓰지만 이웃나라에서는 많이들 쓴다고 하더군요.

이제 다른데서 만든거 가져다가 한글 스킨만 덮어서 배포본이네 하고 팔지말고 먼가를 만들때가 되지 않았나 합니다. 얘기를 하다보니 삼천포로 빠진거 같네요. -_-

댓글 달기

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
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.