Minicube.kr - 블로그닷컴 Ver 3.03

21세기가 시작된 지 거의 10년이 다 되어가는 2009년에 이르러 네트워크와 인터넷은 놀라운 발전을 이뤄왔습니다. 웹브라우저 시장은 MS의 XX 같은 Internet Explorer가 독점하는 상황을 벗어나서, 지금은 파이어폭스, 사파리, 오페라, 크롬, ... 기타 등등 수많은 브라우저가 서로 웹표준을 향해 경쟁하는 행복한(?) 시대가 되었지요.

하지만, 이런 상황에서도 웹브라우저가 공식적으로 지원하는 이미지 형식은 아직까지는 GIF, JPG, PNG 세 가지 뿐입니다. (BMP는 논외) 그 중에서 가장 돋보이는 포맷은 바로 PNG 인데요...
하지만, 이전에 작성했던 나를 미치게 하는 PNG 라는 포스트에서도 밝혔듯이.. IE6 의 점유율이 10% 이하로 떨어지지 않는 한, PNG의 혜택을 누리기에는 무리가 있습니다.

이런 상황에서 갑자기 8bit PNG 를 활용하자니... 이게 무슨 소린가 하시겠죠? 저도 그랬습니다. IE6 이 버티고 있는 한, png의 p자도 꺼내지 말아야 할 상황이 아닌가! 라고 반문했지요.

png의 포맷은 두가지가 있습니다. 8bit, 24bit 로 나뉘는데요.

1. 8bit : Pallete PNG
   이미지 내의 색상을 index화 하여 256 칼라를 사용할 수 있다는 GIF 와 비슷한 특성을 가지지만, 동일 이미지의 GIF 파일보다 크기가 작습니다. 그 외의 속성은 png와 같습니다. (Alpha Transparency, No Animated)
2. 24bit : Truecolor PNG
   JPG와 같은 1670만 칼라를 지원하며, JPG와 달리 이미지의 손실(열화)이 없습니다. 그래서 이미지의 크기는 JPG보다 크지만, JPG의 최상퀄리티의 파일 크기에 비하면 오히려 작다고 할 수 있습니다. 그외에 역시 Alpha Transparency를 지원하며 애니메이션은 지원되지 않습니다.

PNG 에 대한 자세한 원전은 다음 URL 에서 얻을 수 있습니다.
영어의 압박이 있기에 저도 중간쯤 보다가 말아버렸습니다만, PNG에 대한 모든것이라고 보시면 되겠습니다. ㅠ_ㅠ
http://www.ietf.org/rfc/rfc2083.txt

여기서 주목할 만한 것은 8bit PNG 이미지입니다. GIF와 성질은 거의 비슷한데 GIF보다 파일 크기가 대체로 더 작습니다. 게다가 IE6 에서도 8bit PNG는 GIF와 비슷한 Transparency 를 지원하고 있습니다. 적어도 24bit PNG 처럼 투명 영역이 회색으로 보이는 문제가 없지요. 그래서 8bit PNG를 GIF를 대체하는 웹이미지로 사용할 수 있지 않을까 하는 것이 발상의 전환이죠. ㅎㅎㅎ



물론 이 발상의 전환은 제가 한 게 아닙니다 -_-;;;

다만 PNG 는 이전 포스트에서도 밝혔듯, 각각의 웹브라우저에서 실제 색상은 다르게 표현될 수 있습니다. 직접적인 원인은 PNG 이미지가 자체적으로 감마값을 가지고 있고, 이 값을 해석하는 브라우저가 상이한 결과를 내기 때문인데요...

PNG 파일의 구조는 8bit의 헤더(png이미지라는 것을 알리는 부분)와 여러 개의 chunk 라는 것으로 구성되어 있습니다.
디카로 사진 좀 찍어보신 분들은 아시겠지만 jpg파일도 이미지뷰어로 보면 각종 정보(카메라기종, 조리개, 셔터, WB 등)가 따로 저장되는 것을 볼 수 있는데요, PNG도 실제 이미지 데이터와 별도로 이러한 정보들이 하나의 조각(chunk)으로 저장된다고 보시면 비슷합니다.
색상의 불일치 문제를 일으키는 것은 바로 gAMA chunk 라는 것인데요, 이 값을 제대로 처리하는 웹브라우저가 있고, 이를 잘못 처리하는 웹브라우저가 있기 때문에 색상차이가 보이게 되는 것이지요.

결국, 모든 웹 브라우저에서 같게 표현되게 하려면 gAMA chunk 를 없애는 과정이 필요합니다. 사실 이 chunk를 제거하는 것은 근본적인 해결책은 아닐 겁니다. 근본적으로 해결하기 위해서는, png의 감마 값을 모든 브라우저에서 제대로 지원하고 JPG나 GIF도 이를 지원해야 한다는 뜻인데..... 어렵겠죠? ^^;;;
그래서 조금 우회하여 png 도 다른 이미지와 마찬가지로 하향평준화 시킨다.. 라고 이해하는 것이 좋을 것 같습니다.

이전 포스트에서 새빛 님께서 TweakPNG 라는 프로그램이 있다고 알려주셔서 이 프로그램을 이용하여 샘플 PNG 파일의 정보를 열어보았습니다.



뭔가 굉장히 많죠? IHDR이 png파일의 헤더이며 나머지 bKGD, sRGB, sBIT, pHYs ... 뭔가 못알아볼 데이터들이 많지만 어쨌든 문제가 되는 chunk는 위에 표시한 gAMA chunk입니다.

여기서 gAMA값을 삭제하는 것 만으로 png파일을 웹에서 정상적으로 표기하게 하는 것이 가능합니다. 드디어 문제 해결! 24bit의 트루컬러 PNG는 어쩔 수 없지만 GIF를 대체하여 8bit PNG 를 활용할 수 있어서 상당히 기쁘죠?! ㅠ_ㅠ

but...

웹사이트의 최적화를 위한 길은 정말 멀고도 멉니다. 여기서 우린 당면한 문제 해결에만 급급하지 않고 PNG 파일 자체의 다이어트를 할 수 없을까 고민해볼 수도 있을 것 같네요.
다행히 방법은 있었습니다. gAMA값 외에도 이미지를 표기하는데에 굳이 필요없는 정보들을 삭제하고 데이터영역을 다시 압축하여 최적화시킬 수 있는 툴이 몇가지 존재합니다.

- pngcrush : http://pmt.sourceforge.net/pngcrush/
- pngrewrite : http://entropymine.com/jason/pngrewrite/
- OptiPNG : http://optipng.sourceforge.net/
- PNGOut : http://advsys.net/ken/utils.htm

이것저것 테스트를 해보았는데요, 첫번째 제시된 pngcrush의 경우 명령프롬프트 상에서 실행해야 하는 불편함이 존재했지만 가장 확실할 것 같아 테스트해보았습니다.

실행 방법은 조금 복잡합니다. 간단히 프롬프트 상에서 pngcrush 라고 입력하면 여러가지 옵션이 나오는데 저도 잘 모르겠습니다. ㅠ_ㅠ 아무튼 레퍼런스 코드가 있어서 다음과 같이 입력해보았습니다.

C:\>pngcrush -rem alla -brute -reduce sample.png sample1.png

위 명령을 실행하니 마지막에 나온 정보로 17.16%의 파일 사이즈를 줄일 수 있다고 나오는군요.
그래서 이렇게 나온 파일을 다시 TweakPNG로 열어본 결과 꼭 필요한 헤더와 푸터 chunk(IEND), 그리고 데이터 영역(IDAT)을 제외하고 모든 chunk 가 없어진 것을 확인할 수 있었습니다.



