가려웠던 부분을 확실히 긁어줄수 있을꺼 같아요..

오늘도 힘들게 표준화작업을 하는데 너무 힘드네요...이 책이 많은 도움을

줄수 있을꺼 같네요...기다리던 책이 나온거 같습니다.....ㅎㅎㅎ

'DOM 스크립트’ 바로 구매해서 잘 보겠습니다..^^

by 수야러브 | 2007/07/13 16:05 | Book Story | 트랙백(3) | 덧글(0)

디자이너, 개발자 그리고 그들의 PM - 성공적인 프로젝트를 위하여

디자이너, 개발자 그리고 그들의 PM - 성공적인 프로젝트를 위하여

흔히 웹프로젝트를 진행할때

디자이너, 개발자(또는 프로그래머) 그리고 그들을 관리하고 대변해주는 PM 이 있습니다.

성공적인 프로젝트를 위해서는

각기 상대 직책에 대해 알 필요가 있습니다.


앞으로 이 세계에 뛰어드실 예비 IT인이나


혹시 지금 개발자, 디자이너, PM때문에 힘들어하시는분에게 도움이 되었으면 하는

바램에서 키보드를 두드려봅니다.

==========================================================================================================
To. Designer


디자이너는 IT직종중에서 가장 창조적인 역할을 하는 직책입니다.

때문에 그만큼 고민을하고 몸의 컨디션이나

마음가짐에 따라서 결과물의 질이 크게 좌우되곤 하죠.

대부분 디자이너분들은 매우 예민합니다. (역설로 들리시겠지만 남자디자이너가 더 예민한경우가 많습니다.)

때문에 그 예민함과 자신이 내놓은 결과물에 흠집을 내는일을

"극도"로 꺼려하지요.

하지만 디자이너는 프로젝트에 동참한 이상

디자이너가 해야할일은

물론 훌륭한 디자인을 창조해내는것도 중요하지만

그외의 임무도 띄고 있습니다.

1. 궂은일도 기꺼이 감수하라.

"를"->"을" 로 바꾸는 일,

1px 차이로 어긋나는 이미지,

모니터마다 다르게 보이는 색상들...

디자이너를 짜증나게 하는 일들입니다.

하지만 이것을 알아두십시요.

자신이 이세상에 나오게한 모든 이미지를 비롯한 아이콘이나 텍스트들은

자신이 끝까지 책임지십시오.

프로젝트에 "사소한 일"은 없습니다.

끝까지 자신이 만들어낸 이미지는 자신의 얼굴이고 자신의 능력입니다.

어떤 훌륭한 디자이너도 붓칠한번에 몇백만원을 벌지 않고

선한번 긋는다고 박수쳐주지 않습니다.

다 사소한작업들이 쌓이고 쌓여서 훌륭한 결과물을 만들어내느것입니다.

2. HTML을 익혀라.

자신은 디자이너라고 html 안하려는 디자이너분들.

결국 자신의 몸값을 낮추는 결과입니다.

프로그래머가 더 잘안다고 html 안한다고 하시는 분들은

속으로는 "나같이 세련된 디자이너가 html 따위를 만질순 없지" 라는 생각을 한다면

그것은 자만이요 오만한 행동입니다.

조연없이는 영화도 드라마도 찍을수 없습니다.

스스로 조연이 되기를 자청하십시오.

그러면 훗날 빈틈없는 디자이너가 될 수 있습니다.

3. 타인의 의견에 충분히 귀 기울여라.

디자이너들뿐만이 아니라

IT직종에 있는 분들이 대부분 자존심이 강하고 유아독존하려는 경향이 있습니다.

하지만 엄연히 사회입니다.

프로젝트의 성공은 자신의 최고실력을 발휘하는것이 아닌

"우리의 최고실력을 발휘하는것입니다."

다수의 의견을 따르고 거기에 소수의 의견까지 기억하십시요.

평범한 디자이너는 없습니다.

자신의 고집만을 부린다면 "오만한 그림쟁이"일 뿐이며

다른이의 의견을 취합할줄 안다면 "능력있는 디자이너"가 될것입니다.

