- 회원들이 추천해주신 좋은 글들을 따로 모아놓는 공간입니다.
- 추천글은 매주 자문단의 투표로 선정됩니다.
Date | 15/10/16 15:26:03 |
Name | ![]() |
Subject | 간략하게 살펴보는 웹디자인의 역사 |
http://blog.froont.com/brief-history-of-web-design-for-designers/ 위의 블로그에서 작성한 내용을 기초로 간략하게 제가 재정리해본 내용입니다. 1. 웹디자인의 암흑기 (1989)![]() 기술은 만들어졌으나, 초기에는 문서를 만들기 위한 기능만이 준비되어있어 디자인을 구현하는 단계까지 닿지 못했습니다. 2. Table의 활용 - 초기 (1995)![]() 그러다가 사람들이 표를 만들고, 표의 테두리 두께를 0으로 설정해서 외곽선이 안보이도록 하면, 표를 활용해서 레이아웃을 잡을 수 있다는 것을 발견했습니다. 이를 통해 표로 레이아웃을 짜고, 그 안에 또 표를 넣고, 표안에 또 표를 넣고, 표를 넣는... 테이블 레이아웃 시대가 열리게 되었습니다. 3. 자바스크립트의 등장 (1995)![]() 자바스크립트의 등장은 브라우저 상에서 처리 할 수 있는 프로그래밍 언어가 추가되었다는 점에서 의의가 큽니다. 지금도 브라우저 내에서 동작하는 네이티브 언어는 자바스크립트가 유일합니다. 초기의 자바스크립트는 팝업창을 띄우는 등의 일부 용도로만 제한적으로 사용되었으나 2005년경에 Ajax방식으로 활용하는 법이 알려지자 비약적인 발전을 이루게 되지요. 그 전까지는 웹에서의 모든 동작은 클릭하면 무조건 페이지가 껌뻑하고 새로고침되는 방식으로만 동작 했었는데, ajax의 출현으로 추천 버튼을 눌러도 페이지를 새로고침 하지 않고 추천완료 메시지를 보여줄 수 있게 되었습니다. 4. 플래시의 등장 (1996)![]() 플래시를 보기위해서는 플러그인을 설치해야 한다는 전제조건이 있었지만, 워낙 플래시의 위력이 막강하였기에 플래시는 빠르게 많은 사용자들을 모았습니다. 이런 현상은 특히 국내에서 더 심했는데요. 인터넷 속도가 빠르고, 배출된 웹디자인 인력이 많았고, 인터넷 사용 인구의 비율이 높았던 등의 다양한 이유가 작용했다고 생각합니다. 99년 경부터 국내에서도 플래시를 잘 다루는 분들이 생기기 시작했었는데요, 실제로 국내에서 플래시가 본격적으로 사용된 것은 2002년 경부터로 기억합니다. 플래시는 2007년 아이폰의 등장과 함께 꺾이기 시작했습니다. 모바일 지원이 지지부진하던 플래시를 과감하게 지원 배제해버린 스티브 잡스 덕분이지요. 아이폰이 모바일 세상에 플래시가 발붙이지 못하도록 했다면, 아이패드는 데스크탑 세상에서도 플래시가 퇴출되도록 만드는 역할을 했습니다. 아이패드는 데스크탑 웹사이트를 그대로 서핑 할 수 있는 기기였으니까요. 또한 HTML5, CSS3 등의 웹표준 대체 기술도 등장했고, 네트워크가 빨라지면서 동영상으로 플래시가 하던 역할을 대체할 수 있게 되었습니다. 최근에는 파이어폭스에서도 플래시 지원을 중단하고, 보안 취약점이 연달아 터지면서 플래시의 수명은 점점 다해가고 있습니다. 5. CSS (1998)![]() 과거의 웹 기술은 디자인을 표현하기 위해 꼭 필요한 부분들이 많이 없었습니다. 예를들어 <font size=3>과 같은식으로 폰트의 크기를 지정해 줄 수 있었는데 [2는 너무 작고 3은 너무 큰거 같은데 2.5로 줄 수는 없는거야?]와 같은 디테일한 요구사항들을 만족 시켜줄 수 있는 표준이 제안된 것이지요. 단순한 디자인 속성들을 추가해 줄 수 있는 기능에서 벗어나 최근의 CSS는 애니메이션까지도 다룰 수 있는 도구가 되었습니다. (제가 제일 좋아하고 잘 다루는 전문 분야이기도 합니다.) 6. 모바일의 출현과 그리드 레이아웃 (2007)![]() 갑자기 90년대에서 2007년으로 훅 건너 뛰었습니다. 사실 작품으로서의 웹디자인은 계속 발전해왔으나 작업 방식이나 형식적인 측면에서는 계속 제자리에 머물러 있었습니다. 그 이유는 브라우저 전쟁에서 승리했던 마이크로소프트의 IE(인터넷 익스플로러) 때문인데요. IE6 버전을 낸 이후 한참동안 새 버전을 내지 않았고, 그 이후로 냈던 7, 8 버전에서도 기술적으로 충분한 발전이 되지 않았기 때문입니다. 모바일의 출현이 2007년으로 기록되는 이유는 그 이전의 모든 모바일기기의 브라우징 경험에 비해 아이폰의 브라우징 경험이 월등하게 뛰어났기 때문인데요. 아이폰의 등장 이후로 웹디자인에서도 모바일에 대한 지원이 본격적으로 논의되기 시작합니다. 7. 반응형 웹디자인 (2010)![]() 모바일의 폭발적인 성장으로 어떻게 모바일의 작은 화면을 웹사이트가 잘 지원할 수 있을까에 대한 해답을 찾은 것이 반응형웹디자인입니다. 모바일 사이트를 따로 만들 수도 있지만, 그렇게 하면 관리 포인트가 2개로 늘게되어 작업 비용이 2배로 들게되며, 두개로 나뉘어진 데스크탑 웹과 모바일 웹의 내용이 서로 동일하게 싱크가 잘 맞도록 유지되리라는 보장이 없어지기 때문에 작업자들은 그 동안 더 나은 방법을 고민해왔습니다. 그리고 마침내 찾아낸 답이 반응형웹디자인인 것이죠. 하지만 이 고민이 끝날 때 까지 기다리기 힘든 우리 빨리빨리 민족은 모바일 전용 웹사이트를 만드는 방식을 정석으로 삼고 내달렸고, 그 결과 전세계에서 가장 모바일 지원이 빠르고 잘 되어있는 웹사이트들을 갖게 되었습니다. 비록 비용은 2배로 든다고 하더라도 말이죠. 그리고 사실 포털 같은 대형 사이트에서는 반응형웹디자인을 적용하는 것보다 그냥 두벌을 만드는 편이 인프라 비용면에서도 유리합니다. 그 때문에 지금까지도 반응형웹디자인은 국내의 대형 사이트들에서는 잘 사용되지 않는 편입니다. 8. 플랫 디자인의 시대 (2010)![]() 플랫디자인은 다양한 사이즈로 단말을 만들던 안드로이드 진영에서 먼저 시작이 되었다고 생각합니다. 애플에서 추구하고 있던 스큐어모픽(현실의 질감을 최대한 세밀하게 묘사하는 방식) 디자인은 제작하는데 품이 많이 들어갈 뿐더러, 다양한 사이즈를 지원하기에는 적합하지 않았기 때문입니다. 스큐어모픽 방식의 디자인이 다양한 사이즈에서 모두 잘 보이려면 결과적으로 여러벌의 디자인 작업을 하는 노가다가 추가되어야 하고, 그 작업물들을 UI에 잘 녹여내는 것도 UI 개발자의 노하우가 많이 필요한 일이거든요. 그 때문에 후발주자로 쫒아가면서 초짜 개발자들을 모아서 앱을 만들게 해야하는 안드로이드나 MS등의 진영에서는 스큐어모픽 디자인 기조를 따라하기가 어려웠습니다. 그래서 플랫한 스타일로 디자인을 가이드 하기 시작했지요. 하지만 결국 애플의 디바이스도 사이즈가 다양해져가면서 애플 역시도 개발자들에게 계속해서 스큐어모픽을 요구하기가 어려워집니다. 그래서 애플도 스큐어모픽을 버리고 iOS7의 출시와 함께 플랫디자인을 대세로 밀기 시작합니다. 디자인 가이드도 새로 만들어서 배포하구요. 이전에도 비애플 진영들의 플랫 디자인 전략으로 플랫 디자인이 많이 추구되고 있었던 상황에, 애플이 플랫을 밀기 시작하면서 IT 디자인은 플랫이 대세로 완전히 넘어오게 됩니다. (덕분에 디자이너들의 작업 분량도 많이 줄었다고 저는 생각합니다.) 9. 미래는?![]() 미래는 아무도 모르는 것이기에 사실 무슨 애기를 해도 의미가 없습니다. 이 글의 원작자는 새롭게 추가된 HTML5, CSS3 속성들을 손꼽으면서 그런 것들이 영향을 미치지 않겠느냐라고 하는데, 사실 제가 보기에는 코드만 바뀌고 사용자가 체감 할 수 있는 눈에 보이는 변화를 가져올 기능들이 전혀 아닙니다. 위의 Animation GIF는 나름대로 웹이 좀 더 애플리케이션화 된 모습을 상상해서 만든 것이라고 생각되는데요. 사실 우리는 모두 플래시의 황금기 시절에 익숙하게 보아왔던 것입니다. HTML5가 발전하면 예전에 ActiveX로 구현했던 것들이 웹표준 기술로 가능해지는 것이고, CSS3가 발전하면 예전에 플래시로 구현했던 것들이 웹표준 기술로 가능해지는 것이거든요. 그런면에서 이미 우리는 미래의 웹디자인을 다른 나라에 비해 먼저 보고 살았다고 볼 수 있습니다. 이제 앞으로의 웹디자인은 더 이상 기술에 제약을 받지 않기 때문에, 이미 웹디자인이라고 굳이 앞에 '웹'이란 단어를 붙일 필요가 없습니다. 웹디자인은 사라지고 디자인만 남게 되는 것이지요. * 난커피가더좋아님에 의해서 자유 게시판으로부터 게시물 복사되었습니다 (2015-10-23 07:50) * 관리사유 : 추천게시판으로 복사합니다. 17
이 게시판에 등록된 Toby님의 최근 게시물 |
넵. 사실 html5를 html의 관점에서만 보자면 section, article, aside, nav, video, audio... 등등 태그가 몇 개 추가된 정도에 불과합니다만, html5는 자바스크립트 API를 포함하기도 합니다.
그래서 HTML5는 사실은 html에 대한 이야기가 아니라 새로운 브라우저 API에 대한 이야기이지요. 그걸 간단히 이야기 해보면 예전에는 ActiveX 를 통하지 않으면 할 수 없었던 기능들을 자바스크립트로도 할 수 있게 되었다라는 뜻입니다. 저는 이게 HTML5의 의미의 60% 정도를 차지 ... 더 보기
그래서 HTML5는 사실은 html에 대한 이야기가 아니라 새로운 브라우저 API에 대한 이야기이지요. 그걸 간단히 이야기 해보면 예전에는 ActiveX 를 통하지 않으면 할 수 없었던 기능들을 자바스크립트로도 할 수 있게 되었다라는 뜻입니다. 저는 이게 HTML5의 의미의 60% 정도를 차지 ... 더 보기
넵. 사실 html5를 html의 관점에서만 보자면 section, article, aside, nav, video, audio... 등등 태그가 몇 개 추가된 정도에 불과합니다만, html5는 자바스크립트 API를 포함하기도 합니다.
그래서 HTML5는 사실은 html에 대한 이야기가 아니라 새로운 브라우저 API에 대한 이야기이지요. 그걸 간단히 이야기 해보면 예전에는 ActiveX 를 통하지 않으면 할 수 없었던 기능들을 자바스크립트로도 할 수 있게 되었다라는 뜻입니다. 저는 이게 HTML5의 의미의 60% 정도를 차지 하는 것 같습니다.
나머지 40중 30% 정도는 Canvas 태그가 추가됨으로써 자유로운 그래픽 표현이 가능해진게 크지 않나 싶구요. (이로서 타 플랫폼 게임을 웹에도 이식 할 수 있게 되었지요)
시맨틱은 5% 정도의 의미를 갖는 것 같습니다 흐흐
그래서 HTML5는 사실은 html에 대한 이야기가 아니라 새로운 브라우저 API에 대한 이야기이지요. 그걸 간단히 이야기 해보면 예전에는 ActiveX 를 통하지 않으면 할 수 없었던 기능들을 자바스크립트로도 할 수 있게 되었다라는 뜻입니다. 저는 이게 HTML5의 의미의 60% 정도를 차지 하는 것 같습니다.
나머지 40중 30% 정도는 Canvas 태그가 추가됨으로써 자유로운 그래픽 표현이 가능해진게 크지 않나 싶구요. (이로서 타 플랫폼 게임을 웹에도 이식 할 수 있게 되었지요)
시맨틱은 5% 정도의 의미를 갖는 것 같습니다 흐흐
네. 우리가 말하는 HTML5라는 것의 실체는 HTML5 스펙문서를 말합니다.
http://www.w3.org/TR/html5/
과거에 IE와 넷스케이프가 서로 경쟁을 했던 것 처럼, 웹브라우저는 여러회사가 만들지요.
IE를 만드는 MS, FF를 만드는 모질라, Opera를 만드는 Opera, Safari를 만드는 애플, Chrome을 만드는 구글... (오픈소스는 꼭 그 회사만 만드는건 아니긴 하지만)
그래서 표준 문서가 필요합니다. 과거에는 서로 IE와 넷스케... 더 보기
http://www.w3.org/TR/html5/
과거에 IE와 넷스케이프가 서로 경쟁을 했던 것 처럼, 웹브라우저는 여러회사가 만들지요.
IE를 만드는 MS, FF를 만드는 모질라, Opera를 만드는 Opera, Safari를 만드는 애플, Chrome을 만드는 구글... (오픈소스는 꼭 그 회사만 만드는건 아니긴 하지만)
그래서 표준 문서가 필요합니다. 과거에는 서로 IE와 넷스케... 더 보기
네. 우리가 말하는 HTML5라는 것의 실체는 HTML5 스펙문서를 말합니다.
http://www.w3.org/TR/html5/
과거에 IE와 넷스케이프가 서로 경쟁을 했던 것 처럼, 웹브라우저는 여러회사가 만들지요.
IE를 만드는 MS, FF를 만드는 모질라, Opera를 만드는 Opera, Safari를 만드는 애플, Chrome을 만드는 구글... (오픈소스는 꼭 그 회사만 만드는건 아니긴 하지만)
그래서 표준 문서가 필요합니다. 과거에는 서로 IE와 넷스케이프가 서로 다른 기준으로 기능을 마구 추가해대서 개발자들은 양쪽 모두 대응되도록 만드느라 힘들었거든요.
[너희들 맘대로 만들지 말고 이 문서를 보고 여기 써있는대로 만들어.]라는게 저 스펙 문서인거죠.
근데 HTML4 시절에는 스펙문서에 HTML에 대한 내용만 써있었는데, HTML5 스펙문서에는 자바스크립트 관련 내용이 많이 포함되어있습니다.
HTML이라는 이름을 달고 있다고 해서 HTML 이야기만 하는게 아니라 [어짜피 자바스크립트도 HTML과 연관성이 많잖아? 그래서 의미를 조금 확장해봤어]라는 식으로 자바스크립트도 다루기 시작한거죠.
그래서 저 스펙 문서를 보고 브라우저를 만들면 새로운 자바스크립트 기능들이 많이 추가된 브라우저를 만들게 됩니다.
그래서 사실 HTML5는 HTML 보다도 스크립트 관련된 내용들이 주를 이룬다고 할 수 있어요.
선언부에 HTML5 독타입을 쓰느냐 안쓰느냐와 상관없이 HTML5를 지원하는 브라우저는 HTML5에 추가된 자바스크립트 API를 사용 가능합니다.
엄밀히 따지면 자바스크립트 표준도 따로 있고해서 정확한 설명은 아닌데 대충 쉽게 설명하면 그렇습니다.
http://www.w3.org/TR/html5/
과거에 IE와 넷스케이프가 서로 경쟁을 했던 것 처럼, 웹브라우저는 여러회사가 만들지요.
IE를 만드는 MS, FF를 만드는 모질라, Opera를 만드는 Opera, Safari를 만드는 애플, Chrome을 만드는 구글... (오픈소스는 꼭 그 회사만 만드는건 아니긴 하지만)
그래서 표준 문서가 필요합니다. 과거에는 서로 IE와 넷스케이프가 서로 다른 기준으로 기능을 마구 추가해대서 개발자들은 양쪽 모두 대응되도록 만드느라 힘들었거든요.
[너희들 맘대로 만들지 말고 이 문서를 보고 여기 써있는대로 만들어.]라는게 저 스펙 문서인거죠.
근데 HTML4 시절에는 스펙문서에 HTML에 대한 내용만 써있었는데, HTML5 스펙문서에는 자바스크립트 관련 내용이 많이 포함되어있습니다.
HTML이라는 이름을 달고 있다고 해서 HTML 이야기만 하는게 아니라 [어짜피 자바스크립트도 HTML과 연관성이 많잖아? 그래서 의미를 조금 확장해봤어]라는 식으로 자바스크립트도 다루기 시작한거죠.
그래서 저 스펙 문서를 보고 브라우저를 만들면 새로운 자바스크립트 기능들이 많이 추가된 브라우저를 만들게 됩니다.
그래서 사실 HTML5는 HTML 보다도 스크립트 관련된 내용들이 주를 이룬다고 할 수 있어요.
선언부에 HTML5 독타입을 쓰느냐 안쓰느냐와 상관없이 HTML5를 지원하는 브라우저는 HTML5에 추가된 자바스크립트 API를 사용 가능합니다.
엄밀히 따지면 자바스크립트 표준도 따로 있고해서 정확한 설명은 아닌데 대충 쉽게 설명하면 그렇습니다.
뭐 요즘은 낫지만 한 4-5년전에 홈페이지 리뉴얼 쪽으로 클라이언트 가 되었는데... 아이폰 3GS가 막 나오던 시절 말입니다.. 개발자 회의에서 크로스 브라우징 이야기 하니 님 뭥미? 하는 눈초리로 바라보던 기획자들도 있더군요.. 아니 무슨 인터네셔널을 지향하는 학회 홈페이지가 IE전용인게 말이 됩니까. 근데 결국 IE 전용에 플래쉬 떡칠이 되고 말았죠. HTML5이야기 했더니 지들이 모른다고는 끝까지 이야기 안하고 플래쉬를 딱 써줘야 홈페이지가 이쁘니.. 결국 지지치고 플젝에서 빠져버렸는데. 작년에 다시 갈아 엎었죠. 요즘은 웹표준 이야기 하면 네고할려고 하진 않겠죠... 여튼 디자인 문제는 결국 돈내는 60대 아재(?) 들의 취향에 맞춰야 되니 아직 플랫 디자인 그러면 뭐가 이렇게 때깔 안나냐고 한소리 듣긴 하죠.
목록 |
|