네이버의 FE 오픈소스에서  까지

  2017.10.26 

 박재성

네이버의 FE 오픈소스Front-End open source

 

 

 

History (2007 ~ 2017)2007.03 Jindo 개발

2008.12.31

2010 Jindo 외부 공개 (네이버 개발자센터)

2010.12.15  ( )

2010.12.29 Jindo Component(JC) 공개

2011.08.16

2012.04 Jindo v2.0

2014.12.23 JindoJS -   /   /   (GitHub 공개)

2015.12.24  - jQuery 기반의 UI 컴포넌트

2016.10.24

2017.06.08  - 차트 라이브러리

2017.08.17 egjs v2.0 - jQuery 의존성 제거

SmartEditor v1.0 공개

SmartEditor v2.0 Repo

Jindo Mobile Component(JMC) 공개

Jindo JMC JC

egjs 발표

JindoJS 개발 중단 발표

billboard.js 공개

초기의 개발은실무적인 고민의 결과물로,

오픈소스로 공개를 위한

목적의 개발은 아니었다.

오늘 발표는 과거 경험을 공유해

성공적인 오픈소스 등장에도움을 주고 싶기 때문

네이버에서의 시행착오는

다른 미래의 오픈소스 성공을 위한

도움이 될수 있지 않을까?

'역사'를 아는 것은현재를 더 잘 이해하고,

더 나은 미래를 위해

중요하기 때문[참고] A Brief History of JavaScript:  ,   

  

#1 #2A brief history of CSS until 2016

A history of HTMLSolar System of JS

FE가 전문 영역으로 인정된 것은

불과 최근 몇년 전에 불과우리는 주로 '소비'하는 입장

다른 영역에서 성공한 국내 오픈소스들도 있지만...

FE 기술영역에서는 두드러진 결과를 얻고 있지는 못하다.

혹시, 기억하시나요?

 0:00 / 0:31

https://www.youtube.com/watch?v=vZwbdgzg3Tc

기억하고 계시다면... '아ㅈ' 아, 아닙니다.

수많은 자체 개발 FE 라이브러리들이

이전에도 그리고 지금도네이버 서비스의 곳곳에서 '여러분'들을 만나고 있습니다.

지난 10년의 기록2007 ~ 2017

 

2007 ~ 2016

AJAX 프레임워크

당시 라이브러리들에 대한 아쉬움네이버 서비스들에서의 빠른 이슈대응 필요성

[참고]   ( ) 자바스크립트 UI 개발과 Jindo 프레임워크 무료 eBookNHN DeView 2008: Jindo & SmartEditor

2013년 무렵까지 네이버 서비스의

기본 라이브러리로 사용

최초 버전은 Native 객체를 확장

["apple", "banana", "orange"].has("orange"); // Jindo classic

Jindo2 - wrapper 클래스를 사용

$A(["apple", "banana", "orange"]).has("orange"); // Jindo2

 Architecture

[참고] NHN의 안과 밖: Jindo와 jQuery

 

2008 ~ present ( 은 미공개)v3.0

WYSIWYG 웹에디터카페/블로그 등 UGC 서비스를 위한 필요성공통 에디터가 없었음당시 기존 에디터들의 기능 미약외부 사용자들의 요구는 점점 커지고 다양해짐

최초 버전은 5명이 6개월간 개발

[참고]    

NAVER Inside: SmartEditor그 이름은 '스마트 에디터™' 입니다.네이버 스마트에디터가 나오기까지

는 

네이버의 다양한 UGC 플랫폼에서 기본 에디터로 사용

[참고]   / GitHub Online Demo

 

Mobile Component (JMC)2011 ~ 2016

 후, 2009/11월 iPhone 3GS 국내출시

모바일의 폭발적인 성장으로 인한 필요성크로스 플랫폼과 앱스러운 UI/UX 개발 위해

[참고]    

DEVIEW 2011: 모바일 웹 UI 개발 아직도 맨땅에 삽질부터 하십니까?쉽고 빠른 모바일 웹 UI 개발 Jindo 기반 모바일 전용 컴포넌트, JMC

40여개 이상의

모바일 UI 컴포넌트다양한 모바일 환경 지원 강점 

[참고] JMC API

Behind Story당시 코드네임은 개 품종에서 차용 관례

