레이블이 야근인 게시물을 표시합니다. 모든 게시물 표시
레이블이 야근인 게시물을 표시합니다. 모든 게시물 표시

2015년 3월 9일 월요일

야근, “악의 균형”

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

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

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

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

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

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

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

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

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

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

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

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

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

2014년 3월 16일 일요일

SW를 을로 취급하는 하드웨어의 무지

필자는 펌웨어를 개발하는 등 하드웨어 팀과 같이 일하는 소프트웨어 개발자를 자주 만난다. 그런데 많은 개발자들이 하드웨어 팀과 일하기 힘들다고 하소연한다. 

회사에서 하드웨어에 더 집중하고 투자하며 소프트웨어는 보조로 생각한다고 말한다. 그렇지 않은 회사도 있지만 많은 회사들이 하드웨어를 더 중요하게 생각하고 소프트웨어는 하드웨어의 부수적인 역할로 생각하곤 한다. 

'소프트웨어' 하면 흔히 데스크톱 소프트웨어나 게임, 모바일앱을 생각한다. 하지만 이런 순수 소프트웨어, 즉 하드웨어에 종속적이지 않은 소프트웨어 비중은 일반인이 생각하는 것만큼 크지 않다. 반대로 하드웨어와 밀접한 관련이 있는 소프트웨어 비중은 의외로 크다.

자동차의 예를 들면 현재 최고급 차량의 생산 원가에서 소프트웨어가 차지하는 비중은 50%에 육박하고 있다. 그리고 2020년이 되면 고가 차량을 넘어 전체 자동차 생산 원가에서 소프트웨어 비중이 50%가 될 것이란 전망도 있다.

과거에 하드웨어로 수행하던 기능이 점점 소프트웨어로 대체되고 있고 그러면서 과거에는 불가능했던 기능이 실현 가능해져서 하드웨어 발전에도 큰 도움이 되고 있다. 

이런 소프트웨어를 펌웨어, 임베디드 소프트웨어라고 한다. 하드웨어와 간접적으로 관련 있는 소프트웨어까지 합치면 그 비율은 어마어마하다. 

이렇게 하드웨어에서도 소프트웨어 비중이 점점 증가하고 있고 하드웨어 자체 성능에도 소프트웨어가 많은 기여를 하고 있는데 이를 다른 측면으로 보면 조만간 하드웨어 경쟁력도 소프트웨어 역량이 좌지우지 하게 될 것이라는 얘기다. 그렇게 될 날이 몇년 남지 않았다. 

즉, 간단하게 얘기해서 앞으로는 소프트웨어를 잘해야 자동차도 잘 만들 수 있다는 얘기다. 

우리나라는 선진국보다 늦게 산업화되었지만 몇몇 분야에서 선진국을 따라잡았거나 앞질렀다. 자동차, 반도체, 선박, 휴대전화, 가전, 디스플레이, 플랜트 등이 그것이다. 하지만 소프트웨어 분야는 소프트웨어 선진국과 비교하여 아직 멀었다고 많은 사람들이 평가하고 있다. 그런데 이제 몇 년 후가 되면 소프트웨어 역량이 하드웨어 경쟁력을 판가름한다니 발등에 떨어진 불이 아닐 수 없다. 

우리나라는 임베디드 소프트웨어 분야에선 선진국에 더욱 뒤졌다.  이런 상황이 지속되면 그나마 따라잡고 앞지른 분야까지 내놔야 할 상황이 될 것이다. 

실제 성공한 하드웨어 중심인 회사에서 소프트웨어를 개발하는 방식을 보면 문제가 많다. 하드웨어 개발팀이 우위를 가지고 소프트웨어 팀은 시키는 대로 개발하는 방식인 경우가 많은데 그런 사례를 한번 살펴보자. 

A사는 하드웨어가 이미 설계된 상태에서 소프트웨어는 거기에 맞춰서 개발해야 한다. 

