정체성의 혼란

팀을 옮긴지 이제 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년 조금 넘었다고 열정은 있으나 거만하고, 눈치없이 자기 목소리만 너무 내세우지만, 그렇다고 또 어디 가서도 지지않을만큼 당당한 실력도 갖추지 못한... 그런 애매한 실력에 성격도 좋지 못한 개발자가 된 것 같네요.

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

My 5th career path

연말-연시 휴가 복귀 후 1~2월달에 이런저런 일들이 참 많이 일어났습니다.

우선 휴가에서 복귀를 하자마자 긴급 프로젝트에 투입되어 한시적으로 다른 스크럼 팀으로 소속이 변경었습니다.
말 그대로 긴급 프로젝트인지라 오래간만에 숨이 턱 밑까지 차오를 정도로 바쁘게 돌아가는 스프린트를 경험했죠. 또, 오래간만에 테스트 프레임웤이 갖춰지지 않은 상태에서 개발을 하다보니 Biz Logic 구현보다 Test Code와 Test Framework 구현에 더 긴 시간을 투자해야 하기도 했고요.
그러다보니 거의 1년여 만인 듯 한데, 회사 요청으로 주말 근무를 하기도 했고, 제 스스로도 시간가는 줄 모르고 일을 하다보니 퇴근 시간이 거의 7~8시를 넘기기도 했고 때로는 새벽까지 일을 하기도 했네요.

마지막으로 이런 보람과 성취감, 그리고 업무 집중도를 느꼈던 것이 언제였는지 기억이 가물가물한데, 이번 1~2월은 일의 양과 만족도를 느꼈던 시즌이였습니다.
이렇게 1달 반 가량동안 긴급 프로젝트 Phase I의 목표를 모두 완료하고 원대복구를 해야 하는 시점에 저에게 더 큰 변화가 다가왔습니다.

이 프로젝트의 마무리로 한창 바뻤던 지난 금요일, 개발팀 VP와 매니져와 찾아와 잠깐 조용한 곳으로 가서 이야기 하자고 불렀습니다.
거의 매일 VP가 찾아와 진행상황 업데이트 요청을 하면서 살짝 쪼이고 있던 상황인지라, 솔직히 조금 긴장을 하긴 했었습니다.

"혹시 지금 아키텍쳐가 잘못됐다는 리뷰가 나왔나?"
"너무 진척이 느리다는 질책일까?"
"아니면... You are fired!!! 라는 말이라도 하려는건가???"

빈 회의실을 찾아 다른 층으로 이동하는 도중 제 표정이 살짝 굳어있었던지,
"Don't worry, nothing bad."
라고 말을 해 주었지만, 딱히 좋을만한 일도 없던 상황이라 그다지 안심이 되지도 않았습니다.

드디어 비어있는 회의실을 찾아 자리에 앉은 후 먼저 매니져가 말을 꺼냈습니다.

매니저 "너 이번 스프린트 끝나면 AFW 팀으로 복귀하는거 알지?"

나 "응"

매니저 "너 없는 사이에 팀 전체가 거의 NG UI쪽에 몰빵하고 있는 것도 알지?"

나 "응 알아. 그래서 나 가면 할 일 없어서 놀까봐 걱정이긴 해. PM한테 백로그에 있는 에이전트 스토리 몇 개 올려달라고 하거나 아니면 내키진 않지만 나도 Node JS랑 Angular JS 배워야지."

VP "너 Continuous Delivery, DevOps에 대해 얼마나 알아?"

매니저 "얘가 안드로이드 BDD 테스트 프레임워크 구축할 때 Android쪽은 Jenkins로 빌드 파이프라인 만들었어. DevOps팀이 바빠서 대응이 늦어서"

VP "나도 알거든! (VP가 당시에 빌드팀 매니져였고, 관련하여 약간의 아규가 있었음) 너 그 쪽에 관심 좀 있니?"

나 "난 그냥 내가 정말 필요해서 한거지 꼭 관련 경험이 있다거나 아는게 있어서 한건 아닌데?"

VP "그냐? 까놓고 이야기 하자. 지금 DevOps팀에서 업무목표 잡은거 진행상황이 limbo 상태다. 반년 넘게 지나도 목표 성능이 안나와. 자바기반 빌드서버 좀 뜯어고치고, 튜닝하고, 플러그인 개발하고, 등등 할 사람이 필요한데... 팀 구성 전부터 거의 1년간 DevOps Engineer 고용하려고 반년간 찾아봐도 마땅한 사람이 없다. 그래서 마지막 방법으로 내부에서 인력 전환이나 한시적으로라도 도움을 받아야 하는데, 너 그거 할 생각 있니?"

나 "만약에 DevOps가면 이거 지금 하는 것 처럼 temporary야 아님 permanent야? 나 다시 안드로이드 할 기회는 있긴 한거야?"

매니져 "그건 내가 말하지. VP도 나한테 양쪽 모두 원하면 한시적으로 할 수 있다고 약속했어. 그러니까 원하면 언제든 와도 되. 난 너 잠깐 갔다가 돌아오면 좋겠다. 그치?"

VP "응. 나 약속 했어. 한시적인게 맞긴 한데... DevOps 목표가 달성하려면 아마 앞으로 최소 1년일꺼야. 2년 이상도 생각하고 있음. 그건 알아둬라"

나 "오케이. 1년이건 2년이건, 목표만 달성하면 돌아올 수 있다는거지?"

VP "사실 지금도 계속 리크루팅 하고 있어. 너 가봤다가 잠깐 보니 맘에 안들었다! 그리고 우리가 결국 hiring에 성공했다! 그러면 언제든지 돌아올 수도 있음. 근데 어찌되었건 일단 가면 이 프로젝트가 끝났거나, 대체 인력이 마련된 경우에는 복귀 가능함."

