web2.0[Cityzon]2008. 1. 23. 17:02
설치를 위해 삭제를 실행시 깨끗하게 삭제되지는 않았는가?

삭제후 설치하려는 한글 버전이 이전에 설치했던 한글버젼보다 높은것인가?
(ex : 한글2007을 삭제하고 한글2005를 설치하는 것)


당황스러운 경우

사용자 삽입 이미지

Google & Searchmash & Naver & Daum & Bugkorea까지 찾아보고 한컴회사에 전화까지 했다..
하지만 한컴에선 그냥 지식인에서 떠드는 사항들을 이야기하고 안되면 컴을 밀어야 한다고 했다.. (가장 먼저 한 말은 한글정품인지를 묻고 제품번호를 말해달라는것..)

그러다 이러저러한것 다해보고.  레지스트리 재등록 and 정리까지..
하지만 소용없음 windows installer 에러인가 했지만 아님..
컴을 밀어야 하지만 이컴은 내컴이 아님. 그리고 Data는 다 어디로 백업해..젠장

그러다 해결방법 발견 뭐 발견이랄 것도 없이 최후에 발악이지만 2002설치 안되서 2005설치 안되서 2007설치 아~~ 한글2005보다 높은 버전인 2007버전 설치 성공..
ㅠㅠ 하지만 2005는 설치되지 않음.

Posted by aspirinirony
web2.0[Cityzon]2007. 12. 28. 23:13

나의 컴에서 boot.ini 오류로 인해 window로 부팅한다는 메세지가 나왔다.

난 아 ~~ 윔인가 하고 모든 바이러스/세어웨어 등등의 백신과 점검 프로그램을 돌렸다.

최신이라면 몰라도 이건 바이러스가 아니다라는 나름의 추론으로 boot.ini인 파일에 진짜 문제가 있다 판단하고 net에서 boot.ini data을 search했다.

이전에 듀얼부팅의 경험으로 boot.ini의 정보는 booting시 booting System의 정보를 가지고 있으며 정보라하면 os의 종류와 하드/파티션/파티션에 설치된 root OS정보를 컴퓨터의 부팅시 제공하여 부팅을 원할히 할수 있는 파일이라고 알고 있었다. 만약 내가 xp와 2003을 듀얼부팅으로 사용한다면 root System에 C파티션 xp가 있으며 e에 2003이 있는데 이때 c의 xp를 디폴트 부팅루트로 사용하겠다는 정보를 system에 전달하는 것이다.


그런데 현재 난 듀얼부팅이 아닌데..

그래서 다시 net을 뒤지면서 얻은 정보로 복구콘솔을 사용하라는 내용과 boot.ini파일을 수정하라는 정보를 얻었다.

첫번째 복구콘솔은 너무 시간이 오래걸리것 같으며 진실로 말한다면 CD가 없음. CD없이 boot.ini파일을 복구하는 방법이 있었는데 그것도 cd쪼가리라도 있어야 하며 더군다나 부팅디스크를 사용해야하는 98버젼이였다.

그래서 두번째인 boot.ini파일을 수정한다.를 사용하기로 하였다.

이전에 이미 boot.ini을 수정해본 경험이 있어 시스템에 고급 > 시작/복구 > 설정 > 편집을 실행하였는데 이론 boot.ini파일을 찾을수 없어 수정및 저장하겠냐는 메세지가 날아왔다.

이거 잘못건드리면 피똥싸겠구나 라고 생각한 뒤 다음날을 기다리면 사무실에서 해킹당해 컴을 깨끗이 밀어버린 나의 컴퓨터의 boot.ini정보를 보았다. 그런데 이론 내가 알고 있는 것과 똑같은 것이 아닌가.

net을 뒤지다보면 boot.ini정보는 모두 달라서 다른 컴퓨터의 boot.ini을 사용하지 말라고 했는데 그때 난

boot.ini정보는 root os의 부팅 data를 담아놓은 것으로 알고 있는데 다다르다라.. 뭐 사용자에 따라 드라이버나 하드 파티션이 틀려 사용하지 말라고 했다는 것으로 지금 생각한다.

그래서 난 복구콘솔 , boot.ini 수정 이 아닌 그냥 boot.ini 파일을 만들기로 생각하고 나의 하드와 파티션 드라이버 root os정보를 입력하여 boot.ini파일을 만들고 C:(root)에 집어넣었다.

그리고 재부팅하니 문제 해결..

net에 있는 data는 복제되는 것이 아니라 복제와 함께 복제자의 data가 함께 들어가 변형되는 기형적 특성을 다시 한번 느끼게 된다.

난 이 문제를 풀기위해 사물실에 꼿혀있는 pc정보와 xp서적(거의 15권)을 뒤져가며 boot.ini파일의 개념을 알아갔다. net도 신뢰할수 있는 data가 많지만 이를 가려내기 위해선 신뢰적인 지식또한 요구되는 것 같다.


복구를 위해 작성한 boot.ini 정보


