공개SW 개발자센터


- 공개SW개발자센터는 공개SW 리더로 성장할 개발자와 커뮤니티를 지원합니다 -

공개SW역량프라자에서는 오픈프론티어로 활동중인 개발자들이 진행하는 프로젝트를 소개합니다.


Blink 프로젝트는 크롬의 레이아웃 엔진으로 웹 콘텐츠와 포맷 정보를 가져와 화면에 정리하여 보여주는 소프트웨어다. 이 글에서는 Blink 프로젝트의 목표와 역사, 활용에 대해서 알아본다. 또한, Blink 프로젝트의 개략적인 구조를 살펴본다.

프로젝트명Blink
개요

Open Web Platform의 핵심이며 가장 많은 브라우저 벤더들(Google,  Opera, Samsung, Mozilla and so on)이 참여하는 프로젝트

특징

Chrome Browser, Samsung Browser, Opera Browser 등 세계 유명  브라우저들의 기반

목표안전하고 빠르며 안정적인 브라우저를 만들며 더 나아가 오픈 웹 플랫폼을 지향
기대효과웹 세계의 발전에 기여
리퍼지토리https://chromium.googlesource.com/chromium/src.git



[목차]

  1.  Blink의 목표

  2. Blink의 역사

    2.1. Chrome 브라우저의 등장과 Webkit
    2.2. Blink의 Fork
    2.3. Chromium WebView
    2.4. Blink와 Chromium Repository 통합

  3. Blink Project의 참여 및 활용

    3.1. 토론
    3.2. 새로운 기능 살펴보기
    3.3. 개발하기  

  4. Blink와 Web Platform

    4.1. Wen Platform API 추가 및 삭제에 관한 정책
    4.2. 상호 운용성(Interoperability)과 호환성(Compatibility) 평가
    4.3. API Owners
    4.4. 새로운 기능 및 API의 추가 및 변경 과정
    4.5. 기존 기능 및 API의 삭제 과정

  5. Blink의 개략적인 구조(현재 및 미래)

    5.1. Public Layer

    5.2. Browser Layer

    5.3. Services Layer

    5.4. Engine Layer

    5.5. System Layer


1. Blink의 목표

Blink는 Chromium이 사용하는 웹 브라우저 렌더링 엔진(Web Browser Rendering Engine)으로서 웹 분야를 기술적 혁신을 통해 개선하고 세상을 변화시키겠다는 목표로 만들어지고 있다. 웹의 특성상 Open Web Platform을 지향하고, Blink의 전신인 WebKit이 매우 보수적인 태도를 취하는 것에 비해 매우 빠르고 진보적인 태도를 취한다.


2. Blink의 역사


  1. 2.1. Chrome 브라우저의 등장과 WebKit
  2. 구글(Google)은 Multi-process Architecture를 지원하는 크롬(Chrome) 브라우저를 2008년 9월 2일 출시하였다. 이때 사용된 웹 엔진은 WebKit을 사용하였다(Blink의 탄생 이전). 구글 크롬은 이후 WebKit 입장에서 가장 기여도가 큰 브라우저 벤더로 성장하였다. 2010년 분석 자료에 따르면 2009년 11월에 Google의 기여도가 Apple의 기여도를 넘어선 것으로 추정된다.


1_report.png

