개발자가 입사 첫날 버그를 고칠 수 있어야 하는 이유

회사에 새로운 직원들이 입사하면 업무를 가르치느라고 많은 노력이 들어간다. 특히 지식 산업인 소프트웨어 분야는 새로운 개발자가 입사를 하면 알려줘야 하는 것이 매우 많다. 회사마다 다르지만 신규 입사한 개발자가 개발에 투입되는 데는 짧게는 일주일부터 길게는 6개월까지 걸린다. 6개월은 내가 인터뷰 한 회사 중에 있었다. 알아야 할 지식과 법규가 많아서 6개월은 공부를 해야 개발에 투입된다고 한다. 

그러다 보니 입사 후 빨리 업무에 투입될 수 있는 동일직종 경력자를 선호하곤 한다. 이런 회사가 많을수록 개발자들은 이직 시 선택의 폭이 좁아지게 된다. 개발자들이 주로 같은 분야로만 옮겨 다니다 보니 이직도 어렵고 업계간 개발자 순환이 잘 안 된다.  

여기 가상의 A, B, C, D 회사가 있다. 

A사는 김부장이 개발 전반의 내용을 다 꿰뚫고 있어서 신규 개발자가 입사하면 김부장이 1주일 정도 교육을 해줘야 한다. 김부장은 다른 어떤 직원보다 개발 내용을 많이 알고 있어서 웬만한 이슈는 다 김부장을 통해야 해결이 된다. 개발자가 입사를 할 때마다 김부장이 교육을 하기 때문에 개발자들이 김부장에게 많이 의존하고 김부장은 회사의 경영진에게도 신망이 두텁다. 

B사는 개발자 입사 시 개발에 필요한 기본적인 제품에 대한 지식이나 기술을 교육 시키기 위해서 선배들이 돌아가면서 며칠 동안 교육을 해야 한다. 물론 교육을 받자마자 신규 개발자들이 개발을 제대로 하지는 못한다. 사수에게 꾸준히 개발 내용을 전수 받아야 한다. 

C사에서는 업무를 잘 알지 못하면 개발을 하기 어렵기 때문에 업무를 모두 파악하는데 6개월 이상이 걸리고 그때까지는 신규 개발자는 허드렛일 밖에 못한다. 고참이 10분이면 할 수 있는 일을 신규 개발자는 몇 시간이 걸리고 잘못될 위험성도 높아서 신규 개발자에게는 일을 제대로 시키지 못한다. 그러다 보니 신규 개발자가 많이 입사를 해도 고참들은 여전히 바쁘다. 

D사에서는 고참들이 기존 제품의 유지보수에 매달려 있어서 신규 개발자에게 업무를 제대로 전달하지 못한다. 그러다 보니 신규 프로젝트는 신규 개발자들이 담당하게 되었고 기존의 개발자들은 여전히 유지보수에 매달리고 있다. 

A~D사 모두 신규 개발자가 입사하마자 스스로 일할 수 있는 체계를 갖추고 있지 못하고 있다. 이런 구조의 회사는 작은 규모였을 때는 문제가 안보이지만 회사가 커질수록 문제가 급속도로 드러나서 개발 효율은 바닥을 치게 된다. 이런 회사에서는 기존의 고참 개발자들은 신규 개발자들의 무능함과 열정 부족을 탓하게 되고 신규 개발자들은 정보 공유 부족으로 개발하기 어려운 환경을 탓하게 된다. 

필자는 여러 회사에서 강연이나 세미나를 할 때 신규 개발자가 입사 후 개발에 투입되어서 버그를 고치는데 시간이 얼마나 걸리는지 물어본다. 그리고 그 과정에서 고참 개발자들이 얼마나 업무를 가르쳐 주기 위해서 시간을 투자해야 하는지 물어본다. 이 질문에 대한 대답을 통해서 그 회사의 개발체계와 개발 문화의 성숙함을 알 수 있다. 대부분의 회사가 일주일 이상 걸리고 몇 달까지 걸리는 회사도 있었다. 또한 많은 회사들이 사수/부사수 제도를 이용하여 고참들이 많은 시간을 투자하여 가르쳐주고 있다. 