아래 상태표시줄을 확인하면 sample.png 파일의 크기가 13479byte에서 11166byte로 압축되었음을 알 수 있습니다. GIF 에 비해서 PNG 가 용량 면에서 효율적인데도, 덤으로 필요없는 정보를 다이어트 하여 더 크기를 줄일 수 있는 좋은 팁입니다.

이 과정은 조금 복잡하지만, 이 작업을 어느정도 자동화시키면 충분히 실무에도 활용 가능할 것으로 보고 있습니다. 저도 현재 진행중인 모 개편 프로젝트에서 8bit png의 활용과 함께 CSS 스프라이트 등의 최적화 방안을 적용하여 진행하고 있는 중입니다.
적어도 마크업 때문에 사이트 속도가 느리다! 라는 비판을 받으면 자존심 상하지 않나요..?!?! (응?)

pngCrush 프로그램은 다음 URL에서 받으세요.
http://sourceforge.net/project/showfiles.php?group_id=1689&package_id=6641

TweakPNG 프로그램은 다음 URL 에서 받으세요. (Freeware)
http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/TweakPNG.shtml

Posted by 아마티

오늘도 보람찬(?) 하루일과를 마치고, 피곤한 몸을 이끌고 잠들기 전에 마지막으로 컴퓨터 앞에 털썩 앉아 헤드폰을 쓰고 플레이한 음악은...

차이코프스키 바이올린 협주곡 D장조 3악장...

아는 사람은 알겠지만, 이 장면은 노다메 칸타빌레 in 유럽에서 잠깐 나왔던 장면. 이 곡이 바로 3악장이다. (원곡은 대략 10분짜리 곡임)
중반까지는 고요함과 편안함을 유지하다가 점점 힘차고 화려한 연주로 분위기를 끌어올리면서, 마지막에 빵~ 터트려주는 피날레는 정말 감동이라고 할 수 밖에 없다. ㅠ_ㅠ

차이코프스키가 유일하게 작곡했던 바이올린 협주곡인 이 곡은 그 유명세 답게 음반도 매우 많은데... 내가 가지고 있는 음반은 야사 하이페츠, 바딤 레핀, 줄리아 피셔 버전... 그중에서도 줄리아 피셔 (Julia Fischer) 버전이 가장 최근작이기 때문에 음질이 깨끗하다.
여성이기 때문인지, 연주 자체에 엄청난 힘이 느껴지진 않지만, 섬세하고 칼같은 연주로 귀를 즐겁게 해준다.

평소에도 즐겨 듣긴 하지만, 정말 몸이 이렇게 노곤한 상태에서 눈 감고 의자에 푹 묻혀서 듣다보면 뭔가 몸이 동동 떠오르는 기분이 드는 것이 중독이 될것만 같다.

오늘도 お休みなさい (안녕히 주무세요~)

Posted by 아마티

CSS에서 사용하는 다중 선택자(Multi Class)란 동일 엘리먼트에 여러개의 선택자(id, class)를 동시에 적용하기 위한 목적으로 여러개의 선택자를 사용하는 것을 말합니다.
CSS1에서 선택자의 개념이 사용된 후, CSS2에서 다중 선택자가 추가되어 사용되고 있는데요, CSS를 사용해 웹사이트를 개발하다 보면 다중선택자는 정말 편리한 존재입니다.

<style>
.foo { background:yellow; }
.bar { border:solid 4px red; }
.foo.bar { border-style: dashed; }
</style>

<div class="foo">foo</div>
<div class="bar">bar</div>
<div class="foo bar">foo bar</div>

아마 기존에 다중 선택자에 대한 자료를 찾아보셔서 알고 계신 분은 foobar 라는 단어가 익숙하실 지도 모르겠습니다. (웃음)
위의 코드는 다중 선택자를 적용하여 foo 클래스와 bar 클래스의 속성을 하나의 엘리먼트에 동시에 적용한 예제입니다. 또한 클래스를 붙여서 선언하게 되면 평소에는 적용되지 않다가 두 클래스가 동시에 적용될 경우에만 별도의 효과를 주는 것도 가능합니다.
이렇게 여러 개의 클래스를 하나의 엘리먼트에 적용하여 서로 다른 효과를 동시에 적용할 수 있고, 이 다중 선택자는 3개 이상도 사용이 가능합니다.
만약 클래스 내의 css속성이 겹친다면 뒷쪽에 선언된 클래스의 css속성을 우선하지만(덮어쓰기 효과) 만약 !important 가 속성에 포함되어 있을 경우 순서에 상관없이 해당 속성을 우선 적용하게 됩니다.

그래서 CSS개발하시는 분은 대부분 다중 선택자를 매우 유용하게 사용하고 있지만, IE6에서는 관련 버그가 존재하기 때문에 사용에 주의해야 합니다. (또 IE6이 문제입니다! -_-)


1. id와 class 를 동시 조합하여 이용시, 나중에 선언된 다중 선택자 구문 무시
이 부분은 NHN NULI의 css가이드를 참고하였습니다. IE6의 경우 id와 class를 다중 선택자로 적용할 때에 나중에 선언된 다중 선택자를 무시하는 버그가 존재합니다.

<style>
#id.class1{background:#f00;}
#id.class2{background:#0f0; width:200px;} /* Does not exist in the IE6 */
#id2.class2{background:#00f; width:200px;}
#id2.class3{background:#0f0; width:300px;} /* Does not exist in the IE6 */
#id.class3{background:#f00; width:300px; font-weight:bold;} /* Does not exist in the IE6 */
</style>
<div id="id" class="class1">class1</div>
<div id="id" class="class2">class2</div>
<div id="id2" class="class2">class2</div>
<div id="id2" class="class3">class3</div>
<div id="id" class="class3">class3</div>

원래 위의 예제에서는 그림처럼 보이는 것이 바른 렌더링입니다. 하지만 IE6에서는 예제에서 2, 4, 5번째 줄에 해당하는 부분을 무시하게 됩니다. 아래 이미지처럼요.



따라서 불쌍한 IE6 을 위해서라면, 붙여서 쓰는 다중 선택자를 사용할 때에는 id와 class를 동시에 사용하지 않고, class만 사용하는 것을 권장합니다.

2. class 조합하여 이용시, 앞에 선언된 class 무시
하지만 불쌍한 IE6을 생각해서 class만 가지고 다중 선택자를 구성했음에도 불구하고, 특정 상황에서는 또 오작동을 해버립니다.
class만으로 다중 선택자를 구성할 때 예를 들어 .foo.bar{} 라는 클래스를 구성하면 IE6은 앞의 .foo를 무시하고 .bar{} 라는 클래스로 인식하게 됩니다.

원래 코드
.foo { background:yellow; }
.bar { border:solid 4px red; }
.foo.bar { border-style: dashed; }
IE6이 인식하는 코드
.foo { background:yellow; }
.bar { border:solid 4px red; } /* border 속성 중 border-style 속성이 삭제됨 */
.foo.bar { border-style: dashed; } /* bar class의 border-style 속성이 오버라이딩됨 */

이를 이미지로 보여드리면 다음과 같습니다.

<style>
.foo { background: yellow; }
.bar { border: solid 4px red; }
.foo.bar { border-style: dashed; }
</style>
<div class="foo">foo!</div>
<div class="bar">bar!</div>
<div class="foo bar">foo bar!</div>

위에서 foo bar 라는 유명한 예제(?)를 보여드렸는데요, 이게 IE6에서 다중선택자의 버그가 있다는 것을 적나라하게 보여주고 있죠. 원래 bar class의 경우 border-style 속성이 solid임에도 불구하고 IE6에선 .foo.bar 를 .bar로 인식함에 따라 border-style이 dashed 로 모두 교체된 것을 확인할 수 있습니다. 1번 항에서 다루었던 버그도 이 버그의 영향이 겹쳐서 생긴 문제가 아닐까 하는데요, 정확히는 잘 모르겠습니다.
이 버그를 회피하기 위해서는 class를 붙여서 선언하는 다중 선택자를 사용하지 않는 것이 최선입니다. 하지만 CSS작성 중의 편의를 위해서 붙여서 선언해야 할 경우엔 뒤에 붙이는 class명을 겹치지 않도록 사용하는 것도 방법입니다.

