잡다구리 - 요즘 근황

안녕하세요, 약 두달여 만에 포스팅을 남깁니다.

핑계라면 핑계이지만, 팀을 옮긴 이후로 건곤일척 까지는 아니더라도 상당히 많은 것을 걸어두고 달리고 있다보니 좀처럼 블로그 관리를 하지 못하고 있었네요.

보통 무언가 새롭게 시작을 하게되면 초반에 바짝 열심히 해서 어느정도의 입지를 다져둔 후에 이후로는 여유를 갖는 것이 저의 접근 방식입니다. 어느정도 입지를 다져둔 후에는 사실 여유롭게 일을 해도 어느정도는 계속해서 선두그룹에서 같이 뛸 수 있기 때문이지요. 제가 새로운 시도나 경험이나 연구를 하지 않아도 제가 선두로 치고나간 분야에 문제가 있다거나, 새로운 기술이 오픈 되었다거나, 아니면 무언가 리서치가 필요 한 경우에 사람들이 나를 찾아오게 되다보니 제가 계속해서 자발적인 노력을 하지 않더라도 많은 정보들이 몰리게 되고, 그들이 겪는 문제점과 그들이 생각하는 다양한 해결방안들에 대해 같이 이야기를 하다보면 또 많은 고민과 생각을 접하게 되며, 그들과 잠시나마라도 같이 의견을 주고받고 생각하면서 본의아니게 또 정보들을 얻게 됩니다.

그런데 지금 이 팀에서 하는 업무들이 대부분 제가 이전에 하던 일과는 거리가 있는 일들이고, 상당히 다양한 분야를 접하고 있다보니 초반 집중이 계속해서 발생하고 있네요.

중간에 한 sprint 정도는 좀 쉬엄쉬엄 넘어갈까 싶다가도 지금이 작년 6월부터 올해 5월까지 저의 performance를 평가하는 리뷰 기간이라는 점을 떠올리면 1년간 고생해놓고 중요한 시기에 마음을 놓아 1년 농사를 망치기 싫다는 생각에 또 달리게 되고, 달리다가 지쳐도 명확히 보이지는 않아도 눈 앞에 무언가 아른거리는 솔루션을 빨리 확실히 보이게 하고 싶어 계속 달리게 되고... 그렇게 올해도 5,6,7월은 일을 달리고 있습니다.

지난 7월 1일은 Canada Day라는 휴일인데, 캐나다의 150번째 생일이였습니다. 1일이 토요일인 관계로 그 다음주 월요일이 대체휴일이 되어 3일간의 연휴가 되었죠. 한국에서야 설이나 추석같이 3일씩 되는 명절이 있지만, 여기 휴일은 죄다 하루인지라  주말 포함 3일을 쉬기만 해도 long weekend라고 하여 다들 좋아합니다.

그리고 매 년 Canada Day에는 각 도시별로 불꽃놀이를 하는데, 올 해에도 저희는 옥빌에서 하는 행사에 다녀왔습니다. 이런 행사를 할 때에는 행사장 주변 몇 Km부터 차량 진입을 제한하기에 근처 버스 터미널에 차를 주차하고 대중교통을 통해서만 행사장으로 갈 수 있습니다. 이 점이 상당히 불편하긴 하지만, 감당 안되는 도로사정과 주차장 사정을 감안하면 차라리 이런 접근 방식이 모든 이용객의 전반적인 편의성을 위해서는 더 나은 것 같기도 합니다.

Canada Day Firework

7월 3일은 대체 휴일이였고 화요일인 7월 4일에도 사실상 일을 하지 않았습니다. 회사 창립기념일이라 임직원들이 인근 공원을 빌려 하루종일 체육대회? 같은 것을 진행합니다.

가장 인기있었던 인간 foosball

이 행사의 정규 종목은 아니였지만 free time에 임직원들이 자유롭게 이용할 수 있도록 설치한 시설 중 하나인데, Artificial Rock Climbing과 함께 가장 인기있던 시설 중 하나였습니다.

