�ݺ�ߣ

협업 SW개발 플랫폼, Yobi

채수원 / 개발자 서비스 개발랩
NAVER LABS

CONTENTS
1. Yobi ?

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

본 세션에서 얻을 갈 수 있는 것
- Yobi가 뭐고 왜 만들어 졌나?

- 어떤 개발팀의 SW 개발 방식
- 프로젝트를 진행하면서 배운점과 교훈들
- 동시대 같은 업종(?)에서 살아가는 사람들의 고뇌

발표자 소개

 채수원
 NAVER LABS
 개발자 서비스 개발랩 Technical Leader(TL)

 OctoberSkyJs (NodeJs커뮤니티) 리더
 ‘TDD 실천법과 도구’, ‘Agile Software 101 (공저)’

저자
 SNS
 twitter.com/doortts
 blog.doortts.com

유의 사항
- 최대한 솔직하게 이야기 할거니까

어디가서 이야기 하시면 안되어요…
- 여러분 믿고 이야기 시작합니다..
- 그리고 롤러코스터 처럼 진행될 예정이니까
여러분도 저도 모두 정신 바짝!!

"참혹한 운명의 화살을 맞고 마음속으로 참아야 하느냐.
아니면 성난 파도처럼 밀려오는 고난과 맞서 용감히 싸워

그것을 물리쳐야 하느냐. 어느 쪽이 더 고귀한 일일까."

- Hamlet

일반적으로 프로젝트가 시작되면…

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

2000년대 중반~후반

프로젝트 B
프로젝트 A
프로젝트 C
…D

느낀 점과 노력

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

느낀 점과 노력

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

아!!! 그래!!

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

예를들면..

JIRA (atlassian)

프로젝트 관리도구

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

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

이슈 트래커 사용

TRAC과 Subversion을 이용한 개발환경 구축가이드

지속적인 통합 (Continuous Integration)

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

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

:D

손수건 손에 들고 들어야 하는

이런저런 사연 뒤에… 2013년…

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

Yobi ?

 설치형 프로젝트 호스팅 SW
 private / public 프로젝트 선택 생성가능

 오픈소스 (무료로 사용가능)
 Apache License 2.0

 쉬운 설치
 All-in-one
 Java 7 이상, 인터넷 연결된 환경
 의존성 추가 도구들 설치 필요 없음

 Windows / Linux / Mac 지원

Yobi 구성








Playframework 2 + JAVA
EBean (ORM)
JGit
Twitter Bootstrap + Custom CSS
LESS
H2 Embedded DB

Yobi 사용 중인 곳

 NHN Next
 D2FEST
 d2fest.kr

 NAVER LABS

Yobi 주요 기능

 프로젝트 홈

Yobi 주요 기능

 게시판

Yobi 주요 기능

 코드 브라우저

Yobi 주요 기능

 프로젝트 복사/코드 주고받기 (1/2)

Yobi 주요 기능

 프로젝트 복사/코드 주고받기 (2/2)

Yobi 주요 기능

 코드리뷰 (1/2)

Yobi 주요 기능

 코드리뷰 (2/2)

Yobi 주요 기능

 이슈트래커 (1/2)

Yobi 주요 기능

 이슈트래커 (2/2)

네. 그렇습니다!
Yobi =
코드 저장소
+ 이슈 트래커
+ 협업 코드 교환
+ 코드리뷰



SW개발팀을
위한 SW

Yobi

 이름 변천사

 nFORGE4
 Project N4
 HIVE

- CodeMix
- Make
- CodeSlash / Slash /SlashCode
- Resonance
- Runnable
- HIVE
- TwoX (2x)
- Waka
- treviso (이태리 베니스 근처 지역)
- VENCE (프랑스 남부지역)
- pladz ( space danish)

��շ�…

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

Yobi 이름

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

*IEC: International Electrotechnical Commission

"결심의 기억의 노예에 불과하다.

맹렬하게 태어나지만 지속의 끈기는 형편없다."

- 오셀로 中

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

개발순서






목표 세우기
뭘 만들지 정하기
구체화 하기
개발하기
 테스트 만들기

 테스트 / 단계적 릴리즈

몇 가지 가정

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

Vision 수립시의 질문들

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

기획 / 디자인

 기획자가 따로 없음
 다 같이 머리를 맞대서

