2012. 10. 14. 23:48

최근에 외국의 한 블로그에 '우리는 어떻게 애자일 개발이 제대로 작동하게 만들었는가(How We Finally Made Agile Development Work)' 라는 포스팅이 올라왔습니다. 제 지도 교수님이 페이스북에 올려주셔서 읽다보니 재미있는 글이길래 주욱 읽고, 제 블로그에도 포스팅을 남겨봅니다.


* 글 위치 : http://blogs.hbr.org/cs/2012/10/how_we_finally_made_agile_development_work.html


제가 자주 주장하는 "애자일은 불가능하다" 라는 걸 깨주는 글입니다. 네, 맞습니다. 이렇게 하면 불가능하지 않습니다. 다만, 이렇게까지 팀을 만들어갈 수 있는 팀은 원래부터 높은 성숙도(maturity)를 보유한 팀이었음을 글을 읽어보시면 아실 거라 생각합니다. 현재 2012년 한국에서는 솔직히 힘들다고 생각합니다. 왜냐하면 대한민국이라는 나라는 군대 문화가 지극히 영향을 받는 '보직 위주'의 사회거든요. 이 이야기는 이 글의 뒤쪽에 잠깐 풀고, 언젠가 때가 되면 자세하게 풀어보겠습니다만, 굉장히 민감한 부분이라 그냥 아직은 술 안주 정도로 씹는 이야기입니다.


어쨌든, 이 글은 무척 재미있는 글입니다. 번역을 하기엔 귀찮아서 슬슬 읽으면서 요약해보았습니다.


애자일팀의 이상향은 애자일을 행하는 것이 아니라, 애자일화 되는 것(being agile instead of "doing agile")이다.


이 포스팅의 저자는 글의 초기에 "많은 회사들이 진정한 민첩함을 팀에 도입하려 발버둥치며 노력하고 있다"고 이야기합니다. 이런 노력을 기울이는 이들의 이상향은 "애자일을 행하는 것이 아니라, 애자일화 되는 것(being agile instead of "doing agile")이다" 라고 말합니다. 저자는 기본적으로 애자일이 실패하는 이유 중 하나로 폭포수(Waterfall) 모델 방식의 작업에 익숙해져 있기 때문이고, 또 다른 이유는 소프트웨어 엔지니어 같은 경우는 코딩을 위주로하는 핵심 업무 자체에서 변화가 없기 때문이라고 합니다. 그 외의 이유로는 애자일을 사용하면 프로젝트가 가야할 길이 명확히 보이지 않는다는 점을 언급했네요.


이 저자가 바로 전에 쓴 포스팅에 팀의 민첩성을 유효하게 만들기 위한 사람들의 글로 댓글이 가득 메워지는 것을 보고, 저자는 사람들이 민첩한 환경에서 편안하게 일하려고 하는 경향이 있다고 언급합니다. 편하게 일을 하고 싶어하다보니 자신의 업무에 대한 보안을 지키게 됩니다. 즉, 자신이 무슨 일을 하는지 동료들에게 투명하게 밝히지 않다보니 팀의 상호기능(cross functionality)이 저해되는 부분도 있다는 거구요.


* 저자의 이전 포스트 : http://blogs.hbr.org/cs/2012/07/a_better_project_model_than_the_waterfall.htm


이렇게 엔지니어들이 자신이 하는 일에 대해 비밀을 유지하고 싶어하는 경향을 이 포스팅의 저자는 '공포(trepidation)'라고 정의하고, 이를 애자일의 과도기(transition)를 경험하지 못하였기 때문일 것이라고 주장합니다. 해당 포스팅의 저자의 주장으로 폭포수 프로세스는 "기획/설계 단계"를 통해 기획자(designer)의 업무가 고립되어 있어, 생산적인 아이디어 도출이나 개발해야 하는 소프트웨어에 맞는 적합한 기획도록 하지 못했다고 이야기합니다.