사실 이 주의 주말 부근이 제가 가장 바쁘게 달렸던 시기인지라 long weekend에 이벤트데이이긴 했지만, 집에서 틈만나면 컴퓨터를 붙잡고 씨름을 했었죠.

그리고 얼마 전에는 집에 반갑지 않은 손님이 찾아왔습니다.

의문의 구멍?

그 당시가 집에 마루를 교체하는 공사를 하던 시기인데, 뒷마당 데크에 나가서 보니 왠 드릴로 뚫은 것 같은 구멍이 보이는 것입니다. 이게 언제부터 있었을까 생각을 하다 바닥을 보니 바닥에 아직도 톱밥이 그대로 있었고, 그로 미루어 짐작컨데, 공사하는 아저씨들이 드릴 비트를 테스트 하느라 뚫어본 것이 아닐까 라고 생각을 하며 다시 구멍으로 시선을 옮기는 순간...

마치 개미가 개미 집을 지을 때 마냥 구멍 속에서 누군가 톱밥을 밖으로 밀어내고 있었습니다.
"헉! 이거 뭐야."

사진 상으로 잘 표현이 되었는지는 모르겠지만, 이 구멍의 크기는 대략 성인 새끼손가락 정도 됩니다. 이 정도의 나무 구멍을 뚫을 정도의 힘이라면 힘이 엄청 센 녀석일 것이고, 이런 녀석이 우리집 뒷마당에 집을 짓고 산다면 무언가 문제가 될 것 같다는 생각이 들었죠.
그래서 조심스레 이 녀석을 밖으로 꺼내고 싶었지만... 나무도 씹어먹을 정도의 어마어마한 턱인데, 제 손가락을 물면.... ㅠㅠ

그래서 발을 동동 구르던 찰나, 요즘 아이들이 가지고 노는 물총이 생각 났습니다. 한걸음에 달려가 물총에 물을 가득 채우고, 숨을 고르고 조심스레 조준을 해서 이 구멍 속으로 물을 쏟아붇기 시작 했습니다.
하지만 물총의 물을 다 비울 때 까지 아무 소식이 없었습니다. 그래서 다시 물을 채우고, 조준하고, 쏘고를 2번을 더 반복한 끝에 정체모를 이 녀석을 밖으로 끄집어 낼 수 있었습니다.

비록 구멍 밖으로 나왔고, 날개가 젖어있어 날지는 못했지만 어마어마한 힘과 덩치를 자랑하는 이 녀석은 아직 백기 투항을 할 생각은 없었습니다. 날개를 말리기 위해 선풍기 강풍 보다도 큰 "위잉!" 소리를 내며 연신 날개짓을 해댔고, 그렇게 바둥대다 어디에 몸이 닿기라도 하면 무서운 기세로 배를 구부리며 벌침을 쏘는 자세를 취했습니다.

이 녀석을 어떻게 해야할지 한참을 고민 했습니다. 하지만 이 녀석의 생태에 대해 아는 지식이 없어 어떻게 결정을 할 수 없었죠. 하지만 어릴적 퀴즈탐험 신비의 세계와 동물의 왕국을 모두 섭렵했던지라 어디에선가 이 녀석을 봤던 기억이 났습니다. 그래서 바로 랩탑을 열고... 나무벌, 나무땅벌 등등의 키워드로 구글링을 하다 정확한 이 녀석의 이름을 찾아 냈습니다. 바로 목수벌 (carpenter bee)

그리고 이런저런 정보들을 조합해 본 결과 그대로 놔 줄 경우 다시 우리집 어딘가에 구멍을 내고 그 속에 알을 낳고, 그 곳에서 부화한 다른 목수벌들이 또 찾아와 알을 낳고... 말 그대로 우리집 자체가 벌집이 되어버릴 수 있는 상황이라 생각해 바로 그 자리에서 놔주지 않고 이렇게 잡아 두었습니다.

