좋은 코드

예전에 어떤 버그하나를 추적하고 있었다. 문제를 이해하려고 관련된 코드를 쭉 읽어내려가다보니 어느순간 짜증이 솟구쳐 올랐다. <이거는 어떤 자식이 코드를 짰길래 이딴식이야!> 하며 git 히스토리를 열어보니… 그건 몇년전 나였다. 아마도 릴리즈가 급한 나머지 코드의 퀄리티에 신경 안쓰고 일단 돌아가는것에 집중했던 시기였던것 같다. 같은 코드를 오랫동안 만지는 여러 개발자들이 비슷한 경험을 하지 않았을까?

대부분의 사람들은 동작하는 코드를 만들수 있다. 어떤 사람들은 <빠르게> 동작하는 코드를 만들수 있다. 그보다 적은 수의 사람들은 <이해할수 있는> 코드를 만든다. 소프트웨어 회사의 매출은 동작하는 프로그램에서 나오지만, 회사의 진짜 자산은 (커피만 마시고) 코드를 만들어낼수 있는 프로그래머와 그 사람들이 수년간 만들어낸 지식의 총체인 방대한 코드베이스다. 예를들어 2015년 기준 구글의 코드베이스는 20억 라인이라고 한다. 단기간의 성공을 위해 우선 동작하는 프로그램을 만들수는 있지만 SW조직의 수명은 코드의 퀄리티에서 결정된다. 코드를 만들때는 각자 자기의 성을 짓는것과 같다. 그런데 몇년후 자신이 만든 성에 들어가서도 우리는 길을 잃는다. 현실에서 회사는 남이 만든 초가집을 성이라 우기며 아름다운 탑을 몇개 더 붙이라고 요구한다.

“Programs must be written for people to read, and only incidentally for machines to execute.”
“코드는 남들에게 읽히는게 목적이지만, 종종 컴퓨터가 실행하기도 한다”

예전엔 코드가 화려할수록, 복잡해 보일수록 뛰어난 것이라 생각했다. 그런데 이전 블로그에서 설명한대로 프로그래머의 자존심으로 채워진 화려한 코드는 스타트업 하나쯤은 쉽게 무너뜨릴수 있다. 수년간 더 여러 팀에서 일하고 난 지금은 좋은 코드를 이렇게 정의한다.

<당연하게 읽히는 코드>

이전 회사에서 테크 리드로 있으면서 많은 코드를 리뷰했다. 팀원은 이제 갓 대학을 졸업한 어린이(?)부터 20년 경력의 백전노장까지 다양하게 구성되어 있었는데, 그 중 J는 특히 코드 퀄리티에 관심이 많았다. 경험도 많고 듣기로는 인터뷰를 퍼펙트로 통과했을정도로 스마트한 친구였다. 이 친구가 짠 코드를 읽으면 <와우> 이런 감탄사는 나오지 않는다. 단지 코드의 처음부터 끝까지 논리의 흐름이 너무나 당연하게 읽힌다. 마치 J가 만든 성안에 처음 들어가 구석구석 살펴 보는동안 그가 옆에서 친절하게 길을 안내해주는 느낌이다. 그런데 <당연하게 보이는 코드>를 만드는게 사실은 가장 어려운 것이다. J는 스스로 길을 안내하는 코드를 만들기 위해 속도를 희생했다. 그는 어떤때는 좀 답답하게 느껴질정도로 코드를 천천히 만들었다. 어떤때는 괜찮아 보이는 코드들도 처음부터 다시 하겠다고했다. 그렇게 나온 코드는 너무나 당연히 읽히기에 쉽게 이해할수 있었고 고칠 부분이 거의 없었다. 당연히 버그도 나오지 않았다.

이와 반대로 이제 막 학교를 졸업한 어린이(?) 엔지니어들의 코드는 읽으면서 감탄사가 나온다. 여과해 <아 이딴식으로도 생각을 하는구나> 이 정도로 표현해야겠다. 그 코드는 분명히 목적대로 정확하게 동작한다. 유닛 테스트도 충실하게 채워서 논리의 부분 부분을 모두 커버한다. 그런데 아무리 읽어도 당연하지가 않다. 이상하다. 코드가 자신의 논리 흐름을 스스로 설명하지 못한다. 비유하자면 조그만 초가집에 리뷰하러 들어갔는데 그게 미로같은 동굴의 초입이었던거다. 거기에 더해 주니어는 승진 욕심에 코드를 시니어보다 더 빠른 속도로 만들어낸다. 몇년전 여름에 잠깐 일했던 인턴은 열성이 넘쳤다. 아마도 짧은 인턴쉽 기간동안 어떻게든 강한 인상을 남기고 싶었을것이다. 그래서 그 인턴은 석달 내내 코드를 만들어대며 리뷰를 요청했다. 계속 만들어내는 그 이상한 코드를 몇시간씩 리뷰하다가 이런 생각이 들었다.

147255590836907.jpg
(물론 이렇게 얘기하지 않았다)

그런데 <당연하게 읽히는> 에서 당연하다는 것이 몹시 주관적이다. 내게 당연한것이 다른 사람에겐 이상할수 있다. 하지만 경험상 어느정도 퀄리티를 갖춘 시니어로 구성된 팀이라면 한 시니어에게 당연해 보이는 코드는 다른 대부분 시니어에게도 자연스럽다. 주니어의 눈으로 보기에 자기들끼리 밀어주고 당겨주고 하는것처럼 보일수도있다. 하지만 그런것이 아니다. 코드의 퀄리티를 높이는 요소는 객관적으로 정의내리기 어렵지만, 경험자 사이에서 수렴되는 <보면> 알수있는 퀄리티의 요소가 있다. 평점 9점의 영화가 왜 훌륭한지 이유는 관객마다 조금씩 다를수 있다. 그런데 모든 사람들이 <아 좋았어> 라고 공감하는 퀄리티가 있는것이다.

가장 중요한 퀄리티는 <추상화> (Abstraction) 이다. 추상화의 가장 큰 오해중 하나는 <추상화 그림>처럼 현실을 모호하게 표현하는 것이라 생각하는것이다. 추상화의 본질은 감출것은 감추고, 드러낼것은 드러내는 것이다. 좋은 코드는 읽는 사람에게 가장 적절한 추상화의 단계 (level of abstraction)를 선사한다. Class, Function, Variable의 이름과 관계를 통해서 리뷰어가 읽으며 예측하고있는 단계의 추상화를 바로 그 순간 보여주는것이다. 성으로 들어가는 리뷰어가 문같은 형태를 찾고있는데 문의 열쇠를 보여주는 것은 리뷰어를 혼란스럽게 만들뿐이다. 좋은 추상화는 리뷰어가 문 앞에 다가간 그 순간에 문의 열쇠를 보여주는것이다. 성의 문을 하나 하나 열때마다 그 레벨에서 예측가능하고 익숙한 컨셉으로 논리의 방을 설명하는것이다. 추상화의 각 레벨에서 모두에게 <익숙한 컨셉>으로 설명하기 위해서는 많은 코드를 읽는것이 필요하다. 비슷한 유형의 문제에 대해 사람들이 공통적으로 동의하는 코드의 패턴이있기 때문이다. 나는 코미디언 <코난 오브라이언>을 좋아하는데 그의 팟캐스트를 듣다보면 항상 킥킥대던 그가 종종 진지한 주제로 대화할때가 있다. 그건 다른 코미디언이 호스트로 나오는 에피소드들이다. 코난과 다른 코미디언은 서로 뛰어난 코미디의 요소에 대해 진지하게 질문하고 탐색한다. 시대를 앞서간 코미디언들의 <익숙한> 패턴을 알고 싶어서 얼마나 연구했는지 서로 나누는 그 에피소드를 들으며 <직업>이 무엇인지 새삼 생각하게된다. 프로그래머가 새로운 것을 모두에게 익숙하게 설명하는 그 <당연함>의 이면에는 많은 시간 읽어내려간 방대한 코드의 양이 있다.

단계적 추상화를 마스터한 경험자와 초보의 가장 큰 차이는 논리의 흐름을 What 과 How로 설명하는 차이다. 좋은 코드는 추상화의 단계가 깊어질때마다 <이것은 무엇(What)입니다> 를 반복하고 주니어의 코드는 <이것은 어떻게(How) 돌아갑니다>를 반복한다. 주니어의 코드를 리뷰할때면 <이것은 귀가 쫑긋합니다> <이것은 짖습니다> <이것은 귀엽습니다> 와 같은식으로 여러개의 <How>를 붙여 무언가를 설명한다. 그럼 나는 <이거 개야?> 묻고 주니어는 그제서야 <아 개네!> 깨닫는다. 처음부터 대상이 개라고 설명했다면 나는 개의 동작과 특성에 익숙하므로 노력없이 논리를 이해했을것이다 (최악의 경우는 저렇게 설명해놓고 고양이라고 우기는 상황이다). 표현하고자 하는 논리를 모두에게 익숙한 컨셉 (What)들 사이의 관계로 설명하는것은 OOP에 좀 더 가깝다. 또한 논리를 <선언 (Declaration)>의 연속으로 표현하는 함수형 프로그램도 이에 가깝다. 그러나 <What>과 <How>중 무엇을 강조하는지는 OOP, 함수형 언어보다 코드를 만드는 사람의 경험과 내제된 퀄리티에 더 관계가 있다.

“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” – Linux Tovalds
“안좋은 프로그래머는 코드에 대해 걱정한다. 좋은 프로그래머는 데이터 구조와 관계에 대해 걱정한다” – 리누스 토발즈

끝으로 어느 팀이든 좋은 코드를 마스터한 시니어만으로 구성되지 않는다. 프로그래밍팀은 하나의 마을이다. 거기엔 아름답고 웅장하게 세워진 성도 있고 이제 첫 삽을 떠본 주니어가 만든 초가집도 있다. 시니어의 역할은 주니어의 초가집 엉성한 부분을 지적하는것에서 끝나지 않는다. 진짜 마스터는 계속해서 자기 성을 짓는 사람이다. 주니어가 지켜보며 영감 (inspiration)을 얻을만큼 계속해서 조금 더 아름다운 성을 만드는 사람이다. 주니어의 초라한 집에서 훗날 성이 될수 있는 재능을 발견해 용기를 주는 사람이다.

https://twitter.com/sm_park

코더

예전에 한 대기업 주재원분과 짧게 이야기 나눈적이 있었다. 내가 박사후에 계속 개발일 하고 있다고 했더니 <예? 코더요?> 하며 약간 그분 눈이 커진것을 놓치지 않았다. 도대체 코더가 어떻길래, 저 반응은 어떤 뉘앙스일까 살짝 마음에 걸렸다. 1년마다 다시 돌아오는 <잡스는 커녕!> 뉴스기사를 보고 그게 어떤 의미인지 조금 더 명확하게 다가왔다. (뉴스 기사)

기사의 도입부는 이렇다. “지난 6일 서울 관악구 서울대 공과대학에서 만난 하순회 컴퓨터공학부 학과장은 제 4차 산업혁명 시대에 고급 개발자 양성이 가장 중요한데도 현재는 부족한 개발자 인력을 채우기 급급해 ‘프로그래머’만 양성하고 있다고 진단했다. 여기서 하 학과장이 언급한 프로그래머란 단순 코더(Coder)에 가깝다. 고급 개발자가 프로그램 전반을 기획하는 설계자라면, 코더는 이를 실현하는 시공자에 해당한다.”

일단은 기사의 의도 자체가 <학교에 돈 좀 줘…제발> 인것은 기사에 쓰인 <공과대학 전경>이미지를 보면 알수있다 (골라도 저런 사진을…) 그렇다해도 코딩하는것을 천직으로 여기고 사는 나같은 사람은 이 기준으로 그럼 고급이냐 단순이냐 의문이 들수밖에 없다. 나뿐 아니라, 존경해 마지않는 <제프딘> <제임스고슬링> <크리스라트너>… 이 사람들은 분명히 고급일텐데 아직도 코딩을 하니, 이 비유대로라면 세계적인 건축 디자이너가 현장에서 공구리치고 있다는 얘기잖아?

문제는 소프트웨어를 <설계>한다고하니 자꾸 건축업계에서 메타포를 가져와 설명하려는데있다. 설계와 시공이 분리되어있고 고급진(?) 사무직과 현장직이 분리된 산업을 비유해 설명하니 자꾸 이 직업이 오해를 받는다. 내가 아는 뛰어난 개발자들은 모두 실제로 코딩한다. 처음 커리어를 시작할때도 그렇고 나이와 명성이 쌓인후에도 마찬가지다. 제프딘과 Sanjay의 협업에 대해 소개한 New Yorker 최근 기사는 구글의 탑레벨 임원인 그들이 매일 코딩한다는것을 잘 보여준다. 최근에 나는 회사를 옮기며 인터뷰를 했는데, 경력 10년에 어느정도 규모의 팀을 매니지했던 이전 역할과 상관없이 가혹한 코딩테스트를 거쳤다. 10년, 20년차의 경력만 내세우고 코딩을 소홀히 한 사람들은 <쏘리 쏘리> 연발하다 인터뷰를 마치기 십상이다.