기존
.dx.class {}
.dy.class {} /* 별도의 class로 인식되지만, IE버그로 dy.class{}만 인식 */
수정(버그 회피)
.dx.classx {}
.dy.classy {} /* 최종 class명을 다른 이름과 겹치지 않는 고유의 클래스명으로 사용 */

이렇게 수정하는 방법은 다중 선택자의 장점을 완전히 무시하는 비효율적인 방법이긴 하지만, 어쩌겠습니까... 이놈의 IE6이 도와주지 않는걸요...

물론, IE7은 위에 나타나는 다중클래스의 버그는 해결하였습니다. 하지만, 표준모드(HTML 4.01, XHTML 1.0)로 동작할 때에만 버그가 나타나지 않게 되어 있으며, Quirks mode DTD로 동작될 때에는 IE6과의 호환을 위해 (또는 미처 쿽스모드 엔진을 고치지 못했을 수도 있죠) 이 버그가 그대로 나타나도록 되어있습니다.

IE6은 언제까지 우리 UI개발자를 괴롭히게 될까요? ㅠ_ㅠ

이 포스트는 NHN WSG(Web Standardization Guide) 블로그와 네이버의 개인 블로그에 함께 연재되고 있습니다.

Posted by 아마티

저는 현재 NHN 직원입니다. 또한, 제가 쓰는 글은 전적으로 제가 느끼고 생각한 것을 적는 것이며 절대 NHN 의 공식 입장이 아님을 밝힙니다. 이렇게 말하면 우선 색안경을 끼고 보는 분들도 있긴 하지만 (요즘은 일부가 아니라  대부분인 것 같습니다) 할 수 없죠.

회사의 외부 커뮤니케이션과 대내 공지에서도 항상 언급되고 있지만, 실시간 급상승 검색어는 여러 공식 매체에서 밝혔듯이 절대 조작을 하지도 않고, 조작할 수도 없습니다. 이 부분은 회사의 높은 분들도 확인해주신 부분입니다. 제가 있는 부서의 경우 센터장님께서 공지하신 것입니다만...

실시간 급상승 검색어의 로직은 최근 여러 사건 때문에 어느정도 알려져 있습니다만, 일정 시간 내에 검색이 급상승한 단어가 높은 순위를 먹게 됩니다. 아시다시피 네이버의 핵심사업이자 주요 접속요인은 '검색' 입니다. 그만큼 검색어 쿼리가 많다는 것인데, 짧은 시간 내에 정말 엄청난 쿼리가 들어오고 있다고 합니다.
회사 상급자 분께서 예를 들어주셨는데, 실시간 급상승 검색어를 고속도로에 비교하자면 도로에서 1등부터 10등까지 달리는 차를 골라내는 것이 아닌 과속하는 자동차를 관찰하는 시스템입니다. 같은 시간 안에 시속 100km 에서 시속 120km 로 가속한 차보다는 시속 20km 에서 시속 120km 으로 가속한 자동차가 더 높은 순위를 먹습니다. 또한 그 시간에 이 차만큼 토탈 100km 이상을 가속한 차가 없다면, 1위를 먹게 되죠. 시속 120km 로 달려서 1순위가 된 차는 탄력을 받아 계속 가속하겠지만 가속할 수 있는 속도의 한계 때문에 같은 시간에 시속 120km 에서 시속 150km 로 가속하게 되면 겨우 30km 를 추가 가속했기 때문에 가속 정도는 다른 저속 자동차가 급가속하는 것에 비해 떨어질 수 밖에 없습니다.
그래서 단위 시간 안에 가장 많이 검색되고 있는 단어, 즉 인기도 1위의 검색어도 급상승 로직의 입장에서 보자면 상대적으로 검색이 늘어나는 속도가 느리거나, 오히려 떨어질 수도 있기에 이 때에는 순위를 확 낮추거나 없애버릴 수도 있는 거죠.

물론 검색어는 계속 모니터링 되고 있습니다. 네이버 공지에도 밝혔듯이 "이용자 보호와 피해방지를 위해 개인정보, 명예훼손, 음란성, 상업적 목적의 광고 및 범죄 행위와 관련된 검색어에 한해 관련 법률에 따라 노출을 제한" 하고 있을 뿐 의도적으로 검색어의 순위를 바꾸거나 삭제하지 않고, 또한 시스템 상으로도 그렇게 할 수 없습니다. 개발자 입장에서도 이런 짓 했다가는 시스템 꼬이기 십상이죠. -_-;;

다른 이슈로, 대부분의 일반 유저와 달리 시스템을 조작하려고 하는 어뷰저들에 대한 대책도 생각해야 합니다. 과거에는 인기검색어를 조작할 의도로 다수가 동원되어 고의로 특정 단어를 1위에 올려놓을 수도 있었고, (디씨가 유명했죠) 조직적으로 특정 단어를 1위로 올려놔서 검색의 증가를 통해 특정 기업의 방문과 매출을 유도했던 케이스도 많았다고 합니다. 이러한 문제들과 운영 상의 난점, 공정성을 해결하기 위해 실시간 검색어 로직이 계속 개선되어 지금에 이르렀다고 할 수 있죠. 이 실시간 검색어 로직은 다음, 야후, 싸이월드 등 다른 포털 사이트도 나름대로의 과정을 거쳐서 지금에 이르렀고 계속 개선을 하고 있는 것으로 알고 있습니다.

이상이 대략적인 네이버의 실시간 급상승 검색어 시스템의 로직입니다.
따라서 네이버는 절대 실시간 급상승 검색어를 조작하지 않습니다.


우선 실시간 급상승 검색어에 대해서만 글을 썼지만, 솔직히 외부에서 듣는 네이버에 대한 "오해" 에 대해서는 개인적으로 "섭섭하다" 라고 할 수 밖에 없습니다. 저나 다른 동료 분들도 그렇지만, 외부 지인들한테 "요즘 네이버 왜그래?" 라는 말을 들으면 답답해지고, 설명하는 것도 지칠 정도입니다.

네이버는 방문수가 엄청난 거대 포털이고 방문하는 유저도 각양각색이기 때문에 중립을 지켜야 합니다. 이쪽 입장을 보여줄 때에는 여과없이 저쪽 입장도 보여줘야 하죠. 예를 들면, 요즘 같은 때에는 중립 때문에 모든 것을 여과없이 노출하면 거대 세력(촛불집회, 국민 요구)이 볼 때에는 소수 세력(정부 해명)에 대해 편파적으로 힘을 실어주는 것이 아니냐는 것으로 보일 수도 있습니다. 중립을 지키다 보면, 대체적으로 진보 성향이 강한 네티즌들에게는 비판을 받게 되기 때문에, 포털로서는 어쩔 수 없이 이를 감수할 수 밖에 없죠. 다만, 요즘의 반 네이버 정서는 내부에서도 상당히 이슈가 될 만큼 비정상적으로 확대된 것을 보면 중립을 지키는 것 만으로 이런 일이 생겼다고는 볼 수 없겠죠.
따지고 보면 중립과 원칙이라는 명제 때문에 정책적으로 불합리한 부분도 분명 존재하며, 시스템 상의 헛점도 있고 사람이기 때문에 분명 실수도 존재하고 있다고 생각합니다. 하지만, 사내에서도 이를 개선하기 위한 노력과 해결 방안에 대한 토론이 공개적으로 활발하게 이루어지고 있습니다. 재미있는 일상사를 이야기하기도 하고, 대통령과 정부를 까기도 하고, 네이버의 불합리한 부분을 지적하기도 하며, 네이버의 변화를 촉구하기도 하는 글은 사내의 익명 게시판을 둘러보면 많이 찾을 수 있습니다. 또한 네이버가 앞으로 변화해야할 방향을 제시하거나, 서비스 쪽으로 좋은 아이디어를 내거나, 다수를 만족시키기 위한 많은 발전적인 활동이 사내 게시판에서 이루어지고 있죠.

