2014년 5월 26일 월요일

구글이 원하는 개발자 - 문제 해결 역량




저서 "글로벌 소프트웨어를 말하다"의 24장



2년전 쯤에 구글에 취직한 한국 개발자가 자기가 경험한 면접과정을 기사화 한 적이 있다. 한국하고는 다르니까 신기한 경험이었을지 모르지만 미국 소프트웨어 회사들의 공통된 얘기였다. 만약에 개발자로서 실리콘밸리에 취직하려고 한다면 국내 회사에 취직하는 것과는 다른 준비를 해야 한다. 어쩌면 준비할 것이 없을 지도 모른다. 마지막 순간에 쪽집게 공부로는 준비할 수 없는 것이다. 자신의 모든 진실한 역량이 드러나기 때문이다.



필자가 미국 대학교에서 과목을 들을 때도 마땅히 시험 준비를 위해 특별히 공부할 필요가 없는 경우가 많았다. 마지막에 잠깐 공부하고 운이 좋으면 점수가 좋게 나온다는 것은 진정한 실력도 아니고 그런 식의 시험문제가 나오지도 않는다. 그래서 어떤 시험은 일주일 시간주고 집에서 해오는 경우도 많다. 학생 입장에서는 진이 빠지는 경우이다. 답이 하나가 아니고 생각하는 방법에 따라 문제 자체가 달라지고 학생마다 답도 물론 다르다. 그래서 베낄 수도 없고 비슷하게 흉내 낼 수도 없다.



회사 인터뷰를 보자. 개발자의 경우 하루정도 인터뷰 한다. 한국에서는 여러 명의 면접관이 한 명의 지원자를 앉혀 놓고 여러가지 질문을 하며 동시에 관찰을 한다. 필자는 이런 식으로는 평가를 제대로 할 수 없기 때문에 이런 방식을 좋아하지 않는다. 미국은 일대일로 면접을 진행한다. 지원자로서는 한국에서는 한 시간 정도의 인터뷰만 잘 넘기면 된다. 아주 편하다. 미국은 그게 안된다. 면접관 한 사람 당 40-50분 정도 하루종일 인터뷰를 한다. 그래도 잘 판단이 안되면 다시 부른다. 면접관은 위 아래 개발자들이 골고루 섞여 있다. 대부분 점심도 같이 한다. 점심도 지원자를 판단하기 위한 중요한 부분이다. 성격의 많은 부분을 볼 수 있다. 하지만 개발자를 뽑는 것이기 때문에 역시 핵심은 개발 역량이다. 어차피 미국은 다양한 인종이 살기 때문에 성격이 다 독특할 수 밖에 없기 때문에 진짜 이상한 경우만 아니면 문제가 되지 않는다.



인터뷰의 핵심은 문제 해결 능력이다. 문제를 전개하고 정의하고 협의하고 풀어나가는 능력이다. 필자가 한국에서 개인적으로 인터뷰할 기회가 생기면 "숫자 3개를 정렬" 하는 문제를 낸다. 아무 질문없이 문제를 그대로 풀어오면 빵점이다. 문제 자체를 정의하지도 않은 상태에서 자기 멋대로 풀어온 것이다. 이런 스타일의 개발자는 회사에서 가장 큰 문제아다. 언제 어디서 무슨 짓을 저지를지 모르는 동키호테이다. 지원자가 문제를 미리 알고 있다고 해도 아무 상관 없다. 어차피 일 년 동안 풀어도 못푸는 문제이기 때문이다. 지금까지 이 문제에서 필자의 기준에 합격한 국내 개발자는 거의 없었다. 어차피 국내에서는 실리콘밸리 수준의 문제 해결 능력을 가지고 있기가 어렵기 때문에 기대하지도 않는다. 기준에 모자라더라도 그 중에서 상대적으로 나은 개발자를 뽑을 수 밖에 없다. 이 문제를 풀 때 프로그래밍 언어는 상관하지 않는다. 시험에서 연필로 쓰나 볼펜으로 쓰나 상관하지 않는 것이나 같다. 언어 프로그래밍 능력은 금방 배울 수 있는 것이기 때문이다. 객체지향을 이해하는 것이 중요한 것이지 C++이나 Java 같은 언어를 잘 알아야 하는 것은 아니다.



먼저 국내 개발자들의 예를 보자. 그냥 3개 숫자 정렬하는 소스코드를 막 쓰기 시작한다. 물론 자기가 가장 자신있는 프로그래밍 언어를 사용한다. 나를 어떻게 생각하는 지 모르겠는데 내가 그걸 몰라서 풀어보라고 할 리는 없다. 즉 물어보는 사람의 의도를 파악해 보려는 생각은 하지도 않고 늘 정해진 문제를 풀 듯이 그냥 알고리듬 생각해 내기에 바쁘다. 숫자 3개 정렬하는 알고리듬이 복잡해야 얼마나 복잡하겠는가? 삼척동자도 다 아는 것이다. 바로 국내 교육의 병폐가 여기서 확연히 드러나는 것이다. 필자는 국내 회사에 가서 개발자들과 일을 할 때도 이런 문제가 보통 심각한 문제가 아니라는 것을 느낀다.

