양날의 기술 - 편리한 기술이 감시의 도구로

이 글은 <실리콘밸리 견문록>에서 발췌한 글입니다.

2013년 6월 6일, 가디언The Guardian과 워싱턴 포스트The Washington Post에 충격적인 기사가 올라왔다. 미국 국가안보국 NSA가 미국 최대 통신사 버라이즌Verizon으로부터 매일 수백만건의 통화기록을 수집했다는 기사였다. 국외의 적으로부터 미국 국민을 보호한다는 NSA가 자국 국민이 언제 어디서 누구와 얼마나 통화했는지에 대한 자료를 통째로 넘겨받아 데이터베이스화하고 언제든 과거의 통화 기록을 꺼내볼 수 있다는 내용이었다. 이 기사만으로도 경천동지할만한 일인데 이후로 밝혀질 일들에 비하면 이건 빙산의 일각이었을 뿐이었다.

에드워드 스노든Edward Snowden

20대의 에드워드 스노든은 NSA의 시스템관리자로 일하면서 미국 정부의 상상을 뛰어넘는 통신 감청 및 수집 행위를 알게되었고 대략 170만건의 관련자료를 빼내 세상에 폭로했다. 2013년 6월 6일 이후, 아마도 인류역사가 계속되는 한 역사책에 영원히 남을 인물이다. 국경을 뛰어넘는 장벽없는 기술의 발전이 부패한 위정자와 행정권력에 의해 무시무시한 감시와 통제의 도구가 될 수 있다는 것을 에드워드 스노든만큼 극적으로 보여준 사람은 없었다.

프리즘PRISM

에드워드 스노든이 언론에 제공한 자료들이 속속 세상에 나오면서 전화뿐만 아니라 이메일, 영상통화, VoIP(인터넷 전화), 사진, 동영상, 파일 전송, 소셜 네트웍 활동 등 거의 모든 인터넷 활동을 NSA가 감청한다는 사실이 밝혀졌다. 수집 대상은 미국 국민들도 포함되어 있었고 감청의 범위는 가히 전세계라고 할 만큼 광범위했다. 프리즘 프로젝트에서 주목해야 할 점은 이 프로젝트가 수집하는 데이터가 소위 메타데이터로 불리는 누가 언제 누구한테 통신을 주고 받는지에 대한 정보뿐만 아니라 통신 내용 자체까지 포함한다는 점이다.

미국 실리콘밸리의 세계적 인터넷 기업들이 미국의 FISA, 즉 해외 정보 감시법Foreign Intelligence Surveillance Act에 의해서 법원의 명령이 있을 경우 사용자의 정보를 국가 기관에 제출하도록 강제받았다는 사실도 드러났다. 인터넷 기업들은 사용자의 신뢰를 얻어야만 생존할 수 있다. 그런데 이번 사건은 사용자의 신뢰와 법의 준수 사이에서 기업들을 고민하게 만들었다.

물론 미국에 근거를 두는 이들 기업들이 어찌되었든 법이 명령하는 것을 지키지 않을 방법은 없다. 야후는 NSA의 요청을 적극적으로 거부하여 재판장까지 갔지만 패소하고 법에 의해 사용자 정보를 제공할 수 밖에 없었다고 한다. 기업들은 법에 의해 NSA와 협력한다는 것을 밝힐 수도 없고 소송을 해도 미국의 사법 시스템은 그들의 편이 아니었다. 더우기 실재하는 테러리스트의 위협으로부터 미국 국민을 보호한다는 명분에 적극적으로 대항하기는 힘들었을 것이다.

설령 인터넷 기업들이 정보의 제공을 거부하였어도 NSA는 기업 데이터센터를 해킹하여 원하는 자료를 빼내갔다고 한다. 일명 MUSCULAR 프로젝트였다. NSA의 파워포인트 슬라이드 하나가 주목을 받았는데 구글의 망 구성도였다. 그림의 가운데 부분이 핵심이었다. 구글이 암호화를 하는 부분이 구글 내부 데이터센터와 외부 인터넷을 연결하는 GFE라는 부분이고 내부 데이터센터간 통신에는 암호화가 이루어지지 않는다는 것이었다. 그리고 GFE를 설명하는 글, "SSL added and removed here! :-)"의 끝에 웃는 표정의 스마일리Smiley 아이콘이 그려져 있었다. 이걸 본 구글 엔지니어들은 분노했다. 중국 정부의 조직적인 해킹 공격에 대항하여 중국의 민권운동가를 지켜내며 군인들이 총을 들고 구글 데이터센터의 문을 열라고 협박해도 굴하지 않겠다는 구글 엔지니어의 자부심이 NSA의 웃는 아이콘 하나에 무너졌다. 그림속 이모티콘 ;-)이 이렇게 뼈아플수 있을까.

B2. NSA MUSCULAR 프로젝트 슬라이드 중 구글의 망 구성도 

구글 엔지니어들은 더욱 철저하게 암호화를 했고 데이터센터간의 통신뿐만 아니라 컴퓨터간에 주고 받는 데이터를 암호화했다. 그리고 이메일의 종단간end-to-end 통신을 암호화하는 소프트웨어도 오픈소스화하였다. 그리고 소스 코드에 "SSL-added-and-removed-here-;-)"라는 메시지가 보란듯이 들어있었다. 암호화(SSL)는 이제 구글의 GFE가 아닌 NSA가 중간에 가로채긴 힘든 이 부분에서 이루어진다는 조소였다.

B3. 미국 잡지 PCWorld가 발견한 구글 소스 코드내 문장

인터넷 감청은 완전히 새로운 수준의 감시 체계 

미국 정부가 감청을 한다는 사실은 새로운 것이 아니다. 미국은 법에 의해 이미 70년대부터 국외 통신에 대한 감청을 해왔다. 또한 자국 국민을 감청한다는 사실도 세계적으로 보면 새롭지 않다. 가깝게는 우리나라만 해도 민간인 사찰이 조직적으로 이루어진다는 것이 종종 기사화되곤 하지 않는가.