4. 자신의 의견에 충분한 근거를 제시하라.

디자인이라는 일 자체가

굉장히 추상적이며 상대적인 분야입니다.

내가 볼땐 아무리 이쁘고 요즘 트렌드에 맞게 디자인을 했어도

그것을 접하지 않은 사람들에게는 "못보던것"일뿐입니다.

그들에게 자신의 결과물에 대한 설득을 시키려면

"말"보다 "근거"를 제시하는 방법을 터득하십시요.

훌륭한 사이트의 스크린샷을 뽑아서 비교한다던가

해상도를 통계한 수치를 제공한다던가

그에 대한 타당한 근거를 제시하여 설득시키십시요.

데이타와 문서의 힘은 당신을 보다 Professional 하게 만들어줄것입니다.

==========================================================================================================

To. Developer

IT분야에 개발자는 종류가 참 많습니다.

자바개발자, 웹프로그래머, 플래시 개발자, 모바일 개발자, 서버관리자, Data아키텍쳐

참 많습니다.

하지만 프로그램 방법론이 크게 객체지향과 절차지향으로 나눌수 있듯이

개발자가 맡게되는 업무는 공통점이 많을것입니다.

다른 디자이너나 PM이 꼬치꼬치 따지거나

당연한것들을 이것저것 요구하거나 물어볼대 짜증이 쓰나미처럼 밀려오죠...

하지만 우물안에만 있어서는 결코 하늘을 날지 못합니다.

1. 충분히 설명하고 또 설명하라.

프로그램은 해당 직종이 아닌 사람이 봤을땐 외계어입니다.

한국인이 아랍어 봤을때 실타래풀어놓은것 처럼 보이듯이

디자이너가 개발자의 전문용어나 구조적인 용어들은

당췌 딴나라 얘기일것입니다.

그들에게 최대한 쉽고 전문용어를 풀어서 설명해주십시요.

그리고 가장 중요한것은

"무슨뜻인지 이해가시죠?" 라고 확인하십시오.

모른다면 더 쉽게 풀어서 설명하십시오.

그렇지 않다면 당신은 똥고집쟁이 프로그래머 될것이지만

그들에게 충분히 설명하고 원활한 해결방법을 설득시켰다면

당신은 "뛰어난 개발자" 가 될것입니다.

2. 상대의 비합리적인 요구에는 반드시 대안을 제시하라.

무조건 안된다고 하는 개발자보다 무식해보이는 행동은 없습니다.

왜 안되는지에 대한 설명을 하고

그에 대한 대안을 제시해야합니다.

그래도 상대가 계속 주장을 관철시킨다면

설명이 부족한것입니다.

상대가 내입장에서 생각할 수 있을정도의 충분한 설명이 필요합니다.

개발자가 소요하는 시간은

미팅과 회의 > 고민하는 시간 > 파일명 생각하는시간 > 주석다는 시간 > 소스짜는 시간

순일수록 훌륭한 개발자라고 하더군요.

설득과 설명을 멀리하지 마십시오.

그래야 당신도 상대도 수월하게 일을 할 수 있습니다.

3. 기획을 하는것에 대해서 두려워하지 말아라.

스스로를 수동적인 기계로 만들지 마십시오.

능동적으로 책임감을 가지고 예상하지 못한 문제점에 대해서

스스로 기획하고 상부로 건의하십시오.

이는 당신의 몸값을 올려줄 뿐만 아니라

기획자나 PM으로 가는 방법을 제시해줄것입니다.

==========================================================================================================

To. Project Manager

보통 PM은 개발자나 디자이너보다

상사일 경우가 많습니다.

하지만 PM은 그들위에 있는 존재가 아닙니다.

과장되게 말하면 PM은 그들의 "시다바리"입니다.

디자이너에게는 훌륭한 디자인을 뽑아낼수 있도록 모든 컨텐츠를 제공해주고

개발자에게는 최적화된 모듈이 나올수 있도록 모든 정보를 수집하여 문서화해서 넘겨주어야 합니다.

