이우소프트에서 개발자를 채용하는 방법

최고의 개발자들이 최고의 소프트웨어를 만든다.

그래서 뛰어난 개발자를 채용하는 것은 소프트웨어 회사에서 가장 중요한 일이다. 그럼, 뛰어난 개발자의 정의는 무엇일까?

필자는 대한민국의 여러 벤처기업, 대기업, 중소기업, 실리콘밸리의 회사들에 대한 기업 문화를 두루 경험하고 봐왔기 때문에 나름 노하우가 생겨서 이를 공유하고자 하는 것이다. 물론 독자들이 처한 환경과 완전히 배치되는 의견이 될 수도 있음을 밝혀둔다. 인재는 1년에서 3년 이상 장기적인 관점으로 투자를 해야 하는 것이기 때문에 그 정도의 여유도 없다면 공염불인 이야기다.

필자가 채용한 개발자 중에서 최고의 개발자들은 이전 회사에서 뛰어난 개발자로 인정을 받지 못하고 연봉도 낮은 경우가 많았다. 흔히 얘기하는 중위권 대학 출신이거나 개발 환경이 안 좋아서 능력을 발휘하지 못한 경우들이다. 실리콘밸리에 있는 좋은 환경의 회사에 입사를 했다면 몇 년 안에 뛰어난 개발자라는 평가를 들을 사람들도 좋지 않은 개발 환경에서는 실력 발휘도 못하고 인정도 못 받는다. 잠재력은 프리미어리그 급인데 조기축구에서 볼보이하는 격인데, 사실 축구에서 이런 일이 벌어지지는 않을 것이다. 하지만 소프트웨어 필드에서는 이런 일이 종종 벌어진다.

반대의 경우도 있다. 우리 주변에는 흔히 뛰어나 개발자라고 일컫는 사람들이 있다. 이렇게 뛰어난 개발자라고 칭송 받는 개발자들 중에는 형편 없는 개발자들이 매우 많다. 이러한 개발자들을 “헛똑똑이”라고 부른다. 똑똑하기는 한데 다 헛것이라는 의미다. 지식과 경험은 뛰어나지만 논리적인 사고, 협동심, 인내심, 겸손함 등이 부족하고 오만함과 아집으로 자신만이 옳다고 생각하고 바뀌지 않으려고 하기 때문이다. 이러한 “헛똑똑이” 개발자들은 회사에서 “영웅”으로 불리면서 동료들을 이끌고 구렁텅이로 들어가곤 한다. 이러한 문제 개발자와 진짜 뛰어난 개발자를 잘 구분할 필요가 있다.

개발자의 역량은 크게 세가지로 나뉜다.

- 시간이 흐르면 향상되는 것 : SW 지식, 기술, 경험, 도메인 지식
- 좋은 환경에서 향상되는 것 : 협동심, 커뮤니케이션 능력, 문서 작성 능력, 공유
- 노력해도 크게 바뀌지 않는 것 : 수학적이고 논리적인 사고력, Top-down 사고, 창의력, 겸손함 (인내심, 오만함, 아집)

세가지 모두 뛰어난 역량을 가진 개발자라면 정말 좋겠지만, 그런 사람을 찾기란 쉽지가 않다. 신입이나 쥬니어와 경력이 많은 시니어 개발자를 채용할 때 기준이 다르다.

신입 개발자는 “노력해도 크게 바뀌지 않는 것”을 위주로 판단한다. 특히 수학적, 논리적 사고력을 가장 높게 본다. 나머지는 좋은 환경에서 개발을 하면 자연스럽게 향상되는 것들이다.

경력 개발자는 세가지를 모두 봐야 한다. 경력에 걸맞은 지식과 경험도 본다. 여기서도  “노력해도 거의 바뀌지 않는 것”은 중요하다. 게다가 협업, 커뮤니케이션, 문서 작성 등과 관련하여 나쁜 습관이 있는지도 본다.

그럼 좀더 구체적으로 개발자를 채용하는 방법을 얘기해보자.

필자가 가장 선호하는 채용 방식은 직원 또는 지인에게 소개를 받는 것이다. 일단 직원이나 지인은 문제가 되는 사람은 소개를 하지 않고 역량도 꽤 뛰어난 사람을 소개하곤 해서 경험적으로 성공 확률이 매우 높다.