[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS // booting root os data
[operating systems] // OS시스템 data
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

Posted by aspirinirony
web2.0[Cityzon]2007. 12. 28. 22:34

APC(AnLab PlicyCenter 2.0)

AhnLab Policy Center 2.0은 인트라넷으로 연결된 PC에 백신/보안 프로그램을 설치하고, 설치된 백신/보안 프로그램을 중앙에서 관리 및 유지보수할 수 있는 제품입니다. 간단한 프로그램의 설치에서, 조직 내 백신/보안 수준을 판단할 수 있으며, 방역/보안 정책상의 문제점을 파악하여 완벽한 백신/보안 체제가 이루어지도록 할 수 있는 중앙관리 솔루션 입니다.

http://www.softwarecatalog.co.kr/src/Item/ItemMaster.asp?Serial=6101

Posted by aspirinirony
web2.0[Cityzon]2007. 12. 28. 22:22

윈도우 2003의 IIS에서 자체적으로 업로드, 다운로드 용량을 200KB로 제한(default setting)

IIS에 관련된 정보를 변경해 줌으로 사이트 갤럭시 등 컴포넌트를

이용한 업,다운로드시의 문제를 해결 할 수 있다.


C:\WINDOWS\system32\inetsrv\MetaBase.xml


AspMaxRequestEntityAllowed="204800000" <- 업로드 용량제한을 200MB로 설정한 예

AspBufferingLimit="204800000" <- 다운로드 용량제한을 200MB로 설정한 예

*단위 : byte

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

순서.


관리도구 > 서비스 에서


1. IIS Admin 을 정지시킨다.

(WWW 서비스,SMTP,FTP,HTTP ssl 가 같이 정지된다고 나오면 정지시켜준다.)


2. 파일수정.


3. 정지됐던 IIS Admin 서비스와 하위서비스들을 다시 시작해준다.


4.서비스 재시작.

Posted by aspirinirony
web2.0[Cityzon]2007. 12. 28. 21:43

무궁화 삼천리보다 infinity  한 web의 비물리적 공간속에 사용되는 언어는 그 공간만큼의 수로 대적하지만 언어라는 본질적 존재에서 보면 모두가 같은 것이다.. 한글이든 영어든 일어든 중국어든 프랑스어든 결국은 Data전달수단이며 그 전달수단에서 일어난 일을 언어사용과 언어의 이해.. 그리고 언어의 표준과 같은 정립또한 빼놓을수 없는 과정이다..

B에서 C,java,html,javascript,css,php,asp.jsp.net등등내가 아는 것은 이것뿐 하지만 net에 존재하는 language는 더욱 무궁무진이다.. 그래서 알아본다..

그 첫재 python(파이썬)

ENTClic@blog에서 ShowMeDo.com를 소개하고 나서 python이 무엇인지 궁금해졌다..

자세한 내용은 --> http://home.paran.com/johnsonj/pyfaq/index.htm 

O'Reilly Radar의 Blog에 자주 들어가보며 python에 대한 POST가 많이 보이는 것을 알수있다..

뭐 더이상 볼것도 없다. 바로 들어간다..

Python과 다른 언어와의 비교


 (이 글의 원문을 보려면 여기를 클릭하라.)

이들 비교는 개인적인 관점이다. 제언이 있으면 해달라. 다른 더 많은 언어와의 비교를 알고 싶으면 Python Compared 에 접속해보라. Python(파이썬)이 무엇인지 알고 싶으면 executive summary, (Python 이란?)에 가보라.

--Guido van Rossum저. (이강성 역)

  1. Java (자바)
  2. Javascript (자바스크립트)
  3. Perl (펄)
  4. Tcl (티클)
  5. Smalltalk (스몰톡)
  6. C++
  7. Common Lisp and Scheme

 Python은 흔히 Java, JavaScript, Perl, Tcl 또는 Samlltalk와 같은 인터프리터 언어와 비교된다. C++, Common Lisp 그리고 Scheme과 같은 비교되 부각된다. 이 절에서 난 이들 언어를 간단히 비교할 것이다. 이 비교는 언어적인 측면에서만 다룬다. 실제적으로, 프로그래밍 언어의 선택은 다른 실세계 제약(비용, 유용성, 학습 그리고 선행 투자비용 혹은 감성적인 친근감까지도)에 의해 자주 언급되기도 한다. 이러한 면들은 아주 가변적이고, 이러한 면으로 비교를 한다는 것은 시간 낭비에 가깝다.

Java (자바)

일반적으로 Python 프로그램은 Java 프로그램 보다는 느리게 수행된다. 하지만 Python 프로그램은 개발하는 시간이 훨씬 적게 걸린다. Python 프로그램은 Java 프로그램보다도 3-5배 정도 코드가 짧다. 이 차이는 Python의 내장 고수준 데이터 형과 동적인 형결정 기능에서 기인한다고 생각한다. 예를 들면, Python 프로그래머는 인수나 변수의 형을 선언하는데 시간을 허비하지 않고, 구문적인 지원이 언어안에 내장되어 있는 Python의 강력한 다형질의 리스트(polymorphic list)와 사전 형은  거의 모든 Python 프로그램에서 유용하게 활용되고 있다. 실행시간 형결정으로 인해서 Python의 실행시간에 Java가 하는 것보다 좀더 많은 일을 한다. 예를 들면, a+b와 같은 식을 계산할 때, 먼저 컴파일시에 알려지지 않은 a와 b 객체를 검사하여 그들의 형을 알아내야 한다. 그리고 나서 적절한 덧셈 연산을 호출한다. 그 덧셈 연산은 객체에 따라 사용자에 의해 오버로드(overloaded)된 것일 수 있다. 반면에, Java는 효과적인 정수형, 실수형 덧셈을 한다. 하지만 a와 b의 변수선언을 요구하고, + 연산자에 대한 사용자 정의 연산자 오버로딩을 허용하지 않는다.

이러한 이유들로, Python은 '접착' 언어로서 아주 적당한 반면, Java는 저수준 구현 언어로 특성화 지을 수 있다. 사실 이 두 언어는 아주 훌륭한 조합을 이룬다. Java에서 개발된 요소(components)들이 Python에서 활용된다; Python 역시 Java로 구현되기 전에 그 프로토타입을 정하는데 활용된다. 이러한 형의 개발을 지원하기 위해, Java로 쓰여진 Python 구현(implementation)이 개발중이다. 이것은 Java에서 Python을 호출하고 그 반대도 가능하게 해준다. 이 구현으로, Python 소스코드는 Java 바이트코드로 (Python의 동적 의미를 지원하기 위한 실행시간 라이브러리의 도움으로)번역된다.

Javascript (자바스크립트)

Python의 '객체기반' 부분 집합이 대략 JavaScript와 동일하다. JavaScript와 같이 (그러나 Java와는 다르게), Python은 클래스안에 정의하지 않아도 되는, 단순한 함수와 변수를 사용하는 프로그래밍 스타일을 지원한다. 하지만 JavaScript는 이것이 지원하는 전부이다. Python은, 반면에, 훨씬 큰 프로그램을 클래스와 상속이 중요한 역할을 하는 진정한 객체 지향 프로그래밍 스타일을 통하여 더 좋은 코드 재사용을 하도록 지원한다.

Perl (펄)

Python과 Perl은 비슷한 배경에서 개발되었다(유닉스 스크립트언어에서 성장했다). 그리고 많은 비슷한 기능을 지원한다. 그러나 철학은 다르다. Perl은 보편적인 응용지향 태스크를 지원하는데 중심을 두었지만 (예:내장 정규식 표현, 파일 스캐닝과 보고서 생성 기능들), Python은 보편적인 프로그래밍 방법론 (자료구조 설계 및 객체지향 프로그래밍)을 지원한다. 그리고 프로그래머가 우와하고(elegant) 암호같지 않은 코드를 통해 일기 쉽고 관리하기 쉽도록 한다. 결과적으로, Python이 Perl과 가깝지만 그 원래 응용 영역을 침범하는 일은 많지 않다. 하지만 Python은 Perl의 적합한 응용분야 외에 많은 부분에서 적용성을 갖는다.

Tcl (티클)

Python과 같이 Tcl은 독립적인 프로그래밍 언어 분 아니라, 응용 확장언어(extension language)로도 사용된다. 하지만, 전통적으로 모든 데이터를 문자열로 처리하는 Tcl은 자료구조에 약하고 Python 보다 실행에 시간이 많이 걸린다. Tcl은 또한 모듈러 이름영역(name space)와 같은, 큰 프로그램을 쓰기에 적합한 특징들을 가지고 있지 않다. 따라서 Tcl을 사용하는 전형적인 큰 응용 프로그램은 특별히 그 응용에 필요한 C나 C++로 확장된 부분을 갖는다. 이에 반해서 Python 응용 프로그램은 '순수한 Python'으로만 흔히 기술된다. 물론 순수한 Python을 이용한 개발은 C나 C++부분을 쓰고 디버깅하는 것보다도 훨씬 빠르다. Tcl의 결점을 매우는 부분이 Tk 툴킷이다. Python은 Tk을 표준 GUI 라이브러리로 쓰도록 적용했다.

Tcl 8.0은 바이트코드를 도입하여 빠른 처리를 했고, 제한된 데이터 형 지원과 이름영역을 지원한다고 하지만 여전히 거추장스러운 프로그래밍 언어이다.

Smalltalk (스몰톡)

아마도 Python과 Smalltalk의 가장큰 차이는 Python이 보다 더 '주류(mainstream)' 구문을 가진다는 것이다. Python은 Smalltalk과 같이 동적인 형결정과 결합(binding)을 한다. Python의 모든 것은 객체이다. 하지만, Python은 내장 객체 형과 사용자 정의 클래스를 구별하고, 내장 형으로부터의 상속은 현재로서 허용하지 않는다. Smalltalk의 데어터 타입의 표준 라이브러리 모음은 훨씬 섬세한 반면, Python의 라이브러리는 인터넷과 WWW 세계 (email, HTML, FTP등) 에 적응하기 좋은 많은 기능을 제공한다.

Python은 개발환경과 코드 배포에 있어서 다른 철학을 갖는다. Smalltalk이 환경과 사용자 프로그램을 포함하는 통일된 '시스템 이미지'를 갖는데 반해, Python은 표준 모듈과 사용자 모듈을 다른 파일에 저장하여 쉽게 재배열되고 시스템 밖으로 배포될 수 있다. 한 결과를 예를 들면, GUI가 시스템 안에서 설계된 것이 아니므로, GUI를 붙이기 위한 한가지 이상의 선택이 Python 프로그램에 있다.

C++

Java에 대해서 이야기 한 대부분이 C++에도 적용된다. Python코드가 Java 코드보다 3-5배 짧으며, C++코드에 비해 5-10배 짧다!!  일 예로 한명의 Python 프로그래머는 C++프로그래머 두 명이 1년에 끝낼 수 없는 일을 두달만에 끝낼 수 있다. Python은 C++로 쓰여진 코드를 사용하는 접착 언어로 빛을 발한다.

Common Lisp and Scheme

이들 언어는 동적인 의미해석에서 Python에 가깝다. 그러나 구문해석 접근은 너무 달라서 매우 심한 논쟁거리가 될 만한 비교가 된다: Lisp의 구문적인 부족함이 장점일까 단점일까?  Python은 Lisp과 같은 내성적인 능력(capabilities)이 있고, Python 프로그램은 아주 쉽게 프로그램 부분을 구성해서 실행할 수 있다는 것을 밝혀야겠다. 일반적으로, 실세계 실체가 결정적이다: Common Lisp은 크다(어떠한 관점에서도 그렇다). Scheme 세계는 많은 어울리지 않는 버전들로 나누어져있다. 그에 반해서 Python은 하나이고, 무료이고, 작게 구현되었다. 더 자세한 Scheme와의 비교에 관해선 Moshe Zadka가 쓴 Python vs. Scheme을 보라.

 

 

1. 일반적인 정보와 쓰임새

1.1. 파이썬이 무엇인가요?

파이썬은 인터프리터이며, 상호대화적이고, 객체-지향적인 프로그래밍 언어입니다. 파이썬에는 모듈, 예외, 동적인 형정의, 대단히 고 수준의 동적인 데이타 형, 그리고 클래스가 구현되어 있읍니다. 파이썬에는 놀라운 힘이 대단히 명료한 구문에 결합되어 있습니다. 파이썬은 수 많은 시스템 호출과 라이브러리에 대한 인터페이스를 가지고 있습니다, 뿐만 아니라 다양한 윈도우 시스템에 대한 인터페이스도 있으며, C 또는 C++로 확장도 가능합니다. 또한 프로그래밍 인터페이스가 필요한 어플리케이션들을 위한 확장 언어로도 사용할 수 있습니다. 마지막으로, 파이썬은 이식성이 풍부합니다: 수 많은 종류의 유닉스와, 맥에서 실행되며 도스, 윈도우, NT, 그리고 OS/2 환경의 개인용 컴퓨터에서도 실행됩니다.

더 알고 싶으시면, 가장 좋은 방법은 문서 모음속에 있는 지침서를 읽기 시작하는 것입니다 (아래에 있는 질문들을 참조하세요).

질문 1.17 (파이썬은 무엇에 유용한가요)를 참조하시길.


1.2. 왜 파이썬이라고 불리나요?

컴퓨터 과학자는 전혀 아니지만, 저도 "Monty Python's Flying Circus"를 좋아합니다 (혹시 -- 그렇지는 않겠지만 -- 모르시는 분을 위해, 70년대부터 시작된 BBC의 코메디 연속극이랍니다.). 어느날 갑자기 짧은, 특이한, 그리고 약간은 신비스런 그런 이름이 필요하다는 생각이 들었습니다. 마침 저는 그 연속극의 대본을 읽고 있었는데... 바로 그 때 나의 언어를 파이썬으로 부르기로 결정한 겁니다.

지금까지 여러분이 파이썬의 로고로 왕뱀을 사용하든, 왕쥐를 사용하든 신경쓰지 않고 있습니다!


1.3. 어떻게 파이썬 소스의 복사본을 얻나요?

최신의 파이썬 소스 배포는 항상 python.org http://www.python.org/download에서 얻을 수 있습니다. 최신의 개발 소스는 소스포지, http://python.sourceforge.net/에 있는 익명의 CVS에서 얻을 수 있습니다.

완전한 C 소스를 담고 있는 gzip으로 압축된 tar 파일, LaTeX 문서, 파이썬 라이브러리 모듈, 예제 프로그램, 그리고 자유롭게 배포될 수 있는 약간의 유용한 소프트웨어가 있습니다. 이것은 대부분의 유닉스 플랫폼에서 컴파일되고 실행될 겁니다. (비-유닉스에 관한 정보를 위해서는 섹션 7 을 참조하세요.)

파이썬의 구버전, 파이썬 1.6과 1.5.2를 포함하여, 또한 python.org에서 구할 수 있습니다.


1.4. 파이썬에 관한 문서를 어떻게 얻나요?

모든 문서는 온-라인으로 이용가능합니다, http://www.python.org/doc/에서 시작하세요.

그 문서의 LaTeX 소스는 소스배포본에 포함되어 있습니다. LaTeX가 없으시면, 최신의 파이썬 문서 모음은, 익명 ftp 를 통하여, 포스트스크립트와 HTML과 같은 다양한 포맷으로 얻을 수 있습니다 - 현재 버전에 연결된 위의 URL을 방문하세요.

파이썬을 고-수준으로 설명해주는 포스트 스크립트는 nluug-paper.ps속에 있습니다 (위의 ftp 사이트에서 별개의 파일로 존재합니다).


1.5. 파이썬의 배포를 미러하는 다른 ftp 사이트들이 있나요?

다음의 익명 ftp 사이트들이 파이썬의 배포를 미러하고 있습니다:

미국:

        ftp://ftp.python.org/pub/python/
ftp://gatekeeper.dec.com/pub/plan/python/
ftp://ftp.uu.net/languages/python/
ftp://ftp.wustl.edu/graphics/graphics/sgi-stuff/python/
ftp://ftp.sterling.com/programming/languages/python/
ftp://uiarchive.cso.uiuc.edu/pub/lang/python/
ftp://ftp.pht.com/mirrors/python/python/
ftp://ftp.cdrom.com/pub/python/

유럽:

        ftp://ftp.cwi.nl/pub/python/
ftp://ftp.funet.fi/pub/languages/python/
ftp://ftp.sunet.se/pub/lang/python/
ftp://unix.hensa.ac.uk/mirrors/uunet/languages/python/
ftp://ftp.lip6.fr/pub/python/
ftp://sunsite.cnlab-switch.ch/mirror/python/
ftp://ftp.informatik.tu-muenchen.de/pub/comp/programming/languages/python/

호주:

        ftp://ftp.dstc.edu.au/pub/python/

1.6. 파이썬에 공헌하는 뉴스그룹이나 메일링 리스트가 있나요?

뉴스그룹, comp.lang.python과 그리고 메일링 리스트가 있습니다. 뉴스그룹과 메일링 리스트는 서로간에 열려 있습니다 -- 뉴스를 읽을 수가 있으면 그 메일링 리스트에 가입하는 것은 불필요합니다. 메일링 리스트에 가입하기 위해서는 (python-list@python.org) 메일맨 웹페이지 http://www.python.org/mailman/listinfo/python-list를 방문하세요

뉴스그룹과 메일링리스트에 관하여 더 자세히 알고 싶거나, 다른 리스트에 대해 더 알고 싶으시면 http://www.python.org/psa/MailingLists.html에서 찾아 보실 수 있습니다.

뉴스그룹의 문서고는 데자 뉴스가 관리하고 있으며 "파이썬 뉴스그룹 탐색", http://www.python.org/search/search_news.html 웹 페이지에서 보실 수 있습니다. 이 페이지에는 다른 문서 모음집에로의 연결점도 있습니다.


1.7. 파이썬에 공헌하는 WWW 페이지가 있나요?

물론입니다, http://www.python.org/는 공식적인 파이썬 홈페이지입니다.


1.8. 파이썬 문서를 WWW상에서 이용가능한가요?

네. 파이썬 2.0 문서는 http://www.pythonlabs.com/tech/python2.0/doc/ 그리고 http://www.python.org/doc/에서 사용가능합니다. 대부분의 문서가 온라인으로도 보실 수 있고 내려 받을 수도 있습니다.


1.9. 파이썬에 관한 책들이 있을까요?

네, 많고 많은 책들이 출판되고 있습니다. 리스트를 보시려면 http://www.python.org/psa/bookstore를 참조하세요.

온라인 서점을 탐색해서 "Python"을 찾을 수도 있습니다 ( Monty Python 참조를 걸러내시거나; 또는 "Python"과 "language"로 탐색해야겠지요).


1.10. 파이썬에 관하여 제가 읽을 만한 출판된 글들이 있습니까?

웹 사이트를 참조하실 수 없다면, 그리고 그 책들을 참조하기를 원하지 않는다면 (앞의 질문을 보세요), 참조하실 수 있는 파이썬에 관한 몇 개의 사설들이 있습니다.

파이썬에 관한 대부분의 출판물은 파이썬 웹사이트에 모여 있습니다:

Publications.html

이 사설들은 대단히 오래 되었으므로 파이썬의 저자는 그것을 더이상 참조하도록 권장하지 않습니다:

    Guido van Rossum and Jelke de Boer, "파이썬 프로그래밍 언어로 상호대화적으로
원격 서버를 점검하기", CWI Quarterly, Volume
4, Issue 4 (December 1991), Amsterdam, pp 283-303.

1.11. 파이썬에 관한 짧은 소개문이나 이야기가 있나요?

몇개가 있습니다 - Hints.html#intros에서 링크를 찾아보실수 있습니다.


1.12. 파이썬 버전 매기기 전략은 어떻게 작동하는가요?

파이썬 버전은 A.B.C 또는 A.B. 로 매겨지고 있는데 A는 가장 큰 버전 번호입니다 -- 기능이나 소스 구조에 중요한 변화가 있을 때만 증가됩니다. B는 작은 버전 번호입니다, 배포본에 지구를-뽀갤만한 변화가 없는 경우에만 증가합니다. C 는 패치수준입니다 -- 새로운 패치가 적용될 때마다 증가합니다. 모든 배포본이 패치 배포본을 가지는 것은 아닙니다. 주목할 것은 과거에는, 패치가 중요한 변화를 의미하였다는 것입니다; 사실 0.9.9에서 1.0.0으로 바꾼다는 것은 처음으로 A 또는 B가 변경되었다는 것을 뜻합니다!

알파, 베타 그리고 배포 후보 버전은 부가적인 접미사를 가집니다. 알파 버전을 위한 접미사는 "aN"으로 한자리 수 N을 가지며, 베타 버전을 위한 접미사는 "bN"으로 한자리 수 N을 가지고, 그리고 후보 배포본을 위한 접미사는 "cN"으로 한자리 수 N을 가집니다.

(예를 들어) 2.0aN으로 라벨이 붙은 모든 버전은 2.0bN으로 라벨이 붙은 버전에 앞서고, 이 버전은 2.0cN으로 라벨이 붙은 버전보다 앞섭니다, 그리고 그 모든 것들은 2.0.의 이전 버전입니다.

일반적으로, 배포 후보본과 최종 배포본 사이에는 눈에보이는 버그가 없는한 변경되지 않습니다.


1.13. 파이썬의 베타 테스트 버전을 어떻게 얻나요?

알파, 베타, 그리고 배포후보본을 포함한 모든 배포본은 comp.lang.python 그리고 comp.lang.python.announce 뉴스그룹에 공표됩니다, 둘다 python-list@python.org 그리고 python-announce@python.org에 열려 있습니다. 게다가, 이러한 모든 공표는 파이썬 홈 페이지,http://www.python.org/에도 발표됩니다.


1.14. 파이썬을 사용하는데 저작권 제한이 있나요?

전혀요. 여러분은 원하시는대로 소스에 무엇이든 할 수 있습니다, 물론 여러분이 만드신 파이썬에 관한 모든 문서에 그러한 저작권을 보여주거나, 남겨 두셔야겠지요. 또, 저자의 법인 이름을 문서로 먼저 허가 받지 않았다면 사용하지 마세요, 그리고 어떠한 것에도 책임을 남기지 마세요 (정확한 법적인 어의를 아시려면 실제 저작권을 읽어보세요).

특히나, 저작권 규약을 존중하신다면, 파이썬을 상용으로 사용하셔도 좋습니다, 파이썬을 소스나 이진파일형태로 파시거나, 파이썬의 힘을 개선하는 제품을 파시거나, 또는 어떤 형태로든지 파이썬을 (혹은 한부분으로서) 구현하셔도 좋습니다. 저 역시 파이썬을 상업적 용도로 사용하는 것에 관하여 알고 싶습니다!


1.15. 파이썬은 왜 처음에 만들어졌나요?

제가 시작하게된 이유를 아주 짧게 요약하겠습니다:

나는 CWI의 ABC 그룹에서 인터프리터 언어를 구현하는 일에 아주 광범위한 경험이 있었습니다 , 이 그룹과 일하면서 언어 디자인에 관하여 많은 것을 배웠습니다. 여기에서 파이썬의 많은 기능들이 유래했는데, 서술문을 그룹화하기 위해 들여쓰기를 사용하고 대단히-고-수준의 데이타 형이 포함되었습니다 (파이썬에서 세부사항은 전혀 다르기는 하지만 말이지요).

나는 ABC 언어에 관하여 많은 것을 알게 되었습니다, 또한 그 사양의 많은 부분을 좋아하였습니다. 그러나 나의 불만을 없애기 위하여 ABC 언어를 확장하는 것은(또는 그의 구현으로) 불가능 하였습니다. -- 사실 확장성이 없다는 점은 그 언어의 가장 큰 문제였습니다. 나는 Modula-2+를 사용한 경험이 약간 있었고 Modula-3의 디자이너와 대화를 하였습니다 (M3 보고서를 읽어보세요). 예외, 그리고 파이썬의 다른 약간의 사양들에 사용되어진 구문과 의미론은 M3에서 기원하였습니다.

나는 CWI의 아메바 분산 처리 시스템 그룹에서 일하고 있었습니다. 우리는 C 프로그램 또는 본쉘 스크립트를 작성하여 관리하는 것보다 시스템 관리를 하기 위한 더 좋은 방법이 필요했습니다, 아메바는 자신만의 시스템 호출 인터페이스를 가지고 있어서 본쉘로는 쉽게 접근이 힘들었기 때문이었습니다. 아메바에서 에러 처리를 한 경험으로 나는 프로그래밍 언어의 사양으로서 예외의 중요성을 첨예하게 인식하였습니다.

ABC와 같은 구문에 아메바 시스템 호출에 대한 접근을 가진 스크립트 언어라면 요구를 만족시킬 수 있으리라는 생각이 들었습니다. 아메바-특유의 언어를 작성하는 것은 바보 같은 것이라는 것을 깨닫았습니다, 그래서 나는 일반적인 확장성이 있는 언어가 필요하다고 결정하였습니다.

1989년 크리스마스 휴일 동안에, 시간이 많이 남아돌아서, 한번 시도해보기로 결정했습니다. 그 다음해 동안에, 여전히 나의 대부분의 시간을 거기에 쏟고 있었고, 파이썬은 점점 더 성공적으로 아메바 프로젝트에 사용되었습니다, 그리고 동료들의 조언 덕분에 나는 초기에 많은 개선들을 할 수 있었습니다.

1991 년 2 월, 거의 1 년의 개발기간이 끝난후에, 나는 USENET에 올리기로 결정하였습니다. 나머지 이야기는 Misc/HISTORY 파일에 계속됩니다.


1.16. 제가 "Monty Python'의 날으는 서커스"를 좋아해야 합니까?

아니요, 그렇지만 도움은 되겠지요. 파이쏘니타스는 자주 SPAM을 보기를 좋아합니다, 그리고 물론, 아무도 그 스페인 질문록(Spanish Inquisition)을 즐기지는 않습니다.

파이썬을 사용하는 중요한 두 가지 이유는:

 - 이식성이 풍부하다
- 배우기 쉽다

파이썬을 사용하는 세개의 중요한 이유를 들라면:

 - 이식성이 풍부하다
- 배우기 쉽다
- 강력한 표준 라이브러리

(그리고 멋진 빨간색 유니폼.)

그리고 기억하세요, 6번째 규칙은 절대로 없답니다.


1.17. 파이썬은 무엇에 유용한가요?

파이썬은 많은 상황에 사용됩니다. 엄청난 동적처리, 사용용이성, 힘, 그리고 유연성이 요구되는 곳에 사용됩니다.

기본적인 텍스트 처리의 영역에서 (비핵심적인 확장을 가지지 않은) 핵심 파이썬은 사용하기 더 쉽고 다른 어떤 언어와 거의 마찬가지로 빠릅니다, 그리고 이것때문에 파이썬은 많은 시스템 관리 형태의 작업에 유용합니다. 그리고 텍스트와 문자열 등등을 다루는 CGI 프로그래밍과 다른 어플리케이션의 영역 에도 유용합니다.

표준 확장 (PIL, COM, Numeric, oracledb, kjbuckets, tkinter, win32api, 등등.) 또는 (SWIG과 같은 도움 도구를 사용하시거나, 혹은 ILU/CORBA 또는 COM과 같은 객체 프로토콜을 사용하셔서, 여러분이 작성하신) 특수한 목적의 확장이 추가되면 파이썬은 대단히 편리한 "접착제" 또는 "조종간" 언어가 되어서 관련이 없는 소프트웨어 패키지들의 이질적인 모음을 작동시키는 것을 도와 줍니다. 예를 들어 Numeric을 oracledb와 결합함으로써 여러분은 SQL 데이타베이스가 통계분석을 하도록 도울 수 있거나, 심지어는 푸리에 변환까지도 도울 수 있습니다. 파이썬을 "접착제 언어"로서 특출나도록 하는 사양중의 하나는 파이썬의 단순하고, 유용하며, 그리고 강력한 C언어 실행시간 API입니다.

많은 개발자들은 또한 그래픽 사용자 인터페이스 개발 도움자로서 파이썬을 광범위하게 사용합니다.


1.18. FAQ 마법사 소프트웨어를 사용하여 나 자신만의 FAQ를 유지할 수 있나요?

물론입니다. 버전 1.0은 파이썬 1.5의 소스 배포본의 Tools 하부디렉토리에 배포됩니다

  http://www.python.org/ftp/python/src/py152.tgz

1.19. 어느 편집기가 파이썬 소스 코드를 편집하는 것을 훌륭하게 지원하나요?

유닉스에서는, 첫번째 선택은 Emacs/XEmacs입니다. 파이썬 코드를 편집하기 위한 정교한 모드가 있습니다, 파이썬 소스 배포 (Misc/python-mode.el)에서 구할 수 있습니다. 또한 XEmacs에 함께 묶여 있습니다 (우리는 여전히 FSF Emacs에 함께 묶을 수 있도록 하기 위한 법적인 세부사항 검토를 하고 있습니다). 웹 페이지를 가지고 있습니다:

    http://www.python.org/emacs/python-mode/index.html

유닉스, 윈도우 또는 매킨토시를 위한 많은 선택사항들이 있습니다. 리차드 존스(Richard Jones)씨가 파이썬 뉴스그룹에 올라온 글들로부터 표를 편집하여 놓았군요:

http://www.bofh.asn.au/~richard/editors.html

윈도우와 맥을 위해서는 FAQ 질문 7.10을 참조하세요.


1.20. 나는 이전에 프로그램 해 본 적이 없어요. 파이썬 지도서가 있나요?

몇 개가 있습니다, 그리고 적어도 한 개는 책입니다. 이제 시작하는 파이썬 프로그래머들을 위한 모든 정보는 여기에 모여 있습니다:

    Newbies.html

1.21. 도데체 www.python.org 은 어디에 위치하는가?

지금 현재는 암스텔담에 있습니다, XS4ALL의 배려하에 지원되고 있습니다:

    http://www.xs4all.nl/

이것을 준비해준 토마스 워터스(Thomas Wouters)에게 감사드립니다!!!!

Posted by aspirinirony
web2.0[Cityzon]2007. 10. 29. 12:50
한/글 2005 업데이트 파일(한/글 버전 6.5.3.858)
다운로드


 [한/글 2005] 업데이트 후 런타임 오류가 발생합니다.

 [해결방법]

아래와 같이 런타임 오류 나오는 경우 (빌드 버전 973, 989)는 아래 4가지 해결책이 있습니다.



해결책 1

[시작]->[프로그램 또는 모든 프로그램]->[한글과컴퓨터]->[한글2005 또는 한컴 오피스 2005] -> [한글 2005 기본 설정]을 실행하여 한글 2005를 처음 실행 상태로 되돌린다.


해결책 2
1. 바탕화면에서 마우스 오른쪽 버튼을 클릭합니다. . 그리고 새로 만들기를 클릭하여 한글 문서를 선택합니다.


2.바탕화면에  새 한글 문서 아이콘()이 나오면 이 아이콘을 더블 클릭합니다. . (또는 그냥 한글 문서 아이콘을 클릭합니다 .)


해결책 3

1.[시작]->[실행]->regedit 라고 입력 후 엔터를 누릅니다.


2.창이 나타나면 Hkey_Current_User\Software\Hnc\HwpUserAction\Modules 의  "ubiTUBE" 값 삭제 합니다.

※이 경우 한글에서 Ubitube 아이콘이 사라집니다 . (영문 버전 OS에 한글 설치시는 위의 경로가 없음)

 

 

해결책 4

1. [시작]-[실행]을 통해 "command"를 입력한 후 "확인"을 합니다.

2. 다음 그림처럼 한/글 2005 설치된 경로로 들어가서 "hwp /Register"라고 입력 후 enter를 누르세요.

 

Posted by aspirinirony
web2.0[Cityzon]2007. 10. 25. 09:42

RAID[레이드]는 중요한 데이터를 가지고 있는 서버에 주로 사용되며, 여러 대의 하드디스크가 있을 때 동일한 데이터를 다른 위치에 중복해서 저장하는 방법이다. 데이터를 여러 대의 디스크에 저장함에 따라 입출력 작업이 균형을 이루며 겹치게 되어 전체적인 성능이 개선된다. 여러 대의 디스크는 MTBF를 증가시키기 때문에 데이터를 중복해서 저장하면 고장에 대비하는 능력도 향상된다.

하나의 RAID는 운영체계에게 논리적으로는 하나의 하드디스크로 인식된다. RAID는 스트라이핑 기술을 채용하여 각 드라이브의 저장공간을 1 섹터(512 바이트)의 크기에서부터 수 MB에 이르는 공간까지 다양한 범위로 파티션할 수 있다. 모든 디스크의 스트라이프는 인터리브되어 있으며, 차례대로 어드레싱된다.

의료 및 기타 과학분야의 사진 등 대형 레코드가 저장된 단일 사용자용 시스템에서, 스트라이프는 으레 512 바이트 정도의 적은 량으로 설정되는데, 이를 통하여 하나의 레코드가 모든 디스크들에 걸쳐있게 되고, 또 모든 디스크를 동시에 읽음으로써 빠르게 접근할 수 있게된다.

다중 사용자시스템에서는 최대크기의 레코드를 넣을 수 있을 정도로 충분히 넓은 스트라이프를 확보함으로써 더 나은 성능을 발휘하게 되는데, 이는 드라이브간의 디스크 입출력을 중첩시켜준다.

 

RAID에는 중복되지 않는 어레이인 RAID-0를 제외하더라도, 9가지 형태가 더 있다.


  • RAID-0 : 이 방식은 스트라이프를 가지고는 있지만 데이터를 중복해서 기록하지 않는다. 따라서, 가장 높은 성능을 기대할 수 있지만, 고장대비 능력이 전혀 없으므로 이 방식은 진정한 RAID라고 하기 어렵다.
  • RAID-1 : 이 형식은 흔히 디스크 미러링이라고도 하는데, 중복 저장된 데이터를 가진 적어도 두 개의 드라이브로 구성된다. 스트라이프는 없으며, 각 드라이브를 동시에 읽을 수 있으므로 읽기 성능은 향상된다. 쓰기 성능은 단일 디스크 드라이브의 경우와 정확히 같다. RAID-1은 다중 사용자 시스템에서 최고의 성능과 최고의 고장대비 능력을 발휘한다.
  • RAID-2 : 이 형식은 디스크들간에 스트라이프를 사용하며, 몇몇 디스크들은 에러를 감지하고 수정하는데 사용되는 ECC 정보가 저장되어 있다. 이 방식은 RAID-3에 비해 장점이 없다.
  • RAID-3 : 이 형식은 스트라이프를 사용하며, 패리티 정보를 저장하기 위해 별도의 드라이브 한 개를 쓴다. 내장된 ECC 정보가 에러를 감지하는데 사용된다. 데이터 복구는 다른 드라이브에 기록된 정보의 XOR를 계산하여 수행된다. 입출력 작업이 동시에 모든 드라이브에 대해 이루어지므로, RAID-3은 입출력을 겹치게 할 수 없다. 이런 이유로 RAID-3는 대형 레코드가 많이 사용되는 업무에서 단일 사용자시스템에 적합하다.
  • RAID-4 : 이 형식은 대형 스트라이프를 사용하며, 이는 사용자가 어떤 단일 드라이브로부터라도 레코드를 읽을 수 있다는 것을 의미한다. 이것은 데이터를 읽을 때 중첩 입출력의 장점을 취할 수 있도록 한다. 모든 쓰기 작업은 패리티 드라이브를 갱신해야하므로, 입출력의 중첩은 불가능하다. RAID-4는 RAID-5에 비해 장점이 없다.
  • RAID-5 : 이 형식은 회전식 패리티 어레이를 포함한다. 그러므로 RAID-4에서의 쓰기 제한을 주소 지정한다. 그러므로 모든 읽기/쓰기 동작은 중첩될 수 있다. RAID-5는 패리티 정보를 저장하지만 데이터를 중복저장하지는 않는다 (그러나 패리티 정보는 데이터를 재구성하는데 사용될 수 있다). RAID-5는 보통 3 ~ 5개의 디스크를 어레이로 요구한다. RAID-5는 성능이 그리 중요하지 않고 쓰기 작업이 많지 않은 다중 사용자시스템에 적합하다.
  • RAID-6 : 이 형식은 RAID-5와 비슷하지만, 다른 드라이브들 간에 분포되어 있는 2차 패리티 구성을 포함함으로써 매우 높은 고장대비 능력을 제공한다. 현재로서는 RAID-6의 상용 모델은 거의 없다.
  • RAID-7 : 이 형식은 컨트롤러로서 내장되어 있는 실시간 운영체계를 사용하며, 속도가 빠른 버스를 통한 캐시, 독자적인 컴퓨터의 여러 가지 특성들을 포함하고 있다. 현재 단 하나의 업체만이 이 시스템을 제공한다.
  • RAID-10 : 이 형식은 각 스트라이프는 RAID-1 드라이브 어레이인 스트라이프 어레이를 제공한다. 이 방식은 RAID-1보다 높은 성능을 제공하지만, 값이 더 비싸다.
  • RAID-53 : 이 형식은 각 스트라이프는 RAID-3 디스크 에레이인 스트라이프 어레이를 제공한다. 이 방식은 RAID-3보다 높은 성능을 제공하지만, 값이 더 비싸다.

Advanced Computer & Network Corporation에서 RAID의 개념을 쉽게 잡을 수 있도록 그림을 잘 그려놓았습니다. 방문해 보시기를 권합니다.

'web2.0[Cityzon]' 카테고리의 다른 글

File_NO.1] Python.  (0) 2007.12.28
한/글 2005 업데이트 파일(한/글 버전 6.5.3.858)  (0) 2007.10.29
영어문장 프로그램 SendIC  (0) 2007.10.16
IP충돌시 상대찾기  (0) 2007.08.20
한글 Execl 2003 Viewer  (0) 2007.08.14
Posted by aspirinirony
web2.0[Cityzon]2007. 10. 16. 10:40

