2016년 7월 29일 금요일

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

회사에 새로운 직원들이 입사하면 업무를 가르치느라고 많은 노력이 들어간다. 특히 지식 산업인 소프트웨어 분야는 새로운 개발자가 입사를 하면 알려줘야 하는 것이 매우 많다회사마다 다르지만 신규 입사한 개발자가 개발에 투입되는 데는 짧게는 일주일부터 길게는 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에 기고한 글입니다.

2016년 7월 3일 일요일

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

요즘 테슬라도 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