개발자 야근문화를 고쳐야 하는 이유

“월화수목금금금”은 지금도 회자되는 유명한 이야기다. 그리고 모 회사 대표는 신제품 발표회에서 개발기간 동안 개발자가 집에 못 들어가서 이혼을 했다고 자랑 아닌 자랑을 한적도 있다. 개발자들을 연구소에 가둬놓고 밖에서 자물쇠로 잠궈 놓고 주말에도 집에 못가게 했으며 기혼자만 일주일에 하루씩 집에 보내 줬다고 자랑을 하는 경영자도 있다.

자신이 직원들을 얼마나 혹사시켰는지 그렇게 자랑을 하는 이유를 모르겠다. 그래서 한국에서 개발자라는 직업이 유난히 인기가 없고 3D 직종으로 폄하를 하는 모양이다.

많은 경영진이 야근의 효과를 맹신하고 자랑하는 이유는 몇몇 전설적인 성과들이 실제로 있었기 때문이다. 또한 자신들도 초기에 그런 경험을 하기도 했다.

스타트업 초기에 모험심과 열정으로 빠른 시제품 제작과 시장 진입을 위해서 잠도 안자고 일을 하기도 하고 명확한 목표를 가진 어려운 프로젝트를 전직원이 끊임없는 도전을 통해서 결국에 성공을 해내는 기적적인 멋진 성공 스토리가 종종 있다. 여기서 공통점은 명확한 목표와 열정, 자발적인 노력이 있었다는 것이다. 물론 이렇게 해서 성공한 회사도 계속 그렇게는 못한다. 전력질주를 계속하며 마라톤을 할 수는 없다.

그럼에도 많은 경영자들이 야근의 효과를 맹신하는 이유는 야근 말고는 뚜렷한 성과측정 방법이나 생산성 향상 방법을 잘 모르기 때문이다. 세일즈는 숫자로 평가를 하기 때문에 쉽다. 하지만 개발조직은 개발자들이 노는지 열심히 하는지 알기가 어렵다. 개발자들의 프로젝트가 6개월 걸린다는 말도 믿기가 어렵다. 좀더 열심히 하면 4개월이면 끝낼 수 있을 것 같고 과거에도 그렇게 밀어 붙이니 개발 기간을 단축한 적이 있었기 때문에 무조건 압박을 하게 된다. 개발자들도 6개월 걸린다고 주장은 하는데 근거를 가지고 주장을 하지 못하기 때문에 경영자의 신뢰를 얻지는 못한다.

결국 경영자의 유일한 수단은 무조건 일정을 줄이고 직원들을 압박하는 것이다. 물론 압박이 단기적인 효과가 있는 것은 확실하다. 하지만 회사는 100m 달리기를 하고 있는 것이 아니고 마라톤을 하고 있는 것이다. 이를 아는 개발자는 일정을 미리 늘려서 말하곤 한다. 절대로 경영자가 이길 수 없는 싸움이다. 기업문화만 망가진다.

이런 야근 압박의 부작용은 매우 크다. 장기적으로 제품의 품질은 떨어지고 아키텍처는 엉망이 된다. 직원들의 창의력은 사라지고 사기는 저하되며 로열티는 없어진다. 직원들은 사생활을 포기해야 하며 자기계발을 못하고 소모품으로 전락하게 된다. 직원들이 현재 가지고 있는 것을 한 5년 뽑아먹다 보면 그냥 부품이 되어서 직원도 발전이 없고 회사의 미래도 불투명해진다.

소프트웨어는 '창의적인 지식 산업'이며 개발 조직은 '지식공동체'이다. 생산성이 근무시간에 비례를 하는 것도 아니다. 적정 근무 시간이 넘어 가면 생산성은 떨어진다. 공유와 협업에 신경 쓸 겨를이 없어지고 '지식공동체'가 무너져서 각자 따로 노는 조직이 되기 때문이다. 프로세스로 강제해서 '지식공동체'를 만들기는 어렵다. 그렇게 할수록 효율은 더 떨어진다.