스펙 작성

 기능목록 (Function List)

스펙 작성

 기능목록

스펙 작성

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

 추천정도
 어머!! 이건 꼭 사야해야 함!

스펙 작성

 plain text (markdown)

스펙 작성

 상세 스펙

스펙 작성

 상세 스펙
 기능 목록의 항목 하나를 상세화 한 것
 완료 조건(Acceptance Criteria)과 화면설계 파일을 적어 놓음

 추천정도
 상세 스펙을 적기에 적절한 스타일

 기능목록과 겹치는 부분이 있는데 따로 관리하니까 조금 불편
 완료조건을 예제로 적는 건 Spec By Example의 사상을 도입함

화면 설계

 Balsamiq Mockup

화면 설계

 Balsamiq Mockup
 사용방법이 쉬움
 손으로 그리는 것 보다는 조금 시간이 더 걸리지만 디자이너랑 이야기
하기엔 괜찮음

 추천정도
 손으로 종이에 그려 놓은것 보다는 수정 시 디자인 훼손이 적고
오래 유지된다는 점에서는 +
 하지만 역시 디자이너와 꾸준히 대화하는 것이 더 중요함 (!!)

개발하기

 마일스톤 세우기

개발하기

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

개발하기

 아침 미팅
 아침마다 인생이야기 + 개발 이야기 공유 하기

 일감 정하기
 누군가가 할당 하지 않고 개인이 알아서 가져온다

개발하기

 Pair Programming

개발 시 몇 가지 기본 원칙

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

 외부 표준이 있으면 표준을 따른다
 예) versioning은 semver.org 를 따르고..


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


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


 코드 주고받기(Pull-Request) 기능 적극 사용
 원본 프로젝트를 복사(Fork)한다
ORIGIN
Project

FORKING

 기능 개발은 자신만의 Forked Project에서 진행하고 완료되면 origin
으로 코드 받아달라고(pull-request) 요청한다. 이때 필요하다면 알아
서 branch를 만든다.
ORIGIN
Project

FORKING
개발
branch


 코드 리뷰를 한다.


 코드 리뷰 내용을 반영해서 다시 코드를 받아 달라고 요청한다.
ORIGIN
Project

FORKING
다시 요청

개발
branch

코드 리뷰내용 적용


 전체 적인 모양
ORIGIN
Project
코드리뷰

Forked A
개발자 A

Forked B
개발자 B

Forked C
개발자 C


 단, 간단한 수정이나 hotfix는 코드리뷰를 따로 거치지 않는다.
ORIGIN
Project

Forked A
개발자 A

Forked B
개발자 B

Forked C
개발자 C


 당연한 방식이라고 생각 할 수도 있지만

완소 추천!

테스트 하기

 테스트 코드로 테스트
 JUnit

 테스트 서버 운영
 shell script를 이용한 코드 즉각 반영

 베타 테스트 사이트 운영
 NHN Next, D2FEST, 사내

Dog-fooding

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

선행 서비스/ 제품들

 Trac, 2006; 7 years ago
 JIRA, 2002, 11 years ago
 GITHUB, 2008, 5 years ago
 한편 Yobi는?
 2012, 1 year ago

선행 서비스/제품들이 있는 상태에서 Yobi를 만든다 것

 We are not first
 이미 편리하다고 생각하는 아이디어 들은 빠르게 적용 가능
• pull-request 같은 아이디어
 그리고 평소 불편하다고 생각되는 건 입맛에 맞게 개선하면 됨
 그런데 코드가 없으니 클린룸 개발의 경우가 많음

 또 한편, 두려운 점은..
 영혼없는 개발자 소리를 듣는 것
 치열하게 고민하다가 결론을 내리고 github을 보면 논의되어 나온대로
되어 있음

GITHUB

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

GITHUB

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

GITHUB

 시작한지 5년
 개발자 수
 106명

 끊임없이 개선되고 개발되어짐

GITHUB

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

소리를 듣기 십상

엄살?

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

잠깐 이런 경우도!! 이거랑�Ħ

잘하고 있다고 생각되는 점 (1/2)

 주석을 달고 리팩터링 하는 시간을 따로 가졌음
 새로 온 멤버들이 더 빨리 적응하는 계기가 됨

 개밥먹기
 먹어보니 알겠더라.. 그 맛…

 단계적 릴리즈
 NHN NEXT  센터 내에 반영  D2Fest에서 사용  DEVIEW 발표

 일감 각자 알아서 챙겨가기
 "제가 할게요… 느낌 아니까.."

