2015년 3월 28일 토요일

개발자간 공유 문화 정착이 힘든 이유

소프트웨어를 개발하는데 있어서 가장 중요한 문화  하나는 '공유’ 문화라고   있다소프트웨어개발 속도를 향상하고 비용을 절감하며 프로젝트 성공 확률을 높이는 중요 요소다뿐만 아니라 개발자들의 실력을 향상하고 개발자가 20, 30 계속 개발자로 일할  있도록 하는 기초 체력이기도 하다

하지만 우리나라에서 공유 문화를 제대로 갖추고 있는 회사를 찾아보기란 그리 쉽지 않다 주변에는 소프트웨어 개발 문화에 관심을 가지고 있는 개발자가 많다특히 공유문화에 관심이 많아서 실천을 하려고 노력하는 경우도 많다하지만 그런 노력의 결과로 성공적으로 개발문화를 정착했다고 하는 소식은  들려오지 않는다 이유는 무엇일까?

여러 가지 이유가 있겠지만   번째는 아직 공유에 노력을 하는 개발자들이 소수이기 때문이다

죄수 딜레마라고 들어본 적이 있는가

상황은 다음과 같다 명의 사건 용의자가 체포되어 서로 다른 취조실에서 격리되어 심문을 받고 있다이들에게 자백여부에 따라 다음의 선택이 가능하다.
      하나가 배신하여 죄를 자백하면 자백한 사람은 즉시 풀어주고 나머지  명이 10년을 복역해야 한다.
     모두 서로를 배신하여 죄를 자백하면  모두 5년을 복역한다.
     모두 죄를 자백하지 않으면  모두 6개월을 복역한다.

죄수A 죄수B 침묵할 것으로 생각되는 경우 자백을 하는 것이 유리하다죄수B 자백할 것으로 되는 경우 자백이 유리하다따라서 죄수A 죄수B 어떤 선택을 하든지 자백을 선택한다.
죄수B 죄수A 동일한 상황이므로마찬가지로 죄수A 어떤 선택을 하든지 자백이 유리하다.
따라서  모두 자백을 하지 않는 것이 최선의 결과이지만 죄수 A, B  모두 자백을 선택하고 각각 5년씩 복역한다는 것이다.

이런 죄수딜레마를 게임으로 시뮬레이션을 해보면 죄수 둘이 서로 의논을 하게 하건죄수가 2명이 아니라 여러 명이건 상관없이 비슷한 결과가 나온다고 한다.

도로로 나가보자조금 막히는 교차로에서는 교차로 꼬리 물기가 아주 흔하다아무리 막히는 교차로라고 하더라도 꼬리물기를 하지 않으면 다같이 평균적으로  빨리 교차로를 빠져나갈  있다하지만 대중은 그런 선택을 하지 않는다다들 꼬리 물기를 하는 상황에서 나만 교통법규를 지키고 가만히있으면 교차로를 가장 늦게 통과하게  것이다심지어는 주변의 차들에게 욕먹을 각오도 해야 한다.꼬리 물기를 하는 차가 다수인 상황에서는 교통법규를 지키는 소수가    손해를 보게 되어 있다그래서 어쩔  없이 다같이 손해를 보는 경우를 선택하게 된다.

   가족과 함께 괌의  리조트를 방문한 적이 있었다하지만 여기서 부끄러운 일을 목격했다수영장에는 충분한 선배드가 있는데 아침 9시쯤 수영장에 가보니 모든 선배드가 이미 임자가 있었다선배드에 타올을 하나씩 걸쳐 놓았지만 선배드에서 쉬고 있는 사람은 하나도 없었다 시간 나타난 선배드의 주인을 보니 모두 한국사람들이었다아침 일찍 일어나서 일단 선배드를  해놓고아침식사를 하러  것이었다사실 선배드는 모든 사람이 충분히  만큼 많았다하지만 이용도 하지않으면서 먼저 찜을 해놓으니 다른 사람들은 전혀  곳이 없게  것이었다한국에서는 이런 현상이후로 수영장의 선배드 이용이 유료로 바뀐 것으로 알고 있다외국에서는 이로 인해 어떻게 바뀔지,바뀌었는지   없다어쨌든 낯부끄러운 일이었지만 다음날 아침에는 아침식사를 하기 전에 선배드  개를   놓는 일에 동참하는 우리를 발견하게 되었다.

이렇듯 죄수딜레마는 어디에서나 나타난다약속을 지키면 다같이 이익이 되고 모두 약속을 지킨다는확신이 없다면 약속은 순식간에 무너진다.

그럼규칙을 엄하게 적용하면 해결될  있지 않을까공유를 하지 않으면 벌칙을 주고 필요한 문서를 모두 만들지 않으면 승인을 하지 않아서 프로젝트의 다음 단계로 넘어가지 못하게 하면 해결할 있지 않을까이런 식으로 해결이   있었다면 우리나라의 대부분의 회사가 이미 공유문화가  정착되었을 것이다안타깝게도 엄격한 규칙적용은 그렇게 효과적이지 못하다.

