Dr. Strange가 되고픈 Hulk

안녕하세요. 둥이네 아빠입니다.

오늘 제목은 Dr. Strange가 되고픈 Hulk라고 뽑아 봤습니다.

Avengers 시리즈를 안보셨으나 조만간 정주행 하실 생각이 있으신 분들이라면, 약간의... 아주아주 약간의 영화 스포도 포함되어있음을 미리 말씀드립니다.

어느 한 도시에 헐크가 살고 있습니다.
명석한 머리와 빠른 두뇌회전으로 상대방의 약점을 찾아내어 파고드는 능력은 없지만, 타고난 괴력으로 상대방이 버티지 못할 때 까지 끊임없이 타격을 해서 물리칩니다.
상대방이 공격을 해 오더라도 크게 개의치 않습니다. 타고난 힘 만큼이나 덩치와 맷집도 좋아서 어지간히 두드려 맞더라도 그냥 힘으로 밀어부치죠.
말 그대로 만인지적이기에 어마어마한 빌런들이 나오더라도 어벤져스는 이렇게 말 합니다.

"걱정마, 우리에겐 헐크가 있자나."

나름 어벤져스 멤버인 헐크이지만, 그의 가장 근원적인 문제는 스스로 헐크의 존재를 싫어한다는 것입니다. 평소에는 헐크의 모습과는 거리가 먼 브루스 박사는 화가나면 헐크로 변해 무시무시한 괴력을 보이지만, 헐크로 변한 이후에는 피아식별이 안될 만큼 분노 조절이 잘 안되고 스마트하고 똑똑함과는 정 반대의 방법으로 전투를 합니다. 그로인해 때로는 목표는 성취했으나 주변에 어마어마한 피해를 입히기도 하고, 전투 후 분노가 가라앉아 브루스 박사로 돌아왔을 때엔 찢어진 옷가지들 덕분에 알몸이 되는 부끄러움을 감수해야만 합니다. 그래서 브루스는 자신이 헐크라는 사실이 싫고, 다른 존재가 되고 싶어합니다.

그러던 어느 날 헐크는 닥터 스트레인지를 만납니다. 딱히 힘이 세지도 않고 무술 실력이 뛰어난 것도 아니고 운동 능력이 타고나지도 않지만, 말도 안되는 신기한 재주들을 부리며 정말 마술처럼 신묘하게 적들을 물리칩니다. 또 어떤 경우에는 닥터 스트레인지 자신이 시키거나 컨트롤하지 않아도 망토가 저절로 날아가 적들의 공격을 막아내거나 적을 제압하기도 합니다. 신묘한 마법을 부리는 것 뿐 아니라 머리도 아주 좋습니다. 원래 엘리트 의사 출신이니까요. 특히 힘과 기술 그 어떤 것으로도 물리칠 수 없었던 절대 강자인 도르마무를 몰아낼 때엔 기막힌 방법으로 가능성이 없어보였던 거래를 성사시켜 지구를 구하기도 했습니다.

헐크는 그런 닥터 스트레인지가 한없이 부럽습니다. 전투 후 벌거벗을 필요 없이 항상 멋진 망토를 매고있을 수 있고, 무식하게 두드려맞으며 돌격 앞으로를 할 필요가 없이 마법의 힘으로 방패를 만들어 내어 방어하고 공간의 문을 열어 이 곳에서 저 곳으로 순식간에 이동도 가능하며, 물리적 공격으로 타격을 입히는 갓이 아니라 다양한 마법으로 적을 공격하여 무찌르기에 덜 힘들어보이고 더 멋져보입니다.

특히나 100대 맞더라도 끝까지 밀어부쳐서 한대만 때리면 그 누구든지 쓰러트릴 자신이 있었는데, 타노스와 싸우며 힘 대결에서 밀리고, 난생처음 엄청 아프게 두드려 맞은 후 저 먼 곳으로 내팽겨쳐진 이후에는 이전처럼 돌격앞으로를 하기에 겁이 나서 더욱 더 그렇습니다. 한 번 크게 겁을 먹어서인지 예전엔 분노하기 싫어도 분노해서 헐크로 변신했는데, 이제는 헐크로 변해야하는 순간이 찾아와도 좀 처럼 변하지 못합니다.

이상 제 이야기였습니다.

제가 헐크처럼 타고난 괴력이 있는 것은 아니지만, 제가 일을 하는 방식에 비슷함이 있습니다. 낙수물이 돌을 뚫듯이 주어진 문제가 있으면 끊임없이 두드려봅니다. 이것 저것 가능한 경우의 수들을 모조리 두드리다보면 최선의 수는 아니더라도 문제를 해결할 수 있는 방법 중에 하나는 찾아내죠.
하지만 저는 이러한 일하는 방식이 썩 맘에 들지 않았습니다. 남들보다 한 발 더 뛰고 더 고민해서 더 좋은 성과를 내는 것은 일종의 미래 부채를 만들어내는 일임을 알고 있었기 때문이죠. 그래도 작은 믿음이 있었다면, 이렇게 하나씩 하나씩 일을 해 나가며 제가 성장을 해서 어느 순간에는 순리대로 일을 해도 충분히 해 낼 수 있을 것이라는 생각이였습니다.

그래서 무언가 문제가 있을 때 마다, 벽을 만날 때 마다 그 벽이 부서질 때 까지 두드리고 또 두드렸습니다.

결국 어느 정도는 인정도 받았고, 덕분에 우리 네 식구가 먹고사는데 큰 문제가 없을만큼의 대접도 받고 있고요. 하지만, 제가 그렇게 무식하게 일을 한다는 것은 어떻게든 숨기고 싶어서 무언가 파고 파고 또 파고, 두드리고 두들려야 할 때에는 가능한 남들의 눈이 없는 곳에서 일을 했습니다. 나는 밤을 새어 고민을 해보고 다양한 시도 끝에 답을 찾아냈더라도, 남들에게는 순간 번뜩이는 기치를 발휘하여 멋진 마법사 같은 능력으로 문제를 해결 한 사람처럼 보이고 싶었죠. 처음에는 어느정도 저의 이러한 포장이 먹히는 듯 했지만, 아무리 숨겨도 어쩔 수 없었고 결국 제 이미지는 헐크에 가깝게 되어 버렸습니다.

비록 물리적인 시간과 많은 노력이 수반되는 업무 방식이지만, 어느정도 선 까지는 버틸 수 있었습니다. 나는 분명 오늘도 발전하고 있다는 믿음도 확고했고요.

하지만, 이제는 점점 힘에 부치기 시작합니다.

작년에 두 번이나 번아웃을 경험하기고 했고, 회사에 큰 벽이 나올 때 마다 내가 해결할 수 있다는 팀의 믿음 덕분에 저의 도메인이 아는 다른 분야의 문제들이나 모든 경우의 수를 각개격파 해 보기에는 말도안되게 어마어마한 경우의 수를 가진 문제들을 맡아 해결해야만 하기도 했습니다.

결국, 일은 성사시켜도 제 자신에게 찾아오는 데미지가 적지 않은데 지난 수년간 이렇게 받은 데미지들이 계속 누적이 되기도 했죠.

그래서일까요? 이직 후에 무언가 두각을 나타내고 싶은 욕심이 있었지만, 이제는 예전처럼 무한전진 돌파가 되지 않습니다. 무언가 달려들을 만한 꺼리가 있더라도 예전만큼 집중이 되지도 않고, 집중이 되더라도 체력적으로 힘이들어 잠깐 반짝하다 끝나서 곯아 떨어지기 일쑤입니다.

또, 예전처럼 주어진 일만 하면 끝나는 그런 위치도 아니고 다른 팀원들을 이끌기도 하고 새로운 비젼을 보여주기도 해야 하는데, 불도져 식의 업무 방식으로는 도무지 답이 안나오죠. 예전에 우려했던 미래의 부채가 이제는 정말로 찾아왔습니다.

닥터 스트레인지가 온갖 마법을 부리듯 저도 모든 일들을 auto-magically 해결하고 싶은데 현실에서 저의 법력은 부족하기 그지없으며, 이제는 끊임없이 부딛쳐 보기에는 체력적으로도 예전만큼 하기 힘든 다소 지친 헐크가 되어버렸습니다.

그나마 조금 다행인 것이라면 그 동안 불나방처럼 앞뒤 안가리고 다양한 문제들을 항해 돌진하고 부딛치면서 좀 더 많은 경험을 할 수 있었고, 그 덕분에 미미하더라도 이런저런 것 들을 경험 해 보아 기존 경험을 기반으로 해결 방법을 빨리 찾는 경우도 조금은 잦아졌습니다. 닥터 스트레인지가 도르마무를 지구에서 몰아냈을 때 처럼 획기적인 방법으로 game change는 할 수 없더라도 절대 해결 할 방법이 아닌 케이스들을 선험적으로 좀 더 많이 알기에 이전보다는 조금 덜 좌충우돌 해도 답을 찾기도 하죠.