주목해야 할 곳은 따로 있다. 인터넷이 등장하면서 감청의 범위와 대상의 규모가 상상하지 못할 수준이 되었다. 인터넷에는 국경이 없다. 전세계가 인터넷으로 연결되어 있다. 인터넷을 통해 보내는 데이터는 지리적으로 가까운 경로가 아니라 전송 비용이 최소가 되는 경로를 선택하도록 설계되어 있다. 인터넷 통신망에 있어서 미국은 로마제국이다. 전세계 통신망이 미국으로 연결되어 있고 상당량의 세계 인터넷 데이터가 미국을 통과하거나 미국으로 향하고 있다. 미국 정부는 앉아서 통신망에 귀를 대고 있으면 전세계 통신을 감청할 수준이 된 것이다. 얼마나 많은 데이터가 인터넷을 통해 움직이는 지 상상해 보면 전세계인이 부처님 손아귀에서 움직인다는 느낌이 들 정도다.

속고 속이는 각국 정부 

프리즘에는 미국 뿐만 아니라 영국, 독일 등 여러 나라가 참여하는 것으로 보고되었다. 재미있는 것은 프리즘 프로젝트에 공조하는 나라에 대하여도 미국이 따로 감청을 했다는 점이다. 유출된 NSA 자료에 의하면 2013년 3월 한달 동안 독일내 통신 자료만 5억건이 수집되었다고 한다. 심지어는 독일의 앙겔라 메르켈 수상을 미국 정보국이 10년 이상 감청해왔다는 정황이 드러나기도 했다. 독일 정부는 미국 대사를 소환하여 항의하였고 메르켈 수상이 오바마에게 직접 전화를 걸어 사과를 요구하기도 했다.

평소 미국은 중국발 해킹 공격을 강하게 비판해왔는데 프리즘을 비롯한 광범위한 감청의 전모가 드러나면서 뭐 묻은 개가 뭐를 욕하는 격이 되었다.

기술의 한계 

에드워드 스노든의 폭로는 미국인뿐만 아니라 전세계 시민들에게 질서와 안전을 부르짖는 권력자들의 생얼을 보여주었고 자신을 둘러싼 기술 환경이 권력자에 의해서 어떻게 악용되는지 보여주었다.

실리콘밸리에서 반짝거리는 눈으로 기술을 가지고 세상을 바꾸겠다는 젊은 엔지니어들을 만나는 것은 어렵지 않다. 다음 세대에게 더 좋은 세상을 물려주기 위해 전세계의 엔지니어들이 실리콘밸리로 날아온다. 기술로 전세계를 연결하고 지구상 어디에서나 누구나 자유롭게 질좋은 정보를 사용할 수 있게 만들어주고, 더 좋은 기술을 만들 수 있도록 누구에게나 소스코드를 공개하면 더 좋은 세상을 만들 수 있다고 믿었다. 유치하고 순진하지만 이것이 실리콘밸리의 성공을 만들어 낸 것이다.

그런데 그 기술이 평범한 시민들을 감시하고 통제하는 데에 사용되었다. 전세계를 자유롭게 연결한 인터넷을 엿듣고 좋은 세상을 만들자고 공개한 기술을 가지고 사람들을 압제할 도구를 만들었다.

에드워드 스노든 사건은 기술이 안보라는 깃발 아래, 법과 제도에 부딪힐 때 얼마나 연약한지 알려주었다. 그리고 법이 강제한다고 하여도, 국가 안보가 걸린 문제라고 하여도, 사람들을 압제하는 기술을 만든 엔지니어들은 도덕적 책임으로부터 자유롭지 못하게 되었다.

NSA가 저지른, 인류에 대한 범죄 

에드워드 스노든 폭로 이후의 세상은 이전과는 다른 세상이 되었다. 아랍에서 일어난 재스민 혁명은 페이스북 등 인터넷이 평범한 시민들을 깨우고 독재자를 몰아내는 시민 혁명의 도구가 될 수 있음을 보여주었다(혁명 시작후 5년이 지난 현재 재스민 혁명은 실패했다는 의견이 나오고 있다). 인터넷이 사람들의 생각을 자유롭게 나눌 수 있는 공간이 되고 진정한 민주주의 도구라는 환상을 심어주었다. 에드워드 스노든 이후 사람들은 더 이상 인터넷과 기술 기업을 신뢰하지 않는다.

많은 사람들이 매일 찾는 수영장이 있다. 수영장 한 구석에서 와인을 마시며 지평선에 걸치는 붉은 태양을 보노라면 그렇게 좋을수 없었다. 수영장의 안전요원들은 혹시나 있을 사고에 대비하여 경계를 늦추지 않았다. 고마운 이들이다. 그런데 어느 날은 소세지같은 길쭉한 것이 물에 떠올랐다. 똥이었다. 누군가 수영장에 똥을 싼 것이다. 수영장에 있었던 사람들이 허겁지겁 빠져나오기 시작했다. 옆에 있던 안전요원에게 이야기했더니 그가 하는 말이 충격이다. 오늘만 똥이 나온 것이 아니라 사실은 수영장 물에 똥이 항상 섞여 있었단다. 그리고 안전요원들이 일부러 수영장 물에 똥을 싸왔다고 한다. 헉! 이제 이 수영장에는 사람들이 놀러 올 것인가? 내일도 그 다음날도 안전요원들이 바뀌지 않는다면.

NSA가 해왔던 일들이 드러나면서 세상은 의심의 시대로 들어섰다. 미국 기업들에 대한 신뢰는 떨어졌고 이것이 미국 산업에 영향을 주었다. 보잉으로부터 전투기를 구매하기로 했던 브라질은 NSA 사건 이후 구매계획을 취소하고 스웨덴의 Saab와 45억달러 전투기 구매계약을 했다. 이제 미국 IT기업들이 다른 나라에서 사업을 하려면 전보다 훨씬 더 까다로운 절차를 거쳐야 한다. NSA의 요청에 의해 자신들의 네트워크 장비에 백도어를 심은 시스코Cisco사는 중국 시장에서 고전하고 있다. 인터넷 종주국이었던 미국은 이제 세계 각국이 인터넷 관리의 힘을 지역 국가로 분산시키자는 도전에 직면하고 있다.

