1. View360 개발기
-오픈소스화로 기술부채 청산한 이야기-
네이버 FE플랫폼 김희재

2. 내용
소프트웨어 개발 과정에서
기술부채가 왜 발생했고
프로젝트에 어떤영향을 주었으며
오픈소스화로 어떻게 문제상황을 벗어날 수 있었는지
오픈소스로 공개하면 어떤 장점이 있지?
내 프로젝트로 오픈소스로 할때는 어떤 점에 신경쓰면 좋지?

6. View360 체험해 보시죠
goo.gl/3vsUUf

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

8. FE 플랫폼
• 네이버의 FE 기술 지원 조직
• 사내 서비스들을 위한 WEB UI 라이브러리 개발
• 경쟁력 있는 컴포넌트는 오픈소스로 공개
• egjs, billboard.js, jindo.js
> 여러 서비스들의 이슈를 압축적으로 경험하면서 빠르게 성장 할 것을 기대하고 입사

9. “360도 뷰어 만들어 보실 분?”
< -- 오너쉽에 목마른 2년차 FE개발자

10. 요구사항
• 네이티브 WEBGL로 직접 구현
• 안드로이드 등 모바일 브라우저 호환성 확보
• 디바이스 모션 컨트롤
> 정점 쉐이더, 프래그먼트 쉐이더, OpenGL 렌더링 파이프라인
> 오일러각, 짐벌락, 쿼터니언, 센서퓨전, 칼만 필터, LERP, SLERP …
“음 .. 이해하고 구현해 내면 일단 성공”

11. 기술부채 발생이 불가피했던 상황
• 콘셉트 증명 단계로 간주
• 요구사항만 만족하면 됨
• 관련 지식과 경험이 부족하여 구현 하는 것이 1순위
• 1인 개발
• 협업을 위해 코드의 품질을 신경 쓸 필요가 없음(!)
• 문서화? 나중에…
• 테스트코드? 일단 돌아가야 하지 않을까…
• CI? 빨리 일단 돌아가게 만들어야 ㅠㅠ

12. 라이브러리를 서비스 부서에 전달했는데…
> 버그를 수정하면 다른 버그가 발생
> QA 사이클로 감당하기 힘들게 연속해서 발생하는 수정 부작용
> 두번의 배포연기

14. 기술부채(Technical Debt)
• 빠르지만 지저분한 방식으로 일하면 기술 부채로 압박 받게됨
• 기술부채를 지고 빠른 출시를 할 수 있음
• 하지만 기술부채 를 청산하지 않으면 이자가 계속 커짐
• 이자: 유지보수, 기능추가를 위해 추가적으로 들여야 하는 개발시간
• 따라서 시기 적절하게 부채 원금을 청산하지 않으면 이자 복리의 효과까
지 더해서 망하는 소프트웨어가 됨

15. View360 에서의 초기 기술부채
• 테스트 코드 X
• 하나를 고치면 어디서 부작용이 생길지 알 수가 없습니다.
• 따라서 기능 추가를 하기 힘들어짐
• 공감할 수 없는 구조설계
• 남이 공감할 수 없는 구조라면 미래의 나도 이해할 수 없습니다.
• "여기 왜 이렇게 짰지...."
• 코드만 봐도 구조설계가 납득될 수 있도록 구조를 잘 짜야합니다
• 군더더기가 많은 API
• 어떤 기능까지 필요하게 될 지 예측해가면서 개발
• 문서화
• 설계문서, 스펙문서: 최소한 만 수행
• 핵심기술 원리: X

16. 처음부터 다시 둘이서 만들기
• 새로운 시니어 멤버!
• 둘이서 개발진행
• 와! 이제 코드 리뷰하고 받을 수 있다!
• WebGL과 센서신호처리관련 이론을 공부하여 출발선 맞춤
• 구조 설계 함께 진행

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

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

19. 이슈/커밋메시지/문서는 영어로 작성
• 지나가던 개발자는 웬만하면 영어를 씀
• 작성하다보면 익숙해짐
• 비슷한 표현을 스택오버플로우나 다른 깃허브 프로젝트 이슈에서 찾아
보면서 응용하면 더 쉽다

20. 커밋메시지 잘 쓰기
• 이 코드는 왜 이렇지? 를 해결
• 정해진 포멧 준수
${작업의 종류}(${작업대상 모듈}): 작업 내용
Ref #${해당 이슈번호}

21. Pull Request 단위를 줄이기
• 리뷰를 의미있게 하기 위한 조건
• 되도록이면 1이슈 1PR 이 좋다고 봄

22. 테스트의 중요성
• 기능 추가 전후 두려움이 줄어든다
• 문제 없을거에요! 테스트 통과했으니까! 라고 말할 수 있게된다.
• 문제 생기면 해당 이슈를 테스트로 추가하면 되니 개꿀!
• PR을 받을 수 있는 최소한의 준비
• 테스트 없는 오픈 소스의 경우 PR 을 넣어도
• 이것저것 테스트 해보고 응답드릴게요 라고 핑계를 대면서 외부PR을 잘 안받는
경우가 있음

