2013-07: 고급 SW엔지니어로 가는 길 ①Scrum

들어가는 글: 최근 부서이동으로 새로운 사람들, 새로운 role 그리고 새로운 기술set을 익혀야 하는 상황이 되었다. 이왕하는 것.. 이번에는 내 단계를 업시키는 기회로 삼아보리라 결심했다. 다소 야심적인 주제인.. 고급 SW엔지니어로 가는 길을 기획하게 되었다.

0. 고급 SW 엔지니어란 무엇일까?

가장 고전적인 방법은 SW진흥원에서 발행하는 SW인력 노임단가에 명시되어 있는 기준을 사용하는 것이다.

 - 고급기술자 : 기사 자격 취득 후 6년 이상의 SW 기술 분야의 업무를 수행한 자

회사에서 말하면 대충 과장(선임연구원)정도 되는 것일 것이다.

하지만 바꾸어서 말하면 과장이면 고급 엔지니어인가?에 대해서는 누구도 시원하게 대답을 못할 것이다. 차장이면 특급 엔지니어인가? 는 더더욱..

SW엔지니어의 등급을 RPG 게임의 마법사라고 가정해보자.

 - 초급 마법사 : 약한 마법(에니지소모 low , 데미지 low) 구사
 - 중급 마법사 : 강력한 마법(에너지 소모 mid , 데미지 high) 구사 ex) 물계열 , 불계열
 - 고급 마법사 : 단체 마법(에너지 소모 high , 데미지 mid ~ high) 구사

내가 정의하는 고급 SW 엔지니어는

 - 고급 SW 엔지니어 : 자신이 담당하는 개별 SW 뿐만 아니라 좀더 넓은 범위에 파급력을 줄 수 있는 SW 엔지니어, (기술적인) 의사소통 전문가, 코치 , 분석가 , 아키텍트 등.

(기술적인) 의사소통 전문가가 들어간 것은 특히 대기업에서 적용되는 기준일 것이다. 만약 본인이 기술적인 topic을 가지고 수많은 이해관계자 부서와 Project Leader 혹은 Sub-Leader로서 활동하고 있다면 이미 고급 SW엔지니어라고 할 수 있다.

어떻게 단체 마법을 걸 수 있을까? 동시에 파급효과는 low 아니고 mid ~ high로..말이다.
그것이 어렵다.


1. 고급 SW 엔지니어 vs 스크럼 


스크럼은 Agile 방법론에서 사용하는 개발 방식으로 당연히 모든 개발에 해당하는 것은 아니다. 스크럼이 효과적인 프로젝트는 상대적으로 BSP, Device drivers 보다는 UI , 기획들과 자주 상대하게 되는 Application이 더 적절하다.

스크럼은 단순하다. 스크럼의 구성요소는 아래와 같다.

 - Product Owner(PO) : SW제품의 총 책임자 (not 파트장, 팀장, 조직책임자)
 - Scrum Master(SM)  : 스크럼 진행자. 외부 공격으로 부터 개발팀을 지켜야 한다.
 - Scrum 팀원 : 개발자들
 - Product Backlog : 개발할 항목들
 - Sprint : 스크럼은 2주 ~ 3주 단위의 시간을 스프린트(전력질주)라고 부른다.
 - Velocity : 팀의 집중도 (자세한 얘기는 아래서..)
 - Burndown chart : 우리가 잘 일하고 있는지 보여주는 차트

더이상 뺄수 없을 만큼 diet을 했을 때 스크럼에서는 위의 7가지가 남는다.


2, 스크럼은 무엇인가? 


실컷 구성요소를 얘기해놓고 이제와서 스크럼이 무엇이냐 느냐? 라고 얘기할 수도 있겠지만 사실 스크럼이 무엇인지 정의를 내려놓고 하면 오히려 더 햇갈릴 거 같다. 왜냐?

정의(definition)라는 것은 함축되어 있기 때문에 오히려 더 어려울 수 있기 때문이다.

수많은 SW엔지니어들은 자기 업무에 뚱뚱한 개발 방법론이 적용되는 것을 본능적으로 거부한다. 왜냐? 그런 것들은 한번 조직에 도입되면 빼기가 정말 힘들기 때문이다. 조직이론에 대한 것으로 어떤 것으로 도입하는 것은 도입자의 실적이 되지만 그것을 도려낸다는 것은 그 사람에 대한 공격으로 생각될 수도 있기 때문이다. (사실 도입자는 그렇지 않을 수도 있다. 어느 정도 시간이 지나면 오히려 그것이 조용히 사라지기를 원할 수도 있다)

스크럼으로 다시 돌아가자.

 - 스크럼 : 2~3주간 외부의 인터럽트를 받지 않고 열라게 BackLog에 나와 있는 내용을 개발하는 활동

