이민병 환자들을 위한 싸구려 조언

마음의 병 역시 병인지라 육신에 이상이 생긴 것 만큼이나 힘들고 불편하고 아프죠.

대표적인 병으로는 황진이를 사랑하는 바람에 마음에 병이들어 같은 동네 총각을 죽게 했다던 '상사병'이 있을 것이고, 미국 정신의학회에 등록되기까지 한 '화병'도 있을 것이고, 현대인들이 많이 겪는다는 '우을증'과 같은 정신질환도 있고, 또 '이민병'이 있을 것입니다.

이민병이나 상사병이나 무언가 이루고 싶은 욕망과 목표가 있으나 본인의 의지와 뜻 만으로는 이루어지지 않기에 생기는 병이라는 점과 그 병의 완벽한 치료는 결국 그 목표/욕망을 이룰 때 된다는 점에서도 비슷하며, 시간의 흐름에 따른 마음의 변화, 혹은 포기로 인해서도 치유가 된다는 점에서도 비슷하고요.

이전에도 밝힌 바 있듯, 저 역시도 마음의 병인 '이민병'을 한동안 가슴에 품고 살았던 시기가 있습니다.

처음 이 병을 앓았을 당시, 이 병의 root cause는 work-life balance를 가진 삶을 꿈구는 것이였고, , 나중에는 career에 대한 고민이였습니다.

처음 이 병을 앓았던 시기에 대해서는 제 블로그 첫 포스팅에도 소개가 되어있습니다. 그 때에는 직군 전환을 통해 만족할 만한 수준은 아니지만 일단은 견딜만한 수준의 work-life balance를 이루며 마음의 상처가 어느정도 보듬어졌고, 또 아이들의 탄생으로 인해 이민을 노릴만한 상황이 되지 못하게 되자 포기로 이어져 치료가 되었습니다.

두번째 이민병을 앓게 되었을 때에는, 직군을 변경하고 견딜만한 work-life balance를 갖었을 때 입니다. 만족할 만한 수준은 아니지만 주말이나 휴일 근무가 눈에띄게 줄었으며, 밤늦게 퇴근하는 일은 많았지만 새벽에 퇴근하는 일은 적어도 없었으니까요. 하지만 제 일과 직업에 대한 만족도가 문제였습니다. 그나마 다행인 것은 같이 일하는 팀원들과의 관계가 좋았기에 일은 싫어도 사무실이 싫지는 않았으며, 잦은 해외출장이 때로는 피곤하기는 했지만 일종의 리프레쉬 역할을 해주기도 했으며, 제 R&R 중 하나가 해외 지법인 상대 교육 및 고객 상대 PT인데, 이 역할은 제 적성에 맞는 영역이다보니 제 병의 수준이 중증은 아니였습니다. 또, 처음 병을 치료했을 때와 마찬가지로 갓난아이 둘이 있다보니 한국에서 다진 기반을 모두 포기하고 이국땅으로 향하는 것이 무모한 도전처럼 보였죠. 그렇다보니 이민에 지속적인 관심은 있었지만 본격적인 액션을 취할 만한 단계는 아니였습니다.

반면 나중에 이민병을 앓게 되었을 때에는 말 그대로 벼랑 끝이라는 느낌이 있었습니다. 새로운 일에대한 만족도가 낮고, 저의 미래가 불투명하게만 느껴져 또 다른 직군으로 도전을 했지만 오히려 장고 끝에 악수가 되어버렸고, 일에대한 만족도도, 미래에 대한 희망과 가능성도, 또 Work-Life Balance도 이전보다 더 안좋은 상황이 되어버렸으며, 또 다른 커리어로의 도전과 같은 운신의 폭 역시 더욱 줄어들은 상황이였죠. 결국 이러한 상황은 '이민병'을 재발시켰으며, 더 이상의 선택이 없다고 느꼈기에 이민을 통한 치유를 그 대처 방안으로 선택하게 되었습니다.

먼저 여러분께서 지금 이민병을 앓고 계시고 이런저런 이민 방안을 찾아봐도 마땅한 답이 보이지 않는 상황이라면, 왜 발병하게 되었는지 그 root cause를 먼저 찾아보시기를 권해드립니다. 미래에 대한 불안인지 아니면 현실에 대한 불만족인지, 그렇다면 구체적으로 어떠한 것이 불안하고 무엇이 만족스럽지 못한지, 또 현재 상황에서 이민이 아닌 다른 방법으로 그 불만족과 불안을 해소 할 방법이 있는지를 생각하시다 보면, 이민보다 더 안정적이고 나은 다른 치유 방법이 나올 수도 있습니다.

만약 여러분의 가족이 이민병을 앓고 계시다면, 그 분에게 이런 식의 조언은 하지 않으시는게 나을 수 있습니다. 마음의 병이 들었을 때에는 그 마음을 보듬아주는 것이 이성적/논리적으로 해결하는 것 보다 나을 수 있습니다. 보통 이성적/논리적 접근은 어느정도 상처가 아물어야 가능하거든요.

이민병의 root cause를 찾아보고 그에 걸맞는 치유방법이 아무리 생각해도 이민 외에는 답이 없다면, 이민에 대해 찾아보고 공부하시기를 추천드립니다.

어느 나라로 내가 이민을 갈 수 있을지, 그 나라에는 어떤 이민 프로세스가 있으며 나에게 가능한 이민 프로그램은 무었일지, 그 프로그램에 도전 시 성공 가능성은 얼마나 될지, 성공 가능성을 계산할 때 변수가 될 것들은 무엇인지와 그 변수는 나 자신이 스스로 컨트롤 가능한 변수인지 외부 변수인지 등등이 되겠죠.

가장 안좋은 공부 방법은 계속해서 이주공사/유학원을 찾아다니는 것입니다. 처음 이민에 대한 정보를 얻고자 할 때에는 어디에서부터 어떻게 시작해야할지가 막막하니, 이주공사, 유학원이나, 이민 유학 박람회에 가셔서 이런저런 이야기들을 들어보시는 것이 도움이 될 것입니다. 하지만 대략적인 이해가 된 이후부터는 가장 정확하고 신뢰성이 있는 정보를 공부하시는 것이 좋은데, 바로 목표하는 국가의 이민성 홈페이지입니다. 이민성 홈페이지에는 이민 프로그램에 대한 소개와 요구조건, 선발 과정, 선발 기준 등이 자세히 소개되어 있습니다. 어차피 한국어가 아닌 다른 언어를 쓰는 나라에 가서 밥벌어먹고 살 생각을 하신 마당이라면 당연히 자신의 생활의 일부가 될 영어 읽기에 익숙해져야 하기에, 다소 부담스럽더라도 꼭 이민 정보의 오리지널 소스인 이민성 홈페이지를 잘 읽어보시길 추천드립니다. 만약 스스로 정확한 정보와 기준이 없는 상황에서 잘못된 업체를 만나게 되는 경우, 돌이키기 어려운 잘못된 선택을 할 가능성이 높습니다.

이민 자체에 대한 정보와 기준이 확립이 되었다면, 실제 이민자의 생활, 취업 가능성 등등, 이민성 홈페이지에는 잘 나오지 않는 정보들을 익히시는 것이 좋습니다. 이는 어쩔 수 없이 이민 카페나 블로그, 관련기사, 혹은 모임등을 통해 간접 경험을 할 수 밖에 없겠죠. 만약 해외 생활에 경험이 전혀 없다면 시간을 내어 한번 쯤 목표하는 나라에 직접 탐방을 나가보는 것도 좋습니다. 그리고 영주권 획득 방법 자체도 중요하지만 결국 먹고 살아야 하는 것이기에 구직자로서 그 나라에서 나의 경쟁력이 무엇일지도 연구를 충분히 해야 하겠고요.

저도 1차 발병 시 당시 목표하던 이민 대상국이였던 호주에 직접 방문을 했었습니다. 저는 당시에 이민이 아닌 다른 치유법을 선택했는데 가장 중요하게 작용한 것은 저의 직군전환과 아이들의 탄생이였지만, 그 이전에 직군전환을 했던 이유는 호주 방문 시 체감한 물가와 함께 다양한 간접경험들을 통해 느낀 리스크의 정도가 직군전환에 따른 리스크보다 훨씬 더 크다고 판단했기 때문입니다. 결과적으로 저의 선택은 제 커리어를 꼬이게 만드는 부작용을 낳았고, 1/2차 치료 모두 악수에 악수를 거듭하는 꼴이 되었지만, 반대로 이민병의 치유 방법으로 이민 실행을 실천하시는 분들 중에 '이민' 자체가 악수 중에 악수인 경우가 되는 케이스도 분명 있습니다. 제 예전 포스팅에도 있지만 이민을 염두하고 캐나다에 오는 한국인은 한 해에 수만명 이지만 실제로 영주권을 받는 한국인은 한 해 평균 많아야 4000명 수준입니다. 4000명 중에는 당연히 캐나다에 오지 않고 아웃랜드로 영주권을 받는 사람들도 포함이 된 수치이고요.

만약 본인이 지금 이민병으로 인해 이민을 실천에 옮기고 있는 단계가 되셨다면, 제 블로그 포함 각종 이민관련 카페와 모임, 블로그, 웹사이트 등에 접근을 자제하실 것을 추천드립니다.

이미 여러분은 이민 프로세스에 대한 숙지가 되어있으며, 본인이 도전하고자 하는 이민 프로그램에 무엇이 부족하고 어떻게 채워나가야 할 지에 대해서 알고계신 상태일 것입니다. 만약 내가 목표하는 이민 프로그램(들)에 대해 아직 잘 모르겠고 스스로 부족한 것이 무엇인지 불명확하여 어떻게 채워나가야 할 지 조차 모르는 상태라면, 아직 이민을 위한 본격적인 액션을 취하지 않는 것이 좋습니다.

이민 프로세스와 프로그램은 어느정도 수준이 되면 더 이상의 새로운 이야기가 없기 때문에, 스스로 접근을 자제하게 되지만, 간접 경험 채널인 모임, 카페, 블로그 등은 발걸음을 끊기가 쉽지 않을 수 있습니다. 매일매일 하루에도 수십개가 넘는 새로운 글들이 올라오고, 또 필력이 좋은 분들이 올리시는 글이라도 있으면 시간가는 줄 모르고 재미있게 읽게 되죠. 또, 백문이불여일견이라고, 간접 경험이라는 것은 아무리 해도 그 목마름을 충분히 채워주지 못하기도 하고, 간접 경험을 통해 의사결정을 하려해도 각 필자의 주관적 생각에 따라 서로 다른 의견들을 보여주다보니 항상 정보가 부족하다고 느끼게 될 것입니다.
하지만 잘 생각해 보시면 매일 올라오는 수십, 수백개의 글 중에서 완전한 새로운 내용은 거의 없습니다. 대부분 똑같거나 비슷한 경험을 다른 분들이 새로 공유를 해주고 있을 뿐이지요.

지금 단계는 더 이상 의사결정에 도움을 받기 위해 정보를 긁어모을 단계가 아닙니다. 이미 결심을 했고 액션을 취하기 시작하는 단계이기에, 본인의 액션에 더욱 주목을 하셔야 합니다. 매일같이 몇 시간씩 웹 검색을 하기 보다는, 그 몇 시간을 내가 채워나가야 할 것을 채우는데에 조금 더 집중하시는 것이 더 도움이 되실겁니다. 아마도 이 시기에 이민 신청을 위해서건, 학교 입학을 위해서건, 혹은 이주 후 현지 정착을 위해서건 가장 공통적인 준비요소가 어학실력일텐데, 하루에 수십분에서 길게는 몇 시간씩 웹 검색을 하는 것 보다는 그 시간에 어학 점수를 쌓는데 도움이 되는 행위를 하시는 것이 더욱 더 실질적인 도움이 될 것입니다.  또한 사람마다 각자 다른 생각과 의견이 넘치는 정보의 바다에서 헤엄을 치는 것 보다 공부에 집중을 해서 시간을 보내는 것이 스스로의 정신 안정에도 더 도움이 될 것이고요.

그리고 마지막으로... 스스로 생각하기에 장기간 이민병 중증 증상에 시달리면서 아직까지 이민 외에 뚜렷한 대안도 찾지 못했고, 그렇다고 이민 실천을 위한 명확한 action item도 없거나 있어도 실천을 제대로 못하고 계시면서 줄기차게 웹 검색과 이/유 박람회, 이주공사 세미나 참석을 하고 계시다면 힘드시더라도 당분간 이민과 관련된 정보채널의 접근을 차단하시고 현재 생활에 집중을 해보시면서 이민병이 발생한 root cause가 무엇인지 먼저 찾아보시기를 추천드립니다. 그렇게 하시면 새로운 대안이 나오거나, 이민을 위한 진짜 action item을 수립할 수 있는 다른 시각을 갖게 되실 수도 있습니다. 그렇게 해서 다른 대안을 찾으시건 이민으로 결정이 나셨건 치유 방법이 보이신다면, action item을 수립하여 바로 행동에 옮기시는 것이 마음의 병을 다스리시는데 더 도움이 될 것입니다. 군대에서 배운 몇 안되는 지혜 중 하나인데, 몸이 바쁘면 마음은 편안해집니다.

이상 이민병 병력을 가져본 바 있는 전 환자의 값 싼 1¢ 조언이였습니다.

캐나다에서 야근 & 잔업 - 일체유심조라...

요즘 한국 예능 프로그램인 효리네 민박집을 재미있게 즐겨보고 있네요.