23. 테스트 작성
• 구조와 API 설계가 어느정도 안정되고 나서 테스트 작성시작
• 테스트가 작성이 힘들면 테스트 가능성 높아지도록 리팩토링.
• 특정기능을 모듈로 분리하거나
• Mocking 을 용이하게 리팩토링 하거나
• WebGL 렌더링 테스트 방법 적용
• 캡쳐한 이미지와 정답 이미지의 diff 를 비교
• 디바이스 모션은 테스트 헬퍼 구현

24. PR 단계에서 CI 활용
• CI 지속적 통합
• PR 을 날렸을때, 해당 코드 품질 체크
1. 빌드가 되어야함
2. 코드컨벤션이 맞아야함
3. 단위 테스트를 모두 통과해야함
4. 테스트 커버리지가 감소하지 않아야함(!) Travis CI+ coveralls 좋아요
느슨해지지 않도록 제3의 감독관이 있는 느낌

26. 시맨틱 버저닝
• X.Y.Z (Major.Minor.Patch)
• Major: 업데이트 시 기존 코드를 수정해야하는 경우 (breaking change)
• Miner: 기존 API 변경없는 기능추가
• Patch: API 변경이 전혀없는 버그수정

27. 릴리즈 시 시맨틱 버저닝을 따르기
• 기존 라이브러리 전달 방식
• A서비스- a기능 에 이슈가 있어요 고쳐주세요 (1월 20일)
• 수정 후 A_0120 이라는 태그를 따서 전달
• A_1023, B_1120 이라는 태그가 남발.
• 수정사항 어떻게 합치지...
• 사내 버전을 따로 두지 않고 외부 공개된 단일 패키지만 제공하기
• 시맨틱 버저닝을 적용하여, 빠른 이슈 수정요청이 들어올 경우
• 해당 내용을 외부 공개 이슈로 등록 하고 수정반영 하여 바로 릴리즈 후 해당 부
서에 제공
• 관리되는 브랜치가 하나라서 합칠 고민 안해도 된다.

28. 가이드 문서 작성하기
• 메이저 업그레이드를 대비한 마이그레이션 문서(!)
• 메이저 버전 변경 릴리즈 시에는 breaking change 에 대한 문서를 꼭 써야함
(없으면 사내 개발자도 새 버전으로 업그레이드 못해줌…)
• https://github.com/naver/egjs-view360/wiki/3.0.0-rc-Change-Notes

29. 소개페이지 만들기
• 라이브러리에 대한 이해를 도울 수
있음
• 소개페이지를 안 만들면 특히 비개
발자는 소외됩니다
• https://naver.github.io/egjs-view360

30. 커뮤니티에 기여하기
이 때 부채청산과정에서 나온 결과물을 활용할 수 있다.
• 기술 블로그 글 작성
• 내가 해결한 문제를 겪고 있는 프로젝트에 PR 날리기
• 내가 해결한 문제와 관련된 스택오버 플로우 질문에 답변달기
• 내 프로젝트 진행 중 타 깃허브 프로젝트 이슈들 레퍼런스 걸기(!)
• 연구 결과 공유하기
• 컨퍼런스나 개발자 밋업에서 발표
• DEVIEW 2017 ­ 밑바닥부터 시작하는 360뷰어

31. 오픈소스화 과정을 통해 얻은점
• 포지셔닝 작업을 통해 존재이유가 생김
• 빠르고 가벼운 모바일웹에서도 잘 돌아가는 360 동영상/이미지 뷰어
• 라이브러리 품질이 올라감
• 테스트 작성 및 API 설계 완성도 확보
• 품질이 떨어질 수 있는 여지를 최대한 줄여놓아서 외부개발자 참여를 받
기 용이
naver/egjs-view360
저장소를 방문하시면 발표내용에 언급된 내용들이
실제로 적용된 모습을 참고하실 수 있습니다.

32. 오픈소스화 과정을 통해 느낀점
• 타인을 고려하면 할 수록 가치가 더해지는 소셜코딩의 힘
• 나, 미래의 나, 같이 일하는 동료개발자, 타 부서의 개발자/기획자, 사외
개발자/기획자, 내 오픈소스를 이용해 다른것을 개발하는 개발자, 경쟁
오픈소스의 개발자, 스택오버플로우에서 나와 같은 문제로 질문을 올린
개발자, 답변을 단 개발자.
• 다양한 방식의 활동을 통해 내 프로젝트의 품질도 올라가고, 내 지식과
경험도 확장되는 경험
• 소셜코딩으로 다같이 폭풍성장 해요.

36. 끝!
감사합니다.