거기다가 PM은 항상 예상가능한 문제점에 대해서 대비해야합니다.

기간이 길어질것에 대한 대비라던지

비용이 추가될것에 대한 대비를 해야합니다.

디자이너와 개발자분들은 어떻게 생각하실지 모르겠지만

프로젝트가 성공하기 위해서는

무엇보다 PM의 역할이 가장 중요합니다.

1. 자신을 그들보다 낮춰라.

절대 명령하지 마십시오.

어떻게 결정된 사안이든지

그들의 의견을 묻고 "나의 의견"이 아닌

"우리의 의견"으로 인식시켜야합니다.

그것은 그들 스스로에게 책임감을 심어주는 중요한 계기가 됩니다.

돈보다 중요한것은 열정입니다.

열정을 갖기 위해서는 스스로에게 목표에 대한 중요성을 일깨워줘야하는데

"명령"을 해서는 그들의 마음을 움직일수 없습니다.

스스로를 결과물을 만들어내는 기계로 인식해버리고

재료를 넣으면 결과물만 만들어내는 녹즙기로 되버립니다.

이는 일을 지루하게 느끼게 하고 해야할 의무감마저 잃어버리게 만듭니다.

그러다보면 슬슬 딴청을 피게되고

요리조리 안할생각만 하게 됩니다.

그들보다 몸을 낮추십시오.

아무리 좋은 기획과 대안을 가지고 있어도

디자이너와 개발자가 그것을 창조해내지 않는다면 무슨 소용이 있겠습니까?

그들에게 권유하십시오.

"우리 같이 ㅇㅇㅇ합시다."

"이 의견의 이런부분이 저는 참 마음에 드는데 ㅇㅇㅇ디자이너분 생각은 어떠세요?"

"개발자님 혹시 ㅇㅇㅇ게 더 간단하지 않을까요? 어떻게 생각하세요?"

라고 권유를 한다면

그들은 한층 기쁜 마음을 가지고 업무에 임하게 될것입니다.

2. 프로젝트는 가만히 두면 실패하게 되어 있다

이말은 무엇보다 중요합니다.

아무리 플랜이 잘 짜여져 있고 일정과 기간이 풍족하더라도

프로젝트는 가만히 놔두면 실패하게 되어 있습니다.

아무리 완벽한 기획도

실무에 들어가면 반드시 예상하지 못한 부분들이 드러납니다.

이부분을 얼마나 잘 준비하여 대처하느냐에 따라서

그 리스크는 0에 가까워질수 있습니다.

항상 움직이십시오.

아무리 잘 다듬어진 기획서라도

계속 중간 중간 검토하고

예상되는 모든 리스크에 대해서 대비하십시오.

PM은 기획자와 같이 반발씩 앞서나가면서 시작하지만

PM은 프로젝트가 끝난 후에도 가장 오랫동안 해야할일이 많습니다.

사용하는데 발생한 문제점은 없는지

잘 사용하고 있다면 어떤 부분이 가장 편한지

끊임없이 조사하고 관리해야합니다.

3. "Yes-man"이 되어선 안된다.

절대로 그들의 모든 의견에 "Yes"부터 나가면 안됩니다.

반드시 그들의 의견은 문서화하여 두번 세번 검토해야합니다.

그보다 더 나은 대안은 없는건지

이 의견에 대한 하자는 없는건지

충분히 심사숙고하여 검토한 후 결정해야합니다.

해는 동쪽에서 떠야한다고 주장을 하더라도

사람의 방향에 따라서 그들의 입장에서는 서쪽이 될수도 북쪽이 될수도 있고 동서남북을 모르는 사람일 수도 있는것입니다.

충분히 고려하고 또 고려해서

스스로가 질릴때까지 검토할 수록 좋은 대안이 나올 수 있는것입니다.

4. 클라이언트에게 개발자와 디자이너를 내세우지 마라.

자신이 잘 알지 못한다고 개발자나 디자이너를 연결한다거나

자신을 거치지 않고 그들에게 부담을 주어서는 안됩니다.

