화끈하고도 딱딱한 주제가 ‘블로터 포럼’ 대문에 걸렸습니다. ‘HTML5′랍니다. 기술 용어인 탓에 프로그래밍 지식이 없이 이해하는 데는 한계가 있을 겁니다. 그러니 딱딱한 주제이죠. 허나 HTML5는 요즘들어 몸값이 후끈 달아오른 따끈한 이슈이기도 합니다. 해가 바뀌면서 주목받는 기술을 꼽을 때면 빠지지 않는 단골이기도 하고요.

우연의 일치일까요. ‘블로터 포럼’을 진행한 뒤 애플 스티브 잡스가 때마침 제대로 한 방 날렸더군요. 아이폰에서 플래시를 지원하라는 어도비를 향해 ‘플래시 대안은 HTML5′라며 ‘어도비는 게으르다’고 심기를 건드린 겁니다.

왜 갑자기 여기저기서 HTML5를 외치는 걸까요. 특정분야 개발자들을 빼고는 대체로 비슷한 반응을 보입니다. HTML에 익숙한 사람도 HTML5 앞에선 꿀 먹은 벙어리마냥 얌전해집니다. 딱딱하고 어려운 게 사실이지만 알아두고 준비해야 할 기술. 이번 ‘블로터 포럼’에선 입문자 눈높이에 맞춰 HTML5를 들여다보고 싶었습니다.

  • 일시 : 2010년 1월27일(목) 오후 5시~7시
  • 장소 : SK커뮤니케이션즈 회의실
  • 참석자 : 윤석찬 다음커뮤니케이션 DNA랩 팀장, 도안구·이희욱·주민영 블로터닷넷 기자

이희욱 | 오늘 주제가 참 어렵다. HTML5 문외한 입장에서 궁금한 점이 많다. 먼저 묻고 싶다. HTML5가 뭔가?

윤석찬 | HTML5가 어느 날 갑자기 나타난 게 아니다. 사연이 길다. 1998년 HTML4.01 이후 웹표준을 개발하는 국제 컨소시엄인 W3C는 XHTML 표준 개발에 박차를 가했다. 웹브라우저 전쟁 이후 그 작업에서 웹브라우저 제조사들이 빠졌다. 이후 웹표준의 방향은 XML을 기반한 꽤 이상적인 표준을 만들기 시작했다. 2004년 파이어폭스가 나오고 아작스(Ajax)와 웹2.0이 활성화되면서 문서가 아닌 웹애플리케이션을 위한 웹표준의 재정비가 필요했다.

하지만 이러한 현실적 요구를 W3C가 받아들이지 않았다. 웹브라우저 제조사들에게는 W3C의 XHTML2.0과 XML기반 DOM 및 이벤트 핸들러 등은 루비콘 강을 건너는 것이다. 당시 XHTML 문서가 전체 웹에서 5%에 불과했고 웹브라우저 엔진들의 차이 탓에 개발자들은 ‘크로스 브라우징’에 생고생을 하고 있었다. 2004년 W3C의 한 워크샵에서 서로 틀어진 뒤 모질라와 오페라, 애플과 구글은 별도의 ‘웹 하이퍼텍스트 애플리케이션 테크놀로지 워킹그룹’(WHATWG)이라는 공개 표준 그룹을 만들고 새로운 HTML 표준안을 만들기 시작했다. 이것이 바로 HTML5의 시초다.

도안구 | W3C와 웹브라우저 제조사 사이에 그런 의견 다툼이 있었나? 흥미롭다.

윤석찬 | 반목이 오래가지는 않았다. 2006년 팀 버너스 리 경이 ‘리인벤팅 HTML’(Reinventing HTML)이라는 글을 쓰고 WHATWG을 W3C 안으로 받아들이기로 결정하면서 2007년초께 다시 W3C에 HTML 워킹그룹이 결성됐다. 당시 재미있는 에피소드라면 WHATWG의 개방적 표준 활동에 참여하던 700여명 멤버들이 W3C 안 초청 전문가(Invite Expert) 형식으로 대거 들어왔다는 점이다. W3C 역사상 초유의 일이다. 그 때 나도 함께 했다.

기존 WHATWG 표준 초안을 가져오며 ‘HTML5′라 불렀다. 당시 IE7 개발을 맡았던 MS 유명 아키텍트인 크리스 윌슨이 워킹그룹 의장이 됐고 모질라, 오페라, 애플, 구글 등 모두 참여해 HTML5 표준을 만들고 있다.

주민영 | 복잡한 과정을 거쳤다. HTML5는 왜 만들어지게 됐나?

윤석찬 | 기존 웹브라우저들이 제공하는 웹표준 수준이 조금씩 다르고 기존 스펙의 모호성으로 인해 버그도 많다. 제조사마다 다른 렌더링 엔진을 쓰고 당연히 차이가 있다. 웹 개발자들은 각각 테스트해봐야 하는 어려움이 있다. 이를 해소하기 위해 HTML5의 새로운 문서 형식 제안하고, 이 독타입(DOCTYPE)을 사용할 경우 기존 엔진 문제점들을 고쳐 제공해줘 웹 개발자들을 고생에서 벗어나게 해주자는 취지다.

HTML5 독타입은 매우 간단하다. ‘< !DOCTYPE HTML >’ 이렇게 HTML 파일 맨 앞 줄에 넣어주면 끝이다. 이 뒤에 나오는 코드는 웹브라우저마다 HTML5에 맞춰 렌더링한다. HTML5 표준 초안은 웹브라우저 엔진 개발자들을 위해 만든 것으로, 보다 상세하게 구현 내용을 적고 있다.

