엔지니어가 정말 일하기를 원하는 회사를 운영하는 방법

무엇 무엇하는 10가지 방법식의 이야기는 매우 싫어하지만 그래도 생각을 전달하는 가장 좋은 방법이라는 것도 인정한다.

소프트웨어 회사를 운영하는 입장에서 현재 우리의 상태가 어떤지 판단해 보기에 적절하다고 생각되는 글이 있어서 10가지 방법 류의 글이지만 한번 되새겨 본다.

항상 그렇듯이 원문은 다음아래와 같다.

How To Run A Company That Engineers Actually Want To Work For

1. 계층구조는 버려라 - 평등한 환경이 가장 좋은 결과를 가져올 것이다.

현재까지 우리의 회사는 우리의 회사라는 이름과 같이 매우 평등하다. 회사가 조금이라도 성장하여 다른 구성원이 들어오기 전까지는 문제가 되지 않을 것 같다.

2. 숙련된 동료와 최신의 도구를 제공하라.

숙련된 동료는 확신할 수 없지만 최신의 도구를 제공한다는 점에서는 일단 합격이다. 회사의 이윤이 나면 더 좋은 도구들을 제공할 계획이다.

3. 편안함은 중요하다.

현재는 아주 편안하다. 사무실이 일반 주택이기 때문에 매우 편안하다.

4. 다양한 경험을 제공하라.

매일 매일이 새로운 경험이다. 그런데 공동 창업자들 이외의 다른 사람에게 다양한 경험을 제공하려면 고민이 좀더 필요하다고 생각된다.

5. 도전할 과제를 제공하라. - 그러나 프로그래밍은 단거리경주가 아니라 마라톤이다.

먹고 사는 문제가 걸렸으니 매우 도전적이다. 그러면서도 죽어라 일만 하지 않으니 잘한다고 해야 할지 아니면 태평하다고 해야 할지 모르겠다.

6. 프로그래머는 가치있는 일을 만들고 그 결과를 보는 것에 동기부여된다.

세상의 모든 일들이 그렇다고 생각된다. 그리고 이렇게 하기 위해서 사업을 시작했으니 이점도 합격이다.

7. 협상이 불가능한 데드라인을 강요하지 마라.

각자 계획을 세우고 일을 진행하고 있다. 스크럼이란 것을 일하는 방식으로 사용중인데 쉽지만은 않다.

8. 몇주앞의 일정만 계획하고 너무 세부적인 관리를 하지마라.

2주정도 계획으로 일을 하고 있다. 관리는 안한다는 것이 기본 원칙이다.

9. 더 좋은 의사소통 방법을 장려하라.

의사소통은 잘되고 있는데 더 좋은 의사소통 방법은 잘 모르겠다.

10. 유연함이 매우 중요한 요소이다.

이 부분은 좀더 고민이 필요하다. 다른 사람의 의견을 받아 드리고 구성원 전체가 자유롭게 의견을 개진하며 틀린 이야기라고 끝까지 듣을 자세가 되어 있는지는 솔직히 의문이다.

문제는 현재가 아니라고 생각된다. 회사가 성장한 후에도 이런 회사를 만들 수 있을 지가 관건이다.

Control in its wider sense

제목을 짓는 귀찮음을 피하기 위하여 이글을 쓰게된 영감을 준 블로그의 제목을 그대로 이용하기로 했다. 블로그 제목을 그대로 사용하는 것도 넓은 의미에서 표절이라 볼수 있지만 그냥 내 마음대로 괜찮을 것이라고 생각하기로 했다.

Control in its wider sense 이글이 위에서 언급한 영감을 준 블로그이다. 신뢰의 중요성 그리고 회사에서의 조직 구성원에 대한 통제에 대한 반대를 간단하게 언급한 글이다.

현실적으로는 참 어려운 이야기인 것 같다. 그래서 왜 이런 철학들이 실제 회사 운영에서는 이루어 지기 힘든지에 대하여 생각해 보았다. 회사에서 적당한 통제가 필요가 이유는 2가지라고 생각된다.

첫번째는 바로 통제를 위한 통제일 것이다. 아주 부정적인 표현이기는 하지만 사람에 대한 신뢰가 없기 때문에 그 사람을 통제하는 것이다. 위에서 언급한 블로그에서는 이런 것은 아니라고 말하고 있다. 조직원을 믿으면 통제할 필요가 없을 것이다.

두번째는 바로 협업이 필요하기 때문의 통제일 것이다. 다른 사람을 통제하여야만 협업이 잘 되는 것은 아니겠지만 적당한 규율은 협업을 하는데 꼭 필요한 요소일 것이다. 간단히 생각해보아도 회의시간을 결정하기로 했다면 모든 사람이 회의에 참석하도록 통제하여야 할 것이다.

 

조직 구성원들을 믿고 그들을 통제하지 않는다. 이렇게 하기 위해서는 어떻게 해야 할지 앞으로 더 고민해 봐야겠다. 결과는 같지만 어떤식으로 실행하지를 고민해 봐야겠다. 사실 어느정도 밑그림은 있지만 그것이 과연 타당하거나 가능한 것인지에 대하여 더 많은 고민을 해 봐야 겠다.

