IT 개발자, 호주 워킹홀리데이 그리고 정착까지

😢 이 페이지는 다음 주소로 변경될 예정입니다.

2012년 3월, 덜컥 호주행 비행기를 타고 멜버른에 도착한 그 날이 아직도 생생하다. 캐리어를 밀고 백팩커에 체크인 하던 나를 기억해보면 그 때의 나는 무슨 생각으로 이런 일을 저질렀을까, 그런 생각이 든다. 그렇게 호주 생활을 시작한지 만 4년이 조금 넘은 지금, 2016년 6월, 호주 영주권을 갖게 되었다.

겁 없이 올 수 있던 이유

당시에는 엄청 준비하고 나왔다고 생각했지만 지금 봐서는 참 도전적이었고 나쁘게 말하면 많이 안일하게 준비했다. 영어도 부족했고 현지 사정에도 밝지 않았다. 현지 취업 사이트에서 취업 공고 보고 내 이력서와 맞는 자리가 얼마나 있을지 알아본 정도였다. 그래서 4년이란 불안정한 기간동안 마음 고생도 심했었다. 즐길 수 있던 시간도 있었지만 그만큼 자기 관리가 필요했다. 타지에서 오래 지낸 경험이 없어 내게 쉬운 일은 아니였다. 감사하게도 여기에서 만난 분들의 도움을 많이 받을 수 있었다.

지금은 탈조선에 성공한 것을 축하한다는 인사도 받긴 하지만 내가 나올 즈음인 4년 전까지만 해도 이토록 탈조선에 대한 담론이 많지 않았다. 게다가 내 삶에 직접적인 영향을 준 한국 경험의 시간은 4년 전을 기준으로 멈춰 있다. 간접적으로 듣는 경제 사정이나 청년 계층의 취업난은 실제가 어느 정도 수준인지 가늠하기 어려울 정도로 심각하게 느껴진다. 나는 엄청난 의지로 꼭 탈출하고 말리라 정도로 생각하고 나온 것이 아니라서 요즘 해외로 취업하고 싶은데 어떻게 하면 되냐는 질문에 다소 다른 온도의 답변을 하게 되는 것 같다.

내가 다니던 대학 학비는 학기에 170만원 정도 하는 지방 국립대였고 집에서 살았기 때문에 자취를 할 일도 없었다. 군 전역 후에 1년 간 회사를 다니며 모은 적금을 정리하고 호주 올 준비를 한 다음에 300만원을 환전해서 호주로 넘어왔다. 부양 가족도, 갚아야 하는 학자금 대출도 없었다. 만약 학교 학비가 더 비쌌더라면 앞에 낸 비용이 아까워서라도 학교를 끝내야 한다는 강박이 생기지 않았을까 생각도 든다. 워킹홀리데이는 그나마 가장 적은 밑천으로 시작할 수 있는 선택지다. 하지만 이런 말을 어디서 쉽게 하지 않았던 이유는 이런 내 배경으로 쉽게 느끼는 것은 아닌가 고민했기 때문이다. 다녀야 할 학교도 있고 학자금 대출까지 있다면 워홀 커뮤니티에서 흔히 하는 말처럼 경험, 영어, 돈 중 하나 내지 둘 챙기는 것 외에는 결정을 내리기 쉽지 않을 것 같다. 물론 돈이 더 있다면 더 좋은 선택지가 많겠지만 말이다.

지금 보면 참 어린 생각이지만 프로그래밍으로 취업할 수 있을거란 자신감이 있었다. 어릴 때부터 재미로 만들던 웹사이트인데 이 일로 돈을 번다는 것을 군 입대 전에야 알았다. 전역하고 나서는 지방 기업이지만 웹에이전시에서 개발팀장으로 근무하면서 한참 자신감이 충만해졌다. 같은 일을 한다면 전혀 두려울 것이 없을 정도로 알게 되니 겁이 없어졌다. 한국 이 촌구석에도 이렇게 일이 있는데 호주라고 없겠나 싶은 생각도 들었다.

오기 전에도, 오고 나서도 흔하지 않은 케이스였고 좋은 이야기를 들은 기억이 손에 꼽았다. 그래서 지금까지 지낼 수 있었던 점에 더 감사하게 된다.

