[141] 오픈소스를 쓰려는 자, 리베이스의 무게를 견뎌라

오픈소스를 쓰려는 자
리베이스의 무게를 견뎌라
홍영기

About me
Career
- 2014.11~ NAVER Whale
- 2009.2~2014.11 LG전자
- 2012~ Chromium contribution
Public speaking
- 브라우저는 VSync 를 어떻게 활용하고 있을까 - DEVIEW 2015
- Unified BeginFrame - BlinkOn4

Contents
0. 백그라운드
1. 웨일 브라우저 개발의 시작
2. 첫번째 리베이스
3. 첫번째 회고
4. 리베이스 시간, 조금 더 줄여보자
5. 두번째 리베이스
6. 두번째 회고
7. 앞으로..

0. 백그라운드
웨일
크로미움
리베이스

0.1 Whale
옴니태스킹
스마트
향상된 성능
나만의 디자인 http://whale.naver.com/

0.2 Chromium
오픈소스 웹 브라우저 프로젝트
웨일은 오픈소스 Chromium 기반 브라우저
다양한 상용 브라우저의 기반 프로젝트
- Chrome (www.google.co.kr/chrome/)
- Opera (www.opera.com)
- UC 브라우저 (www.ucweb.com)
- 스윙 브라우저 (swing-browser.com)
- MS의 안드로이드 Edge 브라우저 프리뷰(Google Play)
이미지 출처: https://blog.chromium.org/

0.3 리베이스
직접 수정하여 사용중인 오픈소스 프로젝트의 버전을 변경하
는 경우,
변경된 버전에 수정 사항을 옮기는 작업
Version A Version B
Changes Changes
수정 사항 적용

리베이스는 그냥…
git rebase 으로 되는거 아닌가요?

1. 웨일 브라우저 개발의 시작

1.1 Chromium을 선택
WebKit 기반의 자체 엔진으로 브라우저 개발을 시작
했으나
결국 Chromium 기반으로 구현하기로 결정
- 5년간의 네이버 웹엔진 개발/삽질기 그리고... (DEVIEW 2016)

1.2 어떻게 수정할 것인가
Chrome layer 를 직접 사용하여 개발
Chromium
WebView(Contents layer)
Browser(Chrome layer)
브라우저의 기능이 구현된 계층
(ex, 탭, 옴니박스, 북마크, 히스토리 등
등)
웹컨텐츠 렌더링을 담당하는 계층
(웹뷰, 멀티 프로세스 렌더링)

1.3 웨일 베타 출시
Chrome layer 의 사용으로
짧은 5개월여의 개발기간에 베타 버
전의
웨일 브라우저 출시

1.4 빠르게 발전하는 크로미움
베타 출시 때부터 최신 크롬과 큰 버전 차이가 생김
- 웨일은 52
- 크롬은 56
사용자들의 크로미움 버전업 요구

1.5 리베이스 필요
그당 시 베타버전이었던 Chromium 58버전으로
리베이스 결정
Chromium
52
Chromium
58
Whale Whale
수정 사항 적용

2.1 Whale changes
7165 files changed,
775514 insertions,
22363 deletions
Chromium 52
Whale

2.2 Chromium changes
Major 6 version update (52 -> 58)
- 152896 files changed
- 7514461 insertions(+)
- 5542626 deletions(-)
- 36주 개발기간(6주 릴리즈)
- 큰 버전 차이로 인해 많은 부분들이 변경 됨

2.3 많은 Conflicts
1609 files conflicted
빈번히 수정되는 Chrome layer 의 사용이 주 원인

2.4 리베이스 방식
모든 개발자가 담당영역 리베이스 동시에 시작
리베이스 방식
- 커밋 리플레이
- 처음과 마지막 버전의 차이 적용