JindoHuskySharpeiBeaglePekingeseCollie

[참고] http://www.akc.org/dog-breeds/

 

2015 ~ present

개발 당시는 웹 프레임워크들 등장 초기 시점

jQuery → 업계의 de facto standardjQuery에서 사용 가능한 모바일 컴포넌트 필요기존 JMC의 대체 라이브러리 역할도 포함

[참고] 네이버의 모던 웹 라이브러리

10종의 모바일/데스크탑UI/UX 컴포넌트들

Component Description

사용자 입력 반응 응용

캐로셀 UI 구성

무한 카드 UI 스크롤

360도 뷰어

요소의 뷰포트 노출 확인

브라우저 정보

화면 회전 이벤트

페이지 상태 저장 (BFCache)

jQuery 애니메이션 진행 제어

jQuery animate 확장

Axes

Flicking

InfiniteGrid

View360

Visible

Agent

Rotate

Persist

$PauseResume

$Transform

egjs-flickingBrown

egjs-axes

 

2017.06.08 ~ present

재사용 가능한 쉬운 인터페이스 차트 라이브러리

C3.js fork 프로젝트

네이버 블로그/포스트 통계 개선으로 시작라이브러리 사용의 공통화

[참고]   [네이버 블로그] 블로그 통계가 새로워졌습니다![네이버 포스트] 훨씬 좋아진 통계, 지금 제공합니다!

Declarative APIReadable & Understandable: 쉬운 인터페이스

bb.generate({ bindto: "#chart", data: { columns: [ ["data1", 30, 200, 100, 400, 150, 250], ["data2", 100, 80, 130, 240, 350, 90], ["data3", 150, 120, 58, 135, 258, 159] ], type: "bar", colors: { data1: "#2acefd", data2: "#f87070", data3: "#1f77b4" }, labels: true } });

[참고] billboard.js API

Let's Play Chart!

bar   line   spline   pie   gauge   area‑spline   step   donut   scatter

30

200

100

400

150

250

100

80

130

240

350

90

150

120

58

135

258

159

0 1 2 3 4 5

0

50

100

150

200

250

300

350

400

450

data1 data2 data3

초기 웹개발 환경에선

'네이버'가 만든 것에 대한 신뢰가 존재

그러나,점점 '네이버'만의 것은 범용성과 

글로벌한 '성장'은 한계성 존재

반성각각의 Product 들은 목적이 분명했다.

그러나 그 목적이 '오픈소스'와 완전히 부합 했다고 보기는 힘들었던 것 같다.

형식적 '오픈소스' 였던 것은 아닐까?

관점의 변화Phase 1: 2007 ~ 2014

내부 경쟁력과 빠른 대응을 위해

Phase 2: 2015 ~ 현재오픈소스를 바라보는 '관점'과 '원칙'의 변화

기본 원칙 1오픈소스의 활용

좋은 오픈소스가 있다면, 사용한다.

필요한 경우, 커스터마이징 한다.

기본 원칙 2직접 개발하는 경우

기능/성능이 아쉬운 경우

전략적 기술확보 필요성

필요한 기능을 가진 라이브러리가 없는 경우

새로운 원칙에 따른

 개발 중단

무엇이 부족했나?외부 레퍼런스, 교육비용, 호환성

빠른 변화, 환경의 민첩한 대응

개발자들의 long term 커리어 및 발전 기여

기술적 고찰오픈소스의 중요 요소들

오픈소스의 중요 요소들안정성, 충분한 문서 그리고 책임감

[참고] http://opensourcesurvey.org/2017/

안정성 확보 방안들각 단계별 품질 유지를 위한 자동화 검사

커밋 관리를 위한 일관된   적용정적 검사(linting): 

을 통한 자동 검사 수행를 통한 품질 자동화 검사

커밋 로그 룰eslint-config-naver

commit/push hookCI

테스트 코드다양한 도구 활용:  ,  ,  , 

를 활용한 TC 수행커밋에는 TC가 포함 되어야 함

Mocha Chai Sinon KarmaHeadless browser

도구의 활용품질 향상을 위한 많은 도구들이 상용인 경우라도 

오픈소스에는 무료로 제공된다.

[참고]   Tools for Open SourceGitHub Marketplace

기웃거리기유명한 오픈소스 프로젝트들의 사례를 참고