화려함의 최고점을 달리던 톱 가수가 한적하고 여유롭기 그지없는 제주도에서의 삶을 사는 모습이 이색적이기도 했지만, 누구에게도 지지않을 당당함과 자신감으로, 쎈언니의 모습으로 빛나는 예능감을 선보이던 모습과는 사뭇 다른 모습으로 변한 모습이 때로는 잔잔한 감동을 주기도 하더군요.

방송 내용 중 삼남매의 맏언니와 이야기 중 이런 말을 했더군요.

"제주도에서도 마음이 지옥같이 사는 사람도 많다. 서울에서도 얼마나 즐기며 사는 사람이 많지 않느냐. 어디에 사느냐 어떻게 사느냐가 중요한 게 아니라 내가 있는 곳 그 자리에서 만족하는 것. 그게 제일 중요하다"

원효대사님의 일체유심조가 생각나는 대목이긴 한데, 사실 요즘 회사일을 하면서도 그런 점을 조금 느끼기는 합니다.

부서를 옮기기 전 저의 생활을 잠시 돌아보자면... 

  05시 기상

  05시 30분 헬스장

  07시 30분 출근

  08시 근무시작

  15-17시 퇴근

이러한 생활의 반복이였습니다.

근무 강도의 압박이 전혀 느껴지지 않는 그런 생활이였고, 사실 당시의 저의 고민 중 하나는 오늘은 어떤 일을 벌여서 어떤 일을 해야 하는가 였습니다.

제가 담당하는 업무분야는 백엔드쪽에 비해 진척속도가 항상 빠른 편이기에 더 이상 해야 할 일이 없었으니, 스프린트 스토리 외에 technical debt 없애기 위한 별도의 타스크를 스스로 만들어 해결하거나, 백엔드 쪽 스토리와 타스크들 중 저의 역량으로 할 만한 일들을 집어와 해야했죠.

부서를 옮긴 후 지난 반년 가량 저의 생활은...

  05시 50분 기상

  06시 20-30분 출근

   07시 근무시작

  16-22시 퇴근

이렇습니다. 요즘 아침잠이 많아져 아침에 운동을 거르고 있다보니 출근시간이 1시간 당겨지는 효과가 생겼는데, 퇴근 시간은 이전보다 평군 2~3시간 이상 늘어나, 실질적으로 3~4시간씩은 더 근무를 하고 있는 셈이죠.

아니, 한국에서 야근/특근/잔업이 싫고 힘들어 캐나다까지 건너온 녀석이 이렇게 야근질이라니... 싶겠지만, 신기하게도 한국에서의 잔업과 캐나다의 잔업이 저에게 가져오는 느낌은 상당히 상이합니다. 

돈 때문일까요?

그것은 일단 아닙니다. 한국에서 회사를 다닐 때에도 잔업비는 없었지만, '교통비'라는 명목으로 잔업수당을 받았습니다. 8시간 근무 후 매 2시간 추가 시 마다 3만원이던가? 교통비를 지급 받았죠. 지금 회사에서는 24시간 근무를 하더라도 어떤 명목으로든 잔업비가 지급되지 않습니다. 매니져 재량에 따라 다음날 하루 쉬게 해 주거나, 다음에 아무 때에나 대체휴일을 쓸 수 있게 만들어줄 수는 있지만, 몇시간 잔업을 한 경우에 해당한다기 보다는 긴급 사안으로 인해 회사의 요청으로 밤샘을 하거나, 주말에 근무를 한 경우에 해당합니다.

그래서 제가 왜 이럴까를 생각 해 보았는데, 우습게도 마음에 달린 것 같더군요.

하지만 제가 성인군자도 아니고, 득도한 사람도 아니다보니 제 스스로 모든 것을 컨트롤 하여 원효대사님 처럼 해골물도 시원하게 퍼마실 수 있는 것은 아니고, 이 역시도 환경에 영향을 받는 것 같습니다. 그러면 어떤 환경의 차이가 이런 차이를 만들었을까요?

첫째로는 가장 중요한 것이 강제성의 차이라고 생각합니다.

한국에서 제가 모셨던 상사들과 부서장들 중, 몇몇은 잔업에 강제성을 부여했었습니다. 제가 해야하는 일들의 진척상황과는 무관하게 매 월 몇시간 이상의 잔업을 해야만 했고, 또 특별한 사유 없이는 매 일 몇 시 이전까지는 퇴근을 하면 안된다는 암묵적인 룰이 존재하는 부서들이 있었습니다. 보통은 강제적으로 잔업을 할 때, 바쁜 일들이 있기도 했지만, 아무런 할 일이 없는 상황에서도 강제적으로 남아있어야만 하는 상황들이 있었죠.

하지만 지금 제가하는 잔업에는 강제성이 없습니다. 누구도 저에게 남아달라는 요청이나 부탁이나 명령을 한 적이 없으며, 제가 일을하다보니 시간이 자연스럽게 흘러간 경우이거나, 제 스스로 오늘 내에 어디까지 일을 마치겠다고 세운 목표를 달성하기 위해 남아있는 경우입니다.

두번째로는 정규 근무시간 내 일을 마치지 못한 사유입니다.

한국에서 직장생활을 하신 분들은 대부분 공감을 하시겠지만, 본인의 직급과 직무에 해당하는 R&R과, 그리고 계획된 나의 업무와는 무관한 일들을 하면서 보내는 시간이 상당합니다. 

최악의 경우는 윗 사람의 개인적인 일을 대신 봐주는 것인데, 정말 이해가 가지 않는 영역입니다. 반쯤 이해가 가는 부분은 부서 막내이거나 신입이기에 담당해야 하는 부서 총무 역할로 인해 단합대회, 회식 등 이벤트를 주관하고 꾸미는 업무가 되겠고, 그래도 거의 이해가 가는 영역으로 보자면 공식적으로 업무가 된 것은 아니지만, 임원 및 상사의 업무관련 떠오른 아이디어와 생각을 구체화 시켜주고 관련 백업 데이터를 조사해 주는 것 등등이 있습니다. 이렇게 돌발적으로 생긴 업무들이 공식화되고 저의 루틴한 업무와 함쳐저 우선순위가 조정되고, 우선순위에서 밀린 업무들은 그에따라 due date이 조정이 된다면 그다지 불만이 없겠지만, 보통은 루틴한 업무 위에 이런 업무들은 얹혀지게 되다보니 모든 업무들을 주어진 기간내에 해결하기 위해서는 어쩔 수 없이 잔업을 해야만 하게 되었었죠.

하지만 지금의 잔업은 이런 외부요인들로 인해 발생하는 경우가 거의 없다고 봐야 합니다. '거의'라고 한 것은 간혹 저희 부서에서 운영중인 서비스나 서버가 돌발적으로 펑펑 터지는 사고들로 인해 돌발 업무가 발생하기 때문이지, 간혹 위에서 지시나 요청이 내려오기 때문이 아닙니다.

세번째는 절대적인 잔업 시간의 정도라고 생각합니다.

한국에서도 고과 등급의 결과 등 이런저런 사유로 갑자기 충성심과 애사심이 급상승 하고, 의욕의 충만하게 된 경우들이 있긴 합니다. 그리고 당분간은 잔업과 주말 특근을 거뜬하게 버텨내게 되지요. 하지만 이런 것은 오래가지 못했습니다. 최대정지 마찰계수처럼 일정 수준 이상의 잔업과 특근이 반복되다보면 저의 체력과 의욕, 목표의식이 모두 burn out되어 너덜너덜해지고 다시 투덜이 스머프로 바뀌기 마련이였습니다.

하지만 여기서는 다행히도 아직까지 burn out 된 경우는 없었습니다. 일단 제 스스로 정하고 행하는 잔업이기에 제가 버틸만한 적정선에서 stop을 합니다. 늦더라도 밤 10시쯤에는 집에 가고, 어쩌다 정말 밤을 새는 일이 있으면 다음날 푹 쉬거나 일찍 집에 갑니다.

매니져 역시도 팀원들의 burn out을 많이 챙겨줍니다. 실제로 1:1 미팅을 할 때 매니져가 자주 하는 말 중에 하나가 "시스템에 휴가 따위는 신경쓰지 말고, 피곤하거나 집중이 어렵거나 개인적인 일이 있다면 그냥 하루 이틀 회사에 나오지 않거나, 아침에 sync 미팅만 끝나고 바로 집에가도 좋아. 그러다가 다시 회복된 것 같으며 원격근무를 해도 좋고. Burn-out 되지 않는것이 당장의 task를 빨리 하는 것 보다 더 중요해. 휴가는 이럴 때 쓰지말고 아껴뒀다가 가족들과 함께 의미있는 시간을 보내기 위해 써." 라고 말합니다.

그리고 가장 중요한 차이 중 하나라고 느끼는 것이 바로 주체성과 주인의식이 아닐까 생각합니다.

이 것은 부서를 옮긴 이후에 더욱 더 강해졌습니다. 제품팀에 있을 때에도 자칭타칭 '내 새끼' 라고 불리는 것들이 몇 가지 있었습니다. 제가 제안하고 구현한 모듈이나, PM 요청으로 진행 한 것이더라도 처음부터 끝까지 제가 개발했던 기능이나 모듈, 혹은 프레임웍 등이 그러합니다. DevOps로 옮긴 이후에는 이러한 '내 새끼'들이 더 많아졌으며, 또 그 애착관계의 정도가 더 깊어진 것 같습니다. 저희 회사 제품은 태어난지 20년이 넘은 제품이다보니 지속적으로 리펙토링 중이지만 아직도 monolithic 서비스의 구조를 어느정도 가지고 있습니다. 그렇다 보니 내새끼 인 모듈이나 기능들이 각각 독립적인 life cycle과 운영이 되는 구조는 아니죠.

그런데 지금 DevOps에서 개발중인, 또 개발했던 툴/서비스들은 micro service 형태로 개발 중입니다. 그렇다보니 현재 운영중인 각각 독립적인 서비스들 중 정말 머리부터 발끝까지 제가 다 담당했던 그냥 내새끼가 아닌 '애지중지 내새끼'가 참 많습니다. 그 만큼 애착도 더 많이가고요. 주어진 스프린트 스토리 requirements와 acceptance criteria를 모두 구현했다 하여도, 정의되지 않은 gray area들을 보다 확실히 하고, 추후 확장성도 고려하는 등 내 새끼를 더 튼튼하고 안정적이 되도록 만들기 위해 다양한 노력을 더 기울이다보니 자연스레 더 많은 시간을 투자하게 됩니다.

또, 제가 지금 만들고 있는 서비스와 툴의 직접 고객이 회사 내 개발자와 QA들이다 보니 다양한 VoC들이 저에게 직접 접수됩니다. 사실 이러한 VoC들을 따로 뽑아 별도의 티켓을 만들어 다음 스프린트 플래닝에 추가하여 해결을 해도 됩니다. 아니 그래야 됩니다.

하지만 간혹 critical한 VoC이거나, 이전 경험을 되돌아 보았을 때, 개선 시 상당한 편리함을 가져올 만한 VoC인 경우 '애지중지 내 새끼'를 보다 빛내주기 위해 그 자리에서 바로 개선에 들어가는 경우도 발생합니다. 그리고 아무리 소중한 내 새끼이더라도 팀에서 약속한 스프린트는 지켜야 하기에, 더 많은 시간을 투자하여 주어진 업무는 업무대로 완수하고, 그 외에 내 새끼를 갈고 다듬고 보듬는 작업을 하는 것이지요.

마지막으로 작은 차이 하나를 덧붙이자면 칭찬과 격려, 그리고 감사표시가 아닐까 합니다.

이러한 작은 노력 하나하나에 대해 매니져와 VP는 잊지않고 감사표시를 합니다. 그리고 VoC를 접수했던 요청자들 역시 개선될 때 마다 감사 인사를 합니다. 사실 말로 때우는 별 것 아니지만 이런 작은 반응들이 큰 힘이 됩니다. 

한국에서는 늘상 있는 잔업이고, 여기서는 특별한 것이기에 감사 인사를 챙기는 것이 아니냐고요?

저도 예전에는 그렇게 생각 했습니다. 그런데, 지금 제가 속한 DevOps에서 잔업은 상당히 일상적입니다. '내 새끼'에 대한 애착과 주인의식이 사실 저만 가지고 있는 것이 아니고, 대부분의 팀원들이 가지고 있다보니 퇴근은 일찍 하더라도 늦게까지 집에서 원격 근무를 하며 일을 하는 팀원들이 많이 있습니다. 또, 당장 저희 서비스 중 하나가 1시간 동안 작동을 멈추면 개발팀 전체가 1시간 동안 아무런 작업을 할 수 없습니다. 그렇다보니 각 개인의 내새끼를 위해서 뿐 아니라 돌발적인 사건/사고가 발생할 경우 많은 팀원들이 새벽에도 일어나 문제 해결을 위해 뛰어듭니다. 때로는 각 micro services 간에 영향이 큰 변경시, 이미 staging 서비스에서 많은 테스트를 했다 하여도 publishing 서비스로 넘어갈 때에는 가능한 업무시간을 벗어난 시간에 작업을 하기에 밤늦게 일을 하는 경우가 많이 있고요.

작년대비 개인 시간도 많이 줄어들었고, 그렇다보니 줄어든 운동시간으로 살도 많이 찌고, 집 앞뒷마당 잔디밭이 점점 잡초밭으로 변해가고 있기는 하지만 그래도 요즘 참 일이 재미있고 보람되어 만족스럽습니다.