그들의 자문이 필요하다면

직접 그 내용을 받아 문서화한뒤 해당 개발자나 디자이너에게 문의하십시오.

말로 하는것과 문서로 하는것에는

그 의무감이 다릅니다.

말로하는것은 잊어버릴수도 있고 와전될수도 있으며

문서로하는것은 그 흔적이 남고

무엇보다 누구에게나 동일한 내용을 보여준다는 것입니다.

이해는 각기 다를 수 있겠지만 적어도 내용은 동일한것입니다.

개발자나 디자이너에게 있어서는

클라이언트를 대변하지만

클라이언트 앞에서는 자신이 개발자와 디자이너를 대변해야합니다.

그들의 변명도 자신의 이름으로 해야하며

클라이언트의 어이없는 요구도 스스로 막아내야합니다.

그것이 바로 Manager 인것입니다.

==========================================================================================================

우리나라 IT시장이 분명히 인프라에 비해

성숙하지 못한게 사실입니다.

욕심이 많은 한국인으로써 경쟁하기를 좋아하기 때문인것 같습니다.

서로가 서로에 대해서 충분히 알만큼의 기간이 없었던것 같습니다.

조금씩 서로 이해해가면서 발전해나갔어야 하는데

너무 빨리 성장해버린 지금 IT에 대한 환상과 허상이

저급 인프라를 양성해내는것인지도 모르겠습니다.

어떤 직업이나 직책이든지

"이해"와 "타협"만큼 좋은 해결방법은 없는것 같습니다.

이만 우.야.꼬.였습니다.

출처는 네이버 카페

좋은 글이라서 퍼왔어요...모두들 이렇게 하면 성공적인 프로젝트와 좀 더 멋진 인재가 되지 않을까요 ??

대한민국 IT 여러분들 힘내세요..

by 수야러브 | 2006/06/05 10:26 | Good Story | 트랙백 | 덧글(0)

메모의 힘... 아이디어는 바람처럼 내 곁을 떠난다.

 아이디어는 때를 가리지 않고 떠오른다. 샤워하는 도중이나 친구와 술을 마실 때 생각나기도 한다. 이런 순간적인 발상을 '나중에 정리해야지' 하고 미루다 보면 금세 잊어버린다.

회의할 때는 상대방의 의견에 고개를 끄덕이며 이해했다고 생각했는데, 막상 끝나고 나면 그 말이 전혀 기억나지 않는 경우도 많다. 아무리 가슴에 와 닿을 만큼 인상적인 이야기를 들어도 메모하지 않으면 기억나는 것은 고작 두세 가지에 불과하다.

사카토 켄지의 '메모의 기술' 중에서 (해바라기, 17p)

*             *             *

펜과 작은 수첩. 항상 몸에 지니고 다녀야할 필수품입니다. 순간적으로 떠오르는 아이디어를 적기 위해서, 사람을 만나 대화를 하다 들은 인상적인 이야기를 메모하기 위해 필요합니다.
요즘에는 PDA에 입력을 하거나 보이스 레코더, 휴대폰으로 녹음을 하는 분들도 있습니다. 저는 메모에 관한한, 이런 디지털적인 방법보다는 수첩에 적는 아날로그적인 방법이 더 효과가 좋더군요.

침대 옆에 필기도구를 놓거나 욕조 옆에 선반을 만들어 펜을 놓아두는 분들도 있습니다. 실제로 떠오르는 생각, 아이디어는 바람처럼 왔다가 사라지기 때문에 그 순간에 메모해두지 않으면 놓칠 수 밖에 없는 존재입니다.

작은 수첩을 항상 가지고 다니며 메모하는 것. 새로운 일을 기획하고, 업무 효율성을 높이기 위해 반드시 필요한 습관입니다.

by 수야러브 | 2006/05/17 12:54 | Good Story | 트랙백 | 덧글(0)

[2006년 5월 16일]비전으로 가슴을 뛰게하라 - 켄 블래차드

짧은 감상문

이혼녀와 보험회사 CEO가 매주 화요일마다 만나면서 비전을 찾아가는 Stroy 입니다.