이런 폭포수 모델에서의 기획/설계가 나쁜 이유 중 하나로, 저자는 기획자 외의 사람들이 기획/설계 단계에 참여하지 못한 부분을 꼽았습니다. 하지만 애자일 모델에서는 제품담당자(product manager), 소프트웨어 엔지니어(software engineer), 품질보증전문가(QA specialist) 등이 기획/설계에 참여하여, 모든 개발자가 2주간의 스프린트(sprint)에서 자잘한 아이디어들을 공급할 수 있게 되었다고 이야기합니다. 이런 과정에서, 처음부터 소프트웨어를 최상의 상태를 만들 수 없었기 때문에 잦은 피드백이 나쁘게 도착하게 되므로, 마치 자신들이 하는 일이 가치가 없는 것처럼 느껴지기도 했다고 합니다. 이런 과정을 거쳐 저자는 "애자일로는 좋은 기획/설계를 만들 수 없다" 라는 결론을 내렸다고 합니다.


애자일 모델을 기획/설계에 도입하면서 부딛힌 한계 때문에, 저자의 팀은 기존의 폭포수 방식의 방법을 애자일 방법론에 녹여 사용해 보려고 했는데, 그 역시 맞지 않았다고 합니다. 그리고 바로 그것이 기획/설계 영역에서 애자일이 정상적으로 작동하지 않는 이유였음을 깨달았다고 합니다. 그 전까지 팀이 보유한 전문성, 능력, 기술, 도구 등은 중요했지만 그들을 사용하는 방식이나 시점이 모두 변경되어야 함을 깨달았던거죠.


기획자들은 자신들의 역할을 팀의 각 부분에 맞게 재배치할 수 있도록 역할을 변경하였으며, 이 부분은 정말 괴로운 변화였다고 합니다. 이런 경험을 통해 저자의 팀은 기획/설계가 단순히 문서화된 글자나 픽셀 이상의 의미를 가짐을 알게되었다고 하네요. 저자는 기획/설계가 성능, 가격 전략, 컨텐트 등 사용자 경험에 대한 많은 요소들을 포함해야 함을 깨달았다고 합니다.


저자는 현재 애자일 세계에 발을 들여놓고서 잘 맞지 않는다고 괴로워하고 있는 사람들을 위해, 지금 사용하고 있는 프로세스를 어떻게 재구성하고 민첩함을 요하는 팀의 가치에 맞게 변화할 수 있는 지 고려해야 한다고 말합니다. 또한 자신들의 역할과 역량을 되돌아보고, 직책(job title)에 한정되게만 일하고 있지 않는지 돌아봐야 한다고 주장합니다. 이런 요소들을 찾아 전환하는 연습을 하는 것이 애자일로의 변화를 위한 기반이 될 수 있다고 합니다.


자신들의 역할과 역량을 되돌아보고, 직책(job title)에 한정되게만 일하고 있지 않는지 돌아봐야 한다


이제 다시 글 초반에 싸질러 놓은 제 주장에 대한 이야기입니다. 한국에 왜 애자일 도입이 불가능할 정도로 어렵나하는 이야기를 제 경험을 기반으로 해 보겠습니다.


첫 째로 군사정권을 거치면서 군대식 문화가 너무 뿌리깊게 박혀 있고, 아직까지도 분단국가라는 특수성 때문에 사회의 절반을 차지하는 남자들이 의무복무를 하고 있기 때문에, 이런 보직위주의 문화가 무의식적으로 전 사회적으로 널리 퍼져 사람들의 사상에서 제거가 되지 않습니다. 사람을 보직으로 나누어 놓고, 그 보직안에서의 역할 수행하는 것이 옳다고 생각합니다. 그리고 이를 기반으로 역량을 측정합니다. 