하지만 소개만으로 모든 개발자를 채용하기는 매우 어렵다. 그래서 채용공고, 홈페이지, SNS, 헤드헌터나 서치펌 등 다양한 경로를 이용해서 개발자를 채용할 수 밖에 없다. 하지만 이렇게 공개적으로 채용을 할 경우 짧은 시간에 개발자의 실력을 측정하고 회사에 적합한 사람인지 알아내기가 쉽지는 않다. 특히 경험이 많은 개발자들의 화려한 언변에 현혹이 되면 실체를 파악하지 못하는 경우도 많다.

그래서 필자가 개발자를 어떻게 채용하는지 설명하려고 한다. 물론 일반적인 관점과 좀 다를 수는 있다. 필자의 회사에서는 개발과 관리가 완벽히 분리되어 있고 개발 체계와 문화도 실리콘밸리의 소프트웨어 회사들과 비슷하다.  채용에 있어서 특이한 것이 2가지가 있다.

첫째, 동일 도메인 경험이 풍부한 개발자를 특별히 선호하지 않는다.

금융회사는 금융회사 출신의 개발자를 선호하고 보안, 게임 등 여러 분야에서 도메인 경험은 상당한 우대 요소로 작용을 한다. 그 이유는 도메인 지식을 익히는데 시간이 오래 걸리고 그때까지는 역량을 제대로 발휘하지 못하기 때문이다. 물론 도메인 경험이 도움이 안되는 것이 아니다. 하지만 도메인 경험보다 개발자 본연의 역량이 훨씬 중요하고 도메인 지식은 시간이 흐르면 익혀지지만 원초적인 개발 역량은 쉽게 바뀌지 않는다. 게다가 도메인 지식으로 개발 후보를 제한하면 좋은 개발자를 채용할 수 있는 범위가 좁아진다. 이렇게 도메인 지식보다 기초 역량을 중요시 하는 것이 중장기적으로 좋다.

둘째, 관리 능력이 뛰어난 개발자를 별로 선호하지 않는다. 오히려 꺼려한다.

우리나라에서 개발자들은 경력이 5년~10년 정도 되면 조금씩 관리 요구를 받게 되고 관리를 하면 할수록 개발에 매진할 시간은 줄어든다. 소프트웨어 개발이 관리도 하면서 짬짬이 해서 실력을 꾸준히 유지하고 발전시킬 만큼 쉽지가 않다. 관리 능력도 뛰어난 개발자를 선호하는 회사도 있지만 우리 회사에서는 개발과 관리가 철저히 분리되어 있기 때문에 개발자는 순수 개발 능력만을 본다. 관리 능력도 있는 개발자라면 관리 능력은 쏙 빼고 개발 능력만 보기 때문에 관리 능력이 뛰어난 개발자가 관리자가 아닌 개발자로 채용되는 경우는 흔치 않다. 축구선수를 뽑는데 농구도 잘하는 경우는 축구선수로 채용되기 어려운 경우와 비슷하다고 할까? 물론 어쩔 수 없이 관리도 했지만 개발역량이 뛰어난 개발자도 있다. 이런 개발자라면 채용에 문제가 없다.

우리 회사도 타사와 채용 절차는 크게 다르지 않다. 서류심사, 온라인 코딩테스트, 전화 인터뷰, 대면 인터뷰 이런 순서대로 진행이 된다. 대면 인터뷰에서는 즉석에서 칠판에 쓰는 코딩테스트를 진행한다. 20년차 개발자를 채용할 때도 코딩테스트는 필수다. 그럼 채용 시 중점을 두는 것에는 어떤 것들이 있는지 알아보자.

첫째, 출신 대학과 전공은 별로 중요하지 않다. 남녀, 국적도 따지지 않는다.

실제로 출신 대학과 무관하게 코딩테스트에서는 매우 뛰어난 결과를 보였고 천재적인 역량을 발휘한 사례도 있다. 학교 성적과 상관없이 논리적인 사고력이나 수학적인 능력이 뛰어난 사람이 소프트웨어 개발에 탁월한 경우도 드물지 않게 있다. 전공도 마찬가지다. 소프트웨어 전공이 아닌 경우에도 뛰어난 개발자를 자주 발견하고 한다. 최근에는 수학, 통계학 등의 전공자를 일부러 찾기도 한다. 야근이 수월한 체력이 좋은 남자를 선호하는 회사도 있지만 성별을 전혀 따지지 않는다. 또한 국적도 따지지 않고 한국어를 못해도 실력만 좋거나 잠재력만 뛰어나도 채용을 한다.