많은 부분을 생각하게 되는 책이죠.

나의 비전이 무엇인가?

나의 목적은 ?

이 비전을 찾아서 가치, 목적, 실행, 미래의 청사진을 어떻게 그려나갈 것인지 한번쯤은 생각하게

만들어 나가는 책이다...

나는 비전이 무엇인가? 마땅히 모르겠다...

하지만 지금 현시점이 내한테는 중요한 시점이라고 생각한다. 도전과 열정으로 무엇인가 해야

새로운 미래가 열릴것 이다. 

by 수야러브 | 2006/05/16 09:02 | 트랙백 | 덧글(0)

[Allm] 2006년 5월 1일 가슴이 뛰기 시작한다.

5월 1일부터 하늘을 날기 위해 준비를 시작했다.

처음 입사해서 많은 부분이 어색했다. 회사 사람들 낯선 업무들 하지만 여기가 내가 시작할 곳이라 생각하고

빨리 적응해 나가야겠다고 마음 속으로 다짐하며 회사 분들에서 부산사투리로 처음으로 인사했다....^^

"안녕하세요 부산에서 온 박양수 입니다. 많이 부족하지만 잘 부탁드립니다." 한쪽에서 들려오는 웃음소리

나는 A 개발 웹프로그래머다.

모든 분야를 능숙하게 잘 다루고 현란한 드리블을 하는 것 처럼 코딩가 아이디를 내야 한다.

이제 3개월의 수습이 먼저 시작했다. 나의 진가를 보여주고 싶다.

비전을 갖고 열심히 전속력으로 전진 하면 살고 싶다.

비전에는 목적, 가치, 실천, 미래의 청사진을 정하고 향하면 미래의 모습은 밝을 것이다.. ^^

by 수야러브 | 2006/05/16 08:59 | Allm Story | 트랙백 | 덧글(0)

트랙백(trackback, 먼댓글), 트랙백 핑(ping)

트랙백(trackback, 먼댓글), 트랙백 핑(ping)

트랙백은 원격 댓글을 쓰고 이를 알려주는 기능입니다.

초기 블로그에는 없던 새로운 기능입니다. 트랙백은 댓글(reply, 답글), 덧글(comment, talkback 등) 기능의 확장판이라고 보면 됩니다. 기존의 답글과 덧글은 해당 게시판에 독자가 게시물을 읽고 난 뒤 답변이나 감상문을 적는 기능입니다. 따라서 덧글은 해당 게시물 밑에만 남겨집니다. 트랙백은 이보다 좀더 개선된 기능으로 다른 곳에 댓글을 남기는 기능입니다. 즉 해당 게시물에 대해 댓글이나 덧글을 달되 다른 사이트에서 원격으로 덧글을 다는 행위입니다. 이전에는 A 사이트의 '장터' 게시판 '1번' 게시물에 대해 덧글을 남길 경우 이 덧글을 보기 위해서는 A 사이트 장터 게시판 1번 게시물을 읽어봐야만 덧글을 볼 수 있습니다. 하지만 덧글을 지원하는 경우에는 A 사이트의 장터 게시판 1번 게시물에 대한 덧글을 B 사이트의 게시판에서 볼 수 있는 겁니다.

그렇다면 트랙백이라는 기능은 왜 만든 것이며 그 의미는 무엇일까요? 트랙백을 만든 이유와 그 의미는 '내가 쓴 글을 다른 사람에게 알리기 위함'입니다. 트랙백은 이를 지원하기 위한 기능이죠. 트랙백은 다른 사람이 쓴 블로그 문서에 자신이 원격 댓글을 달았다는 사실을 알려주는 행위를 말합니다.

트랙백으로 작성한 글은 작성자 블로그의 새 엔트리가 됩니다.

예를 들어 A 사이트의 블로거가 '한글날에 대하여'라는 글을 올렸을 경우 B 사이트의 블로거는 해당 글에 대한 의견을 자신의 블로그 사이트에 트랙백 형태로 올릴 수 있습니다.

