하늘 아래 세상 이야기.

싸이월드, 미국서 올 연말까지 철수
마이스페이스닷컴·페이스북 등 텃세 못깨고 2년만에 백기
 
- 2006년 8월 진출한 뒤, 누적 적자를 견디지 못하고 올 연말까지 싸이월드USA를 정리하기로 방침
- 싸이월드US가 운영하던 싸이월드 미국 사이트(http://us.cyworld.com/)는 국내서 번역판으로 유지만 하기로.
- 동아시아권에 역량을 집중할 것으로 보임. 지난해 6개 해외법인(미국 독일법인 포함) 모두 적자. 해외 지분법 손실액 189억원.
- 중국에서도 가입자는 600만에 이르지만, 토종 서비스에 밀려 당연히(?) 삽질 중.
- 유현오 전 SK커뮤니케이션즈 사장(SK텔레콤 전무)은 지난 7월 싸이월드USA 대표직을 내놓고 스탠퍼드 대학에서 연수 중
 
기타 참고 - 올초 발표한 싸이월드 글로벌 사업 조정(독일시장 철수 등)
http://www.newswire.co.kr/?job=news&no=320970

- 올초 싸이월드 유럽법인(Cyworld Europe GmbH)을 정리하기로 결정. SK커뮤니케이션즈 유럽법인은 2006년 7월 독일 통신업체 도이치텔레콤 계열 T-Online Venture Fund와의 합작법인으로 출범했으나 폐쇄 가닥.

다음&구글 - 위젯/가젯 개발 컨퍼런스에서 그림 그리고 받은 기념품 가방 안에는 PPT자료와
쿠션이 있엇다...^^;
쿠션 찍은건 어디갔니..ㅋㅋㅋ

당일 까지 3일간 밤을 세우고 간서그런지...

정신이 몽~~~롱~~~
그래도 웹2.0에 한발자국 더 다가설수 있는 기회였던거 같다...^^;

invalid-file

이번 버전은 JPG 파일만 출력합니다만 앞으로 TIFF와 PNG도 지원하겠습니다. 언제일지 모르겠습니다만, .... ^^;

사용 방법

너무 작고 간단한 프로그램이라 딱히 드릴 설명이 없습니다. 그러나 어떻게 생겼는지 보여 드릴 겸해서 정리해 보겠습니다.

프로그램은 zip 파일로 압축되어 있습니다. 즉, setup 파일을 실행할 필요없이 적당한 곳에 압축 파일을 풀어 사용하시면 되겠습니다. 단! 바탕화면에 풀어 사용하지 마세요. 이유는 아시죠. ^^

환경 설정

하트 모양의 아이콘을 클릭하면 간단한 설정을 위한 윈도우가 출력됩니다.

1. Interval between Anma time
   화면에 그림이 출력되는 시간 간격을 분 단위로  지정합니다.
2. Anma time duration
   그림을 몇 분 동안 출력할지를 지정합니다.
3. Image directory
   선택된 사진 디렉토리입니다. 화살표로 표시한 [...] 버튼을 이용하여 변경하실 수 있습니다.
   변경하신 후에 (6)의 [Preview] 버튼으로 사진을 미리 보실 수 있습니다.
4. Run program at startup
   윈도우가 부팅할 때마다 자동으로 실행할지를 선택합니다.
5. Timer
   사진이 출력되기까지 남은 시간을 보여 줍니다.
6. [Preview]
   사진을 순서대로 한 장씩 출력합니다.
7. [OK]
   변경된 설정 내용을 저장하고, 설정 윈도우를 감춥니다.

대단히 주의하셔야 할 내용

사용해 보니 눈 건강이나 잠시 쉬는 데에는 도움이 됩니다만, 일하다 보면 매우 짜증 날 수 있습니다. 골몰하고 있는데 갑자기 사진이 튀어나오니까 말이죠. 그래서 즐거운 사진을 이용하시기 바랍니다. 아무리 바빠도 미소가 지어지고, 열 받아도 차분해지는 가족이나 애인 또는 친구와의 추억 사진을 모아서 이용해 보세요. 그리고 잠시 몇 분만 머리를 식혀 보세요. ^^

파워블로거도 잘 모르는 블로그 운영에 아주 유용한 알짜배기 유틸리티 3선을 소개합니다.

블로그를 운영하다 보면 블로그 스킨을 수정하기도하고, 때로는 작성한 글에 걸맞는 이미지를 편집하고 관련 이미지를 갈무리(캡쳐) 해야하는 경우가 참 많습니다. 하지만 고가의 상용 프로그램을 사용하기엔 비용적인 면도 부담스럽고 그에 앞서 초보 블로거는 물론 파워 블로거라고할지라도 그래픽 또는 웹 전문가가 아니면 쉽게 사용하기 어려워 효율적인 블로그 운영이 쉽지 않습니다.

하지만 지금 소개하고 추천하는 프리웨어 블로그 유틸리티 3선을 활용하면 누구나 손쉽게 전문가 못지 않은 멋진 블로그를 꾸밀 수 있다는 생각됩니다. 물론 이미 잘 활용하고 계시는 분들도 많겠지만 실제 디자이너인 저도 블로그를 운영하면서 글을 쓰고 이미지를 편집할 때, 포토샵이나 워드프로세서 등 전문 프로그램을 쓰지 않고 이 세가지 유틸리티 만으로 모든 콘텐츠를 작성하여 블로그에 담고 있습니다.

1) 에디터 플러스, HTML, CSS, 문서편집 모두 내게 맡는다.

 

문서, 코드 편집기의 대명사 에디터 플러스(Edit Plus)

에디터 플러스 다운로드(30일 평가판)
에디터 플러스 기능소개 바로가기

상용프로그램이지만 29,700원이라는 부담없는 가격으로 판매되고 있으니 투자하셔도 아깝지는 않을 겁니다. 굳이 아깝다는 생각이 드시면 메모장이나 워드패드를  사용하셔도 무방합니다. 하지만 블로그 스킨 수정 시 Html, CSS를 다룰 때는 조금 불편할 수도 있습니다.

2) 오픈 캡쳐, 화면에 보이는 모든 장면은 내게 맡겨줘!

 

손쉽고 다양한 화면캡쳐 기능의 오픈캡쳐

일반 윈도우에서 스크롤 캡쳐가 가능하도록 다양한 캡쳐 방식을 지원하는 캡쳐 프로그램이라 이 곳을 통해 다 설명을 해드리지 못하니 아래 링크를 참고하셔서 숨겨진 기능들도 살펴 보시길 바랍니다. 오픈 캡쳐 하나면 원하는 화면은 뚝딱 잡아서 마음대로 활용할 수 있습니다.

오픈 캡쳐 다운로드 바로가기
오픈 캡쳐 활용법 바로가기

3) 포토스케이프, 포토샵 너 잠깐 비켜 줄래, 블로그 이미지 편집은 내가 최고

 

포토샵 부럽지 않는 이미지 편집 포토스케이프

포토스케이프 다운로드
포토 스케이프 활용강좌 바로가기

애써 소개한 블로그 유틸리티 3선의 자세한 사용법을 설명하지 않아도 해당 사이트를 활용법을 참고하시면 초보자도 쉽게 모든 기능을 익힐 수 있습니다.

앞으로, 블로그에 막 재미를 붙이신 초보 블로거분들과 멋진 이미지 편집, 스킨 편집 등으로 고민했던 블로거분들께 조금이나마 도움이 되었으면 하는 마음으로 1년여 넘게 여러가지 유틸리티를 사용하면서 가장 손쉽고 빠르게 쓸 수 있다고 평가한 3가지 유용한 무료 유틸리티를 소개해 보았습니다. 즐거운 블로깅 되시고 궁금한 점은 댓글로 질문 하셔도 됩니다.

출처 : http://www.designlog.org/2511611

만약 여러분의 사이트에 검색엔진을 통해 색인이 생성되지 않도록 하려는 콘텐츠가 있다면, robots.txt 파일을 사용하여 웹을 색인하는 검색엔진 로봇(이하 "검색봇")을 차단하거나 필요한 부분만을 검색엔진에 나타나게 할 수 있습니다. 검색봇은 자동으로 작동하며, 한 사이트의 하위 페이지에 접근하기 전에 먼저 특정 페이지에 대한 접근을 차단하는 robots.txt 파일이 있는지 여부를 확인합니다. 이번 기회를 통하여 여러분들에게 올바르게 robots.txt를 사용하는 방법을 제공하고자 합니다.

Googlebot이 ‘?’가 포함된 URL 즉, 도메인 이름으로 시작되거나 임의의 문자열 또는 물음표로 구성된URL 검색을 차단하려면 다음과 같이 하시면 됩니다.
User-agent: Googlebot
Disallow: /*?

robots.txt 란..

‘인터넷 검색엔진 배제표준(Robots Exclusion Protocol)’이란 보안이 필요한 내용이 검색엔진에 유출되지 못하도록 웹 페이지를 작성하는 방법을 기술한 국제기술표준이다. 모든 검색로봇이 이 표준을 따르지는 않지만 일반 웹 사이트 개발자들이 손쉽게 적용할 수 있어 이용이 확산되고 있다.

서버관리자가 웹페이지 HTML 작성시 맨 위에 검색로봇을 배제한다는 의미의
 ‘File:robots.txt’, ‘User-agent: *’, ‘Disallow: /’ 등을 적어놓으면 검색로봇의 검색 대상에서 제외된다. 일반 웹 페이지에서도 와 같은 메타태그를 입력하면 검색을 피할 수 있다.

-----------------------------------------------------------------------

[대처법]
웹 사이트 wwwroot 루트 디렉토리에  robots.txt 파일을 하나 만듭니다.

내용에

 User-agent: *
 Disallow: /

라고 하면 모든 긁어가기 검색에서 제외됩니다.

To allow all robots complete access (몽땅 긁어가기 허락)
 User-agent: *
 Disallow:

Or create an empty "/robots.txt" file. (빈파일 만들기로 해도 됨)
To exclude all robots from part of the server (일부분 긁어가기 제외)

 User-agent: *
 Disallow: /help  : /help.html 과 /help/index.html 둘 다 허용 안한다.
 Disallow: /help/  : /help/index.html 는 허용 안하나, /help.html 은 허용됨.
 Disallow: /private/

To exclude a single robot  (배드봇 검색로봇만 긁어가기 제외)

 User-agent: BadBot
 Disallow: /

다음 메인 페이지에 담긴 비밀 - UI개발팀 - 김선진

미니다음 개편 사례: 20픽셀의 미학, 그 현재와 미래 - UI개발팀 - 추홍엽

XUL을 이용한 개발 사례 - RIA기술팀 - 김대웅

한메일 Express iPhone 버전 개발 사례 - RIA기술팀 - 조영주


Session 2

JRIA Widget 구현의 핵심 - UI개발팀 - 구경택

액션스크립트3.0에 대한 개발자들의 호기심 - UI개발팀 - 박형석

RIA와 Silverlight2.0 - UI개발팀 - 박종현

AJAX 채팅 어플리케이션 구현 - UI개발팀 - 최종배

브라우저 확장 - 플랫폼의 다양화 - UI개발팀 - 유시형

Front-End 성능 향상 Tip - UI개발팀 - 유승근

일관성
코멘트도 일관성을 유지하는 것이 좋다. 보기 좋은 떡을 만들라. 누가 뭐래도 코멘트는 사람에게 보여주기 위해 작성하는 것이 아닌가!

뚜렷한 블록 코멘트
에디터에서 색이 다르고 굵게 표시되는 경우가 많지만 흑백으로 프린트해서 봐야 할 수도 있다.(특수한 경우를 생각하지 말고 일반적인 것을 생각하라!)
코멘트의 시작과 끝은 들여쓰기 등으로 다른부분과 구분을 지어야 한다.

/*
  * 좋은 예시의
  * 블록 코멘트
  * 알아보기가 쉽다.
*/

/* 나쁜 예시의
          블록 코멘트
알아보기 어렵다.
*/

1행 코멘트
코드 중간에 들어가지 않도록 해야 한다. 만약 코드 중간에 한줄을 잡는다면
코드의 들여쓰기와 맞춰 알아보기 쉽도록 해야한다.
행 끝에 따로 띄어서 코멘트를 작성하는 것도 괜찮다.
오른쪽에 코드로부터 분리하여 코멘트들을 작성하는 것인데 알아보기는 쉬우나 코드를 수정할 때 간격을 다시 맞춰야 하고 코드가 긴 행을 만나면 화면 밖으로 나가버릴 가능성도 있다.

일반적인 약속(관례)
코멘트는 코드의 위쪽에 쓰인다. 즉, 코멘트가 먼저 나오고 그에 해당하는 코드가 나온다.
코멘트가 단락의 시작으로 여겨지도록 한다.

유지보수가 저렴한 스타일을 선택
/***********************************
*******     모양은 이쁘지만    ********
*******  간격맞추기가 어렵다  ********
***********************************/
게다가 스페이스를 사용하느냐 탭을 사용하느냐에 따라 모양이 다르고 탭을 사용하는 경우 탭의 너비설정이 다르면 또 모양이 달라진다. 쓸데없는 곳에 열정을 낭비하지 말자.

방파제 코멘트
가끔 코멘트가 코드 사이에 방파제 역할을 하는 경우가 있다.
프로그래머는 중요한 코멘트를 특별하게 표시할 필요가 있는데 한 소스파일 안에 여러개의 클래스가 구현되어 있는 경우, 중요 섹션을 구분하기 위해 방파제 코멘트를 사용한다.
/***********************************
* 방파제 코멘트
* 가끔 필요할 때가 있다
***********************************/
좀 전에 함부로 사용하지 말라고 한 것과 비슷한 모양이지만 눈에 띄는 것이 중요하지 ASCII예술을 통해 이쁘게 하지 마라. (ASCII예술이란 특정한 상황에서 띄어쓰기 등으로 화면에 보이는 것을 미술적으로 표현하는 것을 말하는 듯하다.)

플래그
다른 사람의 코멘트를 읽을 때 약속된 플래그를 알아두는 것이 좋다.
// XXX      : 문제를 일으키는 코드나 재작업이 필요하다는 표시
// FIXME   : 고장 난 부분
// TODO    : 누락된 기능(나중에 돌아왔을 때 추가해야 할 기능)
TODO를 사용하기 보다는 exception을 던지는 것이 훨씬 매끄럽다. 하지만 다른 사람이 해놓은 것을 알아볼 필요는 있겠지.
하지만 플레그를 두려워 하지 마라. 코드를 마무리하기 전에 플레그를 검색해보면 된다.