나 "그럼 나 소속팀이 일단 바뀌는거임? 아님 기존 팀 소속이지만 파견임?"

VP "팀 바뀜"

나 "그러면 나 당장 뭐하게 됨?"

VP "당장은 지금 하고있는 프로젝트 마무리부터!!! 이게 더 급함. 그리고 가장 중요한건 네가 DevOps 하고싶은지 의지가 있는지, 열정이 있는지가 중요함. 일단 옮기면 Knowledge transfer랑 현 상황 업데이트는 그 팀에서 받을꺼임"

나 "그래? 나 기본적으로 새로운 일 해보는거 좋아해. 그리고 언제가 되었건 원하면 결국엔 돌아올 수도 있고, 가면 새로운 일 해 볼 수 있으니 nothing to lose네? 그럼 콜!"

VP "콜! 너 지금 말 final call로 받아들여도 되지?"

나 "그래. 나 옮길꺼란 말도 final call 맞지?"

VP "아... 그팀 매니져한테도 이야기 해봐야지. 경력자 끌어오기는 잠정적 실패고 대신 너 간다고. 오늘중으론 final call 줄께."

나 "퇴근전엔 꼭 알려줘. 결과에 따라 주말에 내가 읽을 책 제목이 바뀔지도 모르니"

그렇게 회의실을 나선 후 사실 일이 손에 잘 잡히질 않았습니다. 사실 승낙을 하긴 했지만, DevOps라는 롤에 대해 제가 이해하는 바도 부족했고, 기존 이 회사 내에서 Android Developer의 업무 scope와 시장에서의 needs간 차이로 커리어 고민이 있던 차에 받은 제안인지라 덥썩 물어버린 측면도 있었거든요. 그렇게 어영부영 오전 업무시간을 보내고 점심 시간에는 DevOps에 대해 이리저리 조사를 해보았고, 생각했던 것 보다 더 괜찮은 도전이 될 것 같다는 생각이 들었습니다.

그리고 그날 오후 4시, 토론토에서 열리는 세미나 참석으로 조금 이른 퇴근을 하려는데, 아직 가타부타 답변을 듣지 못했죠. 그래서 VP에게 메일을 한 통 보냈습니다.

"나 옮기는겨 마는겨?"

그러자 VP가 아래와 같이 답장을 주었습니다.

"Read Continuous Delivery, by Jez Humble. And The DevOps Handbook."

제가 주말에 읽을 책 제목을 정해 주었네요.

그리고 지난 주말부터 Continuous Delivery, DevOps 등 관련 강좌와 책을 읽기 시작했답니다. 이제 다음 주 부터 시작하게 될 일인지라 정확히 무엇을 해야하고, 어떤 어려움이 있을 것이고, 어떤 스킬셋을 새로 익히게 될지는 아직 모르지만, 오래간만에 다가온 변화가 다시 저를 설레게 하고 있네요.

한국에서 Developer처럼 저와 찰떡처럼 잘 맞지만 육체적/정신적으로 힘들지, PM처럼 재미 없지만 그럭저럭 잘 할 만한 일질지, 영업처럼 재미도 없고, 힘들고, 성과도 안나올 일일지 모르겠지만, 불확실성과 새로움으로 인한 설레임과 긴장감의 경계선 위에서 저의 5번 째 커리어인 DevOps Engineer를 시작해 볼까 합니다.

Back to basics

지난 주말에 느낀 점이 있어서 Junior 기준 Technical 인터뷰에서 질문하는 질문 형식들에 대해 간략하게 포스팅을 남길까 합니다.

GTA지역 한인 개발자 모임에서 구직자 몇 분이 모여서 취업 스터디를 같이 해 오셨는데, 그 마지막 스터디로 모의 인터뷰를 하는데, 저를 비롯한 몇 분께 interviewer 롤을 맡을 수 있는지 부탁을 하더군요. 사실 저는 Interviewer로서의 경험은 한 손에 다 꼽힐만큼 적고, Interviewee로서의 경험 역시 열손가락에 한참 부족할 만큼 적은 상황인데다, Junior로서 제대로 인터뷰를 본 것은 달랑 한번인지라 거절을 했지만, 이런저런 사유로 모바일 쪽에 다른 경력자들 께서 사정이 여의치 않다보니 제가 모의 인터뷰의 Android쪽 기술 인터뷰 Interviewee로서 참석을 하게 되었고, 그래서 기존에 경험들을 기반으로 인터뷰 질문지를 준비 했었습니다.

캐나다에서 첫 인터뷰를 하고, 처음으로 취업에 되었을 때 올린 글에도 당시에 제가 받았던 질문들에도 나와있는데, 사실 캐나다에서 이후에도 시니어 포지션으로 면접을 볼 때에도 거의 항상 나오는 질문 유형들이 있습니다. 

첫 번째 유형의 질문셋은 이 포스팅 제목에서도 감 잡으셨겠지만, 아주 fundamental하고도 기본적인 그런 질문들입니다.
두 번째 유형은 지원자의 실제 경력이나 경험을 파악하고자 하는 의도가 있는 질문들로 회사 업무에서 바로 사용하게 될 특정 skill set에 관련된 in-depth 질문들입니다.
그리고 마지막 유형은 코딩 능력과 간단한 알고리즘 이해/구현 능력을 보는 질문들입니다.

사실 인터뷰에서 질문을 하는 내용이나 틀은 각 회사마다 다 다르겠지만, 인터뷰 틀이 어느정도 잡힌 회사들이라면 보통은 이와 같은 틀 내에서 움직입니다.

첫 번째 fundamental 질문의 예를 들자면,

- Class/Interface/Abstract Class는 어떻게 다르죠? 어떨 때 어떤 것을 사용하나요?

- 오버라이딩과 오버로딩에 대해 설명 해 보시겠어요?