[트랙백 과정]
1. A가 자신의 블로그에 '한글날'에 대한 글을 올렸다.
2. B가 A의 블로그에 올라간 글을 보고 자신의 블로그에 '한글날' 글에 대한 소감을 적어 글을 올렸다.
3. B는 A의 블로그에 트랙백 핑(TrackBack Ping)을 보내 자신의 블로그에 A가 쓴 '한글'에 대하여 코멘트를 달았음을 알려준다.
4. A는 자기가 쓴 '한글날' 게시물에 달린 트랙백을 통해 B가 B의 블로그에 '한글날'과 관련된 글을 올렸다는 사실을 알 수 있습니다.

**트랙백의 구조

핑은 작은 문장을 뜻하며 트래픽 핑은 트랙백을 알려주는 작은 문장입니다.


트랙백을 건 다음에는 트랙백 핑(TrackBack Ping)이라고 부르는 작은 메시지를 상대편에게 보내줍니다. 물론 이는 프로그램이 알아서 자동으로 보내줍니다. 트랙백을 건 사람은 원 게시물 작성자에게 트랙백 핑을 보내 자신의 사이트에 관련 코멘트를 달았다는 사실을 알리는 겁니다.



핑은 인터넷 도구 중 하나로 MS윈도에 프로그램으로 포함되어 있습니다.


핑(ping = Packet Internet Groper)이라고 하는 것은 초기 인터넷부터 사용된 도구 중 하나로 호스터 컴퓨터에 변경 요구를 보내고 응답이 오는 것을 검사해 목적지까지의 도달성을 검사할 때 사용하는 프로그램입니다. 예를 들어 인터넷 주소를 입력했을 때 접속이 잘 안되는 경우 ping 테스트를 통해 해당 호스트가 실제로 운영 중인지 알아낼 수 있습니다. 응답이 없다면 호스트 운영이 멈추었거나 해당 호스트가 존재하지 않는 겁니다. 또한 현재 운영중인 호스트일 경우에는 해당 호스트까지 자료를 송수신하는데 걸리는 시간이 측정되므로 선로 속도 측정에도 사용됩니다. 핑은 윈도에 포함된 프로그램이므로 도스창에서 ping이라고 입력하면 ping 프로그램을 사용할 수 있습니다.

핑은 별도의 도구로만 작동하는 것은 아니고 인터넷의 주요 도구에서 지정된 주소에 재대로 자료를 송수신할 수 있는지 시험하는 용도로 다양하게 활용합니다. 전자우편(Email)의 경우에도 편지를 보내기 전에 ping을 보내 해당 주소록의 전자우편 주소로 편지 배달이 가능한지 시험합니다.

블로그 프로그램에서도 트랙백을 사용할 때 핑 형태로 동작하는 트랙백 핑을 주고받음으로써 트랙백을 거는 겁니다.



트랙백은 두 블로그 사이의 연락 수단이 됩니다.


이런 트랙백 형태로 글을 올리면 기존의 댓글보다 편리한 점이 많습니다. 트랙백은 두 블로그 사이트 사이에 연락을 취하는 수단이 됩니다. 트랙백을 통해 A는 B사이트의 글에 관심이 있다는 것을 표명할 수 있고 B는 A라는 사람이 자신이 쓴 글에 대해 관심을 가지고 있다는 사실을 알 수 있습니다.

예를 들어 제로보드와 같은 기존의 게시판은 댓글, 덧글 기능이 있지만 몇 가지 한계를 가집니다.

[기존 댓글, 덧글의 단점]
1. 긴 글을 작성하기에 적합하지 않습니다.
2. 주인장의 기능 제한으로 대개는 HTML 태그 사용이 제한됩니다. 이 때문에 텍스트로만 된 글을 올려야 합니다.
3. 자신의 홈페이지에도 기록을 남기기 위해서는 해당 게시물에 덧글을 달고 자신의 홈페이지에도 기록해야 하는 이중 수고를 해야 합니다.
4. 자신이 작성한 덧글에 대한 추가 반응을 얻기가 어렵다. 덧글에 대한 덧글로 커뮤니티를 형성하기 어렵습니다.
5. 작성자의 홈페이지 방문을 유도하기가 어렵습니다.