둘째, 온라인 코딩 테스트를 통해서 개발자 기초 역량을 확인한다.

온라인 코딩 테스트는 보통 3문제를 제출하고 24시간 안에 풀도록 한다. 내가 풀었을 때 2시간 정도 소요가 되기 때문에 24시간은 충분한 시간이다. 경시대회 수준의 어려운 문제와 쉽지만 창의력이 필요한 문제를 출제한다. 적어도 하루를 투자해야 하기 때문에 후보자가 얼마나 진지하게 우리회사에 지원한 것인지 확인할 수도 있다. A~F 등급으로 평가를 하며 B 등급 이상이 되어야 통과된다. 온라인 코딩 테스트 서비스 회사는 많이 있지만 우리 회사에서는 손으로 직접 채점을 한다. 정답 도출 여부는 자동 테스트를 하고 코딩 내용은 직접 눈으로 확인한다. 정답을 도출하지 못해도 창의력과 프로그래밍 방식을 평가하여 높은 등급을 주기도 한다. 온라인 코딩 테스트는 다른 사람이 도와줄 가능성도 일부 있기 때문에 100% 신뢰를 하지는 않고 일정 수준으로 거르는 용도로 사용을 한다.

셋째, 인터뷰 시 진행하는 칠판에 하는 코딩 테스트는 개발의 축소판이다.

개발자 채용에서 가장 중요한 절차다. 온라인 코딩 테스트를 통과한 개발자도 인터뷰 시 꼭 코딩 테스트를 또 진행한다. 문제는 매우 쉽지만 제대로 하기는 만만치 않는 문제를 출제한다. 시간은 10~20분 정도 소요가 되며 이 과정에서 개발자의 두뇌, 논리적인 사고력, 문제 해결 능력을 본다. 알고리즘을 1초 안에 머리 속으로 빈틈없이 시뮬레이션 할 수 있는 사람과 수분에 걸쳐서 숫자를 대입해가면서 검증을 해야 로직이 확인되는 사람은 하늘과 땅 차이다. 칠판에 하는 코딩테스트에서는 이 차이가 적나라하게 드러난다. 물론 후자는 탈락한다는 것은 아니다. 물론 전자의 후보가 월등히 높은 평가를 받는다. 또한 진행하는 과정을 보면서 향후 개발자가 어떻게 개발을 할지 추측할 수 있다. 평소에 개발을 하던 습관이 이 짧은 시간에 다 나온다. 또한 말만 번지르르하고 실제로 코딩을 잘 못하는 고참 개발자들도 여기서 걸러진다. 실제 수백 번의 코딩테스트를 통계 내보면 경력에 따른 큰 차이가 없다. 이런 코딩 테스트를 평가하기 위해서는 매우 뛰어난 개발자가 직접 평가를 해야 한다. 그렇지 않고는 후보자의 논리적인 사고력, 두뇌 회전 속도 등을 판단하기 어렵다.

넷째, 개발언어, 도메인은 별로 중요하게 생각 안 한다.

C, C++, Java, C#, Objective C 등 개발 언어 하나는 완전히 마스터한 개발자를 채용하며 우리가 사용하는 개발 언어를 사용해보지 않은 개발자도 채용을 한다. 다른 개발 언어는 필요하면 익히면 된다. 빨리 익힐 수 있는 잠재력을 가지고 있는지가 더 중요하다. 특이한 경우지만 코딩 경험은 거의 없지만 잠재력이 무한한 사람이라면 개발 언어를 잘 몰라도 채용이 될 수도 있다. 보통 뭘 해봤고 무슨 툴, 라이브러리를 써봤는지 보다는 잠재력 확인에 주력한다. 그래서 가장 자신 있는 개발 언어에 대해서 그 특성을 제대로 이해하고 있는지 질문을 하고 OOP의 개념을 얼마나 잘 이해하고 있는지도 질문을 한다. 우리 회사와 동일한 도메인 지식 경험이 있다면 당연히 좋겠지만 그렇지 않더라도 상관하지 않는다. 우리는 Dental 분야지만 보안, 레저, 게임 등 분야를 가리지 않고 채용을 하며 입사 후 능력과 성과는 도메인과 별로 상관이 없다.