네이버 직원들도 대한민국 국민이며 네티즌입니다. 하지만 직원이기에 자신도 회사의 얼굴이 되기 때문에 외부에 어떤 의견을 내는 것이 매우 부담스럽고, 조심하게 됩니다. 오늘 오후에 네이버에 "최근의 오해에 대해 네이버가 드리는 글" 이라는 공지사항이 떴고 이 글이 블로그스피어에서도 많이 다뤄지고 있습니다만, 제가 볼 땐 이 공지사항의 효과는 성난 네티즌들을 설득하는 효과보다는 오히려 위축되고 동요하는 내부 직원들을 격려하는 효과가 더 클지도 모른다는 생각도 잠깐 드는군요...

NHN의 모든 임직원들은 네이버의 일원으로서 서비스에 자부심을 가지고 있으며, 열정을 바탕으로 국내 최고의 포털을 만들어 네티즌을 만족시키고 싶다는 마음으로 업무에 임하고 있다고 생각합니다. 다들 야근도 불사하면서 열심히 업무에 임하고 있으니, 앞으로의 네이버의 변화된 모습을 지켜봐주시고 좋은 비판과 함께 의견 많이 주시고 격려도 해주셨으면 합니다.

그냥 남들 다하는 한마디 하렵니다.

이게 다 이명X 때문입니다!!
내려올 생각이 없다면 조금이라도 제대로 해주세요 제발 ㅠ_ㅠ

그리고 이런 이슈로 반짝 붐비는 블로그가 아닌 본업의 UI개발 쪽으로 유망한 블로그가 되어서 좋은 컨텐츠를 볼 수 있는 블로그를 가꾸고 싶습니다. 물론 제가 더 열심히 노력해야겠지만요 ^^;;

Posted by 아마티

저 자신도 UI개발 일을 하고 있긴 하지만, 오랜 역사를 가진(?) 프로그래밍/개발 분야와는 달리 UI개발 분야는 아직 미개척 분야라고 해도 과언이 아니죠.
확실히 직군으로서도, 개인적으로도 UI개발 직군이 전문성을 가져야 한다는 것을 절실하게 느끼고 있습니다.

마침 다음에서 좋은 행사를 준비하고 있는데요,
개발자가 주축이 되는 DevDay 와는 달리 UI개발 직군이 중심이 되는 UI DevDay 라는 행사를 준비하고 있다고 합니다.



이 분야에 관심있으시고 새로운 분야를 개척하시겠다는 개척 정신을 가지신 분이라면 한번쯤 참가하셔서 견문을 넓혀 보시는 것은 어떨까 싶습니다. ^^
다녀와서 보고서 올려보도록 하겠습니다!

• 일시: 2008년 5월 30일(금) 오후 1시 30분 ~ 오후 6시
• 장소: 삼성동 섬유센터 17층
• 인원: 250명

Posted by 아마티

1989년, 팀 버너스 리(Tim Berners-Lee)는 네트워크에서 정보를 전달하고 서로 연결하기 위하여 WWW(world wide web)라는 시스템을 고안하고, 이를 구현하기 위해 URL, HTTP, HTML 규약을 만들었습니다. HTML은 그 단순함과 범용성, 호환성을 바탕으로 현재까지도 인터넷에서 정보의 전달을 위한 포맷으로서의 역할을 훌륭히 수행하고 있지요.
하지만 WWW가 탄생된 지 20년이 되어가는 현재 시점에서는 폭발적인 정보 증가량, 멀티미디어화 된 정보, 새로운 기술의 욕구 등으로 인해 HTML 만으로는 정보 전달에 있어 역부족인 상황이 되었습니다. 이 문제를 해결하기 위해 새로운 기술과 이론이 계속 발표되고 있으며, Flash, Silverlight, Javascript, 웹표준, 그리고 UX, RIA, Web 2.0, 시멘틱 웹 등등 많은 신기술과 개념들이 HTML의 부족했던 기능을 보충해주고 있습니다.
이 포스트에서 언급할 Microformat(마이크로포맷) 도 HTML을 도와 정보를 효율적으로 전달하기 위해 고안된 새로운 기술입니다.


마이크로포맷은 HTML 문서 내에서 특정 마크업을 사용하여, 특정 정보를 메타 데이터 형태로 가공하여 사용자(사람)와 컴퓨터(기계)가 이 정보를 직접 사용할 수 있도록 구현하는 정보 포맷 방식입니다.

보통 어떤 문서를 열람할 때, 예를 들어 "010-1234-1234" 라는 것을 사용자들이 보면 대부분 이 번호가 휴대전화번호라는 것을 금방 인식할 수 있습니다. 또한 "김철수 010-1234-1234" 라는 문구를 보면 대부분의 한국인(?) 사용자는 '김철수'라는 사람의 전화번호는 '010-1234-1234'라고 인식하게 됩니다.
하지만, 이 과정은 컴퓨터에는 적용되지 않습니다. '김철수'라는 것이 사람 이름인지 아닌지도 알 수 없고, '010-1234-1234'라는 번호가 무엇인지도 알 수 없고, '김철수'와 '010-1234-1234'가 무슨 관계가 있는지도 알 수 없으며, 단지 '0101001' 등의 이진수의 나열이라는 것 밖에 알 수 없습니다.
이 때문에 위 정보를 찾아내기 위해서 문서 내의 정보를 사람이 직접 검색(Ctrl+F)하여 이름을 찾아내고 전화번호를 찾아내는 불편한 과정을 수행해야 합니다.

하지만 HTML에 특정 마크업을 추가하여 표현한 '마이크로포맷'을 이용하면, 컴퓨터가 해당 정보가 어떤 종류인지 파악할 수 있으며 이를 통해 사람도 더욱 편리하게 정보를 얻을 수 있습니다.

즉, 마이크로포맷은 특정 마크업을 사용하여 human-readable(사람이 읽을 수 있는) 데이터를 machine-readable(기계가 읽을 수 있는), machine-understandable(기계가 이해할 수 있는) 데이터로 바꾸어주는 기술이며, 이를 각종 소프트웨어나 검색 엔진에서 활용하여 사용할 수 있는 방법은 무궁무진할 것이라고 예상되고 있습니다.

"마이크로포맷"은 다음 세가지 표준속성을 사용하여 삽입할 수 있습니다.

• class : 마이크로포맷을 구성하는 기본 속성으로 정보를 정의하는 역할
• rel : 현재 문서가 링크로 연결되는 문서와 어떤 관계인지 정의
• rev : 링크로 연결되는 문서가 현재 문서와 어떤 관계인지 정의 (rel과 반대시점)

다음과 같은 HTML 코드가 있습니다.

<div>
<div>김철수</div>
<div>NHN corp.</div>
<div>031-123-1234</div>
</div>

위 코드는 사람인 우리들이 읽어볼 때 어떤 내용인지 금방 파악할 수 있습니다. 이름과 회사, 전화번호 정도로 예상할 수 있지요.
하지만 컴퓨터는 위에서 설명했듯, 이 내용이 무슨 내용인지 알 수 없습니다. 이 단점을 해결하기 위해 마이크로포맷의 class 속성을 사용하여 다음과 같이 표현할 수 있습니다.

