Talk about Software with hani

디자인 문제를 효과적으로 해결할 수 있는 비결은 우선 주어진 상황에서 제약사항들을 가능한 많이 인지할 수 있는 능력이다. 그리고 이러한 제약사항 내에서 디자인 작업에 대한 의지와 열정을 갖는 것이다.

찰스 임스 from 사용자 경험에 미쳐라!

스타를 처음 배울 때, 가장 좋아하던 치트키가 있었습니다. 바로 ’show me the money’였죠. 이 치트키 한방이면, 게임역전이었습니다. 물론 컴퓨터와 경기를 할 때만 유용한 치트키였죠. 하지만 문제는, ’show me the money’를 친 잠깐 기분이 좋지만, 게임은 곧 명절 때마다 TV에서 방송하는 영화처럼, 지루해진다는 데 있습니다.

살면서 ’show me the money’를 치고 싶은 순간이 있습니다. 돈이 궁해서, 시간이 없어서, 체력이 약해서, 가진 게 별로 없어서 말이죠. 하지만 인생이라는 게, 게임도 아니고. 설혹 게임이라도, 게임도 치트키 한방에 시시한 명절 영화로 변질되는데, 인생은 어떨까요?

물론 긍정의 마인드로 즐겁게 살려고 해도, 이를 악물다 못해서 어금니가 상할 정도로 참아도, 바뀌는 게 없는 것처럼 보이지만. 한시대를 풍미했던 뛰어난 디자이너의 말처럼, 삶은 주어진 조건에서 무언가 해보려는 데 의의가 있지 않을까요?

무릇 있는 자는 받아 풍족하게 되고 없는 자는 그 있는 것까지 빼앗기리라.

마태복음 25장 29절

어떤 회사든지 조직을 구성하는 최소 단위가 있습니다. 제가 처음 입사했던 곳에서는 파트라고 불렀고, 지금 있는 곳에서는 워킹그룹이라고 부르죠. 올해 초에 썼던 블로그에서 잠깐 언급했지만, 제가 한때 몸 담았던 파트의 파트장님께서 임원으로 승진하셨습니다.

아웃라이어에서 캐나다 하키 선수 가운데 1월생이 많은 이유를 설명하죠. 즉 어린 나이일수록 같은 연령대라도 1월생과 12월생은 육체적인 능력 차이가 있고, 이런 능력 차이 때문에 1월생이 12월생보다 기회를 더 많이 얻을 수 있습니다. 1월생 선수는 능력 신장의 선순환이, 12월생 선수는 기회가 주어지지 않기 때문에 능력을 키울 수 없는 악순환에 부닥치게 됩니다. 책에서 이런 현상을 마태복음 효과라고 말했죠.

하키 선수 이야기를 읽으면서, 임원으로 승진하신 파트장님이 생각났습니다. 임원으로 승진하셨던 분보다 1달 늦게 입사한 선배사원이나, 1년 늦게 입사한 분들은 파트원으로 일을 하셨죠. 물론 파트장을 맡으셨던 분이 탁월한 관리 능력이 있었기 때문에, 임원으로 승진하실 수 있었습니다. 하지만 같은 해에 입사하신 분들 가운데 그나마 1달이라도 빠른 것이, 커리어 패스에 큰 영향을 준 듯하죠.

현재 대기업에서 임원인 분들 가운데, 대리 초부터 관리업무를 맡았던 분들이 많을 겁니다. 아무래도 조직이 커지는 상황에서, 실무를 하는 사람도 관리를 하는 사람도 같은 연배에서 나올 수 밖에 없었기 때문일 겁니다.

***

대기업에 입사한 탓도 있지만, 제가 입사했을 때만 해도 조직이 어느 정도 자리를 잡고, 한참 프로젝트가 생길 무렵이었기 때문에, 신입사원이나 관리직을 제외한 기존사원도 모두 실무를 하는 상황이었습니다. 일손이 모자란 상황이었기 때문에, 입사하자마자 제게도 프로젝트가 떨어졌죠.