파일헤더 코멘트
앞에서도 이야기 했던 내용이다. 모든 소스 파일에는 헤더 코멘트로 시작해야 한다.

불필요한 코멘트
코드를 수정할 때 코멘트를 달지마라.
어떠한 내용을 무엇때문에 어떻게 고쳤다..라고 코멘트를 다는 것은 불필요하며 지저분하다. 필요한 경우 결함 추적 시스템(fault-tracking system)을 이용해 결함을 찾고, 파일의 예전 리비전을 끄집어내어 조사할 수 있다. 이러한 불필요한 코멘트는 오히려 코드를 어지럽힌다.

코멘트 유지보수
바로 위에서 코드를 수정할 때 코멘트를 달지 말라고 했다. 그렇다면 코드를 수정할 때는 그냥 넘어가면 되는 것인가? 절대 아니다.
코드를 수정할 경우 그와 관련된 코멘트를 모두 확인하고 보수해야 한다.

코멘트를 의심하라
코드를 코멘트로 막아두는 경우가 있다. 일시적인 경우지만 때로는 오래갈 때도 있다. 이런 경우 적당한 설명을 함께 두거나 아예 코드 자체를 지워야 한다.
코멘트가 있더라도 코드의 수정과 함께 유지보수가 되지 않은 코멘트일 수 있고 작성한 사람이 잘못 작성했을 가능성도 있다. 항상 코드를 신뢰하고 코멘트는 의심해야 한다.


-----------정리-------------
* 소량의 코멘트를 작성하라
* 왜(why)에 대해 작성하라
* 코멘트보다 코드의 작성에 집중하라
* 코드와 함께 유지보수하라
& 코드의 내용을 중복하지 마라
& 자신만 알아보는 코멘트를 작성하지 마라

웹표준화와 웹접근성 강화에 대한 이슈가 커지고 있다. 오는 4월 11일(차주 금요일) '장애인 차별금지 및 권리구제를 위한 법률'이 시행되고, MS의 Internet Explorer 8은 그동안 문제가 많았던 CSS 렌더링 엔진을 자사 제품중(IE 5.5, 6, 7) 가장 완성도 있는 표준 지원 엔진으로 바꿔놓았다. 애플은 자사의 'Safari' 웹브라우저를 윈도우용으로 출시하였고, 최근에는 웹표준기술 테스트인 Acid3를 통과했다는 소식을 전했다. 오페라 역시 'Safari'와 같은 날 Acid3를 통과했고, 모바일 시장(휴대폰, PDA 등에 탑재되는 미니 브라우저 시장)에서의 강세를 이어가고 있다.

바야흐로 2008년은 웹표준의 전환점이 될 것으로 보인다. 그동안 은비까비가 들려주는 옛날 옛적 이야기쯤으로 치부하던 웹 실무자들도 조금씩 관심을 보이기 시작했고, 해야겠다는 생각을 하기 시작했다. 며칠전 사내 웹표준 세미나 이후 계획되어 있던 프로젝트가 곧바로 웹표준 개발로 전환되는 쾌거(!)를 이룬 것이다. 적어도 두시간 가까이 목말라가며 떠들었던 내 작은 수고가 헛되지만은 않았던 것일까.

그런데 바로 고민거리가 생겼다. 해야한다고 이연사 목청 높여~ 외쳤으나 정작 'How?'에 대한 해답을 확실히 주지 못한것이다. 세미나 직후 웹표준 개발로 선회한 프로젝트를 담당하신 기획자분이 내게 왔고, 어떻게 해요... 라고 물으시는데 참 미안해지더라. 지금까지는 웹표준을 위해서 웹퍼블리셔들이나 개발자들이 표준기술을 익혀왔고, 디자이너나 플래셔들에게는 접근성에 대한 이해를 구해왔었다. 하지만 사실 기획자를 통한 개발 프로세스의 적절성 논의에서부터 필요하다면 새로운 개발 프로세스가 필요하지 않을까 하는 생각을 하게 되었다.

한국소프트웨어진흥원에서 발표한  '실전 웹 표준 가이드(2005)'에 보면 마지막 챕터에 표준 개발 프로세스를 자세히 설명하고 있는데 이를 먼저 소개해보고, 김철수님의 웹 표준 개발 후기를 통한 문제점과 개선점 등을 고민해 보겠다.

실전 웹 표준 가이드의 '실전 표준 개발 프로세스'

기존 웹 개발 프로세스는 일반적으로 Waterfall 방식이라고 불리우는 선형적이고 밀어내기식의 프로세르를 따르고 있다.

쉽게 말해 '기획 → 시안 → 스토리보드 → 디자인 → 코딩 → 프로그래밍/디버깅'으로 이어지는 방식인데 전문적인 지식이 없더라도, 또는 프로젝트가 진행중인 새로운 인력이 투입이 되더라도 별도의 교육이 필요하지 않는 비교적 쉽고 단순한 방법이다. 때문에 웹개발 초기부터 도입이 쉬웠고 아직까지도 크게 변하지 않고 적용되고 있다.

이 방법의 문제는 ① 업무의 병목현상 ② 의존적 스토리보드 ③ HTML문서구조화의 어려움 ④ 개별 역활 중심의 프로세스를 통한 업무 과중을 들 수 있습니다.

1. 업무의 병목현상
   Waterfall 방식은 선행 프로세스가 지연될 경우 전체 프로세스의 지연으로 이어진다. 즉, 기획이 늦어지면 디자인과 코딩, 개발이 차례로 늦어지는 문제가 생긴다. 코딩까지 완료된 시점에서 기획이나 디자인이 변경되면 재코딩이 이루어지는 것도 병목현상에 한 몫 하게 된다. 아울러 프로세스상 뒤에 위치한 코딩이나 개발 인력의 프로젝트의 초기 참여율이 낮고, 둘 이상의 프로젝트에 참여하게 되면서 집중도를 낮춰 전체적인 생산성을 떨어뜨리는 경우가 생긴다.
2. 의존적 스토리보드
   스토리보드는 웹개발의 시작이고, 밑그림입니다. 그만큼 중요하죠. 문제는 디자이너나 개발자들이 지나치게 스토리보드에 의존적이라는 것입니다.

   “스토리보드에는 그에 대한 지시사항이 없는 걸요” - 아주 기본적인 에러확인 로직을
   스토리보드에 없다는 이유만으로 개발하지 않은 프로그래머의 반문
   “저는 스토리보드에 그려진 대로 그린 것 뿐인데요...” ? 디자인이 참신하지 못하다는
   지적을 받은 디자이너의 변명
   “어째서 스토리보드에 있는 그대로 하지 않았지?” ? 발전적 창의성을 적용한
   프로그래머/디자이너를 인정하지 않는 기획자의 질책

   위의 예는 의존적 스토리보드의 문제점을 제대로 보여주고 있죠. 이로 인해서 기획자는 스토리보드를 수백장씩 상세하게 기술해야만 하는 업무적 과중을 느끼게 됩니다. 웹디자이너에게는 스토리보드를 그대로 Photoshop에 그려내는 '오퍼레이터'와 같은 수동적인 자세를 가지는 것도 문제가 됩니다. 또한, 전체 프로세스를 한 눈에 보여주지 못한 수백장의 스토리보드는 개발자에게 별로 도움이 되지 못합니다.

3. HTML문서 구조화의 어려움
   HTML문서를 코딩하는 일은 관례적으로 웹디자이너의 역활로 지정되어 온 경우가 많습니다. 규모가 커지고, 웹디자이너의 부담을 줄이기 위해서 'HTML코더'라고 불리우는 직군이 생겼지만 상대적으로 낮은 대우와 평가를 받아왔습니다. 때문에 웹디자이너가 코딩을 하든, 웹개발자가 하든, 별도의 코더가 하든 HTML문서가 제대로 '구조화'되지 못하는 문제가 생기게 된 것입니다.
   
   
4. 개별 역활 중심의 프로세스를 통한 업무 과중
   기획자나 디자이너, 개발중 어느 한 직군(역활)을 중심으로 프로세스를 개선하거나 정리할 수 있습니다.
   기획자 중심의 프로세스는

웹 표준 가이드에서는 위와 같은 기존 프로세스의 문제점을 지적하고 '웹퍼블리셔 중심의 개선된 모델'을 제안하고 있습니다.

보기엔 상당히 복잡해 보이지만 단순히 HTML 코딩만을 위해서 'HTML 코더'를 두었던 것과 달리 웹 표준 기술에 대한 전문성을 가진 '웹퍼블리셔'라는 직군을 포함시키면서 기획자나 디자이너, 개발자가 가질 업무의 과중을 덜어냄과 동시에 전체 프로세스의 효율성을 높이고 있다고 볼 수 있습니다.

이제 여기서 실제로 위의 프로세스를 실무에 적용했던 김철수님의 후기를 살펴보겠습니다.

김철수님의 'Storyboard - 표준 스토리보드 구상기'

김철수님은 웹 2.0 에 따른 Ajax 사용등을 고려하면서 새로운 스토리보드의 필요성을 느끼셨다 합니다. 그리고 앞서 소개해 드린 '실천 웹 표준 가이드'의 '웹퍼블리셔 중심의 개발 프로세스'를 받아들여 프로젝트에 적용하는 노력을 해 주셨습니다. 특히 김철수님은 웹퍼블리셔에게 XHTML, CSS, JS와 같은 웹 표준 기술의 전문성과 더불어 프로젝트의 실무적인 조율 능력이 필요함을 지적하고 있습니다. 그리고 다음은 김철수님께서 실제로 적용한 방법이다.

방법은 이러했다. 우선 전체가 모여 프로세스 플로우를 짜기 시작했다. 이때 사실상 전반적인 기획과 분석과 설계가 같이 진행되어서 대략 2개월 정도가 걸렸다. 그 다음에는 컨텐츠 명세서를 간단히 작성하고 곧바로 퍼블리셔를 임명하여 HTML 코딩 작업에 들어갔다. 그 산출로 나온 CSS를 디자이너가 실시간으로 확인하면서 디자인 작업을 했고, 개발자는 DB 개발과 서버 프로그램 개발을 진행했다.

그리고 다음과 같은 문제점들을 나열했습니다.

첫째, 전체가 모여 프로세스 플로우를 맞추는 것이 매우 힘든 일이었다.

둘째, 컨텐츠 명세서를 작성하는 것이 쉽지 않았다.

셋째, 퍼블리셔의 작업을 충분히 해낼 사람이 없었다.

넷째, CSS를 잘 다루는 디자이너가 없었다.

아무래도 새로운 프로세스를 직군별로 설득하고 이해시키는 일이 쉽지 않았을 것이며, 새롭게 등장한 컨텐츠 명세서를 어떻게 해야하는지 기준도 없는 상태에서 진행하기란 쉽지 않았을 것이다. 그리고 웹 표준 기술을 제대로 숙지하고 적용할 수 있는 전문적인 웹퍼블리셔의 부재는 어제 오늘의 문제가 아니고, CSS 디자인과 같은 웹 표준 기술이 요구되는 작업을 디자이너가 하기에는 무리가 있었을 것이다. 이러한 문제가 있었지만 김철수님은 나름의 노하우를 익히셨고 다음과 같이 공개해 주셨다.

하나, 사이트맵 대신 모듈맵을 만든다.

둘, 모듈 단위로 HTML을 작성한다.

셋, 최종사용자의 UX를 먼저 확정한 뒤 서버 프로그램을 시작한다.

넷, 텍스트 기반으로 먼저 만들고 나중에 세세한 디자인 요소를 삽입한다.

다섯, 위키 방식으로 모두가 개발 소스에 접근하여 수정할 수 있도록 한다.

자세한 설명은 김철수님 블로그에서 직접 확인해 볼 수 있는데, 간단히 코멘트를 하자면 전체 프로세스를 모듈화 하는 것이 중요해 보인다. 과거처럼 거대한 프로젝트를 수백장의 스토리보드에 다 담아 내는 것이 아니라, 기능별로 모듈화된 페이지를 고려하고, 그에 맞는 명세서나 차트를 만들어 개발자와 디자이너에게 전달한다. 그리고 텍스트 기반(XHTML 마크업)의 프로토탑입 설계를 함께 진행하여 디자인 이후에 있을 오류를 최소회 시켜야 한다. 또한, 개발 팀원간의 소통을 위한 도구로 '위키(wiki, 누구나 접근하여 쓰고, 지우고, 수정할 수 있는 시스템)'를 제안하고 있다. 제 의견으로는 'Trac' 의 사용을 추천해 드립니다.'Trac'는 '위키'시스템과 '포럼' 형태를 모두 가지고 있고, 버전관리와 연동이 되기 때문에 프로젝트 게시판으로 사용하기 좋은것 같습니다.

개량형 '웹퍼블리셔 중심의 웹 표준 개발 프로세스'

위 표는 '실전 웹 표준 가이드'와 김철수님의 후기를 읽은 뒤에 살짝 고민을 덧붙여 변형을 가해 본 것이다. 가이드에서도 밝혔고, 나 역시 미리 밝혀두는 것이지만 이러한 웹 표준 프로세스라는 것이 아직은 정형화 되어 있지 못하고, 객관적인 장단점이 불분명한 상태이다. 따라서 프로젝트의 성공 여부를 보장해주지 못한다. 다만, 웹 표준을 준수하는 웹 개발을 할라치면 이러한 고민과 적용이 필요하지 않을까 해서 시작된 것이고, 이렇게 나의 의견까지 덧붙이게 된 것이다.

'개량형'이라고는 했지만 '실전 웹 표준 가이드'에서 소개하는 내용과 크게 다르지는 않다. 용어가 일부 변경('코딩' 보다는 '마크업'이라는 용어로, 일부는 김철수님의이 제안하신 것)되었고, 프로세스가 약간은 더 복잡해졌다고 볼 수 있다. (없던 화살표가 생겼다!) 풀어서 서술하자면 다음과 같다.

