← 블로그 목록

2010년 Google I/O가 보여준 것은 HTML5 한 기술보다 웹을 앱 플랫폼으로 밀어 올리려는 방향이었다

2010년 Google I/O를 다시 보면, 진짜 메시지는 HTML5라는 단어가 아니라 Chrome Web Store, WebM과 VP8, Android Froyo의 브라우저 개선을 한꺼번에 밀어 웹을 앱 플랫폼으로 끌어올리려 한 큰 방향에 가까웠다. 웹이 어디까지 갈 수 있는가에 대한 기대가 한꺼번에 폭발한 순간이었다는 점을 정리한다.

2010년 Google I/O가 보여준 것은 HTML5 한 기술보다 웹을 앱 플랫폼으로 밀어 올리려는 방향이었다

2010년 Google I/O가 보여준 것은 HTML5 한 기술보다 웹을 앱 플랫폼으로 밀어 올리려는 방향이었다

2010년 Google I/O를 지금 다시 보면, 그 시기의 흥분을 한 문장으로 요약할 수 있다. 웹을 문서의 집합이 아니라 앱 플랫폼으로 만들려는 시도였다.

당시 구글은 여러 조각을 한꺼번에 밀어붙였다. Chrome Web Store, WebM과 VP8, HTML5 개발자 자료, Android Froyo의 브라우저 개선이 그것이다. 중요한 건 각각의 기능보다, 이 조각들이 한 방향을 가리켰다는 점이다.


HTML5는 “태그 몇 개 추가”가 아니라 웹 앱의 범위를 넓히는 신호였다

Google Developers 블로그는 2010년 HTML5Rocks.com을 공개하며, HTML5 전반을 다루는 개발자 자료를 만들었다고 설명했다. 이건 단순한 홍보 사이트가 아니었다. 웹이 더 복잡한 애플리케이션을 담을 수 있다는 자신감의 표현에 가까웠다.

같은 시기 Chrome Experiments도 JavaScript와 HTML5를 이용한 새로운 웹 경험을 전면에 내세웠다. 즉 구글은 “브라우저 안에서도 더 많은 것을 할 수 있다”는 개발자 감각을 키우고 있었다.


비디오 전쟁에서는 WebM과 VP8이 중요했다

2010년의 큰 쟁점 가운데 하나는 웹 비디오였다. Chromium 블로그는 2010년 5월 WebM과 VP8 지원이 Chromium에 들어간다고 알렸고, WebM 프로젝트는 VP8 기반의 오픈 웹 비디오 방향을 전면에 내세웠다.

이 흐름이 중요했던 이유는 분명하다.

즉 “HTML5 비디오” 논쟁은 단순한 태그 문제가 아니라, 웹이 독립적인 애플리케이션 환경이 될 수 있느냐는 질문과 연결되어 있었다.


Chrome Web Store는 웹 앱을 “설치 가능한 것”처럼 보이게 만들려 했다

Chromium 블로그는 2010년 Google I/O에서 Chrome Web Store를 an open marketplace for web apps라고 소개했다. 이 말이 상징적이다. 웹 페이지가 아니라 웹 앱을 전제로 한 시장을 만들겠다는 뜻이기 때문이다.

지금 보면 성공 여부를 따지는 것은 별개로, 당시 의도는 꽤 선명했다.

오늘의 PWA 논의와 비교하면, 이 시기에 이미 방향은 상당 부분 잡혀 있었다고 볼 수 있다.


Android Froyo는 모바일 웹이 느리기만 한 것은 아니라는 신호였다

Android 2.2, 즉 프로요(Froyo)는 브라우저 성능 쪽에서도 중요한 변화를 담고 있었다. 당시 안드로이드 관련 자료와 회고들은 JIT와 브라우저 개선이 모바일 웹 성능에 큰 영향을 줬다는 점을 반복해서 언급한다.

이 맥락에서 보면, 2010년 Google I/O의 메시지는 더 분명해진다. 웹은 데스크톱용 문서 환경이 아니라, 모바일에서도 충분히 앱처럼 굴 수 있는 방향으로 밀리고 있었다.


핵심 정리

2010년 Google I/O의 진짜 의미는 HTML5라는 이름 하나에 있지 않았다. WebM과 VP8로 웹 비디오를 열고, Chrome Web Store로 웹 앱 유통을 실험하고, Android Froyo로 모바일 브라우저 성능을 끌어올리면서, 웹을 본격적인 앱 플랫폼으로 만들려는 큰 방향이 드러났다는 데 있다.

즉 그 해의 흥분은 “새 기능이 나왔다”가 아니라, 웹이 어디까지 갈 수 있는가에 대한 기대가 한꺼번에 폭발한 순간에 더 가까웠다.

참고 자료

← 목록으로
Related

함께 읽으면 좋은 글

객체지향상속델리게이트
상속을 줄이고 델리게이트와 시그널로 푸는 이유

상속은 ‘무엇의 하위 타입인가’를 표현하는 데 강하지만, UI 이벤트나 객체 간 통신처럼 호출 관계가 자주 바뀌는 영역에서는 델리게이트나 시그널과 슬롯 같은 느슨한 연결이 더 잘 맞는다. C# 델리게이트와 Qt 시그널의 사례를 빌려, 좋은 설계는 상속을 줄이는 신념이 아니라 ‘타입 관계’와 ‘실행 시 연결 관계’를 분리해 보는 습관에서 나온다는 점을 정리한다.

프로그래밍참조 무결성수명 관리
참조 무결성은 데이터베이스 규칙이면서 동시에 런타임 안전 규칙이기도 하다

참조 무결성은 외래 키 규칙으로만 생각하기 쉽지만, 런타임에서 포인터·핸들·식별자가 가리키는 대상의 수명을 관리하는 문제에도 거의 같은 구조가 깔려 있다. 데이터베이스가 ‘존재하는 행만 가리키게 하라’고 한다면 런타임은 ‘살아 있는 객체만 가리키게 하라’를 요구한다. 결국 핵심은 소유권과 수명, 유효성 확인을 함께 설계하는 일이다.

서평소프트웨어 개발조엘 스폴스키
『Joel on Software』를 다시 읽으면 남는 것은 화려한 이론보다 운영 감각이다

조엘 스폴스키의 『Joel on Software』는 거대한 이론 대신 The Joel Test, 버그 추적, 새는 추상화 같은 낮지만 치명적인 마찰을 집요하게 건드린다. 좋은 팀은 우연히 굴러가지 않는다는 감각, 즉 빌드·버그·채용 같은 기본기를 잃지 않게 만드는 운영 감각이 이 책의 가장 큰 가치라는 점을 다시 짚는다.