2014년 4월 24일 목요일

똑똑한 개발자를 찾기 위한 인터뷰 전략

나는 오랫동안 많은 개발자 인터뷰에 참석했다. 여러 소프트웨어 회사에서 개발자 인터뷰를 어떻게 진행하는지 들을 수 있는 기회가 있었고 회사의 관계자 대신 면접관으로서 기술 인터뷰를 진행한 경험도 많다. 그래서 소프트웨어 업계에서 개발자 인터뷰를 어떻게 하고 있는지 알 수 있는 기회가 있었다. 

우리나라에서 개발자 인터뷰를 어떻게 진행하는지 보면 해당회사와 직접적으로 관련된 경력을 집중적으로물어본다. 구체적으로 무슨 프로젝트를 어떻게 진행했느냐? 무슨 기술을 다뤄 봤느냐? 이런걸 아느냐? 우연히 면접관이 아는 지식과 유사한 경험을 한 개발자는 재수좋게 시원하게 답변을 할 수있다. 또한 개발자는 경력에 대해서는 자신이 한 것이나 동료가 한 것이나 구분하지 않고 과장되게 설명하곤 한다. 

개발자의 역량보다 동일하거나 유사한 분야의 경험을 더 중시하여 개발자를 채용하는 것은 초단기적으로는회사에 급한 불을 끄는데는 도움이 되지만 중장기적으로는 좋은 전략이 아니다. 이는 마치 부품이 고장나서똑같거나 호환되는 부품을 갈아 끼우겠다는 전략과 별반 다를 바가 없다. 

이렇게 동일 경험 개발자를 선호하다보니 경쟁사 개발자를 데려오기도 하고 동종업계 이직금지 서약을 더욱 중요시 하게 되고 논란도 많다.이러다 보니 여러 분야에 손을 대고 있는 대기업은 어느 중소기업에서 개발자가 오더라도 동일 분야라고 주장을 하면 송사에 휘말릴 우려가 있고 개발자의 이직 자유권을 제한하기도 한다. 동일 분야 개발자를 특히 선호하는 이유는 회사의 개발 문화가 낙후되어 있기 때문이다. 

공유가 안되고 협업이 힘들어서 어느 개발자가 오더라도 능력을 발휘하는데 오래 걸린다. 이런 이유로 동일 경험 개발자 위주로 채용하는 현상은 개발자에게 이직의 범위를 축소시키고 기회를 박탈하게 된다. 소프트웨어 개발자는 자신이 일해왔던 분야 뿐만 아니라 거의 모든 분야에서 일할수 있다. 또 그렇게 일해야한다. 

물론 개발자 스스로가 다른 분야에 거부감이 있는 경우도 있지만 이 또한 환경이 그렇게 만든 측면이 크다. 문제는 회사가 문화적으로 프로세스적으로 준비가 되어 있는가이다. 여러 분야의 개발자가 섞이는 것은 개발자에게 기회의 확대외에도 다양한 경험이 창의적인 아이디어와 혁신에 도움이되어 소프트웨어 산업 전반적으로 꼭 필요하다. 

단기적인 부품교체를 하겠다는 생각이 아니라면 개발자를 채용할때 가장 중요한 것은 회사의 미래 개발에필요한 똑똑한 개발자를 뽑는 것이다. 고급 개발자에게 필요한 것은 3가지가있다. 첫째, 소프트웨어 이론 지식이다. 둘째, 공학적인 경험과 개발 문화적인 소양이다. 고참 개발자에게는 중요한 요소다. 셋째, 가장 중요한 논리적인 두뇌와 수학적인 능력, 그리고창의력이다. 

신입 개발자를 채용하는 경우라면 이중에서 세번째만 집중적으로 봐도 된다. 세번째를 확인할 수 있는 방법은 문제해결(Problem solving)능력을 확인할 수 있는 창의적인 질문과 코딩 테스트(Coding Test)다. 이 두가지로 개발자가 얼마나 논리적이고 수학적인 사고를 하는지, 또 창의적인지 확인할 수 있다. 