몇 주 전에 아이들과 함께 어벤져스 엔드게임을 보고 왔습니다. 종종 회사에서 저에게 비유되었던 헐크가 이제는 헐크와 브르스라는 2 명의 분리된 자아에서 헐크의 피지컬과 브루스의 머리가 합쳐진 하나의 자아로 발전한 모습을 볼 수 있었습니다.

저도 이렇게 좀 더 나은 다음 단계로 발전하길 바라며, 오늘도 닥터 스트레인지와 같은 SW 마법사가 되기를 꿈 꿔 봅니다.

SW Developer라는 직업 - 개발자는 무슨 일을 할까?

안녕하세요.

아래 글은 제가 얼마 전에 다른 카페에 올렸던 글인데, 최근 1-2년 사이에 저에게 메일이나 행아웃 등으로 연락을 주시는 분들의 연령대가 낮아지고, 아직 개발자 커리어를 시작하기 이전에 고민을 하시면서 연락을 주시는 분들도 많아 제 블로그에도 포스팅을 합니다.

주제에는 벗어나는 이야기이지만 최근 1-2년 사이에 현재 고등학생이시거나, 대학생이신 10대 후반에서 20대 초중반이신 분들이 이민에 부쩍 관심을 가지시는게 아닌가 싶기도 합니다. 블로그를 처음 시작했던 시기만 해도 저와 비슷한 또래이거나 저보다 좀 더 형님 세대에서 연락을 많이 주셨는데, 요즘에는 오히려 30세 미만이신 분들이 더 많은 것 같네요. 미세먼지 때문인지, 아니면 좀 더 개방되고 세계화 된 환경에서 성장하셔서 더 빨리 더 넓은 곳으로 눈을 돌리시는 것인지는 모르겠지만, 요즘 메일을 보면 조금 신기하기도 합니다. 아, 어쩌면 Express Entry 이후로 나이가 차면 이민이 힘들어져서 미리 포기하시는 분들이 많아져서 그럴 수도 있겠고요.

그러면 카페에서 옮겨 온 글을 시작합니다.

===================================================================

이미 개발일을 하고 계신 분이라면 별다른 이야기도 없고 어쩌면 너무 저수준의 이야기만 풀어놓아 제 생각과 많이 다를 수도 있습니다. 하지만 어쩌겠습니까. 제가 그렇게 훌륭한 지적수준을 지니지 못했고 그냥 열심히 하는 개발자일 뿐인지라 웬만한 것은 다 단순하게 생각하고 처리하니 제 생각도 그 수준에 머물러 있는 것을요...

개발자라는 직업에 대해 생각해보면 이는 분명 전문 기술직입니다. 

일을 하기위해서는 정규교육이건 독학이건 일정 수준 이상의 학습과 경험을 갖추어야 합니다. 또한 개발자라는 직업은 지식 노동자입니다. 육체노동이라고 하면 타이핑을 하고 마우스를 컨트롤 할 때 필요한 손가락과 손목운동 정도입니다. (하지만 거북목 증후군과 터널 증후군이 빈번한 것은 비밀이에요)

그런데, 다른 지식노동 전문 기술직과는 조금 다른 것이 정규교육을 전혀 거치지 않은 사람들도 얼마든지 이 직종에 종사할 수 있으며 또 잘 할 수 있습니다. 근본적인 이론은 아무래도 학사 이상의 교육을 받는 것이 좋겠지만, 업무 자체를 처리함에 있어서는 독학으로 혼자 공부해도 별다른 무리가 없기도 합니다. 온라인에 워낙 많은 학습자료들이 있기 때문이기도 하지만, 기술 변천이 매우 빠른 분야 중 하나인지라 배운 지식을 그대로 활용하는 것 보다 더 중요한 것은 기존에 알고있는 내용을 기반으로 새로운 기술을 빨리 습득하고 활용하는 능력이기 때문이기도 합니다.

아주아주 단순하게 살기위해 노력하는 저의 머리에서는 SW 개발이라는 일을 '긴가민가의 공학' 이라고 생각합니다.

즉 true or false에 대해 계속해서 명확하게 정의하고 확인하는 과정이 무한히 반복되면서 제품이 만들어지고 작동하게 됩니다.

컴퓨터는 0과 1 외에는 아무것도 모른다는 말을 이미 들어보셨을 것입니다. 네, 양자 컴퓨터가 아직 없는 지금은 컴퓨터에서 하는 일이라고는 따지고 보면 0과 1을 처리하는 것 외에는 없습니다.  아무리 복잡한 시스템이라고 해도 이는 마찬가지입니다.

SW 공학은 다른 공학분야들에 비해 근래에 생긴 분야입니다. 그렇다보니 여기에서 만들어내는 제품들은 보통 기존 아날로그 방식의 프로세스나 물건 등을 디지털화 하여 사람보다 좀 더 빠르게 처리하도록 만들죠.

고급 개발자들은 상황이 다르겠지만, 저와같은 저랩 개발자라면 아무리 크고 복잡한 상황이라도 계속해서 단순화하고 분할하여 '긴가민가'의 논리로 모든 것을 처리할 수 있는 단계로 나누는 것만 잘해도 일을 하는데 큰 문제가 없습니다.

10년 전에 제가 했던 일을 다시한 번 떠올려 예를 들어보겠습니다.

요즘 스마트폰에서는 어떤지 모르겠는데, 예전 피쳐폰을 생각 해 보시면 지인에게 전화를 걸 때에 보통 두 가지 중에 한가지 방법으로 전화를 걸으셨을 것 같습니다.

하나는 단축 다이얼 기능으로 0-9까지 번호 중 하나를 길게 눌러서 미리 설정 해 둔 번호로 바로 전화가 걸리게 하는 것이고, 다른 하나는 일명 '초성 검색'으로 이름의 초성만을 입력하면 그 초성과 매칭되는 사람들이 리스팅 되어 사용자가 선택하여 전화를 걸 수 있게 하는 것이지요.

아, 전화번호를 그냥 통채로 외워서 전화를 걸고 계시다고요? 폰북에 들어가 ㄱ-ㅎ까지 주루룩 검색을 하신다고요? 만약 그렇다면 당신은 핸드폰 문화가 퍼지기 시작했던 90년대 말에 이미 중년에 접어드신 분들이거나, 매우 강한 아날로그 적 감성을 지닌 예외적인 분들 일 것입니다.

먼저 단축 다이얼 기능을 단순화하여 보면 이렇습니다.

핸드폰의 키패드는 매 xx millisecond마다 계속해서 사용자가 버튼을 눌렀는지 안눌렀는지 확인을 합니다.

    - 0번키 지금 눌려있니? 아니니?

    - 1번키 지금 눌려있니? 아니니?

    - 2번키 지금 눌려있니? 아니니?

     ...

예를 들어서 사용자가 1번 버튼을 누르면 눌리자마자 기계가 버튼이 눌린 것을 인식하고 동작하는 것이 아니라, 아주 짧은 시간이지만 매 xx millisecond마다 각 개별 버튼의 눌림 상태를 확인해서 눌린 것인지 아닌 것있지 알아내는 방식이지요.

버튼이 눌린 상태에서도 핸드폰은 계속해서 xx millisecond마다 각각의 버튼을 한 번 씩 돌아가면서 눌림 상태가 true인지 false인지 지속적으로 확인을 합니다.

그러다가 특정 순간에 1번 버튼의 눌림 상태가 True에서 False로 바뀌면 또 다른 긴가민가 테스트를 합니다.

    - 버튼이 눌린 후 떼어질 때 까지 시간이 1초보다 크니 아니니?

만약 1초 보다 오랜 기간동안 눌려 있었다면 이건 버튼 길게누름으로 인식을 하게되어 단축 다이얼로 동작을 하게 합니다. 만약 1초 미만으로 눌렸다면 일반 버튼 누름으로 인식을하고 단순히 화면에 1을 출력하고 끝내죠.

1초 이상 눌린 경우엔 다시 한 번 긴가민가 테스트를 진행합니다.

    - 1번 단축 다이얼이 설정이 된 적이 있는지 아닌지 긴가민가 테스트를 합니다.

기라면, 이미 등록된 번호를 가져와 전화 걸기를 합니다.

아니라면, 사용자에게 1번 단축다이얼을 등록 할 것인지 아닌지 물어보는 화면을 뿌립니다. 그리고 사용자의 입력이 Yes인지 No인지 다시 한 번 확인을 하죠.

조금은 더 복잡하지만, 한글 이름의 초성검색 기능도 따지고 보면 다 이러한 식의 긴가민가 테스트의 반복입니다. (검색속도 향상을 위해 초성들 따로 인덱싱을 하는 등의 로직이 추가되었지만, 아주아주 기본으로 보자면 그러합니다)

초성 검색은 따로 초성검색 메뉴로 들어가지 않고 그냥 전화기 메인 화면에서 숫자를 누르면 누른 숫자와 매칭되는 전화번호 검색이나 혹은 누른 숫자키에 매칭되는 한글 초성으로 검색이 됩니다.