내가 생각하는 가장 이상적인 답변은 고참 개발자들의 시간은 거의 투자하지 않고 신규 입사 개발자가 입사 첫날 또는 둘째 날까지 스스로 버그를 고치는 것이다. 고참들은 코드 리뷰를 해주는 정도면 충분하다. 이렇게 할 수 있는 회사는 자세히 물어보지 않아도 성숙한 개발 체계와 개발 문화를 갖추고 있다는 것을 알 수 있다. 불행히도 필자가 접한 우리나라의 수십 개의 회사 중에서 그런 회사는 없었다. 

미국에 취업을 해본 개발자들은 알겠지만, 개발자가 입사했을 때 선배들이 뭘 자세히 가르쳐주는 회사는 많지 않다. 이슈를 할당해주면 알아서 고쳐야 하고 개발 프로세스대로 코드 리뷰 등을 진행할 뿐이다. 물어보면 가르쳐주기는 하는데 먼저 나서서 가르쳐 주는 경우는 별로 없다. 회사는 학교가 아니기 때문이다. 

필자가 CEO로 있는 이우소프트에서도 신규 개발자에게는 이슈를 그냥 할당해주고 개발자는 하루 이틀 안에 이슈를 해결하고 코드리뷰를 진행한다. 물론 여기에 약간의 문제가 있다. 이제부터 어떻게 해야 이렇게 할 수 있고 문제가 무엇인지 얘기를 해보고자 한다. 그럼 시간 순서대로 따라가보자. 

• 2주일 전 - 신규 개발자용 개발 PC를 준비한다.
• 1주일 전 - 신규 개발자가 입사하기 며칠 전에 PM이 미리 신규 개발자가 해결할 수 있을만한 쉬운 버그 몇 개를 할당 해 놓는다.
• 3일 전 - 신규 개발자용 개발 PC에 개발환경을 구축한다. 이미지 백업 받아 놓은 것을 이용해서 한번에 구축한다. 
• 입사 당일 9시 - PM이 개발자에게 이슈관리시스템 URL을 알려주고, 신규 입사자들이 봐야 하는 가이드가 적혀 있는 사이트 URL을 알려준다. (Wiki 등)
• 10시 - 가이드대로 소스코드관리시스템에서 소스코드를 내려 받아서 Build script를 이용해서 Full build를 수행한다.
• 11시 - Build가 진행되는 동안 PM이 알려준 이슈관리시스템의 URL에 접속해서 내가 할당 받은 버그(이슈)를 확인한다. 첫 번째로 고칠 버그를 선택한다.
• 12시 - 식사
• 13시 - 개발 프로세스 문서를 통해서 기본적인 개발 프로세스를 확인한다.
• 14시 - 첫 번째 버그를 고친다. 첫 번째 버그는 간단한 버그라서 스펙/설계 문서 도움 없이 고칠 수 있다.
• 15시 - 소스코드를 commit하고 코드리뷰를 등록한다. 회사에 따라서 코드리뷰를 종료하고 commit하는 회사도 있다.
• 16시 - 리뷰어가 코드리뷰를 진행하고 Confirm을 한다.
• 17시 - 해당 버그 이슈가 close 된다.
• 이제 좀더 빠른 속도로 다른 버그들을 고쳐나간다.
• 개발자의 역량을 확인하고 좀더 어려운 버그와 신규 기능을 할당한다. 

이렇게 진행하기 위해서는 몇 가지 전제조건이 있다. 

• 개발 시스템이 제대로 구축되어 있어야 한다. 이슈관리, 소스코드관리, 빌드 등이 잘 시스템화 되어 있어야 한다.
• 스펙, 설계, 개발 가이드, 개발 프로세스 등의 개발 정보가 Doc, Wiki, Issue 등에 문서로 충분히 기록되어 있어야 한다.
• 신규 입사자가 이와 같은 개발환경에 익숙해서 입사하자 마자 일을 할 수 있어야 한다.

