← 블로그 목록

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

함께 읽으면 좋은 글

Python코루틴Stackless Python
Stackless Python은 파이썬에 경량 태스크릿과 채널을 더한 구현이다

Stackless Python은 코루틴이 들어간 파이썬이라는 짧은 설명만으로는 부족하다. 태스크릿, 채널, 스케줄러를 통해 매우 가벼운 실행 단위를 다루는 별도 구현이며, PEP 342와 PEP 492가 정착시킨 오늘날의 `async`/`await`와는 다른 계보로 동시성을 메시지 전달과 작은 실행 주체의 협력으로 보게 만드는 관점을 보여 준다는 점을 정리한다.

프로그래밍애자일익스트림 프로그래밍
익스트림 프로그래밍은 과격한 방법이 아니라 변화를 버티기 위한 공학 습관이다

익스트림 프로그래밍은 이름과 달리 사람을 몰아붙이는 문화가 아니라, 테스트·리팩터링·작은 릴리스·지속 가능한 속도를 엮어 변화 비용을 낮추려는 공학 습관의 묶음이다. ‘Extreme’의 의미도 중요한 실천을 끝까지 밀어 보자는 태도에 가깝다. XP는 빨리 만드는 법이 아니라 바뀌어도 계속 만들 수 있는 법을 묻는다는 점을 정리한다.

프로그래밍데이터 구조상태 전이
모든 프로그램을 데이터와 상태 전이로 보면 설계가 더 선명해진다

‘모든 프로그램은 데이터베이스다’는 엄밀한 정의는 아니지만 사고 실험으로는 꽤 쓸모 있다. 저장·조회·갱신·삭제, 무결성, 상태 전이의 관점으로 코드를 보면 객체 이름보다 접근 패턴과 유효 상태가 먼저 보이고, 프레임워크가 바뀌어도 설계가 덜 흔들린다. 데이터를 어떻게 다루는지가 결국 프로그램의 성격을 결정한다는 점을 정리한다.