사실 한국에서 직장생활을 했을 때에도, 당시 회장의 경영철학이 그룹 전반에 제대로 자리가 잡혔다면 잔업에 강제성도 없거나 덜했을 것이고, 업무의 주체성도 이전보다 더 많이 있었을 것이라고 생각합니다. 신입사원 연수 때 들었던 이른바 이건희 회장의 '뒷다리 론'인데, 정확한 문장은 기억나지 않지만 그 내용은 대략 다음과 같았습니다.

"뛸 사람은 뛰어라. 걸을 사람은 걸어라. 뛰거나 걸을 능력이 없는 사람은 그냥 쉬어도 좋다. 다만, 뛰거나 걷는 사람 뒷다리만 잡아 당기지 말아라. 그래야 그들 덕에 발전해서 노는 사람도 먹고산다. 걷건 뛰건 놀건 모두 한 방향으로 가자."

이 말 대로라면 열심히 할 사람은 열심히 뛰고 날며 하고 싶은 것 다 하고, 그러기 싫은 사람은 안해도 되며, 결국은 결과와 성과에 따라 보상이 주어지는 기업 문화가 될 터인데, 실상은 그러기 힘들었습니다.

부서장이나 그룹 임원이 걷거나 그냥 놀고 싶은사람이라면 부서원 전체가 그럴 수는 있겠지만, 보통 그 정도 위치에 오른 사람이라면 뛰고 날아야 하는 사람이고 (그 위의 임원이나 사장단이 뛰거나 날기를 바라고, 또 그 위에 서도 그들에게 똑같은 기대를 하기에...), 자신이 뛰고 나는 것을 지속하기 위해 부서원 모두가 자신 이상으로 뛰고 날기를 원했죠. 만약 그럴 의지가 없는 부서장이나 임원이라 해도 1~2년 사이에 그 조직은 사라지기 마련이였고요.

또, 근원적으로 보자면 한국 기업에서 채용은 그룹 채용이나 각 회사별 채용이지 각 부서별 채용이 아니다보니 뛰어야 하는 부서에 뛸 사람이 배치받고, 걸어야 하는 부서에 걷고싶은 사람이 배치받는 것이 아닙니다. 뛰고싶은 사람, 날고싶은 사람, 걷고싶은 사람, 놀고싶은 사람이 모두 섞여 선발이 되며, 또 각 부서 배치 시 섞여서 배치를 받습니다.
그러니 걷고싶은 부서에 배치받은 뛰고싶은 사람은 부서에 만족을 못하고 어느정도 위치에 올라가면 그 부서장을 찍어내리고 싶어하며, 뛰고싶은 부서에 배치받은 걷고싶은 직원은 그 페이스에 숨을 헐떡이다 지쳐 낙오하게 됩니다. 또, 뛰고 나는 사람이 그에 맞는 성과를 인정받아 조기 승진이나 높은 고과와 그에 따른 연봉 및 인센티브를 받더라도 걷고싶은 사람의 입장에서 그 포상을 납득하기 어렵습니다. 자신이 놀거나 걷는 동안 뛰어다닌 사람들이 포상을 받는 것이라면 받아들일 수 있지만, 결과야 어떨지 몰라도 지난 과정에서 자신도 그들과 똑같이 뛰어 다녔음에도 포상에서 제외되었기 때문이죠.

구직자 입장에서도 한 번에 대단위 인력을 선발하는 그룹 채용이 더 편리한 제도이고, 회사 입장에서도 시간과 비용 소모가 적으며, 일관된 채용 프로세스를 적용하여 동일한 선발기준을 유지할 수 있는 채용 방식이지만, 채용 이후 회사 운영의 측면에서는 각 부서별 채용을 하는 것이 더 바람직할 수도 있다는 생각을 합니다.

좋은 소식과 안좋은 소식

컨퍼런스 출장, 그리고 짧은 업무 복귀 후 다시 약 10여 일간 휴가를 보내는 사이에 제 주변에서 Good News와 Bad News가 함께 들려왔습니다.

Bad News는 두가지인데, 하나는 좀 많이 안좋은 뉴스고 다른 하나는 조금 안좋은 뉴스입니다.

약 3달쯤 전에 제가 일하는 회사로 이직을 하게 된 한인 개발자가 계십니다. 사실 직장 자체만 놓고보면 이전에 일하시던 직장은 대기업 중 하나로 좋은 복지제도와 괜찮은 연봉을 주는 곳이며, 오피스 위치도 토론토였기에 미시사가에 위치한 중소기업으로 올 이유가 별로 없었습니다. 이직을 결심한 이유는 이민 때문이였는데, 이전 직장에서는 주정부 이민 지원이 없는 반면, 저희 회사에서는 주정부 이민을 서포트 하기에 이직을 한 것이죠. 하지만 컨퍼런스 출장 후 복귀를 하고나서 보니 안타깝게도 3개월 Probationary 기간을 통과하지 못하고 회사를 떠나고 말았다는 소식을 듣게 되었습니다. 

뒤돌아보면 그간 몇 번의 신호가 있었던 것 같기는 합니다. 그 분과 식사나 산책을 같이 하면서 그 분의 매니져와 1:1 면담 내용에 대해 전해들은 적이 몇 번 있었습니다. 그 일이 있기 약 1~2달 전쯤에는 매니져가 그 분께 바라는 롤이 어떠한 것인지를 설명하면서 현재 진척에 대해 약간의 아쉬움을 표시한 적이 있었습니다. 그리고 이 일이 있기 약 2주 전, 마지막 면담 때에는 일을 익히고 따라오고, 또 팀에 새로운 value를 불어넣는 역할이 기대에 미치지 못한다며 직접적으로 이야기를 꺼내기도 했었고요.
그 분에게 면담 스토리를 들을 때, 그 분께서는 당시 면담 내용이 우려되어 힘들게 말을 꺼낸 것이였지만, 저는 그 때만 해도 이 일을 그다지 심각하게 받아들이지는 않았었습니다.
제가 처음 이 회사에 왔을 때, 저의 매니져 역시 probation기간이 끝날 때 까지 1:1 면담시에 칭찬을 했던 기억은 별로 없었고, 항상 내가 어떠한 것을 더 해주기를 바라는지, 그리고 나의 부족한 점이 무었인지를 계속 이야기 했던 기억이 있습니다. 덕분에 캐나다 회사에서의 기대치에 대해 전혀 감을 잡지 못했던 저는 항상 긴장상태를 유지했었죠. 하지만 막상 probation이 끝나고 나니 이런저런 칭찬도 해 주었고, 또 저의 연봉 또한 조정을 해 주었기에 probation기간 중 다소 딱딱한 이야기들이 그다지 심각하지 않다고 생각했었기 때문이죠.

제가 아는 그 분은 이렇게 허무하게 가실만한 분이 아니셨는데, 아무래도 경력과 연봉수준 등에 따른 회사의 기대치도 다를 것이고, 당시에 개인적으로 영주권 관련하여 몇번의 폭풍이 몰아쳤던 상황이라 그런 것 같기도 합니다.

또 다른 안좋은 소식은 사실 생각하기에 따라 안좋은 소식이 아닐 수도 있습니다.
저희 부서에서도 사람을 구인 중이였고, 반드시 DevOps 경력이 아닐지라도 좋은 개발자이고, DevOps에 관심이 있는 사람이라면 얼마든지 추천을 해 달라는 말에, 그렇지 않아도 커리어에 고민이 있던 친구 한 명을 추천을 한 일이 있습니다. 하지만 면접결과 안타깝게도 채용하지 않기로 했다고 하네요. 그래도 이미 재직중인 회사가 있는 상태에서 다른 기회를 찾아보기 위해 면접을 봤던 것이기에 크게 나쁜일은 아닐 수 있습니다. 오히려 좋은 일이라고 할 수도 있는데, 면접 과정에서 저희 매니져가 마음에 들었던지, 따로 장문의 메일을 써서 어떠한 점들이 부족했고 무엇이 더 필요한지 자세히 피드백도 주었고, DevOps와 관련된 책을 한 권 사서 우편으로 보내주어 혹시 관심이 있다면 이 책을 자세히 읽어보고 더 공부한 후에 다시 한번 만나고 싶다고 했다네요.

다른 한가지 안좋은 소식은 제가 리퍼럴로 추천을 해 준 친구가 회사 면접에 붙지 못한 일입니다. 그래도 그 친구는 다른 회사에 지금 재직중인 상태에서 다른 기회를 찾아 본 것이기에 크게 나쁜 일이라고 까지는 하기 어렵겠죠. 그리고 면접 과정에서 매니져가 마음에 들었던지, 그 친구에게 따로 어떤어떤 점들이 부족했는지 메일도 보냈고, 이쪽 커리어를 생각한다면 도움이 될 만한 책이라며 책도 따로 구매해서 보내주었습니다.

좋은 소식도 두가지이며 둘 다 취업 소식입니다.

먼저 같은 학교를 다녔던 한국인 동생 중 한 명의 취업 소식입니다. 한국에서의 별도의 학력이나 경력은 없는 친구였지만, 항상 성실하고 열심히 하는 멋진 친구였는데, 얼마 전 Web 개발자로 취업을 했다고 하네요. 이 친구도 졸업 후 2년 가까이 다른 분야에서 계속 일을 하고있었고, 시간이 다소 오래 걸리기는 했지만 드디어 개발자로서 커리어를 시작하게 되었습니다.
얼마 남지않은 PGWP 비자 기간때문에, 주중에는 개발자 job을, 주말에는 현재 영주권 진행중인 현재 job을 뛰면서 당분간 투쟙을 유지해야 한다는데 힘들지 않을까 걱정이네요. 부디 영주권을 받아 정착하고 개발자로 완전 전업을 하는 그 날까지 젊음과 체력이 버텨 주길...

다른 취업 소식은 저와 같이 학교를 다녔던 인도 친구 소식입니다.
빈약한 실력 때문에 같이 학교를 다니면서 가능하면 프로젝트는 같이하지 않으려고 했던 친구이긴 하지만, 캐나다에서 가장 큰 은행에서 코업도 했었고, 언변에 능해 취업이 비교적 쉽게 될 것이라 생각했지만, 취업까지 약 2년의 시간이 걸렸네요. 이 친구도 역시 생계를 위해 그동안 보석상에서 일을 하고 있었습니다.

그리고 이 글을 쓰는 사이에 방금 전 페이스북 챗을 통해 안좋은 소식이 하나 더 들어왔네요.

학교에 있을 때 저보다 나이가 조금 더 많은 40대 일본인 아저씨 한 명이 있었는데, 다음 주 월요일에 토론토를 떠나 다른 주로 옮겨간다고 합니다. 이 아저씨도 아직 개발자 쟙을 얻지 못하고 있는 상황이긴 한데, 이제는 1년이 채 안되게 남은 비자기간 때문에, 당장 내일 개발자로 취업을 해서 경력을 쌓는다 해도 1년 미만의 경력인지라 CEC이민을 할  수 없으며, 어찌어찌하여 1년, 혹은 2년의 경력을 쌓는다 해도 Express Entry 점수 충족이 어려워 토론토에서 이민은 포기하고, 마지막 방법으로 반년의 경력으로도 주정부 이민이 가능한 주를 찾아 떠나간다고 합니다.
참 착했고, 학교를 같이 다녔던 친구들 중 저와 문화적으로 가장 잘 맞았던 친구인지라 안타깝네요. 단순한 저의 추측이긴 하지만 아마도 언어실력과 커뮤니케이션 스킬 때문이 아닐까 추측을 해 봅니다.

이 친구의 개발실력은 뛰어난 편은 아니였습니다. 하지만 또 다른 학생들에 비해 뒤쳐지는 수준도 아니였죠. 그럼에도 코업 학기 때 부터 코업 쟙을 구하지 못했었고, 결국 졸업을 할 때 까지 코업을 하지 못하고 졸업을 했습니다. 그 당시만 하여도 대부분 큰 어려움 없이 코업을 구하던 시절인지라 그 친구가 코업을 구하지 못해 1학기 강제 휴학을 할 때만 해도 정말 운이 없는 케이스라고 했었죠.

언어에 대해서는 제가 누구에게 무어라 할 만한 처지는 아닙니다. 저도 매우 영어를 못하고 또, 모르니까요. 이 친구도 저 못지않게 참 영어를 잘 못하는 편이지만, 영어 자체에 대한 능력보다 대화의 스킬에 대해 이야기를 하고 싶습니다.
고급진 영어, 화려한 언변과는 거리가 먼 것이지만, 더듬더듬 서바이벌 잉글리시를 말하는 이민자 영어의 입장에서는 조금 더 적극성을 가지고 대화를 하는 것이 좋은 스킬 중 하나라고 생각합니다.

저는 대화를 하다 어휘가 생각나지 않거나, 적당하게 표현할 방법이 떠오르지 않으면 제가 생각해 낼 수 있는 가장 쉽고 기본적인 단어들로 저의 느낌/생각/경험을 여러번 반복해서 표현을 합니다. 가능한 상대방이 이해할 수 있을 때 까지요. 이 친구가 저와 다른 점이 한가지 있다면 원래 화법 자체가 느린 편인데다, 매우 신중하고 조심스러운 성격을 가지고 있다보니, 이러한 상황이 발생했을 때, 일단 최소 수초간 입을 닫고 생각합니다. 그리고 어느정도 시간이 지나면 그 후에 만들어진 문장을 말을 하죠. 그렇다보니 다자간 대화 뿐 아니라 1:1 대화인 경우 종종 이미 지나간 주제를 뒤늦게 다시 꺼내오기도 합니다.