• 기획자 : 기획자는 '실전 웹 표준 가이드'에서 제안하는 것과 같이 기획문서를 '프로세스 플로우'와 '컨텐츠 상세화'로 구분하여 작성한다. 차이가 있다면 '프로세스 플로우'와 함께 게시판이나 회원가입/로그인과 같이 모듈화가 가능한 것들에 대한 모듈 명세서 또는 모듈 맵이 함께 작성된다. 그리고 이것은 개발자에게 전달되어 프로젝트 전반에 대한 설계와 프레임 개별 모듈에 대한 설계를 할 수 있도록 한다.
• 디자이너 : 디자이너는 기획/분석 단계에서 만들어진 아이디어를 통해 시안과 스타일 가이드(문서 또는 준하는 이미지 파일)를 만듭니다. 그리고 기획자의 컨텐츠 상세화 문서(기존의 스토리보드로 생각하면 쉬울것 같다)를 받아 화면 디자인을 시작한다. 여기서 완성된 스토리보드를 가지고 시안을 만들지 않는다는 것은 중요합니다. '실전 웹표준 가이드'나 김철수님이 지적했듯이 상세한 스토리보드는 디자이너의 창의력을 둘러싸는 장벽이 될 위험요소가 있습니다. 때문에 기획/분석 단계에서 나온 아이디어나 컨셉 등 필요한 만큼의 적은 정보만으로 시안을 잡아 디자이너로 하여금 충분히 창의력을 발휘할 수 있도록 해야 합니다.
• 개발자 : 개발자는 기획/분석 단계에서 나온 아이디어와 컨셉을 통해 기술적 이슈(HTML문서의 DTD, 인코딩, 폼 영역의 ID값 등)에 대한 개발 가이드를 작성하여 퍼블리셔에게 전달합니다. 그리고 기획자로부터 '프로세스 플로우'와 '모듈 맵'을 전달받아 시스템 설계와 모듈 단위의 개발 준비를 시작합니다. 이후 퍼블리셔로부터 마크업이 완료된 XHTML문서를 받아 프로그래밍과 디버깅 작업을 진행합니다.
• 퍼블리셔 : 퍼블리셔는 기획자로부터 '컨텐츠 상세화 문서' 또는 '페이지 명세서'를 받아 XHTML 마크업을 시작합니다. 이때 개발자로부터 받은 '개발 가이드'를 바탕으로 XHTML 문서의 Doctype 설정, 인코딩 설정, 공통  ID값 등을 결정하거나 적절치 않을시 재논의하여 적용하도록 합니다.(한 번 결정된 Doctype이나 인코딩은 개발 과정에 쉽게 바꾸기가 어려우므로 반드시 확실히 결정을 하고 넘어가도록 합니다.) XHTML 마크업이 완료되면 개발자에게 전달하여 프로그래밍이 진행될 수 있도록 합니다. 이후 디자이너로부터 받은 '스타일 가이드'와 '화면 디자인(PSD 파일)'을 통해 XHTML 문서에 CSS 디자인을 시작합니다. 다음으로 개발자와 소통하며 완료된 페이지를 '퍼블리싱'하면서 CSS 오류 등을 잡아내는 '디버깅' 작업을 진행합니다. 마지막으로 기획자와 함께 '표준화 준수 확인'작업을 하게 되는데 '실전 웹 표준 가이드'에서는 이를 퍼블리셔의 역활로 두었으나 제 경험상 '내가 작업한 것을 내가 테스트 하는 것은 실효성이 적다'였습니다. 다시말해 내 실수를 내가 찾아내는게 쉽지 않았다라는 겁니다. 프로세스대로 디자이너와 개발자가 표준에 맞춘 일정을 따라주었다면 최종적으로 퍼블리셔의 웹 표준 기술(XHTML, CSS, DOM, JS 등)에 의한 크로스 브라우징과 접근성 문제 등이 주요 이슈로 나타날 수 있는데 이를 퍼블리셔 스스로 검증하기란 쉽지 않습니다. 따라서 애초에 기획자에게 책임을 지우는 것이 좋다는 생각을 해봤습니다. 그리고 단계적으로는 최종 단계이긴 하나 기획자는 프로젝트가 진행되는 가운데 지속적으로 디자이너와 개발자, 퍼블리셔가 표준을 준수하고 있는지를 검증해야 합니다.
  

특별히 부연 설명을 드리고 싶은 것은 위 표에서도 나타나 있듯이 양쪽화살표로 되어 있는 굵은 선 프로세스들입니다. 퍼블리셔를 중심으로 기획자와 퍼블리셔, 디자이너와 퍼블리셔, 개발와 퍼블리셔가 지속적으로 커뮤니케이션을 이루도록 되어 있습니다. 또 한가지 기획자와 퍼블리셔가 같은 색 영역으로 묶여 있음을 보실 수 있습니다.

김철수님도 쓰셨듯이 웹 표준 개발 프로세스에서 기획자와 퍼블리셔의 협력은 굉장히 중요해 보입니다. 1차적으로 과거의 스토리보드가 세부화된 개별 문서와 XHTML 문서로 만들어집니다. 이렇게 만들어진 XHTML문서는 디자인이 입혀지기 전에 1차적으로 프로세스 테스팅을 가질 수 있다는 장점이 있습니다. 일종의 프로토타입을 만드는 것입니다. 버튼이 빠져 있거나 페이지가 잘못 연결되어 있거나 추가되는 페이지등을 사전에 고려하여 디자인 이후에 생길 수 있는 추가 작업을 줄일 수 있습니다.

디자이너가 CSS를 다루지 않는 것도 김철수님의 경우와 다릅니다. HTML이나 CSS도 모르면서 웹을 어떻게 하냐는 소리를 하곤 했지만 사실 웹디자이너에게 전문적인 수준의 XHTML과 CSS를 강요할수만은 없다고 생각합니다. (현실적으로 불가능에 가깝습니다.) 때문에 CSS 디자인 역시 퍼블리셔의 영역 안에서 해결해야 한다고 생각합니다. 실제로도 대부분의 퍼블리셔들이 시멘틱한 마크업과 CSS 작성은 자신들의 영역이라고 생각하면서 공부하고 있습니다.

아울러 개발자들이 텍스트로만 이루어진 XHTML 문서를 통한 개발에 적응할 수 있어야 한다고 봅니다. 개발 영역에서는 MVC모델이라는 것이 확실히 자리잡고 있지만 아직도 많은 경우에 XHTML문서 내에 직접 프로그래밍을 입히는 경우가 많습니다. 이 경우 XHTML문서와 서버측 스크립트 언어, CSS 등이 뒤섞여 유지보수가 매우 어려워질 수 있고, 위의 개발 프로세스도 적용하기 힘들 수 있습니다.

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

초기 블로그에는 없던 새로운 기능입니다. 트랙백은 댓글(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)을 처음으로 적용시켰습니다. 네이버의 블로그는 트랙백 기능을 지원하기는 하지만 한정된 공간에서만 지원합니다.

▶RSS는 웹사이트끼리 자료를 주고받기 위한 규격입니다.

RSS는 웹사이트의 결합(신디케이팅, 배급망 만들기)과 자료 구축, 교환을 위해 필요한 규격으로 공개 프로젝트인 아톰 프로젝트(옛날: 에코 프로젝트)와 경쟁 관계에 있습니다. 현재 아톰과 RSS 2.0이 업계 표준을 둘러싸고 선의 경쟁을 벌이고 있는 중입니다.

RSS는 뉴스, 블로그 등 자주 업데이트(갱신)되는 성격의 사이트를 위한 XML 기반의 포맷으로 자료 교환을 위한 규격입니다. 웹 사이트끼리 서로 자료를 주고받기 위한 규격이라고 보면 됩니다. RSS는 'RDF Site Summary' 또는 'Really Simple Syndication', 'Rich Site Summary' 등의 약자입니다. 해석이 다양한 이유는 다양한 규격의 RSS가 존재하기 때문입니다.


▶RSS 파일을 이용해 사이트의 각종 정보를 수집할 수 있습니다.

RSS는 XML 서비스 중에서는 가장 성공적이라는 평을 받고 있습니다. 다소 복잡한 원리에도 불구하고 웹 사이트를 통해 콘텐트 정보를 교환하는 커뮤니티 표준으로 자리잡은 상태입니다. 요즘 파이썬과 같은 언어가 새롭게 떠오르고 있는데 파이썬이 RSS에 적합한 도구이기 때문이라는 점도 한 이유가 됩니다.

RSS 규격에 따라 만든 RSS 파일은 특정 사이트의 정보를 담고 있습니다. 예를 들어 B 사이트의 운영자는 A라는 사이트의 각종 정보(갱신된 글의 제목, 링크, 주요 내용 등)를 RSS 파일을 통해 수집한 다음에 자기가 운영하는 B 사이트에 올려놓을 수 있습니다. 이렇게 하면 B 사이트 방문자는 A 사이트를 방문하지 않더라도 A 사이트의 최신 변환 내용을 쉽게 알 수 있습니다.

RSS 역시 트랙백만큼이나 활용도가 큽니다. 만약 자신이 A 뉴스 사이트를 운영한다고 합시다. 이때 과거의 방식으로는 B, C, D, E 뉴스 사이트의 기사를 퍼오는 수고를 하면서 직접 자신의 사이트에 글을 올려야 했습니다. 좀더 쉬운 방법은 B, C, D 사이트의 최신 뉴스 제목에 링크를 걸어 자신의 사이트에 링크를 올리는 것입니다. 그렇지만 뉴스 제목만 볼 수 있고, 그나마 이것마저 수동으로 작성해 링크를 걸어야 하는 불편이 있었습니다. 그렇지만 이들 사이트가 RSS를 지원한다면 A 사이트 운영자는 B, C 사이트의 RSS 파일을 읽어 자동으로 자신의 사이트에 B, C 사이트의 최신 뉴스와 링크, 요약 발췌 내용을 올려놓을 수 있습니다. 즉 손도 대지 않고 거대한 뉴스 사이트를 만들 수 있는 겁니다.

또 각종 영화 사이트의 RSS 파일을 읽어서 자신의 사이트를 국내 각 영화 사이트의 최신 소식을 전하는 종합 영화 소식 사이트로 만들 수도 있습니다. 이처럼 RSS는 콘텐트 수집이나 콘텐트 신디케이트(syndicate, 콘텐트 배급망)를 구성하기에 매우 좋은 도구입니다.


▶개인도 RSS 구독 프로그램을 이용해 RSS 기능을 사용할 수 있습니다.

RSS는 사이트끼리만 사용하는 도구가 아닙니다. 개인 사용자도 RSS 구독(reader) 프로그램을 사용해 각 사이트의 콘텐트 정보를 쉽게 구할 수 있습니다. 즉 B 사이트를 직접 방문하지 않더라도 RSS 구독기(리더기, 구독 프로그램)를 이용해 B 사이트의 최신 콘텐트가 무엇인지 자신의 PC에서 확인할 수 있습니다. RSS 리더 프로그램을 설치하고 환경을 설정하면 RSS 구독기는 자동으로 알아서 설정한 사이트를 돌아다니면서 RSS 정보를 수집해 보여줍니다. 개인 사용자는 이렇게 수집한 RSS 정보를 통해 관심이 가는 콘텐트만 골라 보면 됩니다.


▶[XML] 아이콘은 RSS를 지원한다는 뜻입니다.

블로그 사이트를 방문해보면 많은 사이트에서 블로그 사이트들을 지나다 보면 'Syndicate this site (XML)'이라고 표기하거나 주황색 계통의 [XML] 아이콘이 붙어있는 것을 볼 수 있습니다. 이것은 RSS 파일의 링크를 표시하는 것입니다. 즉 이 사이트에서는 RSS 파일을 제공한다는 뜻입니다.
이들 사이트에서 제공하는 RSS 파일은 보통 index.xml, index.rdf, rss.xml 등의 이름을 가지고 있습니다.

요즘은 하트 모양의 아이콘을 함께 붙이는 경우가 많습니다. 얼핏 보면 무슨 알약(어린이용 영양제 같은) 아이콘 모양인데, RSS를 지원한다는 아이콘입니다. 알약 색이 조금씩 다르고 어떤 알약에는 'RSS' 'Love RSS' 'I Love RSS'등의 글씨가 있습니다. 아이콘을 두 개 이상 붙여놓은 경우에는 규격에 따른 지원을 표시하는 경우입니다. 예를 들어 RSS 1.0 규격 지원 아이콘에는 index.rdf 파일이 링크되어 있고, RSS 2.0 규격 지원 아이콘을 누르면 index.xml 파일이 링크되어 있는 경우가 보통입니다.

▶RSS 공급을 피드(feed)라고 부릅니다.

한 사이트에서 다른 사이트의 주요 글들을 RSS를 통해 공급하는 것을 RSS feed(공급) 서비스라고 합니다. 그리고 이렇게 RSS 기사를 공급(feed)해주도록 도와주는 프로그램을 RSS feed 프로그램이라고 부릅니다.

◇ YES24는?

회 사 명 : 예스이십사 주식회사
공 동 대 표 : 김동녕 / 정상우
설 립 일 : 1999. 4. 1 (전신 WebFox :1998. 6 - 대한민국 최초의 인터넷서점)
자 본 금 : 69억
총 자 산 : 403억원 (2006년 12월 기준)
매 출 액 : 2,038억원 (2006년 거래매출 기준)
임 직 원 수 : 161명 (2006년 12월 기준)
본 사 주 소 : 서울시 영등포구 여의도동 15번지 한섬빌딩 9층

대한민국 대표 인터넷서점 YES24는 1998년 국내 최초의 인터넷서점으로 서비스를 시작하였습니다. 인터넷 서점은 기존 오프라인 서점과 달리 시간과 공간의 제약 없이 고객님들이 원하시는 언제, 어디서라도 편리한 쇼핑이 가능합니다. 이처럼 YES24의 브랜드 네임은 고객님이 원하시는 상품정보를 관리하고 정확하게 검색하며, 쇼핑할 수 있는 즐겁고 행복한 쇼핑공간으로서 고객 지향적 쇼핑몰이 되고자 하고 있습니다.

YES24는 국내 외 도서를 주 판매하고 있으며 e-러닝, 음반, DVD/비디오, 영화, 공연, GIFT, 화장품등의 사업영역을 보유하고 있습니다. 단순 온라인 서점의 이미지에서 확장하여 이제는 어엿한 쇼핑몰수준까지 확장하여 다른 온라인 서점과 차별화를 두고 있습니다. 특히 포인트를 영화 예매에 사용할 수 있으며 e-러닝 부분에서는 기존의 메가 스터디,

이투스, EBS의 인지도는 따라가지 못하나 공무원 시험 대비와 토익, 텝스, 토플, 각종 자격증, IT/인터넷 자격증 코너 등 차별화를 두어 인기를 얻고 있습니다.

-YES24의3B

