1. 협업 SW개발 플랫폼, Yobi
채수원 / 개발자 서비스 개발랩
NAVER LABS

2. CONTENTS
1. Yobi ?
2.어떤 식으로 만들어지고 있나요?
3.배운점과 교훈들
4.향후 계획
5. 결론

3. 본 세션에서 얻을 갈 수 있는 것
- Yobi가 뭐고 왜 만들어 졌나?
- 어떤 개발팀의 SW 개발 방식
- 프로젝트를 진행하면서 배운점과 교훈들
- 동시대 같은 업종(?)에서 살아가는 사람들의 고뇌

4. 발표자 소개
 채수원
 NAVER LABS
 개발자 서비스 개발랩 Technical Leader(TL)
 OctoberSkyJs (NodeJs커뮤니티) 리더
 ‘TDD 실천법과 도구’, ‘Agile Software 101 (공저)’
저자
 SNS
 twitter.com/doortts
 blog.doortts.com

5. 유의 사항
- 최대한 솔직하게 이야기 할거니까
어디가서 이야기 하시면 안되어요…
- 여러분 믿고 이야기 시작합니다..
- 그리고 롤러코스터 처럼 진행될 예정이니까
여러분도 저도 모두 정신 바짝!!

6. "참혹한 운명의 화살을 맞고 마음속으로 참아야 하느냐.
아니면 성난 파도처럼 밀려오는 고난과 맞서 용감히 싸워
그것을 물리쳐야 하느냐. 어느 쪽이 더 고귀한 일일까."
- Hamlet

7. 일반적으로 프로젝트가 시작되면…
기본적인 개발 환경설정 작업이 필요합니다
 코드 저장소가 필요하고
• SVN? GIT?
 이슈를 관리해야 하고
• 엑셀?
• 이메일?
• 어떤 사안의 변경이력을 보려면?
 각종 문서나 파일들도 관리해야 하고
 팀이나 파트가 여러 개일 경우에는 각각 권한 관리도 필요하고…

8. 2000년대 중반~후반
프로젝트 B
프로젝트 A
프로젝트 C
…D

9. 느낀 점과 노력
 발견한 점
 많은 사람들이 충분히 열심히 하고 있지만 이상한 누수가 있다!
 생각보다 적은 노력으로 많은 사람들이 혜택을 볼 수 있는 방법이 존재
한다!
 (프로젝트에는) 돈이 참 없구나…
 좋은 도구든 방법론이든 뭐든 조금만 복잡해져도 쉽게 받아들여지기가
어렵구나..

10. 느낀 점과 노력
 어떤 믿음과 생각
 프로젝트의 이슈는 관리되어야 한다
 개인과 조직의 지식은 전승되어야 한다.
 코드는 안정적으로 저장되어야 하고 원하는 시점으로 언제든 돌아갈 수
있어야 한다.
 코드던지 이슈던지, 어떤 문제든 그 대상에 대해서 관련 있는 사람들,
이를테면 팀원들이나 고객, 기획자들이 서로 쉽게 이야기를 나눌 수 있
어야 하고 그 내용이 보존되어야 한다.
 프로젝트 문서나 파일은 한 곳에서 관리될 수록 좋다!

11. 아!!! 그래!!
 프로젝트 관리 도구가 필요하다!
 프로젝트 멤버들을 관리할 도구 말고…

12. 예를들면..
JIRA (atlassian)

13. 프로젝트 관리도구
 JIRA
 이슈 트래커
 조금 복잡한 감이 있지만 기능 좋음
 사용자 10명까지는 10$이지만 11명부터는? 최소 1200$
 코드관리를 위해서는 동사의 FishEye/Stash를 구매해야 함
• 마찬가지로 10명이 넘으면 최소 각각 1200$
 그리고 문서관리도 함께 하려면 Confluence.. 1200$

14. 어떤 노력… 쉬운 저장소 설치