무엇이 옳고 그르다고 판단할 수는 없지만, 제가 마치 가족오락관 게임을 하듯 비슷한 말로 제가 표현하고자 하는 바를 몇 번 설명하다보면 대부분 native들은 결국에는 그 뜻을 이해하고 저의 말을 rephrase해서 '이 말인거지?' 라고 되묻습니다. 어찌되었건 저는 이렇게 대화가 계속 이어지고 서로 집중을 하면서 대화를 하는 것이 더 편합니다.
신중하게 생각하여 올바른 말과 표현을 하는 것의 장점도 있겠지만, 그 친구와 대화를 하다보면 시간도 오래 걸리고, 때로는 심지어 다음 날 만났을 때에야 서로의 뜻을 이해하게 되기도 합니다. 이러한 대화가 면접장에서도 지속이 된다면, 면접관의 입장에서는 언어를 몰라 말을 못하는 것인지 내용을 몰라 설명을 못하는 것인지 알 수가 없겠죠.

참 재미있는게, 서로간의 코딩스타일은 각자의 화법과 비슷했습니다.
저는 외부 서비스나 플랫폼과 연동되는 새로운 프로젝트를 만들 때, TDD와 비슷하게 합니다.
먼저 간단한 파일럿 클라스와 그의 유닛 테스트를 먼저 만들고 하나씩 돌려보며 외부 서비스의 behaviour를 파일럿 클라스에서 확인을 해 보면서 시작하는 경우가 많습니다. 어느정도 확인이 된 후에 제대로 다시 설계해서 만들어 나간다면 참... 좋은 일이지만 개발자에게 세상에서 가장 힘든 일이 이미 만든 코드를 삭제하는 것이라고 했던가요? 귀차니즘과 파일럿 클라스에 대한 근자감으로 대부분은 그 파일럿 클라스를 수정/확장 해 나아가며 프로젝트 코드가 되버립니다.
하지만 이 친구는 외부 서비스나 API, 플랫폼의 문서부터 파고, 문서를 다 파고나면 그 때서야 설계를 시작하고, 설계가 다 되어야 코딩을 시작했었습니다.
제가 보기에 이 친구는 다소 답답했었고, 이 친구는 저를 다소 무모하다고 생각 했을 것 같네요.

아마 각자의 성격에 따라 화법도 다르고 목소리의 톤도 다르고, 또 개발 스타일도 다른 것 같습니다. 그래서일까요, 예전에 그 친구에게 설명이 안되면 다른 표현으로 설명을 해 보는 것이 어떻겠냐고 권해 본 적은 있지만, 사람 성격이 그리 쉽게 바뀌는 것은 아니다보니...

제 멘탈이 약해서인지 몰라도, 주변에서 좋은 소식들이 들려오면 저 역시도 좀 더 기운이 나고 기쁘지만, 반대의 경우에는 같이 힘들어지는 편인데, 올 해 남은 기간동안이라도 제 주변에서 좋은 소식들이 많이 들려오면 좋겠네요.

가끔 한국이 그리울때?

이민을 결정했을 때에는 일단 건너가서 어떻게 먹고살아야 할 지에 대한 대책이 가장 급하고 중요한 문제였고, 이에 대한 고민을 가장 많이 했지만, 그에 못지않게 가장 근본적인 질문...

"내가 가서 행복할 수 있을까?" 

라는 것에 대해서도 스스로에게 질문을 간혹 던져보곤 했습니다.

만약 영주권도 잘 받고, 일자리도 잘 구했고, 돈도 부족하지 않게 잘 벌고, 아이들도 튼튼하고 바르게 자라더라도 행여 향수병에라도 걸려 매일 저녁 노을이 지는 서쪽 하늘만 바라보며,

"아... 그립다. 사무치게 그립다. ㅠㅠ" 

라고 중얼거리며 눈물 흘린다면 일/선배/상사/야근에 치이고 시달리며 사는 것 만큼이나 힘들 것 같았거든요. 특히나 그다지 길지 않았던 교환학생 시절을 생각해봐도 마지막 학기가 종료되기 직전에 학기 프로젝트를 마무리 지었을 때 즈음에 학기 종료되고 좀 더 놀다 갈 생각보다는 한국으로 빨리 가고싶다는 생각이 들었던 경험이 있었기에 앞으로 평생 수십년간 다른 땅에서 생활한다는 것이 그냥 그것 자체로도 어려울 수 있을것 같았습니다.

비록 이제 캐나다에 건너온지 4년도 채 안되었지만 다행히도 아직까지는 향수병과 같은 증상은 없습니다. 하지만 종종 한국의 무언가가 하나씩 개별적으로 그리울 때는 있습니다.

예를들면 인터넷이나 전화 서비스 등에서 문제가 생겼을때, 한국의 경우 제가 부당한 이야기를 하는 것이 아니라면 당당하게 조목조목 요구하면 어지간한 일들은 다 들어줍니다. 하지만 캐나다에서는 우선 제가 한국말 처럼 이야기를 못하죠. 어눌해도 문제가 되는 상황과 문제점에대해 당당하게 요구를 하면 한국처럼 문제를 수용하고 다른 보상이나 대안을 제시하기 보다는 그 말을 듣고 회사도 저에게 당당하게 '어쩔수 없다', '규정 상 안된다', '정 불편하면 해지하는 것도 방법이다. 너 약정 남은거 없으니 문제 없다.' 라고 말을 하기도 합니다.

하지만 아직까지는 회사생활을 하면서 그런 느낌을 받은 적은 없었지만, 요즘 2주 정도 거의 매일 한국 문화가 그리운 정도까지는 아니지만 생각이 납니다.

얼마 전에 팀에 새로 합류한 동료가 있는데 요즘 거의 매일 1~2시간 정도는 그 내용과 주제는 다르더라도 전반적인 프레임으로 이 친구와 아규가 벌어집니다.

그 프레임은 항상 이런식입니다.

- 동료가 본인 업무 관련해 제게 자문을 요청
- 질문 내용은 그 친구가 지금 당장 해야 할 task 관련 미래에 생길 수도 있는 변화나 확장에 대한 다양한 고려를 어떻게 해서 어떤 architecture로 잡고 나아가야 하는지임
- 간혹 아주 valid한 포인트를 잡아내고도 하지만 보통은 현재 상태로는 고려대상이 아닌 내용임
- 전 항상 당장 주어진 requirements를 만족하는 것을 완수한 후 변화와 확장에 대한 고려는 개별로 확인하여 하나씩 해결하자고 Divide and Conquer를 하자고 말함
- 이 친구는 자기는 나중에 두 번 일하기 싫다며 전부 고려해서 확실히 잡아야 한다고 함
- 당장 필요한 기능에 대해 구현은 되어 있는지, 당장 필요한 기능 개발에 당장 있는 문제점은 무엇인지, 지금 사용하고자 하는 CLI나 API들이 문서 구현된바와 같은 behaviour를 보이는지 물어봄
- 보통은 아직 전체 그림을 잡느라 일 시작은 안했다며 모름
- 이쯤되면 저는 "나도 안해봤고 너도 안해봤고 우리 회사에서 누구도 안해본 분야에 일 시작하는거라 전체 그림을 잡을만큼 이 분야에 seniority가 있는 사람도 없는데 완벽한 전체 architecture는 잡고 시작할 수 없으니 Divide and conquor를 하자" 라고 다시 주장
- 그래도 이 친구는 자신의 concerns에 대해 해결책을 미리 세워놓고 시작해야 추후 수정/확장을 할 만한 구조로 잡을 수 있을것 같다며 이 문제들을 다 확인하자고 함
- 전 다시 기본적인 가장 주된 핵심 기능부터 확인해 보라고 제안함
- 그러면 이 친구는 다시 그것만 돌려보면 자기랑 다시 이 문제점들 얘기 할 것인지 물어봄
...

뭐 이렇습니다.

거의 매일 같은 형태의 대화를 하고있는데, 어제 갑자기 한국이였다면 확 이렇게 말하고 끝냈을 것 같다는 생각이 들더군요

"아놔.. 야, 우리가 지금 AWS 만드냐? 우리에게 지금 요구사항은 테스트 돌릴 때 마다 서버 인스턴스 5개만 만들었다가 다시 죽이면 되는건데 왜그래? 니가 걱정하는 사항들 이미 우리 요구사항과 환경에 다 제한적인 것으로 정해진거자나"

그냥 잠시 혼자 생각하고 혼자 헛웃음 지었던 짧은 생각인데, 이렇게 하고싶은 마음이 저도 모르게 매우매우 간절했었나봅니다. 이 일이 어젯밤 꿈에 벌어지고 말았네요. 인물은 그 친구와 제가 그대로 유지되는데, 장소가 한국에서 일했던 회사 사무실로 바뀌고, 그 친구도 저도 한국말로 말하고 ㅋㅋㅋ

그리고 제가 현실에서 잠시 생각했던 것에도 없던 대사가 더 추가되더라고요.

"니가 내 사촌동생 같아서 하는 얘긴데, 회사는 책에서 보던것과는 다른 세상이야. 일단 현실의 일부터 집중하고, 네 역량이 된다면 그 다음일은 그 다음에 해봐. 우리가 rocket science하는거 아니자나. 그런식으로 일해도 니가 다 해낼꺼면 몰라. 안그러면 너 나중에 남는 성과가 없어서 아무도 인정 안해. 회사에선 실천력과 성과와 결과물이 우선이야. 사회생활이란 말이야..."

헐... 한국식으로 선배로서 하찮은 2 cents 충고까지...

자고 일어나서 사뭇 놀랐습니다. 여기 직장 문화가 오히려 편하고 좋다고 말을 하면서도 지금까지 약 35년여간 살아온 곳의 문화에서 제가 벗어나지 못한것 같더라고요. 회사에 다른 한국인 개발자 분들도 여럿 계시기는 하지만, 만에하나라도 저보다 seniority가 낮은 한국인 개발자가 같은 팀으로 오게 된다면 행여나 제가 꿈에서 했던 짓들을 진짜로 행하지 않을까 걱정도 되고요.

가끔 한인 업소에서 일을하고있는 혹은 일을 했던 분들이

 "여기가 뭔 한국인줄 아시는지, 그럴꺼면 한국에서 장사하지 왜 캐나다와서 그런식으로 하시는지..."

 "더 싫은건 캐네디언 직원들에겐 안그러면서 꼭 우리에게만... 만만한게 동포인가?"

라는 식의 이야기들 듣는데, 지금까지는 보통은 근로자의 입장에서 감정적인 동조를 하게 되었는데, 막상 제가 이런 꿈을 겪고나니 그 사장님 마음도 조금은 이해가 되네요. 정말 안좋은 심성을 가지고 있다거나, 악의를 가지고 그러시는 분들도 계실 수 있지만, 제가 꿈에서 그랬던 것 처럼 나도 모르게 자신에게 익숙한 생각이나 분위기나 감정이 나왔을 것 같다는 생각도 들더군요.

오늘도 그 친구와 대화를 마치고 어젯 밤에 꾼 무서운? 꿈이 생각나 글을 남깁니다.

오늘은 몇 시간 대화 했냐고요? 다행히 10-20분입니다. ㅎㅎ
어젯 밤에 그 친구가 어제 던진 수많은 문제점들 중 가장 크리티컬한 몇가지가 생각나 혼자 이리저리 확인해보고 테스트도 돌려보고 몇가지 해결 가능한 방안을 말해줬더니 오늘은 그래도 빨리 끝났습니다 ㅎㅎㅎㅎㅎㅎ

계속되는 반복되는 대화가 매일같이 제 머리를 아프게도 하지만, 또 이렇게 스스로 찾아보고 공부하는 계기도 만들어 주네요. 그래도 간혹 제가 생각하지 못한 크리티컬한 잠재적 문제들을 찾아내고 문제 제기를 해주기에 나쁜 것 같지는 않습니다. 어쩌면 제 두통은 대화 자체에서 온다기 보다는 장시간 지속되는 영어 대화에 대한 스트레스와 대부분의 질문들을 제가 깔끔하게 답변하고 매듭을 짓지 못하는 것에서 오는 자책 때문일지도 모른다는 생각도 들고요.

비록 꿈은 그렇게 꾸었어도 그래도 전 지금 이런 문화가 전반적으로 더 좋습니다.

진짜에요. 진짜라니까요? 한국에서 을이되는건 싫어도 갑이되는건 좋은, 그런게 아니에요.
믿어주세요 ㅠㅠ

정체성의 혼란

팀을 옮긴지 이제 2달 정도가 지난 것 같습니다.

사실 팀을 옮기지는 했지만 애초에 Developer에서 DevOps Engineer로 완전히 직군과 하는 일이 바뀌지는 않았습니다. 제 이전 글에도 밝힌 바 있는데, DevOps팀을 꾸리고 팀의 1차 목표였던 CD 구축에 Java Developer 가 필요했지만, 현재 DevOps팀에 있는 개발자 출신 직원이 Java가 아닌 C++, C# 개발자 출신이고, 적당한 인물의 신규 채용이 어렵다보니 제가 가게 된 것이지요.. 그래서 아직까지는 제가 하는 일은 여전히 SW 개발입니다. 다만, 제품 개발을 하고있는 것이 아니라 개발과 빌드환경에 필요한 툴들을 수정하거나 새로 만드는 일을 하고 있지요.