두 번째 목적은 동적 웹애플리케이션을 지원할 리치 웹 기술을 담고 있다는 것이다. 멀티미디어를 다루는 ‘canvas’, ‘video’, ‘audio’ 태그를 비롯해 웹브라우저 내 로컬 스토리지를 다루는 돔 API와 드래그앤드롭 API 등 일반 표준 문서에서는 보기 힘든 다양한 기술이 뒤섞여 있다. 특히 웹 개발자 수고를 덜어줄 ‘웹폼2.0′이라는 표준과 함께 쓰면 보다 멋진 리치 웹애플리케이션을 만들 수 있다.

웹브라우저 안에 DB를 탑재해 로컬 스토리지로 활용해 오프라인에서도 데이터를 싱크해 활용할 수 있다. 구글 G메일 ‘오프라인’ 기능이 그렇게 구현돼 있다.

이희욱 | 리치 웹애플리케이션이라면 플래시나 실버라이트를 얘기할 때 자주들 언급한다. HTML5가 리치 웹에 주목하는 이유는 무엇인가?

윤석찬 | 웹브라우저 업체 입장에서 리치 웹 기술에 관심을 갖는 이유는 다양하다. 제가 참여하고 있는 모질라 커뮤니티의 경우, 웹은 읽을 수 있고(readable), 저장할 수 있고(Indexable), 편집할 수 있어야(editable) 한다고 믿는다. HTML 소스를 보고, 복사를 하고, 고칠 수 있었기 때문에 웹 문서가 비약적인 성공을 했다. 기존 플러그인 기반 리치 웹 기술들, 예컨대 플래시나 실버라이트는 그게 어렵다. 물론 이들도 XML 기술을 통해 이용자화면(UI)을 만들 때 스크립트 언어로 동작을 제어한다. 하지만 결국 읽을 수 없는 ‘바이너리’를 포함하고 있다. 이는 웹 본질과 일치하지 않는다. HTML5가 리치 웹 기술의 선택 가능한 대안으로 자리잡아야 한다.

물론 아직 플래시나 실버라이트에 비해 HTML5가 제한 사항이 많다. 하지만 궁극적으로 웹이 나아갈 방향이라고 본다. 구글이나 오페라와 애플도 이러한 점에 동의를 하고 있고 MS 역시 미온적이지만 참여를 하고 있다. 초창기 많은 사람들이 ‘리치 웹 환경에서 HTML5가 성공할 것인가’라는 물음엔 회의적이었다. 지금은 많이 바뀌었다. 이런 ‘블로터 포럼’에도 불려다니는 걸 보면. (웃음)

도안구 | HTML5가 주목 받게 된 특별한 계기나 사건이 있나?

윤석찬 | 아무래도 구글 영향이 컸다. 지난 2009년 4월에 열린 ‘구글 I/O 컨퍼런스’가 전환점이 됐다. 구글은 2008년 첫 구글 I/O 컨퍼런스에서 안드로이드와 구글 기어스를 발표했다. 구글 기어스는 리치 웹애플리케이션을 만들기 위한 웹브라우저 플러그인이었다. 하지만 2009년 컨퍼런스에선 구글 CTO가 첫날 주제로 HTML5를 다루고, 둘쨋날 구글 웨이브를 다뤘다. 그런데 첫날 HTML5를 얘기하면서 ‘HTML5가 대세’란 분위기를 크게 조성했다. 자사 웹브라우저인 ‘구글 크롬’에도 아직 탑재 안 된 HTML5 기술을 파이어폭스와 사파리로 시연할 정도였다. 그러면서 인식이 많이 바뀌었다. 구글이 드디어 HTML5에 베팅하는구나. 시장에도 긍정적인 신호를 줬다.

특히 모바일을 보면 완전히 다르다. 지금 PC의 웹브라우저 시장은 IE가 다수이고 파이어폭스, 크롬, 사파리가 따라오는 모양새다. 모바일 웹에서는 유럽 스마트폰 시장은 오페라가, 아이폰은 사파리를 기반하고 있다. 안드로이드폰이 나오면 크롬이 주력으로 들어간다. 모질라를 빼도 메이저 3사다. 결국 IE가 대세가 아니다. 모바일 애플리케이션 개발 환경은 PC 못지않게 폐쇄적이다. 이런 상황은 오래 가지 않을 것이고, 결국 범용 리치 웹 환경을 사용하는 것으로 바뀔 것이다. 특히 모바일 웹의 변화가 더욱 빠를 것 같다.

주민영 | 허나 애플 아이폰이 촉발시킨 앱스토어도 개발자 입장에선 큰 기회다.

윤석찬 | 물론 지금은 앱스토어가 유행이다. 돈벌이가 아니라 서비스를 만드는 관점에서 보면, 지금은 앱스토어용 따로, 웹애플리케이션 따로 만드는 식으로 과도기다. 결국 HTML 표준으로 웹 문서를 만들듯 웹애플리케이션도 표준으로 쉽게 만들고 서비스하는 환경이 와야 한다. 폐쇄적인 개발 플랫폼을 기반으로 하는 플레이어도 필요하지만 모두에게 이익이 되는 범용 개발 환경이 웹의 목표이고 지향하는 바다. 웹 개발자들은 이를 간과하면 안된다.

이희욱 | HTML5는 그럼 웹 개발자들을 위한 표준 기술 문서인가?

윤석찬 | 앞서 말했듯이 HTML5는 웹브라우저 엔진 개발자를 위한 스펙이다. 하지만 이 안에는 렌더링 엔진 뿐만 아니라 중요한 리치 웹 기술이 포함돼 있다. 예컨대 크롬이 탭마다 적용한 병렬 프로세스 기능이나 외부와 데이터를 주고받을 때 웹브라우저가 어떻게 처리할 지 규약도 있고, 데스크톱에서 웹브라우저로 드래그앤드롭한 파일을 어떻게 처리할 지에 관한 스펙도 있다. HTML 뿐 아니라 방대한 내용들이 추가되고 있다. 초안 자체가 어렵기 때문에 웹 개발자들이 이를 쉽게 이해하고 이용할 수 있도록 설명 문서들도 함께 만들고 있다.