첫째 만들어 놓은 규칙이 엄격하기만   공유 문화 정착에 효과적인 경우가 별로 없다왜냐면 엄격한 규칙을 만든 사람들이 대부분 공유문화를 체험해  적도 없는 사람들이기 때문이다대부분은 방법론에서 필요한 문서를 따와서 만들라고 하는데 대부분의 방법론은 공유문화와는 별로 상관이없다게다가 방법론을 오해해서 오히려 복잡하게 적용하는 경우도 허다하다.

둘째 아무리 복잡한 규칙을 만들어도 개발자들은 요령껏 적응하고 피해 다니게 된다문서를 만들라고 하면 형식 면에서는 규칙을 충족하게 만들  있지만 진짜 필요한 내용이  들어 있는지 확인할방법은 없다공유가 습관화되지 않은 대부분의 개발자들은 어쨌든 규칙만 준수하는 방법으로 진짜공유는 피해 다니게 되어 있다.

셋째 나만 공유를 제대로 하게  경우 나만 손해를   있다는 생각을 의식적으로 또는 무의식적으로 하게 된다나중에 내가 없으면 유지보수가 어려워야 나의 가치가 올라간다고 생각한다전혀 틀린얘기도 아니지만 다들 이렇게 생각하니 다같이 손해를 보는 것이다.

규칙을 통해서 공유문화를 만들어가는 것에는 찬성한다하지만 오히려 공유문화에 역행하는 규칙을만드는 것이 일반적인 상황이라서 안타깝다개발자들이 공유에 익숙하지 않은 상황에서 너무 욕심을내는 것도  된다현재 상황을  파악해서 공유문화를 만들어   있는 단계적인 접근이 필요하다개발자들이 소화할  있는 만큼의 규칙을 만들고 이것이 익숙해지는 것이 공유문화 발전 방향과일치를 해야 한다이렇게 점점 규칙을 업그레이드 시켜나가면서 회사를 조금씩 바꿔나가야 한다물론 이런 과정을 통해서 다같이 이익이  것이라는 확신을 직원들에게 심어주어야 한다.

처음부터 과욕을 부리다가는 영원히 공유문화와는 멀어지게 된다그럼 비효율이 정착된 회사가 것이다.


이글은 ZDNet Korea에 기고한 칼럼입니다.

2015년 3월 9일 월요일

야근, “악의 균형”

어떤 경영자는 “우리 회사 개발실은 밤이나 주말이나 불이 켜져 있다”고 자랑을 한다. 6개월간 개발자들이 집에도 못 들어가면서 프로젝트를 하고 있는 것을 자랑스럽게 얘기하기도 한다. 오랜 야근으로 이혼에 이르게 된 개발자를 에피소드로 소개하기도 한다. 많은 경영자들은 야근이 개발자들의 열정을 대변해준다고 생각한다.

나도 수년간 자발적으로 하루에 14시간 이상 개발을 한 적이 있다. 단기간이거나 자발적이 초과근무는 효과가 있지만 장기적이거나 강요된 야근은 효과가 점점 떨어져서 마이너스 효과가 난다. 경영자들은 야근은 곧 열정의 결과라고 생각하곤 하지만 강요된 열정은 오래가지 못한다. 경영자의 희망사항일 뿐이다.

개발자의 야근은 우리나라 소프트웨어 산업의 큰 이슈다. 과도한 야근은 직업의 질을 떨어뜨리고 뛰어난 인재들을 소프트웨어 업계로 들어오는 것을 가로막고 있다. 또한 이미 소프트웨어 업계에서 일하는 인재들도 다른 업계로 떠나게 만들거나 개발 일을 때려 치우고 관리자나 다른 일을 찾게 만든다.

그럼 소프트웨어 업계에서도 유난히 더 야근이 많은 이유는 무엇일까? 일반적으로 다른 산업계의 야근의 첫 번째 이유는 “생산성”이 낮기 때문이다. 생산성이 낮기 때문에 임금이 낮다. 경영자는 부족한 생산성을 채우기 위해서 야근을 드라이브가 하고 근로자는 야근 수당을 받아 낮은 임금을 보충하기 위해서 야근을 한다. 자동차 공장에서는 야근을 하면 야근 수당이 나온다. 낮은 생산성에 따른 저임금은 야근과 주말근무를 통해서 보충한다. 이를 통해서 선진국과의 임금의 차이를 좁히는 “악의 균형”이다.