SI나 용역을 주로 하는 회사나 재정이 악화되어서 억지로 버티는 회사는 지식 산업에서 점점 멀어지고 있고 단기 수익이 너무 중요하기 때문에 이런 얘기는 모두 공염불일 뿐이다.

야근을 줄이는 가장 좋은 방법은 업무를 계획적으로 하는 것이다. 필자가 CEO로 있는 이우소프트에서는 개발 계획을 세울 때 개발자는 하루에 6시간을 기준으로 계획을 세우며 매우 정확하게 일정을 수립하려고 노력한다. 고참 개발자는 하루 4시간을 기준으로 한다. 나머지 시간은 동료를 위한 시간이다. 스펙, 코드 리뷰도 하고 물어보면 답변도 해준다. 하루에 두뇌를 6시간 풀가동하는 것도 쉬운 일은 아니다. 설렁설렁 일하면 12시간도 가능하다. 물론 너무 재미있는 일이라면 18시간도 몰입할 수 있다. 필자도 어렸을 때는 프로그래밍 재미에 빠져서 하루 18시간씩 개발을 한 적도 있다. 하지만 보통의 경우는 하루 6시간 몰입도 쉽지 않다.

그리고 프로젝트 관리도 제대로 해야 한다. 프로젝트는 리스크(Risk)로 가득 찬 가시밭길이다. 수시로 터지는 리스크는 일정을 꼬이게 만들고 아키텍처를 엉망으로 만들기도 한다. 프로젝트 관리를 제대로 해서 프로젝트가 항상 통제 범위 안에 있어야 한다. 그래야 돌발적인 야근이 줄어 들며 프로젝트 성공 확률도 높아진다. 그리고 이 방법이 프로젝트를 가장 빨리 끝내는 방법이다. 그럼 직원들은 거의 매일 저녁 6시에 퇴근할 수 있다. 그럼 6시 이후에는 무엇을 해야 하나? 물론 6시 이후 시간은 직원의 자유지만 이우소프트에서는 6시 이후에 해야 할 것에 대해서 가이드를 하고 있다.

첫째는 자기계발이다. 영어공부, 운동 등을 규칙적으로 자기 발전을 위해 노력하기를 권장하며 미래의 업무에 필요한 지식 및 기술을 익혀야 한다. 학원을 등록했다가 수시로 발생하는 야근 때문에 포기하는 경우가 많다. 야근이 많은 회사에서는 무엇 하나 계획적으로 할 수가 없다. 무엇을 공부할지는 자율에 맡기기는 하지만 회사에서는 그 내용을 파악하고 상담, 관리, 지원하고 있다. 이것이 직원이 부품이 안되고 5년 후, 10년 후 더 발전된 모습이 되는 방법이다. 그래야 회사도 직원과 같이 발전할 수 있다. 건강을 유지하기 위한 운동은 회사에 피트니스 시설을 만들고 뛰어난 코치를 정직원으로 채용하여 골프, 요가/필라테스, 웨이트 트레이닝을 지원하고 있다.

둘째는 가능하면 가족과 시간을 보내기를 권장한다. 야근을 안했다고 친구들과 술 마시는데 시간을 보내는 것은 가급적 줄이고 가족과 시간을 많이 보내야 한다. 열심히 일하는 목적이 여기에 있기 때문에 굳이 이유가 무엇인지 설명할 필요가 없을 것이다. 회사에서 '이우아이'라는 어린이집을 운영하고 있어서 초등학교 이전까지는 회사에서 보육을 최대한 도와준다.

회사에서 철저히 관리를 하는 것은 프로젝트다. 정해진 시간 안에 프로젝트 목표는 꼭 달성을 해야 한다. 그 외 개발자들의 활동은 회사에서 거의 통제하지 않는다. 스스로 일을 찾고, 만들고, 준비도 한다. 시키는 일만 하는 소수의 직원도 있지만 대부분은 시간과 장소를 가리지 않고 스스로 뭔가를 찾아서 한다. 물론 그 내용은 대부분 공유가 된다. 야근의 유무는 무의미하고 직원의 자율성과 로열티를 높이는데 집중해야 한다.