도안구 | 그 스펙은 계속 추가되고 실제 구현되고 있나?

윤석찬 | W3C 표준 제정 과정을 보면, HTML5는 현재는 초안 단계다. 한 단계 넘어가기 위해 준비 중이고 이는 정해진 내부 프로세스를 따라가는 것이다. 무엇보다 중요한 건, HTML5의 어떤 기술이 웹브라우저에서 구현되고 있고 얼마만큼 사용할 수 있느냐 하는 점이다. 현재 PC 기반 웹브라우저에서 HTML5의 주요 기능을 쓰는 데는 아직 무리가 있다.

가장 중요한 건 IE가 아직 안 바뀌었고, 각 웹브라우저 제조사 사이에도 기술적 차이가 있다. 하지만 ‘canvas’, ‘video’, ‘audio’ 태그와 돔 스토리지 등은 어느정도 쓸 수 있는 단계에 와 있다. 올해 초 MS가 공식적으로 IE9에서 HTML5를 지원하겠다고 밝혔다. 어느 정도까지 지원할 지 모르겠지만, 올 3월 MIX에서 HTML5 기능을 탑재한 IE9을 만나볼 수 있을 것으로 기대한다.

주민영 | 유튜브비메오 같은 동영상 공유 사이트가 플래시 대신 HTML5를 수용하겠다고 해서 화제가 되기도 했다.

윤석찬 | 유튜브나 비메오 등이 수용한 건 HTML5의 일부다. ‘video’ 태그를 이용해 플러그인 도움 없이도 웹브라우저 만으로도 동영상을 서비스할 수 있다. 지금까지는 윈도우 미디어 플레이어나 플래시 플러그인을 깔아야만 가능했다. 문제는 동영상 코덱에 있다. 파이어폭스와 오페라는 오픈소스 기반 OGG 테오라(OGG Theora)를 지지해왔다. 하지만 크롬과 사파리는 특허료를 내야하는 H.264 MPEG 포맷을 지원한다. 유튜브와 비메오도 H.264 코덱을 지원하기 시작했다. 이 때문에 파이어폭스도 H.264 코덱을 지원해야 한다는 여론이 일었다. 이에 대해 모질라 제품담당 마이크 셰이버는 거부 의사를 분명히 했다.

파이어폭스가 H.264 코덱을 이용하는 데 1년에 500만 달러 정도의 특허료를 지불해야 하다. 모질라 입장에서 그리 큰 돈은 아니다. 하지만 문제는 이를 통해 서비스 개발자 및 업체 모두 2011년부터 특허료를 내야 한다. 이는 선택 가능한 대안을 중요시하는 모질라의 미션과 배치되는 것이다. 코덱은 물론 웹의 영역은 아니다. 하지만 플러그인들이 오픈웹에 큰 걸림돌이 되듯, 폐쇄형 코덱은 오픈 비디오 환경에 도움이 되지 않는다고 판단한다.

이희욱 | 그럼 유튜브 HTML5 비디오 태그와 파이어폭스의 연동은 영영 안 되는 건가?

윤석찬 | 가능성은 있다. 구글이 지난해 8월, 동영상 코덱 업체 ‘온투(On2) 테크놀로지’를 인수했다. 구글이 온투 코덱을 오픈소스와 특허 무료로 공개하는 거다. 온투 코덱은 플래시와 호환된다. 이러한 계획은 이미 구글도 밝힌 바 있다. 테오라 역시 온투의 과거 버전이 오픈소스화 된 것이다. 오픈 비디오 환경은 이래저래 구글의 결정에 큰 영향을 받게 될 것이다.

주민영 | 그럼 국제적으로 HTML5가 널리 퍼지고 있는가?

윤석찬 | 사람들이 잘 모르는 게 있다. 구글 첫 화면에서 소스코드를 열어보라. HTML5 독타입이다. 예전 HTML 4.01 독타입을 쓰다가 지난해 하반기에 바뀌었다. 그렇다고 밑에 코드들이 마크업 유효성에 다 통과된 것은 아니다. 하지만 한 발걸음이 중요하다.

2005년쯤 다음이 첫 화면을 W3C 인증을 통과한 웹표준으로 바꾼 적이 있는데, 당시 많은 사람들이 첫 화면만 웹표준을 적용하면 뭐하냐는 반응들을 보였다. 회사 내부에서 선언적으로 첫화면을 바꿈으로서 모든 웹서비스에 영향을 줘, 많은 것이 바뀌었다. 구글 내부에서도 이러한 움직임이 계속될 것으로 보인다. 그런 리더십이 업계 전반에 영향을 준다.

도안구 | 국내 웹사이트들의 HTML5 도입 현황은 어떤가?

윤석찬 | 아직까지 국내에서는 HTML5에 대한 웹 개발자들의 관심이 높지는 않다. HTML5 독타입을 쓰면 표준 모드로 동작하므로 사용해도 지장은 없다. 우선 HTML5에 대한 문서자료와 HTML5갤러리HTML5닥터 웹사이트에서 다양한 예제를 살펴보고, 가능한 것부터 해보는 것이 좋겠다.

이희욱 | 그럼 XHTML은 더 이상 개발 되지 않는 것인가?

윤석찬 | 그렇지 않다. 물론 XHTML 2.0 표준 개발은 완전히 멈췄다. 지난해에 그룹이 해체됐다. 하지만 XHTML의 유용성은 그대로 있기에, HTML5 문서를 XHTML로도 표현할 수 있고 이를 위한 독타입을 선언하면 그대로 XHTML 문서로 유효하다. 이를 ‘XHTML5′라고 부른다. XHTML은 여전히 HTML5 안에서 유효하다.