DevOps Engineer와 SW Developer 사이에서가 고민을 할 것이라는 예상은 하고 시작한 일이긴 한데, 예상외로 조금은 다른 문제로 정체성의 혼란을 겪고 있습니다.

분명 처음 시작을 할 당시에는 VP도 DevOps팀 매니져도 Java 개발을 할 사람이 필요하다고 하여 시작하게 된 일인데, 지금까지 약 2달동안 제가 한 업무의 대부분은 Java 보다는 오히려 C#과 Power Shell Script쪽이 더 많네요. 이전에 퇴직한 다른 개발자가 만들던 플러그인을 이어받아 안정화 시키고 개발 완료를 하는 것이 첫 임무였는데, 의외로 3주 이내에 해당 플러그인의 개발과 그 플러그인의 확장버젼 개발까지 완료를 하게 되었습니다.

그리고 다른 plug-in을 개발하던 중 상당히 장기화 될 것으로 보였던 리팩토링 중 일부가 한방에 해결되는 바람에 한시적으로 필요했던 그 plug-in 프로젝트는 그대로 closed 되었고, 저는 먹이를 찾아 떠돌아다니는 하이에나가 될 수 밖에 없었습니다.

일반 상품화 팀이라면 PM이 있고, PM이 이미 수백가지의 신규 개발 리스트를 가지고 있으며 개발팀에서 언제든지 일감을 달라고 조르면 던져줄 수 있는 스토리들이 백로그에 가득합니다. 하지만 DevOps팀에 따로 PM이 없으며, 아직 팀이 완전한 정상 궤도에 오른 상태도 아니다보니 팀 내에서 자체적으로 백로그 아이템들을 만들고, 백로그 내에서 우선순위도 우리 스스로 정하여 스스로 일감을 골라 진행해야만 합니다. 

지금도 크게 다르지 않지만 당시 저는 2~3주 가량 DevOps 구성원 중 하나로 일을 해 왔지만, 일반적인 DevOps 엔지니어와는 경험과 지식이 상이했고, 이전에 간간히 백엔드 개발을 하긴 했지만 제품 전반을 이해하는 수준은 아닌지라, 팀 내 개발자 출신들이 담당하는 백엔드 단의 리펙토링을 하기에도 무리가 있었습니다. 그런데 백로그 아이템을 아무리 뒤져봐도 우선순위 상위를 차지하는 것들은 대부분 백엔드 리팩토링이나 관련 빌드 스크립트 작성/수정 혹은 모니터링 툴의 개발과, Infrastructure 관련된 것들 뿐이였죠.

"흠... 뭐지? 나 뭐 해야하지? 할 일 없으니 다시 원대복귀 해야 하는걸까?"

그렇게 퇴근을 하고 고민을 하다보니 제가 개발한 확장형 플러그인을 보다 효율적으로 활용하기 위해 shim layer 성격의 별도의 서버 혹은 서비스를 만들자고 제안했던 것이 생각났고, 이 참에 제대로 자바나, 안되더라도 살짝 맛본 적 있는 Node JS로 간단한 REST API Shim 서비스를 만들어 보자는 생각이 들었고, 다음날 출근 후 stand up 미팅 시간에 제안을 했습니다. 안그래도 때마침 CD 서버 외에 다른 서버에서도 해당 서비스를 이용할 계획이 있던 터라 여러 서비스를 통합할 수 있는 Shim Layer가 필요했다며 다들 반기는 모습을 보니 '휴~ 앞으로 적어도 1-2주 정도는 이 일을 할 수 있겠구나' 생각하고 있었는데, 예상치 못한 암초가 다시 나타났습니다.

"Shim layer 성격의 서비스 개발은 찬성. 하지만 Node JS나 Java로 만드는 것은 반댈세!"

"왜?"

"회사에 Java 백엔드 개발이나, Node JS로 상용화 수준의 개발을 한 개발자가 없자나. 그러니 C#으로 하자. 닷넷 개발자는 쎄고 쎘으니."

"어...엉? 이거 아주 라이트 웨이트 서비스라 Node JS로 하면 엄청 심플하고 편할텐데?"

"그렇긴 할텐데, 다들 그냥 개인적으로 공부하고 이것저것 만져본 수준이지 사용화 경험은 아무도 없자나. 그리고, 이거 돌리려면 Node JS 지원되는 별도 VM이 하나 또 있어야 하는데, VM 리소스 관리에도 불편할꺼고, 또, 닷넷으로 해도 이런건 상당히 심플하게 쉽게 갈 수 있어."

사실 맞는 말이기는 했지만, 개인적으로 Node JS로 한 번 해보고 싶기도 했고, 안되더라도 Java는 또 제게 익숙한 언어라 Java로 하고도 싶었습니다. C#은 처음 나왔을 때 잠깐 본 적은 있었지만 제대로 공부한 적도 배운 적도 없었고, Visual Studio라는 툴 자체의 설치를 제가 그다지 좋아하지도 않았고요.

하지만 저 스스로도 개인적인 선호 외에 딱히 내세울 만한 이유도 없었고, 매니져와 다른 팀원들과 VP까지 모두 C#으로 가는 것이 맞을 것 같다는 의견을 보이니 제가 더 주장을 하기도 힘들었습니다. 그리고 난 그러면 다른 일감을 또 찾아야지... 라고 생각하던 차에 VP가 말을 하더라고요.

"왜? C#으로는 너 만들기 힘들어?"

딱히 적대감을 가지고 던진 질문은 아니긴 했지만, 그 말에 왠지 승부욕이 생기더군요. 그 말을 듣기 직전까지도 이 일은 이제 내 손을 떠났구나라고 생각을 했는데, 이제는 이건 내 일이라는 생각이 들었습니다.

"뭐... 나 백엔드 일도 가끔 하긴 했지만 난 C++ 모듈들만 해서 편하진 않지. 그래도 뭐 못할건 없어. 이거 간단한거자나"

"그래 그럼 니가 시작한 일이고, 이미 구조 디자인도 니가 잡아놨으니 니가 이거 하면 되겠네. 얘는 지금 백엔드 코드랑 빌드 스크립트 완전히 모듈화 시키는 일로 앞으로 반년 정도는 계속 바쁠테니."

그렇게 예기치않게 C# 일감을 갖게 되고 1시간 정도가 지나니 진한 후회가 밀려오기 시작하더군요. 기본적인 C#의 syntax야 알긴 하지만... 당장 C#으로 REST 서버를 구축하려면 무얼 어떻게 해야하는지 조차 전혀 알지 못하겠더군요.

"아... 놔... 내 무덤 또 내가팠네... 그냥 내가 right person이 아니라는 말을 했으면 될껄..."

그렇게 시작된 C#쪽 개발은 우여곡절 끝에 마무리가 되었는데, 일단 물꼬가 트이니 줄줄히 그 쪽 업무가 몰려 왔습니다. 회사가 있는 구역 전체가 2시간 가량 정전이 되어 중요도가 낮은 서버들은 잠시 shutdown을 시켰는데, 그 사이에 개발환경 서비스/서버간 예상치 않은 오류들이나 현재 상황을 미스리딩하는 모니터링 리포트들이 나와 그 문제들을 디버깅하고 수정하는 일도 생겼고, 또 다른 니즈가 생겨 또 다른 웹 서비스를 개발하는 일들도 생겼고요.

이렇게 팀을 옮긴 후 지난 2달여 돌아보니 첫 2주 반 가량만 Java를 개발했고 5주 정도는 C#을, 또 최근 1 주 정도는 Power Shell script를 작성하고 있네요. 제가 Java를 고집하는 것은 아니기는 하지만, 기본이 부실하면 쉽게 밑천이 드러나는 법이다보니 제대로 이해하고 있지도 않고,배운 적이나 공부한 적이 없는 C#으로 개발을 하다보니 개발 기간도 기간이거니와 리뷰 과정에서 몇몇 크리티컬한 오류들이 발견되는 일들이 당황스럽기도 하고, 속상하기도 하네요.

필요한 기술과 지식인데 저에게 부족함이 있다면 채우면 되겠지만, 현 상황이 제가 계속 C#을 해야만 하는 상황인지, 아니면 DevOps 엔지니어로서 빌드 인프라와 환경, VM, 도커, 스크립트, 쉐프 등을 익혀야 하는 상황인지, 아니면 당초 저에대한 니즈와 같이 Java쪽 일을 해야 할 일이 많은것인지도 정확히 감을 잡기 어려워 어느 방향으로 제가 뛰어가야 할지가 아직 갈피가 잡히지 않아 걱정입니다. 무엇보다 스스로 내가 무엇을 해야 할 지를 잘 찾지 못하고 알지 못한다는 점이 가장 답답하네요. 아무래도 지금 개발 진행중이고 일부 부분적으로 운영중인 파이프라인을 좀 더 알아보고 이해해서 현재 어떤 needs들이 있는지 스스로 찾아보아야 할 것 같습니다.

제 정체성은 누가 정해주는 것이 아닌 스스로 정해야 하는 것이니까요.

College와 취업률 데이터, 그리고 제 체감 취업률

요즘 연이어서 저에게 문의를 주신 많은 분들께서 '취업이 잘 되는 컬리지를 가는 것이...' 라는 말씀을 하셔서 글을 올립니다.

이전에도 제 다른 포스트에 댓글이나 메일로 따로 문의주신 분들께 답장으로도 이미 나간 적이 있는 내용이긴 한데, College의 SW 학과 졸업생의 취업률에 대한 이야기입니다.

캐나다에 첫 발을 내딛기 위한 준비 하면서 컬리지를 알아보았을 때에 제가 가장 중요하게 생각하고 찾아본 데이터는 각 프로그램의 커리큘럼과 취업률 데이타입니다. 아무래도 이미 전공을 했던 분야인지라 너무나 기초적인 과목으로 커리큘럼이 되어 있으면 피하고 싶어 커리큘럼을 찾아 봤었고, 당연히 이민을 간 이후에 일을하며 돈을 벌고 살아야 하기에 가장 중요한 '취업'을 확인하지 않을 수 없었죠.

정확한 수치로는 기억이 나지 않지만, 대부분의 토론토 인근 컬리지 SW 관련 학과의 취업률 데이터는 졸업 후 6개월 이내 70%를 웃돌았던 것으로 기억합니다. 그 외에 조금 더 범위를 넓혀서 오타와나 나이아가라 등 다른 온타리오 주의 컬리지들을 찾아 보아도 낮아봐야 60-70% 정도는 되었던 것으로 기억하고요.

당시에 이 데이터는 저에게 상당히 긍정적인 요소로 작용을 했던 것이 사실입니다. 아무리 언에에서는 disadvantage가 있다고 해도 60-80%의 확률이면 충분히 스스로의 힘 만으로도 돌파해 낼 자신이 있었거든요.

이 자료는 누구나 쉽게 인터넷으로 찾을 수 있는 자료이긴 한데, 저도 처음 준비를 했을 때에는 직접 자료를 찾아 볼 생각은 하지 않았고, 유학원에 문의를 하여 자료를 받아 보았었습니다. 대부분 유학원들이 캐나다 컬리지 요강 같은 두꺼운 책이 있고, 그 책에는 각 학교/학과 별 입학시기, 입학정원, 취업률 같은 데이터들이 있었죠.

예를들어 제가 다녔던 학교의 취업률 통계 자료는 이 링크에서 찾아볼 수 있죠.

위 스크린샷은 2015년 자료 첫 장을 캡쳐한 것입니다. 저도 사실 본 포스팅을 준비하면서 처음 본 자료인데, 위 자료에서 가장 중요한 부분은 % Working Related 부분과 Available for Employment가 아닐까 생각합니다.

한국에서도 정부에서 발표하는 실업률과 취업률 수치와 실제 체감하는 정도에 차이가 많아 허수가 많다고들 이야기가 많이 나오는데, 그 원인 중 하나가 이를 계산할 때 모수가 전체를 대상으로 하지 않고 Available for Employment만을 대상으로 하기 때문이죠.

위 표에서도 볼 수 있듯, 총 6,449명의 졸업자 중 Available for employment는 2,730 명입니다. 그리고 2,730명이 취업률을 계산할 때 분모로 들어가는 숫자인데, 실제 전체 졸업자의 약 40% 수준밖에 되지 않습니다. 즉 졸업자 100명 중 10명만 취업이 되었어도 취업률 계산은 10/100으로 하지 않고 10/40으로 계산하여 25%라고 말하는 것과 같습니다.

위 테이블에서 녹색 부분에 표시된 72%라는 취업률은 캐나다에 오기 전에 보았던 수치와 상당히 유사한 수치인지라 익숙한 데이터이지만 그 옆에 Working Related의 48%는 저에게는 매우 생소한 수치입니다. 제가 컬리지를 생각하면서 받아보았던 자료에서는 절대 나온적이 없었던 과반 미만의 취업률 수치입니다.

자 그러면 실제로 제가 체감하는 컬리지 SW 학과 취업률에 대해 말씀드리고자 합니다.

다른 글과 마찬가지로 제가 경험하고 아는 캐나다 사회는 제 경험만을 기반으로 하기에 전체를 대변하기는 어려울 수 있지만, 실제 이 곳에서 생활하는 사람 중 한 명으로서 어떻게 느끼고 생각하는지를 참고하실 수는 있을 것입니다.