NSA는 단순히 미국 기업의 매출에 타격을 주고 미국의 기술 지도력을 떨어뜨린 것이 아니다. NSA는 세상을 불신의 시대로 떨어뜨렸고 기술의 밝은 미래를 작살냈다. 평범한 인터넷 사용자들이 친구와 채팅을 하고 가족과 영상통화를 할때 가슴 저 밑바닥에서는 불안감을 떨치지 못하는 세상을 만든것이다.

기술, 국가, 인류

에드워드 스노든의 진짜 업적은 기술환경과 부패한 권력에 대해 눈 감고 있던 사람들을 깨운 것이다. 주인이 잠을 자고 있는 동안 집을 지키라고 키우던 개들이 찢고 까부르고 난장판을 만들었다. 주인이 자고 있으니 세상이 지들 것인양 난리를 피우다 주인의 침대에까지 뛰어올랐다. 놀라 잠이 깬 주인 앞에 개들이 멈칫한다. 난장판이 된 방안을 둘러본 주인이 버럭 소리를 지른다. 주인의 고함 소리에 그제야 자신들의 위치를 깨닫는다. 먹여주고 재워주고 쓰다듬어주었던 그 사람이 주인이고 자신들이 주인의 것들을 망쳐놨다는 사실을 깨닫고 꼬리를 감추고 만다.

법도 정부도 국가도 모두 시민을 위해 존재한다. 시민이 주인이다. 시민이 먹여주고 재워주고 쓰다듬어주었던 권력이 기술을 가지고 시민을 감시하고 통제하려고 한다면 누가 주인인지 보여주어야 한다. 주인이 잠에서 일어나 눈을 떠야 한다. 에드워드 스노든이 시민을 깨우고 있다.


덧: 결론부의 개 비유는 개를 가족으로 생각하는 분들께는 거북하게 들릴수 있습니다. 미리 사과의 말씀을 드립니다.

구글 소프트웨어 엔지니어 인턴에 대한 정보

구글 소프트웨어 엔지니어 인턴에 관심있는 분들께.

이번에 팀에서 인턴을 채용하면서 알게 되었는데 관심있는 분들께 도움이 되시라고 올립니다. (일반적으로 알려진 내용일텐데 모르시는 분들도 있을 것 같아 올립니다. 인턴 채용은 각 나라별로 조금 다를수 있고, 아래의 내용은 구글 본사에 관한 내용임을 알려드립니다.)

1. 대학 학부/대학원(석사, 박사) 재학 중인 학생
인턴을 하게 될 시점에 재학중이어야 합니다.  여름방학에 인턴을 하면 그 전 가을부터 지원을 하는데요, 인턴을 하게 되는 여름동안 재학중이어야 합니다. (휴학중이면 어떻게 되는지 모르겠네요. 될 것 같긴 한데.)

2. 한국에서 본사로 지원 가능합니다
외국에서 미국으로 지원해서 합격하는 경우가 많습니다. 다른 나라에서 오는 인턴은 회사에서 비자 프로세스 지원까지 해 줍니다.

3. 전화로 기술면접을 봅니다
사람마다 경우마다 다르지만 보통 두세번 정도 전화로 기술면접을 보고, 한번에 45분 정도 면접을 봅니다. 인턴도 일반 소프트웨어 엔지니어와 비슷한 수준의 난이도로 기술 면접을 실시합니다.

4. 합격후에도 프로젝트를 찾는 프로세스가 있습니다
면접을 잘 보고 합격을 한 후에는 가장 중요한 절차가 남아 있습니다. 프로젝트(팀)을 찾는 건데요. 프로젝트를 찾지 못하면 합격을 했어도 인턴자리를 얻지 못합니다. 이때 마치 TV 짝짓기 프로그램처럼 인턴을 호스트할 팀과 인턴 합격자간의 밀고당기기가 있습니다.

인턴 호스트 신청자들은 인턴 합격자 전체 리스트를 보고 관심을 표하고 프로젝트 매칭 인터뷰를 하자고 요청합니다. 인터뷰 성적이 좋고 레쥬메가 좋은 인턴들은 인턴 호스트들이 서로 데려가려고 매칭 인터뷰 신청을 하기 때문에 자기가 원하는 팀을 골라서 갈 수 있습니다. 합격자 중에서도 인기가 없어서 결국 호스트를 못 찾는 경우도 많을 것 같습니다.

인기 있고 정말 괜찮은 인턴들과 매칭 인터뷰를 할 때는 저도 등줄기에 땀이 날 정도로 우리 프로젝트가 얼마나 좋은지 홍보를 합니다.

저는 호스트의 입장에서 수학과 구현을 잘 하는 인턴을 구했는데요, 긴 합격자 리스트에서 대여섯명 정도 매칭 인터뷰를 하고 정말 기대되는 인턴을 득템했습니다. ^^

5. 여름 인턴은 그 전 해의 가을부터 지원해야 합니다
겨울에 이미 합격된 인턴들의 프로젝트 매칭 인터뷰가 시작되고 3월이면 매칭 인터뷰도 끝납니다. 여름 인턴을 준비하신다면 1년전부터 미리 준비를 해야 합니다.

인턴에 관심있는 분은 "슈퍼인턴을 만나다"도 참고하세요.

구글 인터뷰 팁

오래전에 구글+에 올렸던 글을 옮겨왔다.

구글에 소프트웨어 엔지니어로 지원하려는 사람들을 위해 몇 가지 팁을 적어본다. 이 글은 구글의 공식적인 의견이 아니고 개인적인 경험을 바탕으로 대학 후배에게 얘기한다는 마음으로 적은 글이다. 누구에게나 적용하기 힘든 개인적인 경험도 있고 손발이 오글거리는 표현도 많이 있지만 그게 나의 솔직한 이야기이니 너그러이 이해해 주기를 바란다. 참고로 나는 구글에 입사하여 150회 정도의 엔지니어 후보자를 면접했고 채용위원회에서도 활동했다.