주민영 | HTML5가 산업에 미치는 영향은 어떨 것으로 예상하나?

윤석찬 | 가장 큰 수혜자는 기존 웹 개발자다. 요즘 모바일 애플리케이션 개발자는 중고 매킨토시를 산 뒤 코코아 개발환경을 익혀 앱스토어에 애플리케이션을 올리고, 안드로이드 애플리케이션 개발자는 자바를 배워야 한다고들 말한다. 하지만 자신이 가진 웹 기술에 조금만 더 보태면 감탄할 만 한 리치 애플리케이션을 만들 수 있다. 예컨대 ‘R그래프‘란 서비스를 보면 HTML5를 기반한 각종 비주얼 차트를 서비스 안에 넣을 수 있다.

그러니 웹 프론트엔드 개발자가 더 많은 생각을 갖고 HTML5를 적용하는 노력을 기울여야 한다. 그게 결국은 자기에게 보답으로 돌아온다. 전세계에 제공되는 범용 웹브라우저 기반으로 웹애플리케이션을 만들면 모든 개발자가 수혜를 받는다. 결국 이게 정석이다.

웹 산업에서 대형 주자가 폐쇄된 개발 환경과 플랫폼에서 비즈니스하는 것은 당연하다. 좋은 이용자경험(UX)을 주는 것은 칭찬할 만 하다. 중요한 것은, 선택 가능하고 범용적인 웹 기반 플랫폼도 제공돼야 한다. 표준은 죽기도 하고 산업에 밀리기도 한다. 100% 올바르지도 않다. 하지만 없는 것 보다는 낫다.

이희욱 | HTML5 확산을 위한 과제가 있다면?

윤석찬 | 국내에서는 일단 HTML5가 대형 포털이 적용할 만큼 매력이 있느냐의 문제가 있다. 국내에서 이용하는 대다수 웹브라우저가 아직 지원하지 않는 부분이 있기 때문이다. 파일럿 서비스나 모바일 웹 서비스를 준비하는 사람은 HTML5를 적용해보면 좋겠다. 아이폰용 웹 페이지를 만들 때 ‘video’나 ‘canvas’ 태그 혹은 오프라인 스토리지 기능을 이용하는 아이디어를 내야 한다. 천편일률적인 모바일 페이지는 식상하다. 기왕이면 모바일 웹페이지를 만들 때 ‘엣지있게’ 만들면 좋잖나.

만약 누군가 ‘canvas’ 태그를 이용해 그림을 그리고 이를 공유하는 서비스를 모바일 웹서비스로 만들었다 치자. 그는 회사에서 인정받는 사람이 될 수 있다. 그런 점들에 개발자가 좀 더 신경쓰면 좋겠다. 스스로 찾고 배워서 도전해 봤으면 한다.

이희욱 | 새롭고 흥미로운 얘기들을 많이 들었다. 아직은 어렵고 낯선 면이 많다. 리치 웹을 플러그인 없이 구현할 수 있는 기술을 내장했다는 얘기가 기억에 오래 남는다. 웹 개발자분들이 좋은 기회로 활용했으면 하는 생각이 든다. 새로운 정보들도 자주 알려주시길 기대한다.


♣ 자료출처 : 블로터포럼


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

breadcrumbs

News/Web Develop 2008. 9. 1. 09:56

오라클 문서 보다가 발견한 단어.
일반 사전에서는 저 단어의 뜻이 '

빵 부스러기

'라고...
빵 부스러기는 '헨젤과 그레텔'에서 나와야지 왜 오라클에 있냐고;
조금 더 검색해보니 소프트웨어 용어라는 것을 알 수 있겠더군.
단계별 구성 메뉴 등에서 현재 위치를 표시하여 상위 레벨로도 쉽게 이동할 수 있게 하는 편리한 기능.
소프트웨어 계의 어른들이 동화 교육에도 소홀치 않았던 모냥..

Like this:

사용자 삽입 이미지


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,
개인 홈페이지를 만들어 보았던 사람들 중에 HTML을 공부해 보지 않았던 사람은 아마 없을 것이다. HTML은 정보(콘텐츠)와 의미(마크업)를 함께 손 쉬운 텍스트로 편집할 수 있어 쉽게 배우고 쓸 수 있었다. 글꼴을 굵게 하려면 <b>굵게</b>,

제목

을 표시하고 싶으면 <h1>제목</h1>이라고 적기만 하면 된다. HTML의 이런 단순함은 웹 상에 사람이 참여하는 토대를 낳게 하기에 충분했다.

하지만 이러한 장점에도 불구하고 90년대 후반 웹 브라우저 업체의 점유율 전쟁 중에 상용 비표준 태그들이 남발되면서 HTML의 기본 정신을 훼손했는가 하면 웹 표준 기구인 W3C도 기계도 이해할 수 있는 완벽한 형태인 XML 전향을 기반으로 XHTML로의 전환을 꾀하였다. 따라서 HTML은 4.01 버전을 끝으로 더 이상 업그레이드 되지 않는 낡은 표준으로 남았다.

2000년대 초반 인터넷 익스플로러가 넷스케이프를 물리치고 웹 브라우저 왕좌에 오르고 난 후 웹 디자인 업계는 안정되는 것 처럼 보였다. 사실 상 웹 프론트 기술은 더 이상의 혁신은 일어 나지 않았고 HTML은 단순 기술로 남아 있었다. 최근 들어 구조와 표현을 분리하는 웹 표준 기반 웹디자인이 부각되면서 CSS 기반 기술이 뜨고 있기는 하지만 여전히 HTML은 하급 기술이다.


웹 애플리케이션 전성 시대