하지만 현실적으로 마지막 조건에 문제가 발생한다. 대학에서 소프트웨어를 전공한 개발자도 이슈관리시스템을 한번도 써보지 못하고 입사를 하는 경우가 대부분이다. 기껏해야 Subversion이나 Git의 기본기능을 써본 것이 개발 시스템을 써본 것의 전부인 경우가 많다. 그래서 회사에서 아무리 준비가 잘 되어 있다고 하더라도 입사 첫날 버그를 고치기는 어렵다. 그래서 기본적인 개발 프로세스와 개발 시스템에 대한 교육을 먼저 시키고 진행을 해야 한다. 이 때문에 하루, 이틀 지연이 될 뿐이지 그 이후에 개발을 하는 것은 별 문제가 없다. 

이런 환경에 개발을 한다면 본인도 자연스럽게 공유를 중심으로 한 개발 문화를 자연스럽게 익히고 대부분의 지식과 경험은 선배들이 남겨놓은 문서를 통해서 습득하게 된다. 그래서 선배 개발자들은 신규 개발자가 입사를 하면 시간을 더 빼앗기는 것이 아니라 귀찮았던 일을 덜어주게 되고 선배 개발자들은 더 어려운 일을 하게 되고 새로운 일을 할 수 있다. 물론 문서로 모든 지식이 공유되는 것은 아니고 선배에게 물어봐야 하는 시간이 상당히 줄어드는 것이다. 공유를 하고 후배 개발자들이 일을 하기 쉽게 만들어 놓는 것은 바로 자신이 앞으로 나아갈 수 있게 만드는 것과 같다. 

신입 개발자가 입사를 하면 아무 것도 가르쳐주지 말고 버그만 달랑 할당해보자. 그리고 무슨 일이 벌어지는지 보자. 선배를 귀찮게 하지 않고 스스로 첫날 버그를 해결하면 문제가 없는 것이고 2,3일 넘어가도 버그를 못 고치면 뭔가 문제가 있는 상황이다. 어떠한 문제 때문에 신입 개발자가 버그를 고치지 못하는지 잘 분석해보자. 거기에 회사의 만들어 나가야 할 개발체계, 개발문화가 있다. 

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

기업문화를 바꾸기 어려운 이유

요즘 테슬라도 GE도 너도 나도 소프트웨어 회사라고 선언을 하고 소프트웨어에 엄청난 투자를 하고 있다.

그 와중에 우리나라 회사들은 소프트웨어에 실패했다고 자성을 하고 있다. Google의 1/100 실력이라고 자수를 하기도 한다. 최근에 대기업들의 대대적인 구조조정으로 수많은 소프트웨어 개발자들이 노동시장으로 쏟아져나 왔다.

우리나라 기업들도 소프트웨어만이 살길이고 소프트웨어 엄청나게 투자를 한다고 한 것이 불과 10여전 밖에 안되었다. 그 동안 수많은 소프트웨어 개발자를 채용하고 교육하고, 기업문화를 바꾸기 위해서 엄청나게 애를 썼다.

그런데 왜 결과가 이런가? 필자는 소프트웨어 개발에 있어서 기업에게 가장 중요한 것은 천재적인 개발자도 아니고, 엄청나게 많은 돈을 투자해야 하는 것도 아니고 바로 "기업문화"라고 생각한다.

물론 우리나라 대기업들이 "기업문화" 개혁에 투자를 하지 않은 것이 아니다. 엄청나게 투자를 했다. 그런데 왜 과거와 별반 다른 것이 없을까? 물론 조직이 너무 크고 기득권 세력이 강해서 쉽게 바뀌지 못하는 한계도 있다.

필자는 여러 기업에서 기업문화를 바꾸겠다고 얘기를 할 때 실패를 할 것이 뻔히 예상된다. "기업문화"를 넘어서 "문화"란 남들이 하는 것을 보고 흉내를 내기는 어렵다. 기껏해야 공짜 점심 같은 것을 흉내낼 뿐이다.

