가뿐한 주말과 언짢은 시간낭비

오래간만에 상쾌하고 가뿐한 주말이 찾아왔습니다.

주말이야 매 7일마다 찾아오는 것인데 '상쾌하며 가뿐한' 주말은 정말 오래간만인 것 같습니다. 요즘에는 계속 주말에 제가 해야만 하는 일들 혹은 주말에 제가 계속 공부나 연구 혹은 고민을 해봐야만 하는 일들을 안고 주말을 맞이했었는데, 이번 주에는 머릿 속을 하얗게 비워두고 쉬어도 될 만큼 뒷일을 남겨두지 않아도 되는 주말입니다.

그런데... 제 업무 자체와는 상관이 없지만, 이번 주의 목요일 금요일의 시간 낭비 자체와 시간 낭비를 하게 된 회사 정책때문에 조금 언짢은 기분이 있었습니다.

지난 달 말에 저희 팀원 중 한 명이 회사를 떠났습니다. 자발적인 퇴사가 아닌 해고였죠.

회사의 기본 견습 (probation) 기간은 3개월입니다. 법적으로 probation기간동안은 회사에서는 아무런 제약없이 직원을 해고 할 수 있기에 채용 프로세스를 통과 했어도 이 probation을 통과 해야 사실상 진정한 정직원이 되었다고 할 수 있죠. 저도 이 친구의 probation 평가 리포트를 작성하기도 했지만, 첫 3달이 지났을 때 정말 애매한 상황이였습니다.
입사할 때 조건이 시니어급이였는지 아닌지는 알 수 없었으나 그의 그간 경험이나 나이로 미루어 봤을때, 그리고 일반적인 주제에 대해 말하는 것으로 봐서는 시니어로 봐도 될 것 같은데, 조금은 새로운 분야에 대해 논할때에는 시니어의 고집과 함께 쥬니어급의 이해도를 보였습니다. 그리고 가장 문제가 된 것은 실제 퍼포먼스가 쥬니어 급이였습니다. 새로운 분야에 이해도가 쥬니어급이라고 했는데, 새로운 일은 거의 하지 못했죠. 기존 그가 익숙한 분야의 업무는 말로는 청산유수이고 모든 일이 조만간 끝날 것인 것 처럼 말을 했지만 매일매일 팀 sync up 미팅을 할 때마다 같은 업무내용에 대해 "곧 끝난다" 라는 말만 며칠간 반복이 되어 생각보다 일의 진척이 늦었었죠.
그렇다보니 처음 3개월 이후에도 Extended Probation이라 하여 추가 3달의 견습 기간을 거치게 되었는데 결국 그 기간동안 이렇다 할 진척을 보이지 못했고, 우리가 바라던 만큼의 수준을 보여주지 못해 어느날 갑자기 해고되었습니다.

원래 매니져 포함 6명인 작은 조직에서 1명이 줄어드니 이래저래 일이 몰리고 밀릴 수 밖에 없었고, 그렇다보니 제가 원래 잘 하지 않던 Ops쪽 일도 해야하여 주말에는 Ops 관련 툴들을 공부하거나 밀린 개발관련 일들을 해치우거나, 혹은 업무시간 중 바빠 미처 확인하지 못한 새로운 pilot 서비스들을 돌려보느라 이래저래 바빴습니다. 사실 그 친구가 함께했던 기간 중에도 항상 우리가 기대했던 만큼의, 또 그가 말한 만큼의 성과가 안나와 매 스프린트마다 마지막 주차가 되면 뒤쳐진 일들을 쳐내느라 바빴는데, 든자리는 몰라도 난자리는 티가 난다고, 그가 빠지니 그 정도가 더 심했었죠.

회사에서 주말근무를 요구하거나 반드시 각 스프린트마다 주어진 일을 마쳐야 한다고 강제하는 것은 아닌데, 이건 약간의 사람의 성격 문제인 것 같아요. Sprint planning에서 약속한 업무들을 모든 sprint마다 다 해치우자는 것 까지는 아니지만, 연속으로 3-4 스프린트에서 목표 달성을 못하는 상황을 제가 차마 지켜보지 못하여 저 혼자라도 더 달려서 어떻게든 목표 달성을 위해 달렸던 것 같아요. 