그럼 프로그래머를 설명할 적당한 다른 직업은 없을까? 나는 개발자는 연예인에 좀 더 가깝다고 생각한다. 가수는 무대에서 노래를 불러야 가장 빛나듯이 개발자는 컴퓨터앞에서 코드와 싸울때가 가장 어울린다. 나이가 들어 무대뒤에 숨어서 후배들만 가르치려드는 가수보다는 계속 무대에 나와 조금 더 잘 하려고 애쓰는 사람을 아티스트라는 말로 표현한다. 아침마당에 나와 유연하게 허리 돌리는 사장님 박진영과 비의 퍼포먼스는 나이든 개발자가 지향해야 할 모델이다. 폴그레이엄은 에세이에서 개발자를 화가에 비유하기도 했다. 미술관의 주인공은 큐레이터가 아니고 아티스트인것을 잊지않았음한다.

기사에서는 고급개발자를 <양성>할수 있다고 주장했다. 개발자들 사이에서는 능력의 차이가 실제 크게 존재한다. 한때 10x 엔지니어라는 말이 유행했는데, 일반과 고급의 성능차이를 10배로 추정한다는 뜻이다. 나는 내 경험을 토대로 고급개발자의 조건을 세가지로 요약하려한다.

  1. 코딩이 뛰어나다면

코딩을 잘하는 사람은 많지 않다. 대충 경험상 네명중 한명정도 잘한다. 코딩은 엔지니어링 프로세스의 가장 중요한 한 부분이고, 좀더 넓게 표현하면 문제해결능력이 고급개발자의 조건에 가깝다. for-loop, if/else 등의 로직 연산으로 구성된 코딩은 사실 사람이 매일 수행하는 연산이다. 그래서 쉽게 보여 뛰어들수 있지만 일단 시작하면 죽을때가지 마스터할수 없는 수행의 길이다. 이 고난의 길에서 탁월한 기량을 보이는 사람은 두가지 정도로 나뉠수 있다. 첫째는 타고난 지능이다. 지금까지 학교졸업하고 막 직업전선에서 코딩을 시작한 여러명의 주니어들이 성장하는것을 지켜봤다. 그 과정에서 부인할수 없는것은 어떤 사람들은 불공평하게 똑똑하다는것이다. 브레인 자체의 배기량이 커서 한번에 처리하는 복잡도의 양이 다르다. 세상은 불공평하고 나 역시 불공평한 세상에 선택받지 못한자로 태어났다. 하지만 아직 찬스가 남아있는것은 두번째 이유 때문이다.

두번째 자질은 문제해결을 즐기는 사람이다. 많은 사람들에게 이 문제들은 괴로운 것이고 월급이라도 받아야 간신히 참여하는 노동인데 어떤 사람들은 그 과정 자체를 즐거워한다. 사실 똑똑한 것과 즐기는 것은 그 둘사이에 크게 연관성이 없다. 배기량이 조금 부족한 차를 몰아도 운전하는게 즐거워 매일 드리프트하다보면 배기량 큰차와 레이싱 붙어도 꿇리지 않는다. 내가 조립해놓은 생각의 조각들이 서로 맞물려 한치의 오차없이 돌아가는것을 지켜보는것은 세상에서 가장 즐거운 일중 하나이다. 나는 이번에 회사를 이직했는데, 지난주 회사를 나오며 약 반년간 작업한 결과물을 런치했다. 스케줄이 밀려 마지막날 금요일에 버튼을 눌러야했는데, 동료들에게 이걸로 나는 회사의 <레전드> 아니면 <빌런>으로 남을거라며 웃었다. 높은 확률로 서버가 터질수 있고 그 경우 회사의 매출에 직격탄을 맞는 백엔드 작업이다. 다행히 난 <레전드>로 마무리할수 있었다. 그 이유는 마지막날 새벽 3시까지 근심어린 눈으로 서버 그래프를 지켜볼 정도로 나는 이 문제를 내것으로 여기고 좋아했기 때문일것이다.

  1. 태도역시 겸손하다면

꽤 오래전 스타트업 직장에 정말 뛰어난 개발자 친구 C가 있었다. 수십만 라인의 코드를 몇달만에 만들어내는 어려서부터 코딩한 타고난 해커다. 제품 첫 버전의 거의 70%정도를 C 혼자 작성했다. 내가 처음 들어가 그 친구 코드의 이해안가는 부분을 질문했을때 흔쾌히 설명해준 다음 자신의 구현이 경쟁자에 비해 얼마나 빠른지 그래프까지 보여줬다. 경쟁 오픈소스 제품에 대해 설명할때면 다소 경멸띤 표정으로 얼마나 자신의 구현이 우월한지 설명하곤했다. 그런데 경쟁 제품이 시장에서 인기를 더 얻기 시작했다. 회사는 버전 2를 만들어야했고 가장 중요한 부분은 역시 C군에게 맡겨졌다. 다른 개발자들에겐 그 문제가 너무 어려울거라 생각했는지 C군은 문제를 독점했다. 그게 문제의 시작이었다. 버전 1에 비해 훨씬더 복잡한 스펙을 요구했던 버전 2는 C군에게도 버거운 문제였다. 하지만 그는 도움을 청하지 않았고 버전 2는 계속 지연됐다. 나중에는 문제가 지겨워졌는지 아프단 핑계로 한동안 회사에 나오지도 않아 그당시 우리 VP는 치킨누들수프를 끓여서 그 친구집으로 배달을 가곤했다. 스케줄보다 1년넘게 지연된 버전 2는 나온 후에도 버그 투성이였다.

코딩이 뛰어난데 겸손한 개발자 찾기는 정말 쉽지 않다. 어느정도 규모있는 팀에서 일하는 사람은 무슨 의미인지 알것이다. 경험상 두명중 한명꼴로 본받을만한 겸손함을 갖고있었다. 뛰어난 개발자는 높은 비율로 똑똑하기 마련이고 어려서부터 똑똑했던 사람에겐 겸손이 어려운 문제다. 하지만 똑똑한데 오만한 개발자는 팀에 있어서 독과 같다. 디자인, 코드 리뷰를 할때면 어느 순간 브레인의 배기량 자랑으로 변해버려 상대를 짓눌러버릴 방법을 찾는다. 오만한 시니어가 주도하는 팀은 각자도생하는 정글로 변해버린다. 정말 뛰어난 개발자는 혼자서 버전 1은 만들어낼수 있다. 하지만 궤도에 올라간 프로덕트를 우주로 끌어올리는건 팀이 함께 푸쉬하는 힘이다. 그리고 그팀을 만들어내는건 코어에 있는 능력을 겸손한 말로 전달하는 리드다. 겸손함의 핵심은 상대방과 팀을 돕기위해 자신을 내어주는 것이다.

  1. 그런데 커뮤니케이션도 잘하면

훌륭한 코딩에 겸손함을 갖추고 있는 개발자가 주위에 있는지 생각해보라. 혹시 그 사람이 팀에 미치는 영향력이 생각보다 작다면 마지막 조건에 미달하기 때문일것이다. 커뮤니케이션과 코딩능력은 정말로 어울리지 않는 상극과 같은 조건이다. 왜 그런지는 나도 잘 모르겠다. 주변에 코딩 정말 잘하는데, 자신의 문제를 비지니스에 연결지어 효과적으로 설명하는 사람이 얼마나 되는지 생각해보라. 경험상 세명에 한명 꼴로 개발자의 커뮤니케이션이 좋았다. 야후의 Marisa Mayer는 이렇게 얘기했다.

“Beyond basic mathematical aptitude, the difference between good programmers and great programmers is verbal ability.” – Marissa Mayer

“기본적인 수학능력 이외에 괜찮은 프로그래머와 뛰어난 프로그래머의 차이는 말하는 능력이다”

나는 지난 몇년간 매니저 역할을 하면서 수도없이 많은 미팅을 했다. 사실 매니저 시작하며 제일 부담스러웠던건 내 떨어지는 영어실력과 발음이었다. 하지만 몇달 지나고나서 내 걱정은 기우였다는 것을 알았는데, 영어가 모국어인 사람들도 말을 엄청못한다는걸 깨달았기 때문이다. 1:1 미팅하면서 지금 해결하는 문제에 대해 질문하면 눈을 잘 못 마주치며 우물대는 사람도 있고, 전달해야 할 내용을 요약을 못해 코드 레벨 하나하나 다 설명해야 하는 사람도 있다. 커뮤니케이션을 잘하는 것은 말을 많이하는것이 아니다. 어떤 친구들은 말하는 것을 너무 좋아해 정보에 시그널 대비 노이즈가 너무 많다. 커뮤니케이션이 좋은 사람은 상대방에게 필요한 정보를 정황 (context)속에서 빨리 캐치해내고 상대의 언어로 해석해서 전달한다. 개발자와 PM/마케팅같은 비 개발자가 모이는 미팅에서 개발자가 사용하는 단어 하나하나를 유심히 살펴보라. 외계언어로 이야기하는 개발자에게 미소를 짓는 마케팅 부서 직원은 <이 외계인이 또…> 속으로 생각할런지 모른다.

코딩 잘하는 사람이 1/4, 겸손한 사람이 1/2, 마지막으로 커뮤니케이션 잘하는 사람이 1/3 비율로 존재한다면, 이 세가지를 모두 갖춘 사람은 1/24 비율이다. 이렇게 찾기 어려우니 고급 개발자인게 맞다. 그런데 이 세가지 조건중에 학교에서 양육할수 있는것은 무엇인지 생각해보라. 겸손을 학교에서 배울수 있을까? 다양한 직종의 사람들 틈사이에서 배워가는 커뮤니케이션 능력은 어떨까? 코딩의 영역 역시 학교는 정글에서 살아남는 도구 쓰는 능력을 가르칠뿐 실력 자체를 만들어주지는 못한다. MIT, 스탠포드, 아이비리그 학교의 졸업생들 많이도 일해봤지만, 흔히 이야기하는 학교의 네임밸류와 실제 코딩 능력은 크게 연관성이 없었다. 뛰어난 리더는 양육되는게 아니다. 혹시 가능하더라도 최소한 양육하는 스승이 뛰어난 모델이어야 하지않을까? 누군가가 <교수는 졸업하지 않기로 마음먹은 학생>이라고 이야기했는데…

코딩, 겸손, 커뮤니케이션을 마스터한 뛰어난 리더는 살면서 그렇게 하기로 스스로 깨달은 사람들이다.

https://twitter.com/sm_park

코딩 인터뷰 – part 5

온사이트의 마지막 세션을 마칠때쯤엔 대략 오퍼의 여부를 스스로 예상할수 있다. 파트 2에서 설명했던것처럼 한개 정도 부족한 세션이 있었다해도 나머지 문제들을 풀었다면 오퍼가 희망적이다. 회사들은 보통 인터뷰 다음날 인터뷰어들이 모여 debriefing 시간을 갖는다. 여기에서 리뷰들이 오퍼쪽으로 결정되면 리쿠르터는 지체없이 연락을 해온다. 인터뷰 후 결과가 나오기까지는 마치 예전에 대입시험 결과를 기다리는 그런 초조함이 있다. 내 경험상 오퍼가 나올때에는 인터뷰후 빠르면 24시간, 늦어도 3일안에 오퍼 소식을 들을수 있었다. 혹시 연락이 오지 않고 시간만 흘러갈때는 점점 오퍼의 가능성이 낮아진다. 이 경우 며칠후에 공손하게 확인하면 결과를 가르쳐준다. 리젝시에 한가지 꼭 시도하면 좋은것은 인터뷰의 피드백을 달라는 요청이다. 일반적으로 회사는 정책상의 이유로 인터뷰의 피드백을 공유하지 않는다. 그러나 종종 피드백을 짧게라도 이야기해주는 곳이있다. 이 피드백에는 내 예상과 다른 평가들이 있을수 있기때문에 다음 인터뷰를 준비하는데 아주 유용하다. 내 경우 첫 인터뷰에 안되고나서 코딩때문이라 생각했는데, 의외로 시스템디자인에서 부족했다는 피드백을 받았다. 결과가 안좋을때는 배울것을 한가지라도 건지고 툭툭 털어내는게 좋다.

