'구글'에 해당되는 글 6건

내 블로그에도 구글 애드센스(AdSense)를 달아 놓았고, 인터넷을 다니면서 구글 광고는 흔하게 많이 접한다. 몇 년 전부터 지금까지 구글 광고를 보면서 느끼는 명백한 한계점이 하나 있는데, 바로 "내가 이미 구입을 완료한 제품에 대한 광고를 지속적으로 나에게 노출시키는 것"이다.

직접 확인한 두 가지 사례가 있다.

첫 번째로, 해외에 잠시 다녀오기 위해서 호텔 검색 사이트(호X스닷컴)에서 특정 지역의 호텔들을 검색해서 몇 개를 살펴보았고, 그렇게 며칠 동안 검색한 뒤에 하나를 정해서 예약과 결제를 모두 완료했다. 그런데 그 뒤로 일주일이 지나도록 내가 인터넷을 돌아다닐 때마다 거의 대부분의 구글 광고에서, 내가 이미 예약한 바로 그 호텔에 대한 광고를 보여주는 것이었다. 우스운 것은, 내가 며칠 전에 결제했을 때의 가격보다도 더 비싼 가격을 "특가"라고 광고하는 것이었다. ㅎㅎ

두 번째는, 얼마 전에 스마트폰 케이스를 사기 위해서 또 구글 검색을 여러 번 했고, 그 중에 매우 얇은 케이스 하나를 잘 구입했는데, 구입한 지 벌써 몇 주가 지났는데 오늘 갑자기 구글 광고에서 내가 구입한 것과 정확히 똑같은 제품을 광고의 한 가운데에 배치해서 보여주었다. 내가 그 케이스를 구입한 쇼핑몰에서 내보낸 광고였는데, 다른 모양의 케이스들이나 강화유리를 보여줬을 만도 한데 정확히 내가 구입한 그 물건만 일부러 강조해서 광고에서 표시되고 있었다.

결국 구글은 내가 검색하고 가장 많이 쳐다보고 있었던 페이지가 무엇인지는 알고 있지만, (쇼핑몰 사이트에 내장된 구글 애널리틱스와 내 구글 계정의 검색 기록을 종합하면 아마 쉽게 알 수 있을 것이다) 내가 이미 구입해서 더 이상 흥미가 없는 제품이라는 판단은 아직 못 하는 듯 하다.

솔직히 구매 내역도 내 계정의 지메일을 조사하면 알 수 있을 텐데, 내 지메일도 속속들이 다 들여다 보고 있으면서 (호텔이나 항공권을 결제하면 내가 시키지도 않았는데 자동으로 구글 캘린더에 모두 등록되는 것만 봐도 알 수 있다), 구글 광고에 보여 줄 제품을 표시할 때에 지메일을 적극적으로 확인하지 않는 것은 좀 의외다.

아직 특정 쇼핑몰에서 보내 주는 주문/구매 내역에 대한 이메일 내용을 "자신 있게(충분한 confidence level을 유지한 채)" 분석해 내지는 못하는 것인가 하는 생각이 든다. 쇼핑몰이나 각종 결제 사이트마다 워낙 레이아웃과 텍스트 내용이 제각각이라서 아마 정확도를 높이기가 아직은 쉽지는 않을 지도 모르겠다.

하지만 사실 구글 어시스턴트와 같이 음성인식 비서가 발전하는 속도로 봤을 때, 이메일에 적혀 있는 자연어와 표 형식으로 잘 구분된 데이터 (대부분의 주문 내역은 표를 이용해서 제품 이름과 구매수량, 단가, 결제금액, 시간 등을 정렬해서 보여주고 있으니까)를 머신러닝을 써서 분석해 내는 것은 마음만 먹으면 금새 해낼 수 있을 것 같다.

결국 구글이 애드센스의 광고 추천 정확도를 지금보다 조금 더 개선시키기 위해서 사용자의 지메일 상의 각종 구매 내역과 전세계 쇼핑몰 사이트에서의 구글 애널리틱스에 기록된 방문 기록을 종합해서 빅데이터 분석을 수행할 의지가 있느냐 없느냐의 문제로 귀결된다.

...물론 이렇게 소소하게 구글이 인터넷에서 나에게 추천하는 모든 것에 대한 정확도를 높여 갈 수록 사람들은 오히려 구글을 더 무서워하게 될 지도 모른다. (이미 돌이킬 수 없게 무서운 존재인 것은 사실이지만...) 구글은 너무 무서워지지 않기 위해서 일부러 안하고 있는 것일까?

논문을 읽다가 아래와 같이 생긴 공식을 보게 되었는데,