그래서 이전까지는 피동적으로 DevOps 포지션의 지원자를 구하다가 지난달 말 부터는 외부 헤드헌터들에게도 요청을 하는 등 조금은 더 공격적으로 사람을 구하기 시작했습니다.

그리고 이번주 금요일, 드디어 한 명과 인터뷰가 잡혔습니다.

월요일 밤에 매니져를 통해 지원자의 이력서를 받았는데, 모국인 우크라이나에서 석사를 마쳤고 전체 경력은 10년이 조금 넘었습니다. 특히나 좀처럼 구하기 힘든 DevOps 포지션의 경력이 최근 3년간 있었죠. 그래서 지금 그가 일하는 회사의 CD 수준을 파악하고자 이력서에 기재된 회사명을 검색 해 보았는데, 좀처럼 이렇다 할 정보를 얻을 수 없었습니다. 회사 공식 웹사이트는 찾을 수 없었고 페북 그룹이나 링크드인에 그 회사에서 일하는 직원들이 보이는 정도였죠.

그래도 지난 경력을 보니 우크라이나 석사 졸업 후 4-5년 정도 캘리포니아에서 웹 개발자로 일을 했고, 이후 모국으로 돌아가 다시 2-3년 정도 자바 개발자로 일을 했으며, 최근 3년간은 토론토에서 DevOps 및 자바 개발자로 일을 한 경력이 있는 점이 마음에 들었습니다. 저희 팀에 저만 자바 개발자이다보니 저희가 쓰는 오픈소스 툴에 contribution 할 일이 있을경우 그 일들이 저에게만 몰리는 상황이라 다른 자바 개발자가 있었으면 싶었거든요.

그래서 목요일 밤, 인터뷰를 준비하기 위해 코딩을 시작했습니다.
손코딩을 통한 간단한 알고리즘이나 369 게임, 혹은 fizz-buzz 같은 것을 구현하는 테스트를 하기 보다는 실제 코딩을 통해 그의 코딩 습관이나 실력을 조금이라도 엿보고 싶었기 때문입니다. 물론 인터뷰를 보기 전에 온라인 코딩시험을 치루기는 하는데, 무슨 이유인지는 몰라도 저희 회사 HR은 인터뷰가 끝난 이후에야 온라인 시험 점수를 알려줬거든요. 더구나 저는 살짝 목표 지향적인지라 업무와 무관한 지식들을 시험하기 보다는 실무에서 실제로 하는 일이나 할 법한 일과 유사한 일에 대해 실무적인 능력을 보고 싶었습니다.

제가 준비했던 문제는 지금도 저희 CD 파이프라인에서 사용중인 저희 자체 VM 클라우드 관련된 것이였습니다. VM 클라우드에서 동시 처리능력과 파이프라인 처리 병목 정도를 파악하기 위한 간단한 모니터링 툴을 만드는 상황을 가정하였고, 각 데몬에서 리포팅한 로그들을 가져와 실제 운영상황에 대한 데이터를 필터링하는 것을 문제로 만들었습니다.

실제 문제는 매우 단순화 하여 각 VM 별로 VM 생성시간과 종료 시간의 array를 입력값으로 주었을 때, 특정 moment에 운영중인 VM의 최대 갯수가 몇 개인지를 구하는 method를 구하는 문제가 한 문제였고, 두번재 문제는 각 VM Host의 매니져 서비스에서 로그를 가져와 각 VM별로 생성 요청을 받은 시간과 생성이 종료된 시간 로그를 array 형태로 뽑아낸 뒤, 2분간 처리하는 최대 VM 생성 개수가 몇 개인지를 구하는 method를 만들라는 문제였습니다. 실제로 VM이 생성된 이후 빌드를 돌리거나 테스트를 돌리는데에도 리소스가 많이 사용되지만, 내부 클라우드에서 가장 병목이 되는 것은 Disk IO였는데, VM이 생성 될 때 마다 20GB가 넘는 VM Image 파일이 복사가 되기에 성능에 가장 크리티컬 했던 것이 Disk IO 문제였던지라 실제로 툴과 스크립트를 만들어 의사결정에 활용될 만한 metric들을 뽑아낸 적이 있었던 것입니다.