위에 버튼 길게눌림 긴가민가 테스트를 통해 버튼 짧게 눌림을 인식했다고 가정하고...

    - 눌린 숫자와 매칭되는 한글이 자음이니 모음이니?

모음인 경우라면 이건 그냥 숫자키로 인식합니다. (중성 검색 기능은 없기에...)

이런 식의 키 입력이 지속되어 계속해서 한글 자음과 매칭되는 숫자 키가 눌렸다고 가정하면, 버튼이 눌릴 때 마다 또 이런 테스트를 합니다.

    - 지금 2글자 이상 입력을 한 것이니 아니니?

초성검색은 보통 2자 이상 입력을 할 경우에만 동작을 시작하기에 (1글자로 검색을 하려면 워낙 많은 검색 결과가 나오기에...) 이런 검사를 합니다.

만약 입력한 버튼 중에 초성과 매칭되지 않는 숫자가 섞여있다면 지금까지 입력한 숫자열은 모두 초성검색이 아닌 일반 전화번호 검색 기능으로 동작합니다. 예를들어 전화번호 뒷 4자리 검색 같은 기능 말이죠.

자, 사용자가 2글자 이상 입력을 했고, 모두 초성에 매칭되는 숫자키라면 초성검색 기능를 작동시킵니다.

초성검색을 하는 방법은 여러가지이지만, 지금은 편의상 가장 무식하지만 단순한 방법으로 설명 드립니다.

먼저 입력된 숫자키에 매칭되는 한글 자음의 조합들을 전부 만들어 냅니다.

예를들어 삼성 천지인 자판에서 4번 버튼은 ㄱ 과 ㅋ에 매칭됩니다. 그리고 5번 버튼은 ㄴ과 ㄹ에 매칭되죠.

그러면 4, 5번 버튼이 연속으로 눌렸을 경우 ㄱㄴ, ㄱㄹ, ㅋㄴ, ㅋㄹ 라는 초성의 조합이 나올 수 있습니다.

아, 쌍자음을 까먹었군요. 쌍 'ㄴ'이나 쌍 'ㄹ', 쌍 'ㅋ'은 없지만 'ㄲ'이 있으니 이 조합도 추가를 해서 ㄱㄴ, ㄱㄹ, ㅋㄴ, ㅋㄹ, ㄲㄴ, ㄲㄹ 조합이 만들어 집니다.

그 다음에는 주소록에 저장된 모든 사람의 이름들을 한 번 씩 다 확인을 합니다.

이미래

강래원

김개똥

...

이렇게 이름이 있으면 먼저 처음에 있는 '이미래' 부터 가봅니다

이미래과 이전에 만들어 둔 초성 조합인 ㄱㄴ, ㄱㄹ, ㅋㄴ, ㅋㄹ, ㄲㄴ, ㄲㄹ을 하나씩 비교 해 봅니다. 이름의 첫 글자 '이'에서 초성인 'ㅇ'을 가져옵니다.

    - 미리 만들어 둔 조합의 첫 자음과 'ㅇ'이 매칭 되니?

답은 No이니, 다른 긴가민가를 해봅니다.

    - 그 다음 이름도 있니?

그 다음에 '강래원'이 있으니 가져옵니다. 그리고 그 중 첫 글자의 초성인 'ㄱ'을 가져오죠.

    - 조합 내에 첫 글자로 'ㄱ'이 있니?

네 있습니다. 그러면 비교대상 조합군을 ㄱㄴ, ㄱㄹ, ㅋㄴ, ㅋㄹ, ㄲㄴ, ㄲㄹ 6개에서 ㄱ으로 시작하는 ㄱㄴ, ㄱㄹ 두 개로 줄여줍니다. 그리고 그 다음단계로

    - 이름에 '강'다음에 글자가 있니?

네 있죠. 그러면 그 다음 단계로 다음 글자를 가져와 그 중 초성인 'ㄹ'을 뽑아냅니다.

    - 혹시 조합 내에 두 번째 글자로 'ㄹ'이 있니?

네 조합 내에 있습니다. 축하합니다! 드디어 초성검색에 부합되는 검색결과 중 하나를 찾았습니다. 이제 이 이름은 입력한 값과 매칭되니 화면에 출력하고, 그 다음 이름을 또 가져와 하나씩 긴가민가를 해 주는 것입니다. 전화번호부의 맨 끝에 갈 때 까지요. 그렇게 하여 매칭되는 초성 조합을 가진 이름들을 모두 찾아내서 보여주는 것이지요.

이렇게 SW라는 것은 사실상 "긴가민가 테스트"를 주어진 목록과 상황 상에서 "반복" 하는 방식으로 이루어져 있습니다.

별 것 아닌 것 같지만 의외로 이련 일을 하면서 자주하는 실수로는....

첫 번째 글자 비교를 완료했으니 그 다음 글자로 넘어가야하는데, 실수로 같은 글자를 반복 비교한다거나, 이름의 첫번째 글자 자음과 만들어 둔 조합의 두번째 자음을 비교하여 매칭한다거나 식의 실수가 자주 발생하기도 합니다.

혹은, '강래원' 이름은 세 글자이지만 입력한 숫자는 2글자 뿐이기에 앞 두글자만 비교를 하고 넘어가야 하는데, 구지 세번째 글자를 비교하려고 덤비는 경우도 있지요. '원'의 'ㅇ'과 아무런 값도 없는 것 간의 비교를 하는 것이지요. 이 경우에는 비교 방식에따라, 사용하는 프로그램 언어에 따라 폰이 재부팅 될 수도 있고, 그냥 강래원은 4, 5번키 입력에 맞지 않는 것이라고 치부하고 넘어 갈 수도 있고, 아니면 잘못해서 비교를 했지만 또 잘못해서 비교한 것이 맞다고 하여 2중 오류로 최종 결과는 강래원은 4, 5번 키와 맞는 이름이라고 올바른 답을 찾을 수도 있습니다.

SW가 이세돌 9단을 바둑으로 이기기도 하고, 처음 가는 길이라도 막히지 않는 구간으로 잘 찾아 최적 구간의 길을 찾아주기도 하는 등 참으로 복잡한 일을 하는 것 같지만, 복잡한 것은 최종 완성된 제품일 뿐 세분화 하여 나눠놓고 따지고 들어가면 각각의 논리 구성은 이와같이 긴가민가 테스트를 각각 주어진 조건과 환경에 맞게 지속적으로 반복을 하는 작업입니다.

그렇다보니 복잡한 세상을 잘게 쪼개서 아주아주 단순하게 생각하는 능력이 좋다면 전문적인 고등교육을 받지 않아도 얼마든지 혼자서 할 수도 있는 일이기도 하죠. 공학이라고는 하지만 다른 공학과는 달리 높은 수준의 수학적 지식을 필요로하기 보다는 Yes/No의 논리연산에 대한 능력이 더 필요합니다. 

여기에서 오는 작은 문제가 하나 있는데, 아직 실무를 경험 해 보지 못한 학생들의 경우 1,2학년 때에는 과연 내가 배우는 것으로, 지금까지 배운 것으로 뭘 만들어 볼 수나 있으려나? 맨날 숫자 비교나 하고, 글자 비교나 하고, 그거 반복하고... 아주아주 단순한 것 밖에 만들지 못하는데, 내가 뭘 할 수 있으려나? 졸업하면 일이나 할 수 있으러냐? 코업 나가면 일이나 할 수 있으려나? 걱정을 많이 하기도 합니다.

벌써 20여년 전인데... 저도 예전에 대학생 때 그랬습니다. 학교에서 이것저것 많이 배우기도 했고, 또 혼자서 학교에서 가르치지 않는 다른 기술들도 공부하고 연습 해 보기는, 매냥 하는건 긴가민가의 반복만 하는데 어떻게 엑셀같은 프로그램을 만들고, 어떻게 핸드폰을 만들 수 있는지 도무지 감이 오지 않았죠.

하지만 엑셀이건 핸드폰이건 너무 큰 숲만 봐서 그런 것이고 그것들도 다 잘게 잘라서 보면 이렇게 지금까지 배운 것들 위주로만 구현이 된 것이니 혹 지금 SW 공학 전공을 하시는 학생들이 있다면 너무 걱정하지 말라고 이야기 해주고 싶습니다. 대신, 큰 숲을 작은 나무와 작은 나무에서도 각각의 나뭇잎 한장 한장으로 잘게 쪼개서 볼 수 있는 능력을 키워야 합니다. 자기가 배운 단순한 기술들을 조합해서 무언가 소소하게나마 의미있는 제품으로 만들어 내는 훈련을 해야합니다. 이런건 학교에서 잘 가르쳐주는 것도 아니고 가르쳐준다고 다 아는 것도 아니기에 혼자서 이것저것 많이 해보는 것이 좋지요.