15. 이슈 트래커 사용
TRAC과 Subversion을 이용한 개발환경 구축가이드

16. 이슈트래커 TRAC (무료)

17. 지속적인 통합 (Continuous Integration)

18. CI서버 - Hudson (=Jenkins)

19. 근데 생각만큼 잘 되진 않았어요… ^^;
그래도 믿음을 잃진 않았습니다..

20. "우린 지금보다 더 나아질 수 있고
충분히 더 잘할 수 있다!"
:D

21. 손수건 손에 들고 들어야 하는
이런저런 사연 뒤에… 2013년…

22. 개발자 서비스 개발랩 - NAVER LABS

23. 1. Yobi ?

24. Yobi ?
 설치형 프로젝트 호스팅 SW
 private / public 프로젝트 선택 생성가능
 오픈소스 (무료로 사용가능)
 Apache License 2.0
 쉬운 설치
 All-in-one
 Java 7 이상, 인터넷 연결된 환경
 의존성 추가 도구들 설치 필요 없음
 Windows / Linux / Mac 지원

25. Yobi 구성






Playframework 2 + JAVA
EBean (ORM)
JGit
Twitter Bootstrap + Custom CSS
LESS
H2 Embedded DB

26. Yobi 사용 중인 곳
 NHN Next
 D2FEST
 d2fest.kr
 NAVER LABS

27. Yobi 주요 기능
 프로젝트 홈

28. Yobi 주요 기능
 게시판

29. Yobi 주요 기능
 코드 브라우저

30. Yobi 주요 기능
 프로젝트 복사/코드 주고받기 (1/2)

31. Yobi 주요 기능
 프로젝트 복사/코드 주고받기 (2/2)

32. Yobi 주요 기능
 코드리뷰 (1/2)

33. Yobi 주요 기능
 코드리뷰 (2/2)

34. Yobi 주요 기능
 이슈트래커 (1/2)

35. Yobi 주요 기능
 이슈트래커 (2/2)

36. 네. 그렇습니다!
Yobi =
코드 저장소
+ 이슈 트래커
+ 협업 코드 교환
+ 코드리뷰

SW개발팀을
위한 SW

37. Yobi
 이름 변천사
 nFORGE4
 Project N4
 HIVE
- CodeMix
- Make
- CodeSlash / Slash /SlashCode
- Resonance
- Runnable
- HIVE
- TwoX (2x)
- Waka
- treviso (이태리 베니스 근처 지역)
- VENCE (프랑스 남부지역)
- pladz ( space danish)

38. HIVE…

39. HIVE…
 문의메일을 받았는데..
"안녕하세요? 회사 내에서 마침 HIVE를 하는 팀이 있다고 들어서…"

40. Yobi 이름
 Yobi 요비
 280 : YiB, Yotta binary
 IEC에서 2005년 8월에 지정한
현존 가장 큰 디지털 데이터 정보저장 단위
 그리고.. 발음이 귀엽다..
*IEC: International Electrotechnical Commission

41. "결심의 기억의 노예에 불과하다.
맹렬하게 태어나지만 지속의 끈기는 형편없다."
- 오셀로 中

42. 개발 작업방식

43. 참! 기본적으로 저희 개발 진행 모습이나
산출물 등은 언제든 자유롭게 보실 수 있으세요
http://repo.yobi.io

44. 개발순서




목표 세우기
뭘 만들지 정하기
구체화 하기
개발하기
 테스트 만들기
 테스트 / 단계적 릴리즈

45. 목표세우기

46. 몇 가지 가정
 몇 가지 가정
 팀원이 몇 명 없고 불안(?)이 크니 목표가 확실해야 한다!
 그리고 개발에 대한 동기도 확실해야 한다!
 중간에 지칠 수도 있고 기억이나 결심도 약해질 수 있으니 적어 놓자
 대신 뭐든 짧고 간결하게!
 최대한 Plain Text를 이용한다.