[그림 1] 2010년 분석자료


    1. 2.2. Blink의 Fork
    2. 구글(Google)은 2013년 4월 WebKit으로부터 Fork를 선언하였다. 당시 core 엔지니어 중 한 명인 Adam Barth 씨의 말을 빌리면 “Chromium은 다른 WebKit 기반 브라우저와 달리 멀티 프로세스 아키텍처를 채용하고 있으므로, WebKit과 Chromium 프로젝트는 지난 몇 년 동안 합병증의 일로를 걷고 있었다.”라고 하였으며, 이를 통해 전반적인 혁신의 속도가 저하되고 개발 시간의 낭비를 해왔기 때문에 새로운 렌더링 엔진의 채용을 단행했다고 설명했다.


      2_blink_chrome.png

      [그림 2] Blink가 탑재된 Chrome


    3. 2.3. Chromium WebView
    4. Blink Fork 이후 Chrome 브라우저는 모두 Blink 엔진을 사용하였으나 Android OS에서 제공되는 시스템 웹뷰(WebView)는 여전히 WebKit을 사용하고 있었다. 이것은 Android 4.4 KitKat 이후 Chromium에서 제공하는(내부적으로 Blink를 사용하는) WebView로 교체되었다.


    5. 2.4. Bink와 Chromium Repository 통합
    6. Blink Fork 이후에도 Chromium과 Blink는 별도의 Repository에서 관리됐는데, 이는 주기적으로 Roll-up을 요구하여 개발 속도에 영향을 준다는 이유로 구글은 두 Repo를 통합하는 일을 추진해왔다. 그리고 2015년 9월 23일에 두 Repo는 통합되었으며 한 Repo에서 레이어만 다르게 존재한다.


3. Blink Project의 참여 및 활용


    1. 3.1. 토론
    2. Blink는 회사 및 조직, 제휴 등과 관계없이 누구에게나 열려있는 Open Platform을 지향하기 때문에 투명성을 핵심 가치로 생각하고 있다. 그러므로 모든 토론은 공개적으로 열리는 것을 원칙으로 하고 누구나 거기에 참여하고 의견을 개진함으로써 프로젝트에 참여할 수 있다. 이러한 토론은 다양한 곳에서 발생할 수 있다.
  1.       º Chromium Bug Tracker: Chromium Issue Tracker로서 Blink는 “Blink” component를 지정하여 따로 표시를 해두고 있다.
  2.       º Code Reviews: Chromium/Blink 공식 코드리뷰 시스템인 Rietveld에서 코드에 관한 토론이 이루어진다. 더 나은 코드를 만들기 위해 Line by line으로 코멘트가 발생할 수 있다.
  3.       º  #blink: IRC 공개 채널로 빠른 답을 얻을 수 있고, 빠른 토론이 이루어질 수 있다.
  4.       º  blink-dev: 공개 메일링 리스트로서 가장 general 한 토론이 이루어지는 곳이다. 새로운 기능을 구현하거나 새로운 기능을 Default Enable 할 때 반드시 이곳에 Intent를 보내야 한다.
  5.     

4. Blink와 Web Platform