동일 분야 경험이 전혀 없더라도 회사가 문화적으로 프로세스적으로 준비가 되어 있다면 1, 2개월후에는 동일 경력만 있는 개발자보다 우수한 능력을 보여줄 수 있고 그 성과의 차이는 시간이 흐를수록 점점 벌어지게된다. 이중에서 코딩 테스트에 대해 좀 더 알아보자. 코딩테스트를 하는 회사가 과거보다 많이 늘었다. 하지만 코딩 테스트의 방향을 못잡고 엉뚱하게 진행하는 회사도 있고 코딩 테스트에 거부감을 가지고 있는 개발자들도 있다. 

사실 코딩 테스트를 한다는 것은 개발자에게 긍정적인 신호일 가능성이 더 높다. 개발자의 역량을 제대로 평가할 줄 알고 그 만큼의 대우가 있을 가능성이 더 높다. 가끔 소프트웨어 회사의 코딩 테스트를 보면 나도 통과하기 힘든 것 같은 문제들이 나오기도 한다. 동일분야의 상세한 경험이 없으면 풀 수 없는 문제가 대표적이다. 동일 분야 동일 경력 개발자를 채용하기 위한 방법으로 코딩 테스트를 사용할 뿐이다. 

이런 회사는 단기적으로 부품을 교체하겠다는 생각이라면 상관이 없지만 그렇지 않고 좋은 개발자를 뽑기 위한 목적이라면 잘못된 방법을 사용하고 있는 것이다. 역사를 배운다고 연도나 줄줄이 외워야 하는 것처럼 이런 것을 물어보는 쪽지 시험과 같은 코딩 테스트는 뛰어난 개발자를 놓치기 쉬운, 좋지 않은 방법이다. 

그런데 지금도 이런 문제들을 갖고 개발자를 채용하고 있는 회사들이 꽤 있다. 이런 현상이 벌어지는 이유는 회사에서 고참 개발자들에게 코딩테스트 준비를 하라고 하면 그 동안 암기식 교육에 익숙해서 이런 문제 밖에 못 내고 인사 담당자는 이를 평가할 능력이 없기 때문이다. 코딩 테스트시 집중적으로 봐야하는 것은 개발자의 논리적인 사고 능력과 문제해결 능력, 창의성이다. 

그러기 위해서 특정분야의 지식을 필요로 하는 문제는 삼가는 것이 좋다. 코딩 테스트에는 대략 5가지 방법이 있다. 아래 방법 중 한 두가지를 선택해서 코딩테스트를 진행한다. 

첫째, 온라인 사이트 코딩 테스트다. 지원자가 너무 많은 경우 정말 자격이 안되는 개발자를 거르기 위한 용도로 사용한다. 인터넷을 검색해 보면 이런 서비스를 제공하는 회사가 많이 있다. 지원한 회사에서 지정한사이트에 등록을 하고 자신이 선호하는 개발언어로 주어진 시간동안 코딩을 하면 된다. 

둘째, 24시간에서 며칠이 소요되는 프로젝트 테스트다. 좀더 가능성이 있는 개발자에게는 첫 번째 온라인 사이트를 이용한 코딩 테스트보다 몇 시간 또는 하루 이틀 걸릴 간단한 코딩 숙제를 주고 1~3일안에 온라인으로 제출을 하게 한다. 

이때는 개발자의 논리적인 사고와 창의력도 보고 코딩 스타일도 보게 된다. C사의 경우 이 코딩 테스트에서 95% 이상의 개발자가 탈락을 한다고 한다. 개발자들이 정말로 가고 싶어하는 유명한 회사가 아니고 이름이 잘 알려지지 않은 중소 소프트웨어 회사라 면이 방법을 사용하기 힘들다. 개발자들이 그냥 귀찮아서 포기할 가능성이 높다. 