문제를 내는데 코딩을 한 이유는 간단합니다. 주어진 몇 시간의 기술 인터뷰 중에 가능한 짧은 시간동안 코딩 테스트를 하기 위해서였죠.
그래서 먼저 제가 뽑아온 데이터 중에 가장 데이터가 복잡하여 연산 중 작은 오류가 있으면 오답이 나올만한 부분을 골라내고 나머지 데이터는 삭제를 했습니다. 그리고 일일히 손으로 계산을 해 보았고, 제가 계산한 값과, 테스트 데이터를 기반으로 Unit Test 코드를 작성했습니다.
그리고 각 문제별로 시간이 얼마나 주어져야 할 지를 판단하기 위해 직접 method 구현을 했고, 문제의 배경이나 요구사항, 테스트 데이터가 어떻게 주어지고 원하는 값이 어떠한 것일지를 이해 할 만한 설명 문서도 작성을 했습니다. 물론 구두로도 그 자리에서 설명을 할 예정이였지만, 문제를 풀어나가며 생기는 질문들로 인한 지연을 최소화 하고 싶어 그렇게 준비 했죠. 그리고 코딩 테스트용 문제를 다 만든 이후에는 로그에서 timestamp를 datetime으로 변환하는 것과, 로그에서 regex로 읽어올 데이터만 뽑아내는 것 관련 행여나 시간 낭비를 할까봐 답안을 작성 할 class 내에 관련 기능은 미리 method를 작성해 만들어 주었습니다. 그리고 정말 오래간만에 나서는 인터뷰인지라 인터뷰에서 질문 할 내용들도 추렸습니다.

그렇게 자정이 넘어 시작한 인터뷰 준비는 좋은 동료와 함께 일을 할 수도 있다는 기대감과 함께 새벽 2시가 넘어서야 끝이 났습니다.

그리고 금요일. 먼저 매니져가 인터뷰를 시작 했습니다. 매니져 인터뷰가 끝나고 제가 면접장으로 가는데, 매니져가 저를 붙잡고 짧게 말하더군요.

"아마 한 두개 정도의 질문만 하면 그가 어떤지 바로 알 수 있을꺼야"

의미심장한 말이였습니다. 몇 마디의 말로도 고수의 향기를 느낄 수 있는 그런 사람이거나, 정말 아니거나...

그런데 정말 불행하게도 그는 전자가 아닌 후자였습니다. 일단 영어가 정말 안되었습니다. 캐나다에서 일을 하면서 거의 처음으로 저보다 영어를 더 못하는 사람을 일터에서 만났습니다.

그래도 처음 두개 정도의 질문을 하면서는 그래도 10년가량의 경력도 있는데, 언어적 문제로 인해 답변을 잘 못하는 것이 아닐까라는 생각을 했습니다.
하지만 조금씩 더 깊게 들어갈수록 정말 아니라는 생각이 확고해졌습니다. 결국 제가 준비한 코딩 문제는 차마 꺼내지도 못했고, 일반적으로 어느 회사를 가건 질문하는 기본적인 Java 관련 질문들만 하고 끝이 났습니다.

아... 아까운 내 시간... 잠도 줄여가며 인터뷰 준비를 했건만, 지금까지 봐온 인터뷰 중 가장 준비가 안된 인터뷰였던 것 같습니다.

인터뷰가 끝난 후 그의 온라인 코딩 테스트 성적이 너무나도 궁금했습니다. 그래서 매니져에게 달려가 물었습니다. 

