2016년 7월 19일 화요일

Salary Negotiation 준비편 - 올해의 업무 실적 정리 2편

안녕하세요.

오늘은 지난 포스팅에 이어서, 올해 연봉 협상시 사용한 주요 실적 중 세번째 내용을 적어볼까 합니다.

사실 이 성과는 6월에 발생한 건으로 이번 연봉 협상에 제 실적으로 반영이 될 내용은 아니기에, 본인 스스로 작성하는 self evaluation에는 그 내용을 직접 언급하지는 못했습니다.

하지만 사람이라는 동물의 기억과 느낌은 아무래도 최근의 이벤트들이 좀 더 강렬하게 다가올 수 밖에 없습니다. 마치 연초 흥행작보다 연말 흥행작이 대종상이나 아카데미 시상식에 더 큰 영향력을 미치는 것 처럼 말이죠. 그래서 제 스스로 문서상 기술을 하지는 않았지만 협상 과정에서 몇 번 언급은 될 수 밖에 없었고 연봉 결정에 영향을 주었습니다.

6월 어느 날, 지난 삼성 이슈에서 같이 일했던 OEM Relationship 담당자로부터 전화가 와서 이런 저런 이야기들을 했습니다. 주요 내용은 보안 이슈 때문에 MDM App의 인증 과정 중 크리티컬 한 프로세스 하나가 긴급히 변경 될 것이고, 변경될 모델 범위는 러프하게 잡아도 Galaxy S3 이후 모든 단말이 될 것이라는 소식이였죠. 그리고 올 해 8월부터 시작될 펌웨어 변경 이후에는 기존 당사의 MDM 앱들은 업데이트 된 단말에서 사용 불가능하기에 재 발행을 해야 한다는 소식이였습니다.

매우 중요한 이슈이고, 저희 같은 B2B 서비스 회사 입장에서는 5년 전 SW 버젼을 아직도 사용하고 있는 고객들도 있는 상황이기에 광범위하고 긴급하게 대응을 할 필요가 있었습니다.
재발행 하는 것이 큰 문제가 아닐 수도 있다고 생각 할 수도 있지만, 사실 그간 저희 빌드 머신이 수차례 변경을 거치면서 솔직한 말로 3년 이전의 SW들을 현 머신에서 이전과 동일하게 빌드 할 수 있는지에 대한 자신도 없었고, 수백개의 버젼들을 8월까지 재 검증을 하기에도 역시나 물리적인 시간이 촉박하기도 했으며, 삼성 펌웨어 업그레이드 이후 동작 상황에 대한 검증과 펌웨어 업글 이전에 우리의 사전대응으로 인한 새로 발행된 동일 버젼이 업글 이전 단말에서 동작이 어떻게 될 지에 대해서도 미지수였습니다.

삼성 입장에서 보안상 이슈로 상세한 이야기를 다 풀어놓지 못 한 것은 이해할 수 있었지만, 파트너사의 입장에서는 대응 방안을 만들기 위해 무엇이 어떻게 변경되는 것인지에 대해 알아야만 하는데, 이를 알지 못해 오리무중에 빠진 안타까운 상황이였죠.

이슈 자체가 크리티컬 한 만큼, 당장 CEO 포함 주요 개발/검증 담당자에게 삼성의 공문을 첨부한 메일이 날아갔고, 각 시니어 개발자들은 문서 + 추정을 통한 분석을 내놓기 바빴습니다.

저는 여기서 다시 한 번 삼성에서 배운 기술을 써 먹었습니다.
개발을 떠나 서비스 기획을 담당하면서 스스로 느낀 것은, 내가 무엇인가 알아야 할 신규 분야나 서비스가 있을 경우, 문서로 모든 것을 이해하기 보다는 단 한 번이라도 직접 써봐야 한다는 것이였습니다.

 09년, 처음 개발에서 기획으로 직군을 옮기고 나서, SNS라는 것이 너무나도 생소 하고, 주변에 사용자가 아무도 없을 때, 페북이나 트위터, MySpace, LinkedIn 계정을 만들고 부서 사람들 끼리 각 SNS 채널을 통해 이런 저런 이야기들을 주고 받으면서 블로그나, 싸이월드 등과는 어떻게 다르고 이 기능들을 어떻게 폰과 잘 어우러지게 할 수 있을지 연구 했었습니다.
 애플의 iTunes 서비스나, Netflix, Hulu, Spotify를 연구 할 때에도 구글링이나 컨설팅 자료만을 찾아보지 않고, 회사에서 별도의 지원은 없었지만 제 개인 해외 계정을 만들고 해외 VPN 서비스를 구매해서 직접 이런 저런 컨텐츠들을 구입해보고 이용 해 보면서 어떠한 장점과 단점들이 있고 우리는 어떻게 서비스를 하는 것이 바람직한지 이용해 보았습니다.
 그래야 나중에 고객이나 파트너사 미팅 시 실제 서비스를 이용하고있는 그들이 어떤 질문을 할 것인지 미리 예측할 수 있고, 또 대응할 수 있었기 때문이죠.