좀더 뜯어 보자.
> 2~3주간 : 이것을 스프린트라고 한다. 전력질주
> 외부의 인터럽트를 받지 않고 : 이것을 스프린트라고 한다.
> 열나게 : 이것을 집중도(velocity)라고 한다.
> BackLog : 개발할 내용

이제 조금 이해가 되는가?

원론적인 스프린트는 '마징가 개발 프로젝트'와 같은 닫혀있는 개발방법으로 BackLog에서 합의된 내용을 정해진 기간동안 그것만 집중하여 개발하는 방법이다.

이렇게만 될 수 있다면 우리는 정말 많은 일을 할 수 있을 것이다.

주말에 나홀로 사무실에 나와 홀연히 코딩을 할때의 그 생산성을 상상해보라!


3, 스크럼은 집중도 싸움

하지만 현실을 보자. 우리는 절대로 100% 집중할 수 없다. 수많은 SW bugs, 고객의 신규 요구사항, 사장님/임원의 긴급 요구사항 등등 매일 수많은 메일에 시달리고 있는 것이다. 

그런데 집중도 100%의 스크럼이 가당키나 한가? 

사장님의 긴급 urgent emergency 요청을 2주간이나 기다리라고 할 수 있는가? 

한두번은 가능하겠지... 

하지만 지속가능하지 않다. 

    "스크럼은 본인 팀의 적절한 집중도를 찾아가는 방법이다."(유동환)  

위에서 언급되지 않았던 PO(Product Owner)와 SM(스크럼 마스터)의 역할은 이때부터 시작된다. 

추가적인 단어를 배워보자. 

   - 스프린트 시작회의: 스프린트를 시작하기 전에 이번 스프린트동안 개발할 BackLog에 대해서 얼마나 시간이 소요되는지 일정 산출. 꼭 해야할 것과 그렇지 않은 option 사항을 결정한다. PO가 먼저 제안하고 회의때 합의한다. 

   - 스프린트 회고: 스프린트 기간이 끝나면 산출물을 데모하고 배운점(Lesson learned)을 서로 회고하고 공유한다. 짤막하게 남겨 놓는다.  

4. 집중도는 작게 시작하자: 25% 부터~ 


책에는 70%정도가 적절하다고 한다. 하지만 70%정도가 되려면 진짜 외부 인터럽트가 다 차단되고 사전에 관리되어 있는 높은 수준에서만 가능한 수치라고 생각한다.


외부 인터럽트는 스프린트 시작회의에서 논의된 것이 아니라면 모두 인터럽트이다. 즉, 집중도를 까먹어야 한다.

외부 인터럽트는 가능한 최대한 협상을 하여 다음 스프린트에 뺄수 있으면 좋겠지만 꼭 필요한 것은 해야 한다. 그것은 다음 스프린트의 집중도를 산출할 때 감안되어야 한다.

부담없이 25%부터 시작하자. 어떤 팀은 100% 인터럽트성 업무만 해야할 시기(period)라면 집중도 0%라고 하자. 스크럼은 개방된 개발 방법론으로서 최대한 모든 사항을 open시키는 것을 원칙으로 하고 있다.


5. 예측하는 것은 누구나 싫어한다. 


어떤 개발 항목이 나왔을 때 그것이 얼마 걸려요~ 하는 것은 가장 난이도가 높은 고도의 심리적인 작업이다.

1) 기술적으로 순수 구현했을 때의 시간  ... 개발자의 가장 잦은 실수
2) 제품 출시나 외부에서 바라보는 요구되는 시간 ... 영업혹은 윗선의 push
3) 내부적으로 투입할 수 있는 집중도 ... 그동안 쌓여있는 업무

위의 3개를 종합적으로 때로는 조직적으로 검토를 해야 합리적인 일정이 산출될 수 있다.

하지만 고급 SW엔지니어는 예측할 수 있어야 한다.


6. 결론 


나는 이번주부터 2개의 Application의 스크럼 마스터를 맡게 되었다. 이론적으로는 위와 같이 장광설을 풀었지만 실전에서는 어떻게 효과를 발휘할지 아직 본인도 예측할 수 없다.

그러니까 고급 SW엔지니어 지망생일 것이다.

나는 그 두개의 App에 대해 전혀 사전 지식이 없으며 순수하게 Scrum Master로서 참여하고 있다.

 > 개발팀 소속의 스크럼 마스터(A형) vs 외부에서 온 스크럼 마스터(B형)

어떻게 달라질까? 내 주변에는 A형이 80% , B형이 나 포함 20%이다. 혼자는 아니다
앞으로 어떻게 발전할지 비교 관찰해보는 것도 흥미로운 일이 될 것이다.

2013.8.10 @Home