Blink는 앞서 설명한 것처럼 Open Web Platform을 지향하고 있다. Blink는 Chromium 프로젝트가 추구하는 더 빠르고, 더 안전하게 만드는 것을 넘어서 새로운 기능의 추가와 레거시(Legacy) 기능들을 제거하여 개선된 웹 플랫폼을 지속해서 만들어 간다. 이러한 목표를 달성하기 위해서 web-facing API들의 변화를 매우 조심스럽게 진행하며, 투명성, 책임감과 그리고 무엇보다도 호환성을 지키려고 노력한다. 또한, Blink는 단지 엔진 구현에만 초점을 맞추지 않고 있으며, 새로운 구현이 새로운 개방형 표준(Open Standards)으로서 자리매김을 하도록 노력하고 있다. 이러한 일련의 과정들은 Chromium Feature Dashboard를 통해 살펴볼 수 있다.


    1. 4.1. Web Platform API 추가 및 삭제에 관한 정책
    2. 브라우저 개발자의 입장에서 Web Platform에 새로운 변화를 추구하는 것이 매우 중요하지만, 이것은 기존 호환성을 유지하는데 있어서는 쉽지 않은 문제이다. 새로운 API를 추가할 때, 다른 브라우저 벤더는 이를 제공하지 않을 수 있고, 또한 마찬가지로 기존의 API가 제거될 때 기존 웹 개발자들이 작성한 기존의 웹을 전반적으로 망가뜨릴 수도 있다. 그래서 Blink는 이를 해결하거나 이 문제를 최소화하기 위해 나름의 정책을 시행하고 있다.

    3. 4.2. 상호 운용성(Interoperability)과 호환성(Compatibility) 평가
    4. 상호 운용성이란 다른 브라우저 벤더(Browser Vendor)들이 해당 기능을 얼마나 구현하였는지, 혹은 얼마나 이 기능을 구현할 가능성이 높은지를 의미한다. 그러나 모든 브라우저 벤더가 특정 기능을 동시에 구현하는 경우는 거의 없으므로 다음과 같은 것들을 통해 상호 운용성 위험도를 평가하고 예측한다.
    5. º 다른 브라우저 벤더가 이미 Shipping한 구현체가 존재하는가?
    6. º 관련된 표준의 진행 정도(예를 들어 W3C라면 ED인지 WD인지 등등)
    7. º 다른 브라우저 벤더의 입장(앞으로 구현할 것인지 말 것인지?)
    8. º 해당 API의 등장 배경 및 앞으로의 가능성

    9. 호환성 위험도는 기존에 존재하는 웹 콘텐츠들과의 호환성이 얼마나 떨어지는지를 의미한다. Blink에서는 이것을 판단하기 위하여 각각의 API의 사용 정도를 수집하는 시스템인 UMA를 사용하고 있다. 특히 기존의 레거시 API를 삭제하는 과정에서는 이러한 데이터 확보는 매우 필수적으로 요구된다. 

    10. 4.3.  API Owners
    11. 모든 프로젝트 구성원(Contributor, Committer, Owners 등)들은 새로운 기능 및 API를 도입할 때 위와 같은 정책을 유지할 책임이 따른다. 어떤 기능의 구현이 해당 정책을 위반하거나 위반하는 것을 목격하는 경우 먼저 해당 패치의 Contributor에게 반드시 알려야 할 의무가 있고, 이렇게 해서 해결이 되지 않는 경우 공개 메일링 리스트를 통해 이 문제를 이슈화하여야 한다.

    1. 하지만 책임감만으로 모든 것을 해결할 수 없으므로 이러한 정책을 보완하고 프로젝트를 원활하게 돌아가게 하려고 API Owners 정책을 갖고 있으며 이들은 Blink 내 대부분의 기능 추가 구현을 모니터링하고, 공개 메일링 리스트에 제안된 기능 및 API를 검토해야 할 의무를 진다. 현재 API Owners의 리스트는 이 링크에서 볼 수 있다.

    2. 4.4. 새로운 기능 및 API의 추가 및 변경 과정
    3. ① 어떤 기능의 변경에서 이 과정이 필요한지를 먼저 판단한다.
      º 어떤 기능 변경이 외부 웹 환경의 변화를 요구하지 않는다면 이 과정은 생략할 수 있다.
      º 변화 자체가 trivial에 해당한다면, 이를 Patch 리뷰 단계에서 주장하고 리뷰어 (Reviewer)가 그것을 허용한다면 이 과정을 역시 생략할 수 있다.
      º 어떤 기능 변경이 외부 웹 환경의 변화를 요구하지만, Blink가 아닌 Chromium의 변화에 의해 변경되는 것이라면 chromestatus.com에 entry를 하나 추가하고 chromium-dev에 “Web-Facing Change PSA” 메일을 보낸다.
      º Blink의 변화가 필요한 경우 2번을 수행한다.

    4. ② blink-dev mailing list에 “Intent to implement”를 보낸다.
      º chromestatus.com에 entry를 하나 추가하고, OWP launch tracking을 Issue Tracker에 생성한다.
      - OWP launch tracking은 추가로 보안 및 개인정보 검토가 필요한지 아닌지를 판단하기 위해 격주마다 검토된다.
      - chromestatus.com 항목은 예를 들면 Chrome beta blog에 Web Platform Change에 대한 홍보를 위해서 사용될 수 있고, 웹 개발자와 브라우저 벤더가 새로운 기능에 대한 가시성을 확보하기 위해 매우 중요하다.
      º 구현을 진행하기 위해서는 API Owners들의 공식적인 승인은 필요하지 않지만, 공개 메일링 리스트에서 최소한 일주일 이상 해당 기능 구현에 대한 반대가 없어야 한다. 별다른 반대 의견이 없다면 이것을 구현하는 데 문제가 없다.
      º  경우에 따라서 프로세스를 간소화하기 위해 2번, 3번, 5번을 한번에 수행할 수 있다. 단 이때는 반드시 API Owners들의 허락을 받아야만 한다.

    5. ③ 필요한 기능을 구현한다. 일반적으로 구현할 때는 Runtime-Enabled Flag를 만들고, 해당 기능이 Open Web에 노출되지 않도록 구현해야만 한다.

    6. ④ 필요한 경우, origin trial이라고 부르는 웹 플랫폼 실험 환경에서 기능을 실험해볼 수 있다.
      º 이 실험을 수행하기 위해서는 5번과 마찬가지로 최소한 3명 이상의 API Owners들의 지지를 받아야만 한다.
      º 이 실험의 목적은 API를 디자인하거나 신규 기능을 검토하기 위해 웹 개발자들로부터 피드백(Feedback)을 받기 위해 사용될 수 있다.
      º 최대 3개의 릴리즈에 대하여 실험을 해볼 수 있으며, 피드백 이후 API나 기능상에 변경이 있으면 4번 단계를 다시 수행하여야만 한다.

    7. ⑤ 구현된 기능을 실제 웹 환경에 노출하기 위해 blink-dev로 “Intent to ship”을 보낸다.
      º 반대가 없어야 하며, 최소 3명 이상의 API Owners의 지지를 받아야 한다.
      º 매주 화요일 해당 Intent에 대한 검토 회의가 열린다.

    8. ⑥ 최종적으로 Runtime-Enabled Flag를 stable로 변경하여 Default Enable 한다.
      º 이때 Runtime Flag는 바로 삭제하지 않고, 어느 정도 안정성이 확보 된 이후에 플래그를 삭제하는 것이 권장된다.
      º Intent to ship이 LGTM을 받으면, Default Enabled Patch에서는 API Owners의 허락을 필수적으로 요구하지 않는다.

    9. 4.5. 기존 기능 및 API의 삭제 과정
      ① 기존 기능의 삭제가 이 과정이 필요한지를 먼저 판단한다.
      º 어떤 기능의 변경이 외부 웹 환경의 변화를 요구하지 않는다면 이 과정은 생략할 수 있다.
      º 변화 자체가 trivial에 해당한다면, 이를 Patch 리뷰 단계에서 주장하고 리뷰어 (Reviewer)가 그것을 허용한다면 이 과정을 역시 생략할 수 있다.
      º 기능 삭제의 경우 웹을 깨트리게 되면 일반적으로 Canary, Dev, Beta와 같은 과정을 거치면서 대부분 발견되게 되고, Stable까지 가기 전에 안정적으로 되돌릴 수 있으므로 지나치게 조심스럽게 기능 제거를 할 필요는 없다. 다만, 이러한 문제에 대해서는 리뷰어의 책임감 있는 리뷰가 필요하다.


    1. ② 실제 사용률에 대한 데이터 측정이 필요한지를 판단해야 한다.
      º 호환성 문제를 일으키지 않는다는 것을 확신할 수 있다면 데이터 측정이 필요 없다. 하지만 확신할 수 없다면 데이터 측정을 먼저 수행해야만 한다.
      º 실제 사용률 측정하기
      - 먼저 UseCounter::Feature enum을 하나 추가한다.
      - MeasureAs라는 Extension을 IDL단에 측정할 API에 대하여 추가한다.
      - 데이터가 어느 정도 확보될 때까지 기다린다.

    2. ③ blink-dev mailing list에 “Intent to depreate”를 보낸다.
      º Deprecation을 진행하기 위해서는 API Owners들의 공식적인 승인은 필요하지 않지만, 공개 메일링 리스트에서 최소한 일주일 이상 해당 기능 구현에 대한 반대가 없어야 한다. 별다른 반대 의견이 없다면 이것을 Deprecation하는 데 문제없다.
      º 어떤 기능을 삭제하기 위한 구체적인 계획 없이는 Deprecation하지 말아야 한다.
      º Deprecation은 삭제가 아니며, 이것을 수행한다고 해도 기존 웹은 유지된다.

    3. ④ Deprecation 수행 및 경고 메시지
      º Deprecation을 수행할 때 사용률 확보가 되어있지 않는다면 향후 삭제 시 근거 자료 마련을 위해 실제 사용률 측정을 먼저 수행한다. (2번 단계 참조)
      º 웹 개발자들에게 이러한 기능 및 API가 곧 삭제될 수 있을 것이라는 메시지를 표시해줘야만 한다. 이 메시지는 구체적으로 어떤 milestone에서 삭제될 것이라는 것을 명시해야만 한다.

    4. ⑤ Deprecation 이후 기능 및 API를 제거하기 위해 blink-dev로 “Intent to remove”를 보낸다.
      º 반대가 없어야 하며, 최소 3명 이상의 API Owners의 지지를 받아야 한다.
      º 매주 화요일 해당 Intent에 대한 검토 회의가 열린다.

    5. ⑥ API Owners들의 승인 이후 해당 기능을 삭제한다.