그래서 저는 우선 공문 내용과 각 시니어들의 의견들을 먼저 읽어 본 후에, 삼성에서 보내온 샘플 app 패키지들을 직접 단말에 설치해 보기도 하고, 패키지 압축을 풀어서 파일들을 하나하나 비교해 보기도 하고, 바이너리 파일 비교, jar 파일 리버스 엔지니어링 등 제가 할 수 있는 선에서 최대한의 비교에 들어갔습니다.

그렇게 비교를 해 보니 어느정도 답이 보였습니다.

그 날 저녁 퇴근 전에 현재까지 상황에 대한 내부 공유를 위해 메일로 제 분석 내용을 돌렸습니다. 그리고 제가 더 이상 접근할 수 없어 알지 못하는 궁금증들에 대해 다시 한 번 '한국어 네이티브'라는 강점을 살려 한국에 전화하여 물어보기 시작 했습니다. 기획 일을 하면서 개발팀 책임/수석님들과 어떻게 일을 해야 할 지 종종 경험을 해 보았기에 삼성의 보안사항을 제외하고 기술적으로 어떤 변경이 있는지에 대해 좀 더 상세하게 알 수 있었죠.
밤 늦은 시간 수 차례 통화를 마친 후 잠자리에 들기 전에 제가 알게 된 내용들을 정리 해 보니, 우리 입장에서 현재 서비스에 어떤 영향이 있을 수 있는지, 그리고 각 영향 별로 어떤 대응방안 옵션들이 있는지, 그리고 각 옵션들의 장단점은 무었인지 얼추 그림이 잡혔습니다.

그래서 다음 날 아침 회사에 도착하자마자 삼성에서 기획할 때 했던대로, 표를 작성하기 시작했습니다.
무엇이 변경되었고, 각 변경사항 마다, 우리의 각 MDM 버젼별로 어떤 영향을 주는지를 적었고, 다음 열에는 각 영향들 마다 우리는 어떤 대응 옵션들이 있는지를 적고, 다시 그 다음 열에는 각 대응 옵션들 마다 장점과 단점은 무었인지 적었고, 마지막으로 제 개인적인 의견상 어떤 옵션이 더 바람직한 것인지를 기술 했습니다.

사실 튀기 위해서 이렇게 분석을 하고 메일을 작성한 것은 아니였고, 아무래도 수 년간 삼성에서 익혔던 근무 방식이 아직 남아있었기에 나도 모르게 한 것 같습니다. 그런데 지난번과 마찬가지로 의외로 반응이 좋았습니다. 가장 크리티컬했던 반응은, CEO의 땡큐 레터였습니다. CEO는 땡큐 레터를 작성하면서 원래 mail thread에 없었던, 개발팀 시니어 메니져를 포함 시키더군요. 사실 제 팀 개발 매니져가 저의 연봉을 산정하여 상신을 하지만, 최종 결정은 개발팀의 시니어 매니져가 HR에서 사전에 정한 개발팀 내 총 샐러리캡과 가이드 내에서 결정을 하게 됩니다.

시니어 매니져가 담당하는 업무 영역이 안드로이드와는 크게 관련있지 않은 편이였고, 저와 직접적으로 같이 일 한 적 또한 없었죠. 그렇기에, 저와 메니져간 협의로 다시 한 번 조정된 연봉에 대해 시니어 매니져가 거절을 하거나, 2차/3차 조정이라는 단계를 거칠 수도 있었지만, 이 사건을 통해 시니어 매니져의 머리 속에 제 이름 역시 남기게 되어, 이번 연봉 협상에서 저와 제 직속 매니져간 협의된 결과에 대해 단칼에 승인을 하는 쿨함을 보여 주었습니다.