호주에 도착해서

지인이 도와줘서 미리 만들어온 커버레터와 준비해온 이력서를 들고 지원할 수 있는 모든 포지션에 지원했다. 열린 포지션이라면 어디든지 지원 했지만 리쿠르터를 거치는 경우에는 아무래도 영어가 약해서 면접까지 가는 일이 쉽지 않았다. 이런 일은 예상했지만 실제로 경험을 하고 반복하다보면 기운빠지는 일이긴 하다. 그래도 주변에서는 리쿠르터가 아예 전화를 하지 않는 경우도 많다고 그래서 전화 오고 인터뷰가 잡힌다는 사실 자체에 감사했다. 많은 전화 덕분에 오히려 더 빠르게 전화에 익숙해질 수 있지 않았나 생각이 든다.

그러던 중에 급한 프로젝트에 투입된 적도 있었다. 2주 정도의 짧은 기간이었지만 좋은 레퍼런스를 얻을 수 있었다. 이 레퍼런스를 가지고 부지런히 자리를 찾으려고 노력했다. 이때 만난 저스틴님께도 조언을 많이 들을 수 있었고 지금까지도 항상 좋은 말씀을 해주셔서 감사할 따름이다.

리쿠르터를 통과하는 일이 아무래도 적다보니 콜드메일도 정말 많이 보냈다. 멜번 지역에 있는 회사를 구글 맵스에서 검색해서 일일이 웹사이트를 확인했다. 채용 페이지가 없을 때는 문의 이메일로 이력서와 커버레터를 보내기도 했다. 인터뷰도 더 많이 잡을 수 있었고 그렇게 지금 회사에 다니게 되었다.

호주에 지내는 내내 호주에서 아무 일도 못해보고 한국을 돌아갔다면 어땠을까 하는 궁금증은 늘 따라다녔다. 제주에서 임용고시를 준비하며 씨름하고 있었을까, 서울에서 계속 웹개발을 하고 있었을까.

비자 문제

해외 체류에 있어서 비자는 늘 문제다. 물론 학력이 좋거나 많은 연봉을 받는 사람이라면 비자는 전혀 문제가 되지 않는다. 모셔가야 하는 사람 발목은 안잡는다. 그 외의 경우는 내 자신이 왜 비자를 받아아 하는지 설득해야 한다. 작게 보면 회사의 상사에게 그래야 하고 크게 보면 호주 정부에게 내 비자의 타당성을 서류로 검증받아야 하는 것이다. 이렇게 말은 쉽지만 체류하는 사람마다 비자와 관련한 에피소드는 다들 하나는 갖고 있을 정도다.

비자 발급 비용도 적지 않다. 나는 고맙게도 모든 비용을 회사에서 처리해줘 부담없이 잘 받을 수 있었다. 준비해야 할 서류가 크게 복잡하게 느껴지지 않아 대리인을 고용하지 않았다. 그리고 호주 이민성에서 제공하는 체크리스트를 보며 준비 서류를 챙겼다. 그렇게 워킹홀리데이 비자에서 Subclass 457 비자로 전환 후 2년 반을 지내고 영주 비자인 ENS 비자를 신청했다.

비자를 신청하기 전에 요건을 충족하는 것이 1차 관문이고 비자를 신청하고 처리되기까지 기다리는 일이 2차, 담당자가 배정되어 통과되는 일이 마지막 관문이다. 처리를 기다리는 기간이 기본적으로 5개월 이상인데 이 기간 동안 별 생각이 다 든다. 게다가 까탈스러운 담당자를 만난다면 정말 정신을 붙잡기가 쉽지 않다. 내 경우에도 꼼꼼한 담당자를 만나서 번거로운 일이 있었지만 다행히 큰 문제가 되진 않아 감사했던 기억이 난다.

영주권은 끝이 아니라 시작

