예전 개발자들의 대부분의 성향은 자신이 개발하는 것에 대한 책임감이 무척 강해서, 자신이 만든 소스들이 자신의 자식인양 애지중지 한적이 많았다. 그래서 자신의 코드 부분에서 버그가 발생되면 누구보다 앞장서서 수정하고, 전반적인 책임을 가지고 진행을 하는 모습을 많이 보아왔다.
그런데, 당시에는 Unix내 모듈단위 개발이라, 실제 컴파일하기 위한 Object 파일은 많아도 50개 내외였다. 물론 코드 라인 수는 많아서, 복잡하게 보이기는 했지만, 역할이나, 기능은 요즘 통합 시스템 로직에 비하면 매무 심플한 구조였다. 요즘은 하나의 시스템 내에서 동작되는 규칙은 매우 복잡해지고, 다양한 기능을 수행하다보니, 예전 처럼 1인 프로그래머로 개발하기에는 버거운 구조를 갖추게 되었다. 최소한 2~3인이 팀이 여러 개의 팀으로 구성되어 하나의 시스템을 구축하곤 한다. 그러다 보니, 점점 자신의 코드라는 개념은 서서히 사라지고, 버그는 모두 함께 해결해야 하는 로직적 버그가 많아지기 시작했다. 혼자 해결하기는 점점 어려워지고, 같이 협업해서 없애려고 노력한다.
그런데, 간혹 구세대 프로그래머처럼 자신이 손댄 코드들은 모두 자기 것이라고 판단하고 공유하지 않은 채 혼자만 안고 가는 프로그래머들이 종종 눈에 띈다. 이해는 할 수 있다. 이 코드들은 자신이 이해해서 구성/수정하면서 구축해왔고, 자신 밖에 모르기 때문에, 자신의 자리보전을 위한 중요한 무기가 될 수 있다고 생각하는지도 모르겠다. 점점 노쇠해가는 자신의 능력 대비 서서히 줄어가는 자신의 업무를 바라보면서 말이다.
개인을 바라보면 이해는 하지만, 이것이 팀 그리고 회사의 입장에서 보면, 매우 암적인 존재라는 사실이다. 들어가면 나오지 않는 블랙홀 같은 소스 저수지가 되어가고, 그 만큼 그 사람에게 의존은 하는데, 원하는 퀄리티는 나오지 않아, 매번 회사는 고객에게 욕을 먹는다. 퀄리티가 좋아도, 기한을 맞추지 못하는 괴이한 상황에 빠진다. 그렇다고, 인원을 충원해도 방법이 없다. 블랙홀에서 나오지 않는 코드와 기술은 후임자에게 전달되지 않으니까. 결국 남는 것은 자신에게만 쌓이는 일거리들 ( 유지보수, 개선 사업 등등 )이고, 빠르게 해소되지 않는 병목의 주요한 원인이 되버리는 것이다. 프로젝트는 이 개인에 집중하게 되고, 해결, 개선은 보이지 않게 되는 것이다.
냉정하게 바라보자. 결과적으로도 문제지만, 애초의 시작자체가 잘못되었다는 것을 확인할 수 있다. 마치 자신이 손댄 코드나, 자신의 기여한 코드는 자신의 코드이므로, 이 제품자체의 소유가 자신의 것이 되었다고 생각하는 그 자체를 말이다.
진짜 자신이 손댄, 기여한 코드는 자신의 것인가? 이 질문을 던지는 원인은 바로 그 소스코드들이 생긴 흐름 전체를 바라볼 때 생각을 해보도록 하자는 것이다. 먼저 그 소스코드를 만들 때, 자신의 돈과, 시간이 전부 들었는가? 부터 시작할 수 있다. 애초에 자신이 가진 돈을 가지고 자신을 고용하고, 자신의 개인적인 시간을 투자하여 개발했냐는 것이다. 대부분 회사 내 소속된, 팀에 소속된 경우에는 애초에 이 부분에 해당되지 않는다. 돈은 고객에서부터 나와 회사에서 지급된다. 그리고 온전히 자신만의 소스라고 말하기 어려운 것은, 소규모 1인 프로젝트와 같은 것이 아닌 이상, 1인 개발로 처음부터 끝까지 하는 프로젝트는 거의 없다는 사실이다. 대부분 선임자, 혹은 후임자가 함께 설계하고, 코딩을 하고, 같이 고민해서 해결하게 된다. 물론 일부 로직은 전부 자신이 짜기도 하지만, 제품 단위로 볼 때, 과연 제품 전체 자신만의 코드들로 가득 차 있냐는 것이다. 결국 당위성을 말하기 어렵다는 것이다.
혼자 문제 수정 및 개선 작업을 했으니 이제 내 제품이 되었다고 반론하고 싶은가? 그렇다면, 무엇을 근거로 수정하고, 개선 작업을 했다는 것인가? 만일 그렇다면, 해당 소스 코드 없이, 완전히 빈 프로젝트(솔루션)을 열어 지금 자신이 수정/개선하는 프로젝트를 비슷하게라도 만들어 낼 수 있을까? 애초에 이런 것이 불가능하다면, 온전히 자신의 소스라고 말할 수 없다는 것이다.
개발작업이나 개선작업은 쭉 수행해온 부분에 대해서 존중 받아야 되며, 그 기술에 대해서 인정해주어야 한다. 하지만, 그 소스와 기술은 홀로 안지 말고, 회사 구성원, 팀 구성원과 공유해야 한다. 자신의 기술을 뺏기는 것이 아니고 나눈다고 생각하도록 한다. 평생 그 프로젝트만 하면서 노닥거릴 생각이라면 모르겠지만, 자신의 직위와 급여가 오르고, 다양한 경험을 요구 받는 입장이면, 이제 과거에 만들었던, 개선, 수정 했던 프로젝트들은 같은 구성원에게 건네 주고, 새로운 업무에 뛰어들어 더 발전된 모습을 보여주어야 한다. (그냥 무턱되고, 왜 내 급여는 왜 안 오르냐고 따지지 말고 말이다. )
이번에 사내에 프로젝트 관리 솔루션을 하나 작게 구축했다. 개인적으로 사용하던 프로젝트 관리 솔루션을 통해 얻은 경험들을 기반으로 이번에 무료 솔루션 중, 이질감이나 관리의 편의성이 좋은 제품을 도입해봤다. 구축해보고, 테스트해보고, 내가 담당한 프로젝트를 등록해봤다. 사실 프로젝트의 성공적인 수행을 위한 관리라는 포커스 보다, 프로젝트 이력 관리라는 측면을 강조한 구축이라고나 할까…
구두로 형식적인 인수인계가 아닌 실질적인 히스토리를 공유할 수 있는 그런 공간 말이다.
제발 이제 이런 암적인 존재인 프로그래머들이 이런 솔루션 속에 녹아내리면서 암적인 유전자 변이가 좀 제 정신을 차릴 수 있도록 할 예정이다..(뭐 말기면 쳐내야 겠지만 )
하인도1
[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.
