View360�개발기-오픈소스화로�기술부채�청산한�이야기-�

네이버�FE플랫폼�김희재

내용

소프트웨어�개발�과정에서�기술부채가�왜�발생했고�프로젝트에�어떤영향을�주었으며�오픈소스화로�어떻게�문제상황을�벗어날�수�있었는지�

오픈소스로�공개하면�어떤�장점이�있지?�내�프로젝트로�오픈소스로�할때는�어떤�점에�신경쓰면�좋지?

View360�체험해�보시죠

goo.gl/3vsUUf

현재는�네이버TV에�열심히�적용�중… 360영상도�모바일�브라우저에서�곧!

FE�플랫폼

• 네이버의�FE�기술�지원�조직�• 사내�서비스들을�위한�WEB�UI�라이브러리�개발�• 경쟁력�있는�컴포넌트는�오픈소스로�공개�• egjs,�billboard.js,�jindo.js�

>��여러�서비스들의�이슈를�압축적으로�경험하면서�빠르게�성장�할�것을�기대하고�입사�

“360도�뷰어�만들어�보실�분?”

<�--�오너쉽에�목마른�2년차�FE개발자

요구사항

• 네이티브�WEBGL로�직접�구현�

• 안드로이드�등�모바일�브라우저�호환성�확보�

• 디바이스�모션�컨트롤�

>�정점�쉐이더,�프래그먼트�쉐이더,�OpenGL�렌더링�파이프라인��>�오일러각,�짐벌락,�쿼터니언,�센서퓨전,�칼만�필터,�LERP,�SLERP�…�

“음�..�이해하고�구현해�내면�일단�성공”

기술부채�발생이�불가피했던�상황

• 콘셉트�증명�단계로�간주�• 요구사항만�만족하면�됨�• 관련�지식과�경험이�부족하여�구현�하는�것이�1순위�

• 1인�개발�• 협업을�위해�코드의�품질을�신경�쓸�필요가�없음(!)�

• 문서화?�나중에…�

• 테스트코드?�일단�돌아가야�하지�않을까…�

• CI?�빨리�일단�돌아가게�만들어야�ㅠㅠ

라이브러리를�서비스�부서에�전달했는데…�

>�버그를�수정하면�다른�버그가�발생�

>�QA�사이클로�감당하기�힘들게�연속해서�발생하는�수정�부작용��

>�두번의�배포연기

기술부채(Technical�Debt)

• 빠르지만�지저분한�방식으로�일하면�기술�부채로�압박�받게됨�

• 기술부채를�지고�빠른�출시를�할�수�있음�

• 하지만�기술부채�를�청산하지�않으면�이자가�계속�커짐�

• 이자:�유지보수,�기능추가를�위해�추가적으로�들여야�하는�개발시간�

• 따라서�시기�적절하게�부채�원금을�청산하지�않으면�이자�복리의�효과까지�더해서��망하는�소프트웨어가�됨�

View360�에서의�초기�기술부채

• 테스트�코드�X� �• 하나를�고치면�어디서�부작용이�생길지�알�수가�없습니다.� �• 따라서�기능�추가를�하기�힘들어짐��

• 공감할�수�없는�구조설계�• 남이�공감할�수�없는�구조라면�미래의�나도�이해할�수�없습니다.��• "여기�왜�이렇게�짰지...."� �• 코드만�봐도�구조설계가�납득될�수�있도록�구조를�잘�짜야합니다�

• 군더더기가�많은�API�• 어떤�기능까지�필요하게�될�지�예측해가면서�개발�

• 문서화�• 설계문서,�스펙문서:�최소한�만�수행�• 핵심기술�원리:�X��

처음부터�다시�둘이서�만들기

• 새로운�시니어�멤버!��

• 둘이서�개발진행�

• 와!�이제�코드�리뷰하고�받을�수�있다!��

• WebGL과�센서신호처리관련�이론을�공부하여�출발선�맞춤�

• 구조�설계�함께�진행

오픈소스화�기준에�맞춰부채청산�시작

구글의�사례:�텐서플로

“많은�분들이�구글이�하는�모든�프로젝트가�철저한�계획�아래�깔끔하고�효율적으로�진행될�걸로�생각하십니다.�사실�항상�그렇지�않습니다.�많은�프로젝트가�처음엔�엉망진창이며,�관련된�문서는�찾기�힘듭니다.�같은�일을�여러�번�반복하기도�하죠.�그런데�기술을�오픈소스화하면�(외부에�공개되기�때문에)�문서�작성나�작업을�체계화하는�데�많은�노력을�들입니다.�이건�과정에서�팀�전체가�일주일�동안�문서화�작업에�집중하기도�합니다.�이건�구글에게�매우�좋은�영향을�끼칩니다.”�

�구글�브레인�팀�-�마이크�슈스터�http://www.bloter.net/archives/254962

이슈/커밋메시지/문서는�영어로�작성

• 지나가던�개발자는�웬만하면�영어를�씀�

• 작성하다보면�익숙해짐�

• 비슷한�표현을�스택오버플로우나�다른�깃허브�프로젝트�이슈에서�찾아보면서�응용하면�더�쉽다

커밋메시지�잘�쓰기

• 이�코드는�왜�이렇지?�를�해결�

• 정해진�포멧�준수�

${작업의�종류}(${작업대상�모듈}):�작업�내용�

Ref�#${해당�이슈번호}

Pull�Request�단위를�줄이기�

• 리뷰를�의미있게�하기�위한�조건�

• 되도록이면�1이슈�1PR�이�좋다고�봄

테스트의�중요성

• 기능�추가�전후�두려움이�줄어든다�• 문제�없을거에요!�테스트�통과했으니까!�라고�말할�수�있게된다.� �• 문제�생기면�해당�이슈를�테스트로�추가하면�되니�개꿀!�

• PR을�받을�수�있는�최소한의�준비�

• 테스트�없는�오픈�소스의�경우�PR�을�넣어도� �• 이것저것�테스트�해보고�응답드릴게요�라고�핑계를�대면서�외부PR을�잘�안받는�경우가�있음

테스트�작성

• 구조와�API�설계가�어느정도�안정되고�나서�테스트�작성시작�

• 테스트가�작성이�힘들면�테스트�가능성�높아지도록�리팩토링.� �• 특정기능을�모듈로�분리하거나� �• Mocking�을�용이하게�리팩토링�하거나�

• WebGL�렌더링�테스트�방법�적용� �• 캡쳐한�이미지와�정답�이미지의�diff�를�비교��

• 디바이스�모션은�테스트�헬퍼�구현

PR�단계에서�CI�활용

• CI�지속적�통합�

• PR�을�날렸을때,�해당�코드�품질�체크� �1.�빌드가�되어야함��2.�코드컨벤션이�맞아야함� �3.�단위�테스트를�모두�통과해야함� �4.�테스트�커버리지가�감소하지�않아야함(!)�Travis�CI+�coveralls�좋아요�

느슨해지지�않도록�제3의�감독관이�있는�느낌�

시맨틱�버저닝�

• X.Y.Z�(Major.Minor.Patch)�

• Major:�업데이트�시�기존�코드를�수정해야하는�경우�(breaking�change)�

• Miner:�기존�API�변경없는�기능추가�

• Patch:�API�변경이�전혀없는�버그수정

릴리즈�시�시맨틱�버저닝을�따르기�

• 기존�라이브러리�전달�방식� �• A서비스-�a기능�에�이슈가�있어요�고쳐주세요�(1월�20일)� � �• 수정�후�A_0120�이라는�태그를�따서�전달� � �• A_1023,�B_1120�이라는�태그가�남발.� � �• 수정사항�어떻게�합치지...�

• 사내�버전을�따로�두지�않고�외부�공개된�단일�패키지만�제공하기��• 시맨틱�버저닝을�적용하여,�빠른�이슈�수정요청이�들어올�경우��• 해당�내용을�외부�공개�이슈로�등록�하고�수정반영�하여�바로�릴리즈�후�해당�부서에�제공�• 관리되는�브랜치가�하나라서�합칠�고민�안해도�된다.

가이드�문서�작성하기

• 메이저�업그레이드를�대비한�마이그레이션�문서(!)��• 메이저�버전�변경�릴리즈�시에는�breaking�change�에�대한�문서를�꼭�써야함�(없으면�사내�개발자도�새�버전으로�업그레이드�못해줌…)�

• https://github.com/naver/egjs-view360/wiki/3.0.0-rc-Change-Notes

소개페이지�만들기

• 라이브러리에�대한�이해를�도울�수�있음�

• 소개페이지를�안�만들면�특히�비개발자는�소외됩니다�

• https://naver.github.io/egjs-view360

커뮤니티에�기여하기

이�때�부채청산과정에서�나온�결과물을�활용할�수�있다.�

• 기술�블로그�글�작성�• 내가�해결한�문제를�겪고�있는�프로젝트에�PR�날리기�• 내가�해결한�문제와�관련된�스택오버�플로우�질문에�답변달기��

• 내�프로젝트�진행�중�타�깃허브�프로젝트�이슈들�레퍼런스�걸기(!)�

• 연구�결과�공유하기�� �• 컨퍼런스나�개발자�밋업에서�발표�• DEVIEW�2017�­�밑바닥부터�시작하는�360뷰어

오픈소스화�과정을�통해�얻은점

• 포지셔닝�작업을�통해�존재이유가�생김�• 빠르고�가벼운�모바일웹에서도�잘�돌아가는�360�동영상/이미지�뷰어�

• 라이브러리�품질이�올라감�• 테스트�작성�및�API�설계�완성도�확보��

• 품질이�떨어질�수�있는�여지를�최대한�줄여놓아서�외부개발자�참여를�받기�용이�

naver/egjs-view360�저장소를�방문하시면�발표내용에�언급된�내용들이��

실제로�적용된�모습을�참고하실�수�있습니다.

오픈소스화�과정을�통해�느낀점

• 타인을�고려하면�할�수록�가치가�더해지는�소셜코딩의�힘�

• 나,�미래의�나,�같이�일하는�동료개발자,�타�부서의�개발자/기획자,�사외�개발자/기획자,�내�오픈소스를�이용해�다른것을�개발하는�개발자,�경쟁�오픈소스의�개발자,�스택오버플로우에서�나와�같은�문제로�질문을�올린�개발자,�답변을�단�개발자.��

• 다양한�방식의�활동을�통해�내�프로젝트의�품질도�올라가고,�내�지식과�경험도�확장되는�경험�

•소셜코딩으로�다같이�폭풍성장�해요.

끝!�감사합니다.