셋째, 전화 코딩 테스트다. 전화를 이용해서 코딩 테스트를 하는 방법인데 위 방법보다 좀더 많은 것을 볼 수가 있다. 전화를 통해서 지원자와 대화를 하면서 화면을 공유할 수 있는 방법을 통해서 직접 코딩하는 것을 보면서 코딩 테스트를 진행한다. 

구글 드라이브 문서를 통해서 공유하기도 하고 이와 비슷한 공유가 가능한 온라인 편집기를 사용하기도 한다. 또는 스카이프 등 화면을 공유하는 소프트웨어를 이용하기도 한다. 이런 협업 도구를 통해서 코딩하는것을 직접보면서 면접관은 이런 저런 질문을 하고 개발자는 코딩하는 것을 설명하면서 진행한다. 토론식으로 진행도 가능함으로써 코딩 결과만 보는 것보다는 훨씬 많은 것을 파악할 수가 있다. 지역적으로먼거리에 있는 개발자를 검증하기 위해서 사용할 수 있다. 

넷째, 1~3시간 온사이트 테스트다. 지금까지의 방법은 다른 사람의 도움을 일부 받을 수가 있다. 하지만 온사이트 테스트는 확실히 본인만의 실력으로만 진행해야 한다. 이 방법은 인터뷰전에 혼자서 노트북에 직접코딩을 하는 것이다. 1~3시간안에 풀 수 있는 문제를 주고 컴파일 및 실행이 되도록 직접 코딩을 하는 것이다. 인터뷰시에는 코딩한 결과를 설명할 수 있어야 한다. 이런 테스트는 면접자에게 많은 시간과 부담을 주기 때문에 이에 합당하는 면접 비용을 지불하는 것이 좋다. 

다섯째, 면접관과 함께 하는 칠판 코딩 테스트다. 내가 가장 선호하는 방법은 짧은 시간에 진행하는 칠판 코딩 테스트다. 가장 많은 것을 볼 수 있다. 칠판이라는 특성 때문에 문법은 보지 않는다. Pseudo Code(실행되지 않고 로직만 표현한 소스코드)로 작성을 해도 된다. 코딩결과만 보는 것이 아니라 어떻게 진행하는지더 눈여겨 본다. 

개발자가 문제를 정확하게 이해했는지 면접관에게 물어보는 자세도 중요하게 본다. 일부러 질문을 유도하기 위해서 문제에 질문이 필요한 함정을 넣기도 한다. 이를 질문도 없이 일사천리로 코딩을 해나가면 의심을 해봐야 한다. 

코딩을 하면서 중간 중간에 적절하게 설명하는 자세도 아주 중요하다. 그런데 우리나라 개발자들은 설명없이 그냥 써내려가는 경우가 많다. 평상시에 개발하는 방식이 그대로 반영된다. 이때 면접관이 지적하는 것에 대해서 어떻게 대응하는지도 중요하다. 코딩을 다하고 나면 개선점을 가지고 간단한 토론을 하는 것이 좋다. 이렇게 면접관과 상호작용이 잘 되는 개발자는 나중에 개발시에도 공유 및 커뮤니케이션이 잘될 수 있다. 

이렇게 10~30분동안 진행하는 코딩 테스트는 평소 개발의 축소판이고 창의력, 문제 해결 능력, 커뮤니케이션 능력까지도 볼 수 있는 좋은 수단이다. 실제 인터뷰에서 경력은 화려한데 칠판 코딩 테스트에서 탈락하는 경우가 부지기수다. 기본적인 논리적 사고와 수학적인 능력도 없이 본인이 설명하는 수 많은 프로젝트를 수행했고 높은 연봉을 받은 고참 개발자들을 보면 안타깝기 그지 없다. 

누가 설계를 해야하고 누가 프로그래밍을 해야하는지 구체적인 구분도 없이 고참이고 경력이 많다는 이유로 프로젝트의 설계를 주도하고 망쳐와서 정작 경력이 적더라도 똑똑하고 뛰어난 개발자들이 성장의 기회를 놓치게 된다. 개발자에게 진짜로 필요한것이 무엇인지 생각해보자. 

