신림 프로그래머 모임에서 발표한 자료

1. 개발 프로세스 개선기
정재한

2. • 기존 개발 프로세스 설명
• 기존 프로세스에 대한 단점과 고민
• 프로세스 개선 과정 설명
• 과정에서 발생한 저항에 대한 이야기
• 결론
진행 순서

3. 일반적인 개발 진행 방법
요구사항 전달 요구사항 분석
일정 산정
설계
개발패키징/배포
테스트/검증
운영

4. 소스 공유
개발
스테이징
상용
패키징/배포
기존 개발 프로세스
요구사항 전달
타부서
개발자2
개발자1
설계
1
6
7
개발
일정 산정
테스트8
QA
사업부서
4
5
3
모니터링/운영
요구사항 분석2
9

5. 개발
스테이징
상용
요구사항 전달
개발자2
개발자1
1
QA
요구사항 분석2
단점
• 이메일, 메신저, 전화, 회의 등 요구사항을 전달하는 채널이 너무 많음
• 요구사항은 자기가 해야 될 일에 대해서만 기억 함
• 급한 요구사항이 들어오면 업무 우선순위에 혼란이 발생
개발5
설계
일정 산정
4
3
소스 공유
패키징/배포
6
7
테스트8
모니터링/운영9
타부서
사업부서

6. 개발
스테이징
상용
개발자2
개발자1
1
QA
요구사항 분석2
단점
• 딱딱한 커뮤니케이션으로 경직된 협업 문화 형성
• 구두로 주고 받은 논의 내용, 사소한 의사결정 사항은 이력관리가 되지 않음
요구사항 전달
개발5
설계
일정 산정
4
3
소스 공유
패키징/배포
6
7
테스트8
모니터링/운영9
타부서
사업부서

7. 개발
스테이징
상용
개발자2
개발자1
1
QA
단점
• 요구사항에 대한 러프한 일정만 전달 가능
• 산출물은 각자의 방법대로 저장 됨(파일 서버, 메일, 개인 PC 등)
• 산출물이 현행화 되지 않고 검색하기도 쉽지 않음
요구사항 전달
개발5
설계
일정 산정
4
3
소스 공유
패키징/배포
6
7
테스트8
모니터링/운영9
요구사항 분석2
타부서
사업부서

8. 개발
스테이징
상용
개발자2
개발자1
1
QA
단점
• 중앙 집중식 공유 방식이기 때문에 소스 검증이 쉽지 않음
• 작업자수가 많을 수록 소스 충돌 발생이 잦음
요구사항 전달
개발5
설계
일정 산정
4
3
소스 공유
패키징/배포
6
7
테스트8
모니터링/운영9
요구사항 분석2
타부서
사업부서

9. 개발
스테이징
상용
개발자2
개발자1
1
QA
단점
• 환경에 따른 설정파일 변경 필요
• 개발자마다 패키징 및 배포 방법이 조금씩 다름
• 개발자가 직접 Command를 실행하기 때문에 실수로 인한 배포 장애 발생
요구사항 전달
개발5
설계
일정 산정
4
3
소스 공유
패키징/배포
6
7
테스트8
모니터링/운영9
요구사항 분석2
타부서
사업부서

10. 개발
스테이징
상용
개발자2
개발자1
1
QA
개발 외적인 일
요구사항 전달
개발5
설계
일정 산정
4
3
소스 공유
패키징/배포
6
7
테스트8
모니터링/운영9
요구사항 분석2
타부서
사업부서

11. 개발 외적인 일들로
정작 개발할 시간이 부족..
= 서비스 품질 저하

12. 개발 프로세스에 대한 고민

13. 요구사항을 하나의 채널로 받을 수 있다면..
개발프로세스가 정형화 될 수 있다면..
좀더 쉽고 빠르게 협업 할 수 있다면..
여러 사람이 작성한 산출물을 통합해서 관리할 수 있다면 ..
일정 산정에 상호간에 납득 가능한 방법이 있다면..
배포 시 수작업에서 발생하는 오류를 줄일 수 있다면..
개발하는데 좀더 집중할 수 있는 환경이라면...
…
개발 프로세스에 대한 고민

14. 개발
스테이징
상용
개발자2
개발자1
1
QA
개선 방안
요구사항 전달
개발5
설계
일정 수립
4
3
소스 공유6
7
테스트8
모니터링/운영9
요구사항 분석2
패키징/배포
• 이슈 등록 기능으로 하나의 채널로 요구사항 전달 가능
• 댓글 기능으로 쉽고 빠르게 협업 가능
• 워크플로우 방식이기 때문에 개발 프로세스가 정형화 됨
• 이슈 별 예측시간 입력을 통한 일정 산정 가능
타부서
사업부서
선정한 이유