도전 - 구글 면접 자체로 배울 것이 있다

내가 구글에 입사하기 위해 도전할 때를 추억해보면 면접후의 나는 면접 보기전의 나와 다른 사람이었다. 면접 과정에서 한계에 부딪혔고 그 한계 너머의 세상을 경험했고 컴퓨터 공학 문제를 푸는 방법에는 더 높은 단계가 있다는 것을 깨달았다. 면접이 끝나고 나서 세상을 향해 자신감이 붙었다고 할까.

내가 구글에 지원할 때 합격하리라는 믿음은 없었다. 지방국립대를 (정말로) 간신히 졸업하고 대기업 근처에도 가보지 못해 이력서에 눈에 띄는 내용이 없었기 때문이었다. 한국에 구글 R&D센터가 들어오기 전이라 면접을 영어로 볼텐데 그럴 실력도 없었다. 영어점수가 없어 대기업 근처에도 못 갔고. 오히려 불가능해 보였기 때문에 도전을 했다. 반지하 월세방에서 어린 아이들 셋을 두고 구글에 면접을 보려고 회사에는 퇴사를 알렸다. 그러니 형편으로 봐도 무모한 도전이었다.

구글 면접을 어떻게 준비해야 하는지도 모른채 도전을 했고 레쥬메를 내고 합격통지를 받기까지 4개월동안 최선을 다했다. 마지막 면접을 보고 지하철 역으로 향하며 아내에게 전화를 걸었다. “이제 다 끝났어. 난 이제 떨어져도 아쉬운게 없어.” 정말 한 단계 성장했다는 느낌을 받았다. 하루종일 긴장하고 면접을 치러서 어지러웠지만 세상 어디에 떨어져도 다 먹어치울 수 있을 것 같은 느낌이 들었다.

소프트웨어 엔지니어라면 구글에 도전해 보기를 권한다. 떨어지더라도 짧은 시간에 많은 것을 배울 수 있는 기회다. 구글 면접에서 세 번이나 떨어진 어떤 사람은 구글의 면접은 현대의 소크라테스에게 가르침을 받는 시간이라고 말한다.

전화 인터뷰 팁 - 자신에게 가장 유리한 시간대로 고른다

일반적으로 본면접을 보기전에 전화로 기술 면접을 치른다. 전화상으로 45분 정도 기술 면접을 보는데 대면 면접과 비슷한 수준의 문제를 푼다. 전화를 들고 구글 닥스Google Docs에다가 코딩도 시킨다. 얼굴도 보지 않고 전화로 기술면접을 보는 것은 상당한 부담이다. 그리고 영어다. 따라서 전화 인터뷰 전에 준비를 잘 하는 것이 중요하다.

준비의 첫번째는 면접 시간이다. 면접시간을 조정하는 리쿠르터에게 자기가 원하는 시간을 정확히 알려주자. 하루 중 컨디션이 최상이 되는 시간대 그리고 다른 일 때문에 방해를 받지 않는 시간대를 골라야 한다. 구글의 면접관과 채용담당자가 지구 반대편에 살고 있을 수도 있어서 실수로 면접 시간이 면접 후보자에게는 새벽이 되는 경우도 있다. 바꿔줄 것을 반드시 요구해야 한다. 면접 과정은 후보자의 최상을 보려는 것이기 때문이다.

전화 인터뷰 팁 - 준비를 하면 좋은 것들

전화는 스피커 폰 기능이 동작하는 지 확인하자. 헤드셋이 있으면 편하다. 적어도 1시간 동안은 방해받지 않도록 준비하는 것이 좋겠다. 면접 중에 전화가 끊기거나 누가 방해를 하면 곤란하니까.

연습장과 연필을 준비하자. 종종 종이에 계산을 하거나 메모를 할 일이 있다. 면접관의 이름을 메모하기도 한다. 가령 면접관이 처음 소개할 때 밝혔던 부서를 메모해 두었다가 나중에 관련된 질문을 할 수도 있겠다. 예를 들어, 검색팀에 계시다고 했는데 요즘 가장 어려운 문제는 무엇인가를 물어볼 수도 있다.

인터넷과 구글닥스가 잘 동작하는지 확인하자. 코딩을 구글 닥스에 시킨다. 인터넷 브라우저도 확인해 두는 것이 좋다. 면접 시간이 되기 전에 리쿠르터가 구글 닥스 링크를 보내준다. 면접 시간에 면접관도 해당 구글 닥스 문서에서 함께 작업을 진행한다.

문제 유형과 요령

코딩, 알고리듬, 시스템 설계 등을 주로 물어본다. 박사 졸업자의 경우는 졸업 논문에 대해서 묻기도 한다. 대체로 실제로 현업에서 발생하는 내용을 토대로 물어본다.

코딩은 보통 15분에서 20분 사이에 풀 수 있는 간단한 문제들이 많다. 구글 면접 문제로 잘 알려진 atoi함수 구현이나 문자열 뒤집기 등의 문제는 쉬운편이다. 물론 이런 잘 알려진 문제는 더 이상 묻지 않는다. 쉬운 코딩 문제를 내지만 대부분의 후보자들은 통과하지 못한다. 코딩은 누구나 하지만 제대로 코드를 작성하는 것은 쉽지 않다. 더욱이 인터넷도 없고 비주얼 스튜디오도 없이 칠판에 코드를 짜는 것이 상당히 부담스럽다. 평소에 칠판이나 종이에 연습을 많이 해두어야 한다.

코딩 문제가 나올때 바로 구현으로 들어가는 것은 좋지 않다. 먼저 요구사항을 제대로 밝히는 것이 중요하다. 나는 일부러 중요한 사항을 빠뜨리고 문제를 내기도 한다. 예를 들어, 입력 데이터의 타입이나 중요한 예외 케이스corner case등을 일부러 누락한다. 바로 구현으로 들어가면 반드시 나중에 문제가 생긴다. 요구사항을 점검하고 간단하게라도 어떤 식으로 구현할지 설명하는 것이 좋다. 그렇다고 여기에 너무 많은 시간을 쏟지는 말고.