5. Blink의 개략적인 구조 (현재 및 미래)


3_blink architecture.png

[그림3] Blink의 개략적인 구조


Blink는 앞서 설명한 것처럼 크롬의 경우 WebKit2 이전에 Multi-process Architecture를 도입하고 있었으므로 Fork 직후 WebCore(WebKit1)에 해당하는 코드만 존재했으나 이후 많은 변경을 거치면서 Blink에는 인터페이스 및 기본적인 골격만 존재하고 실질적인 구현이 Content 레이어에 있는 경우가 많이 생겼다(예를 들면 Service Worker와 같은 기능들). 또한, 기존 WebKit 시절, 엔진 쪽 변화를 최소화하기 위해 존재하였던 많은 Abstraction이 구조를 매우 복잡하게 만들었고, 이제는 이러한 레이어들이 불필요하게 되었다. 이러한 이유로 기존 레거시 IPC의 문제점을 해결하고 구조를 간략히 하기 위해 도입된 새로운 Mojo IPC를 이용하여 Content 레이어에서 renderer와 child를 Blink 내부로 통합하기 위한 노력의 일환인 Onion Soup 프로젝트를 진행 중이다. 위 그림은 Onion Soup 프로젝트를 기반으로 작성된 Blink Architecture이다.


5.1. Public Layer
Public 레이어는 기본적인 ADT(API Data Types)와 Public 인터페이스로 구성된다. 이 레이어는 실질적인 구현을 하지 않으며 Services 레이어와 Engine 레이어에 의해 구현된다. 여기에서 제공되는 API들은 Browser 레이어에서 사용되며 이를 이용하여 실질적으로 브라우저가 구현된다.
ADT(API Data Types)는 Public API에서 Blink 밖으로 데이터를 전달하는 데 필요하다. 예를 들면 WebString, WebVector와 같은 것들이 있으며, 이것들은 각각 Blink 밖에서 std::string, std::vector와 같은 형태로 변환된다. System 레이어 내부의 Platform 레이어(플랫폼의 실질적인 구현을 위한 레이어)에서도 Blink 밖으로 데이터를 전달할 경우가 생길 수 있는데 이때는 ADT를 사용하는 것을 강제하지는 않으며 Mojo Type을 그대로 이용할 수 있다. 그러나 복사를 방지하기 위해 Platform 레이어에서도 ADT 사용을 고려할 수 있다.