- xxx 키워드에 대해 설명 해 보시겠어요? 어떨 때 그걸 사용할까요? (final, static, synchronized...)

- Activity와 Service는 무엇이 다르고 무엇이 같죠?

- Android에서 Context가 무엇일까요?

- Activity와 Fragment 라이프사이클과 각각의 콜백에서 놓치면 않되는 중요한 행위들이 무었이 있고 왜 그것이 중요한지 몇가지만 설명 해 보실래요?

회사 내부 인력 사정상 피치못하게 제가 기술면접에 Interviewer로서 나가게 되었을 때에도, 회사 팀 리드들이 미리 뽑아놓았던 문제은행(?)에도 이런류의 질문은 반드시 처음에 있었고, 시니어 포지션으로 다른 회사에 면접을 볼 때에도, Junior 때 보다는 비중은 줄었지만 적어도 한 두 문제 정도는 이런 류의 질문이 꼭 나왔었습니다.

그리고 제가 Interviewer로 나가기 전에 교육 받은 내용에도 그랬고, 제가 Interviewer로서 느낀 바로도 그랬는데, 질문은 interviewee의 백그라운드에 따라 꼬리에 꼬리를 무는 방식으로 진행이 됩니다.

즉 쉬운 질문부터 시작해서 점점 난이도가 있는 질문들을 던져보며 지원한 포지션에 맞는 스킬셋에 대해 어느정도의 seniority를 갖췄는지 판단하기 위함입니다. 그리고 간단한 알고리즘 구현에 대한 코딩 시험을 거치며 1) 단순히 달달 외워가며 인터뷰만 준비한 사람인지 아닌지도 확인 해 보고, 2) 코딩 습관이 어떤 사람인지도 파악 해 보고, 3) 문제에 따라 덤으로 얼마나 꼼꼼한 사람인지도 확인 해 봅니다.

한 손으로 꼽을만큼 적은 경험이지만, 제가 Interviewer일 때에 이런 fundamental 질문들은 사실 형식적으로 던졌습니다. 당연히 답변을 할 것이라고 기대는 깔고 있었고, 실제로 제가 interviewer로 나갔을 때에는 대부분의 interviewee들이 이런 질문들에 대해 적절히 대응 했었습니다.

그 다음 질문셋은 지원한 롤에서 요구하는 기술셋에 대해 어느정도 지식과 경험이 있는지 판단하는 그런 류의 질문들입니다. 사실 하나하나 놓고보면 어려운 질문은 아니긴 하지만, 회사에 오면 당장 자주 부딛칠 수 있는 일들에 대한 내용에 대해 얼마나 경험이 있는지, 혹은 경험은 없더라도 이론적으로라도 이해하고 있는지 보는 것입니다.

예를들면 제 직전 포스팅에서 처럼, 화려한 UI 구현이 필요한 회사라면 다양한 UI 구현 Skill에 대한 질문이나, 안드로이드에서 Service/Intent Service/Thread/AsyncTask에 대한 질문, 혹은 최근 안드로이드 OS에 추가된 Run time permission이 뭔지 또 어떻게 app에서 대응해야하는지, Doze Mode는 무었인지, 또 각 app은 이를 어떻게 처리해야 하는지 같은 질문을 할 것입니다. 

저희 회사의 경우는 업무 특성상 UI가 거의 없기에 보통 묻는 질문들이 Android Fundamental과 과련된 질문들이 좀 더 많습니다. 예를들어, Looper/Handler 설명, Android에서 각 app은 어떻게 isolated된 환경에서 구동되는 것인지, Shared UID, package signing은 무엇이고 대략적으로 어떻게 동작하는 것인지, Permission Level, Out Of Memory가 무엇이고, 어떻게 하면 이를 최대한 회피할 수 있는지 등등...

그리고 Junior인 경우 (혹은 기존 경력들이 있지만 우리가 지원자에 경력에 대해 잘 감이 안잡히는 경우. eg. 찾을 수 없는 회사 경력, 전혀 모르겠는 외국 회사 경력. 정말 상품화 과제를 한 적이 있는지 잘 모르겠는 경력 등등)에는 toy project에서는 구지 필요 없지만, 상용화 프로젝트에서는 필요 한 그런 기술들을 좀 더 자주 물어봅니다. 예를들어 Android에서 Unit Test, Instrumented Unit Test는 어떻게 하는지, Proguard는 뭐고 왜 쓰는지, 그리고 이런 것들을 한 번이라도 해 본 적 있는지 등등...

이런 류의 질문셋에서 간혹 안좋은 질문들을 보는 경우도 있는데, 특정 오픈소스 혹은 유료 라이브러리에 대해 별다른 배경설명 없이 직접적으로 질문이 들어가는 경우들입니다. 사실 이런 라이브러리들은 말 그대로 각 프로젝트 성격에 따라 다른 라이브러리로 변경이 될 수도 있고, 또 그럴 때 마다 필요에 따라 reference보고 몇몇 라이브러리 도입 acceptance test를 해보면 다 알 수 있는것이라 단순히 경험의 많고 적음만 볼 수 있지 경험의 깊이를 알기에는 일반적으로 어려운 질문들이기 때문이죠. 특정 라이브러리를 직접 언급하면서도 나름 괜찮았다고 생각했던 질문이 하나 있었는데, 특정 라이브러리의 어떤 API의 입력값/출력값, 그리고 내부 동작 원리를 간단히 설명하고, 제품 요구사항을 설명하더니, 이렇게 요구사항과 API behaviour가 상이한데 어떠한 방식으로 Wrapper Layer를 구현하면 좋을까 라는 질문이였죠.