• 워드/엑셀/특정 도구가 없어도 되게..

47. Vision 수립

48. Vision 수립시의 질문들
 무엇을 하는 SW인가?
 개발팀에게 있어서는 어떤 의미의 SW인가?
 우리의 현재 고객은 누구인가?
 우리의 미래 고객은 누구인가? 누가 사용했으면 좋
겠는가?
 목표로 한 미래의 고객을 만들기 위한 활동은?
 프로젝트 개발이 현재 어디쯤에 있는지 어떻게 하면
알 수 있을까?

49. 뭘 만들지 정하기

50. 기획 / 디자인
 기획자가 따로 없음
 다 같이 머리를 맞대서

51. 스펙 작성
 기능목록 (Function List)

52. 스펙 작성
 기능목록

53. 스펙 작성
 기능목록
 항목별로 "누가" "뭘 하기 위해" "어떤 기능이 필요하다" 식으로 서술
• "누가"와 "뭘 하기 위해"를 잘 적으면 확실히 도움이 많이 된다.
 분량을 산정하기 위해 포인트를 적는다
• 가장 쉬운 개발을 1점으로 가정해서
• 점수가 아주 정확할 필요는 없다.
• 전체적인 분량파악에만 도움이 되면 된다.
 추천정도
 어머!! 이건 꼭 사야해야 함!

54. 구체화 하기

55. 스펙 작성
 plain text (markdown)

56. 스펙 작성
 상세 스펙

57. 스펙 작성
 상세 스펙
 기능 목록의 항목 하나를 상세화 한 것
 완료 조건(Acceptance Criteria)과 화면설계 파일을 적어 놓음
 추천정도
 상세 스펙을 적기에 적절한 스타일
 기능목록과 겹치는 부분이 있는데 따로 관리하니까 조금 불편
 완료조건을 예제로 적는 건 Spec By Example의 사상을 도입함

58. 화면 설계
 Balsamiq Mockup

59. 화면 설계
 Balsamiq Mockup
 사용방법이 쉬움
 손으로 그리는 것 보다는 조금 시간이 더 걸리지만 디자이너랑 이야기
하기엔 괜찮음
 추천정도
 손으로 종이에 그려 놓은것 보다는 수정 시 디자인 훼손이 적고
오래 유지된다는 점에서는 +
 하지만 역시 디자이너와 꾸준히 대화하는 것이 더 중요함 (!!)

60. 개발 하기

61. 개발하기
 마일스톤 세우기

62. 개발하기
 마일스톤 세우기
 이벤트를 기준으로 정한다.
- NHN Next에 반영, 센터 내에서 사용, D2FEST에서 사용 등
 너무 시점이 길진 않게 조절(6주~8주 정도)
 기능목록에서 우선순위와 분량을 따져서 가져온다
 (조금 슬프지만) 이번 마일스톤이 개발의 마지막이 되더라도 SW의 상
태가 의미있도록 개발 기능 선정을 고려한다.

63. 개발하기
 아침 미팅
 아침마다 인생이야기 + 개발 이야기 공유 하기
 일감 정하기
 누군가가 할당 하지 않고 개인이 알아서 가져온다

64. 개발하기
 Pair Programming

65. 개발 시 몇 가지 기본 원칙
 최대한 직접 개발하지 않는다.
 개발하기 전에 유사 모듈이 있는지 검색해서 가져다 쓴다.
 딱 입맛에 맞는게 없네~ 라는 생각이 들어서 다시 만들고 싶으면 가장
비슷한 걸 골라서 수정한다.
 그렇게 개선한 내용은 다시 원래 프로젝트로 돌려준다.
(contribution 권장)
 외부 표준이 있으면 표준을 따른다
 예) versioning은 semver.org 를 따르고..

66. 개발 시 몇 가지 기본 원칙
 어떠한 기능을 개발하려 할 때 해당 기능을 우회적
