아빠곰의 세상나들이

출처 : http://blog.naver.com/javaservice7/20197432298

간단히 조직이 큰 그림을 볼 수 없는 형태 또는 마인드를 갖고 있지 못한 조직들이 종종 있다.

준비 안된 조직의 특징은 근시안적 발상을 갖고 있거나 게임 개발을 로또 복권 처럼 대박을 기대한다.

다른 특징 하나는 조직내 이슈나 사람에 대한 비난을 많이 하는 반면,
문제에 대한 해결 방안을 내놓지 못하거나 잘한다는 표현이나 긍정적인 표현은 없다.
또한 의견이나 이슈에 대한 토론이라는 형태는 없다.
아니 있으면 그것은 마치 노는 것이나 잡담으로 치부하며
컴퓨터 앞에 앉아서 일만 하라고 하고 무언가의 결과물을 기대한다.

회의가 많아진다.
문제점은 있지만 결과가 없다.
아니 도리뱅뱅같은 개념의 회의만 될 뿐!
시간이 지나도 문제의 해결은 없이 폭탄 돌리기 하다가
어느새 누군가가 독박 쓰고 멘붕을 당하고 있을 것이다.

게임 개발은 창작물이다.
혼자의 생각이나 의견으로 나올수도 있겠지만
대부분 이런 경우는 천재 한명이 회사를 좌지우지하는 경우일 것이고
보편적인 회사나 조직의 경우는 많은 사람들의 의견이 나오고
옳바른 방향의 토론이나 많은 대화를 통해 의견을 모으고 합의의 결론에 도달해
새로운 창작물에 대한 심도 있는 결과물이 나온다고 본다.

개발은 그냥 연장 몇개 들고 조립해 나오는 식으로 화자되어
누구나가 보편적인 생각이라는 식으로
개발자들이나 조직에 있는 사람들에게 세뇌시키는 발언을 하는 경우가 종종 있다.

이런 스타일의 조직은 과감한 결정이 뒤따라야 하지 않나 싶다.

어쩌다 준비안된 조직이 성공하는 경우도 있다.

문제는 오래가지 못하거나, 성공할때 벌어둔 돈에 비례해서 시간이 걸리겠지만, 망해가는 절차를 밟았다.

1990년대~2000년 그 많던 게임 개발사들이 성공하고 망하고 하는 과정들을 지켜보면서 몇자 적어봤다.

소프트웨어 개발자와 야근이라는 주제는 끊임없는 담론이다. 최근에 국내 대형 포털 기업의 CSO께서 야근이 사라진 칼퇴근 문화에 대해 사내 강의에서 언급한 것이 기사화 되어서 큰 역풍을 맞기도 했다.

나도 과거 회사에서 개발을 할때 야근을 많이 했고, 대학생 시절에는 인터넷과 웹 프로그래밍에 열중 하다가 삼일 밤낮을 꼬박 책상에 앉아 있을 때도 있었다. 그만큼 SW 개발자의 야근은 그냥 업무의 일환 처럼 당연한 것이 되었다. 

물론 그에 따른 명암도 있다. 어떤 이는 벤처업계에서 신데렐라로 떠 오르기도 했고, 밤에 혼자 만든 게임이 앱스토에서 대박을 치기도 한다. SI업계에서 야근을 하다 폐를 잘라낸 개발자도 있고, 어떤 사람은 이혼을 당하기도 했다고 한다. 우리가 SW 개발자 야근을 문제로만 바라보기도 어렵고 그렇지 않다고 열정이 식었다고 보기도 어렵다.

야근은 필요악인가? 우리가 업무 시간을 늘이지 않고도 이를 해결할 방법은 없나? 한번 생각해 봤다.

우선 SW 개발자의 업(業)의 특징을 이해해야 한다. 사람이 컴퓨터가 알아먹는 방법으로 일의 순서를 만들어 주아야 한다. 이것을 전산적 사고(Comutational Thinking)이라고 하는데 프로그래밍을 하는 동안은 컴퓨터 처럼 생각하는 '사고 이입'이 필요하다. 그리고 테스트라는 반복 작업이 많은 엄청난 지식 노동 과정이 있다.

집중할 수 있는 업무 환경

프로그래밍에 몰두했다가 뭔가 외부의 요인(메일, 전화, 메신저, 회의 등등)에 의해 그 흐름이 깨어지면 다시 돌아가기에 더 많은 시간이 필요하다. 과거에 한밤중에 코딩을 많이 했던 것도 일과 시간 중에 너무 많은 프로그래밍의 방해요소가 있었기 때문이었다. 옆에 누가 와서 이야기를 하거나 이쁜 여직원이 지나가도 방해가 된다. 

밤에는 조용하고 일을 프로그래밍을 더 효율적으로 해내기 매우 좋은 환경이다. (물론 기획서나 보고서를 쓴다던지 회계 마감, 디자인을하는 다른 직군도 마찬가지겠지만 유독 개발자가 야근이 많은 것은 그 영향이 더 크기 때문이다.)