영어를 공부해야 할 일이 생겼다.

그것도 문장알고 말해야한다..
어떻게 해야할지 모르다.

지인의 추천으로 하나의 프로그램을 알게 되었다..

SendIC

링크만 달겠다..
그곳에 가면  부과 설명이 다되어 있으니 뭐..

url : http://sendic.net/sendic.htm


Posted by aspirinirony
web2.0[Cityzon]2007. 8. 20. 11:34
LAN환경에서 같이 작업하다보면 가끔 새로 정책을 따르지 않은 pc로 인해
어느날 갑자기 IP가 충돌하여 인터넷이 안되는 경우가 많습니다.
이때는 시작 > 프로그램 > 보조프로그램 > 명령프롬프트 를 실행하세요.
nbtstat -A 192.168.1.1(충돌하는 IP)라고 입력하신 후 엔터를 치세요.

그러면 이미 쓰고 있는 pc의 사용자이름과 작업그룹이 아래와 같이보여집니다.
사용자 삽입 이미지

이제 CHO가 누구야? 하고 사무실을 한바퀴 돌면 그 사람이 나타나십니다. ^^
 
Posted by aspirinirony
web2.0[Cityzon]2007. 8. 14. 10:49
Posted by aspirinirony
web2.0[Cityzon]2007. 8. 13. 12:49

