'소프트웨어 엔지니어'에 해당되는 글 2건

작년(2016년) 이맘때쯤에 연구를 하다 말고(ㅜㅜ) 구글 코리아에 지원을 했다가 떨어졌었다. 벌써 1년이나 지났다.

구글 채용 절차는 서류전형(온라인으로 CV 보내는 게 전부), 전화 일반면접(대화와 질의응답), 전화 코딩면접, 현장면접, 입사의 순서인데, 작년에 지원하던 당시에 나는 전화 코딩면접만 두 차례 겪어보고 떨어졌다. 기왕 떨어지더라도 현장면접까지는 가 봤어야 하는데, 내가 현장면접을 할 정도의 실력이 되지 못했다는 반증이니 달리 할 말이 없다. ㅠㅠ 그래서 현장면접에서 어떻게 해야 하는지에 대해서는 한 마디도 쓸 수 없다. 나중에 혹시 또 지원하게 되면 + 현장면접까지 겪어볼 수 있게 된다면 그 때 추가하는 걸로…

비록 1년 전의 일이지만 그 당시의 경험을 따로 어딘가에 기록해 두지 않았기에, 여기에 기록하면서 앞으로 professional (우리말로 딱 표현하려니 잘 떠오르지 않는다)한 소프트웨어 엔지니어 또는 연구원이 되기 위해서 어떤 노력을 해야 할 지 생각을 정리해보려 한다.

일단 구글의 소프트웨어 엔지니어 채용 스타일은 굳이 쓰지 않더라도 잘 알려져 있고, 유튜브에는 구글 코리아가 올린 현장면접 예시 영상도 있다. [1] 게다가 최근 구글의 채용 스타일을 꽤 많은 IT 대기업들이 따라 하고 있다. LG전자 CTO의 소프트웨어 직군 면접의 일부도 그랬었던 기억이 있다.

*지원부터 전화면접까지의 과정 개요

나는 링크드인에서 구글 코리아 소프트웨어 엔지니어 지원 페이지에 CV를 보냈는데(링크드인 프로파일을 CV로 변환해서 첨부함), 서류 통과 후에 구글 재팬(?)에서 영어로 면접을 보자는 메일이 왔다. 그래서 전화상으로 대화를 하고 질의응답을 하는 면접은 구글 재팬에서 일하는 소프트웨어 엔지니어와 영어로 진행했다. 지원대상은 구글 코리아였는데 왜 구글 재팬에서 연락이 왔는지는 잘 모르겠다. 그냥 어느 branch에 가던지 상관 없이 회사 전체적인 입장에서 면접 가능한 엔지니어를 배정한 것인지, 아니면 일본 branch에서 실제로 관심이 있었는지는 알 수 없다.

전화상의 코딩이 아닌 일반면접 후에 전화 코딩면접을 할 때에는 다행히도 구글 코리아에서 한국인 소프트웨어 엔지니어가 전화를 걸어 와서 한국어로 편하게(?) 면접을 진행할 수 있었다.

전화 코딩면접은 두 번을 했는데, 사실 전화 코딩면접은 한 번만 하고 당락을 결정하는 게 일반적인 듯 하다. 내가 왜 전화 코딩면접을 두 번 했는지 정확한 이유는 사실 알 수 없다. 굳이 추측하자면, 내가 첫 번째 전화면접 후에 당락의 경계선 상에 놓이게 되면서 현역 엔지니어들이 보기에 ‘긴가 민가’ 해서(…) 한 번만 더 기회를 줘 보자고 생각했을 지도 모르겠다.

아니면 조금 더 부정적으로 보자면, 내가 비록 첫 번째 전화면접에서 망했지만(ㅠㅠ) 그럼에도 불구하고 혹시나 지원자가 애석하게도 문제가 잘못 걸려서 못했을 지도 모르니 다른 문제를 내서 한번 더 역량을 발휘할 기회를 줘 보자는 생각이었을 수도 있다. 결국 두 번째 전화면접 이후에 다시 구글 재팬에 있던 맨 처음 전화로 얘기했던 엔지니어로부터 탈락 통보를 이메일로 받았다.