마이크로소프트 같은 전통 SW기업에는 개발자는 1~2인실의 별도 방을 나눠 준다. 야후나 구글 같은 회사의 경우, 2~3인 정도의 파티션이 매우 높은 자리를 배정한다. 예전에 회사를 옮기고, 자리 배치를 하다 보면 유독 개발자들만 안쪽 구석 자리를 원하는 경우가 많다. 모니터를 막고 헤드셋을 쓰고 일하는 것이 그들이 대인 기피증이 있어서 그런건 아니다.

우리 나라는 유독 뻥뚫린 사무 공간에 100명씩 한꺼번에 배치해 놓고 업무를 시키기를 좋아한다. 회사가 크면 클 수록 그런 유혹에 빠지기 더 쉽다. 이런 공간에서 개발자들이 집중력을 발휘하기는 매우 어렵다. 개발자의 공간 배치는 그 만큼 중요하고 야근이 아니어도 평상 업무 시간에 프로그래밍 업무에 집중할 수 있는 환경을 만들어 주어야 한다.

잉여는 비용이 아니다
또 다른 관점은 바로 개발자와 잉여력이다. IT 기술은 끊임없이 변화해 왔고 "늘 배워야한다"라는 점이 SW 개발이라는 직업의 장점이자 단점이다. 그래서 가끔 주니어 팀장에게 늘 팀에 20% 정도의 버퍼를 두라고 충고한다. 즉, 팀원 중 10명 중 2명은 놀고 있어야 한다는 것이다. 여기서 논다는 것은 주어진 당장의 업무 보다 좀 더 새로운 기술을 테스트 해보고 실험해 보는 일을 하는 것이다.

프로젝트 투입을 해야 하는데 한두명을 놀린다는 것은 매우 비효율적이고 비용으로 보는 경향이 크다. 회사가 좀 크면 더더욱 그렇게 노는 꼴을 못본다. 특히, 어떤 신기술이 나왔는데 여러 팀에서 해 보고 있으면 비효율적이라고 생각하고 콘트롤 타워 부터 만들려고 한다. 

개발자에게 업무로서 배우는 시간을 주고 이를 자신의 업무에 적용하는 노력을 비용이라고 부르면 안된다. 그것이 더 높은 생산성으로 나올 가능성이 크기 때문이다. 이것이 야근이 아니어도 생산력도 올리고 자발적으로 좀 더 효율높은 결과물을 만드는 동기가 된다.

가슴 진한 보상이 필요하다
어느 회사 어느 직군이든지 보상은 매우 중요한 동기 유발 요소이다. 어느 대기업 처럼 일은 고되지만 월급과 보너스를 많이 주니 회사를 탈출할 수 없도록 말이다. 아니면, 연말 시상에서 외제차를 준다던가 벤처기업에서 엄청난 스톡을 안길 수도 있을 것이다.

돈으로 하는 보상도 좋지만 SW 개발자에게는 '가슴 진한 보상'을 해 보면 어떨까? 자기가 맘대로 원하는 개발 환경을 꾸밀 수 있도록 구매의 권한을 준다던지(예를 들어, 다음의 개발자 마일리지) 외부에서 자신의 기술을 공유하고 발표할 기회를 준다던지 새로운 기술을 도입하는 프로젝트에 발탁하는 기회를 주는 것이다.

구글에는 개발자들의 20% 프로젝트 중 제일 좋은 것을 선발해 백만불을 주는 제도가 있었다고 하고 페이스북은 해커톤을 통해 개발자의 아이디어를 바로 서비스에 접목할 수 있는 기회를 준다고 한다.

때로는 돈보다 명예 보다 이러한 자아 성취를 유도해 주는 보상책이 더 큰 결실을 맺기도 한다. 눈에 보이는 사람과 그 업무 시간을 조절하는 것 배우 쉬운 일이다. 하지만, 그것이 좋은 결과를 못 얻는다. 

기업 문화라는 것은 계속 바뀌고 성장하지만 밑바탕에는 바로 업에 대한 성찰과 원칙이 필요하기 때문이다. 예전에 했던 경험만 비추어서 강제하려는 순간 그게 바로 역효과로 나타나는 일이 부지기수다. 소프트웨어 개발자를 다루는 문화도 그렇다. 무턱대고 야근이나 근로를 강요하기 보다는 동기 유발에 의한 자발적 참여를 이끌어 내는 일관성 있는 문화가 더 절실하다.

p.s. 사실 포털 뿐 아니라 SI 업체와 그 프로젝트를 하는 경우, 대부분 쫓기듯한 일정과 과도한 업무량에 의해 야근하는 분들이 있습니다. 이 글은 과연 그렇게 만들어진 생산품이 정말 그 값어치를 하는지 한번 다시 생각해 보아야 한다는 취지의 글입니다.  

출처 : Channy’s Blog