아직도 DevOps쪽에서 제가 공부를 해야 할 분야들이 많은데다, 곧 컨퍼런스들로 출장을 가야하기도 하고, 한국에서 가족들이 놀러 올 예정이기도 하기에 당분간은 계속 바쁘게 지내야 할 것 같습니다.
그래도 바쁘지만 제가 사랑하는 가족들과 함께있고, 제가 좋아하는 일을 하면서 바쁘게 지내고 있고, 바쁘게 일을 하고 기여한 만큼 보상을 받기에 힘들어도 참 즐겁게 삽니다.

가끔 한국이 그리울때?

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

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

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

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

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

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

비록 이제 캐나다에 건너온지 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분입니다. ㅎㅎ
어젯 밤에 그 친구가 어제 던진 수많은 문제점들 중 가장 크리티컬한 몇가지가 생각나 혼자 이리저리 확인해보고 테스트도 돌려보고 몇가지 해결 가능한 방안을 말해줬더니 오늘은 그래도 빨리 끝났습니다 ㅎㅎㅎㅎㅎㅎ

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

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

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

호주 457 비자 중단의 파장

어제 포스팅을 마치고 blog admin 페이지에 statistics에 들어가보니 이전과는 다른 신기한 트래픽들이 대거 증가했습니다.

딱히 집계를 내 본 적은 없지만 제 기억에 주된 Traffic Source는 항상 google.co.kr이나 google.ca, google.co.jp 혹은 google.com이였습니다. 딱히 국내 포털에 등록은 하지 않았기에, 다음이나 네이버 등을 통한 유입은 거의 0였고요. 그리고 어찌된 일인지는 모르겠지만 신기하게도 러시아 포털과 SNS인 yandex.ru와 vkontakte를 통한 유입이 항상 10위권 내에 있었고요.

Audience 국가 정보역시 한국이 압도적 1위이고 2위는 고정적으로 캐나다, 3~5위는 미국, 일본, 러시아 3국이 엎치락 뒤치락 하는 모습이였고요.

그런데 어제 확인을 해보니 최근 수 주 사이에 호주에서 트래픽이 대거 유입되었더군요.
심지어 지난 주에는 호주 Audience가 2위까지 오르기도 했었습니다.

무슨일일까 싶어 확인을 해보니 호주에서 영주권 신청을 위한 디딤돌 역할을 하던 비자 중 하나인 457비자가 조만간 폐지되며, 폐지 이전에도 당장 당일부터 457비자의 신청 조건을 강화한다는 발표가 있었더군요.

7~8년 전 호주 이민을 고려했을 때에도 봤던 비자 타입이라 이름은 익숙하기는 한데, 세부적인 절차와 프로세스는 기억하지는 못하여 이번 변화가 어떤 파장이 있을지 역시 제가 잘 알만한 부분은 아닙니다. 하지만, 캐나다/호주/뉴질랜드 등 이민자 유입 국가들의 정책의 일반적인 변화와 관련하여 제 생각을 적어볼까 합니다.

정확히 기억나지는 않지만 457비자라는 것이 호주내 인력이 부족한 (잠재적 고소득의) 숙련직 기술자를 해외에서 받아들여 자국 산업의 인력부족 해소 및 고도화를 시키고, 또 이를 통한 국가 재정의 확대를 위한 비자로 기억합니다. 양질의 인력이기에 이민을 받아 중장기적으로 사회적 이득을 보기에도 좋기에 이민 457에서 영주권으로 넘어가는 과정 역시 수월했고요. 그런데, 이 457비자의 성격이 약간 변질되기 시작한 시점은 mining boom때가 아닌가 생각합니다. 호주 달라가 USD에 육박할 정도로 치솟고, 경제 전반에 cash flow가 매우 좋았고, 그렇다보니 산업 전반에서 투자가 활성화되고 일손이 부족했던 시기입니다.
이 때 부터 457비자를 받는 직업군들이 다양해지기 시작했고, 자국 내에서도 충분히 육성 가능한 분야의 직업군에서도 457비자를 받기 시작했죠.