으로라도 일부 대체 사용할 수 있다면 뒤로 우선순위
를 미룬다.
 사용자들의 요청이 좀 더 강력해 지거나 시간적 여유가 생겼을 때 개발
한다.
예) 이슈 워크플로우(work-flow) 기능을 개발하려고 했는데 현재 있는
라벨 기능을 이용하면 불편하지만 어느정도 해당 기능을 구현할 수 있
다. 그럼 지금은 이슈 워크플로우 기능기능 대신 다른 기능을 먼저 개발
한다.

67. 개발 시 몇 가지 기본 원칙
 어떤 기능을 구현할때 고민이 되면 팀원들에게 의견
을 묻고 팀원들은 적극적으로 자신의 의견을 제시한다.
 고민이 될 수록 최대한 많은 의견을 듣는다.
 하지만 최종 결정은 해당 기능을 개발하는 사람이 결정하고 다른 사람
들은 따른다.

68. 개발 시 몇 가지 기본 원칙
 코드 주고받기(Pull-Request) 기능 적극 사용
 원본 프로젝트를 복사(Fork)한다
ORIGIN
Project
FORKING
 기능 개발은 자신만의 Forked Project에서 진행하고 완료되면 origin
으로 코드 받아달라고(pull-request) 요청한다. 이때 필요하다면 알아
서 branch를 만든다.
ORIGIN
Project
FORKING
개발
branch

69. 개발 시 몇 가지 기본 원칙
 코드 주고받기(Pull-Request) 기능 적극 사용
 코드 리뷰를 한다.

70. 개발 시 몇 가지 기본 원칙
 코드 주고받기(Pull-Request) 기능 적극 사용
 코드 리뷰 내용을 반영해서 다시 코드를 받아 달라고 요청한다.
ORIGIN
Project
FORKING
다시 요청
개발
branch
코드 리뷰내용 적용

71. 개발 시 몇 가지 기본 원칙
 코드 주고받기(Pull-Request) 기능 적극 사용
 전체 적인 모양
ORIGIN
Project
코드리뷰
Forked A
개발자 A
Forked B
개발자 B
Forked C
개발자 C

72. 개발 시 몇 가지 기본 원칙
 코드 주고받기(Pull-Request) 기능 적극 사용
 단, 간단한 수정이나 hotfix는 코드리뷰를 따로 거치지 않는다.
ORIGIN
Project
Forked A
개발자 A
Forked B
개발자 B
Forked C
개발자 C

73. 개발 시 몇 가지 기본 원칙
 코드 주고받기(Pull-Request) 기능 적극 사용
 당연한 방식이라고 생각 할 수도 있지만
완소 추천!

74. 테스트 하기

75. 테스트 하기
 테스트 코드로 테스트
 JUnit
 테스트 서버 운영
 shell script를 이용한 코드 즉각 반영
 베타 테스트 사이트 운영
 NHN Next, D2FEST, 사내

76. Dog-fooding
 역시 개밥먹기 방식이 좋음!
 http://repo.yobi.io

77. 배운 점
Lessons & Learned

78. 후발 주자

79. 선행 서비스/ 제품들
 Trac, 2006; 7 years ago
 JIRA, 2002, 11 years ago
 GITHUB, 2008, 5 years ago
 한편 Yobi는?
 2012, 1 year ago

80. 선행 서비스/제품들이 있는 상태에서 Yobi를 만든다 것
 We are not first
 이미 편리하다고 생각하는 아이디어 들은 빠르게 적용 가능
• pull-request 같은 아이디어
 그리고 평소 불편하다고 생각되는 건 입맛에 맞게 개선하면 됨
 그런데 코드가 없으니 클린룸 개발의 경우가 많음
 또 한편, 두려운 점은..
 영혼없는 개발자 소리를 듣는 것
 치열하게 고민하다가 결론을 내리고 github을 보면 논의되어 나온대로
