프로세스가 창의성을 저해한다고?

개발 프로세스가 창의성을 저해한다고 싫어하는 개발자, 관리자, 경영자를 종종 만나게 됩니다. 이들이 프로세스를 싫어하는 이유는 과거에 개발 프로세스 도입에 대한 실패의 경험이 있거나 그런 얘기를 종종 전해 듣기 때문입니다.

이렇게 개발 프로세스 도입에 실패하는 이유는 현실성이 없는 이론적인 프로세스를 도입하거나 회사의 역량 수준에 맞지 않는 프로세스를 시도한 경우가 많습니다. 또 인터넷이나 책을 통해서 배우게 된 프로세스를 따라 하다 보면 그 Context를 다 알지 못하고 형태만 비슷하게 흉내 내다가 실패하기도 합니다.

그럼, 그렇다고 프로세스가 없다면 창의성이 샘솟을까요?

개발프로세스가 제대로 갖춰지지 않은 회사는 대부분 각 개발자들의 개인 역량에 따라서 적절히 개발이 이루어지며 개발자들은 역할의 구분 없이 만물박사 식으로 온갖 업무를 처리합니다. 이러다 보면 항상 바쁘고 새로운 기술을 조사한다거나 참신한 생각을 할 틈이 별로 없습니다. 또, 멋진 아이디어가 떠올라도 마땅하게 Follow up할 방법이 없어서 아이디어를 떠올린 개발자가 북치고 장구치고, 경영층도 설득하고, 프로토타입도 만들어보고 시장 조사도 해보고 해야 합니다. 안 그래도 바쁜 마당에서 짬을 내서 또 새로운 아이디어를 Follow up하기는 정말 어렵습니다. 누가 무슨 일을 얼마나 하고 있는지 잘 파악이 안되므로 또 이런 일을 벌여서 괜히 성과도 없이 평가만 안 좋아 질까봐 포기하기 십상입니다. 또 아이디어 낸 사람이 총대를 매야 하기 때문에 그렇다고 기존의 업무가 줄어들지 않기 때문에 공식적으로 이런 활동을 안하려고 합니다.

하지만, 개발 프로세스를 잘 갖추고 있는 회사는 아이디어를 내기만 하면 일단 회사의 System이 이를 Follow up합니다. 일단 아이디어는 수면 위로 떠올라서 여러 사람과의 Review를 통해서 더욱 Refine되고 정식 절차를 통해서 Prototype을 만들고 마케터는 시장 조사를 하고 영업은 고객들의 의견을 수집해 옵니다. 관리자는 해당 개발자가 아이디어를 발전시킬 수 있도록 정식으로 업무를 할당해서 시간을 빼줍니다. 한마디로 개발자는 기술적인 것만 Follow up해도 됩니다. 물론 모든 아이디어가 제품화 되는 것은 아니지만, 이런 아이디어들이 10개 100개 모여서 성공하는 제품이 나옵니다.

결국 프로세스가 창의성을 저해한다는 생각은 무지의 산물이거나 잘못된 경험의 결과입니다.

문제는 회사의 몸에 딱 맞는 개발프로세스를 갖추는 것이 어렵다는 것입니다. 현재 개발을 어떻게 하고 있는지 조사를 해보면 제각각 일겁니다. 이것부터 통일해 나가면서 조금씩 바꿔가는 것이 스스로 해볼 수 있는 최선의 방법입니다.

소프트웨어 개발의 극과 극

꽤 오래 전에 TV에서 "비교체험 극과 극"이라는 프로그램을 방영한 적이 있습니다. 어떤 아이템을 정해서 가장 비싼 것과 가장 싼 것을 비교하는 프로그램이었는데 꽤 재미있게 본 기억이 납니다.

소프트웨어를 개발하는 현장에서도 극과 극 현상은 드물지 않게 발생합니다.

여러 회사를 분석해보면 완전 주먹구구이거나 또는 너무 무거운 방법론을 도입해서 오히려 부담이 되는 경우가 많습니다. 적당히 중간인 회사를 찾기가 더 어렵습니다.