제가 입학을 한 시기는 2014년 1월 학기이며, 프로그램은 3년제 프로그램의 Fast-Track 과정인 Software Engineering Technology Fast-Track 과정입니다. 그리고 같은 시기에 같은 프로그램에 입학했던 친구들의 절대다수는 외국인 학생이였으며, 또 대부분이 Co-op 프로그램으로 등록을 하여 저처럼 non co-op으로 등록한 학생들은 많지 않았고, 또 non co-op으로 처음에 입학을 했어도 상당수의 학생들이 첫 학기중에 학교에 이야기 하여 Co-op으로 프로그램 변경을 했었습니다.
1월학기에 시작했던 당시 프로그램의 일정상 코업 유무와 상관없이 방학이 없이 학사계획이 잡혀있어 졸업까지 non co-op의 경우 16개월, Co-op의 경우 24개월이 걸리는 과정으로 저처럼 중간에 자퇴?를 한 경우를 제외하면 대부분 2015년 4월에서 2015년 12월 사이에 졸업을 했기에 졸업 후 지금까지는 약 1.5~2년 정도의 시간이 흘렀습니다. 같이 입학했던 친구들 중 한 명은 Software Engineering Technician Fast-Track 과정으로 8개월(2학기)만에 졸업을 했지만 총 50여명의 모수 중 1명이니 일단 예외로 하겠습니다. (참고로 그 친구는 졸업과 동시에 BlackBerry QA로 취업이 되서 월털루로 갔으며 이후로는 연락이 안되서 잘 모릅니다)

졸업 후 1.5-2년이 지난 지금 시점에서 살펴보면 졸업자의 대부분은 취업을 했습니다.

하지만 단순 취업률이 아닌 전공 관련분야 취업률을 보자면 이야기가 조금 달라지는데요, 카페나 식당, 마트 등에서 전공과 무관한 일을 하고있는 경우를 제외하고 전공 관련분야인 Software Developer, QA, Tech Support, IT 테크니션, Tech sales 등으로 취업을 한 경우는 다 합치면 21명으로 절반에 미치지 못합니다. 그리고 그 중 가장 근무여건이나 연봉 면에서 가장 나은 대우를 받는 직업군인 SW Developer (DBA 포함)로만 보자면 총 11명이 SW Developer로 현재 일을 하고 있어 25% 미만이고요.

시계를 돌려서 졸업 후 반년 정도의 시점인 2016년 여름으로 돌아 가보겠습니다.

당시에는 SW Developer로 취업을 한 사람은 총 8명이고, QA 등 다른 포지션 취업자는 정확히 기억나지는 않지만 매우 소수였습니다. 제 생각에는 당시만 해도 친구들이 근무 조건이나 연봉에서 상대적으로 나쁜 대우를 받는 다른 포지션에는 지원을 잘 안했기 때문이라고도 생각합니다.

그러면 SW Developer로 취업을 한 8명의 면면을 살펴보겠습니다.

컬리지 입학 전에 모국에서 Software Developer (or DBA) 근무 경력이 있던 사람은 저를 포함하여 총 8명이지만, 저는 제대로 된 경력자는 7명이라고 생각을 합니다. '본인 주장'에 의거하여 PHP 경력이 3년 남짓 된다는 한 친구는 같이 과제나 프로젝트를 하면서 코드를 보면 3년의 경력이 거짓 주장이거나, 제대로 된 회사에서 일을 했던 경력이 아닐꺼라고 생각되기 때문입니다. PHP의 syntax는 이것저것 많이 아는 것이 확실하지만, 프로젝트 설계나, 로직 구현 수준에서는 도무지 경력자라고 믿어지지 않는 수준이였거든요. 아마 개인 웹 서비스 개발/운영 정도를 경력으로 말한 것이 아닐까 생각됩니다.

이 7명 중 6명은 졸업 후 반년 정도가 지났던 당시 시점에 Software Developer로 취업을 했습니다. 나머지 경력자 1명은 상해에서 C++ 쪽에서 경력도 10년이 넘었고, 실력도 좋은 친구였는데, 이력서를 아무리 넣어도 좀처럼 인터뷰 기회조차 잡지 못하고 있다며 힘들어하곤 했었죠.
그 외에 기존 학력은 있으나 (Fast-track 이였기에 기존 학력이 다들 있었습니다) 경력이 없었던
친구들 중에 Software Developer로 취업이 된 케이스는 단 2명입니다. 지금은 취업이 안되 고생하던 그 상해 친구도 구직에 성공을 해서 경력자들은 100% 취업을 했고, 경력이 없지만 SW Developer가 된 사람은 현재 기준 총 4명입니다.

물론 제 체감 통계에는 여러가지 구멍이 있습니다.
제가 아는 케이스들로만 예를 들자면, 당초부터 명확히 SW 개발자가 되겠다는 의지는 없었던 홍콩인 캐나다 영주권자 아저씨는 졸업 후 모국으로 돌아갔습니다. 처음 입학 후 학기초에 영주권 갱신을 위해 머무르기 위해 왔는데, 그냥 놀 수는 없어서 컬리지에 왔고, 20대 시절에 코볼 개발을 한 적이 있기에 요즘 기술이 궁금해서 왔다고 했었죠. 캐나다에서 모델로 활동하던 여자친구와 함께 살기 위해 캐나다 컬리지에 왔던 베네주엘라 친구는 졸업 후 1년정도 지났을 때, 여자친구가 주 신청자가 되어 영주권을 받은 뒤 다시 모국으로 돌아갔고요. 또, 정확한 나이는 잘 모르지만 최소 40세 이상이였던 파키스탄인 아저씨는 나이 감점때문에 자력 이민이 어렵다는 판단으로 캐나다에 이민와 개인 비지니스를 하는 친척이 사는 도시로 이동하여 그 업체의 스폰서를 받아 영주권을 받기 위해 자발적으로 전공분야 취업을 하지 않았다고 다른 친구를 통해 전해들었습니다.

이런저런 케이스들을 모두 고려한다면 제 체감 통계도 좀 더 정확해 질 수 있지만, 제가 그들 모두와 친밀하게 지내고 있는 것도 아니고, 또 지금은 건너 건너서도 연락이 닿지 않는 사람들도 있다보니 실제 취업이 되었어도 알지 못하는 케이스도 있을겁니다만, 저와 같은 학교 같은 프로그램에 같이 입학했던 친구들도 그렇고, 주변에 다른 사람들의 경험을 통해 보더라도 대략적인 느낌은 비슷합니다.

졸업 후 1년이 넘으면 전공관련 분야는 전체 졸업자 중에 절반가량이 취업을 하고, SW Developer로는 25% 가량이 취업을 합니다. 그리고 SW Developer로 취업을 한 친구들의 면면을 살펴보면 학교 재학시 "저 친구랑 팀프로젝트 같이 해야겠다" 라는 생각이 들었던, 나름 잘한다는 느낌을 받았던 친구들이기도 하고요.

그리고 "학사/석사를 받았으나 취업이 안되어 컬리지에 다시 갈 정도로 컬리지에 가면 취업이 잘된다더라" 라는 말이 있어 이에 대해서도 잠깐 말씀드립니다.

컬리지는 직업 시장을 위한 직업 학교라는 그 특성상 학교 전체를 놓고 보자면 학문 연마를 목적으로 하는 대학/대학원 대비 전반적으로 취업률이 높을 수 있습니다. 아무래도 실질적인 특정 직업을 겨냥한 학과의 졸업생이 순수학문 학과를 졸업한 졸업생 보다는 특정 직업군에 특화되어 있기에 구직 시장에서 더 유리할 수 있죠.
하지만 이는 전반적인 컬리지 vs 유니의 이야기라면 맞을 수 있지만, 대학/대학원/컬리지 졸업자, 심지어 그냥 고졸자라도 모두 같은 포지션을 두고 다투는 SW Developer라는 직업군에서는 맞는 이야기가 아닙니다.
만약 컬리지가 아닌 대학/대학원이라면 "꼭 관련분야 취업을 해야하나?", "취업률이 전부는 아니자나!" 라는 말이 맞겠지만, 직업을 위한 교육기관에서 가장 중요한 지표는 결국 졸업생들이 졸업 후 관련분야에 얼마나 정착하는가라고 생각합니다.

대학/대학원에 대한 저의 직접적인 경험은 없지만, 저희 팀에 들어오는 갓 대학/대학원을 졸업한 쥬니어 개발자들을 통해 듣는 바에 의하면 그들 역시 그 누구도 손쉽게 취직이 되지는 않지만, 제가 느끼는 컬리지 졸업생들의 취업률 수준에 비하면 훨씬 수월하다는 느낌이였습니다.

제가 생각하는 Software, Computer Science 관련 컬리지의 취업을 정리하자면 이렇습니다.

- 학교 다닐 때 잘 했던 사람들은 시간이 좀 걸리지만 결국엔 SW Developer로 취업을 한다.

- 컬리지 졸업해서 SW Developer가 되는 것은, 낙타가 바늘구멍 들어갈 만큼의 어려운 경쟁은 아니지만 졸업하면 대부분 취업되는 수준도 아니다.

- Developer가 아니라 해도 전공 관련분야/유사분야로의 취업 역시 절반 미만으로 쉽지는 않지만 많이 어렵다고 하기는 힘들다.

- SW/CS 관련 학과로 한정지어 보자면 컬리지 졸업자의 취업률은 대학/대학원 취업률보다 낮으면 낮았지 높지는 않다.

제 블로그의 다른 글에서 오직 컬리지만이 유일한 선택지는 아니라는 말씀을 드린 적이 있는데요, 간혹 "컴싸/컴공 석사를 하는 것 보다 컬리지를 가는 것이 취업에 유리할 것 같아 컬리지로 간다" 라고 생각하시는 분들이 계시다는 것은 참 안타까운 일입니다.
컬리지와 석사는 분명 그 목적성도 다르고, 입학 요건도 다르며, 졸업의 난이도 또한 차이가 나고, 학비 역시 대학원이 더 비쌉니다. 입학 요건의 문제, 시기상의 문제, 다른 환경적인 문제, 자금의 문제, 혹은 졸업시 까지 공부를 할 자신감의 문제라면 모를까 만약 취업률을 걱정하여 컬리지에 오신다면 컬리지에 실망을 하실 수도 있을 것입니다. 만에하나 컬리지에 오시면서 70%의 취업률이라는 통계만 믿고 하위 30%에만 벗어날 정도의 노력을 하며 졸업한다면 최악의 경우가 될 것이고요.

오늘 포스팅을 준비하면서 갑자기 짧게나마 같이 생활했던 컬리지 친구들이 생각나서 오래간만에 페북/페북 메신져/링크드인/문자 등으로 연락을 했네요.

Probationary period는 안전할까?

벌써 2년이 넘었네요. 아직 스스로 준비가 되었다고 생각하지 않은 상태에서 정말 운이 좋게도 회사에 들어가게 되었고, 스스로 자신이 없는 상황이라 언제든지 당장이라도 해고가 가능한 probationary period를 어떻게 버텨야 할지 항상 고민을 하며 발버둥 쳤던 것이 바로 딱 2년전 저의 모습인 것 같습니다.

갑자기 이 이야기를 꺼낸 이유는 최근 팀 이동 후 겪은 몇 가지 일들 때문입니다.

팀 이동을 한 지 벌써 벌써 한 달이 넘었는데, 처음 2주 정도 제가 맡았던 일은 빌드 파이프라인 서비스용 플로그인을 제작하는 일이였습니다. 아니, 정확히 말하면 현재 사용중인 플러그인의 개발 프로세스를 완료하는 일이였습니다. 그 전에 DevOps팀에 몸 담았던 어떤 직원이 개발한 플러그인으로 현재 사용중인 플러그인이지만 정상적인 개발 프로세스를 거치지 않아 코드리뷰 상태에서 거의 한달 째 팬딩이였죠.

처음 이들 정도는 전체 빌드 파이프라인 서비스 서버의 구조와 플러그인 설계관련된 문서등을 참고하고 그 플러그인이 어떤 동작을 해야하는 것인지 requirement 파악에 주력했고, 이후 현재 소스코드와 그간 코드 작성이 된 히스토리를 살펴보기 시작했습니다. 오픈소스 프로젝트인지라 문서화에 중간중간 공백이 있었지만 전체 그림을 읽는데는 큰 문제가 없었는데, 문제는 코드 리딩과 히스토리 확인이였죠.

 일단 코드 리딩을 시작하니 온갖 곳에 다양한 예외처리 로직들이 있었습니다. 메인 비지니스 로직보다 더 길고 복잡하게 구현되어있는 예외처리 로직들이 제가 흐름을 쫒아가는데 방해가 되기 시작했죠. 그래서 최종 마스터 브랜치를 읽는 것이 아니라, 그간 커밋 히스토리를 읽으며 왜 그러한 예외코드들이 작성되어있는지 알아보기로 했습니다. 하지만 더욱 더 가관은 커밋 히스토리였죠. 분명 git을 도입하면서 저희가 만든 가이드라인에 의하면 한 커밋에 2개의 티켓이 포함되어도 안되고, 하나의 티켓이라고 해도 각각의 구현 내용, 목적 등에 따라 커밋을 나눠어야 하는데, 이 프로젝트의 각 개별 커밋에는 3~4개의 티켓 번호가 들어간 것은 기본이거니와 각 티켓번호마다 4~5개 이상의 수정 내역을 적어 두었더군요. 그나마 커밋 메시지에 들어온 내용이면 다행인데, 전혀 언급이 되지 않은 수정내역도 많이 있었고요.

