코딩 인터뷰 – 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년이상 수련한 미켈란젤로의 재능이 몇년간 공을들여 디테일을 완성했기 때문입니다. 그의 직업의 결과물은 바티칸 대성당에서 수백년째 하나님을 영화롭게하고 있습니다. 저는 제 직업의 결과물역시 그렇게 하나님을 영화롭게 하는 작품이 되길 원합니다. 그것을 위해서 수련하고 또 남들이 안보는 디테일까지 최선을 다하는 것입니다. 이 자리에 있는 우리 청년들 역시 여러분의 직업을 하나님의 선물로 여겨 즐거워하고, 또 그것으로 작품을 만들어 하나님을 영화롭게 하길 바라며 오늘 말씀을 마칩니다. 감사합니다.

 

회의 시간에 똑똑해보이는법 9가지

(재미있길래 퍼와서 가볍게 번역했습니다. 원글은 여기에서…) https://techcrunch.com/2016/09/30/9-tricks-to-appear-smart-in-brainstorming-meetings/

1. 물마시러 나가면서 필요한거 없냐고 묻는다.

사람들은 당신이 친절하고 사려깊다고 생각하느라 10분간 어디에서 놀다오는지 잊는다.

2. 미팅중 포스트잇에 그림을 그려라.


사람들이 주제를 가지고 이야기하기 시작할때 미리 준비한 포스트잇에 아무 그림이나 그리기 시작한다. 사람들은 갑자기 준비안된 자신을 생각하며 당황해할 것이다.

3. 너무 단순해서 깊이있어 보이는 비유를 들어라.


사람들이 문제에 대해 토론을 시작할때 뜬금없이 비유를 들어가며 문제와 연결시켜라. 예를들어 문제를 빵굽기에 연결시켜 “자 여기 빵이 있습니다. 빵에는 크림이 필요하겠죠? 우리에게 크림은 뭘까요” 이런식이다. 사람들은 당신이 문제의 깊은 곳까지 바라본다고 착각하지 설마 그냥 크림빵이 먹고싶은거라고는 생각하지 않는다.

4. “우리가 과연 맞는 질문을 하는 걸까요?” 라고 물어라.


당신이 똑똑해 보이게하는 최고의 질문은 질문 자체에 대해 질문하는것이다. 혹 누군가 “그럼 맞는 질문이 뭘까요?” 물으면 “그냥 확인을 하고 싶었습니다”라고 넘겨라.

5. 관용적인 표현을 써라.


아이디어에 대해 관용구를 써서 질문을 하면 똑똑해보이는데 효과적이다. “돼지목에 진주 목걸이 아닐까요? 입에 거미줄 치는건 아닐런지… 이거 발 디딜틈도 없겠군요!” 이런식으로 하면 된다.

6. 독특한데 창의적으로 보이는 습관을 만들어라.


당신 심연의 생각을 다 끌어내는것처럼 보이는 그런 습관을 만들어라. 이를테면 복도를 계속 왔다갔다 한다거나, 같은 자리에서 계속 뛰든지, 벽에다 공을 계속 던지는것도 괜찮다. 온몸을 다해 당신이 생각중이란걸 표현하면된다.

7. “CEO는 이렇게 생각할텐데…” 라고 말하라.


사람들이 당신이 CEO와 가깝다고 믿게끔 하는게 포인트다. “사장님은 이렇게 생각했을것 같은데…” 혹은 “아 그 아이디어 좋네요! 사장님이 좋아할거 같은데요.” 이런식으로 대화하면 사람들은 당신이 CEO 라인에 있구나 생각할거다.

8. “우리가 지금 맞는 모델을 세우는겁니까?” 라고 질문하라.


모델, 프레임워크, 아키텍춰 이런 단어들을 사용하면 사람들은 당신이 문제를 앞서 나가는, 큰 그림을 그릴줄 아는 사람이라고 생각할것이다. 사람들의 이야기를 이해할수 없을때마다 “그게 맞는 모델일까요?” 질문하면된다.

9. 사람들이 아이디어에 거의 동의하는거 같으면 “합시다!” 라고 먼저 말하라.


눈치를 봐서 사람들이 어떤 아이디어를 모두 좋아하는거 같으면 크게 “합시다 (ship it)!” 제일먼저 외쳐라. 물론 사람들은 웃게되겠지만 무의식적으로 당신이 회의의 결론을 내는 사람인것처럼 여길것이다.
http://twitter.com/sm_park

소프트웨어와 돈

소프트웨어로는 돈 벌기가 쉽다. 최근 수십년간 새로 탄생한 억만장자들은 모두 소프트웨어로 돈을 벌었다.