하지만 소프트웨어 업계에서는 야근을 한다고 야근 수당을 더 주는 경우는 드물다. 보통 개발자는 야근을 통해서 임금을 더 받는 것도 아니고 그냥 야간을 강요 받는 경우가 많다. 그래서 경영자는 야근을 통해 부족한 생산성을 야근을 통해서 보충했다고 생각할지 몰라도 개발자 입장에서는 아무런 이익도 없다. 소프트웨어는 자동차 공장과 달라서 야근에 따른 생산성 향상을 측정하기가 매우 어렵기 때문에 시간대로 야근 수당을 지급하기도 어렵다. 그래서 대부분은 야근 수당을 주지 않는다. 이러니 경영자 입장에서는 개발자의 야근을 아주 손쉬운 수단으로 생각한다.

이는 육체노동 산업과 지식 노동 산업의 차이 때문에 발생한다. 특히 소프트웨어는 창의적인 지식 산업이기 때문에 야근이 결정적으로 생산성을 올려 주지는 않는다. 그 이유는 여러 가지가 있다. 한 시간에 자동차를 한대 만들면 두 시간이면 두대를 만든다. 천재가 와서 열대는 못 만든다. 하지만 소프트웨어는 개발자에 따라서 수십배 이상의 차이를 보인다. 창의적인 아이디어와 예술적인 생각이 중요한 경우에는 수백배 차이가 날 수도 있다. 이렇게 소프트웨어는 뛰어난 인재가 더욱 높은 생산성을 발휘하는데 낮은 임금을 선호하는 많은 경영진 때문에 뛰어난 인재는 오히려 제대로 대접을 못 받는다. 

그럼 생산성이 낮은 이유는 무엇일까? 물론 생산성이 높은 회사도 있다. 평균적인 수치를 말하는 것이다.

무엇이 원인이고 무엇이 결과인지 알 수 없이 이미 악순환의 고리에 들어가 있는 회사가 많다. 경영진들이 소프트웨어에 대한 이해가 부족한 상태에서 단기적인 영업 드라이브 정책으로 촉박한 프로젝트에만 매달리면 장기적인 기술 로드맵이나 기술공유는 어려워지고 호떡집에 불 끄듯이 일단 개발을 해 놓으면 이렇게 뱉어 놓은 코드들은 회사의 미래를 더욱 복잡하게 만들고 생산성은 더욱 떨어지게 만든다. 그러면 또 야근에 매달리고, 우수한 인재는 회사를 떠나고 낮은 임금의 개발자들이 투입되면 생산성은 더욱 떨어지게 된다. 그러면 더욱 야근에 내몰리게 된다. 

경영진들의 근거 없는 야근에 대한 믿음도 한몫 한다. 밤이나 주말에 사무실 순찰을 돌아서 개발자들이 자리에 없고 텅 비어 있으면 낮은 평가를 주거나 팀장을 문책하기도 한다. 이런 분위기를 만들면 개발자들은 어차피 야근을 해야 하는 상황이라면 낮에는 설렁설렁 체력을 비축하고 밤에 집중해서 일하기도 한다. 이렇게 개발자들을 평가하는 잘못된 잣대는 개발 문화를 더욱 꼬이게 만든다.

해결책은 악순환을 선순환으로 바꾸는 것이다. 이미 악순환의 고리에 깊숙이 빠진 회사는 빠져 나오기가 쉽지는 않다. 하지만 악순환의 결말은 뻔하기 때문에 빠져 나와야 살 수 있다. 악순환을 선순환으로 바꾸는 방법은 소프트웨어 문화를 바꾸고 소프트웨어 공학을 도입하는 것이다. 소프트웨어 문화나 소프트웨어 공학은 모두 소프트웨어를 빨리 개발하고 생산성을 높이는데 집중되어 있기 때문이다. 스펙을 제대로 쓰고, 설계를 하고, 소스코드 관리를 제대로 하고, 이슈관리를 하는 이유는 오직 하나, 소프트웨어를 빨리 개발하기 위한 것이다. 효과적인 개발 프로세스를 만들고 소스코드를 리뷰하는 목적도 생산성 증가다. 직원들간에 정보를 공유하고 전문적인 조직, 수평적인 조직을 만드는 이유도 생산성을 증가하기 위한 것이다.

생산성이 증가해야 임금도 오르고 야근도 줄어들고 신기술도 익히고 창의력을 발휘할 여가 생긴다. 그러면 우수한 인재가 더 많이 유입되고 생산성은 더욱 오르는 선순환이 될 것이다. 여기서 전제조건은 경영진이 소프트웨어를 이해하려고 노력하고 소프트웨어 문화와 소프트웨어 공학에 투자를 해야 한다는 것이다.

물론 현재 회사의 수행 능력을 고려하여 적절한 변화와 혁신을 꾸준히 추진해도 수년이 걸리는 일다. 그래도 포기를 할 수는 없다. 포기는 곧 미래를 포기하는 것과 같기 때문이다. 

이글은 ZDNet Korea에 기고한 칼럼입니다.