대학원을 다니면서 프로젝트를 수행했기 때문에, 프로젝트가 어떤 식으로 흘러가는지 알고 있었지만, 프로젝트를 도맡아서 수행해야 한다는 부담감이 무척 컸습니다. 지금 생각해 보면, 이 시기가 제게는 무척 큰 도움이 됐던 시간이었는데요. 즉 선배사원이 PM을 맡았지만, (아마도) 저를 키워주실려고 모든 일을 제게 일임하셨기 때문입니다.

***

저희 부서에도 1년에 1~2명 정도 신입사원이 들어옵니다. 하지만 경력사원은 신입사원보다 더 많이 들어오죠. 아무래도 엔지니어링 업무를 하는 회사이기 때문에, 고객들도 프로젝트의 품질이 우수하기를 기대합니다. 이런 이유로, 신입사원들에게 핵심적인 업무가 돌아가지 못하고, 프로젝트에서 핵심으로 뛰시는 분들은 대개 30대 후반입니다. 물론 40대 초반이 분들도 있죠.

88만원 세대와 386세대로 대표되는 세대간 경쟁이 있습니다. 386세대든지 88만원 세대든지, 이런 말이 의도한 것은 아니지만, 왠지 세대로 편가르는 듯한 느낌을 주기 때문에 그다지 좋아하지 않습니다. 하지만 세대간 경쟁이라고 부를 정도는 아니지만, 마태복음 효과가 프로젝트에 존재합니다. 즉 회사 입장에서 중요한 프로젝트는 신입사원에게 맡기기보다 아무래도 경험이 많은 개발자들에게 맡기기 때문이죠.*

***

베이비붐 세대가 한세대를 풍미하고, 그 속에서 복된 자(?)는 관리직으로 임원까지 올라갔으며, 그 뒷세대 가운데 운좋게도 처음부터 좋은 프로젝트에 참여해서 경험을 쌓은 사람은 능력을 더욱 키울 수 있는 프로젝트에 참여했습니다. 마태복음 효과가 하나의 현상을 이야기하는 것이지만, 자칫 잘못하면 이데올로기처럼 작용할 수 있기 때문에 경계해야죠. 다만,야망이 있는 사람이거나 자신의 능력을 키우고 싶은 사람들은, 참고할만한 아이디어인 듯합니다.

* 이런 상황에서 신입사원의 능력을 조직적으로 키울 수 있는 방안을 항상 고민해야 합니다.

얼마 전에 제가 참여했던 프로젝트가 끝났습니다. 무사히 끝나서 천만다행이죠. 지금에서야 드는 생각이지만 약간은 무모한 프로젝트가 아니었나 싶습니다. 데드라인도 달력 위에 특정한 날짜로 고정되어 있었고, 개발범위도 협상가능하지 않았으며, 프로젝트 예산조차도 딱 정해져 있었습니다.

이 프로젝트가 제안되고 프로젝트로 만들어질 때, 동료들이 “누가 PM이나 팀원이 될지 모르겠지만, 고생이 심하겠다”고 말할 때, 저도 고개를 끄덕였죠. 물론 프로젝트의 성공만을 놓고 볼 때에, 이런 프로젝트는 피해야 하는 게 상책이지만, 조직 입장에서 매우 중요한 프로젝트였기 때문에, 어쨌든 성공해야 했습니다.

하지만

프로젝트의 PL로서(그리고 실질적인 PM), 제가 낙점되었다는 희소식(?)에 ‘관조끝 고생시작’의 길로 들어섰습니다. 대개 제한인자가 많은 프로젝트에 참여하는 팀원들은, 약간의 피해의식에 빠져드는 경향이 있지만. 그나마 다행스럽게도 팀원들로서 긍정적인 동료들이 참여했죠.

겸손한 개발자가 만든 거만한 소프트웨어에서 다루었지만, 소프트웨어 개발 프로젝트에서 작업량을 예측하는 것은 매우 중요합니다. 즉 거만한 소프트웨어의 한 종류인, 품질이 나쁜 소프트웨어를 만들지 않으려면 프로젝트 기간에 품질을 확보할 있는 작업 시간이 필요 하고. 그럴려면 팀원들이 탈진하지 않고 개발 리듬을 활기차게 유지할 수 있도록, 하루 평균 8시간 정도만 작업해야 합니다.