그리고 회사에 따라 퀴즈, 혹은 해커톤에 가까운 번뜩이는 아이디어나, 복잡한 알고리즘 적용을 하는 류의 문제가 있기도 합니다. 저희 회사에서도 제가 입사하기 이전에는 이런 문제들을 종종 냈다고 하는데, 이런 류의 문제는 사람이 얼마나 학술적인 혹은 수학적인 사고능력을 갖췄는지 판단하는데 도움이 되지만, 실제 업무에서 이런 이슈를 만나는 경우가 거의 없기에, 업무능력 판단에는 무의미하다는 내부 결론으로 제가 아는한 요즘에는 이런 유형의 문제는 내지 않습니다.

그리고 코딩 문제는 사실 많이 어려운 문제는 아닙니다.

간단한 소팅이나, 루프, 재귀, 자료구조나 tree traversal같은 류를 구현하는 문제들이고, 만약 문제 내에 특정 알고리즘알아야만 하는 것이라면 해당 알고리즘의 설계 원리도 미리 알려주기에 interviewee 입장에서는 이를 적절히 구현만 하면 되는 식의 문제입니다.

코딩 문제에서는 당연히 이 사람이 알려준 알고리즘을 제대로 구현하는가를 먼저 봅니다. 그리고 구현해 냈다면, 이 사람의 코딩 습관이나 스타일도 간략하게 확인 합니다. 문제 성향에 따라 이 사람이 주어진 요구조건에 맞는 절절하고 효율적인 자료구조형태나 설계를 했는지도 보기도 하고요. Junior 면접 때에는 특히나 일부러 HashSet(or HashMap)을 쓰는 것이 딱 맞는 문제나, 중복 키/값이 반드시 있을 수 밖에 없기에, 혹은 잦은 sorting이 필요하기에 무조건 쓸 수 없지만 왠지 Hash를 써야만 할 것 처럼 첫 인상을 주는 문제 유형을 만들어서 내기도 합니다. Hash의 유혹에 전혀 흔들리지 않는 것 같으면, "여기 이거 HashSet 쓰면 안될까?" 라고 일부러 질문을 던지기도 하고요.

그리고 앞선 질문들과 코딩 문제를 잘 소화해 냈다면 기존 문제에서 확장을 해보거나, 우리 내부적으로 봤을 때 조금 더 어려운 난이도의 문제를 한두개 더 내기도 합니다.

예를들어 3/6/9 게임하고 비슷한 Fizz Buzz라는 게임이 있습니다.

차례대로 숫자를 말하되 3의 배수라면 숫자 대신 Fizz가, 5의 배수라면 Buzz를 말해야 하고, 3과 5의 공배수라면 FizzBuzz를 말해야 하는 게임입니다.

그러면 첫번째 난이도 문제로 1~n까지 FizzBuzz 게임 룰로 stdout 출력하는 프로그램을 짜보게 합니다.

두번째로는 배수 뿐 아니라 그 수의 첫번째 자리수 혹은 마지막 자리수의 숫자가 3이면 Fizz 5면 Buzz가 나오는 것으로 확장하여 수정을 요구합니다.

마지막으로는 자릿수에 상관없이 3이 들어가는 숫자는 다 Fizz, 5가 하나라도 들어가면 Buzz 나오는 것으로 수정을 요구하죠.

그래서 제가 이번 스터디 용으로 준비한 질문지 역시 위에 언급한 내용들로 준비를 해갔는데, 예상치 못한 변수로 인해 사실 첫번째 Fundamental 질문 이외의 질문은 거의 하지 못했습니다.

우선 참석자들의 데모그래픽을 보자면 대부분 캐나다로 오시기 이전에는 SW Developer 경력과 학력이 보통 없으셨고, 있더라도 10~20여년 전 경력인 분들이셨기에, 사실상 캐나다 컬리지를 통해 SW 관련 공부를 처음 하시거나 새로 하신 분들이셨습니다. 그래도 학교 재학도중 매 코옵 학기마다 코옵 쟙을 잘 구해 경력을 이미 어느정도 만드셨거나, 포트폴리오로 쓸 만한 수준의 App을 이미 개발하여 올리신 분들도 있었죠.

하지만, 저로서는 처음 접한 경험이긴 한데, 면접 시작부분에 묻게되는 Fundamental 질문에서 열에 아홉은 대부분 답변을 하지 못하였습니다. 단순한 언어의 장벽으로 제대로 설명이 못된 것이 아니라 OOP의 기본 철학에 대한 이해가 없다는 것을 느꼈죠. 제가 다른 포스팅들에서도 틈이 날 때 마다 캐나다 컬리지의 실망스러운 학업 수준에 대해 언급을 했었는데, 이번에 구직 스터디에 참석을 하면서 이러한 문제가 단순히 제가 다녔던 컬리지만의 문제는 아닐것 같다고 다시한번 느끼게 되었습니다.

워낙 컬리지에서 배우는 SW는 기본적인 이론에 대해 충분한 생각과 학습을 하기 보다는 일단 IDE 띄워서 메인 메소드 만들고 커맨드 창이건 UI로건 뭔가 빨리 보여주는 것만 배우다보니 아주 기본적인 개념에 대한 학습과 이해가 부족할 수 밖에 없는 것이이라 생각합니다.

아무래도 인터뷰의 서두에 Fundamental 질문에서부터 꽉 막히다보니, 이후 참석자의 seniority level이나 경험을 확인하기 위해 파고들어가는 인터뷰가 진행될 수 없었던 것입니다. 그리고 당시 제가 느꼈던 솔직한 심정은 이후 코딩 테스트에서 잘 동작하는 코드를 만드신 분들 역시 썩 좋은 느낌이 아니였고, 만약 이것이 진짜 인터뷰라 인터뷰 결과를 보고해야만 한다면 저는 부정적인 피드백을 남겼을 것 같았습니다.

