2016년 9월 20일 화요일

왜 이우소프트에는 개발팀장이 필요없는가?

내가 CEO로 있는 이우소프트에는 우리나라에서 흔히 얘기하는 개발팀장이 없다. 정확히 말하면 개발팀장이라는 포지션이 있기는 한데 일반적인 개발팀장은 아니다. 관리를 전혀 하지 않는 개발팀장이다. 평가 등 몇몇 행정적인 역할이 필요하기 때문에 개발팀장 포지션이 있기는 하다. 

회사마다 개발팀장의 역할이 다르고 뭐가 옳고 뭐가 그르다라고 할 수는 없다. 하지만 대부분의 소프트웨어 회사에서 조금 또는 많은 시간을 관리에 할애를 해야 하는 개발팀장과 다르게 이우소프트에서는 개발팀장이 관리를 전혀 하지 않는다. 이우소프트에서는 이렇게 하는 것이 가장 효율적이라고 생각을 하기 때문에 개발자에게는 지위고하를 막론하고 관리를 전혀 시키지 않는다. 

개발팀장이 관리를 전혀 하지 않는 다는 것은 크게 두 가지 의미가 있다.

첫째, 개발자에게는 팀장이든, 누구든 관리를 시키지 않음으로써 개발에 전념하도록 하고 개발자로서 꾸준히 성장하여 60세가 되어도 개발자로서 경력을 유지할 수 있도록 한다.

둘째, 관리가 필요 없는 조직 문화에서는 개발이 더 효율적으로 진행된다. 

첫 번째, 개발자 경력에 대한 얘기를 먼저 해보자. 

관리형이냐 실무형이냐에 따라서 조금씩 다르기는 하지만 소프트웨어 개발이 아니라도 대부분의 팀장들은 관리도 하고 실무도 하게 된다. 많은 회사에서 개발팀장은 개발도 하고 관리도 한다. 대부분은 경력이 많을수록 관리를 더 많이 하게 된다. 관리 일이 많아질수록 개발에 힘을 쏟을 시간은 부족하게 되고 점점 개발자로서 역량을 유지하기 힘들게 된다. 그렇게 오랜 시간 관리에 시간을 빼앗기면 마음만 개발자이고 실제 개발에는 별로 도움이 안 되는 간섭 잘하는 관리자가 되기도 한다.

그렇게 어정쩡한 관리형 개발팀장들은 전문적인 관리자와는 다르다. 자신이 기술과 개발에 대해서 잘 알기 때문에 수시로 기술에 관여를 하게 된다. 그러면서 권위를 내세워 잘못된 기술적인 결정을 하기도 한다. 그러면서 전문적인 관리는 잘 하지 못하기 때문에 개발자들은 오히려 힘겨워하곤 한다. 

다른 분야보다 소프트웨어 개발 분야에서는 유독 개발자로서 경력을 유지하기 어려운 이유는 소프트웨어 기술이 너무 빨리 바뀌고 새로 배워야 할 기술이 너무나 많기 때문이다. 또한 그 속도는 점점 빨라지고 있다. 관리도 하고 보고서 쓰는 등으로 시간을 보내서는 그 속도를 따라 갈 수가 없다. 

우리 회사에서는 개발팀장이라고 해서 행정적인 권위는 거의 없고 기술 카리스마 밖에 없다. 그렇게 기술로 경쟁을 해야 하기 때문에 끊임없이 기술을 익혀야 하고, 그렇기 때문에 60세가 넘어도 개발자로서 일할 수 있다. 또한 연공서열이 의미가 없기 때문에 나이 어린 PM과도 문제 없이 일해야 한다. 구글의 경우 72세의 개발자도 현역으로 일을 하고 있다고 하는데 개발자가 개발에 전념을 할 때 가능한 일이다.

두 번째, 관리가 거의 필요 없는 조직 문화가 왜 더 효율적인지 얘기해보자.

관리를 많이 필요로 하는 조직은 개발팀장이 관리 때문에 할 일이 많아지고 개발실장, 본부장 등 회사마다 다르지만 여러 단계의 많은 관리자들이 필요하게 된다. 그럼 관리를 잘 하면 개발이 더 효율적으로 진행이 될까? 현실은 그렇지 않다. 

소프트웨어 개발은 창의적인 지식노동이기 때문에 벽돌 쌓듯이 할 일을 딱 정해서 시간 단위로 관리를 하는 것이 그렇게 효율적이지 못하다. 해야 할 일의 대부분은 개발자들이 스스로 찾아내는데, 관리가 철저한 조직일수록 꼭 해야 할 일들이 숨겨지게 된다.