세계의 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 파일들을 사용한다. 이렇게 하면 코드 구조가 간단해지고 나중에 유지 보수하기도 쉬워진다. 가능한 모듈과 오브젝트라는 관점에서 생각하라.

Posted by aspirinirony
web2.0[Cityzon]2007. 8. 9. 23:08

웹2.0 새로운 등장과 그 의미

By 김중태 김중태문화원 원장 (www.dal.co.kr)

 

미래의 웹은 시맨틱웹이며, 웹2.0은 시맨틱웹을 경제적 관점에서 본 말이다.

시맨틱웹이 보급되려는 시점에 웹2.0이라는 말이 나와 혼란을 주고 있다. 결론부터 내리자면 W3C나 팀 버너스 리가 제시하고 있는 차세대웹(NGWeb = Next Generation Web)은 1998년부터 확정되어 전개되고 있는 시맨틱웹이다.

웹2.0(Web 2.0)은 초창기 웹을 1.0이라 생각하고 다음 세대 웹을 2.0으로 구분한 것인데, 이 낱말은 경제적 관점에서 만들어졌다. 시맨틱웹이 RSS 등을 통해 점차 구현되기 시작하자 오라일리(O'Reilly Media, www.oreilly.com)는 2004년 10월 5일부터 일주일 동안 미국 샌프란시스코에서 '웹2.0컨퍼런스(www.web2con.com)'를 개최한다. 이때부터 퍼진 웹2.0 용어는 시맨틱웹의 다른 낱말로 이해되고 있다. 하지만 일부 사람은 이미 시맨틱웹이라는 낱말이 있는데 별도의 웹2.0이라는 낱말을 만든 것이나, 차세대웹(Next Generation Web) 용어가 일개 회사의 전략에 따라 경제적인 관점으로 흘러가는 방향을 탐탁치 않게 생각하고 있다.

웹2.0 컨퍼런스 홈페이지(www.web2con.com)



웹2.0은 아직 개념이 정립되지 않은 상황이라 사람마다 조금씩 정의가 다르다.

"플랫폼이 기반 환경이 되는 웹 - Richard MacManus" "컴퓨터에게 유용한 웹 - Jeff Bezos" 등과 같이 사람마다 조금씩 다르며 받아들이는 사람마다 그 해석이 다르다. 위키피디어에서는 '더블클릭은 웹1.0이고, 구글 애드센스는 웹2.0'이라는 재미있는 표현이 있다. 이 비유는 정확하지는 않지만 웹2.0의 특징이 무엇인지 눈치챌 수 있게 해준다. 사람이 광고를 눌러서 자기가 관심 가지는 광고를 찾아가면 웹 1.0이고, 컴퓨터가 알아서 구독자가 관심 가지는 광고를 제공하면 웹2.0이라는 뜻이다.

따라서 기본적으로 웹2.0과 시맨틱웹은 목적지가 거의 동일하다. 다만 시맨틱웹이 목적지를 향한 기술에 관심을 두고 있다면 웹2.0은 시맨틱웹의 기술을 어떻게 응용하여 경제와 인간생활에 적용시킬 것인가에 관심을 두고 있다는 정도의 차이가 있다. 웹2.0 컨퍼런스의 주요 내용을 보면 '웹 2.은0 개발 환경이며 웹사이트는 사용자가 불러서 사용하는 소프트웨어다. 따라서 소프트웨어의 업그레이드 사이클이 존재하지 않는다. 웹은 늘 최신의 것을 제공하기 때문이다.'라고 표현하고 있다. 이런 표현을 보면 웹을 서비스적인 관점과 경제적 관점에서 보는 웹2.0 지지자의 논리가 잘 나타난다.

응용 관점의 웹2.0이므로 결국 플랫폼에 관심을 가질 수밖에 없다. 웹2.0 컨퍼런스에서도 이런 부분이 집중적으로 논의되었다. 휴대전화에서 친구가 보낸 이메일을 보고 전자렌지나 냉장고 화면에 '오늘의 추천요리'가 표시되는 이유는 이들 기기가 웹이라는 플랫폼에 기반을 하고 있기 때문이다. 이처럼 웹이 플랫폼으로 가전과 모바일기기에 들어갈 경우 우리의 일상은 웹과 연결되어 더욱 자동화되고 편리해질 것이다. 이것을 바로 웹2.0이라고 보는 것이다.


웹2.0은 기계의 노동력으로 움직이며 사람을 위한 웹이다.

그러나 확고한 개념과 목표, 발전과정과 이에 필요한 기술, 뼈대와 구조까지 제시된 시맨틱웹과 달리 웹2.0은 매우 추상적이며 모호하다. 웹2.0을 주장하는 사람은 이전의 웹보다 발전된 것이 웹2.0이라고만 말할 뿐, 웹2.0의 기술이 무엇이고 어떤 기술이 적용되어야 하는지, 웹2.0의 목표는 무엇인지 제시하지 못하고 있다. 단적인 예로 다들 플랫폼 기반의 웹2.0을 말하지만 아직 웹2.0의 구조가 어떤 식으로 구성되고 있는지조차 제시하지 못하고 있다. 어떤 플랫폼이 어떤 식으로 역할을 하면서 웹2.0을 구성하고 있으며 그런 플랫폼의 종착지가 어디인지는 막연하다. 좀더 제대로 말하자면 시맨틱웹 논의로 개발된 기술을 이용해 좀더 멋진 웹생활을 구현하려는 것이 웹2.0 지지자들의 목적인데, 어떻게 하는 것이 좀더 나은 웹인지를 제시하지 못하고 있는 상황이라 할 수 있다. 이런 이유로 이 책에서는 개념이 명확하지 않은 웹2.0이라는 말을 사용하지 않고 시맨틱웹이라는 말로 차세대웹을 다루고 있는 것이다.

그러나 일반인에게는 시맨틱웹이나 웹2.0이나 같은 개념으로 다가갈 것이다. 어차피 지향하는 것이 같고 사용되는 기술이 비슷하기 때문이다. 웹2.0은 시맨틱웹을 경제적 관점이나 플랫폼으로 보고, 응용해 구현된 상태를 표현하는 말인 것이다. 그러므로 웹2.0은 곧 시맨틱웹의 또 다른 이름으로 봐도 무방하다.

WEB 2.0 컨퍼런스에서 제프 베조스(Jeff Bezos, Amazon CEO)는 WEB 1.0은 사람을 위한 인터넷으로, WEB 2.0은 기계를 위한 인터넷으로 표현했다. 그러나 내가 보기에 이 표현은 적합하지 않다. 웹 2.0이야말로 사람을 위한 웹이기 때문이다. 'WEB 1.0이 사람의 노동력으로 움직인 웹이라면 WEB 2.0은 기계의 노동력으로 움직이는 웹이다.'라고 나는 표현한다. 웹2.0은 그동안 사람이 해야 했던 일들을 기계가 자동화처리해주는 웹으로, 사람이 정보처리를 위해 낭비한 시간만큼 정보를 습득하고 공유하는 시간으로 활용할 수 있는 '더욱 인간을 위한 웹'이 될 것이다.


인터넷2.0은 새로운 구조의 인터넷을 뜻하는데, 공식적인 용어가 아니다.

인터넷2.0이라는 낱말은 새로운 인터넷이라는 말로 사용하고 있는데, 일부는 시맨틱웹의 개념을 인터넷2.0이라는 이름으로 사용하고 있고, 일부는 새로운 구조와 시스템에 기반한 더 빠르고 강력한 인터넷을 뜻하는 낱말로 사용하고 있다. 그러니까 인터넷2.0이라는 낱말은 정확한 개념 없이 막연하게 다음 세대 인터넷이라는 뜻으로 사용되고 있는데 시맨틱웹과는 거리가 있다.

정리하자면 차세대 웹이라는 의미로 '웹2.0'을 사용하는 것은 큰 무리가 없으나 컴퓨터끼리 대화하고 자동화된 지능형 웹을 뜻할 때는 '시맨틱웹'으로 표현하는 것이 좀더 정확한 사용법이 될 것이다.

출처:유미디어랩

Posted by aspirinirony
web2.0[Cityzon]2007. 8. 9. 22:59
앞의 굵은 글자 부분만 읽으시면 될듯...;;

1990년대 초 데이브 홀랜더는 CD-롬 브라우저용 마크업 언어를 고안했다. 이 언어는 초기 월드와이드웹과 함께 사용하는 것에 관해 일찍부터 논쟁이 됐지만, 그 당시 홀랜더의 고용주였던 HP는 지적재산권을 엄격하게 제한했다. 그 결과 HTML이 성공했다.


그러나 역사는 순환하기 마련이어서, 10년 후 HTML(Hypertext Markup Language)은 XML에 기반해 HTML을 대용하는 홀랜더의 또 다른 창작품인 XHTML이라는 언어에 그 자리를 내주고 있다.


홀랜더가 전자상거래와 웹서비스 분야의 데이터 집중 작업을 위한 문서 기반 테크놀러지에서 떠난 이후 오랜 시간이 흘렀지만 XML(Extensible Markup Language)에 대한 그의 초창기 작업이 웹을 그가 처음에 웹을 위해 계획했던 것 같은 것, 즉 기계가 더 잘 판독할 수 있는 모델로 되돌려놨다.


뉴욕 발드윈스빌 출신인 홀랜더는 미시간 테크에서 과학 학사 학위로 졸업하기 전까지 트럭 운전같은 임시 직업으로 돈을 충당해 학교를 다녔다. 요즘 그는 콘티보(Contivo)에서 CTO로 일하고 있다.


또한 46살의 홀랜더는 'XML 애플리케이션'의 공동 집필자이며, 'XML 스키마'의 기술 편집자이자, OAGI, 로제타넷, OBI, ECO 프레임워크 등을 포함한 표준화 작업에 조력하고 있다.


그는 W3C(World Wide Web Consortium)의 웹서비스 아키텍처 워킹그룹은 물론 XML 스키마 워킹그룹의 공동 의장이며, W3C의 권고 사항인 'XML에서 네임스페이스'의 공동 저자이다.


홀랜더는 콜로라도 러브랜드에 있는 자신의 집에서 CNet 뉴스닷컴과 데이터 통합과 웹서비스에 관한 그의 생각과 작업에 대해 얘기했다.


XML 개발에서 당신은 어떤 역할을 했는가?


90년대 초반으로 돌아가 보면, 나는 HP에서 CD-ROM에 관해서 (유닉스를 비롯한 여러 가지) 모든 매뉴얼 출판 작업을 관장했다. 이것이 웹의 초기 작업이었다. 그리고 나는 SDL(Semantic Delivery Language)이라는 언어를 개발했는데, 이 언어는 시맨틱 웹에서 할 수 있는 것이 없다!(웃음).


그 당시 SGML 언어가 있었는데 우리는 SGML 언어를 CD-ROM에 사용할 수 없었다. 그래서 SDL이 CD-ROM 브라우저에서 읽혀질 수 있는 매개 언어였는데, 그것이 나에게 하이 레벨 SGML을 컴퓨터에 더 밀접한 것으로 바꿔놓는 좋은 토론거리를 제공했다.


나는 월드와이드웹의 창시자이며 W3C 책임자인 팀 버너스-리를 포함한 내 동료들과 얘기했고, 우리는 그것을 이용해 웹에 접속할 수 있을 것이라고 생각했다. 그 당시 팀은 CERN(유럽핵연구위원회) 환경 내에서 웹의 선봉으로 작업하고 있었다.


팀은 웹에 대한 폭넓은 지원을 얻으며 작업하고 있었지만, 오늘날 우리가 알고 있는 것 같은 웹은 존재하지 않았다. 우리는 심지어 94년 4월까지도 상업적인 트래픽은 생각하지 못했다.


91년 데이븐포트 그룹(Davenport Group)이라는 비공식 단체가 있었지만, 나는 HP로부터 SDL 사용에 대한 (지적 재산권) 허가를 얻을 수 없었다. 그렇게 그들은 HTML 프로젝트를 시작했다. 그리고 우리가 이 문제가 분명해질 때까지 그 프로젝트는 잘 진행됐다.


이제 10년이 지났고, W3C는 HTML에서 XML에 기반한 대안인 XHTML로 옮겨가려 애쓰고 있다. 만약 HP가 IP 인증을 당신에게 줬다면? 우리가 이러한 변화를 겪지 않아도 돼지 않았을까?


아마도 힘은 덜 들었을 것이다. 이것은 일반적으로 커뮤니티가 별도로 정보를 처리하고, 마크업과 메타 데이터의 개념을 이해하기 시작하고, 그리고 컨텐트 뿐만 아니라 데이터에 대한 양상에 대해 관심을 가지기 위해 겪어야 하는 학습 과정이다.


내가 HP닷컴을 만들고 있을 때, 우리에게는 검색 엔진에 필요한 근본적인 메타데이터 세트가 있었다. 그리고 내가 그것을 계약에 추가할 수 있는 매니저가 될 때까지 그들은 페이지가 괜찮아 보이는 한 그것에 대해 걱정하지 않았다. 세계는 웹페이지가 고찰해볼 만하다는 것을 이해하기 시작했지만, 그것을 컴퓨터로 작업하기가 어려웠을 것이다. 사람들은 이제 웹 페이지 고찰의 필요성을 이해한다.


그래서 어떻게 HTML로부터 XML이 나왔는가?


1992년 제2회 W3C 컨퍼런스에서 였다. 그때 나는 내가 시작했던 HP닷컴의 웹마스터였다. 우리는 시카고에 가서 HTML 2.0을 다뤘고, 나는 웹 출판업자로서 적절한 기술을 찾지 못했다. 공항으로 돌아오는 길에 나는 (썬마이크로시스템 기술자인) 존 보삭과 택시를 함께 탔고, SGML보다 더 제한된 어떤 것이 있어야 한다는 데 생각을 같이 했다.


제한된다는 것이 무슨 뜻인가?


그것은 SGML에서는 사용되지 않았던 많은 것, 즉 웹에서 구현될 수 없었던 기능을 가진 깊고 풍부한 스펙을 의미한다. 오늘날 당신은 XML 툴과 파서를 어디서나 찾을 수 있다. SGML의 경우 겨우 3개가 있고, 구입하기에 매우 비쌌다.


우리는 계속 메타 언어를 갖는 아이디어를 가질 수 있기를 원했고, 다른 누군가의 시맨틱을 사용하고 싶지 않았으며, 고유 언어를 개발할 수 있기를 바랬다. SDL이나 HTML보다 더 심오한 더 높은 수준의 것. 몇 개월 내에 존은 함께 일했던 사람들로 팀을 구성했고 우리는 무엇이 XML이 되는 지에 대해 기안을 하기 시작했다.


우리는 우리 스스로 이 작업을 했다. 우리는 몇 개월 동안 토요일 아침마다 만나서 우리의 목표와 원칙을 계획했다.


그후 어떤 일을 했나?


나는 HP에서 커머스넷(CommerceNet)으로 옮겼다. 그들의 헌장에 대한 내 이해는 회사가 어떻게 사업을 하고 어떻게 보안, 임금 표준 등에 관련된 거대한 결함을 보완하는지를 조사하기 위해 회사간의 여백을 탐구하는 것이었다.


나는 카탈로그, 임금 분야에서 많은 일을 하려고 했고, 이런 B2B 트랜잭션 종류의 사업을 하는데 도움이 되는 XML 표준을 규정하기 위해 노력했다. 나에게 그것은 문서와 매뉴얼에 대한 생각을 멈추고 우리가 매일 사업에서 사용하는 툴이 되는 그런 것에 대해 생각하기 시작하는 방법이었다.


그후 나는 커머스넷에서 콘티보로 옮겼다. 도큐먼트든 B2B든 나에게 가장 큰 이슈는 변환이었다.


변환은 무엇을 의미하는가?


그것은 수신인이 정보를 보낸 발송인의 의미를 어떻게 해석하는가를 의미한다. 생각하기 쉬운 예를 하나 들면, 언어의 경우 프랑스어 'rue'를 독일어 'strasse'로 해석하는 것이다. 그 의미를 이해하고 발송인이 의미하는 것을 수신인이 할 필요가 있는 것으로 바꾸면 변환이 된다.


시맨틱은 개념의 의도를 이해하는 것이다. 나는 그것을 데이터와 행동의 경계로 생각하는 것을 좋아한다. 만약 당신이 같은 데이터를 보내고 5개의 다른 답을 얻었다면, 그 데이터에는 관련된 5개의 다른 의미가 있는 것이다.


'rue'를 'strasse'로 변환하기 위해, 나는 이것이 거리라는 것과 거리, 고속도로 혹은 길로 구별된다는 것 같은 기본적인 변환을 이해해야 한다. 의미있는 변환을 위해서는 정보의 의미론을 이해해야 한다.


이 모든 것이 W3C의 시맨틱 웹 활동과 어떤 관련이 있는가?


시맨틱 웹은 약간의 기본적인 기술을 기반으로 하는 연구 프로젝트이다. 만약 당신이 시맨틱 웹 프로젝트에 자금을 투자할 것을 고려하고 있다면, 그것은 주로 입회금이 아닌 연구 보조금을 통해서 투자하게 될 것이다.


기반 기술은 RDF와 DAML이나 OWL같은 온톨로지 언어이다. 그러한 기술은 완성됐거나 증명되지 않았고, 나도 그것들을 상업 제품에 구축하는 방식이 명확하지 않다. 그것으로 연구 프로젝트를 하는 것은 적절하지만, 아직 증명되지 않은 기술에 대한 대량의 계정을 나가서 팔 수는 없다.


시맨틱 웹과 인공 지능 사이에는 어떤 유사점이 있다고 생각하는가?


많은 사람들은 그것을 역사적인 평행선이라고 지적한다. 판정은 여전히 시맨틱 웹 밖에 있기 때문에 나는 그렇게까지 생각할 수 있을지 확실치 않다. 그리고 비록 AI가 불명예를 얻었다 해도 그것은 모든 장소에서 존립할 수 있는 기술로서 나타날 것이다.


비즈니스 인텔리전스, 의학과 임상 분석에서 AI 시스템을 요구하지 않아도 당신은 결정 시스템에서 AI 기술을 사용한다. 그렇지만 개념적으로 AI의 기본은 일종의 지식 나무로 정보를 이해하고 분류하는 방법이다.


KIF는 지식을 구축하는 관계를 묘사하기 위한 프레임워크이며, DAML은 또한 관련된 정보를 저장하기 위한 계층적인 구조이다. 만약 당신이 핀이 날카롭다는 것을 발견한다면 그것은 당신에게 그 정보를 계급내의 어디에 저장하는지를 보여줘서 당신이 나중에 날카로운 물체로서 핀과 못을 연상할 수 있다.


당신은 W3C의 XML 스키마 워킹그룹에 속해 있다. 스키마가 무엇인가?


일반적으로 스키마는 어떤 것이 설계된 패턴으로 구조와 데이터 종류의 형식적인 설명이다. XML 스키마는 DTDs(document type definitions)보다 훨씬 강력한 방법이다. 스키마는 당신이 관계있는 데이터베이스에 있기 때문에 데이터 종류를 매우 정확하게 하는 방법이 있다.


DTD가 어떤 점에서 안좋은가?


DTD로는 0과 100 사이의 날짜나 달러 가치를 설명할 방법이 없다. 모든 것은 문자열이며 당신이 할 수 있는 것은 그 문자열의 존재 여부 확인이 전부이다. 스키마는 또한 정보를 매우 다르게 구성하는 능력을 제공한다. 스키마는 네임스페이스를 지원하기 때문에 나는 DTDs로는 어려웠던 내 문서에 있는 네임스페이스를 적극적으로 사용할 수 있다.


네임스페이스란 무엇인가?

보통 XML 네임스페이스의 공동 작가로서 이 질문에 대답할 때는 길게 논쟁을 하게 된다. 컴퓨팅에서 네임스페이스는 XML에서보다 더 일반적인 개념이다. XML 네임스페이스는 누가 그 태그 세트에 대한 관계자인지 확인하는 방법이다.


그래서 XHTML 2에서, 페이지 중간에 (P)라고 써있는 태그가 있다면 그것이 누구의 단락 태그인가? 누가 컨텐트가 무엇일 수 있다고 말하는가? 네임스페이스를 사용하면 나는 XHTML과 그날의 이상한 언어를 구별할 수 있다. 네임스페이스는 우리가 스키마를 만들기 전까지 완전히 사용할 수 없었던 매우 강력한 툴이다.


우리는 문서의 종류를 설명하기 위해 XML 스키마를 사용한다. 나는 구입 주문이나 내 웹사이트의 연구 페이지를 가리키는 목록이 연결돼 있는 여러 페이지를 설명하기를 원한다. 그래서 나는 내 연구 기록과 도서 목록의 참조를 포착할 스키마를 만들었다.


그것은 모든 종류의 문서를 설명한다. 그것들은 일정한 구조와 예시를 갖고 있다. 나는 내가 데이터와 가지고자 하는 적절한 데이터를 포착한다는 것을 확신할 수 있다. 사업 관계에서 그것은 계약의 기초가 될 수 있다. 만약 당신이 나에게 이러한 압박에 관련된 모든 정보를 보낸다면 우리는 이런 종류의 거래를 하고 그런 것에 대한 출시 통지를 보내는데 있어 법적인 의미를 갖게 된다.


스키마와 웹서비스의 관계는 무엇인가?


매우 흥미로운 질문이다. 이 질문은 웹서비스 커뮤니티가 서로 상충하고 있는 근원에 대한 것이다. 현재 웹서비스 커뮤니티에는 두 개의 당이 있다. EDI, 즉 B2B 트랜잭션과 비슷한 것으로 생각하는 사람들과 시맨틱 웹의 전망으로 스키마를 생각하는 사람들.


웹을 좌우하는 원칙 중 하나는 부분적인 이해이다. 내가 완전히 이해할 수 없는 메시지를 받더라도 여전히 그것을 처리할 수밖에 없다. 사업 즉 상거래에 있어서, 내가 전체 메시지를 이해하지 못하거나 구입 주문서를 보내고 거리 주소나 제품 설명을 이해하지 못한다면, 당신은 최선을 다하지 못할 것이고, 우리가 이해할 때까지 그것을 되돌려보낸다.


당신이 웹에서 자전거에 관한 사이트를 찾아볼 때, 당신은 적당한 페이지로 가서 해결할 문제를 해결할 것이다.


문제는 웹서비스가 상거래 트랜잭션과 같은 역할을 할 것인가, 혹은 이런 것들을 시간보다 빨리 설치하는 방법에 대한 가능성은 없는가와 당신이 정보가 표현되는 방식에 최선을 다할 수 있는가 하는 것이다.


상업과 관련해서 스키마를 생각하는 사람들에게 스키마는 그러한 접촉을 만드는 방법이다. 이 정보를 나에게 보내면 나는 받았다는 통지로 구입 주문서같은 다른 정보 세트로 대답할 것이다. 나에게 주식 시세 요청을 보낸다면, 나는 당신에게 주가 정보를 보낼 것이다.


웹서비스 아키텍처 워킹그룹의 목표와 WS-I(Web Services Interoperability) 조직의 목표 사이에는 어떤 차이가 있는가?


WS-I(나는 회원이 아니다)의 목표는 이 새로운 기술이 상호운영이 가능한 방식으로 나타나는 것을 보증하는 것이다. 그들은 개발자의 표준이 되는 것을 목표로 하지 않는다. W3C의 목표는 업계 실행에 기반한 표준을 개발하는 것과 두번째로 전자통신에 관한 연구를 하는 것이다. 그리고 현재 상호운영이라는 목표를 달성하기 위해 함께 작업할 수 있는 최선의 방법을 찾기 위해 조직 간에 활발한 대화가 이뤄지고 있다.


당신은 MS와 IBM이 맨 처음 만든 WS-I가 W3C의 방식을 가로채려고 한다고 생각하는가?


아무도 없는 곳에 갈등을 만드는 것은 커뮤니티에 전혀 도움이 되지 않는다. 두 그룹이 상호운용성을 성취하기 위해 노력하고 있기 때문에 본래부터 약간의 갈등은 있다.


W3C는 SOAP, WSDL, XML를 통해 기반을 확고히 하고 있고, 웹서비스는 W3C에서 적절한 위치에서 근본적인 토대를 보강하고 있다. 나머지 작업을 하기에 가장 생산적인 장소는 어디인가? W3C는 프로젝트의 목록을 가지고 있다. W3C는 이러한 것을 성공적으로 할 필요는 없지만 이것이 웹 진화의 일부분이라는 것을 알고 있으며, 그 일부가 되기를 원하고 있다.


보안과 트랜잭션 표준중 어디에 비중이 더 있는가? W3C의 작업이 MS와 IBM이 발표한 표준과 어떻게 맞물리는가?


적극적인 교섭에 모든 질문이 있다. XML 디지털 시그니처는 W3C를 통하고 있고, 시그니처는 어떤 보안 표준에도 기초적 요소이다. 아키텍처에서 어디서부터 우리가 선을 그리기 시작해야 하는가? ISO에는 7층의 스택이 있다. 우리는 웹서비스를 위해 하나를 가져야 할 것이다.


다른 그룹이 W3C가 제공하는 것 위에 더 높은 수준의 보안을 구축할 것인가? 우리는 기다려 봐야할 것이다. 그러나 좋은 점은 내가 업계의 모든 사람들로부터 이러한 것이 상호운용이 가능한 방식에서 일어나도록 만드는 것이 얼마나 중요한지에 대해 들은 것이다. 유일한 질문은 성공하기 위해 가장 효과적인 방법은 무엇인가 하는 것이다. 브라우저 전쟁 시대에는 그것은 진실이 아니었다.


W3C가 현재 다루고 있는 RAND(reasonable and nondiscriminatory) 대 사용료 무료라는 지적 재산권 문제에 대해서는 어떻게 생각하는가?


나는 그것이 현재 전체 표준이 직면하고 있는 가장 기본적인 문제라고 생각한다. 지적 재산권에 대해 조사해야할 작업이 많고, 진행 방법에 대해서도 혼란이 많다. 그들이 한 작업에 대한 보답과 공공 영역으로 두는 것 사이에는 미묘한 경계가 있다.


만약 그것이 당신에게 달려있고, 당신이 황제 군주 독재자라면 어떻게 그 문제를 풀겠는가?


나는 배심원처럼 모든 사람을 방에 넣고 그들에게 합의를 끌어낼 때까지 나오지 말라고 말할 것이다. 나는 협정이 어떻게 되든 상관없다.


잠깐, 당신은 정말로 어떤 방식으로 결론이 나든 상관이 없는가?


내가 그렇게 말한 것에는 물론 모든 것이 무료가 되기를 바란다는 것도 포함돼 있다. 그러나 한편으로 나는 무료라는 것은 없다는 것을 안다. 그리고 속도와 과정에 대한 그것의 가격을 고려해 볼 때 나는 아마도 기꺼이 지불할 수 있을 것이다.


XML에 대한 당신의 업적에 대해 보상을 받은 적이 있는가?


없다. 직접적으로는 보상받은 사람은 아무도 없다. 우리는 단지 우리가 고민하던 문제를 풀기 위해 노력했을 뿐이다. XML은 업계에 의해 강요받은 것이 아니었다. 우리는 회사로부터 개인적인 프로젝트 수준으로 지원을 받았다. 우리 그룹은 서로 잘 알고 있는 12명으로 구성됐다.


이제 W3C에는 XML 활동과 관련된 12개 이상의 워킹그룹이 있다. 각 그룹은 50∼70명의 사람들로 운영되고 있다. 모든 회사들이 웹서비스에 미래를 걸고 있다. 이는 우리가 XML 작업을 했던 94, 95년과는 아주 다른 환경이다.
Posted by aspirinirony
web2.0[Cityzon]2007. 8. 6. 15:41
사용자 삽입 이미지

컴퓨터 를 뜯으시면요^^


인터넷을 달때 하얀쪽(4개)에 이상한 칩같은 걸 꼽죠??


그곳이 PCI 입니다


그리고 그위에 컴은색으로 똑같이 꼽는곳이 AGP 입니다^^


PCI - E는 요즘 최신에 나온 메인보드에만 부착되는 거라서


일단 PCI옆에 ㅣ 로 선이 끄어져서 따로 그래픽카드

 

가 나왔습니다.


메인보드도 요즘에 나온거라 많이 가격이 비쌉니다.


그리고 AGP는 메인보드(위사진) 에서 위쪽 하얀색 2개 바로위에 검은색으로 된 곳이


AGP 입니다^^ AGP는 보편화가 되어 사용하기가 지금은 편합니다.


그리고 AGP는 8배속  PCI-E 는 16배속으로 가량2배 정도가 차이납니다


지원하는 슬럿의 방식이 다르져....
 

단순히 생각하면 "PCI-E 제품이 전송방식이 빠른것이니까 더 좋아..."

이렇게 생각할수 있으나,

제품의 모든 스팩을 확인 하시면 꼭집어 어느게 더낳다라고 할수 없습니다.

성능은 둘다 비슷합니다.

전송방식만을 따진다면 PCI-E가 우위지만,   제품스팩중 메모리 부분이 떨어집니다.

당연 가격도 PCI-E보다 AGP제품이 비싸구여...

아직도 AGP를 많이 사용하고 있고, 시장성같은것을 고려할때 비싼건 당연합니다.

그러나 그외 제품의 메모리 부분도 상당한 이유를 가지고 있습니다.


그리고 확인 방법 간단합니다.

바탕화면에서 마우스 오른쪽 버튼을 클릭하셔서 속성에 가신 다음 설정에서 고급을 선택하신후 메뉴 맨 오른쪽에 있는 그래픽카드의 속성에 보시면

AGP는 AGP로 PCI-E는 PCI EXPRESS x16이라고 나와 있습니다~^^


 


일단 AGP는 지포스는 FX버젼 이하에서는 대부분 AGP이구요

라데온의 경우는 9XXX 버젼은 모두 AGP입니다.

PCI-E는 지포스는 6XXX버젼대 이상

(6XXX 버젼에서느 AGP로 나온 모델들이 있습니다)

라데온의 경우는 X(XXX) 버젼 이상의

모델들입니다. (처음 엑스는 지포스의 6과 비슷한 의미입니다)

(라데온에서도 X(XXX) 버젼이 AGP나온 모델이 있습니다.

Posted by aspirinirony
web2.0[Cityzon]2007. 7. 30. 17:29

주요 기능으로는 다양한 파일 포맷 지원 및 썸네일 보기, 슬라이드 쇼, 이미지 편집 기능, 오디오 CD 재생, 캡쳐, 미리 보기, 드랙 & 드랍 지원, 일괄 변환, Command line 옵션, TWAIN 호환 장치 지원, 바탕화면 지정, 플러그 인 지원 등의 기능을 가지고 있습니다.

일부 지원 파일에 대해서는 플러그 인 설치 후 사용이 가능하며 플러그 인 지원이 필요한 파일 목록은 옵션의 Properties를 선택한 후 Extentions 탭에서 "*" 표시된 파일입니다.

다양한 파일 포맷 지원 및 빠른 로딩 속도 그리고 무엇보다 프로그램의 장점은 프리웨어로써 사용에 아무런 제한이 없다는 장점을 지니고 있지만 바탕화면에 경매사이트인 eBay 바로가기 아이콘 및 프로그램 메인 윈도에 eBay-search 버튼이 위치하고 있습니다.




MP3 및 RA, WAV, MOV, AVI, SFF, SWF, LWF, LDF, IMG 등의 파일 포맷을 사용하기 위해서는 플러그 인을 설치하여야 합니다.

tif 변환 포멧을 찾다 발견했음..

Posted by aspirinirony