<div class="vcard">
<div class="fn">김철수</div>
<div class="org">NHN corp.</div>
<div class="tel">031-123-1234</div>
</div>

위 코드만 추가하면 사용자는 물론이고 마이크로포맷을 인식할 수 있는 소프트웨어도 이 내용이 명함임을 파악하고, 이름과 소속, 전화번호를 얻을 수 있습니다.

또한, rel 속성은 XFN(XHTML Friends Network)를 사용하여 연결된 문서간의 관계를 정의할 수 있습니다.

<a href="http://dave-blog.example.org/" rel="friend met">Dave</a>
<a href="http://darryl-blog.example.org/" rel="friend met">Darryl</a>

위 코드가 나타내는 바는 dave-blog 라는 사이트는 현재 friend met 관계라는 것을 말하며 "friend" 는 친구, "met" 은 만난 적이 있는 관계를 의미합니다. 모두 조합하면 dave-blog 는 내가 예전에 만난 적 있는 친구라는 것을 의미합니다. 자세한 레퍼런스는 XFN 사이트를 참고해주세요.

또한, 마이크로포맷을 조합하여 사용할 수도 있는데 다음의 예처럼 hCard(명함)와 hCalendar(일정) 정보를 조합하여 사용할 수 있습니다.

<div class="vevent">
  <a href="http://aneventapart.com/" class="summary url">An Event Apart,
    <span class="location vcard">
      <span class="fn org">Scandinavia House</span>,
      <span class="adr"><span class="locality">New York City</span>, <span class="region">NY</span></span>
    </span>
  </a>,
  <abbr class="dtstart" title="2006-07-10">July 10</abbr>-<abbr class="dtend" title="2006-07-12">11th, 2006</abbr>
</div>

vevent는 hCalendar(일정) 정보를 표시하는 상위 클래스이며 그 하위에는 summary(일정 요약), url(인터넷주소), location(위치), dtstart(시작일시), dtend(종료일시) 등을 사용하였고 location에는 vcard 클래스를 통해 위치 정보를 더 자세하게 표현한 것을 알 수 있습니다.

이외에도 마이크로포맷 규칙은 많이 있으며 지금도 계속 제안되고 있습니다. 대표적인 클래스는 다음과 같습니다.

• hCard : 주소록(명함) 정보, class="vcard"
• hCalendar : 일정 정보, class="vevent"
• hReview : 리뷰(사용기, 감상기, 체험기 등) 정보
• hResume : 이력서 정보
• geo : 위도와 경도
• XOXO : 리스트와 요약 정보 저장
• rel-nofollow : 마이크로포맷 파서가 분석할 필요가 없음을 명시하는 링크
• rel-directory : 링크가 디렉토리 정보임을 명시
• rel-tag : 링크가 태그 정보임을 명시
• XFN : 웹페이지간의 관계 설정

위의 대표적인 속성인 hCard, geo 등을 조합하여 와인의 이름, 생산자와 위치 정보를 포함하는 마이크로포맷도 제안될 정도로 마이크로포맷은 활성화되어 있습니다.
이 글엔 언급하지 못할 정도로 많은 클래스가 제안되고 있기 때문에, 현재 제안된 마이크로포맷 클래스를 자세하게 찾아보려면 아래에 별도로 정리된 레퍼런스를 참조해주세요.

마이크로포맷은 어떻게 활용할 수 있을까요?

마이크로포맷은 파이어폭스 진영의 Tails Export, Operator 등의 플러그인을 통해 사용할 수 있습니다. 이 플러그인은 문서 내에 포함되어 있는 마이크로포맷을 파악하고, 해당 정보를 Outlook 등의 일정관리 프로그램에 보내주기도 합니다. 또한 Firefox 3 beta 버전에서도 브라우저 자체적으로 마이크로포맷을 활용할 수 있는 옵션이 존재합니다.

앞으로도 마이크로포맷이 활성화되면 이 정보들을 더욱 많은 곳에 활용할 수 있는 소프트웨어가 나올 것이라 예상됩니다. 각종 정보가 집중적으로 수집되는 포털에서 사용자들에게 원하는 정보를 예전과 달리 필요한 정보를 더 쉽게 쪽집게처럼 찾아준다는 것은 즐거운 일일 것입니다.
예를 들면, 사용자가 단순히 짜장면을 주문하는 명령 만으로도 사용자의 생활권 내에 수집된 음식점 정보들을 바탕으로 일정지역 내에 가장 싸고 맛있는 짜장면을 찾아내어 자동으로 주문하는 것도 가능하다는 것이죠.

현재로서는 마이크로포맷을 제공하는 사이트는 소수입니다. 국내에서 블로깅 툴로 유명한 텍스트큐브, 워드프레스 등이 마이크로포맷을 지원하고 있지만, 국내 포털에서는 아직 마이크로포맷을 제공하는 사이트가 없으며, 해외 사이트 중에서도 마이크로포맷을 활용한 사이트는 아직 많지 않습니다.
하지만 마이크로소프트, 야후 등이 차후에 자사의 사이트와 소프트웨어에 마이크로포맷을 활용할 것이라고 하였고, 쉬운 사용법을 바탕으로 블로그 등의 소셜 사이트 등에서 사용하는 곳이 많아지고 있기 때문에 마이크로포맷의 영향력은 더욱 확대될 것입니다.

WWW를 창시했던 팀 버너스 리(Tim Berners-Lee)가 차세대 웹으로 제안한 "시멘틱 웹" 은 컴퓨터가 이해할 수 있는 WWW 를 목표로 하고 있습니다. 하지만 이를 구현하기 위해서는 많은 장애물이 있으며, 사람의 사고를 컴퓨터가 이해해야 하기 때문에 어쩌면 도달하지도 못할 WWW의 이상향이라고 할 수 있으며, 이 때문에 시멘틱 웹은 아직 개념도 제대로 잡히지 않은 단계에 있습니다.
하지만 마이크로포맷이 기계와 사람이 동시에 이해할 수 있는 정보를 제공한다는 개념을 통해서 시멘틱 웹의 첫걸음이 되고 있는 것은 분명합니다. 이를 통해, 앞으로 시멘틱 웹이 어떤 방식으로 구현되게 될지 지켜보는 것도 즐거운 일이 아닐까 싶습니다.


References :
http://microformats.org/
http://wiki.mozilla.org/Microformats
http://microformats.org/wiki/Main_Page

이 포스트는 NHN WSG(Web Standardization Guide) 블로그와 네이버의 개인 블로그에 함께 연재되고 있습니다.

Posted by 아마티

인터넷 브라우저에서 사용할 수 있는 이미지는 아시다시피 GIF, JPG, PNG 가 있습니다.

그중, 웹에서 사용할 수 있는 이미지로서의 PNG 는 GIF 나 JPG 에 비해 많은 장점을 가지고 있습니다. PNG 는 "Portable Network Graphics" 의 약자이며, 프리웨어이고, JPG 와는 달리 무손실압축(원본과 완전히 같음)을 지원하며, 24bit(1670만) 컬러를 구현합니다. 무엇보다도 알파채널, 즉 반투명을 지원한다는 큰 장점이 있죠. 단점이라면, GIF 처럼 애니메이션을 지원하지 못한다는 것과, 파일 크기가 다소 크다는 점이지만, 큰 단점은 아닙니다. (사실, 구버전의 포토샵에서 PNG로 저장할 때 용량이 비정상적으로 커지는 버그 때문에 PNG 에 대한 편견이 부각된 점도 있습니다.)
자세한 설명은 위키를 참고하세요!

http://ko.wikipedia.org/wiki/PNG