commit log rule & hook (AngularJS, jQuery)

환경구성 (linting, test, build, etc.)

다른 프로젝트들의 package.json은 많은 것을 알려줄 수 있다.

집중과 선택JMC에서 경쟁력 있다고 판단된 것들만 

egjs 컴포넌트로 재개발

<JMC → egjs 전환비율>

오픈소스 사용 전환 (67%)

직접 개발 (22%)

개발 중단 (11%

)

능동적 변화전통적인 DOM 직접 핸들링(like jQuery) → Framework 개발 패러다임 전환

의존성을 갖지 않는 컴포넌트 요구 증가

 v2.0은? 

1개의 공통 라이브러리에서, 

10개의 독립된 컴포넌트로의 전환

흐름에 맡기다.의 경우, 

프로젝트 지속성 의문에 따른 fork 

C3.Js 기능 확장 개발로 시작 → Fork 후 외부공개

[참고] DEVIEW 2017: 14일 만에 GitHub 스타 1K 받은 차트 오픈소스 개발기

적극적 참여 시도2015, jQuery 재단 멤버십

[참고] Wayback Machine: jQuery Foundation Members

좋은 오픈소스 개발을 위한더 깊은 이해를 위한 노력들

Internal 분석 시리즈다른 라이브러리에 대한 이해

AngularJS 도입 선택 가이드jQuery 세부 분석 시리즈React 적용 가이드 시리즈AMP는 어떻게 웹 페이지의 성능을 높일 수 있나

JavaScript/FE 개발 동향 & 기술분석생태계와 기술에 대한 이해 & 분석

2017년과 이후 JavaScript의 동향2016년과 이후 JavaScript의 동향하드웨어 가속에 대한 이해와 적용웹 컴포넌트터치 이벤트를 이용한 사용자 제스처 분석JavaScript 표준을 위한 움직임: CommonJS와 AMD

홍보전략오픈소스의 성장

특정 tag 들에 대한 답변시도 ( ,  , etc.)carousel jquery

Reputation(평판/활동 점수)?   

신규 tag 생성과 신뢰도 등, 활동을 위한 기본적 조건을 위해 필요

라이브러리 자체 인지도가 낮아 큰 반응 얻지 못함

직접 발로 뛰어 보기다수의 'Echo' 사이트에 등록하기

 

 

많은 곳에서 해당 사이트에 등록된 정보를 활용, 재전파 한다.

뉴스레터 소개 요청하기 JavaScript Weekly

[참고] FE 관련 뉴스레터는 사실, 한 곳에서 발행 https://cooperpress.com/

JavaScript Weekly 소개

Issues 308 (16.11.03): Issues 338 (17.06.09): Issues 353 (17.09.22): 

egjs: jQuery-Based UI Interactions, Effects, and Utilities Librarybillboard.js: A Chart Library, based on D3 v4+billboard.js: A Simple Chart Library Based on D3 V4

 Trending!: JavaScript 언어부문 3위 기록

[참고] https://github.com/trending/javascript

오픈소스어떤 의미와 가치일까?

오픈소스성공을 위한 조건들공개는 완성이 아니라, 이제 시작일 뿐

빠른 피드백과 대응

충실한 문서와 데모

지속적 기능 추가/bug fix 및 정기적 릴리즈

Corporate Open Source?패러다임의 전환 

개인의 노력을 통한 발전에서 기업의 후원을 받는 개발로의 전환 

Angular(Google) / React(Facebook)

다른 이들에게 좋지만, 우리(기업)에게 더 좋을 수 있는

내부 이슈의 빠른 대응성신규 기능 구현 가능성 상승대외적 이미지 향상 ...

Why Do

Open Source?세상에서 내가 도움 받은 것에 대해 다시 기여하는 의미있고 가치있는 행동

[참고]   네이버 오픈소스 가이드GitHub Open Source Guides

The Bad

[참고] Equifax blames open-source software for its record-breaking security breach: Report

The Good

[참고] https://twitter.com/s0yuka/status/874530243595436032

지난 10년간의

시간과 도전을 통해우리만의 것이 아닌 모두를 위한 개발

시도할 수록 더 나은 결과

글로벌한 오픈소스 개발의 자신감

오픈소스는 어렵지만, 큰 가치 존재

❤ 

 

T

h

a

n

k

 

Y

o

u!