많은 외국인들이 들어온다 하여도 실업률이 낮고 자국인들이 일 할 일자리가 얼마든지 있다면 사회적으로 큰 문제가 되지 않겠지만, 최근 5년간 호주의 실업률과 실업자 수는 급증을 하였고, 많은 호주인들의 시각에는 구지 해외에서 데려오지 않아도 될 사람들이 호주에 와서 나 대신 일을 하고 돈을 벌고있다는 생각이 들기 시작한 것 같습니다.

제 기억이 맞다면 457비자는 캐나다에서 LMIA를 받아 Work Permit을 받는 절차처럼 고용주의 스폰서 하에 진행되는 것으로 기억하는데, 캐나다에서도 가끔 발견되듯 불법적인 비자 발급이 있기 마련인데, 소수의 이러한 케이스들이 전체적인 이민 프로세스에 대해 안좋은 시각을 만드는데 큰 역할을 하기도 합니다.

불법적인 비자발급이라면, 사업상 needs에 따른 채용이 아닌, 피고용인의 비자 발급이 목적이자 수단이 되는 경우라고 할 수 있겠죠. 제가 호주 이민을 찾아 볼 때에도 돈 얼마를 내면 이런 식의 paper company를 통해 비자를 발급받게 해주겠다는 이민 업체들이 간혹 있었습니다. 그리고 paper company가 아닌 경우에도 실제 하는일은 비숙련직이지만, 서류상 숙련직 노동자의 포지션으로 작성하여 비자 발급을 약속하고 뒷돈을 받는 경우도 있었고요.

자세히 읽어보지는 않았지만, 간략하게 변경사항에 대해 확인을 해 보니 당장 내년 3월 이후로는 457비자 발급이 중단되며, 아직 발급되지 않았지만 기 접수된 457비자 신청건에 대해서도 강화된 요건을 적용하여 재검토 할 것이고, 고용주의 심사와 자국민 채용을 위한 노력 정도의 검토를 강화하며, 457비자를 신청할 수 있는 직업군에도 변경이 생기고, shorterm과 mid and long term으로 직업군이 나뉘어 short term은 비자 기간이 2년 mid and long term은 4년이 된다는 것 등등이더군요.

직업군의 변경이야 각 국가별/시기별로 시장 needs가 다른 것이지만, 결국에는 시장에서 절실히 필요로하는 숙련직 노동자는 받되, 시장에서 절실히 필요하지 않다거나, 숙련직이 아닌 경우에는 제약을 둔다는 것으로 보입니다.

고용주 심사 강화와는 앞서 말씀드린 불법/편법적인 비자 발급으로 인한 이민의 사회적 부작용을 줄이기 위한 노력일 것이고, 자국민 채용 노력 검증 강화 (Labour Market Test)는 진정으로 needs가 있는 해외채용인지, 사업을 위한 채용이 아닌 이민을 위한 채용인지 검증하겠다는 것입니다.

신청조건 강화 역시 시장에서 needs가 있는 인력이라 해도 채용하고자 하는 외국인이 정말 그 needs에 적합한 사람인지 보겠다는 것이며, 가장 활발히 일하며 사회에 기여하는 연령대의 사람이라 자국 연금 재정을 튼튼하게 할 사람인지, 아니면 역으로 연금 재정 악화에 도움을 줄 사람인지 보겠다는 것이고, 영어점수 강화는 기본적으로 호주 사회에서 노동력으로 가용한 사람인지, 또 사회 적응과 융화에 필요한 기본적 능력이 있는 것인지 보겠다는 것으로 생각됩니다.

결국 위에 변경된 내용들을 살펴보면 캐나다에서 일어났던 변화와 큰 틀에서 그 맥을 같이한다고 보입니다.

어느 나라건 난민 이민을 제외하고 이민은 자국의 산업과 경제 발전, 그리고 (납세 인구 확대를 통한) 세수원 확보를 위한 정책이지, 국제사회에 대한 기여나, 외국인들을 위한 정책이 아닙니다. 자국민과 자국 산업/사회를 위한 정책이다보니 아무리 좋은 정책이라 하여도 사회적 합의가 되어야 하는 정책이고요.

