필자 : 신창섭 이사보

시쳇말로 개발 프로젝트 짬밥을 먹은 지가 어언20년이 되어 가지만 초창기 친구들과 진행하던 프로젝트에서 느끼던 재미를 되살리기란 여간 힘든 일이 아니다.

물론 당시의 재미는 순수했던 젊은 혈기와 배우는 즐거움 때문이었을 것이다. 주위 사람들도 그렇게 얘기하고, 나 역시 큰 프로젝트는 어쩔 수 없이 희생과 노력으로 완성된다고 애써 최면을 걸어본다. 하지만 그럼에도 불구하고 내 자신이 이제는 수백 명의 개발자와 관리자들을 재미없는 프로젝트로 몰고가는 주체가 되고 있는 듯하여 죄책감을 느끼곤 한다.

과연 프로젝트를 게임처럼 즐기면서 하는 방법은 없는 것일까?

왜 현재의 프로젝트들은 타들어가는 촛불처럼 개발자들이 소진되면서 작업을 할 수밖에 없는 것일까?

돌이켜보면 이 질문에 대한 대답은 의외로 망가지고 있던 프로젝트 혹은 일부 파트를 성공적으로 정상궤도로 돌려놓았던 경험에서 그 실마리를 찾을 수 있을 것 같다.

대개 망가져가는 프로젝트들은 사전에 몇 가지 징후들을 보인다.

첫째, PM과 PL이 소집하는 회의가 많아진다. 대개 이런 회의들은 생산적인 결론이 도출되기보다 PM과 PL의 일장 훈시로 시작해서 각자의 진행 상황에 대한 보고(보고라기보다 사실 변명에 가까운)가 이어지고 후반에 이르러서는 갑에 대한 불만토로의 장으로 마무리되고 으레 저녁엔 개별적인 술자리 혹은 회식이 이어진다.

두번째 징후는 수백 명의 개발자가 일하는 사무실이 독서실로 바뀌는 현상이다. 모두들 밤늦게까지 야근을 하지만 서로간에 말이 없다. 가끔 담배 피러 가자거나 밥 먹으러 가자고 할 때를 제외하면 별로 대화를 하지 않는다. 심지어는 현업에게 업무요건에 대한 확인도 하지 않는다. PL이나 현업의 결함 지적 또는 추가요건에 대해서는 문서로 전달해 주기를 바랄 뿐이며 꼭 필요한 대화는 대부분 메신저를 통해 해결한다.

세번째 징후는 조정계획이 수립될 때 각 Task가 커지거나 개발자만 알 수 있는 Task로 변하면서 그 기간이 길어지는 현상이다. 아마 그 이유는 그 결과가 잘된 것인지 아니면 잘못된 것인지 판단할 기준이 모호하거나 적어도 해당 Task가 진행 중일 때에는 괴롭히는 사람이 거의 없기 때문일 것이다.

이러한 징후들이 보이고 일정 기간이 지나면 어김없이 대부분 PM들의 비장의 무기인 ‘월화수목금금금’ 신공이 펼쳐지고 하청에 재하청 소속 개발자들 중에서는 건강상의 이유 혹은 개인적인 신상의 문제로 프로젝트를 도중하차하는 사람들이 간간이 보이게 된다.

독자들도 추측하다시피 이들의 모습은 몇 일 뒤 또 다른 프로젝트의 킥오프 모임에서 찾아볼 수 있는 경우도 적지 않다.

오랜 기간 PMO로 일하면서 이렇게 무너진 팀을 정상궤도로 올려놓기 위한 나만의 필살기가 몇 가지 있다.

물론 다년간의 하청에 재하청 프로젝트 생활로 프로젝트 관리자들에 대한 냉소적인 태도가 몸에 배인 개발자들을 간단히 몇 가지 조치만으로 슈퍼맨은 아닐지라도 최소한 제 몫을 하는 멤버로 바꿔놓는 것은 결코 쉬운 일이 아니다.

하지만 적어도 이들의 문제를 완화시키거나 서서히 반전시키는 방법의 공통분모들을 다음과 같이 정리할 수 있다.

1. 우선 모호한 Task들을 개발자가 아니더라도 눈으로 확인할 수 있는 기능 단위로 변경하고 각 기능의 크기를 측정한다.
2. 개발자들을 8명 정도의 작은 팀으로 분할한 후 적절한 경쟁구도를 만든다. 회식비 따먹기와 같은 확실한 전리품이 있다면 더욱 좋겠다.
3. 2주~1개월 정도의 이터레이션을 단위를 설정하고(이터레이션의 단위는 프로젝트 팀의 성숙도에 따라 달라진다) 총 몇 회의 이터레이션을 가져갈 것인지 결정한다.
4. 팀별로 각 이터레이션 동안 소화할 수 있을 만큼의 120%에 해당하는 기능을 과제로 준다. 적어도 해당 이터레이션 동안 다른 과제는 고민하지 않도록 배려해야 한다.
5. 매일 빌드를 통해 해당 과제가 얼마만큼 소화되었는지 측정할 수 있도록 조치한다.
6. 각 이터레이션이 끝날 때마다 현업의 평가를 통해 완료된 기능에 대해 선언한다.

물론 대형 프로젝트에 이러한 조치들을 적용하기 위해서는 S/W 아키텍처, 프레임워크, 테스트 절차, 형상관리도구 등 제반 환경을 갖추어야 한다.

눈치채셨는가? 요즈음 많이 회자되고 있는 애자일 방법론 가운데 스크럼과 유사하다. 대부분의 애자일 방법론이 기존 방법론으로 실패한 프로젝트들을 만회 또는 극복하는 과정에서 만들어진 것을 떠올리자면 애자일 방법론들 사이의 유사성을 가지는 일련의 조치들은 효과적인 처방의 하나가 될 수 있다는 사실을 증명한다

그렇다면 왜 이러한 처방이 효과가 있는 것일까?

프로젝트를 게임처럼 즐기기 위해서는 어떠한 필요조건들이 있을까?

축구, 야구, MMORPG 등 여럿이 참여하며, 장기간의 리그를 하면서도 플레이어들에게 재미가 사라지지 않게 만드는 게임들의 흥미요소에서 공통분모를 찾아보자면 ‘결과의 불확실성’, ‘즉각적인 반응’, ‘경쟁’, ‘팀플레이’, ‘적절한 몰입의 반복’, ‘도전’, ‘효과적인 게임 규칙’과 같은 요소들을 찾을 수 있다.

어떤가? 뭔가 망가지고 있는 프로젝트에 대한 처방과 유사성이 드러나 보이지 않는가?

위에서 언급했던 처방들은 프로젝트에 게임의 흥미요소들을 넣기 위한 일련의 조치들로 볼 수 있다.

사람은 기계가 아닌지라 처해진 환경에 따라 다른 반응들이 나타난다.

특히나 개개인의 지적 능력을 최대한 끌어내야 하는 소프트웨어 개발에 있어서 어떠한 환경이 그들로 하여금 게임과 같이 몰입하면서 즐길 수 있게 만들 수 있는가는 프로젝트관리 관점에서 대단히 중요한 문제이다.

테일러, 포드, 도요타, 린, 닛산 생산방식 등 자동차 산업에서 시도되었던 효율적인 생산방식에의 탐구는 소프트웨어 개발 프로젝트에서도 본받을 필요가 있다.

우리나라에서도 SDS개발방식, LG CNS개발방식, NHN개발방식, 다음개발방식 등이 소개되는 그런 날을 기다리는 것이 헛된 희망일까?