다섯째, 좋은 개발 습관을 가진 개발자를 선호한다.

경력이 많은 개발자일수록 자신의 습관을 바꾸기가 어렵다. 그래서 경력이 많을수록 습관을 주의 깊게 파악한다. 신입이라면 백지와 다름이 없기 때문에 거의 잠재 능력 위주로만 평가를 한다. 소프트웨어 공학에 관심이 많은 것은 긍정적인 요소이며 권위 의식이 있는지 협업과 커뮤니케이션에 능숙한지 공유하는 습관이 있고 문서 작성을 제대로 하는지 확인한다. 꾸준히 새로운 기술을 거부감 없이 익히고 공부하는 것을 즐기는 타입이면 좋다. 인터뷰에서는 보통 좋은 모습만 보여주려고 하기 때문에 습관을 숨길 수 없는 핵심적인 질문을 통해서 진짜 습관을 알아내려고 노력한다. 습관은 바뀌기 어렵기 때문에 인재에 투자할 여력이 된다면 잠재력이 뛰어난 신입개발자를 채용하여 좋은 환경에서 훈련시키고 회사의 문화를 습관화 시키는 것이 좋다.

우수한 개발자가 뛰어난 개발자로 성장하고 뛰어난 성과를 내려면 거기에 걸맞은 환경이 필요하다. 그 중에서 가장 중요한 것이 협업이다. 분석, 설계를 제대로 하고 공유를 하며 개발자의 경력을 보장하고 수평적인 조직 문화를 갖추는 등 개발자가 실력을 발휘하고 성장할 수 있는 환경이 필수적이다. 이건 워낙 광범위한 주제이기 때문에 이 글에서는 논외로 하자.

지금까지 회사 관점에서 어떻게 뛰어난 개발자를 채용하는지 알아봤는데 거꾸로 개발자 관점으로 보자. 필자가 걸어온 길이기도 한다.

개발 언어 하나는 일단 도사급이 되어야 한다. 그리고 다양한 개발 언어를 거부감 없이 수시로 익히고 특히 스크립트 언어 한두개도 능숙해져야 한다. 새로 나온 기술도 관심을 꾸준히 가지고 필요한 만큼 익혀 놓아야 한다. 영어는 끝이 없으므로 꾸준히 공부를 해야 한다. 수학과 논리적인 사고를 꾸준히 단련해야 하며 수시로 글을 쓰고 개발 문서를 써야 한다. 소프트웨어 공학이 몸에 익어야 하며 커뮤니케이션, 협업 역량 향상을 위해 노력하고 겸손함과 인내심을 갖추려고 노력한다. 이렇게 좋은 습관과 뛰어난 지식과 경험을 쌓은 개발자라면 대부분의 SW 회사에서 채용하고 싶을 것이다.

이렇게 준비하며 습관을 만들어가기 어려운 환경에서 일하고 있는 개발자도 매우 많다. 그래도 언제든지 이직의 기회는 발생하는 것이고 현재 환경에서 할 수 있는 최선을 다해서 자신을 만들어가면 좋겠다.

이글은 ZDNet Korea와 기업블로그에 기고한 글입니다.

이 세상에서 가장 먼 길

세상에서 가장 먼 길은 뭘까? 

여기에서 지구 반대 편까지?

김수환 추기경은 “머리에서 가슴까지 내려오는 길”이라고 했다. 여기서 머리는 지식을 말하고 가슴은 마음을 말한다. 즉, 습관을 말한다. 몰라서 못하는 것도 많지만 알아도 행하는데 까지는 긴 시간 동안 수련과 정진이 필요하며 평생 못하기도 한다.

이것이 회사의 기업문화를 바꾸기 어려운 이유 중 한다. 머리로만 알아서 되는 것이 아니라 가슴, 마음이 움직여야 한다. 즉 습관이 되게 해야 한다. 한 개인이 혼자서 습관을 바꾸는 것도 어려운데 많은 사람들이 모여 있는 회사 전체의 습관을 바꾸는 것은 상상을 초월할 정도로 어렵다. 