이런 부분은 SW개발의 전 영역에 악형향을 끼치지만, 특히 테스트 영역에서 아주 나쁘게 나타납니다. 어떤 테스터(Tester)가 단위테스트에 역량이 높은지, 자동화에 역량이 높은지, 테스트 전략 수립에 역량이 높은지 전혀 모른채로 무작정 제품을 던져주고 테스트하라고 하기 때문에, 역량 있는 테스터를 거친 품질보증담당자(Tester -> QA specialist)가 나오지 못합니다. 이 부분은 한국 SW산업에 굉장히 큰 악영향을 끼치고 있습니다. 테스트를 체계화하지 못하고, 그렇기 때문에 조직 내에서 힘쎈놈, 입김쎈놈, 뭐하는지 모르겠지만 일단 경력있는놈 위주로 돌아가게 만들었다보니, SW의 공정 자체가 정량화 되지 못하는 결과를 낳고 있고, 비-정량화 된 상태에서 관리자의 감으로만 조직이 굴러가고 있는 부분이 그렇습니다. 대부분의 성공한 IT업체에서 SW가 성공했는데, 왜 성공했는지 측정이 되지 않습니다. 반대로도 마찬가지구요. 사업을 잘해서, 마케팅을 잘해서 성공했다고 쉽게 결론 내리고 끝내버립니다. 정량화된 기준이나 데이터가 없으니까요.


자, 위 글에서는 기획자의 역할을 분리하여 팀 전체의 알맞은 부분에 분산시켜 기획과 설계를 안정화 시켰다는 이야기를 했는데, 사실 기획만이 아니고 코딩, 테스팅 부분도 역할 분담을 해야 하며, 가능한 사업적인 부분도 역할 분담을 해야 합니다. 예전처럼 "넌 이거 잘하니까 이거 해" 라는건 애자일 모델에선 맞지 않으며, 굳이 애자일이 아니더라도 21세기에서는 불필요한 이야기입니다. 시대에 뒤쳐지는 발상이죠. 21세기의 SW는 굉장히 복잡하고, 개발 참여자들이 서로 다른 사람의 업무를 이해하고 있어야 정상적으로 협업이 가능한 부분이 많습니다. 가장 영향을 많이 받는 부분이 설계, 코딩, 테스팅이지요. 모든 분야를 잘 할 필요는 없지만, 적어도 이해할 줄 알아야 하지, "저건 내 업무 아니니까 신경 안쓸래" 라는 태도는 좋지 않습니다. 개인적으로 그런 스탠스(stance)를 가진 사람은 업무에서 빼야한다고 생각해요.


둘 째, 첫 번 째 이유와 얽혀 있는 부분인데, 일반적으로 사람들이 편안함을 추구하다보니 자신의 영역에서 변화가 추구되는 것을 원하지 않습니다. 남들은 다 변화시켜도 자신은 그대로 있으려고 드는게 대부분의 '자신만은 변화를 추구한다는' 사람들의 행동 패턴입니다. 자신이 아는 것만은 확실하다고 확신하면서 남을 변화시키려고 하는데, 정작 자기 자신은 자신의 고집과 아집속에 그대로 남아 있습니다. 예를 들어, 애자일의 여러가지 도구 중 어떤 하나에 집착하여 목표를 설정하고, 이를 이루어 내려고 하다보니 정작 필요한 개선이 되지 않는 것이지요. "우리는 애자일을 시행하고 있어" 보다는, "우리는 아직 부족하지만 서로 잘 협업하고 있어" 가 훨씬 낫지 않은 지 돌이켜봐야 합니다.