회사에서 진짜 뛰어난 개발자를 구분할 수 있고 그에합당한 대우를 할 수 있을때 우리 주변에 연봉 수억의 개발자들이 바글바글하게 될 것이다. 그래야 뛰어난두뇌를 가진 사람에게 소프트웨어 개발자는 충분히 매력적인 직업이 될 수 있을 것이다. 그쯤되면 소프트웨어 생태계가 더욱 좋아지고 개발자에게는 롤모델도 생기고 개발자에 대한 전반적인 인식과 대우도 더 좋아질 것으로 확신한다.

2014년 4월 6일 일요일

美 SW 힘은 평등한 호칭 문화에서 생겼다

필자는 지금까지 소프트웨어 조직에는 수평적이고 자율적인 문화가 필요하다고 했다. 하지만 수직적이고 상명하복 식 조직문화를 없애고 평등한 토론에서 오는 창의적이고 효율적인 개발문화를 만들고 싶어도 넘기 힘든 큰 장애물이 있다. 

바로 '직급'을 부르는 호칭이다. 

한국은 아주 옛날부터 이름 대신 직급을 부르는 것이 전통이다. 부장님, 과장님이라고 불러야지 이름을 부르는 행위는 아주 무례한 것이고 조직문화에서는 용납이 안 되는 행위다. 호칭은 오래 이어져 온 전통이며 쉽게 바꾸지 못하는 고착된 문화다. 

직급을 부르는 호칭은 조직에서 상하관계를 명확하게 하고 상명하복 문화에서 쉽게 벗어나지 못하게 하는 강력한 수단이다. 차장과 부장은 권위의 수준이 다르고 차장에서 부장으로 진급했는데 이를 모르고 차장이라고 부르면 기분 나빠하는 사람도 있고 부르는 사람도 민망해진다. 가끔은 오랜만에 만난 옛날 동료의 직급을 몰라서 뭐라고 불러야 할지 애매한 경우도 많다. 

이런 수직적인 조직문화에서는 '대리'와 '부장'이 어떻게 똑같은 관계에서 평등하게 토론을 할 수 있겠는가? 호칭은 사람에 대한 인식과 사고를 지배하고 알게 모르게 행동과 말하는 것을 통제한다. 

부장의 얘기가 틀렸어도 눈치를 보며 쉽게 지적하기 어렵다. 설령 자신의 생각이 맞는다고 확신해도 위계질서를 무시할 수 없고 괜히 얘기했다가 나중에 불이익을 당하지 않을까 걱정하여 자연스럽게 자기 검열을 하게 된다. 그러다 보니 좋은 아이디어가 있어도 괜히 얘기했다가 일만 많아지고 면박이나 받지 않을까 걱정해서 가만히 있게 된다. 그래서 '가만히 있으면 중간이라도 간다'라는 생각이 지배를 하게 된다. 

복잡도가 소프트웨어보다 낮은 산업들, 특히 전통적인 굴뚝산업에서는 상명하복과 위계질서가 더 효율적인 경우도 많다. 하지만 인류 역사상 가장 복잡한 지식산업이라는 소프트웨어 산업에서는 상명하복으로는 효율적인 개발을 하기 어렵다. 자유로운 사고와 창의력과 혁신이 없이는 살아남기 힘든 소프트웨어 산업에서는 무엇보다도 평등한 토론 문화가 필수적이다. 

전통적으로 직급보다 이름을 부르는 미국이 소프트웨어 강국이 되는데 이런 호칭 문화가 일조를 했다고 생각한다. 신입사원이 사장의 이름을 부를 수 있고 자유롭게 의견을 얘기할 수 있는 토론 문화는 어릴 때부터 훈련이 되어 있다. 물론 모든 회사가 다 그렇다는 것은 아니고 사회 전반적인 문화가 그렇다는 것이다. 