8시간 근무를 하려면 작업량을 예측하는 작업을 먼저 진행해야죠. 즉 주어진 프로젝트 기간에 주어진 팀원들로 고객이 원하는 기능을 모두 개발할 수 있는지 우선 예측을 해야 합니다. 프로젝트 초기에 내린 작업량 예측치는 대개 틀리기 마련입니다. 예측을 하는 데 필요한 데이터가 부족하고 정확하지 않기 때문이죠.

예측치의 정확도를 높이려면, 애자일에서 하듯이 반복주기가 끝날 무렵 예측치가 얼마나 정확했는지 평가하고, 예측치의 정확도를 높이는 작업을 해야 합니다. 그리고 남은 기간 동안, 고객이 원하는 기능을 모두 인도할 수 있는지 판단해야죠. (가능할지 모르지만) 주어진 기간에 모든 기능을 인도할 수 없다면, 고객(내부고객이든 외부고객이든)과 요구사항 or 예산 or 기간을 두고 협상을 해야 합니다.

앞의 이야기는 프로젝트를 수행해 보신 분들은 거의 아시는 이야기일 듯합니다. 제가 참여했던 프로젝트처럼 지나치게 제약사항이 많은 상황에서도, 작업량을 예측할 필요가 있을까요? 작업량을 예측한다는 것은, 프로젝트를 구성하는 여러 조건들을 조정할 수 있다는 것을 가정하죠. 하지만 제약사항이 모두 고정되어 있을 때 사실 협상의 여지가 없기 때문에, 작업량을 예측하는 것은 그다지 도움이 되지 않습니다.

그렇다면 이런 상황에서, PL로서 저는 어떤 선택을 했을까요? 제약사항이 많았지만, 다행스럽게도 설계서와 비슷한 산출물을 고객이 제공했고, 전문 테스터가 프로젝트에 투입됐습니다(개발자 2명당 테스터 1명이 붙었습니다. 일반적인 프로젝트와 비교했을 때, 테스터 비율이 무척 높았죠*).

이런 호의적인 조건에 덧붙여서 프로젝트를 성공시키기 위해서, 저는 ‘과연 프로젝트를 합리적으로 끝낼 수 있는지 고민’하기보다, ‘프로젝트를 성공에 가깝게 하는 방법’들을 적용하는 데 주력했습니다. 즉 제가 프로젝트의 PM으로 참여할 때 항상 적용하는 애자일 실천방법을 조금 더 밀도 있게 적용했습니다. 이런 실천 방법으로는 스탠드업 미팅, 짝 프로그래밍, 동료 검토(Peer review), statement coverage 100퍼센트를 목표로 한 단위 테스트, 프로젝트 초반부터 테스터와 협업 등이 있었습니다.

애자일 프랙티스를 처음 경험하는 팀원들이 대다수여서, 짝 프로그램이나 동료 검토에 대해서 프로젝트 초반에는 회의적인 분위기가 다소 있었지만. 프로젝트를 시작하고 나서 2주 정도 지나자, 짝 프로그래밍과 동료 검토의 효과를 경험하고 나서, 프로젝트에는 경쾌한 개발 리듬이 형성되었죠. 그리고 다행스럽게도 프로젝트는 잘 마무리되었습니다.

세상에 협상 불가능한 것은 존재하지 않습니다. 제약사항이 많은 프로젝트라든지, 협상이 불가능하다고 선언한 고객이라도, 불가피한 상황에서 이해당사자들이 협상 테이블에 앉기 마련입니다. 그렇기 때문에, 작업량을 계속해서 예측하는 것도 도움이 될지 모르죠. 하지만 협상 테이블이 차려질 정도면, 이미 이해당사자들이 감정이 상한 상태이거나 팀원들이 탈진 상태인 경우가 흔합니다.

작업량을 예측하는 것도 어느 한편으로 도움이 되지만. 그것보다 제가 경험한 프로젝트처럼, 기민하게 프로젝트를 성공시킬 수 있는 실천방법을 적용하든가. 고객 입장에서 우선순위가 가장 높은 기능 순서대로 개발을 해서, 협상 테이블이 차려졌을 때, 협상 가능성을 높이는 편이 낫다는 생각입니다.

* 이번 프로젝트에서 어떤 식으로 테스터와 협업했는지는 다른 포스트에서 한번 다뤄 보겠습니다.