플러그인이라 그다지 큰 프로젝트는 아니기에 하루면 충분히 프로젝트 파악이 될 수 있을 것이라는 저의 생각은 완전히 물 건너갔고, 현재 코드 구조를 읽고 이해하는데만 첫 주의 남은 근무일을 모두 소진하고 말았습니다.

코드 리딩에 결정적인 장애물은 위 두 가지였지만, 사실 자잘하게도 여러가지가 있었습니다. Java 프로젝트임에도 Java에서 사용하는 네이밍 노테이션을 따르지도 않았고, 코드 인덴테이션도 맞지도 않고, 함수명이나 변수명이 그 목적이나 의미와 잘 맞지 않은 경우도 많았으며, 프로젝트 생성 시에는 퍼블릭 함수에 Java Docs를 만들어 두고서는 관리를 전혀 하지않아 설명과 실제 코드가 맞지 않기도 했고, 유닛 테스트는 유의미한 유닛테스트를 한 것이 아니라 단순 테스트 커버리지를 어느정도 확보하기 위한 테스트들만 있었기에 유닛 테스트를 통해 각 매서드의 expected behaviour를 알아내기도 힘들었습니다.
 예를들어 플러그인에서 외부 웹 서비스를 통해 어떠한 값을 받아오면, 그 값에 따라 3가지 다른 핸들링 케이스가 나오며, 그 외의 경우에는 BAD_REQUEST exception을 던져야 한다고 가정해보죠. 그런 경우 보통 외부 서비스를 mocking 처리를 하고, 유효한 리턴값 3가지와, 유효하지 않은 임의의 리턴값을 포함한 최소 4가지 시나리오가 나오는 테스트 매서드를 만드는 것이 보통의 접근 방법이겠죠? 그런데 이 유닛테스트는 어찌 된 것인지, 외부 서비스를 mocking하지 않고, JUnit테스트 프로젝트 내에서 더미 서비스를 직접 구현했고, 리턴 값에대한 setter/getter 함수를 만들어 놓고, "외부 서비스가 1을 리턴하게 설정했을 경우 서비스는 1을 리턴해야 한다." 를 테스트 하는 말도안되는 유닛 테스트를 하고 있었습니다. 즉 실제 제품의 비지니스 로직은 전혀 테스트 하지 않고, 테스트 프로젝트 내에서 작성한 더미 클라스의 세터와 게터 함수를 확인하는 것이였죠.

사실 Java 개발자가 한명도 없는 DevOps팀에서 신입 개발자가 이 플러그인을 개발했다면 어느정도 이해를 할 수도 있는 부분이 있긴 했습니다. 그래서 어마어마한 인내심을 가지고 1달동안 이 프로젝트 리뷰를 어떻게든 해보려고 노력했던 Java Architect에게 그간의 이런저런 히스토리를 듣고 거의 처음부터 다시 작성한다는 기분으로 하나씩 하나씩 리팩토링에 들어갔습니다.

그렇게 2주 정도 지났을 무렵, 이전 팀 매니져와 만나서 이런저런 이야기를 하다가, 지금 제가 하고있는 프로젝트 상황을 잠깐 이야기 했죠. 그러자 바로 매니져가 대뜸 하는 말이 

"아. 그 코드 original author가 누군지 말 안해도 알겠다. 분명 xxx일꺼야."

"응? 맞아. 너 xxx알아?"

"알아. 너 우리회사 오기 전에 안드로이드 팀이였거든"

"근데 난 그 친구 얼굴도 본 적이 없는데? 언제부터 DevOps로 옮긴거야?"

"말하자면 긴데, xxx가 첨에 면접 통과해서 Intermediate 급으로 안드로이드 왔었지. 근데 너 그 프로젝트 보면 이해 되겠지만, 도저히 같이 일할 수 없어서 probationary 기간 중에 그만 뒀어"

"뭐야? 그럼 회사 나갔다가 다시 DevOps로 재입사 한거야?

"응. DevOps에서 면접본거 우연히 알게되서 안드리(DevOps 매니져)에게 절대 뽑지 말라고 얘기했는데, 2년이면 사람이 바뀔만한 충분한 시간이고 면접할 때 인상 좋고 잘했다면서 구지 뽑더니만... 결국 DevOps에서도 2달정도 있었나? 그러다 짤랐지."

"그래, 솔직히 프로젝트 코드 보면서 어쩜 이럴까 싶긴 했는데... Build Tool 전문가가 그냥 코드 짰거나 쥬니어나 인턴이 작성한건줄 알았어"

"걔 DevOps엔 시니어로 들어왔어! 그것도 Java Specialist로!"

"DevOps에 Java Developer가 없어서 면접볼때 제대로 확인 못했나보네"

"아냐, 우리팀에서 면접권으로 같이 나가서 봐줬었어"

"그럼 우리팀 면접 질문에 문제가 있네. 바꿔야지"

"근데, 참 신기한게 내가 xxx 채용 할 때에도 면접할 때엔 정말 인상 좋았어. 기술면접 진행한 시니어들도 평가가 좋았고. 그래서 채용한거고"

"안드리도 마찬가지였나보네."

"응, 내가 그래서 속지 말라고, 진짜 후회한다고 그렇게 말렸던거지."

잠시잠깐 제가 개고생 하고있는 프로젝트의 원작자의 뒷담화?를 하면서 속으로 뜨끔 했습니다.

'헉! 그래... 면접을 잘 봐서 실제 실력보다 과대평가 되서 다른 회사에 간다면 이런 일이 생길 수도 있겠구나. 내가 만약에 그 전에 면접에서 어찌어찌하다 잘 되서 다른회사로 이직 했으면 바로 이 꼴 났겠다.'

불행인지 다행인지 사실 저는 직접적으로 팀 내에서 이런 팀 동료를 아직까지는 만난 적이 없기는 합니다. 게으른 동료들은 있어도 못해도 잘하는척, 몰라도 아는척 하면서 자기 실력을 뻥튀기 하지는 않았거든요. 대학생 코업 학생 중에 그런 친구가 한 명 있긴 했는데, 팀원 다수가 매니져에게 차라리 인력 1명이 줄더라도 그 친구는 있는 것 보다 없는 것이 오히려 도움이 된다고 이야기 해서 그 친구는 다른 팀으로 보낸 이력이 있죠. 그래도 그나마 그 친구는 코업 학생이라 해고되지는 않았는데 이 친구는 intermediate와 senior로 들어와 그 미만의 실력을 보였던지라 회사에서 probationary 기간 중에 바로 쫒아 낸 것이였죠.

그리고 플러그인 개발을 마친 후 빌드용 VM관리 서버의 동작 확인을 위해 VM관리용 서비스 C# 프로젝트를 오픈하고나니, 또 비슷한 상황을 볼 수 있었습니다. 당연히 같은 친구가 한 일이라 생각했는데, 또 다시 제가 모르는 다른 이름이 나오더군요. 그래서 처음 DevOps팀 설립 멤버인 동료에게 물어보니 이런 말을 해주더군요.

"아, 전에 팀에 있던 사람이야. 지금은 회사 떠났어. 처음에 우리도 Continuous Delivery 공부하면서 팀을 만들 때, 인력 확장도 필요하고, 기존에 관련 경험과 경력이 있는 사람이 필요해서 채용한건데, 사실 우리가 이에대해 아는 것이 없다보니 그 사람이 얼마나 아는건지, 제대로 아는건지 확인을 하지도 못하고 채용했던 사람이야."

역시나 약간의 허세와 말빨, 그리고 인터뷰를 위한 공부를 통해 들어왔던 사람 이였던 것 같았습니다.

예전에 차승원씨가 삼시세끼에서 손호준씨를 칭찬하면서 이 모든 것을 갖추었다며 이런 말을 한 적이 있었죠.

“능력이 없으면 열정이 있어야 하고, 열정이 없으면 겸손해야 하며, 겸손하지도 못하면 눈치가 있어야 한다”

그런데 Probationary 기간 중에 해고되었던 그 친구들의 사례를 보면, 차승원씨가 한 이야기 중에 눈치는 확실히 있었던 것 같네요. 능력과 열정은 없거나 부족하지만, 겸손하기는 커녕 자기 자신을 과대포장해서 인터뷰 시에 눈치껏 잘 홍보 한 것이죠.

그리고 코드 자체를 보면 능력이 부족하다는 것이 (적어도 Senior로 들어온 사람으로서는) 명약관화하게 보이며,  코드리뷰 히스토리를 보면 정말 겸손함과 열정이 없습니다. 회사 가이드라인에 맞지 않은 커밋에 대해 Architect가 초반부터 지적했음에도 조금도 개선되지 않았죠. 사실 git이기에 본인 브랜치 삭제하고 커밋을 다시 잘라 push해도 되는 일인데, 그 리뷰에 대해 "나 그 가이드라인 따르려고 많이 노력중임. 그런데 그거 다 따라하기는 어려움. 일단 그냥 마지막 커밋 기준으로 코드 리뷰 해주길 바람. 돌려보면 동작함" 이런 답변을 달고 끝낼 정도로 열정도 없고, 리뷰어에 대한 존중도 없었죠.

최근에 갑자기 Probationary기간에 해고된 2명의 직원 이야기를 몰아서 들은 후에, 제대로 다른 회사에서 Senior로 일 할 만한 실력도 준비도 안된 상태에서 면접을 보러 다녔던 제가 부끄럽기도 했거니와 오히려 이직을 하지 않은 것에 대한 감사함이 떠오름과 동시에, 2년여 전 처음 어쩌다 입사를 해서 항상 게눈을 하고 이곳저곳 동태를 살피며 눈치보고, 캐나다 직장에서는 나에게 바라는 기대치가 얼마일지 전혀 감을 잡지 못해 행여나 운 좋게 잡은 직장에서 해고당할까봐 밤 늦게까지 공부하고 일하면서 보냈던 그 때의 시간이 다시 생각나기도 했네요.

그 때엔 능력은 정말 없었지만, 열정도 있었고, 또 스스로를 바닥이라고 생각했던 만큼 당연히 겸손했으며, 모든 것이 불안했기에 당연히 또 눈치가 있었는데, 요즘 겨우 경력 다시 시작한지 2년 조금 넘었다고 열정은 있으나 거만하고, 눈치없이 자기 목소리만 너무 내세우지만, 그렇다고 또 어디 가서도 지지않을만큼 당당한 실력도 갖추지 못한... 그런 애매한 실력에 성격도 좋지 못한 개발자가 된 것 같네요.

팀 이동도 했고, 새로운 분야에서 일을 시작했으니 초심으로 돌아가 하나씩 다시 배워봐야 할 것 같습니다.

Android Developer Interview 후기 2탄

안녕하세요.

캐나다 안드로이드 개발자의 면접기 2탄을 올립니다.

지금 직장에 다닌지 이미 2년이 되어가는데, 지금에서야 그 후기를 올리는 것은 아니고, 최근에 다른 회사의 면접을 본 적이 있어서 그 회사에서 진행했던 면접에 대한 이야기를 해볼 까 합니다.

이번 주에 면접을 본 것이라 아직 합격여부에 대해 답을 받지는 못했지만, 저는 확실히 "불합격"이 될 것을 믿어 의심치 아니합니다. ㅠㅠ 
"불합격"이 거의 확실시 되는 이런 면접 후기를 올리는 이유는 아무래도 지금 회사의 Android Developer 역할과 일반적인 Android Developer의 역할간에 간극이 크고, 회사에서 요구하는 지원자의 skill set 또한 간극이 크기에, 인터뷰 내용 역시 다른 점들이 많아 2년 전쯤에 올린 제 인터뷰 후기가 일반적으로는 크게 도움이 되지 않을 것으로 생각되기 때문입니다.

이전 포스팅에서도 언급 한 바 있지만, 저는 지금 직장의 조건이나 제가 하는 일, 근무 환경 등등에 모두 만족하고 있습니다. 하지만 미래를 생각했을 때, 현재의 제 Job Experience는 불안한 요소들이 있습니다.

MS의 시대에서 Google과 Amazon, 그리고 최근에 Facebook로 IT 시장에서 중심축이 이동해 온 2000년대는, OS와 Client에서 서버와 오픈 클라이언트로 그 흐름이 많이 이동을 해 왔습니다. 그렇다보니 중요한 Business logic이나 데이터 핸들링, 컨트롤 등은 모두 서버에서 이루어지고 있으며, client단은 서버에서 가공한 데이터를 가져와 얼마나 잘 표현하느냐가 중요해 졌습니다. 따로 제조사가 없는 캐나다에서 Android Developer job이라면, 결국에는 99% Android client app 개발인 것이고, Android client app에서 게임 등 별도의 UI engine을 보유한 app을 제외한다면, UI의 중요성이 가장 높은 제품이 절대 다수라고 할 수 있겠습니다. 그렇다보니 Android Developer의 seniority를 말할 때, UI와 관련된 다양한 Know-how와 Skill, Experience가 얼마나 있는지를 보는 것이 일반적이라 할 수 있겠죠.
하지만 제가 다니고있는 회사의 flagship product는 Mobile Device Management 서비스입니다. 단말 컨트롤, 통제 룰과 정책에 대한 비지니스 로직은 서버단에 구현을 하지만, 그 정책들이 각 단말로 내려왔을때, 각 단말의 context에 따라 이 정책들을 조합하여 어떻게 어떤 기능과 HW를 컨트롤 할 것이지에 대한 know how와 skill이 Android Developer로서 갖추어야 하는 기술이라고 할 수 있습니다. 
UI요? 네, 물론 저희 제품에도 UI가 있긴 합니다만, 모든 UI mock-up을 다 합쳐도 5개 화면 정도 될 것 같습니다. UI로 보여줄 만한 내용이 있는것도 아니고, UI가 있다해도 End-user가 관심을 가지고 지켜볼 만한 것도 아니기에, 그 중요성이 매우 낮습니다.