5.2. Browser Layer
Browser 레이어는 Blink를 사용하는 브라우저, 즉, 크롬을 위한 레이어이다. Frame Loading 및 Navigation Process와 같은 기본적인 동작들을 컨트롤 하고, Blink의 Rendering Life Cycle에 맞춰 적절하게 각각의 Frame들을 스케줄링(Scheduling)한다.

Content 및 Components 레이어는 Multi-process Architecture와 Navigation, Loading and History 서비스를 구현한다. 또한, out-of-process를 위한 프레임 관리를 하기도 한다. 결국, Content 레이어는 System에 있는 Platform 레이어 내부에서 사용되는 Service들의 집합으로 볼 수 있다. 이 Service들은 Blink 내부와 통신하기 위해 Mojo를 사용해 IPC를 주고받을 수 있으며 필요한 경우 또 다른 외부 구성요소와 통신할 수 있다.


5.3. Services Layer
서비스(Service) 레이어는 브라우저 구현을 위한 고급 기능들(High Level Services, 예를 들면 Autofill, 번역 기능)을 제공하기 위해 엔진에서 처리해야 하는 일들을 모듈 단위로 모아놓은 레이어이다.
이 서비스들은 Blink에서 Content로 Public API들을 통해 제공되며, Content 레이어에서 사용된다.