가장 좋은 것은 좋은 기업문화와 뛰어난 선배들이 많은 회사에 가는 것이다. 혼자서 20년을 정진해도 못 배울 것들을 1,2년 안에 배울 수 있고 그 습관은 평생을 간다. 인위적으로 단기간에 기업문화를 바꾸는 것은 대단한 각오로 추진하지 않으면 어렵다. 

내가 과거에 Survey한 정보에 따르면 10년전만 해도 이슈관리시스템을 쓰는 회사의 비율이 50%가 안되었다. 이제는 80% 이상의 회사가 이슈관리시스템을 쓰고 있는 것으로 추측된다. 하지만 제대로 쓰고 있는 회사의 비율은 10%가 안된다. 제대로 된 방향으로 강력히 드라이브를 해도 3년에서 5년은 걸린다. 하지만 이슈관리시스템을 쓰기만 하는 정도로 제대로 되고 있다고 착각하는 회사가 많다.

예를 들어서 설명하면 스펙은 5년, 빌드는 6개월, 소스코드관리는 1~2년, 공유 협업 문화는 5년 등 기업에서 뭘 하나 바꾸려고 해도 제대로 바꾸는데는 6개월에서 10년이상 걸린다. 이것이 머리에서 가슴으로 내려오는 시간이다. 많은 기업들은 이런 것을 몇개월만에 해치우려고 하고 그렇게 하면 흉내를 내는 것에 불과하고 오히려 부정적인 의식이 팽배해져서 더 손해가 된다.

그럼 가슴으로 내려오기 전까지는 전혀 도움이 안되는가? 그렇지는 않다. 분야에 따라서 다르지만 조금씩 좋아지고 임계점을 넘으면 생산성이 확 올라간다. 하지만 처음에는 생산성이 더 떨어진다. 임계점에 이르는데 짧게는 6월부터 5년이 걸릴 수 있다. Jira나 Redmine 깔았다고 Subversion이나 Git를 쓰고 CI 툴을 이용한다고 생산성이 올라갈 것이라는 생각은 버리자. 골프채 좋은 것 쓴다고 골프를 잘 치는 것이 아니다. 좋은 도구가 꼭 필요하기는 하지만 골프를 잘 치려면 결국에 올바른 훈련법에 따른 오랜 훈련이 필요한 것이다. 

회사가 크면 그만큼 변화가 느리다. 변화를 거부하는 직원이 많으면 실패할 확률이 높다. 

두뇌는 변화를 거부한다. 두뇌는 변화를 위기로 인식하기 때문에 변화를 시도하면 두뇌는 자꾸 원래대로 돌아가라고 명령한다. 작심삼일이 발생하는 이유다. 내가 의지력이 약한 사람이라서 그런 것이 아니라 두뇌의 잠재의식이 명령을 하기 때문이라고 이해하자. 그래서 변화를 거부하는 직원이 있는 것은 당연하다. 그래서 회사가 변화를 하려면 두뇌가 받아들일 수 있을 만큼씩 변화를 해야 하는데 전략이 필요하다. 

변화에 성공하는 회사는 몇% 안된다. 이는 나쁜 일도 아니다. 모든 회사가 변화에 성공해서 다 뛰어나지면 경쟁이 더 치열해질 것이다. 변화에 실패하는 다른 회사와 다른 사람을 탓하지 마라. 그들은 내가 또 우리 회사가 돋보일 수 있는 결정적인 기여자들이다. 

회사에서도 남들에게 영향을 미칠 수 있는 위치에 있다면 “머리에서 가슴까지의 거리”를 생각하자. 직원들이 잘 못한다고 나무라거나 스트레스 받지 말고 습관이 될 수 있도록 꾸준히 가이드를 해야 한다. 6개월에서 10년을 기다릴 각오를 해야 한다.

개발자 입장에서 가장 좋은 자세는 회사나 동료는 생각하지 말고 혼자서 배우고, 바뀌고, 정진하는 것이다. 회사를 바꾸려고 스트레스 받지 말고 스스로 정진하여 좋은 개발자가 되는 것이 좋다.

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

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