역할, 작업, 그리고 수행자

SW 프로젝트에서 하나의 역할을 반드시 한사람이 수행해야 함을 의미하는 것은 아닙니다. 하지만, 프로젝트를 진행하다 보면, 자기의 업무에 대한 영역을 표현하고 다른 역할을 수행하는 것에 대해 반감을 갖는 경우들이 종종 목격됩니다. 예를 들어, 개발 업무를 수행하고 있는 작업자에게 테스트나 배포, 혹은 형상관리에 대한 작업(업무)를 한다고 불평한다든지, 특정인에게 배포와 형상관리 업무 만을 맡긴채 개발이나 설계에 대한 작업을 전혀 주지를 않는 형태는 역할이라는 개념을 잘못 이해하고 있는 경우가 큽니다.

하나의 역할은 수행해야할 작업과 책임을 가지고 있습니다. 그 작업은 다양한 내용들로 구성될 수 있으며, 이들 간에서 서로 관계를 가질 수도 있습니다. 또한, 다른 역할이 수행하는 작업들과 관계를 가지며, 서로 영향을 미치기도 합니다. 하나의 SW 프로젝트에는 다양한 역할이 만들어지며, 그러한 역할은 프로젝트 초반부터 끝까지 유지되고 지속되는 것도 있지만, 특정 작업이 발생될 때에만 필요한 역할이 있습니다. 후자의 대표적인 역할이 형상관리나 배포를 담당하는 역할입니다. 그리고, 이러한 역할들은 대부분이 간과하거나 누구도 책임을 지려하지 않는 경향이 강합니다. 이와 같은 역할들의 특징은 특정 업무가 아닌, 여러 업무를 가로지르는 역할이라는 것입니다.

여러 업무를 관통하는 역할은 SW 개발을 진행할 때 초반과 중반 이후에 그 활약이 두드러집니다. 초반에 그 역할이 두드러지는 것들에는 SW 아키텍트, 형상관리자, QAO 등이 있습니다. 이들은 초반에 SW 를 만들기 위한 기반을 다지며, 전체적은 큰 윤곽을 만들게 됩니다. 또한, 이들은 통상 별도의 조직으로 별도의 인원들을 훈련시켜서 운영하기도 합니다. 하지만, 프로젝트 후반으로 진행하면서 형상관리자와 배포관리자, 테스터, 시스템 통합의 역할을 담당하는 사람들의 비중이 커집니다. 특히, 개별 업무 단위로 진행하면서 만들어진 개별 모듈(혹은 컴포넌트)들이 하나의 애플리케이션으로 조합하여 서비스를 제공하면서 여러가지 상황들이 발생하게 됩니다. 그리고, 이러한 문제나 이슈들은 어느 특정 역할을 수행하는 작업자의 작업으로 해결되는 것이 아니라, 여러 사람들이 같이 협업하여 해결해야만 간신히 풀릴 수 있는 것들입니다. 이러한 상황에서는 역할과 그 수행자를 선을 자르듯이 명확하게 구획화시킬 수 없는 것이 제일 큰 이슈입니다.

예를 들어, 데이터 마이그레이션을 통해 기존 데이터를 새로운 스키마로 옮겼는데, 이러한 데이터는 해당 데이터를 처리하는 비즈니스 로직을 수행하는 서비스를 실행하기 전까지는 완벽하게 검증되었다고 볼 수 없습니다. 이러한 상황에서 발생된 문제는 그 원인을 찾기도 어려울 뿐더러 원인을 찾아다고 하더라도 이미 마이그레이션 된 데이터를 다시 처음부터 롤백해서 새로운 스키마로 이전시킬 수도 없는 상황입니다. 따라서, 이러한 상황에서는 새로운 해결책을 필요로 하게 되며, 이는 기존의 데이터 마이그레이션을 작업했던 수행자, 해당 데이터를 처리하는 비즈니스 로직을 만든 작업자가 같이 머리를 맞대고 불완전하게 변형된 데이터에 대한 해결책을 찾아야 합니다. 이 과정에서 서로의 잘잘못 만을 따지고, 더 이상의 해결책을 찾지 못한다면, 또 다시 새로운 문제점들이 발견될 것이고, 상황을 더 악화시키기 마련입니다. 통상 이러한 선후행 작업에 대해서 작업 수행 전에 최대한 고려는 하지만, 조직이 커질수록 놓치는 연결고리들이 점점 더 많게 됩니다.

이러한 작업 형태는 역할과 작업, 그리고 이를 수행하는 사람들이 거의 일대일로 매핑함으로써 한번 할당된 작업이나 역할에 대해서 더 이상의 다른 작업이나 역할을 수행하지 않으려는 고정된 역할을 만들어내게 됩니다. 역할이 수직적인 경향이 강할수록 새로운 역할을 수행하고자 하는 환경이 점점 더 희박해지는 경우도 있습니다. SW 개발을 수행하는데 있어서 모든 역할이 식별되고, 그 역할마다 고유한 업무와 절차가 정확하게 (세밀하게) 정의되어 있다면, 이는 가능할 것입니다. 또한, 자로 잰듯이 작업을 수행하고 모든 것들이 통합 시점에 딱 들어맞게끔 서비스를 제공한다면 이 역시 가능할 것입니다.

하지만, SW 개발이란 사람이 사람의 지식을 표현하는 작업으로 이와 같은 형태는 결코 일어나기 힘듭니다. 즉, 역할과 작업, 수행자 간의 관계는 N대 M의 관계를 형성하게 되며, 다양한 역할을 수행하는 수행자가 많으면 많을수록 그만큼 생산성이 더 뛰어나기 마련입니다. 즉, 일정한 간격으로 수행할 작업이 발생한다고 보면, 이를 처리하는 역할자는 분명 작업의 종류에 따라 결정되겠지만, 수행하는 사람은 '누구나'가 되어야 이상적인 SW 개발이 이루어집니다. 물론, 여기서의 작업은 불필요한 보고나 교육, 회의 주재와 같은 것은 제외되며, 순수하게 SW 개발에 관련된 작업만을 의미합니다. (보고나 교육, 회의 주재 역시 중요하지만, SW 개발 측면에서는 순수하게 WBS 상에서도 잡혀있지 않은 작업이기 때문에 제외됩니다.)

역할이 겹치는 작업, 오로지 (특정) 한사람만 수행하는 역할, 본인이 수행하는 작업 이외에는 다른 작업에 전혀 관심이 없는 수행자. 이러한 상황이 발생되는 순간은 늘 프로젝트가 삐걱거릴 확률이 높습니다. 프로젝트 초반에서는 어떻게든 진행은 되겠지만, 막바지 후반으로 갈수록 이슈와 위험들을 숨기게 되며, 서비스 오픈 시점에 되어서야 (혹은 한참 지나서야) 그러한 이슈와 위험들이 불거지고, 이때 대처하기 시작하면 많은 비용의 손실이 발생할 수 밖에 없습니다.

SW 개발은 수평적인 개념의 역할과, 여러 역할과 작업을 수행할 수 있는 토탈 작업자들이 많으면 많을수록 많은 위기가 기회로 바뀔 수가 있을 것입니다.