이 글도 그렇고, 현재의 우리는 너무 애자일 모델에 목 메달고 있습니다. SW공학 역량의 성숙도를 측정하는 CMMi의 최고 레벨은 5단계로, 그 이름은 "지속적인 변화"입니다. 그런데 이걸 달성하기가 너무 어렵습니다. CMMi 3단계도 사실 현업을 하는 사람들이 "정확히" 측정하면 달성하기 어렵습니다. 이렇게 정석적인 방법을 달성하기 어려우니까 애자일 하겠다고 하면, 적어도 저는 안말립니다. 애자일 도입 하라고 합니다. 근데 무조건 폭포수는 나쁘고, 애자일 해야 한다는 글을 보면 (외국의 저 포스팅도 폭포수의 장점 없이 애자일로 해결했다는 식이지만) 어이가 없습니다. 애자일은 폭포수 모델을 제대로 이해하지 못한 사람은 할 수 없습니다. 왜냐하면 이 글에서 말했다시피 "삽질한 경험을 통한 개선과 변화"가 수반되어야 이룰 수 있는건데, 폭포수도 제대로 못한 사람이 무엇을 기준으로 변화를 할까요? 애자일 광신자들은 인정하기 싫겠지만, 소프트웨어 엔지니어링의 기본은 폭포수입니다. 이것은 인간의 인식 체계가 순차적으로 발생하도록 되어 있기 때문입니다. 응용은 그 다음이죠.


위에서 설명한 첫 번 째와 두 번 째는 제가 실제로 많이 겪어본 경험에서 나온 이야기입니다. 


제 개인적인 성향에 대한 이야기를 잠시 하자면, 저는 어디 누군가에게 두려움을 갖거나, 거대한 권력이 무서웠던 적이 없습니다. 누군가 저의 그런 모습을 보셨다면, 그건 제가 작정하고 연기하는 모습을 보신겁니다. 권력을 가진자들은 그런 걸 좋아하더라구요. 맞춰준거죠. 저는 조폭이나 경찰 앞에서도 쫄지 않습니다. "저 사람도 저러는 이유가 있겠지" 라고 생각하고 그에 맞춰줄 뿐이죠. (최근에 주진우 기자 책을 읽는데, 이런 맹랑한 하룻강아지식 삶이 저 하나가 아니라 무척 다행이라고 생각하고 있습니다. 어딘가 또 있겠죠. 주 기자랑 저 말고도.)


저는 어딜 가나 개발팀의 프로세스 개선을 위해 노력했고, 하고 있습니다. 이런 성향을 가지고 있다 보니, 상대가 누구든 불합리 하면 잘 못 했다고 했다가 손해도 많이 봤죠. 요새는 나이도 들고 해서, 현명히 해결하거나 피해버립니다만, 예전엔 참 피해를 많이 봤습니다. 최근에 나이 들고도 손해본 예도 있구요. 최근 몇 년의 경험 중, 지금은 망해버린 회사의 이야기 하나를 언급하자면, 너무나도 비정량화되고 관리자의 감에 따라 운영되고 있는 조직을 정량적으로 변화시켜 보려다가 윗 사람한테 욕먹고 싸대기 맞아본 적도 있습니다. 그곳에서 그리 큰 변화를 원한 것도 아니었습니다. 팀원들의 역량을 명확히 평가하기 위해, 우리 회사 내에서 갖추어야 할 역량을 전략적으로 잡고 교육시키고, 세미나에 보내는 등 역량 강화도 전략을 수립해서 진행해야 한다고 했다가 저항에 부딛혔습니다. 그 분들은 "모든 개발자는 코딩만 잘하면 된다" 라면서, QA조차도 코딩만 시키더군요. 정말 좌절, 좌절, 대-좌절이지요. 그들은 아직도 어느 회사엔가에 가서 또 그짓거리를 하고 있을 것이고, 그들에게 업무를 배운 이들은 그게 맞는 줄 알고 또 그런 식으로 행동하겠지요.


솔직히 저로서는 이런 부분들이 해결이 될지, 어떨지, 정말 모르겠습니다. 이미 사회적으로 너무 뿌리깊게 박혀 있거든요. 간절한 소망이건데, 다음 대통령은 꼭 IT분야에서 SW공학이 왜 정량적으로 관리되어야 하는 지에 대해 알고 계시는 분이 당선되었으면 좋겠습니다. 그래야 대한민국의 SW분야가 앞으로 더 나아갈 수 있을테니까요.




Posted by 『 Lv8+の 꽃怪獸 』 천년나무