Back to basics. 언제나/누구에게나 중요한 일이긴 한데, 혹시나 컬리지를 통해 개발자가 되신 분이라면, 워낙 이 basic fundamental을 건너띄는 컬리지들이많다보니, 더욱 더 중요할 수 있다고 느꼈습니다.

아, 마지막으로 첨언을 하자면, Junior 포지션의 인터뷰에서는 사실 모든 질문에 답변을 받을 수 있을 것이라는 기대를 사실 않습니다. 하지만 Fundamental 관련된 질문들에 대해서는 지원자가 명확하게 컨셉을 잡고 있거나, 아니면 그렇다고 느껴지는 수준을 (말로 풀어서 각각의 개념 설명은 잘 못하지만, 어떤 경우에 어떻게 사용해야 하는지 잘 알고있는 경우) 기대합니다. 어차피 개인 프로젝트에서는 고려 할 일이 적거나 없는 실무 경험기반 지식들은 와서 하나씩 스스로 배울 수 있다고 생각하니까요. 

당연히 모든 질문에 정확한 대답을 한다면 좋겠지만, 그렇지 않더라도, 강한 fundamental 지식을 보였고, 코딩 능력도 부족함이 없었다면 인터뷰 후 좋은 피드백을 줍니다. 적어도 Junior로서 기대 할 만한 능력을 보인 지원자이기 때문이죠. 반대로 다른 질문들은 다 대답을 했지만, fundamental 질문에 대해 적절히 대응을 하지 못한 지원자인 경우에는, 저희 회사는 일단 그런 지원자는 선발하지 않는 것으로 공감대가 있습니다. 손기술만 있는 Coding Monkey를 채용하면 근본에서부터 잘못된 설계로 인해 잠재적으로 더 큰 문제를 만들어 나아 갈 위험이 크기 때문입니다.

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%! 바닥을 쳤습니다. 제 헤드헌터에게 다시 연락이 온다면, 그냥 당분간 난 이직 생각 없으니 전화하지 말라고 이야기 해야겠어요 ㅎㅎㅎ

Christmas and New year vacation

어느덧 2017년이 되어 블로그를 시작한지 벌써 2년이 꼬박 지나갔군요. 아직 많이 젊은 나이이긴 하지만, 한 해 한 해 나이가 들 수록 시간이 참 빨리 지나가는 것 같다는 느낌이 듭니다. 

요즘 몇가지 개인적인 사정으로 인해 2달 정도 블로그가 뜸했는데요, 2017년 업무목표에서 가장 중요한 부분을 가능한 연말 휴가 전까지 끝내고 싶은 마음에 연말에 회사 일에 조금 집중을 했었고, 크리스마스 전부터 어제까지는 오래간만에 부모님을 뵈러 New Zealand에 여행을 다녀오느라 포스팅이 없었습니다.

오늘 포스팅은 딱히 주제는 없고 그냥 여행중에 들은 생각들에 대해 잠깐 적어볼까 합니다.

이번 여행은 본의아니게 이민 복기 여행이였습니다. 이번 여행의 목적지인 뉴질랜드는 최초 이민 목표 국가였고, 중간 경유지였던 벤쿠버는 캐나다 이민을 결정한 후 잠시 고민했던 랜딩 지역이죠.

중간 경유지인 벤쿠버에서 경유 대기시간이 8시간이 조금 넘었기에, 벤쿠버 다운타운으로 나가 이전에 살던 아파트도 가보고, 학생 시절에 돈이 없어서 혹은 아까워서 잘 가지 못했던 식당에도 다시 한 번 가보고, 매일 걷던 Davie street와 Robson street, 그리고 제가 다녔던 학교 캠퍼스 앞에도 잠시 가봤습니다. 10년이 넘게 세월이 흘렀지만, 벤쿠버 다운타운 쪽은 그다지 큰 변화가 없었기에 다행히 도보로 이곳 저곳을 둘러 보면서 길을 헤매는 일은 없었습니다. 변한 것이라면 아마도 하늘 높은 줄 모르고 올라가고 있는 벤쿠버의 주택 가격 정도가 아닐까 싶네요. 하긴 그 때에도 벤쿠버 부동산 가격은 거품이라고들 했으니 가격이 비싸다는 사실은 그대로겠죠.

하지만 벤쿠버를 바라보는 저의 마음, 그리고 제 아내의 마음이 조금 바뀌었습니다.

이민을 오기 전, 정착지를 정할 때 저는 벤쿠버 인근과 토론토 인근, 두 지역을 마음에 두었습니다. 일자리 시장은 벤쿠버에 비해 토론토가 더 크다지만, 시장이 큰 만큼 더 많은 인력이 있을 것이고, 시장이 작은만큼 더 적은 인력이 있을테니 큰 차이는 없을 것이라고 생각했고, 아무래도 잠시나마 정을 붙였던 곳이기에 벤쿠버에 대한 애정이 조금 더 컸죠. 사실 토론토 쪽에 온 이후에도 주택문제만 어떻게 해결 되고, 벤쿠버쪽 회사에서 오퍼만 온다면, 벤쿠버로 가고 싶다는 생각을 간간히 하기도 했고요. 학생 시절에는 차가 크게 필요도 없었고, 차를 탈 만한 여유도 없었기에 대중교통 이용이 (비교적) 편리한 다운타운에서 친구들과 함께 아파트 렌트를 하며 살았습니다. 당시에는 다운타운에서 삶이 참 좋았죠. 아파트 바로 앞에는 해변이 있고, 해변을 따라 조금 뛰면 벤쿠버가 자랑하는 Stanley Park가 있고, 조금만 걸어가도 Safe way 같은 마트와 커뮤니티 센터같은 편의 시설들이 있기에 학교 통학하고, 장보고, 운동하고 놀기에 최적의 조건이였습니다. 또 스키를 좋아하는 저로서는 차로 30분만 가도 스키장들이 있고, 2시간만 가면 세계 최고의 스키장인 Whistler Blackcomb 스키장이 있었기에 겨울철 주말만 되면 Greyhound버스를 타고 스키장으로 향했던 행복한 기억이 있습니다.