전화 코딩면접 진행 과정은 잘 알려져 있듯이 사전에 이메일로 공유된 구글 문서를 켜고, 휴대폰으로 걸려오는 전화를 통해서 문제를 전달받고, 30분 동안 그 문제를 해결하는 코드를 구글 문서에 작성한다. 중간에 엔지니어와 계속 전화상으로 대화하면서 진행한다.

첫 번째 전화 코딩면접 때는 문제를 정확하게 이해하지 못하는 바람에 알고리즘 제시는 못했고, 어찌됐든 컴파일 에러나 로직 에러(스택오버플로우, 익셉션 따위) 없이 돌아가는 코드를 제출하기는 했다.

두 번째 전화 코딩면접 때는 문제를 제대로 이해했고 어떻게 해결하면 되는지 해결 방법도 개념상으로는 맞게 제시했지만, 막상 내가 짠 코드에 컴파일 에러뿐만 아니라 스택오버플로우 문제마저 있는 상태로 제출해 버렸다. ㅠㅠ

(문제가 무엇인지는 왠지 함부로 공유하면 안될 것 같아서 일부러 언급하지 않았다.)

위의 두 차례의 전화 코딩면접을 겪으면서 나의 어떤 부분이 부족했는지를 생각해 보았다.

*알고리즘과 코딩실력: 두 마리 토끼 모두 잡기

위에 언급했듯이 나의 첫 번째와 두 번째 코딩면접 결과를 보면 알고리즘 이해도와 코드의 완성도, 이 두 가지 측면에서 서로 다른 한계를 갖고 있었다. 알고리즘을 정확히 이해해서 문제 해결방법을 제대로 짚기도 해야 하지만, 결국 그걸 주어진 시간 안에 집중적으로 코딩해서 실제로 돌아가는 코드를 만들어내는 능력이 있는지도 같이 검증하는 것이 아닐까 싶다.

구글 입장에서도 이익을 극대화하려면 같은 소프트웨어 엔지니어라도 기본기가 있어서 재교육 비용이 가급적 적게 드는 인재를 원할 테니까 당연한 것일 수 있다. 면접 과정에서 프로그래밍 언어의 선택권이 지원자에게 있는 만큼, 그만큼 지원자 입장에서 가장 자신있는 프로그래밍 언어를 들고 왔을 테니 적어도 문제없이 코드를 짤 수 있어야 한다는 전제가 깔려 있을 것 같다.

*코딩면접 이전의 일반 전화면접의 중요성