여기서 차수인 람다(λ)가 1에서 2로 바뀌면서 2차평면 상에 그래프 모양이 선형에서 원형으로 바뀌고, 그에 따라 특정 영역을 커버할 수 있게 되는 부분을 설명하는 그림이 나왔다.

그리고 차수가 커짐에 따라 점차 해를 찾을 확률이 커진다는 이야기를 했는데, 그냥 순전한 호기심으로 차수가 3이 되면 그러면 어떤 모양이 되는지 (g = x^3 + y^3) 궁금해졌다.

구글에 검색해서 이미지 검색하면 웬만하면 그래프를 볼 수 있을 것이라는 기대를 하고서 검색을 해 봤더니...

오?!

기대하지도 않았던 고퀄의 그래프 시각화 결과물이 뙇!

일단 켜자마자 애니메이션으로 자동으로 돌아가면서 결과를 보여주고, 그걸 마우스 드래그로 원하는 방향으로 돌려볼 수 있고, 휠을 써서 확대/축소를 할 수도 있다. 또한 우측 하단에 있는 x, y, z에 숫자를 바꿔서 결과물을 갱신할 수도 있다.

확인해 보니 삼각함수, 지수함수, 로그함수, 3D 그래프를 시각화할 수 있고, 3D 그래프는 Web GL이 되는 경우에 보여준다고 한다.

3D로 표현할 필요가 없는 그냥 평범한 2차함수도 검색해 보니 그래프로 잘 그려주었다. 가령 y = 2x^2 를 검색하면,

위와 같이 잘 표현된다.

하지만 원의 방정식과 같이 차수가 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)으로 어떻게든 코드 작성을 시작할 수는 있어 보였다. 결국 관건은, 일단 그렇게 시작해 놓고 나서 면접관들과 대화를 해 나가면서 그 코드를 얼마나 개선시킬 수 있느냐이다. 내가 문제를 어떻게 정의하고 어떻게 단계적으로 설계하는지가 드러날 것이고, 이어서 면접관의 힌트를 얼마나 잘 활용하는지도 드러날 것이며, 면접관과의 대화를 통해서 실제로 쓸만한 코드로 개선해 내는 능력이 있는지도 드러날 것이다. 결국 구글이 원하는 소프트웨어 엔지니어 인재에 해당하는 현실의 문제를 협업을 하면서 전산 도구를 적절하게 활용해서 빠르게 개발해 내는 사람인지가 판가름이 날 것이다.

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

이번 구글 I/O 발표에 소개된 여러 가지 중에서 "나우 온 탭(Now on Tap)"을 살펴보게 되었다.

*구글 나우에 대한 회고

나우 온 탭의 이전 버전(이전 버전이라기보다는 기반이 더 맞는 표현 같다)에 해당하는 "구글 나우(Google Now)"는 음성 검색과 능동적인 정보 제공을 중심으로 하는 안드로이드 스마트폰 개인 비서의 출발점이었다. 사실 시기적으로 애플이 음성 인식 기능을 핵심으로 하는 시리를 먼저 출시했으나, 능동적으로 사용자가 필요로 할 만한 정보를 사용자가 직접 검색하기 전에 먼저 제공하려는 시도는 구글 나우가 앞섰다는 평가를 받는다. 그리고 애플은 자사의 시리를 구글 나우와 같은 형태로 발전시키기 위해서 지능형 개인비서 앱 개발업체 큐(Cue)를 인수한 바 있다.

연구실에서 상황인지 관련 기술을 더러 살펴봐 왔던 필자의 입장에서는 이러한 지능형 개인 비서의 음성 인식 기능보다는 위와 같은 "능동적인" 정보 제공 능력이 더 인상깊게 와 닿았다. 구글 나우는 개인의 검색 기록과 구글 캘린더, 그외 지도 데이터와 이동 패턴 등을 바탕으로 퇴근 시간에 집에 가는 경로와 교통편 정보를 알려 주고, 평소에 자주 검색하던 주식 정보를 보여 주고, 좋아하는 스포츠 팀의 경기 현황을 자동으로 검색해 주는 등의 몇몇 능동성을 제공했던 것을 기억한다. 심지어 내가 타지에 놀러 갔을 때, 내가 마지막으로 주차한 위치를 카드로 알려주기도 했었다.

(한편으로는 그만큼 위치 데이터와 같은 개인 정보를 구글에게 많이 제공한다는 반증이기도 하다)

*기존의 "구글 나우"에 날개를 달아 준 "나우 온 탭"

서론이 길었다. 나우 온 탭에 대한 소개 발표 내용 중 몇몇 표현을 보면:

 - "사용자가 지금 실행 중인 앱을 끄고 화면을 전환할 필요 없이 빨리 물어보고 얼른 대답을 얻고 싶을 때" (quick questions and quick answers without switching contexts)

 - "바로 필요한 그 순간에, 스마트폰 상의 어느 화면에 있든지 당신을 도와주는 것" (To assist you in the moment, right when you need it, wherever you are on the phone)