오퍼가 나오면 이제 시작되는 것은 연봉과 Title, Benefit (보험, 휴가)등에 관련된 협상(negotiation)이다. 미국에서 비지니스 관계의 모든 딜은 철저하게 협상을 통해 이루어진다. 예전에 차를 한대사러 딜러샵에 간적있다. 전날밤 미리 여러개의 웹사이트에서 해당 차량의 가격 정보를 풍부하게 수집하고 딜러와 데스크를 사이에 두고 앉았다. <갑>의 위치에 있다고 생각한 나는 편안하게 내가 생각한 적정 가격을 제시했다. 딜러는 웃음기 없는 얼굴로 이렇게 되물었다.

“왜 그 가격이 타당한지 나를 설득시켜봐”

잡마켓에서 오퍼 이후의 협상도 마찬가지다. 목표하는 연봉이 있을경우 그 액수를 뒷받침할수 있는 논리적 이유가 있어야 한다. 그중 가장 효과적인것은 역시 다른 회사에서 제시하는 경쟁 오퍼다. 한개의 오퍼만 가지고 테이블에 올라오면 설득시킬 무기가 없다. 리쿠르터와의 대화는 그래서 이렇게 요약된다.

“잘 해 줄께. 근데 얼마까지 알아봤어?”

리쿠르터는 타 회사의 오퍼가 있을경우 이를 상세하게 적어가고 곧 이보다 조금 많은 금액으로 오퍼한다. 이쯤되면 보통 지원자 입장에서는 연봉과 상관없이 가고싶은 회사가 한곳 이미 정해져있다. 그래서 다른 곳의 오퍼는 원하는 회사의 오퍼를 올리기 위한 수단으로 사용해야한다. 그런데 리쿠르터 역시 매일 이런 딜을 하는사람들이기 때문에 본인이 top에 있는지 아니면 오퍼를 올리기 위한 마중물인지를 파악하려고 노력한다. 그래서 지원자는 끝까지 포커페이스를 유지하며 왜 그 회사가 top choice인지 이유를 댈수있어야한다. 지원자에게 최고의 전략은 second choice에서 오퍼를 맥시멈으로 끌어올리고, top에서 이를 이기게끔 만드는것이다.

소프트웨어 회사의 오퍼는 보통 이렇게 구성되어 있다.

  • 베이스 연봉
  • 보너스
  • 주식 (RSU)
  • 사이닝 보너스

주식과 보너스 역시 시간이 얼마 지나면 현금화 할수있기때문에 이를 모두 합산한 Total Compensation을 기준으로 협상하는것이 좋다. 사이닝 보너스는 일회성 금액이라 융통성이 있기때문에 회사들은 경쟁 오퍼를 죽이기위해 활용할수 있다. 그래서 오퍼가 여러개 있을때 사이닝을 최대한 잘 받는것도 좋은 전략이된다.

최근엔 보통 Glassdoor의 정보를 활용해 오퍼가 괜찮은지 여부를 평가한다. 그런데 내 경험에 Glassdoor의 연봉 정보는 시장 가격보다 좀 많이 낮은편이다. 아마도 오래된 정보가 쌓여있어서 그런게 아닌가 생각된다. 시장의 가격보다 대략 30%정도 디스카운트 되어있다고 생각하는게 좋다. 이보다 좀 더 정확한 정보는 paysa.com에서 얻을수 있다. 예를들어 시애틀 마이크로소프트의 시니어 엔지니어 경우 glassdoor에선 175K이 평균인 반면, paysa에서는 221K가 시장 가격으로 올라와있다. 경쟁 오퍼가 있다면 이보다 조금 더 올리는것도 어렵지 않으니, “얼마까지 알아봤어?”의 시장 원리를 최대한 활용하는것이 좋다.

이렇게해서 이번 인터뷰 시리즈를 마무리한다. 결과적으로 나 자신도 뜻밖의 결과인 Niantic Lab.으로 다음 회사를 결정했다 (나이엔틱은 포켓몬고를 만드는 증강현실 게임회사). 다른 몇개의 대기업에서 받은 오퍼가 괜찮고 한두개 회사는 일의 종류, 환경, 팀도 너무 마음에 들어 포기해야 하는게 아까웠다. 나이엔틱의 인터뷰 경험은 다른 대기업들과는 많이 달랐다. 높고 화려한 대기업 오피스들 사이에 낮고 오래된 건물이 있고, 어두컴컴한 복도 한켠에 회사간판도 없는 오피스… 문을 열고 들어가니 주성치 영화에 조연처럼 생긴, 머리카락 몇올없는 중국 아저씨가 웃으며 나를 맞았다. 아주 작은 사무실에 다닥다닥 붙어앉아 일하는 사람들. 오피스가 그래서인지 다소 창백해 보였지만 다들 눈은 초롱초롱 빛났다. 작년의 포켓몬고 열풍에 서버를 어떻게 감당했는지 물었더니 중국아저씨는 <그땐 3-4시간씩 자면서 다 막아냈지 껄껄껄>… 이 바닥 초 절정 고수의 아우라를 풍겼다. 인터뷰를 마치고 나오며 팬시한 대기업에서 못느낀, <여기에서 일하고싶다> 라는 열망이 생겼으니, 나도 어지간히 스타트업을 좋아하는가보다.

https://twitter.com/sm_park

코딩 인터뷰 – part 4

예전에 구글에서 일하시는 한분이 본인은 시스템 디자인 인터뷰가 가장 어렵다고 이야기한적 있다. 코딩인터뷰의 경우 문제 set이 존재하기때문에 문제를 많이 풀어보면 되지만, 시스템 디자인은 질문을 예측하는것도 어렵고 정답이란것도 존재하지 않기때문이다. 구글에서 시스템 디자인 문제를 검색해봐도 결과에 정답은 나오지 않는다. 시스템 디자인은 대부분 스케일 문제를 다룬다. “수억명의 사람들이 너의 서비스를 사용한다면 너는 어떻게 이 문제를 해결할래?” 이런 질문에 경험에서 우러나오는 사골같은 답을 할수 있다면 얼마나 좋을까마는 사실 그런 시스템을 다 만들어본 엔지니어는 극히 소수일 것이다. 나 역시 시스템 분야로 PhD도 했고 수년간 같은 분야에서 다양한걸 만들었지만 여전히 이 질문은 어렵다. 그러나 디자인 인터뷰 역시 살아남는 방법은 있다. 그 방법이란 좀 싱겁지만…,

“공부를 많이하면 된다.”

우선 내가 그동안 받았던 디자인 질문들을 나열해보면 이렇다.

  • Queue 시스템을 디자인해라
  • Twitter를 디자인해봐라
  • TinyURL 디자인해봐라
  • Yahoo의 Stock Quote 시스템을 디자인해라
  • Elevator 시스템을 구현해봐라
  • Hadoop의 namenode를 새로 디자인해봐라
  • (AI 관련팀) 우리 시스템을 네가 디자인해봐라

4-5명과의 인터뷰중 시스템 디자인은 최소 한차례, 많게는 두세번 질문을 받게된다. 시스템 디자인에서 인터뷰어가 파악하고자 하는것은 크게 세가지로 볼수 있다:

  1. 커뮤니케이션을 잘 하는가?
  2. 문제를 정확히 알고있는가?
  3. 괜찮은 디자인을 할수있는가?

디자인 질문은 의도적으로 모호하게 주어진다. 예를들어 Queue 시스템을 디자인하라는 질문은 사실 밑도끝도 없다. <어떤 Application이 Queue를 사용하는가?>, <Queue에는 무엇이 들어가는가?>, <Producer/Consumer의 숫자는 몇개인가?> 등 디자인에 꼭 필요한 디테일이 빠져있다. 그래서 디자인 질문을 받았을때 처음 해야하는것은 <질문>이다. 여러번 충분한 질문을 통해서 인터뷰어가 생각하는 진짜 문제를 파악해내고 여기에서 Requirement를 알아내는것이 첫 단계에서 반드시 해야할 일이다. 이 과정에서 인터뷰어는 지원자의 커뮤니케이션 능력을 평가한다. 혹시 예전에 비슷한 시스템을 구현해본적이 있다고 질문을 생략한다면 이는 인터뷰가 망하는 길로 가는 지름길이다.

내가 받았던 디자인 질문중 특히 좋았던 것 한가지는 엘리베이터 시스템을 디자인하라는 것이었다. 무한하게 많은 수의 엘리베이터가 늘어서있다고 가정하고 사용자가 각 층에서 누르는 Up/Down 버튼에 맞추어 어떻게하면 최적의 서비스를 제공할수 있을까라는 질문이었다. 이 질문이 좋았던 이유는 엘리베이터라는 잘 알려진 문제가 그동안 생각하지 못했던 수많은 분산시스템의 컨셉을 드러내기 때문이다. 예를들어서,

  • Controller가 중앙에 한개 놓여있고 모든 엘리베이터가 통제에 따른다고 가정해보자. 그럼 Controller가 죽어버리면 엘리베이터의 Availability는 어떻게 될것인가?
  • 그럼 엘리베이터를 분산시스템으로 구현해보자. 엘리베이터 사이의 커뮤니케이션이 불안정할때 스케줄이 항상 정확할수 있을까? (CAPS theorem)
  • 엘리베이터는 사용자가 버튼을 누른 시간순으로 서비스를 제공한다. 그럼 엘리베이터의 시간은 모두에게 동일하게 흘러가는가? (Vector clock의 개념)

이러한 질문의 의도는 지원자가 시스템에서 발생하는 <문제> 혹은 <컨셉>을 다양하게 알고있는가를 파악하기 위한것이다. 가상의 문제에 대해 대화하면서 분산시스템의 클래식한 문제들 — vector clock, CAPS theorem, distributed consensus, quorum vote, data hashing등 — 을 연상해낼수 있는지를 보는것이다. 뛰어난 인터뷰어일수록 이런 질문을 던진다. 이런 문제에 답하기 위한 쉬운 방법은 없다. 아래에 달린 긴 리스트에서 보듯, 그저 다양하게 많이 아는 수밖에…

마지막으로 디자인 질문에서 파악하고자 하는것은 <괜찮은 디자인을 할수 있는가?> 여부이다. 복잡한 시스템에는 정답이 없다. 다만 괜찮은 답이 있을뿐이다. 여기에서 괜찮은 답이란 디자인의 각 단계에서 어떠한 선택을 해야할때 각 선택의 Trade-off 를 알고 있고, 자신의 선택을 논리적으로 방어할 수 있는 디자인이다. 즉 취할것은 취하고 버릴것은 버리되, 왜 그러한 선택을 하는지는 설명을 할 수 있어야 한다는 뜻이다. 예를들어 트위터를 디자인한다면,

  • Relational DB를 Shard해서 사용할것인가 아니면 Cassandra, Dynamo와 같은 분산 key-value DB를 사용할 것인가?
  • In-memory cache로 Redis 혹은 Memcached 를 사용할까?
  • Push model (모든 follower에게 tweet을 저장) 혹은 pull model (모든 following에게서 tweet을 읽음)을 사용할까?
  • Tweet의 아이디는 DB의 Sequential ID를 사용할까 아니면 snowflake와 같은 분산시스템을 따로 만들까?

코딩 질문이 한가지 질문에 optimal 알고리즘을 구현하기위한 것이라면 시스템 디자인은 시스템의 각 파트를 해결하기위해 제각각 여러개의 알고리즘을 끌어와서 큰 스케일에서 동작하는 그림을 보여주는 것이다. 그러므로 좋은 답을하기 위한 핵심은 얼마나 많이 그러한 알고리즘을 알고 있는가의 여부이다. 예를들어,

  • 어떻게 분산된 컴퓨터에 데이터를 나눌 것인가 —> Consistent hashing
  • 분산 컴퓨터들은 어떻게 자신이 담당할 문제의 영역을 선택할까? —> Paxos algorithm or zookeeper
  • 데이터가 복제되어있을때 어떻게 consistency를 보장할까? —> Quorum vote
  • 분산 컴퓨터가 어떻게 ID를 고유하게 만들까? —> Twitter’s snowflake
  • 데이터 통신의 보안은? —> PKI encyprtion

아래는 내가 그동안 공부했던것들중 인터뷰에서 가장 유용했던 자료들이다. 꼭 인터뷰가 아니더라도 최신의 시스템을 이해하는데 좋은 자료들이라고 생각해 여기에 공유한다. 가장 중요한 자료에는 별점 5개를 붙여놓았다.

[Designing Data-Intensive Applications]
시스템 디자인 준비하기에 가장 좋은 책. 아래의 레퍼런스 대부분 내용을 책 한권에 다 요약해 놨다. https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321

[Distributed Systems]

[Distributed Key-Value Database]

[Sharding]

[Caching]

[Search]

[Distributed Consensus]

[Concurrency]

