써보고 까자

재밌다..ㅎㅎ

너무 기발한 아이디어와 극 공감되는(공대 출신이므로..ㅋㅋㅋ)

창문열고 에어컨 끄고 운행하면 연료절약?

(서울=연합뉴스) 휘발유 가격이 하늘을 뚫을 기세로 오르고 있는 가운데 자동차 연료를 아끼기 위한 온갖 아이디어가 속출하고 있지만 이런 말을 다 믿다가는 잃는 것이 더 많을 수도 있다고 ABC 뉴스 인터넷판이 보도했다.

ABC는 미국자동차협회(AAA)와 컨슈머 리포츠, 그리고 디스커버리 채널의 과학 상식 검증팀 `미스 버스터'(호기심 해결사)의 도움을 받아 연비를 높이는 방식을 일문일답식으로 짚어냈다.

- 에어컨을 끄고 창문을 여는 편이 나을까?

= 에어컨 가동이나 열린 창문으로 인해 줄어드는 연료 효율은 둘 다 1ℓ당 주행거리 200m 정도로 비슷하다. 고속도로에서 창문을 열면 오히려 손해다. 운행속도가 아주 느린 경우엔 창문을 여는 편이 다소 이익이지만 더운 날씨에 에어컨을 켜지 않음으로써 피로해지는 것도 고려해야 한다.

- 연료를 아침 일찍 넣는 것이 좋을까?

= 오후가 되면 기온이 올라가 주입 과정에서 연료가 증발하기 때문에 연료탱크 온도가 낮은 아침 일찍 넣을수록 실속 있다는 계산에서 나온 말이지만 이렇게 증발되는 양은 연간 1% 정도이다. 그리고 주유소의 연료 탱크는 대부분 지하에 있어 시간에 따라 온도 차이가 나지 않는다.

- 휘발유가 고급일수록 연비가 높다는데?

= 자동차 제조회사가 제시하는 연료 사용 지침은 엔진 성능을 토대로 한 것인데 요즘 차는 회사 측이 최고급을 권고하더라도 중급, 또는 일반급이라도 지장 없다. 엔진의 성능은 약간 떨어질지 몰라도 트레일러를 끌거나 자동차 경주를 벌이는 것이 아니라면 엔진 성능을 100% 발휘해야 할 경우는 거의 없다.

노킹음이 들리지만 않으면 아무 문제가 없지만 이런 소리가 들릴 땐 지체없이 최고급으로 바꾸라고 AAA는 권고한다.

- 에어필터가 깨끗해야 연비가 높아진다는데?

= 연비에 영향을 미치는 것은 차 무게를 늘리는 지붕 위의 짐받이 등 여러 가지가 있지만 에어필터의 상태는 상관 없다. (미국의 경우) 1997년 이후에 생산된 자동차들은 더러워진 에어 필터에 엔진이 자동 적응하도록 돼 있다.

에어필터보다는 타이어 공기압에 신경을 써 한 달에 한번씩 점검하는 것이 더 중요하다. 공기압이 낮으면 연료를 더 많이 소모하게 된다.

- 엔진 공회전을 10초 이상 하지 말라는데?

= 일반 도로에서 조금 막힌다고 시동을 끄는 사람은 없다. 30초 이상 움직이지 못할 것 같으면 꺼도 되지만 그렇게 해서 절약되는 연료의 양은 극소량이다.

- 연료 첨가물을 넣는게 좋다는데?

= 온갖 그럴싸한 선전 문구로 유혹해도 연비를 높여 준다는 첨가제나 장비는 사지 마라. 한마디로 `아무 소용 없다'. 미국 환경부(EPA)의 실험에서 연비를 높인 제품은 단 한 개도 없었다.

- 화를 가라 앉히는데 드라이브가 좋다?

= 연비를 높이는 최고의 방법은 긴장을 풀고 느긋하게 운전하는 것이다. 최근 실험 결과 화 난 상태로 운전하는 운전자들은 느긋한 운전자에 비해 연료를 50%나 더 소모하는 것으로 나타났다.

계기판 위에 커피 잔이라도 얹힌 것처럼 액셀러레이터와 브레이크를 부드럽게 밟는 것이 연료 소모를 줄이는 최고의 비결이다.

또 엔진 온도가 높을 때 연비가 높으므로 차를 찔끔찔끔 쓰지 말고 볼 일을 모아 한꺼번에 하는 것이 좋다.
출처
연합뉴스
http://news.naver.com/main/read.nhn?mode=LPOD&mid=etc&oid=001&aid=0002123173

