필자는 23년 경력의 개발자이며 소프트웨어 회사의 CEO다. 과거 8년 동안 소프트웨어 공학 컨설턴트로서 소프트웨어 개발에 관한 글을 써왔다. 우리나라의 열악한 소프트웨어 개발 환경의 핵심이 개발문화 때문이라고 생각해서 글로벌 개발 문화를 소개해 왔고 이제는 실제 한국의 소프트웨어 회사에 적용된 사례 소개하고 있다. 오늘은 소프트웨어 회사에서 경영자가 하면 안 되는 것들을 소개하려고 한다. 물론, 회사마다 기업문화가 달라서
회사에 새로운 직원들이 입사하면 업무를 가르치느라고 많은 노력이 들어간다. 특히 지식 산업인 소프트웨어 분야는 새로운 개발자가 입사를 하면 알려줘야 하는 것이 매우 많다. 회사마다 다르지만 신규 입사한 개발자가 개발에 투입되는 데는 짧게는 일주일부터 길게는 6개월까지 걸린다. 6개월은 내가 인터뷰 한 회사 중에 있었다. 알아야 할 지식과 법규가 많아서 6개월은 공부를 해야 개발에 투입된다고 한다. 그러다 보니
요즘 테슬라도 GE도 너도 나도 소프트웨어 회사라고 선언을 하고 소프트웨어에 엄청난 투자를 하고 있다. 그 와중에 우리나라 회사들은 소프트웨어에 실패했다고 자성을 하고 있다. Google의 1/100 실력이라고 자수를 하기도 한다. 최근에 대기업들의 대대적인 구조조정으로 수많은 소프트웨어 개발자들이 노동시장으로 쏟아져나 왔다. 우리나라 기업들도 소프트웨어만이 살길이고 소프트웨어 엄청나게 투자를 한다고 한 것이 불과 10여전 밖에 안되었다. 그 동안
필자가 그 동안 수많은 회사의 컨설팅을 하면서 경험한 바에 의하면 대부분의 회사가 일하는 방식에 있어서 “모 아니면 도”를 선택한다. 작은 회사는 서로 무슨 일을 하는지 속속들이 알기 때문에 프로세스가 없거나 단순하고 문서도 거의 없는 경우가 많다. 하지만 많은 대기업들은 과도하게 절차가 복잡하고 문서를 많이 작성해야 한다. 적절한 중간 정도의 프로세스를 유지하는 회사는 별로 없다. 그래서 작은 회사는 관리가 잘 안돼서 문제, 큰 회사는 형식으로 흐르고 비효율적이어서 문제다. 모두 그런 것은 아니지만 대부분의 회사가 여기에 해당한다. 웬만한 규모를 가진 회사의 관리자들은 보고서를 작성하는데 꽤 많은 시간을 소비한다. 보고서의 종류도 여러 가지고 보고서의 질에 따라서 업무의 성과에 대한 평가가 좌우되기도 한다. 개발자라고 예외는 아니다. 개발은 개발대로 하고 개발 후에 보고서 형태로 여러 문서를 별도로 작성하는 회사가 많다. 이런 보고서를 작성하는데 들어가는 노력과 시간은 낭비인 경우가 많다. 관리자나 경영자는 직원들이 작성한 보고서를 통해서 업무 내용을 파악하곤 하는데 여기에는 문제점이 있다. 보고서는 요약을 할 수 밖에 없다. 그 과정에서 중요한 정보들은 사라지고 문제점들이 숨겨지곤 한다. 보고자들은 대부분은 잘한 내용, 좋은 결과만 예쁘게 포장해서 보고를 하곤 한다. 이런 보고가 여러 단계를 거치다 보면 최고 경영자는 좋게 포장된 낙관적인 정보를 접하게 되는 경우가 많다. 까다로운 경영자와 일하는 직원들은 본연의 일보다도 보고서 작성에 과도하게 노력을 들이기도 한다. 일이야 어떻게 진행되었던 간에 보고서를 잘 작성해서 보고만 잘 넘기면 된다고 생각하기도 한다. 그리고 실제로 문제가 많은 상황에서도 보고서를 잘 작성해서 위기를 넘기기도 한다. 물론 이런 문제가 꾸준히 쌓이면 언젠간 폭발하기 마련이다. 보고서의 종류는 여러 가지가 있다. 먼저 업무 관리를 위해서 관리자에게 주기적으로 제출하는 보고서가 있다. 회사마다 형태는 다르지만 일일보고, 주간보고, 월간보고 형태로 업무 진행 내용을 요약해서 작성하고 보고하는 것이다. 이런 보고서는 일은 일대로 다 하고 별도로 작성하는 경우가 많다. 보고자는 별도의 보고서를 작성하기 위해서 시간을 낭비하지만 관리자도 이런 보고서를 보고 판단할 수 있는 것은 많지 않다. 피상적인 파악 밖에는 못한다. 하지만 이 정도의 보고도 안하면 관리자가 업무 파악이 어려워서 어쩔 수 없이 이런 보고라도 받는다. 주기적인 보고서 외에 단발성 보고서가 있다. 단발성 업무를 수행하고 그 결과를 보고서로 작성하는 것이다. 이 경우에도 보고를 위한 보고서를 작성한 후에 책꽂이에 꽂혀서 방치되는 경우가 종종 있다. 그럼 “모 아니면 도”가 아닌 “걸” 쯤 되는 방법은 없을까? 보고서를 최소화하고 업무의 효율성을 높이는 방법을 알아보자. 필자의 회사에서는 보고서 제로화를 추진하고 있다. 보고를 위한 보고서 작성을 모두 없애고 업무에 집중하려고 하는 것이다. 가장 먼저 관리를 위한 주기적인 보고서인 일일보고, 주간보고를 모두 폐지했다. 이렇게 하기 위해서 선행되어야 할 중요한 전제 조건이 있다. 바로 모든 업무의 정보가 Online system에 기록되어야 한다는 것이다. 필자의 회사에는 중요한 업무 규칙 한가지가 있다. "No issue, no work"가 바로 그것이다. 이슈관리시스템에 기록되지 않는 업무는 할 수 없고, 이슈를 생성하지 않고 업무를 진행하는 것도 금지되어 있다. 업무를 요청할 때도 오직 이슈관리시스템만을 이용해야 한다. 말로 요청할 수도 없고 Email로도 요청할 수 없다. 내부에서 직원끼리의 Email은 금지되어 있다. 공식 커뮤니케이션 수단은 오직 이슈관리시스템 밖에 없으므로 나머지 어떠한 수단도 공식 수단은 아니다. 이러다 보니 모든 정보는 이슈관리시스템으로 모이고 시간과 장소를 구애 받지 않고 커뮤니케이션이 가능하며 업무를 할 수 있다. Email은 당사자끼리만 정보를 아는 폐쇄적인 시스템이고 추적도 관리도 안된다. 따라서 Email을 통한 업무 처리는 철저히 금지되어 있다. Email은 외부인과만 주고 받을 수 있다. 이렇게 이슈관리시스템을 통해서 업무를 하다 보면 일일이 승인을 받고 일을 할 필요도 없다. 스스로 해야 할 일이라고 생각하면 이슈를 등록하고 일을 하면 되고 관리자는 모니터링을 할 뿐이다. 물론 지시를 하는 경우도 있다. 이런 자율적인 분위기가 자연스럽게 자리를 잡기 위해서는 수평적인 조직문화가 필수적이다. 시키는 일만 하는 것이 아니라 스스로 일을 찾아서 하고 정보는 공유되고 서로 모니터링을 하면서 문제를 해결해 나간다. 관리자나 경영자는 요약된 보고서를 보는 것이 아니라 이슈관리시스템을 통해서 모든 업무 진행 내용을 모조리 다 보는 것이다. 그래서 별도의 보고가 따로 필요 없다. 모든 내용을 다 보는데 시간이 엄청나게 많이 소요될 것 같지만 막상 해보면 그렇지 않다. 이 직원 저 직원 불러다가 보고 받는 것보다는 시간이 적게 걸린다. 그리고 업무를 마친 후에 보고를 받으면 일이 잘못 되었을 경우 이미 늦어 버린 것이다. 질책 밖에 할 것이 없다. 하지만 일이 진행되는 처음부터 계속 모니터링을 하면 중간 중간에 계속 의견을 제시할 수 있고 일이 잘못 진행되는 경우는 많이 줄어들게 된다. 처음에는 직원들이 모든 커뮤니케이션을 이슈관리시스템을 통해서 해야 하고 모든 정보를 다 남겨야 하는 것을 힘들어 했지만 별도의 보고서를 작성해야 할 필요가 없고 업무도 더 원활하게 진행이 되므로 이제는 이런 환경에 적응했다. 이제는 과거로 돌아가자고 해도 모두 반대를 할 것이다. 과거에 Email과 대화 위주로 일하면서 정보도 제대로 남기지 않았던 때를 생각하면 끔찍하게 생각된다. 그때 그렇게 하고도 어떻게 일을 했는지 신기하게 생각될 정도다. 누구나 이런 문화를 1년 정도만 경험하게 되면 그렇게 생각될 것이다. 물론 보고서가 아예 없는 것이 아니다. 단발성 업무를 진행할 때는 보고서를 작성하지만 보고를 위한 보고서가 아니다. 예쁘게 꾸미기 위한 PPT(Power Point)는 금지되어 있고, 대부분은 Word로 작성을 한다. 보고는 별도로 하지 않고 시스템에 등록하며 경영자도 똑같이 시스템에 등록된 보고서를 리뷰 한다. 보고보다는 리뷰를 한다고 보면 된다. 추가 논의가 필요할 때만 만나서 얘기를 한다. 물론 추가 논의한 내용도 시스템에 기록된다. 대기업을 비롯한 많은 회사들은 KMS, Wiki 등 지식과 정보를 온라인으로 구축하는데 실패했다. 성공적인 회사도 있지만 그리 많지는 않다. 아무리 강제화를 해도 형식적인 정보만 쌓이고 직원들은 프로세스를 요리조리 피해 다닌다. 이런 환경에서 자신이 가지고 있는 정보를 혼자서 시스템에 고스란히 남기면 자신만 손해를 보는 환경인 것이다. 모든 직원이 정보를 공유하는 것이 습관화되지 않은 곳에서는 지식과 정보가 온라인에 쌓이지가 않는다. 이것이 많은 회사들이 지식과 정보를 시스템에 모으고 공유하는데 실패하는 이유다. 기업문화는 바꾸기 어렵다. 프로세스로 강제화 해도 어렵다. 프로세스가 오히려 방해가 되는 경우도 많다. 여기서
“월화수목금금금”은 지금도 회자되는 유명한 이야기다. 그리고 모 회사 대표는 신제품 발표회에서 개발기간 동안 개발자가 집에 못 들어가서 이혼을 했다고 자랑 아닌 자랑을 한적도 있다. 개발자들을 연구소에 가둬놓고 밖에서 자물쇠로 잠궈 놓고 주말에도 집에 못가게 했으며 기혼자만 일주일에 하루씩 집에 보내 줬다고 자랑을 하는 경영자도 있다. 자신이 직원들을 얼마나 혹사시켰는지 그렇게 자랑을 하는 이유를 모르겠다. 그래서 한국에서 개발자라는 직업이 유난히 인기가 없고 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년이 넘고 개발은 매우 잘 하지만 관리는 싫어하는 천상 개발자다. 하지만 회사에서 개발실 관리를 맡기니 어쩔 수 없이 관리를 해야 했고 보고서 작성, 회의 등으로 거의 모든 시간을 보내고 정작 자신이 잘하고 좋아하는 개발 일은 거의 못했다. 그래서 스트레스도 매우 심했다.