여기에 개들이 다니는 "D"사가 있다. "D"사의 개들은 모두 네발로 걸어 다닌다. 그런데 그들이 배우고 싶은 "H"사의 개들은 두발로 다니고 SW 개발 역량이 D사의 100배이다. 그럼 어떻게 해야 D사는 H사의 문화를 배울 수 있을까? D사의 경영진들은 H사의 개들이 두발로 걸어 다니고 두발로 걷는 것은 SW 개발 역량 향상에 필수적이라는 것은 이미 알려진 사실이므로 D사 직원 모두에게 이제부터 모두 두발로 걷게 한다. 하지만 두발로 걷는 것은 보통 어려운 것이 아니다. D사의 직원들은 남들이 볼 때는 두발로 걷고 안볼 때는 네발로 걷게 된다. 또한 이런 어려움을 아는 관리자들은 형식적으로 점검을 하게 된다. 네발로 걷는 것이 익숙한 관리자들은 말로는 "두발로 걸어야 한다"고 하면서도 어떻게 해야 하는지 잘 모른다. 형식적으로 흉내를 낼 뿐이다.

이 과정에서 D사의 직원들은 죽을 맛이다. 두발로 걷는 방법을 제대로 알려주지도 않고 겉모습만 잔뜩 알려주니 따라할 수가 없다. 겉으로는 두발로 걷는 척해야 하고 실제 일은 네발로 해야 진행이 되므로 일은 두배로 힘들어진다.

D사의 경영진들은 직원들이 모두 두발로 걷는데 왜 여전히 SW 개발 역량이 향상되지 못하는지 한탄을 하게 된다.

내가 생각하는 D사가 바뀌는 방법은 이렇다. 먼저 두발로 걷는 것이 당연한 H사나 비슷한 회사의 전문가들이 D사의 중요 직책으로 들어온다. 이들은 D사의 직원들을 두발로 걷게 하고 같이 일하면서 수백 가지의 노하우를 직원들에게 전수한다. 직원들이 수시로 네발로 걸으려고 할 때마다 그 상황에 맞게 코칭을 계속한다. 이러면서 새로 D사에 입사한 직원들은 두발로 걷는 것이 당연한 환경에서 생활을 하게 된다. 이렇게 10년쯤 일을 하면 D사에서도 개들은 두발로 걷는 것이 당연한 문화가 된다.

그래서 문화가 바뀌려면 적어도 10년은 각고의 노력을 해야 한다고 생각한다. 완전히 정착하려면 세대가 바뀌어야 한다. 기업에서 세대가 바뀌는데는 10년이 걸린다.

SW를 개발하는데 핵심 문화인 "수평적인 조직", "공유", "문서", "리뷰", "토론" 등 여러 문화는 남들이 하는 것을 보고 흉내를 낼 수 없다. Template과 Process를 흉내내면 더 망가질 뿐이다. 또한 전문가를 영입해도 힘이 없으면 고군분투하다가 포기할 뿐이다.

Google의 1/100 실력이라고 하면서 또, 과거와 비슷하게 스스로 열심히 뭔가 개혁을 해보려고 하고 단기간에 성과를 내보려고 한다면 매번 반복되는 현상이 이번에도 반복될 것이다. 

share with abctech.software

보고서를 효율적으로 줄이는 방법

필자가 그 동안 수많은 회사의 컨설팅을 하면서 경험한 바에 의하면 대부분의 회사가 일하는 방식에 있어서 “모 아니면 도”를 선택한다. 작은 회사는 서로 무슨 일을 하는지 속속들이 알기 때문에 프로세스가 없거나 단순하고 문서도 거의 없는 경우가 많다. 하지만 많은 대기업들은 과도하게 절차가 복잡하고 문서를 많이 작성해야 한다. 적절한 중간 정도의 프로세스를 유지하는 회사는 별로 없다. 그래서 작은 회사는 관리가 잘 안돼서 문제, 큰 회사는 형식으로 흐르고 비효율적이어서 문제다. 모두 그런 것은 아니지만 대부분의 회사가 여기에 해당한다.

웬만한 규모를 가진 회사의 관리자들은 보고서를 작성하는데 꽤 많은 시간을 소비한다. 보고서의 종류도 여러 가지고 보고서의 질에 따라서 업무의 성과에 대한 평가가 좌우되기도 한다. 개발자라고 예외는 아니다. 개발은 개발대로 하고 개발 후에 보고서 형태로 여러 문서를 별도로 작성하는 회사가 많다. 이런 보고서를 작성하는데 들어가는 노력과 시간은 낭비인 경우가 많다. 