되어 있음

81. 어떤 벽, GITHUB

82. GITHUB
 Octocat이라는 Github 캐릭터
 귀엽나요?

83. GITHUB
 첫 화면에만 약 60개 이상의 "기능"이 있음

84. GITHUB
 시작한지 5년
 개발자 수
 106명
 끊임없이 개선되고 개발되어짐

85. GITHUB
 고민끝에 기능을 결정하고 github을 보면 똑같거나
더 똑똑한 경우가 많음
 여차하면
 영혼없는 개발자들…
 Github의 Deadcopy
 베끼기 네이버 개발자들..
소리를 듣기 십상

86. 엄살?
 으응? 그래서?
 선행 제품/서비스가 있다고 결코 쉽지 않다
 더 더 고민해야 하는구나…
 1등 서비스 만드는 사람들은 바보가 아니니까 가만히 있을 리 없다
• 따라가기 벅차다는 느낌도 때로..
 그래도 고민을 하고 노력하니까 Yobi만의 기능들도 들어가기 시작함!

87. 잠깐 이런 경우도!! 이거랑…

88. 잠깐 이런 경우도!! 이거랑…

89. We are fine…

90. 잘하고 있다고 생각되는 점 (1/2)
 주석을 달고 리팩터링 하는 시간을 따로 가졌음
 새로 온 멤버들이 더 빨리 적응하는 계기가 됨
 개밥먹기
 먹어보니 알겠더라.. 그 맛…
 단계적 릴리즈
 NHN NEXT  센터 내에 반영  D2Fest에서 사용  DEVIEW 발표
 일감 각자 알아서 챙겨가기
 "제가 할게요… 느낌 아니까.."

91. 잘하고 있다고 생각되는 점 (2/2)
 팀원이 모두 개발에 참여
 디자인 / 기획 / 기능개발 / 테스트
 때때로 짝 프로그래밍
 역시 한 사람 보다는 두 사람이 하면 더 좋구나
 서로 뭐 하는지 알기 / 문제에 대해 공유하기
 똑같은 삽질 반복하지 않기
 아이디어 나누기
 예) 탭을 기억하는 방식에 대해서
• local storage? server-side 처리? push-state 조작? cookie?

92. 실수한 점들
 코드 리뷰를 훨씬 더 일찍 시작했어야 했었음
 결국 변변한 릴리즈도 하기 전에 재개발 수준의 리팩토링을 해야 했음

93. 실수한 점들
 TWO-TOP 체계의 실수
 역시 TOP은 한 명이야…

94. 실수한 점들
 Test 코드를 더 많이 만들지 못한 점

95. 어려운 점들 1
 Playframework 2
 ORM (Ebean)
 공부 조금 하고 쉽게 되는 게 아니구나..
 소스코드를 보자!

96. 어려운 점들 2
 Scala
 컴파일 시간이 오래 걸림 (!!!)
 빌드 서버를 따로 구축해서 써야 할 정도
 Sbt 버전에 따른 다른 동작
 build tool for Scala
 설치형 단독 제품이면서 서비스 제품이다.
 예) 서버 비밀 키를 생성하도록 유도해야 하는 경우

97. 아쉬운 점 + 기타 불안?
 상주 디자이너를 가지지 못한 점
 UX 전문가가 없어서 시간이 많이 걸리고도 부족함
 팀이 언제 사라져도 어색하지 않다!
 기회이자 불안요소
• 동기부여에 대한 양날의 칼 같은 느낌
 잘해서 가치를 증명해 보자! VS 언제까지 할 수 있으려나~

98. 기타 도움이 많이 된 것들
 IntelliJ IDEA
 Open-Source License 를 받아서 사용
 참여하시면 드립니다!
 Test Code
 더 많이 짯어야 했는데..
 GITHUB
 잘 만들었음

99. 기타 도움이 많이 된 것들
 CI (Travis-CI)
 깨진 빌드나 테스트는 바로바로 알려줌