문제를 해결하기 위해 필요한 전제조건이 문제를 찾아내고 정확히 정의하는 능력이다. 이 능력은 학원가서 배울 수 있는 것도 아니고 주입식 위주의 교육 환경에서 쌓여온 무의식의 축적이기 때문에 장기적인 교육환경의 변화를 필요로 한다. 하여튼 국내 교육의 결과로 그런 능력은 없다 치고 알고리듬이라도 제대로 쓰면 가장 기본적인 논리력은 인정해 준다. 그런데 이것도 헤매지 않고 적어내는 사람도 많지 않다.

필자가 풀라고 한 "3개 숫자의 정렬"이란 문장으로서 문제가 확실히 정의되었다고 보는가? 아직도 그렇게 생각한다면 국내 소프트웨어 업계가 성숙하지 않았다는 구체적인 증거이다. 그럼 실리콘밸리의 회사의 인터뷰에서 벌어지는 대화를 시뮬레이션 해보자.

면접관: 숫자 3개 정렬하는 문제를 풀어보세요
지원자: 숫자 3개만 정렬할 것인가요? 4개, 5개, 혹은 많은 숫자를 정렬할 필요가 있나요?
면접관: 나중에는 숫자가 늘어날 겁니다.
지원자: 오름차 순, 내림차 순을 선택할 필요가 있나요?
면접관: 예
지원자: 숫자가 정수인가요, 실수인가요?
면점관: 두 가지를 다 사용합니다.
지원자: 정수일 경우 최대와 최소범위가 무엇인지요?
면접관: 최대가 큽니다. 30자리 숫자 입니다. 최고는 마이너스로 10자리 정도 됩니다.
지원자: 실수일 경우는 어떤가요?
면접관: 소수점 이하 20자리 까지 정확해야 합니다.
지원자: 이 프로그램이 독립적인 프로그램인가요? Function으로 제공해야 합니까?
면접자: 둘 다 필요합니다.
지원자: 어떤 응용프로그램이 사용하려고 하는 건가요?
면접관: 우주 관제 센터에서 사용할 것입니다.
지원자: 이 프로그램을 사용할 운영환경이 무엇입니까?
면접자: IBM 메인프레임 입니다.
지원자: 이 프로그램을 얼마나 자주 호출합니까?
면접자: 1초에 1억번 정도 호출됩니다.
지원자: 속도 때문에 소숫점 20자리를 계산하기는 불가능 할 것 같습니다.
면접자: 메모리는 충분히 늘릴 수 있으니까 어떤 알고리듬을 써야 속도가 가장 빠를까요?
지원자: 일단은 O(N log N) 인 알고리듬이 빠르겠지만 정렬해야 하는 숫자가 천 개, 만 개가 될 것이 아니라면 별 차이는 없으니까 중요한 것은 Function을 부를 때 숫자가 30자리나 되니까 parameter로 넘기지 말고 pointer로 넘기거나 Global 변수로 접근 하는 것이 어떨까요?
면접관: 그렇게 하면 객체지형적인 측면에서 어떤 문제가 있을까요?
.............



지금까지 보았지만 이 문제 정의는 아직 끝나려면 멀었다. 이런 대화가 1시간을 진행된다고 생각해 보자. 지원자가 가지고 있는 모든 지식이 나타난다. 국내 개발자들에게 풀라고 하면 그냥 답 적어내겠다고 하는 것과는 워낙 접근 방법이 다르니 비교할 수 조차 없다. 이런 인터뷰를 여러 명하고 하루 종일 하면 실력이 다 드러난다. 다른 면접관하고 얘기를 하면 또 완전히 다른 방향으로 간다. 그래서 문제를 안다고 해도 미리 공부해 갈 수도 없다. 사실은 대화 중에 면접관도 많은 것을 배운다. 지원자에게 많이 배울수록 감동받고 "저 사람은 꼭 고용해야 합니다" 라는 평가서를 적을 것이다. 이런 상호존중이 바로 회사에서 가장 중요한 것이다. 그룹으로 협업하면서 문제를 해결하는 능력인 것이다. 실리콘밸리의 개발자들은 이런 식의 사고방식이 익숙해져 있기 때문에 추상적인 문제가 주어져도 협업하면서 구체적으로 정의하며 문제를 해결해 나간다. 어차피 벼락치기 한다고 인터뷰 준비가 될 것도 아니기 때문에 평소 실력으로 편안하게 인터뷰에 임하면 된다.