소프트웨어 개발팀 관점으로 봤을 때 하드웨어 설계에 문제가 있어도 소프트웨어가 우회 방법을 찾든지 해서 재주껏 해결해야 한다. 하드웨어 설계에 소프트웨어 개발자가 제대로 참여를 못해 이런 비효율적인 상황이 벌어진다. 그러나 A사는 하드웨어는 변경이 어렵지만 소프트웨어는 얼마든지 마음대로 변경할 수 있으니 소프트웨어를 하드웨어에 맞춰 개발하고 문제를 해결해야 한다고 한다. 

버그가 발견되면 무조건 소프트웨어 개발팀에서 문제의 원인을 찾아야 하고 하드웨어 문제도 소프트웨어 개발팀에서 해결해야 한다. 그러다보니 문제가 발생하면 욕은 소프트웨어 개발자들이 먹는다. 

기획 단계부터 소프트웨어 개발팀의 의견을 들을 기회조차 없다. 서로 다른 생각을 가진 사람들의 의견이 잘 모아질 때 창의적인 아이디어가 나오는데 하드웨어 중심적인 개발에서는 획기적이고 창의적인 아이디어가 나오지도 않는다.

B사는 모든 개발 일정이 하드웨어에 맞춰져 있다. 하드웨어 개발팀은 소프트웨어 개발팀과 개발 일정을 논의하지도 않는다. 이미 단계 별로 하드웨어 개발 및 양산 일정이 정해져 있으니 소프트웨어는 각 단계 별로 어떤 것은 1주일 어떤 단계에선 3주 안에 하드웨어에 필요한 소프트웨어를 무조건 만들어내야 한다. 

소프트웨어 개발팀은 인터페이스를 맞추거나 에뮬레이터를 통해서 미리 개발을 하고 싶지만 미리 정보를 제공 받지 못해 하드웨어 일정에 맞추느라고 항상 야근에 시달린다. 하드웨어 부서 일정이 바뀌면 소프트웨어 개발 일정도 틀어져서 일정을 조율하기가 매우 어렵다. 

C사는 소프트웨어 개발 프로세스도 하드웨어 개발 프로세스에 맞춰져 있다. 

과거에는 하드웨어를 개발할 때 한 두명의 개발자가 밤세워가며 펌웨어를 만들어주는 방식이었다. 하지만 지금은 소프트웨어 개발자가 엄청나게 늘었다. 그런데도 하드웨어 개발 프로세스에 소프트웨어를 끼워 넣는 방식은 그대로다. 

하드웨어 개발 프로세스에는 있지만 소프트웨어에는 없는 것도 있고 물론 그 반대도 있다. 소프트웨어는 알파, 베타 단계가 있지만 하드웨어는 그렇게 고쳐 나가지 않는다. 하드웨어 개발 프로세스에 억지로 소프트웨어 개발을 끼워 맞추다 보니 매우 비효율적으로 되어 있다. 용어들도 상이해서 이해하기 어렵다. 

지금은 소프트웨어 개발자들도 적응해서 프로세스를 따르고 있지만 여전히 문제가 많은 프로세스임은 명백하다. 

D사의 경우 소프트웨어 기술 책임자가 하드웨어 출신이다. 

이같은 상황은 업계에 안고 있는 가장 큰 문제이기도 하다. 소프트웨어 분야는  전문가가 아니면 정말 이해하기 어렵다. 콜라를 팔던 경영자가 TV 파는 회사의 경영자가 될 수는 있다. 하지만 비즈니스를 아무리 잘 하던 사람도 소프트웨어 조직의 기술 책임자가 될 수는 없다. 불가능하다. 

그런데 많은 회사들의 소프트웨어 부문 CTO(Chief Technical Officer)가 소프트웨어 전문가가 아니거나 CTO가 아예 없는 경우도 많다. 하드웨어 출신이 소프트웨어를 맡기도 하고 소프트웨어 출신이라고 해도 중간에 관리자로 넘어가서 이제는 소프트웨어 엔지니어가 아닌 사람이 CTO를 맡기도 한다. 

