프로그래밍 영웅과 독불장군?!

원본 클릭

프로그래밍 영웅과 독불장군

출처 : 'Professional 소프트웨어 개발' , 스티브 맥코넬

부족한 기술 인력과, 너무 낙관적으로 일정을 잡는 일반적 성향을 더하면 어떤 일이 일어날 것 같은가?
그렇다. 이제는 일당백의 능력을 가진 프로그래밍 영웅(programming hero)을 말할 차례다.

프로그래밍 영웅은 항상 자기 능력을 시험해 볼만한 일을 선택하고, 어마어마한 코드를 써 나간다.
그런 사람은 대부분 야근을 밥먹듯 하고, 곧 프로젝트에서 절대로 빼놓을 수 없는 사람이 된다.
성공은 그들의 어깨에 달려 있는 것 같이 보인다.

프로젝트 관리자는 이 영웅 프로그래머를 사랑하지만, 두려워하기도 한다. 그들은 똑똑하지만,
성미가 까다롭고 독선적인 성격인 경우가 많다. 그러나 그들이 없는 프로젝트 수행은 상상할 수 없다.
수급 불균형 노동 시장에서 그들을 대체하는 것은 절대로 선택 사항이 아닐 것이다. 그러나 안타깝게도
엄청난 양의 코드를 뽑아내는 능력이 있는 대부분의 프로그래밍 영웅들은 다른 사람들과 같이 일하는
방법을 모른다는 치명적인 요소가 있다.

이런 사람들은 대부분의 설계 정보와 소스코드를 자기만 볼 수 있도록 숨겨놓고,  테크니컬 리뷰
(technical reviews)에 참여하는 것을 거부한다. 또, 팀이 정해 놓은 표준을 따르지도 않는다.
이러한 행동들은 결국 다른 팀원들의 프로젝트에 가치있는 공헌을 할 수 있는 기회를 박탈하게 된다.
많은 프로그래밍 영웅들은 결국 전혀 영웅이 아니다. 그들은 단지 프로그래밍 독불장군일 뿐이다.

개개인의 탁월한 능력이 프로젝트 성공에 큰 영향을 미칠 수도 있지만, 일반적으로는 팀워크가 더
큰 영향을 미친다. IBM의 연구에 의하면 평균적인 프로그래머는 약 30%의 시간만 혼자 일하는
데 보내고,나머지 시간은 팀 동료나 고객 같은 다른 사람들과 같이 일하는데 쓴다.
31건의 소프트웨어 프로젝트들을 조사한 결과, 전체 생산성에 가장 큰 영향을 미치는 요소는
바로 팀의 융합이라는 것을 알 수 있었다. 물론 개개인의 능력도 생산성 증가에 공헌하지만, 팀 융합이
더욱 큰 힘을 발휘한다. 많은 사람들이 자신의 능력을 더 높일 수 있는 도전적인 프로젝트에 참여하고
싶어한다. 그러나 자신의 한계를 테스트하려는 의지가 있고 효과적인 소프트웨어 개발 지침들을따르며
지속적으로 동료와 협업하는 사람만이 진정한 프로그래밍 영웅이고, 프로젝트에 참여할 자격이 있다.

포스팅 출처 : http://kldp.org/node/43548

=======================================================

우연히 이 글을 보게 되었는데요. 느끼는 점이 많아 함께 공유하고 싶었습니다.
대학교때 진행했던 프로젝트나 현재 회사에서 하는 프로젝트들을 돌이켜볼때 혹시라도
나 자신이 독불장군은 아니었나 말입니다.

대학교때 실버라이트 프로젝트를 시작할때 팀원들의 프로그래밍 실력은 제각각이었긴 했지만
팀원모두 실버라이트에 대해 잘 모르고 있었기때문에 같은 선상에서 시작하겠구나 생각했습니다.
어찌보면 모험이었지만 한번 해보자는 분위기로 시작했지요.
저의 경우엔 팀장이란 역할을 맡고 있어서 밤새 MSDN과 씨름하고 들리지도 않는 영어로 된 동영상
강의를 보면서 스킬을 하나 둘 익혀나갔습니다.

하지만 시간이 지나면서 알게 모르게 프로젝트 전체에 대한 저의 비중이 커지기 시작했습니다.
그리고 팀원들은 실버라이트를 어렵게 느끼기 시작했으며, 점차 흥미를 잃어가는 것이 보였습니다.
다만 몇몇만이 지금까지 완성된 코드를 보며 힘겹게 따라오는 듯한 느낌이 들었지요.

테크니컬 리뷰를 더욱 자주 하고 싶었지만 어떻게 해야 효율적인지 잘 몰랐고, 후반부에는 바쁜 일정에
쫓기다보니 성과 없는 리뷰의 효율에 대해 의심이 들기 시작했습니다. 또한 많은 양의 코드를 뽑아내는데는
익숙했지만 다른사람들과 같이 팀웍을 한다는게 아직은 어렵게 느껴지기 시작했습니다.
돌이켜보면 비록 프로젝트 결과는 성공적으로 마쳤을지 모르지만 프로젝트 과정은 실패했다고 생각합니다.



대학교 프로젝트라서 그렇겠지.. 했지만.. 문제는 그 다음 프로젝트에서도 반복되는 것 같다는 점입니다.
일단은 자바 개발 경험이 있는 사람이 적은 상태에서 자바로 프로젝트가 시작되었고, 도메인 역시 생소하긴
했지만 일정상에는 기간도 길고 문제가 없어보였습니다.

그러고보니 위의 글에서 첫 문장의 조건이 되는군요..
"부족한 기술 인력과, 너무 낙관적으로 일정을 잡는 일반적 성향을 더하면 어떤 일이 일어날 것 같은가?"

구현단계에 오니 문제점들이 드러나기 시작했습니다. 디자인할때 인식하지 못했던 구현상의 문제들을 해결하거나
좀더 효율적으로 처리하기 위해 많은 알고리즘들이 삽입되고 패턴들이 적용되었습니다. 그러다보니 디자인때보다
더 많은 클래스들이 생겨나고 복잡해 보이기 시작했습니다. 저는 그 당시 뛰어난 아키텍쳐의 부재를 아쉬워하며..
이렇게 해야 확장이 쉽고 유지보수에 좋습니다. 라는 말로 설득시켜 모든 짐을 지고서 팀을 끌고왔습니다.
그때그때 팀원들의 이해를 돕기위해 많은 PPT를 준비하고 코드리뷰에도 적극적으로 참여했습니다만
문제는 언제부터인가 제가 전체 프로젝트의 80%이상의 코드를 손대고 있고 팀원들이 제 코드중 핵심 코어부분을
블랙박스라고 부르는데 있습니다.

위 글 중 영웅이고 머를 떠나서  '자기 능력을 시험해 볼만한 일을 선택하고, 어마어마한 코드를 써 나간다' 라는
말에 동의는 합니다만 제가 성미가 까다롭거나 독선적이진 않습니다. 또한 공유는 저의 일상생활이구요.
그리고 기술적인 토론을 좋아하고 언제든지 피드백에 제 자신을 채찍질 할 준비가 되어있습니다.

다만, 팀워크와 관련된 결정에 있어서 딜레마에 빠질까봐 걱정이 됩니다. 그리고 혼자 너무 많은 일을 맡으려
하는 성격(다른사람에게 일을 막 못시키는)도 협업을 할때 풀어야할 과제가 아닐까 생각해봅니다.