사실 직접 써보고 만져보고 느껴야 한다는 것은 문서 자체나, 영어로 작성된 웹 상의 다양한 컨텐츠들에 대한 이해도 부족과, 그렇게 글로 배운 'OOO'은 제 머릿 속에 잘 저장되어 남아있지 않아 시작하게 된 버릇입니다. 하지만 수 년이 지난 지금, 이렇게 제 삶에 도움을 주는군요.

제가 개발을 떠나 적성에 맞지 않는 커리어로 너무나 큰 고민과 고뇌에 빠져있을 때, 제 와이프가 저에게 해 준 말이 있습니다.

"싫은 일을 하기 보다는 좋아하는 일을 해. 돈은 나만 벌어도 되니까 벤쳐를 가건 중소기업을 가건 하고 싶은 일을 해. 하지만 지금 이 일이 너무 가치없다고는 생각하지는 마. 사람이 하는 모든 경험은 어떻게든 도움이 되기 마련이야."

당시에는 제가 하는 일이 너무나 적성에 맞지 않는다고 생각하여 모든 일 하나하나가 가치없고 그저 힘들기만 하다고 느꼈기에, "하고 싶은 일을 해" 부분을 제외하면 와이프의 조언을 크게 귀담아 듣지 않았지만, 지나고 보니 와이프의 말이 모두 맞았습니다.

자의건 타의건 당시에 갖게 된 '문서로만 배우지 말아라' 라는 습관과 비교/분석 표 작성, 그리고 자료를 바탕으로 한 의견 개진의 기술은 역시나 수 년이 지난 후 캐나다에서 빛을 발휘했습니다.

결국 모토로라와 삼성 x 2, 이 세 가지 이슈 덕분에 올 해 연봉협상은 순조롭게 마무리 되었습니다.

그리고 연봉 협상이 끝난 후 매니져가 내년에 저에게는 새로운 기술과 방법을 리드하는 롤을 기대한다며, 상품화 가능한 많은 의견과 기술들을 소개하기 위해 노력 해 보고, 서버 개발쪽에서도 올해 안드로이드에서 한 것과 동등한 수준의 역량을 기대 한다는 말을 하더군요.

올 한 해 이 세 건의 사건 해결로 인해 올라간 저의 연봉 만큼이나 저에대한 회사의 기대치 역시 높여 놓았습니다.

내년 연봉 협상의 전략과 카드에 대해 다시 한 번 진지한 고민이 필요하다는 부담감이 있기는 하지만, 일단 2 주간의 휴가 기간 동안에는 이번에 마무리 된 성과 평가 및 연봉 협상 결과의 기쁨을 만끽하려 합니다.


2016년 7월 15일 금요일

Salary Negotiation 준비편 - 올해의 업무 실적 정리 1편

이민을 결정하고나서 제가 세운 단기 목표 중 직업과 관련된 주요 목표들은 다음과 같았습니다.

1) 1년 내에 최소한 개발자 은퇴하기 직전의 감과 실력을 되찾기
2) 2015년도 내에 SW 개발자로 취업하기
3) 취업 후 3년 내에 연봉 10만불 만들기

1번 목표의 경우 아직 잘 모르겠습니다.
전에 하지 않던 자바를 하며 새로운 기술도 많이 익혔지만, 이전에 비교적 이해도가 높았던 커널쪽이나 C/ASM쪽은 완전 잊은 상태인데다, SW 기본 이론중 상당 부분 역시 잊혀진지 오래 되었거든요.

2번은 정말 운이 좋게도 구직활동을 시작 하자마자 구직이 되서 의외로 손쉽게 달성 했습니다.

그리고 마지막으로 남은 세 번째 단기 목표, 모든 직장인들의 궁극의 목적인... 연!봉!

작년에 한 차례 연봉 조정을 거치기는 했으나, 제 스스로도 자신감과 준비가 부족했던 터라, 회사에서 제시한 조건을 단 일초의 망설임도 없이 덥석 물어버렸죠. 사실 제가 거부하고 버티고 협상을 돌입하기도 애매했던 것이 당시 저는 회사에 입사한지 반년밖에 안된 상태로, 회사 규정상 연봉 조정 대상자가 아니였습니다. *이전글 참고

그래도 당시의 제 연봉 인상은 제 스스로에게는 상당히 고무적이였습니다.