필자는 수평조직 문화를 정착하기 위해서 호칭 문화를 획기적으로 바꾼 몇몇 우리나라 회사를 알고 있다. 

A사는 모든 직원이 서로 '영어이름'을 부른다. 서로 존칭은 하지만 극존칭은 사용하지 않는다. 말단 사원이 최고 경영자인 사장에게 그냥 '빌(Bill)' 또는 '스티브(steve)' 이렇게 부른다. 

문서나 회의록을 작성할 때도 "Bill이 이렇게 말했다"라고 작성을 한다.

수직적인 조직 문화에서 문서에 사장님을 언급할 때 이름을 그냥 쓰기가 몹시 꺼려진다. '사장님'이라고 써야 할지, '홍길동 사장님'이라고 써야 할지 고민이 된다. 이렇게 주제에 집중하지 못하고 신경을 쓰는 것 자체가 호칭에 지배를 받고 영향을 받고 있다는 증거다. 많은 기업은 문서나 대화에서 최고 경영자의 호칭을 CM 등 직급의 약자나 이름의 이니셜을 쓰기도 한다. 여기에는 최고위층 이름은 직접 언급할 수 없다는 금기도 작용하기도 한다. 조선시대에는 왕의 이름에 들어간 한자는 민간에서는 절대로 쓸 수가 없다. 이만큼 우리는 옛날부터 호칭에 민감하다. 

직원들끼리 영어 이름을 부르는 A사는 조직문화가 사뭇 다르다. 호칭 자체가 모든 것을 평등하게 바꾸는 것은 아니지만 평등한 조직문화를 만드는데 일조한다. 

회의나 토론 시간에 위계질서는 없고 자유롭게 발언하며 면박을 주지 않는다. 사장이나 말단 개발자나 똑같은 위치에서 의견을 얘기한다. 제3자가 이 광경을 보고 있으면 누가 사원이고 과장, 부장인지 알 수가 없다. 각자 자신의 전문성과 경험에 기반 하에 자유롭게 의견을 얘기한다. 이런 환경에서 창의적이고 혁신적인 아이디어가 나온다. 

빠른 의사 결정도 장점이다. 회사가 직급에 의해서 돌아가는 것이 아니라 각자의 역할이 있을 뿐이다. 팀장이 있기는 하지만 모든 사람들이 다 평등하다. 자신이 맡은 일이 있을 뿐이다. 결재도 한 두 단계로 끝난다. 길어야 팀장, 사장, 이렇게 두 단계다. 결재판을 들고 돌아다니면서 결재를 받는 경우도 일부 있지만 많은 경우 구두나 이메일로 승인이 떨어진다. 사전에 시스템이나 이메일로 내용이 충분히 공유가 되어 있어서 최종 결정은 신속하다. 

이런 환경에서는 위에서 시키는 일만 하는 수동적인 직원은 매우 적고 능동적이고 자율적인 문화가 퍼져나간다. 나의 위에 줄줄이 상사들이 있어서 시키는 일을 잘하고 눈치를 봐야 하는 상황이 아니고 자신이 알아서 일해야 하는 분위기가 자리를 잡는다. 성과가 안 좋은 것은 자신의 책임이다. 

물론 호칭만 바꾼다고 이런 문화가 저절로 정착되는 것은 아니다. 경영진의 의지가 가장 중요하다. 호칭을 바꾸려는 목적이 무엇인가? 수평적인 문화를 만들기 위한 것이다. 영어이름을 사용하는 호칭 문화는 수평적인 문화를 만들기 위한 강력한 수단 중 하나다. 

하지만 호칭만 바꾸고 권위의식이 여전하다면 별 효과가 없을 것이다. 권위 의식을 타파하고 상명하복 전통을 없애고 자율적이고 수평적인 문화를 만들기 위해서 다각적으로 노력해야 한다. 호칭문화는 그 시작이 될 수 있다.

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