그러나 변화는 일어 나고 있었다. 혁신의 단초를 제공하게 된 것은 웹2.0이다. 특히, 블로그나 위키피디아와 같은 사용자 생산 콘텐츠를 담기 위해 '플랫폼 웹'이 지향하는 소프트웨어형 서비스가 늘어나고 있다. 웹을 기존의 문서 형식의 정보의 제공이라는 틀에서 벗어나 데스크톱 소프트웨어와 같은 기능을 제공하고 상호 연결성을 기초로 협업 작업 및 공유 기능을 첨가한 사용자 기반 웹 애플리케이션이 뜨고 있는 것이다. 이에 대한 대표적인 성공 사례가 Ajax를 기반한 구글 맵스와 지메일이다.

특히 자신들의 데이터를 XML이라는 표준 포맷으로 전달해 주는 '오픈 API'라는 기술을 제공하면서 전문 개발자 뿐만 아니라 전문 사용자까지 웹 플랫폼에 끌어 들임으로서 사람들이 사용하기 쉽고 편한 기술의 우수성을 다시 한번 입증해 주고 있다. 오픈 API를 이용하면 자신의 블로그나 홈페이지에 네이버나 다음의 검색 결과나 구글 맵의 위성 지도, 이베이의 중고 상품 목록 같은 것을 쉽게 추가할 수 있다.

뿐만 아니라 다양한 소프트웨 플랫폼 벤더들은 공개 표준 기술을 웹 애플리케이션에 접목하는 시도를 계속 하고 있다. XML과 (X)HTML, CSS, 자바 스크립트 같은 웹 표준 기술들을 웹 애플리케이션을 만드는 데 사용하기 시작한 것이다. 대표적으로 모질라의 파이어폭스 확장 기능, 야후! 위젯, 마이크로소프트의 실버라이트(Silverlight), 어도비의 플렉스(Flex) 및 AIR 등이 여기에 속한다. 애플의 경우, Mac OS의 대시보드 위젯을 시작으로 사파리에서 구동 가능한 웹 애플리케이션을 최근 출시한 아이폰(iPhone)에서도 실행 할 수 있도록 하고 있다.

이들 응용 소프트웨어의 대표적인 특징은 XML 혹은 (X)HTML로 사용자 인터페이스를 만들며 CSS로 디자인 및 스타일을 정의하고 자바 스크립트로 기능을 제어 하는 전형적인 웹 기술의 성공을 벤치마킹했다는 데 있다.


HTML5의 탄생


이런 와중에 웹 사이트를 이용하는 기본 도구인 웹 브라우저 업계의 변화 역시 시작 되었다. 깨질것 같지 않았던 인터넷 익스플로러의 아성이 2004년 한 오픈 소스 웹 브라우저에 의해 금이 가기 시작한 것이다. 현재 모질라 파이어폭스의 세계 점유율은 약 15%, 유럽의 경우 30%가 넘어섰다. 또한, 오페라 브라우저 역시 구글과의 제휴로 무료 배포를 시작 했고 애플도 새로운 Mac OS와 사파리 브라우저를 선 보이면서 자신들의 영역을 구축 했다. 이로서 지금 웹 브라우저 업계는 제 2의 브라우저 전쟁에 돌입한 상태다.

사실 상 앞서 말한 웹 애플리케이션의 변화에는 이러한 마이너 웹 브라우저 업체의 혁신에 힘입은 바 크다. 하지만, 웹 표준화 기구인 W3C는 이러한 변화를 수용할 준비를 하고 있지 못했다. 2004년 W3C의 한 워크샵에서 부터 생긴 의견 차이 때문에 모질라, 애플, 오페라 등은 W3C 밖에서 새로운 버전의 HTML 표준을 준비하기 시작했다. W3C의 비대한 조직과 시맨틱 웹과 상호 운용이라는 너무 거대한 이상 때문에 현실 웹의 변화에는 거의 관심 없는 상태였다.

이들은 WHATWG라는 공개 그룹을 형성하여 자신들이 만드는 새로운 표준안에 누구나 참여할 수 있도록 개방 하였다. W3C의 회원사 중심 표준안이 아닌 업계가 진정 원하는 바를 만들기 위해서 였다. 이들은 오랜 공개 토론을 거쳐 Web Form 2.0과 Web Applications 1.0이라는 표준안을 만들어 냈다.

이들 표준안의 철학은 아직 전 세계 웹 사이트의 90%가 넘는 언어인 HTML을 혁신하자는 것이다. 웹 브라우저 업체 입장에서 W3C가 요구하는 새로운 웹 표준은 기존 웹 브라우저를 새로 작성해야 할 정도로 어려운 작업이라는 측면도 있지만 기존 HTML이 가진 가치를 끌어 올려 최대의 효과를 거두자는 데 있다. 즉, 손 쉬운 HTML의 장점은 그대로 살리면서 브라우저 업체간 불명확했던 처리 방식을 재정의하고 CSS와의 상호 관계를 최대한 맞추면서 웹 애플리케이션 개발에 손 쉬운 각종 기능들을 추가하는 것이다.


HTML5, 무엇이 달라지나?


WHATWG 활동의 성공은 즉각 W3C에 영향을 주기 시작했다. 작년 10월 웹의 창시자이자 W3C를 이끌고 있는 팀 버너스 리(Tim Berners-Lee)는 'Reinventing HTML'이라는 글에서 XHTML의 전환 실패와 더불어 새 HTML 작업을 시작할 것을 천명하였다. 이에 제 3지대에서 활동하고 있던 WHATWG의 멤버들은 W3C의 결정에 환영하면서 올해 3월 새로운 HTML 워킹 그룹에 합류하기 시작했다.