한국의 경우만 보더라도 이민을 통한 생산인구 유지 내지는 확대가 절실한 상황이지만, 당장 한국 사회 전반적으로 다민족 다문화에 대한 인식이 낙후되어있고 사회적 합의가 되지 않은 상황이다보니 이민 정책이 아직도 매우 폐쇄적이고, 교육과 대중매체 등을 통해 다민족/다문화에 대해 조금씩 마음을 열게 하려는 노력이 갓 시작된 수준에 머물고 있지요.

많은 분들이 대부분의 이민자 유입국에서 자국민 우선, 이민자 폐쇄 정책으로 가고있다는 말씀을 하시는데, 사실 저는 조금 생각이 다릅니다. 근래에 많은 국가들이 겪고있는 주요 사회 문제 중 하나는 치솟고 있는 청년 실업률과 서서히 시작되고 있는 baby boomers의 은퇴 시점입니다. 그리하여 당장 앞으로 10여년간 세수는 줄어들고 실업수당과 연금 등으로 지출되어야 할 재정은 늘어날 예정이고요.

그렇다보니 활짝 열어두었던 이민 정책에도 변화가 생길 수 밖에 없었습니다.

이전에는 사회 전반적으로 활발히 돌아가다보니, 산업 전반에 걸쳐 가용한 노동인력이 부족했습니다. 그래서 이러한 시장의 needs를 맞추기 위해 이민 문호를 열어두었지만, 지금도 이러한 정책 기조를 유지하다가는 집권 정부와 정권은 철퇴를 맞을 수 밖에 없습니다. 그렇다고 모든 이민 문호를 꽁꽁 닫아버리면 더 큰 사회문제가 생길 수도 있습니다. 대부분 이민 유입국들은 이민과 이민을 위한 과정들이 하나의 산업화 되어 있어 당장 이민/유학 사업의 황폐화가 될 것이고, 앞서 말씀드린 baby boomer 세대의 은퇴가 불러올 사회적 영향에 적절한 대응 시점을 놓칠 수 밖에 없을 것입니다. 반대로 이민 개방정책 기조를 유지한다면 수 많은 실업자들은 그 화살을 이민자에게 돌릴 것이고 정부와 정권이 위협받음은 물론 반이민 정서가 싹트게 되어 훗날 이민 문호를 개방해야만 할 때에도 사회적 거부감으로 인해 쉽사리 받지 못하는 문제가 야기될 수도 있겠죠.

그래서 대부분의 이민자 유입국에서 나아가고 있는 방향은 최대한 경제생산 활동 기간이 길 수 있도록 나이 조건을 강화하고, 보다 활발하고 폭넓은 경제활동을 할 수 있도록 언어 능력이나 현지 경력을 살펴보며, 자국민 노동시장과 carnivalization이 발생하지 않으며, 또 보다 높은 소득군이라 더 많은 세수가 가능한 직업군으로 제한을 두고, 고학력의 숙련된 노동인력을 받고자 학력과 경력 조건 역시 까다로워 지는 것입니다.

최근 호주 457 비자 폐지와 관련하여 캐나다의 한인 카페등에 올라오는 글들을 보면 말콤 총리가 이민법을 정치적으로 이용한다는 비난의 목소리도 엿볼 수 있었는데, 사실 위에 맥락에서 보자면 꼭 그렇지도 않다는 것이 제 생각입니다.