Best Place To Shop (For Customer)
Best Place To Work (For Employee)
Best Place To Invest (For Investor)

◇ YES24 의 실적

-타 인터넷 서점에 비해 일평균 방문자수, 페이지뷰에서 2배 이상의 차이를 보임.

서점 분야 점유율에서 48% 차지

1. <도서 쇼핑몰 순위 집계표>

2. 주요도서 쇼핑몰 일평균 방문자 그래표

◇ 차별화된 “YES24” - 혜택 및 특권.

1. 모바일 서점

<YES24 모바일서점 접속 안내>

-모바일서점은 SKT의 무선인터넷을 이용하는 서비스로, 사용하신 만큼 무선통화요금이 발 생.
-데이터 정액 요금제를 사용하면, 정해진 월정 납부액만으로 이용 가능.
-YES24 모바일서점 상품구매 안내

모바일서점에서는 신용카드, 휴대폰결제, 모네타, YES머니 등 다양한 결제가 가능합니다.
휴대폰 결제는 월 5만원까지 가능하며, 휴대폰 요금 고지서에 통합 청구.

도서 매장에서 음반, DVD 매장으로 이동하시면, 음반, DVD 상품도 구매 가능. 모바일 YES24는 SKT-쇼핑몰로 결제승인이 나며, SKT에서 발행하는 할인쿠폰 혜택 가능.

-YES24의 제휴할인서비스(각종 카드할인, OK캐쉬백 등)는 적용 불가.
-모바일서점 주문은 부분출고 되지 않으며, 모든 상품이 일괄로 전체 배송.

2. YES 환전소

선물로 받으신 상품권이나 외부 포인트를 YES 상품권(YES머니)로 환전 하고 자유롭게 사용 가능 (도서, 음반, DVD, 영화, GIFT, 화장품 등을 할인 혜택은 그대로 , 편리하게 결제가능)

3. 최저가격보상재

최고의 도서정보, 최대의도서보유량, 신속한 배송, 고객만족 서비스 최저가격을 보상해 주는 First Class 인터넷서점 YES24

① 비교 대상 인터넷 서점 : 교보문고, 리브로, 알라딘, 영풍문고, 인터파크 (가 나 다 순) - 매 4분기 단위 인터넷서점 매출액 순위(오프라인 기반 2개사, 온라인 기반 3개사) 기준 으로 대상 서점을 재선정.

② 비교 대상 도서종류 : 전집류를 제외한 모든 국내도서

- 대상 도서의 상세 정보 및 검색 결과 화면 등에 있는 "최저가격 보상 대상 도서" 문구 확인

③ 비교 방법

- YES24와 회원님께서 지정하신 비교 대상 서점 한 곳의 동일한 주문에 대한 건당 비교
- 해당도서가 비교 대상 서점에 없을 경우 비교에서 제외되며, 기 보상접수 처리 건에 대 해서는 재신청 불가
- 보상신청 후 24시간 이내(휴일은 48시간 이내)에 담당자가 접수한 시점의 타 서점 판매 가격을 기준으로 가격 비교

④ 보상신고 기간 : 해당 주문의 상품 출고 완료 후 12일이 지나기 전까지 신고 가능

⑤ 보상방법 : 담당자 접수 후 보상결정이 내려진 주문에 대해 그 주 금요일에 YES머니로 지급

4. 편의점 픽업 [24시간 픽업]

- 편의점 Pick-up 서비스는 주문하신 상품을 원하는 편리한 시간에 지정하신 편의점에서 직접 수령하실 수 있는 서비스.

- 가까운 GS25, 훼미리마트, 바이더웨이 등 3개 편의점을 통해 서울, 경기 등 수도권 및 전국 6,800 여개의 매장에서 이용 가능.

- 업체에서 직접 배송하는 상품은 편의점 Pick-up 서비스를 이용 불가능.

5. YES마니아

6. YES 블로그

-새로워진 YES블로그, 책에 대한 여러 가지 글쓰기 가능.

리뷰도, 메모도, 감상도 YES 블로그에 기록가능.

7. 배송일 안내

- 당일, 하루, 이틀 등 고객에게 배송되는 날짜를 실시간 인터넷 창에서 바로 확인이 가능. 이는 개별 제품에 따라 서로 다르게 측정이 되며 대부분의 제품이 하루이상이 걸리지 않음. 타 인터넷 쇼핑몰의 불특정한 배송일에 비교되는 YES24만의 특징이라 할 수 있음.

8. 국내 최대 도서 보유

- 약 260만 종의 국내 및 국외 도서를 보유하고 있으며 오프라인 서점에서 이용 불가능한 40만 건 이상의 독자서평 및 각종 미리보기 서비스를 제공.

9. 최고의 물류 시스템

- 20,000~35,000건 이상의 일일 처리 능력을 지닌 국내최대 3,100평 규모의 물류센터를 보유하고 있으며 실시간 배송정보를 확인 가능.

title; More on CardSpace and XRI
link; http://xditao.blogspot.com/2007/03/more-on-cardspace-and-xri.html

XRI/XDI는 현재의 URI 기반 주소 체계 위에 추상화된 계층을 구축하려는 기술입니다. 가령 제 블로그 주소를 =ayo/+blog 로 표시하고, 메일 주소를 =ayo/+email 로 표시하는 것이죠. 나를 가리키는 식별자인 =ayo 만 기억하면 쉽게 모든 정보에 접근할 수 있는 서비스를 제공할 수 있습니다. 프라이버시와 보안을 고려하여 Link Contract라는 접근/공유 제어 기술 또한 포함되어 있습니다.

XRI/XDI를 CardSpace와 연계하여 사용한다면 어떨까요? Andy Dale은 CardSpace와 XRI/XDI로 연계로 인해 얻을 수 있는 3가지 이점을 소개합니다.

1. Portability

CardSpace은 한 컴퓨터에서만 사용할 수 있습니다. CardSpace가 아무리 다양한 인증 기술을 커버하고 많은 사이트에 도입되더라도, 언제 어디서나 사용할 수 없다면 큰 문제가 됩니다.
Higgins 프로젝트의 HBX Card Selector는 이 문제를 깔끔하게 해결해줍니다. 로컬 PC에 Card를 저장하는 것이 아니라 신뢰할 수 있는 사이트에 저장합니다. 사용자는 처음에(boostrap) 사이트 로그인을 하고, 사용자의 로그인을 요구하는 다른 사이트에는 i-name을 입력하고 Card를 선택하여 인증절차를 통과하는 시나리오가 가능합니다.

2. i-Name authentication

XDI는 데이터 교환에 관한 기술을 정의합니다. 그 데이터의 한 종류로 Assertion을 사용한다면 i-Name 인증이 가능합니다. Andy Dale은 EZI Broker라는 사이트를 활용하여 Managed Card를 생성하고, 사용자의 XRDS에 해당 내용을 추가하는 방법을 제안합니다. 사이트가 i-name을 resolution할 때, XRDS의 내용을 이용하여 Assertion의 발급 요청을 할 수 있습니다.

3. Pointers as Data

CardSpace는 사이트가 요청하는 데이터를 Managed Card로 직접 제공하거나 다른 사이트에 있는 데이터를 가져와서 제공하게 됩니다. 즉, 실제로 데이터를 전송합니다. 하지만 XRI/XDI는 데이터의 위치(Pointer)를 전달할 수 있습니다. Pointer는 C 언어의 포인터와 마찬가지입니다. 데이터가 아닌, 데이터가 저장된 위치 정보를 전달하는 것입니다. 위치 정보를 이용하여 실제 데이터를 해석(dereferencing)하는 작업이 필요한데, 이 때에 여러가지 보안 요소가 적용될 수 있습니다. XDI의 Link Contract가 사용되겠죠.

Portability와 i-Name Authentication은 확실히 좋을 것 같습니다. 3번은 약간 애매하네요. 직접 데이터를 전송하는 것보다 위치 정보를 전송하는 것이 더 좋은 경우가 무엇이 있을까요? Link Contract를 맺어, 한 번 위치 정보를 제공하면 RSS 처럼 정보가 수정될 때마다 PULL/PUSH 방식으로 제공하는 것이 그럴듯 합니다. 다른 이점은 무엇이 있을지 생각해봐야겠네요.

일단 위키백과에서 가져온 정의.

오픈아이디(OpenID)는 웹에서 자신의 계정을 통합적으로 관리하는 방식으로, 흔히 쓰이는 중앙집중식 로그인에 비해 비교적 느슨한 방식으로 사용자를 인증한다. 즉 각각의 사이트에서 아이디와 비밀번호를 관리하는 대신, 오픈아이디를 지원하는 사이트에서는 사용자 인증을 독립된 각 서비스 제공자에게 맡기고, 그러면 개별 오픈아이디 제공자가 사용자를 인증해준다.

OpenID 커뮤니티에서 가져온 보다 쉬운 정의.

여러 업체의 서비스들을 매번 가입하지 않고 모두 사용할 수 있는 하나의 아이디 입니다.
OpenID 에서 ID 는 인터넷 주소 (URL) 로 표현되며, 인증 서비스를 통해서 사용자가 ID 의 소유자 임을 인증합니다.

즉 하나의 아이디로 여러 사이트를 이용할 수 있다는 말이다. 여기서 아이디의 형태는 기존에 알고있는 영문+숫자의 조합이 아니라 url 형태이거나 최근에는 XRI형태라고 하는데 후자의 경우는 디지털주소 형태라는데 구체적인 내용은 영어 해석에 능한 분이라면 위키백과 영문판에서 확인하시라.

그렇다면 왜 오픈아이디가 각광받는지 그 장점을 알아보자.

1. 하나의 아이디로 여러 사이트에 이용가능하므로 매번 사이트에 가입해야하는 번거로움을 해소할 수 있다.

2. 공용아이디니까 사이트마다 여러 아이디를 사용함으로써 오는 혼란도 어느 정도 막을 수 있다.

> 자주 사용하지 않는 사이트인데도 정보를 보기 위하여 가입하게 되는 경우가 있다. 괜히 찜찜한 기분을 가실 수 없고, 게다가 매번 개인정보 입력하는 것도 상당히 귀찮다. 어쩌다 내가 사용하는 아이디가 이미 사용중이라고 뜨면 정말 낭패 -_-; 그래서 생각해낸 새로운 아이디는 훗날 다시 그 서비스에 로그인할 때 기억이 나지 않는 경우를 만들기도 한다. 실제로 나는 야후에 아이디가 있는데 야후를 하도 안써서 기억도 안난다.

3. url 형태이므로 본인의 블로그나 미니홈피를 주소를 ID로 사용함으로써 기억하기 쉬우며  홍보효과 비슷한 것을 누릴 수 있다.

> 오픈아이디는 만약 내가 myid.net에서 인증을 받아 사용한다고 했다면, ABCD.myid.net 이라는 형태로 사용하게 된다. 뭐야 이건? 더 길고 어렵잖아! 라고 할 수도 있다. 하지만 이걸 내 블로그 주소로 사용할 수 있다면? 현재 서비스를 제공중인 곳은 이글루스, 태터툴즈, 티스토리, 그 밖에 설치형 블로그다. (자세한건 여기서 확인) 만약 네이버에서도 오픈아이디를 적용한다면 blog.naver.com/ABCD 이게 내 아이디가 되는 거다. 어디에서 비로그인 상태로 댓글을 남길 때 이름/ 비번/ 내용을 입력하는데 여기서 이름/비번 대신 내 블로그 주소를 남기는 것! 그러면 내 댓글을 보고 누군가 반박이나 동의를 하고 싶다면 그 블로그 주소를 누르고 들어와서 커뮤니케이션 할 수 있는거다. 미니홈피나 블로그는 요즘 거의 하나씩은 있으니까 확실히 편하겠지?

4. 암호 변경의 문제도 훨씬 간편하며 어려운 암호로 설정해도 하나로 통일되므로 보안면에서 유리하다.

-> 여러 사이트에 가입하는 것은 그만큼 아이디 노출이 많이 된다는 거다. 대부분 어느 사이트에 가입하든 비슷한 아이디를 사용하니까- 그렇게 노출이 많이될수록 스팸의 공격을 받을 확률도 높아진다. 게다가 이번에 옥션에서 개인정보유출 해킹사건 이후 모든 사이트마다 비밀번호 변경하라고 난리인데, 이미 손에 익은걸 일일이 바꾸기란 정말 귀찮아 죽을 노릇이다. 오픈아이디는 하나만 바꾸면 전부 쓸 수 있으니 얼마나 편한가! 원래 개인정보보호를 위해서 암호는 3달에 한 번은 바꾸라고 하는데 난 벌써 몇년째 같은걸 쓰는지;;;

오픈ID 어떻게 사용하면 되지?

현재 오픈ID 인증 서비스를 제공하는 업체(Open ID Provider)는 3군데다.

다음의 오픈ID(아직은 베타서비스), 안철수연구소의 IDtail, 오픈마루의 myId.net.

이 중에서 마음에 드는 한 곳을 골라 인증절차를 거치면 된다. 나는 마이아이디에서 가장 먼저 접했기 때문에 마이아이디를 기준으로 설명하겠다.

1. 마이아이디에서 myID 발급받기를 통해 간단한 인증을 거치면 오픈아이디를 얻게 된다.

2. 댓글이나 정보를 보고 싶은 사이트에서 로그인을 하라고 떴는데 그 창이 아래와 같은 오픈ID 적용 사이트라면 내 ID를 적는다.

3. 그러면 내가 인증받은 업체의 사이트로 연결되며, 거기서 비밀번호를 입력하고 로그인한다.

4. 로그인을 한 뒤엔 내가 처음에 로그인하고자 했던 사이트의 url이 보여지고 이는 기록으로 남는다.

5. 이 과정을 거치면 처음 이용하려던 사이트에서 간단한 약관체크 후 사이트를 이용할 수 있다.

그렇다면 지금 국내에서 오픈아이디를 지원하는 사이트(consumer)는 어디어디가 있을까?

스프링노트, 미플레이, 이글루스, 제로보드, 위자드 닷컴, 라이프팟 등 국내 사이트와 해외사이트가 있다. 국내 사이트는 지금 확인가능 한 곳이 약 30-40군데 인듯 싶은데, 웹 2.0 신생서비스들로 혁신적인 서비스를 좋아하는 사이트에서 이를 허용하고 있다. 앞으로 점차 늘어날 것으로 보인다. (1. 로고형으로 확인하기!  / 2. 좀더 다양하지만 텍스트로 확인하기!)

