2017년 12월 29일 금요일

헤어짐에 익숙해지기

타이틀을 적어두고보니 마치 연인과의 이별을 이야기하는 것 같지만, 사실은 회사생활 이야기입니다.

회사를 다니다보면 동기나 선후배, 혹은 직속 상관이 회사를 떠나는 일들을 맞이할 수 밖에 없습니다. 너무너무나도 완벽한 직장이라 turn over rate이 아무리 낮은 회사라고 해도 결국에 은퇴를 하는 사람도 있고, 자신의 적성에 도무지 맞지않아 떠나는 사람이 있으니 결국 한 번 이상은 이러한 순간을 맞이하게 되죠.

한국에서 직장을 다녔던 8년여간 저는 가깝게 지냈던 동료들과의 이별의 순간을 그다지 많이 경험하지 않았습니다. 저와는 거리가 아주 먼 전무, 부사장, 사장 급 임원이 회사를 떠나는 순간은 거의 매 해 임원인사 시즌마다 경험했지만, 저의 직속 상관이나 저의 직속 후배들, 혹은 저와 같은 팀에서 일을하는 팀원들이 떠나는 경우는 지금까지 딱 2번이 있었던 것 같네요.

제가 신입사원 때 부터 저희 소파트를 이끌던 책임님이 과도한 업무부담으로 회사를 떠난 적이 있었고, 서비스 기획자로 변신한 직후 저희 소파트를 이끌던 과장님이 다른 회사의 독일 법인장으로 스카웃되어 떠나면서 이렇게 단 2번의 이별을 경험 했었습니다.

그런데 캐나다에 와서 일을하면서보니 이러한 이별에 좀 더 익숙해져야 한다고 느껴집니다.

지금 회사에서 일을 시작한지는 고작 3년밖에 되지 않았지만, 벌써 회사 내 경력으로는 중고참 급에 해당합니다. 그 만큼 캐나다의 직장문화는 한국에 비해 turn over rate이 훨씬 높더군요. (적어도 개발자라는 직업군에 한해서는...)

오늘도 저는 회사에서 가장 신뢰하고있는 사람 중 한명을 떠나 보냈습니다.

바로 저희 팀 매니져인데, 이 친구가 회사를 그만두게 된 계기 중 일부에 대해 저의 역할이 있었기 때문에 더 각별히 응원 해 주고 싶으면서, 동시에 더 안타깝습니다.

제가 다른 팀에 속했을 때 이 친구에대한 저의 인상은 매니져가 아닌 Senior Developer였습니다. 사실 제가 현재의 팀으로 옮기기 직전까지만 해도 이 친구가 개발자라고 생각했었죠. 이렇게 착각을 하게 된 이유는 업무상 이 친구의 소속팀과 협업을 할 일이 있었는데, 누가봐도 사통팔달 시원시원하게 기술적 해답과 의견을 제시했고, 또 이 친구의 이름으로 된 커밋을 간간히 볼 수도 있었기 때문이죠.

사실 제가 이 회사에 들어오기 전에 Developer에서 Manager로 전직을 한 것인데, 개발 일에대한 애착과 열정이 넘치다보니 Manager가 되어서도 끊임없이 따로 공부하고 연구하며 새로운 기술들을 익히고 살아온 친구입니다.

이렇게 development를 좋아하는 사람들의 특징 중 하나는 자기 자신에대한 무한한 열등의식을 가지고 있다는 것인데, 워낙 좋아하는 일이고 누구보다도 잘 하고 싶어하는 일이다보니 객관적인 시각에서 자신의 seniority를 보기 보다는 주관적인 입장에서 자기보다 항상 높은 곳만을 바라보며 자신의 부족함을 책망하는 것이지요.

제 주변에도 몇몇 이런 사람이 있는데, 정말 제 기준에서는 "천재 아니야?" 싶은 분들도 같이 이야기 해보면 단순 겸손한 것이 아니라 진짜로 자기 스스로를 slow learner라고 하거나, 창의력이 부족하다고 하거나, 기술의 스펙트럼이 너무 좁다고 하거나, 지금은 몰라도 미래에 먹고살기 힘들다며 자책을 하는 경우를 많이 봤습니다.

이 친구와 1년 가까이 같이 일을 하면서 1:1 면담이나 개인적 사담을 통해 제가 왜 캐나다에 왔고, 어떻게 왔는지에 대해서도 이야기를 한 적이 있고, 그런만큼 다른 모든 조건을 떠나서 내가 개발을 하고 있다는 사실만으로도 참 고맙고 감사하고 행복하다는 이야기를 한 적이 있는데, 저의 이런 이야기가 이 친구에게 작지않은 자극이 되었다고 합니다. 그래서 일단은 혼자만의 시간을 가지면서 최근 기술 트랜드와 여러가지 관심있는 분야에 대해 공부를 하기로 결정했다고 하더군요. 그러다 만약 business opportunity를 찾으면 직접 창업을 할 수도 있고, 결국 경제적 압박이 심해지면 지금 회사로 돌아오거나 다른 회사의 일자리를 찾을 수도 있다면서 말이죠.

지금까지 만났던 매니져 중에 가장 개발자를 잘 이해하고, 가장 잘 배려하면서, 개발 일손이 부족하면 직접 일선에 뛰어들 수 있는 최고의 매니져였는데, 너무 아쉽네요.

언젠가 또 다른 인연으로 다시 만나길 바라며 그 친구도 저도 Happy New Year가 되길 바랍니다.

2017년 12월 20일 수요일

영어의 벽과 이메일

안녕하세요.

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



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

영어실력에 따라 개인차가 있을 수 있지만, 저도 그렇고 제 주변에 다른 분들도 대부분 가장 두려운 것은 전화통화이며, 그 중에서도 단연 백미는 흔히 다양한 목소리들이 겹치는 상황도 발생하는 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인지라 영어가 딸리는 제가 빠져도 다른 동료들이 주저없이 콜로세움으로 뛰어들기에 제 입장에서 더 이상 부담 될 일은 없죠.

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