** 기존 덧글은 해당 게시판에서만 확인할 수 있습니다.


트랙백은 자신의 블로그에 글을 새롭게 작성하는 것이므로 기존 댓글이 지닌 단점을 대부분 보완합니다. 한 두 줄의 짧은 텍스트가 아니라 사진이나 동영상이 들어간 제대로 HTML 문서로 작성할 수 있기 때문입니다. 물론 자신의 트랙백으로 쓴 엔트리(글)가 또 다시 트랙백의 대상이 되거나 링크의 대상이 됩니다. 이는 과거의 게시판에서 제공하지 못하던 기능입니다.


일단 트랙백을 '먼댓글(먼거리 댓글)'로 번역하겠습니다.

이 책에서는 트랙백이라는 용어를 많이 사용하지만 한글 용어로 바꾼다면 먼댓글이나 댓글자국이 적당하다고 봅니다. 먼거리에서 단 댓글과 이를 알려주는 기능이므로 '먼거리 댓글'의 의미로 먼댓글이라 할 수 있고, 다른 곳에서 댓글을 달았다는 자국을 남겨주는 것이므로 댓글자국이라고 써도 좋을 것 같습니다.

B라는 내 사이트에 보면 A 블로그의 '한글날' 글에 대하여 댓글을 남긴 상태이므로 원격 코멘트의 의미인 '먼댓글'의 의미를 부여할 수 있습니다. 또한 자신이 남긴 '댓글'을 가리켜야 하므로 '글'의 의미를 강조한다면 '멋댓글'이 적합한 해석입니다. 자신의 사이트에 올린 엔트리를 가리켜 '자국'이라고 말하기는 조금 곤란합니다. '글'이라고 지칭해야 적합하죠. 따라서 트랙백을 쓴 블로거 입장에서 보면 '댓글'을 쓴 것이므로 '먼댓글'을 썼다고 하는 표현이 어울립니다.
반면 A 블로그의 입장에서 보면 자신의 글에 대해 B가 댓글을 남겼다는 자국(흔적)을 남겨주는 것이므로 '댓글자국'의 의미가 더 강합니다. B가 자신의 글에 댓글자국을 남겼다고 표현하는 것이 적절합니다.

댓글 작성자의 관점에서 보는 것을 기준으로 생각한다면 '먼댓글'이라는 낱말이 더 어울린다고 생각합니다. 낱말이 생소한 관계로 일단 이 책에서는 원어인 트랙백이라는 용어로 계속 설명하겠으니 이점 양해 바랍니다.

참고로 트랙백의 한글 용어는 사이트마다 각기 다릅니다. 엮인글, 이어 말하기, 관련글, 되오름글 등등. 다양한 용어가 트랙백을 뜻하는 용어로 사용 중입니다.



트랙백은 콘텐트 수집의 수단이 될 수 있습니다.


트랙백(먼댓글)은 여러 가지 면에서 혁신적인 기능입니다. 과거의 게시판 형태는 조회수를 통해서 인기도는 알 수 있지만 그 글을 읽은 사람에 대한 정보는 얻을 수 없었습니다. 물론 댓글을 쓰면서 자신의 홈페이지 주소와 링크를 함께 올리는 방법으로 자신의 존재를 밝힐 수는 있지만 이렇게 하는 사람이 없었고 또 매번 자신의 주소를 밝히기도 어려운 일입니다. 이에 비해 트랙백은 자동으로 자신의 사이트가 링크되므로 사용하기 편리합니다.

두 가지 경우를 생각해봅시다.

영화 '취화선'에 대한 글을 올렸다고 합시다. 이 글이 좋은 글이라면 댓글이 수 십 개 이상 올라오겠지만 댓글을 쓴 사람과 연결되기는 어렵습니다. 반면 트랙백의 형태로 글을 쓴다면 다음과 같은 점이 달라집니다.