개발자들은 꽉 짜여진 관리틀 속에서 꼭 해야 할 일을 찾아내더라도 적극적으로 수면 위로 드러내지 못한다. 작은 리팩토링이 필요한 모듈을 찾아내거나 개선 사항이 있어도 팀장이나 관리자에게 얘기를 했다가는 자신이 해야 할 일만 늘어나는 결과를 초래하여 야근만 증가하기 때문에 적극적으로 얘기를 하지 않곤 한다. 흔히 누군가 아이디어를 얘기하거나 개선 사항을 말하면 의견 제시자에게 일을 시키는 것이 관행인 회사에서는 쉽게 말을 못 꺼낸다. 결국 시키는 일만 최소로 하는 소극적인 자세를 보이게 된다. 특히나 야근을 밥 먹듯이 하는 회사에서는 더욱더 스스로 일을 찾아서 겉으로 드러내기가 쉽지 않다. 문제는 꼭꼭 숨어 있다가 지뢰나 시한폭탄이 된다.

우리 회사에서는 어떤 할 일을 찾아내거나 아이디어, 개선 사항이 있으면 그 즉시, 지체하지 않고 이슈관리시스템에 등록하도록 되어 있고, 많은 직원들이 습관처럼 그렇게 하고 있다. 이렇게 시스템에 올리면 등록자는 시스템에 올리는 것으로서 첫 번째 역할을 끝낸 것이다. 이 일이 무작정 등록자에게 할당이 되거나 당장 처리를 하게 되는 일은 없다.

이렇게 등록된 일은 곧 여러 사람이 보게 된다. 그래서 다른 사람이 스스로 일을 가져가서 일을 하기도 하고, 기술적인 이슈라면 기술위원회에서 처리를 하기도 하고, 버그나 새로운 기능은 PM이 관리를 하기도 한다. 또한, 당장 처리를 하는 일도 가끔 있지만 대부분은 우선순위에 따라서 나중에 처리를 한다. 어떤 이슈는 몇 년 후에 처리를 하기도 한다.

이렇게 누구나 해야 할 일을 찾아서 시스템에 자유롭게 등록하고 스스로 관심이 있는 일을 가져가 처리를 하게 되면 관리가 최소화 되고 꼭 해야 할 일의 대부분의 일들이 숨겨지지 않고 표면 위로 드러나며 빠짐없이 관리가 된다. 

물론 개발자가 프로젝트에 투입되면 명확한 임무가 주어진다. 프로젝트 안에서도 미시적으로는 위와 같이 스스로 진행하는 일들이 매우 많기는 하다.  

이렇게 일하기 때문에 모든 업무는 시스템에 자동으로 기록이 되며 그 과정이 추적되고 공유되기 때문에 대부분은 사전에 허락을 받지 않고 스스로 판단 하에 진행을 한다. 그래서 별도의 일일보고, 주간보고를 작성할 필요도 없다.

간단한 일은 이슈관리시스템에 공유를 하고 진행하지만 일주일 이상 걸리는 일들은 Engineering One-Pager라는 문서를 작성하곤 한다. One-Pager는 아주 간단한 스펙 문서로서 1,2페이지 또는 조금 더 작성하기도 한다. 작성된 One-Pager는 관련된 사람들이 모두 리뷰를 하여 필요성과 적절성을 검토한다. One-Pager를 작성한 사람이 그 일을 하기도 하고 다른 사람에게 그 일을 시키기도 한다. 어쩔 때는 Holding을 해 놨다가 나중에 진행하기도 한다. 물론 Drop을 하기도 한다.

One-Pager를 쓰는 이유는 공유, 기술검증, 중복 방지, 학습, 타당성 검토 등 여러 가지 목적이 있다. One-Pager를 숙제처럼 부담스러워하는 개발자들도 일부 있다. 2,3일에서 2,3주 걸리는 일은 자연스럽게 무엇을 할지를 적고 검토를 받는 것을 자연스럽게 생각해야 한다. 우리 회사에서는 그 형식이 One-Pager일 뿐이고, 형식은 회사마다 다를 수 있다.

이렇게 스스로 일하는 문화를 통해서 적극적인 사람은 얼마든지 자신의 생각을 표출하고 기회를 얻을 수 있고, 수동적인 사람은 매일 시키는 일만 하기도 한다. 물론 이우소프트에서는 적극적인 표현을 권장하고 있다. 이러다 보니 개발자의 커뮤니케이션 능력을 매우 중요한 역량으로 본다.

개발자 채용 시 코딩테스트를 할 때도 코딩만 평가하지 않고 코드를 적어가는 과정에서 얼마나 적절한 커뮤니케이션을 하는지 본다. 물론 문제마다 커뮤니케이션 내용이 다르기 때문에 정답은 없다. 문제의 의도를 좀더 정확하게 파악하고 불확실한 요소를 제거해 나가는 대화 접근법은 10분짜리 코딩 테스트 시나 실전 개발 시나 비슷하게 나타나기 때문이다.