일단 제 생각에 사회적인 영향력이 큰 대부분의 법안 발의나 정책에는 거의 대부분 정치적인 포석이 같이 섞여있을 가능성이 높습니다. 행정부의 정책이나 국회의 입법과정에서 그 내용 자체의 득과 실만큼이나 중요한 것은 좋은 명분과 명분을 쌓기위한 과정입니다. 각 정치인과 당이 가지는 고유의 색깔에 따라 그 명분을 만들 것이며, 그 명분의 진위여부와 논리성에 대해 정치인간 혹은 정당간 논쟁을 벌이며 지지세력을 집결시키거나 세력을 확산해 가기도 하고, 때로는 반대로 상대의 지지세력을 분산시키거나 축소시키는데에 이용을 하기도 합니다. 종종 국민 다수가 정말 필요한 법안이라고 생각되고, 예산 측면에서도 큰 부담이 없는 안이지만 국회 상임위 내에서 장기간 계류중인 것 들 중 일부는 명분이 잘 안만들어진다거나, 명분을 만들어도 이슈화 되기가 힘들어 해당 법안을 끝까지 밀고나가 추진 할 동력을 잃었거나 없기 때문이기도 합니다. 그러니 기본적으로 대부분의 입법과 정책 수립 과정은 다소간의 정치적인 성격이 같이 섞여있을 수 밖에 없다는 것이 제 생각입니다.

만약 진정으로 단순한 정치적인 이용을 위한 정책이 있는 경우가 있다면, 사회 전반적 needs는 없지만, 현 정권이나 정부에 매우 협조적인 일부 지지세력, 혹은 이익집단만을 위한 정책이거나, 정책 변경의 득실을 따질 때 분명 실이 더 큰 문제임에도 그 논점을 흐리게 하거나 잘못된 정보를 설파하고, 실제 정책 변경에 피해자가 될 수 도 있는 집단으로부터도 지지를 이끌어 내는 것이겠지요. 한국에서 자주 벌어지는 일로 보자면 정책에 대한 다툼에 어느덧 이데올로기 프레임을 씌워, 일부 이익집단에만 이득이 되는 법안이나 정책을 다수의 국민들로 부터 찬성을 받아내는 그런 케이스라고 할 수 있습니다. 또 그 반대로 요즘과 같이 "보수"라는 단어 자체가 이상하리만치 부정적인 의미를 가지고 있는 상황에서는 상대에게 보수 혹은 적폐와 같은 프레임을 씌울 수도 있겠고요.
또는 매우 controversial issue인자라 그 어느쪽이 맞다고 섯불리 평가하기 힘든 이슈이지만, 이를 일부러 꺼내들고 공론화시켜 현재 당국을 곤경으로 몰고가는 다른 지표들이나 이슈들을 이른바 '물타기' 하는 경우에도 정치적 이용을 한다고 볼 수 있겠고요.

분명 호주 정부에서 457비자 폐지에 대한 지지와 근거 등을 이야기 하면서 다소 왜곡된 정보도 있었던 것은 사실이지만 (참고링크), 현재 호주 상황을 놓고 보자면 이민 절차와 조건 강화가 분명 필요한 시점인 것 같다고는 보입니다.

불법/편법적인 스폰서를 통한 비자 발급이 간혹 적발되기도 하고, 실제 서류상 제출된 포지션에 적합한 언어적/업무적 능력과 경력이 없는 사람이 이민을 위해 비자를 받아 오기도 하며, 때로는 현지인 대비 보다 싼 값에 인력 수급을 하기위해 스폰서를 하는 고용주들도 있으며 (정책상 시장가 이상의 연봉이 지불되어야 하지만, 일부 캐나다 한인업주 스폰서에서도 그렇듯 서류상 기록이 남는 페이 체크는 서류상 연봉으로 나간 후, 피고용인이 고용인에게 다시 연봉 중 일부를 돌려주는 형식으로...), 점점 확대되어 온 457 비자의 직업군이 자국민으로도 커버 가능한 일자리까지 확대되고 있으니까요.

이를 점진적으로 강화 할 수도 있었고, 한번에 충격적으로 드라이브 할 수도 있었는데, 호주의 경우 강하게 한 번 밀고 나간것으로 보입니다. 그래도 단기/중장기 직업군과 제외 직업군, 지속 감독(관찰?) 직업군 리스트들을 보면 시장에 인력에 대한 수요가 공급보다 강하고 쉽사리 자국민 실업자 교육을 통해 바로 근무가 가능하기 힘든 숙련직 직업군의 경우에는 당장 귀국이나 다른 나라로 옮겨야 할 정도는 아닌 것으로 보이지만, 당장 한번의 큰 충격을 주었다고 해서 향후 점진적인 변화가 없을 것도 아니기에 현지에서 준비중이신 분들은 많이 불안하실 것 같네요.