경영자에게 불도저 같은 추진력을 요구하는 회사에서 소프트웨어 전문가인 경영자들은 추진력이 부족한 것처럼 보여 많이 밀려 났고 이제는 소프트웨어 조직도 전혀 다른 분야 출신의 불도저 같은 사람이 맡는 경우도 많다. 

그런 경영자들이 추진하는 정책이라고는 고작 끊임없는 야근이다. 단기적인 성과는 날 수 있지만 아키텍처는 엉망이고 개발자들은 지치고 개발 문화는 엉망이 되었다. 소프트웨어는 소프트웨어 전문가가 맡아야 한다. 

기적적인 하드웨어에서의 성공을 회상하며 소프트웨어도 거기에 끼워 맞추려고 하면 큰 착오다. 하드웨어에서 성공했다고 그 방식으로 소프트웨어를 조금만 더 잘하면 될 것 같은 착각에 빠지기도 한다. 소프트웨어는 스타트업을 제외하고는 한두명의 천재가 밤을 세워서 잘 할 수 있는 분야가 아니다. 소프트웨어가 하드웨어의 부속이라는 생각에서 벗어나야 한다. 오히려 소프트웨어가 중심이 되는 시대가 오고 있다. 

그나마 그 동안 이룩했던 우위를 잃지 않으려면 소프트웨어가 '을'의 자리에서 벗어나 하드웨어와 동등한 관계가 만들어져야 한다.

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

2010년 3월 4일 목요일

개발자의 야근은 공짜?

소프트웨어 회사의 일들은 대부분 사람, 특히 개발자에 의존하는 일이 많습니다.
따라서 인건비는 가장 큰 비중을 차지하는 고정비입니다.
그런데 일단 뽑아 놓은 직원들의 야근은 공짜로 생각하는 경우가 많습니다.

게다가 몇몇 기업을 제외하고는 개발자들에게 "야근 수당"이나 "시간 외 근무 수당"은 딴나라 얘기입니다. 
제가 하고 싶은 얘기는 "개발자들이 야근을 하면 안된다", "시간 외 근무 수당을 받아야 한다"라는 얘기가 아닙니다.
개발자들은 동기부여만 되면 얼마든지 밤을 세가며 일하고 이는 금액으로 따지기 어렵습니다.

오늘 할 얘기는 경영자들의 절약 정신이 소프트웨어 개발팀의 효율을 떨어뜨린다는 얘기입니다. 
절대적인 잣대가 있는 것은 아니지만, 개발자들의 여분의 노동력을 공짜로 생각해서는 안됩니다. 회사마다 조금씩 다르기는 하지만, 합리적인 투자가 있어야 개발팀의 최대 능률을 이끌어 낼 수 있습니다. 

 야근

개발자들이 야근을 많이 할수록 많은 시간 일을 할 수 있으니 똑같은 월급을 주고 훨씬 효율이 높다고 생각할 수 있으나 외부 요인으로 인해서 발생하는 야근의 효율성은 그리 높지 않습니다. 
특히 장기적이고 일상화된 야간 압력은 개발자의 사기 및 충성도를 떨어뜨리며 제품의 품질을 떨어뜨리고 개발자들의 발전을 저해하며 창의적인 아이디어 발생을 가로막고 개발팀의 효율을 떨어뜨립니다. 
단기적으로 야근의 압박이 있을 수는 있겠지만, 장기화 되는 것은 문제가 있습니다.
단, 자발적이고 능동적이고 자유롭고 적절한 야근은 오히려 도움이 되죠

 조용한 사무실