사실 회사에서 어느정도 단말 UI/UX에 관심이 없냐하면... Android OS 버그로 인해 모든 버튼이 동작하지 않는 상황이 있어서, 그런 상황이 오면 마치 페이스북 메신져 처럼 어떤 화면에서건 둥둥 떠다니는 버튼을 만들어야 할 일이 생겼었습니다. 프로젝트 매니져를 통해 회사 GUI팀에 이미지를 요청했고, 그 사이에 저는 일단 구현을 해야하니, 급한대로 gimp를 다운로드 받아 대충 아이콘을 만들어 기능을 구현 했습니다. 그런데, GUI팀이 요즘 Web UI작업에 한창이라 바빠서 PM도 그렇고 GUI팀도 그렇고 그냥 제가 30분 만에 만든 아이콘을 제품에 그대로 넣자고 하더군요. 헐...

현 상황이 이렇다보니, 만에하나... 현 직장이 문을 닫는다면? 제가 쫒겨난다면? 현 직장에서 이런저런 관계들이 악화되어 다른 곳으로 옮기고 싶어진다면? 이런 질문들에 대해 생각을 해 보았을 때, 지금의 미천한 UI Experience로는 Android Developer로서 경쟁력이 없기에, 제 경험의 폭을 넓히는 것이 중요하다 생각되어 이직을 염두하고 있는 것이죠.
그래서 언젠가부터 현재의 position대비 동급 수준의 '연봉/Benefit/근무환경/회사의 발전 가능성' 만 보장된다면 이직에 대해 언제든지 open mind로 준비하고 있었습니다.

반년 쯤 전에도 3번 면접을 본 적이 있지만, 사실 그 당시에는 detail한 technical question들이 거의 없었습니다. 그래서 제 단점을 부족한 UI 경험이라 생각하면서도 그 심각성에 대해 제대로 인지하지 못하고 있었던 것이죠.
한국 속담으로 "하룻 강아지 범 무서운 줄 모른다"를 학술적 용어로 하자면 더닝 크루거 효과(Dunning–Kruger effect)일 것 같은데, 제가 딱 그 꼴이였습니다. 삼성에서도 Platform개발자였기에 UI 경력이 전무하다보니 "다양한 화면과 OS 버젼별로 다를 수 있는 widget components들 때문에 많은 노하우와 기술이 필요하긴 하지만... UI는 그냥 노가다고, 뭐 그런 노하우야 언제든지 내가 시작하면 따라 잡을 수 있는거고, 특별한 기술과 기능이 필요한 것도 아니고......" 이런 식으로 무의식/의식적으로 무시했고, UI관련해서 아는 것도 없으면서 UI에 대한 '근자감'까지 있었습니다.

이번에 면접을 본 회사는 자체 서비스나 mobile client가 있는 회사가 아니라, 다른 회사의 업무용, 고객용, 판매용 서버와 클라이언트를 개발하여 납품하는 회사였습니다. 이쪽 업계에서는 나름 콧방귀 뀌는 수준의 회사였으며, 이 회사의 규모에 맞게, 이 회사의 고객사들 역시 대형 서비스/유통업 회사였죠. 고객사의 규모가 큰 회사다 보니, 웬만한 서버단 기능은 이미 갖추고 있는 상황이지만, 보다 고객에게 쉽고/편리하고/재미있게 다가갈 수 있는 Web/Mobile 스토어를 만들려는 것이 고객사들의 주요 목표인지라, 이 회사에서도 가장 방점을 찍는 것은 화려하고 직관적이면서 사용에 편리한 UI 디자인과 구현이였죠. 그래서인지 기술면접의 대부분은 UI와 관련된 질문들로 이루어져 있었고, 말 그대로 저는 영혼까지 탈 탈 털렸습니다. 그리고 다행히도 이제는 근자감에서 벗어나 제가 정말로 부족함을 느끼게 되었으며, 어떤 부분을 어떻게 준비해야 할 지에 대해서도 방향을 잡았네요.

면접 당시에 워낙 영혼까지 털린 상황이라 제대로 기억이 안나긴 하지만, 지금 기억나는 기술 인터뷰 내용을 조금 말씀드립니다. 아래 대화는 기술 인터뷰 중 일부를 재구성한 것으로 제 답변은 일부 생략을 했습니다 ㅠㅠ 너무 아는게 없어서 헛소리만 해대서요.

- 면접관: 피카소, 프레스코, 이미지로더 라이브러리들 비교를 해봐라. 어떤 문제나 장점으로 어떤 라이브러리를 선택해서 이용했었는지 말해봐라.

 둥이아빠: 셋 다 듣보잡인데???

- 면접관: 이미지 핸들링 어떻게 했나? 자체 라이브러리를 만들었나?, 설마... 안드로이드 비트맵 쓴건 아니지?

 둥이아빠: 다 아닌데? 우리 이미지 핸들링 할 일이 없어. 이미지 라이브러리는.... NDK 쪽에서 libjpeg-turbo C 라이브러리 쓰는거는 있어. 단말 remote control을 위해 단말에서 서버로 현재 화면 뿌려줄 때
 면접관: 헐...

- 면접관: 그래 그럼 UI 관련해서 질문 해보자. (자신의 폰에 최근 그들이 만든 명품 구두 App을 보여주며...) 여기 해쉬태그 버튼들 보일꺼야. 알파벳 순서로 정렬되어있고. 태그 종류에 따라 그 길이는 다 제각각 다르고. 지금 이 UI처럼 각각 다른 길이의 버튼들인데, 한 줄에 여려개의 버튼이 들어갈 수 있으면 다 한 줄에 표시를 하고, 한 줄에 한개만 되면 한개만 넣되 버튼들은 다 중앙 정렬되야되.
이런거 할 때 레이아웃은 어떤거 써야 할까?

둥이아빠: 흠... 글쎄? 그냥 리니어나 리스트 레이아웃으로 밖에 큰 틀을 잡고, 각 줄 마다 릴레이티브 레이아웃으로 버튼 배치하면 안될까? 사실 나 레이아웃 종류들도 다 몰라. UI쪽은 1년에 한 번 코드 볼까말까 할 수준이라. 그렇게 하면 안될 것 없을 것 같은데, 더 효율적인 방법이 있어?

- 면접관: 흠... 그럼 그냥 Material & Motion쪽으로 넘어가보자. 아, 혹시 카드뷰가 어느 OS 버젼부터 가능한지 아니?

 둥이아빠: 매 OS 발행 때 마다 변경사항 체크하지만, UI쪽은 신경 안써서... 그거 구글 나우랑 같이 소개한걸로 기억하는데... 롤리팝이던가? 마쉬멜로는 확실히 아니고.... 롤리팝에서 킷켓 그쯤 일것 같은데?

- 면접관: 뭐 그건 넘어가고.... (폰을 다시 보여주며) 여기 상단 탭하고, 하단 탭 보이지?
상단탭 1이 하단 탭 1/2/3과 엮이고, 상단탭 2는 4/5 하고 엮여있어. 컨텐츠를 좌우 스와핑을 하면 탭이 이동되는데, 탭 3에서 4로 넘어갈 때 봐봐. 상단 탭 1에서 2로 포커싱 바뀌지? 이거 어떻게 하면 될까?

둥이아빠: 흠... 난 이런거 고민 해 본 적이 없는데. 그냥 하단 탭 변경될 때 상단 탭 포커싱도 같이 바꾸면 안되나? 근데 어떻게 하는지는 해 본적이 없어서 모르겠네. 어려울 것 같지는 않은데 말이야.

- 면접관: 흠... 그래 그럼 이걸 봐봐. 좌/우 스와핑을 천천히 할테니 상단과 하단 탭을 잘 봐봐. 스와핑이 완료되지 않고 진행중일 때 하단/상단 현재 탭에 포커싱 되어있다는 표시가 점점 옅어지면서 그 옆에 탭으로 포커싱이 이동되고 있는 게 보이지? 이건 어떻게 구현할래?

둥이아빠: 흠... 글쎄 이 역시도 고민 해 본 적도 없고 생각 해 본 적도 없어서. 이거 그냥... 흠... 카트 스타일 위젯을 쓴 적도 없고 좌우 스와핑 UI 이벤트 역시 해 본 적 없어서 이 프로그레스가 어떻게 전달되는지 잘 모르겠네. 1시간 정도 주어지면 앉아서 이것저것 찾아보면 할 수 있을것 같은 기분이긴 한데...

- 면접관: 헐... 그럼 좌우 말고 내가 상하로 가볼께. 컨텐츠 영역을 위로 올리면, 여기 봐봐, 상단 탭이 배너를 먹고 들어가면서 점점 컨텐츠 영역 디스플레이가 넓어지지? 그리고 다시 내리면 배너가 나오고. 이런건 어떻게 할까?

둥이아빠: (이젠 포기모드) 나 진짜 1시간 주면 할 것 같은데? 지금 말하라면 모르겠어

- 면접관: (면접관도 포기모드인듯...) 너 진짜 UI 모르는구나? 
 그럼 이거봐봐 (점점 면접 모드에서 자기 제품 자랑모드로 변경) 
 카드에서 좌우 스크롤하면 탭 이동이지? 근데 카드에서 이쪽에서 터치해서 좌우 스와핑하면 컨텐츠 삭제야. 이건 어떻게 할까?
컨텐츠 삭제할 때 카드가 날아가는 UI 이펙트가 이런 식이야. 이런거 만들 수 있겠어?
컨텐츠 카드 선택하면 그 컨텐츠가 전체화면으로 나올꺼야. 그런데 이거봐봐. UI 이펙트가 이렇게 들어가. 이건 어떻게 할까? 라이브러리 쓸까? 안드로이드 자체로 이런게 될까?, 여기 네비게이션 패널하고 컨텐츠가 이렇게 서로  상호 연동이 되는데...
등등...

둥이아빠: 몰라, 몰라, 몰라, 야~ 이 앱 이쁘다~. 몰라, 몰라..... (완전 포기하고 어떤 것을 내가 공부해야 할 지 보는것에 집중)

참... 이거야 정말 제 이야기이지만, 제가 봐도 답답할 정도로 정말 아무것도 제가 모른다는 것을 느끼고 말았습니다.

나중에 찾아보니 안드로이드 공식 리퍼런스의 디자인 파트 페이지를 열면 딱! 나오는 내용들일 정도로 기본중에 기본인 내용들이더군요. https://developer.android.com/design/index.html
저는 안드로이드 개발자로 일을 하면서 이런 페이지가 있는지조차 사실 알지 못 할 정도로 단 한번도 UI를 심도있게 공부 해 본 적이 없었습니다.
아무것도 모르면 자신감이 100%에 이르고, 아는게 많아질 수록 자신감은 떨어지다가 어느 수준에 이르르면 다시 지수함수 형태로 자신감이 올라가지만, 최고의 자리에 있을 때라도 자신감이 100%에는 미치지 못한다는 Dunning-Kruger effect. 이건 정말 사실이였습니다.

정말 아무것도 모르면서도 UI는 무시했고, 그냥 "난 다 할 수 있어" 라는 자만심에 빠져 아무런 대비도 없이 면접에 나갔던 제가 잘못을 한 것이죠. 더구나 복잡한 비지니스 로직 보다는 화려하고 안정적이고 직관적인 UI가 사업의 핵심인 회사에 지원을 했으니...

그 동안 다른 면접을 봤을 때만 해도, 이렇게 직접적으로 UI와 관련된 질문을 받기 보다는, 프로젝트 설계나, 데이타 커뮤니케이션 구현 등 현재 제 업무와 비교적 유관한 분야만 질문을 받았었는데, 진짜 순도 100% UI 질문 공세를 받으니 말 그대로 영혼까지 탈탈 털리고 말았습니다.

그래도 참 다행인 것은, 'UI를 해야겠다' 라는 것 까지만 인지하고 있었던 제가, 이제는 'UI에 대해 난 하나도 모르는구나. 내 스스로라도 좀 공부를 해서 뭐라도 하나 만들어보고 경험 해 봐야겠다' 라는 것을 느꼈다는 것입니다. 그래서 언젠가 다가올 이직의 순간에 대비하고자, 앞으로 https://developer.android.com/design 에 보이는 모든 레이아웃과 모션들이 적용된 샘플 앱을 하나 만들어 보려고 합니다. 아마도, API와 SDK가 비교적 잘 되어있는, Facebook이 그 대상이 되지 않을까 싶근 하네요. 정확히 기억은 안나지만, 제가 면접을 봤던 회사에서 했던 UI들과 비슷한 기능들을 좀 넣어보려고요 ㅋ

아, 지금 저의 자신감이요??? 이젠 0%! 바닥을 쳤습니다. 제 헤드헌터에게 다시 연락이 온다면, 그냥 당분간 난 이직 생각 없으니 전화하지 말라고 이야기 해야겠어요 ㅎㅎㅎ