[Distributed Queue]

[그외]

코딩 인터뷰 – part 3

예전에 한 스타트업과 인터뷰를 한적이 있다. 첫 시간에 두명의 엔지니어가 함께 들어왔는데 한시간 내내 코딩이나 시스템디자인이 아닌 behavioral 인터뷰를 했다. 과거 직장동료와 충돌이 있었는지, 그런 상황에서 어떻게 문제를 해결했는지등 일반적인 질문이었다. 코딩 인터뷰를 기대했던 나는 약간 당황했고 답은 횡설수설이었다. 그리고 한시간을 마치자마자 리쿠르터가 들어와 나는 그 회사와 cultural fit이 맞지 않으니 집에가라는 결과를 받았다. 태연한척 걸어나왔지만 ‘내 인성이 그리 엉망진창이란 말인가?’ 모욕감이 며칠간 내내 머리를 맴돌았다. 최근에서야 깨달은것은 behavioal 인터뷰 역시 준비가 필요하다는 사실이다. (참고로 나는 그 스타트업이 잘될거라고 생각하지 않는다. 엔지니어를 인성만으로 거르는건 축구선수를 외모 보고 발탁하는것과 같다.)

테크 회사들의 개발자 인터뷰는 크게 1) 코딩, 2) 시스템 디자인, 3) behavioral 세가지 파트로 나눌수 있다. 코딩인터뷰의 경우 주어지는 문제에따라 최적의 알고리즘이 이미 알려져있기때문에 pass/fail 여부를 쉽게 가늠할수 있는반면 behavioral과 시스템 디자인은 정확하게 어디까지가 pass이고 fail인지를 나누는것이 쉽지 않다. 지원자 입장에서는 최대한 ‘잘’ 준비하는수밖에 없다. behavioral의 경우 회사에서 알고자하는것은 크게 두가지로 볼수있다:

1. 커뮤니케이션을 효과적으로 하는가
2. 이 녀석은 혹시 jerk (고문관)가 아닐까?

과거에 아무리 대단한 프로젝트를 많이했어도 몇분안에 그 경험의 핵심을 전달하는것은 코딩과 별개인 커뮤니케이션 능력이다. 영어에 native가 아닌 사람들에게는 특별히 준비가 필요한 영역이다. ‘jerk test’의 경우 가장 중요한것은 인터뷰 과정에서 이상 행동을 하지 않는것이다. 듣기로는 테크 인터뷰를 하면서 인터뷰어와 싸우려드는 사람들이 의외로 많다고한다. 혹시라도 자신에게 파이터 본능이 있다면 인터뷰 당일만큼은 날카로운 발톱을 최대한 숨기는것이 좋다.

Behavior인터뷰의 방법은 회사마다 다르다. 어떤 회사들은 코딩인터뷰 중간에 인성과 관련된 질문을 넣기도 하고, 다른 회사들은 점심 시간이나 하이어링 매니저와의 세션 전부를 인성과 관련된 질문으로 채워 넣는다. 다음은 내가 받았던 Behavioral 혹은 프로젝트 경험과 관련된 질문들이다.

  • 지금까지 해결한 기술적인 문제중 아주 어려웠던 것은 어떤것이 있는가? 어떻게 그 문제를 해결했는가?
  • 지금 회사를 왜 떠나려고 하는가? 왜 우리 회사를 선택했는가?
  • 프로젝트가 내가 원하지 않는 방향으로 진행되는 것을 경험한적이 있는가? 어떻게 대응했는가?
  • 프로젝트가 기술외의 문제 (사내 정치등)로 영향을 받은적이 있는가?
  • 팀을 리드해본 경험이 있는가?
  • 내가 담당하는 영역이 아닌 다른 사람, 부서의 문제를 해결한 경험이 있는가?
  • 직장동료와 충돌을 경험한적이 있는가? 그런 상황에서 어떻게 문제를 해결했는가?
  • 고객과 회사의 이해가 충돌하는 상황을 경험한적이 있는가? 나는 어떤 선택을 했는가?

이와같은 질문을 받았을때 그 자리에서 즉흥적으로 답을 만들어내는것은 생각보다 쉽지 않다. 과거의 경험을 바탕으로 최대한 긍정적인 면을 어필할수 있는 답을 미리 준비하는것이 필요하다. (To be continued…)

코딩 인터뷰 – part 2

온사이트 인터뷰

스크리닝에서 일단 지원자가 사람이라는게 판가름나면 그 다음은 <쓸모>있는 사람인지를 판단하는 온사이트 단계로 넘어가게된다. 폰스크린 마치고 짧게는 1시간 안에, 길게는 2-3일내로 온사이트 초청 이메일을 받게된다. 이때부터 리쿠르터가 지원자를 대하는 태도가 조금 달라지는걸 느낄수 있는데 미래의 동료가 될 가능성이 높기때문에 이메일과 전화통화에서 좀더 지원자를 배려해준다. 즉 이제 <사람 취급> 받는다는 뜻이다.

폰스크리닝이 예선전이었다면 온사이트는 이제 본선이다. 월드컵 예선에서 미얀마, 필리핀같은 array문제를 풀었다면 이제 본선에선 독일, 브라질같은 dynamic programming, graph search 문제도 만나게 된다. 더 쓰기전에 우선 내 경험을 좀 더 이야기하려고 한다. 나는 내 자신이 한번도 알고리즘에 소질이 있다고 생각한적이 없다. <알알못>같은 사람이다. 학부 시절에 알고리즘 수업에서는 C를 받았었고, 대학원 수업에서도 C를 받았다. 참고로 대학원 수업에서 B를 못받는건 교수에게 진상짓하는것과 같다. 박사학위를 했지만 시스템쪽 전공이라 알고리즘과는 관계가없고, 지난 몇년간 스타트업에서 일하며 제대로 코딩 인터뷰를 해본적도 없다.

내가 코딩 인터뷰를 돌파하기 위한 방법은 그래서 한가지였다. 멋있는 말로 하면 <photographic memory 능력을 사용하자> 이고, 쉽게 말하면 <답을 외우자>가 내 전략이었다. 코딩 인터뷰에는 분명히 문제 set이 존재한다. 어떤 경우엔 문제가 토씨하나 틀리지않고 그대로 나올때가있고, 응용이지만 결국 같은 알고리즘을 원하는 문제를 만날때도 있다. 코딩 인터뷰의 set을 공부하는 가장 좋은곳은 leetcode.com 이다. 이곳에서 Frequency 순으로 정렬해서 가능하면 많이 문제를 풀어보는것이 좋다. 나는 지난 3개월간 160개 정도의 문제를 풀었고 같은 문제가 나왔을때 한번도 실수 안할정도로 답의 코드 패턴을 외웠다.

사실은 인터뷰의 set을 푸는 그 과정이 쉬운것은 아니다. 한 문제를 풀어보려고 2시간 이상 씩씩대가며 모니터를 쳐다볼때도 많았다. 나는 내가 좀 지능이 모자라서 그런가 생각했는데, 최근 공부를 시작한 나보다 훨씬 똑똑한 동네 친구 역시 나처럼 2시간씩 씩씩대고 있다는 하소연을 들었다. 그런데 한가지 흥미로운 사실은, 공부를 시작할무렵 문제를 보면서 느낀, 마치 벽을 앞에두고 선듯한 막막함이 지금은 거의 사라졌다는 사실이다. 지금은 비슷한 문제를 보면 예전에 외웠던 알고리즘의 패턴이 자연스럽게 생각난다. 같은 문제에 대해 예전에는 두뇌가 불편해 했다면, 지금은 두뇌가 자연스럽게 받아들인다고 할까? 160개의 문제와 답의 알고리즘 패턴을 외우는 과정에서, 두뇌가 좀 더 알고리즘 문제에 적응되었기 때문일것이다. 그래서 <답을 달달 외우면 그게 실력이냐?> 누가 묻는다면, <하다보면 실력이 돼> 라고 답할수 있을것 같다.

다시 온사이트 이야기로 돌아가보자. 온사이트는 보통 4-6명의 인터뷰어와 1시간씩 돌아가며 문제를 푼다. 폰스크리닝과 확연한 차이점은 두뇌가 5시간 이상을 버틸 체력이 필요하다는 사실이다. 코딩을 격투기라고 생각하면 매 시간마다 새로운 도전자가 씨익 웃으며 링위로 올라온다는 뜻이다. 쉬는 시간도 주어지지 않고 <다음 인터뷰어를 소개하지~> 이렇게 계속해서 상대방만 턴을 바꾸게된다. 나는 3주간 10개의 온사이트를 집중해서 보았다. 처음 온사이트는 숨막히는 피곤함 뿐이었는데, 후반기로 갈수록 체력이 붙어 여유롭게 6시간을 버텨낼수 있었다. 특히 오퍼가 이미 나왔다면 <허허 어디 문제한번 봅세~> 이런 여유로움도 누릴수 있다.

폰스크리닝과 마찬가지로 매 시간마다 인터뷰어는 <너는 뭐했슴?> <우리팀에 질문있슴?> 이렇게 묻는다. 가능하다면 앞 부분의 이런 인트로는 짧게 하고, 문제를 푸는 시간을 최대한 길게 갖는것이 좋다. 4-5명과의 온사이트중 최소한 1명은 디자인 인터뷰를 담당한다. 시니어 레벨의 경우 2명 이상과 디자인 세션을 하는 경우도 있다. 또 점심식사를 겸해서 behavioral interview를 하는게 일반적이다 그래서 코딩은 온사이트에서 3회 정도 한다고 보면 일반적이다.

인트로가 끝나면 <자 오늘 내가 준비한 문제는…>, 이렇게 멘트를 날리며 인터뷰어는 문제를 화이트보드에 적는다. 이때 문제에 따라 몇가지 다른 시나리오가 생긴다.

  • 아는 문제: 경험상 절반의 문제는 leetcode 문제 set에서 그대로 나왔다. 이때 필요한 것은 출중한 연기력이다. 태연하게 ‘나는 저 문제를 모른다. 나는 저 문제를 모른다’ 머리속으로 되뇌인다음 1) 막막한 표정, 2) brute-force는 이렇게 하면 될건데 , 3) 아 이렇게 하면 더 빨리 되겠구나!, 이렇게 단계별로 연기해가며 차분하게 외운 코드를 화이트보드에 적으면 된다
  • 응용 문제: 경험상 1/4 정도의 문제는 이미 외우고있는 문제를 약간만 응용해서 답을 찾는 타입이다. 예를들어 graph search 문제는 무궁무진하게 응용이 가능한데, 몇개의 문제를 풀어봤으면 대략 문제 설명을 듣고나서 이건 graph 문제구나 라는 느낌이온다. 이 경우엔 연기가 필요없다. 자연스럽게 내가 아는 지식을 꺼내서 문제에 적용하는 것이기 때문에, 코딩만 실수없이 잘 마무리하면 된다.
  • 모르는 문제: 이런 경우가 없으면 좋겠지만 어떤 인터뷰어는 너무 부지런해서 공개안된 문제를 내곤한다. 경험상 1/4 정도의 문제는 처음 접해보는 것이었다. 이 경우 우선은 알고리즘 패러다임 (dynamic programming, graph, binary search, divide&conquor..) 혹은 자료구조 (priority queue, binary search tree, …) 중에서 하나라도 써볼수 있는게 있나 생각해야 한다. 그리고 최대한 막막하고 힘든 표정을 지으며 인터뷰어의 힌트를 유도해야 한다. 힌트를 얻고도 도저히 안되겠다 싶을때는 시간을 잘 고려해 brute-force라도 코드를 정확하게 끝까지 써내야 한다. 한 세션의 결과는 [pass, neutral, fail] 세가지중 하나인데, pass가 글렀으면 neutral로 승점 1점이라도 건져야한다.

지난 10회의 온사이트에서 나온 25개 문제를 카테고리로 나누면 다음과 같다:

  • Binary Search Tree or Binary Tree: 8회
  • Graph Search Problem: 3회
  • Dynamic Programming: 2회
  • Advanced(응용) Sorting: 3회
  • Hybrid Data Structure: 2회
  • Greedy Algorithm: 4회
  • String, sliding-window problem: 2회
  • Binary Search 응용: 1회

대부분 문제들은 leetcode의 medium difficulty 수준이라고 생각하면 되고, 종종 hard difficulty 문제가 나오는 경우도 있다. 내 경우 dynamic programming 문제중 하나는 아주 어려운것이었는데 마침 그 문제의 답을 며칠전 외운 상태였다. 그리고 그 인터뷰가 첫 오퍼였으니 어쩌면 인터뷰엔 운도 많은 작용을 한다.