마치 고등학생 때 수능 보고 대학만 가면 모든 일이 끝날 것 같지만 더 많은 선택지와 삶의 방향 앞에서 혼란을 겪는 것과 비슷한 것 같다. 영주권을 받고 나서 기쁜 마음도 분명 있지만 이제는 더 이상 내 비자 상태를 탓하며 아무 일도 안하며 손놓고 있을 수 없다는 생각이 들어 괜스레 부담감도 생긴다. 그런 부담감도 있고 앞으로 어떤 일을 해야 할 지 뚜렷하게 생각해보지 않고 당장 앞에 있는 일에만 바쁘게 지냈는데 막상 그 날이 와서 어떻게 해야 할지 잘 모르겠다고 할까. 그래도 기쁨과 감사함으로 앞으로 시간을 잘 준비해야겠다는 생각을 한다.

호주에서의 삶부터 지금까지 지내온 시간은 나에게 너무나도 새로운 경험이었고 평생 가지고 갈 내 인생의 밑천이 되었다. 호주에서 어떤 일이 있었든지 또 다시 다른 나라를 알아보고 도전해보지 않았을까. 지금 내가 갖고 있는 모든 것을 털고 또 새롭게 시작해보겠냐 그러면 그럴꺼라 대답할 것이다. 그 인생의 충격은 또 다시 경험해보고 싶을 정도로 매력적이다.

다행인지 삶은 여기에 끝이 아니라 도전의 연속이다. 영주권이 큰 고비라고 생각했지만 앞으로도 등정하고 싶은 산도, 올라야 하는 산도 많이 보인다. 그러면서도 여전히 내 자신에게서 부족한 부분을 많이 보게 된다. 더 나아지기 위해 노력하는 동시에 결여를 부정하거나 괴로워하거나 덮어두지 말고, 있는 그대로를 자연스럽게 받아드릴 수 있는 사람이 되었으면 좋겠다. 그리고 지금까지의 삶에서 갚아야 할 감사가 더 많아졌다. 부지런히 살고 열심히 지내서 도움 주신 모든 분들에게 보답하고 싶고 다른 사람에게 그런 도움을 줄 수 있는 사람이 되도록 노력해야겠다.

앞으로 어떤 삶을 마주하게 될 지 기대된다.


다음은 호주 생활과 관련해서 썼던 글이다.

C# 초보가 C# 패키지를 만드는 방법 발표 후기

😢 이 페이지는 다음 주소로 변경될 예정입니다.

지난 21일 Weird Developer Melbourne 밋업이 있었다. 3회차인 이번 밋업은 라이트닝 토크 형식으로 진행되었고 그 중 한 꼭지를 맡아 C# 초보가 C# 패키지를 만드는 방법 주제로 발표를 했다.

C# 스터디에 참여한 이후에 윈도 환경에서 작업할 일이 있으면 C#으로 코드를 작성해서 사용하기 시작했다. 하지만 업무에서 사용하는 기능은 한정적인데다 의도적으로 관심을 갖고 꾸준히 해야 실력이 느는데 코드는 커져가고, 배운 밑천은 짧고, 유연하고도 강력한 코드를 만들고 싶다는 생각을 계속 하고 있었지만 실천에 옮기질 못하고 있었다.

얼마 전 저스틴님과 함께 바베큐를 하면서 이 얘기를 했었는데 “고민하지 않고 뭐든 만드는 것이 더 중요하다”는 조언을 해주셨다. 말씀을 듣고 그냥 하면 되는걸 또 너무 망설이기만 했구나 생각이 들어서 실천에 옮겼다. 특별하게 기술적으로 뛰어난 라이브러리를 만들거나 한 것은 아니지만 생각만 하고 앉아있다가 행동으로 옮기는 일을 시작한 계기와 경험이 좋아서 발표로 준비하게 되었다.

발표 자료는 다음과 같다.

발표는 다음 같은 내용이 포함되었다.

  • MonoDevelop에서 간단한 예제 코드 시연
  • 라이브러리 작성하면서 배운 것
  • Github
  • Nuget 패키지
  • AppVeyor 설정

라이트닝 토크라서 이 주제가 괜찮지 않을까 생각했지만 다른 분들은 더 심도있는 주제를 많이 다뤄서 쉬어가는 코너 정도 느낌이 되었던 것 같다. 시간을 짧게 한다고 좀 더 설명할 부분을 그냥 넘어가거나 보여줄 페이지를 다 보여주지 못했던 점도 아쉽다.