포브스 세계의 부자 랭킹을 보면 1, 2위의 빌게이츠, 제프베조스 모두 소프트웨어로 시애틀에 큰 기업을 만든 사람들이다. 그리고 12위 안에 페이스북, 구글, 오라클의 창업자 6인이 부자리스트의 절반을 차지하고 있다.

이 사람들은 모두 1. 아이디어를 생각하고, 2. 아이디어를 실행하고, 3. 주변에서 도움 약간 (펀딩, 직원..)을 받았을 뿐이다. 몇년후에 이 사람들이 만든 소프트웨어는 전 세계 수십억의 인구가 사용한다.

지금은 사람들이 이것없이는 살수 없을만큼 생활의 필수품이 되었지만 그 당시 윈도우즈가 없을때, 페이스북이 없을때 ‘이런걸 만들어야지’ 라고 아이디어를 떠올리며 이들에게는 얼마나 그게 당연하게 (obviously) 보였을까.

그래서 내가 “소프트웨어로 돈 벌기 참 쉽다, 그죠~” 이렇게 말하면 전세계 프로그래머들이 다 이렇게 반응할것이다.


소프트웨어를 만들어 파는건 최악으로 어렵다. 이미 잘 나가는 회사의 월급쟁이는 일단 이야기에서 제외해본다. 이야기는 소프트웨어로 부자되기에 대한 것이니까.

소프트웨어로 스타트업을 하거나 능력있는 사람이 1인 기업을 해보면 이게 얼마나 어려운 일인지 알수있다.

다른 종류의 노동은 대개 시간과 일의 가치에 따라 값을 쳐준다. 몸을 쓰는 노가다를 해도 8시간 일하면 30만원은 받아야한다. 식당을 차리고 음식을 내놓으면 원가에 이익을 더해 값을 매기지만 사람들은 기꺼이 지불하고 먹는다.

그런데 하루종일 단내나게 일을 해도 사람들이 천원이라도 내고싶은 제품은 만들어지지 않는다. 아마 능력자가 한달 내내 일을 한다면 그럴듯하게 동작하는, 예를들어 앱스토어에 넘쳐나는 사진 필터링 앱 정도 만들어낼수 있을것이다.

그리고 그걸 팔면 얼마나 돈을 벌까? 아마도 십만원 정도 벌면 주변에서 “괜찮은데 나도 해볼까” 이런 이야기를 들을것이다.


하루에 8시간씩 일한다고 치면 한달에 160시간 일하고 10만원을 벌어보자. 그럼 시간당 일당이 600원이다. 사발면 한개 사먹기도 힘들어 시발 소리가 나올것이다. 

나는 지금 직장을 다니며 개발을 해주면 한달에 꽤 많은 돈을 번다. 그런데 내가 어느순간 ‘내일을 할거다’ 생각해 직장을 나와 소프트웨어를 만들어 팔기 시작하면 시간당 사발면 한개값 벌기도 힘들어진다. 호텔 식당에서 일하다가 자기 식당을 차리는 쉐프들은 이렇지 않을것이다.

소프트웨어로의 창업은 모 아니면 도가 된다. 그런데 윷가락을 20개쯤 던져서 모가 나와야한다.

그런데 그 이유는 생각보다 분명하다. 내가 한달내내 죽어라 일해 소프트웨어를 만들면 솔직히 아이디어와 퀄리티가 거지같기 때문이다. 예를들어 앱스토어에 넘쳐나는 사진 필터링 앱을 만들었는데 버튼이 사진 가운데 붙어있거나 이런식이다. 미치거나 변태가 아닌 이상 이런 앱을 사줄 사람이 없다. 호텔에서 일했던 쉐프는 자기 식당을 차려도 호텔 비스무리한 맛이 나오니까 장사가 되겠지만 대기업 개발자가 몇달 내내 뭔가를 만들면 아무짝에도 쓸데없는 앱을 만들 가능성이 높다.


에픽 게임즈를 만든 전설적인 게임 개발자 팀 스위니가 한 말이다. “소프트웨어를 팔아서 2만원 벌기까지 16,000 시간을 취미로 코딩해야했다”.

나는 말콤글레드웰이 <아웃라이어>에서 이야기한 1만 시간의 법칙이 소프트웨어에 해당된다고 생각한다. 1만 시간 이상을 직업으로서가 아니라 순전한 호기심으로, 취미로 시간을 쏟은 개발자만이 직장인에서 창업자로, 번데기에서 나비가 날아가는 그런 변화를 경험할수 있다.

5년간 하루 8시간씩 순전히 어떤것에 몰두해있을때 그때서야 나는 개발자중 한사람이 아니라, 특별한 한사람이 될수 있을것이라 믿는다.

그럼 나는 그때에서야 순전히 내가 만든 소프트웨어로 2만원을 벌것이다.