← 블로그 목록

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

함께 읽으면 좋은 글

프로그래밍 학습게임 개발튜토리얼
GameTutorials.com 같은 옛 입문 사이트는 출발점으로 좋았지만 지금은 공식 문서와 함께 봐야 한다

GameTutorials.com 같은 옛 입문 사이트는 창 만들기, 렌더링 루프, 충돌 같은 큰 흐름을 작게 쪼개 보여 준 좋은 학습 문화의 산물이지만, 그대로 따라 하면 API와 도구 선택이 어긋난다. 옛 자료를 개념 입문용으로만 활용하고 Unity Learn, Unreal Engine 학습 자료, LearnOpenGL 같은 최신 공식 경로로 구현을 교차검증하는 방식을 정리한다.

소프트웨어 공학테스트재사용
재사용성과 테스트는 둘 다 의존성을 드러내고 경계를 나눌 때 좋아진다

재사용성과 테스트는 따로 다뤄지는 품질처럼 보이지만 실제 설계에서는 같은 방향으로 움직인다. 의존성을 드러내고 책임 경계를 작게 유지한 코드는 다시 쓰기도 쉽고 시험하기도 쉽다. 마틴 파울러의 의존성 주입 설명을 빌려, 두 품질이 결국 얼마나 덜 얽혀 있는가라는 같은 질문으로 수렴한다는 점과 함께 챙길 수 있는 설계 습관을 정리한다.

소프트웨어 공학조직갈등
데드락은 컴퓨터 과학 용어지만 사람 사이의 교착을 돌아보게 하는 좋은 비유다

데드락은 본래 여러 작업이 서로의 자원을 기다리다 모두 멈춰 버리는 운영체제 용어다. 사람은 스레드가 아니지만, 데드락 성립의 네 조건이라는 구조만 빌리면 조직과 관계에서 누구도 먼저 풀 수 없는 교착이 왜 생기는지를 누가 더 나쁜가가 아니라 무엇이 서로를 묶고 있는가의 질문으로 다시 보게 된다. 그 비유의 쓸모와 한계를 정리한다.