게으른 개발자가 될 수 없는 이유

게으른 개발자가 일을 더 잘한다 라는 글을 소개하면서 이야기를 시작한다.

게으른 개발자가 되라! 라는 글도 한번 읽어 볼만한 글이다.

Why Good Programmers Are Lazy and Dumb 한층 더 나아가 둔해야 한다고 말하는 글도 있다.

 

건방지지만 3글을 한마디로 정리하면

 

계으른 개발자는 자신이 계속 게으른 상태로 남아 있기 위하여 항상 현재보다 효율적인 방법을 찾으려고 노력하고 그때문에 결국 게으른 개발자가 더 일을 잘하는다는 내용이다.

 

반어적인 표현이기는 하지만  이 글들을 읽어면서 무척이나 동감이 되었다.  "불필요한 일을 하지 않는 것이 가장 효율적인일이고 그렇게 하기 위해서는 가장 효과적으로 일을 해야 한다."라는 나의 생각과 많은 부분에서 일치하였기 때문이다.

 

하지만 나와 생각이 비슷한 이 글들을 읽고 나니 나는 왜 항상 부지런한 개발자가 되어서 프로젝트 현장에서 삽질을 하고 있을가 하는 평소의 나의 의문이 더욱더 커져만 간다. 게으른 개발자가 되기 위하여 항상 고민하고 노력하고 시도하지만 그렇게 안되는 것은 무엇때문에 그런지 갈수록 알수가 없었다. 고민고민해서 현재까지 내가 생각하는 이유를 한번 적어보고자 한다.

 

첫째, 프로젝트에서 어떤 일을 어떤 방식으로 할지에 대한 의사결정권자와 실제 그 일을 하는 사람이 다르기 때문에 게으른 개발자는 살아남기 어렵다. 특히 의사결정권자의 권한이 매우 큰 우리나라 프로젝트 현실에서는 더욱더 그렇다.

 

이런 경우 게으른 개발자는 단순히 일을 못하거나 과격한 말로 개기는 개발자가 되기 십상이다. 의사결정권자는 자기가 할 일이 아니기 때문에 불필요한 일을 없애려는 노력도 하지 않고 심한 경우 자신이 해야한다고 결정한 일이 비 효율적이고 불필요한 일이라는 인식도 가지지 못하는 경우가 많다.

 

프로젝트 과정에서 의사결정권자는 순서는 일반적으로 다음과 같다.

고객, 외부감리 > 내부감리, PM > 품질담당자, PL  >  개발자

 

이런 사항에서 불 필요하고 불 합리한 일을 하는 개발자는 부지런해 지던지 아니면 자신에게 쏟아지는 많은 비판을 감수하면서 일을 진행하다가 지쳐가는 상황에 처하기 싶상이다.

 

소규모 SI(10억 내외)를 진행하면서 50억이상의 대규모 프로젝트에 적용하는 것이 적당한 방법론의 강요, 모든 최신의 품질검토기술은 모두 적용하기를 바라는 것, 보기에는 정말 멋지게 문서(워드, 액셀, 파워포인트, 한글)로 프로젝트 관리를 하기 위한 샘플을 만들지만 그것을 실제로 작성하고 현행화하는 것은 불가능에 가까운 과업이라 결국은 형식적으로 작성되고 마는 산출물의 강요등과 같은 일이 실제 프로젝트 현장에서는 끊임없이 벌어진다.

 

둘째, 지식노동자의 일반적인 특징이기는 하지만 개발자의 성과를 의자에 앉아 있는 시간으로 생각하는 관리자의 특징 때문이기도 하다. 특히나 우리나라는 개발자로서의 성장경로가 없어서 관리자가 되면서 개발자라고 부르지 못하는 풍토이기 때문에 게으른 개발자는 더욱더 설 자리가 없어진다. 다른 표현으로 하자만 관리자가 개발자의 성과를 제대로 평가할 능력이 없기 때문이라고도 말할 수 있다.

 

프로젝트에서 개발자의 평가는 일반적으로 프로젝트 관리를 담당하는 PM, PL과 고객이 있다. 실제로 프로젝트가 종료된 후 평가과정에서 또 다음에 새로운 일을 담당하기 위한 능력의 인정에 대한 권한을 가진 사람들이 바로 위에서 말한 계층의 사람들이다.

 

이런 사람들이 개발자의 능력을 평가하는 방식중 많은 비중을 차지하는 것이 바로 근무시간이다. 일예로 현재 진행하고 있는 프로젝트에서 비공식적이기는 하지만 고객과 PM이 개발자들의 퇴근시간을 가지고 다른 프로젝트와 비교하여 놀고 있다는 평가와 함께 알아서 기라는 지시를 암묵적으로 내린적이 있다. 이런 일은 많은 프로젝트에서 실시하는 근태관리 방식을 봐도 알 수 있을 것이다. 간단히 출근은 정시에 퇴근은 일 마칠때까지라는 근태관리 방식에서 일하고 있는 개발자가 게을러 질수 있을 지는 누구나 알 수 있는 사실이다.

 

이런 상황에서 특히 근무시간이 매일 보고되는 프로젝트 상황에서 자신의 근무시간표에 출근 9시, 퇴근 6시를 찍을 수 있는 사람은 별로 없을 것이다.

 

마지막으로 새로운 방법의 시도는 그것이 기술적인 것이던 프로세스적인 것이던 검증의 책임은 시도하는 사람의 것인 경우가 많으며 그것 또한 대부분의 경우에 객곽적인 데이터라는 듣기에는 좋지만 만들기는 힘든 어떤 것을 요구한다.

 

마지막 원인은 특히 한명의 개발자가 혹은 게으른 개발자의 집합이 모든 프로젝트에 대하여 책임이 없는 경우에는 절대적인 원인이 되는 경우가 많다. 팀문화의 문제인데 문제는 보통 갑을병정 관게로 묶여있는 경우 개발자가 아닌 고객이 개발자가 아닌경우 더욱 더 큰 문제가 된다.

 

 

이런 이유들을 생각해 보면 게으른 개발자가 되기 위해서는 개인의 노력보다는 조직적인 문제가 해결되어야 한다고 생각한다. 우리나라 개발자들의 실력이 없는 것은 결코 개발자들 개인의 문제가 아니라고 생각된다.

 

PS.내가 이제껏 그리고 현재도 참여하고 있는 프로젝트가 공공사이트의 SI이기 때문에 그런점에서 이글은 편협한 생각이라고도 할 수 있다.