1 M/M vs. 1 K/M

소프트웨어 개발이라는 자체가 많은 인력을 필요로 해서 그런지 몰라도 '사람 장사'라는 표현을 현실에서는 사용하기도 한다. 소프트웨어도 최종적으로 제품을 생산하는 것에 비유한다면 원가당 인력 비율이 다른 업종에 비해서 상당한 양을 차지할 것이다. 다시 말하면, 그만큼 자동화 되기가 어려운 부분이 소프트웨어 생산 분야일 것이다. 따라서, 소프트웨어 업계는 소위 하청이라는 업체간 사람을 제공하고 그 인력을 통해 얻어지는 소프트웨어 지식을 활용하여 최종 제품을 생산하게 된다. 그런데, 이상하게도 대상이 사람임에도 불구하고, 이 업계에서는 물건 취급하듯이 거래를 하는 모습이 종종 보인다. 아니 심하게 말하면 사람에 가격표를 붙이고, 그 가격표로 협상을 한다. 결국 이러한 거래를 통해 이루어진 계약은 그 안에 사람이라는 그 자체가 있는 것이 아니라, 계약을 맺은 회사가 산 노예에 불과한 사람으로 보이게 된다. 이 노예는 그 노예를 산 주인에게 무조건 복종하듯이 말을 들어야 하며소위 '깐다면 까'라는 식의 언행과 태도가 비일비재하게 오고 간다. 이른바 '갑질'이라는 오래된 관행이 곳곳에서 보인다.
무엇이 옳고 그른지를 따지기 이전에 과연 소프트웨어의 '사람 장사'라는 거래가 우리에게 의미하는 바가 무엇인지를  따지지 않을 수 없다. 소프트웨어 업계의 계약은 보통 M(an)/M(onth) 라는 단위로 가격이 책정된다. 즉, 1개월에 몇명이 해당 프로젝트에 참여하는지를 가격으로 책정한다. 예를 들어, 1M/M 의 가격이 1백만원이라면, 1사람이 1개월에 걸쳐서 작업한 결과가 1백만원어치라는 의미이다. 이걸 다시 상세하게 표시한다면, 소프트웨어 개발자가 1달 동안에 자기의 소프트웨어 지식을 사용하여 해당 비즈니스의 상황을 소프트웨어化하는데 1백만원이라는 의미일 것이다. 즉, 1 Man 이라는 의미는 SW Knowledge in 1 Man 라는 것이다. 따라서, 소프트웨어가 지식 산업이라는 의미하는 바가 바로 이것 때문이다.
우리는 1백만원으로 그 사람의 SW 지식을 구매한 것이지, 결코 개발자의 전체를 구매한 것은 아닐 것이다. 여기서 바로 계약의 주체와 마찰이 발생하는 지점이 된다. 소위 말하는 '갑질'은 갑이 시키는 무엇이든지 하라는 의미로 말을 하게 된다. '이것 좀 하셔야 되는데요...그쪽이 아니면 안되는데요...', '언제까지 뭐 좀 해야되는데요...', '이래서 오픈하겠어요....', '이렇게 에러나는 것 봐서 다른 것도 뻔합니다...' 등등. 수많은 오고가는 말 속에는 '너희는 내 것이니까 시키는 대로 해라' 라는 보이지 않는 의도가 담겨져 있다. 분명 이런 말을 들은 사람들은 그 의도가 뭔지 들으면 바로 기분이 상하고 억울하다는 마음이 바로 들 것이다. 마음 약한 개발자나 경력이 별로 많지 않은 개발자들은 이런 말에 쉽게 상처받고 그냥 속으로 삼키기도 하는 경우도 있고, 정말 소프트웨어 업계를 떠나버리는 사람도 종종 본다.
내가 하고 싶은 말은 이런 말은 그 어느 누구에도 도움이 되지 않다는 것이다. 특히, 프로젝트 막바지에 상당히 신경이 곤두서 있는 상태에서 이런 말들은 적어도 한두번은 오고 간다. 물론, 이러한 말을 하는 사람은 당장에 분이 풀릴지는 몰라도, 결국 그 말은 자신에게 돌아오게 된다. 마음이 상하고 억울한 개발자들은 그동안 수많은 밤을 세우고 온갖 SW 지식을 쥐어짜내어서 만든 소프트웨어 제품에 실망감을 가지고, 결국 오픈 막바지에 점점 꼬여가는 코드와 함께 자멸하게 된다. 오픈 연기, 반쪽 오픈, 베타 테스트 기간 등 실질적인 프로젝트의 성공하고는 거리가 먼 다른 경로로 치닫게 된다.
다시 소위 '갑질'이라는 행위에 대해 돌아가서, 이러한 말과 행동을 하는 사람들은 분명 자신의 위치를 재확인하게 해주며 자신의 우월감을 나타내는 표현으로 밖에는 보이지 않는다. 무언가가 잘못 되었다든지 아니면, 예상치 못한 다른 이벤트가 발생했다면, 이러한 '갑질' 보다는 대안을 모색하고 함께 하려는 동질감이 더 도움이 된다. 우선 무엇보다 누구의 잘못인지, 혹은 어느 부분이 문제인지에 대한 부분은 무엇보다 개발자 그 자신이 더 잘 알고 있다. 그러한 개발자에게 우월감을 내비치는 것보다 동질감을 표현하는 것은 개발자가 가지고 있는 해결 방안을 더욱 극적으로 찾아낼 수 있는 방책이다.
동질감은 개발자와 같이 술이나 식사와 같은 행위를 통해 생길 수도 있지만, 우선은 사면초가의 개발자에게 더욱 외롭게 싸우게 해서는 안된다. 프로젝트를 수행하는 동안 서로가 각자의 할일을 찾아 외롭게 싸워왔다면, 어느 시점에는 같이 싸워야하는 시점을 분명 마련해야 한다.
이러한 관행과 관습들이 아직까지는 소프트웨어 업계에 뿌리 깊게 있는 것이 사실이고, 지금도 그러한 상황에 처해 있는 소프트웨어 종사자들이 있을 것이다. 누구를 탓하고 누구의 잘못을 돌리기 전에 우선 이러한 상황에 대해서 대체하는 방법은 좀 더 솔직하게 서로의 의견을 털어놓는 것이 가장 좋은 해결책이라고 생각한다. 마음 상하는 말을 들은 사람은 내 마음이 상하고, 기분이 억울하다는 감정을 분명히 드러내고, 이런 것은 상황에 도움이 되지 않음을 표현하는 것이다. 좀 더 나아가 서로의 솔직한 감정을 드러내고 같이 해결하자는 동질감을 갖는 것이다. 비즈니스에서 현실적으로 이러한 유토피아 같은 상황이 연출되지 않을 것이라 생각하겠지만, 먼저 솔직해지면 그 만큼 동질감을 느끼는 시간이 더 빨라지게 된다.

소프트웨어에서의 단가는 1 M(an)/M(onth) 가 아닌 1 K(nowledge)/M(onth)로 바뀐다면 이러한 상황은 좀 더 줄어들 수 있을까 생각해본다.