구현이 끝나면 반드시 검증을 하자. 요구사항 분석시 사용한 예제나 예외 케이스를 가지고 코드를 한줄 한줄 진행하면서 논리적으로 잘못된 부분이나 문법의 오류를 스스로 찾도록 한다. 평소에 엔지니어들은 코드의 작성보다는 버그를 수정하고 코드를 향상시키는 데에 더 많은 시간과 노력을 쏟는다. 따라서, 면접과정에서도 스스로 버그를 찾고 코드를 향상시키는 노력을 보여주는 것이 좋을 것이다.

정리하면 (1) 요구사항 분석 -> (2) 구현 -> (3) 검증 및 향상의 3단계를 거치는 것이 좋겠다.

알고리듬은 주어진 컴퓨터공학 문제를 어떻게 풀지 물어본다. 주로 많은 데이터에서 주어진 값을 찾는 가장 빠른 방법을 물어본다. 처음에 간단하게 시작해서 데이터의 규모가 커진다거나 컴퓨터 시스템의 한계를 설정하는 방식으로 심화하기도 한다. 알고리듬 문제에서 중요한 것은 다양한 접근 방식의 장단점을 구체적으로 얘기할 수 있어야 한다. 예를 들어, 문제의 조건에 따라 퀵 정렬보다 병합 정렬이 더 효과적이라고 말할 수도 있는데 이때 왜 그런지 설명하는 것이 좋다. 입력 데이터가 메모리의 용량보다 커서 랜덤 액세스가 필요한 퀵 정렬이 비효율적이라든지 말이다. 계산 복잡도와 공간 복잡도를 공학적 표기법(대문자 O 표기법 등)으로 설명하는 것도 있지 말자. 알고리듬 문제에서 코딩 문제로 발전하기도 하니 미리 코딩 연습을 하는 것이 도움이 될 것이다.

시스템 설계에서는 구글에서 제공하는 서비스를 설계해 보라고 하기도 하고 상상의 제품을 만들어 보라고도 한다. 구글에서 하는 대부분의 작업은 모두 병렬처리 또는 분산 시스템에 대한 것이다. 따라서 분산 시스템에 대해서 공부해 두면 도움이 될 것이다. 구글 검색의 성공을 뒷받침했던 구글 파일 시스템GFS과 맵리듀스MapReduce에 대한 논문을 한번쯤 읽어보는 것도 좋겠다.

구글 파일 시스템에 대한 논문:
http://research.google.com/archive/gfs.html

대규모 병렬 처리 프레임워크 맵리듀스에 대한 논문:
http://research.google.com/archive/mapreduce.html

면접관들의 문제 출제 유형

면접관들의 면접유형에는 크게 두가지가 있다. 가능한 넓은 영역을 두드려서 후보자의 컴퓨터 공학 지식과 경험을 전반적으로 평가하는 진단 평가 유형과 좀 더 복잡한 공학 문제를 물어서 후보자의 지식과 경험을 깊이 평가하는 심화 평가 유형이다. 면접관들의 성향에 달려있기는 하지만 시스템 관리자, 웹마스터 등은 진단 평가를 사용하고 소프트웨어 엔지니어는 심화 평가 유형을 주로 사용한다. 때로는 한 면접 세션에서 진단 평가와 심화 평가가 동시에 이루어지기도 한다.

심화 평가라면 한 세션에 보통 두 문제 정도를 푼다. 45분 면접의 시작시 소개와 종료직전의 자유질문 시간을 빼면 한 문제당 15분에서 20분 정도를 사용한다고 생각하자. 이걸 반대로 생각하면 문제가 아무리 어려워 보여도 15분내에 풀 수 있는 간단한 문제이니 지레 겁먹지 않아도 된다는 얘기다. 물론 어려운 문제는 한 세션에서 한 문제만 푸는 경우도 있다.  

단순 지식을 묻는 문제가 아닌데 3문제까지 왔다면 둘 중 하나다. 평균을 크게 웃도는 실력을 가진 후보이거나 가망이 별로 없는 후보다. 나는 보통 처음에 쉬운 문제를 낸다. 몸풀기 문제인 것이다. 몸풀기를 마치면 본격적으로 어려운 문제를 낸다. 어려운 문제를 잘 푸는 경우 더 어려운 문제로 옮겨간다. 드문 실력자다. 개중에는 첫 번째 문제에서 헤매는 사람이 있다. 이때는 더 쉬운 문제를 내거나 분야를 바꿔서 문제를 낸다. 후보자의 가능성을 찾는 것이다. 하지만 대개 가망이 별로 없다.

때로는 처음부터 어려운 문제로 몰아치는 경우도 있다. 레쥬메를 읽을때 또는 면접 초기에 감이 오는 경우다. 이 친구 정말 실력자라는 느낌이 오면 어려운 문제를 내면서 후보자의 약점을 찾으려고 한다. 이렇게 하는 이유는 수준 높은 후보자를 그 수준에 맞는 잣대로 평가하려는 것도 있지만 면접관이 혹시 가질 수 있는 선입견을 스스로 견제하기 위해서다.

문제 풀이 과정이 중요하다

기술 면접에서 중요한 것은 정답을 만들어내는 것이 아니라 문제를 해결하는 방식이다. 실세계의 공학문제는 정답이 없는 경우가 많다. 실세계 시스템은 복잡하고 요구사항이 상충하기 때문이다. 따라서, 항상 상충점trade-off을 고민하는 것이 공학이다.

아폴로 착륙선의 다리를 설계할 때도 상충점에 대한 고민을 했다고 한다. 다리를 세개로 하면 무게를 줄일 수 있지만 안전하지 않았고 다섯개로 하면 가장 안전하지만 너무 무거워졌기 때문에 다리를 네개로 정했다고 한다. 이걸 비공학도들에게 얘기하면 당연히 다리 네개가 제일 좋은 것 아니냐고 핀잔을 듣는다. 하지만 공학도들은 사람들이 당연하게 생각하는 문제의 원리를 풀어내야 한다. 