이런 인터뷰 과정을 거쳐 입사를 하게 되면 한국 회사에서는 상상도 하지 못할 일이 다음날 벌어진다. 실제 업무를 하는 것이다. 교육은 없다. 필자가 대학 졸업 때부터 많은 미국 회사를 다녔지만 교육을 시킨 회사는 하나도 없었다. 그 다음날 부터 일을 시키는 것이다. 문제 해결 능력이 있는 사람들을 뽑았다면 당연히 자기가 해결해야 할 문제를 발견하고 정의하고 해결할 수가 있어야 한다. 물론 그러기 위한 기본적인 기반시스템은 갖추고 있어야 하는 것은 회사의 책임이다. 국내회사는 이런 기본 시스템도 갖추고 있지 않은 것이 산 넘어 산이다. 또 다른 방대한 주제이므로 여기서는 넘어간다. 그래서 국내 소프트웨어 개발자들의 화려한 이력서가 아무런 의미가 없다. 사상누각인 것이다. 대부분의 이력서에는 많은 프로그래밍 언어, 플랫폼, 방법론, UML같은 도구를 자랑스럽게 적어 놓는다. 미국 회사 인터뷰때는 그런 것은 별로 보지도 않는다. 다 보조적인 도구에 불과한 것 뿐이지 소프트웨어 개발자로서의 역량과는 거의 상관관계가 없다.



참고로 한국의 개발자가 구글에서 경험했다는 인터뷰 질문은 다음과 같으니 자신이 얼마나 깊이 많은 관점에서 대화를 할 수 있을까를 한 번 시물레이션 해보기 바란다. 그냥 정답을 내려고 하는 접근 방법으로는 아마 100% 불합격할 것이다.

* integer operation으로 log를 구현하려면 어떻게 하는가? 이 경우 총 연산의 수는?

*두 개의 sort된 행렬을 merge하려면 어떻게 하는가? 이 경우 complexity는 어떻게 되는가?

* C++ class의 static variable은 어떤 의미가 있고 어떻게 쓰이는가?



인터뷰 질문에서 보듯이 문제의 깊이와 다양한 관점을 가지기에는 경험도 필요하다. 그런 이유로 미국 회사에서는 젊은 개발자도 많지만 젊은 개발자가 쫓아 갈 수 없는 백발이 성성한 개발자의 역량이 존재한다. 그래서 실리콘밸리에는 60세된 개발자가 흔하고 회사의 핵심 역량이기도 하다. 실제 회사를 대표하는 기술 회의에 나가면 백발의 개발자가 나오는 경우가 많다.



문제 해결 역량은 교육부터 시작해서 기초를 배우고 제대로 된 회사에서 협업하며 경험을 함으로써 쌓여가는 것이다. 혼자서 열심히 프로그램 한다고 길러지는 역량이 아니다. 국내 교육기관도 변해야 하고 국내 기업문화도 빨리 답을 재촉하는 것보다 여러 관점에서 다양하게 생각할 기회를 주는 것이 결국은 좋은 품질의 제품을 가장 빨리 만드는 지름길이다. 이것이 바로 제1원인인 분석능력인 것이다.

댓글 1개:

Zizek :

안녕하세요.

김익환님의 책들을 관심을 갖고 읽은 독자입니다. 사실 외국의 개발 서적들만 보다가, 김익환님의 글을 보고 적잖은 충격을 받았습니다. 그동안 한국 사람이 쓴 개발서적은 별로 가치가 없을 것이라 생각했는데, 오히려 한국에서 개발하는 저의 입장에서는, 더욱 공감가는 내용..충격받은 내용이 많습니다. 감사합니다.

일단 이 글에 대해서 제가 느낀점은, 실제 개발자 역량을 파악할 때 어떤 식으로 해야할지 전달은 되는 것 같으나, 예제가 너무 쉬운 것 같긴 합니다. 물론 문제의 답을 내놓느냐가 아니라, 문제의 답에 어떻게 논리적으로 접근하느냐를 보려한다는 것을 의미하시려고 저러한 예제를 사용하셨다고 생각합니다.

사실 Problem Solving 영역은, 그것도 하나의 전문분야라고 할 만큼 깊이기 있는데, (어려운 문제는 엄청나게 어렵지요..) 실제 면접에서 어느 수준으로 질문을 할지가 좀 애매한 것 같긴 합니다. 결국은 회사 및 팀에서 요구하는 인력의 수준에 따라서 질문을 잘 해야 겠지요.

좋은 글 감사합니다.

PS) SWEBOK 번역, 해설에 대한 글도 재미있게 읽고 갑니다.