4_service layer.png


[그림 4] Services Layer


5.4. Engine Layer
Engine 레이어는 실질적으로 웹 개발자에게 노출되는 Platform API들의 실질적인 구현체이다. 여기에는 가장 기본적인 DOM 및 Rendering(Layout)에 대한 구현과 Web Payments, Web Bluetooth, File System과 같은 IDL을 통해 노출되는 JS API들이 C++로 구현된다.
core디렉토리는 기존 WebKit에서 WebCore에 해당하며, DOM과 Rendering, Loader와 같은 웹 브라우저 엔진이 가져야 할 가장 기본적인 내용(HTML5에 해당)이 존재하게 되며, module 디렉터리는 이러한 DOM과 상호작용하는 JS 형태의 API 구현체들이 존재하게 된다.


5_Engine Layer.png

[그림 5] Engine Layer

5.5. System Layer
앞서 설명한대로 Blink는 추상화된 플랫폼 상단에 있는 레이어이기 때문에 단독으로는 실행될 수 없다. 그래서 OS Dependency가 있거나 Browser에서 구현되어야 할 내용은 Platform 레이어에 존재하게 된다. 또한, 이 레이어에서는 WTF 및 base와 같은 기본적인 자료구조와 Mojo IPC를 포함한다.


6_system layer.png

[그림 6] System Layer




[필자소개]

방진호.png

 방진호

주요경력

(2010) 삼성소프트웨어멤버십 
(2011 ~ 현재) 삼성전자

(2014 ~ 현재) Chromium/Blink Committer

활동 커뮤니티오픈프론티어 파트 3기
전문분야Linux Platform, Web Browser Engine



by 공개SW역량프라자에 의해 작성된 이 저작물은 크리에이티브 커먼즈 저작자표시-변경금지 4.0 국제 라이선스에 따라 이용할 수 있습니다.







List of Articles
번호 제목 글쓴이 날짜 조회 수
공지 오픈프론티어 개발 프로젝트 연재 OSS 2016-08-06 2456
25 [3기 정진영 개발자] XPUSH (실시간 커뮤니케이션 플랫폼) file OSS_ 2017-02-20 1233
» [3기 방진호 개발자] Blink (웹브라우저 크롬의 레이아웃 엔진) file OSS_ 2017-02-20 1129
23 [3기 송태웅 개발자] Linux Kernel - perf(리눅스 서버의 버전별, 기능별 성능측정 분... file OSS_ 2017-02-08 2909
22 [2기 채수원 개발자] Yona (설치형 프로젝트 호스팅 SW) file OSS_ 2017-02-08 1295
21 [2기 김현종 개발자] UrQA (Android Crash Report 도구) file OSS_ 2017-02-07 1025
20 [2기 임정민 개발자] 구름IDE (클라우드 통합 개발 환경) file OSS_ 2017-02-07 1283
19 [3기 김영근 개발자] Pandas (빠르고 유연한 데이터 처리를 위한 파이썬 라이브러리) file OSS 2016-12-22 1630
18 [3기 윤제상 개발자] Apache Zeppelin (빅데이터 처리툴 Spark의 실행과 데이터 시각... file OSS 2016-12-16 2399
17 [3기 신정규 개발자] 텍스트큐브/메모리큐브 (개인화에 집중한 설치형 블로그 서비스 ... file OSS 2016-12-16 1138
16 [3기 김종광 개발자] IoT분야의 통신, DB, 데이터 분석을 지원하는 개발지원플랫폼 file OSS 2016-12-15 1261


사이트하단 로고, 하단메뉴, 트위터 바로가기

퀵메뉴모음
퀵메뉴열기
퀵메뉴닫기