제 경험을 토대로 말하기엔 제 경험이 너무 미천하여 마치 100일 휴가를 나온 신병이 아직 군대 안 간 친구들에게 군대란 어떤 곳인지 이야기를 하는 것일테지만, 제가 듣고 읽은 바에 의하면 북미 기업문화에서 물가상승률 이상의 연봉 인상은 포지션 변경 시 외에는 없다고 알고 있고, 그래서 2~3년마다 잦은 이직을 하는 이유 중 큰 요인이 연봉 인상을 위해서라고 알고 있습니다.

그래서 처음 입사를 하고, 3개월 probationary period를 무사히 마친 다음부터는 세 번째 목표 달성을 위해 매 1년마다 이직을 해야겠다는 생각을 가지고 있었는데, 회사에서 먼저 연봉을 조정해 주는 것을보고, 유랑단 생활을 하지 않고도 목표를 달성할 수도 있을것 같다는 생각을 갖게 되었죠.

그리고 꼭 돈만 보고 일을 하고있는 것은 아니지만, 이 회사에서도 제 연봉을 꾸준히 올릴 수 있다는 가능성은 제가 일을 할 때 일종의 당근 역할을 하기도 했고, 그렇게 1년여의 시간이 더 지난 지금, 드디어, 마침내, 아기다리고기다리던 정식 연봉 협상을 할 시기가 다가왔습니다.

결과적으로는 3번 목표에는 조금 못미치는 연봉 + 직급 조정으로 마무리가 되었지만, 개인적으로 생각한 이직 마지노선보다는 높게 받아내 만족합니다.

성과평가 기간은 전년도 6월부터 올해 5월까지의 성과를 바탕으로  합니다.
성과 평가의 기본 자료는 임직원 개개인이 각 항목별로 자신의 어떤 성과때문에 이러한 평가를 받아 마땅하다는 것을 피력해야 합니다.
회사 시스템 상에도 제가 한 일들이 로그가 다 남긴 하지만, 성과평가에 자기 PR을 위해 저는 거의 매 주마다 제가 했던 일들 중 굵직한 일들, 남들에게 자랑할 만한 성과가 있다면 따로 로그를 남겨둡니다.

사실 올 해 초 까지만 해도 제 업무일지를 들여다보면 전년대비 특별히 괄목할 만한 것은 없었습니다.
그래서 올 해에는 큰 기대를 하기 힘들 것 같았기에 1) 남들보다 문제 해결 속도가 빠르다. 2) 그래서 남들보다 더 많은 기능구현이나 버그 수정을 해왔다 정도를 강조하려고 생각하고 있었죠. 남들보다 손이 빠른 편이라 매 스프린트 중반이 넘어가면 일감이 없어 심심하다고 하여 서버쪽 개발에도 같이 참여를 시작했지만, 20년 넘게 묵은 서버 구조를 아직 파악하지 못했고, 하는 일도 쥬니어 수준에서 크게 벗어나지 못한 걸음마 수준이라 이걸 자랑하기는 힘들었죠.

이전글에서도 잠깐 언급되었는데, 작년에 연봉 인상 제안을 받을 때에 몇 가지 운이 따랐었는데, 올 해에도 3월에 구 모토로라(현 지브라)에서 한 건, 5, 6 월 두 달동안 제 이전 직장인 삼성에서 두 건의 사건?을 터트려주며 이번 연봉 협상에서 유리한 고지를 선점할 수 있도록 도와주는 일이 생기고 말았습니다.

모토로라 사건은 올 3월에 포스팅을 이미 한 바 있으니 (링크 참조), 삼성발 이슈 두 건에 대해 한 번 적어보죠.

첫 번째 사건은 캐나다 공휴일인 Victoria Day 직전에 발생합니다.

Victoria Day로 연휴가 시작되기 3일 전 아침, 매니져가 저를 찾아왔습니다.
  •  매니져: "우승, 너 지금 스프린트 상황 어때? Blocker나 Critical task 있어?"
  •  나: "아니 나 지금 스프린트 타스크들은 다 끝내서 백엔드쪽 BDD 테스트용 시뮬레이터 구현하는거 하려고 하는데. 왜?"
  •  매니져: "그럼 급한 일 하나 처리해줘. 내가 메일 재전송 해줄테니 한 번 읽어보고, 폴한테 지금 상황 업데이트 받아."
  •  나: "폴? 시장문제야?"
  •  매니져: "그냥 문제가 아니고 좀 심각해. 전 세계에 걸쳐 10개 넘는 고객사 단말 총 8만대 정도가 갑자기 먹통이 되었어. 리포팅 된건 전부 삼성 단말인데, 삼성 특화 문제인지 아닌지도 정확하지는 않고"