통섭 (統攝,Consilience)은 "지식의 통합"이라고 부르기도 하며 자연과학과 인문학을 연결하고자 하는 통합 학문 이론이다. 이러한 생각은 우주의 본질적 질서를 논리적 성찰을 통해 이해하고자 하는 고대 그리스의 사상에 뿌리를 두고 있다. 자연과학과 인문학의 두 관점은 그리스시대에는 하나였으나, 르네상스 이후부터 점차 분화되어 현재에 이른다. 한편 통섭 이론의 연구 방향의 반대로, 전체를 각각의 부분으로 나누어 연구하는 환원주의도 있다. - 위키백과 (http://ko.wikipedia.org/wiki/%ED%86%B5%EC%84%AD)

경영 마인드만 갖고는 빠르게 변화하는 고객의 욕구를 만족시킬 수 있는 제품과 서비스를 개발하기는 힘들다. 기업이 다양한 학문을 전공한 인재들을 필요로 하는 것도 그 때문이다. 경영학ㆍ경제학은 물론 인문학ㆍ자연과학적인 지식과 아이디가 동원될 때 이제까지의 사고를 뛰어넘는 상상력이 발현될 수 있다.

그러고 보면 통섭은, 끊임없이 새로운 비즈니스 모델을 찾아 나서야 하는 기업들에게 가장 필요한 개념이 아닐까? 

통섭, 휴대전화의 고정관념을 깨다

모프(Morph). 노키아가 지난 2월 샌프란시스코의 한 전시회에서 선보인 미래형 휴대전화의 이름이다. 아래 그림에서 보는 바와 같이 이 모프는 상황에 따라 모양이 변할 뿐 아니라, 필요한 경우 색깔도 바뀐다. 이뿐 아니다. 펼치면 자판으로 사용할 수도 있고, 둘둘 말아 팔찌처럼 찰 수도 있다.

 

 노키아가 개발한 미래형 휴대전화 모프(사진 노키아 홈페이지).
상황에 따라 모양과 색깔이 바뀌는 이 휴대전화는 생물학을 응용함으로써 통섭을 멋지게 적용했다.

이 휴대전화를 어떻게 개발할 수 있었을까? 노키아는 이 모프를 개발하기 위해 카멜레온의 보호색 기능, 자유자재로 움직이는 거미줄의 원리를 응용했다고 한다. 그래서 이를 바탕으로 플렉시블 트랜지스터(flexible transistor)라는 새 기술을 적용하기도 했다. 최첨단 기술에 생물학의 기본원리를 차용한 것이다. 다시 말해, 새로운 제품을 개발하기 위해 신기술과 디자인에만 의존하지 않고, 생물학이라는 전혀 새로운 분야의 특성을 원용한 것이다. 이것이 바로 기업이 필요로 하는 통섭의 한 사례이다.

왜 기업에 통섭이 필요한가

그러면 왜 지금 기업이 이런 통섭을 필요로 하는가? 다 아는 바와 같이, 세계 일류급 기업들 사이에는 기술의 차이는 그다지 크지 않다. 그래서 한동안 디자인이 뛰어나야만 더 많은 제품을 소비자에게 팔 수 있다고 생각해 왔다. 지금도 이 말은 틀린 말은 아니다. 디자인은 여전히 중요하다. 하지만 이제 모든 기업이 디자인의 중요성을 아는 이상, 디자인만으로는 다른 기업과 더 이상 ‘차별화'할 수 없게 되었다.

무엇이 더 필요할까? 그것은 다름 아닌 제품과 기술에 대한 ‘새로운 개념과 안목'이다. 이제 단순히 좀 더 진보된 기술을 개발하는 것으로는 충분하지 않다. 필요한 것은 그 기술을 원용한 ‘전혀 새로운 개념'의 제품을 개발한 뒤, 그 제품을 ‘전혀 새로운 안목'으로 사람에게 다가가게 하는 것이다.

예를 들면 위에서 말한 모프는 '휴대전화는 딱딱한 것, 색깔은 변할 수 없는 것'이라는 고정관념을 깨고, 상황에 따라 모양과 색깔이 자유롭게 변하는 휴대전화에 대한 새로운 개념과 안목을 제시했던 것이다.

하지만 고정관념을 깨고 새로운 개념과 안목을 제시하는 것은 쉬운 일이 아니다. 그러기 위해서는 새로운 사고유형이 필요하다. 단편적 지식이 아닌 복합적 사고와 통찰력이 필요하고, 인간에 대한 깊은 이해를 기반으로 한 상상력과 창의력이 필요하고, 21세기 디지털경제 시대에 맞게 글로벌 감각이 필요하다.

이런 ‘넓고 깊은' 사고유형은 한 종류, 혹은 한 가지의 분야만을 천착해서는 얻을 수 없다. 오히려 다양한 학문 분야를 아우르고, 혹은 전혀 이질적인 생각과 관습을 보다 높은 차원에서 바라볼 줄 아는 시각, 즉 통섭의 관점을 통해서만 얻을 수 있다.

간략히 정리하자. 21세기 글로벌한 경제 환경에서 세계 초일류를 지향하는 기업이라면 ‘통섭을 기반으로 한 제품', 다시 말해 ‘새로운 개념과 안목을 보여 주는 제품'을 개발할 필요가 있다. 이제 이해가 되는가? 아직 고개를 갸웃거린다면 통섭을 기반으로 한 새로운 제품 개발의 사례를 하나만 더 들면서 논의를 진행하자.

로봇 도마뱀, 서로 다른 영역을 가로지르다

유리벽을 수직으로 올라가는 로봇을 개발할 수 있을까? 유리벽을 수직으로 오르기 위해서는 우선 그 크기가 작아야 한다. 지나치게 크면 위로 오르는 것 자체가 힘들어진다. 하지만 그런 작은 로봇을 어떻게 수직으로 올라가게 할 수 있을까? 수직으로 올라가게 하기 위해서는 중력의 작용을 거스르는 장치가 필요하다.

미국 스탠퍼드대학교의 김상배 연구원은 오랜 고민 끝에 이런 로봇을 만들어 냈다. 그는 한 번 달라붙으면 절대 떨어지지 않고 발걸음을 옮길 때면 너무나 사뿐하게 움직이는 도마뱀의 발바닥을 보고 영감을 얻었다. 그러니 아래 사진과 같은 로봇 도마뱀 스티키봇(Stickybot)은 로봇 공학에다 도마뱀에 대한 생태연구가 합쳐져 탄생한 것이다.

이런 로봇 도마뱀은 사실 기술로만 보면 새로운 것이 아닐 수도 있다. 하지만 놀라운 것은 서로 다른 두 학문 영역의 경계를 가로질러 누구도 생각해 내지 못한 아이디어(새로운 개념)를 개발하고 그것을 실현해 낸 점이다.

 

 스탠퍼드대학교 김상배 연구원이 개발한 로봇 도마뱀 스티키봇(사진 김상배 연구원 홈페이지).
로봇 공학과 도마뱀에 대한 생태연구가 합쳐진 결과물이다.
2006년 타임지의 '올해의 발명품' 중 하나로 꼽혔다.

지금 기업은 이런 안목을 제시하는 제품을 필요로 하고 있다. 그런 제품을 만들기 위해서는 ‘지금까지와는 다른 새로운 발상과 사고의 방식'이 필요한데 다름 아닌 통섭이 그 기반을 제공해 주고 있다는 것이다.

어떻게 새로운 인재를 양성할 것인가

그런 제품을 개발하기 위해서는 통섭을 이해하고 그런 바탕 위에서 사고하는 새로운 인재가 필요하다. 학문에서의 통섭이란 학문 간 경계 없이 서로 가로질러 연구하는 것을 의미한다. 이것을 기업경영에 접목한다면, 기업에 필요한 통섭적인 인재는 ‘경계를 넘나드는 사람들'로 이해할 수 있다.

경계를 넘나든다는 것은 경영학ㆍ경제학ㆍ자연과학ㆍ공학ㆍ심리학이라는 학문의 한 굴레에 갇히지 않고 주어진 문제를 해결하기 위해, 혹은 새로운 시도를 하기 위해 자신이 속해 있는 기존의 영역을 과감히 벗어날 줄 아는 사람을 의미한다.

그런 의미에서 지금 CEO를 위시한 기업의 모든 인재들이 인문학적 교양을 강조하는 것은 참으로 시의적절하다. 칼리 피오리나 전 HP(Hewlett Packard) 회장은 "나는 경제학이 아니라 중세철학에서 비즈니스에 대한 분석력을 키웠다. 중세가 르네상스 시대로 이행한 것에서 디지털시대의 도래에 대한 영감을 얻었다“고 말한다. 그의 전공이 경영학이 아니라 역사학과 철학이라는 것은 우연이 아니다. 애플의 CEO인 스티브 잡스 역시 그의 창의력의 많은 부분은 종교적 직관에서 나왔다고 한다.

문학ㆍ역사ㆍ철학과 같은 인문학이 의미를 가지는 것은 이것만큼 인간의 근원적인 문제를 다루는 것이 없기 때문이다. 기업의 경영이 무엇인가? 인간이 필요로 하고 기뻐하는 새로운 제품을 만들어 그것을 가급적 많은 인간에게 팔아서 삶을 윤택하게 하고, 그 결과 기업은 이윤을 늘리고 사업을 확대해 나가는 것이 아닌가? 결국 기업경영은 인간의 문제인 것이다.

인간을 이해하고, 인간을 움직이고, 인간을 만족시키는 것. 그것이 경영의 본질이고 그래서 기업경영은 인간을 이해하는 통섭, 아니 통섭을 통해 인간을 다면적으로 이해하는 것을 필요로 한다.

통섭, 기업의 아이디어와 상상력을 좌우한다

지금까지 설명한 바와 같이 새로운 아이디어 혹은 새로운 상상력, 그것은 기업이 21세기를 효율적으로 그리고 일류로 살아가기 위해 정말 필요한 것이다. 더 나아가선 앞으로 10년 우리 기업이, 아니 우리 한국이 먹고살 새로운 터전을 만들어 내기 위해 필요한 것이기도 하다.

IT(정보기술: Information Technology), BT(바이오 기술: Bio-Technology), NT(나노 기술: nano-Technology)에만 매몰되지 않고 그것을 아우르는 혹은 그것을 뛰어넘는 발상이 있어야 정말 ‘새로운' 제품을 만들 수 있고, 정말 우리의 ‘미래를 보장'받을 수 있는 것이다.

흔히 상상력의 원조로 두바이를 말한다. ‘불가능한 것은 없다. 당신은 상상을 하라. 우리는 이루어 내겠다.' 아직까지 틀린 말은 아니다. 하지만 조금만 더 시야를 넓히면 앨빈 토플러의 다음과 같은 말이 우리의 가슴을 친다.

"제1의 물결은 농업혁명, 제2의 물결은 산업혁명, 제3의 물결은 지식산업의 혁명이다. 하지만 제4의 물결은 이 모든 것을 뛰어넘는 생각의 혁명이다."

통섭은 이 생각의 혁명을 주도하는, 아니 생각의 혁명을 이끄는 원동력이 될 수밖에 없다. 기업이라고 예외는 아니다.

- 글

김기홍 / 부산대학교 경제학과 교수

출처 - http://www.samsung.co.kr/news/biz_view.jsp?contentid=120242

아이잡 리뉴얼에 들어갔다...
http://i-jobgangwon.com/service/
에서 현재까지의 진행 상황을 체크 해볼수 있다.

최대한 웹표준과 크로스브라우징을 맞추려고 노력 하고 있지만 개발 기간이 촉박한 관계로 1~2픽셀정도의 미세한 차이는 간과하기로 했다...

잘 진행되어서 좋은 결과가 나왔으면 정말 좋겠다.

CSS를 짜다보면 어쩔수 없이 핵과 마주해야합니다. 그나마 있어줘서 고마운 핵... 하지만 우리는 그 이름조차 모르고 있지는 않나요? ( --; 무슨 공익광고인가...)

그래서 이름과 용법 등을 정리해 보았습니다.

박스모델 핵 (Box Model Hack)
<적용브라우저 : IE4, IE5, IE5.5, NS4>

voice-family:"\"}\"";
voice-family:inherit;
property:<value>;

"웹2.0을 이끄는 방탄웹(왜 웹2.0을 방탄웹이 이끄는지는 미스테리)"에 보면 처음 나오는 핵입니다.

IE5.x (IE5, IE5.5 등)에서 div로 지정된 박스의 넓이가 padding과 margin을 적용하면 해석하는 과정에서 큰 오차가 발생하는 관계로 이 부분의 오차를 미연에 방지하고자 적용하는 핵입니다. 하지만, 다른 IE5.x관련 값에도 적용되는 유용한 핵입니다.

(제 경험으로는, DTD를 Strict로 맞춰주면 이 핵을 적용하지 않고도 별 이상없이 구현되었습니다.)

간략화된 박스모델 핵(SMBH, Simplified Box Model Hack)
<적용브라우저 : IE4, IE5 ,IE5.5, NS4, OP5>
말뜻 그대로, 길어서 줄인 것입니다.

* html <selector> {
property:<value>;     <- IE5.x의 값
p\roperty:<value>;  <- 그 외 브라우저의 값
}

카이오 핵(Caio's Hack)
<적용브라우저 : NS4>

/*/*/property:value;/* */

패브라이스 도치법(Fabrice's Inversion)
<적용 브라우저 : IE4, IE5, IE5.5, IE6, IE7, NS6, NS7, OP6, OP7, OP8, SF2>

/*/*//*/property:value;/* */

오웬 핵(Owen's Hack)
<IE4, IE5, IE5.5, IE6, NS4, OP5, OP6>

head:first-child+body div

자식 셀렉터(Child Selector)
<적용 브라우저 : IE4, IE5, IE6, NS4>
원래는 핵이 아닌데, IE 구버전에서 처리할 수 없는 셀렉터를 이용해 핵처럼 이용하는 방법입니다. 이런 핵이 몇개 있는데, 대부분 IE 구버전과 관련있습니다.

body>div

속성 셀렉터(Attribute Selector)
<적용 브라우저 : IE4, IE5, IE6, NS4>
이것 또한 속성셀렉터를 구버전 IE에서 인식하지 못하는 점을 이용한 핵입니다.

html[xmlns] div

스타 HTML 버그(Star HTML Bug)
<적용 브라우저 : IE7, MO1, NS4, NS6, NS7, OP5, OP6, OP7, OP8, SF>
오페라 전용 핵처럼 생각되어질 정도군요.

* html div

넥스트 낫씽 핵(Next to Nothing Hack)
<적용 브라우저 : IE5.5, IE6, MO1, NS4>

*+html div

인라인 하이패스 필터(Inline High Pass Filter)
<적용 브라우저 : IE4, IE5, IE5.5, NS4>

i{content:"\"/*"}
div{property:value}

스타7 핵(Star 7 Hack)
<적용 브라우저 : IE4, IE5, NS4, OP5, OP6, OP7, OP8, SF>

html*#test

언더스코어 핵(Under Score Hack)
<적용 브라우저 : IE7, MO1, NS4, NS6, NS7, OP5, OP6, OP7, OP8, SF>

_property:value

http://centricle.com/ref/css/filters/의 내용을 참고하여, 윈도우용만 적용해 보았습니다.

기타 잘 정리해 둔 내용...

Netscape 4 배제하기
<link rel="stylesheet" type="text/css" href="http://wis1674.tistory.com/css/style.css" media="all" />
Netscape 는 media 속성이 screen 이 아닌 경우 외부 스타일시트를 읽지 못하는 버그가 존재함.

Win IE 3~4, Mac IE 4~4.5, Netscape 4 배제하기
@import url("/css/style.css")
Win IE 4, Mac IE 4 는 인용부호가 "가 아니면 읽지 못하는 버그 존재. IE 3과 Netscape 4는 @import 지원하지 않음.

Mac IE 5 배제하기
H1 { /* \*/ color:red; /* */ }
Holly 핵이라 하며, 주석 안의 내용이 적용되지 않음.

Win IE 4~5 배제하기
H1/**/ { color:red; }
셀렉터 뒤에 /**/ 삽입.

Win IE 4~5, Mac IE 4.5~5 배제하기
H1 { color/* */:red; }
속성과 속성값을 구분하는 콜론(:) 앞에 /* */ 삽입.

Win IE 4~6, Mac IE 4, Netscape 4 배제하기
html>body H1 { color:red; }
셀렉터 앞에 html>body 삽입.

Win IE 6 제외시키기
H1 { color /**/:red; }
속성과 속성값을 구분하는 콜론(:) 앞에 스페이스와 /**/ 삽입.

언더스코어 핵 (_)
H1 { _color:red; }
Win IE 4~6 에 적용.

닷핵 (.)
H1 { .color:red; }
속성 앞에 . 삽입. Win IE 6~7 에만 적용. 타 브라우저는 정확히 확인하지 못했습니다.
이 핵에 대해선 계속 확인중인데 블로그스피어나 여타 서적에는 전혀 언급이 없는 이상한 핵(?)입니다.

해시 핵(#)
H1 { #color:red; }
속성 앞에 # 삽입. Win IE 4~6, Mac IE 5, Opera 7, Mozilla계열, Firefox 에 적용.

스타 핵
*HTML H1 { color:red; }
셀렉터 앞에 *html 삽입. Win IE 4~6, Mac IE 4~5 에 적용.

스타7 핵
HTML*H1 { color:red; }
셀렉터 앞에 html* 삽입(공백없이). Win IE 5.5~6, Mac IE 5, Safari 에 적용.

xmlns 속성 핵
HTML[xmlns] H1 { color:red; }
셀렉터 앞에 속성 선택자를 삽입. Mozilla, Firefox, Opera, Safari 등 속성 선택자를 지원하는 브라우저에 적용.

:root 가상클래스 핵
:root H1 { color:red; }
셀렉터 앞에 :root 가상클래스 삽입. Mozilla, Firefox, Mac IE 5, Safari 등 가상클래스를 지원하는 브라우저에 적용.

Tantek 박스모델 핵
H1 {
    width:500px;
    voice-family: ""}"";
    voice-family:inherit;
    width:400px;
}
Tantek Celik 이 고안한 유명한 박스모델 핵. Win IE 4~5, Mac IE 4, Netscape 4 에서는 voice-family 속성 이전의 스타일 적용. 그외의 브라우저는 뒤의 속성 적용.

단순 박스모델 핵
H1 {
    width:500px;
    w\idth:400px; //Win IE 6, Mac IE 5, Mozilla, Opera, Safari
    \width:450px; // only Win IE 5
}
속성의 첫번째, 두번째 글자 사이에 \를 삽입하면 Win IE 6, Mac IE 5, Mozilla, Opera, Safari 에 적용.
추가로 속성의 앞에 \를 삽입하면 Win IE 5 에만 적용.

IE 7, Opera 적용하기
*+html body H1 { color:red; }
셀렉터 앞에 *+html body 삽입. IE 7, Opera 8 이후 버전 적용. Opera를 배제한 IE7 전용으로 하고 싶을 때는 *+html>/**/body 로 Opera 전용 속성 기술.

IE 7 적용하기
*:first-child+html H1 { color:red; }
셀렉터 앞에 *:first-child+html 삽입. IE 7에만 적용되고, 이외의 브라우저는 앞에서 기술한 셀렉터의 속성 적용.

Win IE 5 패스필터
@media tty {
i{content:"";/*" "*/}}; @import '/css/style.css'; {;}/*";}
}/* */

Win IE 5.5 패스필터
@media tty {
i{content:"";/*" "*/}}@m; @import '/css/style.css';/*";}
}/* */

Win IE 6 패스필터(?)
<!--[if IE 6]><link rel="stylesheet" type="text/css" href="http://wis1674.tistory.com/css/style.css" media="all" /><![endif]-->

Win IE 7 패스필터(?)
<!--[if gte IE 7]><link rel="stylesheet" type="text/css" href="/css/style.css" media="all" /><![endif]-->

모던브라우저 패스필터 (Win IE 5.5 이하, Mac IE 5, Opera 8 이하, Netscape 4 이하 제외)
@import "null?"{";
@import "/css/style.css";
@import "null?"}";

----copyed by ilmol----
몇년전 어둑해져가는 저녁에 라디오를 들으며 운전을 하다 우연찮게 이 시대의 패러독스, 역설에 대하여 이야기하는 George Carlin 의 글을 듣게 되었습니다. George Carlin 은 시대를 비판하는 스텐드업 코미디언으로도 유명하고 책도쓰고 배우도 했던 엔터테이너입니다. 저질개그도 하곤해서 늙은 할아버지 대단하네 했었지만 이 메세지를 듣고나니 머리가 띵 하더군요… 멍한 시간후에 많은 생각이 들게 했습니다. 하지만 알고보니 George Carlin이 Dr. Bob Moorehead의 글을 인용한것이었더군요. 인터넷에 George Carlin의 글인냥 퍼지고 있는지라 올바른 글쓴이를 알리는 사이트들이 좀 있었습니다. 저 또한 올바른 글쓴이를 찾지 못한 것에대해 사과를 드립니다. 그리고 알려주신 지저깨비님께 감사드립니다. 그리고 이 글이 저에게 전달되기까지 많은 도움을 준 George Carlin 에게도 감사를…

이 글은 인간이 최선의 선택을 하였지만 과연 정말 더 나아진 것인가 라는 생각과 인생의 본질이 얼마나 잊혀져 가고 있는지를 알려주는 좋은 메세지입니다. 이에 9/11 이나 총기사건후에 많이 인용되어 사용되었고 좋은글인 만큼 인터넷에 혹시나 번역글이 있나 찾아보았지만 George Carlin 의 글을 제대로 전달하고 있는 번역이 없는듯 하여 제가 직접 해버렸습니다. 그냥 잠시 생각하는 시간이 되었으면 해서 나눕니다. 요즘 누군가를 “판단”하는데에 급급한 제 자신을 보며 “사랑”의 시각을 가져야 하겠다는 생각이 들고 있거든요…

문법이나 어색한 표현은 알려주시면 수정토록 하겠습니다.

A Message by George Carlin

우리가 살고 있는 이 시대의 패러독스이다.
빌딩들은 높아졌지만 참을성은 짧아졌고 길은 더 넓어졌으나 시야는 더욱 좁아졌다. 소비하는 것은 늘었으나 소유한것은 줄어들었으며 구입하는 것은 많아졌으나 즐기는 것은 줄어들었다. 집은 더욱 커졌지만 가정은 줄어들었고 더욱 편리해진 반면 시간은 더욱 짧아졌다.

우리는 학위는 높아졌지만 지성은 떨어졌으며 지식은 많아졌지만 판단력은 줄어들었고 전문가들이 늘어났지만 문제들도 늘어났으며 의학은 발달했지만 건강은 줄어들었다.

우리는 과하게 술을 마시며, 과도히 담배를 피우고, 과도하게 소비하지만 과소하게 웃는다. 너무 과속을 하며, 너무나 심하게 화를 내고, 너무 늦게 자며, 너무 피곤하며, 너무 적게 읽으며, 너무나도 TV를 많이 보지만 너무나도 적게 기도한다.

우리의 소유는 늘어났지만 우리의 가치는 떨어졌다. 말은 많이 하지만 사랑은 드물며 남을 쉽게 미워한다.

우리는 먹고 사는 법은 배웠지만 인생을 사는 법은 배우지 못했다. 인생의 명은 늘어났으나 삶의 가치가 늘어나지는 않았다. 달까지도 왕복하였으나 길건너의 이웃에게는 가지 못하고 있다. 우주를 정복해 가면서도 정작 우리 안의 우주, 내면은 정복하지 못하고 있다. 더 큰일을 해가고 있으나 더 나은일을 하고 있지는 않다.

우리는 공기는 정화했지만 영혼은 오염시켰다. 분자를 정복했다고 하지만 차별은 여전하다. 글 쓰는것은 늘어났지만 배우는 것은 줄어들었다. 계획하는 것은 늘어났으나 이루는 것은 줄어들었다. 서두르는 것은 배웠으나 기다리는 것은 배우지 못했다. 더 많은 정보를 저장한다고 더 많은 컴퓨터를 만들어 복제는 늘어가지만 정작 대화와 소통은 점점 줄어들고 있다.

이 시대는
페스트푸드와 느린 다이제스트,
큰 체격과 작은 인성,
높아진 이윤과 낮아진 관계의 시대이며

맞벌이 부부가 늘어났지만 이혼은 늘어났으며
집은 더 멋져가지만 가정은 깨지고 있는 날들이고

고속 여행과 일회용 기저귀, 버려진 도덕성, 하룻밤 관계, 비만된 육체와 흥분케 하기도 하고 진정케도 그리고 죽음까지 가능한 약들의 날들이며

쇼윈도우엔 넘쳐나지만 정작 제고는 없는 시간들이다.

또한 당신에게 이 글을 전달케 하는 테크놀로지가 가능한 그런 시간이며 이 글을 나눌수도 혹은 delete 키를 눌러버릴수 있는 그런 시간이다.

기억하기 바란다. 사랑하는 이들과 시간을 보내라. 그들이 영원히 당신의 주위에 있지 않을 것이기 때문이다.
당신을 위대하게 바라보는 이에게 선한말 하는 것을 잊지마라. 그 작은 존재가 자라나서 당신곁을 떠날 것이기 때문이다.
당신 옆에 있는 이에게 따뜻한 포옹을 전하는 것을 잊지마라. 당신이 유일하게 마음을 담아 줄수 있는 보물이지만 동전한푼 들지 않기 때문이다.
당신의 동반자와 사랑하는 이들에게 “사랑해”라고 말하는 것을 잊지말되 진실되게 하라. 마음속 깊은 곳에서 우러나오는 입맞춤과 포옹은 상처를 치유할것이다.
그곳에 다시는 오지 않을 그 사람과 손을 잡고 그 시간을 소중히 간직하라.
사랑하는 시간을 갖으며 대화하는 시간을 갖으라! 그리고 당신속에 소중히 간직하고 있는 생각들을 나누는 시간을 갖으라.

그리고 언제나 기억하라.
삶의 가치는 우리가 숨을 쉰 숫자가 아닌 숨을 멎게할 정도의 값진 순간들로 결정된다는 것을 말이다.

Dr. Bob Moorehead. 번역 by 일몰.

The Paradox of Our Age:

The paradox of our time in history is that we have taller buildings but shorter tempers, wider Freeways, but narrower viewpoints. We spend more, but have less, we buy more, but enjoy less. We have bigger houses and smaller families, more conveniences, but less time. We have more degrees but less sense, more knowledge, but less judgment, more experts, yet more problems, more medicine, but less wellness.

We drink too much, smoke too much, spend too recklessly, laugh too little, drive too fast, get too angry, stay up too late, get up too tired, read too little, watch TV too much, and pray too seldom.

We have multiplied our possessions, but reduced our values. We talk too much, love too seldom, and hate too often.

We’ve learned how to make a living, but not a life. We’ve added years to life not life to years. We’ve been all the way to the moon and back, but have trouble crossing the street to meet a new neighbor. We conquered outer space but not inner space. We’ve done larger things, but not better things.
We’ve cleaned up the air, but polluted the soul. We’ve conquered the atom, but not our prejudice. We write more, but learn less. We plan more, but accomplish less. We’ve learned to rush, but not to wait. We build more computers to hold more information, to produce more copies than ever, but we communicate less and less.

These are the times of fast foods and slow digestion, big men and small character, steep profits and shallow relationships. These are the days of two incomes but more divorce, fancier houses, but broken homes. These are days of quick trips, disposable diapers, throwaway morality, one night stands, overweight bodies, and pills that do everything from cheer, to quiet, to kill. It is a time when there is much in the showroom window and nothing in the stockroom. A time when technology can bring this letter to you, and a time when you can choose either to share this insight, or to just hit delete…

Remember; spend some time with your loved ones, because they are not going to be around forever.
Remember, say a kind word to someone who looks up to you in awe, because that little person soon will grow up and leave your side.
Remember, to give a warm hug to the one next to you, because that is the only treasure you can give with your heart and it doesn’t cost a cent.
Remember, to say, “I love you” to your partner and your loved ones, but most of all mean it. A kiss and an embrace will mend hurt when it comes from deep inside of you.
Remember to hold hands and cherish the moment for someday that person will not be there again.
Give time to love, give time to speak! And give time to share the precious thoughts in your mind.
AND ALWAYS REMEMBER:
Life is not measured by the number of breaths we take, but by the moments that take our breath away.

Dr. Bob Moorehead

이 시대의 패러독스..

XML의 미래

미래의 XML은 어떤 모습일까?

Elliotte Harold, 교수, Polytechnic University

2008 년 3 월 04 일

Elliotte Rusty Harold가 XML 저장과 관련하여 자신이 생각하는 바를 예상합니다.

비록 느리지만 진보의 수레바퀴는 돌아간다. 마법의 수정구는 흐릿할지 몰라도 XML의 미래는 점차 윤곽이 드러나고 있다. 정확한 시기를 예측하기는 어려우나 적어도 목적지는 분명하다. XML의 미래는 웹, 구체적으로 웹 출판에 있다.

막 상 말하고 보니 웃기다. 웹과 출판은 동음이의(同音異意)가 아니던가? 애초에 웹 자체가 정보를 게시할 목적으로 생겨나지 않았던가? 출판 외에 웹으로 무엇을 할 수 있단 말인가? 아주 많은 일을 할 수 있다. 최근 3년 동안 기존 웹 사이트의 한계를 극복하는 웹 응용 프로그램에 대한 관심이 가히 폭발적으로 증가했다. 문서편집기, 스프레드시트, 게임, 다이어그램 그리기 도구 등 점차 많은 도구가 브라우저로 통합되고 있으며 이러한 추세는 웹 브라우저의 지역 저장소 기능으로 오프라인 작업이 가능해짐에 따라 앞으로 더욱 확산될 전망이다. 그러나 XML은 여전히 웹 1.0 출판에 뿌리를 두고 있으며 우리는 이 사실을 주목해야 한다.

해몽

올 해는 몇 가지 꿈이 이뤄질 전망이다. 네트워크 상에서 응용 프로그램을 배포하고 사용한다는 썬 사의 꿈이 한 걸음 현실로 다가왔다. 충격적이게도 현실에서는 응용 프로그램 언어로 자바(Java™)가 아니라 자바스크립트(JavaScript™)를 선택했지만 말이다. 10여전 전에도 충분히 실현이 가능했지만 경험과 비전과 클라이언트의 관심 부재로 썬 사는 진짜로 멋진 기회를 놓치고 말았다. 이제 회사는 '따라잡기'라는 필사적인 (그리고 실패할) 게임에 뛰어들어 고전 중이다.

브라우저로 운영체제를 대체하겠다는 넷스케이프 사의 꿈도 한 걸음 현실로 다가왔다. 넷스케이프 사는 미래를 내다보는 비전이 있었다. 하지만 불행하게도 원대한 비전을 실현할 비즈니스 능력과 예술적인 감각이 없었다. 그럼에도 불구하고 넷스케이프 브라우저의 직계 후손인 파이어폭스(Firefox)와 모질라 재단(Mozilla Foundation)은 이 용감무상한 신세계를 현실로 만들어 줄 핵심 주자로 활약 중이다.

젊고 민첩한 경쟁사가 자신을 집어 삼킬지도 모른다는 마이크로소프트(Microsoft®) 사의 악몽도 현실로 다가왔다. 회사는 썬 사와 넷스케이프 사에 정신을 파느라 구글이 오피스와 윈도우 시장을 넘본다는 사실을 알아채지 못했다. 지메일(GMail), 구글 독스(Google Docs) 등과 같은 응용 프로그램은 급속하게 기반 운영체제로부터 독립을 선언하고 있다.

물론 브라우저를 돌리려면 아직도 운영체제가 필요하다. 하지만 점차 운영체제 이름 자체는 무의미해지리라. 마이크로소프트 윈도우(Windows®) 운영체제가 돌아가는 한 아무도 PC 제조업체 이름을 신경쓰지 않았던 지난 10여년처럼 말이다. 이제는 구글이 돌아가는 한 아무도 운영체제 개발업체 이름을 신경쓰지 않는 시기가 다가왔다. PC가 그랬듯이 운영체제도 점차 일반재화가 되어가고 있다. 마이크로소프트 윈도우 왕국은 패배했다기보다 버려졌으며, 마이크로소프트 사는 빈 성문을 지키고 있을 따름이다.

위로

이게 대체 XML과 무슨 상관인가?

evalJSon() 옵션 evalJSon() 함수는 나도 안다. 이제껏 살펴 본 일부 Ajax 응용 프로그램으로 판단하건데, 상당수 Ajax 응용 프로그래머보다 내가 evalJson() 함수를 더 잘 안다. 더 나은 방법이 있음에도 많은 Ajax 프로그래머가 eval()을 고집하고 있다.

관 심과 이목을 한 몸에 받아온 기술치고 XML은 이 상황과 거의 무관하다. 혹자는 비동기 자바스크립트(Asynchronous JavaScript) + XML (Ajax)을 들먹이며 Ajax에서 x는 XML을 뜻한다고 주장할지도 모르지만, 실제 이 목적으로 XML을 사용하는 사람은 거의 없다. Ajax라는 약어가 출현함과 거의 동시에 웹 개발자들은 XML을 원시 자바스크립트 코드로 교체하여 데이터로 넘긴 후 eval()로 계산하기 시작했다. 보안 구멍이 훤히 뚫힌 셈이다.

문 제는 자료 형식이 아니라 API에 있다. 구체적으로 DOM(Document Object Model)이라는 API가 문제다. 대다수 개발자들은 DOM부터 배운 후 다른 대안을 배우지 못했다. DOM과 XML을 구분하지 않는 탓에 DOM에 대한 근거 있는 혐오와 XML에 대한 근거 없는 혐오를 혼돈한다. DOM은 최소의 공분모 API가 아니라 최악의 공분모 API다. 일부러 노력해도 DOM보다 못한 XML API를 설계하기 어려울 정도다. 그러나 개발자들은 새로운 기술을 배우기를 극도로 꺼린다. 자바 공동체 내에서는 JDOM과 dom4j가 다소 진전을 보였을 뿐이지만, 자바 공동체를 벗어나면 E4X와 아마라 XML 툴킷(Amara XML Toolkit)처럼 더 나은 대안이 존재한다. 그러나 이 대안들은 거의 알려지지 않았으며 대놓고 거부 당하고 있다. JSON(JavaScript Serialized Object Notation)이라는 천재적인 개념 역시 커다란 취약점이다. JSON은 실행 가능한 자바스크립크 코드이므로 자바스크립트 프로그래머 입장에서는 새로운 내용을 익힐 필요가 없다. 더욱 안전한 데이터 전송 방법이 있더라도 받아들이지 않는다.

널리 사용하는 약어 API: application programming interface HTML: Hypertext Markup Language SGML: Standard Generalized Markup Language W3C: World Wide Web Consortium XML: Extensible Markup Language

DOM 은 XML 목에 걸린 맷돌이다. 소프트웨어 개발 분야가 XML을 폭넓게 활용하지 못하는 가장 큰 걸림돌이 DOM이다. 프로그래밍 측면에서 XML은 이 2000파운드짜리 닻을 질질 끌면서 나갈 만큼 나갔다. W3C(World Wide Web Consortium)와 브라우저 제조업체가 DOM을 이성적인 대안으로 교체하지 않는 한(되도록이면 이성적인 대안 여러 가지로 교체하면 좋겠다. 한 API로 모든 문제를 처리하려다가는 DOM짝이 나기 십상이다) XML은 소프트웨어 개발, 특히 (앞으로 점차 중요해지는) 웹 소프트웨어 개발에서 더 이상 앞으로 나가기 어렵다. W3C는 현장 개발자들의 필요를 인식하되 나쁜 명세는 반대해야 한다.

그래서 XML이 죽었느냐고? 천만의 말씀이다. 나는 XML의 미래가 밝고 중요하다고 믿는다. 단지 기존 소프트웨어 개발이나 웹 소프트웨어 개발과는 별다른 관련이 없다고 믿는다. 2008년도 이후에 XML이 움직일 방향을 이해하려면 먼저 1997년 이전으로 돌아가 XML의 기원을 살펴보자.

위로

XML의 기원

XML 은 결코 소프트웨어 개발에 사용하려던 언어가 아니었다. 적어도 초창기에는 그랬다. XML 1.0, XPath, XSLT(Extensible Stylesheet Language Transformation), XML 네임스페이스(XML Namespace), XHTML(Extensible Hypertext Markup Language), DOM 등 초기 명세를 살펴보면 어느 것도 소프트웨어 개발자를 염두에 두지 않았다. XML을 소프트웨어 개발용으로 만들었다면 JSON처럼 리스트와 맵과 다양한 자료 유형을 지원했으리라. XML은 출판, 좀더 구체적으로 웹 출판에 사용하려고 설계한 언어였다.

XML은 전자문서 출판을 목적으로 20여년 동안 사용해 온 기술인 SGML에서 나왔다. IBM®의 코드(Codd) 박사가 데이터를 순서 없는 작은 조각으로 나누어 구조화하는 방법을 깨달았던 바로 그 시기에 같은 IBM의 찰스 F. 골드파브(Charles F. Goldfarb), 에드워드 모셔(Edward Mosher), 레이몬드 로리(Raymond Lorie)는 표 형식으로 정리하기 불가능한 대규모의 정렬된 문서를 구조화하는 방법을 알아냈다. 코드 박사가 재고와 재정 기록같은 비즈니스 데이터를 고려한 반면, 골드파브와 모셔와 로리는 연간 보고서와 항공기 기술 매뉴얼같은 비즈니스 문서를 고려했다.

SGML은 출판 문제를 해결하려는 언어였다. 즉, 프로세서와 문자 집합과 자연 언어와 운영체제와 제조업체가 다른 여러 가지 플랫폼에 흩어진 수십만 장의 문서를 읽고, 쓰고, 보수하고, 고치고, 인쇄하고, 검색하는 방법을 제시하는 언어였다. SGML은 정부 기관과 군대에서 다소 성공을 거두었으며, 오라일리(O’Reilly)와 같은 일부 기술서 출판사가 때때로 사용했을 뿐 일반인들이 사용하기에는 너무 무겁고 복잡했다. 심지어 출판 업계 사람들조차도 꺼릴 정도였다.

SGML의 가장 큰 성공이자 가장 큰 실패는 HTML이었다. 애초에 HTML은 SGML 응용 프로그램으로 출발했으나 브라우저나 편집기나 웹 페이지를 개발하는 사람들 누구도 SGML이 Standard Generalized Markup Language를 줄인 말이라는 사실 외에 SGML에 관해 아는 바가 없었다(이 사실조차 모르는 사람도 많았다). 결국 무질서한 확장으로 말미암아 HTML이 SGML 구조를 따라야 한다는 주장은 급속히 힘을 잃어갔다. 심지어 1996년 당시 존재했던 몇 안 되는 고가 SGML 도구도 실제 사용 중인 HTML의 난잡한 내용을 인식하지 못할 정도였다.

바로 이런 난국을 타계하고자 XML이 나왔다. 다른 한 편으로 SGML을 합리적으로 단순화하여 모두가 충실하게 지킬 표준 부분집합을 만들려는 목적이 있었다. SGML보다 단순한 명세로 SGML보다 널리 받아들여지리라 여겨졌고, 이 점에서 XML은 대체로 성공을 거두었다.

다른 한 편으로 XML은 브라우저 간 호환성 문제와 특이성을 줄이고 형식이 갖춰진(well-formed) 웹을 유도하려는 의도였는데 이 점에서 XML은 대체로 실패를 맛보았다. 엉망진창인 태그 짬뽕을 교체하기는 커녕 XML과 XHTML은 브라우저가 처리해야 할 또 다른 HTML 사투리가 되고 말았다.

성공이든 실패든 XML은 책, 매뉴얼, (가장 중요하게) 웹 페이지를 출판할 목적으로 만들어진 언어다. 소프트웨어 개발에 사용할 의도도 아니었고 소프트웨어 개발에 맞게 최적화되지도 않았다. 환경 설정 파일, 원격 프로시저 호출, 개체 직렬화, 데이터베이스 덤프, 기타 객체 지향 작업을 수행하리라 예측하지도 계획하지도 않았다. 그러니 XML이 이런 잡무에 100% 적합하지 못하더라도 놀랄 일이 아니다. 그럼에도 불구하고 XML은 개발자들에게 이제껏 없었던 가능성을 보여주었다. 플랫폼 독립적이고, 언어 중립적이고, 국제화가 쉬운 자료 형식에다 우수한 공짜 구문 분석기를 구하기도 수월했다. 정수나 부동소수와 같은 자료 유형과 리스트나 맵과 같은 기본 자료 구조가 없다는 단점에도 불구하고 프로그래머들은 이러한 장점을 거부하기 어려웠다.

그러나 프로그래밍은 XML이 원래 의도했던 목적이 아니므로 프로그래밍 언어로서 XML을 판단해서는 안 된다. 프로그래밍 언어로서 강점을 찾거나 가능성을 점쳐서도 안 된다. XML의 강점과 가능성을 찾으려면 원래 XML이 목적한 용도인 출판, 특히 웹 출판으로 돌아가야 한다. 웹에서 출판은 다음과 같은 세 가지 구성요소로 나눠진다.

• 저작자
• 출판사
• 독자

독자쪽은 문제가 없다. 브라우저가 있으니까. 현재 주요 브라우저는 모두 XML을 지원한다. 그러나 저작과 출판과 둘 사이 연결은 이제 막 시작 단계다.

위로

저작

문 서를 출판하려면 작성부터 해야 한다. 이 부분에서 승패는 이미 판가름 났다. XML이 승자다. 이제 주요 오피스 프로그램은 기본적으로 문서를 XML 압축 파일로 저장한다. 여기에는 마이크로소프트 오피스, 오픈오피스, 스타오피스, 워드퍼펙트 오피스, 로터스 노츠(Lotus® Notes®)가 포함된다. 심지어 어도비 일러스트레이터(Adobe® Illustrator®)와 같은 그래픽 응용 프로그램도 이제는 문서를 XML로 저장한다. 아직 이 진영에 속하지 않은 주요 소프트웨어로는 iWorks가 있지만 내년 즈음에는 가담하리라 예상한다.

마크업-중심 편집기의 종말 초창기에는 많은 개발업체가 내장 문서를 트리 형식으로 제어하는 마크업-중심 편집기를 내놓았다. 스윙의 JTree처럼 다양한 트리 컴포넌트를 이용하여 문서를 구현하기는 매우 쉬웠지만 XML 문서를 트리 형식으로 읽고, 쓰고, 편집하려는 사람은 아무도 없었다. 결국 시장에서 사라졌지만 아쉬워하는 사람은 아무도 없었다.

이 러한 변화는 중요한 발전임에도 불구하고 별다른 주목을 끌지 못했다. XML은 (당연히 그래야 하듯이) 사용자에게 보이지 않기 때문이다. 일반 스프레드시트 사용자 입장에서는 엑셀(Excel®)이 자료를 디스크에 저장하는 정확한 방식을 알 필요가 없고 별 관심도 없다. 그러나 협력 개발업체 입장에서 XML 텍스트 구조는 역공학으로 분석하여 응용 프로그램에 접목하기가 한결 수월하다. 어휘 문서가 부실하고 일관성도 떨어지는 오픈오피스 XML조차도 예전 이진(binary) 형식에 비하면 수천 배는 편하다. 게다가 오픈독(OpenDoc)처럼 좀더 합리적이고 좀더 플랫폼에 무관하고 좀더 기존 기존 형식에서 자유롭다면 금상첨화라 하겠다.

2008 년 현재, 오피스 문서에서 사용하는 XML 어휘를 놓고 상당한 불평이 터져나오지만 어느 쪽이든 건설적인 논쟁은 거의 없다. 나는 마이크로소프트 사가 2월에 OOXML을 ISO 표준으로 통과시키려는 시도가 실패하리라 예상하지만 확신은 못하겠다. 어쨌거나 메시지는 분명하다. 앞으로 마이크로소프트 오피스는 오픈오피스, iWorks 등 기타 경쟁 제품에 계속 시장 점유율을 잃어갈 것이다.

오피스가 나쁜 제품이라서가 아니다(오피스는 나쁜 제품이 아니다). 오픈 소스가 아니라서도 아니다(오피스는 오픈 소스가 아니다). 더 이상 올라갈 데가 없기 때문이다. 더 이상 성장할 여지가 없기 때문이다. 이제는 어느 정도 깊이, 어느 정도 빨리 추락하느냐는 질문만 남았다. 현재 마이크로소프트 왕국이 당면한 위협은 네델란드와 노르웨이처럼 오픈독과 오픈소스 솔루션을 필수적으로 요구하는 정부가 점차 많아지리라는 사실이다. 심각도는 덜하지만 PC가 널리 퍼지면서 윈도우와 오피스 가격이 전체 PC 가격의 절반을 넘는다는 사실 또한 희소식은 아니다. 어떤 면에서 마이크로소프트 사는 이미 문제를 인식하고 교사와 학생 가족과 학교와 눈꼽만치라도 연관되는 모든 사람을 대상으로 저가 학생/교사용 오피스 에디션을 내놓았다. 그러나 동시에 오피스의 불법복제방지 기능을 강화하고 있으니 ‘왼손이 하는 일을 오른손이 모르게 하라’라는 교훈을 확실히 실천하는 중이라 하겠다. 그렇다고 불법복제가 줄어들 가망성은 없으나 사용자를 오픈 소스 대안으로 몰아갈 가능성은 충분하다.

이제 모든 오피스 문서가 XML 형식이므로 한 형식을 다른 형식으로 바꾸기가 놀랍도록 쉬워졌다. 2008년은 XML 계열 중에서도 업계 판도를 뒤집은 기술인 XSLT가 나온 10주년이다. 새로운 2.0 버전은 더욱 강력하다. 조만간 경쟁 제품끼리 문서 형식을 변환하기가 너무도 쉬워져 대다수 사람은 더 이상 문서 형식을 따지지 않을 것이다. 변환 과정에서 몇몇 스타일이나 매크로를 잃을지도 모르지만, 어차피 범용적으로 사용하지 않는 기능이니 상관이 없다. 제품 개발업체가 문서 형식을 독점하는 현상은 이제 소소한 문제가 되었다.

물론 가장 중요한 변환은 오픈독과 OOXML 사이에 일어나는 변환이 아니라 오픈독이나 OOXML에서 XHTML로 이루어지는 하향 변환(down-conversion)이다. 현재 오픈오피스와 마이크로소프트 오피스가 제공하는 HTML 변환 기능은 아주 형편없다. 다른 개발업체가 끼여들 틈새가 충분하다. 가장 중요하게 기업 사이트 개발자들이나 웹 마스터들이 자기네 사이트용으로 내놓는 사용자 정의 템플릿(custom template)에 주목한다. 이런 템플릿 덕택에 일반인들은 기존 방식으로 마이크로소프트 워드 문서를 작성한 후 CMS(Content Management System)로 직접 읽어들일 수 있다. 편집 도구와 검토 도구도 제작하기 쉽다. (사람은 GUI 인터페이스를 사용하지만) 컴퓨터가 마크업을 모두 생성하므로 문법 오류와 양식 오류가 사라지기 때문이다. 2008년 말까지 모든 웹은 아니지만 지금보다 많은 웹이 이러한 상태에 이르리라 생각한다.

또 한 XSLT와 XML 오피스 형식은 기존에 숨겨졌던 자료를 드러내는 역할도 한다. 지난 수십 년 동안 수많은 비즈니스 문서가 읽히지 않은 채 파일 시스템 속에 묻혀 있었다. 물론 더 이상 쓸모 없는 문서도 당연히 많겠지만, 중요한 정보가 담겼으나 찾아낼 방도가 없어 잊혀진 문서도 있다. 기업 개발자들은 이러한 기존 오피스 문서를 새로운 XML 기반 형식으로 자동 변환한 후 XSLT와 XQuery로 조회가 가능하게 만듦으로써 잊혀진 정보에 생명을 불어넣을 것이다.

워드나 오픈 오피스 라이터와 같은 기존 오피스 프로그램을 저작 도구로 사용한다면 서버에서는 이를 어떻게 처리할까? 문서 내용을 클라이언트에서 서버로 옮기는 방법은? 여기서 2007년에 나온 두 가지 중대한 1.0 배포 기술이 진가를 발휘한다. 바로 APP(Atom Publishing Protocol)와 XQuery다.

위로

APP(Atom Publishing Protocol)

흔 히 기술에 익숙치 못한 사람들에게 웹 저작 방법을 가르칠 때는 두 가지 난제에 직면한다. 하나는 의미론적 마크업(Semantic Markup)을 이해시키는 일이고, 또 하나는 FTP 사용법을 가르치는 일이다. (표준 파일 열기 대화 상자조차 사용할 줄 모르는 컴맹이 많다는 사실을 명심한다. 그들은 모든 문서를 “내 문서” 폴더나 바탕화면에 저장한다. 실수로 다른 곳에 넣으면 찾지 못한다. 프로그래머는 계층이라는 개념을 알지만 많은 사용자는 그 정도로 추상적인 사고를 하지 못한다.)

오픈오피스 와 마이크로소프트 워드처럼 XML을 지원하는 워드프로세서는 첫 번째 문제를 해결한다. APP는 두 번째 문제를 해결한다. APP는 사전에 협약하거나 개념적인 모델을 공유하지 않고도 독립적인 클라이언트와 서버가 서로 통신할 수 있도록 표준 프로토콜을 제공한다. 웹 검색에서 HTTP가 맡았던 역할을 웹 저작에서는 APP가 맡는 셈이다.

소프트웨어 개발업체는 각 서버에서 돌아가는 APP 서비스와 통신하는 저작 도구를 개발할 수 있다. 독자적인 편집기 형태도 가능하고 워드나 오픈오피스와 같이 기존 오피스 제품의 플러그인 형태도 가능하다. 문서를 업로드하는 방법은 지역 디스크에 파일을 저장하는 방법만큼이나 쉽다. 아니, 때로는 더 쉬울지도 모른다. 새 문서를 제작하려면 게시할 URL과 사용자 이름과 암호만 있으면 충분하다(위키 스타일 사이트라면 사용자 이름과 암호도 필요 없다). 문서를 편집할 때는 문서 URL만 있으면 된다.

위로

저장소

이제 2008년에 (워드나 오픈오피스로) XML 문서를 작성하는 방법과 서버로 저장하는 방법을 알았다. 그럼 마지막으로 이 멋진 XML 문서를 어디다 저장할까?

전 통적으로 두 가지 방법이 있다. 하나는 파일 시스템에 저장하는 방법이고, 다른 하나는 관계형 데이터베이스에 BLOB(Binary Large Object)로 구겨넣는 방법이다. 둘다 많이 쓰는 방법이지만 어느 쪽도 웹 문서에는 적합하지 않다.

파일 시스템은 간단하고, 안정적이며, 널리 알려진 기술이지만 검색 기능이 매우 부실하다. 같은 데이터를 여러 곳에다 중복하여 저장하며, 문서 내부 구조를 전혀 알지 못하며, 하위 문서(subdocument) 단위로 쪼개지도 못한다.

관계형 데이터베이스는 특정한 순서가 없고 중복이 적은 데이터 조각을 저장하기에 아주 적합하다. 그러나 XML은 어느 쪽에도 속하지 않는다. 관계형 테이블을 XML 문서로 변환하기는 쉽지만(각 행을 요소로 만들고 각 필드를 속성이나 자식 요소로 만들면 된다), XML 문서를 관계형 테이블로 변환하기는 쉽지 않다. 많은 XML 문서는 순서가 있으며, 공백이 많고, 요소 유형이 섞여 있으며, 반복적이면서도 고유한 요소를 가지고, 중첩 단계를 예측하기 어려운 등 관계형 테이블에 적합하지 못한 특징이 다분하다. 특히 HTML이나 XHTML 등과 같은 웹 페이지는 이러한 특성을 모두 지닌다. HTML 문서와 XML 문서를 관계형 데이터베이스에 저장해도 되지만(간혹 MySQL을 사용하는 경우도 있다) 결과는 깔끔하지도 빠르지도 못하다. 문서를 작은 단위로 낱낱이 쪼개면 자료를 검색하고 선택하고 순서를 변경할 수는 있다. 그러나 적당한 성능을 얻기 위해 소모하는 비용 탓에 배보다 배꼽이 더 커져버린다. 비교적 간단한 작업이라도 원래 SQL 용도와 무관한 탓에 SQL 쿼리는 반 페이지를 훌쩍 넘어버리고, 복잡한 쿼리를 개발하고 유지보수하는 작업 또한 악몽이 된다.

또 다른 방법으로 각 문서를 BLOB로 저장해도 된다. 간단하고 빠른 방법이지만 문서 일부를 선택하거나 다른 문서와 결합하는 기능은 모두 포기해야 한다. 현재 응용 프로그램 논리는 PHP나 루비 등과 같은 서버측 프레임워크에서 구현하는 추세다. 데이터베이스는 그저 파일 시스템보다 문서 분리가 나은 대안에 불과하다.

우리에게 필요한 데이터베이스는 일반 웹 문서가 지니는 계층 구조를 (잘라내지 않고) 포용하는 데이터베이스다. 그리고 처음으로 이런 데이터베이스가 시장에 나왔다. 가격대가 다양하고, 안정적이며, 곧바로 쓸 수 있다. 저가 제품으로는 eXist와 버클리 DBXML이 두각을 나타낸다. 마크 로직(Mark Logic)과 같은 고가 XML 데이터베이스는 초기 비용을 감당할 여력이 되는 대형 출판사를 끌어들이고 있다. IBM DB2® 9 pureXML™과 같은 제품은 XML 문서와 테이블형 문서를 혼합하려는 고객들에게 XQuery를 퍼트리리라 예상된다.

이 같은 초기 제품과 비교하여 새로 나오는 제품은 더욱 안정적이고, 더욱 확장성이 있고, 더욱 신뢰성이 높다. 가장 중요하게는 모두가 여러 해 동안 개발한 끝에 나온 표준 언어인 XQuery 1.0을 공유한다. 한 데이터베이스에서 다른 데이터베이스로 응용 프로그램을 이식할 가능성은 필요 이상으로 강조된 반면, 한 서버에서 다른 서버로 개발자의 기술을 이식할 가능성은 필요 이상으로 간과되어 왔다. 여섯 종류나 되는 다양한 쿼리 언어를 그것도 6개월마다 배우고픈 사람은 없다. 이제는 배울 필요도 없다.

XQuery에서 갱신(Update) 부분은 급속도로 진전을 보이고 있다. 2008년 내에는 끝나지 않겠지만 이미 구현해도 좋을 정도로 안정적이다. 새 안이 나올 때마다 코드를 조금씩 손봐야 하는 수고를 꺼리지 않는다면 말이다. 올해 안으로 상황은 나아질 전망이다.

마지막으로 2008년에는 javax.xml.xquery가 출시될 예정이다. 이는 자바 프로그램을 XQuery 엔진/데이터베이스와 연결하는 표준 API다. XQuery용 JDBC라 하겠다. 이 API를 사용하면 자바 코드와 XQuery를 섞어쓸 수 있다. 2009년 자바 7이 출시된 후에야 표준 자바 라이브러리 클래스에 들어가겠지만, 이미 많은 제품에서 이를 지원하며, 앞으로 그 수가 늘어날 전망이다.

위로

향후 방향

소셜 북마크 mar.gar.in Digg this story Post to del.icio.us Slashdot it!

XQuery 는 드디어 실전에 투입될 준비를 갖추었다. APP는 막 출전하려는 참이다. 나더러 XML에 시간과 돈을 투자하라면 바로 이 두 가지 기술을 주목하겠다. CMS, 블로그 엔진, 게시판은 이미 넘치게 많다. 그러나 문서를 쉽게 저장하고 게시하는 방법은 부실하다. 전용 XML 데이터베이스와 APP가 이러한 요구를 충족시킨다.

그리고 이 자리를 빌어 개발자 도구를 하나 더 요청한다. 앞서 소프트웨어 개발에서 XML은 미래가 없다고 말했지만 그래도 아직 생명은 남아 있다. JSON이 가르치는 교훈을 살펴보면, 응용 프로그램은 그리 확장성 있는 자료 구조를 필요로 하지도 않고 원하지도 않는다. 기본 자료 유형과 리스트와 맵을 지원하는 기본 XML 형식이면 충분하다. Listing 1처럼 간단한 XML 말이다.

Listing 1. XML 기본 자료 형식

<PRE class=displaycode> <data xmlns="http://www.w3.org/data"> <list> <string>Foo</string> <int>17</int> <year>1999</year> <list> <map> <entry> <string>Boston</string><string>Red Sox</string> </entry> <entry> <string>New York</string><string>Yankees</string> </entry> </map></data></PRE>

위와 같은 XML 문서를 자바, 자바스크립트, 파이썬(Python), 펄(Perl), 루비(Ruly)와 같은 언어의 고유(native) 자료 구조로 변환하는 라이브러리는 어떨까? JSON과 비슷하지만 XML 확장성을 고려하면서도 보안 문제가 없는 도구가 가능할까? 도전해 볼 해커가 있는가?

 

참고자료

교육

• DB2 9 pureXML로 Microsoft Office 2007 문서 관리하기 (Chris C. Gruber, developerWorks, 2007년 8월): IBM DB2 9를 사용하여 PHP의 PDO와 XQuery로 데이터를 저장하고 검색하는 방법
  
  
• Manage a media collection with the Atom Publishing Protocol (Nicholas Chase, developerWorks, 2007년 4월): Atom Cyndication Format과 Atom Publishing Protocol을 결합하여 웹 기반 미지어 저장소를 생성하는 방법
  
  
• An introduction to XQuery (Howard Katz, developerWorks, 2006년 1월): XQuery W3C 표준 둘러보기
  
  
• 왜 XForms인가? (Elliotte Rusty Harold, developerWorks, 2006년 10월): XForms이란? 국제화, 접근성, 디바이스 독립성 살펴보기
  
  
• XML 2007 (한글) (Elliotte Rusty Harold, developerWorks, 2008년 2월): 2007년 XML을 돌아보며
  
  
• IBM XML 인증: XML과 관련 기술 분야에서 IBM 인증 개발자가 되는 법
  
  
• XML 기술 라이브러리: 기사와 팁, 튜토리얼, 표준, IBM 레드북 등 다양한 기술 자료를 제공한다.
  
  
• developerWorks 기술 행사와 웹 캐스트: 최신 기술 동향 파악
  
  
• 기술 온라인 서점: 다양한 기술 서적을 제공한다.
  
  

제품 및 기술 얻기

• eXist 전용(native) XML 데이터베이스: 전적으로 XML 기술에 기반을 둔 오픈 소스 데이터베이스 관리 시스템으로, XML 데이터 모델에 따라 XML 데이터를 저장하고 XQuery를 사용할 수 있다.
  
  
• IBM 평가판 소프트웨어: IBM 평가판 소프트웨어를 developerWorks에서 바로 내려받을 수 있다.
  
  

토론

• 포럼에 참여하기.
  
  
• XML 영역 토론 포럼: XML과 관련하여 다양한 토론을 나눌 수 있다.
  
  
• developerWorks 블로그: 블로그를 읽어보고 developerWorks 공동체에 참여해 보라.

 

필자소개

		Elliotte Harold: 교수, Polytechnic University [출처] XML의 미래 (자료출처:한국IBM) (자바 으뜸 동호회(PerfectjavA)) |작성자 김종권