PNG 의 가장 큰 장점이자 특징이라면 알파채널을 지원해서 반투명도 표시할 수 있다는 점인데요, 그만큼 표현할 수 있는 범위가 상당히 넓어진다는 장점이 있어서 최근들어 비주얼이 강조되는 사이트에서 많이 사용되고 있습니다. 하지만, 현재로선 가장 높은 점유율을 가지고 있는 IE6 에서는 png를 사용할 때 치명적인 버그가 존재합니다.

1. IE6 에서는 PNG 의 투명 영역을 회색으로 표시함.

반투명의 영역을 회색으로 표시하는 버그 때문에 가장 큰 장점인 알파 채널을 사용할 수 없습니다. 굳이 PNG 이미지를 사용할 이유가 없어지는 것이죠. 따라서 IE 에서는 이 문제를 해결하기 위해 AlphaImageLoader 라는 내장필터를 제공하고 있습니다. 해당 필터에 대한 자세한 설명은 다음 페이지를 참고해주세요.

http://msdn2.microsoft.com/en-us/library/ms532969.aspx

이를 해결하기 위한 방법으로는 검색해보시면 아시겠지만, 일명 iepngfix.htc 를 이용한 방법이 가장 쉽게 해결할 수 있는 방법입니다. 이 방법도 따지자면 위에 언급한 AlphaImageLoader 필터를 사용하여 해결하였는데요, 이에 대한 포스팅은 다음을 참조해주세요.

http://bjorkoy.com/past/2007/4/8/the_easiest_way_to_png/
http://naradesign.net/wp/2006/12/15/100/

2. 색상이 더 짙게 표현됨
위 이미지는 포토샵에서 #333333 색상을 이용한 이미지를 각각 GIF 256color Transparency, JPG very high quality, PNG 24bit Transparency 옵션으로 각각 저장한 후 웹브라우저로 렌더링 해본 결과입니다.
만약 미세한 색상을 구분할 수 있으시다면 사파리, 오페라, 파이어폭스에서는 전혀 문제가 없다는 것을 확인하실 수 있지만, IE계열에서는 jpg, gif 보다 png 쪽 이미지가 약간 짙게 표현되는 것을 확인 하실 수 있을 겁니다.
각각의 이미지로 표현된다면 별 문제는 안되겠지만, 같은 색상의 이미지 위에 반투명 표현을 위해 png 이미지를 사용한 것이라면 문제가 생길 수 있겠죠. 이 문제는 IE 의 AlphaImageLoader 필터를 사용해도 공통적으로 발생하는 문제인 것을 보면 HTML 수준에서 해결할 수 있는 방법은 없다는 것을 예상할 수 있겠습니다.

저도 예전에 png를 많이 사용한 프로젝트를 진행하면서 위 문제때문에 상당히 고생했었던 기억이 있는데요, 비주얼이 특히 화려한 한게임 계열 사이트를 작업하시는 분들은 PNG 가 사용되는 상황이 되면 머리를 싸매시더군요. ㅠ_ㅠ

위의 문제들이 해결된(사실은 원래 없었던) 파이어폭스나 기타 표준계열 브라우저가 있다고는 해도, 아직까지는 점유율 80% 이상을 차지하는 IE6 을 무시할 수 없는 상황에서... PNG 를 쓰는 것은 과연 옳은 걸까요?

이 포스트는 NHN WSG(Web Standardization Guide) 블로그와 네이버의 개인 블로그에 함께 연재되고 있습니다.

Posted by 아마티

이젠 펀드도 안되나 보다...

작년 2007년만 해도 펀드는 재테크의 시작이요, 은행에 돈 넣어두면 바보 취급을 당했었는데 지금의 펀드는... 미국 증시에 조그만 문제만 있으면 엄청난 기복을 타고 있으니...

예를 들면, 오래 묶어두셨던 분들이라면 작년 말의 펀드 폭락에 100% 수익에서 50% 수익률로 내려서 "약간 손해를 봐도 전체적으로 이익" 정도로 끝났지만, 펀드 열풍을 타고 작년에 가입하셨던 분들의 수익률은 20% -> -50% 정도 된 거 보면... 대략 난감하더라.
그냥 조금 멀리 떨어져서 제3자의 눈으로 보자면... 우루루 펀드에 몰렸던 개미 투자자들은 증시의 조그만 오르내림에도 얼마 되지 않는(?) 투자금의 +, - 를 넘나드는 수익률에 울고 웃는 모습은 조금 안쓰러운 감정도 느껴지곤 한다.

개인 투자자는 큰손이 아닌한 주식 시장 전체, 한국 경제에 대비해서 보면 정말 보잘것 없는 금액이다. 이러한 작은 돈에서 10% ~ 20% 내외의 수익을 얻어보겠다고 머리 싸매며 재테크 한다는 것은, 솔직히 멀리서 떨어져서 보면 이건 아니다 싶다.
거기에 더 비관적인 것은, 재테크로 돈을 크게 벌었다는 얘길 자세히 들어보면 그 중간 수단 중에 "부동산"이 없었던 케이스는 찾을 수 없었고, 오히려 부동산이 재테크를 성공적으로 이끌어주는 키포인트인 경우가 많았다. 한국에서 돈 벌려면 부동산 말고는 없는 것일까?
책도 몇개 읽어보긴 했지만, 다들 똑같은 얘기. 겨우 도움이 되는 것이라면 경제쪽 상식이라거나, 돈쓰는 습관을 체계적으로 바꾸어 합리적인 소비를 강조했다는 것. 뭐 나쁘다는 투로 말하긴 했지만, 이정도 얻은 것만 해도 도움이 되긴 했다.

글쎄.. 재테크를 단순히 저축해서 이자 늘리기로 보는 나의 지식의 한계일지도 모르겠다. 과연 재테크가 무엇인가에 대한 정답은 찾지를 못했다.

현재는 개인적으로 돈 쓸일이 많기도 하고, 여유자금이 얼마 없는 데다가, 동양생명 직원의 말빨에 넘어가 들어놓은 저축성 보험 이외에는 모두 CMA에 박아두고 있는데 어떻게 해야할 지 고민중...
아무리 재테크 계획을 잘 짜서 치밀하게 한다고 해도 원금의 100% 수익을 내는 것이 가능할까? 가능하다고 해도... 1억원에서 2억원으로 불리는 것이라면 몰라도 1천만원에서 2천만원으로 늘어나는 것을 비교해보면? 같은 노력을 들였는데도 수익은 9000만원이나 차이나는 이 현실은 어떻게 할 것인가;;;

이런 비관적인 글을 쓴 계기는 주식 시장의 작은 변화에도 큰 영향을 받을 수 있는 개미 투자자(물론 나를 포함한. 투자는 안했지만 ㅎ)에 대한 허무함이라고나 할까, 그냥 단상은 단상일 뿐.

역시 처음의 전략이 좋은 것 같다. 월급을 받으며 꾸준히 돈을 모으는 것보다는, 돈을 벌 수 있는 무엇인가를 찾아서 그것을 노후대책으로도 생각하는 게 가장 마음에 든다.

물론... 재테크보다 훨씬 어려운 길이지만, 재미는 있겠지?

Posted by 아마티

미국 라스베가스에서 현지시간 3월 5일~7일 일정으로 진행되고 있는 MIX08 Conference 에서 Internet Explorer 8 Beta1 버전이 발표되었습니다. 이전 기능을 통합하는 새로운 기능, 웹표준을 지원하는 새로운 렌더링 엔진이 큰 특징이라고 할 수 있습니다.

최근 IE8 에 대한 소식이 잦다는 느낌이 들었는데, MIX08 컨퍼런스를 통해 Beta1 버전을 일반 사용자도 다운받아서 사용해볼 수 있도록 제공하고 있네요.
이번 버전은 개발자와 디자이너들을 위한 Beta1 버전으로, 일반인들까지 대상으로 하는 Beta2 버전은 여름 쯤에 제공하겠다고 밝혔답니다. 개발자와 디자이너들에게는 이번 Beta1 버전을 통해 미리 IE8 이 정식으로 발표될 때를 준비하라는(?) 메세지를 주고 있는 것 같습니다. ^^;;

