HTML5에서 추가된 Geolocation API는 웹 브라우저에서 사용자 위치를 찾을 수 있도록 도와주는 API다. 이 API를 기반으로 웹앱을 만들거나 웹사이트에서 기능을 구현하면 임의의 경도, 위도로 변경해 테스트를 해야 하는 경우가 있는데 Google Chrome 개발자 도구에서 이 Geolocation 위치를 변경하는 기능을 지원한다.
개발자 도구에서 스마트폰 모양 아이콘을 클릭해 emulation 모드를 활성화 한 후, 하단 emulation 탭에서 좌측 Sensors 항목을 클릭하면 Emulate geolocation coordinates 항목을 확인할 수 있다.
좌표를 입력하면 API에서의 좌표가 변경된 것을 볼 수 있다.
2월 한 달 휴가를 내서 한국에 들어왔고 3박 4일 일정으로 서울에서 시간을 보내게 되었다. 만나고 싶었던, 반가운 사람들을 만나 재미있고 알찬 시간을 보낼 수 있어서 좋았다. 많은 분이 호주에서 일하는 삶에 대해 궁금해하셔서 여러 답변을 드렸지만 다소 두서없게 얘기한 감이 있어 짧게라도 정리해 포스팅한다.
2012년 3월에 호주 생활을 시작했으니 이번 휴가를 마무리하고 돌아가면 만 3년차가 된다. 내 호주 생활은 꼭 끝나지 않는 긴 긴 휴가처럼 느껴져서 이렇게 지내도 되는걸까 생각 들 때가 많다. 집 문만 나서면 여행인 기분은 3년을 살아도 그렇다.
한편으로 지냈던 시간을 생각해보면 택배가 엄청 느려서, 한국과 같은 대형 서점이 없어서 불편한 점보다는 언어, 문화적 차이로 인한 고독감이 더 컸다. 내가 활동적인 편도 아닌 데다 오자마자 일을 시작했기 때문에 주변에 아는 사람도 많은 편이 아니라서 더 외로움이 있었다. 게다가 이번 휴가를 지내면서 호주에서는 한국에서 온 한국 사람인데 한국에 돌아오면 한국 사람이 아닌 호주 사는 사람이 되는, 이쪽도 저쪽도 속하지 못하는 느낌을 많이 받았다. 평생을 살아왔던 공간, 국가를 떠나 사는 것은 다른 양말을 신는 것과는 다르다. (물론 이 인식의 강도는 개인마다 다르니까, 양말 갈아 신는 정도로 느끼는 사람도 분명 있다. 선천적으로 노마드의 피가 흐르는 사람!)
하지만 그 누구도 서두름을 강요하지 않는, 여유로움이 일상 속에 가득한 호주를 경험하고 나면 이 곳을 쉽게 벗어날 수가 없다. 여행으로 호주를 다녀간 후에 호주행을 진지하게 고려하는 사람이 많고 또 실제로 여행 후 호주행으로 오신 분이 정말 많다. 사람이 사람답게 살 수 있는, 서로를 이해하고 배려하는 문화, 무엇보다 가족을 중심으로 생각하는 가족 중심의 문화는 자연스럽게 현재의 한국과 비교가 될 수밖에 없는 것 같다.
호주에서의 삶은 확실히 한국에서의 삶과는 다르다. 가족적이고 여유로운 분위기, 자연 친화적인 환경, 저녁 있는 삶과 같이 한국에서 쉽게 만들기 힘든 시간을 활용할 수 있다. 반면 호주에서 적응하지 못하고 한국으로 돌아가는 분들도 많다. 한국 특유의 밤 문화를 좋아하는 분이나 친구가 없어 힘들다고 말씀하시는 분도 있었다.
호주에 관해 궁금하고 고민이 된다면 호주로 여행을 가서 직접 눈으로 확인하는 방법이 가장 좋다. 여행에서 현지 분위기에 매료되어 호주로 오게 되는 분들도 적지 않다. 여행으로 둘러보고 현지에서 사는 많은 분께 조언을 구하는 것도 호주행 결정에 도움이 되리라 생각된다.
IT도 범주가 크고 호주에도 직종의 편중이 있어서 본인이 원하는 일자리와 포지션이 얼마나 있는지 확인하는 것이 중요하다. 일자리 수요가 얼마나 있는지 확인하기 위해서는 seek.com.au와 같은 취업 웹사이트를 찾아보면 되는데 어떤 job description을 요구하고 있는지 등을 파악하는데 용이하다. 다른 방법으로는 meetup.com 과 같은 사이트나 언어 사용자 모임을 찾아보고 그 커뮤니티에 물어보는 것도 큰 도움이 된다.
호주는 IELTS를 통해 영어 능력을 평가한다. 읽기, 듣기, 쓰기, 말하기를 모두 평가하는 IELTS는 General Training과 Academic 두 가지 모듈이 있는데 자신에게 맞는 모듈을 선택해 응시하면 된다. “영어는 얼마나 가능해야 하는가”를 물어보는 경우도 엄청 많은데 자신이 구사할 수 있는 한국어를 영어로 얼마나 구사할 수 있는 지 스스로 생각해보면 어떤 부분을 어떻게 공부해야 할 지 판단하는데 도움이 된다.
호주는 정말 다양한 방법과 경로를 통해 비자를 신청할 수 있고 개개인의 상황에 가장 맞는 방법을 찾는 게 가장 중요하다. 각 비자에 대한 정보는 한국어로 검색해서 나오는 자료보다 호주 이민성 웹사이트에서 확인하는 방법이 가장 정확하고 확실하다. 한국어로 작성된 글은 가장 최신의 정보라는 보장도 없을뿐더러 더더욱이 잘못된 정보라면 시간을 낭비할 수밖에 없다. 이런 글들은 참고 용도로만 찾아보고 필요한 요건이나 서류는 꼭 이민성 웹사이트에서 확인해야 한다.
직접 하는 게 번거롭다면 이민 대행사, 법무 대행사 등에 비용을 내고 해결할 수 있다. 물론 이 경우에도 위 이민성 웹사이트에서 각각의 내용을 상세하게 확인하는 것이 중요하다. 대행은 어디까지나 대행이라 잘못된 내용으로 진행하다 문제가 생겨도 책임을 지지 않는 부분이 있기 때문에 꼭 웹사이트에서 교차로 검증을 해야 한다.
호주에서 거주의 제한 없이 일을 하며 지내기 위해서는 영주 비자를 취득해야 한다. 비자는 각각 개인의 학력, 경력 등에 따라 취득할 수 있는 종류와 방법이 다 다르다. 학교를 다니며 비자를 준비할 수도 있고 미리 영주권을 받아서 오는 경우도 있다. 상황에 맞게 비자를 찾는 것이 가장 중요하다.
내 경우에는 다음과 같은 과정으로 진행하고 있다.
대부분 워킹 홀리데이로 와 정착하는 경우에는 위와 같은 과정을 거치는데 시간이 많이 들고 고용주에 따라 불확실성이 좌우되는 경향이 있어서 비록 내가 이 과정으로 영주권을 받으려고 하고 있지만 추천하고 싶지는 않은 과정이다. ENS는 3가지 stream을 지원하고 있는데 만약 다른 stream에 조건이 맞으면 임시 취업 비자 없이도 바로 영주 취업 비자를 신청할 수 있다.
다른 방법으로는 독립기술이민 Skilled Independent visa (subclass 189) 비자를 통해 영주권을 신청할 수 있다. 안정적으로 비자를 취득할 수 있어서 많은 분들이 이 비자로 호주에 들어오고 있다. 예전에는 독립기술이민 요건만 맞으면 바로 영주권을 줬는데 이제는 SkillSelect 라는 제도로 변경되어 직업군에 따라 발급해주는 양을 조절하고 있다.
독립기술이민은 경력, 학력, 영어점수, 나이 등을 제공되는 점수표에 따라 환산해 60점 이상이 나왔을 때 신청할 수 있다. 점수표는 웹사이트에서 확인할 수 있다. 점수표는 학력, 경력이 있다면 그렇게 까다로운 편은 아니다. 예를 들면 학사 학력이 있고 3~5년 경력, 만 32세라면 점수가 충족된다.
나이 30점 + 경력 5점 + 학력 15점 + 영어 10점 = 60점
점수가 되면 신청 자격이 생기지만 그 외 직업군이나 기타 확인해야 할 사항이 많다. 신청 가능한 Skilled Occupation List (SOL)을 확인해보는 등 체크 리스트를 확인해봐야 한다.
앞에서도 이야기했지만 여기서 이야기한 비자는 극히 일부다. 이민성 웹사이트를 통해 모든 비자를 확인해보고 자신에게 가장 잘 맞는 비자를 선택하는 것이 중요하다.
(두서 없는 이야기를 두서없게 정리했다… 만약 부족한 부분이나 궁금한 부분이 있으면 덧글을!)
나에게 있어서도 삶의 터전을 옮기기는 쉽지 않은 결정이었고, 결정하고 나서 실행하는 것 하나하나도 큰 도전이었다. 그 과정 모두 엄청난 경험이었고 그사이 만나게 된 사람들에게 받은 도움이 너무나도 감사하다. 이 결정을 내릴 때 심각하게 고민했던 일들은 정말 사소한 일들이었고 지금은 그때 생각했던 것보다 더 넓은 눈으로 미래를 기대하고 있다.
내 짧은 3년의 경험이 지금 고민하는 분들에게 도움이 되었으면 좋겠다.
기한이 좀 지난 글이긴 하지만 지금 내가 느끼는 호주와 크게 다르지 않아 링크를 남긴다.
내 글인데 워킹 홀리데이로 온다면 조금이나마 도움이 될까 싶어 링크를 붙였다.
이번에 한국을 가는데 상하이 푸동공항을 경유해서 가게 되었다. 인터넷으로 검색했을 때 관련 글을 찾을 수 없어서 답답했는데 경유한 경험을 기록 차원에 짤막하게 포스팅한다. 사진을 넣으면 좋겠지만 입/출국장 사진은 촬영이 금지되어 있고 민감할 수 있는 사안이라 글로만 적어둔다.
멜번에서 한국 직항도 없어졌고 항상 이용하던 콴타스는 멜번-시드니-인천 경로라서 집인 제주로 내려가는 연결편을 타기가 번거로운 편이었다. 그래서 이번에는 중국동방항공을 이용해서 멜번-상하이-제주 경로로 표를 구입했다. 상하이-제주는 좀 비싼 편이라 그렇게 표는 저렴한 편이 아니었지만 그래도 콴타스보다는 저렴했다.
비행은 밤 10시 30분(멜번 시간)에 출발해 상하이에 아침 5시 30분(북경 시간)에 도착했고 제주 출발은 북경 시간 오후 4시 10분에 예정되어 있어 10시간 가량을 상하이에서 체류하게 되었다.
비행기 모드로도 사용할 수 없다. 기내 미디어에 한국 영화 보면서 시간 보냈다.
멜번-상하이-제주 편이 전부 같은 항공사라서 짐을 상하이에서 되찾지 않고 바로 제주로 연결되었다. 상하이에서 입을 두꺼운 옷을 생각 없이 캐리어에 담아 맡겼던 탓에 추워서 벌벌 떨었다. 경유지에서 찾아야 하는 물건이 있으면 진작에 챙겨두는 것이 좋다. 말해서 상하이에서 되찾아도 상관 없긴 하지만 상하이 공항에도 짐 맡기기 위한 대기열이 엄청 길기 때문에 장단점이 다 있다.
내가 검색했을 때에는 무조건 입국한 후에 다시 출국해야 한다는 얘기만 있었는데 국제선 경유 프로세스가 있다. 비행기에서 내려 입국장에 들어서면 오른쪽으로는 입국 심사대로 진입하는 통로고 좌측으로는 국제선 출국장으로 갈 수 있도록 “transfer to international” 공간이 마련되어 있었다. 상하이에 들어가지 않을 생각이라면 이쪽에 줄을 서면 된다. (줄이 엄청 길었다.) 나는 10시간 가량 여유가 있어서 무비자로 입국하기로 했다.
2015-03-02 추가 – 호주로 돌아올 때 경유 프로세스 절차를 밟았다. 경유 창구에 가면 티켓을 확인한 후 직원을 따라 이동하게 된다. 창구 뒷편 문을 통과해 수하물 검색을 진행하는데 검색을 통과하면 출국장으로 바로 갈 수 있다.
상하이는 72시간 내 제3국(홍콩, 마카오, 타이완 포함)으로 출국하는 항공권이 있으면 72시간 동안 별도의 비자 없이 체류가 가능하다.
기내에서 입국 및 출국 카드를 받을 수 있다. 입국 카드를 작성할 때 무비자 입국 관련해서 어떻게 작성해야 할 지 설명이 전혀 없는데 체류할 주소는 없으면 안적으면 된다. (물론 체류 시간이 낮이었기 때문에 그런 것 같다. 1박 이상 한다면 당연히 있어야.) 나는 입국 사유에는 관광으로 체크했고 입국 심사할 때 “transfer?” 라고 물어봐서 그렇다고 대답했다.
푸동 공항은 상하이 중심가와 10분 내외로 연결되는 자기부상열차 Maglev가 있다. 하지만 운영 시간은 오전 9시부터 밤 11시까지라 내가 도착한 시간에는 문도 열지 않았었다. 대신 아침 일찍부터 지하철은 운행하기 때문에 지하철로 이동하면 된다. 지하철은 1일권이 18위안인데 자동판매기에서 팔지 않는 대신 역무원한테 물어보고 구입할 수 있다.
지하철 2호선은 주요 관광지로 연결되는 노선이다. 대신 광난루广兰路 역과 푸동공항 사이에는 탑승객이 적어서 그런지 광난루에서 도심으로 가는 지하철로 갈아타야 한다. 다들 내려서 어디론가 이동하면 따라서 가면 된다.
Maglev는 롱양루龙阳路 역과 연결되어 있다. 2호선 밖으로 나오면 Maglev 탈 수 있는 플랫폼이 따로 있고 표를 판매하는 창구가 있다. 편도는 50위안 왕복은 80위안에 구입할 수 있다.
필름을 들고 가지 말아야 할 도시 0순위다. 공항 이용 시 수하물 검사 시 xray 스캔 만으로도 상당히 민감할 수 있는데 상하이는 지하철 이용할 때마다 스캔을 해야해서 고감도 필름을 사용한다면 특히 주의해야 할 듯 싶다. 수하물 검사할 때 필름이 있다고 얘기하면 xray 없이 손으로 들고 통과하게 한 후 수검사를 진행한다.
난징동루南京东路 역에서 내려 외이탄-예원-난징동루-인민광장 이 근처를 구경했다. 사실 관광도 쇼핑도 망했는데 아침 5시 반에 도착해서 시내 도착한게 7시라 문 연 곳이 하나도 없어서 외이탄 말고는 어마어마한 중국의 출근 풍경 구경한게 전부였다. 나중엔 제대로 시간을 들여 숙박하고 구경해야겠다는 생각이 들 정도로 구석구석 볼 만한 곳이 많았다.
관광객이 많이 가는 동네는 영어 되는 사람이 많아서 사먹는데 문제가 없다. 뒷골목에서 길거리 음식 파는 곳은 중국식 숫자 수신호를 외워 갔는데 그걸로도 충분히 소통하고 사먹을 수 있었다.
출국 심사는 줄이 길긴 했지만 그렇게 오래 걸리진 않았다. 느낌은 인천공항에서 출국심사 하는 것과 거의 비슷했다.
면세점은 인천이랑 비교하면 정말 구경할 곳이 적다. 일부 공사중이긴 했지만 전자제품 파는 매장도 없었다. 인터넷은 무료 wifi가 있긴 한데 중국 번호 또는 로밍되서 문자를 받을 수 있는 번호가 있어야 한다.
예전에 인천공항에서 자동입국심사를 신청해뒀는데 제주에도 해당 시스템이 구축되어 있었다. 그 덕분에 입국 심사대도 빠르게 통과하고 짐도 맨 처음 찾아 바로 나올 수 있었다. 비행기 제주 도착부터 게이트 나갈 때까지 20분도 걸리지 않았다.
초고층 현대식 건물들 사이에 말도 안되게 작고 좁은 집들이 다닥다닥 있는 모습이 여러 생각이 들게 한 상하이였는데 다음엔 더 구석구석 돌아보고 싶다는 생각이 많이 들었다.
CoffeeScript에 대한 얘기는 정말 많이 들었고 주변에서도 많이 사용하고 있지만 정작 제대로 살펴본 적이 없었다. 주말 시간을 내서 Better CoffeeScript Testing With Mocha 글을 중점으로 여러 아티클을 읽어보고 정리하는 차원에 남기는 포스트다.
이 모든 내용을 포스트 하나에서 다루기에는 각각의 내용이 방대하기 때문에 개론적으로만 읽고 각 소제목에 따른 더 읽을 거리를 참고 했으면 좋겠다.
BDD 즉, 행위/행동 주도 개발은 애자일 방법론 중 하나로 TDD와 인수 테스트 주도 계획(Acceptance Test-Driven Planning)에서 진화한 방법론이다. TDD를 한다는 본질은 다르지 않지만 사용자 스토리와 같은 인수 테스트를 기준으로 기획하게 된다.
유닛테스트는 올바른 코드를 작성했는가 즉, 개개의 클래스와 메소드를 테스트 한다면 인수테스트는 올바른 소프트웨어를 작성했는가 즉, 시스템 전반에 걸친 기능에 대해 테스트하게 된다. 그 결과로 Domain-Driven Design과 같이 기획과 개발에서 같은 시나리오로 이야기 할 수 있게 되고, 개발에서는 사용자 스토리의 맥락을 통해 요구사항을 쉽게 이해할 수 있게 된다.
더 읽어볼 만한 내용은 마지막 섹션인 더 읽을 거리에서 찾아볼 수 있다.
CoffeeScript는 JavaScript로 컴파일 할 수 있는 작은 언어다. JavaScript에서 반복적으로 사용되는 코드를 효과적으로 짧게 사용할 수 있도록 도와주고 그로 인해 가독성도 높아지는 등 여러 장점이 있어 많은 사람들이 사용하고 있다. 공식 사이트를 보면 알겠지만 축약 문법을 제공한다고 생각하면 이해하기 쉽다.
nodejs가 설치되어 있다면 npm으로 간단하게 설치해서 사용할 수 있다.
npm install -g coffee-script
js파일을 node에서 실행해볼 때 node something.js 와 같이 실행한다면 CoffeeScript에서는 coffee something.coffee 처럼 실행할 수 있다. 앞서 이야기 한 것처럼 CoffeeScript는 JavaScript로 컴파일되어 실행되는데 js파일로 어떻게 컴파일되는지 확인하고 싶다면 --compile 플래그를 사용해 js파일을 확인해볼 수 있다.
coffee --compile something.coffee
# something.js 파일로 결과물이 나온다
CoffeeScript의 문법은 CoffeeScript 웹사이트에서 확인할 수 있다.
Mocha는 JavaScript 테스트 프레임워크로 node, 브라우저, 비동기 테스트까지 가능하다. 순수하게 테스트를 위한 프레임워크라서 assertion을 위해 다른 라이브러리를 사용해야 한다. 이 포스트에서는 chai BDD/TDD assertion 라이브러리를 사용한다.1
내가 읽은 글은 Todo 만들기였는데 이 포스트에서는 서점 만들기2를 해보려고 한다. 앞서 언급한 세 모듈을 로컬에만 설치해서 node_modules/.bin/coffee <blarblar> 식으로 사용해도 되지만 그냥 전역으로 설치했다.
$ npm install --global coffee-script mocha chai
먼저 npm init로 package.json을 생성하고 앞서 세 모듈을 의존성 모듈로 추가한다.
$ mkdir bookstore
$ cd bookstore
$ npm init
$ npm install coffee-script --save
$ npm install mocha chai --save-dev
Mocha는 기본적으로 test 폴더 내에 있는 파일들을 실행한다. test 폴더를 생성하고 bookstore_test.coffee를 추가해 테스트를 작성한다.
$ mkdir test
$ touch test/bookstore_test.coffee
Chai는 BDD와 TDD 모두 지원하는데 BDD 스타일로 사용하려면 chai를 불러온 후 chai.should()를 호출해야 한다. 다음과 같이 describe와 it으로 테스트 파일을 작성한다.
chai = require 'chai'
chai.should()
{Book} = require '../src/bookstore'
describe 'Book', ->
it 'should have a title', ->
book1 = new Book 'Colorless Tsukuru Tazaki'
book1.title.should.equal 'Colorless Tsukuru Tazaki'
위 파일에서 assert 라이브러리 chai를 불러오고 Book 클래스를 앞으로 작성할 파일인 bookstore.coffee에서 불러왔다. 그리고 책은 제목을 가져야 한다는 시나리오를 작성하고 그에 맞는 테스트를 추가했다. 이제 프로젝트 디렉토리로 이동해서 mocha로 테스트를 실행한다.
$ mocha
0 passing (1ms)
mocha는 실행되었지만 작성한 파일이 실행되지 않았다. 만약 여기서 Error: cannot resolve path (or pattern) 'test'가 난다면 프로젝트 최상위 위치가 아니기에 test 디렉토리를 찾지 못해 발생하는 에러다.
여기서 mocha를 별다른 플래그 없이 실행하면 기본값인 JavaScript 파일만 확인해서 실행이 된다. 이 테스트가 CoffeeScript로 작성되어 있으므로 --compiler 플래그를 다음과 같이 추가해야 한다.
$ mocha --compilers coffee:coffee-script/register
Book
1) should have a title
0 passing (4ms)
1 failing
1) Book should have a title:
ReferenceError: Book is not defined
...
작성한 코드가 실행되었고 아직 Book을 작성하지 않았기 때문에 실패했다. (위 코드에서 보듯 ReferenceError가 발생했다.) src 디렉토리에 bookstore.coffee를 추가하고 코드를 작성한다.
class Book
constructor: (@title) ->
true
root = exports ? window
root.Book = Book
CoffeeScript는 컴파일되면 익명함수 속으로 들어가서 실행되기 때문에3 마지막 두 줄을 추가해 다른 곳에서도 해당 클래스를 사용할 수 있도록 해야 한다.
이제 파일을 작성했으니 mocha를 실행해야 한다. mocha를 실행할 때 --compiler 플래그 등의 설정값을 설정파일을 만들어서 대체할 수 있다. test 폴더 내에 mocha.opts 파일을 만들고 해당 플래그를 추가한다.
--compilers coffee:coffee-script/register
이제 mocha를 실행하면 다음과 같이 테스트가 성공하는 것을 확인할 수 있다.
$ mocha
Book
✓ should have a title
1 passing (3ms)
여기서 책은 새 책/헌 책 일 수 있다, 책은 시리즈물 일 수 있다는 행동을 추가해 다음과 같이 작성했다.
describe 'Book', ->
book1 = book2 = null
it 'should have a title', ->
book1 = new Book 'Colorless Tsukuru Tazaki'
book1.title.should.equal 'Colorless Tsukuru Tazaki'
it 'should be a series of books', ->
book1 = new Book "Harry Potter and the Philosopher's Stone"
book2 = new Book "Harry Potter and the Chamber of Secrets"
book2.seriesOf book1
book2.volume.should.equal 'series'
book2.original.should.equal book1
book1.sequel.should.equal book2
it 'should be initially new', ->
book1.status.should.equal 'new'
it 'should be used', ->
book1.use().should.be.true
book1.status.should.equal 'used'
위 테스트를 통과할 수 있도록 seriesOf, use 메소드와 volume, status 프로퍼티를 추가해 Book 클래스를 작성하면 다음과 같다.
class Book
constructor: (@title) ->
@volume = 'single'
@status = 'new'
true
seriesOf: (@original) ->
@original.sequel = @
@volume = 'series'
use: ->
@status = 'used'
true
테스트를 실행하면 테스트를 모두 통과하는 것을 볼 수 있다.
$ mocha
Book
✓ should have a title
✓ should be a series of books
✓ should be initially new
✓ should be used
4 passing (3ms)
어떤 과정으로 프로젝트를 시작하고 BDD를 통해 개발을 하는지 간단하게 확인했다. 원 글에서는 다른 클래스에 대해서도 설명했지만 같은 내용을 반복하는 것보다 추가적인 과정은 직접 해보고 리포지터리랑 비교해보는게 좋을 것 같아서 여기까지만 작성했다.
Bookshelf는 다음과 같은 시나리오로 작성을 했다.
Mocha와 chai로 다양한 시나리오를 작성해보고 그에 맞는 코드를 CoffeeScript로 작성해보는 것은 분명 도움이 되리라 믿는다. 내가 작성한 최종 코드는 이 리포지터리에서 확인할 수 있다.
Better CoffeeScript Testing With Mocha는 위 내용보다 더 세세하게 다루고 있어서 이 글 보다 이해하기 쉽다.
BDD에 대해서 더 알고 싶다면 다음 글이 도움이 된다.
여기서 사용한 모듈은 전부 문서화가 잘 되어있는 편이었다.
이름만으로는 도대체 무슨 역할을 하는지 알 수 없는 시대다. 커피 이름 종류별로 다 쓰고 나면 나중엔 WhiteChocolateMochaFrappuccino 같은 이름을 써야할지도. ↩
<li id="fn-2621-2">
결국은 같은데 이름만 다른 코드 아니냐 하시면 할 말은 없습니다. 녜. (…) <a href="#fnref-2621-2" rev="footnote">↩</a>
</li>
<li id="fn-2621-3">
<code>coffee -c filename.coffee</code> 명령어로 어떻게 컴파일이 되는지 눈으로 확인하면 이해가 쉽다. <a href="#fnref-2621-3" rev="footnote">↩</a> </fn></footnotes>
최근에 #이상한모임 slack이 개설되었다. 순식간에 많은 분들이 가입해서 왕성한 활동 펼치고 있어 신기해 하는 한편 같이 휩쓸려(?) 잘 놀고 있다. 골빈해커님이 hubot으로 weirdbot을 만들어서 재미있는 기능들을 만드는 것을 보고 hubot을 어떻게 만들 수 있는지 찾아보게 되었다.
Hubot은 GitHub에서 공개한, 자동화를 위한 채팅봇이다. Node.js 기반에 CoffeeScript로 짜여져 있고 Heroku와 같은 곳에 손쉽게 디플로이 해서 활용 가능하며 확장도 간편하게 가능하도록 구성되어 있다. 또한 이미 많은 기능들이 구현되어 있어서 npm에서 hubot-script을 내려받고 설정하는 것으로도 강력하게 활용할 수 있다.
Slack은 협업을 위한 채팅 도구로 GitHub, Trello 등 다양한 Integration, 여러 체널의 Push notification 지원 등 편리한 기능을 많이 제공한다. 이전까지는 몰랐는데 내부적으로는 IRC로 구현되어 있는 모양이다. IRC에 친숙하다면 쉽게 적응해서 사용할 수 있을 정도로 유사한 부분이 많다.
Slack에서 Integration을 통해 Hubot을 추가하면 API키를 발급해줘서 쉽게 연동이 가능한데 무료 정책 내에서는 연동할 수 있는 서비스 수가 제한되어 있기 때문에 여기서는 IRC gateway를 활용했다. IRC Gateway는 보안상 기본 설정에서는 사용할 수 없다. 사용하려면 slack의 primary owner에게 요청해 기능을 사용할 수 있도록 활성화 해야 한다. 다만 이 gateway를 사용하게 되면 채팅방의 내용이 외부로 노출될 가능성이 있다는 요지의 안내를 받을 수 있는데 보안성에 민감한 slack이라면 이 방법보다 앞서 얘기한 hubot integration을 사용하는 편이 낫다.
이 글에서는 다음과 같은 방법으로 Hubot을 만들어 사용했다. (늘 그렇듯 OSX 기준으로 작성되어 있다.)
본인 그룹의 slack에서 IRC Gateway 사용이 가능하다면 로봇으로 상주시킬 계정을 새로 생성한 후 Account > Settings > Gateways 에서 Gateway Configuration 버튼을 눌러 Host, User, Pass 정보를 확인한다.
사실 이런 포스트 할 필요도 없을 정도로 Hubot 문서는 깔끔하게 잘 되어 있다. 먼저 기본적으로 nodejs는 설치되어 있어야 한다.
$ npm install -g yo generator-hubot
$ mkdir koalabot
$ cd koalabot
$ yo hubot
[yeoman](http://yeoman.io/) 제너레이터로 hubot을 생성할 수 있다. yo hubot 명령어를 입력하면 봇을 생성하는 인터프리터가 나타나는데 내용에 맞게 작성자, 봇 이름, 설명 등을 순차적으로 입력하면 된다. 여기서는 IRC Gateway를 사용하므로 adapter에는 irc을 입력하면 된다. 그러면 알아서 irc에 맞는 어뎁터가 설치된다.
여기서 unicode/ucsdet.h를 찾을 수 없다는 에러가 나타나면 다음 명령어로 command line developer tool을 설치한다.
$ xcode-select --install
이제 초기 생성이 끝났다. 이제 설치된 hubot을 shell adapter를 통해 콘솔에서 확인할 수 있다. hubot help를 입력하면 사용 가능한 명령어를 볼 수 있다.
$ bin/hubot --name <봇이름>
이제 heroku로 봇을 내보낼 차례다. heroku를 사용하기 위해서는 heroku에 먼저 가입을 해야 하고 heroku toolbalt를 설치해야 한다. 그리고 나서 생성한 hubot을 git에 커밋한다.
$ git init
$ git add .
$ git commit -m "Initial commit"
앞서 가입한 heroku를 heroku login을 통해 로그인하고 dyno라고 불리는 컨테이너를 생성한 후 환경설정을 한 다음에 앞서 만들었던 hubot을 내보내는 순서로 진행된다.
$ heroku login
# 앞서 가입한 정보로 로그인
$ heroku create
# heroku에 dyno가 생성됨, dyno 주소를 알려준다.
# 환경변수를 다음과 같이 지정하는데 서버, 닉네임, 비밀번호는 앞서 IRC Gateway에서의 정보를 입력해야 한다.
$ heroku config:set HUBOT_IRC_SERVER="<IRC Server>"
$ heroku config:set HUBOT_IRC_NICK="<IRC Nickname>"
$ heroku config:set HUBOT_IRC_PASSWORD="<IRC Password>"
# 자동으로 접속하게 될 방 목록을 `,`로 구분해서 입력한다.
$ heroku config:set HUBOT_IRC_ROOMS="#koala,#kangaroo,#melbourne"
$ heroku config:set HUBOT_IRC_UNFLOOD="false"
$ heroku config:set HUBOT_IRC_USESSL=1
# dyno가 생성될 때 알려준 주소를 입력한다.
$ heroku config:set HEROKU_URL=http://hot-koala-2015.herokuapp.com
# heroku로 git을 push하면 끝난다.
$ git push heroku master
hubot-scripts에 포함되어 있는 스크립트는 hubot-scripts.json에 추가하는 것으로 바로 사용할 수 있다. 사용 가능한 목록은 카탈로그 페이지에서 확인할 수 있다.
외부 스크립트 설치도 지원한다. 다음은 hubot-thank-you를 설치하는 예로 아래와 같이 npm으로 설치한 후 external-scripts.json에 배열로 해당 스크립트명을 추가하면 된다.
$ npm install hubot-thank-you --save
# external-scripts.json을 열어서 "hubot-thank-you"를 json스럽게(...) 추가한다.
직접 만들고 싶다면 scripts 폴더에 있는 example.coffee를 참고해 만들면 된다. 자세한 가이드는 Scripting 항목에서 볼 수 있다.
아무리 재미있는 도구들이 나와도 회사에서 적용하지 않는 경우엔 둘러보는 정도로 그칠 때가 많았는데 이 기회에 살펴볼 수 있어서 좋았다. CoffeeScript는 아직도 어색한데 익숙해질 수 있도록 좀 더 살펴봐야겠다.
아이폰을 과하게 쓰다보니 몇번 완충완방이 되었었는데 베터리 수명에 그렇게 큰 영향을 준다는 사실은 최근에야 알았다. 사무실에도 충전 케이블을 하나 비치해두기 시작해서 평일엔 그래도 괜찮은 편이지만 주말엔 정말 금방 베터리가 달아버려 불편했었다. 그러던 중에 Xaomi Power Bank가 평이 좋아 Aliexpress를 통해 하나 구입하게 되었다.1
내가 구입한 모델은 Xaomi Power Bank2 10400mAh이다. 자세한 스펙은 xaomi power bank 페이지 에서 확인할 수 있다.
매일 가지고 다니는 카메라 Ricoh GR도 베터리가 짧은 편이라 여행을 가거나 한다면 이 충전기 힘을 빌리게 될 것 같다.
2014년엔 예기치 못했던 건강 문제로 후반기 내내 컨디션 회복이 안되서 더 금방 지나가버린 기분이다. 작년에 2013년을 회고하며 2014년을 계획했던 글을 읽어보면 지난 2014년도 그다지 목표가 많이 지켜지진 않은 것 같지만 돌아보면 잘잘하게 많은 개인 프로젝트도 했고, 그 중에 Koala Hates Rain 같이 끝을 본(!) 개인 프로젝트도 있었고, 깊이 있는 주제는 없었지만 블로그도 나름 꾸준하게 했고, 이상한모임도 이 멀리서 나름 재미있게 참여할 수 있었고, 취미에 시간을 더 써보기도 하고, 회사도 성장해서 연봉도 올랐다(…). 이런저런 작고 큰, 감사할 일이 참 많았던 해를 보냈다.
오늘은 공부하러 도서관에 갔는데 올해 계획을 생각하다가 실천의 밑거름이 되었으면 하는 마음에서 올해의 목표 목록을 다음과 같이 적어봤다.
경험은 개인적이고 그만큼 폐쇄적인 자산이지만 글, 사진 등 여러 매체를 통해 공유를 하면 다수의 간접 경험으로 확장할 수 있고 그 과정 자체에 큰 의미가 있다는 생각이 들었다. 내가 겪는 경험을 공유해 가치를 더 할 수 있도록 노력해야겠다. 경험의 공유는 결과가 아닌 과정에 초점을 두는 것도 빼먹지 말아야겠다.
호주 거주 만 3년이 되어가고 있다. 영어도 여전히 반쪽인데 한국어 사용 빈도도 점점 적어지고 있어서 두 언어 모두 어눌한 기분이 든다. 그래서 그런지 내 정체성도 점이지대를 방황하는 주변인 정도로 느껴지고 있다. 그래서 내 생각과 의견을 정확하게 전달할 수 있도록 의사소통을 위한 훈련이 필요하다.
글쓰기는 매년 목표에 있었는데 올해에는 경험의 공유를 위해서라도 더 의미를 부여하고 꾸준히 진행하려고 한다. 지난 해에 영어에도 제대로 투자하지 않았는데 시험 준비를 다시 해 제대로 공부를 해야겠다.
출퇴근 시간도 많이 걸리는 데다 환승도 여러번 해야해서 은근 시간이 낭비되는 경향이 있는데 시간을 좀 더 체계적으로 관리해서 사용해야겠다. 요즘 호흡이 긴 글을 읽는데 힘들어 하고 있는 편이다. 그래서 전반기엔 이 시간을 책을 읽는데 투자하고 싶다.
한동안 많이 절제 했었는데 또다시 SNS를 지나치게 하고 있다는 생각이 든다. 하고 싶은 일이 많은데 다 하려면 시간을 정하고 그 시간 안에 밀도 있게 사용하는 습관이 필요하다. 당분간 SNS와는 멀어지고 좀 더 정적인 매체에 가까이 가는 연습을 해야겠다. 그리고 하고 싶은 일들을 지치지 않도록 잘 배치해 부지런히 해야겠다. (회사 일, 영어, 개인 프로젝트, 새로운 언어 공부, 코세라, 사진.)
작년에 운동을 나름 꾸준히 했었는데 아픈 이후로 제대로 운동을 못하고 있다. 운동을 안하니 잠과 살만 늘고 있어서 잠도 줄일 겸 운동도 열심히, 그리고 꾸준하게 할 수 있도록 해야겠다. 잠도 조절해야 하고 음식 조절도 필요하다. 커피도 점진적으로 줄이고 식습관도…
호주는 한창 여름이다. 오늘도 최고 기온이 41도였는데 1월에 이런 날씨는 아무리 만 3년차가 되어도 어색하다. 그래도 삶에서 매년 마주하는 1월은 내 삶의 징검다리를 만드는 시간 같고 내 삶 마지막 1월에 어떤 징검다리 위에 서 있게 만들지도 궁금하다. 올해에도 재미있고 행복한 일, 그리고 새롭게 도전할 수 있는 일들이 많이 있었으면 좋겠다.
요즘 대부분의 php 도구들이 콘솔에서 사용할 수 있도록 제공되고 있다. OSX에는 기본적으로 php가 설치되어 있고 별다른 설정이 없다면 이 php를 사용하게 된다. composer 같은 도구는 php 버전이나 모듈과는 큰 영향이 없어서 기본 설치 과정을 따라해도 큰 문제가 없지만 데이터베이스 연결이 필요하거나 하는 경우에는 문제가 발생할 수 있다.
MAMP 환경을 설치해서 개발에 사용하고 있다면 이 MAMP에서 사용하고 있는 php를 간단하게 연결해서 활용할 수 있다.
이와 관련해서 검색해보면 직접 컴파일해서 패키지를 설치하라거나 mamp-php 등의 이름으로 심볼릭 링크를 연결해주는 등 여러 방법이 있었는데 다 장단점이 있었고 가장 간단하고 별 문제 없는 방식이 기존 설치되어 있는 php를 mamp 안에 있는 php로 심볼릭 링크를 생성해주는 방법이었다.
먼저 php가 설치되어 있는 위치를 찾는다.
$ which php
/usr/local/opt/php56/bin/php
내 경우는 brew로 php5.6을 설치해 경로가 다른데 /usr/local/bin/php 쯤 될 것이다. 파일명을 변경하고 심볼릭 링크를 생성한다.
$ cd /usr/local/opt/php56/bin/
$ mv php php_backup
$ ln -s /Applications/MAMP/bin/php/php<사용하는 php version>/bin/php php
이렇게 변경하면 기본 php를 mamp에서 사용하는 php로 사용할 수 있다.
2015년 1월 20일 추가.
환경변수를 추가해주는 방법도 있었다. (왜 이걸 생각하지 못했는지 ㅠㅠ) 다음 두 값을 zsh 사용자는 .zshrc, bash 사용자는 .bash_profile에 추가하면 된다.
export MAMP_PHP=/Applications/MAMP/bin/php/php<사용하는 php version>/bin
export PATH="$MAMP_PHP:$PATH"
환경변수에 선언되어 있는 순서대로 명령어를 실행할 수 있는 프로그램이 있는지 확인한다. 정상적으로 연결되어 있는지는 앞서 사용했던 which 명령어로 확인할 수 있다.
국가에서 특정 사이트를 직접적으로 차단/통제하는 경우1도 있고 배급 등 라이센스 문제로 국가 제한에 막혀 사용해보지 못하는 미디어 관련 서비스들도 있다. 이런 경우 VPN을 통해 해당 사이트 또는 서비스를 이용할 수 있다. (이러라고 만든 VPN은 아닌 것 같지만;)
물론 유료 VPN을 쓸 수 있지만 자주 사용하는 게 아니라면 비용이 좀 아깝다. 게다가 모든 트래픽이 해당 VPN을 경유하기 때문에 유료든 무료든 보안상 찝찝할 수 밖에 없다. 그래서 저렴하고 안전한 방식은 없을까 고민하다가 AWS의 EC2 Free tier를 활용해 VPN을 구성하는 방법을 찾게 되었다.
AWS의 EC2를 생성 및 사용해본 적이 없다면 다음 글을 참고하자. 내 인스턴스를 생성할 땐 지역은 북미(N. Virginia), 설치 이미지는 ubuntu를 선택했는데 지역은 자신의 용도에 맞게 사용하면 되겠다.
이제 생성한 인스턴스에 VPN을 구성할 차례다. Voodoo Privacy Project에서 제공하는 VPN 설치 쉘스크립트를 사용하면 간편하게 설치할 수 있다.
$ wget https://raw.githubusercontent.com/sarfata/voodooprivacy/master/voodoo-vpn.sh
쉘스크립트를 받은 후 IPSEC_PSK, VPN_USER, VPN_PASSWORD를 안전한 정보로 변경한다.
그다음 관리자 권한으로 설치하면 끝난다.
$ sudo bash voodoo-vpn.sh
다음은 VPN을 설정할 차례다. 시스템 설정 > 네트워크에서 다음과 같은 절차로 VPN을 생성할 수 있다. 먼저 네트워크 창에서 좌측 하단 + 버튼을 눌러 VPN을 추가한다.
서버 주소는 ssh 접속할 때 사용한 주소(ec2-00-00-00-00.compute-1.amazonaws.com 같은 형식), Account Name은 위에서 변경했던 VPN_USER 값이다.
인증 설정 Authentication Settings... 버튼을 누른 후 나머지 설정들은 위에서 작성했던 VPN_PASSWORD, IPSEC_PSK 순으로 입력하면 된다.
그리고 모든 트래픽을 VPN을 통해 받을 수 있도록 고급 Advanced... 버튼을 눌러 Send all traffic over VPN connection을 체크한다. 여기까지 설정한 후 Connect 버튼을 눌러 VPN을 활성화하면 모든 과정이 완료된다.
EC2 서비스는 사용량에 따라 비용이 청구될 수도 있으므로 조금 주의깊게 보는 것이 좋다. EC2 Free tier 제공 범위를 넘는 트래픽을 만들면 EC2 요금을 내게 되니 유의하자. Free Tier는 월 750시간까지 해당이라 나는 그냥 켜둔 상태로 두고 있고 아직까진 사용량이나 트래픽으로 별다른 요금이 발생하지 않았다.
N 모 유명 스트리밍 서비스의 경우는, 스트리밍이 시작되고 나서 VPN을 꺼도 끊기지 않았다. 사용하지 않을 때는 VPN 접속을 끄면 된다. 물론 VPN 서버를 종료해도 되는데 이런 경우 다시 켰을 때 IP가 변경되어 설정을 변경해야 하는 번거로움이 있어 별로 추천하지는 않는다.
얼마 전 처음으로 원격근무를 경험했다. 우리 회사는 상당히 유연한 근무 환경을 제공하고 있어서 꼭 참여해야 하는 미팅이 있는 경우가 아니고서는 원격근무가 가능하다. 지금까지 신청하지 않았던 이유는 근무 환경이 달라지는 것, 내가 집에서 쓸 수 있는 개발 환경이 회사에서보다 제한적이었던 상황이었기 때문에 한번도 이런 형태로 일을 해보지 않았었다. 이번엔 특이하게도 택배를 본인이 수령해야 하는(?) 부득이한 상황이라서 재택근무를 하기로 마음 먹었고 처음으로 집에서 일을 해보게 되었다.
원격근무는 집에서 일을 하는 것이라고 막연하게 알고 있었지만 내 방 책상에 앉아서 컨퍼런스 콜을 하고 코드를 작성하고 이메일을 작성하고보니 “집에서 일을 한다”라는 문장이 이전과는 조금 다르게 느껴졌다. 그 전까지는 출퇴근을 하면서 조금이나마 전환 시간이 있어서 그랬는지 일과 내 삶이 명확하게 분리되었던 반면에 재택근무는 일상에 업무를 끌어다 놓는 과정으로 느껴졌다.
업무와 삶이 뒤범벅 되는 일은 재택근무를 하게 될 때 경계해야 하는 부분 중 하나라고는 하지만 가장 이상적으로 일을 할 수 있는 환경을 만드는 일과 같다고 느껴졌다. 일과 일상에서 컨텍스트 스위칭이 빈번하게 일어날 수 있는 환경이라 그 둘이 명확히 분리해야 한다고 생각하는 사람에게는 분명 좋은 환경은 아닐 것이다. 반면 내 일에 더 몰입하고 싶다면 이보다 더 좋을 수가 없다. 아침부터 막히는 출근길, 환승 시간표, 주의력을 분산하게 만드는 수많은 인터렉션들(내 경우엔 SNS)을 마주할 수 밖에 없는데 그 복잡한 과정을 거치지 않고 책상에 앉기만 하면 일을 시작할 수 있어서 좋았다.
이제는 당연한 말이지만 인터넷만 연결되어 있으면 어디서든 일을 할 수 있다. 예전에 비해 쉽게 사용할 수 있는 수많은 협업 도구들과 분산 버전관리 도구 덕분에 적은 리소스로도 충분히 업무가 가능해졌다. 우리 회사도 대부분의 코드를 gitlab에서 관리하고 있고 구글앱스와 trello를 활용해 협업하고 있고 컨퍼런스 콜은 skype를 사용하고 있어서 큰 문제 없이 업무를 볼 수 있었다. 이제는 정말 어디서든 인터넷만 가능하면 업무 처리를 할 수 있다. 이런 기술의 발전들이 전통적인 공간 개념을 허물고 있고 원격근무의 문제점도 같이 해결하고 있다.
멜번은 임대 비용이 비싸서 여러 회사가 큰 오피스를 빌려 같이 공간을 공유해서 쓰는 경우가 꽤 많은 편이다. 우리 회사도 다른 두 회사와 함께 사무실을 공유해서 쓰고 있는데, 하나는 에너지 회사, 다른 하나는 금융 IT 회사다. 전자는 MS의 클라우드 서비스를 기반으로 모든 자료를 공유하고 있어서 잦은 출장에도 업무의 연속성을 유지하고 있고 후자는 VPN을 통해 업무 환경이 구성되어 있어 회사 직원들이 일주일에도 수 차례 시드니와 멜번을 오가며 일을 한다. 시간이 갈수록 더욱 쉽고 저렴하게 구축이 가능해진 업무 환경으로 사무실의 역할이 점점 무형적으로 변하고 있다는 점을 체감한다.
사실 사소한 차이고 아직 경험이 많지 않기 때문에 마주하게 된 일들이지만 출퇴근 할 때 딱히 고민해보지 않았던 새롭고 작은 부분들을 볼 수 있었다.
살고 있는 곳이 주택가라서 커피를 사 마실 수 있는 곳이 없었다. 처음이라 잔뜩 긴장해서 커피 없이도 하루종일 업무를 할 수 있었지만 반복되다보면 또 커피가 필요한 날이 올 것 같다. 회사 근처에 맛있는 카페에 길들여져 내 커피가 맛없다는 사실을 입이 기억하고 있어서 직접 커피를 내려 마시면 되는 일이지만 그건 또 맛이 없어서(정말 없다) 그렇게 좋은 해결책은 아니다. 겨우 하루 경험이라 은행에 다녀올 일이 없어서 그나마 다행이었지 내 주거래 은행은 커먼웰스인데 집 근처에 커먼웰스도 없다. 회사가 있는 곳들은 항상 집적되어 있기 때문에 식당, 은행 같은 편의 시설도 많이, 가까이 있기 마련이다. 한국처럼 인구밀도가 높아서 어디에서든 상가, 은행을 찾을 수 있는 상황이 아니라면 불편한 경우도 충분히 있음직 하다.
5시 반에 퇴근을 하고나서 뭘 해야할지 막막했다. 평소에는 교통 상황에 따라 퇴근이 1시간에서 1시간 반 가량 걸리는데 이 시간이 갑자기 생겨나니 어색해서 어쩔 줄 몰라하다가 동네 산책을 하고 왔다. 생각해보면 아침에 일을 시작할 때에도 은근슬쩍 침대에서 뒹굴다가 컴퓨터를 열고 업무를 시작했었다. 아침, 저녁에도 더 효율적으로 시간을 관리한다면 평소에 퇴근하고 저녁 먹고 씻고나면 잘 시간이 되서 아무 것도 할 수 없던 상황보다 훨씬 유익하게 시간을 쓸 수 있으리라 생각된다. 내게도 부양하는 가정이 있다면 아이들과 더 시간을 보내준다거나 할 수 있지 않을까. 일과 일상의 전환에 소비되는 시간을 가용적인 영역 안으로 들어오게 되면 그만큼 쓸 수 있는 시간은 늘어나는데 이번 경험에서처럼 준비되지 않으면 결국엔 출퇴근 하면서 쓰는 그런 시간들처럼 쉽게 지나가버리는데 좀 더 체계적인 계획이 필요한 것 같다.
겨우 하루의 경험으로도 이렇게 많은 차이를 느낄 수 있었는데 원격근무를 전사적으로 적용하고 있는 회사들은 어떻게 운영되고 소통하는지 궁금해졌다. 이미 실제로 많은 회사에서 원격으로 일하고 있고 그 과정을 공유하고 있다.
원격근무가 양날의 검이란 것도 맞는 말이지만 인류사에서 따져볼 때 출퇴근하게 된 기간도 얼마 되지 않으니 출퇴근의 장단점을 더 생각해봐야 하지 않을까 싶기도 하다. 그리고 원격근무를 하는가 안하는가의 문제라기보다는 재택근무를 해도 문제가 없는 업무 환경과 여건을 만들 수 있는가가 더 중요한 부분인 것 같다.