코딩과 디자인 인터뷰 (다음 블로그 주제)를 4명과 했을경우 경험상 오퍼의 여부는 이렇게 가늠할수 있다:

  • 4명 PASS: 당연히 오퍼
  • 3명 PASS, 1명 Neutral: 오퍼
  • 3명 PASS, 1명 Fail: 리젝
  • 2명 PASS, 2명 Neutral: 리젝

즉, 한명에게라도 Fail수준의 인터뷰를 했으면 오퍼는 나오지 않았다. 그리고 2명이상 Neutral일 경우에도 오퍼는 나오지 않았다.

끝으로 코딩 인터뷰에 적합한 알고리즘 교과서는 Skiena의 Algorithm Design Manual을 추천한다. Cormen의 Introduction to Algorithm보다 쉬우면서 인터뷰에 충분한 내용은 모두 담고있다. 그리고 인터뷰 경험이 부족한 사람에겐 가상(mock) 인터뷰를 할수 있는 pramp.com 도 아주 유용했다. 코딩 인터뷰의 pressure를 훈련하기에는 mock 인터뷰만큼 좋은것이 없다.

(To be continued…)

코딩 인터뷰 – part 1

지난 두달간 무려 15개의 회사와 코딩 인터뷰를 했다. 혹 비슷한 과정을 겪게될 분들을 위해 그동안의 경험을 지극히 주관적인 관점에서 정리해보려고 한다.

미국의 소프트웨어 개발자 채용 과정은 사실 공정한 편이다. 채용 프로세스중 몇몇 역할을 우선 소개하자면,
  1. 리쿠르터: LinkedIn등을 통해 지원자와 처음 연락하는 것부터 오퍼의 마지막 단계까지 끌어주는 역할을 한다. 오퍼의 여부를 결정하는 사람은 아니지만, 오퍼에서 연봉등을 하이어링 매니저와 조율하기 때문에 중요한 역할을한다. LinkedIn으로 귀찮게 연락한다고 가볍게 여겨선 안된다.
  2. 하이어링매니저: 포지션을 오픈하고 채용 후에 보통 매니저 역할을 수행하게되는 사람이다. 곧 미래의 보스라고 생각하면 된다. 이 사람의 의견이 채용에 있어 가장 중요하므로 지원자 입장에선 높이 우러러보는 자세가 필요하다.
  3. 같은팀 개미 개발자: 오퍼를 받았을때 같은 팀에서 일하게될 개미 개발자들이다. 여기서 개미는 Principal 보다 낮은 직급으로 주로 코딩 인터뷰를 담당하는, 일개미 같은 개발자들을 말한다.
  4. 같은팀 왕고 개발자: 같은 팀에서 Principal 엔지니어 이상의 직급으로, 칠판에 그림만 그리고도 월급을 쓸어가는 사람들을 말한다. 참고로 대기업에서 Principal들은 보통 연봉이 30만불을 훌쩍 넘긴다. 이들의 역할은 주로 그림 그리는 것인만큼 인터뷰 역시 칠판에 그림 그리는 시스템 디자인을 주로 담당한다.
  5. 다른팀 왕고 개발자: 원래 아마존에서 시작했던 Bar-raiser 시스템이 여러 회사에 퍼지면서 다른팀의 왕고 개발자가 인터뷰에 들어올때가 있다. 이들은 보통 어려운 문제를 던져놓고 심드렁하게 앉아있는 경우가 많다. 지원한 팀에대해 질문을 하면 자기 팀이 아니라 당황해 하기때문에, 맘에 안들면 타이밍을 봐서 한번 물어보는것도 괜찮다.
채용 프로세스의 첫 단계는 리쿠르터와의 짧은 통화다. 내 레주메가 하이어링매니저 혹은 리쿠르터의 눈에 들었을땐 이메일로 전화 약속을 잡게된다. 통화시엔 레주메를 기준으로 과거의 경력을 짧게 소개하고, 왜 그 포지션에 지원하게 되었는지 설명한다. 하이어링매니저가 시켜서 전화를 걸어온 경우엔 거의 100% 전화 인터뷰를 잡자고 이야기하고, 혹 리쿠르터가 단독으로 연락을 해온경우 하이어링매니저의 레주메 심사를 더 통과해야 한다. 리쿠르터와의 통화는 거의 같은 패턴을 반복하므로 몇번 같은 통화를 하고나면 나중엔 유머사이트 보거나 애들 밥먹이면서 이야기하는 경지에 이르게된다. 혹 첫단계에서 현재 회사의 연봉을 묻는 리쿠르터가 있는데, 이 경우 어차피 오퍼 단계에서 필요한 정보이므로 알려주는것도 나쁘지 않다.

전화 인터뷰

리쿠르터와의 통화이후 며칠안에 전화 인터뷰가 잡힌다. 흔히 이것을 Phone Screening 이라 부르는데, 해석하자면 전화기 너머 상대가 스크리닝 (차양막, 모기장) 당해야 하는 벌레인가 아니면 온사이트 불러도 되는 인간인지를 판가름하는 지원자 입장에선 기분나쁜 단계다. 폰스크리닝의 상대로는 흔히 개미 개발자들이 출현하고, 혹 시니어 포지션으로 지원했을때는 그에 걸맞는 시니어 개미가 전화해 예우를 갖춰준다. 보통은 짧게 자신의 팀 소개를 먼저 하고, 그 다음엔 “너는 뭐했슴?” 묻는다. 여기서 주의할점은 이 질문의 역할은 지원자의 긴장을 풀어주기 위한것이지, 지원자의 화려한 전적을 듣고싶어 하는것이 아니라는점이다. 신바람나서 과거의 무용담을 끝도없이 늘어놓으면 나중에 시간이 부족해 “I’m sorry, I’m sorry…” 를 반복하다가 전화를 끊게되는 참담함을 겪을수 있으니 소개는 적당한것이 좋다. 또 인터뷰어는 흔히 “우리 팀에 질문 있슴?” 이렇게 묻는데, 코딩 문제 끝나고 나중에 묻겠다고 이야기하는게 낫다. 어차리 이런 잡담은 당락에 영향을 미치지 않고 오직 코딩 테스트가 결과를 결정하기 때문이다.

여러번 인터뷰후 한가지 파악한것은 폰스크리닝용 문제 타입이 있다는 사실이다. 우선 스크리닝 역할은 ‘멋진’ 인간인지를 판가름하는게 아니라 상대가 그저 인간인지를 알아내는데 있기 때문에 어려운 문제를 내선 곤란하다. 그리고 전화와 코딩 사이트의 텍스트 에디터로만 문제를 설명하는 한계때문에 문제 자체가 짧고 이해하기 쉬워야 한다. 아래는 실제로 폰스크리닝에서 받았던 질문들 혹은 같은 유형의 예제이다.

폰스크리닝 단계에서 주로 맞닥뜨리는 코딩문제의 패턴을 보면…
  • Array위에서 한개 이상의 variable을 가지고 놀수 있는가? (maximum-subarray, move-zeroes와 같은 문제)
  • LinkedList, Stack, Queue등을 이해하고 갖고 놀수 있는가?
  • 다양한 엣지 케이스를 잡아낼수 있는가? (Integer overflow, negative numbers 등등). 사실 이건 함정을 파놓고 기다리는 아주 짜증나는 타입의 질문인데 시애틀 M사 출신의 개발자들이 특히 많이 물었다.
  • HashMap이나 Set을 제대로 사용할줄 아는가? 두개 이상의 Map을 차분하게 사용해야 해결할수 있는 문제들이 많았다.
실용적인 질문을 한다고 알려진 몇몇 회사의 경우 (시애틀 A사, 캘리포니아 사과회사등), 코딩에 더해서 몇가지 시스템 지식문제를 내는 경우도 있었다. 예를들어
  • web browser로 google.com에 접속했을때 운영체제, 네트워크에서 벌어지는 모든 일들을 설명해봐
  • 프로그램이 execution될때 무슨 일이 일어나는지 Stack과 heap과 관련해서 설명해봐
  • virtual memory 설명해봐
  • Java가 C에 비해서 왜 느린지 설명해봐

(To be continued…)

스타트업 아이디어 – 좋은 글


Slava Akhmechet 이 쓴 좋은 에세이를 읽고나서 요약해봅니다. 원글은 이곳에서 찾을수 있습니다. http://www.defmacro.org/2015/02/25/startup-ideas.html

——————-

그동안 스타트업을 운영해보니 한가지 깨달아진게 있다. 혁신이 이루어지는 시장은 효율의 법칙이 지배한다는 점이다. 시장에 한개의 스타트업 아이디어가 열리면 이미 그 안에는 여러개의 스타트업들이 경쟁할 가능성이 많다. 그 반대의 경우도 성립하는데 어떤 시장에 스타트업이 없다면 그 시장은 스타트업이 가능할만한 환경이 아니라는 뜻이다.

보통 테크널러지 시장은 승자독식 방식이다. 새로운 문제를 해결한 첫번째 회사의 가치가 후발주자들 모두를 합친것보다 더 큰게 일반적이다 (예를들어 우버). 그래서 이미 어떤 회사가 시장에서 같은 문제를 해결했다면 당신이 그것을 대체하는건 거의 불가능이라고 보면된다.

흔히 알려진바대로 스타트업의 창업자는 자신이나 주변의 사람들이 가지고 있는 문제를 해결하는게 좋다. 그러나 이것은 아이디어를 걸러내는데 있어 효과적이지 않다. 시장은 효율적이기때문에 어떤 문제가 가치있고 해결할만하다면 이미 그 문제는 다른 회사에 의해 해결되었을 것이다. 반대 논리로 당신이 관심있는 어떤 문제가 해결되지 않았다면 구조적으로 그 문제의 해결이 불가능한 이유가 있을것이다. 

<다수의 법칙>으로 운영되는 투자자에겐 창업자들이 자신의 문제를 찾아서 해결하는 방식에 전혀 문제가 없다. 왜냐하면 포트폴리오 회사의 대부분이 실패해도 한두군데에서만 승자독식하는 회사를 건지면 되기 때문이다.

그러나 창업자들에겐 자신의 문제만 쫓는 방식은 효율적이지 않다. <다수의 법칙>이 그들 편은 아니기때문이다. 인생은 스타트업 아이디어를 여러개 시도해볼만큼 길지않다. 그래서 창업자들은 스타트업 아이디어를 좀 더 신중하게 걸러낼 필요가있다.

효율이 지배하는 시장이 이런식으로 스타트업이 나오는것을 막고있다면 그럼 어디에서 스타트업 아이디어를 찾아야할까? 모순같지만 그 해답은 초기단계에 문제를 찾아서 해결하려는 의지를 버리고 경제 환경(economic environment)이 변하는 흐름을 찾아내 이 변화가 여는 기회를 포착하는 것이다.

경제환경은 멈추어있지 않다. 사회의 도덕기준이 변하고 정치적 환경은 점차 자유로움을 더 추구하게된다. 개발도상국의 사람들은 점점 더 여유롭게된다. 기술의 발전은 조금씩 더딘것같지만 어느 시점 임계점을 넘어서면 사회에 의미있는 변화를 일으킨다 (예를들면 AI).

이런 환경의 변화는 스타트업이 일어날수있는 기회를 열어준다. 강조했듯이 기술회사는 승자독식이므로 환경의 변화를 제일 먼저 감지하고 시장에 어느정도 동작하는 솔루션을 제시하는 회사가 길게봤을때 새로운 시장을 지배할 가능성이 많다.

그래서 초기에는 “세상은 어떻게 변하고 있는가? 내가 그 변화에대해 할수있는건 무엇인가” 이 질문에 답을해야한다. 그리고 그 다음엔 관련된 문제를 찾아서 해결하는 방법을 생각해야한다.

스토리텔링

스타트업의 초기에는 수많은 사람과 대화해야한다 – 사용자, 투자자, 분야의 전문가, 초기 직원들, 그리고 기자들까지. 이 사람들의 가장 첫 질문은 “당신 스타트업은 무얼 하는건가요?”일것이고 당신의 스토리를 잘 전달하는게 첫번째 해결해야 할 문제다.

사람들은 스토리텔링에 반응하게끔 되어있다. 모든 스토리텔링엔 공통되는 구조가있다. 여기 픽사에서 사용하는 아주 간단한 스토리텔링의 법칙을 소개한다. 

Once upon a time there was ___. Every day, ___. One day ___. Because of that, ___. Because of that, ___. Until finally ___.

옛날옛날에 ___이 있었습니다. 매일 사람들은, ___ 을 했습니다. 그런데 어느날, ___. 그것때문에 사람들은 ___. 그리고 그것때문에 사람들은 ___. 드디어 사람들은 ___.

