모든 일에는 완료라는 개념이 존재하며, 프로젝트 또한 완료 뿐만 아니라, 시작과 더불어서 중요한 마일스톤 중에 하나입니다. 하지만, 이 완료를 정의한다는 것은 현실적으로 상당히 어렵습니다. 그 이유는 프로젝트의 완료 시점에는 또 다른 시작이라는 개념이 같이 묶여있기 때문입니다. 시스템을 만드는 프로젝트는 완료시점에 시스템의 가동/운영이 시작되는 시점입니다. 프로젝트의 완료라는 것이 이 시스템을 만드는 것을 목적으로 진행되었다고 한다면, 그 이후에는 만들어진 시스템의 운영이라는 새로운 시작과 더불어서 안정화라는 관점에서 새로운 국면이 시작됩니다.
이와 같이 어느 한 국면의 종료와 시작이 같이 만나는 지점에서는 항상 문제가 발생될 수 밖에 없으며, 그 문제가 서로 다른 목적의 완료와 시작의 의미를 전혀 다른 시각으로 바라보게 만듭니다. 우선은 시스템을 만드는 입장에서의 완료는 비즈니스 로직을 구현해서 시스템 내에서 이를 동작하도록 만드는데 있습니다. 이러한 개발 과정은 예상하고 예측한 기능의 실현화에 초점을 맞추어져 있습니다. 특히, 이 시점에서는 시스템이 운영하는 다양한 환경을 고려하기가 무척 어려우며, 모든 가능성들을 예측하여 정해진 기간 동안에 실현화시킨다는 것 역시 불가능합니다. 따라서, 어떠한 형태이든 간에 시스템을 만드는 과정에서 간과된 많은 것들은 새로운 시작 국면인 시스템 운영 시점부터 서서히 나타나기 시작합니다.
결국은 프로젝트의 완료는 동일한 시스템을 바라보는 두 가지 서로 다른 입장의 차이로부터 완료에 대한 정의의 차이가 발생되기 시작합니다. 완료를 바라보는 두가지의 입장 차이는 새로운 압력이나 강제의 형태로써 분위기를 압도하여 자기가 편한 방식으로 상대의 입장을 완전히 꺾어뜨리는 것에서부터 서로의 합의점을 찾아서 매끄럽게 넘어가는 형태까지 다양합니다. 하지만, 여기에는 돈이라는 결정적인 변수가 작용하여 돈 가진 사람의 횡포로써 그 입장을 표현하기도 합니다.
어찌되었든 간에, 프로젝트를 완료하고, 다음 단계로 넘어가고자 하는 서로 다른 입장의 목표만은 분명 일치합니다. 프로젝트 막바지에 나타나는 형태는 단일 기능의 작동 여부보다는 전반적인 기능을 관통하는 시스템적인 기능들에 대한 문제가 더 크고 위험해보입니다. 바로 이 문제로 인해서 기존 로직의 수정에 대한 유연성이 얼마나 확보되었는지가 전체 시스템의 영향도에 미치게 되며, 결국은 기능의 미구현 상태로 남아있게 됩니다. 프로젝트 막바지에 이러한 문제들을 해결하려는 노력이나 시도는 아무리 사람을 많이 투입한다고 하더라도 해결하기가 힘들 뿐더러, 그 동안의 이력을 모르는 상태이기 때문에 오히려 기존 멤버들에게는 방해만 될 뿐입니다.
결국, 이러한 문제들을 해결하기 위해서는 초반부터 이러한 노력들을 기울이는 작업이 같이 병행되어야 합니다. 하지만, 현실적인 제약(제품 서버 미구비, 목표 시스템 아키텍처 불명확, 확정되지 않은 비즈니스 등)으로 인해서 기능을 관통하는 작업을 수행하기가 여간해서는 쉽지도 않으며, 결국 기술적인 부채(technical debt)로 남아서 막바지와 운영 후에 계속해서 남게 됩니다.
이러한 현상들은 매번 프로젝트를 경험하면서도 느끼고, 또 경험하는 것들이지만, 막상 이러한 현상에 부딪히게 되면 이를 해결할 수 있는 능력을 가지고 있더라도 참으로 어려운 작업이기도 합니다. 결국은 급한 불을 끄는 심정으로 문제가 되는 곳을 직접 뛰어들어가 이곳 저곳을 강도높은 작업을 통해서 진화하거나, 아예 기술적인 부채를 하나 둘씩 갚아가면서 전반적으로 해법들이 나타나면서 진화하는 형태로 작업을 할 수 밖에 없습니다.
짧은 기간 안에 그리고, 한번의 번뜩이는 사고를 통해서 이를 해결한다는 것은 극히나 위험합니다. 또한, 그러한 해결책이 나중에 어떠한 문제들을 일으킬지는 아무도 모릅니다. 시간의 제약 속에서 이러한 압박감을 받는다는 것은 누구에게나 고통스러운 일입니다. 하지만, 이 불을 끄지 않고서는 그 어느 누구도 그 집에 살 수 없기에 어떠한 방법이 되었든 간에 그 불을 끄려는 시도나 노력을 해야만 합니다. 불을 보고만 있고 이러꿍 저러꿍 이야가만 해보았자, 점점 더 상황은 악화되기 마련입니다.
프로젝트 완료 시점에 서로 다른 시각을 가지는 양측이 가져야 할 태도는 '모든 프로젝트는 항상 실패한다'는 사실을 인지하는 것입니다. 이번 프로젝트를 반드시 성공하겠다라는 의지만을 가진다면 바로 충돌이 발생할 수 밖에 없습니다. 항상 문제를 안고 있는 프로젝트를 어떤 방식으로 풀지에 대한 합의만이 완료 시점에는 존재할 뿐입니다. 그리고, 핑크빛 소망이긴 하지만, 솔직한 커뮤니케이션을 통해서 문제를 풀어가는 데에만 신경을 써야 합니다.
프로젝트를 완료하는 것은 매번의 프로젝트 경험을 할 때마다 항상 어렵다고 느끼며, 점점 더 힘들다는 생각이 듭니다. IT의 발전과 더불어서 점점 더 고려해야 할 사항들이 많아지고, 점점 더 구현해야할 비즈니스 로직의 크기도 커지기 때문입니다. 눈에 보이지 않는 IT 영역에서 완벽한 제품은 그 어디에도 존재하지 않습니다. 다만, 사용자에게 이득이 되는 시스템만이 완벽해질 뿐입니다.
반응형
'Homo Ware' 카테고리의 다른 글
역할, 작업, 그리고 수행자 (0) | 2011.01.14 |
---|---|
조직과 기술 발전 - 테스트 조직 구성 (0) | 2011.01.12 |
클린 코드와 클린 작업장 (1) | 2010.11.05 |
기술 선택에 대한 자기 검열 (0) | 2010.04.13 |
IT 기술 선택의 기준 (0) | 2010.04.02 |