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

 

 

 

=======================

=======================

=======================

 

 

 

 

출처: http://www.zdnet.co.kr/column/column_view.asp?artice_id=20150312062303

 

프트웨어 개발에 있어 가장 중요한 문화 중 하나는 '공유’라고 할 수 있다. 공유는 소프트웨어 개발 속도를 끌어올리고 비용을 절감하며 프로젝트 성공 확률을 높이는 중요한 요소다. 뿐만 아니라 개발자들의 실력을 향상시키고 개발자가 20년, 30년 계속 개발자로 일할 수 있도록 하는 기초체력이기도 하다. 
 
하지만 우리나라에서 공유문화를 제대로 갖추고 있는 회사를 찾는 것은 쉽지 않다. 내 주변에는소프트웨어개발문화에 관심이 있는 개발자들이 많다. 공유문화에 관심이 많아 실천하려고 노력하는 이들도 많다. 하지만 그런 노력의 결과로 개발 문화가 성공적으로 정착됐다는 소식은 잘 들리지 않는다. 
 
이유는 무엇일까? 
 
여러가지 이유가 있겠지만 가장 큰 이유는 아직 공유를 위해 노력하는 개발자들이 소수이기 때문이다.  ‘죄수 딜레마’는 공유 문화를 가로막는 이유를 설명할 때도 유용하게 쓰인다. 
 
죄수의 딜레마를 둘러싼 상황은 다음과 같다. 두명의 사건용의자가 체포돼 다른 취조실에 격리되어 심문을받고 있다. 이들에게 자백여부에 따라 다음의 선택이 가능하다. 
 
-둘 중 하나가 배신하여 죄를 자백하면 자백한 사람은 즉시 풀려나고 나머지 한 명이 10년을 복역해야 한다. 
-둘 모두 서로를 배신하여 죄를 자백하면 둘 모두  5년을 복역한다. 
-둘 모두 죄를 자백하지 않으면 둘 모두  6개월을 복역한다. 
 
죄수A는 죄수B가 침묵할 것으로 생각되는 경우 자백을하는 것이 유리하다. 죄수B가 자백할 것으로 되는 경우 자백이 유리하다. 따라서 죄수A는 죄수B가 어떤 선택을 하든지 자백을선택한다. 죄수B도 죄수A와 동일한 상황에 처해 있으므로, 마찬가지로 죄수A가 어떤 선택을 하든 자백이 유리하다. 따라서 둘 모두 자백을 하지 않는 것이 최선의 결과이지만 죄수 A, B는 모두 자백을 선택하고 각각 5년씩 복역한다는 것이다. 
 
이런 죄수딜레마를 게임으로 시뮬레이션해보면 죄수 둘이건 여러명이건 상관없이 비슷한 결과가 나온다고 한다. 
 
도로로 나가보자. 조금 막히는 교차로에서는 교차로 꼬리물기가 아주 흔하다. 아무리 막히는 교차로라고 하더라도 꼬리물기를 하지 않으면 다같이 평균적으로 더 빨리 교차로를 빠져나갈 수 있다. 하지만 대중은 그런 선택을 하지 않는다. 다들 꼬리물기를 하는 상황에서 나만 교통법규를 지키고 가만히 있으면 교차로를 가장 늦게 통과하게 될 것이다. 심지어는 주변의 운전자들로부터 욕먹을 각오도 해야 한다. 꼬리물기를 하는 차가 다수인 상황에서는 교통법규를 지키는 소수가 몇배 더 손해를 보게 되어 있다. 그래서 어쩔수 없이 다같이 손해를 보는 경우를 선택하게 된다. 
 
몇년전 가족과 함께 괌에 있는 한 리조트를 방문한 적이 있었다. 하지만 여기서 부끄러운일을 목격했다. 수영장에는 충분한 선베드가 있는데 아침 9시쯤 수영장에 가보니 모든 선베드가 이미 임자가 있었다. 선베드에 타올을 하나씩 걸쳐 놓았지만 선베드에서 쉬고있는 사람은 하나도 없었다. 몇시간 후나타난 선베드 주인을 보니 모두 한국사람들이었다. 아침 일찍 일어나서 일단 선베드를 찜해놓고 아침식사를 하러간 것이었다. 
 