하지만 막상 가정이 생기고, 아이가 있는 상황에서 다시 벤쿠버를 가보니 벤쿠버로 가지 않기를 잘했다는 생각이 들었습니다. 다운타운에 제가 살던 곳을 다시 가보니 아이 교육을 위한 환경은 아니였습니다. 우선 주택 밀집지역이 아니기에, 도보로 통학 가능한 학교를 찾기 힘들었습니다. 도보 통학이 어렵다면 차량이 필요한데, 벤쿠버의 오래된 아파트에는 주차장이 그다지 여유가 없고, 있다해도 주차장 렌트비가 부담스러운 수준입니다. 주차장을 구했더라도, 오래전 형성된 도시이기에 길이 좁고 막힙니다. 아이들과 함께 산책을 나가려해도 골목마다 홈리스들이 한명씩은 있습니다. 예전에도 홈리스들을 많이 봐왔지만, 최근 신종 마약의 과복용으로 인해 하루에 벤쿠버에서만 열댓명씩 사망을 하고 있다는 뉴스를 봐서인지 무언가 더 불안하게 보였습니다. 그리고 벤쿠버는 겨울철 내내 하루 종일 비가 내립니다. 내려봐야 부슬비 수준이라 강수량을 높지 않겠지만, 하루 종일 흐리고 부슬부슬 비가 내리죠. 제 아들이 벤쿠버 길을 거닐다가 이런 말을 하더군요. 

"옥빌에는 겨울에 눈이 많이 내려서 밖에 나가 눈썰매도 타고, 눈싸움도 하고, 눈사람도 만들고 노는데, 벤쿠버엔 비만 내리고, 비싸움이나 비사람이나 비썰매는 없으니 여기서 살면 놀게 없어서 심심할 것 같아요"

그리고 아이들 뿐 아니라 저와 제 아내 역시 이런 비오는 날씨가 달갑지 않았습니다. 10여년 전 피끓던 20대 시절에는 문제없던 날씨였지만, 영상 1~10도 언저리의 기온에 부슬부슬 내리는 비를 맞으며 돌아다니다보니, 영하 10~20도의 토론토 겨울철에도 느끼지 못했던 뼛속이 시린 느낌을 받기 시작했습니다. 토론토는 그래도 상점들과 건물들의 난방이 잘 되어있다보니, 카페나 상점에 들어가 몸을 녹이면 됐는데, 벤쿠버는 본격적인 난방을 하기에는 또 애매한 날씨라 간간히 카페에 들러 커피와 핫쵸코를 마시며 몸을 녹이는데도 추운 기운을 느끼게 되더군요.

다운타운을 벗어나거나, North Vancouver, Richmond, Burnaby, Coquitlam, Surrey 등지의 residence area로 가면 학교도 많고, 환경이 나아지기는 하지만, 하루종일 해가 뜨지않고 부슬부슬 내리는 비는 피하기 힘들고, 역시나 가장 큰 문제는 역시 돈! 벤쿠버 인근지역 주택가격은 제가 감당 할 수준이 아니였습니다. 집을 구했다 해도, 지금 살고있는 집보다 더 좁고, 낡고, 더 외곽에 위치한 안좋은 집이였을 것이고요.

그렇게 벤쿠버와 8시간의 짧은 만남을 뒤로하고 다시 비행기에 올라 뉴질랜드로 갔습니다.

뉴질랜드에서 2주간 부모님과 함께 즐거운 시간을 함께 보낸 것은 뭐 말 할 필요가 없는 것이고, 뉴질랜드에서 지내며 느낀 몇가지가 있어서 적어봅니다.