이 문장의 첫부분은 이미 정립된 환경이다. 세상은 이렇게 돌아가고있다고 정의하는 부분이다. 다음 부분(그런데 어느날)은 세상에서 일어나는 변화이다. 이런 변화는 당신의 스타트업과는 거의 관련이 없어야한다. 그런 변화는 당신이 스타트업을 하건 말건 일어나는 것들이다. 시장은 효율성을 따라 움직인다고 이미 이야기했다. 당신이 스타트업을 하지 않아도 그 변화에 대응하는 스타트업은 반드시 생겨날것이다. 그럼 당신의 목표는 그 시장에 어느정도 동작하는 제품을 제일 먼저 선보이는것이다. 결국에 그럼 당신이 시장을 장악하게 되어있다.

이 법칙에 맞추어 세상의 변화를 설명한 다음에야 당신의 제품과 회사에 대해 이야기 할수있다. 당신이 대응하는 여부와 상관없이 변화는 일어난다. 그저 당신이 그걸 제일 먼저 알아챘을뿐이다.

위 문장의 마지막 부분은 당신의 회사가 사람들의 삶을 어떻게 바꿀것인가 설명하는 것이다. 당신의 스타트업이 훗날 성장해 시장을 장악하게되면, 그 회사는 이제 다음번 환경의 변화를 일으키는 촉매가 된다. 이 방식으로 당신의 스타트업이 기술 혁신의 사이클을 완성하는것이다.

이게 성공적인 회사들이 스토리를 전달하는 방법이다. 사람들은 내연기관이 돌리는 차를 타왔다. 그러나 배터리 기술은 지속적으로 발전해 100% 전기 자동차를 가능케하는 수준에 이르렀다. 그러나 아직은 비싸기때문에 고급 차종으로 시작할것이다. 배터리기술이 좀 더 싸지면 보급형 차종으로 내려갈것이다. 그리고 결국에는 자동차 시장을 변혁해 길에는 전기차만 달릴것이다.

————————

역자주