컴퓨터공학도 마찬가지다. 혹 틀린 답을 도출할지라도 답이 나오는 과정에서 요구사항의 우선순위가 무엇이었는지, 가능한 옵션들은 어떤 것들이 있었는지, 어떤 상충점을 고려했는지, 결과를 어떻게 검증할 수 있는지 얘기할 수 있어야 한다. 문제 풀이 과정과 검증 방법을 아는 사람이 문제를 정말로 풀 수 있는 사람이다. 결국 문제풀이 과정이 정답보다 중요하다.

따라서, 기술 면접에서 문제 풀이 과정을 보여주는 것이 중요하다. 

반복iteration과 대화interaction다

문제를 풀 때 쉬운 풀이 방법으로부터 차근차근 반복하면서 향상시키는 것이 좋다. 코드를 작성하는 경우라면 알고리듬은 비효율적이지만 구현하기 쉬운 방법으로 빨리 코드를 완성하고 개선해 나가는 것이 좋다. 아무리 좋은 알고리듬을 썼더라도 코드를 완성하지 못했다면 인정을 받기는 힘들다. 많은 후보자들이 최적의 구현방법을 고민하는 데 시간을 너무 많이 쓰고 정작 코드를 완성하지 못한다.

머리로 생각하는 것과 실제로 구현하는 것에는 간극이 있다. 이 간극은 실제로 코드를 쓸 때 드러난다. 따라서 우아하지(?) 않더라도 동작하는 코드를 작성하고 문제를 발견한 다음에 반복적으로 향상하는 것이 전략이다. 물론, 초절정 고수는 일필휘지로 단방에 최고의 코드를 써내리는 경우도 있지만...

면접관과 대화를 하면서 문제를 푸는 것도 중요하다. 면접관을 동료라고 생각하고 문제풀이를 짝 프로그래밍pair programming으로 생각하자. 면접관의 질문을 확인하고 부족한 부분을 점검하고 코드를 어떻게 작성할지 대강의 플로우flow를 얘기하자. 코드를 작성하면서 본인이 어떻게 생각하고 있는지 말로 표현하면서 써내려 가는 것이 좋다. 때로 잘 못된 방향으로 가는 경우 면접관이 가이드를 해 줄 수도 있다.

통역관을 요청할 수 있다

영어에 정말 자신이 없으면 통역관을 요청할 수 있다. 보통은 엔지니어가 통역을 한다. 컴퓨터공학 용어나 기술 설명은 비엔지니어가 통역하기는 힘들기 때문에.

참고로 나는 영어를 잘 못했지만 일부러 통역없이 면접을 봤다. 비엔지니어가 통역을 하리라고 생각했고(당시에는 실제로도 그랬다) 대면 면접에서 부족하더라도 중간에 끼는 사람 없이 정면으로 부딪히겠다는 각오를 했기 때문이다. 결과를 놓고 보면 나는 이런 배포 때문에 득을 보았다. 하지만 다른 사람에게 적용되는 방식은 아니라고 본다.

엔지니어는 영어 능력 테스트가 아니니 자신이 없으면 통역관을 요청하자.

면접관들이 잘 묻지 않는 질문

“앞으로 10년후 자신에 대해서 이야기보세요.”나 “구글에서 어떤 일을 하고 싶으세요?” 같은 질문은 잘 하지 않는다. 후보자들은 열이면 열명 모두 알흠다운 답변을 한다. 이런 질문을 통해 후보자의 진면목을 알 수도 없고 변별력도 없다는 뜻이다. 혹시 이런 질문이 나오면 그건 분위기 조성용이라고 보자.

엔지니어 면접에서 미국에 주유소가 몇개 있느니 골프공의 홈은 몇개 있으니 같은 질문은 묻지 않는다. 이런 질문은 전문 용어(?)로 돈오 질문Aha questions이다. 번뜩하는 재치를 평가할 수는 있겠지만 좋은 엔지니어인지를 드러내는 평가로 보기는 힘들다. 좋은 엔지니어는 오랜 시간 점진적인 노력을 통해 만들어진다. 돈오보다는 점수의 질문이 좋다.

연락이 오지 않으면 적극적으로 문의하자

구글의 채용 시스템은 완벽하지 않다. 전세계에서 일주일에 수만명의 후보가 지원하기 때문에 간혹 채용절차의 중간에서 누락되거나 실수로 문제가 발생하는 경우가 종종 있다. 지원하는 사람은 리쿠르터 한 사람과 1:1로 연락한다고 생각하지만 리쿠르터는 엄청난 숫자의 후보자를 다룬다.

이런 경우도 있었다. 내가 추천했던 어떤 후보자는 처음 지원했을 때 쓰던 이메일 주소가 아닌 다른 이메일 주소로 리쿠르터에게 연락을 취했다가 응답을 받지 못하고 단단히 화를 낸 적이 있다. 그는 그의 이름과 내용으로 해당 리쿠르터가 충분히 응대를 하기를 기대했던 것이다. 그런데 리쿠르터의 시스템은 이메일 주소를 기준으로 관리가 되었기 때문에 확인이 어려웠던 것이다. 이건 드문 경우인데 이외에도 중간에 문제가 발생할 수가 있다.

궁금하거나 문제가 있을 때 무한정 기다리지 말고 적극적으로 물어보자. 물어보는 것은 흠이 아니다.   

면접관들이 싫어하는 말

@ 나를 뭘로 보고 코딩을 시키나요? 코딩에서 손 뗀지 오래되었어요.

소프트웨어 엔지니어로 지원하는 경력자가 이런 얘기를 하는 경우가 있다. 자신은 소프트웨어 아키텍트로 코더들을 관리하는 역할을 오래 해왔다면서. 이런 말이 엔지니어인 나의 자존심을 건드린다. 코딩을 하급 노동이나 잡일로 취급한다는 인상을 받기 때문이다. 그렇다면 소프트웨어 엔지니어 직책에는 어울리지 않다. 더 나아가 소프트웨어 기업에서 일하기에는 부적합하다고 생각한다.