"아까 나에게 한 말이 무슨 뜻인지 이제 알겠다. 그런데, 혹시 HR에서 codility test 점수 알려줬어?"

"응. 받았어."

"몇 점이야?"

"0점"

"응? 뭐라고?"

"0점"

미리 점수를 안알려주는 것이야 선입견 방지를 위해 그럴 수도 있다지만, 0점 임에도 인터뷰를 arrange하는 HR은 도대체 뭐지요?

덕분에 저와 매니져가 업무시간 중 본 손실은 총 3시간 가량입니다. 저도 인터뷰 준비를 위해 문제를 만드느라 두세 시간 정도 개인 시간을 쓰기도 했지만, 매니져 역시 그와 관련된 정보를 찾아보기 위해 어젯 밤에 몇시간 동안 인터넷을 헤맸다고 하는군요.

사실 이런 문제가 어제오늘 일은 아닙니다. 수 년 전에도 다른 팀 시니어와 매니져가 HR 리크루터에게 이와 관련된 항의를 하는 모습을 본 적이 있었습니다. 사실 그 이후에 개선이 되었을 것이라고 생각했는데, 아직도 유효하더군요. 온라인 테스트 점수를 통해 미리 사람을 걸러내면 좋은 사람을 놓칠 수도 있다나요?

물론 그럴 수도 있습니다. 저도 이 회사에 오면서 봤던 온라인 시험을 볼 때 웹 환경인 IDE 툴에서 개발하는 것이 익숙하지 않다보니 처음 10분 정도는 '이게 뭐지?' 하다가 흘러갔던 기억이 납니다. 그리고 주어진 시간에 문제를 풀다보면 실수를 할 수도 있고, 그래서 평소 실력대비 점수상으로는 20-30점 정도가 낮게 나올 수도 있습니다.

그런데 0점이라도 면접을 봐야 한다니요. 0점이라면 말 그대로 주어진 문제에서 부분점수조차 획득하지 못한 것인데, 어떤 실력인지 확실히 검증이 되지 않은 사람이 아니라 확실히 수준 미달의 실력이라는 것이 검증된 사람과 면접을 본다는 것이 정말 납득이 되지 않았습니다.

DevOps로 옮긴 이후로는 처음 interviewer로 나섰던 자리인데다, 기존 팀과는 다르게 팀 차원에서 공동으로 준비한 인터뷰 문제들도 없는 상황에서 나간 인터뷰라 좀 더 많은 시간을 투자했는데, 정말 죽쒀서 개줬다는 말 처럼 너무나 허무하고 언짢은 기분이 들더군요.

지원자 일정에 따라 다음주 중으로도 인터뷰가 하나 더 잡힐 수도 있다고 하는데, 다음 번에는 제발 이런 케이스가 아니길 바래봅니다.

좋은 소식과 안좋은 소식

컨퍼런스 출장, 그리고 짧은 업무 복귀 후 다시 약 10여 일간 휴가를 보내는 사이에 제 주변에서 Good News와 Bad News가 함께 들려왔습니다.

Bad News는 두가지인데, 하나는 좀 많이 안좋은 뉴스고 다른 하나는 조금 안좋은 뉴스입니다.

약 3달쯤 전에 제가 일하는 회사로 이직을 하게 된 한인 개발자가 계십니다. 사실 직장 자체만 놓고보면 이전에 일하시던 직장은 대기업 중 하나로 좋은 복지제도와 괜찮은 연봉을 주는 곳이며, 오피스 위치도 토론토였기에 미시사가에 위치한 중소기업으로 올 이유가 별로 없었습니다. 이직을 결심한 이유는 이민 때문이였는데, 이전 직장에서는 주정부 이민 지원이 없는 반면, 저희 회사에서는 주정부 이민을 서포트 하기에 이직을 한 것이죠. 하지만 컨퍼런스 출장 후 복귀를 하고나서 보니 안타깝게도 3개월 Probationary 기간을 통과하지 못하고 회사를 떠나고 말았다는 소식을 듣게 되었습니다. 