15. 개발
스테이징
상용
개발자2
개발자1
1
QA
개선 방안
개발5
설계4
3
소스 공유6
7
테스트8
모니터링/운영9
요구사항 분석2
패키징/배포
• 거의 모든 분석/설계 문서를 작성 가능
• 검색엔진이 포함되어 있어 산출물을 빠르고 쉽게 검색 가능
• 쉽고 빠른 협업 수단이 많음 (멘션, 페이지 공유, 지켜보기, 좋아요)
• JIRA와 같은 회사 제품이라 연동 기능이 많음 (SSO, 이슈연결/생성 등)
요구사항 전달
일정 수립
타부서
사업부서
선정한 이유

16. 개발
스테이징
상용
개발자2
개발자1
1
QA
개선 방안
개발5
4
3
소스 공유6
7
테스트8
모니터링/운영9
2
패키징/배포
• 통합 관리자 방식의 워크플로우 도입으로 소스 검증이 가능
• 중앙 저장소와 격리된 상태로 개발하기 때문에 소스 병합에 대한
부담감 없음
요구사항 전달
일정 수립
설계
요구사항 분석
타부서
사업부서
선정한 이유

17. 통합 관리자 워크플로우
SVN – 중앙 집중식 워크플로우
Git – 통합 관리자 방식 워크플로우

18. 개발
스테이징
상용
개발자2
개발자1
1
QA
개선 방안
개발5
4
3
6
7
테스트8
모니터링/운영9
2
패키징/배포
• Maven 플러그인을 통한 환경 별 설정 파일 변경 작업 자동화
• 사소한 수정이 있을 때 마다 클릭 한번으로 배포 가능
• 패키징 및 배포 절차가 정형화 됨
• ssh publish 플러그인을 통한 단순 반복적인 서버작업 자동화
요구사항 전달
일정 수립
설계
요구사항 분석
소스 공유
타부서
사업부서

19. 개발
스테이징
상용
분석/설계/협업
개발자
통합 관리자
개발/테스트
• 패키징 / 배포
• 테스트 코드 수행
• 소스 백업
• 웹 서버 재시작
타부서
사업부서
개선 방안

20. 시스템을 구축하기 전에 …
계정에 대한 고민..

21. etc
• 시스템마다 계정이 다를 경우 혼란을 초래 함
• 처음 써보는 사용자는 계정 생성 부터 거부감이 발생
• 이미 쓰고 있는 계정이면 BEST
• 입사시 등록된 Active Directory 계정이 정답!
계정 통합 시스템 컨셉

22. 쉬운 접근을 위해 구축한 계정 통합 시스템
etc
계정 통합 시스템
• 계정관리
• 권한관리

23. JIRA + Agile Plugin 도입

24. 개발프로세스 기본 워크플로우

25. 배포 요청 워크플로우

26. 단말 대여 워크플로우

29. Confluence 도입

30. 기획서를 통합 협업
파워포인트 뷰어 메크로 활용

31. Jenkins + Maven + Git 배포 도입

32. 주요구성 - Jenskins 설정
Git 연동
빌드 스케쥴링 메이븐 연동
ssh 를 통한 서버 배포

33. 개발 생산성에 도움이 되었나?
6개월 동안
개발서버 배포만
2,829회

34. 개발 생산성에 도움이 되었나?
1) 개발자 수작업으로 배포할 경우
• 배포 시간 10분으로 가정
• 일 평균 8시간 일한다고 가정
10분 * 2,829회 = 471시간 58일
2) Jenkins로 배포할 경우
• 배포 시간 평균 40초
40초 * 2,829회 = 31시간 4일
93%

35. 저항에 대한 이야기

36. 꼭 나오는 말
• 이거 왜 사용 해야 하나요? 꼭 써야 해요?
• 너무 어렵고 복잡해요~
• 난 기존에 하던 방식이 있어요~
• 메일이 너무 많이 와요~ㅠㅠ

37. 저항을 줄이기 위한 노력
• 지속적인 매뉴얼 공유 (온라인/오프라인)
• 입사 OJT시 전파 교육
• 전사 교육
• 쉬운 사용을 위한 한글 패치
• 각 부서별로 JIRA/Confluence 세팅
• 요구사항이 있거나 문의가 있으면 최대한 협조적으로~

38. 프로세스 개선 1년 후…
• 쓰다 보니 편하긴 한 것 같아요.. 유용한 기능들을 공유해주세요~
• 이런 것도 되요? 이렇게 쓰고 싶은데 어떻게 해야 하나요?
• JIRA 요청이 없으면 업무 시작 안하는 사람이 생기기 시작..
• 장애보고서, 작업계획서, VOC내역, 주간/월간 보고서등 Confluence로 작성
• Jenkins, Git 프로젝트가 최초 구축 시 3개였지만 현재는 50개 이상
• 시스템이 조금만 이상해도 바로 문의가 들어옴
이제는 없으면 안됨

39. • 기술도 중요하지만 인간 관계가 좀더 중요
• 프로세스를 개선하기 위한 필수 항목은 의지와 책임감
• 구축 했으니 이제 잘 사용하겠지 라고 생각하면 안됨
• 변화에 부정하는 것은 당연하다고 생각해야 함
• 기업 문화에 따라 1~2년 정착 기간이 필요함
결론

40. 여전히 진행 중..

41. Q & A