야근을 100% 없애는 것은 불가능하며 그런 노력을 할 필요도 없다. 강요 없이 자율에 맡겨 놓으면 된다. 업무 절대 시간이 평가에 어떠한 영향도 주지 않는다는 확신을 직원들에게 심어 줘야 한다. 야근 자체가 나쁘다, 좋다 말할 수 없다. 경영진의 야근에 대한 잘못된 맹신이 문제일 뿐이다. 야근을 없애야 하는 이유는 "우리 회사는 야근이 없는 멋진 회사에요"라는 우스운 얘기를 하기 위해서가 아니다. 습관적이고 강압적인 야근 문화의 부작용은 상상 외로 크며 회사의 경쟁력을 서서히 좀먹기 때문이다. 야근 자체가 화제도 문제도 안되는 자율적인 문화가 필요하다.

이 글은 ZDNet Korea와 바텍블로그에 게재되었습니다.

이우소프트에서 개발자의 경력을 보장하는 방법

현재 필자가 CEO로 있는 이우소프트에서는 2015년 여름까지 K수석연구원이 개발실장 역할을 맡고 있었다. K수석은 경력이 20년이 넘고 개발은 매우 잘 하지만 관리는 싫어하는 천상 개발자다. 하지만 회사에서 개발실 관리를 맡기니 어쩔 수 없이 관리를 해야 했고 보고서 작성, 회의 등으로 거의 모든 시간을 보내고 정작 자신이 잘하고 좋아하는 개발 일은 거의 못했다. 그래서 스트레스도 매우 심했다. 

우리나라 대부분의 소프트웨어 회사에서 비슷한 일이 벌어진다. 개발자 경력이 10년쯤 되면 팀장, 실장 등 여러 가지 타이틀로 관리에 발을 들인다. 개발자가 일단 “장” 타이틀을 달기 시작하면 커리어가 꼬이기 시작한다. 그럴듯한 보고서도 만들어서 경영진에게 보고도 해야 하고 회의도 많아져서 개발을 할 시간이 점점 줄어든다. 일단 관리에 발을 들이게 되면 관리에 많은 시간을 쏟아야 하고 기술과는 점점 멀어지고 어정쩡한 관리자로 자리를 잡게 된다. 그런데 전문성이 별로 없는 일반 관리자가 될 뿐이다. 다시 개발자로 돌아오지도 못한다. 그러다가 못 버티는 개발자들은 업계를 떠나 치킨집을 차리기도 한다.

이렇게 고참 개발자에게 본인의 의사에 반해서 관리를 맡기면 회사는 무엇을 얻게 되는가? 

회사에서 가장 뛰어났던 SW 개발자들이 잘 하지도 못하고 전문성도 없는 관리 일을 기웃거리다가 대부분 밀려나게 된다. 그럼 개발자는 10년을 넘어가면 더 이상 개발을 못하는 것인가? 전혀 그렇지 않다. 계속 개발에만 매진한다면 10년, 20년, 30년 경력이 쌓일수록 실력이 향상된다. 단지 회사에서 개발자 경력을 보장하지 않기 때문에 개발자의 경력을 지키지 못할 뿐이다.

개발자는 여러 종류가 있다. 어플리케이션 개발자, 알고리즘 개발자, 이미지 프로세싱 전문가, 커널 개발자 등 다양한데 이들에게 고참이 되었다고 관리, 사업, 경영을 하라고 회사에서 압박을 하는 것이다. 이들의 대부분은 관리자로서 실패한다. 원래부터 그쪽으로는 영 소질이 없는 경우가 대부분이다. 하지만 조직에서 힘있는 위치이기 때문에 관리도 잘 못하고 망치고 있어도 팀원들은 불만을 얘기하지 못하고 경영자는 이들이 회사를 망치고 있다는 것을 잘 알아차리지 못한다. 이들은 조직문화의 피해자이며 가해자가 된다. 