1. 해산물. 우왕굳!
바다가 없는 온타리오 주에서 살다가 섬나라 뉴질랜드, 그 중에도 동서로 해안을 끼고있는 Auckland로 가보니 마트마다 해산물이 넘쳐나고, 식당에서 서빙되는 해산물들의 맛이 아주 일품이더군요
2. 운전하기 불편해
그 전에도 부모님 집에 놀러 갈 때마다 느꼈지만, 우측 운전선과 좌측통행 차선은 아직도 익숙하지 않네요. 차선과 운전 감은 그래도 조금 지나면 그럭저럭 괜찮은데, 여행 마지막 날 까지 계속 헷갈린 것은 깜빡이와 와이퍼입니다. 보통 깜빡이는 핸들 좌측, 와이퍼는 핸들 우측인데, 뉴질랜드 차들은 차종에 따라 그 위치가 제각각 입니다. 어머니 차와 아버지 차가 그 방향이 서로 반대인데, 깜빡이를 켜려다 와이퍼를 켜는 일이 계속 반복되었고, 심지어 캐나다에 돌아와 제 차를 운전하는데 다시 또 헷갈리네요.
3. 물가, 집값 더 비싸, 너무 비싸!!!
캐나다에서는 해외 투자자(특히 중국 투자자)들로 인해 Vancouver의 주택 가격에 너무나도 심한 거품이 끼어 있다고 말하지만, 사실 Auckland에 비하면 세발의 피 입니다. 이민 행선지 고민을 할 때만 해도, 피부에 와닿는 것이 아닌 단순한 숫자이기에 그저 그러려니 했지만, 지금 느끼는 감정은 정말 Auckland의 주택 가격은 무시무시하다는 것이였습니다. 캐나다에서는 아파트/콘도 렌트비를 보통 월 단위로 계산하지만, 뉴질랜드에서는 2주 단위로 지불합니다. 그런데, 비슷한 크기/조건의 토론토와 Auckland 아파트 렌트비를 비교해 보자면, 토론토의 월 렌트비가 Auckland의 2주 렌트비와 비슷합니다. 그래서 제가 토론토에 도착해 가족들과 함께 살 아파트 렌트 계약을 마치고 부모님께 말씀 드렸을 때, 부모님께서는 당연히 제가 말씀드린 렌트비가 2주치 렌트비인 것으로 생각을 하셨었죠.
집값 뿐 아니라 전반적인 물가 역시 캐나다에 비해 많이 높았습니다. 이 역시도 이전에 부모님 집을 방문 할 때 마다 느꼈던 것이지만, 원화와 달러화의 차이로 인한 착시도 있거니와, 당장 제 피부로 느끼는 것이 아니기에 지나쳤던 것이지만 이번에 다시 돌아보니 물가가 참 비쌌습니다. 식당 메뉴판 가격에서 세금과 팁을 추가로 계산하지 않아도 된다지만, 그 절대적인 숫자 자체가 높고, 마트에서 파는 빵/우유/그로서리 등등 생필품 가격 역시 캐나다의 그것 보다 많이 비쌌습니다. 가장 가격 차이가 심하게 나는 것은 공산품이였는데, 제가 도착한 다음 날이 Boxing day라 부모님께서 필요하신 몇몇 전자제품들을 사러 나갔는데, Boxing day 세일을 해도 가격이 캐나다의 그것 보다 작게는 30~40%, 많게는 두 배 이상 비쌌습니다. 어머니께서 몇 달 전에 신차를 뽑으셔서 차량 가격 역시 이것 저것 알아봤는데, 차 가격 역시 50% 정도는 캐나다보다 더 비쌌고요.
4. 멋지다, 예쁘다, 그림같다!
캐나다도 자연환경이 참 좋은 나라 중 하나입니다. 하지만 온타리오주 지도에서 등고선을 보자면, 마치 다리미로 잘 다려놓은 손수건 마냥, 죄다 평지입니다. 아주 낮은 언덕? 몇개 정도와 수없이 많은 크고 작은 호수들 만 있죠. 그렇다보니 깨끗하고 맑은 자연은 있지만, 언덕과 굽이치는 계곡이 만들어내는 멋진 자연 경관은 조금 부족합니다. 그에 비하면 Auckland는 깨끗하고 맑으면서도 아름다운 자연을 가지고 있습니다. 동서 양쪽으로 바다를 끼고 있어 곳곳에 아름다운 해변들이 즐비하고, 가는 길 마다 굽이굽이 언덕과 산, 초원과 계곡이 있어 정말 그림같은 전경이 펼쳐집니다. 덤으로 제가 겨울에서 여름으로 건너뛰었기에따스한 햇살과 푸른 하늘을 제공해 준 날씨는 뉴질랜드의 자연을 더욱 더 포근하게 만들었습니다.
5. 영어 어렵다...
영어 원어민이라면 뉴질랜드 영어는 정통 영국 영어와는 다르게 들리겠지만, 그저 서바이벌 영어 수준인 저로서는 뉴질랜드 영어나 영국 영어나 그 발음과 억양이 똑같다고 느껴집니다. 지난 3년간 캐나다 영어만 접하며 (아니 사실은... 러시아/인도/이란/중동/중국 이민자 영어) 살아오다가 뉴질랜드에서 영국식에 가까운 영어를 들으니 정말 어렵네요. 억양과 발음도 그렇고, 몇몇 서로다른 어휘들 또한 익숙하지 않아 잘 들리지 않고요. 가이드 투어를 하면서 어머니께서 동시 통역을 부탁하신 적이 있는데, 도저히 제가 감당 할 수가 없었습니다.
6. 캐나다보다 더 여유있는 삶?
뉴질랜드에서 가장 번화한 Auckland라고 하지만, 생활양식은 캐나다 중소도시와 비슷합니다.
식당들은 오전 11시~오후 2시 사이의 점심시간, 오후 5시~8시 저녁 시간에만 영업을 하며, 7시 30분쯤 되면 주문 마감을 받습니다. 대부분 상점들 역시 빠르면 오후 5시, 늦어도 8시면 문을 닫았고요. 그렇다보니 오클랜드 인근에 관광/여행을 갔다가 식사시간대를 놓치면, 식사를 하기 위해 갈 수 있는 식당들이 햄버거, 핏자, 케밥과 같은 종류로 제한되었고, 집으로 너무 늦게 돌아오면 마트들이 문을 닫아 다음날 아침 식사를 위한 장을 보지못하기도 했습니다. 일부 식당들은 크리스마스 때 부터 1월 중순까지 3주 정도 휴가로 문을 닫기도 해서 몇몇 부모님 동네의 맛집들은 저희가 가볼 수도 없었습니다.

7. 캐나다로 오기를 참 잘한 것 같다!
이번 여행에서 벤쿠버와 오클랜드를 다니며 저와 제 아내는 본의 아니게 날씨, 주거환경, 물가 등등 모든 면에서 의도치 않게 지금 살고있는 지역과 비교를 하게 되었고, 몇번씩 토론토 쪽으로 이민오기를 잘했다고 서로 이야기 했습니다.

날씨는 분명히 개인 취향 차이가 있을 수 있습니다. 저는 원래 추위를 타는 체질이 아니였지만, 아이들과 제 아내는 추위를 많이 타는 체질이라 처음에 토론토 쪽으로 오는 것을 조금 망설이기도 했으니까요. 하지만 1년 정도 지난 후, 아내와 아이들 체질이 많이 바뀌어서 오히려 저보다 추위를 안타기에, 덜 추워도 비오는 날씨는 저희에게는 이제 큰 메리트가 아닙니다. 덜 춥기에 난방과 방한이 덜 되는 주택 때문에 오히려 여름철인 오클랜드의 새벽/저녁과 비오는 벤쿠버가 토론토보다 더 추웠습니다.