뒤돌아보면 그간 몇 번의 신호가 있었던 것 같기는 합니다. 그 분과 식사나 산책을 같이 하면서 그 분의 매니져와 1:1 면담 내용에 대해 전해들은 적이 몇 번 있었습니다. 그 일이 있기 약 1~2달 전쯤에는 매니져가 그 분께 바라는 롤이 어떠한 것인지를 설명하면서 현재 진척에 대해 약간의 아쉬움을 표시한 적이 있었습니다. 그리고 이 일이 있기 약 2주 전, 마지막 면담 때에는 일을 익히고 따라오고, 또 팀에 새로운 value를 불어넣는 역할이 기대에 미치지 못한다며 직접적으로 이야기를 꺼내기도 했었고요.
그 분에게 면담 스토리를 들을 때, 그 분께서는 당시 면담 내용이 우려되어 힘들게 말을 꺼낸 것이였지만, 저는 그 때만 해도 이 일을 그다지 심각하게 받아들이지는 않았었습니다.
제가 처음 이 회사에 왔을 때, 저의 매니져 역시 probation기간이 끝날 때 까지 1:1 면담시에 칭찬을 했던 기억은 별로 없었고, 항상 내가 어떠한 것을 더 해주기를 바라는지, 그리고 나의 부족한 점이 무었인지를 계속 이야기 했던 기억이 있습니다. 덕분에 캐나다 회사에서의 기대치에 대해 전혀 감을 잡지 못했던 저는 항상 긴장상태를 유지했었죠. 하지만 막상 probation이 끝나고 나니 이런저런 칭찬도 해 주었고, 또 저의 연봉 또한 조정을 해 주었기에 probation기간 중 다소 딱딱한 이야기들이 그다지 심각하지 않다고 생각했었기 때문이죠.

제가 아는 그 분은 이렇게 허무하게 가실만한 분이 아니셨는데, 아무래도 경력과 연봉수준 등에 따른 회사의 기대치도 다를 것이고, 당시에 개인적으로 영주권 관련하여 몇번의 폭풍이 몰아쳤던 상황이라 그런 것 같기도 합니다.

또 다른 안좋은 소식은 사실 생각하기에 따라 안좋은 소식이 아닐 수도 있습니다.
저희 부서에서도 사람을 구인 중이였고, 반드시 DevOps 경력이 아닐지라도 좋은 개발자이고, DevOps에 관심이 있는 사람이라면 얼마든지 추천을 해 달라는 말에, 그렇지 않아도 커리어에 고민이 있던 친구 한 명을 추천을 한 일이 있습니다. 하지만 면접결과 안타깝게도 채용하지 않기로 했다고 하네요. 그래도 이미 재직중인 회사가 있는 상태에서 다른 기회를 찾아보기 위해 면접을 봤던 것이기에 크게 나쁜일은 아닐 수 있습니다. 오히려 좋은 일이라고 할 수도 있는데, 면접 과정에서 저희 매니져가 마음에 들었던지, 따로 장문의 메일을 써서 어떠한 점들이 부족했고 무엇이 더 필요한지 자세히 피드백도 주었고, DevOps와 관련된 책을 한 권 사서 우편으로 보내주어 혹시 관심이 있다면 이 책을 자세히 읽어보고 더 공부한 후에 다시 한번 만나고 싶다고 했다네요.

다른 한가지 안좋은 소식은 제가 리퍼럴로 추천을 해 준 친구가 회사 면접에 붙지 못한 일입니다. 그래도 그 친구는 다른 회사에 지금 재직중인 상태에서 다른 기회를 찾아 본 것이기에 크게 나쁜 일이라고 까지는 하기 어렵겠죠. 그리고 면접 과정에서 매니져가 마음에 들었던지, 그 친구에게 따로 어떤어떤 점들이 부족했는지 메일도 보냈고, 이쪽 커리어를 생각한다면 도움이 될 만한 책이라며 책도 따로 구매해서 보내주었습니다.