하지만 과연 좋은 점만 있을까?

1. 하나의 사이트에서 개인정보를 통합관리하는 것은 그만큼 위험부담도 따른다.

인증사이트가 해킹을 당한다면? 그 서비스를 통해 로그인할 수 있었던 모든 사이트로 그 피해가 번질 것이다. 위의 장점 4와 상반되는 내용이지만, 결과적으로 중요한 것은 인증 제공업체의 철저한 보안이겠다.

2. 위에서 잠깐 언급했던 사항인데, 기억해야할 아이디가 더 길어졌다는 점은 제법 치명적이다.

사람들은 복잡하고 어려운 걸 싫어한다. 사실 꽤나 웹에 관심있다는 나도 오픈아이디가 번거로워 거의 사용하지 않고 있다. (사실은 아직 내가 자주 가는 사이트 중엔 오픈아이디를 허용한 곳이 별로 없다 -_-; 게다가 오픈아이디 아니라 이미 가입한 아이디로도 사용이 가능하니까 필요를 못느꼈다;) 그런 나도 이모양인데, 대부분의 인터넷 이용자들은 어떻겠냔 말이다. 실제로 글을 보다보면 아이디가 길어서 불편하다는 의견이 많았다.

3. PC방 등에서 철저한 개인정보 보호가 필요하다.

한 번 인증을 거치고 나면 오픈아이디를 허용하는 다른 사이트를 이용할 때는 별도의 비번 입력(인증과정)을 거치지 않는다. 이것은 물론 편리하기는 하지만 만약 PC방 등 공용 컴퓨터에서 오픈아이디를 사용한 뒤, 하나의 사이트만 창을 닫고 나왔다면 다른 사이트는 아직 인증된 상태이므로 내 아이디가 도용될 수 있다. 따라서 공용 컴퓨터에서는 모든 사이트를 로그아웃하고, 브라우저를 다 끄는 등 각별한 주의가 요구된다. 하지만 사실 이건 다른 포털 등에서도 마찬가지로 적용되는 부분이긴 하다. 조금 더 주의가 요구되지만.

4. 오픈아이디는 위의 사용방법에서 보았듯이 내가 정보를 이용하려는 사이트 내에서 모든 것이 이루어지는게 아니라, 인증업체의 페이지 내에서 로그인 과정을 거치고 다시 사이트로 돌아와야 한다. 이 과정은 다소 번거롭게 느껴질 수도 있다. 역시 사람들은 편한 걸 좋아하니 말이다.

오픈 ID 앞으로는?

오픈아이디는 개방형서비스라는 점에서 웹2.0의 대표서비스라 할 수 있다. 오픈아이디는 지난 2005년 미국의 개발자인 브래드 피츠패트릭이 제안한 기술로써 이미 해외에서는 9천개 정도 되는 사이트가 허용했다고 하지만, 국내는 미미한 수준이다. 야후와 구글이 오픈아이디를 허용한다고 했고 MS도 그러한 움직임이 있다니 국내 포털들에도 빠른 시일 내 반응이 오지 않을까? =) (실지 국내 포털에서 이를 기대하기는 좀 어려울 듯 싶다 T-T 우리나라 포털들은 제법 폐쇄적이란 말이야;)

지금 프로바이더인 3업체는 IT에서는 나름 탄탄한 기업들이니 도중에 서비스가 중단되면 어쩌지? 라거나 보안에 대해서 걱정하는 것은 조금 덜어놓아도 될 것 같다. 하지만 나날이 보안이 중요해지는 시점이니만큼 철저한 관리가 중요할 것이다.

또, 세계적인 트렌드가 되어가는 서비스임에도 불구하고 국내에는 consumer가 많지 않아서 허울뿐인 서비스가 되지 않도록 좀 더 많은 업체에서 마음을 열고 이를 허용해야 할 것이다. 개인적으로 굵직한 포털들에서 (특히 블로그랑 미니홈피 쓰고 있는 네이버랑 SK컴즈!!)

최근에 다음하고 AhnLab, 오피니티, 더블트랙, 오픈마루 스튜디오에서 합동으로 대대적인 이벤트를 진행하기는 했지만 아직까지 사람들은 오픈아이디에 대해 모르고 있다. 나도 이번 기회가 아니었다면 그냥 통합 로그인 시스템 정도로 밖에 생각하지 못했을 테니까.. 좀 더 홍보를 겸하면 좋겠다 =) 일단 알아야 뭘 쓰지 않겠어?

아직 미흡하긴 하지만, 오픈아이디는 앞으로가 기대되는 서비스니만큼, 모두가 공유하는 서비스가 되었으면 좋겠다. =)

그 밖에 참고하면 좋은 것

국내 OpenID 커뮤니티 : 오픈아이디에 대한 개괄적 설명과 여러가지 정보 제공
OpenID FAQ in korea : 오픈아이디 이해를 돕기 위한 FAQ
[알아봅시다] 오픈아이디 디지털타임스 IT/과학 | 2008.01.22 : 가장 기본적인 내용이 잘 정리된 기사

노출

1.노출이란

2.셔터스피드

3.조리개

4.셔터와 조리개의 조합

5.적정 노출의 결정

세계의 Top 10 뉴미디어 디자인 회사가 공개하는 “잘.나.가.는.”

                                                                      사이트 만들기 비법 100가지

디 지털 디자이너의 부차적인 취미 정도에 불과했던 웹 디자인은 지난 3-4년에 걸쳐 디자인 산업의 핵심으로 부각되었다. 사실 웹 디자인은 이제 고유의 구조와 제작 과정, 윤리 기준을 가진 하나의 산업이 되었다고도 할 수 있다. 단순한 판촉 도구가 아니라 비즈니스의 핵심으로, 단순한 브랜딩 전략의 한 부분이 아니라 비즈니스의 생존에 결정적인 역할을 하고 있는 존재이다. 그런데 온라인 산업은 현재의 경제적인 동향 속에서 압박감을 느끼고 있다. 많은 웹 콘텐츠 제작자들이 일자리를 잃었고 디자이너들 역시 마찬가지로 불안한 실정이다.

경쟁력을 지니면서 동시에 고객의 경쟁력도 높여주려면 최대한으로 효율적인 사이트가 되도록 디자인해야만 한다. <컴퓨터아트>는 최고의 뉴미디어 디자인 대행사에서 내놓은 100가지의 웹 디자인 팁을 모아 이번 호 특집 기사로 실었다. 이 팁들은 레이아웃, 그래픽, 정보 디자인, 내비게이션, 애니메이션, 흡인력 있는 콘텐츠, 음악과 사운드 효과, 스트리밍 미디어, 3D화 하기, 그리고 난해한 백엔드(back-end: 사용자에게 직접 보여지는 화면 이외의 기술적인 부분)의 열 개 분야로 나뉘어져 있다. 이 주제들 중 자신 있는 한 분야에 대해 각각의 에이전시가 열 가지의 팁을 제공했다. 이 팁들은 모두 어떤 한 소프트웨어에 국한되지 않는 것들이며, 사이트 구축의 전반에 적용될 수 있는 디자인과 제작 과정에 관한 것들이다. 현재의 상황에 적용할 수도 있고, 미래를 위한 참고 자료로 남겨두어도 좋을 것이다. 고객이 언제 스트리밍 미디어나 까다로운 백엔드를 요구할런지는 아무도 모르는 일이지만 팁은 여기에 모두 들어있다.

---------------------
레이아웃
---------------------

단 도직입적으로 말해 레이아웃은 웹사이트 디자인의 핵심이다. 레이아웃은 사용자의 지각 대상으로서 웹사이트의 외관과 느낌을 결정하기 때문이다. 하지만 사이트의 레이아웃을 정한다는 것은 스케치를 하거나 제작 도구에서 버튼이나 그래픽 등을 끌어다놓는 것 정도로 끝나는 일이 아니다. 레이아웃은 기획과 팀워크, 창의력을 필요로 하는 창조적인 작업 과정인 것이다. 뉴 미디어 대행사인 레이저피시의 런던 지사에 근무하는 수석 디자이너 리차드 월렛(Richard Wallett)이 효율적인 사이트 레이아웃을 위해 다음 열 가지 팁을 내놓았다.

1. 요점을 명확히 정리한 간단한 문서를 만든다. 자신이 이해할 수 있고, 팀 전체와 고객에게 조리 있게 설명할 수 있는 것이어야 한다. 모든 결과물과 그 책임 소재를 분명히 정리한다. 이 문서는 프로젝트 전반에 걸친 안내서가 되며, 이를 토대로 프로젝트의 체크리스트를 만들게 된다. 고객의 요구사항이 변경될 경우를 대비하는 것이 될 수도 있다.

2. 제작 일정. 마감에 맞추어 일을 진행하고, 제작 기간을 고려하여 일정을 정하며, 일정을 지킨다. 모든 팀원들에게 각자 책임지고 있는 부분을 숙지시키고, 쉬운 용어들을 사용한다('계층적 결과물들을 구조화하다'가 무슨 뜻인지 도대체 누가 알 것인가?). 콘텐츠가 어디서 나오는지 확인한다. 팀원들에게 일을 분배하고 기한을 정한다. 좀 혹독하게 들릴 수도 있겠지만, 일이 매끄럽게 진행되기 위해서는 이런 것들이 꼭 필요하다.

3. 프로젝트의 영감을 얻으려면 잠시 일을 멈추고 자신이 무엇을 전달하려고 하는지에 관해 초점을 맞춘다. 어떤 단계에서든 모든 요소들을 고려하고 그것들을 순서에 맞게 준비한다. 고객들은 총체적인 솔루션을 제공받는다는 느낌을 좋아한다.

4. 총 문자 수를 정하고, 특정 플랫폼에서의 최적의 화면 사이즈를 기반으로 망을 만든다. 그리고 테스트해 본다. JPEG 파일의 한계를 고려하고 다시 테스트한다. 웹 페이지의 넓이를 염두에 둔다. 드림위버나 고라이브를 사용해 기본형을 만든다. 기본형을 작성하면 콘텐츠가 어떻게 이동하는지 감을 잡을 수 있다. 플래시나 퀵타임 등등의 다른 미디어를 넣을 작정이라면 가로 세로 비율을 고려한다(팁 6번을 볼 것).

5. 일러스트레이션이나 사진에 투자한다. 이 요소들은 감성을 자극한다. 정해진 레이아웃 안에서 다양하게 실험해 본다. 좋은 이미지는 그 안에 스토리를 가지고 있다. '나는(사용자는) 이것을 어떻게 받아들이는가?', 그리고 '시공간의 느낌이 들어있는가?'라는 질문을 스스로 해본다. 뭔가 신선한 것을 시도해 본다. 지나치게 화려한 모음집 이미지(stock images: 한 장, 혹은 여러 장의 CD에 연관된 이미지들을 모아놓은 것으로, 한번 구매하면 반복해서 사용할 수 있다)의 사용은 자제하도록 한다

6. 템플리트를 만들면 시간도 절약될 뿐더러, 컨텐츠가 늦어지더라도 큰 문제가 생기지 않는다. 고객이 제공할 원고나 필요 자료 등이 늦어지게 되면 프로젝트 일정이 묶여버린다. 이럴 경우를 각 포맷들과 그 비율들을(예를 들면 퀵타임 무비에는 16:9/4:3의 비율) 알아두어 대비한다. 가로 세로 비율은 망을 작성하는 출발점이 되기도 한다(팁 4번을 볼 것). 레이어의 사용도 좋은 대비책임을 염두에 둔다.

7. 컬러 팔레트. 216 컬러에만 집착하지 말 것. 한 색은 투명하고 다른 한 색은 불투명하게 사용해보자. 이것은 하프톤 스크린(halftone screens: 신문 등의 인쇄에 쓰이는 망점. 두 가지 색을 작은 점들로 인쇄해서 중간 색으로 보이게 한다)과 유사한 기능을 해서 반투명한 느낌을 줄 수 있다. 투명도와 질감, 형태 등을 이용해 계층적으로 영역 구분을 할 수 있다. 사용자가 웹페이지를 인쇄해야 할 경우를 고려해서 겹쳐진 부분이 회색이 되지 않도록 한다.

8. 대화성(interactivity). 사용자의 입장이 되어서, 어떻게 정보를 찾아가게 될지를 생각해 본다. 세 가지의 내비게이션 시스템을 고려해보고, 기본형을 만들어 효율성을 체크한다. 고객이나 제작 팀 모두가 이 문제에 집중해야 하며, 내비게이션 구조를 정확히 보여주는 것이 매우 중요하다.

9. 지금까지는 모두 너무 논리적인 이야기들이었다. 이제 여기에 진짜 한가지를 더해야 한다. 바로 당신이 '최고'가 되기 위해 필요한 것이다. 당신을 당신의 경쟁자들과 차별화시키는 요소 말이다.

10. 확장성. 솔루션은 여기서 끝나서는 안된다. 고객에게 제공하는 솔루션을 항상 전체적인 하나의 패키지로 생각해야 한다. 인쇄물, 오디오, 스트리밍 미디어, 방송, 광고 등등에 이르기까지... 그것이 고객이 당신을 다시 찾게 되는 이유이기도 하다.

---------------------
그래픽
---------------------
웹 그래픽은 일종의 아이러니다. 쓸만한 사이트를 방문한 사용자라면 훌륭한 그래픽과 매혹적인 환경을 원하겠지만, 한 페이지에 많은 그래픽을 넣을 수록 다운로드 시간은 길어지고, 그렇게 되면 사용자는 참지 못하고 다른 사이트를 찾아가게 된다. 훌륭한 웹 디자인이란 그래픽을 적절하게 사용하면서도 그것에서 최대한의 효과를 끌어내는 것이다. 허브의 디자이너들이 제안하는 그래픽/이미지 압축에 관한 열 가지 지침을 소개한다.

1. 이 포맷이 적당한 포맷일까? JPEG 포맷은 사진이나 다양한 컬러나 톤의 이미지에 적당하다. 수백만의 색을 지원하며 GIF 포맷보다 훨씬 다양한 단계의 압축을 지원하고, 화질을 유지하면서도 빨리 다운로드된다.
GIF 포맷은 넓은 면이 한가지 색, 혹은 제한된 몇 가지의 색으로 이루어져 있을 경우 적합하다. GIF 포맷은 비손실 압축 알고리즘을 사용하므로, 경계선이 뚜렷하고 깨끗하게 나와야 하는 그림이나 글자의 경우 JPEG보다 효율적이다. GIF 포맷은 투명한 부분을 지정할 수 있다는 장점도 가지고 있다.