가장 골치 아픈 개발자는 의문이 있거나 문제가 있는데도 공유, 리뷰, 의논 등을 하지 않고 혼자가 다 처리해버리는 경우다. 이렇게 대화를 싫어하는 개발자는 문제를 일으키기 쉬우며 성장하기도 어렵다.

실제 여러 개발자를 대상으로 커뮤니케이션 역량을 향상시키기 위해서 리뷰 제도를 강화하고 업무 중 커뮤니케이션 코칭을 계속 해보면 대부분의 개발자가 커뮤니케이션 역량이 향상된다. 가장 중요한 것은 개발자 본인이 마음을 열고 회사의 문화를 받아들이는 것이다. 또한 이미 커뮤니케이션 역량이 뛰어나거나 잠재력이 높은 개발자를 채용하는 것도 중요하다.


이러한 문화 속에서 이우소프트의 개발팀장은 다른 개발자와 똑같이 개발에만 집중한다. 물론 개발자가 개발자로서 경력을 꾸준히 유지하고 싶을 경우에 그렇다는 얘기다. 그렇지 않고 개발자 경력을 바탕으로 PM, 마케터, 관리자 등 다른 경력으로 전환을 하고자 하는 경우에는 다른 길이 기다리고 있다.

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



2016년 8월 30일 화요일

이우소프트에서 경력직 공채를 실시합니다.

9/7까지 이우소프트의 그룹사 차원에서 공동으로 경력직 공채를 진행중입니다

많은 지원 부탁합니다. 

이우소프트에서는 SW개발, AI개발, AI마케팅, SW제품기획, Project Management 분야에서 직원을 채용합니다.



하반기 공채 안내

  • 지원기간 : 2016년 8월 25일(목) ~ 2016년 9월 7일(수)
  • 지원구분 : 경력
  • 전형단계 : 서류 전형 > 인성 검사 > 실무/임원 면접 > 최종 면접
  • 전형일정 : 서류합격자에 한해 인성 검사 진행 (*추후 상세 면접일정은 인성 검사 합격자에 한해 개별 공지 예정)
  • 지원방법 : recruit.vatech.co.kr 에서 온라인 지원


URL : https://recruit.vatech.co.kr/index.php?mid=recruit_notice

2016년 8월 17일 수요일

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

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

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

필자는 대한민국의 여러 벤처기업, 대기업, 중소기업, 실리콘밸리의 회사들에 대한 기업 문화를 두루 경험하고 봐왔기 때문에 나름 노하우가 생겨서 이를 공유하고자 하는 것이다. 물론 독자들이 처한 환경과 완전히 배치되는 의견이 될 수도 있음을 밝혀둔다. 인재는 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기업블로그에 기고한 글입니다.

2016년 8월 5일 금요일

이 세상에서 가장 먼 길

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

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

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

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

가장 좋은 것은 좋은 기업문화와 뛰어난 선배들이 많은 회사에 가는 것이다. 혼자서 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년을 기다릴 각오를 해야 한다.

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

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월 18일 월요일

이우소프트에서 AI 기획자를 채용합니다.

이우소프트에서 AI 솔루션과 제품을 기획할 기획자를 채용합니다.

현재 이우소프트는 이우AI랩에서 AI 전문 개발 인력들이 다양한 AI 솔루션을 개발하고 있습니다.
덴탈용, 산업용 등 여러 분야에 적용 가능한 AI 기술을 연구/개발하고 있습니다.

이에 AI 솔루션과 제품을 기획할 기획자를 채용합니다. AI에 관심이 많고 AI를 이용하여 새로운 솔루션과 제품을 만들어서 세상을 좀더 좋게 바꾸는 꿈을 갖고 계신 분들의 많은 관심 바랍니다.

업무
  • AI 솔루션/제품 기획/마케팅
    • 덴탈/의료 분야 
    • 산업용 분야
    • 보안 분야
    • 기타 분야
  • 신제품 아이디어
  • 학습 데이터 수집, 관리

자격


  • 제품/서비스 기획 능력 보유
  • 비즈니스 영어 회화 능력 보유
  • AI에 대한 기본 지식 보유
    • CNN과 RNN을 구별할 정도
    • Precision과 Recall을 설명할 정도
  • Dental 분야 경험자 우대

회사 경기도 동탄에 위치해 있으며 7월에 서울 교대역 인근에 “R&D 센터”를 Open할 예정이어서 R&D는 분야에 따라서 서울에서 근무가 가능합니다.

지원방법 : 이력서자기소개서를 scarlet.choi@ewoosoft.com 으 보내주세요.

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 실력이라고 하면서 또, 과거와 비슷하게 스스로 열심히 뭔가 개혁을 해보려고 하고 단기간에 성과를 내보려고 한다면 매번 반복되는 현상이 이번에도 반복될 것이다.