우리회사는 왜 애자일 전환에 실패했을까?
어느 날 대표님이 우리도 애자일 좀 해보자고 말했다
햇살이 내리쬐는 따뜻한 봄날. 베란다에서 광합성을 하던 서점군의 곁에 사장님이 다가오십니다.
사장님 : 서점아 우리도 애자일 그거 해야 되지 않을까?
서점군 : (또 시작이군. 여기도 떠날 때가 된 건가...)
오늘은 프로이직러이자 3개 회사에서 애자일 전환을 경험한 서점군의 애자일 실패 경험담입니다.
C-Level의 애자일 이해도 부족
애자일 전환 결심은 보통 C-Level단에서 이루어집니다.
의외로 많은 사장님들이 유행에 민감합니다.
"이게 요즘 미국에서 유행하는 최신 기법이래"
"구글은 이렇게 해서 생산성을 높인다던데?"
사장님들은 업계 사장님들의 모임, 서점가에 꽂혀있는 책, 외국의 아티클을 번역한 칼럼이나 번역글에서 서구의 최신 유행 기법에 대한 이야기를 듣습니다. 대기업들은 이미 앞다투어 도입하고 있다느니 하는 얘기가 들릴 때쯤 사장님은 초조해지기 시작합니다. 유행에 뒤쳐질까 봐 두렵거든요.
그래 카카*나 네*버도 한다는데 좋은 거겠지. 우리도 유행을 앞서나가는거야!
생각보다 애자일 전환의 계기는 몹시 사소합니다. 그리고 이 사소함이 애자일 전환에는 큰 장애물이 됩니다.
많은 사장님들이 애자일을 개발 방법론으로만 인식합니다. 애자일이 생기게 된 배경이라던가 정신, 선언문 같은 건 뒷전에 두고 애자일을 도입만 한다면 조직원들이 주인의식을 가지고 생산성이 올라갈 거라고 생각합니다.
2010년대 중반 에이전시 업계에서 파티션 치우기가 유행이었던 시절이 있었습니다. 구글은 파티션이 없어 조직원들끼리 자유롭게 의사소통이 가능하다. 우리도 도입해야 한다라는 게 이유였죠. 서로를 가로막고 있던 장막을 걷어내면 직원들 간에 소통이 자유로울 줄 알았지만 많은 사람들이 파티션 없는 자리에 피로감을 나타냈습니다. "팀장에게 너무 감시당하는 것 같다" / "파티션이 없으니 사람들이 왔다갔다 하는 게 다 보여서 업무에 집중이 안된다" / "건너편 사람과 눈을 마주칠 때 민망하다" 같은 이유였죠.
소통은 물리적인 공간의 문제가 아니라 조직문화의 문제입니다. 누구나 자유롭게 아이디어를 개진할 수 있고 열린 마음으로 토론하는 문화라면 파티션이 있어도 소통이나 생산성에 문제가 없습니다. 반대로 놀이터 같은 회사를 표방하면서 회사에 미끄럼틀이 있다 한들 조직문화가 경직되어 있다면 소통도 경직되게 됩니다. 조직문화를 바꾸지 않으면 물리적 환경을 바꿔봐야 아무 소용이 없다는거죠.
많은 사람들이 애자일의 정신을 잊은 채 방법론에만 집착합니다. 그러니 애자일 전환이 잘 될 리가 있나요.
호칭은 영어로 합시다
띵동. 메일이 도착했습니다.
[전사공지] 수평적인 조직문화 형성을 위한 영문 호칭제 시행 안내
회사가 애자일 전환을 할 때 어떤 회사던 가장 먼저 하는 일이 있습니다.
바로 호칭 바꾸기입니다.
호칭 바꾸기는 크게 2가지 방식입니다.
1) 직급때고 이름뒤에 ~님 붙이기
2) 영어이름 부르기
호칭 바꾸기의 명분은 수평적이고 자유로운 조직문화 형성입니다. 우리를 억압하고 있는 직급의 굴레를 벗어버리고 모두 한명의 자연인이자 작업자로 돌아가서 사원도 자유롭게 의견을 개진할 수 있는 그런 조직문화를 만들어보자는 취지죠. 명분은 그럴 듯 하지만 실제로 호칭제가 잘 정착되지 않거나 정착된다고 해도 겉핧기식인 경우가 많습니다. 호칭제 정착의 실패에는 여러가지 이유가 있습니다.
1) 팀장급의 격렬한 반발
호칭제 도입의 순서는 보통 이렇습니다.
① C 레벨단의 영문 이름 도입 결심
② 팀장회의에서 영문 이름 도입 발표
③ 전사공지로 영문 이름 도입 발표
①, ③번 과정에서는 문제가 거의 발생하지 않습니다. 오히려 영문 이름 도입을 환영하는 부류도 있죠. 문제는 ②번 팀장급에서 발생합니다. 호칭제 도입에 격렬한 거부반응과 반발을 보이는 부류도 있고 바뀐 제도에 적극적으로 참여하지 않는 부류, 겉으로는 적당히 순응하는 척하는 부류로 나뉩니다.
큰 회사던 작은 회사던 팀장이라는 직위는 회사에서 산전수전 다 겪고 온갖 정치질과 모략, 협잡질을 통해 해당 자리에 오른 인물입니다. 전통적인 조직에서 팀장은 주로 카리스마형 리더십을 가진 사람이 많습니다. 이런 사람들에게 영어이름을 부르라는 건 니가 가진 직급의 권위를 내려놓으라는 말과 같습니다. 내일 당장 새파랗게 어린 인턴이 회의 자리에서 팀장에게 "줄리아 그건 아닌 것 같은데요." 라고 반박해도 팀장이 가진 권위가 아니라 기술적인 논박을 통해 조곤조곤 반박해야 된다는 이야기죠.
회사는 이런 리스크를 알고 있더라도 대수롭지 않게 생각하거나 혹은 무시합니다. 애자일을 도입하는데 생기는 작은 시행착오쯤으로 생각하죠. 팀장급에서는 불만이 있어도 대놓고 불만을 표출하지 않거든요. 명분은 그럴듯하니까요. 거기서 반박을 하면 회사가 발전하려고 노력하는데 반발하는 천하의 쌍놈이 될테니까요.
팀장급은 앞에서는 네네 해도 뒤에서는 호칭제 변경에 적극적으로 참여하지 않거나 혹은 방조합니다. 가장 적극적으로 호칭제 변경에 참여해야 할 팀장급이 방조하는데 영문 이름 부르기가 잘 정착될 수 있을까요? 안봐도 비디오입니다.
2) 전격적이며 파격적이지 않은 호칭 변경
대부분의 회사들이 호칭제 변경에 유예기간을 둡니다. 한번에 바꿀 수 없으니 유예기간을 두고 시행한다거나 뒤에 ~님을 붙인다거나 하는 식으로 점진적으로 한단계씩 호칭제를 도입하려 합니다. 그런데 이는 나이브한 생각입니다. 호칭제 변경은 전격적이며 파격적이어야 합니다.
회사내에서 실명을 쓰는건 금지고 직급을 부르는것도 금지이며 ~님자를 붙이지도 말고 무조건 영어이름으로만 불러라, 외부에 나가는 이름도 명함도 니 실명은 넣지 마라. 고객이나 외부 관계자들도 니 이름을 모르고 옆자리 동료도 니 실명을 모를 정도로..
요정도로 해야 호칭제가 정착될까 말까입니다. 직원들이 반발할꺼라고요? 어차피 직원들은 이래나저래나 반발할겁니다. 어설프게 병행할바에는 독재자 뺨치게 이왕 도입될꺼 파격적으로 도입하는게 훨씬 낫습니다
이렇게 해도 초반에는 익숙하지 않아서 회의실 가면 지들끼리 OO과장님, 팀장님 이렇게 안 보이는 곳에서 직급과 이름을 부를겁니다. 억지로라도 정착을 시켜야 마지막까지 저항하던 사람들도 마지못해 영어이름을 부르게 될겁니다. 그렇게 부르다보면 어느새 익숙해지고 그게 당연시되겠죠.
대외적으로 부르는 직급도 다 없애버리고 현기차처럼 G1, G2, G3, G4 이런식으로 바꿔서 쥴리아 = 팀장님이 아니라 자연인 쥴리아라는 이름을 자연스럽게 튀어나올 수 있는 환경을 만들어줘야 합니다. 외부에 나가서도 기획팀의 서점 과장입니다가 아니라 전략기획팀의 C3 북스토어스태프입니다가 자연스럽게 나올 수 있는 환경이 되어야 합니다. 어설프게 하는 건 죽도 밥도 안됩니다. 영어 이름 부르기 운동의 목적은 글로벌 시대에 맞춰 영어 이름을 부르자가 아니라 수평적인 조직 문화를 만들자 이니까요.
3) 계급과 서열 문화
호칭제 변경의 가장 큰 장벽은 한국사회에 만연한 나이와 서열문화입니다. 한국인은 두명만 모이면 서열을 정한다는 우스갯소리가 있을 정도로 나이와 직급에 따른 서열문화가 몹시 강한 국가입니다. 많은 사람들이 서열문화가 조선시대의 유교 문화에서 기인한 것이다 라는 생각을 많이 하는데 사실은 일제시대의 잔재가 더 정설에 가깝습니다. 일제시대 황국 신민을 길러내기 위한 상명하복, 위계질서의 일제 군대식 문화를 교육에 도입하기 시작한 게 그 시초이고 군사정권이 이를 국민교육 헌장에 도입하기 시작하면서 현재의 나이와 서열문화가 굳어지게 된 것이죠.
TVN 나의 첫 사회생활 유튜브 캡처 이미지 중한국사회에서 나이와 서열문화가 얼마나 뿌리 깊게 박혀있는지는 TVN의 나의 첫 사회생활이라는 프로그램을 보면 알 수 있습니다. 7살 아이가 6살 아이에게 너 몇살인데를 시전하고 6살 아이는 상대가 자기보다 나이가 많다는 것을 확인한 후 바로 혀엉하고 굽히는 모습을 보여줍니다. 상명하복식 문화가 뿌리 깊게 박힌 씁쓸한 단상이죠.
구글에서 수평적인 조직문화가 가능한 건 CEO와 구성원들이 열린 마인드라 그런 게 아니고 원래 서양에서는 그게 당연한거라 그렇습니다. 서구에서는 존댓말, 반말이라는 구분이 없고 13살 스티브가 옆집 사는 70살 할아버지에게 "제임스 오늘 저녁에 게임 한판 ㄱㄱ?" 라는 대화가 스스럼이 없는 문화이기 때문에 가능한거죠. 나이라는 굴레를 벗어나 13살과 70살도 대화만 통한다면 얼마든지 친구가 될 수 있는 문화적 환경이 존재하기 때문에 수평적 조직문화 조성이 가능한겁니다. 하지만 한국은 좀 다릅니다.
28살 기획자가 32살 개발자에게 "토미 여기 부분 에러가 많은데요" 라고 말하는건 어쩌면 가능할수도 있습니다. 32살 개발자가 심성이 착한 놈이라면요. 하지만 32살 개발자가 47세 팀장에게 "모니카. 모니카가 작성한 이 부분 기획서에 문제가 있는것 같은데요" 라고 말하는건 극히 어렵습니다. 32살도 그럴진데 하물며 25세 인턴이 47세 팀장에게 "모니카 저는 이 의견에 반대합니다" 라고 말하기는 불가능에 가깝죠.
호칭제 변경이 잘 정착되려면 가장 나이가 많고 가장 직급이 높은 직원들이 호칭제 도입에 적극적으로 협조하고 나서서 영어 이름 부르기를 시작해야 합니다. 그런데 호칭제 변경에 가장 거부반응을 일으키는 사람들이 이 사람들이니 호칭제가 잘 정착될 턱이 있나요.
수평적 조직이 안되는데 수평적 의사소통이 가능할리 없습니다. 호칭제 변경이 실패하는 시점부터 애자일 전환은 반쯤 실패한거나 마찬가지입니다.
이상한 조직개편
호칭제 변경이 어느정도 정착되면, 혹은 호칭제 변경과 동시에 많은 회사들이 다음 스텝으로 시행하는 것이 있습니다. 바로 조직개편입니다.
애자일 기반의 조직구조는 기존 보직 위주의 팀 구성에서 벗어나 같은 업무를 하는 실무자끼리 묶어서 팀을 구성하는 이른바 셀 방식입니다. 어느기업에서든 마찬가지겠지만 조직개편의 끝은 결국 밥그릇 싸움으로 귀결됩니다. 애자일은 특히 더 심하죠. 직급이 높으면 높을수록 잃을 것이 더 많아지니까요.
애자일 조직개편에서 가장 애매한 인력들이 바로 팀장, 임원급입니다. 이 사람들의 공통적인 특징은 회사 재직 기간이 오래되었고 고인물이며 월급 루팡인 경우가 대부분이죠. (가끔 능력자들이 있긴 함) 문제는 중소기업 특유의 보상 심리로 인해 회사 규모에 비해 너무 많은 임원이 있으며 능력에 비해 이분들의 발언권이 너무 세다는 데 있습니다.
생산성을 높이기 위한 조직개편이 갈등의 불씨가 되면 이상한 해결책들이 등장하기 시작합니다. 팀장급의 영향을 유지하기 위해 조직 구조는 그대로 두고 아래 구성원들만 프로젝트팀 단위로 묶는 이른바 논리적 애자일 조직이 등장하기도 하고 극단적인 경우 기획팀은 디지털 혁신팀, 개발팀은 디지털 서비스팀 같은 모호한 명칭으로 바꾸고 기획팀에서 개발자를 뽑고 개발팀에서 기획자와 디자이너를 뽑아 애자일팀으로 자체 조직화하는 본질과 벗어난 조직 개편이 이루어집니다.
이런 병맛스러운 해결방법이 탄생하는 배경에는 밥그릇 싸움도 있지만 중소기업 특유의 인력난이 큰 비중을 차지합니다. 풍부한 인력과 자금을 가진 대기업은 보직이동에 익숙하고 필요시 재교육을 통한 인력 재배치가 가능한 반면 늘 인력난을 겪고 있고 구성원 개개인의 역량도 떨어지며 재교육에 비용을 투자할 여력이 없는 중소기업은 할 일은 많은데 적임자는 부족한 상황에 처하게 됩니다. 이러한 상황에서 회사를 먹여 살리는 능력자들은 여기저기서 끊임없는 러브콜을 받게 되고 팀장들은 소중한 에이스들을 지키고 눈엣가시를 털어내기 위해 뒤에서 각종 공작과 암투를 펼치게 됩니다. C-Level에서 이러한 암투를 제대로 조율하지 못하면 조직구조는 그대로 두고 프로세스만 애자일로 바꾸는 병맛스러운 해결법으로 갈등을 봉합하게 되는 거고요.
인력쟁탈전과 치열한 눈치싸움
전통적인 프로젝트 관리에서는 구성원들이 주어진 업무만 수행하는 수동적 참여가 이루어지며 프로젝트 관리자의 역량에 따라 프로젝트의 성패가 갈리게 됩니다. 이러한 문제점을 극복하고자 애자일에서는 구성원들이 프로젝트에 자발적으로 참여하고 책임감을 높여 자기 조직화(Self-organizing)하여 프로젝트 관리자의 역량이 아닌 조직원들의 전체 역량으로 프로젝트를 이끌어 나갈 수 있는 환경을 주문합니다.
애자일 소프트웨어 개발 원칙 12 중
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
(동기가 부여된 개인을 중심으로 프로젝트를 구성, 환경과 자원을 제공하고 작업이 잘 끝낼것을 신뢰한다)
11. The best architectures, requirements, and designs emerge from self-organizing teams.
(자율 구성된 팀에서 최고의 설계, 요구사항, 디자인이 나온다.
애자일에서 가장 강조하는것 중 하나가 바로 동기부여(Motivation)와 자기 조직화(Self-organizing)입니다. 그리고 동기부여와 자기 조직화를 위해 많은 지침서들이 자기가 원하는 일을 하게 하거나 원하는 팀에 넣을것을 주문합니다. 자기가 하고 싶은 일을 해야 동기부여와 열정이 생길테니까요.
하지만 현실은 어떨까요.
"또라이 보존의 법칙", "1%의 천재가 99%의 나머지 사람을 먹여살린다" 는 이야기가 있습니다. 현실은 동화처럼 아름답지 않죠. 일잘하는 에이스들은 어느 조직에서나 탐을 내고 조직개편에서 이런 에이스들은 좋은 먹잇감이 됩니다. 조직개편은 이 일을 가장 잘할 수 있는 적임자이며 본인의 의사에 따라 이루어지는 것이 아니라 회사 내 역학관계에 따라 가장 파워가 쎈 사람이 에이스들을 차지하게 됩니다. 일을 잘하면 잘할수록 본인의 의사와 발언권은 약해지고요. 어느새 동기부여와 자기 조직화는 온데간데 없고 회사내 역학관계와 파워게임만 남게 됩니다.
반대의 경우도 있습니다. 승진, 자기개발 그런거 관심없고 웰빙과 워라벨을 추구하는 사람들에게 프로젝트 선택 기준은 하고 싶은 일이 아니라 꿀을 빨 수 있는 일이 됩니다. 그리고 짬밥이 많으면 많을수록 기가막히게 꿀 빨 수 있는 곳을 찾아내는 능력도 상승하게 됩니다. 쉬운 프로젝트에는 사람이 몰리고 빡센 프로젝트에는 지원자가 거의 없는 상황이 됩니다. 이렇게 되면 또 회사 내 역학관계가 개입되어 강제 재배치가 이루어지게 됩니다.
이쯤되면 동기부여와 자기조직화는 이미 안드로메다로 가버린 상황입니다.
애자일에 적합하지 않은 사무 환경
어찌어찌 조직개편까지 대충 마무리되었다고 칩시다.
애자일 업무 지원을 위해서는 애자일에 걸맞은 사무환경 조성이 필요합니다.
잠깐 애자일 개발 원칙 중 사무 환경 부분을 볼까요.
애자일 소프트웨어 개발 원칙 12 중
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
(동기가 부여된 개인을 중심으로 프로젝트를 구성, 환경과 자원을 제공하고 작업이 잘 끝낼것을 신뢰한다)
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
(정보를 전달하는 가장 효율적인 방법은 얼굴을 마주보고 대화하는 것이다)
조직개편을 했으면 자리배치도 애자일스럽게 바꿔야죠. 각 팀(BU)별로 모여서 마주 앉을 수 있는 책상배치가 필요합니다. 자리만 바꾸는 것도 많은 에너지 소모가 들어가는 일인데 책상 배치까지 바꾸는 건 직원들의 힘만으로는 불가능합니다. 애자일에 적합한 자리배치가 되려면 업자를 불러서 자리배치를 바꿔줘야 됩니다. 그런데 많은 사장님들이 이런데 돈 쓰는 건 아까워합니다. 열정이 있는 사장님이면 직원들을 채찍질해서 직원들끼리 책상 배치를 바꿀수도 있겠지만 그런 건 좋좋소에 나오는 좋소기업이나 가능한 겁니다. 결국 책상 배치는 그대로 둔 채 서로 자리만 바꿉니다. 파티션에 가로막혀, 물리적 거리가 멀어서 회의실을 잡지 않는 한 팀끼리 원활한 소통이 잘 안됩니다.
애자일 조직은 많은 회의실이 필요합니다.
Daily Standup Meeting, Product Backlog Meeting, Sprint Planning Meeting, Story Point 협의 등 이전에 비해 회의할 일도 많고 작업을 시각화할 수 있도록 칸반보드를 붙일 공간도 필요합니다.
회의실 수요는 많은데 회의실이 부족하니 새로 회의실을 만들어주고 각 팀마다 칸반보드를 만들 수 있는 공간이나 환경을 조성해줘야 하는데 모두 다 돈이 꽤나 많이 드는 일입니다.
ING 생명의 데일리 스탠드업 미팅많은 사장님들이 비용 지출에 인색합니다. 사무 환경개선을 투자로 인식하지 않고 비용으로 인식합니다. 칸반보드 명당 자리 선점, 회의실 예약 눈치싸움이 시작됩니다.
업무에 집중해도 모자랄 시간에 쓸데없는 눈치싸움으로 시간을 낭비하고 있습니다. 애자일에서 극혐하는 불필요한 자원 소모와 낭비 요소를 제거하지 못한 결과 업무 효율성이 떨어지고 있는거죠.
과연 애자일 정신을 잘 이해했다고 할 수 있을까요?
모호한 책임 소재
조직 개편도 잘 되고 사무 환경도 그럭저럭 갖춰졌습니다. 이제 본격적으로 애자일을 도입해서 프로젝트를 진행합니다. 그런데 프로젝트 진행 중 여기저기서 끊임없는 잡음이 발생합니다. 그리고 잡음의 가장 많은 비중을 차지하는 것이 바로 모호한 책임 소재입니다.
업무를 하다보면 A팀과 B팀의 업무 경계 사이에 묘하게 걸쳐있는 애매한 업무들이 있습니다. 이런 업무들은 보통 지들끼리 토스하며 주고받다가 해결사가 짜잔 등장해서 교통정리를 해주거나 아니면 권력싸움에서 패배한 (주로 팀장의 파워가 약한 경우) 팀이 받아서 해결하게 됩니다. 그런데 애자일에서는 이 모호한 책임 소재가 더 심하게 나타납니다.
업무란것이 A팀에서 해야 하는 일이라고 딱 떨어지지 않을때가 있습니다. 개발을 수정하면 될 것 같은데 어느 BU에서 담당해야 할지 애매한 업무가 발생하는거죠. 전통적인 조직구조에서 기획에 대한 이슈는 기획팀이 개발에 대한 이슈는 개발팀이 처리하면 됐습니다. 그런데 애자일에서는 팀을 뿔뿔이 흩어놓으니 책임소재가 애매해지는 문제가 발생합니다. 서로 총대 메고 책임지기 싫어하다 보니 업무를 각자 BU끼리 토스합니다. 토스하다가 결론이 안 날 것 같으면 PMO 조직에게 던저버립니다. 에스컬레이션은 그럴 때 쓰라고 만든 게 아닌데 말이죠. PMO 조직은 업무를 조율하느라 죽어나고 각 BU들은 업무 해결에 적극적으로 협조하지 않으려고 합니다. 나섰다간 자기일이 되니까요. 사일로 현상을 해결하려고 애자일을 도입했는데 사일로 현상이 더 심하게 일어납니다.
업무의 우선순위 설정에도 마찬가지 상황이 발생합니다. BU단위에서 생각하는 우선순위와 제품 전체에서의 우선순위가 서로 다를 수 있는 상황이 생깁니다. BU에서는 개발에서 발생한 이슈를 해결하는 것이 먼저라고 판단해도 제품 전체에서는 매출을 위해 마케팅적 이슈를 해결하는 것이 먼저라고 판단될 때가 있습니다. 이런 문제는 BU와 BU 사이에서도 발생합니다. A조직과 B조직의 기능이 서로 연계되어 있는데 바라보는 방향성이나 지향성이 달라질 수 있는거죠.
이렇듯 애자일을 도입하면 누가 나서서 총대를 매고 교통정리해줘야 할 일이 많이 생깁니다. 애자일은 서번트 리더십을 강조하지만 아이러니하게도 애자일을 도입하면 높은 누군가가 나서서 상황을 정리해주는 카리스마형 리더십이 필요해질 때가 많습니다. 재밌게도 큰 회사보다는 작은 회사일수록 이 카리스마형 리더십이 더 빛을 발합니다. 애자일에서 책임소재 문제를 해결하려면 고도의 테일러링(tailoring)이 필요합니다. 그런데 애자일 경험이 없는 조직이 그런 고도의 기술을 가지고 있을리 없죠.
Head들의 역량 부재
애자일 조직이 되면 팀장급은 Scrum of Scrum Master가 되거나 한 Business Unit의 리더급이 되어 프로젝트를 이끌어나가야 합니다. 그런데 여기서 문제가 발생합니다. 많은 팀장들이 실무에 손을 놓은 지 너무 오래된 관리직이거나 한 분야만 전문적으로 판 스페셜리스트거든요.
이미지 출처 : hmgjournal애자일에서는 모든 구성원들이 스페셜리스트(specialist)가 아니라 제너럴리스트(generalist)가 되길 요구합니다. 어제까진 개발 팀장이었던 사람에게 "자 이제 너는 비즈니스와 마케팅 역량, 기획과 디자인을 컨트롤할 수 있는 역량을 갖춰야해" 라고 말하는 것과 같죠. 기획자나 PM 출신들은 이런 업무에 곧잘 적응합니다. 늘 하던 일이 그거니까요. 그런데 다른 직군에서는 이런 능력을 단기간에 갖추기가 어렵거나 그럴 의지가 없는 경우가 많습니다. 내일모레 오십을 바라보고 있는데 내가 이제와서 마케팅을 왜 배워야 되나 싶은거죠.
그리고 많은 팀장들이 카리스마형 리더십으로 지시하는 것에 익숙해져 있는 경우가 많습니다. 10년동안 아래 직원들에게 지시만 해왔는데 갑자기 내일부터 "자 우리는 이제부터 직원을 섬기는 서번트(servant) 리더십으로 부하직원이 아니라 동등한 구성원으로 그들을 섬기며 얘기를 경청하고 토론하는 거에요" 라고 하면 그게 될리가 없죠.
많은 팀장들이 애자일 조직으로 전환된 이후에도 팀장때의 습관을 버리지 못합니다. 토론과 합의에 의한 결과도출이 아니라 권위에 의한 일방적인 의사결정을 하고 데일리 스탠드업 미팅은 현황 파악이 아니라 일일 업무보고가 됩니다. 15분 스탠드업 미팅이 일일 업무보고가 되면 많은 구성원들이 피로감을 느낍니다. 업무의 많은 시간을 데일리 스탠드업 미팅에서 팀장에게 까이지 않기 위한 보고자료를 만드는데 사용합니다.
애자일 프로세스에서 가장 중요한건 시니어급의 마인드셋 전환입니다. 강사를 초빙하고 2박 3일 합숙훈련을 통해서 애자일 마인드를 심어놔도 될까말까인데 그런 과정없이 갑자기 애자일을 도입하겠다고 하면 하루아침에 마인드셋이 바뀔리 없죠.
애자일이 우리회사에 맞는걸까?
모든 프로젝트, 모든 회사에 애자일 방법론이 적합한 것은 아닙니다.
프로젝트 환경에 따라 폭포수 모델이 적합한 프로젝트도 있고 폭포수와 애자일을 혼합한 하이브리드 형태가 더 적합할때도 있습니다. 그런데 애자일을 도입한 많은 회사들이 이러한 환경을 무시하고 무분별하게 애자일을 도입합니다. 디자인 가이드가 나오지 않은 상태에서 서브페이지 디자인을 하라고 한다거나 기능정의가 되지 않았는데 일단 만들고 보라는 식이죠. 스프린트(Sprint)를 반복적인 재작업(Rework)이 가능하다는 것으로 잘못 해석한 결과물입니다. 반복적인 작업에 지친 조직 구성원들의 사기가 저하되고 칸반 보드에서 병목현상이 발생하며 생산성은 폭포수 모델 시절보다 더 떨어집니다. 이쯤되면 구성원들 머리속에 물음표가 띄워집니다.
"아 이게 맞는 건가?"
"미제놈들의 간악한 술수에 우리 사장님이 속은 건 아닐까?"
대부분의 IT회사가 프로젝트 중심조직(Projectized Organization)이나 매트릭스 조직(Matrix Organization) 형태를 띱니다. 이미 조직구조 자체가 어느정도 애자일 형태를 띄고 있는거죠.
Waterfall에서 시작하여 XP > Agile > Scrum > Lean에 이르기까지 개발방법론은 꾸준히 진화해왔습니다. 그리고 만능이라고 생각했던 애자일과 린도 실무에서는 여러가지 한계를 드러내고 있죠. 애자일과 린도 발표된지 20년 가까이된 나름 오래된 방법론이니까요. PMI가 발간한 Agile Practice Guide에서는 생애주기에 따른 개발방법론을 아래와 같이 정의합니다.
PMI Agile Practice Guide 프로젝트 생애주기 특성 중폭포수 : 요구사항이 어느정도 Fix 되어 있는 경우
반복형 : 요구사항 변경 가능성이 높으며 반영을 1번만 해도 될 경우
증분형 : 요구사항 변경 가능성이 높으며 빠른 출시를 원할 경우 (MVP)
애자일 : 프로젝트의 불확실성이 높으며 (예측 불가능) 주기적인 반영을 원할 경우
모든 요구사항과 프로젝트가 애자일 방법론이 필요한 것은 아닙니다. 명확한 RFP가 있는 경우에는 폭포수나 증분형 모델로도 충분한 대응이 가능하고 XD, 스케치나 프로토타입 등 다양한 툴을 이용해 기획이나 디자인 단계에서 고객의 요구사항을 어느정도 도출해낼 수 있습니다. PM의 의사소통 역량이 충분하다면 굳이 애자일이 아니라 다른 방법론으로도 개발이 가능하죠. 그리고 알게 모르게 우리 회사는 조직구조나 개발방법론에서 애자일 프로세스를 일부 도입하고 있고 몇 년째 잘 굴러가는 경우가 많습니다. 하지만 국내에서는 애자일과 린 프로세스가 만능이라는 환상에 젖여 기존 방법론과 조직구조도로도 충분한데 조직의 특성과 실정에 맞지 않는 무리한 애자일 프로세스를 도입하는 경우가 많습니다.
애자일에 적합하지 않은 한국의 IT 시장 환경
애자일의 핵심 개념 중 하나는 고객의 요구사항을 언제든지 수용한다입니다. 잠깐 애자일 헌장의 내용을 볼까요.
애자일 소프트웨어 개발 원칙 12 중
2. Welcome Changing requirements, even late in development, Agile processes harness change for the customer`s competitive advenage.
(제품 경쟁력을 위해 개발 막바지라도 요구사항 변경을 수용한다)
많은 클라이언트들이 "요구사항을 언제든지 수용한다"라는 것을 무기로 활용합니다. 일단 만들어보고 아니다 싶으면 요구사항을 바꾸거나 결정된 요구사항을 손바닥 뒤집듯 변경합니다. 그리고 PM입장에서는 이런 상황이 큰 리스크가 됩니다. 요구사항을 어느정도 파악해야 인력투입이나 예산을 결정할 수 있는데 요구사항 파악이 안되면 PM은 예산 운용의 불확실성을 안게 되니까요.
국내에서 대부분의 IT 프로젝트들이 확정 고정가계약(FFP) 방식을 사용합니다. 천원을 줄테니 내가 원하는 기능을 책임지고 만들 수 있은 사람 손! 같은 방식이죠. 확정 고정가계약에서 애자일 프로세스를 도입한다는건 붕어빵 장수에게 내일 천원을 주고 붕어빵을 살 건데 배고픔 정도를 봐서 4개를 달라고 할 수도 있고 5개를 달라고 할 수도 있어라는 말과 같습니다. PM입장에서는 요구사항 증가나 변경에 따른 원가 초과의 위험성을 안게 되는거죠.
애자일 방식의 용역 계약에서 추천하는 조달 방식은 시간자재계약(time and materials contracts) 방식입니다. 인원의 투입시간에 따라 실비를 지급하는 방식이죠. 시간자재계약은 주로 건축업체나 제조업에서 많이 사용하는 방식(건설 하청업체가 노동자를 투입 후 인원수만큼 일당을 받는 방식)인데 국내 IT에서는 다소 낯선 계약방식입니다. IT 업계의 경쟁이 워낙 치열하다보니 단가 후려치기를 해서라도 프로젝트를 따내려는 영세한 업체들이 많기 때문이죠.
클라이언트가 "자 이번에는 애자일 프로세스를 일부 도입해서 진행해보려고 합니다"라고 했을 때 수행사에서 "프로젝트의 불확실성이 높으니 시간자재계약으로 조달해주세요"라고 했다가는 고객사에서 "응 너네 말고도 고정가 계약으로 할 회사 많으니까 껒여"라고 말할 확률이 높습니다. 천에 하나 클라이언트 담당자가 착한놈이라 계약방식을 변경해주려고 해도 이미 예산이 정해져 있기 때문에 계약을 변경하기 어려운 경우가 대다수죠.
이 문제를 해결하는 방법은 공공에서 나서는 수밖에 없습니다. 공공에서 애자일 프로세스 도입 시 시간자재계약이나 실비정산을 해주는거죠. 공공에서 나서서 시장 풍토를 개선하면 민간기업도 자연스럽게 따라오게 될테니까요. 미국에서는 고정가 계약, 원가 정산 계약, 시간 자재 계약 3가지 조달방식을 채택하고 있는것에 비해 한국에서는 확정 계약과 일부 원가 정산 계약을 사용하고 있습니다. 법 재정이 우선시 되어야 하는데 소프트웨어 분리발주도 법 통과되는데 한세월이 걸렸는데 조달 방식 개선이 빨리 될까요?
결국은 사람의 문제
애자일 도입에는 많은 인내심이 필요합니다. 교육이라던가 환경개선에 많은 돈이 필요하고 정착되는데도 최소 1년은 필요하죠. 정착됐다고 해도 단시간에 생산성이 향상된다거나 직원들이 주인의식을 가지지는 않습니다. 주인의식은 조직의 문제가 아니라 사람의 문제니까요.
애자일의 청사진만을 쫓았던 사장님들은 당황하기 시작합니다. 전보다 나아지기는커녕 문제점들이 더 심해지니까요. 문제의 근본 원인을 해결하지 않고 애자일만 도입하면 문제가 해결될 거라는 나이브한 생각으로 애자일을 도입하는데 잘될리가 있나요. 회사의 문제는 시스템이 아니라 사람인 경우가 더 많습니다. 사람을 바꾸지 않고 시스템만 바꾸는건 호박에 줄 긋는다고 수박이 되지 않는 것과 같습니다.
마치며
3번째 애자일 전환을 시작할 시점에 저는 애자일 전환이 실패할 것을 어느정도 예상했습니다.
사장님이 보여준 어느 글 때문이었죠.
사장님 : 서점아 내가 어떤 글을 봤는데 애자일로 전환하면 동기부여가 높아지고 자기조직화가 되면서 생산성이 높아진데
사장님이 보여주신 글은 해외 아티클을 번역한 애자일 찬양글이었습니다. 실무 경험도 그것을 해석할 능력도 없는 사이버 번역 레카들이 양산해 낸 그 글은 온갖 미사여구로 애자일의 장점만을 강조한 찬양글이었고 사장님은 필터 없이 그 글을 수용하면서 애자일을 도입하면 이뤄질 자기 조직화와 생산성 향상의 꿈에 부풀어있었죠.
결과는 뭐 따로 말하지 않겠습니다.
애자일 방법론이 무조건 만능인 것은 아닙니다. 하지만 현장에서는 애자일이 만능인양 찬양하고 폭포수 모델은 낡은 방식인양 무시하는 풍토가 만연합니다.
저는 이런 풍토를 자료에 대한 충분한 분석 없이 애자일 찬양글을 신나게 퍼나르는 사이버 번역 레카들과 미제라면 그저 좋다고 무분별하게 받아들이는 사람들이 만들어내고 있다고 생각합니다. 애자일 도입 전에는 꼭 한번 생각해봤으면 좋겠습니다. 우리가 수평적 조직문화가 가능한 환경일지 우리가 진행하는 프로젝트가 애자일에 적합한 환경일지. 나는 애자일 전환의 시행착오를 감내할 수 있는 사람일지...
저는 이제 4번째 애자일 전환을 준비합니다. 이번에는 꼭 성공했으면 좋겠네요.