이렇게 뛰어난 고참 개발자들이 사라지는 회사는 개발 생산성이 낮아 질 수 밖에서 없다. 어떤 경영자는 밤을 새워 가며 일할 수 있는 젊은 개발자를 더 선호하지만 SW는 작업시간이 생산성과 비례하지는 않는다. 창의적 지식산업인 SW개발에서는 시니어 개발자가 주니어 개발자보다 몇 배 더 뛰어난 것이 일반적이다. 시니어 개발자일수록 회사에서 잘 지켜내야 한다. 그래서 실리콘밸리에서는 60세가 넘는 개발자를 보는 것이 그렇게 어렵지 않다. 

그럼 우리나라에서는 개발자 경력 보장이 왜 잘 안될까? 뿌리깊은 상하관계 위주의 조직문화가 중요한 이유다. 관리자가 윗사람으로서 팀원에게 지시를 하고 팀원은 이를 따라야 한다. 그런 조직에서 일하다 보면 왠지 팀장 등 관리자가 되어야 승진을 한 것 같고 힘도 생기며, 팀원으로 계속 남아 있으면 피곤해진다. 이런 상하관계 조직문화가 계속 남아있는 회사에서는 개발자의 경력을 보장하기는 어렵다. 

우리나라에서는 개발자의 분포가 나이 들수록 개발자의 인원수가 급격히 줄어드는 위가 뾰족한 삼각형 모양이다. 하지만 구글 등의 글로벌 회사들은 나이에 따른 개발자 인원수가 사다리꼴에 가까운 네모 모양이다. 즉 개발자들은 꾸준히 자신의 경력을 보장 받으며 실력을 키워간다는 것이다. 그런 회사와 어떻게 개발 실력으로 경쟁이 되겠는가? 

그럼, 과거 이우소프트는 어떤 상황이었을까? 

개발실의 고참들은 실장, 팀장의 이름으로 관리에 바빴고 개발과는 점점 멀어지고 있었다. 또한 회의와 보고에 불려 다니느라고 정신 없는 나날을 보내고 있었다. 그래도 다시 팀원이 되라고 하면 좋아하지 않을 상황이었다. 팀장이 되어야 연봉도 더 오르고 행정적인 파워도 생기기 때문이다. 

그래서 나는 먼저 개발실 내에서 “상하 관계 철폐”를 강력하게 추진했다. 제도를 바꾸고 마인드를 바꾸기 위해 노력했다.

개발팀장의 인원수도 대폭 줄이고 팀장의 역할도 최소한의 결재로 축소를 했다. “직급”도 거의 통일해서 대부분의 개발자가 “책임연구원”이 되어 호칭도 수평적으로 바뀌었다. 개발팀장도 95%의 시간을 순수 개발에 투입하도록 했다. 개발자들에 대한 개별 관리는 완전히 제거를 하고 스스로 일하게 했다. 

PM조직을 신설하고 전문PM을 영입했고 전문PM이 프로젝트 관리를 전담하게 했다. PM과 개발자는 완전히 수평적인 관계를 형성했고, 개발팀 내에서도 누가 윗사람이라는 의식은 거의 없어졌다. 각자 전문분야가 다른 전문 개발자들일 뿐이다. 직급통일로 위아래 구분도 어려워졌다. 어린 PM과 나이 많은 개발자가 같이 일하는데 거북함은 없는 분위기다.

이제 개발도 하고 관리도 하는 어정쩡한 개발자는 없으며 채용도 하지 않는다. 20년 경력의 개발자를 채용할 때도 코딩테스트는 필수다. 날고 긴다는 개발자도 코딩테스트를 통과하지 못하면 입사를 할 수 없다. 그리고 개발자들도 원한다면 평생 개발을 할 수 있다는 확신을 가지게 되었고, 관리자가 되고 싶어하는 개발자는 이제 거의 없다. 