안그래도 잘 알지도 못하는 시뮬레이터 만드느라 개고생 중이였는데, 참 듣던 중 반가운 소리였던지라 휘리릭 메일을 읽고선 폴이 있는 5층으로 달려갔습니다.

문제 상황이나 문제 해결 스토리를 나열하면 아무래도 보안상 안될 것 같아 이후 상황을 간단히 요약하자면 힘들게 문제 재현을 했고, 생판 모르는 SE Linux 공부를 해가며 분석한 결과 삼성에서 무언가 문제를 야기시켰을 가능성이 보였고, 삼성에 리포팅하니 이미 문제 발생한 보안 정책을 서버에서 삭제하였다고 함.
이후 이슈 해결을 위해 삼성과 컨퍼런스 콜을 arrange 했지만, 본사 개발팀은 안나오고 중국 연구소 개발팀만 나옴. 그들은 이슈 히스토리도 모르고 해당 보안 정책 변경사항도 잘 모름.

깔끔하게 해결이 된 것은 아니지만, 일단 삼성 문제라는 것 까지는 확인이 된 상황이고, 저희가 할 수 있는 것은 Factory Reset 외에는 아무것도 없다는 것 역시 확인이 되었기에 기다리면 되는 상황이긴 했습니다.

하지만...제가 왜 그랬는지는 모르겠지만, 아무래도 삼성에서 일 할 때 버릇이라 나도 모르게 나온 것 같습니다. 8만대가 멈췄는데, 휴일이라고 팽팽 노는건 삼성에선 절대 허락되지 않는 일이였거든요 ^^;;

일요일 저녁이 되자, 한국은 이제 월요일 아침이라는 것이 생각나, 그간 주고받은 메일 루프에 있는 한국인 개발자들에게 개별적으로 전화를 돌리기 시작했고, 마침내 정확한 문제 원인에 대해 설명을 듣게 되었습니다.
그래서 바로 해당 문제 고객대응 담당과 tech support 담당에서 추가적인 문제 발생을 막기위한 방법을 먼저 메일로 보내고, 전체 이슈 메일 쓰레드에 문제 내역을 요약해 돌렸습니다.

그러고 캐나다에서는 휴일이였던 월요일 아침... 아직 한국은 저녁 8시 정도이니 아직 근무중이겠거니(???) 싶어서 다시 삼성 개발자에게 전화를 걸었고, 이미 8만대를 넘어 10만대에 육박하는 문제 발생 단말들이 있기에, 보안 정책을 내리기만 하는 것으로는 충분하지 않고, 문제 수정이 되는 새로운 정책이 당장 필요하다는 것을 역설 했습니다.
삼성에서도 이 점을 인식하고는 있으나, 물리적인 한계점과 서버에서 기술적인 어려움 몇 가지를 이야기 해주며 저에게 테스트용 복구 파일을 보내 줬습니다.

삼성에서 배운 것 중 하나는, "파트너가 민첩하게 대응하길 원한다면, 너는 그 보다 몇 배 더 빨리 민첩하게 행동하라" 입니다. 직접적으로 압박을 할 수 없기에 그 누구보다 기민하게 행동한다면 상대도 문제의 중요성과 심각성을 간접적으로 깨닿고 기민하게 행동하게 된다는 것이죠.

삼성에서 문제를 발생시켰고, 수정 역시 삼성에서만 가능한 상황이기에 손 놓고 기다리기만 해도 되지만, 어느덧 10만대에 이르게 된 벽돌이 된 단말들은 우리 고객들의 단말이기에 하루라도 빨리 수정이 필요했죠. 더구나 더 큰 문제는... 경쟁사 제품에서는 문제가 생기지 않는 상황이였기에...

휴일이지만 저는 사무실로 달려가 복구 파일 테스트를 해보고 삼성에 결과를 알려 주었습니다. 혹시나 모를 추가 확인을 위해 사무실에 굴러다니는 삼성 단말들을 최대한 긁어모아 집으로 가져왔죠.

그리고 월요일 아침... 어제 삼성에서 말 한 기술적 문제점들에 대해 근원적 해결은 아니지만, 가능한 방안이 생각나 캐나다는 휴일이지만 다시 삼성에 전화를 걸었습니다.