사실 폴그레이엄도 스타트업 아이디어 블로그에서 외부에서 주어지는, 그래서 한편으론 창업자들이 어쩔수 없는 환경의 변화를 언급했다 (http://paulgraham.com/startupideas.html). 창업자들은 본인이 갖고있는 문제를 해결해야하고 처음엔 같은 문제를 경험한 소수의 그룹에만 솔루션이 어필한다는 것이다. 즉 구덩이를 좁지만 깊게 파 들어가야한다는 점이다. 그러나 폭발적인 성장이 이루어지려면(구덩이가 옆으로 넓어지려면) 외부적인 환경이 때마침 도와주어야 가능해진다. Slava는 이런 외부적인 변화까지도 예측하는것이 필요하다고 설명한다. 

위의 픽사 스토리텔링 공식에 맞추어 몇개의 성공 사례를 적어보았다. 간결하지만 정말 잘 예측하는 공식이다. 혹시 스타트업 아이디어를 갖고있다면 여러분도 이 공식에 한번 맞추어보는게 어떨까?

테슬라: 옛날옛날에 내연기관 자동차가 있었습니다. 매일 사람들은, 기름을 넣은 자동차를 탔습니다. 그런데 어느날, 배터리 가격이 충분히 싸졌습니다. 그것때문에 사람들은 비싼 전기차를 타기 시작했습니다. 그리고 그것때문에 사람들은 보급형 전기차를 타기 시작했습니다. 드디어 사람들은 전기차만 타기 시작했습니다.

인스타그램: 옛날에 디지털카메라가 있었습니다. 매일 사람들은 사진을 찍어 컴퓨터로 옮겼습니다. 그런데 어느날, 아이폰이 나왔습니다. 그것때문에 사람들은 전화기로 사진을 찍기 시작했습니다. 그리고 그것때문에 사람들은 사진을 인터넷에 공유하기 시작했습니다. 드디어 사람들은 매일 사진을 인터넷에 올리고 있습니다.

우버: 옛날에 택시가 있었습니다. 매일 사람들은 택시를 타고 목적지로 이동했습니다. 그런데 어느날, 스마트폰으로 사람들이 자신의 위치를 알릴수 있게되었습니다. 그것때문에 사람들은 자동차를 자신이 있는곳으로 불렀습니다. 그리고 그것때문에 자동차를 더이상 소유하지 않았습니다. 드디어 사람들은 이동할때 우버만 사용하게되었습니다.

스냅챗, Musical.ly: 옛날에 메신저가 있었습니다. 매일 사람들은 텍스트 메시지와 주위 경관 사진을 서로 교환했습니다. 그런데 어느날, 스마트폰이 좋은 품질의 프런트 카메라를 달았습니다. 그것때문에 사람들은 셀피를 찍기 시작했습니다. 그리고 그것때문에 셀피와 비디오를 교환하게 되었습니다. 드디어 사람들은 텍스트대신 미디어로 대화하게되었습니다. 

리더와 말

올해는 7명의 우주인이 목숨을 잃은 우주 왕복선 챌린져호 폭발 30주년이었다. 1986년 1월 28일 챌린져호의 발사과정은 CNN등 미디어에 생중계되었는데, 발사된지 채 몇분이 지나지 않아 폭발해 그날 미국인들은 우주인 7명의 죽음을 실시간으로 목격해야했다. 우주인 중에는 민간인 신분의 고등학교 선생님이 포함되어 있어서 전국의 학교들에서 아이들이 그날 발사를 시청하고 있었다.

CNN live 영상. 폭발은 1:30초 지점.

생중계로 우주인의 죽음을 목격해야했던 국민에게 레이건대통령은 6시간만에 급히 담화를 발표했다. 그런데 이날 레이건의 담화는 전 국민의 심금을 울리며, 훗날 <20세기 최고의 대통령 연설>로 꼽히는 명문이 되었다. 그날 연설의 일부분을 발췌해본다.

“I want to say something to the schoolchildren of America who were watching the live coverage of the shuttle’s takeoff,” Reagan said. “I know it is hard to understand, but sometimes painful things like this happen. It’s all part of the process of exploration and discovery. It’s all part of taking a chance and expanding man’s horizons. The future doesn’t belong to the fainthearted; it belongs to the brave. The Challenger crew was pulling us into the future, and we’ll continue to follow them.”

“챌린져호의 발사를 지켜보았던 아이들에게 해주고 싶은말이 있습니다. 이런 고통스런 일이 어떻게 일어났는지 이해하기 힘들다는걸 알고 있습니다. 그러나 이런 사고는 탐험과 발견을 하는 과정중 한부분입니다. 인류가 작은 가능성을 가지고 세상을 확장해하는 과정중 한부분입니다. 미래는 두려워하는 사람들에게 열려있지않습니다. 미래는 용감한 이들이 소유하는 것입니다. 챌린져호의 우주인들은 우리를 미래로 한걸음 더 당겨주었습니다. 우리는 그들의 발자취를 따라갈 것입니다.”

그리고 레이건은 현재 모든 미국인들의 뇌리에 남아있을 아름다운 표현으로 연설을 마무리한다.  2차대전중 비행사고로 사망한 미국 시인 John Gillespie Magee의 시에서 인용한 것으로 알려진 문장은 이렇다.

“… waved goodbye and slipped the surly bonds of Earth to touch the face of God.”

“(우주인들은)… 작별인사를 마치고 이 강한 중력의 속박을 벗어나 손을 내밀어 신의 얼굴을 만졌습니다.”

우리에게 이렇게 큰 충격을 준 역사적 사건은 세월호일 것이다. 생중계로 300명이 넘는 학생들의 죽음을 목격해야했던 국민은 몇날 며칠간을 속으로 울어야했다. 하지만 리더 박근혜는 국민 앞으로 나와 아무런 말도 하지않았다. 심각한 트라우마로 고통받는 국민을 향해 그가 했다고 <전해지는>얘기들은 “왜 구하지 못했느냐?”  “경제가 걱정된다”는 단편적인 감정의 표현일 뿐이다. 사고후 34일만에 정치적 압력에 떠밀려 담화를 발표했고 그마저도 <특검>, <처벌>, <부패>등 닳아빠진 표현으로 가득한 수준낮은 연설이었다. 34일을 준비한 말중 유일하게 사람들의 기억에 남아있는 표현은 겨우 이런것이다.

그래서 고심 끝에 해경을 해체하기로 결론을 내렸습니다.

레이건과 그 보좌진은 단 6시간만에 역사에 남을 말을 준비해 미 국민을 위로했다. 박근혜와 (최순실을 위시한) 보좌진은 34일간을 미루어놓은 말로 국민을 절망하게했다. 지난 대선전 부모님과 논쟁하면서 나는 절대 박근혜는 안된다고 했는데 그 이유는 하나 <말을 지독하게 못한다>였다. 말을 못하니 글을 못쓰는것은 말할 필요조차없다. 말을 못하는 것은 그 사람안에 표현할만한 지식이 없고, 그 빈약한 지식마저 정리가 되어있지않기 때문이다.

우리 부모님은 <말만 잘해서 무엇하냐?> 라고 고집을 꺾지 않으셨다. 그것은 틀리다. 리더에겐 말이 전부다. 잘 준비된 연설은 국민의 감정을 흔들어야하고, 즉흥적으로 기자나 시민들과 소통하는 말은 그 안에 통찰(insight)이 담겨있어야 한다. 리더의 머리 안에 아무리 대단한 내용이 담겨져있어도 표현하지 못하면 가치가 없다. 그러나 더 두려운점은 사실 표현하지 못하는 이유가 리더의 머리안에 내용이 없다고 암시하기 때문이다. 권위와 통제로 리더의 말을 따라가던 시대는 우리도 이미 몇십년전에 끝났다. 사람들을 웃게하고, 울게하고, 움직이게 하는 리더의 툴(tool)은 단 하나 <말>이다. 이점에서 박근혜는 한 국가의 리더로서 전혀 자격이 없다.

끝으로 미국의 이번 대선에서 인종주의자 도널드 트럼프를 가장 강력하게 막아냈다고 평가받는 미셸오바마의 <말>을 인용하며 나의 말을 마친다.

“I wake up every morning in a house that was built by slaves, And I watch my daughters, two beautiful, intelligent, black young women, playing with their dogs on the White House lawn.”

“나는 오늘 아침 그 옛날 흑인 노예들이 지었던 집에서 아침을 맞았습니다. 그리고 두 딸들 – 아름답고 지적인 두 흑인 아이들- 이 백악관의 잔디밭에서 강아지와 뛰어노는것을 봅니다.”

미셸오바마의 DNC 연설. 1분 지점부터 하이라이트.

https://twitter.com/sm_park

고난, 비전, 직업에 대한 이야기

(몇달전에 출석하는 작은 교회에서 나누었던 이야기를 copy&paste 해서 올려봅니다. 이미 페이스북에서는 공유했던 내용입니다)

안녕하세요. 저는 과분하게도 오늘 청년부 예배에서 말씀을 맡은 박상민집사입니다. 먼저 제 소개를 짧게 드리겠습니다. 저는 2010년에 동부의 University of Virginia에서 Computer Science로 박사학위를 마쳤고, 그 후 지금까지 미국의 스타트업 회사들에서 일하다가 현재는 Hewlett Packard에서 SW엔지니어로 일하고 있습니다. 조금 특이한것이 있다면 저는 5년째 출근을 하지 않고 집에서만 일을 합니다. 일년에 오피스 나가는 날은 열흘이 채 되지 않습니다. 그래서 어쩔수 없이 아이들 학교 등하교는 제가 담당하고 있습니다. 둘째아이를 유치원에 데려다주고, 픽업하는걸 제가 매일 하는데 백인 엄마들 사이에서 그렇게 하는 남자는 중국인 할아버지와 저 밖에 없습니다.

사실은 오늘 부탁을 받고 무슨 이야기를 해야할까 고민하느라 잠도 제대로 못잤습니다. 제가 목사님이 아닌데 설교를 할수도 없고  그렇다고 제 전공분야, 하는 일을 설명하자니 그건 또 밑도 끝도 없는 이야기가 될것이고… 그래서 제가 오늘 나누는 이야기는 짧지만 여러분보다 10년정도 세상을 더 산 교회아저씨의 <개똥철학> 정도로만 들어주시면 감사하겠습니다. 성경말씀도 중간중간 나누겠지만, 제 이야기는 진리이신 성경 말씀과는 비교할 수 없는, 오로지 경험에 기초한 이야기임을 먼저 밝힙니다.

제가 오늘 할 이야기는 공부와 직업 그리고 그것을 우리 인생에 심어주시는 하나님에 대한 것입니다. 저는 제 자신을 돌아봤을때 감사할 것이 정말로 많습니다. 훌륭한 부모님을 주셨고 착하고 예쁜 아내도 교회에서 만나서 겨우 스물다섯살에 결혼을해서 함께 유학을 왔습니다. 아내보다 더 예쁜 세딸도 주셨습니다. 그리고 제가 감사하는것중 하나는 제 직업입니다. 저는 제가 하는 일 — 소프트웨어 만드는것– 을 정말 좋아하고 사실은 꽤 잘합니다. 잠을 일찍자고 일찍 일어나는 편인데 새벽 5시에 일어나 커피를 가득 내려 마시면서 코딩하는 것만큼 즐거운것이 없습니다. 낮엔 직장일을 하지만, 새벽엔 취미삼아, 공부삼아 개인적인 프로젝트를 꾸준히 만듭니다. 저를 길이나 스타벅스에서 혹시 만났는데 먼데를 응시하고 있다거나, 혼자 중얼중얼대고 있다면 ‘아 저 사람이 지금 머리로는 프로그래밍 중이구나. 건드리지 말아야겠다’ 생각하시면 됩니다. 교회에서 제 인상이 험악해 보이거나 아파보이면 ‘아 박집사가 지금 버그를 잡고 있구나’, 이렇게 넘어가주시면 감사하겠습니다.

세상엔 자기 여가시간에 취미삼아서 일을 계속하는 사람이 많지 않습니다. 생각해 보세요. 직장 끝나고 취미삼아 일 더하고 가는 사람들이 얼마나 될까… 예를들어 그로서리 QFC에서 일을 한다면, 주말에 취미삼아서 일을 더하러 나오겠습니까? 저는 이런 제 직업을 하나님이 내게 주신 선물, 더 나아가 사명이라고까지 생각합니다. 그러나 처음부터 그렇게 생각한것은 아닙니다.

고난과 하나님의 계획

한때 <아프니까 청춘이다>라는 책이 한국에 유행한적이 있습니다. 그런데 책보다 현실이 더 고달픈 청년들은 “아프면 환자지 어째서 청춘이냐?” 라고 반박을 하기도 했었죠. 그런데 현실적으로 학교와 취업등에서의 고난은 우리가 10, 20대를 지나면서 반드시 겪게 되어 있습니다. 제가 아는 어떤 사람도 고난없이 30대, 40대의 어른이 된 사람이 없습니다. 이러한 어려움은 예상치 못하게 폭풍처럼 찾아오는데, 고난가운데 빠지게 되면 그 순간엔 오로지 그곳에서 빠져 나오기 위해 몸부림을 치지 고난의 이유가 무엇일까에 대해선 생각할 겨를이 없습니다.

스티브잡스가 죽기 얼마전 스탠포드에서 한 졸업식 연설은 아주 유명합니다. 거기에서 잡스는 인생의 중요한 포인트를 하나 집었습니다. 자신의 삶을 돌아보니 고난들이 <점>과 <점>처럼 찍혀 있는데 성공의 순간과 그 고난의 점들이 연결되어 있더라라는 것입니다. 예를들어 그가 학교를 자퇴하고 청강한 과목에서 배운 Calligraphy (글씨를 아름답게 쓰는것) 가 후에 애플컴퓨터의 혁신적인 폰트가 되는것 말이지요. 무신론자였던 잡스는 논리로 설명하기 힘든 이 현상을 Karma-운명 , 숙명등의 단어로 표현합니다. 그러나 우리는 이것을 <하나님의 계획, 섭리> 라고 부릅니다.

저는 지금까지 살면서 세번정도 큰 어려움을 겪었습니다. 다 소개하기엔 시간이 부족해서 첫번째 이야기는 스킵하고 두번째, 세번째 이야기만 나누겠습니다. 첫번째 이야기는 제가 어떻게 군대를 안가게 되었나 스토리입니다.

두번째는 고난 이라기보다는 황당한 고집에 대한 이야기입니다. 지금은 어떤지 모르겠지만 저희때는 대학입시에서 4개의 학교를 선택할 수 있었습니다. 보통 1개 학교는 가고싶지만 성적이 조금 모자란곳, 1-2개는 가고 싶고 성적도 충분한 곳, 마지막은 성적은 남아도는데 가고싶진 않은곳을 고릅니다. 제게는 가고 싶고 성적도 충분한 곳이 한양대학교였습니다. 저는 사실 고등학교때 인문계였습니다. 그래서 컴퓨터나 공대는 관심이 없었고, 갈수도 없었습니다. 제 관심은 영문학쪽에 있었습니다. 한양대 영문학과는 점수도 충분하고 제가 가고 싶은 곳이기도했습니다.

입시의 과정엔 논술시험과 면접이 있습니다. 어떤 학교는 논술만보고 어떤곳은 두가지 모두 필요했습니다. 한양대 캠퍼스에 논술 시험을 보러 갔는데 논술을 나름 잘 써내고 마치는 찰나였습니다. 시험 조교가 이렇게 마무리를 했습니다: “여러분 다음주에 있는 면접도 다들 잘 보세요.” 그런데 저는 이때까지 한양대는 면접이 없다고 생각했습니다. 정상적인 사람이라면 ‘어, 내가 잘못 알았나?’ 확인해야 하지만 저는 정상이 아니었습니다! ‘저 조교는 준비가 덜 됐네’ 생각했습니다. 그래서 면접을 가지 않았고 당연히 입시에 떨어졌습니다. 내 계산대로라면 당연히 가야하는 학교, 전공이었는데말이죠.

결국 어쩔수없이 선택한 곳은 아주대학교 인문학부였습니다. 아주대는 컴퓨터나 공대가 괜찮은데 인문학은 별로라서 실패한 기분이었습니다. 그런데 아주대학교가 그때 한국에서 한가지 아주 특별한것이 있었습니다. 무제한 전과 (transfer) 제도입니다. 전공을 바꿀수 있는 제도입니다. 심지어 인문계에서 이공계로도 전과가 가능했습니다. 그리고 1년후에 저는 컴퓨터가 좋아졌습니다. 그때 인문계에서 이공계로 전공을 바꿀수 있는 학교는 한국에 한곳 아주대 뿐이었습니다. 그리고 아주대의 컴퓨터 전공은 꽤 실력이 좋은 곳이었습니다.

여기에서도 하나님은 보너스를 하나 남겨놓았습니다. 저는 컴퓨터를 나름 잘하지만, 사실 사람들 사이에선 글 잘쓰는 블로거로 더 유명합니다. 책 읽기, 글쓰기 좋아하는 인문계의 소질은 하나님이 제게 남겨놓은 보너스 입니다.

세번째 고난은 유학중에 겪었습니다. 박사과정의 가장 힘든것중 하나는 퀄시험이라 불리는 전공시험입니다. 퀄 시험을 2번 실패하면 학교에서 나가야 합니다. 흔히 <피똥싼다>고 표현하는 시험인데 저는 피똥을 여러번 쌌습니다. 유학을 나와보니 주변에 수재들로 가득했습니다. 특히 중국에서 온 친구들은 스펙들이 대단했습니다. 어떤 친구는 중국 어디 성 대학입시에서 2등했다고 합니다. 근데 그 성 인구가 1억명입니다.

첫해에 시험을 보았습니다. 여러개 과목에서 15개 정도의 문제가 출제됩니다. 처음 시험에서 제가 몇문제를 맞추었을까요? 정답은 한문제도 맞추지 못했다입니다. 공부가 조금 부족하긴 했지만, 설마 백지를 내고 시험장을 나가리라곤 상상도 못했습니다. 교수에게 답안지를 돌려주며 혹 백지인것을 들킬까봐 얼마나 창피했는지 모릅니다. 그래도 몇달간 도서관에서 공부만 했는데, 백지라니… 아마 지금껏 살며 가장 절망한 날이 그날이었던것 같습니다. 집에 돌아와 어떻게든 위로해보려는 아내를 뒤로하고 혼자 침대에 누워 별의별 생각을 다 했습니다. 여러분 <기쁨>의 반대말이 무엇인지 아십니까? <슬픔>이 아니고 <절망>입니다. 희망이 없음입니다. ‘그깟시험 다시 한번 잘 준비하면 되지 뭘 그래’라고 생각할수도 있을겁니다. 하지만 객관적으로 나 자신을 평가했을때 내 계산으로는 도저히 시험을 패스하는것이 불가능했습니다. 사람의 계산에서는 절망이 나옵니다.

하나님의 계획이 이렇게 허무할리 없다는 믿음으로 다시 공부했습니다. 9개월 후 시험이 마지막 기회라서 그때는 정말 도서관에서 살았습니다. 머리가 나빠서 이해가 안되니까 큰 전공책 여러개를 통째로 외웠습니다. 그 당시 아내가 큰 애 수안이를 임신했는데 배 나온 아줌마가 싸온 도시락을 도서관에서 같이 까먹으며 공부했습니다. 시험날이 가까워오는데 신물나게 공부하고 또 하니까 이제 될것 같았습니다. 그리고 시험날엔 꽤 괜찮게 답안지를 써냈습니다. 이만하면 됐다고 생각했습니다. 결과가 어떻게 됐을까요?

또 떨어졌습니다. 지도교수의 말로는 거의 근접했는데 아쉽게도 탈락이라고합니다. 그런데 다행히 저를 좋게 봐주었던 지도교수가 구원의 손길을 내밀었습니다. 교수회의에서 삼세판을 강력하게 주장해 예외적으로 한번 더 기회를 준것입니다. 그리고 몇달후에 결국은 시험에 합격했습니다. 몇달간 더 공부를 했지만, 사실 두번째 시험과 세번째 시험 사이에서 실력의 향상은 없었습니다. 다만 한가지 바뀐 중요한 마음의 자세가 있습니다. 그것은 하나님의 계획에 대한 신뢰입니다. 두번째까지는 내가 최선을 다 했으니 성공해야한다는 믿음이 나를 지배하고 있었습니다. “이것이 하나님의 계획이어야 한다”는 내 의지가 믿음이었습니다. 그러므로 내 의지가 실패했을때는 강한 절망이 지배할수 밖에 없었습니다.

하지만 두번째의 실패후에 마음에 찾아온것은 뜻밖에도 평안이었습니다. (어렸을때 병원에 누워서 누렸던것과 비슷한 평안입니다). “이것이 하나님의 뜻이 아닐수도 있다. 그럼에도 불구하고 나는 기쁠것이다”. 한번이나 두번만에 합격했다면 이 중요한 진리를 발견하지 못했을것입니다. 때론 머리나쁜것이 진리로 인도하는데 쓰이기도 합니다. 우리의 의지가 실패해 절망에 빠지려할때, 그래서 이 익숙한 말씀이 우리를 보호하는 것입니다.

<항상 기뻐하라 쉬지말고 기도하라 범사에 감사하라. 이것이 그리스도 예수 안에서 너희를 향하신 하나님 뜻이니라> 데살로니가전서 5:16

그리고 이번 역시 하나님은 고난 후에 보너스를 예비하셨습니다. 시험에 떨어져 학교를 떠나게되면 석사 학위라도 받아야 하니까 관심에도 없던 수업 하나를 학점을 채우려 들었습니다. 그리고 그 수업에서 배운 이론을 제 분야에 적용해 학술대회 최고논문상 후보에도 오르고, 그것으로 박사 논문까지 잘 마치게 됩니다.

어쩌면 여러분중에 지금 고난가운데 있는 사람도 있을것입니다. 혹 지금이 아니더라도 분명 여기 모두는 고난을 겪여 봤고, 또한 앞으로도 많이 겪을것입니다. 스티브잡스와 같은 무신론자 역시 이러한 고난이 무작위의 현상이 아니라 미묘하게 미래와 연결되는 인생의 점과 점이라는 사실을 인정합니다. 그는 성공한 다음에야 과거를 돌아보고 고난의 가치를 알수 있다고 이야기합니다. 하지만 하나님을 믿는 우리는 다릅니다. 고난가운데 있어도 아니면 미래에 겪을 고난에 대해서도 우리는 그 의미를 말씀을 통해 알수 있습니다.

<나 여호와가 말하노라 너희를 향한 나의 생각은 내가 아나니 재앙이 아니라 곧 평안이요 너희 장래에 소망을 주려하는 생각이라. 너희는 내게 부르짖으며 와서 내게 기도하면 내가 너희를 들을것이요 너희가 전심으로 나를 찾고 찾으면 나를 만나리라> 예레미야 29:11-13

비전

우리가 교회에서 가장 자주 사용하는 단어중 하나는 <비전>입니다. 그런데 사실은 세상에서도, 특히 젊은 사람들이 가장 자주 듣는 단어 역시 <비전>입니다. “비전을 가져라. 큰 꿈을 품어라” 자주 듣는 말이지요. 그러면 요즘 세대에서는 이렇게 얘기합니다: “제 비전은 공무원입니다”. 그만큼 우리는, 한국의 젊은이들은 불확실성의 시대를 살고 있고, 조금이라도 확실한 것을 붙잡아보려고 애씁니다.

그런데 사실은 비전의 의미를 잘못 해석해서 붙들고 있는 경우가 많습니다. 비전의 사전적인 의미가 무엇인지 아십니까? Merriam-Webster를 보면 이렇게 나옵니다.

1) 눈으로 보는 것 (그래서 안과를 vision 이라고 이야기하죠)
2) 상상하는것, 꿈을 꾸는 것 (흔히 지칭하는 비전이 이것입니다).