이 부분은 이전 포스팅(http://skylit.tistory.com/189)에서도 썼지만, 채용에서 떨어진 후에 다시 생각하면서 반복해서 쓰게 되었다.

지금 다시 생각해 보면, 전화 코딩면접을 하기 전에 구글 재팬 소프트웨어 엔지니어와 나눴던 대화가 의외로 중요했으리라는 생각이 든다. 그 당시에 나 자신의 역량에 대해서 여러 분야별로 1~10점 사이의 점수를 매겨 보라는 질문을 받았는데, 그 때 멋모르고 Java 언어를 조금 높게(7점) 제시했더니 엔지니어가 살짝 당황하는 눈치였다. 그리고 이어서 들어오는 Java 언어의 자세한 속성들에 대한 질문에서 제대로 대답하지 못하고 실컷 털리고 보니 내가 점수를 뻥튀기한 셈이 되어 버렸다. ㅜㅜ

그리고 알고리즘은 내가 4점 또는 5점이라고 대답했던 것 같다. 이 경우는 비록 그 당시에 대답하던 당시에는 나의 가감없는 실제 실력을 그대로 보여주는 점수라고 할지라도, 차라리 그 전에 미리 알고리즘 개념을 복습을 좀 하고서 6점 정도가 된다고 자신 있게 이야기할 수 있어야 했다. 알다시피 구글은 알고리즘을 특히나 중요하게 생각하는데 이미 그 역량에서 내가 한 수 접고 들어간 것이다. ㅜㅜ

즉, 코딩이 아닌 일반 전화면접이고 그냥 대화를 나눈다는 식으로 안내가 오더라도 그 메일에 속지 말고(?) 전산학의 주요 분야를 충분히 복습해야 한다.

*트렌드보다는 기본기가 충실한 것이 더 중요하다.

IT분야의 큰 트렌드에 따라 시기별로 회사가 유난히 원하는 소프트웨어 엔지니어의 종류도 어느 정도 있게 마련이다. 가령 2000년대 중후반에는 정보검색 기술, 2010년대 초반에는 빅데이터, 수 년 전부터 지금까지는 IoT와 클라우드, 최근에는 인공지능 등…

그런데 구글은 일반 소프트웨어 엔지니어 채용 과정에 있어서는 그런 트렌드를 별로 고려하지 않는 듯한 느낌이 들었다. (트렌드에 적합한 실력 있는 인재는 그 회사를 인수하는 방법으로 충당하는 것일지도?)

내가 얼마나 지금의 트렌드에 적합한 인재인지에 대한 자기PR은 서류 전형에서 조금이나마 영향을 줄 수는 있을 지도 모른다. 하지만 전화 코딩면접에서는 정말 내가 학사인지 석사인지 박사인지는 전혀 중요하지 않았고, 내가 석/박사과정을 하면서 나름대로 확보했다고 생각되는 경쟁력에 대해서는 통화를 시작할 때 단 한번 물어보고 끝났다. 예를 들면,

첫 번째 전화 코딩면접 당시:

두 번째 통화에서도:

결론적으로, 구글은 나의 석/박사 연구주제나 논문에 관심이 없다. ㅠㅠ 석/박사과정을 통해서 습득한 연구능력이 산업 현장에서 일어나는 문제를 제대로 정의해서 해결 방법을 체계적으로 제시하는 것으로 발현이 되는지를 코딩면접을 통해서 검사할 뿐이다. 즉, 내가 과거에 석/박사 연구를 얼마나 체계적으로 잘 수행했는지를 확인하는 대신, 그렇게 연구를 잘 했으니까 instant하게 주어지는 문제 상황에 대해서도 본인이 잘 대처하는지 증명해 보라는 식이다.

해외, 국내를 막론하고 차라리 다른 회사들이라면 나의 박사학위 연구 주제에 대해서 물어볼 만도 하고, 어느 학회나 저널에 냈는지에 관심을 가져 주거나 연구실에서 수행한 프로젝트가 회사가 필요로 하는 일과 얼마나 연관성이 높은지 정도를 생각해볼 만도 한데, 구글 소프트웨어 엔지니어는 그런 거 없다. 그냥 소프트웨어 엔지니어 개인이 기본기와 문제해결능력이 충분하면 어떤 문제를 던져 줘도 잘 해결할 것이라는 단 하나의 원리만 갖고서 채용하는 것처럼 느껴졌다.

물론 구글도 개발이 아닌 연구 부서가 없을 리가 없겠지만 잘 알려져 있지 않으니까… 적어도 구글이 생각하는 “소프트웨어 엔지니어” 범주에서는 학위를 별로 신경쓰지 않는 것만은 확실하다.

이것을 바꾸어 생각해 보면, 결국 내가 석/박사과정을 충실하게 보냈는지를 과거 기록에 의존하지 않고 검증하는 것과 같다. 모든 교수님들이 얘기하듯이 대학원에서 배우는 핵심은 문제 정의와 문제 해결 능력이고, 이것은 스펙만으로 일대일 대응으로 증명되지는 않는다. 즉, 문제해결능력이 뛰어난 석/박사가 논문을 잘 쓰고 프로젝트를 성공적으로 수행하는 것은 참이 되지만, 좋은 논문실적과 좋은 프로젝트 수행 실적이 개인의 문제해결능력을 역으로 증명해 준다고 볼 수는 없다는 것이다.

*결론: 어려운 문제를 대하는 태도의 문제

비록 전화 코딩면접에서 떨어졌지만, 내 입장에서는 꽤 중요하고 값진 경험이었다. 내가 알고리즘 설계와 코딩 실력이 어느 정도 되는지를 점검할 수 있는 기회였고, 한편으로는 말로 설명하는 나의 역량과 실제로 드러나는 나의 생산성 사이에 존재하는 괴리를 직접 확인할 수 있었다.

최근에 자꾸 연구과제 등 신경쓸 것이 많다는 핑계로 개인연구가 점점 미뤄져 가는 현실을 한탄하고 있지만, 정작 이러한 도전적인 상황에서 문제해결능력과 코딩면접 때와 같은 집중력으로 지금의 상황을 돌파해 내지 못하는 내 모습을 다시 확인할 수 있었다. ㅜㅜ 내가 박사학위를 내 손으로 내 실력으로 받기 위해서는 지금의 내 모습에서 한두 단계는 더 역량을 업그레이드해야 한다는 것도 다시 느끼게 되었다.

개인연구에서 제시하는 문제 상황을 시뮬레이션이나 실험 코드로 구현해서 측정하고 그걸 증명하는 과정에서 쉽게 코딩이 되지 않을 때가 자주 있는데, 사실 그 때 문제를 해결하는 것이 어쩌면 구글 전화 코딩면접을 하는 과정과 다를 바가 없는 것 아닐까? 어려움에 봉착했을 때, 귀찮아하면서 좀더 쉬운 과제 문서작업이나 연구실 허드렛일들(서버 관리 등)을 하며 의도적으로 회피했던 내 모습이 부끄럽다. 그럴 때 문제에 직면해서 해결 방법을 설계하고 그 방법을 집중해서 구현하면서 (비록 에러가 나거나 버그가 발생하더라도) 반복적으로 검증함으로써 점차 나만의 문제 해결 능력과 코딩 능력을 쌓아 가는 태도가 필요하다.

무턱대고 방향성 없이 하는 노력이 아니라, 나의 궁극적인 목표(박사학위)를 달성하는 과정에서 일어나는 온갖 문제들을 어떻게 해결할 지를 생각해 가면서 꾸준하게 집중적으로 노력하는 나 자신이 완성될 때까지는 힘들지만 매일매일 회피하지 말고 노력해야 하겠다.

<참고자료>

[1] https://www.youtube.com/watch?v=BF3FLDAzWxo

링크드인(LinkedIn)에 가끔씩 들어가서 개인 프로파일 관리를 하다가, 지난 1월에 구글 코리아에서 소프트웨어 엔지니어 채용 과정이 열려 있다는 내용의 공지를 보게 되었다. 그 페이지를 보면서 내가 무슨 배짱(...)이었는지 모르지만, 아무튼 Apply 버튼을 누르고 링크드인의 프로파일 페이지를 변환해서 간단한 CV를 첨부해서 보냈다.

Apply 버튼을 누를 당시에는 정말로 별 생각이 없었다.

'설마 되기나 할까?'

잠시 이런 생각을 했다가, 큰 의미부여 없이 그렇게 신청해 두고는 최근까지 잊고 지냈었다. 곧이어 개인연구 실험과 제안서 작업이 닥쳐와서 지원했다는 사실을 까맣게 잊은 채 바쁘게 지냈고, 서류 검토 과정에서 떨어졌으리라 생각했을 뿐이었다.

그런데, 며칠 전에 "Hello from Google" 이라는 제목으로 영어로 된 이메일 하나가 왔다. 너무 간단한 제목에 스팸이나 피싱이 아닐까 하는 걱정을 하면서 메일을 열었는데, 신기하게도 나의 지원 정보가 구글 재팬으로 넘어가서 일본인 소프트웨어 엔지니어 한 명이 관심을 갖고 나에게 연락한 것이었다.

그 엔지니어가 가까운 시간 내에 전화로 얘기를 해 보자고 해서 일단 바로 다음날로 시간을 정하고 전화통화를 하였다. 나는 내 지메일 계정에 행아웃으로 영상통화를 걸어올 줄 알았는데, 그냥 +81로 시작하는 국제전화가 걸려 왔다. ㄷㄷㄷ

메일을 받았을 때, 메일 내용에는 그저 conversation이라고 되어 있었지 면접이라고 적혀 있지 않았기에 나는 준비도 긴장도 없이 (물론 낯선 사람과의 통화에 긴장이 안될 수는 없지만, 국내 대기업 기술면접을 준비했을 때에 비하면 긴장이 아니었다) 전화를 받았다. 그런데 알고 보니 기술면접을 포함하는 전화 면접이었다. (...) 일본인이니까 영어로. 연습도 못해 보고 실전 전화영어라니... 그래도 담당 일본인 엔지니어가 영어를 명확하게 잘 해줘서 알아듣는 데 큰 어려움이 없어서 정말 다행이었다.

처음에는 무엇을 해 봤는지, 언제 졸업하는지, 언제부터 일할 수 있는지 등을 물어보다가, 몇몇 기술요소(예를 들어 자바 프로그래밍 언어, 알고리즘, 데이터구조 등)에 대해서 본인의 지식수준이 얼마나 되는지를 0~10 사이의 숫자로 스스로 평가해 보라고 했다. (0: 전혀 모름, 1:초보, 3:초중급, 5: 중간, 7:전문가, 10:다 아는 신급)

여기서 내가 실수한 것이 있는데, 웬만하면 7 정도의 숫자를 함부로 말하면 안되는 것이었다. ㅋㅋㅋ 지금 생각해 보면 정말이지 용감하기만 한 내가 어떻게 비춰졌을지 손발이 오글오글하다. @_@

그러고 나서 갑자기 기술적인 질문 십수 가지를 던지기 시작... ㅜㅜ

완전 망함... 까지는 아니지만, 그렇다고 선방한 것도 결코 아닌, 알고리즘과 자료구조에 대해서 전혀 준비되지 않은 나의 날 것 같은 지식이 모두 탄로나서 털털 털렸을 뿐이었다. ㅠㅠ 

평소에 쓰는 자료구조가 개인연구 또는 연구실 과제 차원에서 필요한 것들만 반복해서 쓰는 정도라서 다양한 자료구조를 다룰 일이 적다 보니 아는 것은 잘 아는데 모르는 것은 전혀 모르는 편식하는 학생 신분의 개발자였기에, 이렇게 갑자기 훅 들어오는 질문들에 대한 내 대답은 천차만별이었다. 평소에 개인연구의 실험 코딩을 하다말고 자꾸만 옆길로 빠져서 네트워크 로그 정보를 처리하기 위해 무슨 데이터 구조를 쓰는 게 좋을지 살펴보느라 시간을 허비했던(?) 과거의 경험이 오히려 고마울 뿐이었다. 그마저도 없었다면 거의 대부분의 질문에 대답을 못했거나 틀리게 했을 것이다. 차라리 며칠 더 시간을 두고 그 동안 알고리즘, 자료구조를 간단히 리뷰라도 하고 나서 통화를 했으면 그나마 나았을 텐데 무식하면 용감하다는 것을 몸소 실천하는 꼴이 되고 말았다. ㅠㅠ

아무튼 정신없는 기술면접을 마무리하고, 엔지니어로부터 나중에 한번 더 전화통화를 하면서 코딩 면접을 할 것이라는 안내를 받고서 통화가 끝났다. 아마 구글 공유 문서를 통해서 코드를 짜는 과정을 검토하는 방식을 말하는 듯 했다.

구체적인 시간은 정해지지 않았지만 아마도 짧으면 1주, 길면 2주쯤 후에 전화상 코딩면접이 있을 것이고, 이 과정을 무사히(?) 통과하면 서울에 있는 구글 코리아에 직접 가서 또 기술면접을 여러 차례 하게 될 것으로 예상된다. 구글 재팬에서 채용을 진행하는데 얼굴을 대면하는 기술면접은 서울에서 본다길래 의아했지만, 알고 보니 원래 지원자가 있는 지역에 구글 지사가 있으면 그 곳에 가서 면접을 보는 게 정식 절차라고 한다.

일단 당장 얼마 후에 있을 2차 전화면접을 잘 해야 그 다음 과정도 의미가 있을 텐데... 서류를 통과한 모든 지원자에 대해서 오프라인 기술면접까지 모두 하게 해 주는지는 알아내지 못했다. 전화통화하던 당시에도 마지막에 정신없어서 묻지도 못했다. ㅡㅡ 상식적으로 생각해 보면, 전화상 코딩 면접에서 잘 하지 못하는 지원자를 굳이 회사까지 데려와서 면접해서 현역 엔지니어들의 시간과 비용을 낭비할 필요는 없을 것 같다.

어쨌든 이렇게 갑작스럽게 좌충우돌 구글의 소프트웨어 엔지니어 면접 과정을 시작하게 되었다. 지금 내가 처한 상황을 있는 그대로 얘기하자면, 내가 얼마나 털릴지 가늠이 안되는 상황에서 산 정상은 아득하게 보이는데 산 중턱은 구름에 가려져 있고, 나는 고급장비 하나 없이 정상을 향해서 맨몸으로 뛰어가는 듯한 느낌이다. ㄷㄷ

상황만 놓고 보면 내가 해낼 수 있을까 하는 의구심이 한가득이지만, 한편으로는 과연 내 실력이 어디까지일까 점검해 볼 수 있다는 측면에서 기대가 되기도 한다. 다시 말해서 뭔가 긴장감이 몰려 오는데, 그 긴장감이 싫다기보다는 도전해 보고 싶다는 그런 느낌이다.

1~2주 동안에 알고리즘이나 자료구조 차원의 지식을 보강해야 하는데, 연구를 하는 중간에 내가 얼마나 보강할 수 있을지는 모르겠다. 결국 면접에서 살아남기(?) 위해서는 문제해결능력으로 어필해야 할 것 같다. 박사과정을 하면서 남의 논문을 평가하고 내 논문을 쓰는 차원의 문제해결 과정은 겪어봤는데, 그렇게 연습해 온 것이 도움이 되기를 바랄 뿐이다.

면접에서 물어볼 만한 샘플 문제들을 하나씩 살펴보면 만만치않은 난이도인데, 실제 문제는 이보다 더 어려울 것이다. 몇몇 문제는 일단 무식한 방법(brute force)으로 어떻게든 코드 작성을 시작할 수는 있어 보였다. 결국 관건은, 일단 그렇게 시작해 놓고 나서 면접관들과 대화를 해 나가면서 그 코드를 얼마나 개선시킬 수 있느냐이다. 내가 문제를 어떻게 정의하고 어떻게 단계적으로 설계하는지가 드러날 것이고, 이어서 면접관의 힌트를 얼마나 잘 활용하는지도 드러날 것이며, 면접관과의 대화를 통해서 실제로 쓸만한 코드로 개선해 내는 능력이 있는지도 드러날 것이다. 결국 구글이 원하는 소프트웨어 엔지니어 인재에 해당하는 현실의 문제를 협업을 하면서 전산 도구를 적절하게 활용해서 빠르게 개발해 내는 사람인지가 판가름이 날 것이다.

이번 면접 과정을 기회삼아, 비록 주어진 시간이 얼마 없지만 그동안 내 지식을 다시 정리해서 내 실력이 어디까지인지 점검해 보는 계기로 보고 준비해 봐야겠다.