관리자나 경영자는 직원들이 작성한 보고서를 통해서 업무 내용을 파악하곤 하는데 여기에는 문제점이 있다. 보고서는 요약을 할 수 밖에 없다. 그 과정에서 중요한 정보들은 사라지고 문제점들이 숨겨지곤 한다. 보고자들은 대부분은 잘한 내용, 좋은 결과만 예쁘게 포장해서 보고를 하곤 한다. 이런 보고가 여러 단계를 거치다 보면 최고 경영자는 좋게 포장된 낙관적인 정보를 접하게 되는 경우가 많다. 

까다로운 경영자와 일하는 직원들은 본연의 일보다도 보고서 작성에 과도하게 노력을 들이기도 한다. 일이야 어떻게 진행되었던 간에 보고서를 잘 작성해서 보고만 잘 넘기면 된다고 생각하기도 한다. 그리고 실제로 문제가 많은 상황에서도 보고서를 잘 작성해서 위기를 넘기기도 한다. 물론 이런 문제가 꾸준히 쌓이면 언젠간 폭발하기 마련이다. 

보고서의 종류는 여러 가지가 있다. 먼저 업무 관리를 위해서 관리자에게 주기적으로 제출하는 보고서가 있다. 회사마다 형태는 다르지만 일일보고, 주간보고, 월간보고 형태로 업무 진행 내용을 요약해서 작성하고 보고하는 것이다. 이런 보고서는 일은 일대로 다 하고 별도로 작성하는 경우가 많다. 보고자는 별도의 보고서를 작성하기 위해서 시간을 낭비하지만 관리자도 이런 보고서를 보고 판단할 수 있는 것은 많지 않다. 피상적인 파악 밖에는 못한다. 하지만 이 정도의 보고도 안하면 관리자가 업무 파악이 어려워서 어쩔 수 없이 이런 보고라도 받는다. 

주기적인 보고서 외에 단발성 보고서가 있다. 단발성 업무를 수행하고 그 결과를 보고서로 작성하는 것이다. 이 경우에도 보고를 위한 보고서를 작성한 후에 책꽂이에 꽂혀서 방치되는 경우가 종종 있다. 

그럼 “모 아니면 도”가 아닌 “걸” 쯤 되는 방법은 없을까? 보고서를 최소화하고 업무의 효율성을 높이는 방법을 알아보자. 

필자는 이우소프트에서 보고서 제로화를 추진하고 있다. 보고를 위한 보고서 작성을 모두 없애고 업무에 집중하려고 하는 것이다.  

가장 먼저 관리를 위한 주기적인 보고서인 일일보고, 주간보고를 모두 폐지했다. 

이렇게 하기 위해서 선행되어야 할 중요한 전제 조건이 있다. 바로 모든 업무의 정보가 Online system에 기록되어야 한다는 것이다. 이우소프트에는 중요한 업무 규칙 한가지가 있다. "No issue, no work"가 바로 그것이다. 이슈관리시스템에 기록되지 않는 업무는 할 수 없고, 이슈를 생성하지 않고 업무를 진행하는 것도 금지되어 있다. 업무를 요청할 때도 오직 이슈관리시스템만을 이용해야 한다. 말로 요청할 수도 없고 Email로도 요청할 수 없다. 내부에서 직원끼리의 Email은 금지되어 있다. 공식 커뮤니케이션 수단은 오직 이슈관리시스템 밖에 없으므로 나머지 어떠한 수단도 공식 수단은 아니다. 

이러다 보니 모든 정보는 이슈관리시스템으로 모이고 시간과 장소를 구애 받지 않고 커뮤니케이션이 가능하며 업무를 할 수 있다. Email은 당사자끼리만 정보를 아는 폐쇄적인 시스템이고 추적도 관리도 안된다. 따라서 Email을 통한 업무 처리는 철저히 금지되어 있다. Email은 외부인과만 주고 받을 수 있다. 