추가로 말씀드리자면 사실 위에 예제는 실제 핸드폰에 구현된 코드 구조와는 사뭇 다릅니다. 앞서 말씀드린 것 처럼 구현할 수 있는 수 많은 선택지 중 가장 단순한 방법을 말씀드린 것입니다. 보통은 이런 식으로 검색을 할 경우 검색 속도의 문제가 있기에 사전에 초성 인덱싱을 미리 하는 방법등 다른 방법 등을 쓰지요. 예를들어 '김개똥'이라는 이름을 저장할 때에 초성 검색시 매칭되는 숫자 키인 '4, 4, 6'이라는 키 조합을 미리 찾아서 '김개똥'이라는 이름과 함께 저장하는 것 같은 방식이 그 중 하나라고 할 수 있습니다.

이렇게 하면 사용자가 버튼을 누를 때 마다 모든 조합을 다 찾아내고 각 조합마다 계속해서 비교하는 등의 반복된 작업을 하지 않고 사용자가 입력한 숫자키의 배열이 '4, 4, 6'과 매칭되는지의 여부만 확인하면 되니 훨씬 더 빨리 검색 결과를 얻을 수도 있죠.

이렇게 인덱싱을 하는 방법을 연구하여 남들보다 빨리, 효율적으로 검색하는 것을 찾아내는 것이 SW 개발자라는 직업을 단순 기술직이 아닌 지식 노동자로 만듭니다. 단순하게 계속해서 Yes No만 반복하다보면 아무리 빠른 컴퓨터라고 해도 입력된 데이터가 많아질 수록 점점 느려질 수 밖에 없는데, 아주아주 작고 보잘것 없는 아이디어 같지만, 전화번호를 저장할 때에 작은 계산만 하나 미리 해서 실제 사용 시에 반응속도를 향상시키는 것이지요.

또 이러한 새로운 방식으로 검색을 하지 않는다 하여도 앞서 했던 긴가민가 테스트들의 순서나 이를 반복하는 순서만 바꾸어도 성능에 큰 영향을 주기도 합니다.

제가 예전에 대학생때 후배들에게 세미나를 하면서 한 적이 있는 말인데, 만원짜리 한장과 천원짜리 한 장이 있을 때, 사람 세계에서는 어떻게하건 11,000원이지만, 컴퓨터 세상에서는 만원짜리가 앞에오고 천원 짜리가 나중에 올 경우 만 천원이지만, 천원이 앞에오고 만원이 나중에오면 천만원이 되기도 합니다.

컴퓨터 공학의 시초는 사실 수학인지라, 정말 고성능에 뛰어난 연산이 필요한 제품을 만들기 위해서는 수학적인 지식과 다양한 수학 공식들의 활용/적용 능력이 필요하기도 합니다. 하지만 저처럼 저랩 개발자들의 경우 그런거 별로 필요 없습니다. 복잡한 실제의 인간 세상을 단순화해서 네/아니요의 구조로 잘게 자를 수 있고, 계속해서 무한 반복되는 긴가민가에서 내가 확인해야 하는게 기인 것인지 아닌 것인지 헷갈리지 않을 능력만 있으면 적어도 저처럼 밥벌어 먹고 살 수는 있습니다. (그런데 종종 긴가민가의 숲에서 길을 잃고 헤메기도 합니다 ㅠㅠ)

혹시나 이쪽 분야에 새로 커리어를 시작을 고민하시는 분들이나, 전공 고민을 하시는 분들께서 만약에 제 글을 읽고 뻘써부터 머리에 쥐가나기 시작한다면 어쩌면 이 분야가 적성에 맞지 않는 것일 수 있습니다. (아니면 제 필력이 형편없어서 읽기 힘들어서 그럴 수도 있고요)

어찌되었건 저의 개똥같은 작은 생각이 고민하시는 분들께 조금이라도 도움이 될 까 싶어 몇 자 적어봅니다.

영어의 벽과 이메일

안녕하세요.

오늘은 영어와 이메일 작성에 대한 저의 이야기를 적어볼까 합니다.

한국 회사에서라도 해외 법인이나 고객, 혹은 외국인 동료와 같이 일을 해보신 분들은 아마 잘 아실 것입니다. 한국인과 함께 일을 할 때에는 이메일이나 메신져로 업무를 하는 것 보다 직접 만나서 이야기를 하거나 전화를 하는 것이 가장 빠르고 정확하고 편리하지만, 영어로 일을해야하는 상황에서는 조금 달라집니다.

영어실력에 따라 개인차가 있을 수 있지만, 저도 그렇고 제 주변에 다른 분들도 대부분 가장 두려운 것은 전화통화이며, 그 중에서도 단연 백미는 흔히 다양한 목소리들이 겹치는 상황도 발생하는 Conference Call입니다. 그 다음 기피대상은 메신져를 통한 업무이며, 그 다음으로는 화상통화, 직접 대화, 이메일의 순서입니다. 

전 저 같은 경우 영어를 잘 하지도 못하고, 체계적으로 공부를 한 적도 없다보니 상대방과 영어로 대화를 할 때에는 적어도 20% 정도는 알아듣지 못합니다. 그러니 '말' 이라는 소리 컨텐츠만 순수하게 해석하여 대화를 한다면 최소 20% 정도의 내용은 놓치게 되고, 제가 놓친 컨텐츠가 흐름상 매우 중요한 뜻일 경우 이후 오가는 대화 내용 전체를 이해하지 못하는 상황이 오기도 합니다.

하지만 똑같은 대화라 하여도 직접 만나서 하게되는 경우, 상대의 표정이나 제스쳐, 그리고 서로 대화를 주고받는 장소에서 느끼는 직감이라고 할까요? 제 5의 감각 등에 의해 제가 놓친 소리가 있다 하여도 대략적으로 그 대화의 흐름을 놓치지 않고 잡아나갈 수 있죠. 이는 일상 대화에서는 잘 적용되지 않지만 대화의 내용과 주제가 한정적인 비지니스 대화에서는 거의 대부분 적용됩니다.

화상통화를 하는 경우에는 이 제 5의 감각이 제한받게 됩니다. 또한 '말' 이라는 컨텐츠의 전달 채널인 소리가 실제 대면을 할 때 만큼 깔끔하게 전달되지 않으며, 표정/제스쳐가 전달되는 채널인 '화면'은 제한된 프레임을 통해서만 제공되기에 실제로 만났을 때 만큼 생생하게 그 것을 캐치해 내지는 못합니다.

그리고 이것이 전화가 되면, 오직 청각세포에만 의존하여 모든 컨텐츠들을 캐치 해 내어야만 하게 되기에 여간 스트레스가 아닙니다. 실제로 저 정도의 영어실력에서는 20%를 놓치면 전체 대화에서 맥을 완전히 잘못 짚어내기도 하고, 이해를 못하기도 하다보니 전화통화를 할 경우 온 우주의 기운을 제 달팽이 관에 집중해야 하지요. 그나마 비지니스 대화의 경우 사전에 Agenda가 조율 된 상태에서 전화 연결이 되어 일부 놓치는 것이 있더라도 대화 주제와 내용이 한정되어 있기에 빨라 따라잡을 수 있어서 상대적으로 용이하지만 직장 동료가 갑자기 전화해서 무언가 이야기를 하는 경우에는 너무나 어렵습니다.

메신져의 경우에는 전화통화와 같이 실시간성이 있지만 약간의 지연이 있는 실시간 대화이기에 조금은 부담이 덜합니다. 모르는 단어가 나오면 재빨리 온라인 사전을 통해 확인을 할 수도 있고요. 하지만 역시나 빠른 응답이 필요한데다, 글을 써야 한다는 점에서 어려움이 있습니다. 조금은 어눌하거나 틀린 발음일 수 있지만 말로는 할 수 있는데, 이것을 글로 옮겨 적으려면 철자를 모르는 단어들이 상당히 많기 때문이죠.

마지막으로 이메일은 상당히 귀찮은 일이지만 가장 부담은 덜합니다. 아무래도 시간적 여유가 가장 많은 채널이다보니 천천히 글을 작성하고 두번 세번 다시 검토하고 내용을 고칠 수 있기 때문입니다.

이렇게 항상 언어의 벽을 느끼고 살다보니 영어에 대한 부담이 늘 뒤따릅니다.
지금은 제가 팀을 옮겼지만, 이전 팀에서 매니져가 저에게 항상 영어공부를 좀 하라는 말을 하며 자신이 캐나다에 처음 이민왔을 때 어떤 방식으로 영어 공부했는지를 알려주며 이것저것 추천을 하기도 했습니다. 업무 관련해서는 이전 매니져와 별다른 트러블이 없었지만, 1:1 개인 면담을 할 때 마다 항상 영어 공부를 하라는 이야기를 해서 이에대한 스트레스가 이만저만이 아니였습니다.