잘하고 있다고 생각되는 점 (2/2)

 팀원이 모두 개발에 참여
 디자인 / 기획 / 기능개발 / 테스트

 때때로 짝 프로그래밍
 역시 한 사람 보다는 두 사람이 하면 더 좋구나

 서로 뭐 하는지 알기 / 문제에 대해 공유하기
 똑같은 삽질 반복하지 않기

 아이디어 나누기
 예) 탭을 기억하는 방식에 대해서
• local storage? server-side 처리? push-state 조작? cookie?

실수한 점들

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

실수한 점들

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

실수한 점들

 Test 코드를 더 많이 만들지 못한 점

어려운 점들 1

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

어려운 점들 2

 Scala
 컴파일 시간이 오래 걸림 (!!!)
 빌드 서버를 따로 구축해서 써야 할 정도

 Sbt 버전에 따른 다른 동작
 build tool for Scala

 설치형 단독 제품이면서 서비스 제품이다.
 예) 서버 비밀 키를 생성하도록 유도해야 하는 경우

아쉬운 점 + 기타 불안?

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

기타 도움이 많이 된 것들

 IntelliJ IDEA
 Open-Source License 를 받아서 사용
 참여하시면 드립니다!

 Test Code
 더 많이 짯어야 했는데..

 GITHUB
 잘 만들었음

기타 도움이 많이 된 것들

 CI (Travis-CI)
 깨진 빌드나 테스트는 바로바로 알려줌

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

# 개발팀원이면서 리더가 되는 것

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

# 개인적으로 중요시 한 점

 저에게 중요한 점은
 저희가 만드는 SW인 Yobi를 쓰는 고객만큼이나
저희 팀 개발자들의 삶이 중요하다고 생각합니다.

 영혼을 울리는 맛의 수제 햄버거 가게
 고객도 울었고, 직원도 울었다

 SW가 두 가지 측면
 삶을 개선하거나

 즐거움을 준다

 이 부분이 고객에게만 해당되지 않도록

향후 계획

 우선 먼저…
 부족한 게 많습니다…
 갈 길이 아직 멀었습니다…

 그런데 여튼 저희 팀은 Yobi로 Yobi 개발 하고
있습니다.
 나름 쓸 만 합니다.

향후 계획

 코드 리뷰 기능 강화
 이슈 워크 플로우 (workflow)
 엔터프라이즈 요구사항 반영
 조직 구성
 LDAP 연결 등

 기본 기능 안정성 증가

목표

 목표는
 한국의 대표적인 오픈소스 제품
 GITHUB, GITLAB, TEAM-FORGE 등과 경쟁
 해외에서도 사용하고 외쿡인도 참여해서 함께 개발해 가는 것
• 현재 한국어 / 영어 / 일어(…) 지원

 하지만 무엇보다..
 개발자인 우리들에게 도움이 되고 사랑 받는 SW가 되는 것 :D

여러분

* 빈 화면 버그 아님!

요약 및 결론

 SW 개발은 참 어렵다
 부족한 점 많지만 개발팀에 응원을 보내주시면
 더 열심히 노력해서 더 더 좋은 SW로 보답하겠습니다.
 많이 써주시고
 FEEDBACK 많이 주시고
 여유가 되시면 코드기여도 해주세요

 바로, 우리의 삶이 좀 더 나아질 수 있도록 하는 건
 저희 팀 혼자 만드는 SW가 아니라 함께 만들어 간 SW로 되었으면 좋겠고

 SW의 존재 목적인
 더 나은 세상, 즉 삶에 보탬이 되거나 좀 더 즐거울 수 있도록 도와주는
 그런 SW가 되었으면 좋겠고 그런 SW를 만들어 주셨으면 좋겠습니다.

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

참고

 사용 이미지 출처


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

�ݺ�ߣ

131 deview 2013 yobi-채수원

Recommended

More Related Content

What's hot (20)

Viewers also liked (6)

Similar to 131 deview 2013 yobi-채수원 (20)

More from NAVER D2 (20)

131 deview 2013 yobi-채수원