기반을 닦자 ("글로벌 소프트웨어를 꿈꾸다"를 읽고)
Business | 2011/04/05 12:10
예전에 경훈이형 미투를 비롯하여 많은 N사 사람들 미투에서 이 책에 대한 추천 포스팅들을 봤었고, B형에게도 추천해주었던 책인데, 막상 난 보지 않았던 터라.. 프로젝트에 본격적으로 들어가기 전에는 꼭 읽어봐야 될 것 같아서 날씨가 화창한 일요일에 집에서 기쁜 마음으로 이 책을 읽었다.
회사는 규모에 따라 조직과 문화가 다를 수 밖에 없는 3단계가 있다. 소프트웨어 회사에도 두 번의 재건축이 필요한 시기가 온다. 소수의 벤처회사에서 수십 명 정도의 중소기업으로 자라날 때가 첫 번째고 중견기업, 대기업으로 성장할 때가 두 번째다.지금 우리는 1단계에서 2단계로 가려는 상황이다. 이전 단계에서 다음 단계로 도약하는 과정에서 '기반시스템, 조직, 프로세스, 기술, 문화 등을 전반적으로 바꿔야 한다' 고 언급하고 있는데 불행인지 다행인지(난 다행이라고 생각하고 있다 ㅎㅎ) 기존에 존재하던 것들이 없어서 이를 바꾸는 데에서 오는 반발심이나 거부감이 없다. '영웅개발자'도 없어서 진행하는데 있어 불협화음도 없고...
재밌는게 N사에서 있을 때는 그렇게 거부감이 들었던 시스템이나 프로세스 등이, 지금은 그 니즈가 절실하다. QP도 그렇고 개발 프로세스도 그렇고 인프라 쪽도 그렇고.. 직원이란 입장에서 봤을 때는 거추장스럽고 귀찮았던 것들이 세팅하는 입장에서 보니 너무나도 필요한 것들이다. 이래서 항상 '입장 바꿔서 생각해 보라' 라고 하는 것 같다 ㅎㅎ
다행인건, 곧 합류하실 개발자 분들은 이에 대해서 긍정적인 마인드를 가지고 있다. 저번에 메신저 상으로 살짝 언급했었을 때나 HS형이 얘기한 것들로 미루어볼 때나~ 다만 그 정도의 차이는 모두 합류하시게 되면 적절히 조절해야 할 필요성이 있다.
소프트웨어 회사가 성공하기 위한 다섯 가지 조건
- 기반시스템
- 조직
- 프로세스
- 기술
- 문화
여기서 핵심은 이 다섯가지 요소 중에서 어느 하나라도 모자라면 효과가 떨어진다는 것이다.
1. 기반시스템
기반시스템에는 여러가지가 있지만 크게 2가지를 강조하고 또 강조하고 있는데, 바로 소스관리시스템과 이슈관리시스템이다.
1) 이슈관리시스템 : TRAC
들어와서 보니 이슈관리시스템을 사용하고 있지 않았다. 음.. 그럴 수 밖에 없는 상황이었다. HS형 말을 들어보니 Mantis를 잠깐 사용했었다고 하였다. 전 직장에서는 모든 커뮤니케이션의 중심이 BTS라 불리는 JIRA를 기반으로 한 이슈관리시스템을 통해 이루어지고 있고, 1년차 때는 잘 몰랐다가 2년차 때 두 번의 프로젝트를 하면서 그것의 중요성을 확실히 알게된터라 우선 이슈관리시스템부터 세팅해야겠다고 생각을 하였고, TRAC을 사용하기로 결정하였다.
TRAC을 사용하다보니 불편하거나 아쉬운 점들이 몇 가지 눈에 띄는데, 구글링해보니 이를 보완해주는 플러그인들이 있더라. (가장 대표적인건 시간추정 입력 플러그인 ㅎㅎ) 플러그인도 설치하고 세팅도 커스터마이징 좀 하고 TRAC을 좀 더 사용하기 쉽게 만든 뒤에, 적극적으로 활용해야겠다. 그리고 좀 더 사람들에게 notify해야 할 것은 이슈에 대한 모든 히스토리를 TRAC에 담도록 해야하는 것. 메일 커뮤니케이션이나 메신저 커뮤니케이션, 일의 진행상황 등, 그 이슈의 시작부터 끝까지 모든 것을 TRAC에 담도록 말이다.
전 직장에서는 JIRA를 사용했었는데, JIRA가 사용하기도 쉽고 매력적이지만, 당장 JIRA를 도입하는 건 몸에 맞지 않는 거추장스러운 옷을 입는 것과 같다고 생각한다. 2단계에서 3단계로 가게 된다면 그 때 도입을 고려해봐도 충분할 듯 하다.
2) 소스관리시스템 : SVN
이것 역시 마찬가지였다. SVN이 설치되어는 있었으나 (그것도 처음부터는 아니라고 하였다) 제대로 사용되고 있지 않았다. 들어오고 나서 일주일도 채 안 되어 2.22 사태라고 불리는 사건이 터졌는데, 이건 일어날 수 밖에 없는 사건이었다. 그 뒤 모든 소스를 수정하면 반드시 SVN에 커밋하도록 하였다. 이번 리뉴얼 프로젝트에 대해서는 YH님의 도움을 받아 세팅을 완료한 상태이다. 추가적으로 필요한 건, 커밋시 로그 메시지 규칙을 정하는 것. 소스관리시스템과 이슈관리시스템은 연결되어 있어야 하고 이를 연결해주는 것이 커밋 로그인데..(전 직장에서는 그렇게 했다.) 지금 글을 쓰다 보니 뭔가 이를 더 편리하게 해주는 플러그인이 있을 것 같은데 찾아보야겠다. SVN + TRAC 연동 플러그인과 같은? Tagging도 언제, 무슨 목적으로 할 지? 생각해봐야겠군.
3) 코드 리뷰
코드 리뷰를 어떤 식으로 할 지도 고민중이다. 음.. 코드 리뷰의 당위성에 대해선 굳이 언급하지 않겠다.
커밋할 때마다 Peer Code Review를 할 지, 아니면 daily로 team code review를 할 지, 아니면 필요할 때마다 요청에 의해서 code review를 할 지.. 전 직장에서 이 3가지 모두를 경험해 봤었는데,
1) 커밋할 때마다 peer code review를 하는 것은 code의 quality적인 면에서는 good이지만 코드리뷰를 해야 하는 상대방이 불규칙적으로 interrupt가 걸리게 되어 생산성을 낮추게 된다.
2) 필요할 때마다 요청에 의해서 하는 것은 처음에는 할 지 몰라도 프로젝트 중반에 들어가게 되면 아무도 안 하더라...
3) 그나마 가장 나은게 daily로 team 전체가 모여서 code review를 하는 것인데, 아직 개개인의 실력차가 다르고 background도 판이한만큼, 바쁘더라도(사실 바쁘다는 건 핑계다) 강제적으로 꾸준히 daily로 1시간 정도 code review를 진행해서 서로의 눈을 맞출 필요가 있다.
2. 조직
'깨진 유리창의 법칙'. 이건 꾸준히 모니터링해야 할 부분이다. 어느 한 명이 QP를 제대로 하지 않고 그것이 지속된다면 '깨진 유리창의 법칙'처럼 다른 사람들도 그렇게 할 가능성이 높아진다. 매일매일 꾸준히 관찰하자. (이건 랩장이나 센터장님이 하던건데... 왜 그리 했는지 알겠네 ㅎㅎ)
CTO의 역할에 대해서도 나와 있었다. 결론만 얘기하면 공부 열심히 해야한다 ㅎㅎ 경험도 많아야 하고~
3. 프로세스
개발 프로세스는 전 직장에서 사용하던 프로세스를 나름 optimizing해서 사용하려고 하는데(그렇게 세팅을 하고 있는데) 이건 실제로 돌려봐야 알 듯.
4. 기술 : 가장 중요하게 언급된건 SRS인데.. 이건 좀 더 알아보고 따로 포스팅해봐야지.
5. 문화
문화에 대해서도 역시 따로 포스팅을 해볼려고 한다. 개발자 리쿠르팅 설명회 PT를 작성하면서 든 생각들이 있어서..
뭔가 뒷 부분으로 가니 살짝 날림글이 되었구나...
(0) 
(0)
태그 : 글로벌 소프트웨어를 꿈꾸다
Recent comment
2011- BAKI
2011- 경훈이형
2011- pickup
2011- pickup
2011- arwenii