사실 선베드는 모든사람이 충분히 쉴만큼 많았다. 하지만 이용도 하지 않으면서 먼저 찜을 해놓으니 다른사람들은 전혀 쉴곳이 없게된 것이었다. 한국에서는 이런 현상 때문에 수영장에서 선베드 이용이 유료로 바뀐것으로 알고 있다. 외국에서는 이로 인해 어떻게 바뀔지, 또 바뀌었는지는 알 수 없다. 어쨌든 낯부끄러운일이었지만 다음날 아침에는 아침식사를 하기 전에 선베드 몇개를 찜해 놓는 일에 동참하는 우리를 발견하게되었다. 
 
이렇듯 죄수딜레마는 어디에서나 나타난다. 약속을 지키면 다같이 이익이 되고 모두 약속을 지킨다는 확신이 없다면 약속은 순식간에 무너진다. 
 
그럼, 규칙을 엄하게 적용하면 해결될 수 있지 않을까? 공유를 하지 않으면 벌칙을 주고 필요한 문서를 모두 만들지 않으면 승인을 하지 않아서 프로젝트의 다음 단계로 넘어가지 못하게 하면 해결할 수 있지 않을까? 이런 식으로 해결이 될 수 있었다면 우리나라 대부분의 회사에 이미 공유문화가 잘 정착되었을 것이다. 안타깝게도 엄격한 규칙적용은 그렇게 효과적이지 못하다. 
 
첫째 만들어 놓은 규칙이 엄격하기만할 뿐 공유문화 정착에 효과적인 경우가 별로 없다. 왜냐면 엄격한 규칙을 만든 사람들이 대부분 공유문화를 체험해 본 적도 없는 사람들이기 때문이다. 대부분은 방법론에서 필요한 문서를 따와서 만들라고 하는데 대부분의 방법론은 공유문화와는 별로 상관이 없다. 게다가 방법론을오해해서 오히려 복잡하게 적용하는 경우도 허다하다. 
 
둘째 아무리 복잡한 규칙을 만들어도 개발자들은 요령껏 적응하고 피해다니게 된다. 문서를 만들라고 하면형식면에서는규칙을 충족하게 만들 수 있지만 진짜 필요한 내용이 다 들어 있는지 확인할 방법은 없다. 공유가 습관화되지 않은 대부분의 개발자들은 어쨌든 규칙만 준수하는 방법으로 진짜 공유는 피해다니게 되어 있다. 
 
셋째 나만 공유를 제대로 하게 될 경우 나만 손해를 볼 수 있다는 생각을 의식적으로 또는 무의식적으로 하게 된다. 나중에 내가 없으면 유지보수가 어려워야 나의 가치가 올라간다고 생각한다. 전혀 틀린 얘기도 아니지만 다들 이렇게 생각하니 다같이 손해를 보는 것이다.
 
규칙을 통해서 공유문화를 만들어가는 것에는 찬성한다. 하지만 오히려 공유문화에 역행하는 규칙을 만드는 것이 일반적인 상황이라서 안타깝다. 개발자들이 공유에 익숙하지 않은 상황에서 너무 욕심을 내는 것도안된다. 현재 상황을 잘 파악해서 공유문화를 만들어갈 수 있는 단계적인 접근이 필요하다. 개발자들이 소화할 수 있는 만큼의 규칙을 만들고 이것에 익숙해지는 것이 공유문화 발전방향과 일치해야 한다. 
 
이렇게 점점 규칙을 업그레이드 시켜나가면서 회사를 조금씩 바꿔나가야 한다. 물론 이런 과정을 통해서 다같이 이익이 될 것이라는 확신을 직원들에게 심어주어야 한다.  처음부터 과욕을 부리다가는 영원히 공유문화와는 멀어지게 된다. 그럼 비효율이 정착된 회사가 될 것이다. 

 

=======================

=======================

=======================