좋은 소식도 두가지이며 둘 다 취업 소식입니다.

먼저 같은 학교를 다녔던 한국인 동생 중 한 명의 취업 소식입니다. 한국에서의 별도의 학력이나 경력은 없는 친구였지만, 항상 성실하고 열심히 하는 멋진 친구였는데, 얼마 전 Web 개발자로 취업을 했다고 하네요. 이 친구도 졸업 후 2년 가까이 다른 분야에서 계속 일을 하고있었고, 시간이 다소 오래 걸리기는 했지만 드디어 개발자로서 커리어를 시작하게 되었습니다.
얼마 남지않은 PGWP 비자 기간때문에, 주중에는 개발자 job을, 주말에는 현재 영주권 진행중인 현재 job을 뛰면서 당분간 투쟙을 유지해야 한다는데 힘들지 않을까 걱정이네요. 부디 영주권을 받아 정착하고 개발자로 완전 전업을 하는 그 날까지 젊음과 체력이 버텨 주길...

다른 취업 소식은 저와 같이 학교를 다녔던 인도 친구 소식입니다.
빈약한 실력 때문에 같이 학교를 다니면서 가능하면 프로젝트는 같이하지 않으려고 했던 친구이긴 하지만, 캐나다에서 가장 큰 은행에서 코업도 했었고, 언변에 능해 취업이 비교적 쉽게 될 것이라 생각했지만, 취업까지 약 2년의 시간이 걸렸네요. 이 친구도 역시 생계를 위해 그동안 보석상에서 일을 하고 있었습니다.

그리고 이 글을 쓰는 사이에 방금 전 페이스북 챗을 통해 안좋은 소식이 하나 더 들어왔네요.

학교에 있을 때 저보다 나이가 조금 더 많은 40대 일본인 아저씨 한 명이 있었는데, 다음 주 월요일에 토론토를 떠나 다른 주로 옮겨간다고 합니다. 이 아저씨도 아직 개발자 쟙을 얻지 못하고 있는 상황이긴 한데, 이제는 1년이 채 안되게 남은 비자기간 때문에, 당장 내일 개발자로 취업을 해서 경력을 쌓는다 해도 1년 미만의 경력인지라 CEC이민을 할  수 없으며, 어찌어찌하여 1년, 혹은 2년의 경력을 쌓는다 해도 Express Entry 점수 충족이 어려워 토론토에서 이민은 포기하고, 마지막 방법으로 반년의 경력으로도 주정부 이민이 가능한 주를 찾아 떠나간다고 합니다.
참 착했고, 학교를 같이 다녔던 친구들 중 저와 문화적으로 가장 잘 맞았던 친구인지라 안타깝네요. 단순한 저의 추측이긴 하지만 아마도 언어실력과 커뮤니케이션 스킬 때문이 아닐까 추측을 해 봅니다.

이 친구의 개발실력은 뛰어난 편은 아니였습니다. 하지만 또 다른 학생들에 비해 뒤쳐지는 수준도 아니였죠. 그럼에도 코업 학기 때 부터 코업 쟙을 구하지 못했었고, 결국 졸업을 할 때 까지 코업을 하지 못하고 졸업을 했습니다. 그 당시만 하여도 대부분 큰 어려움 없이 코업을 구하던 시절인지라 그 친구가 코업을 구하지 못해 1학기 강제 휴학을 할 때만 해도 정말 운이 없는 케이스라고 했었죠.

언어에 대해서는 제가 누구에게 무어라 할 만한 처지는 아닙니다. 저도 매우 영어를 못하고 또, 모르니까요. 이 친구도 저 못지않게 참 영어를 잘 못하는 편이지만, 영어 자체에 대한 능력보다 대화의 스킬에 대해 이야기를 하고 싶습니다.
고급진 영어, 화려한 언변과는 거리가 먼 것이지만, 더듬더듬 서바이벌 잉글리시를 말하는 이민자 영어의 입장에서는 조금 더 적극성을 가지고 대화를 하는 것이 좋은 스킬 중 하나라고 생각합니다.