2. JPEG 포맷은 또렷한 이미지보다는 흐릿한 이미지를 잘 압축하므로, 이미지를 흐려 압축 한다. 대부분의 웹 디자인 도구에서는 단계적으로 흐리기 효과를 주는 기능이 있다. 미리보기와 파일 크기를 고려해가며 적절히 조절한다. 이렇게 하면 화질에는 큰 영향 없이 파일 사이즈를 줄일 수 있다.

3. GIF 파일 정보는 왼쪽에서 오른쪽으로 기록된다. 따라서 이 방향으로 요소들이 반복되면 좀더 많이 압축될 수 있다. 즉, 수직이나 불규칙적으로 반복되는 경우보다 수평으로 동색이나 무늬 등이 반복되는 경우에 압축률이 더욱 좋아진다는 말이다.

4. GIF 파일로 몇 가지 색이나 사용할 수 있을까? 세 가지 색 이미지를 256 컬러의 GIF로 저장한다면 파일 사이즈는 그만큼 커지게 된다. GIF 파일로 저장할 때는 이미지의 질에 지장을 주지 않는 한도 내에서 최소한의 색만을 사용하도록 바꾸는 것이 좋다. 디더링(dithering)을 줄여본다. 디더링을 줄이면 그만큼 이미지 안에서 한가지 색으로 된 면이 늘어나게 되므로 압축률도 높아지고 파일 사이즈도 줄어든다.

5. 그래픽 프로그램의 최적화 기능을 최대한 이용하도록 한다. 어도비의 이미지레디 3(포토샵 6와 함께 제공됨)에는 '차별적 옵티미제이션(Optimisation)' 기능이 있어서, 한 이미지 안에서도 부분마다 다르게 압축 수준을 지정할 수 있다. 이렇게 하면 화질은 최대로 보존하면서 파일 사이즈를 줄일 수 있게 된다.

6. PC에서는 Mac에서보다 이미지가 훨씬 어둡게 보인다. 매크로미디어의 파이어웍스는 다른 시스템에서 이미지가 어떻게 보이는지를 미리 볼 수 있다. Mac에서 이미지가 어떻게 보일지 알아보려면 View > Mac Gamma를 선택한다. Mac의 경우, PC에서 이미지가 어떻게 보이는지 보려면 View > Windows Gamma를 선택하면 된다. 양쪽 플랫폼에서 최적의 상태로 보여지도록 이미지의 레벨을 조절한다.

7. 간혹 아주 큰 이미지를 써야만 할 경우가 있다. 이럴 때는 점차적으로 보여지는 GIF이나 JPEG을 사용해 사용자가 기다리는 시간을 좀더 짧게 느껴지도록 할 수 있다. 이 포맷들은 처음에는 저해상도의 이미지로 표시되고 점차 완전한 이미지로 변하므로, 사용자가 완전히 빈 페이지만 쳐다보고 기다리는 것보다는 덜 지루해 하게 된다.

8. 큰 이미지나 이미지 맵을 사용하려면, 이미지를 작게 자르도록 한다. 전송되는 시간은 같지만 이미지 조각들이 각각 조금씩 전송된다.

9. 이미지 태그에 높이와 넓이를 써주도록 한다. 브라우저는 이를 인식해 이미지가 들어갈 정확한 자리를 남겨놓고, 문자를 배열한다. 즉 사용자는 이미지가 모두 나오기를 기다리지 않고도 컨텐츠를 읽을 수 있게 되는 것이다.

10. 캐쉬를 최대한 이용한다. 다른 페이지에서 쓰였던 그래픽 파일들을 그대로 재사용하면, 이미 사용자의 캐쉬에 저장되어 있으므로 더 빨리 나오게 된다.

---------------------
정보디자인
---------------------
정 보 디자인은 부담스런 주제처럼 들리지만, 사실 상식 선에서 해결할 수 있는 문제이다. 디자이너들이 저지를 수 있는 가장 큰 죄악은 사용자를 혼란스럽게 하는 것이라고 생각들 하지만, 신경 쓰지 않은 디자인을 가지고는 사용자들에게 완전히 잘못된 내용을 주게 된다. 사용자의 관점을 고려하면서도 사이트 구조가 사용자에게 어떤 종류의 내용을 보내고자 하는지를 알아야 하겠는데... 정보 디자인을 전문으로 하는 회사 블랙 아이디에게 열 가지 팁을 부탁했다.

1. 특정 기능을 수행하는 사이트를 개발할 때 중요한 정보를 모호한 위치에 숨기지 않는 것이 중요하다. 규정이나 설명서 등은 디자인을 망친다는 이유로 종종 구석에 위치시키고는 한다. 절대 중요한 정보를 숨기지 말라.

2. 정보 디자인의 규칙 중 가장 유명한 것이 '세 번 클릭으로 원하는 정보에 도달하도록' 하라는 것이다. 이 규칙은 무시하지 않는다. 사용자가 무엇인가 하려고 할 때 수많은 화면을 거쳐가야만 한다면, 그 사용자는 다른 곳으로 가버릴 것이기 때문이다.

3. 사용자가 행동을 취하도록 하는 버튼(calls to action)이 매 페이지마다 있어야 한다. 그렇지 않으면 사용자는 페이지를 보고 나서 '그래서?'라고 생각할 것이다. 사용자가 회원 등록을 하거나 물건을 사거나 사이트의 어떤 기능을 사용하도록 하려면, 가능한 모든 페이지에 그것을 홍보해야만 한다.

4. 내비게이션 요소들이 페이지 내에서 한 눈에 들어오지 않는다면 사용자는 그것을 볼 수 없고 따라서 찾아가지도 않게 된다. 내비게이션 도구를 찾기 위해 스크롤하게 만드는 것은 절대 금물이다.

5. 사이트의 디자인을 잘 하는 것은 중요하다. 하지만 사용자가 페이지를 보고 난 후 이것이 무엇을 하려는 사이트이며 자신이 무얼 해야 할지를 모른다면 그 웹사이트는 실패한 것이다. 단순하고도 정확하게 사용자가 해야 할(할 수 있는) 것들을 표시해 주어야 한다

6. 모호한 제목은 처음 방문하는 사용자에게 혼란만 준다. 내비게이션 제목에는 간단한 단어를 사용하고, 제목을 보고 어떤 페이지인지 정확히 알 수 있도록 해야 한다.

7. 많은 사이트들이 방문객에 관한 정보를 수집하는 것을 목적으로 하고 있다. 장황한 양식으로는 이 목적을 달성할 수 없다. 작성해야 하는 양식을 짧고 간단하게 하고, 사용자가 자신의 정보를 제공할 만한 가치나 보상을 제공하도록 한다.

8. 사람들은 인터넷을 '읽지' 않는다. 읽어야 할 필요가 있을 때는 프린트하게 마련이다. 긴 텍스트 대신 짧은 설명을 달고 사용자가 원할 때 기술적인 문서나 멋진 산문들을 다운로드해서 볼 수 있도록 하면 좋다.

9. 사용자에게 신뢰감과 친근감을 주기 위해서는 내비게이션과 페이지 레이아웃의 일관성이 필요하다. 페이지가 바뀔 때마다 내비게이션이나 정보 디자인을 찾아 헤매는 것은 혼란스럽고 짜증나는 일이다.

10. 마지막 팁은 정보 디자인이기보다는 정보의 표시에 관한 것이다. 웹사이트에 엄청난 경비를 들이는 세계 최대의 기업 사이트에서부터 침실에서 만들어지는 동호회 사이트에 이르기까지, 이 모든 사이트들이 문법이나 철자 오류를 가지고 있다. 이런 오류는 사이트 전체의 질을 떨어뜨린다.


---------------------
내비게이션
---------------------
내 비게이션 구조를 디자인하는 것은 매우 재미있다. 우주선의 계기판 모양에서 동굴 벽화에 이르기까지 다양한 내비게이션 구조들이 있어왔다. 내비게이션을 잡는 것은 정보 디자인 과정과 매우 흡사할 수도 있지만, 내비게이션은 사용자의 흥미를 끌기 위해 눈에 보이는 시각적 은유(metaphor) 까지를 사용한다. 영국에서 가장 잘 알려진 웹디자인 대행사인 딥엔드에게 내비게이션에 관해 물었다. 런던 딥엔드의 토니 필립스 (Tony Philips, 디자인 디렉터), 제인 오스틴 (Jane Austin, 인터랙션 디렉터), 빅토리아 잭 (Victoria Jack, 인터랙션 디자이너), 로렌스 톰슨 (Laurence Thompson, 디자이너)에게 감사를 전한다.

1. 방문객을 설정하라. 이 사이트는 누구를 위한 것인가? 사용자의 유형을 정의함으로써, 사용자가 이 매체에 얼마나 친숙한지, 그들이 이 사이트에서 얼마만큼의 시간을 보내는지, 그리고 사이트의 기능을 얼마나 이해하고 있는지의 관점에서 그들에게 적합한 내비게이션 시스템을 만들 수 있게 된다.

2. 기능을 설정하라. 이 사이트는 무엇을 하는 사이트인가? 사용자들이 내비게이션에서 기대하는 것은 무엇인가? 사용자의 구매 의사를 이끌어내야 하는가? 혹은 사이트를 둘러보거나 즐기게 만들 것인가? 초기에 사이트의 기능을 정의하면 그에 따라 다른 것들을 결정할 수 있게 된다.

3. 명확한 분류와 제목을 사용한다. 목표가 되는 사용자가 이해할 수 있는 용어와 언어를 사용하도록 한다. 시각 언어의 일관성 역시 중요하다. 서체의 선택, 컬러의 사용, 간단한 롤오버 등에서 일관성을 줄 수 있다.

4. 위치와 배열에 일관성을 지킨다. 모든 페이지에서 글로벌 내비게이션(Global Navigation: 사이트 전체에 걸쳐있는 내비게이션)과 로컬 내비게이션(Local Navigation: 어떤 섹션이나 페이지에만 존재하는 내비게이션) 요소에다 일정한 위치와 순서를 정해 놓는다. 이렇게 하면 첫 페이지에서 다른 페이지로 이동한 사용자가 컨텐츠의 범위를 정확하게 알 수 있고, 따라서 친숙함을 줌으로 원하는 정보와 대화의 경험을 느낄 수 있다.

5. 다른 관련된 컨텐츠로의 링크를 생각해 본다. 아마존 웹사이트([w]www.amazon.com)가 좋은 예이다. 이 사이트는 시각적으로는 매우 평범하지만 매우 효율적인 구조로 구성되어 있다는 것을 알 수 있을 것이다.

6. 많은 사이트들이 좀더 감성적인 사용자 경험(User experience)을 이끌어내기 위해 상상력과 창의력을 동원해 내비게이션 시스템에 접근한다. 탱고 웹사이트 ([w] www.tango.com)를 보자. 이 사이트는 컨텐츠와 내비게이션 도구들에 장난스러운 그림이나 캐릭터를 사용해 유머러스한 느낌을 주고 있다.

7. 사용자로 하여금 컨텐츠를 자신에 맞게 조정할 수 있도록 하는 것이 좋을 때가 있다. 타이포그래픽 56 웹사이트(Typographic 56 사이트), [w] www.typographic56.co.uk)는 국제 타이포그래픽 디자이너 모임(International Society of Typographic Designers)을 위해 만들어진 것으로, 사용자가 정보의 양과 순서를 선택할 수 있도록 되어있다.

8. 가끔 색다른 시각적 메타포를 찾아보는 것도 흥미로운 결과를 만들어낸다. 비어 이즈 라이프(Beer is Life) 사이트, [w] www.beerislife.co.uk)는 학생들을 위해 만들어졌는데, 내비게이션 요소의 하나인 '학생관'은 그들을 염두에 두고 디자인된 것이다. 다른 웹사이트들은 기능과 콘텐츠에 기반해서 은유적인 내비게이션 구조를 만든다. 디자인과 아트 디렉션 웹사이트 (Design and Art Direction Website), [w] www.dandad.org에서 딥엔드는 '연필을 굴려서' 다른 섹션으로 이동할 수 있는 메뉴를 선보였다.

9. 내비게이션 시스템은 종종 이야기의 형태를 띠기도 한다. 프렌치 커넥션 사이트, [w] www.fcukingkybugger.com은 이야기 중간에 사용자가 줄거리를 선택할 수 있고, 그에 따라 결과가 달라지게 되어 있다.

10. 내비게이션의 한계를 넘어, 인터랙티브 사운드를 사용하여 완전히 실험적인 내비게이션 시스템을 만들어내는 것도 가능하다. 새로 나온 소프트 드링크, 카본(Carbon)을 위해 딥엔드에서 제작한 웹사이트, [w] www.carbon-stimulation.com은 사용자가 내비게이션 요소들을 발견하고 즐기도록 되어있다. 사용자는 시각적, 청각적인 피드백을 해석하고 메뉴를 선택할 수 있다. 또 하나 눈 여겨 봐 둘만한 사이트로는 [w] www.copyrightdavis.com이 있다.


---------------------
애니메이션
---------------------
애 니메이션으로 인해 웹은 활기를 띠게 되었다. 하지만 디자인이 잘된 웹사이트라도 완성도가 떨어지는 애니메이션이 들어가면 격이 떨어지게 마련이다. 애니메이션은 다운로드 속도를 느리게 하고 어떤 경우는 플러그인을 필요로 하기도 하며, 가장 나쁜 것은 몇 가지의 '단순하면서도 효과적인' 애니메이션 스타일이 웹사이트 전반에 걸쳐 퍼져 있다는 점이다. 현재의 웹 애니메이션이 필요로 하는 것은 독특함이다. 마티니의 멀티미디어 팀장인 벤 애덤스(Ben Adams)의 조언을 들어보자. 일반적인 조언에서 시작해 아홉 가지의 플래시 관련 팁을 제공한다.

1. 웹사이트를 제작할 때 가장 중요한 결정 사항이 있다면 '애니메이션을 넣을 것인가 말 것인가'이다. 이것은 매우 결정하기 쉬운 문제인 것 같지만 개발 시 이 문제를 고려하지 않을 경우, 결과적으로 어지럽거나 구토를 유발할 것만 같은 페이지에 말도 안 되는 내비게이션이 나오는 경우가 허다하다. 신중히 생각하고 어떤 사용자들을 겨냥하고 있는지를 명확히 한 후 그들에게 어떤 시각적 경험을 선사할 것인지를 정한다. 속도와 플러그인, 브라우저, 그리고 시각적 효과와 파급 효과를 고려한다.

