1.
게임산업과 친숙하지 않기때문에 게임개발자들이 어떻게 프로그램을 출시하는지 알지 못합니다. ‘크런치 모드’라는 단어가 게임산업의 노동시간을 상징하는 단어라는 것도 처음 알았습니다. 정의당 이정미 의원이 낸 보도자료를 여러 신문이 인용할 때입니다.
근로복지공단 서울업무상질병판정위회(이하 질판위)의 자료에 따르면 넷마블 네오에서 게임개발 업무(클라이언트 프로그래밍)를 담당한 고인은 지난해 11월 심장동맥경화(급성심근경색)으로 사망하였으며, “연령, 업무내용, 작업환경, 근무관련자료, 재해조사서 등 관련자료 일체를 종합적으로 검토”한 결과, “업무상 사유에 의한 사망”을 했다는 것이다.
특히 질판위는 “발병 전 12주 동안 불규칙한 야간근무 및 초과근무가 지속되고 있으며, 특히 발병 4주전 1주간 근무시간은 78시간, 발병 7주전 1주간 89시간의 근무시간이 확인”되었으며, “20대의 젊은 나이에 건강검진 내역상 특별한 기저질환도 확인할 수 없는 점을 검토할 때 고인의 업무와 사망과의 상당인과관계가 인정”된다고 봤다. 게임개발 등 IT업계 관행인 소위 ‘크런치모드’(게임 출시와 업데이트를 앞두고 숙식 등을 모두 회사에서 해결하는 초장시간 노동을 의미)가 결국 젊은 노동자의 죽음을 불러왔다는 것이다.
고인 측이 근로복지공단에 제출한 자료에서도 질판위와 마찬가지로 초장시간 근무가 확인됐다. 문제가 된 9월과 10월은 빌드주간(게임개발의 중간점검을 하는 기간)으로, 10월 첫 주에 95시간 55분, 넷째 주에 83시간 4분이나 일을 했다는 것이다. 특히 고인은 사망한 일요일 당일에도 가족에게 출근을 한다는 통화를 한 것으로 알려져 안타까움을 자아냈다.
크런치 모드는 장시간 노동입니다만 장기간 노동으로 표시하는 이유가 있을 듯 합니다. Urban Dictionary의 설명입니다.
The way one works during crunch time. In an effort to make up for schedule slippage and meet a deadline, workers are required to make sacrifices including (but not limited to) sleep, nutrition, social life, hygiene, and product quality.
프로젝트의 데드라인을 맞추기 위하여 개발자들의 일상적인 생활을 희생하면서 이루어지는 노동입니다. 같은 사전에서 Crunch Time을 보면 아래와 같습니다.
The interval of time immediately before a project is due, when it becomes apparent that the schedule has slipped and everyone is going to have to work like dogs to try to complete the project in time.
‘개같이 벌어서 정승같이 쓴다’는 우리 속담에 등장하는 개가 Crunch Time에 등장합니다. 프로젝트의 마무리를 위해 개같이 일하는 시간입니다.
2.
게임산업의 크런치 노동이 사회적인 이슈가 된 계기는 무엇일까요? 구글에서 검색해보면 2016년에 일어난 일련의 돌연사가 시작입니다.
넷마블 30대 게임 개발자 ‘돌연사’…회사 “과로사 아니다”
넷마블, 과로사 논란 이어 직원 ‘투신자살
넷마블 개발자, 4개월 만에 또 돌연사 ‘파문’
이런 배경과 여론으로 2017년 2월 9일 넷마블 노동자의 돌연사, 우연인가 필연인가? 라는 주제의 토론회가 열렸습니다.
이후 고용노동부가 2017년 2월부터 게임 및 IT기업을 대상으로 근로감독을 실시하였습니다.
고용노동부, 3월부터 IT 업종 대상으로 기획 감독 추진한다.
고용노동부, 유명 게임업체 대상 기획근로감독 결과 발표
고용노동부, IT서비스업체 83개소중 79개소에서 노동법 위반 적발
이상의 조사결과와 관련한 보도자료입니다.
마지막 자료를 보면 장시간노동이 비단 게임산업뿐 아니라 SI를 수행하는 소프트웨어개발업체 대부분에 일반적임을 알 수 있습니다. SI산업을 3D산업으로 보고 ‘월화수목금금금’이 일반적이라는 통념과 부합합니다. 아주 오래전 모은행 차세대프로젝트를 담당하였던 전산팀장이 자살하였던 사건이 떠오릅니다. 크런치 모드는 어디에서나 존재합니다.
3.
크런치 시간이라고 부르든 아니든 주어진 시간내에 일을 마무리하여 특정일에 시작해야 하는 프로젝트 혹은 업무에 크런치 시간은 항상 있습니다. 특정일은 경영상의 목표를 배경으로 합니다. 예를 들어서 애플의 경우가 제품의 출시를 위하여 크런치 모드로 일했다고 합니다.
Apple said to be in ‘crunch mode’ to ready ‘iPad 3’ apps for on-stage demos, ads
특정일을 놓치면 경영상의 피해를 우려하여 생산성을 높이기 위한 방법으로 크런치 모드에 돌입합니다. 여기서 크런치 모드를 바라보는 관점의 차이가 발생합니다. 찬성하는 사람도 ‘생산성’을 주장합니만 반대하는 사람도 ‘생산성’을 말합니다. 생산성에 어떤 영향을 주느냐에 따라 태도가 달라집니다.
미국이나 유럽도 크런치 모드와 관련한 다양한 논의가 있었습니다. Crunch mode: Programming to the extreme외에 2005년에 쓰여진 ;Why Crunch Modes Doesn’t Work: Six Lessons은 The International Game Developers Association (IGDA)가 만든 지침입니다.
1.Productivity varies over the course of the workday, with the greatest productivity occurring in the first four to six hours. After enough hours, productivity approaches zero; eventually it becomes negative.
2.Productivity is hard to quantify for knowledge workers.
3. Five-day weeks of eight-hour days maximize long-term output in every industry that has been studied over the past century. What makes us think that our industry is somehow exempt from this rule?
4. At 60 hours per week, the loss of productivity caused by working longer hours overwhelms the extra hours worked within a couple of months.
5. Continuous work reduces cognitive function 25% for every 24 hours. Multiple consecutive overnighters have a severe cumulative effect.
6. Error rates climb with hours worked and especially with loss of sleep . Eventually the odds catch up with you, and catastrophe occurs. When schedules are tight and budgets are big, is this a risk you can really afford to take?
2014년 Chad Fowler은 Killing the Crunch Mode Antipattern에서 다음과 같은 이유로 반대합니다.
The more you have to use your brain, the less effective and healthy Crunch Mode is. In fields that require less creativity and thought, it might even really work as a (ruthless) management technique. In software development, it just doesn’t.
이처럼 해악을 잘 알고 있는 장시간노동이 쉽게 없어지지 않는 이유는 무엇일까요? 요즘 뜬다고 하는 커뮤너티의 개발자들이 전한 이유로 접근해보죠. 요즘 뜨는 개발자 커뮤니티 ‘OKKY‘의 오프라인 모임의 내용을 기사화하였습니다.
기사가 전하는 문제점은 여러가지입니다. 국비지원 개발자 양성 프로그램, 소프트웨어산업진흥법, Man/Month 인력 산출법, 초과근무에 대한 제재등이 나왔습니다. 제도와 구조로 접근해야할 문제도 있지만 사업주와 개발자의 관계를 정하는 M/M와 초과근무만 보죠. 참석자들의 의견이라고 합니다.
이미 초과근무 수당과 초과 근무시간 제한 법도 존재한다. 하지만 개발자들의 일주일은 아직까지 ‘월화수목금금금’인 경우가 있다. 지켜지지 않는 법에 어떤 의미가 있을까. 지키지 않아도 ‘일할 사람은 많다’라는 ‘배째라’하는 심보로, 법적으로 규정되어있는 것들을 지키지 않는 기업들이 태반이다. 하지만 제재를 가하면 기업이 죽는다는 이유로 정부 또한 솜방망이 처벌을 하면서 개발자들의 정부에 대한 불신은 더 깊어졌다. 정부가 지금껏 소프트웨어 개발자들을 위해 많은 법을 만들었지만, 제대로 지켜지지도 않고 지지도 받지 못하고 있는건 바로 기본 근로 환경 재고가 부족해서가 아닐까?
효율적은 근무 문화를 위해 인력비 산정에 Man/Hour을 도입하는 것도 방법이다. 다른 전문직종이 으레 그러하듯이 개발자들에게도 시간당 단가가 정해지면 야근이 당연시되는 풍조도 사라지고 고객의 과도한 사양변경 요청도 막을 수 있다. 다른 방법도 있다. 계약을 맺을 때, 미리 고객들과의 계약 상황응 명확히 문서화시켜 추가 프로젝트에 변경 요청이 들어올 시에는 추가 금액을 지불해야함을 명시하고 프로젝트 일정을 미룰 수 있도록 해야한다. 또한 앞서 말한 FPs방식을 사용해 프로젝트의 난이도를 산출하고, 일정 수의 개발자를 보유하지 않으면 발주 규모에 제한을 두는 것도 방법이다
오래 전 SI를 직접하거나 PM을 맡으면서 느꼈던 점은 한가지입니다.
“주어진 시간동안 개발자 산출물의 크기와 깊이가 일정하지 않다”
같은 고급이라도 생산성이 다릅니다. 개발자의 문제일 수도 있고 개발프로세스의 문제일 수도 있고 주사업자의 문제일 수도 있습니다. 그렇지만 출발은 기간과 비용을 정해진 SI라는 점입니다. 기간과 비용을 바꿀 수 없습니다. 바꾸는 경우도 아주 예외적입니다. 인력의 질과 숫자를 결정하는 비용과 기간은 발주사가 결정합니다. 모든 출발은 주먹구구식 발주문화입니다. 주먹구식 발주가 100%는 아닌 80%의 품질수준으로 가동을 할 수 있도록 뒷받침해주는 SI시장이 다음입니다. 개발자는 이런 문화와 시스템에 순응하여 생존합니다. 단순히 M/H를 바꾸고 초가노동을 규제한다고 달라지지 않습니다. 필요는 시장에서 새로운 공급을 만듭니다.
개인적으로 발주자의 책임을 명확히 하는 것이 출발이라고 생각합니다. 법적으로 강제할 방법이 있을지 의문이지만 소프트웨어 개발프로세스중 분석 및 설계까지의 책임은 온전히 발주사가 지도록 해야 합니다. SI는 설계에 기반한 최고의 산출믈을 적기에 내놓기 위한 솔류션과 인력을 제안하고 수행함에 국한하여야 합니다.
개발은 팀 작업입니다. 생산성의 기준도 개인이 아니라 팀이어야 합니다. 팀은 자기직원이든, 외부직원으로 구성을 합니다. 이런 팀이 하나의 팀으로 발전하여 프로젝트를 수행할 수 있도록 권한도 부여하여야 하고 개발프로세스 – 방법론이 아니라 -도 맞추어야 합니다. 투자 없이 좋은 성과물을 내놓기를 바라는 것은 도독님 심보입니다. 디지탈 혁신을 말하면서 IT투자는 주저함은 맞지 않습니다.
100%를 원하면 100%에 합당한 투자를 하여야 합니다.