물론 단 몇 개월 만에 조직 문화와 모든 직원들의 마인드까지 완전히 바꾸는 것은 쉽지 않고 끊임없이 과거의 습관들이 튀어나올 수 있다. 스스로 일하는 문화는 적응이 어렵고 윗사람이라는 권위의식도 한번에 없어지지 않는다. 그래서 수많은 기업들이 개발자 경력보장을 제도로 만들어도 고착된 문화에 가로막혀 정착이 잘 안 된다. 필자의 회사 내에서도 수평적인 조직과 전문가 중심의 조직을 유지 발전 시키기 위해서 끊임 없이 노력하고 있으며 그런 노력이 소홀해지면 순식간에 과거로 회귀할 수 있다는 것을 잘 알고 있다. 공든 탑을 쌓는 것은 어렵지만 무너지는 것은 순식간이다.

우리나라도 개발자가 선택에 의해서 안심하고 평생 개발자로 일할 수 있는 환경이 되어야만 한다. 여러 기업 문화가 서로 얽혀 있어서 하나만 바뀐다고 이 문제가 해결이 되지 않는다. 앞으로 글로벌 기업들과 경쟁하기 위한 최소한으로 바뀌어야 하는 기업문화를 실제 사례 중심으로 계속 이야기 해보고자 한다. 

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

글로벌 소프트웨어 회사를 저와 같이 키워 볼 기획자를 채용하려고 합니다.

대한민국에서 글로벌 소프트웨어 회사를 탄생시키기 위해서 젊은 소프트웨어 창업자를 위한 비영리 교육사업을 시작합니다.

본 사업을 기획하고 같이 글로벌 소프트웨어 회사를 키워 볼 기획자를 채용하려고 합니다.

사업의 개요

• 아이디어와 열정만 있으면 됩니다. 나머지는 모두 이우소프트에서 제공합니다.

• 일할 수 있는 공간, 시스템, 급여, 회사설립, 특허, 휴식공간, 식사 모두 무상으로 제공합니다.

• 실리콘밸리의 소프트웨어 개발 문화를 공유하고 코칭을 제공합니다.
• 김익환, 전규현 코치가 실질적인 소프트웨어 공학과 문화를 가르쳐 줍니다.
• 여러 전문가가 마케팅부터 개발 등 여러 분야에서 지원을 해줍니다.

• 가능성 있는 창업자에게 Seed funding을 제공합니다.
• 추가적인 투자 및 투자 연결을 제공합니다.

• 글로벌 시장에서 통할 아이템을 선발하며 글로벌 시장 진출을 지원합니다.

채용하려는 사람

• 위 사업을 기획할 사람

• 소프트웨어 회사를 키우고 싶은 열정과 실력을 갖춘 사람

지원방법 : 이력서, 자기소개서를 [email protected]로 보내면 됩니다.

리뷰! not 설명회

소프트웨어를 개발할 때 가장 중요한 활동 중 하나가 리뷰다. 특히 Peer review다.

리뷰가 중요하다는 것은 소프트웨어 개발에 종사하는 사람들은 거의 다 알 것이다. 하지만 막상 리뷰를 어떻게 하고 있나 살펴보면 제대로 하고 있는 경우는 별로 없다.

우리나라에서 흔히 볼 수 있는 리뷰의 형태는 설명회 방식이다. Reviewee(리뷰를 받는 사람)가 내용을 하나씩 설명하면 Reviewer(리뷰를 하는 사람)들이 설명을 듣고 있다가 의견을 얘기하는 방식으로 진행하는 경우가 많다.

많은 Reviewer들은 사전에 리뷰자료를 읽지 않거나 훑어만 보고 참석해서 설명을 들으면서 의견을 얘기하곤 한다. 이런 형태의 리뷰는 문제가 많다.

