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를 받는군요.

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