네이버 웨일, 리베이스 36주→2달로 줄인 해법은?

자동화·인력 효율 개선 덕봐

네이버 브라우저 '웨일' 개발팀이 리베이스 과정 동안 겪은 시행착오와 노하우를 공개했다. 리베이스는 오픈소스 프로젝트 버전을 변경할 때 수정사항을 옮기는 작업을 의미한다.

네이버는 16일 서울 삼성동 코엑스에서 개발자 컨퍼런스 '데뷰(DEVIEW) 2017'을 개최했다.

홍영기 웨일 UI 개발자는 데뷰 2017에서 '오픈소스를 쓰려는 자, 리베이스의 무게를 견뎌라' 세션에서 두 번의 리베이스에서 파악한 문제와 해결 방법, 향후 개선 방향에 대해 소개했다.

홍 개발자는 우선 전체 소요 시간을 줄이기 위해 각 개발자들이 독자적으로 리베이스하는 방식을 택하기보다 리베이스 전반을 담당하는 개발자를 정해야 한다고 조언했다. 또 자동으로 코드를 변경하는 기법을 적용한 두 번째 리베이스 과정에서는 시간을 크게 절약할 수 있었다고 덧붙였다.

네이버 홍영기 웨일 개발자가 '데뷰 2017'에서 세션을 진행하고 있다.

■ 36주→8주…"향후 6주로 단축"

웨일은 당시 구글의 오픈소스 웹 브라우저 크로미움 52버전을 기반으로 만들어졌다. 오픈소스인 크로미움에 이미 구현돼 있는 여러 브라우저 기능을 쉽고 빠르게 지원하기 위해서였다.

그러나 출시 시점인 작년 12월 당시엔 크로미움 56버전을 사용하고 있어 이용자들의 버전 업데이트 요구가 속출했다. 또 웨일 버전 업데이트를 권하는 경고 알림이 이용자에게 나타났고, 이는 보안에 취약한 인상을 줄 수도 있다는 것이 웨일 개발팀의 판단이었다.

이 때문에 개발팀은 당시 베타 버전이었던 크로미움 58버전을 기반으로 리베이스를 결정했다.

첫 리베이스는 총 36주가 걸렸다. 4주를 한 달로 잡아 계산하면 약 9개월에 달하는 기간이다. 이 당시 홍 개발자는 비효율적인 방식으로 리베이스를 진행하고 있었다고 회상했다.

홍영기 개발자는 "모든 개발자가 담당 영역의 리베이스를 동시에 시작했는데, 개개인이 독립적으로 과정을 진행하는 반면, 각 모듈은 서로 의존적이라 다른 작업자의 일정에 영향을 받았다"며 "모든 개발자가 리베이스에 매달리다 보니 신규 기능 개발이 중단되는 단점도 초래됐다"고 설명했다.

총괄이 없다 보니 미리 발견하지 못한 실수도 나타났다. 리베이스 이후 초반에는 웨일 브라우저에서 구글의 고객센터 페이지로 접속되는 오류도 나타났다.

첫 리베이스를 통해 메모리 사용량이 최적화되면서 메모리 부족이나 크래시 오류 현상은 크게 줄어들었다. 그러나 이처럼 장기간의 리베이스 과정을 일 년에 여러 번 반복할 경우 개발자들에게 큰 부담이 될 수 있었다.

이후 다시 진행한 리베이스에서는 담당 개발자가 전체 과정을 진행하고, 각 모듈의 담당자만 해결할 수 있는 부분을 남겨두는 방식을 택했다. 결과적으로 첫 리베이스에서 2달이 걸렸던 코드 리베이스가 4주 만에 끝나는 성과를 거뒀다.

자동화 기법도 활용했다. 웨일에 사용됐던 이미지, 문자열, 다국어 등의 리소스를 크로미움 최신 버전에 일일히 집어넣던 것을 오버라이딩 스크립트 기법을 적용, 자동으로 대체했다. 오버라이딩 스크립트 기법은 웨일과 크로미움의 리소스 ID를 비교, 동일한 ID에 같은 리소스를 대신 첨부하는 것이다.

2달만에 완료된 두 번째 리베이스를 뒤로 하고, 네이버 홍영기 웨일 개발자는 더 높은 목표치를 제시했다. 크로미움처럼 6주 안에 리베이스를 끝내면서 신규 개발도 진행할 수 있게 하겠다는 것이다.

홍영기 개발자는 "리베이스 이후 검증 방법에 있어 자동화 방식을 더 많이 도입해야 할 것 같다"며 "트라이봇이나 유닛테스트 등의 방법도 향후 사용해보려 한다"고 말했다.