발표 이후로도 계속 시간을 내서 라이브러리도 다듬고 C# 공부도 부지런히 해야겠다는 생각을 했다. (아직도 갈 길이 멀다!) 학습에서 유익했던 자료와 보고 있는/볼 예정인 자료를 참고로 남긴다.

In Weird Developer Melbourne! Thanks @justinchronicles

A photo posted by 용균 (@edwardykim) on

인터페이스는 클래스 구현과 별도의 프로젝트로 분리해야 하나요?

Interfaces separated from the class implementation in separate projects?를 짧게 번역했다. 이 포스트는 cc-by-sa를 따른다.


인터페이스는 클래스 구현과 별도의 프로젝트로 분리해야 하나요?

Tomas Walek의 질문

현재 중간 규모의 프로젝트를 개발자 3명이서 6개월 넘게 진행하고 있다. 구체적인 구현에서 인터페이스를 분리하자는 결론에 이르렀다. 가장 먼저 인터페이스를 별도의 파일로 보관하기로 했다.

추가적으로 데이터를 더 분리하기 위해서 인터페이스 .CS 파일과 헬프 클래스 .CS 파일(이 인터페이스를 사용하는 퍼블릭 클래스나 enum 등)을 담은 프로젝트(CSPROJ)를 만들었다. 그리고 팩토리 패턴이나 구체적인 인터페이스 구현, 다른 “워커” 클래스 등을 별도의 프로젝트(CSPROJ)로 만들었다.

어떤 클래스든 인터페이스를 구현하는 개체를 생성하려면 그 자체만으로 구현하지 않고 인터페이스와 퍼블릭 클래스를 포함하는 첫 번째 프로젝트로 분리한 다음에 해당 프로젝트를 포함하는 방식으로 작성했다.

이 해결책은 큰 단점이 있다. 어셈블리 수가 2배로 늘게 된다는 점인데 모든 “일반” 프로젝트가 하나의 인터페이스 프로젝트와 하나의 구현 프로젝트를 포함하게 되기 때문이다.

당신의 추천은 무엇인가? 각각 프로젝트 자체에 인터페이스를 보관하는 것보다 인터페이스 만을 위한 별도의 프로젝트 하나를 갖는 것이 좋은 생각인가?


Wim Coenen의 답변

  1. 독자적 인터페이스 (Standalone interfaces)는 프로젝트 나머지와 소통할 필요 없이 사용할 수 있도록 제공하는 목적에서 작성한다. 이런 인터페이스는 단일 항목으로 “인터페이스 어셈블리(interface assembly)”에 넣게 되고 프로젝트 내 모든 어셈블리가 참조할 것이다. ILogger, IFileSystem, IServiceLocator가 전형적인 예시다.
  2. 클래스 결합 인터페이스 (Class coupled interfaces)는 오직 프로젝트 내의 클래스와 사용하는 맥락에서만 이해가 되는 경우다. 이 인터페이스는 의존성을 갖는 클래스와 동일한 어셈블리에 포함한다.

예를 들어보자. 도메인 모델이 Banana 클래스를 갖고 있다고 가정한다. 바나나를 IBananaRepository 인터페이스를 통해서 얻을 수 있다면 이 인터페이스는 바나나와 밀접하게 결합된 상황이다. 이 경우에는 바나나에 대해 알지 못하고서는 이 인터페이스를 구현을 한다거나 이 인터페이스를 사용하는 일이 불가능하다. 그러므로 이 인터페이스는 바나나 어셈블리와 함께 위치하는 것이 논리적이다.

앞 예제는 기술적인 결합이지만 논리적으로 결합하는 경우도 있다. 예를 들면, IFecesThrowingTarget 인터페이스는 Monkey 클래스에 기술적인 연결 고리로 선언되어 있지 않더라도 Monkey 클래스와 함께 사용하는 경우에만 유의미할 수 있다.

내 답변은 개념에 의존적이지 않으며 클래스가 약간 결합하는 정도는 괜찮다고 생각한다. 모든 구현을 인터페이스 뒤에 숨기는 일을 실수일 것이다. 의존성을 주입하거나 팩토리를 통해 인스턴스를 생성하지 않고 그냥 클래스를 “new 키워드로 생성”하는 것도 괜찮을 수도 있다.