올해 초에  DevOps로 팀을 옮기면서도 한가지 마음에 걸리는 것이 있었는데, 그것 역시 영어였습니다. 팀 특성상 다른 개발팀들과 소통이 빈번할 수 밖에 없고, 또한 매우 중요한 부분 중 하나이기 때문이였습니다. 하지만 아이러니하게도 DevOps로 옮긴 이후에 종종 듣는 이야기는 제가 커뮤니케이션을 아주 잘한다는 말입니다. 팀을 옮기면서 따로 영어공부를 한 것도 아니고, 영어 실력이 갑자기 일취월장 한 것도 아닌데, 영어공부가 필요하다는 평가에서 커뮤니케이션을 잘한다는 평가로 바뀐 이유는 바로 소통 채녈의 변화가 큰 요인이 아닐까 생각합니다.

개발팀의 일원으로 일을 할 때에는 사실 사전 조율된 미팅이나, 이메일을 통한 공문 형태의 커뮤니케이션이 극히 드물었습니다. 주로 전화나 메신져, 혹은 그 자리에서 바로 대면 커뮤니케이션이 시작됩니다. 그렇다보니 대화의 내용이나 주제를 제가 미리 예측할 수 없고 그런만큼 듣기에 집중을 해야하며 말할 때에도 더 많은 생각을 거치게 됩니다.

하지만 DevOps에서는 공식적으로 대외 커뮤니케이션을 하는 일이 더 빈번하지만, 이메일을 통한 공지, 혹은 외부 요구사항/요청사항에 대한 대응이 그 주를 이루다보니 커뮤니케이션을 할 때에 제가 혼자만의 시간을 상대적으로 충분히 가질 수 있었고, 그런만큼 메일을 작성하거나 요청 메일에 응대를 할 때, 어떤 이야기를 할지 충분히 생각하여 작성을 하고, 작성 후에도 다시 한 번 읽어보며 수정 할 시간이 있으며, 문법의 벽에 걸려 생각이 충분히 전달되지 않는다고 느낄 시에는 스크린 캡쳐나 코드 캡쳐 혹은 flow chart 등 Visual Aids를 작성할 수도 있었습니다. 또한, 저의 필력과 영어실력, 그리고 문법이 부족하다보니 서술형으로 설명하기 보다는 최대한 bullet point로 간략화하여 설명하고, 필요시 세부적인 설명에 대해서는 주석을 통해 전달합니다.

이러한 노력들로인해 공문을 보내거나 공식적으로 온 요청에 대해 회신을 하는 메일을 작성할 때 상당한 시간 투자가 요구되기는 하지만, 성급하게 조금 잘못된 빠른 커뮤니케이션을 하는 것 보다 약간은 지연이 되더라도 오해의 여지를 남겨두지 않는 커뮤니케이션을 하는 것이 상호간 시간을 더 아낄 수 있다는 것을 이전에 경험으로 배웠거든요. 특히나 영어로 커뮤니케이션을 할 경우에 말이죠. 그래서 한글로 된 메일이나 글을 작성 할 때에는 그냥 의식의 흐름에 모든 것을 맡겨두고 줄줄줄 작성한 후에 마지막 검토라고는 수신인 리스트와 첨부파일 여부정도만 하지만, 영문 메일을 작성 할 때에는 일부러 시간을 투자하여 각종 Visual Aids도 만들고, 두세 번 다시 읽어보며 부족한 영어실력에 말도안되게 장문으로 작성된 내용은 여러 문장으로 다시 잘게 쪼개고, 그래도 스스로 자신이 없으면 bullet point로 바꾸고, 중요 내용이나 키워드에는 Bold체와 Italic체를 섞어주고 Underline이나 폰트 색을 바꿔가며 조금 틀린 문법이라도 누구나 쉽게 알아볼 수 있도록 바꾸고 또 바꿔서 보냅니다.

후회되는 과거라 할 지라도 무엇이건 결국 자신에게 도움이 된다는 제 아내의 말이 다시금 생각나는 대목인데, 한국에서 기술영업, 기획, 수출팀에서 근무 한 경험이 도움이 되더군요. 일단 기획, 기술영업을 하면서 하루에서 몇 개씩 Presentation 자료들을 만들면서 훌륭한 미적 감각을 지닌 도형을 만들어내지는 못해도 PPT나 OneNote 등을 이용해 최대한 핵심을 간추린 챠트나 도형을 만들어내는 기술을 몸으로 익혔고, 해외 사업자나 법인들과 커뮤니케이션 하면서 문장형 이메일 보다는 눈에 들어오기 쉬운 Bullet Point형 메일을 작성하는 것 또한 경험을 통해 몸에 익혔는데, 이러한 경험들이 지금 이렇게 도움이 되더군요.

또한 간혹 Thank you letter나 요청/요구를 빙자한 메일 중에는 은근히 우리 팀을 공개적으로 까면서 개선을 촉구하는 메일들이 있기도 한데, 이 경우에도 공돌이가 아닌 분야의 경험이 도움이 되었습니다.

만약 공개적으로 까는 것이라 할 지라도 정말로 우리의 잘못이라거나, 우리가 인지하고는 있지만 일단 받아들이고 넘어간 technical debt인 경우에는 지체없이 Sorry 를 날립니다. 혹자는 북미 문화에서 Sorry를 남발할 경우 자신의 가치가 깎이는 것이고 다른 이들이 자신을 우습게 여기는 길이기에 가능한 sorry라는 말을 하지 않는 것이 좋다고 하기도 합니다.
예를들어

"Sorry for the inconvenience." -> "Thank you for your patience and understanding."

이런 식으로 돌려서 말을 하는 것이 좋다는 것이지요.

하지만 제 성격의 문제인지, 그냥 습관인지는 몰라도 이런 문장 작성을 쉽게 받아들이지 못하기에 그냥 기존 습관대로 Sorry를 날립니다. 다행히도 아직까지 저를 우습게 여기는 사람은 없는 것 같기도 하고요.

하지만 이렇게 다른 메시지를 빙자하여 돌려까기를 하는 정치적인 메일을 보내는 사람들의 경우 열에 여섯 일곱은 근본적인 잘못과 오류가 자신에게 있기에 이를 덮고 우리쪽 잘못으로 물타기를 하기 위해 보내는 경우가 많이 있습니다. 이런 케이스에도 역시 한국에서 개발을 떠나 근무했던 경험들이 도움이 되었습니다.

제 경험상 이런 정도의 메일을 보내는 사람이라면 상당한 전투력을 이미 가지고 있거나 이미 코너에 몰린 상황이라 뭐든 보이면 다 물고 뜯을 자세가 되이있는 경우인지라, 만에하나 나의 잘못이 정말로 하나도 없는 상황이라고 해도 이성적/논리적/이론적/기술적으로 시시비비를 가리려들면 영어도 딸리고, 언어적 기술도 부족한 제가 공개적으로 넉다운 될 가능성이 매우 높으며, 아무리 잘 싸워봐야 양쪽 모두 거지꼴이 되는 진흙탕 싸움이 되기 십상입니다.

그래서 이런 메일에도 영혼은 없지만 일단 Sorry를 날립니다. 하지만 단순한 사과 레터가 아닌 약간의 정치적인 메시지를 섞어서 보냅니다.
정치적인 메시지란 여러가지 케이스들이 있을텐데, 예를들면 이렇습니다.
사과를 하고, 시비를 건 당사자의 실수나 오류에대해서는 직접적인 언급을 최대한 자제합니다. 대신, 그들이 범하고 있는 큰 실수나 오류, 혹은 그들 제품의 문제점을 보여 줄 수 있는 실측 데이터를 첨부하고 메일을 주의깊게 읽을 경우 그들의 잘못이라는 것을 해석 할 만한 다른 비교 데이터, 혹은 데이터에 대한 해석 등을 추가합니다.

정말 정치질을 잘하는 사람들의 경우 이런 정치적인 답장을 받으면 그냥 거기에서 싸움을 중단하고 자신의 단점을 감추기 위해 공격할 다른 쉬운 대상을 찾습니다. 정치질과는 보통 무관하더라도 제 메일의 뜻을 이해 할 만한 사람이라면 자신의 내재적 문제점에 대해 자각하고 더 이상 저희 쪽을 물어뜯지는 않죠.
제 레터를 그냥 말 그대로 사과의 뜻으로 받아들이는 경우도 있기는 한데, 이 경우에는 정말 답이 없습니다. 적당한 무시와 함께 저 역시 본격적인 반격을 할 수 밖에 없는데, 이러한 본격적인 반격은 제가 아니더라도 팀 내에 대부분의 개발자들이 아주 좋아하는 Technical debate인지라 영어가 딸리는 제가 빠져도 다른 동료들이 주저없이 콜로세움으로 뛰어들기에 제 입장에서 더 이상 부담 될 일은 없죠.

