00. 애자일이 실패하는 이유(실리콘밸리)
몇 주 전에 재미난 글 하나가 페이스북을 떠 돌았습니다.
실리콘밸리에서 일어난 애자일 실패 스토리인데요.
재미있게도 이런 비판은 국내에서도 많습니다.
이미 국내에도 실패 경험담들이 많이 쌓였다는 뜻입니다.
※ 참고글 : The Hazards of Silicon Valley (번역 : 왜 애자일 스크럼이 끔찍한가)
참고로, 이글은 2015.6.6일에 포스팅 되었습니다.
먼 과거의 이야기가 아닙니다.
글쓴이는 실리콘밸리에서 일하는 소프트웨어 엔지니어입니다.
개인 블로그에 실리콘밸리의 화려한 이면을 주로 폭로하고 있어 유명하기도 합니다.
이 글에는 댓글이 738개나 달렸는데요.
실리콘밸리의 현실을 그대로 보는 듯 해서 더 재미있습니다.
01. 내가 느낀 현장
그런데 왜 이런 실패들이 일어날까요?
왜 애자일은 실패하고, 개발자들의 끔찍한 경험으로 자리잡을까요?
그런데 이 댓글들을 찬찬히 읽어 보면, 국내 개발자들의 반응과도 비슷합니다.
거기에 대해 적어 보았습니다.
이 글이 도움될 분들은 아마 기술에 대한 이해가 부족한 경영자분들이 아닐까 싶습니다.
(1) 잘못된 시작
제가 본 사례는 이렇습니다.
첫째로, 개발팀이 애자일을 도입하자고 경영자에게 보고합니다.
이 경우는 대부분 사업팀과의 갈등 해결 수단으로 시도됩니다.
일방적인 지시과 부족한 일정을 탈피해 보고 싶은 것이지요.
그런데, 애석하게도 많은 경우 경영진을 설득하는 논리가
“생산성이 높아진다”입니다.
그렇게 “조직내 프로세스”로 받아들여 집니다.
당연히 생산성은 높아지지 않고, 갈등도 해소되지 않습니다.
둘째로, 경영진이 도입을 원한 경우가 있습니다.
이 경우는 경영진이 애자일의 우수 사례를 듣고 와서
자기 조직에도 실험해 보는 것입니다.
보통 전략부서와 컨설팅업체에 의해 실행 전략이 만들어집니다.
하지만 거의 실패합니다.
조직 갈등이 높아지고 일 진행이 멈추어 버리지만, 보고는 좋다고 올라갑니다.
결과가 좋아야 하므로 직원들이 몸빵으로 때웁니다.
그러면 경영자들은 애자일 도입이 성공했다고 믿으며 친한 회사에게 전파합니다.
경험상 이런 케이스가 결코 작지 않았습니다.
시작부터 잘못된 것이지요.
(2) 탄생에 대한 이해 부족
애자일이 왜, 어떻게 생겼는지를 이해하지 못하면, 본질을 이해하지 못합니다.
본질을 놓치고 형식을 따라하다 보면 원하는 결과를 얻을 수 없습니다.
애자일하게 일해 보자라고 처음으로 합의한 사람들은
당시 40대 개발자들 17명이었습니다.
시니어로서 팀이 가볍고 쉽게 일하기 위한 방법론을 자주 모여서 토의했고,
스노우버드 리조트에 놀러가서 일종의 합의를 도출한 것입니다.
선포라기 보다 회의록 정리? 정도 됩니다.
그런데, 그들이 그런 것을 고민했을까요.
그것도 프로젝트 관리자나 사업담당자가 아니라, 개발자들이?
왜냐하면 그들이 기존의 개발방법을 불편해 한 당사자들이었기 때문입니다.
그리고, 그들이 그 불편을 바꿀 당사자들이었기 때문입니다.
(시사점)
SW개발은 개발자들이 일하는 방법을 바꾸어야 달라진다.
SW개발 프로세스 등이 불편한 것을 제일 만이 느끼는 사람은 개발자들이다.
2001년은 닷컴버블이 꺼진 직후다. 반성할 것이 많았을 듯.
(3) 전달자의 이해 부족
애자일이 인기를 끌자 전달자들이 생겼습니다.
하지만 많은 전달자들이 외부 조직이었습니다.
그래서 애자일이 “잘 팔리기 위한 컨텐츠”로 가공되었습니다.
조직효율 극대화와 생산성 향상을 위한 “개발 프로세스”로 변형 되었습니다.
마치 좋은 칼을 쓰면 좋은 요리가
저절로 만들어지는 것처럼 이야기 되었습니다.
그러다 보니 문제는 도입할 때 발생되는
조직의 거부반응은 전혀 설명되지 않았습니다.
그리고 그런 거부반응을 이겨낼 조직장치 하나 없이 도입되기 시작했습니다.
이 거부반응을 이겨낸 조직은
훌륭한 협업체계를 가지게 되었지만,
많은 조직은 그렇지 못했습니다.
개발자의 부정적 경험은 조직 내 생산성의 저하로 이어집니다.
(시사점)
전달과정과 상품화 과정에서 내용이 변질 되었다.
실행해야 할 사람은 빠지고, 부속품들을 통제하는 프로세스만 남았다.
(4) 생산 프로세스로 접근
경영자들에게 품질관리와 생산성은 언제나 큰 숙제입니다.
좋다면 도입해 보고자 하는 것이 인지상정입니다.
그러나 경험상 애자일은 생산성을 높이는 도구가 아닙니다.
잘 되면 생산성이 높아지는 결과가 보이기는 합니다.
여기서 생산성이란 분량만 이야기 하지 않습니다.
품질도 어느 한계선까지는 좋아집니다.
Why에 대한 이해가 없다면 2주짜리 스프린트는 그냥 쥐어 짜기일 뿐입니다.
단기적인 산출 분량은 많아지지만, 품질은 떨어지고 개발자는 번아웃 됩니다.
오히려 그냥 지시하는 게 훨씬 더 쉽고, 간단하고 효과적입니다.
애자일을 생산성에 대입시키면 그 순간 프로세스화될 수 밖에 없습니다.
왜냐하면 대부분의 기업들은 분업화된 조직을 가지고 있기 때문입니다.
분업화된 조직에서 생산성을 높이려면
일사분란하게 통제하는 수 밖에 없습니다.
그리고 통제를 하려면 프로세스로 만드는 수 밖에 없습니다.
그래서 2주 단위 스프린트는 2주 짜리 프로세스가 되고 맙니다.
즉, “프로세스”는 훌륭한 생산공정(설비)이 메인이고
개발자들은 교체가능한 생산도구로 접근하는 방법입니다.
하지만, “애자일”은 개발자들이 메인이고
그들이 더 잘 일할 수 있도록 도와주는 “도구”로서의 접근 방법입니다.
그래서 반대로 도입하면 개발팀이 멈추어 버리게 됩니다.
(시사점) 소프트웨어 개발은 처음부터 끝까지 개발자가 메인이다. 생산설비이자 자원이다. 그런데 그게 기계가 아니라 사람이다. 좋다고 아무렇게나 아무 곳에나 애자일을 도입하면 안된다. 조직이랑 안 맞으면 도입하지 마라.
03. 어떤 문제들이 일어났을까?
2주 단위의 점검 프로세스는 빡셉니다.
당연히 번아웃이 일어납니다.
그리고 자율은 통제의 상실로 이어집니다.
통제의 상실은 결과물의 부재로 이어집니다.
즉 밖에서 바라보면 애자일을 도입한 팀이
아무것도 안 하는 것처럼 보이게 됩니다.
만일 이런 현상이 보인다면 애자일을 잘못 이해하고 적용한 것입니다.
애자일이 잘못 되거나, 개발팀이 일을 안하고 있는 것이 아닙니다.
제일 먼저 깨달아야 할 사람은 경영자와 관리자들입니다.
04. 어떤 곳에 잘맞을까?
(1) 창의력이 중요한 현장
문제를 수습하는 팀과, 없는 것을 창조하는 팀은 완전히 다릅니다.
두 개의 성향이 완전히 달라 같은 개념로 접근할 수 없습니다.
문제를 해결하려면 처음부터 높은 완성도의 기술을 적용해야 합니다.
하지만, 없는 것을 만들려면 어설프게라도 시작해야 합니다.
즉, 개발자들이 훈련되어 있는 생각이나 기술들이 다릅니다.
애자일은 절차를 무시?하고 빠른 길로 가자는 겁니다.
새로운 것에 대한 빠른 실천이 중요한 곳이어야 합니다.
빠른 실천은 장애와 에러를 동반합니다.
그래서 장애와 에러가 비교적 민감하지 않은 곳에서 좋습니다.
(2) 변화가 심한 현장
정형화된 프로세스가 중요한 곳에서 애자일은 최악의 궁합을 보입니다.
애자일의 기민성은 절차의 중요성을 무시합니다.
즉, 절차가 중요한 현장에는 에러가 납니다.
반면, 새로 정착된 방법의 결과가 더 좋지 않을 수도 있습니다.
하지만, 그렇게 해서라도 해보겠다는 곳이 있습니다.
그런 곳이라면 아마 애자일 도구들이 주옥같이 느껴질 것입니다.
(시사점) 윗분들이 이런 내용들을 잘 이해하자. 남들이 좋다고 한다고 막 가져 오지 말자. 약파는 이야기에 홀딱 넘어가지는 말자.
05. 좋은 방법
- 좋다고 하는 현장을 방문해 본다. 기존 조직과의 융합, 기존 프로세스와의 정리 등을 챙겨서 본다.
- 직접 실행할 당사자들을 데리고 방문한다. 당사자들이 한 번 해 볼 마음이 들어야 한다.
- 꼭 실패 경험을 물어보자. 그게 없다면 거짓말일 가능성이 100% 다.
(실패경험의 극복 == 면역력의 생성 == 조직적 승화!!!) - 좋아지는 지표가 무엇이었는지, 나빠지는 지표가 무엇이었는지 꼭 물어보자.
- 잘 되는 집의 씨를 조금 받아 오자. 성공경험이 성공경험을 만들어 낸다.
- 우리 조직에 대한 평가부터 제대로 하자. 왜 필요한지를 정해야 한다.
- 실패해도 조직 부담이 적도록 차근차근히 해 보자.
(인류 역사상) 한 번에 현실에서 이데아로 가는 길은 없었다. - 더 복잡한 이야기는 생략.
※ 관련글 : 거짓 합의한 조직의 대표적인 현상, 애벌린패러독스
IT의 중심에서 
댓글 남기기