2009년 1월 13일 화요일

잔말 말고 시키는 대로 해

소프트웨어를 개발하는 현장에서는 매우 합리적인 척하는 가면을 쓰고 벌어지는 수많은 비 논리적인 판단과 결정을 자주 보게 됩니다.

약장사처럼 "이 약만 먹어봐 끝내줘!"부터 아주 사소한 이슈까지 정말 다양한 문제들이 비효율적으로 의논되고 합리적이지 않은 결정이 이루어 집니다.

물론 PI(Process Innovation)을 하다 보면 "잔말 말고 시키는 대로 해!"라고 하고 싶은 때가 종종 있습니다. 모든 이슈를 모두에게 합리적으로 납득시키고 이끌어가는 것이 오히려 비효율적이고 또는 거의 불가능할 때 이런 생각이 듭니다. 소프트웨어 개발에 관련된 이슈는 상대방과 반대의 생각을 가지고 끝까지 반박을 하면 끝도 없는 논쟁으로 빠뜨리는 것이 그리 어려운 일이 아닙니다. 물론 득도 없죠.

C가 좋나? C++이 좋나? 
CBD방법론이 좋나? OO방법론이 좋나?
Java냐? .NET이냐?
무슨 프레임웍을 써야 하나?
스펙을 자세히 적어야 하나? TDD를 사용해야 하나?
설계는 UML를 써야 한다. Use case를 그려야 하다.

이 중에 쉽게 결정할 수 있는 이슈는 하나도 없습니다. 
회사마다 비즈니스 상황이 다 다르고 고려해야 할 환경이 제각각이기 때문입니다.
암에 걸린 사람에게 내가 침 맞아서 나았다고 다른 암환자에게 침만 맞으면 낳는다고 하는 것처럼 위험합니다.

하지만 자신이 아는 것이 침술 밖에 없다면 또 침술로 먹고 살아야 하는 사람이라면 그렇게 침이 최고라고 주장을 하겠지요.

.NET위주로 개발을 한 개발자가 사내의 모든 개발이슈에서 자신이 아는 것이 .NET이라는 이유로 모든 관련 의사 결정에서 .NET으로 개발하도록 관철하는 것과 비슷합니다. 물론 그 이유로는 "내가 아는 것은 .NET밖에 없다"라고 하지는 않고 온갖 그럴듯한 이유를 대지만, 이미 마음을 정해 놓은 마당에 합리적인 결정은 물 건너 간 것이지요. 그로 인한 손해는 회사와 개발자들이 몇 년 후에 고스란히 감수를 하게 됩니다. 코딩 망쳐서 버그 잔뜩 만들어 낸것과는 비교과 안되는 막대한 비용을 치뤄야 합니다.

또 회사의 역량이나 환경이 다른데 특정 방법론을 무조건적으로 기계적으로 적용하는 것 또한 비슷한 경우입니다. 이 경우 과거처럼 주먹구구식으로 개발하는 것이 오히려 나은 경우도 많습니다.

본인이 뛰어난 개발자라고 생각한다면 또는 뛰어난 엔지니어가 되고 싶다면 고집은 필요하겠지만 아집은 버려야겠습니다. 그리고 합리적인 결정을 하는 훈련이 필요합니다. 이것이 개발자가 성장해나가는 필수 단계입니다.

댓글 6개:

  1. 공감합니다.
    개발을 하면 할수록 느끼는 점은 "Balance"가 중요하다는 점이지요.

    답글삭제
  2. 헝그리맨님 안녕하세요.
    "균형"은 소프트웨어 뿐만 아니라 인생의 원리 아닐까요?

    답글삭제
  3. 저는 윗 분들께 "믿어 보시라니깐요?"라는 말을 많이하는 것 같습니다. 올해는 좀 더 균형?있게 윗 분들과 균형있는 대화를 할 수 있도록 노력해야 겠습니다. 혼자 막~ 달려가고 넘어지고... 욕하고... 후회한... 작년... 그것이 문제였습니다. 이제 윗 분들도 손잡고 함께 달려갈 수 있도록 균형있는 설득을 해 봐야겠습니다. ^^;

    답글삭제
  4. 정의의소님 안녕하세요.
    "믿어 보시라니깐요?"방법이 좋다 나쁘다 말하기 어렵네요. 가장 좋은 방법일 수도 있습니다. 신뢰관계가 있다면요. 사실 모든 일을 설득하고 납득시켜서 하기는 어려운 것 같습니다. 윗분들이 아랫사람의 전문성을 어느 정도 믿어 주는 것이 가장 좋죠. 그만큼 전문성을 갖추고 있어야 할듯.

    답글삭제
  5. 맨 마지막의 글귀인
    '합리적인 결정' , 이 내용이 귀에 들어 오네요
    동료의 의사는 무시한 채 일방적인 생각은
    성장에 저해되는 요소가 아닌가 싶습니다.

    답글삭제
  6. 마음의꿀단지님 안녕하세요.
    말은 쉽지만 참 어려운 일인 것 같습니다.

    답글삭제