아직까지는 기존의 IE7 과 거의 비슷한 인터페이스를 보여주고 있습니다만, 베타2와 정식판에서는 어떤 비주얼을 보여줄지 기대되네요.

다운로드 :
http://www.microsoft.com/windows/products/winfamily/ie/ie8/readiness/Install.htm

IE8 의 큰 특징인 동시에 유례없는 관심을 받고있는 이유를 찾아보자면, IE8 에는 기존의 호환 모드 대신 웹표준을 준수하는 표준 렌더링 엔진이 기본 모드로 채택되었다는 것이라고 할 수 있겠습니다.

이전 포스트에서도 밝혔듯이 IE8 이 표준 모드에서 Acid2 테스트를 통과했다고 알려졌는데요, 원래 IE8 에서는 이 표준 렌더링 엔진이 아닌 기존 IE7 까지 쓰이던 호환 모드를 기본 엔진으로 채택하겠다는 입장을 고수하고 있었습니다. 이는 각각 장단점이 존재하는데요, 이때문에 개발자들 사이에서 큰 논쟁이 이루어졌고, 결국 IE 를 개발하던 Microsoft는 이들의 의견을 받아들여 IE8의 기본 모드를 표준 모드로 채택하기로 했다고 합니다.

MSDN 블로그 :
http://blogs.msdn.com/ie/archive/2008/03/03/microsoft-s-interoperability-principles-and-ie8.aspx

Microsoft 가 OS를 독점한 상황에서 독자적인 웹브라우저를 개발하던 이전 상황과는 달리 Mozilla 계열의 Firefox의 놀라운 성장세와 함께 더이상 웹표준을 외면할 수 없는 환경적 영향이 IE 의 개발 방향을 크게 바꾸었다고 생각됩니다.

IE8 이 기존의 정책을 바꾸어 웹표준에 친화적인 웹브라우저로 공개되긴 했지만, 앞날이 그렇게 순탄하지만은 않습니다. Netscape 가 존재하던 시절과는 달리, 강력한 오픈소스를 무기로 한 Firefox 3 가 버티고 있고, IE 외에도 웹표준에 최적화된 수많은 웹브라우저가 존재하기 때문이죠.

차후 웹브라우저 전쟁은 플랫폼에 관계없이 웹표준을 얼마나 잘 지키는지, 사용자를 위한 특화 기능을 얼마나 잘 지원하는지에 따라 승패가 결정될 거라고 생각이 됩니다. 이 상황에서 IE 도 기존의 독점적 자세와 지위를 버리고 정정당당히 다른 웹 브라우저와 경쟁을 벌여 좋은 소프트웨어로 발전하기를 바랍니다.

IE8의 새로운 기능을 살펴보겠습니다.
MIX08 컨퍼런스의 발표에서는 8번째 버전에 맞추어 8가지의 내용으로 IE8의 특징을 소개했습니다.  

• CSS 2.1
  Firefox, Safari, Opera 등의 기존 웹브라우저들과 마찬가지로 CSS2.1을 지원합니다.
• CSS Certification
  CSS2.1 스펙을 테스트하는 Acid2 Test를 통과했습니다.
• Performance
  자바스크립트 개발자라면 누구나 느낄법한 IE의 속도문제와 버그를 해결하여 타 브라우저 만큼의 퍼포먼스를 보여준다고 합니다. 실제 웹을 서핑한 결과 이전보단 체감적으로 빨라졌다는 느낌을 주고 있습니다.
• HTML 5 Start
  HTML5 스펙을 지원합니다. HTML5는 현재 초안(Working Draft) 작업이 진행중인데요, 일부 스펙의 지원을 시작했다고 언급하고 있습니다. (Ajax UI에서 뒤로/앞으로 버튼 액션 지원, 오프라인 후 컨텐츠 임시저장)
• Development Tools
  웹브라우저 내장의 개발툴로는 유명한 Firefox의 firebug가 있는데요, 이와 비슷한 강력한 개발 도구를 내장하였다고 합니다.
• Activities
  웹을 사용할 때 원하는 컨텐츠에 대해 빠르게 외부 서비스로 연결할 수 있는 기능입니다. 보통 필요한 정보가 있다면, 이를 마우스로 드래그하여 다른 서비스에서 붙여넣기 형태로 많이 이용하는데, 이 과정을 매우 쉽게 한 것이라고 합니다. 크게 "Look up" 과 "Send" 기능으로 나뉘는데 Look up은 해당 콘텐츠에 대한 타 서비스의 콘텐츠를 볼 수 있고, Send는 말 그대로 외부 서비스(ex. 블로그)로 보내는 것을 말합니다.
   
• WebSlices
  쉽게 말하면 RSS의 다른 개념이라고 말할 수 있는데요, 해당 웹페이지에서 제공하는 단편적인 정보들을 상단의 Favorite Bar에 등록하여 해당 정보의 최신 업데이트를 실시간으로 받아볼 수 있도록 하는 기능입니다. 마이크로포맷과 비슷하다고 보시면 될 듯 합니다.
   
• Download after keynote?
  특징은 아니지만, 해당 프리젠테이션이 종료된 후부터 IE8을 실제로 다운받을 수 있다고 하는 내용입니다. 실제로 현지시간 3월 5일 오후 12시 30분 즈음부터 다운로드 서비스를 개시했다고 합니다.

이외에도 프리젠테이션에서 언급하지 않은 추가된 기능이 몇 가지 더 있습니다.

• 버전별 렌더링 엔진 지정
  기존 IE8개발정책 때문인지, 베타버전이기 때문에 존재하는 것인지 확실하지는 않지만, 메타태그를 통해 구 버전의 렌더링 엔진으로 웹사이트를 이용할 수 있도록 하고 있습니다. 또한 "Emulate IE7" 버튼을 통해 IE8 베타 버전이 아닌 기존 엔진을 디폴트로 사용할 수 있도록 배려하고 있습니다.
  개인적으로는 정식 IE8이 출시될 때는 이 기능이 사라졌으면 합니다. 만약 이 옵션이 그대로 존재한다면 웹표준에 맞지 않는데도 개선할 의지가 없는 웹페이지들이 IE8 정식 출시 이후에도 계속 존재할 가능성이 높을 것 같습니다. 
• 자동 크래시 복구 기능 (Automatic Crash Recovery)
  웹서핑을 하다보면 웹브라우저가 다운되는(죽는) 경우가 발생하는데요, IE8에서는 크래시가 발생한 탭에서 내용을 복구하여 볼 수 있도록 한 기능입니다. Firefox에서는 이미 지원하는 기능이죠.
  
• Safety Filter
  IE7 에서 지원하던 피싱 필터를 개선하여 "Safety Filter"라는 이름으로 추가되어 보안이 향상되었습니다.
• Favorite Bar
  IE7 에서 쓰였던 즐겨찾기 기능에서 더 확장되어 웹 콘텐츠 뿐만 아니라 링크, RSS피드, WebSlice, 오피스 문서(Word, Excel, Powerpoint)도 배치할 수 있습니다.
  
• URL 강조기능
  현재 접속하고 있는 사이트의 도메인과 경로를 구분하여 보여줍니다.
  

현재 IE8에 대한 프리젠테이션 영상은 Microsoft 사이트에서 실버라이트로 제공하고 있습니다. 앞으로 IE8에 대한 자료가 꾸준히 공개될 듯 하고 IE8에 대해 많은 기술적인 이슈가 존재할 듯 하네요.

프리젠테이션 영상 :
http://www.microsoft.com/presspass/events/mix/default.mspx