이렇게 이슈관리시스템을 통해서 업무를 하다 보면 일일이 승인을 받고 일을 할 필요도 없다. 스스로 해야 할 일이라고 생각하면 이슈를 등록하고 일을 하면 되고 관리자는 모니터링을 할 뿐이다. 물론 지시를 하는 경우도 있다. 이런 자율적인 분위기가 자연스럽게 자리를 잡기 위해서는 수평적인 조직문화가 필수적이다. 시키는 일만 하는 것이 아니라 스스로 일을 찾아서 하고 정보는 공유되고 서로 모니터링을 하면서 문제를 해결해 나간다. 

관리자나 경영자는 요약된 보고서를 보는 것이 아니라 이슈관리시스템을 통해서 모든 업무 진행 내용을 모조리 다 보는 것이다. 그래서 별도의 보고가 따로 필요 없다. 모든 내용을 다 보는데 시간이 엄청나게 많이 소요될 것 같지만 막상 해보면 그렇지 않다. 이 직원 저 직원 불러다가 보고 받는 것보다는 시간이 적게 걸린다. 그리고 업무를 마친 후에 보고를 받으면 일이 잘못 되었을 경우 이미 늦어 버린 것이다. 질책 밖에 할 것이 없다. 하지만 일이 진행되는 처음부터 계속 모니터링을 하면 중간 중간에 계속 의견을 제시할 수 있고 일이 잘못 진행되는 경우는 많이 줄어들게 된다. 

처음에는 직원들이 모든 커뮤니케이션을 이슈관리시스템을 통해서 해야 하고 모든 정보를 다 남겨야 하는 것을 힘들어 했지만 별도의 보고서를 작성해야 할 필요가 없고 업무도 더 원활하게 진행이 되므로 이제는 이런 환경에 적응했다. 이제는 과거로 돌아가자고 해도 모두 반대를 할 것이다. 과거에 Email과 대화 위주로 일하면서 정보도 제대로 남기지 않았던 때를 생각하면 끔찍하게 생각된다. 그때 그렇게 하고도 어떻게 일을 했는지 신기하게 생각될 정도다. 누구나 이런 문화를 1년 정도만 경험하게 되면 그렇게 생각될 것이다. 

물론 보고서가 아예 없는 것이 아니다. 단발성 업무를 진행할 때는 보고서를 작성하지만 보고를 위한 보고서가 아니다. 예쁘게 꾸미기 위한 PPT(Power Point)는 금지되어 있고, 대부분은 Word로 작성을 한다. 보고는 별도로 하지 않고 시스템에 등록하며 경영자도 똑같이 시스템에 등록된 보고서를 리뷰 한다. 보고보다는 리뷰를 한다고 보면 된다. 추가 논의가 필요할 때만 만나서 얘기를 한다. 물론 추가 논의한 내용도 시스템에 기록된다.  

대기업을 비롯한 많은 회사들은 KMS, Wiki 등 지식과 정보를 온라인으로 구축하는데 실패했다. 성공적인 회사도 있지만 그리 많지는 않다. 아무리 강제화를 해도 형식적인 정보만 쌓이고 직원들은 프로세스를 요리조리 피해 다닌다. 이런 환경에서 자신이 가지고 있는 정보를 혼자서 시스템에 고스란히 남기면 자신만 손해를 보는 환경인 것이다. 모든 직원이 정보를 공유하는 것이 습관화되지 않은 곳에서는 지식과 정보가 온라인에 쌓이지가 않는다. 이것이 많은 회사들이 지식과 정보를 시스템에 모으고 공유하는데 실패하는 이유다. 

기업문화는 바꾸기 어렵다. 프로세스로 강제화 해도 어렵다. 프로세스가 오히려 방해가 되는 경우도 많다. 여기서 가장 중요한 것은 경영자의 의지와 직원들의 참여다. 경영자가 바뀔 기업문화의 핵심을 제대로 이해하고 강력한 의지를 가지고 추진한다면 시간은 걸리겠지만 기업문화 정착에 성공할 것이다. 이우소프트에서도 이러한 도전은 계속 되고 있다.

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