저는 대화를 하다 어휘가 생각나지 않거나, 적당하게 표현할 방법이 떠오르지 않으면 제가 생각해 낼 수 있는 가장 쉽고 기본적인 단어들로 저의 느낌/생각/경험을 여러번 반복해서 표현을 합니다. 가능한 상대방이 이해할 수 있을 때 까지요. 이 친구가 저와 다른 점이 한가지 있다면 원래 화법 자체가 느린 편인데다, 매우 신중하고 조심스러운 성격을 가지고 있다보니, 이러한 상황이 발생했을 때, 일단 최소 수초간 입을 닫고 생각합니다. 그리고 어느정도 시간이 지나면 그 후에 만들어진 문장을 말을 하죠. 그렇다보니 다자간 대화 뿐 아니라 1:1 대화인 경우 종종 이미 지나간 주제를 뒤늦게 다시 꺼내오기도 합니다.

무엇이 옳고 그르다고 판단할 수는 없지만, 제가 마치 가족오락관 게임을 하듯 비슷한 말로 제가 표현하고자 하는 바를 몇 번 설명하다보면 대부분 native들은 결국에는 그 뜻을 이해하고 저의 말을 rephrase해서 '이 말인거지?' 라고 되묻습니다. 어찌되었건 저는 이렇게 대화가 계속 이어지고 서로 집중을 하면서 대화를 하는 것이 더 편합니다.
신중하게 생각하여 올바른 말과 표현을 하는 것의 장점도 있겠지만, 그 친구와 대화를 하다보면 시간도 오래 걸리고, 때로는 심지어 다음 날 만났을 때에야 서로의 뜻을 이해하게 되기도 합니다. 이러한 대화가 면접장에서도 지속이 된다면, 면접관의 입장에서는 언어를 몰라 말을 못하는 것인지 내용을 몰라 설명을 못하는 것인지 알 수가 없겠죠.

참 재미있는게, 서로간의 코딩스타일은 각자의 화법과 비슷했습니다.
저는 외부 서비스나 플랫폼과 연동되는 새로운 프로젝트를 만들 때, TDD와 비슷하게 합니다.
먼저 간단한 파일럿 클라스와 그의 유닛 테스트를 먼저 만들고 하나씩 돌려보며 외부 서비스의 behaviour를 파일럿 클라스에서 확인을 해 보면서 시작하는 경우가 많습니다. 어느정도 확인이 된 후에 제대로 다시 설계해서 만들어 나간다면 참... 좋은 일이지만 개발자에게 세상에서 가장 힘든 일이 이미 만든 코드를 삭제하는 것이라고 했던가요? 귀차니즘과 파일럿 클라스에 대한 근자감으로 대부분은 그 파일럿 클라스를 수정/확장 해 나아가며 프로젝트 코드가 되버립니다.
하지만 이 친구는 외부 서비스나 API, 플랫폼의 문서부터 파고, 문서를 다 파고나면 그 때서야 설계를 시작하고, 설계가 다 되어야 코딩을 시작했었습니다.
제가 보기에 이 친구는 다소 답답했었고, 이 친구는 저를 다소 무모하다고 생각 했을 것 같네요.

아마 각자의 성격에 따라 화법도 다르고 목소리의 톤도 다르고, 또 개발 스타일도 다른 것 같습니다. 그래서일까요, 예전에 그 친구에게 설명이 안되면 다른 표현으로 설명을 해 보는 것이 어떻겠냐고 권해 본 적은 있지만, 사람 성격이 그리 쉽게 바뀌는 것은 아니다보니...

제 멘탈이 약해서인지 몰라도, 주변에서 좋은 소식들이 들려오면 저 역시도 좀 더 기운이 나고 기쁘지만, 반대의 경우에는 같이 힘들어지는 편인데, 올 해 남은 기간동안이라도 제 주변에서 좋은 소식들이 많이 들려오면 좋겠네요.