이 워킹 그룹 활동에는 몇 가지 고무스러운 점이 있다. 먼저 전직 IE 개발자 이며 최근 마이크로소프트의 IE7 이후의 개발을 총책임을 맡은 크리스 윌슨(Chris Wilson)이 워킹 그룹 의장이 되었다는 점이다. 또한, WHATWG의 표준 작업을 사실상 주도한 이안 힉슨(Ian Hickson)이 첫 표준 초안의 편집자가 된 것이다. 이안은 넷스케이프와 오페라를 거쳐 지금은 구글에서 풀타임 표준 작성가로 활동 중인 젊은 인재이다. 뿐만 아니라 초빙 전문가(Invited Expert)라는 제도를 활용해서 W3C에서는 유래가 없는 500여명의 비회원사 전문가들이 참여하는 통로를 열었다. 이러한 과감한 변화를 통해 W3C의 새 HTML 워킹 그룹은 새 표준의 이름을 'HTML5'라고 명명 하고 WHATWG가 작업하던 대부분의 표준안을 그대로 수용하기에 이른다.

HTML5에서 크게 달라지는 점은 크게 세 가지 이다. 먼저 웹 브라우저 마다 기존의 HTML을 해석하는 방식의 차이에서 오는 혼란을 없애기 위해 구현 방식을 상세하게 기술한 점이다. 기존 HTML의 하위 호환성은 제공하면서 <!doctype html>라는 새로운 DOCTYPE을 가진 경우 각 요소와 속성에 대한 웹 브라우저의 동작 방식이 명확하게 정의했다. 전체 표준안의 상당 부분이 여기에 해당한다.

두 번째는 새로운 HTML 요소를 대거 도입하고 콘텐츠 구조에 불필요한 요소와 속성들을 제거 했다. 웹 문서를 구조적으로 제공 가능한 <header>, <nav>, <footer> 같은 태그 등을 포함하였고 시간, 측정 단위 등 의미를 살린 <time>, <m> 태그 등이 추가 되었다. 대표적인 스타일 요소인 <font>, <strike>와 align이나 background, bgcolor 같은 속성은 더 이상 사용할 수 없다.

HTML5에서 달라지는 가장 대표적인 특징은 웹 애플리케이션 개발용 스펙들이다. 가장 대표적인 것이 Web Form에서 다양한 속성들을 추가한 것이다. <input> 태그에 datetime 속성을 넣어주면 웹 브라우저가 자동으로 달력을 표시해 준다. 또한 IE에서만 사용 가능 했던 contenteditable 속성이 표준화 되어 모든 HTML 요소를 사용자가 직접 편집할 수 있게 된다. 특히 innerHTML, embed 같이 많이 사용하면서도 비 표준 영역에 있었던 것들이 대거 포함 된다.

뿐만 아니라 HTML 요소의 드래그앤 드롭, 오디오 비디오 표시, 벡터 그래픽 표시를 위한 각종 요소들을 새로 도입 했다. 그러면서도 <b>, <i> 같은 대표적인 HTML 요소는 없애지 않고 각각 제품명 키워드 같은 강조 요소와 동식물 학명 같은 이탤릭체에 사용하도록 재정의 했다. HTML4와 HTML5 차이점 및 변경 사항은 W3C 기술 노트 번역본 을 참고하면 된다.


HTML5의 미래


많은 사람들이 HTML5에 대해서 회의적인 시각을 가지고 있는 것을 자주 본다. 그 대표적인 이유가 W3C 표준안이 되었다 하더라도 웹 브라우저에 적용되는 시기는 매우 오랜 기간이 걸릴 것이라는 이유에서다. 그래서인지 이러한 표준안의 변화에 관심 가지는 국내 인터넷 업체나 사람들은 거의 없는 실정이다.

하지만 현실은 그렇지 않다. 이미 HTML5의 많은 기능들이 파이어폭스 2.0과 오페라 9.0에 탑재되어 있으며 올해 안으로 출시될 파이어폭스 3.0에도 많은 기능을 포함하고 있다. 오페라와 사파리의 신 버전에도 관련 구현 작업이 진행 되고 있으며 무엇보다도 마이크로소프트가 참여하고 있기 때문에 차세대 IE8에서 HTML5의 기능 탑재는 기정 사실화 되고 있다. 우리가 신 기능이 탑재된 브라우저를 볼 날이 이제 머지 않았음을 보여 주는 대목이라 하겠다.

W3C의 첫 표준 초안(Working Draft)는 올해 8월을 목표로 막바지 작업을 진행 하고 있고 늦어도 2010년 하반기에는 표준 권고안(Recommendation)으로 만들 예정이다. 웹 브라우저 벤더가 모두 참여한 상태에서 과거의 관례를 살펴 본다면 표준 초안이 만들어 지면 구현이 이미 시작된다고 보면 맞다. 따라서 향후 1~2년 내에 HTML5 표준안을 탑재한 브라우저들을 실제로 보게 될 것이다.

이러한 변화에도 불구하고 현재 국내에는 Ajax, 마이크로소프트 실버라이트, 어도비 AIR 등 각종 리치 인터넷 기술이 웹 애플리케이션의 미래인 듯 포장되고 있는 감이 없지 않다. SW 플랫폼을 기반한 리치 인터넷이 차세대 웹의 전부인양 상용 벤더들의 홍보가 과도하게 진행 되고 있다. 하지만 우리가 우를 범해서는 안되는 것이 웹은 정보 전달의 수단으로 기본에 충실하면서 애플리케이션 기능을 제공할 수 있어야 한다는 점이다. 사용자 경험은 담보로 기존 웹의 장점들을 낡은 기술로 치부해서는 안 된다.

이는 브라우저 벤더들의 몫만이 아니다. 누구나 정보와 기능 모두를 제공할 수 있도록 웹의 콘텐츠를 만들고 생산하는 모든 저작자들과 리치 웹 서비스를 만드는 사람들의 책임이다. HTML5가 중요한 것은 이러한 표준 웹의 근본적인 변화가 시도되고 있기 때문이다. 지금이야 말로 우리가 함께 만들어 왔던 웹의 미래를 직면하게 되는 순간이다.@