'취화선' 글에 대하여 관심 있는 블로거들의 그룹이 만들어지며 해당 블로거가 운영하는 블로그 사이트를 클릭 한 번으로 방문할 수 있습니다.

즉 '취화선' 글을 한 편 올림으로써 취화선과 관련된 그룹이 트랙백을 통해 수집되는 겁니다. 따라서 '콘텐트 수집(content aggregation)'이 매우 용이해지는 겁니다. '취화선' 글 하나를 통해 '취화선'과 관련된 블로그 사이트가 뭉치게 되고 사람들은 취화선 관련 블로그 사이트를 골고루 돌아다닐 수 있게 됩니다. 하나의 글이 해당 게시판에서 게시물 하나로 끝나지 않고 관련 블로그 사이트를 취합하는 결과를 가지는 셈입니다.



트랙백은 블로그 프로그램의 기능이자 프로토콜로 공개된 기능입니다.


트랙백은 공개 규격으로 2002년 8월에 무버블타입의 기능으로 발표되었습니다. 따라서 역사는 매우 짧은 셈입니다. 트랙백은 하나의 프로토콜이지만 블로그 프로그램인 무버블타입(Movable Type) 2.2의 한 기능으로 발표되었기 때문에 프로토콜이자 무버블타입의 기능이라는 양면성을 가지고 있습니다. 트랙백 규격은 국제규격으로 서로 다른 서비스와 프로그램 사이의 트랙백이 가능하게 호환성을 부여합니다.

트랙백의 기본적으로 공개로 운영되도록 설계되었습니다. 그 이유는 블로그 자체가 공개와 네트웍을 목표로 만든 개념이고, 트랙백 역시 특성 상 좀더 많은 블로그 사이트가 지원해야 트랙백의 가치가 빛나기 때문입니다. 이처럼 트랙백 기능은 공개로 계획되었기 때문에 다른 블로그 툴도 트랙백 기능을 쉽게 구현할 수 있습니다.

[트랙백을 지원하는 블로그 프로그램]
Movable Type
B2
Bloxsom
Blojsom
Nucleus
Radio
TrackBack Standalone Tool

트랙백은 블로그의 필수 조건이 아니지만 많은 블로그 사이트에서 트랙백을 지원하는 추세이므로 앞으로 나올 블로그 프로그램은 대부분 트랙백을 지원할 것으로 보입니다.



트랙백은 푸시 형태이므로 트랙백이 걸린 글은 수정하기 어렵습니다.


트랙백은 현재 한 가지 중요한 특징을 가지고 있습니다. A 블로거가 자신의 블로그에 글을 올렸을 경우 이 글에 대한 트랙백이 달리면 A 블로거 자신도 원문을 수정할 수 없다는 점입니다. 그 이유는 현재 국내외 블로그 툴에 적용된 트랙백이 대부분 PUSH 방식이기 때문입니다. 때문에 이미 밀어낸 글에 대해서는 글을 수정하고 싶어도 수정할 수가 없습니다. 따라서 트랙백을 지원하는 경우에는 자신이 쓴 글에 트랙백이 달리는 순간 더 이상 수정 불가능한 글이 된다는 점을 심각하게 고려해야 합니다.

우리나라의 경우 국내 최초 블로그 사용자 모임으로 알려진 WIK(한국어 웹로그 모임, wik.ne.kr)에서 블로그에 대한 트랙백을 활발하게 주고받음으로써 블로그에 대한 정보를 공유합니다. 개인 블로그 사이트는 트랙백을 적용하는 곳이 많지만 아직까지 국내 포탈 업체는 트랙백을 지원하는 곳이 드뭅니다. 업체로는 웹 솔루션 업체인 온네트에서 제공하는 블로그 서비스인 이글루스(http://www.egloos.com)에서 트랙백(TrackBack)을 처음으로 적용시켰습니다. 네이버의 블로그는 트랙백 기능을 지원하기는 하지만 한정된 공간에서만 지원합니다.

by 수야러브 | 2006/04/21 15:40 | Web Story | 트랙백(421) | 덧글(0)

<< 이전 페이지다음 페이지 >>