주거환경은 뉴질랜드도 집이 비싼 것 빼면 아주 좋습니다. 하지만 집 자체를 놓고 보자면, 이미 방 수는 적어도 넓은 캐나다식 집에 익숙해서인지, 좁아도 방이 많은 뉴질랜드의 집이 조금 답답해 보였고, 이미 지하실 전체를 아이들의 놀이공간으로 꾸며 놓아서인지, 지하와 2층이 없는 뉴질랜드의 단층집은 무언가 실내 공간이 부족한 것 같이 느껴졌습니다. 또한, 방한/난방 설비가 부족해 여름이라도 새벽에는 찬공기가 느껴지는 뉴질랜드 집 보다는, 창이 좀 좁아도 방한이 잘 되어 따뜻한 캐나다 집이 더 좋았습니다.

물가와 생활비는 어찌보면 이민을 결정함에 있어서 큰 문제가 아닐 수도 있습니다. 제가 경제용어를 잘 모르지만 구매력 지수라고 하던가요? 물가가 2배 높다고 해도 임금을 2배 이상 받는다면 실질적인 구매력은 오히려 더 높을 수 있고, 체감 물가는 낮게 느껴질 것입니다. 실제로 뉴질랜드의 minimum wage는 시간당 $15.25로 캐나다 온타리오의 $10.70 대비 40% 이상 높습니다. 그러니 최저임금 기준으로 계산해 보자면 이곳보다 물가가 비싼만큼 더 많은 임금을 받는 것이기에, 현지에서 일하며 돈을 벌고 생활한다면 양국간 실질 구매지수 차이는 크지 않을 수도 있습니다. 

하지만 현지 국민이 아닌 이민자에게는 임금 수준과 무관하게 절대적인 물가 수준의 중요성이 결고 낮지만도 않습니다. 이민 초기에는 안정적인 직장을 잡기 전까지 좋건 싫건 한국에서 준비해 간 자금을 냐금냐금 까먹으면서 소비생활을 할 수 밖에 없습니다. 영주권을 받아 이민을 간 경우라면, 그나마 서빙이나 일용직 같은 서바이벌 쟙을 통해 생활비의 일정부분 충당을 할 수라도 하며 버틸 수 있지만, 영주권을 받기위해 스터디 퍼밋 등으로 먼저 이주를 한 경우라면, 학교졸업 + 구직까지 최대 수년간 only 소비 생활을 해야 할 수도 있습니다. 하루하루 시간이 지날 수록 줄어드는 잔고를 보면 심리적으로 흔들릴 수 밖에 없고, 마음이 약해지면 향수병이나 진짜 질병이 생겨 안정적인 정착에 방해가 되겠죠. 심리적인 문제를 떠나 실질적으로 보더라도 마찬가지입니다. 이민을 위한 정착, 혹은 이민 후 성공적인 정착을 위해서는 안정적이고 지속 가능한 수입(직장)을 찾을 때 까지 버틸 수 있는 기간을 최대한 늘리거나, 혹은 수입원을 최대한 빨리 확보해 소득/지출의 불균형 기간을 최대한 짧게 해야 합니다. 소득 only가 가능한 기간이 충분히 길다면, 사실 이민을 간 후에 놀고먹어도 될 것이고, 적당히 길다면 이민 후 안정적인 정착을 위해 재투자 (2nd career를 위한 교육 등)를 할 여유가 있을테니 보다 성공적인 정착의 가능성이 높을 수 있고, 너무 짧다면 영주권을 받는다 하더라도 결국엔 충분한 소득원 확보를 하지 못하여 이민 후에 오히려 더 어려운 삶을 살 수도 있습니다. 그러니 어쩔 수 없이 소비에 걸맞는 소득을 올리기 어렵거나 할 수 없는 초기 이민자에게 물가라는 요소는 결코 사소한 문제만은 아니기도 하죠. 그래서 저도 이민 대상 국가를 결정하기 전에 각 국의 부동산 정보 사이트나 대형 마트 웹 사이트와 전단지/쿠폰 서비스 사이트 등을 통해 물가 수준을 확인 하여 예상 생활비 내역을 뽑아 제가 가진 자본으로 버틸 수 있는 예상 기간을 확인 해 보기도 했었습니다. 전에도 한 번 포스팅 한 적이 있는 것 같은데, 뉴질랜드나 호주로 선택하지 않은 여러 이유 중 하나도 바로 이 물가-연봉 상관관계 때문입니다. 최저임금으로 비교하자면 물가-임금에 문제가 없지만, SW Developer만 놓고 보자면 조금 문제가 있었습니다. 뉴질랜드와 호주의 생활 물가는 캐나다 대비 월등히 비싼데, SW Developer라는 직업군의 임금으로 보자면 뉴질랜드는 오히려 캐나다보다 조금 낮았고, 호주는 크게 높지 않았습니다. 벤쿠버와 토론토로 비교 해 보아도, 주거비로 인해 벤쿠버에서 생활비가 더 필요할텐데, 벤쿠버-토론토 간 SW Developer의 임금 격차는 거의 없었고요. 모르긴 몰라도 제가 워낙 두부멘탈인지라, 만약 뉴질랜드로 이민을 가서 Auckland에 정착 했더라면 아마도 직장을 구하기 전에 줄어드는 잔고에 조급한 마음이 생겼을 것이고, 그 조급함에 SW Developer를 다시 하기위한 준비를 착실히 하기 보다는 당장 생계를 위한 일자리에 뛰어들었을지도 모릅니다.

마지막으로 뉴질랜드 여행 기간 중 찍은 사진 몇 장 간단하게 올려봅니다.
12월/1월의 여름을 감상 해 보시죠.