100. 그리고 중요하게 배운 점 하나…

101. # 개발팀원이면서 리더가 되는 것
 리더로써 해야 할 일은
 팀원들의 이야기를 들어줘야 하는 것
 독단적이지 않게 결정을 해야 하는 것
 그리고 책임을 지는 것
• 결정을 전가하던가
• 직접 내리던가 어느 경우든

102. # 개인적으로 중요시 한 점
 저에게 중요한 점은
 저희가 만드는 SW인 Yobi를 쓰는 고객만큼이나
저희 팀 개발자들의 삶이 중요하다고 생각합니다.
 영혼을 울리는 맛의 수제 햄버거 가게
 고객도 울었고, 직원도 울었다
 SW가 두 가지 측면
 삶을 개선하거나
 즐거움을 준다
 이 부분이 고객에게만 해당되지 않도록

103. 향후 계획 및 목표

104. 향후 계획
 우선 먼저…
 부족한 게 많습니다…
 갈 길이 아직 멀었습니다…
 그런데 여튼 저희 팀은 Yobi로 Yobi 개발 하고
있습니다.
 나름 쓸 만 합니다.

105. 향후 계획
 코드 리뷰 기능 강화
 이슈 워크 플로우 (workflow)
 엔터프라이즈 요구사항 반영
 조직 구성
 LDAP 연결 등
 기본 기능 안정성 증가

106. 목표
 목표는
 한국의 대표적인 오픈소스 제품
 GITHUB, GITLAB, TEAM-FORGE 등과 경쟁
 해외에서도 사용하고 외쿡인도 참여해서 함께 개발해 가는 것
• 현재 한국어 / 영어 / 일어(…) 지원
 하지만 무엇보다..
 개발자인 우리들에게 도움이 되고 사랑 받는 SW가 되는 것 :D

107. 요약 및 결론

108. 여러분
* 빈 화면 버그 아님!

109. 요약 및 결론
 SW 개발은 참 어렵다
 부족한 점 많지만 개발팀에 응원을 보내주시면
 더 열심히 노력해서 더 더 좋은 SW로 보답하겠습니다.
 많이 써주시고
 FEEDBACK 많이 주시고
 여유가 되시면 코드기여도 해주세요
 바로, 우리의 삶이 좀 더 나아질 수 있도록 하는 건
 저희 팀 혼자 만드는 SW가 아니라 함께 만들어 간 SW로 되었으면 좋겠고
 SW의 존재 목적인
 더 나은 세상, 즉 삶에 보탬이 되거나 좀 더 즐거울 수 있도록 도와주는
 그런 SW가 되었으면 좋겠고 그런 SW를 만들어 주셨으면 좋겠습니다.

110. Q&A + a 는
BOF 시간에
개발팀 멤버들과 함께
나눠요~
오후 1시 부터 시작하는 "Git은 어떻게 동작하는가" 시간에는
Yobi 내부 동작과 기능개발 고민에 대한 이야기를
좀 더 자세히 들으실 수 있습니다.

111. THANK YOU
http://yobi.io

112. 참고
 사용 이미지 출처

8p, fallout 3 official wallpaper

21p, http://suhailalgosaibi.com/2010/08/13/nine-radical-time-management-secrets/

46p, http://www.headhunt.com.sg/blog/how-to-stick-to-your-career-objectives-timeline/

50p, http://www.futureatwork.com/future-at-work/sample-next.html

55p, http://www.imgbase.info/images/safewallpapers/digital_art/1_miscellaneous_digital_art/14052_1_miscellaneous_digital_art_sketch.jpg

61p, http://www.imgbase.info/images/safe-
wallpapers/digital_art/1_miscellaneous_digital_art/19070_1_miscellaneous_digital_art_black -white.jpg

82p, http://heyitsalex.net/love-letter-to-github/

83p, Github official site