제가 이전의 수 많은 글들에서도 이민병에 걸리셨으면 하루빨리 그 병을 치유하여 일상으로 복귀 하시거나, 아니면 1~2년 길게 내다보지 마시고, 반년 이내의 눈 앞에 목표를 세우고 당장 어학 점수를 확보하고, 한국에서 지금 즉시 신청 가능한 영주권 프로세스를 알아보고 이민을 신청하시는 것이 가장 좋다고 말씀드린 이유가 이런 일들 때문입니다.

앞으로 세계경기가 어떻게 될지는 몰라도 지금과 같은 경제적 어려움이 지속된다면, 향후 몇년간은 이민 조건이 더 어려워지면 어려워지지, 더 쉬워지지는 않을 것입니다.
그러면 결국 학력과 경력이 좋아야하고, 나이는 어려야하고, 영어는 잘해야 이민을 오기 쉽습니다. 이러한 조건들이 다 좋다면 지금의 규정에 따라 이민을 올 수 있으며, 이러한 조건이 조금 부족하다면 최대한 단기간 내에 이민을 갈 국가에서 유학이나 취업 등을 통해 극복 후 조금이나마 적게 변경된 규정을 통해 이민을 하게 될 것이며, 이러한 조건에서 많이 멀어져 있는 상황이라면 최대한 오랜 기간동안 현지에서 유학을 하고, 유학 후 취업을 하고, 취업 후 일정 기간 이상의 경력을 쌓아 매우 많이 개정된 이민 규정하에서 영주권을 노려야만 할 수도 있습니다.

그리고 사정이 여의치 않아 조금은 오래 걸리는 이민 프로세스를 선택 하셨다면, 직업은 두 가지 중 한 분야여야만 한다고 생각합니다. 만에하나 귀국을 하게 되었을 때에도 내가 지속적으로 일을 할 수 있는 분야이거나, 이민국 현지에서 시장 needs가 활발하게 있는 분야이면서 동시에 숙련직 노동 분야로 그 사회 내에서는 인력 수급이 지속적으로 어려움이 있을만한 분야여야 합니다. 정부는 어차피 자국민의 목소리를 대변하기에, 다소 왜곡되고 잘못된 이야기라 할 지라도 많은 자국민 노동자들이 같이 일하는 외국인 때문에 내 옆집 사람이 일을 못한다거나, 내가 일을 못한다는 볼맨소리를 하면 그 목소리를 정책에 반영할 수 밖에 없습니다. 본인의 적성 등이 맞지 않아 비숙련직을 할 수 밖에 없다면 호주라면 RSMS, 캐나다라면 주정부 이민을 할 수 밖에 없는데, 이는 기간상으로도 오래 걸릴 뿐만 아니라 현지에서 생활을 함에 있어서도 낮은 소득으로 경제적인 어려움이 있고, 영주권을 받는 그 날까지 고용주에게 종속적인 관계가 되는 위험이 있습니다.

이번 사례에서도 볼 수 있듯, 이민에 대한 각국의 정책은 언제든 상황에 따라 변동이 있을 수 있습니다. 그래서 먼저 영주권을 받는 것이 가장 바람직한 길이며, 아니라면 기간이 가장 짧고 변수가 적은 이민 방법이 차선입니다. 

그리고 단기간 내에 해결이 안되는 학력이나 경력은 차치하더라도 점점 강화되고 있으며 주요한 항목 중 하나인 영어시험 점수를 미리미리 준비 하신다면 훗날 큰 도움이 될 수 있을 겁니다. "가면 영어 늘겠지" 라고 생각하시는 분들이 많은데, 영어 '시험' 점수는 '시험' 공부를 할 때 오르지, 영어를 자주 쓴다고 하여 유의미한 수준으로 점수가 오르지는 않습니다.

정체성의 혼란

팀을 옮긴지 이제 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를 시작해 볼까 합니다.