이렇게 실시간 상황에 대한 대응을 강조하는 것처럼 보인다. 

그리고 발표에서 보여주는 예시들을 보면 실제로 그렇다.

 - 음악 앱에서 음악을 듣고 있다가, 갑자기 지금 듣고 있는 음악 아티스트의 본명을 알고 싶으면, 홈 버튼을 길게 탭하고 "그의 본명이 뭐지?"라고 물어보면 바로 해당 가수의 본명을 대답해 준다.

 - 문자 앱에서 상대방과의 대화 내용이 오늘 저녁에 특정 식당에 가서 식사하는 거 어떨지 이야기하는 내용이라면, 홈 버튼을 길게 탭하고 있으면 문자 앱 화면에서 이야기하고 있던 그 식당을 구글 맵에서 바로 검색해서 위치와 메뉴 등을 보여준다. 

 - 심지어 식당 메뉴 화면에 있는 음식 이름을 이상하게 발음해도 구글이 지금 보고 있는 화면에 있는 단어들을 바탕으로 음성인식 성능을 개선하는 기능까지 생겼다.

즉, 구글 나우가 안드로이드 상에 있는 앱들의 상태와 앱에서 보여주는 정보를 "상황 정보"로 활용해서 실시간으로 구글 나우와 연동시킨 것으로 볼 수 있다. 일단 당장은 모든 안드로이드 앱과 다 연동되지는 않고 제휴를 맺은 몇몇 주요 앱들과 협력해서 나우 온 탭을 제공할 것으로 예상된다.

*사물 인터넷 환경에서 더욱 강력해질 것

구글의 이러한 행보가 무서운(?) 이유는, 가까운 미래에 "사물 인터넷" 환경이 본격적으로 생겨나고 각종 사물 인터넷 서비스 앱이 출시되기 시작했을 때, 실시간으로 사물 인터넷 환경과 소통하고 필요한 정보를 얻어 와서 보여주는 것도 가능해지기 때문이다.

사물 인터넷이 최근 컴퓨팅 업계의 주요 트렌드이고 이러한 기조가 당분간 이어질 것으로 세계 각지의 전문가들이 예측하는 만큼, 사물 인터넷의 파급력은 매우 클 것이다. 오죽하면 지금 당장 스타트업을 했을 때 가장 오래 살아남으려면 사물인터넷 쪽으로 하라는 말이 나오겠는가. 국내에서도 미래부가 사물 인터넷을 주요 전략 중 하나로 선정하고 있다.

현재는 센서나 개별 기기들이 독자적인 플랫폼과 앱을 바탕으로 사물 인터넷 서비스를 제공하는 식으로 발전되는 중이고, 당연한 순서로 주요 IT 기업들은 이들을 하나로 묶을 사물 인터넷 플랫폼 개발에 경쟁적으로 뛰어들고 있다.

사물 인터넷 환경에서 스마트폰은 사용자와 현실 세계의 사물들 사이의 연결 통로 역할을 할 것이고, 이 때 구글 나우 온 탭이 주요 사물 인터넷 플랫폼과 연동이 되어서 실시간으로 정보를 제공한다면 어떻게 될까?

어떤 스마트 공간에서 홈 버튼을 길게 탭하고 이곳의 온도와 습도가 얼마인지 질문하면, 그 공간에 설치된 온도/습도 센서에 접근해서 실시간 온도/습도 정보를 보여줄 수 있을 것이다. 스마트 TV 앞에 가서 지금 스마트폰에서 유튜브 영상을 보고 있는 상태에서 홈 버튼을 길게 탭하면, 자동으로 눈앞의 스마트 TV를 켜고 큰 화면에서 방금 전까지 보고 있던 유튜브 영상을 보던 위치에서부터 재생해 줄 수도 있을 것이다. 좀더 도전적으로 간다면, 스마트 전등(e.g. 필립스 Hue)이 설치된 방에서 불을 켠 채로 침대에 누워서 "오케이 구글, 난 자야겠다"라고 말하면 자동으로 불도 꺼 줄 수 있겠다. 충분히 가능한 시나리오다.

위의 예제들도 현재 제품화된 사물 인터넷 기기에 한정해서 나온 예제일 뿐이고, 만약 커튼이나 오븐 등등 온갖 일상 사물들이 사물 인터넷에 편입되면 상상할 수 없는 다양한 작업이 나우 온 탭을 통해서 가능해질 수도 있는 것이다. 나는 나우 온 탭의 이러한 잠재력이 놀랍고, 그 측면에서 혁신이라고 생각한다.