이렇다보니 저는 "매니징"을 하는게 싫고 "개발"을 하는게 좋아서 캐나다 이민까지 왔는데, 회사에서 매니져 롤에 대해 저에게 말을 꺼내게 되는 상황을 맞이하기도 했네요.
만약 제가 더 나이가 들어서 정말로 제 머리와 체력으로는 기술을 따라가기 어렵게 되었고, 이메일 뿐 아니라 말하기와 듣기도 잘하게 된 상황이라면 고려 할 수도 있는 제안이겠지만, 지금 저의 열정과 영어실력을 고려하면 전혀 고려할 대상이 아니지요.
또, 지금 이메일을 비교적 잘 쓰고는 있다지만 공식적인 이메일 커뮤니케이션을 밥먹듯 해야하는 상황이라면 지금과 같이 한타 한타 공들여서 이메일을 작성할 수도 없기에 저의 미천한 영어실력과 필력, 부족한 지식과 얕은 안목이 금방 드러날 수 밖에 없기에, 딱 지금 수준이 적당한 것 같습니다.

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

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

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

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

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

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

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

  05시 기상

  05시 30분 헬스장

  07시 30분 출근

  08시 근무시작

  15-17시 퇴근

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

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

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

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

  05시 50분 기상

  06시 20-30분 출근

   07시 근무시작

  16-22시 퇴근

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

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

돈 때문일까요?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

가끔 한국이 그리울때?

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

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

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

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

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

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

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

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

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

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

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

Salary Negotiation 준비편 - 올해의 업무 실적 정리 2편

안녕하세요.

오늘은 지난 포스팅에 이어서, 올해 연봉 협상시 사용한 주요 실적 중 세번째 내용을 적어볼까 합니다.

사실 이 성과는 6월에 발생한 건으로 이번 연봉 협상에 제 실적으로 반영이 될 내용은 아니기에, 본인 스스로 작성하는 self evaluation에는 그 내용을 직접 언급하지는 못했습니다.

하지만 사람이라는 동물의 기억과 느낌은 아무래도 최근의 이벤트들이 좀 더 강렬하게 다가올 수 밖에 없습니다. 마치 연초 흥행작보다 연말 흥행작이 대종상이나 아카데미 시상식에 더 큰 영향력을 미치는 것 처럼 말이죠. 그래서 제 스스로 문서상 기술을 하지는 않았지만 협상 과정에서 몇 번 언급은 될 수 밖에 없었고 연봉 결정에 영향을 주었습니다.

6월 어느 날, 지난 삼성 이슈에서 같이 일했던 OEM Relationship 담당자로부터 전화가 와서 이런 저런 이야기들을 했습니다. 주요 내용은 보안 이슈 때문에 MDM App의 인증 과정 중 크리티컬 한 프로세스 하나가 긴급히 변경 될 것이고, 변경될 모델 범위는 러프하게 잡아도 Galaxy S3 이후 모든 단말이 될 것이라는 소식이였죠. 그리고 올 해 8월부터 시작될 펌웨어 변경 이후에는 기존 당사의 MDM 앱들은 업데이트 된 단말에서 사용 불가능하기에 재 발행을 해야 한다는 소식이였습니다.

매우 중요한 이슈이고, 저희 같은 B2B 서비스 회사 입장에서는 5년 전 SW 버젼을 아직도 사용하고 있는 고객들도 있는 상황이기에 광범위하고 긴급하게 대응을 할 필요가 있었습니다.

재발행 하는 것이 큰 문제가 아닐 수도 있다고 생각 할 수도 있지만, 사실 그간 저희 빌드 머신이 수차례 변경을 거치면서 솔직한 말로 3년 이전의 SW들을 현 머신에서 이전과 동일하게 빌드 할 수 있는지에 대한 자신도 없었고, 수백개의 버젼들을 8월까지 재 검증을 하기에도 역시나 물리적인 시간이 촉박하기도 했으며, 삼성 펌웨어 업그레이드 이후 동작 상황에 대한 검증과 펌웨어 업글 이전에 우리의 사전대응으로 인한 새로 발행된 동일 버젼이 업글 이전 단말에서 동작이 어떻게 될 지에 대해서도 미지수였습니다.

삼성 입장에서 보안상 이슈로 상세한 이야기를 다 풀어놓지 못 한 것은 이해할 수 있었지만, 파트너사의 입장에서는 대응 방안을 만들기 위해 무엇이 어떻게 변경되는 것인지에 대해 알아야만 하는데, 이를 알지 못해 오리무중에 빠진 안타까운 상황이였죠.

이슈 자체가 크리티컬 한 만큼, 당장 CEO 포함 주요 개발/검증 담당자에게 삼성의 공문을 첨부한 메일이 날아갔고, 각 시니어 개발자들은 문서 + 추정을 통한 분석을 내놓기 바빴습니다.

저는 여기서 다시 한 번 삼성에서 배운 기술을 써 먹었습니다.

개발을 떠나 서비스 기획을 담당하면서 스스로 느낀 것은, 내가 무엇인가 알아야 할 신규 분야나 서비스가 있을 경우, 문서로 모든 것을 이해하기 보다는 단 한 번이라도 직접 써봐야 한다는 것이였습니다.

 09년, 처음 개발에서 기획으로 직군을 옮기고 나서, SNS라는 것이 너무나도 생소 하고, 주변에 사용자가 아무도 없을 때, 페북이나 트위터, MySpace, LinkedIn 계정을 만들고 부서 사람들 끼리 각 SNS 채널을 통해 이런 저런 이야기들을 주고 받으면서 블로그나, 싸이월드 등과는 어떻게 다르고 이 기능들을 어떻게 폰과 잘 어우러지게 할 수 있을지 연구 했었습니다.

 애플의 iTunes 서비스나, Netflix, Hulu, Spotify를 연구 할 때에도 구글링이나 컨설팅 자료만을 찾아보지 않고, 회사에서 별도의 지원은 없었지만 제 개인 해외 계정을 만들고 해외 VPN 서비스를 구매해서 직접 이런 저런 컨텐츠들을 구입해보고 이용 해 보면서 어떠한 장점과 단점들이 있고 우리는 어떻게 서비스를 하는 것이 바람직한지 이용해 보았습니다.

 그래야 나중에 고객이나 파트너사 미팅 시 실제 서비스를 이용하고있는 그들이 어떤 질문을 할 것인지 미리 예측할 수 있고, 또 대응할 수 있었기 때문이죠.

그래서 저는 우선 공문 내용과 각 시니어들의 의견들을 먼저 읽어 본 후에, 삼성에서 보내온 샘플 app 패키지들을 직접 단말에 설치해 보기도 하고, 패키지 압축을 풀어서 파일들을 하나하나 비교해 보기도 하고, 바이너리 파일 비교, jar 파일 리버스 엔지니어링 등 제가 할 수 있는 선에서 최대한의 비교에 들어갔습니다.

그렇게 비교를 해 보니 어느정도 답이 보였습니다.

그 날 저녁 퇴근 전에 현재까지 상황에 대한 내부 공유를 위해 메일로 제 분석 내용을 돌렸습니다. 그리고 제가 더 이상 접근할 수 없어 알지 못하는 궁금증들에 대해 다시 한 번 '한국어 네이티브'라는 강점을 살려 한국에 전화하여 물어보기 시작 했습니다. 기획 일을 하면서 개발팀 책임/수석님들과 어떻게 일을 해야 할 지 종종 경험을 해 보았기에 삼성의 보안사항을 제외하고 기술적으로 어떤 변경이 있는지에 대해 좀 더 상세하게 알 수 있었죠.

밤 늦은 시간 수 차례 통화를 마친 후 잠자리에 들기 전에 제가 알게 된 내용들을 정리 해 보니, 우리 입장에서 현재 서비스에 어떤 영향이 있을 수 있는지, 그리고 각 영향 별로 어떤 대응방안 옵션들이 있는지, 그리고 각 옵션들의 장단점은 무었인지 얼추 그림이 잡혔습니다.

그래서 다음 날 아침 회사에 도착하자마자 삼성에서 기획할 때 했던대로, 표를 작성하기 시작했습니다.

무엇이 변경되었고, 각 변경사항 마다, 우리의 각 MDM 버젼별로 어떤 영향을 주는지를 적었고, 다음 열에는 각 영향들 마다 우리는 어떤 대응 옵션들이 있는지를 적고, 다시 그 다음 열에는 각 대응 옵션들 마다 장점과 단점은 무었인지 적었고, 마지막으로 제 개인적인 의견상 어떤 옵션이 더 바람직한 것인지를 기술 했습니다.

사실 튀기 위해서 이렇게 분석을 하고 메일을 작성한 것은 아니였고, 아무래도 수 년간 삼성에서 익혔던 근무 방식이 아직 남아있었기에 나도 모르게 한 것 같습니다. 그런데 지난번과 마찬가지로 의외로 반응이 좋았습니다. 가장 크리티컬했던 반응은, CEO의 땡큐 레터였습니다. CEO는 땡큐 레터를 작성하면서 원래 mail thread에 없었던, 개발팀 시니어 메니져를 포함 시키더군요. 사실 제 팀 개발 매니져가 저의 연봉을 산정하여 상신을 하지만, 최종 결정은 개발팀의 시니어 매니져가 HR에서 사전에 정한 개발팀 내 총 샐러리캡과 가이드 내에서 결정을 하게 됩니다.

