It's Myself

오랜만에 방문한 김창준씨의 “애자일 이야기”에 가보니 “게임 개발을 위한 스크럼 마스터 교육” 이라는 항목이 보였다.

개인적으로 스크럼 마스터 자격증의 현실적 가치는 별로 없다고 생각하고(자격증이 있다는 것은 이틀간 CSM 교육을 들었다는 것 외에는 별다른 의미가 없다고 생각), 또 스크럼 연합의 자격증 정책을 좋아하지 않습니다만, 스크럼을 기업에 퍼뜨리고 마케팅하는 데에 효과적인 방법이었다고 인정합니다.
자격증에 대해 그다지 우호적이지 않으면서도 이번 교육을 제 블로그에 소개하는 이유는 자격증 획득 외에도 다른 가치가 있다고 생각하기 때문입니다. 특히 클린턴은 애자일을 실제 게임 개발에 꽤 적극적으로 적용해본 경험이 있어서 그런 부분에서 얻을 것이 많다고 생각하고 있습니다. 다만 아쉬운 점이 있다면 수강료에서 "자격증 획득" 부분이 상당비율을 점유하지 않을까 하는 점이죠.

자격증 같은 부분에 대해서는 부정적인 의견이신것 같다. 하지만, 지하철 왕복비 수준의 비용으로 받는 교육이라면 질러 볼만 하다.(대략 10만원까지 어떻든 마련해 볼까 고민했는데, 결제 금액에 놀랐음) 
게다가, 바스 보드씨가 방문한다는 사실은 뭐랄까…
책으로만 뵙던 분을 본다는 미묘한 기분 같은 기분이 들었다.

사실 사내에서 이 애자일 기법(주로 스크럼 기반으로) 적용을 해보고 싶었지만, 애석하게도 부서내 개발자로는 본인 한명 뿐인지라, 이러지도 저러지도 못하고 그냥 책 읽고 상상하는 정도에 불과해서 고민이였는데, 새로운 이야기를 듣고 나면 좀더 구체적으로 움직일 수 있지 않을까 하는 기대감이 든다.

10월 19~20일이라.. 일단 신청은 했고, 다시 새로운 마음으로 애자일을 외쳐본다!!!!!!

많은 소프트웨어 방법론들을 보면(전부는 아니지만, 대개 유명하다고 싶은 것들을 몇가지만 보면),
오랜 역사와 시행착오, 그리고 경험을 축적하여 공학적으로 정리한 방법들을 다양하게 시도하고
제공한다. 건축 메타포의 형태로 끄집어 내 정리한 부분도 있고, 각종 제품 생산 라인을 정리한 부분도 있다.

공장에서 제품을 생산하는 예를 들어보자.
생산라인 A를 통해 최종 제품 A를 만든다. 맨 처음 사람은 제품 프레임을 꺼내 몇가지 선들을 붙이고 정리해서 컨테이너 벨트 위에 얹는다. 그 다음 사람은 다시 파워 유닛을 꺼내 프레임에 얹고 나사로 고정한다. 그렇게 흘러 흘러 맨 나중의 사람이 그 제품을 마무리하고 포장을 한다.

공장 생산 만능 주의 - 작업 흐름과 분업 그리고 예측이 가능해야 생산이다! 라고 생각하는 - 에 빠지신 분들에게는 정말이지 저 생산방식이 가장 효율적이고 완벽하다고 생각한다. - 또한 많은 공장들은 저렇게 생산하며, 큰 문제없이 잘 해오고 있다. - 그런데 왜 소프트웨어는 저렇게 안돼?

공장과 소프트웨어의 개발을 가만히 매칭 시켜보면, 우리도 그 공장 메타포를 은근히 이해하고 이용하고 있다.
컨테이너 벨트가 바로 일종의 폭포수 모델의 메타포라고 생각한다면, 컨테이너 벨트 옆에 앉아 부품을 하나씩 끼우는 사람들이 아키텍처, 설계자, 개발자, 테스터의 역할을 한다고 보면 된다. 이 공장 메타포가 이해가 안될지도 모르겠지만, 가만히 생각해 보면 이런 핑계를 대고 있지는 않는지 한 번 주변을 보자. 프레임이 구축되지 않아서, 설계가 빠져서, 이전 부분을 개발하는 개발자가 덜 개발을 하고 아파서 등등.....
이게 바로 공장 형태의 개발을 중시하는 모습이지 않을까 싶다.