즉, 지금 시점에서 눈으로 보고 있는것과 미래에 이루어질 것을 상상하는 것이 <비전>의 두가지 의미입니다. 그리고 사실은 이 두가지 의미는 서로 연결되어 있습니다. 다시 말해서, 미래에 이루어질 꿈은 지금 눈으로 보는 그것이라는 사실입니다. 성경에서 비전의 의미가 가장 생생하게 드러나는 곳이 요한계시록입니다. 앞으로 있을 미래의 일을 사도 요한이 지금 시점에서 보고 이것을 기록한것이 요한계시록이니까요.

그래서 “저는 공무원이 비전입니다” 이렇게 이야기를 하는 사람이 있다면 그 사람은 동사무소에서 서류 발급해주는 직원을 눈으로 보면서 ‘이게 나의 미래구나. 신난다!’ 이렇게 속으로 소리쳤을 사람입니다. 혹시 그게 아니라 <삼포세대, 취업률 50%도 안돼, 취업하자마자 명예퇴직…> 이런 소문을 귀로 듣고 공무원을 꿈으로 삼았다면, 그건 비전이라고 이야기할 수 없습니다. 사회의 현상을 부모님 통해, 친구를 통해 귀로 들었지, 자기 미래의 모습을 아직 눈으로 본적이 없기 때문입니다.

제가 미래의 제 모습을 본 것은 2003년 이었습니다.  그당시 저는 아주대학교 대학원에서 석사를 공부하고 있었습니다. 공부를 좋아해서가 아니라 사실 학부때 성적이 안 좋아서, 석사학위라도 받으면 대기업에 가기 수월하니까 공부했습니다. 컴퓨터와 프로그래밍은 좋아하고 잘 했는데 시험만 보면 성적이 안좋았습니다. 특히 인문계 출신이라 그런지 수학, 물리같은 기초 과학과목은 C가 최고 점수입니다.

그런데 마침 저희학교에서는 정부의 지원을 받아 학생들이 재학기간중 한번 외국의 컨퍼런스에 연수를 가는 제도가 있었습니다. 제가 몇명 친구들과 같이 간곳은 스코틀랜드의 에딘버러라는 아름다운 도시입니다. 이곳에서 <글로벌 그리드 포럼>이라는 그당시 막 떠오르던 컴퓨터 기술 컨퍼런스가 열린다고해서 정말 아무 기대없이 구경하러 갔습니다. 그렇게 연수를 가면 지원금이 꽤 많이 나오는데 사실은 공짜관광하러 가는것이었습니다. 괜히 중간에 런던에 들른다거나 말이죠.

그 컨퍼런스 첫날 제 시선을 사로잡은 한가지 광경이 있었습니다. 그것은 컨퍼런스장 복도에서 아무렇게나 앉아 노트북을 켜놓고 뚫어져라 집중하던 사람들이었습니다. 가까이가서 보니 검은 스크린에 떠오르는 하얀 문자들을 두드리고 있는 그 사람들은 연구소, 학교에서 나온 프로그래머들이었습니다. 회의장 안에서는 정부기관, IBM같은 회사에서 나온 잘 차려입은 높은 사람들이 미래의 기술에 대해 설명하는데 후줄근한 티셔츠입은 이 사람들은 그런것엔 그다지 관심도 없고 그냥 노트북속 코드에만 집중하고 있었습니다. 함께 다녀왔던 여러명의 동료들에겐 그 모습이 전혀 인상적이지 않았지만, 제게는 달랐습니다.

거기서 미래의 제 모습을 본 것입니다. 마치 카메라로 찍은것처럼 그 순간을 찍어서 그 사람이 아닌 내가 그 자리에 노트북을 들고 앉아있는것을 상상한 것입니다.

그리고 학교에 다시 돌아와서 남은 1년반동안 집중한것은 박사과정 유학이었습니다. 한국인이 미국의 연구소에서 그 사람들처럼 일하기 위해서는 미국 학교에서 박사학위가 필요하기때문입니다. 사실 저희 학교 – 아주대학교 –는 유학을 많이 보낼만큼 유명한 곳이 아니었습니다. 그리고 더더욱 문제는 제 학점이 3.0이 채 안된다는 사실입니다. 유학관련 사이트를 뒤져보니 몇년간 제 학점으로 유학간 사람은 거의 없었습니다. 돈을 많이 내고 석사유학을 가는 몇가지 경우가 전부였습니다. 제가 유학을 가는 유일한 방법은 논문을 외국의 교수들이 알만한 유명한곳에 출간하는것이었습니다. 그래서 고작 석사 1년차인데 무작정 덤볐습니다. 컴퓨터 프로그램을 만들고, 실험을 하고, 논문을 쓰고…교수님이 지도하면서도 “안될텐데…” 말리는걸 그냥 우겨서 보냈습니다.

그리고 실제로 상상하던 일들이 일어났습니다. 좋은 곳들에서 논문이 채택되고, 논문을 읽고 추천한 교수들에게 박사 어드미션을 장학금과 함께 받았고 한국에서 6만불짜리 국가장학금까지 캐쉬로 챙겨서 유학을 나왔습니다. 물론 아까 소개한대로 몇달후에 피똥싸는 경험을 하게 되지만요. 그리고 졸업후에 처음 취직한 스타트업 회사는 그때 그 컨퍼런스에 앉아있던 사람들이 창업한 회사입니다. 제가 눈에 보았던 그 모습 그대로 그 사람들과 후줄근한 티셔츠입고 컴퓨터와 씨름하는 사람이 된 것입니다.

여러분, 비전은 소문을 듣는 것이 아닙니다. 다른 사람으로부터 전해듣는 세상의 현실이 아닙니다. 바로 여러분 눈으로 직접 보고 마음속에 사진처럼 찍어놓는 것입니다.

직업의 목적

몇주전 인공지능 알파고가 큰 뉴스거리였던걸 기억하실겁니다. 곧 세상이 인공지능 중심으로 돌아갈 것이라는 전망이 파다했죠. 컴퓨터를 전공한 제 관점에서 판단하면, 그러한 전망은 아마도 사실일것입니다.  인터넷이 모든 종류의 정보에 접근하게 만들었다면 인공지능은 곧 그 정보들을 사용해 사람보다 더 정확한 판단을 내리게 될 것입니다. 그럼 영화 터미네이터에 나오는 스카이넷이 곧 사람들을 지배하게 되는건가? 라고 묻는 사람들이 많습니다. 여기에 대한 답은 이 질문을 생각해보면 알수 있을것 같습니다. 과연 로봇이 “나는 누구인가? 나는 왜 존재하는가?” 질문을 던질수 있을까? 만일 사람이 지성과 감성만으로 이루어진 존재라면 그럼 로봇역시 이 질문을 언젠가 스스로 던질것입니다. 나의 존재 목적을 묻는것이 지적인 활동의 클라이막스라면 사람의 지성을 그대로 따라하는 알파고 역시 이 질문을 언젠가 할 것입니다. 어쩌면 그게 인류의 마지막이 될지도 모르고요.

그러나 우리는 이것이 그저 상상인것을 압니다. 왜냐하면 <나는 누구인가>라는 이 질문은 영적인 영역이기 때문입니다. 즉 우리가 그저 뇌세포들의 상호작용으로 모델링할수 있는 로봇이 아니라, 그 이상으로 하나님의 형상을 닮은 존재이므로 이 질문을 던지는 것입니다. 그리고 개신교 신앙의 핵심인 웨스트민스터 신앙고백에선 이렇게 답을 합니다.

Q: 사람의 첫째되는 목적은 무엇인가?
A: 하나님을 영화롭게 하는것과 영원히 그를 즐거워하는 것이다 (Man’s chief end is to glorify God and to enjoy Him forever).

20대에게 가장 큰 걱정은 당장 눈앞에 닥친 취업일 것입니다. 그러나 아마도 시간이 지나서 30대가 되면 여러분 모두 안정적인 직장생활을 하고 행복한 가정을 꾸리게될 것입니다. 저 역시 남들이 보기에 부러워할만큼 그런 직장과 가정 생활을 하고 있습니다. 그럼 모든 문제가 해결될까요? 아니요 그렇지 않습니다. 아침에 깰때도 밤에 잠들때에도 여러분은 이 질문을 하게될 것입니다. ‘내가 존재하는 목적은 무엇인가?’ 우리는 낮시간 대부분을 일하는데 보내므로 결국 이 질문은 ‘내가 일하는 목적은 무엇인가?’ 입니다. 저 역시 이것에 명쾌한 답은 아직 못 찾았습니다. 다만 웨스트민스터 고백이 어렴풋하게나마 중요한 푯대가 되어줍니다.

하나님을 영화롭게 하는것과 영원히 그를 즐거워하는 것이다.

흔히 꿈을 이야기하라면 <꿈의 직장>을 댑니다. <구글>, <페이스북>, 한국에서는 <삼성>, <몇급 공무원>. 남들이 부러워할만큼 좋은 직장의 좋은 타이틀을 가지게되면 얼마동안 행복할까요? 우리는 다 경험해봐서 압니다. 한두달 지나면 무덤덤해지고 만족스럽지 않습니다. 40대, 50대가 되서 아직 <내가 삼성맨이야!> 떵떵거린다면 주위에서 다들 불쌍하게 쳐다볼것입니다. 그러나 우리가 중요하게 여겨야 하는것은 <직업> 입니다. 직업과 직장은 다릅니다. 저는 소프트웨어 만드는것이 직업입니다. 이것은 아마 평생 변하지 않을 것입니다. 그러나 직장은 그동안 여러번 바뀌었고 앞으로도 그럴겁니다.

제가 천국에 가면 하나님은 저를 <직장>을 가지고 평가하지 않을것입니다. “너는 왜 구글에 못갔니?” 라고 묻진 않으실겁니다. 그러나 제 <직업>을 가지고는 평가하실 것입니다. 그것이 제게 주신 사명이고 달란트이기 때문입니다. “너는 내가 준 직업의 10 달란트를 가지고 무엇을했니?” 라고 찾으실 것입니다. 제 직업은 소프트웨어를 <창조>하는 것입니다. 제가 하나님을 닮았기때문에 하나님이 사람을 창조했듯, 소프트웨어를 <창조>하는 능력이 제 안에 있습니다. <그를 즐거워하는 것이다>라는 웨스트민스터의 답 그대로 내게 주신 이 능력을 저는 즐거워합니다. 매일처럼 새벽에 코딩하는 이유는 이 능력이 즐겁기 때문입니다. 저는 제 직업이 <하나님을 영화롭게> 하는 수준에 다다르기 원합니다. 부끄럽게도 그러나 아직은 그 수준에 미치지 못합니다. 그저 직장에서 동료에게나 인정받는 수준입니다. 그러나 매일 여가시간에 코딩하는 이유는 언젠가 나의 실력이, 나의 결과물이 <하나님을 영화롭게> 하고싶기 때문입니다.

pieta

Pietà, 1498-1499

2년전에 아내와 결혼 10주년으로 로마에 갔었습니다. 바티칸 대성당에가서 곳곳의 예술작품들을 넋을 잃고 바라봤었습니다. 특히 미켈란젤로가 24살에 조각했다는 피에타는 그곳을 떠나지 못하고 바라볼만큼 아름다웠습니다. 잘 아시죠? 마리아가 예수님의 시신을 안고있는 조각상. 예수님의 죽음을 그렇게 생생하고 또 아름답게 묘사할수 있었던것은 이미 10년이상 수련한 미켈란젤로의 재능이 몇년간 공을들여 디테일을 완성했기 때문입니다. 그의 직업의 결과물은 바티칸 대성당에서 수백년째 하나님을 영화롭게하고 있습니다. 저는 제 직업의 결과물역시 그렇게 하나님을 영화롭게 하는 작품이 되길 원합니다. 그것을 위해서 수련하고 또 남들이 안보는 디테일까지 최선을 다하는 것입니다. 이 자리에 있는 우리 청년들 역시 여러분의 직업을 하나님의 선물로 여겨 즐거워하고, 또 그것으로 작품을 만들어 하나님을 영화롭게 하길 바라며 오늘 말씀을 마칩니다. 감사합니다.