시니어 매니져가 담당하는 업무 영역이 안드로이드와는 크게 관련있지 않은 편이였고, 저와 직접적으로 같이 일 한 적 또한 없었죠. 그렇기에, 저와 메니져간 협의로 다시 한 번 조정된 연봉에 대해 시니어 매니져가 거절을 하거나, 2차/3차 조정이라는 단계를 거칠 수도 있었지만, 이 사건을 통해 시니어 매니져의 머리 속에 제 이름 역시 남기게 되어, 이번 연봉 협상에서 저와 제 직속 매니져간 협의된 결과에 대해 단칼에 승인을 하는 쿨함을 보여 주었습니다.

사실 직접 써보고 만져보고 느껴야 한다는 것은 문서 자체나, 영어로 작성된 웹 상의 다양한 컨텐츠들에 대한 이해도 부족과, 그렇게 글로 배운 'OOO'은 제 머릿 속에 잘 저장되어 남아있지 않아 시작하게 된 버릇입니다. 하지만 수 년이 지난 지금, 이렇게 제 삶에 도움을 주는군요.

제가 개발을 떠나 적성에 맞지 않는 커리어로 너무나 큰 고민과 고뇌에 빠져있을 때, 제 와이프가 저에게 해 준 말이 있습니다.

"싫은 일을 하기 보다는 좋아하는 일을 해. 돈은 나만 벌어도 되니까 벤쳐를 가건 중소기업을 가건 하고 싶은 일을 해. 하지만 지금 이 일이 너무 가치없다고는 생각하지는 마. 사람이 하는 모든 경험은 어떻게든 도움이 되기 마련이야."

당시에는 제가 하는 일이 너무나 적성에 맞지 않는다고 생각하여 모든 일 하나하나가 가치없고 그저 힘들기만 하다고 느꼈기에, "하고 싶은 일을 해" 부분을 제외하면 와이프의 조언을 크게 귀담아 듣지 않았지만, 지나고 보니 와이프의 말이 모두 맞았습니다.

자의건 타의건 당시에 갖게 된 '문서로만 배우지 말아라' 라는 습관과 비교/분석 표 작성, 그리고 자료를 바탕으로 한 의견 개진의 기술은 역시나 수 년이 지난 후 캐나다에서 빛을 발휘했습니다.

결국 모토로라와 삼성 x 2, 이 세 가지 이슈 덕분에 올 해 연봉협상은 순조롭게 마무리 되었습니다.

그리고 연봉 협상이 끝난 후 매니져가 내년에 저에게는 새로운 기술과 방법을 리드하는 롤을 기대한다며, 상품화 가능한 많은 의견과 기술들을 소개하기 위해 노력 해 보고, 서버 개발쪽에서도 올해 안드로이드에서 한 것과 동등한 수준의 역량을 기대 한다는 말을 하더군요.

올 한 해 이 세 건의 사건 해결로 인해 올라간 저의 연봉 만큼이나 저에대한 회사의 기대치 역시 높여 놓았습니다.

내년 연봉 협상의 전략과 카드에 대해 다시 한 번 진지한 고민이 필요하다는 부담감이 있기는 하지만, 일단 2 주간의 휴가 기간 동안에는 이번에 마무리 된 성과 평가 및 연봉 협상 결과의 기쁨을 만끽하려 합니다.

Salary Negotiation 준비편 - 올해의 업무 실적 정리 1편

이민을 결정하고나서 제가 세운 단기 목표 중 직업과 관련된 주요 목표들은 다음과 같았습니다.

1) 1년 내에 최소한 개발자 은퇴하기 직전의 감과 실력을 되찾기

2) 2015년도 내에 SW 개발자로 취업하기

3) 취업 후 3년 내에 연봉 10만불 만들기

1번 목표의 경우 아직 잘 모르겠습니다.

전에 하지 않던 자바를 하며 새로운 기술도 많이 익혔지만, 이전에 비교적 이해도가 높았던 커널쪽이나 C/ASM쪽은 완전 잊은 상태인데다, SW 기본 이론중 상당 부분 역시 잊혀진지 오래 되었거든요.

2번은 정말 운이 좋게도 구직활동을 시작 하자마자 구직이 되서 의외로 손쉽게 달성 했습니다.

그리고 마지막으로 남은 세 번째 단기 목표, 모든 직장인들의 궁극의 목적인... 연!봉!

작년에 한 차례 연봉 조정을 거치기는 했으나, 제 스스로도 자신감과 준비가 부족했던 터라, 회사에서 제시한 조건을 단 일초의 망설임도 없이 덥석 물어버렸죠. 사실 제가 거부하고 버티고 협상을 돌입하기도 애매했던 것이 당시 저는 회사에 입사한지 반년밖에 안된 상태로, 회사 규정상 연봉 조정 대상자가 아니였습니다. *이전글 참고

그래도 당시의 제 연봉 인상은 제 스스로에게는 상당히 고무적이였습니다.

제 경험을 토대로 말하기엔 제 경험이 너무 미천하여 마치 100일 휴가를 나온 신병이 아직 군대 안 간 친구들에게 군대란 어떤 곳인지 이야기를 하는 것일테지만, 제가 듣고 읽은 바에 의하면 북미 기업문화에서 물가상승률 이상의 연봉 인상은 포지션 변경 시 외에는 없다고 알고 있고, 그래서 2~3년마다 잦은 이직을 하는 이유 중 큰 요인이 연봉 인상을 위해서라고 알고 있습니다.

그래서 처음 입사를 하고, 3개월 probationary period를 무사히 마친 다음부터는 세 번째 목표 달성을 위해 매 1년마다 이직을 해야겠다는 생각을 가지고 있었는데, 회사에서 먼저 연봉을 조정해 주는 것을보고, 유랑단 생활을 하지 않고도 목표를 달성할 수도 있을것 같다는 생각을 갖게 되었죠.

그리고 꼭 돈만 보고 일을 하고있는 것은 아니지만, 이 회사에서도 제 연봉을 꾸준히 올릴 수 있다는 가능성은 제가 일을 할 때 일종의 당근 역할을 하기도 했고, 그렇게 1년여의 시간이 더 지난 지금, 드디어, 마침내, 아기다리고기다리던 정식 연봉 협상을 할 시기가 다가왔습니다.

결과적으로는 3번 목표에는 조금 못미치는 연봉 + 직급 조정으로 마무리가 되었지만, 개인적으로 생각한 이직 마지노선보다는 높게 받아내 만족합니다.

성과평가 기간은 전년도 6월부터 올해 5월까지의 성과를 바탕으로  합니다.
성과 평가의 기본 자료는 임직원 개개인이 각 항목별로 자신의 어떤 성과때문에 이러한 평가를 받아 마땅하다는 것을 피력해야 합니다.
회사 시스템 상에도 제가 한 일들이 로그가 다 남긴 하지만, 성과평가에 자기 PR을 위해 저는 거의 매 주마다 제가 했던 일들 중 굵직한 일들, 남들에게 자랑할 만한 성과가 있다면 따로 로그를 남겨둡니다.

사실 올 해 초 까지만 해도 제 업무일지를 들여다보면 전년대비 특별히 괄목할 만한 것은 없었습니다.
그래서 올 해에는 큰 기대를 하기 힘들 것 같았기에 1) 남들보다 문제 해결 속도가 빠르다. 2) 그래서 남들보다 더 많은 기능구현이나 버그 수정을 해왔다 정도를 강조하려고 생각하고 있었죠. 남들보다 손이 빠른 편이라 매 스프린트 중반이 넘어가면 일감이 없어 심심하다고 하여 서버쪽 개발에도 같이 참여를 시작했지만, 20년 넘게 묵은 서버 구조를 아직 파악하지 못했고, 하는 일도 쥬니어 수준에서 크게 벗어나지 못한 걸음마 수준이라 이걸 자랑하기는 힘들었죠.

제 이전글에서도 잠깐 언급되었는데, 작년에 연봉 인상 제안을 받을 때에 몇 가지 운이 따랐었는데, 올 해에도 3월에 구 모토로라(현 지브라)에서 한 건, 5, 6 월 두 달동안 제 이전 직장인 삼성에서 두 건의 사건?을 터트려주며 이번 연봉 협상에서 유리한 고지를 선점할 수 있도록 도와주는 일이 생기고 말았습니다.

모토로라 사건은 올 3월에 포스팅을 이미 한 바 있으니 (링크 참조), 삼성발 이슈 두 건에 대해 한 번 적어보죠.

첫 번째 사건은 캐나다 공휴일인 Victoria Day 직전에 발생합니다.

Victoria Day로 연휴가 시작되기 3일 전 아침, 매니져가 저를 찾아왔습니다.

