레인블루 :: 책과 영화 이야기

이 글은 회사동료중 두어분과 함께 프로젝트의 가치와 진행방법에 대해서 잡담을 하다가 나온 이야기를 정리하는 것입니다.

리팩토링 프로젝트란 필요한가?
먼저 리팩토링의 정의를 살펴보면, (출처 : 마틴 파울러의 리팩토링 From http://allwiz.egloos.com/2711555 )

리팩토링이란, 소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할 수 있도록, 겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는 것.

정의만 놓고 짐작해보건데 적어도 새로이 시작하는 프로젝트를 리팩토링 프로젝트라고 하지는 않는것 같습니다. 아마도 기존에 이미 존재하는 소프트웨어를 보다 이해하기 쉽고 유지보수하기 쉬운형태로 구조변경하는것이겠죠. 자 그렇다면, (회사에서) 기존의 업무를 뒤로 미루고 '리팩토링' 프로젝트를 하는것이 과연 옳은 방법인가? 혹은 리팩토링이 다른 업무보다 우선순위에서 앞으로 오는것이 바른것인가? 하는 의문이 남습니다.

이 의문에 대한 답은 바로 아래의 물음에 대한 답도 될수 있을 것입니다.

프로젝트의 성공유무를 판단하는 기준이 되는 가치는 어떤 것이어야 하는가?

프로젝트의 목표에 따라 그 대답이 여러가지가 있을수 있습니다. 하지만 최근에 제가 느낀것은 (저를 포함해서) 개발자에게서 발의되는 또는 시작되는 프로젝트는 지나치게 개발자적인 시각에 머물고 마는 경우가 많다는 것입니다. 시스템을 분리한다거나, 혹은 리팩토링을 통해서 유지보수성이 향상된다.. 는 등의 프로젝트의 가치는 개발자적인 시각으로 보면 뿌듯한것일수 있지만 그로인해 회사의 가치가 함께 향상되지 않는다면 의미없는 것일수 있다는 것입니다.

예를 들어 시스템을 분리한다면 그로인해 얼마의 가용성이 증가하고 이로인해 다운타임이 줄어든다는 식의 가치가 있어야 할것입니다. 또한 리팩토링은 기존의 업무를 Stop하고 적용하는 성질의 것이라기 보다는 유지보수 업무를 진행하면서 끊김없고 반복적으로 진행되어야 할 사안이라고 생각합니다. 그런면에서 리팩토링은 프로젝트로서 해결될수 있는것이 아니고 개발자의 마음가짐이나 자질향상등의 반복적이고 끊임없는 연구와 시도로 접근해야 하는 것이라고 할 수 있습니다.

유지보수는 가치가 없는 것인가?

이에 대해서는 최근에 읽고 있는 소프트웨어 컨플릭트 2.0에 신선한 시각이 있습니다.(옛날 책인데도 이런건 놀랍습니다)

소프트웨어 유지보수란 작업이 창의성을 억제하고 지저분하기까지 하지만, 소프트웨어는 어차피 쉽게 변하기 마련이며, 그렇기 때문에 개인간의 차이가 극명한 효율성의 차이를 보여주는 소프트웨어 생산성의 측면에서 볼때, 오히려 유지보수 업무에 최고인력을 투입해야한다고 이야기 합니다. 또한 그러기 위해서 상여금이나 승진과 같은 매력적인 조건을 제시하며, 유지보수의 기술향상을 위해 우선순위를 부여하는 방식으로 효율성을 향상 시켜야 한다고 합니다.

정리하면 이렇습니다.

회사에서 프로젝트를 한다면, 그것이 리팩토링이던 아니면 신규서비스를 만드는 것이건간에 회사의 입장에서 납득할만한 가치를 제공할수 있는 프로젝트 여야 한다는 것입니다. 그래야만 투입되는 리소스도 정당화 될수 있는 것이구요.
또한 리팩토링이란 항시성을 가지고 진행되어야 하는 업무라고 생각합니다. 물론 리팩토링을 함으로서 건지는 가치가 기존업무(유지보수)가 생산해내는 가치보다 월등히 큰 경우는 우선순위에서 앞서야 합니다. 하지만 그렇지 않은경우라면 당연히 리팩토링은 기존의 유지보수업무를 진행하면서 함께 병행되어야 할 업무일 것입니다.

덧. 개인적으로도 프로젝트를 마무리 하는 단계에서 과연 이번 프로젝트가 어떤 가치를 창출했는가.. 하는 고민이 있어 겸사겸사 포스팅 합니다.