2. 처음에 종이 위에 스토리보드를 그려 주제를 강력하고 훌륭하게 발전시켜 나간다. 작은 크기로 대강 그려가면서 무대와 장면, 애니메이션을 기획한다. 아이디어를 위해 영화나 전통 TV 애니메이션 시리즈들을 보는 것도 좋다. 영화나 전통 애니메이션 작품들을 보는 것은 효과적인 카메라 각도나 편집을 위해 특히 유용하다.

3. 기본적인 얘기이나, 처음 무비를 제작할 때부터 Modify Movie 메뉴에서 초당 프레임 비율을 설정하도록 한다. 대개 초당 20이나 24 프레임을 쓴다. 단순한 플래시 무비에서는 최소 12fps 정도를 주면 CPU의 부담을 줄이게 되어 낮은 컴퓨터 사양에서도 재생할 수 있게 된다.

4. 플래시에서 심벌(Symbol)을 흐릴 때 알파(Alpha) 대신에 틴트(Tint)로 변화시킨다. 이렇게 하면 CPU의 처리 시간을 줄일 수 있다. 예를 들어 엷거나 흰 배경 색에서 심벌을 페이드아웃 시킬 때 틴트를 흰색으로 주면 같은 효과를 얻을 수 있다. 대부분 알파를 사용하는 것보다 이 방법을 쓰는 것이 효과적이다.

5. 이즈인과 이즈아웃(Ease In & Ease Out: 플래시의 Modify 메뉴에서 Frame Motion과 Tweening 부분에 있다)의 차이를 알아야 한다. 움직임이나 중력을 표현할 경우 이 두 옵션을 적절히 사용하면 큰 효과를 볼 수 있다. 간단히 말하면 이즈아웃은 끝으로 갈수록 천천히 움직이는 것이고, 이즈인은 천천히 시작되어 빨라지는 것이다.

6. 오브젝트의 움직임을 끝내거나 화면에서 페이드아웃 시킬 경우 마지막에 빈 프레임을 넣어준다. 더 이상 쓰이지 않는 오브젝트가 화면에 남아있으면, 줌 효과를 주거나 다른 요소에 트위닝 효과를 줄 때 처리 속도에 영향을 주게 되어 애니메이션의 재생 속도가 느려질 수 있다.

7. 음향 효과 역시 훌륭한 애니메이션의 중요한 요소인데, 종종 무시된다. 사운드를 정확한 키프레임에 위치시키는 것은 정말 큰 차이를 가져온다. 공들여 사운드를 편집하고 애니메이션 이벤트와 일치하는 키프레임에 사운드를 넣는다.

8. BMP나 JPEG 위에서 형체를 애니메이션화 할 때. 먼저 BMP(혹은 JPEG)를 브레이크 어파트(Break Apart) 해준다. 이미지를 선택하고 그룹화 한 후 심벌로 변환한다. 효과(Effects) 메뉴에서 알파치를 99퍼센트 이하로 낮춘다. 이렇게 하면 벡터 그래픽이 움직일 때 비트맵이 몇 픽셀씩 움직이는 현상이 없어지고 자연스럽게 된다.

9. 캐릭터 애니메이션. 캐릭터를 몇 개의 부분으로 나눈다. 캐릭터가 얼마나 정교하게 움직일 것인지를 결정한 후 화면상에서 어떤 부분들이 움직이거나 이동할지를 정한다. 예를 들어 캐릭터를 눈 (깜빡일 때), 입과 턱 (립싱크 할 때), 머리, 몸통, 팔, 손, 다리, 등등으로 분리시킨다.

10. 아웃라인을 그리기 위해 플래시의 라인 도구를 이용할 때, 크기를 확대/축소하거나 줌 효과를 주면 경계선이 왜곡된다는 것을 알아야 한다. 가장 가는 선(hairline)의 경우 100 퍼센트에서는 매우 자세하게 나타나지만 이미지의 크기를 축소하면 선이 너무 굵어진다. 그러므로 작은 이미지는 너무 자세히 그릴 필요가 없다. 파일 크기만 커진다.



--------------------------------
흡인력 있는 콘텐츠
--------------------------------
' 흡인력 있는 콘텐츠(Sticky contents)'라는 말은 오히려 다르게 해석될 의미가 있는 말이지만, 이제는 확실히 굳어진 인터넷 용어 중의 하나가 되었다. 웹사이트에서 게임이나 재미있는 장치들을 제공해서 방문객들이 오랫동안 머물게 하고 재방문하도록 하는 수법은 몇몇 웹 디자인 대행사들 사이에서 거의 예술의 수준으로 끌어올려지고 있다. 이 분야의 유명한 선두 주자의 한 명인 브렌든 도즈(Brendan Dawes)는 전에 Subnet에서 일했고 지금은 맨체스터에 있는 마그네틱 노스의 제작 감독으로 있다. 그의 열 가지 팁을 들어보자.

1. 콘텐츠를 자주 업데이트한다. 콘텐츠가 항상 똑같다면 아무도 그 사이트를 찾지 않을 것이다. 그러려면 헌신적인 편집자들로 이루어진 팀이 필요하다. 만약 작은 회사나 집단일 경우는 방대한 주제의 콘텐츠를 보유하고 있는 [w] www.moreover.com 등의 사이트와 계약을 맺고 콘텐츠를 제공받을 수도 있다.

2. 방문객에게 회원 등록을 하게 하고 사이트의 업데이트 소식을 이메일로 알려준다. 왜 회원 등록을 해야 하는지와 회원 등록을 할 경우의 이익, 그리고 회원의 이메일 주소를 다른 곳에 누출시키지 않는다는 것을 알려준다. 하지만 꼭 회원 등록을 하지 않아도 사이트를 이용할 수 있다는 것을 확실히 해둔다. 그렇지 않으면 사람들은 사이트를 외면한다.

3. 플래시 기반의 사이트를 만들 작정이라면, 첫 페이지만은 빨리 뜨도록 하는 것이 좋다. 방문객들이 콘텐츠에 흥미를 갖게 된 후 다른 섹션들에 좀더 무거운 콘텐츠를 올려도 된다. 방문객들이 뭔가 흥미를 느낄만한 것이 있다는 사실을 일찍 깨닫도록 하라는 것이다.

4. 사이트에서 게임을 제공한다면, 최고 점수를 보여주는 페이지를 만들어서 게임에 들이는 사용자들의 노력을 기록할 수 있도록 한다. 이렇게 하면 사용자들은 그 사이트에 다시 들어와서 자신이 몇 위나 되는지 확인하게 된다.

5. 사이트에 뭔가 독특한 것을 넣어서 사람들이 그 기능을 사용하기 위해 사이트를 방문하도록 만든다. 이 방법은 사이트가 니치 서브젝트(niche subject: 규모는 적지만 시기 적절함과 독특함으로 인해 수익 가능성이 있는 분야)에 관한 것일 때 특히 효과적이다. 사이트에서 제공하는 동시 메시지 서비스나 메시지 포럼 같은 것이 부가 서비스의 좋은 예이다. 사이트에 메시지 포럼을 넣는 것은 충분한 수의 고정 방문객이 있을 경우, 항상 새로운 읽을거리가 있다는 것을 의미한다.

6. 다른 사이트들에서 제공하는 유틸리티를 사용하면 컨텐츠를 항상 새롭게 유지할 수 있다. [w] www.blogger.com에서는 멋진 웹 로그 유틸리티(log utility)를 제공한다. 이 유틸리티를 자신의 사이트에 붙일 수 있고, 지난 로그들을 관리할 수도 있다.

7. 컨텐츠에 쏟는 노력의 일부를 비슷한 성향의 사람들로 이루어진 커뮤니티를 구축하는데 들여보자. [w] were-here.com 같은 사이트가 어떻게 플래시 세계에서 성장했는지를 살펴보라.

8. 사이트에 검색 기능을 넣는다. 사람들은 특정 컨텐츠를 빨리 찾으려고 할 때 메인 내비게이션 도구를 사용하기보다는 검색을 선호한다. [w] www.atomz.com를 보라. 이 사이트는 정말 훌륭한 검색 엔진을 무료로 제공하는데, 플래시 파일에 들어간 텍스트까지 검색할 수 있다.

9. 사람들은 자신의 의견을 피력하는 것을 좋아한다. 웹사이트에 관련된 이슈에 대해 투표나 여론 조사 등의 기능을 넣어보라.

10. 웹은 매우 인터랙티브한(대화형) 매체라는 것을 기억하라. 즉, 어떻게 하면 사용자를 사이트의 경험에 몰입하도록 할 수 있는지에 관해 항상 염두에 두고 있어야 한다.



--------------------------
음악과 음향 효과
--------------------------

웹디자인에서 가장 간과되고 있는 부분이 바로 소리일 것이다. 디자이너들은 대개 시각적인 경험에만 초점을 두고 만다. 시각적인 경험이 가장 중요한 것은 분명하지만, 사이트를 정말 기억에 남도록 만드는 것은 음향 효과와 음악이다. 이 부분은 사이트를 향상시키거나 완벽하게 만드는 한 방법이다. 훌륭한 사이트들은 대부분 뛰어난 청각적 요소를 써서 사용자 경험을 마무리한다. 다음의 팁들은 영화와 TV, 웹을 위한 사운드 디자인을 전문으로 하는 아마데우스 미디어의 로빈 커쇼우(Robin Kershaw)가 제공한 것이다.

1. 왜 음악 혹은 소리를 사용하려는지 확실히 한다. 적절한 사운드는 사이트의 분위기에 놀라운 효과를 주며 독특한 선율은 사이트의 인지도를 높일 수 있다. 인텔의 로고와 멜로디는 따로 떼어서 생각할 수 없다. 이런 것을 오디오 브랜딩(audio branding)이라고 한다.

2. 사이트에 사운드를 사용하는 것은 전체적 디자인의 한 부분이라는 것을 명심하도록. 사운드가 단순히 장식적으로만 쓰인다면 오히려 신경 거슬리는 것이 될 수 있다. 사용자 경험을 염두에 두도록 한다.

3. 관객을 신중히 고려한다. 다운로드 속도 때문에 사용자의 모뎀 유형에 따라 사운드를 사용할 수 있는 범위가 달라진다. 관객의 연령대와 통계 수치 역시 고려해야 한다. 연금을 받는 사람들에게 댄스 음악을 트는 것은 아무 소용이 없다. 그들은 그 사이트를 떠날 것이다.

4. 다운로드 시간을 최소화하기 위해 스테레오를 모노로 바꾸는 것을 고려해 본다. 말 그대로 파일 사이즈가 반으로 줄어든다. 하지만 어떤 종류의 음악은 다른 것들보다 음질이 더 많이 손상된다는 것에 주의해야 한다. 압축 정도에 따라서도 음질이 많이 달라진다.

5. 음악 외에도, 멋진 화면 해설을 사이트에 잘 결합한다면 사이트의 가치를 더욱 높일 수 있다. 많이 들어갈 필요는 없고, 그저 페이지가 업데이트 되었다던가 하는 발표 정도면 좋을 것이다 (그밖에도 상상의 나래를 마음껏 펼쳐보자).

6. 화면과 소리를 어떤 방식으로든 동기화 할 필요가 있다면 플래시를 사용해야 한다. 플래시에서 사운드를 사용하는 방법에는 두 가지가 있다. 이벤트 사운드와 스트림 사운드이다. 플래시에서 이벤트 사운드는 어떤 키프레임에 도달하면 재생되기 시작해서 애니메이션과는 전혀 무관하게 끝까지 재생된다. 스트림 사운드는 프레임 단위로 재생되므로 프리로드(Preload) 시간이 짧다.

7. 프리로딩(이벤트) 사운드를 사용할 것인지 스트리밍을 사용할 것인지 결정하기 위해서는 사이트의 나머지 부분들을 살펴보아야 한다. 애니메이션을 어떤 식으로든 프리로드 할 작정이라면 사운드 역시 프리로드 해야 한다. 사이트의 첫 페이지가 빨리 뜨기를 원하거나 또는 긴 음악을 넣고 싶다면 스트림 사운드를 사용하라. 몇 초간의 프리로딩 후에 음악이 재생되기 시작할 것이다. 하지만 네트웍이 혼잡할 경우 소리가 끊길 수도 있다는 점을 염두에 둘 것.

8. 화면과 음악이 동기화되지 않아도 상관없다면 좀 더 진보된 압축 방법을 쓸 수 있다. MP3(플래시 최고의 익스포트 옵션이다)가 가장 적당하지만 음악만 있을 경우 QDesign Music을, 목소리만으로 된 경우에는 퀄컴 PureVoice를 써보는 것도 좋다.

9. 상대적으로 다운로드 시간이 적게 걸리는 반복적인 음악의 경우 동기화된 사운드와 스트림 사운드를 결합하는 것도 생각해볼 수 있다. 플래시에서 스트림 사운드는 애니메이션 재생률을 떨어뜨릴 수 있으므로, 적절한 곳에 위치시키거나 분리된 레이어에 동기화된 사운드를 반복해서 사용하면 된다.

10. 항상 전문가가 제작한 음악을 사용하도록 한다. 작곡가에게 곡을 구입하던가 기존의 라이브러리 음악을 구입한다. 저작권을 갖지 않고 음악을 사용할 수는 없다. 음악을 도용하는 것은 여러 작곡가들을 죽이는 일이며, 나중에 값비싼 대가를 지불하게 될 수도 있다.


--------------------------
스트리밍 미디어
--------------------------

최근 3 년 동안 우리는 브로드밴드(Broadband : 廣帶域)의 가능성에 관해 들어왔고, 근사한 웹 비디오 솔루션의 미래를 믿어왔다. 온라인 관객들이 얼마나 빨리 브로드밴드 서비스로 전향하고 있는지는 미지수이지만, 디자인 관점에서 볼 때 작은 비디오가 사이트에 움직임과 컬러, 그리고 청각적인 재미를 가져다주는 큰 역할을 한다는 것은 확실하다. 관객을 지루하게 만들지 않고 영상을 제공하려면 스트리밍 미디어를 써야 한다. 최대의 온라인 엔터테인먼트 사이트인 아이필름이 말하는 스트리밍 미디어에 관한 열 가지 팁을 들어보자.