♣ 자료출처 : 윤석찬 (다음 R&D 센터 팀장)

WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,
소프트웨어 프로젝트가 실패하는 이유에는 수많은 원인들이 있다. 가장 고전적인 원인을 꼽는다면 ‘잘못 결정된 프로젝트 기간과 비용’일 것이다. 또는 요구사항을 제대로 파악하지 않았거나 빈번하게 수정했기 때문일 수도 있고, 주요 이해관계자의 참여 또는 경영층의 지원이 부족했거나, 제대로 된 프로젝트 계획을 작성하지 않았기 때문일 수도 있다. 그것도 아니면 프로젝트 또는 조직 내부의 정치적인 문제 때문일 수도 있다.

어떤 최악의 프로젝트에서는, 그 모든 요인들이 결합해서 나쁜 시너지를 만들어내고 그 결과로 참담한 상황을 맞이하기도 한다. 프로젝트에 나쁜 영향을 미치는 모든 요인들에 대해 살펴보려면 엄청난 지면이 필요할 것이다.

이번 컬럼에서는 가장 중요한 실패 원인 중 하나이지만 잘 거론되지 않는 사실을 하나 소개해 보겠다. 그것은 바로 프로젝트 매니저, 아키텍트의 역할을 혼동한 나머지, 잘못한 책임을 부여하는 것이다. 즉 관리 책임과 기술 책임을 구분하지 않는 문제인데, 가장 중요한 인적자원에 오류가 있는 것이어서 프로젝트의 근본적인 실패 원인으로 작용하게 된다.

현재의 상황을 살펴보자. 먼저, 지금 당장 아무 구인구직 사이트든 가서 확인해보라. 다음과 같은 글을 쉽게 만날 수 있을 것이다.

[PM 모집: 자격 요건은 다음과 같음]
C/C++, Java, DBMS를 능란하게 구사 가능해야 함
UML 등을 활용한 설계 능력이 뛰어나야 함
고객과의 원활한 의사소통 및 협상이 가능해야 함
교육 및 프레젠테이션 스킬이 뛰어나야 함
소프트웨어 프로젝트의 관리 능력이 능숙해야 함
기술사, PMP, CISA 등의 자격증 우대


위와 같은 사람을 구하려고 한다면 장담컨대 거의 확실하게 구할 수 없을 것이다. 우리 업계에 그런 스펙을 갖춘 사람도 드물지만, 그런 사람이 있다고 하더라도 구인 업체에서 어떻게 평가하고 판단할 수 있겠는가? 또한 충분한 대우는 가능할까?


멀티 플레이어에 대한 무지 또는 욕심

프로그래밍 능력의 경우 면접 시 테스트 프로그래밍을 통해 어느 정도 평가를 할 수도 있겠지만, 설계 능력과 관리 능력의 경우 테스트 자체가 거의 불가능하다.

위와 같은 사람을 구하는 것은 그저 업체의 욕심일 뿐이다. 프로그래밍 능력, 설계 능력, 관리 능력을 모두 갖춘 그런 자원이 거의 없는 것이 국내 업계의 현실이다. 개인 탓이 아니라 시대가 그렇다.

기술 쪽을 살펴보면, 지금은 코볼로 개발을 하던 1980년대가 아니다. 그때에는 코볼 하나만 알면 모든 것이 해결되었지만 지금은 알아야 할 것이 너무 많다. 관리 쪽도 만만치 않다. 비즈니스 환경을 전반적으로 이해해야 하고, 정치력도 필요하고, 문서 작성, 프레젠테이션을 잘 해야 하는 등 고도의 스킬이 필요해졌다. 그리고 관리와 기술은 서로 다른 분야이다.

하지만 주요 인적자원의 실제 업무를 이해하지 못한 채로, 멀티 플레이어(또는 업계 용어로 올라운드 플레이어)를 뽑으려고 노력하는 업체들이 참으로 많다. 그것은 무지 또는 욕심. 둘 중의 하나이다.


잘못된 역할 배정의 문제

위에 예를 든 구인 공고를 보면 알겠지만 그 제목은 어쨌거나 ‘PM 모집’이다. 즉 프로젝트 매니저를 뽑는 것이다. 그런데 세부 사항을 보면 도통 프로그래머를 뽑는 것인지, 설계자를 뽑는 것인지, 관리자를 뽑는 것인지 헷갈린다.

물론 척박한 국내의 IT 현실에 비추어 볼 때, 프로젝트에서 수많은 역할을 동시에 수행할 수 있는 그런 멀티 플레이어를 선호하는 상황을 인정하지 못하는 바는 아니다. 하지만 바로 그런 잘못된 판단 또는 욕심이 바로 프로젝트를 실패하게 만든다.

일단 프로그래머의 경우 모든 사람들이 익히 잘 아는 역할이므로 논외로 치고, 소프트웨어 아키텍트와 프로젝트 매니저의 역할을 생각해보자.

소프트웨어 아키텍트는 설계자이다. 개발을 위한 ‘소프트웨어 요구사항’을 파악하고, 큰 그림의 소프트웨어 아키텍처를 디자인하고, 개개의 프로그래머들이 작업해야 할 서브 시스템과 컴포넌트를 정의하는 사람이다. 또한 테스트 엔지니어들과 함께 테스트 요구사항을 수립하기도 하면서, 소프트웨어 개발의 전 과정에서 중요한 기술 책임자의 역할을 수행하는 사람이다.

프로젝트 매니저는 관리자이다. 프로젝트의 진행을 위한 ‘프로젝트 요구사항’을 파악하고, 프로젝트 계획을 수립하고, 개개의 팀원들이 작업해야 할 프로젝트 활동을 시간과 비용 개념을 갖고서 정의하는 사람이다. 또한 품질 담당자와 함께 품질 보증을 위한 활동을 수립하기도 하면서, 프로젝트의 전 과정에서 관리 책임자의 역할을 수행하는 사람이다.