작가가 글쓰기를 잡일로 보고 연설가를 말하는 것을 잡일로 보고 육상선수가 달리기를 잡일로 볼까. 소프트웨어 제품을 움직이는 것은 소프트웨어 코드다. 기획도 중요하고 설계도 중요하다. 그러나 제대로된 코딩없이는 죽은 자식 불알 만지기일 뿐. 

@ 구글 제품들은 최고입니다.

고마운 얘기다. 그런데 면접관들은 구글 제품의 문제점에 대해 더 관심이 있다. 구글이 나아가는 방향이 어떻게 잘못되었는지 논리적으로 설득할 수 있는 사람에게 관심이 있다. 앞 문장에서 논리라는 단어에 밑줄을 긋자.

가끔 면접관들이 혹시 구글 제품의 문제점에 대해서 묻는다면 지적할 내용에 대해서 미리 생각해두는 것도 좋겠다. 

@ 학교에서 배우지 않은 내용입니다.

차라리 그냥 모른다고 얘기하는 것이 나을 것이다. 학교 망신은 주지 않을테니까. 기술 면접에서 물어보는 내용은 소프트웨어 엔지니어의 기본 소양이라고 본다. 배우지 않아서 모르겠습니다라는 말은 실제로 그럴지라도 가슴에만 담아두자.

@ 제가 인터뷰 잘 보았나요?

물어봐도 면접관들이 말해주기는 힘들다. 

땡큐 인사를 따로 보낼 필요는 없다

가끔 면접관의 이메일 주소를 알려달라는 경우가 있다. 나중에 땡큐 인사를 보내기 위해서. 솔직히 나는 별로다. 나는 면접관으로서 합격과 불합격을 좌우할 수 있다. 이건 후보자에게는 생사여탈로 비춰질 수 있기 때문에 상당한 부담이다. 후보자에게 내 연락처를 준다는 것, 그리고 땡큐 인사를 받는다는 것은 객관적 결과에 혹시 영향이 있을 수 있으므로 달갑지 않다.

땡큐 메일은 가능한 한 보지 않으려고 한다. 나도 사람인지라 다른 후보자들과 공평하게 평가해야 하는 순간에 흔들릴 수 있기 때문이다.

자기 소개는 짧게

자기소개에 에너지를 쏟지 말자. 면접관들은 후보자의 레쥬메를 읽고 들어온다. 후보자의 자기소개가 크게 필요하지 않다. 진짜 궁금하면 구체적인 사항을 물어본다. 3문장 정도로 요약하여 나는 현재 무슨일을 하고 주로 어떤 분야에서 일을 했는지 이야기하면 된다. 자랑할 만한 것이 있으면 키워드와 숫자로 주의를 끌도록 한다. 예를 들어, 나는 1970년대에 데니스 리치와 함께 유닉스를 만든 켄 톰슨입니다. 팍. 끝.

마지막 팁

내가 구글에 지원했을 때 이런걸 알려주는 사람이 주위에 없었다. 레쥬메를 어떻게 쓰는지도 몰랐으니까. 막막하게 준비하던 그때의 답답함을 나는 잘 안다. 그래서 이 글을 적었다.

나의 마지막 인터뷰 팁은, 팁은 팁일뿐 규칙이 아니라는 것이다. 조금씩 세상을 알게 될수록 세상이 교과서대로 움직이는 것이 아니라는 것을 깨닫는다. 나는 오랜 시간 경험했던 것을 바탕으로 조언을 하지만 여러분이 부딪힐 세상은 내가 경험한 세상과는 다르다. 내가 틀릴 수 있다.

나는 자기소개는 짧게 하라고 조언했지만 내가 구글에 지원할 때는 자기소개를 정말 열심히 준비했다. 파워포인트의 품질이 맘에 들지 않아 생전 처음 맥북을 구입해서 애플 키노트 프로그램으로 자기소개 프리젠테이션 자료를 만들었다. 친한 직장 동료에게 돈까스를 사며 식당에서 영어로 자기소개 프리젠테이션도 했다. 그러나 실제 면접에서는 자기소개를 할 시간이 주어지지 않았다. 그런데 외국에서 온 한 면접관이 서울의 교통체증 때문에 면접시간에 빠듯하게 도착했다. 미리 내 레주메를 확인하지 못해 당황해하는 것을 눈치채고 인터뷰 시간에서 딱 5분만 주면 내 소개를 하겠다고 했다. 나는 내 인생 최고의 프로젝트 3가지에 대해 이야기했다. 각 프로젝트마다 무슨 프로젝트였으며 문제점이 무엇이었으며 어떻게 해결했는지 3단계로 적었다. 마지막에 진짜 최고의 프로젝트는 가족이라며 세 아이와 아내를 팔았다. 3+1. 팍. 끝.

5분의 자기소개가 내 입사에 어떤 영향을 미쳤는지 지금도 알지 못한다. 그렇지만 결론은 구글에 입사했다. 내가 강조하고 싶은 것은 다른 사람들의 조언을 완전히 무시해야 할 때도 있다는 것이다. 세상은 교과서대로 움직이지 않고 내 조언도 그저 조언일뿐 당신이 경험할 세상은 나도 잘 모르기 때문이다. 그 배의 선장은 당신이다. (아... 오그라든다.)

면접관으로서 새로운 것을 배우게 되는 면접이 있다. 면접관을 한단계 성숙하게 만드는 후보자가 있다. 문제는 면접관이 내지만 후보자가 동료로서 문제풀이 여행을 함께 떠나는 면접이 있다. 나는 면접관으로서 이런 면접을 기다린다.

구글 인터뷰 팁은 이 정도다. 

병렬 컴퓨팅의 대가 진 암달 별세

진 암달Gene Amdahl(관련 기사)이 별세했다.

암달의 법칙으로 유명한 진 암달은 "옆동네" 사람이다. 나는 진 암달이 좀 더 가깝게 느껴진다. 내가 병렬 컴퓨팅 분야에서 일하기 때문이라기보단 내가 다니는 교회당과 관련이 있기 때문에.