완전 주먹구구식 가내수공업 형태의 개발방식도 문제가 있지만, 몸집과 역량에 걸맞지 않은 거대한 방법론을 무조건 따라하는 것은 더 문제가 큽니다. 그럴 바에는 차라리 주먹구구가 낫습니다.

그런 주먹구구회사가 문제를 깨닫고 거대 방법론들을 스스로 연구해서 도입을 하면 그 핵심은 모르고 형식만 따라하는 경우가 많습니다. 그러다보면 프로세스가 너무 복잡하고, 문서도 너무 많이 만들어야 되는 경우가 허다합니다. 이런 시도는 거의 실패한다고 보면 됩니다. 애초에 따라 할 수도 없고, 억지로 따라한다면 비용과 시간은 몇 배로 더 들고 회사는 망하기 길 밖에 남지 않습니다. 국내의 대부분의 소프트웨어 회사들은 그러한 거대 방법론은 필요하지도 않습니다. 또 그렇게 많은 문서는 만들 필요도 없습니다. 개발에 필요한 핵심문서 몇 개만 자신들이 만들고 업데이트하고 감당할 수준 정도만 만들어내야 합니다.

극과 극의 양쪽이 아닌 회사에 딱 필요한 수준의 중간점을 찾아서 적용해야 합니다.

빌딩과 개집

시중에는 넘쳐나는 수많은 소프트웨어 개발 방법론이 있습니다. 지금까지 알려진 방법론만 100가지가 넘습니다. 인터넷에서 이에 대한 설명만 보고 Template만 복사해 와서 회사에 적용하기에는 무리가 있습니다. Template과 Sample만 보면 방법론을 적용하여 선진 개발 방식을 따라 할 수 있을 것 같지만, 이는 착각입니다. 

방법론 자체가 잘못되지 않았음에도 잘못된 방식으로 오해를 하여 적용을 하거나 특정 부분에 집착하여 전체를 놓치는 경우가 많습니다.

집을 짓는데 빌딩을 만드는 방법을 적용하면 안되고, 그렇다고 개집을 만들 때처럼 대충 지어서도 안 됩니다. 개집을 만들 때는 대충 만들어도 되고, 안되면 다시 만들면 됩니다. 빌딩을 만들 때는 한치의 오차도 없이 정확하고 복잡한 방법을 사용해야 합니다. 

빌딩을 만드는데 대충 만들고 마음에 안들면 다시 만들고, 요구사항을 중간에 마구 바꾸면 안된다는 누구나 알 수 있습니다. 

그 반대로 개집을 만드는데, 정교한 설계와 많은 시간과 비용을 들일 필요는 없겠지요.

하지만 소프트웨어를 개발하는 현실 세계에서는 이와 같은 일들이 흔히 벌어집니다. 

빌딩과 같은 시스템을 만들면서 형식적으로만 방법론을 따르지만, 아키텍쳐는 심각하게 고려하지 않고, 요구사항이 철저히 분석, 검토되지도 않고 나중에 요구사항을 마구 바꿀 수 있다고 생각합니다.

모든 개발 방법은 프로젝트의 특성에 따라서 적절히 정해져야 합니다. 많은 경우 작거나 중간 규모의 프로젝트를 진행하면서 거대 프로젝트에 적합한 방법론을 기계적으로 적용하려고 합니다. 또는 정반대로 완전 주먹구구식으로 진행하는 경우도 많습니다. 

작거나 중간 규모의 프로젝트에 개발 방법론을 적용하려면 뭔가 생략하고 간소화를 해서 적용해야 할 것입니다. 그런데 무엇을 생략할지는 그 원리를 모르면 알기가 어렵습니다. 따라서 인터넷이나 소프트웨어 공학책을 통해 쉽게 익힌 방법론을 회사에 적용하는 것은 무리가 있습니다. 각 회사에 맞는 개발 방법론을 적용하려면 전문가의 도움을 받는 것도 좋은 방법일 것입니다.