소프트웨어 아키텍트는 소프트웨어 개발을 위한 높은 수준의 디자인을 계획하고 책임지는 사람이고, 프로젝트 매니저는 프로젝트 관리를 위한 여러 활동들을 계획하고 책임지는 사람이다. 기술 활동과 관리 활동은 분명히 다른 것이다.

하지만 많은 업체들이 그것을 혼동함으로써 재앙을 불러온다. 마치 프로젝트 매니저가 프로그래밍도 잘 알아야 하고, 설계도 잘 해야 하고, 관리도 잘 해야 한다고 생각한다. 물론 작은 규모의 프로젝트에서는 단 한 명이 모든 역할을 다 수행하는 경우도 있겠지만, 그것은 아주 예외적인 것이다.


기술 책임자와 관리 책임자는 구분되어야 한다

대부분의 소프트웨어 프로젝트에서 프로젝트 매니저의 역할과 아키텍트의 역할은 명확히 구분될 필요가 있다. 물론 두 사람이 상호 신뢰 하에 관리 책임자, 기술 책임자로서 긴밀하게 협조해야 하는 것은 자명하다.

그러므로 이 컬럼의 진지한 충고는, 프로젝트 매니저와 아키텍트의 역할을 제대로 구분하고 적합한 사람을 각각의 역할에 배정하라는 것이다. 그런 사람이 없어서 못 쓴다고 항변하는 업체들도 있을 것이다. 글쎄, 세상에 쉬운 일이 어디 있겠는가? 그것은 시간을 갖고 업체 스스로 양성을 하든, 경쟁 업체에서 스카우트를 하든, 해외에서 데려오든 해당 업체가 판단할 일이다.

프로젝트의 실패. 그것은 바로 소프트웨어와 프로젝트의 본질을 무시하고 인적자원의 중요성을 무시한 행동에 따른 필연적인 결과가 아닐까 필자는 생각한다. 그래서 필자는 다음의 주장을 명백히 강조하고 싶다.

“기술 책임자와 관리 책임자는 구분되어야 한다” 그것은 CEO와 CTO가 구분되어야 하는 것과 같은 개념이다. 만일 무지하여 그러한 구분을 제대로 해내지 못하거나, 또는 비용 절감의 욕심에 사로잡혀 고의적으로 그것을 행하지 않는다면, 프로젝트는 필히 재앙으로 보답할 것이다. 소프트웨어 프로젝트의 역사는 그것을 증명하고 있다. @


♣ 자료출처 : 류한석(피플웨어 운영자)

WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,
국내의 최고 페이지랭크 값은 몇일까? 현재까지는 6이라고 할 수 있다. 하지만, 6이라는 점수는 매우 특별한 경우라고 볼 수 있고, 대체적으로는 5를 받으면 최고 점수라고 볼 수 있다. 올블로그, 미디어몹 등도 모두 5점을 받고 있다.

페이지랭크는 구글이 사용하는 검색 순위에 많은 영향을 미치는 일종의 알고리즘으로, 페이지랭크 값이 높으면 검색엔진의 상위 랭크가 가능하다. 그리고, 구글의 한국 공식 블로그의 메인페이지 랭크 값이 7이기 때문에 멀지 않아 7값을 갖는 블로그가 출현할 가능성도 있다.

하지만, 최근 ZDNET에서 야심차게 준비한 ZDNET 전문블로그 서비스는 블로그스피어 전체적인 페이지랭크 값을 올리는데 일조할 가능성이 매우 높다. ZDNET 메인페이지의 랭크 값은 네이버, 다음보다 높은 무려 8점을 받고 있다. ZDNET 한국 서비스의 랭크값이 높은 이유는 ZDNET 영문페이지에 직접 링크를 받고 있기 때문으로, ZDNET 영문의 메인페이지는 랭크 9를 받고 있다.

현재까지 ZDNET 전문블로그는 ROBOT.txt으로 막아놓은 네이버 블로그를 제외한다면, 팔글을 포함해서 ENTClic@blog, 피플웨어, 스마트플레이스, 왕멀 블로그 그리고 Inuit Blogged. 이들 블로그의 현재 페이지랭크 값도 상당히 높은 편이기 때문에 ZDNET의 링크가 오랫동안 살아있다면 현재의 랭크 6을 받고 있는 네이버나 랭크 7인 다음보다 높은 점수를 받는 블로그의 출현도 불가능하진 않다.

외국의 경우 페이지랭크 값을 올리기 위해 유료 광고를 진행하는 경우도 있다. 웹 표준을 만들어가는 월드 와이드 웹 컨소시움의 경우 최고 점수인 10점을 받고 있는데, W3C는 페이지랭크 9점짜리 페이지에 1년 고정링크 광고를 년 1000달러를 받고 팔고 있다. 이 광고 페이지는 웹사이트 이름과 링크만 제공한다는 점을 상기한다면, 완전히 페이지랭크 상품이라고 할 수 있을 것이다.

구글의 시장 점유율이 높은 외국의 경우, 페이지랭크에 유리하다는 이유로 기업 홍보창구로 블로그를 활용하고 있다. 반면, 한국은 웹검색이 거의 활성화되어 있지 않아서 큰 의미는 없을 것이다.

아무튼, ZDNET의 이번 기획은 한국 블로고스피어의 페이지랭크 값을 올리게 될 것이고, 장기적으로는 구글과 야후 검색결과의 상위에 블로그 노출이 더욱 많아지리라는 시나리오를 그릴 수 있을 것이다. @


♣ 자료출처 :  http://www.zdnet.co.kr

WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,