일단 시간이 오래 걸린다. 웬만한 프로젝트의 스펙문서는 수백페이지에서 천페이지를 넘곤한다. 그런데 이런 설명회 방식의 리뷰로는 며칠이 걸릴지 짐작도 안된다. 모든 내용을 꼼꼼하게 훑으면서 리뷰를 하기도 어렵고 나중에는 시간에 쫓겨서 대충 끝내버리기도 한다.

또한 난상토론 방식으로 진행을 하다가 마무리를 못하기도 한다. 그렇게 다시 수정된 문서를 리뷰하게 되면 첫번째 리뷰보다 충실하게 진행되기 어렵다. Reviewer들도 이미 봤던 내용을 또 보기 때문에 대충 검토를 하게 된다.

이런 부실한 리뷰를 통해서 진행되는 소프트웨어 프로젝트는 수많은 난관을 만나기 마련이다.

설명회 방식의 리뷰는 지양해야 한다.

리뷰는 진짜 리뷰여야 한다. 리뷰의 목적은 여러 가지가 있지만 가장 중요한 목적은 여러 관점에서 전문가들이 검토를 해서 문제점을 찾아내서 고치는 것이다. 리뷰를 진행하다고 하면 Reviewer는 사전에 문서를 한글자, 한글자 빠짐없이 꼼꼼히 검토해서 의견을 제시해야 한다. 그래서 오프라인 리뷰 없이 온라인으로 진행하기도 한다.

하지만 오프라인 리뷰가 같이 의논을 할 수 있어서 더 효율적이다. 그렇게 여러 Reviewer들은 미리 완벽하게 검토를 해서 리뷰 자리에서는 문서를 한줄 한줄 같이 보는 것이 아니라 검토할 내용들만 빠르게 의논하고 결론을 내고 끝내는 것이다. 천페이지짜리 스펙문서가 2시간에 리뷰를 마치기도 한다.

이렇게 하기 위해서는 일단 문서가 잘 적혀야 한다. 웬만한 이슈들은 사전에 개별 담당자와 검토가 완료되었고 오프라인 리뷰를 요청할 때는 98% 정도 완성이 되었을 때 가능한 것이다.

그리고 리뷰는 한번에 끝내야 한다. 이렇게 Reviewer들이 많은 노력을 들여서 검토를 했는데 이런 리뷰를 여러 번 해야 한다고 하면 2, 3번째 리뷰는 제대로 진행이 되지 않는다.

리뷰를 한다는 의미는 공동 책임을 진다는 의미다. 그런데 설명회에 구경와서 한마디씩 툭 던지고 책임은 지지 않는 사람이 너무 많은 것 같다.

전문가도 아니면 윗사람이라고 툭툭 던지는 얘기가 프로젝트를 망치게 할 수도 있다. 경영자라면 스펙을 리뷰할 때 Product scope 부분의 Business Strategy, Corporate Goal 등의 내용을 심도 있게 검토하면 된다. 각자 전문분야가 다 있다.

하지만 노력이 많이 드는 리뷰는 원하지 않고 편하게 앉아서 설명해 주는 것을 듣기나 하겠다고 설명회를 원하는 경영진들은 권위의식과 귀차니즘에 빠져 있는 것이다.

MS에서 초기에 엑셀을 개발에서 스펙을 리뷰할 때 빌게이츠가 스펙 문서를 모두 읽고 와서 윤년 계산에 버그를 발견하여 리뷰 때 얘기를 했다는 일화는 유명하다. 빌게이츠는 당시 CEO였지만 Chief Architect의 역할로서 스펙을 모두 검토했던 것이다.

소프트웨어를 제대로 개발하고 싶다면 권위의식은 버리고 리뷰를 제대로 진행해야 한다. 개발자들도 건성건성 구경하러 가는 리뷰는 지양해야 한다. 리뷰에 참석했다는 의미는 공동으로 책임을 진다는 생각을 하고 철저히 검토를 해야 한다.