잔말 말고 시키는 대로 해

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

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

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

C가 좋나? C++이 좋나? 

CBD방법론이 좋나? OO방법론이 좋나?

Java냐? .NET이냐?

무슨 프레임웍을 써야 하나?

스펙을 자세히 적어야 하나? TDD를 사용해야 하나?

설계는 UML를 써야 한다. Use case를 그려야 하다.

이 중에 쉽게 결정할 수 있는 이슈는 하나도 없습니다. 

회사마다 비즈니스 상황이 다 다르고 고려해야 할 환경이 제각각이기 때문입니다.

암에 걸린 사람에게 내가 침 맞아서 나았다고 다른 암환자에게 침만 맞으면 낳는다고 하는 것처럼 위험합니다.

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

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

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

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