지난번 글(새로운 툴을 대하는 자세)에서도 언급했듯, 나는 조직에 많은 툴들을 전파해보았다(혹은 전파하려 하였다). 그 중 규모면에서나 영향력면에서나 가장 큰 툴은 바로 Rational Team Concert (RTC) 일 것이다. 내가 접해본 툴들 중 가장 마음에 드는 툴이기도 하다. 그런 이유로 수년간에 걸쳐, 다양한 방법으로 팀원들을 끌어들이려 노력해보고, 한 때 좋은 분위기로 흘러가기도 했지만.. 현 시점에서 결론을 내려보면 ‘완전 실패’다. 자.. 이제부터 내가 느낀 실패 원인을 살짝 정리해보겠다.
자잘한 원인들을 모두 나열하자면 한도 끝도 없을테고 초점도 흐려질듯하니 생략하고, 내가 생각하는 가장 근본적인 원인만 다루려 한다. 바로 (주로 유교의 영향이 컸을 듯한) ‘수직적 문화’이다.
우리 문화는 서열을 중시한다. 조직에서의 서열은 이렇게 매겨진다.
이 서열을 뛰어넘기란 여간 어려운 게 아니다. 아무리 능력이 좋아도 직급이 더 높은 사람을 부릴 수 없으며, 심지어 같은 직급과 같은 연차라도 나이가 한 살이라도 더 많은 사람을 밑에 두기란 쉽지 않다. 여러 가지 예가 있다.
특히 직급은 우리 조직 시스템에서 너무도 중요한 축을 담당한다. 말단 사원을 제외하고는 모든 사람들을 호칭할 때 직급을 붙여준다. 대부분은 때되면 붙여주는 직급이지만, 이를 생략하고 불렀다간 관계가 소원해질 것을 각오해야 한다. ^^;
굳이 회사에서만 예를 찾으려할 필요도 없다.
불행히도 이런 문화는 우리가 쓰는 언어에 의해 아주 어렸을 때부터, 거의 언어를 배우기 시작하면서부터 주입된다. 한 살이라도 많으면 형, 누나, 오빠, 언니가 되고 그들에게는 말을 높이라고 교육받는다. 윗사람을 공경하는 문화야 칭송되기도 하고, 그리 나쁘지는 않은 문화라 생각한다. 다만 아쉬운 것은 단순히 나이 많은 이에 대한 어휘와, 정말 존경이나 높은 사람에 대한 예우로써 쓰는 어휘에 차이가 없다는 점이다. 즉, 우리는 존경과 나이 많음을 명확하게 구분짓지 않기 때문에 알게모르게 이 둘을 동일시 시킨다. 언어가 인간의 사고를 지배하기 때문이다. 초등학생만 되어도 선배는 후배에게 일을 시키고, 후배는 선배의 명령을 따르는 것이 몸에 익어버린다. 갑으로써 누릴 수 있는 힘과 을로써의 자세를 사회 관계를 처음 쌓게 되면서부터 체득하게 된다. 그리고 성인이 될 때까지 단 한 번도 이에서 벗어난 문화를 경험하지 못하고 성장한다. (채벌에 관대하게 된 데에도 많은 영향을 미쳤으리라 믿는다.)
이렇게 우리는 협동과 협업보다는 명령 하달과 수행 체제에 적합하게 훈련되었다. 평등한 관계 속에서 협업이 중시되는 사회에서는 뛰어난 리더가 중심이 되지만, 명령과 수행에 의해 움직이는 사회에서는 냉철한 관리자가 더 중요해진다.
이쯤에서 RTC를 잠시 살펴보자. 툴에는 툴 설계자의 노하우와 철학이 담겨있다.그럼 RTC 설계를 주도한 에릭 감마는 어떤 생각을 가지고 이 툴을 만들었을까. 이런저런 이야기를 하고 있지만, 핵심은 효율적인 협업과 투명성이다. 관리와 통제가 아닌 것이다.
우리 사회도 물론 협업과 투명성을 강조하지만, 평등한 관계에서의 협업/투명성과 수직적 관계에서의 그 의미는 완전히 달라진다. 후자에서의 협업은 같은 등급의 사람들끼리 잘 협동하고, 높은 사람의 말을 잘 따르는 것이다. 투명성은 높은 위치의 사람이 낮은 위치의 사람이 땡땡이 치지 못하게 잘 감시할 수 있는 일방적인 하향 투명성을 뜻한다. 협업은 그렇다 쳐도.. 투명성에 대해서는 실무자쪽에서 더욱 방어적으로 나오는 이유가 되기도 한다. 갑은 을을 마음대로 부릴 수 있음을 어려서부터 익히 배워왔기 때문에, 을은 갑으로부터 최대한 자신을 보호하고 싶어한다. 상향 투명성은 생각하기도 힘들고, 동급의 실무자들간 투명성도 그리 환영받지 못한다. 아랫 사람은 위에서 내린 명령만 잘 수행하면 되는 것이고, 그것이 어떻게 조합되어 전체를 만드는지는 윗사람이 생각할 문제이다. 또한 피지배 계층이 너무 많은 정보를 가지고 있다면 지배하기기 쉽지 않다. 과거 평민 이하에겐 교육을 시키지 않은 이유와 같다. 예를 들어, 지금까지의 과제 진척률이 고스란히 공개된다면 단순 채찍질용 일정 단축 요청 같은 것은 의도한 효과를 발휘하기 어렵다.
몇 년 전, 우리의 행태를 비판하며 프로젝트 투명성에 대한 생각도 끄적여 봤었지만, 하루 아침에 변화시키엔 수직적 문화의 뿌리는 우리 사회에 너무 깊게까지 내려 있다. 나이 차이가 수십년 이상 되는 사람들이 모여 있는 거대 조직에서는 말도 안되는 이상향일 지도 모르겠다.
이런 이질적인 동서양 문화에서 파생되는 또 하나의 심각한 문제는 바로 실무자로써의 생명이 짧다는 점이다.
일반적으로 사원으로 입사했다면 8년쯤 후, 박사로 입사했다면 거의 곧바로 관리자의 역할을 맡게된다. 편차가 심하긴 하지만 평균은 대략 이와 비슷할 것이다. 심지어 대규모 플랫폼을 개발하는 팀에서조차, 능력있는 고참 실무자를 아키텍트로 키워보려 면담을 해보면 ‘저도 이제 관리를 익혀야지요’하는 반응이 많다는 이야기도 들었다.
그런데 이것이 수직적 문화와 무슨 관련이 있단 말인가? 계급이 다르다는 것은 (암묵적으로) 하는 일이 다르다는 뜻이다. 승진을 했음에도 하는 일은 과거와 똑같다면 스스로도 실망스럽고, 주변의 위로 소리가 어색하지 않게 느껴진다. 실무 능력이 아무리 뛰어나도 관리 능력이 미달되면 그는 우리 사회에서 도태되기 쉽다.
이와 달리, 수평적 사회에서는 하는 일의 차이보다는 능력의 차이가 보다 중시된다. 조직을 이끄는데 있어 관리는 물론 중요하지만, 직급이 높으면 관리를 해야한다는 인식보다는 개개인이 가장 잘 할 수 있는 일을 하는 것이 올바르다 생각한다. 관리는 직급의 구분 기준보다는 역할이 다른 것으로 인식된다.
그래서 다시.. RTC와 무슨 상관인가? 관리자 입장에서 생각해보자.
기타 등등.. 관리자 입장에서는 전문 개발 툴에 통합된 RTC의 인터페이는 불필요한 기능들로 가득차있고 복잡하고 무겁다. 관리를 잘 하기 위해서는, 스스로 툴을 조작하며 이러저런 상세 정보 속에서 헤매이기보다는, 핵심 정보들만 빨리 캐취해서 적시에 올바른 의사 결정을 내리는 것이 훨씬 중요하다. 즉, RTC는 이런 문화에 속한 관리자를 위한 툴이 아니다.
그렇다면 개발자에게는 좋은가..
이렇듯, 개발자 입장에서도 그리 매력적이라 보기는 힘들다는 생각에 이르렀다. 결국 우리 사회 구성원 누구에게도 딱 맞지 않은.. 먼 나라의 툴이 되어버린 것이다.
물론 우리 사회도 조금씩 변해가고 있다. 요즘의 젊은 벤쳐 기업이나 열린 마음의 사람들로 구성된 작은 팀에서는 RTC가 진정한 힘을 발휘하기에 충분한 문화를 만들 수도 있을 것이다. 그리고 점점 더 상황은 나아질 것이라 믿어 의심치 않는다. 하지만 똑같은 수준에서, 몇 년 내에 급격한 개선이 있을 것이라고는 절대 생각하지 않는다. 조직 문화를 성공적으로 혁신시키려면, 조직 구성원들 대부분이 그 필요성을 마음속 깊이 공유한 상태여야 한다. 그렇지 못한 상태에서 무리하게 추진한다면 모난 돌 취급을 받게 되거나, (추진자가 높은 사람이라면) 마지못해 하는 척만 하다가 머지 않아 원상복귀된다. 혹은 형식만 남아 안함만 못한 상태가 되어버린다.
RTC와 같이 프로젝트 개발 과정 전반을 아루르며 팀 구성원 모두가 써야하는 툴을 온전히 도입하는 것은, 팀 문화 전반을 바꾸려는 시도와 같다. 개인적으로 마음에 들더라도, 팀 차원에서의 적용을 시도하려면 분위기와 팀원들의 성향을 잘 판단해서 추진하기 바란다. 우리팀은 지금 50명 이상이 RTC를 사용하는 듯 싶지만, 에릭 감마가 의도한 방식대로 사용하는 사람도 거의 없을 뿐더러, 관리자쯤 되면 쓰는 사람을 손에 뽑고, 매뉴얼/검색/옆사람을 통해 쉽게 해결할 수 있는 사소한 것들로도 수시로 (전파자인) 나를 찾아 귀찮게 하는 상황이다. ^^;;
가볍게 소개해보고 분위기를 살펴보는 것으로 시작하는 것은 나쁘지 않은 방법일 것이다. 단, 몇 마디 긍정적인 피드백만으로 너무 쉽게 총대를 둘러매진 말길 바란다. ^^
(updated: 내가 이런 글을 적은 이유 중 하나는, 이런 문화적 차이를 미리 알고 충분히 고려해서 적용을 시도해보는 것과, 무턱대고 밀어붙이는 것에는 분명 큰 차이가 있을 거라 믿기 때문이다. 뭐든 내맘에 든다고 다른 사람 맘에도 들거란 생각은 위험하지만, 만약 이 툴이 정말 마음에 든다면, 당신은 주변 사람들과는 다른 사상을 가지고 있을 확률이 많을 것이다. ^^ 실패하더라도 남 탓하지 말고, 사회 탓도 하지 말기 바란다. 이 시스템은 또 이 시스템 만의 장점이 있다. 적응을 해보던지, 정 맞지 않다면 일찌감치 다른 조직을 찾아 모험을 떠나보는 것도..^^)
‘쉬어가기.. 혁신을 이끌어내는 방법 [1]‘ 에서는 개발자들에게 쉬어갈 수 있는 시간을 제공함으로써 창의와 혁신을 이끌어는내는 이야기를 해보았다. 이번에는 ‘직접보기’라는 주제로 비슷한 이야기를 해보려 한다.
‘직접보기’ 가 필요한 이유는 아래의 그림을 보고 생각해보자. 이 그림이 말하고자 하는 원목적은 완전히 동일하진 않지만, 실물을 보지 않고 커뮤니케이션 했을 때의 문제를 효과적으로 말해주고 있다.
정리하면 고객이 원하는 것을 각 사람/조직마다 다르게 이해하고 있으며 심지어 고객 스스로도 자신이 무엇을 필요로 하는지 알지 못한다 것이다.
시장 조사를 토대로 고객의 needs 를 모두 만족시킨 제품의 출시 후 반응이 그리 좋지 않은 수많은 사례들을 잘 설명할 수 있는 논리이기도 하다.
혁신적인 제품을 잘 만들어내기로 유명한 애플(Apple)사의 경우, 신제품을 만들 때 시장 조사를 아얘 하지 않는 것으로도 유명하다(You Can’t Innovate Like Apple [2]). 시장에 존재하지 않는 제품에 대해 물어봐야 가치 있는 대답을 구하기 어렵기 때문이다. 대신 스스로 계속해서 실제품 수준의 프로토타입을 수없이 만들어보면서 직접 만져보고 써보며 자신들이 정말 이 제품을 원하는가를 판단한다. 그 결과 애플의 제품들은 종종 시장에서 당연히 필요하다고 생각하는 기능이 빠지기도 하고 이미 더 나은 제품들이 수두룩한데~ 라고 평가절하되곤 한다.
이미 만들어진 제품에 대해서는 다르다. 직접 사용해본 사용자들의 피드백은 소중하다. 애플 리테일 스토어가 중요한 역할을 수행하는데, 리테일 스토어의 직원들은 고객이 와서 들려준 이야기들을 놓치지 않고 본사로 보고하게 되어 있다. 그래서 스티브 잡스는 아이디어 도둑(유명 마케터 이해선 대표의 메시지 [3])이라는 말이 나오기까지 했다.
고객의 소리를 듣는 방식에 있어 두 경우가 다르다고 이야기했지만, 사실 그 원리는 동일하다. 바로 제품을 직접 만져보고 사용해본 사람들의 소리를 듣는다는 것이다.
이는 사실 애자일, 전통 할 것 없이 거의 모든 소프트웨어 개발 방법론에 중요하게 다루는 주제이고, 결론 또한 항시 동일하다. 짧은 반복 주기로 매 주기마다 동작 가능한 제품을 내놓고, 이를 고객에게 보여주고 피드백을 받는다. ‘당신이 말한 것을 우리는 이렇게 이해했는데, 이것이 정말 당신이 원했던 것이오?’ 를 확인하는 가장 중요한 절차인 것이다. 진정 공존을 원한다면 이 과정에서 쓸데없는 과장과 화려한 프리젠테이션은 없어져야 한다. 그리고 프로젝트 진행에 관련된 주요 인력들이 다 참석하는 것이 좋다. 고객, 프로젝트 리더, 영업 담당자, 주요 개발자들 등이 포함된다. 이들이 자주 모여 현실을 냉정하게 보고 허물없는 이야기를 하다보면 다음과 같은 반응들을 심심치 않게 목격할 수 있을 것이다.
직접 보기는 서로의 생각을 확인하고 공유할 수 있는 가장 좋은 방법이며, 다음 방향을 결정짓기 위한 논의를 시작하기 위한 믿음직한 베이스가 되어준다.
또한 개발자들에게는 자신들의 창의력과 열정을 어필할 수 있는 절호의 기회가 되기도 한다. 직접 구현하면서 가장 먼저 써보게 되는 개발자들은 가장 빠르게 피드백을 줄 수 있는 훌륭한 고객인 셈이다. 이해한 요구사항대로 구현했을 시 불편한 부분이 있거나 더 나은 안이 떠오르면 릴리즈 전에 그 아이디어를 정리해두자. 가능하다면 직접 구현해서 보여주는 것이 가장 좋다. 직접 사용해본 고객과 말이나 문서 정도로만 본 고객은 확연히 다른 반응을 보인다.
이런식으로 개발자들의 능력을 인정받고 발언권을 강화해두는 것이 조직 전체의 커뮤니케이션과 생산성 향상, 제품 혁신에 긍정적인 영향을 줄 것이다. 개발자들은 기본적으로 창의적인 인력들이며, 이에 더해 현실적이다. Sci-fi 영화에나 나올 법한 허무 맹랑한 꿈을 꾸지도 않고, 일부러 과장하려는 경향도 적다. 먼 과거와 달리 골방의 괴짜들이 모여 있는 집단도 아니다. 윗사람들보다 신세대이며 소비의 주체라는 장점도 있다.
결론?
조직은 제품을 직접 보고 함께 이야기하는 문화를 정착시킴으로써 많은 것을 얻을 수 있다. 단, 어설프게 릴리즈 압박용으로만 오용하지 않도록 주의하자. 상향식 변화는 실패할 것이며, 하향식 변화는 성공한 것 처럼 보일 것이다. ^^ [4]
[updated]
사례를 몇 가지 추가해보기로 하였다.
어제는 오랫만에 깨어 있는 SE 전공자를 만났다. 여러 화두들 중 일전에 포스팅한 [나쁜 팀 문화] 점진적 지연 [1] 에 관한 이야기가 나왔고, 그분은 재미난 해결책 하나를 말씀해 주셨다.
먼저.. ‘점진적 지연’이란 현상적으로 보면 주요 마일스톤 일정을 막바지에 조금씩’만’ 뒤로 미루며 결국 긴 기간동안 지연되는 것이다. 어쩔 수 없이 나타나는 현상이라면, 그리고 이를 문제로 인식하고 해결하려고 하는 조직이라면 미래가 있다. 하지만 내가 보아온 많은 조직에서는 관리자들이 의도적으로 이런 정책을 편다.
그들은 ‘9월에 끝날 거 같은 과제라면 6월에 끝내라고 해야 그나마 9월에 끝이 난다’라고 말한다. 그들 믿음의 기반은 ‘개발자는 일정으로 쪼지 않으면 일을 열심히 하지 않는 게으른 존재’ 라는 것이다. 그러면서 이게 노하우이고 자신이 팀을 잘 이끌고 있다고 믿는다.
노동 집약적 산업 시대의 잔재인 듯한 이런 시도는 신입사원처럼 아직 조직에 적응하지 못한 사람이나 선천적인 워커홀릭 정도에게나 효과를 보인다. 워커홀릭은 몸이 부서지거나 삶의 전환이 될만한 계기가 찾아오지 않는한 열심히 일하지만, 신입사원들은 기껏해야 한 두 해면 유효기간 만료이다. 결국 9월이 지나고 10월, 11월이 지나도 끝나지 않는다.
왜 그럴까? 관리자들은 종종 ‘내가 6월이라고 말했지만 사실 난 9월로 예상하고 있어’라는 것을 자신만 알고 있다고 ‘착각’하기 때문이다. ‘당신만 아냐? 나도 안다.’ – 개발자들의 마음속이다. 물론 9월이라고 똑같이 예측하는 사람은 일부, 대부분은 자기 나름의 예상치를 잡거나 아예 관심 없어 한다. 즉, 명목상 한 팀임에도 불구하고 멤버들이 목표에 관심이 없거나 제각각의 기준으로 일에 임하는 것이다. 이런 콩가루 팀과 원래부터 9월을 목표로 하여 멤버들 대다수가 ‘어! 잘하면 될 거 같은데, 한 번 해보자!’라고 뭉쳐진 팀, 둘 중 어느 팀이 빠른 시간 안에 높은 품질의 제품을 내놓을 수 있을까?
해결책?
스스로 제시한 목표치에 훨씬 못미치는 관리자 한 두 명만 본보기로 잘라 버리는 것이다. 마음대로 자를 수 없다면 다른 팀에 전배를 보내거나, 다른 일로 전형시켜버리면 된다. 위화감을 느낀 관리자들은 현실적인 목표를 잡기 위해 혈안이 될 것이다.
배우려는 마음과 변화해보겠다는 의지 없어서 그렇지, 현실적인 목표를 잡는 것은 그리 어려운 일도 아니고, 관리자 혼자 머리 싸매고 미래를 예측해야 하는 일도 아니다. 위의 충격요법은 절박함을 심어주어 마음과 의지를 북돋아줄 것이다. ^^
그럴 일은 없겠지만, 현 팀에서도 한 번쯤 이런 일이 일어났으면 좋겠다. 모두에게 공감대가 형성되고 내게 그만한 권한만 주어진다면 크나큰 변화를 이끌 자신이 있는데 말이다. ^^
참고로, 연구 성격의 과제라 누구도 앞을 예측하기 어려운 경우에는 짧은 iteration 을 돌며 그때 그때의 성취를 공유하는 방법이 가장 좋다.
글을 적으면 생각이 나서 리더 vs. 매니저 [2] 도 업데이트 하였다.
점진적 지연이란 아주 짧은 간격으로 릴리스 날짜를 조금씩 미루는 행태를 뜻한다. 일단 릴리스를 시도해보고, 안되면 조금 (보통 1~3일) 미룬 후 다시 시도한다. 역시 잘 안되면 또 다시 미룬 후 시도한다. 이렇게 릴리스가 될 때까지 무한 반복하는 릴리스 관리 방식이다.
내가 경험해본 최악의 상황은 이러했다. 원래의 릴리스 목표일은 금요일이다. 금요일이 되어서 시도를 해보았으나, 도저히 릴리스할 만큼의 품질이 나오지 않는다. 그래서 월요일로 목표를 바꾼다. 월요일에도 역시 원하는 품질에 도달하지 못했다. 다음날 다시 한 번 시도해보기로 한다. 마찬가지로 실패했다. 이와 늦은거 금요일로 다시 미룬다. 금요일도 여전히 실패.. 토요일.. 월요일.. 수요일.. 금요일.. 월요일.. 화요일.. 토요일.. ..
이런 식으로 가장 길게는 6주간 계속 릴리스만 한 경우도 있었다. 릴리스가 이렇게 한달 가량 지연되면 당연히 다음 릴리스에 일정에 지장을 주게 된다. 새로운 기능을 추가하는데 필요한 최소 시간이 있으므로 차례차례로 전체 일정이 연기된다. 하지만 다음 릴리스 시점에 와서도 크게 다르지 않다. 역시 또 몇 주의 지연이 발생한다. 그래서 ‘릴리스가 끝나면 (다음) 릴리스 일정이 바뀐다’, ‘릴리스가 되는 날이 릴리스 날이다 (역: 릴리스 날에 릴리스를 한다)’ 라는 말까지 하게 되었다.
위의 경우는 continuous integration (CI) 도 도입되지 않은 열악한 환경에서의 상황이었고(도입을 요구했지만 관심 갖는 사람이 없었음), 그 후 CI 가 도입되면서 상황은 많이 호전되었다. 하지만 여전히 제 때 릴리스 되는 경우는 전무했고.. 심한 경우 3주가 밀리기도 했다. 금요일 릴리스를 (주말을 열심히 일해서) 그 다음주 월요일 저녁에 할 수 있다면 대단히 이례적인 성공이 케이스가 될 정도였다.
Incremental Delay 가 팀 문화처럼 정착되면서 다음과 같은 부작용들이 나타나기 시작했다.
팀원들은 윗선에서 정한 릴리스 날짜(deadline)에 큰 의미를 부여하지 않게 되었다. 한 차례도 성공적으로 릴리스한 경험이 없으며, 릴리스가 연기되어도 아무 일도 발생하지 않음이 학습되었기 때문이다. 꼭 지켜져야하는 중요한 릴리스라 강조해도 마음속으론 ‘어짜피 안될걸..’이란 생각을 자연스레 하게된다.
서브팀별 개발 일정이 꼬이기 시작한다. 팀별로 이터레이션(iteration) 주어진 일의 양이나 생산성, 예측 정확성 등의 차이가 생겨 발생하는 현상으로.. 일부 팀은 일정에 맞춰 일을 끝내놓고 다음 릴리스를 위해 할 일을 준비하고 있다. 하지만 곧 될 듯 말 듯 하면서 릴리스는 기약없이 지연된다. 처음엔 2~3일 후면 될 거라 기대하고 잠시 쉬던 것이 하루 이틀씩 밀리면서 결국 이 주 삼 주 동안 제대로 진행할 수 없게 된다. 이런 경험이 잦아지면서 일부에선 중간중간에 변경된 코드를 밀어 넣는다. 다음 릴리스를 위한 개발 코드 브랜치와 (지연중인) 릴리스 브랜치 간에 코드 격차가 심해져, 개발 브랜치에서 해결된 문제를 릴리스 브랜치에 반영하는데 한참을 씨름하기도 한다.
윗선도 계속되는 릴리스 관련회의로 시간을 낭비하기는 마찬가지다. 현황을 파악하고, 얼마나 더 지연시킬 지 정하고, 지연이 미치는 영향을 분석하고, 이왕 지연된 것 미리 구현된 간단한 기능을 포함시킬 지 논의하고.. 자료를 준비해 더 윗선이나 마케팅, 기획, 운영(예산) 팀 등과도 계속 조율을 해야 한다. 야근과 주말 근무가 늘어난다. 일주일 단위로만 지연시켜도 호흡 조절과 재충전이 가능하겠으나, 지연 단위가 보통 1~3일 정도이고, 특히나 금요일 일정은 반드시 토/일/월로 지연된다.
무엇하나 좋을 게 없는 이런 비합리적 문화가 왜 개선되지 않는 것일까?
이런 현상이 반복되고 있음은 윗선에서 과제가 어떻게 돌아가고 있는지 전혀 파악하지 못하고 있다는 확실한 반증이다. 릴리스를 하기 위해 해야할 일이 얼마만큼 남아 있는지 도통 감이 없다. 개발자들의 생산성과 문제 해결능력에 대한 어떠한 정량적/경험적 데이터도 갖춰져 있지 못하다. 개발자 각각이 지금 무슨 일들로 얼만큼의 로드가 걸려있는지도 잘 파악이 안되고 있다. 해결해야할 문제들이 얼마만큼의 노력이 들어가야 하는지도 역시 감이 없다. 아직 드러나지 않은 문제들은 또 얼마나 될 지 역시 예상하기 어렵다. 결국 위에서 할 수 있는 말은 보통 ‘언제까지 이 문제들을 해결해라’ 정도에서 그친다.
제품의 설계나 코드의 품질이 크게 떨어지거나, 다뤄야할 대상을 개발자들의 완벽하게 이해하지 못하고 있을 경우 사태는 더 심각해진다. 분석하고 수정하는데 필요한 시간을 예측하기 힘들고, 수정시 부작용(side-effect)이 따를 가능성이 높다. 동작 여부만이 아니라 코드의 품질을 챙기는 개발 문화를 조성해야 하고, 서로 간의 잦은 리뷰를 통해 다른 팀원들과 개발 패턴, 노하우 등을 공유해야 한다.
관련 개발팀간 커뮤니케이션 효율성도 큰 영향을 미친다. 심한 경우는 핵심 모듈을 전혀 다른 팀에서 관리하고 있고, 우리 과제를 지원하는 것은 그 팀의 최우선 역할이 아닐 때이다(실제로 자주 접해보았다). 유관 팀들이 지리적으로 멀리 떨어져 있고, 원격지에선 문제를 재현하기 어려울 때도 마찬가지.. 어떠한 경우건 커뮤니케이션 지연은 일의 진행 속도를 현저히 떨어뜨리는 주요 원인이 된다. 과제를 기획하고 팀을 조직할 때 그 과제와 팀이 적시에 충분한 지원을 받을 수 있도록 고려해야 한다. 필요하다면 조직 구성을 바꿔 같은 명령 계통 내로 흡수할 필요도 있다.
미흡한 인프라에 의한 불확실성도 크다. 기본적인 테스트 자동화 시스템도 갖추지 못해 매번 개발자들이 수동으로 테스트하는 것도 많이 보아왔다. 나름 도입한 continuous integration 이 기껏 빌드만 해주고 기본적인 unit test 도 수행하지 못한는 경우를 상상해보자. 내가 경험한 어떤 팀은 unit test 를 CI 에 통합해달라는 요청을 한 지 1년이 넘도록 반영하지 못했다. 다른 자동화는 물론 말할 것도 없었다. 과제 규모가 커질 수록 그에 걸맞게 인프라 효율성에도 투자를 해야한다. 발등에 떨어진 일정에만 쫒겨 제때 투자를 못하면 일을 해야할 정작 개발자들의 시간을 어먼 곳에 낭비하게 만든다.
개발 문화와 생산성 향상, 효율성, 팀웍에 대한 인식이 부족하다. 위에서 가장 중요시 하는 것은 언제 릴리스 되는가이다. 어떤 때는 그것 외에는 전혀 관심이 없는 것 같다는 인상을 받곤 한다. 일벌레인 사람들이 지배하는 조직에서 더 심한 경향이 있는 것 같다. 종종 일찍 퇴근하고 싶어하는 사람을 이해하지 못하는 듯한 발언을 듣기도 한다. 아무래도 사람은 자신의 기준에서 남을 이해하는 성향이 있으니, 어찌보면 당연한 것일 수 있다. 하지만 사람(뿐 아니라 모든 생물)은 기계와 달리 충분한 휴식 없이는 높은 집중력과 생산성을 유지할 수 없음을 주지시켜야 한다.
[나쁜 팀 문화] 시리즈.. 두 번째..
As Many Tasks As Possible in Parallel (AMTAPP) 는 문장 그대로 가능한 많은 태스크들을 동시에 진행시키는 프로젝트 관리 방식을 말한다. 훌륭한 프로젝트 관리 가이드와는 전면으로 배치되는 정책으로, 특히 Kanban [1][2] 에서는 철저히 경계하고 있다.
이 방식은 현재 내가 속한 팀뿐 아니라 우리 회사의 전형적인 프로젝트 관리 방식이다. 프로젝트가 이렇게 진행될 수 밖에 없는 원인을 몇 년간의 경험을 토대로 유추해 보았다.
그 외에도 나열하면 끝이 없겠으나.. 간략히 두 가지로 요약해보면.. 역량 이상의 일을 따냈고, 그래도 다 하고 있음을 강조해야 해야 한다. 결과적으로, 일할 사람 수보다 당장 해야할 태스크 수가 더 많은 상황에 처한다. 하나의 태스크에 둘 이상이 달라붙는 것은 사치스러운 짓이다.
그럼 AMTAPP 방식의 폐단은 무엇일까?
가장 큰 문제로 개발자 간의 의사소통이 단절을 뽑겠다. 내가 하는 일과 옆의 팀원이 하는 일은 관계가 거의 없다. 풀어야할 문제가 다르고 서로 코드를 봐줄 일도 없다. 어려움에 봉착해도 상의할 사람도 없고, 일부러건 몰라서건 대충 만들어 놓아도 당작 동작만 하면 아무도 알지 못한다. 겉으로 잘 드러나지 않는 품질이야 어떻든, 동작만 하면 관리자는 만족해한다. 또한 노하우가 공유되지 않아, 못하는 사람은 계속 못하고, 잘하는 사람의 발전도 더디다.
다음으로는 집중력 저하를 들겠다. 소프트웨어는 순전히 개발자의 사고에 의해 만들어지는지라, 소프트웨어 개발직은 다른 무엇과 비교해서도 고도의 집중력을 가장 요하는 직업 중 하나이다. 불행히도 신은 사람의 두뇌를 멀티 태스킹용으로 설계하지 않았다. 동시에 두 가지 이상을 생각하는 것은 어림도 없고, 심지어 하나 하나 번갈아 처리하는 능력 역시 상당히 떨어진다. 일을 바꿔 집중력 끌어 올리기까지는 수분에서 십수분 이상이 필요하다 – 정확한 수치를 Peopleware [4] 에서 본 듯 하나, 지금은찾아보기 귀찮다
하이라이트는 다른 사람들의 태스크를 만들어내는 태스크를 할당받은 사람들이다. 이들이 일을 열심히 할 수록 다른 팀원들 수십명의 일거리가 눈더미 처럼 불어나 버린다. 코딩하고 결함 잡기도 벅찬 와중에, 문서 고쳐라, 새로운 툴체인 적용해라, 디렉토리 구조 바꿔라, 여기 새 이디엄이 있으니 적용해라, 방금 나온 따끈따끈한 바이너리 당장 테스트해서 보고해라, 보고용 자료 좀 준비해와라, 이것 보고 커맨트 좀 달라 등등 수많은 요청이 쏟아진다. 프로젝트를 이런 식으로 이끌면서 품질은 개발자의 자존심이니 하는 이야기가 나오면 울컥하지 않을 수 없다.
나는 대기업에서도 상당히 큰 규모의 과제에 몸담고 있다. 연관된 내/외부 팀원만 하더라도 족히 5백은 넘을 듯 하고, 그 중 직간접적으로 내 영향력이 미치는 범위는 백여명 정도 될 듯 싶다. 이런 규모의 과제를 진행하다보니 프로젝트 투명성의 중요성이 더욱 크게 느껴진다.
여기서의 프로젝트 투명성이란 프로젝트 계획, 세부 태스크, 진척도, 히스토리, 위험 요소, 가용 자원 현황 등 프로젝트 진행과 관련된 중요 정보들에 관련자들이 실시간으로 얼마나 쉽고 정확하게 접근할 수 있는가를 말한다.
우리팀의 수직적 계층을 대략적으로 구분해보면 ‘개발자, 중간 관리자, 상위 관리자, 경영진’ 정도로 나뉘는 듯 하다. 수평적으로는 협력 팀과 경쟁 팀이 있고, 경쟁 팀들의 수직적 구조는 우리 팀과 대동소이하다. 이러한 거대 조직에서 프로젝트 투명성을 제대로 지원해주는 어떠한 인프라도 갖춰져 있지 않다면 어떤 현상이 벌어질까? 우리의 예를 일반화시켜 적어보겠다.
실시간 정보 공유가 어려우므로, 개발자는 중간 관리자에게 한 주 정도 간격으로 진행 상황을 보고한다. 하지만 이 때 기입되는 태스크들의 의미를 전체 프로젝트의 관점과 연관시켜주는 인프라가 없다. 무언가 많은 일들이 진행되고 있는 것은 같으나 그것의 의미는 잡아내기 쉽지 않다. 중요하지 않거나 계획에도 없던 일에 과도한 시간을 투자하거나, 반대로 아주 시급한 일과 직결된 이슈 사항이 주목 받지 못하고 묻혀버리는 일이 허다하다. 진도가 계획 대비 얼마나 충실히 나아가고 있는지, 그래서 예정된 마일스톤에 납기가 가능할 지와 같은 정작 중요한 정보는 거의 포함되지 못한다.
중간 관리자와 상위 관리자도 보통 주 단위의 미팅을 갖는다. 개발자들로부터 받은 보고를 정리해서 공유하고 전체 일정 대비 점검하거나 큰 이슈들에 대한 논의가 주로 이루어진다. 개발자의 보고 내용이 필터링 되는 것은 오히려 작은 문제이고.. 더 큰 우려 사항은 앞서 이야기한 ‘중요한 정보를 얼마나 잘 캐취해 냈는가’이다. 중간 관리자가 이 일을 제대로 처리하지 못한다면, 중요치 않은 일이 부각되고 그 후속 조치로써 더 중요한 일에 투입할 시간마져 갉아먹게 된다.
이 단계에서의 또 하나의 심각한 문제는, 가용 리소스와 각 태스크별 요구되는 리소스량에 대한 신뢰할 만한 데이터 없이 매니저들의 감과 욕심(혹은 바람)에 의존해 일이 계획된다는 점이다. 실무자가 보기엔 현재 할당된 일만으로도 일정 지연이 뻔한 상황에서도 새로운 태스크들이 추가된다. 요구 일정에 맞추려면 실무자는 결국 대충 진행할 수 밖에 없다. 그 때 그 때 지뢰를 하나씩 매설해놓고, 제품은 점차 건드리기조처 겁이 나는 지뢰밭이 되어 간다. 심지어 기존 기능을 변경할 시에도 감히 현 코드를 수정하지 못하고 편접적인 방법으로 살짝 덧씌운다.
상위 관리자는 협력 팀이나 경영진들과 미팅을 갖고, 그 주기나 형태는 어떤 주제로 누구와 맞나느냐에 따라 달라진다. 이전까지의 논의가 주로 기술과 일정에 대한 것이었다면, 이제부터는 기술은 쏙 빠지고 비즈니스 임팩트와 내/외부 경쟁에 대한 것들에 초점이 맞춰진다. 빠르게 변하는 시장 상황에 따라 과제 방향이 확 틀어질 수도 있고, 경쟁에서 너무 밀릴 것 같으면 생존 자체가 위협을 받는다. 이런 상황이 상급 관리자들을 방어적으로 만든다. 거짓말이 되지 않도록 신경쓰면서 문제를 최대한 숨기고, 작은 장점을 크게 부풀리고, 묘한 가정을 설정하거나 자신들에게 유리한 데이터를 추려 인용한다. 예를 들면, 여러가지 임시 방편과 제한된 시나리오로 간신히 데모 정도 돌리는 수준에서 마치 다 마무리 되어가는 듯 보고가 되고, 그 결과 추가적인 일거리가 생기고 과제 규모도 커져버리는 식이다. 추가된 업무에 허락된 리소스는 당연히 지금까지 잘 된(것처럼 보고된) 생산성에 맞춰져 있다. 일을 받는 입장에서 현실적인 리소스를 요구할 수 없는 것이, 앞으로는 자신의 팀원들의 생산성이 훨씬 떨어질 것이라는 납득하기 어려운 주장을 펴거나 현재의 상황을 인실직고해야하기 때문이다. 더욱이 현 문제에 대해 상급 관리자가 파악하고 있는 수준 역시 현실과는 꾀 거리가 있게 마련이다.
결과적으로 부정확한 데이터에 기반해 엄청난 예산을 낭비하고 기회를 놓치게 된다. 그리고 이런 체제에서는 개발자들의 실력도 늘지 않아 경쟁에서 점차 뒤쳐질 수 밖에 없다. 좋은 개발자들은 기회가 되면 조직에서 벗어나려 할 것이다. 그 외의 악순환 얘기까지는 굳이 꺼내지 않아도 될 것 같다.
투명한 프로젝트의 장점 중 가장 중요한 것은 다음 두 가지라고 생각된다.
첫 째, 여러 단계에 걸친 보고 과정에서 낭비되는 고급 인력의 시간을 실무적인 문제 해결로 돌릴 수 있다. 어떤 정보를 공개할 지, 어느 정도로 포장을 해야할 지, 유리한 데이터는 무엇이 있을 지, 경쟁자보다 우월해 보이려면 다소 무리해서라도 어떤 기능을 더 넣어야 할 지 등을 찾고 고심하는대는 생각보다 많은 시간과 노력이 필요하다. 한 구글 직원의 블로그에서는 자신들의 리더는 약 20% 의 리소스만을 관리에 쓰고 나머지는 같이 개발을 한다고 하였다. 반면 비효율적인 기업은 상위 20%의 인력은 관리만 하고 있는 것이 아닌가 싶을 정도이다. 고급 인력 한 사람의 적극적인 참여는 저급 인력 몇 명을 투입하는 것보다 훨씬 나은 효과를 낳는 경우가 많다. 이런 효과는 팀 규모가 커지고 과제가 장기화될 수록 더욱 뚜렷해진다. 과제가 진행되면서 노하우가 전파되고 개발인력들의 역량이 향상된다. 이 문제는 굉장히 심각한 것이.. 실무에서 몇 년을 일한 프로 개발자들 중 아직껏 대학생 수준의 코드를 작성하고 있는 경우가 너무 많이 목격되기 때문이다. 투명성 부여 하나만으로 해결될 일은 아니지만 문제를 부각시키는데 분명 큰 효과를 발휘한다.
둘 째, 조직이 스스로의 역량을 정확히 파악함으로써, 현실성 있는 비전과 전략을 수립하여 그에 집중할 수 있게 해준다. 어느 시점에 어떤 역량을 더 키워야 하는지도 판단할 수 있고, 이는 조직이 경쟁에서 살아남기 위해 꼭 필요한 정보 중 하나이다.
하지만 위와 같은 경직된 조직에서 과제에 투명성을 부여하기란 결코 쉽지 않다. 깨어 있는 사람에 의해 위에서부터 도입되는 시나리오가 가장 현실적이나, 정보가 차단된 문화에서 그럴 필요성을 느낄 수나 있는가가 첫 난관이다. 반대로 아래로부터의 개선은 변화를 시도하는 팀에게 상당한 모험이 될 것이다. 모든 정보를 투명하게 공개한 과제는 여러 겹 포장된 과제에 비해 생산성이 떨어지고 각종 문제들로 정신이 없는 것처럼 비춰지기 쉽다. 이런 현상의 진실을 경영진들에게 잘 납득시켜 결과가 나올 때까지 과제를 유지해 나가는 것이 가장 큰 난관이 될 것이다.
개발자들에게 오픈 마인드를 심어주는 것 역시 큰 장애가 될 수 있다. 자신들이 하는 일이 실시간으로 공개가 된다는 것은 자칫 일거수 일투족이 감시받는다는 오해를 불러 일으키기 쉽다. 실제 비공식적으로 도입해본 결과도 아랫사람들이 훨씬 적극적이며, 주로 위로부터의 말도 안되는 압박에 대한 방어효과 때문으로 보인다. 그리고 윗사람들이 하는 일도 다 같이 공개된다는 점을 잊지 말자.
마지막으로 그리고 절대 간과해서는 안되는 것이 있다. 정보 공개를 위해 귀찮은 추가 작업을 수행해야 한다면 업무 집중도가 떨어지고 정보 누락이 발생한다. 부정확한 정보를 얻기 위해 생상성을 떨어뜨리는 것은 바보짓이다. 따라서 충분한 논의와 교육으로 가능한 많은 이들과 공감대를 형성하고, 좋은 자동화 인프라를 갖춘 후에 시행에 옮겨야 한다. 의욕만 앞서 무리하게 추진하면 부정적 인식만 남겨 도입 시기를 더 늦춰버리는 역효과가 나기 쉽다. 지금까지 자칭 SE 라는 조직에서 수없이 반복해온 실수들이 아닌가!
하루라도 빨리 제대로된 개발을 해볼 수 있는 날이 오기를 바라며, 답답한 마음에 두서 없이 적어본 프로젝트 투명성에 대한 이야기를 마친다.
참고로, 인프라 관점에서는 본격적으로 제품이 나오기 시작한지는 아직 몇 년 되지 않아 제대로된 솔루션 중에는 선택의 폭이 넓지 않다. 현 시점에서는 IBM Rational 의 Jazz/RTC 와 MS 의 Visual Studio Team System 2010 정도가 눈에 들어온다. 통합 환경에 비해 사용법을 익히고 관리하는데 더욱 많은 노력이 드는 것은 어쩔 수 없지만, 별개의 여러 툴들을 조합해 사용할 수도 있다. 조직의 규모가 커질수록 투자할 만한 가치가 있을 것이다. 나라면 개발 인력 5명에 3개월 과제만 되어도 이런 류의 인프라를 도입할 것이다.