•  매니져: "우승, 너 지금 스프린트 상황 어때? Blocker나 Critical task 있어?"
•  나: "아니 나 지금 스프린트 타스크들은 다 끝내서 백엔드쪽 BDD 테스트용 시뮬레이터 구현하는거 하려고 하는데. 왜?"
•  매니져: "그럼 급한 일 하나 처리해줘. 내가 메일 재전송 해줄테니 한 번 읽어보고, 폴한테 지금 상황 업데이트 받아."
•  나: "폴? 시장문제야?"
•  매니져: "그냥 문제가 아니고 좀 심각해. 전 세계에 걸쳐 10개 넘는 고객사 단말 총 8만대 정도가 갑자기 먹통이 되었어. 리포팅 된건 전부 삼성 단말인데, 삼성 특화 문제인지 아닌지도 정확하지는 않고"

안그래도 잘 알지도 못하는 시뮬레이터 만드느라 개고생 중이였는데, 참 듣던 중 반가운 소리였던지라 휘리릭 메일을 읽고선 폴이 있는 5층으로 달려갔습니다.

문제 상황이나 문제 해결 스토리를 나열하면 아무래도 보안상 안될 것 같아 이후 상황을 간단히 요약하자면 힘들게 문제 재현을 했고, 생판 모르는 SE Linux 공부를 해가며 분석한 결과 삼성에서 무언가 문제를 야기시켰을 가능성이 보였고, 삼성에 리포팅하니 이미 문제 발생한 보안 정책을 서버에서 삭제하였다고 함.

이후 이슈 해결을 위해 삼성과 컨퍼런스 콜을 arrange 했지만, 본사 개발팀은 안나오고 중국 연구소 개발팀만 나옴. 그들은 이슈 히스토리도 모르고 해당 보안 정책 변경사항도 잘 모름.

깔끔하게 해결이 된 것은 아니지만, 일단 삼성 문제라는 것 까지는 확인이 된 상황이고, 저희가 할 수 있는 것은 Factory Reset 외에는 아무것도 없다는 것 역시 확인이 되었기에 기다리면 되는 상황이긴 했습니다.

하지만...제가 왜 그랬는지는 모르겠지만, 아무래도 삼성에서 일 할 때 버릇이라 나도 모르게 나온 것 같습니다. 8만대가 멈췄는데, 휴일이라고 팽팽 노는건 삼성에선 절대 허락되지 않는 일이였거든요 ^^;;

일요일 저녁이 되자, 한국은 이제 월요일 아침이라는 것이 생각나, 그간 주고받은 메일 루프에 있는 한국인 개발자들에게 개별적으로 전화를 돌리기 시작했고, 마침내 정확한 문제 원인에 대해 설명을 듣게 되었습니다.

그래서 바로 해당 문제 고객대응 담당과 tech support 담당에서 추가적인 문제 발생을 막기위한 방법을 먼저 메일로 보내고, 전체 이슈 메일 쓰레드에 문제 내역을 요약해 돌렸습니다.

그러고 캐나다에서는 휴일이였던 월요일 아침... 아직 한국은 저녁 8시 정도이니 아직 근무중이겠거니(???) 싶어서 다시 삼성 개발자에게 전화를 걸었고, 이미 8만대를 넘어 10만대에 육박하는 문제 발생 단말들이 있기에, 보안 정책을 내리기만 하는 것으로는 충분하지 않고, 문제 수정이 되는 새로운 정책이 당장 필요하다는 것을 역설 했습니다.

삼성에서도 이 점을 인식하고는 있으나, 물리적인 한계점과 서버에서 기술적인 어려움 몇 가지를 이야기 해주며 저에게 테스트용 복구 파일을 보내 줬습니다.

삼성에서 배운 것 중 하나는, "파트너가 민첩하게 대응하길 원한다면, 너는 그 보다 몇 배 더 빨리 민첩하게 행동하라" 입니다. 직접적으로 압박을 할 수 없기에 그 누구보다 기민하게 행동한다면 상대도 문제의 중요성과 심각성을 간접적으로 깨닿고 기민하게 행동하게 된다는 것이죠.

삼성에서 문제를 발생시켰고, 수정 역시 삼성에서만 가능한 상황이기에 손 놓고 기다리기만 해도 되지만, 어느덧 10만대에 이르게 된 벽돌이 된 단말들은 우리 고객들의 단말이기에 하루라도 빨리 수정이 필요했죠. 더구나 더 큰 문제는... 경쟁사 제품에서는 문제가 생기지 않는 상황이였기에...

휴일이지만 저는 사무실로 달려가 복구 파일 테스트를 해보고 삼성에 결과를 알려 주었습니다. 혹시나 모를 추가 확인을 위해 사무실에 굴러다니는 삼성 단말들을 최대한 긁어모아 집으로 가져왔죠.

그리고 월요일 아침... 어제 삼성에서 말 한 기술적 문제점들에 대해 근원적 해결은 아니지만, 가능한 방안이 생각나 캐나다는 휴일이지만 다시 삼성에 전화를 걸었습니다.

그리고 월요일 저녁, 삼성에서 제가 제안한 방법에 추가 개선을 더 해서 기술적 제약에 대해 대응을 하기로 했지만, 다시 찾아온 문제는... 검증 기간...

저도 삼성에 다녀봐서 알지만, 아무래도 제조사다보니 삼성의 검증 프로세스는 일반 SW 프로세스보다 까다롭고 깁니다. 더구나 보안 정책의 경우 동일 OS버젼의 모든 모델들에 적용되는 것인데, 삼성 QA에서는 각 타깃 모델에서 full test를 해야만 하죠. 그렇다 보니 물리적인 시간 제약이 발생합니다.

이 때, 삼성에서 기획자로 일 할 때의 경험이 빛을 발휘하게 됩니다.

보통 B2B 고객들의 경우 다양한 모델을 쓰지 않습니다. 폰/태블릿 구매가 필요할 때 마다 입찰을 통해 한 모델을 수백에서 수만대 한 번 구매를 하는 편이죠. 문제 발생 단말은 10만대가 조금 넘고, 파생모델을 포함해 삼성에서 일 년에 출시하는 모델 수는 수백 가지가 넘지만, 문제가 발생한 모델 수는 다양하지 않을 것이라는 생각을 하게 되었습니다.

 그래서 저는 당장 고객 담당에게 연락해서 간단하게 상황을 설명하고, 고객사들에서 사용하는 단말들 모델명을 가능한 그 수량과 함께 취합해 달라고 했습니다.

 화요일 아침, 발빠른 고객 대응담당은 모델별 수량과 각 고객사별 우선순위까지 정리해서 보내 줬습니다.

 고객 담당자가 만들어준 고마운 자료를 바탕으로 삼성측에 동일 OS 전 모델에 복구 정책을 동시에 보내지 말고, 해당 모델들을 기재된 우선순위에 따라 먼저 검증하여 배포해 달라고 요청했습니다. 결국 1달, 최소 2.5주 후에나 배포 가능하다는 보안 정책은 그 후 3일만에 모델별로 배포되기 시작했습니다.

 이렇게 문제 해결이 되는 와중에도 정확한 근본적 문제 원인에 대해서는 계속 묵묵부답이였습니다. 하지만 저희 customer/tech support 입장에서도 고객 커뮤니케이션을 위해 어느 정도는 파악이 필요했고, 저희 개발팀 입장에서도 향후 동일 문제 재발 방지를 위해 알아야 했고, 또 개발자라면 누구나 있는 기술적 궁금증? 해소를 위해서도 알고 싶었습니다.  

 사실 저는 개인적으로 SE Linux를 공부하면서 알게된 지식과 현 상황이 상충되는 것이 있었기에 기술적 궁금증이 더 컸죠. 그래서 계속 개별 연락을 지속한 끝에 근본적 문제 원인 또한 속 시원하게 설명을 듣게 되었습니다.

 역시나 제 개인적인 연락을 통하게 된 것이라 관련 개발팀에 메일을 통해 공유를 했고, 우리가 좀 더 문제를 이해하는데 도움이 되었습니다.

 이렇게 저렇게 사건이 해결된 후 저는 뜻하지 않게 생에 처음 Kudos라는 것을 안드로이드 시니어 개발자와 개발팀 VP에게 받게 되었습니다.

 휴일도 마다하고 하루 빨리 고객 문제를 해결하기 위한 열정과 root cause를 향한 기술적 집요함 등에 대해 kudos를 표하더군요.

 참 상황이 재미있는게 이 모든 것이, 삼성과 관련이 있었다는 것입니다.

삼성 보안 정책 오류에서 문제가 발생했고, 해결 과정에서 삼성에서 배운 다음 두가지, "고객 발등에 불똥이 떨어졌다면 네 머리 위에는 운석이 떨어지고 있는 것이다.", "파트너가 민첩하게 대응하길 원한다면, 너는 그 보다 몇 배 더 빨리 민첩하게 행동하라", 덕분에 이렇게 해결을 하게 된 것이죠.

삼성에 있을 때엔 이렇게 하지 않으면 혼날만한 일이였건만, 여기에서는 이렇게 행동하니 오히려 Kudos를 받는군요.

올 해 연봉협상에서 제가 쓸 카드 두 장이 생겼는데, 그 누구보다 기민한 대응과 될 때 까지 두들겨보는 집요함. 두 가지입니다.