1. 소스의 질이 낮으면 압축 결과도 좋지 않고, 웹사이트의 질 역시 떨어진다.

2. 항상 최고 해상도에 최대 프레임 사이즈, 최고 프레임 비율(재생률)로 캡처한다. 비디오를 캡쳐할때 가장 좋은 기준은 720×480 픽셀의 해상도, 29.97fps로 DV FireWire 에서 캡쳐받는 것이다.

3. 아이필름이 추천하는 편집과 캡쳐용 소프트웨어는 맥에서 사용되는 파이널 컷 프르(Final Cut Pro)와, Mac과 PC에서 사용할 수 있는 어도비 프리미어(Adobe Premiere) 6.0이다. 압축용 소프트웨어로는 단연코 테란(Terran)의 Cleaner 5를 추천한다.

4. 이제 웹에 올릴 포맷을 결정해야 한다. 주요 포맷으로는 리얼미디어 (Real 8), 퀵타임 (Sorenson 2, 버전 3은 베타 테스트 중), 윈도우즈 미디어가 있다. 이 포맷들은 각각 장단점을 가지고 있다. 이 세 개의 포맷을 모두 시험해본 후 어떤 것이 가장 좋을지 결정하는 것이 좋다.

5. 잘리는 현상(cropping). 결과물을 보면 처음과 끝은 괜찮은 것 같은데 중간의 곳곳에서 일정치 않게 잘리는 현상이 발생하는 경우가 있다. 문제가 있으면 설정을 조절하든가 다른 포맷으로 압축하는 것을 고려해본다.

6. 화면의 가로 세로 비율을 염두에 둘 것. 만일 DV와 같이 일반 화면 비율이 아닌 포맷의 영상을 캡쳐했다면, 압축할 때 4:3의 비율에 맞게 크기를 조절해 주어야 한다. 표준 화면 비율은 640×480, 320×240, 240×180 등이 있다.

7. 화질에 상관없이 파일 크기를 줄일 수 있는 두 가지 방법이 있다. 첫째는 프레임 비율을 줄이는 것이다. 15-12fps 정도면 200-300k의 스트리밍 파일이 나온다. 6-10fps로 낮추면 낮은 대역폭(56k 모뎀)에서 재생할 수 있을 정도의 크기인 100k 정도로 파일 크기를 줄일 수 있다. 둘째 방법은 화면 비율/해상도를 줄이는 것이다. 320×240이나 240×180 픽셀 사이의 동영상은 200-300k 정도의 파일 크기로 압축된다. 이것을 160×120이나 240×180 픽셀로 줄이면 파일 크기는 100k 정도로 줄어든다. (화면 비율은 4로 나누어지는 숫자이어야 하며, 그렇지 않은 수를 지정했을 경우는 되지 않는다.)

8. 56k용 스트리밍 파일에서 압축 대역폭은 36k를 넘어서는 안된다. 대부분의 전화선은 56k 모뎀 사용자들에게 56k의 속도를 모두 지원하지 않기 때문이다.

9. 클리너 5(Cleaner 5)의 블랙 리스토어(Black Restore) 필터를 써보자. 이 필터는 화질을 좀더 향상시켜주는 반면 어두운 부분의 세밀함은 손상시킨다. 오디오 쪽에서는 오디오 리버브(Audio Reverb) 필터를 쓰면 오디오 압축으로 인해 생기는 잡음들을 완화시켜준다.

10. 56k용으로 압축할 때는 16k의 Low Pass 필터를 쓰면 고음 부분의 잡음이 줄어든다.



----------------
3D화 하기
----------------
소 프트웨어 개발자들의 주장에 일리가 있다면, 웹 3D는 세상을 구원(?)하고 만연해 있는 따분함을 치료할 것이며, 우리 모두는 영원히 가상의 즐거움이라는 사이버 세계에서 살게 될 것이다. 이상에 가까운 얘기는 그만하고. 사실 웹 3D 솔루션을 선택하는 것은 웹 디자이너가 직면한 가장 어려운 문제 중의 하나이다. 어쨌든 몇몇 디자이너들은 웹에서 훌륭한 3D 작품들을 선보이고 있다. 디지트 런던의 제작 감독인 닉 크리스티어(Nick Cristea)에게 웹 3D에 대한 조언을 들어보자.

1. 적절한 근거에 의해 3D를 사용하라. 3D를 쓰는 것이 웹사이트의 분위기를 돋구는 편한 방법인 것처럼 보일 수도 있지만, 사이트 전체에 꼭 필요한 부분이라고 판단될 때에만 3D를 사용해야 한다. 형편없는 아이디어나 컨텐츠의 부족을 메우는 방법으로 3D를 사용한다면, 그건 정당화될 수도 없고 팔릴 수도 없다. 프로젝트에 왜 3D를 사용해야 하는지를 대략 정리한다. 3D를 사용하는 것이 정말 최선의 방법인지 스스로에게 질문해 본다.

2. 최적의 3D 도구를 선택한다. 리얼 3D이어야만 하는가? 특정 플러그인을 꼭 다운로드해야만 하는가? 저작권 문제는 어떻게 되나? 그 작업을 위해 특정 개발자를 고용해야 할 필요가 있는가? 현재로서는 플래시가 가장 많이 쓰이는 유일한 플러그인이므로 가능하다면 플래시를 쓰는 것이 좋다. 인터넷에서 액션스크립트 3D 엔진을 구할 수도 있고, 프레임 단위의(frame-by-frame) 애니메이션으로 3D처럼 보이게 할 수도 있다. 시점을 움직이거나 아바타(Avatars)를 바꾸거나 그림자나 조명을 실시간으로 바꾸어야 한다면 '진짜' 3D 플러그인을 쓸 필요가 있다.

3. 디자인 초안을 만든다. 줄거리, 분위기, 배경, 속도, 드라마 등은 3D 도구를 사용할 때 모두 중요한 요소들이다. 일관성 있고, 잘 고안된 상황을 만들어 방문객이 몰입할 수 있도록 해야 한다. 시각적인 요소들의 관계를 적절히 조합하고, 테스트한다.

4. 3D 작업의 장점은 단시간에 구도를 여러 가지로 바꿔볼 수 있다는 점이다. 단순한 오브젝트를 만들어 구성과 애니메이션을 테스트한다. 카메라 각도를 이리저리 옮겨보거나 움직이는 속도를 바꿔보거나 한 장면 내의 오브젝트들간의 관계를 다양하게 설정해 본다. 새로운 아이디어를 발견하는데 이런 시도들이 유일한 방법일 때도 있다.

5. 대략적인 모델을 사용해 구성과 줄거리의 감을 잡은 후 웹에서의 기본 원형을 만든다. 모든 종류의 트라이얼이나 데모 플러그인에서 작업한 시안이 구현 가능한지 테스트해본다. 실제로 만들어보거나 기본 원형을 만들어보아야만 무엇이 가능하고 무엇이 불가능한지를 알 수 있다.

6. 모델을 최적화한다. 3D 웹 콘텐츠의 최종 결과물이 어떤 포맷이든, 최적화의 규칙은 모두 같다. 모델이 세밀하고 복잡해질수록 파일 사이즈는 커진다. 처음부터 아이디어와 디자인을 단순하게 하고, 파일 사이즈를 계속 체크한다.

7. 3D 요소들을 내보낸다. 일부 플러그인은 모델링 단계에서 특정한 방법을 써야 한다. 3ds Max는 현재까지 가장 많이 지원되고 있으며, 대부분의 플러그인 기술을 지원하는 고유 애드-온(add-on: 특정 기능 보강을 목적으로 만든 보조 소프트웨어)들이 무료로 나와 있다. 하지만 비싸다. LightWave는 훌륭한 VRML 내보내기 기능을 가지고 있지만 특정 플러그인이 없다. 스위프트 3D(Swift 3D)나 아모피움 프로(Amorphium Pro)는 저렴한 가격으로 3D SWF 파일을 만들 수 있는 좋은 프로그램들이다. 어떤 소프트웨어를 사용하든, 모델을 내보내어 초기에 테스트를 한 후, 한 장면을 좀더 작은 여러 개의 부분으로 나눈다.

8. 최적화와 사이트 구축. 사이트를 스트리밍할 수 있는 요소와 배경에서 로딩될 요소, 그리고 필요할 때만 로딩되는 요소 등, 몇 개의 레이어로 분리시킨다. 모든 로딩 시간을 계산하고 조절하여 되도록 사용자가 로딩 시간을 느끼지 못하도록 한다.

9. 파일 크기가 문제가 되거나 기술적으로 문제가 있을 때 창조적으로 접근하지 못하고 결과물의 질을 떨어뜨리는 경우가 있다. 사용하고 있는 도구를 충분히 테스트하고 기능에 관해 잘 알아야 이러한 문제들을 해결할 수 있다. 단순한 팔레트와 셰이프, 텍스쳐 매핑을 사용하고, 하나의 셰이프나 오브젝트들을 반복해서 쓴다.

10. 한가지 도구로 모든 것을 해결할 수는 없다. 여러 도구를 결합해서 사용하면 좀더 새롭고 흥미로운 결과물을 만들어낼 수 있다. 30일 짜리 데모 버전들을 잘 이용해서 최근의 도구와 기능들을 익혀 시대에 뒤떨어지지 않도록 한다.




-----------------------
난해한 백-엔드
------------------------
데 이터베이스 서버를 다루는 것과 그것을 웹사이트와 연동시키는 것은 그리 재미있는 일은 아니다. 하지만 이 작업이 제대로 되면 웹디자이너들의 작업 시간을 많이 줄일 수 있다. 효율적으로 설계된 데이터베이스를 기반으로 콘텐츠가 자동으로 업데이트 되기 때문에 디자인과 씨름하지 않아도 된다는 말이다. 어려운 것은 그 데이터베이스를 초기에 정확하게 설계해야 한다는 점이다. 이후에 변경이나 재구축하려면 시간 낭비가 막대하다. 데이터베이스와 사이트 구축 및 통합을 전문으로 하는 웹디자인 집단인 콘챙고에게 마지막 열 가지 팁을 들어보자.

1. 디자인과 개발을 분리시키지 말 것. 복잡한 데이터 기반의 사이트를 효율적으로 만드는 것은 훌륭한 디자인이나 잘 짜여진 코드만으로 되는 것이 아니다. 두 부분이 긴밀하게 협력해야 한다. 디자이너들은 개발 팀과 함께 일해야 한다. 개발자들이 디자이너의 의견을 무시하면 사이트는 위험에 빠지게 된다.

2. 콘텐츠가 자동으로 바뀌는(dynamic) 사이트는 최소한의 디자인 템플리트가 대부분의 페이지들에 적용되는 경우에 한해서 가장 효율적으로 운영된다. 이 점이 창의력을 제한하는 것은 아니다. 개발 팀은 다르게 얘기하겠지만 템플리트는 딱딱한 망으로 짜여진 레이아웃을 의미하는 것은 아니다. 템플리트는 여러 유형의 페이지들에 공통으로 쓰이는 요소들을 구분해주는 것이다.

3. 데이터베이스에 필요한 테스트 데이터를 가능한 빨리, 그리고 가능한 실제 데이터에 가까운 것으로 받는 것이 좋다. 데이터는 사이트 컨텐츠의 대부분을 차지하면서도 대개 맨 마지막에야 확정되기 때문에 문제가 생긴다. 누군가 고객과 협조해서 테스트 데이터를 받아내지 않는다면 전체 프로젝트가 위험에 처한다. 실제 데이터가 시스템에 입력될 때 대부분의 문제들이 발생하기 마련이다. 실제 데이터를 초기에 받아내지 못한 경우, 그 사이트는 사상누각이다.

4. 관리자 페이지를 소홀히 하지 말 것. 사이트에 훌륭한 데이터를 넣는 것만큼이나 그것을 보여주는 것도 중요하다. 관리자 사이트를 쓰기 쉽고 직관적으로 만드는 것은 프론트-엔드(front-end: 사용자들에게 직접 보여지는 화면)만큼이나 중요한 문제다. 디자이너들과 유용성(Usability) 관련자들에게 관리자 화면을 디자인하게 하고 카피라이터에게 사용법을 만들도록 한다.

5. 플래시로만 제작된 사이트에서 그림이나 텍스트를 업데이트할 때, 플래시 제너레이터(Flash Generator)가 쓰기 어렵거나 너무 비싸다면 다른 쉬운 방법이 있다. 이미지를 SWF 파일로 저장한 후 LoadMovie와 Target 액션을 써서 이미지를 화면에 불러들일 수 있다. 카피 텍스트는 메모장에서 TXT 파일로 저장한 후 플래시 무비에서 자동으로 읽어들일 수 있다.

6. 사이트에 사용될 패키지와 플랫폼을 고를 때 신중해야 한다. 특정 벤더에 연연하다 보면 고객의 요구 사항을 고객에게 맞지 않는 것에 억지로 끼워 맞추는 결과를 가져온다. 여러 패키지들을 신중하게 알아보도록 한다.

7. 백-엔드는 알고 보면 그리 어려운 것이 아니다. 프론트-엔드나 백-엔드는 문제를 복잡하게 만드는 용어일 뿐이다. 프론트-엔드와 백-엔드, 디자인, 그리고 개발을 가능한 밀접하게 연계시킨다. 다양한 집단의 사람들이 서로 협력하도록 한다면 그들이 백-엔드에 대한 그들의 두려움을 없앨 수 있다.

8. 복잡한 백-엔드 솔루션을 개발할 때 프로젝트 매니저가 기억해야 할 사항은 다음과 같다. (1) 디자이너가 '다 끝냈다'고 할 때 절대 믿지 말 것. (2) 개발자가 '다 끝냈다'고 할 때 절대 믿지 말 것. (3) 테스트: 위 두 가지 사항을 테스트 할 것.

9. 확장 가능하고 기능적인 관계형 데이터베이스를 고안하라. 어떤 데이터를 입력하든지 문제없다고 생각될 때까지 코딩을 시작하지 않는다. 처음에 이 문제를 확실하게 해두는 것이 제대로 작동되는 사이트와 그렇지 않은 사이트의 차이를 만든다.

10. 고객 사이드 파일들을 구조화해서 가능한 하나의 코드를 반복 사용하도록 한다. 예를 들어 ASP 페이지에서는 템플릿에 #include 파일들을 사용한다. 이렇게 하면 코드 구조가 간단해지고 나중에 유지 보수하기도 쉬워진다. 가능한 모듈과 오브젝트라는 관점에서 생각하라.