이 포스트는 NHN WSG(Web Standardization Guide) 블로그와 네이버의 개인 블로그에 함께 연재되고 있습니다.

Posted by 아마티

최근들어 MicroSoft 에서 개발중인 Internet Explorer 8 이 Acid2 test 를 통과했다던가, 새로운 웹표준 테스트로 발표된 Acid3 가 웹브라우저 시장에 좌절을 안겨주고 있다는 소식이 들려오고 있습니다. 특히 IE8 이 Acid2를 통과했다는 소식은 이제 IE도 악명높은 IE6 의 비정상적인 렌더링을 벗어나 웹표준을 잘 지킬 수 있지 않느냐 하는 희망을 주기도 했는데요…

그런데 과연 이 Acid 테스트라는 것은 무엇일까요?

Acid 테스트란 웹브라우저들이 웹 표준을 어느정도로 지원하면서 렌더링을 하는지 측정할 수 있도록 작성된 예제 페이지를 말합니다. 단 한장의 페이지에서 수많은 웹표준 스펙을 포함하고 있으며, 그래픽이 얼마나 잘 표현되는지의 결과를 통해 해당 브라우저의 웹표준 준수율을 한눈에 알 수 있도록 되어있습니다.
현재 Web Standards Project (WaSP) 에서 Acid Test 사이트를 운영하고 있으며, 1998년에 처음으로 Acid1 이 개발된 이후로, 2005년에 Acid2 를 거쳐 2007년에는 Acid3 가 개발되었습니다.


1. Acid1
http://www.w3.org/Style/CSS/Test/CSS1/current/test5526c.htm

웹브라우저 테스트용 페이지로 가장 먼저 개발된 Acid1 테스트는 CSS1 스펙을 중점적으로 테스트할 수 있습니다. 1998년에 개발되었던 페이지가 꾸준히 개선되어 왔으며 가장 최근 버전은 5.5.26.c 버전입니다. 현재 주로 쓰이는 웹브라우저에서는 무난히 통과하고 있구요. (IE6, IE7, FF2, OP9, SF2 등) 다만 IE5.5 버전 이하에서는 비정상적으로 렌더링되는 것을 확인할 수 있습니다.

2. Acid2
http://acid2.acidtests.org/

IE8 이 Acid2 test 를 통과했다고 알려지면서 대중에게 많이 알려지기 시작했지요. Acid2 는 HTML과 CSS2.1 스펙을 중점적으로 테스트를 합니다.
표준 CSS2.1 스펙을 완벽하게 지원한다면 위 이미지처럼 웃는 얼굴과 Hello World! 라는 문구가 나타나게 되어있으며, 코 부분을 마우스 커서를 가져가면 파란색으로 바뀌게 됩니다. 하지만, 현존하는 웹브라우저 중에는 이를 완벽하게 지원하는 브라우저가 많지 않은 실정입니다. IE6 은 물론이고 IE7 에서는 붉은색으로 가득찬 화면을 볼 수 있구요, 심지어 웹표준을 잘 지킨다고 인식되는 FireFox 2 에서도 렌더링이 제대로 되지 않는 모습을 보여주죠.
Acid2 테스트를 처음 통과한 브라우저는 맥의 Safari 입니다. 이후에는 Konquerer, Opera, FireFox3 beta 버전이 통과했구요, 최근에 개발중인 IE8 의 표준모드에서 이 테스트를 통과했다고 알려지고 있습니다.

Acid에서 체크하는 항목은 다음과 같습니다.

• Alpha transparency on PNG images – the eyes are transparent PNGs
• The object element
• Absolute, relative and fixed positioning using CSS
• The CSS box model
• CSS tables
• CSS margins
• CSS generated content
• CSS parsing – Acid2 includes a number of illegal CSS statements to test error handling
• Paint order
• CSS line heights
• Hovering effects 

Acid2 테스트의 소스가 어떤 구조로 되어있는지 궁금하다면 다음 가이드 페이지를 참조하세요!
http://www.webstandards.org/action/acid2/guide/

3. Acid3
http://acid3.acidtests.org/

가장 최근에 개발된 Acid3 test 는 HTML5 그룹의 리더인 Ian Hickson 에 의해 개발되었습니다. 자바스크립트로 작성되어 있으며, 이전 Acid1 과 Acid2 테스트를 종합적으로 체크하는 것은 물론이며 Web 2.0 을 위한 동적인 웹 애플리케이션을 만드는데 필요한 스펙을 중점적으로 체크합니다. 이전 테스트가 CSS스펙을 중점적으로 체크했기에 엄밀하게 말해서 웹표준을 테스트한다고 할 수는 없었는데요, Acid3 test 는 이전 테스트에 비해 한층 의미에 맞는 웹표준 스펙을 테스트한다고 볼 수 있겠습니다.
Acid3 test를 완벽하게 통과한다면 위 화면을 보여주게 되어 있는데요, 100개의 테스트를 수행하면서 통과한 테스트 수를 구체적으로 보여주기 때문에 테스트 결과를 객관적으로 볼 수 있도록 바뀐 것이 장점이라고 볼 수 있겠습니다.
현재로선 이 테스트를 제대로 통과하는 웹브라우저는 없다고 알려져 있습니다. 그나마 가장 높은 점수를 낸 웹브라우저는 FireFox3 beta3 버전이 59/100, Opera 9.5 beta 버전이 64/100, Safari 3.1 버전이 64/100 정도의 점수를 내고 있는 상황이지요.

Acid3 테스트에서 체크하는 항목은 다음과 같습니다.

• DOM2 Core
• DOM2 Events
• DOM2 HTML
• DOM2 Range
• DOM2 Style (getComputedStyle, …)
• DOM2 Traversal (NodeIterator, TreeWalker)
• DOM2 Views (defaultView)
• ECMAScript
• HTML4 (<object>, <iframe>, …)
• HTTP (Content-Type, 404, …)
• Media Queries
• Selectors (:lang, :nth-child(), combinators, dynamic changes, …)
• XHTML 1.0
• CSS2 (@font-face)
• CSS2.1 (’inline-block’, ‘pre-wrap’, parsing…)
• CSS3 Color (rgba(), hsla(), …)
• CSS3 UI (’cursor’)
• data: URIs

아직까지는 Acid3 테스트는 개발중으로 현재 Final Review 단계에 있다고 합니다. 과연 어떤 웹브라우저가 1등으로 100/100을 받게 될지 궁금하네요. ^^


과거의 웹브라우저 시장은 Internet Explorer 가 독점적인 시장 점유율을 바탕으로 웹 표준 스펙을 소홀히 해왔기 때문에, 개발자 입장에서도 어쩔 수 없이 IE 기준으로 왜곡된 웹페이지를 개발할 수 밖에 없었으며 사용자의 웹브라우저 선택의 폭도 좁아진다는 문제점이 있었습니다.
하지만 Web 2.0 시대에 들어서며 웹표준의 중요성이 강조되면서 IE를 제작해오던 Microsoft 도 더이상 웹표준을 외면할 수가 없게 된 현재의 상황은 IE도 이전보다 웹표준 스펙을 준수할 수 있도록 개발될 것이라는 기대를 할 수 있겠으며, 이는 개발자와 사용자 모두에게 좋은 영향을 줄 것이라고 생각됩니다.

웹표준이 만능은 아니겠지만, IE의 수많은 비표준 스펙에 휘둘려왔던 웹 관련 개발자라면 웹표준이 얼마나 반가운 존재인지 아실 분은 아시리라 생각합니다. 웹개발에 있어서도 표준적인 개발이 가능한 세상이 빨리 왔으면 좋겠습니다. ^^

이 포스트는 NHN WSG(Web Standardization Guide) 블로그와 네이버의 개인 블로그에 함께 연재되고 있습니다.

Posted by 아마티