그리고 월요일 저녁, 삼성에서 제가 제안한 방법에 추가 개선을 더 해서 기술적 제약에 대해 대응을 하기로 했지만, 다시 찾아온 문제는... 검증 기간...
저도 삼성에 다녀봐서 알지만, 아무래도 제조사다보니 삼성의 검증 프로세스는 일반 SW 프로세스보다 까다롭고 깁니다. 더구나 보안 정책의 경우 동일 OS버젼의 모든 모델들에 적용되는 것인데, 삼성 QA에서는 각 타깃 모델에서 full test를 해야만 하죠. 그렇다 보니 물리적인 시간 제약이 발생합니다.

이 때, 삼성에서 기획자로 일 할 때의 경험이 빛을 발휘하게 됩니다.
보통 B2B 고객들의 경우 다양한 모델을 쓰지 않습니다. 폰/태블릿 구매가 필요할 때 마다 입찰을 통해 한 모델을 수백에서 수만대 한 번 구매를 하는 편이죠. 문제 발생 단말은 10만대가 조금 넘고, 파생모델을 포함해 삼성에서 일 년에 출시하는 모델 수는 수백 가지가 넘지만, 문제가 발생한 모델 수는 다양하지 않을 것이라는 생각을 하게 되었습니다.

 그래서 저는 당장 고객 담당에게 연락해서 간단하게 상황을 설명하고, 고객사들에서 사용하는 단말들 모델명을 가능한 그 수량과 함께 취합해 달라고 했습니다.
 화요일 아침, 발빠른 고객 대응담당은 모델별 수량과 각 고객사별 우선순위까지 정리해서 보내 줬습니다.

 고객 담당자가 만들어준 고마운 자료를 바탕으로 삼성측에 동일 OS 전 모델에 복구 정책을 동시에 보내지 말고, 해당 모델들을 기재된 우선순위에 따라 먼저 검증하여 배포해 달라고 요청했습니다. 결국 1달, 최소 2.5주 후에나 배포 가능하다는 보안 정책은 그 후 3일만에 모델별로 배포되기 시작했습니다.

 이렇게 문제 해결이 되는 와중에도 정확한 근본적 문제 원인에 대해서는 계속 묵묵부답이였습니다. 하지만 저희 customer/tech support 입장에서도 고객 커뮤니케이션을 위해 어느 정도는 파악이 필요했고, 저희 개발팀 입장에서도 향후 동일 문제 재발 방지를 위해 알아야 했고, 또 개발자라면 누구나 있는 기술적 궁금증? 해소를 위해서도 알고 싶었습니다.  
 사실 저는 개인적으로 SE Linux를 공부하면서 알게된 지식과 현 상황이 상충되는 것이 있었기에 기술적 궁금증이 더 컸죠. 그래서 계속 개별 연락을 지속한 끝에 근본적 문제 원인 또한 속 시원하게 설명을 듣게 되었습니다.

 역시나 제 개인적인 연락을 통하게 된 것이라 관련 개발팀에 메일을 통해 공유를 했고, 우리가 좀 더 문제를 이해하는데 도움이 되었습니다.

 이렇게 저렇게 사건이 해결된 후 저는 뜻하지 않게 생에 처음 Kudos라는 것을 안드로이드 시니어 개발자와 개발팀 VP에게 받게 되었습니다.

 휴일도 마다하고 하루 빨리 고객 문제를 해결하기 위한 열정과 root cause를 향한 기술적 집요함 등에 대해 kudos를 표하더군요.

 참 상황이 재미있는게 이 모든 것이, 삼성과 관련이 있었다는 것입니다.
삼성 보안 정책 오류에서 문제가 발생했고, 해결 과정에서 삼성에서 배운 다음 두가지, "고객 발등에 불똥이 떨어졌다면 네 머리 위에는 운석이 떨어지고 있는 것이다.", "파트너가 민첩하게 대응하길 원한다면, 너는 그 보다 몇 배 더 빨리 민첩하게 행동하라", 덕분에 이렇게 해결을 하게 된 것이죠.

삼성에 있을 때엔 이렇게 하지 않으면 혼날만한 일이였건만, 여기에서는 이렇게 행동하니 오히려 Kudos를 받는군요.

올 해 연봉협상에서 제가 쓸 카드 두 장이 생겼는데, 그 누구보다 기민한 대응과 될 때 까지 두들겨보는 집요함. 두 가지입니다.