2.5 코드 리팩토링(C++)
Conflict 해결을 좀 더 쉽게 하기 위해
- 가드 사용해서 구분함 (#ifdef WHALE_DEV)
Conflict를 줄이기 위해 섞여있는 코드를 구분하고 파일을 분
리
- 상속으로 동작 변경이 가능할 경우, 별도의 파일로 구현
- 소소한 코드 수정 팁
* In-class initialization
* 파일/함수의 중간에 추가코드 삽입
* Alias 사용

2.6 일정
코드 리베이스에 약 2개월의 시간 소요
리그레션 처리에 4주 정도 소요

3. 첫번째 회고
실수들..
신규 기능 개발
사기 저하

3.1 발견하지 못한 실수

3.2 힘든 신규 기능 개발
개발자 모두가 담당 부분 리베이스 진행으로
리베이스 기간동안 웨일의 신규 기능 개발은 중단됨

3.3 비효율적인 작업
개개인이 독립적으로 리베이스 완료가 어려움
모듈들이 서로 의존적이어서 다른 작업자의 일정에 영향을 받
음

3.4 느낀점
리베이스후 어려운 이슈(OOM, Crash) 들이 많이 해결
가성비가 뛰어난 작업임을 느낌
코드 리팩토링 & 클린업의 기회

3.5 하지만..
리베이스에 많은 시간을 투자하고 싶지는 않다..
업무 시간의 상당부분이 리베이스 작업이라면 사기 저하가 예
상
이미지 출처: http://money.cnn.com/2016/05/03/news/boring-job-lawsuit/index.html

4. 리베이스 시간,
조금 더 줄여보자

4.1 새로운 리베이스 방식 시도
개발자 한명이 리베이스를 시도
- 기계적인 리베이스
- 간단한 Conflict 는 직접 해결
- 구현자의 도움이 필요한 부분은 남겨둠
- 2주 정도에 대부분의 코드를 리베이스 함
웨일 신규 기능 구현을 위해 더 이상 진행하지 않았지만,
이 방식으로 좀 더 빠르게 완료할수 있겠다는 가능성을 봄

4.2 리소스 처리
리소스(이미지, 문자열, 다국어)의 경우
크로미움의 리소스를 직접 수정하여 웨일의 리소스를 적용
크로미움의 리소스를 건드리지 않고 웨일의 리소스를
적용할 수는 없을까?

4.2 리소스 처리
빌드시점에 리소스 오버라이딩 스크립트 적용
IDS_RELOAD_BTN_TOOLTIP = “XXX”
IDS_STOP_BTN_TOOLTIP = “YYY”
IDR_HOME_BUTTON = “home.png”
<Chromium resources>
IDS_STOP_BTN_TOOLTIP = “ZZZ”
IDR_HOME_BUTTON =
“home_whale.png”
<Whale resources>
IDS_RELOAD_BTN_TOOLTIP = “XXX”
IDS_STOP_BTN_TOOLTIP = “ZZZ”
IDR_HOME_BUTTON = “home_whale.png”
<Resource pack>
빌드

5.1 Changes & Conflicts
Whale
- 6712 deletions(-)
58버전의 Whale 수정 내용과 Chromium 60
Conflict
- 1577 files conflicted
Chromium (58 -> 60)
- 3359676 deletions(-)

5.3 리베이스 방식
한명의 개발자가 기본적인 리베이스 진행하고
모듈 담당자가 꼭 봐야하는 부분만 남겨둠
이후 담당자가 Conflict 를 처리

5.4 일정
코드 리베이스에 약 총 4주의 시간 소요
리그레션 처리에 4주 정도 소요

6. 두번째 회고
리그레션..

6.1 리베이스의 두단계
컴파일 타임 리베이스
- 초기 코드 리베이스
- 담당 개발자가 Conflict 처리
런타임 리베이스
- 리베이스된 코드가 제대로 동작하는지 검증

6.2 일정 단축
0
2
4
6
8
10
컴파일 타임 런타임
첫번째 리베이스 두번째 리베이스
(주)

6.3 Code conflict
오리지널 소스코드가 변경되면 Conflict 는 피할 수 없었음
리소스의 경우는 오버라이딩 기법으로 Conflict 해결

지금은 어플리케이션 테스트에 의존
Unit test, Trybot 도입 필요
7.1 검증 방법의 개선

크로미움의 스케줄과 같은 6주 리베이스
6주안에 리베이스 & 신규개발
7.2 궁극의 목표

[141] 오픈소스를 쓰려는 자, 리베이스의 무게를 견뎌라

More Related Content

What's hot

Viewers also liked

Similar to [141] 오픈소스를 쓰려는 자, 리베이스의 무게를 견뎌라

More from NAVER D2

[141] 오픈소스를 쓰려는 자, 리베이스의 무게를 견뎌라