프로젝트의 쓴맛

SI 업계에 있은지 10여년을 훌쩍 넘겼지만 여전히 매 프로젝트마다 쉽게 넘어가는 프로젝트는 없는 것 같다. 프로젝트마다 난이도가 다르고 수행 여건이 다르기에 각각의 특성은 매번 달라지고 그 때마다 새로운 경험을 하면서 뭔가를 배우게 된다. 왜 경험이 누적되는 데 반해 "프로젝트의 쓴맛"은 여전할까? 달콤상콤한 프로젝트란 나하고 거리가 먼 걸까?

예전에도 프로젝트 종료 후 교훈을 복기했지만 여전히 잘 안되고 있는 것들이 많은데 오늘은 한 가지만 새로 짚어보자. 이름하여 “Technical debt”.

내가 경험하는 관점에서 "기술 부채"란 요구사항에 부합하는 기술적 설계/구성을 프로젝트 초기에 완료할 수는 없기에 부족한 부분이 누적되게 되는데 이게 단순 누적이 아니라 “복리” 개념으로 제 때 해결되지 않으면 시간이 지날수록 눈덩이처럼 불어난다는 것이다. 일견 쉬운 문제를 어렵게 해결하는 건 합리적이지 않아보이니 일단 깔끔하진 않지만 쉽게 해결하는 방법을 선택하지만 그게 빚이 돼서 나중에는 다시 해결해야 하는 문제로 돼서 돌아올 수 있는 것이다. 적절한 비유적 표현이다.

어떤 기능을 구현할 때 프로젝트 전체적인 관점에서 재사용성, 확장성 고려 없이 해당 기능 하나만 잘 만들어 놓으면 되겠지하고 짧은 시간에 만들었다고 하자. 그런데 나중에 보니 다른 곳에서도 같은 방식의 구현이 필요하고 하고 그에 따라 이미 구현된 여러 것들의 구조를 변경해야 한다면? 이 때도 임시 방편으로 다른 것들의 구조를 바꾸지 않고 쉽게 가는 방법을 발견해서 갔는데 나중에 또 가보니 결과적으로는 구조를 바꿔야 하게 된다면?

이번 프로젝트에서 그런 문제를 여러 차례 경험했다. GIS 제품, BI 제품을 도입했으나 고객 요구 사항과는 부합하지 않은 것이 많아져 결국 새로 개발하게 되어 제품 비용은 제품 비용대로 들어가고 인력과 시간은 또 추가 투입되고…

그런데 그게 기술 구조도 그렇지만 인력 구성도 마찬가지다. 프로젝트를 셋업할 때 적합한 인력으로 구성해야 하는데 처음부터 적합한 사람을 투입하기 어렵다보니 일단 눈에 띄는 사람부터 넣고 나중에 찾아서 넣는 계획으로 시간을 벌어보고자 한다. 그러나 그 나중이 프로젝트 초기가 아니라 점점 늘어져 중기가 되고 말기가 되는 경우가 발생한다.

프로젝트 진행에서 대출은 자꾸 늘어가기 때문에 처음부터 원금을 갚는 전략을 취해야 한다. 원금을 갚지 않으면 시간이 흐를 수록 늘어나는 대출에 그 이자를 감당할 수 없다. 당장은 원금부터 갚기 힘들겠지만 쉽고 편한 길만 선택하다보면 프로젝트 전체 관점에서 비용은 훨씬 더 많이 들어가게 된다.

느리지만 거북이 같이 꾸준하게 한 걸음, 한 걸음 나아가도록 해야겠다.