다니고 싶은회사, 만들고 싶은회사

돌이켜 생각해보면 길지 않은 직장생활동안 참 많이도 힘들어 한거 같다. 어떤 때는 조직 부적응이 아닌가 고민도 많이 했었다.

 

이제 한달정도 더 근무하면 그만둘 회사에 신종플루 관련하여 보다 적극적인 주문을 하는 글이 계시판에 올라왔는데 다시 그 글에 조직문화팀이라는 신종플루 대책을 담당하는 부서의 사람이 다시 댓글을 달고 개인의견이라고는 명시했지만 비판을 달고 어쩌고 난리인걸 보고 아래 글을 적었다.(뭐 내용은 뻔하다 소독, 마스크, 체온의 관리 등)

 

이제 그만둘 회사 어떻게 되던 무슨 상관이라고 이런 글을 주절주절 적고 있는건지 하는 생각에 3분정도 고민하다가 계시물을 삭제하고 블로그로 옮긴다.

 

이제 회사를 시작하는 입장에서 고민이 많다. 과연 내가 만든 회사에 다른 사람을 고용할때에도 내가 고용자로 일할때 회사에 바라는 정도의 것을 해 줄수 있는지 하는 것이다. 같이 일을 시작하는 친구는 1년의 2달간의 유급휴가 또는 무급휴가 겨울철의 2일의 주중휴가를 나는 사용하겠다고 요구하니까 다음과 같이 말하기는 했다.

지속 가능성의 문제인데 과연 우리회사가 현재 너가 하고 싶은대로 모든 종업원에게 다 해줄 수 있는지를 생각해라.

참 도덕적인 답변이기도 하고 어려운 문제이기도 하다.  내 생각은 분명히 다른 것 같은데 그것이 말하기에 비도덕적이라서 그런지 아니면 정말 모르는 것인지 말로 옮겨지지가 않는다. 의식적인 무시 정도의 수준이랄까.

 

내가 나중에 회사를 경영하고 있을때 다시 신종플루가 유행한다면 나는 과연 다음의 글과 같이 말하는 직원의 요구를 수용할 수 있을 것인가?

 

솔직히 우리회사가 적극적인 대응을 하는 것은 아니라고 생각합니다.

많은 이유가 있겠지만 결국 비용의 문제라고 생각합니다.

 

"신종플루 발생자는 병가를 이용하여 완치시까지(최대 3주)까지 쉴수 있다."

"신종플루 의심만 생겨도 2주간의 병가를 낼 수 있다."

"신종플루 발생자가 생긴 부서는 전체 부서가 재택근무를 한다."

 

이정도 되어야 적극적인 대응이라고 생각합니다.

하지만 우리회사에서는 불가능 하겠죠.

하지만 이렇게 하는 조직들도 있습니다.

제가 근무하는 공공기관에서는 첫번째를 시행하는 것 같습니다.

 -> 우리회사는 개인휴가 사용이고 다 소진한 경우 재택근무를

      리더재량으로 결정하고 안되면 내년도 휴가를 쓰게 되어 있군요

     글을 쓰다가 계시판을 보고 알았습니다.

NHN에서는 현재는 모르지만 신종플루 초기대응시 3번째를 했었다고 합니다.

현재는 어떤지 잘 모르겠습니다.

2번째는 하는 곳이 있는지는 모르겠네요. 있다면 참 근무 하고 싶을 것 같습니다.

 

신종플루에 걸리면 해고 될까봐 비밀로 하고

출근하는 열악한 회사에 근무하는 사람들도 있다고 뉴스에 나왔습니다.

최소한 우리회사는 이렇지는 않아서 다행입니다.

 

조직문화팀에서 많은 고민이 있을 것이라고 생각이 들지만,

결국은 고민으로만 머무르고 실제로 진행되는 것은 말씀하신

부분적인 것일 겁니다.

솔직히 우리회사 대응이라는게 그저 그런 생색내기라고

생각이 드는 것은 어쩔수가 없네요.

 

어렵겠죠. 안되는 일이겠죠. 그렇지만 하고 싶은 말은

우리회사의 모습은 적극적인 대응은 아니라는 겁니다.

현실을 최대한 반영한 대응이라고 하는 점은 인정하겠습니다.

 

마지막으로 얼마전 SBS 스페샬에 신종플루 특집으로 정말 치사율이 높은

플루가 도는 경우에 어떻게 될지 신종플로 감영자의 인터뷰를 바탕을 만든

가상 시나리오를 본적이 있습니다.

 

그때 한 회사원의 독백 내용입니다.(기억으로 쓰는거라 의미만 받아들이시면 됩니다.)

"플루가 유행이다. 회사에도 감염되어 죽은 사람이 있다. 올해의 휴가는 다 사용하였다.

내일부터는 회사에 가야한다. 그런데 가면 어떻게 될까? 그렇다고 가지않으면 회사에는

어떻게 할까? 해고될까? 그렇다고 출근했다가 플루에 걸리면 어떻게 될까?

나도 죽을지 모른다."

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

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

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

 

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