자, 그럼 우리의 소프트웨어도 완벽한 분업과 완벽하게 시간을 잴 수 있겠네? 라고 미리 짐작하실 분도 있고, 아니면 그래서 우리 소프트웨어가 납기 못맞추고 제대로 못만든다고 생각할 수도 있다. ( 후자의 경우는 대개 작업 초반자가 깽판? 을 부려서 그런 현상을 발생한다고 생각한다. 설계 미스, 아키텍처의 부실 등등 )

그런데 내 생각은 다르게 보고 있다.
소프트웨어의 개발은 그 컨테이너 벨트 위에서 벌어지는 것이 아니라, 바로 그 컨테이너 벨트 자체를 만드는 것이라고 생각한다. 그리고 그 컨테이너 벨트를 이용하는 쪽이 고객이라는 사실이다.
공장마다 컨테이너 벨트의 종류와 배치가 전혀 틀리다. 생산품에 따라 전혀 틀리다. 몇가지는 비슷할 지 모르겠지만, 대개 틀리다. 또 어디서는 직선의 컨테이너 벨트가 다른 공장에서는 "ㄱ"자로 휜 형태의 컨테이너 벨트일 수 있다. 어디는 속도가 시속 1KM로 진행되면, 어디는 시속 1.5KM로 컨테이너 벨트가 흐른다.

고객이 가진 조건과 형태가 매번 할때마다 판이하게 틀리다. 공통화 시킬 요소가 너무 적다는 생각이다.
(윗 말에 반박의 내용으로 "MS 윈도 같은 경우 다양한 분야에서 다양하게 쓰인다" 라고 건넬지는 모르겠지만,  그게 그렇게 간단하게 만들어졌다고 생각한다면, 당신은 프로그래밍을 모르시거나, 정말이지 낙관주의자 인듯 싶다.MS 윈도 프로젝트는 애들 장난하는 프로젝트가 아니다. 수천명의 개발자가 다양한 생각과 다양한 의견 충돌을 어떻게 어떻게 조율하고 조정해서 만들어지는 것이다. 정말이지 MS 윈도가 지금까지 끌어온 윈도 시리즈를 보고 있으면 윈도 개발팀-그룹에 대한 무한 영광을 올리고 싶다)
우리가 닥쳐서 일하고 있는 SI라는 환경은 바로 이런 곳이다. 매번 고객의 요구가 바뀐다. 또 시대의 흐름에 필요한 컨테이너 벨트가 필요한데, 그 컨테이너 벨트를 만드는데 시간이 많이 걸리고, 변화에 유연하지 못하면 요 근좌 유행하는 소량 다품종 생산과 거리가 멀다. 고객은 컨테이너 벨트에 지랄하고, 개발자는 돈 조금 줘 놓고, 제멋대로 이것 저것 만들어 달라는 고객에 지랄한다.

왜 이런 현상이 발생했을까?
나의 주관적인 생각에는 다음과 같이 요약되지 않을까 싶다.

개발자측은 개발자 측 대로 컨테이너 벨트가 있어 이 안에서 나름 순서에 맞는 제품을 만든다.
(즉 가급적 똑같은 형태의 여러개의 제품이 나오길 기대한다.)
고객은 고객 측 대로 개발자의 생산품으로 컨테이너 벨트가 구축되어 돈벌이를 위한 제품을 만든다.
(즉 자기 입맛에 맞는 환경 구성용품을 사길 원한다.)

서로간의 양보가 없다면 이건 절대 끝나지 않는 무한루프의 게임이 된다.
근래 공부한 내용 중에 한가지를 대안점으로 들자면 바로 SCRUM 이다. (럭비의 SCRUM 작전이라고 한다. 무슨 긴 문장의 약자 따위는 아니다 ) 고객이 필요로 하는 점들을 나열한 뒤, 고객이 필요로 한다고 판단된 최소한의 기능을 구현하여 시연까지 될 수 있는 아주 작은 단위(2주? 3주? 한달? 그렇게 일정 기간 단위로 나눈)로 점진적으로 개발한다는 것이다. 초기에는 혼란의 연속이고 끊임 없는 개발일지는 모르겠지만, 조금씩 조금씩 하다가 보면, 미처 서로간에 놓치고 있던 문제점이나 생각을 정리하고 볼 수 있지 않을까? 고객이 원하는게 무엇이며, 개발자 측이 보여줄 수 있는게 무엇인지를 조금이나마 더 명확히 볼 수 있을 것이라 생각이 든다.

한번 고객과 개발자 측이 이런 문제로 무한루프에 빠져 있는 상황이라면, 한번 읽어보고 조금씩 하나씩 실천해보는 것도 좋을 것같다. 나 역시 이런 실천 방법들을 고민하고 생각하며 공부하고 있는 중이다.
(추천 도서 : 스크럼과 XP)