우리 교회(이민 한인 교회)가 세들어 있는 교회당이 임마누엘 루터교회다. 진 암달이 바로 이 교회 회원이었다. 듣기로는 진 암달의 지원으로 교회당이 지어졌다고 한다. 동네 교회지만 정말 아름다운 교회다.

임마누엘 루터교회 예배당 전경

예배당 안에서 밖을 본 모습

가끔 예배당을 보면서 진 암달을 떠올릴 것 같다. 혹시 궁금하신 분들을 위해 주소는 다음과 같다.

Immanuel Lutheran Church
14103 Saratoga Ave, Saratoga, CA 95070

평소에는 문이 잠겨있어서 예배당을 보지는 못한다. 한인들이 예배하는 일요일 오후 1시쯤 오면 내부를 구경할 수 있다.

식인문화의 수수께끼

대학시절, (서고가 있는) 도서관에서 죽치고 아무 책이나 손에 잡히는 대로 읽은 적이 있다. 그때 읽었던 책 중에 가장 기억에 남는게 한스  아스케나시Hans Askenasy의 "식인문화의 수수께끼"(원서는 Cannibalism: From Sacrifice to Survival)였다. 별로 유명한 책은 아니다.

저자는 인간의 역사와 문화에 깊이 새겨진 식인에 대한 이야기를 다양한 자료를 인용하며 풀어냈다. 읽기 거북한 이야기들이 정말 많았지만 마지막 페이지를 넘기면서 평생에 남을 충격을 받았다. 식인 이야기 자체도 충격이었다. 그런데, 인간이 '나' 그리고 '우리'밖에 있는 사람들을 괴물(식인종)로 규정하고 책임을 전가하기 위해 끊임없이 식인이라는 주제에 집착한다는 이야기는 대학을 졸업하고 사회생활을 하면서도 되새김질하게 되는 부분이다.

(정치든 종교든 회사든 인종이든)다른 사람을 괴물로 규정하는 순간 내가 괴물이 될 수 있다는 생각이 내 의식의 뒷편에서 끊임없이 나를 불편하게 만든다.

저자 한스 아스케나시는 유대인으로 나치 홀로코스트 생존자다. 또 다른 저서 "Are We All Nazis?"(우리말 번역본은 아직 없나보다)에서 다음과 같은 이야기를 했다.

"우리는 보통 엽기적인 사건의 범죄자들을 보며 짐승같다는 표현을 쓴다. 마치 그런 행동들이 우리 인간보다 하등한 동물들의 특징인것처럼 말이다. 그런데 실상은 극단적인 엽기스러움은 인간에게만 보인다. 이 정도로 서로에게 야만적으로 행동하는 모습은 자연에서는 전혀 찾아볼 수 없다. 틀림없는 진실 하나는 인간이야말로 지구상에 존재했던 그 어떤 생명체보다 독하고 잔인한 종이라는 것이다."
“We generally describe the most repulsive examples of man's cruelty as brutal or bestial, implying that such behavior is characteristic of less highly developed animals than ourselves. In fact, however, the extremes of brutal behavior are confined to us: there exists no parallel in nature to our savage treatment of each other. The unmistakable truth is that man is the most vicious and cruel species that ever walked the earth.”
- Hans Askenasy, Are We All Nazis?

무서운 이야기

애들 재울때 이야기를 해주거나 노래를 불러주곤 한다. 할로윈을 맞아 (평소 겁이 많은) 막내에게 무서운 이야기를 하기로 했다. 실제로는 영어로 해줬는데 한국어로 옮긴다.

"괴물이 한 아이(막내의 눈을 똑바로 쳐다보며. 바로 너야라고 얘기하듯이)를 찾아왔어. 괴물이 아이에게 말했어. 네가 나보다 작으면 잡아먹고 나보다 크면 살려주겠다. 그리고 키를 쟀어. 어떻게 되었을까?

아이는 괴물보다 작지 않았어. 크지도 않았어. 괴물은 아이와 키가 똑 같았어. 어떻게 되었을까?

아이는 괴물을 먹어치우기 시작했어. 다 먹어치우고 괴물의 얼굴만 남았어. 그리고 괴물의 얼굴을 들여다봤어. 괴물은 그 아이의 얼굴을 갖고 있었어. 괴물이 그 아이였던거야."

막내의 눈이 동그래졌다. 옆에서 엿듣던 중학생 첫째는 "아빠, 이거 좀 무서운데요...".

그냥 끝내면 잠을 못잘 것 같아서 조금 설명을 해줬다. "There are no monsters. No ghosts. They are all your creations. You yourself create monsters and ghosts. If you are scared of them. You are scared of yourself. They live in your imagination. Eat them."


즉석에서 만들어낸 이야기였지만, 이런 비슷한 이야기를 어디에서인가 들어본적이 있는것 같다. 정확히 어느 이야기였는지 집어내진 못하겠다. 간단한 이야기지만 생각해볼 것이 많이 있다. 우리 아이들이 내 나이가 되면, 오늘 이야기하지 못한 숨은 배경에 대해서 이해하게 될까? 아마 오늘 이런 이야기를 했다는 것조차 기억하지 못하겠지.

쓸데없는 오늘의 영어 - ad hominem

인신공격의. (논쟁에 있어서) 상대 주장의 내용이 아니라 상대방의 성격 등을 공격하는 행위.

ad hominem은 라틴어로 to the man 또는 to the person을 뜻한다. 보통 시사 게시판에서 논란이 큰 주제를 다루거나 논쟁이 겪해지면 인신공격으로 보일만한 대화가 시작된다. 이때 It's an ad hominem attack.이라면서 한번 꺽어줄 필요가 있다.

비슷한 단어로 ad feminam이 있다. 'femi'는 female을 가르키며 '여성'이라는 점을 부각시키며 상대방의 논리를 공격할 때 쓴다.

다음은 인터넷에서 찾은 ad hominem 예제다. ^^;
"That's not an ad hominem attack. You idiot."