경영자 입장에서는 작은 공간에 최대한 많은 개발자와 다른 부서 직원들을 몰아 넣고 서로 긴밀하게 커뮤니케이션을 하면서 일을 하기를 바랄 겁니다. 일단 이렇게 하면 임대료가 적게 나가고 영업의 이슈가 즉각적으로 개발팀에 전달이 잘 될 것으로 생각하곤 합니다. 하지만 이런 북적이고 시끄러운 환경에서 개발자는 최고의 능력을 발휘할 수 없습니다. 그러면 자연스럽게 몰입할 수 있는 밤시간을 선택해서 개발을 하곤 합니다. 
영업사원들의 시끄러운 전화를 옆에서 엿들어야 커뮤니케이션이 잘되는 것은 아닙니다. 커뮤니케이션은 적절한 시스템과 프로세스와 문화가 필요한 것입니다. 그리고 개발자에게는 최대한 집중해서 일할 수 있는 조용한 공간이 필요합니다.
공간이 조금 더 들어가고 임대료가 조금 더 나가더라도 개발자에게 조용한 공간을 제공할 수 있는 벽을 세우거나 사무실을 만들어 주는 것이 좋습니다.
개발자들을 따로 띄어 놓으면 딴짓 할까봐 걱정이 된다구요. 그러면 처음부터 잘못 뽑았네요. 

 널찍한 모니터와 빠른 시스템

개발자들에게 끊임 없이 좋은 시스템으로 교체해주는 일이 쉬운 일은 아닙니다. 하지만 너무 인색한 회사는 좋은 시스템이 개발 효율성과 연관이 있다는 것을 잘 알아차리지 못합니다. 작은 모니터는 동시에 여러 화면을 보지 못하며 디버깅도 불편하여 조금씩 작업 시간이 더 오래 걸립니다. 특히 빌드를 밥 먹듯이 하는 개발자들은 빌드 시간을 10~20% 줄이는 것만으로도 전체적으로 꽤 많은 시간을 절약해 줍니다. 이런데 투자를 하는 것보다 개발자들이 하루에 몇십분씩 더 일하면 된다고 생각하는 경영자들도 있습니다. 개발자들의 여분의 시간은 공짜가 아닙니다.

 허리를 보호해 주는 의자

안타까운 얘기지만 소프트웨어 개발자로 10년 정도 종사하면 허리 디스크에 시달리는 것은 예사가 되었습니다.
비싸지만 좋은 의자들은 개발자들이 더 오랜 시간 몸에 무리가 가지 않게 일할 수 있게 만듭니다.
직접적으로 개발 효율을 높일 수 있는 투자이지만, 대부분의 회사에서는 가장 싼 의자 구매만 승인이 납니다. 그래서 여러 개발자들은 자신의 돈을 들여서 좋은 의자를 구입하곤 합니다. 이런 투자는 회사의 몫입니다.

 아침식사와 간식

최근에 컨설팅을 했던 회사는 매일 아침 직원들에게 신선한 식빵을 매일 제공하더군요. 오전시간에 속이 비어 있으면 두뇌 회전이 느려지고, 점심시간을 기다리느라고 일에 집중이 잘 안됩니다. 
비용은 얼마 안되는 투자이지만, 투자대비 효과가 높은 것 중 하나입니다. 

 테스트 조직

개발자와는 별도로 테스터 조직을 만드는 것을 비용으로 생각하는 회사가 의뢰로 많습니다. 테스트의 비중을 별로 높게 생각하지 않고 개발자들이야 말로 자신들이 만든 소프트웨어를 잘 테스트할 수 있다고 생각합니다. 이런 식으로 개발을 하면 평생 구멍가게를 면치 못합니다.
테스트의 비중은 생각보다 큽니다. 테스트 팀을 활용하지 않고 개발자들에게 테스트를 맡기는 것은 상대적으로 비용이 많이 드는 개발자들을 낭비하는 것이며 실제로 개발자들은 테스트를 잘하지 못합니다. 또한 이는 테스트의 전문성도 무시하는 겁니다. 
회사마다 다르기는 하지만 적절한 인원의 테스트팀을 유지하는 것이 비용이 더 적게 들면서도 제품의 품질을 잘 유지할 수 있는 길입니다.

소프트웨어 회사에서 주변을 둘러보면 비용 효율성을 높일 수 있는 요소들이 많이 있습니다. 대부분은 사소한 비용을 절약하기 위해서 더 큰 대가를 치를 경우가 많습니다. 어디에는 투자를 해야 하고 무엇을 아껴야 하는지 적절히 판단할 수 있는 균형 잡힌 시각이 필요합니다.