Thoughts2019. 10. 13. 07:03

그렇다면 개발자의 일상에서 불확실성은 어떤 형태로 등장하는가?

 

불확실성은 내가 잘 모르는 것, 그리고 내가 통제할 수 없는 어떤 것에서부터 등장한다. 내가 통제할 수 없는 것으로는 여러가지가 있지만, 주로 소프트웨어 납기에 관련된 것만 살펴보면 주로 다음과 같다.

 

  • 내가 이용하는 소프트웨어/서비스의 업데이트 주기 또는 릴리즈 사이클
  • 내가 속한 팀과 다른 서비스 소유자 또는 팀과의 협업 형태
  • 사용자로부터의 요구사항 
  • 시니어 리더십으로부터의 우선순위 변경 요청
  • 여러 프로젝트 사이의 컨텍스트 스위칭 오버헤드 
  • 내가 이용하는 소프트웨어/서비스의 가용성 

 

전부 시간을 들여 따져볼 가치가 있는 사항들이지만, 우선 제일 마지막 항목, 그러니까 내가 이용하는 소프트웨어/서비스의 가용성이 어떻게 내가 통제 불가능한 형태의 불확실성이 되기도 하는지 살펴보자.

 

보통 소프트웨어의 특정 기능('피처'라고 부르기도 하는)을 개발하고 납품하는 과정에 문제가 없으려면, 이용하는 소프트웨어/서비스의 가용성에도 문제가 없어야한다. 현대 소프트웨어는 복잡한 의존성(dependency)을 갖는다. 하나의 소프트웨어가 온전히 자족적으로 존재하는 경우는 이제 찾아보기 어려우며, 보통 하나의 제품은 다른 여러 소프트웨어/서비스에 의존한다. 여러분이 AWS/GCP 등에 의존하고 있다면, 여러분의 소프트웨어는 해당 클라우드 플랫폼이 제공하는 서비스들에 의존성을 갖는다. 여러분이 회사 내부적으로 공개된 다양한 서비스를 이용하여 소프트웨어를 개발하고 있다면, 여러분의 소프트웨어는 해당 서비스에 의존성을 갖는 것이다. 이 의존성은 프로젝트 개발 과정의 다양한 부분에 영향을 미치지만, 가장 결정적인 부분은 테스트이다.

 

여러분이 어떤 서비스를 만든다고 하자. 해당 서비스에 대한 변경사항을 배포하기 위해서는 다양한 테스트가 필요하다. 해당 변경사항을 머지한 이후에 서비스가 정상적으로 실행되는지는 가장 기본적으로 테스트해야 할 사항이다. 해당 변경사항을 머지한 이후에 해당 서비스의 응답 속도에 큰 변화가 없는지, 처리량에 큰 변화가 없는지를 검사하는 것은 조금 더 복잡하지만, 역시 필수적으로 요구되는 사항이다. 한편 사용자 경험 상에 어떤 부정적 변화가 없는지를 테스트하는 것은 훨씬 어렵다. 이런 부분까지 테스트하는 자동화된 툴을 도입할 수 있다면 좋겠지만, 그렇지 못한 경우도 있기 때문에 릴리즈 마지막 단계에서는 QA 엔지니어들의 도움을 받아 서비스를 수동 테스트하기도 한다. 

 

이 각각의 테스트는 단계적으로 이루어진다. 가령 서비스의 실행이 정상적으로 이루어지는지를 검사하는 것은 보통 알파 스테이지(alpha stage)에서 이루어지고, 서비스의 기본 기능에 부정적 변화(regression)이 없는지를 검사하는 것은 통상 베타 스테이지에서 이루어지며, 처리랑/응답속도/사용자 경험에 있어서 부정적인 변화가 없는지를 검사하는 것은 통상 감마 스테이지에서 이루어진다.

 

주목해야 할 것은 보통 알파/베타 스테이지에서 실행되는 서비스는 내부망을 바라보도록 설계되어 있어서, 해당 서비스가 의존하는 하위 서비스도 알파/베타 스테이지 버전을 이용하게 된다는 것이다. 한편 감마 스테이지에서 실행되는 서비스가 바라보는 타 서비스의 엔드포인트는 감마 엔드포인트, 그러니까 감마 스테이지에서 실행되는 서비스의 엔드포인트인경우도 있고, 실 서비스망에 위치한 서비스의 엔드포인트인 경우도 있다. 실 서비스에서 생성되는 데이터에 혼란을 야기하기 싫은 경우가 대부분이기 때문에, 보통은 감마 엔드포인트를 바라보도록 구성한다.

 

여기서 주의할 것은 내 알파/베타 스테이지 서비스가 이용하게 될 하위 의존성, 다시 말해 내가 이용해야 할 알파/베타 서비스들은 보통 굉장히 불안정하다는 것이다. 이름 자체가 알파/베타이므로 많은 팀들은 이들 스테이지를 그다지 적극적으로 관리하지 않는다. 이들 스테이지는 수시로 망가지고, 수시로 복구된다. 감마 스테이지 이후의 서비스가 정상적으로 동작하고 있다면, 많은 팀들은 알파/베타 스테이지에서 벌어지는 문제를 긴급하게 처리하려 하지 않는다. 실 서비스 망에서 지금 당장 벌어지고 있는 문제가 아니기 때문이다. 

 

그러나 망가진 알파/베타 스테이지 서비스는 해당 서비스에 의존하는 다른 팀들의 서비스 테스트를 곤란하게 만든다. 방금 머지된 서비스 변경 사항이 정상 동작하지 않는 것이 해당 변경사항에 끼어든 버그 때문인지 아니면 하위 서비스의 장애 때문인지 확인하기 어렵기 때문이다. 이 때문에, 많은 경우 시스템 변경을 A/B 테스트로 감싼 후 감마 스테이지까지 푸시한 뒤에 감마 스테이지에서 하위 서비스의 안정 버전을 이용해 테스트하는 고육책을 쓰기도 하는데, 보통 알파->베타->감마로 내 변경사항을 옮기는 데는 시간이 소요되기 때문에 (테스트되지 않은 변경사항을 코드리뷰하는 데는 갑절의 시간이 든다) 전반적인 개발 속도가 지연되는 결과를 낳고 만다. 

 

이런 형태의 불확실성은 프로젝트 계획 단계에서 추정하기가 어렵다. 그렇기 때문에 많은 개발자는 이런 문제가 생길 것으로 예상되는 태스크에 좀 더 큰 버퍼를 방어적으로 할당하기도 한다. 이런 버퍼는 프로젝트의 규모에 대한 추정치를 보수적으로 만들기 때문에, 전체 부서의 생산성에 큰 문제가 있는 것처럼 보이도록 만들기도 한다. 

 

이런 문제를 방지하는 좋은 방법이 무엇이냐에 대해서는 이견이 있을 수 있으나, 많은 개발자는 보다 공격적이고 선제적인 테스트 전략이 없이는 이런 형태로 드러나는 불확실성이 양을 줄일 수 없다는 데 동의할 것이다. 개발자가 변경사항을 마스터 브랜치에 머지하기 전에 e2e로 변경사항을 테스트할 수 있도록 허락하는 어떤 물리적 수단의 도입 없이는, 여러 팀이 지연 없이 협업하는 것 또한 물리적으로 어렵다. 

 

Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2019. 9. 26. 14:00

앞선 글에서 불확실성을 관리하는 것이 곧 커리어 관리가 될 수도 있음을 살펴봤다. 불확실성 관리가 없는 계획은 곧 신뢰할 수 없는 계획으로 바뀌게 마련이고, 신뢰할 수 없는 계획을 내놓고 납기일을 약속하는 개발자는 곧 관리자와 다른 팀의 신뢰를 잃게 된다. 

 

그렇다면 불확실성은 대체 어떻게 관리해야 하는가? 

 

불확실성을 관리하는 방법을 알기 위해서는 보통 불확실성이 어떤 형태로 드러나는지를 살펴봐야 한다. 형태가 없는 것을 관리할 수는 없는 노릇 아닌가. 그러나 불확실성의 형태를 살펴보기 전에 먼저, 한 가지만 살펴보고 넘어가자.

 

우리는 프로젝트의 불확실성을 적정 수준 이하로 관리하기 위해 애자일 방법론을 도입해 왔다. 애자일 방법론은 (특히 스크럼은) 2주 단위의 스프린트마다 새로운 목표를 세우고, 그 목표가 완수되는 정도를 측정함으로써 팀의 속도를 평가하고 그 결과를 다음 계획에 활용한다. 이처럼 프로젝트의 실행 과정을 더 이상 잘게 쪼갤 수 없을 때 까지 쪼개는 행위는, 2주라는 기간 안에 완료할 수 있다는 확신이 서는 (다시 말해 그 규모에 있어서 불확실성이 거의 존재하지 않는) 작업만을 스프린트의 실행 대상으로 삼는다는 것을 전제한다. 간단하게 들린다. 

 

그러나 '2주라는 기간 안에 완료할 수 있다는 확신이 서는 작업만을 스프린트에 포함시키는' 것 자체가 이미 만만한 작업은 아니라는 것을 우리는 깨달을 필요가 있다. 왜 그런가? 

 

여러분이 여러 팀으로 구성된 어떤 조직의 일원이라고 해 보자. 보통 이 조직은 어떤 공통의 목표를 달성하기 위해 함께 움직이지만, 각 팀은 그 팀이 관리하는 소프트웨어의 특성에 따라 상이한 개발 체계를 따르는 것이 일상적이다. 한 팀에서 당연한 일이 어떤 팀에게는 전혀 당연하지 않다. 이 간단한 한 문장은 굉장히 많은 것을 의미한다. 예를 하나 살펴보자. 많은 팀이 이용하는 플랫폼 소프트웨어를 관리하는 팀 A가 있다. 이 플랫폼 소프트웨어는 운 나쁘게도 다른 팀으로 하여금 특정 모듈을 스스로 업데이트하도록 강제한다. 그 문제 때문에 팀 A는 매주 한 번씩 소프트웨어를 릴리즈하며, 다른 팀으로부터 접수되는 코드 리뷰 요청을 전담하는 온콜(on-call)을 둔다. 이 담당자는 일주일에 딱 이틀간만 다른 팀으로부터 접수된 코드를 리뷰한다. 이런 개발 체계는 CI/CD를 당연시하는 팀 B에게는 재앙에 가깝다. 코드 리뷰 요청을 제때 넣지 않으면 일주일을 날린다. 리뷰된 코드가 제 때 머지되지 않으면 또 일주일이 날아간다. 팀 B의 개발자는 이 문제를 제대로 숙지하지 않은 탓에 2주, 그러니까 스프린트 1회 분량의 시간을 날리고 매니저로부터 문책을 당한 경험이 있다. 

 

이런 형태의 불확실성은 조직 형태와도 밀접한 관련이 있다. 어떤 조직이 크면 클수록, 각 팀의 규모가 작으면 작을수록 이런 문제는 도드라진다. 우리는 이것을 보통 커뮤니케이션 오버헤드(communication overhead)라는 말로 퉁치지만, 그 실체는 훨씬 복잡하다. 

 

 

 

Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2019. 9. 23. 09:43

개발자로서 당신의 커리어가 서쪽으로 가는 것은 당신의 능력이 인정받지 못하기 때문이다. 능력이 인정받지 못하는 데는 여러가지 이유가 있지만, 그 가운데 가장 으뜸은, 당신이 약속한 일정이 번번이 어겨지는 것이다. 

 

왜 이것이 가장 큰 이유인지는 보통 회사라는 곳에서 납기일이 어떻게 관리되는지를 살펴보면 이해하기 쉽다. 

 

당신의 회사는 보통 몇 단계의 보고 체계를 따른다. 이 보고 체계의 상층부에서는 큰 그림의 우선순위를 정하고, 그 우선순위에 따라 납기 일정을 맞춘다. 보통 이 납기 일정은 아래쪽 팀이 보고한 추정치에 근거하는데, 이 추정치가 부정확하면 부정확할 수록 위쪽으로 보고되는 수치의 정확성은 낮아진다. 이 수치의 정확성이 낮아지면 프로젝트는 일정 대로 마쳐지지 못하게 되고, 그렇게 되면 누군가는 문책을 당한다. 일정에 맞춰 수립했던 사업 계획이 망가졌기 때문이다. 

 

이런 일이 자주 생기면 누군가는 문책성 인사를 당하게 되어 있다. 당신의 매니저가 이런 저런 이유로 파면되었다는 소식이 들린다면, 대체로 그것은 이런 이유 때문이다. 

 

그렇기 때문에 매니저들은 자신에게 화살이 돌아오는 상황을 어떻게든 피하려고 한다. 그렇다면 매니저는 과연 누구에게 책임을 돌리려고 할까? 아마 개발자일 것이다. 개발자는 매니저에게 일정 추산치를 제공하는 사슬의 가장 마지막에 위치하고 있다. 매니저는 개발자에게서 들은 대로 모든 일정을 역산한다. 

 

여기까지 이해하고 나면, 우리는 프로젝트 진행에 있어, 그리고 개발자의 커리어 관리에 있어서 가장 중요한 기술이, 프로젝트의 규모를 산정하는 데 있어서 불확실성의 수준을 평가하고 그에 비추어 계획을 수립하며 그 계획의 각 단계를 가급적 더 잘게 쪼갤 수 없는 단위로 분할하여 우선순위를 정하는 능력이라는 것 또한 미루어 짐작할 수 있게 된다. 

 

개발자의 능력을 평가할 때 아름다운 코딩 능력을 최 우선으로 삼지 않는다는 것이 많은 개발자에게 아마 부당하게 느껴질 수도 있을 것이다. 처음에는 너무나 단순하게 보였던 문제가 실제로 프로젝트가 진행됨에 따라 거대한 빙산으로 변모하는 상황은 그다지 드물지 않다. 그런 상황에서 프로젝트를 이끈 개발자, 그리고 결국 끈기있게 모든 것을 성사시킨 개발자에게 일정 지연 책임을 묻는 것은 그다지 온당하지 않다고 항의할 개발자도 많을 것이다. 

 

그러나 일정을 지키는 것은 개발자 이전에 직장인으로서 반드시 준수해야 할 사항이다.

 

밥 마틴은 이것을 Professionalism이라는 단어로 묘사했다. 그는 역저 "Clean Coder"에서 직업인이 반드시 가져야 할 이 '윤리'의식을 "commitment"에 대한 "responsibility"로 서술했다. 다시 말해 어떤 작업을 완수하겠다는 책임의식으로 묘사한 것이다. 

 

직장인에게 있어서 이 책임의식만큼 중요한 것은 없다. 직장에서 한 두 번 눈감아줄 수 있는 '실수'나 '실패'는 보통 이것을 말한다. 이것이 거듭되면, 보통 해당 직원은 저성과자로 분류되어 해고 수순을 밟거나 특별 교육 대상자로 분류된다. 이런 사람들은 보통 회사를 떠나고 나면 다시는 그 회사로 돌아가지 못한다. 최종 평가 기록이 회사 데이터베이스에 남기 때문이다. 

 

Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2018. 2. 4. 04:46

앞선 글에서는 커뮤니케이션에서 오는 스트레스를 개인적인 차원에서 다루는 여러가지 방법에 대해서 살펴봤다.


그러나 말했듯이 직장에서 생기는 커뮤니케이션 문제는 개인적인 차원에서 온전히 소거해버릴 수 있는 것이 아니다. 절에 가도 그런 스트레스가 있고, 수도원에 들어가도 그런 스트레스는 생긴다. 사람과 함께 일할 수 밖에 없는 것이 인간의 운명이므로, 어쩔 수 없는 일이다. 조직이 있는 한 어쩔 수 없는 스트레스다. 문제는 그 수준이 어느 정도냐다. 


커뮤니케이션 오버헤드가 어떤 임계치를 넘어서면, 조직원으로부터 대략 두 가지 정도의 반응이 나온다. 일이니까 어쩔 수 없다는 반응과, 대체 왜 그런 일에 업무 시간을 써야 하는지 이해하기 어렵다는 반응 정도로 요약할 수 있다. 회사에서의 커뮤니케이션도 업무라는 관점에서 본다면 두 번째 반응은 지나치게 개인적으로 비춰질 수 있다. 


그러나 그런 해석은, 회사에서 일하는 개인들을 지나치게 얕잡아 보는 것이다. 설마 그렇게 어려운 과정을 거쳐서 회사에 입사한 사람들이 일과 사생활도 제대로 구별 못하겠는가? (물론 간혹 가다 그런 사람도 있긴 하다.) 


따라서 두 번째 종류의 반응이 나오기 시작하면, 그런 반응을 보이는 사람들을 질책하기 보다는 그 반응이 어디서 오는지를 제대로 살펴야 한다. 그리고 이런 일은 조직이 해야 하는 일이다. 


조직의 책무


조직에게 이런 책무가 있다는 사실을 조직이 깨닫지 못하면, 다시 말해서 구성원의 스트레스 레벨 관리 또한 조직이 응당 신경써야 (not 전적으로 책임져야) 하는 부분임을 깨닫지 못하면, 그 조직의 구성원들은 아마 다른 직장을 찾기 시작할 것이다. 그런 일이 벌어지기 시작하면 해당 조직 입장에서도 힘들어지기 때문에, 미리 미리 관리를 하는 것이 좋다. 


이런 문제를 관리하는 좋은 방법 중 한 가지는, 관리자 레벨에 있는 사람들을 '관리'하는 것이다. 보통 대부분의 조직에서 커뮤니케이션의 허브 역할을 하는 사람들은 관리자이므로, 그런 사람들에게 있는 문제를 관리하는 것이 요령이다. 관리자가 커뮤니케이션 문제를 다루는 데 능숙하면 조직원들이 스트레스를 덜 받지만, 관리자가 아무 생각이 없거나 자기 멋대로면 그 관리자에 연결된 모든 구성원들이 대단한 피해를 보기 시작한다. 그리고 아마 실제로 관리에 들어가보면 확인할 수 있는 사실이겠지만, 대부분의 커뮤니케이션 문제는 대체로 관리자 때문에 생긴다 (목소리가 클 수 밖에 없기 때문이다).


따라서 관리자와 구성원 간의 상호작용 문제에 있어서 만큼은 상향평가를 어느 정도 하는 것이 바람직하다. 


문제는 상향 평가를 어떤 식으로 하는 것이 좋느냐이다. 한국은 암묵적인 도제식 군문화가 지배해왔던 사회라 상향 평가에 굉장히 민감했었지만 (대기업일 수록 더 그렇다) 최근들어 상황이 많이 바뀌기 시작한 것 같다. 따라서 어떤 식으로든 일단 커뮤니케이션 부분에 관해서 만큼은 상향 평가를 시작하고 보는 것이 좋다. 대부분의 IT 관련 개발조직에서 사람들에게 가장 많은 스트레스를 주는 부분이 커뮤니케이션이기 때문이다 (아마 대부분의 실무레벨 개발자들이 그럴 것이다). 


그러니 '어떤 식으로 해야 하지?'라는 문제에 너무 골몰하지 말고, 일단 하고 보자. 모 회사 처럼 트위터 스타일로 한줄 평만 받아도 좋다. 일단 하기 시작하면 큰 도움이 된다. 


IT 프로젝트의 어쩔 수 없는 오버헤드(?)들


조직 내의 커뮤니케이션 오버헤드를 적절히 관리하는 또 한 가지 요령은, IT 프로젝트 진행 과정상 어쩔 수 없이 겪어야만 하는 커뮤니케이션 오버헤드의 상당수는 (스탠드 업 미팅, 요구사항 회의, 디자인 리뷰, 코드 리뷰) 개인의 창의성과 시간을 측정 가능한 수단으로 환산하고 관리해야만 하는 '관리상의 필요' 때문에 어쩔 수 없는 부분이라는 것을 모든 개발자에게 납득시키는 것이다. 이런 오버헤드는 공장에서 공정관리를 위해 필수적으로 요구하는 절차와 같은 수준의 오버헤드기 때문에, 사실 제거할 수 없다. 그런 것 까지 안하는 조직은 보통 그만 그만한 수준의 소프트웨어만 만들어내다가 망하게 마련이고, 그런 곳에서 일하는 개발자는 보통 더 크고 유명한 회사에 가서 왕창 깨져보고 나서야 왜 그런 절차들이 필요했는지 깨닫는다. 


그리고 이걸 납득시키는 가장 좋은 방법은, 프로젝트 괸리에 숙달된 사람을 적어도 한 명 이상 프로젝트에 포함시키는 것이다. 보지 않으면 믿지도 않는 것이 사람 심리고 개발자들도 예외는 아니다. 프로젝트의 '공정' 관리가 어떻게 이루어지는 지 알도록 해야 잡음이 생기지 않는다. 기한에 맞춰서 납품만 하는 것이 소프트웨어 개발 프로세스가 아니다. 리스크를 지정 수준 이하로 괸리하는 것이 그 핵심이고, 그 노하우를 활용하지 않으면 결국 그 결과물로 가장 많은 피해를 보는 사람은 개발 당사자다. 그 사실을 똑바로 보도록 하는 것이 중요하다.


다음 글에서는 직장인의 커리어 관리에 관한 스트레스에 대해서 집중적으로 살펴보자. 


Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 이직 준비중인 2년차 개발자입니다.
    본문에 나온 내용에 공감하고
    그것 때문에 이직을 준비중입니다.
    좋은 글 감사합니다.

    2018.03.25 13:38 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2017. 12. 31. 11:21

앞선 글에서는 생각을 조금만 달리하면 스트레스에서 벗어날 수 있을지도 모른다는 이야기를 했다.


그러나 그렇게 쉬우면 스트레스가 아니다. 정말로 스트레스에서 벗어나려면 이것 저것 따져봐야 할 것이 많다.


스트레스의 한 가지 요인으로 '욕심'과 '자존감'에 대해서 이야기했다. 거의 모든 문제가 이 두 단어에 연결되어 있지만, 스트레스가 드러나는 표면적인 양상만 두고보면 그 두 가지로 쉽게 치환하기 어려운 문제도 많다. 


그 중 대표적인 것으로, 인간관계를 들 수 있다. 이 문제는 사실 굉장히 재미있는 문제다.


많은 사람들이 회사에 일하기 위해서 간다. 그런데 막상 입사하고 보니 정작 일로 받는 스트레스보다 사람 때문에 받는 스트레스가 더 많은 것 같다. 가령 이런 식이다. 


"저, 이 일을 작년에 진행하셨던 것으로 알고 있는데, 브리핑을 좀 해 주실 수 있을까요?"


"지금 바빠요. 담주 까지는 어렵습니다."


이렇게 나오면 그 일은 담 주 까지는 진행하기 어렵다. 좀 친절하게 이야기했으면 모르겠는데, 말투까지 으시딱딱하면 절로 열까지 받는다. 내가 저런 인간하고 같이 일하려고 그렇게 열심히 공부했나 싶다.


또 다른 사례를 보자. 이 번은 여사원의 경우다. 열심히 일하려고 입사했는데, 내가 비서인줄 아는지 커피를 타오라지 않나, 회식자리에서 술만 거나하게 취하면 정신머리를 안드로메다 너머에 널어놓고 왔는지 평소에는 꿈도 못꾸던 스킨십을 해 대는 동료들 때문에 스트레스가 이만 저만이 아니다. 


회식 다음날만 되면 정말 다들 꼴보기 싫고 일이 손에 잡히지 않는 것은 당연지사. 


이런 것도 당연히 인간관계 스트레스다.


이 쯤 되면 이런 말이 목구멍까지 올라온다.


"인간관계를 하려면 내가 SNS를 하지 회사에 입사했겠냐?"


앞 글에서 잠깐 언급했듯이, 인간은 자기가 가장 시간을 많이 쏟는 데서 스트레스를 받는다. 여러분이 인간관계에서 굉장히 다양한 스트레스를 받는다면, 그것은 그 회사에서 보내는 시간 가운데 상당수가 커뮤니케이션에 집중되어 있다는 뜻이다. 물론 회사가 코드 공장이 아닌 만큼, 회의 없이 또는 어떠한 형태의 커뮤니케이션도 없이 자리에 죽치고 앉아서 코드만 생산하는 식으로 꿈같이 일할 수는 없다. 하지만 이런 인간관계 스트레스가 회사 생활을 지배할 정도로 커졌다면 문제다.


그럼 이런 문제는 어떻게 해결하나?


아쉽게도 개인적인 차원의 노력만으로는 해결하기 어렵다. 


커뮤니케이션에서 오는 스트레스를 개인적인 차원에서 전부 해결하려면 도인이 되는 수 밖에 없기 때문이다. 


불가능하긴 하지만, 말이 나왔으니 그런 도인이 되려면 어떻게 해야하는지 한 번 짚어보고 넘어가자.


그런 도인이 되기 위해 갖춰야 하는 핵심적 역량은 다음과 같다.


  • 자기 자신을 회사의 부속품으로만 여길 것

  • 일에 지나치게 많은 개인적 가치를 부여하지 말 것

  • 나는 남보다 못하다는 마음 가짐을 '진심으로' 가질 것

  • 자기 일을 시간 내에 끝낼 수 있다는 것만을 중요하게 여길 것

  • 기술적인 말만 할 것

  • 아무런 생각 없이 즉시 신고할 것


그 각각의 의미는 사실 이 글을 읽는 각자 조금만 고민해도 쉽게 알 수 있는 것들이지만, 이 글을 읽는 모든 분들이 필자만큼 게으르다는 가정 하에 한 번 하나씩 짚어보고 넘어가보자.

첫 번째. 자기 자신을 회사의 부속으로만 여기는 마음가짐은, 자기 자신을 뭔가 중요한 존재로 여기는 마음가짐을 거세함으로써, 자존심이 상처받을 가능성을 최대한 낮춰준다. 진심으로 겸손하면 커뮤니케이션에서 스트레스를 받지 않는다. 보통 스트레스는 자존심이 조각날 때 찾아온다.

두 번째. 일에 가치를 부여하기 시작하면 커뮤니케이션 때문에 일이 지체되었을 때 스트레스를 받게 된다. 일은 일일 뿐이다. 그 일은 지구를 구하는 문제와는 대체로 아무 관련이 없으며, 데드라인이 오기 전까지 잘 마무리되기만 하면 여러분의 승진이나 성장에도 대체로 큰 영향을 미치지 않는다. (그 정도로 중요한 프로젝트를 하고 있다면 아마 이런 글 따위를 읽을 시간이 없을 것이다.) 

세 번째. 첫 번째와 크게 다르지 않다. 겸손한 자만이 밤에 쉽게 잠들 수 있다. 겸손하라. 숙면은 스트레스에도 그만이다.

네 번째. 두 번째와 크게 다르지 않다. 자기 몫의 일을 제 때 정확히 올바르게 끝내는 데만 집중하라. 그러면 '저 새끼 때문에 일이 지연되고 있어!' 라거나, '내가 저 인간 때문에 시간을 얼마나 낭비했는지! 왜 저 인간과 한 팀인거야!' 같은 생각에서 벗어날 수 있다. 이 글을 읽는 대부분의 독자들께서는 아마 관리자가 아니며, 그저 개발자일 것이다. 그렇다면 팀 내의 특정 직원 때문에 생기는 프로젝트의 지연은 관리자가 해결할 몫이지 여러분 문제가 아니다. 문제가 생기면 관리자에게 보고하고 그가 해결하도록 내버려 두자. 여러분 일도 아닌 일에 시간을 낭비하면 피곤해진다. 관리자가 해야 할 일까지 가로채면 곤란하다는 것이다 그렇지 않은가 관리자도 월급을 받는데.... 물론 관리자가 여러분에게 그런 일을 떠 넘겼을 때는 다른 문제다.

다섯 번째. 말했듯이, 사람은 가장 많이 시간을 쓰는 일에서 가장 많은 실수를 한다. 이 글을 읽는 여러분이 만일 다변가라면, 그 만큼 여러분 때문에 스트레스 받을 사람도 많을 것이다 (니가 몰라서 그렇지). 그러니 회식 자리가 아니라면 기술적인 이야기만 하도록 하자. 여러분이 쓸데 없이 내뱉은 말이 비수가 (스트레스가) 되어 여러분 가슴에 되돌아와 꽂히는 일이 없도록 하자. 

여섯 번째. 개인적 차원에서 해결하기 어려운 문제가 생기면 고민하지 말고 신고하거나 매니저에게 알리자. 물론 쉬운 일은 아니지만 인터넷 덕에 많은 것이 달라졌다. 세상이 달라졌음을 한 번 믿어보도록 하자. 

(다음에 계속) 


Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 좋은 말이네요 다음 글도 기대해봅니다 ㅎㅎ

    2018.01.16 09:42 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 주니어 개발자입니다. 좋은 글에 치유받고 갑니다!
    종종 들려서 치유하고 가겠습니다. 선배님.

    2018.01.18 01:54 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2017. 12. 28. 06:26

공기업 생활을 십삼년간 하고 팔자에도 없는 사기업 생활에 도전한지도 어언 삼년이 훌쩍 넘었다. 새해를 맞아 그 삼년 간 깨달은 것을 몇 번에 걸쳐 적어 보려고 한다. 오직, 그저, 까먹기 전에. 


아마 누군가에게는 도움이 될지도 모를 교훈들이지만, 이 글을 읽는 여러분들께서는 모름지기 '인생은 케바케'라는 대전제에 입각하여, 지나치게 심각하게 받아들이지는 말아 달라는 당부 말씀도 드리고 싶다. 세상에는 이 글보다 심각하게 따져봐야 할 문제들이 차고 넘친다. 이 글에서 말하려는 교훈들이 여러분의 성에 차지 않는다면, back 버튼을 누르면 그만이다. 스트레스 받지 마시라.


스트레스는 어디에서 오는가  


스트레스 없는 직장생활을 하기 위해서는 스트레스가 어디에서 오는지 부터 깨달아야 한다. 


좀 이상하게 들릴 수도 있겠지만, 스트레스는 보통 여러분이 잘 하는 것에서부터 온다. 잘 못하는 것으로부터 오지 않는다. 


여러분이 수영 초보자라고 하자. 수영 초보자가 수영을 잘 못하는 것은 당연하다. 그러니 매일 같이 물을 먹어도 스트레스를 받을 일은 좀처럼 없다. 물을 먹는 것이 당연하기 때문이다. 


수영 초보자가 수영에서 스트레스를 받는 것은 대체로 언제부터 시작되느냐면, '시간을 많이 투자한 것 같은데 실력이 좀처럼 늘지 않는다는 것을 깨닫는 순간'부터 시작된다. 다른 초보자가 보기에는 꽤 잘 하는 것 같은데, 자기 자신이 슬슬 부족함을 느끼기 시작하는 것이다. 그러면 스트레스가 생긴다. 


달리 말해, 스트레스의 근원 중 상당수는 '더 잘 하고 싶은 욕심'이다. 잘 하지만 더 잘 하고 싶은 것이다. 자신의 능력이 자기 기대에 못 미칠 때 스트레스를 받는 것이다. 


여러분 중 상당수는 단순히 먹고 살기 위해 개발자의 길을 택한 것이 아니라, 개발에 남들 보다 재능이 있는 것 같아서 개발에 뛰어들었을 것이다. 개발이 재미있는 일이었기 때문에 개발에 뛰어 들었을 것이다. 그런데 희한하게도, 직장을 잡고 일을 하는 순간 부터 개발이라는 것이 마냥 즐겁지만은 않은 일이 되어 버린다. 스트레스를 받는다. 힘들다. 왜인가? 


생각만큼 잘 되지 않기 때문이다. 


나름 잘 한다고 생각했는데, 동기에게 치이고 상사에게 지적받고 매니저에게 혼난다. 자존감이 낮아지고 자기 능력에 회의가 생긴다. 이러니 스트레스를 안 받을래야 안 받을 수가 없다. 힘들고 불행하다. 사는 게 사는 것 같지 않다. 


이런 스트레스는 어떻게 해소해야 하는가? 


이런 스트레스를 해소하려면, 당장의 자기 감정만 살피는 근시간적인 생각을 버려야 한다. 그리고 다음 사실을 받아들여야 한다.


  • 실패야 말로 가장 좋은 선생님이다

  • 깨지면서 배운 것들이 가장 오래 간다


어디서 많이 듣던 소리다. 뒤집어 말하면 케케묵은 공자님 말씀이란 소리다. 다시 말하면 하나 마나 한 소리이며 피부에 잘 와닫지 않는다는 소리이다.

그러나 이런 '하나 마나' 한 소리들이 그토록 오랫동안 인류 공통의 교훈이 된 데에는 다 이유가 있다. 

필자는 공기업 생활을 13년간 했는데, 이 기간 동안 한 가지 단언할 수 있는 건, 개발자로서 개인적 실패 경험이 0에 가까왔다는 것이다. 당연히 자존감(또는 자만심)이 하늘을 찔렀으며, 아마 많은 사람들이 뒤에서 '오만 방자한 인간 같으니'하면서 수근 댔을 것이나 듣지 못했다. 개발자로서 실패한 적이 없으니 당연히 스트레스 또한 0에 가까운 나날들이었다. 

그러나 지금 생각해보면 그 13년간은 개발자로서 나에게 해 준 것이 아무 것도 없다. 그 오만 방자했던 시간 덕에 사기업 이직의 꿈을 꾸었고 지금은 아마존 미국 본사에까지 와 있으니 딱히 아무 것도 해 준 것이 없다고 하기에는 좀 어폐가 있긴 하지만, 사기업으로 이직한 뒤에 내가 겪었던 오만가지 수모를 생각하면 '아무 것도 없다'는 말은 꽤 정확한 수사다. 왜? 내가 시니어 엔지니어로서 주니어들에게 보여줄만한 경험이 아무 것도 없다는 사실을 그 때 가서야 깨달았기 때문이다. 

개발자로서 실패하고 깨지는 경험을 좀 더 일찍 했으면, 40대 중반에 개발자로 살면서 이렇게 피곤하지는 않았을 것이다. 

자. 그러니 여러분이 지금 직장에서 굉장히 스트레스를 받고 있으며, 그것이 여러분이 매일 같이 겪는 실패의 경험 탓이라고 하자. 최소한 그것은 몇 가지 긍정적인 사실을 드러내 준다. 첫 번째는 여러분이 '더 잘 하고 싶은 욕심을 가진 인간'이라는 것이며, 두 번째는 그 경험들이 여러분을 진정한 개발자로 단련시켜주고 있다는 사실이다. 

그러니, 너무 스트레스 받지 마시라. 오히려 더욱 감사하게 생각해야 할 일이다.

그래도 스트레스를 받는다고?

그렇다면 그 원인은 다른 곳에 있다. 뒤 이은 글에서는 그 '다른 이유들'에 대해서 짚어보도록 하겠다. 




Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. ㅎㅎㅎ 하소연 잘 읽었습니다. 듣기 좋은 아무리 들어도 기분 좋아지지 않는 것도 공감하고요.

    https://coderlife.tistory.com/94

    전에 적었던 개발자가 피해야할 8가지 유형인데 함께 봐주시면 감사하겠습니다.

    2019.09.07 14:58 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2017. 9. 30. 15:36

시애틀에 처음 도착한 것이 9월 23일이니까 드디어 미국에 온지도 만 2년이 넘었다. 세월은 정말로 화살처럼 날아가 사라진다. 그 진부한 속담이 뼈속 깊이 사무치게 되면 나이를 먹은 거라던데, 드디어 정말로 나이를 먹은 모양이다. 


새로 배속된 부서는 음성 쇼핑 기술을 개발하는 부서다. 소위 '알렉사' 덕에, 아마존에서 가장 잘 나가는 부서가 되었다. 그래서 그런지 지원자도 많고, 사람도 그만큼 많이 뽑으려고 한다. 그러나 일주일에 서너번씩 면접관으로 뛰어도, 그 가운데 합격자를 보기란 여간 쉽지 않다. 인기가 많은 부서일수록 문턱도 높은 법이다. 그 문턱을 높이는 사람들은 바로 이곳에서 일하는 엔지니어들. 최고의 기술자들과 함께 일한다는 자부심이 있으니, 굳이 의식하지 않아도 문턱은 어느새 조금씩 높아진다. 그러니 그들을 만족시켜 함께 일할 기회를 잡기란 여간 어려운 일이 아니다. 나야 마음 넓은 매니저 덕에 운이 좋아 여기까지 왔지만, 그렇지 못한 사람들은 아마존의 '변방' 부서에서 허드렛 일부터 배워가며 이곳까지 오기도 한다. 그렇게 성장한 사람들일수록 깐깐하기도 그지 없다. 


조직이 급속도로 커지다보니, 한 개 층만 쓰던 부서는 어느새 서너개 층을 동시에 써야 될 정도로 덩치가 커졌다. 내가 속한 팀도 예외는 아니라서, 팀원들이 한 곳에 모여 앉을 수 없는 지경에 이르렀다. 보통 이런 지경까지 되면 부서에 할당된 공간을 늘린 후 자리를 재배치하게 되는데, 덕분에 어제는 짐을 싸버리고 일찍 퇴근, 오늘은 옮겨진 짐을 풀어 정리만 하고 (짐을 옮겨주는 직원들이 따로 있다) 다섯시에 퇴근했다. 내 자리는 조만간 책임 엔지니어로 승진할 거라는 소문이 무성한 능력 좋은 선임 엔지니어 옆 자리다. 보통 능력 좋은 사람이 창가 자리를 꿰 차고, 남은 사람들이 나머지 자리를 나눠 갖는다. 나는 다행히 그 친구 옆이라, 바깥 풍경에서 그다지 멀지 않다. 


나이가 들면 신기할 일이 없어진다는데, 나는 아직도 매일 매일이 신기하다. 매일 매일 새로운 사건이 터지고, 새로 배울 것들이 생기고, 새로이 적응해야 할 일들이 벌어진다. 그러나 그 가운데 가장 신기한 것은 내가 아직도 여기에서 일하고 있다는 것이다. 특히 나이 30 초반에 잘나가는 선임 엔지니어가 되어 있는 동료들을 보고 있으면, 정말 내가 어떻게 이렇게 오래 버틸 수 있었는지 의아할 때가 한 두 번이 아니다. 


그러나 오늘만큼은 몇명 없는 사무실에 조용히 앉아 한 가지 일에만 집중하며, 스스로에 대한 의구심이나 회의는 잠시 잊어버릴 수 있었다. 집중할 수 있는 시간, 조용한 시간은 그래서 중요한 것이다. 그런 시간이 많으면 많을 수록, 자기가 가장 잘 하는 일로 돌아갈 수 있기 때문이다. 제일 잘 하는 일을 자주 하면 자신감이 커진다. 자신감이 커지면 버티기 쉽다. 


Posted by 이병준
TAG 아마존

소중한 의견, 감사합니다. ^^

  1. 비밀댓글입니다

    2017.10.24 11:03 [ ADDR : EDIT/ DEL : REPLY ]
    • 남겨주신 글 잘 봤습니다. 좋은 학교에서 포스닥까지 하고 계신다니, 앞으로가 더욱 기대됩니다.

      적지 않은 나이에 미국으로 건너와 늦깎이 도전을 하고 있자니, 왜 사람들의 그토록 안정된 삶을 추구하는지 조금은 이해할 것 같은 기분입니다.

      하지만 그럴 때 마다 미국으로 건너올 때 했던 생각들을 되새기곤 합니다. '그 때 그 일을 저질렀더라면 인생이 어떻게 달라졌을지 궁금해하다 죽고싶지는 않다.'

      조금은 거창하게 적었습니다만, 매일 매일의 사투를 견딜 수 있게 해주는 나름의 신념을 나누고 싶었다는 정도로 이해해주시면 좋겠습니다.

      건승을 빕니다.

      2017.10.28 17:14 신고 [ ADDR : EDIT/ DEL ]

Thoughts2017. 9. 26. 06:54

미국에서 프로그래머로 일하려면 영어 문제를 어떻게 해결할 것인지 진지하게 고민해봐야 한다.


본인의 경우 영어 문제를 심각하게 생각하지 않았다가 시니어 개발자로 채용되는 바람에 첫 출근하는 날부터 영어 문제로 굉장히 고생을 많이 했다. 시니어 개발자에게 최 우선으로 요구되는 덕목 가운데 하나가 커뮤니케이션 기술이기 때문이다. 게다가, 현지에서 접하는 언어 장벽은 생각보다 굉장히 높았다. 커뮤니케이션이고 나발이고 간에 뭐가 들려야 일단 시작이라도 해 볼 것 아닌가... 당황스럽게도 정말 첫 한 달 간은 (사람마다 분명 다를테지만) 아무것도 들리지 않았다. 스탠드업 미팅 뿐 아니라 모든 중요 미팅에서 상대가 무슨 말을 하는지 눈치 코치를 동원해도 정말 아무 것도 알아들을 수 없었다. 


그래서 궁여지책으로 보이스레코더를 구입한 다음 동료들에게는 양해를 구하고, 참석하는 모든 미팅을 녹음하기 시작했다. 그리고 나서 출퇴근길에 듣고 또 들었다. 그래도 안들리는 건 안들린다는 걸 깨닫고 좌절한 날이 며칠이던가... (안습)


그렇게 고생에 고생을 거듭한 지 몇달 후, 드디어 무언가 알아들을 수 있게 되었다는 것을 남몰래 기뻐하면서 훌쩍거리던 날이 생각난다. 왜 아니 그렇겠는가. 미국에 와서 일에 적응하기도 힘이 드는데, 언어 문제를 해결하기 위해 오디오북을 사고, 듣고, 받아 쓰고, 그래도 안 들리는 것들은 죽어라 외우고, 그리고 졸린 눈을 비벼가면서 출근하고, 자신에게 실망하고... 이짓을 반복하다보면 초인이라고 해도 지치게 마련이다. 도무지 뭘 알아듣는 것 같지 않아 보이니 동료들에게 무시당하는 일도 다반사. 자존감이 바닥나면 무릇 항우라고 해도 자진의 길을 택하는 법. 정말 다 때려치우고 돌아가기 직전까지 간 날이 하루 이틀이 아니었다. 


해서, 미국길을 고민하는 많은 개발자에게 가장 먼저 조언하고 싶은 것 중 하나는, 영어 실력을 키우라는 것이다. 


내가 동원한 방법은 다음과 같다. 


* 신기술은 무조건 영어로 접할 것 (Coursera 강의, YouTube 동영상)

* 오디오북 받아쓰기 

* 현지인 대화 녹음하고 반복 청취 

* 원어민 멘토 구하기 

* 한국인 커뮤니티 회피

* 한국 방송 회피 (무조건 CNN/영어방송)

* 영어 라디오를 들으면서 따라할 수 있는 건 무조건 따라하기

* 적극적으로 영어 발표 준비


그러나 이렇게 해도 한동안은 굉장히 고생할 것이다. 미국 도착한지 이년이 지난 지금도 나는 고생하고 있다. 그래서 의식적으로 다음과 같은 것들을 하려고 애쓴다. 커뮤니케이션 문제가 나의 유일한 단점으로 받아들여지도록 만들기 위해서. 


* 팀원들을 위한 툴 고안하기

* 남들보다 코딩 많이 하기 / 좋은 코드 많이 짜기

* 같은 문제를 겪는 아시안계 주니어 개발자 멘토하기 

* 등신같은 실수를 두 번 이상 반복하지 않기 위해 노력하기 

* 팀 내 프로세스 개선에 적극적으로 참여하기 (특히 신입 개발자를 위한) 

* 시키지 않아도 알아서 하는 일 늘리기 


이렇게 해도, 나는 여전히 커뮤니케이션 문제를 나의 유일한 단점으로 만들 수 없다. 


그러니 뭐니 뭐니 해도 가장 중요한 것은 다음이다.


* 관두고 싶더라도 버티기 


버티기 앞에 장사 없다. 


Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. mulder

    '관두고 싶더라도 버티기' 마지막 문장이 확 꽂히네요. 직장생활을 견디기 위한 가장 큰 덕목이지요. 미국까지 가시게 될줄 몰랐는데 그 나이에 나라까지 옮겨 새롭게 시작하시니 정말 대단하다는 생각이 들고 존경스럽습니다. 저는 마흔에 건강문제가 생겨 쉬고 있습니다만... 언제나 기본은 건강! 부디 타국에서 건강하게 잘 지내시길 바랄게요, 홧팅요~

    2017.10.05 21:55 [ ADDR : EDIT/ DEL : REPLY ]
  2. 감사합니다 건강하세요

    2017.10.07 11:40 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2017. 3. 6. 15:34

지난번에 예고 하였듯이, 오늘은 바람직한 링크드인(LinkedIn) 이력서의 비결을 알아보자.


'바람직한 링크드인 이력서'란 무엇인가를 알기 위해서는, 내가 가고 싶은 회사에서 어떤 기준으로 이력서를 고르는지를 소상히 알아보는 것이 순서이리라. 


아마존을 기준으로 살펴보면 (다른 기업들도 대동소이하리라고 생각되지만), 대략 다음과 같은 기준으로 이력서를 고른다.


1. 어느 회사를 다녔나?

2. 어느 학교를 다녔나?


그러나 보통 2는 1보다는 덜 중요하다. 미국 리크루팅 팀이 한국 대학 순위에 대해서 별로 신경쓰지 않기도 하거니와, 보통 리크루팅 팀이 채용 대상으로 하는 주니어-시니어 엔지니어는 2년 이상의 경력을 가진 사람을 말하기 때문이다. 경력자를 뽑는 경우에는 대체로 어디에서 일했는지만 본다고 생각하면 된다. 따라서 위의 두 기준은 대체로 아래의 한 가지 기준으로 수렴한다.


1. 어느 회사를 다녔나?


자... 그러면 바람직한 글로벌 이력서를 만들기 위해서는 좋은 회사에 들어가야 한다는 역설적인 결론에 도달한다. -_- 


미국 현지 리크루팅 팀이 주로 보는 한국 기업은 다음과 같다.


1. 샘숭

2. 엘쥐

3. 네이버

4. 넥슨

5. 카카오

6. NHN ENTERTAINMENT

7. ... (생각하기 귀찮아서 이하 생략)


그러니까 여러분이 생각하는 바로 그 기업들을 미국에서도 주목하고 있다고 보면 된다. 


... 그러니 어쨌던 2년 이하의 비경력자는 미국 진출하기가 쉽지 않다. 일단 국내에서 2년 이상의 경력을 쌓도록 하자. 가급적이면 해외에서도 알고 있을만한 굴지의 소프트웨어 회사면 유리하다. 


이 글을 쓰고 있는 필자의 링크드인 이력서는 어떻게 생겨먹었을까? 아래의 링크를 보자. 


https://www.linkedin.com/in/bjlee72/


보시다시피 별거 있다면 있고 없다면 없는, 평범한 이력서다. 아마 이 이력서에서 아마존 이전의 가장 쓸만한 경력은 NHN ENTERTAINMENT일텐데, 아마존에서도 그거 한줄 보고 연락한 것 같다. 


그러니 해외 취업을 꿈꾸고 있다면 국내에서 좋은 기업에 입사해 최소 2년간 열심히 일하도록 하자. 그러면 좋은 해외 기업에서도 높은 확률로 연락이 올 것이다. 그러니 링크드인 프로파일은 절대로 한글로 적지 말자. 구사 가능 언어 목록에는 꼭 영어를 명시하자.


다음 시간에는, 모든 개발자에게 공통적으로 심각한 문제 가운데 하나인 '영어'에 대해서 잠시 살펴보도록 하겠다.




Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2017. 3. 3. 04:22

오늘은 미국에서 프로그래머로 일하는 방법을 알아보자. 그 첫 번째 시간이다. 


미국에서 프로그래머로 일하는 첫 걸음이 뭐라고 생각하는가?


미국에서 프로그래머로 일하려면 일단 미국에 가야한다. 


미국에 가는 방법은 여러가지가 있다.


1. 비행기

2. 배

3. ?


이 중 가장 쉬운 방법은 비행기를 타는 것이다. 물론 돈이 좀 든다. 이 돈을 내가 직접 내면 너무 아깝다. 그러니 공짜로 갈 수 있는 방법을 알아봐야 한다.


공짜로 가는 방법에는 여러가지가 있으나, 가장 보편적인 것은 출장일 것이다. 그러나 회사에서 돈들여서 출장을 보내줬더니 면접이나 보러다니고... 그러다가 ㅈ망하기 딱 좋다. 


가장 좋은 방법은 일단 면접에 합격하고 미국 취업 비자를 받은 다음 해당 회사가 지원해주는 트랜스퍼 패키지를 이용해서 미국에 가는 것이다. 그러면 죄 공짜다. 


그러니 결론은 하나 뿐이다. 일단 면접에 합격해야 한다. -_-


그러면 한국에서 면접에 합격하려면 어떻게 해야 하나?


한국에 자주 와서 대규모 채용 행사를 진행하는 회사를 눈여겨 봐뒀다가 면접을 보면 된다. 대표적인 회사로 아마존이 있다. 일년에 두어번씩 한국에서 채용 행사를 하니 그 기회를 이용하면 된다. 


한국에서 열리는 채용 행사를 통해 면접을 보는 경우, 대개의 경우 당일 바로 당락 통보를 받으므로 편하다. 


그런대 대관절 채용 행사에 초청은 어떻게 받나?


보통 아마존 같은 곳에서 채용 대상 직원을 물색하는 방법은 다음의 몇 가지다.


1. 링크드인 이력서

2. 아마존 직원을 통한 추천


따라서, 취업하고 싶은 회사에 아는 사람이 없으면 링크드인 이력서를 잘 써서 검색 대상이 되는 수 밖에 없다.


다음 시간에는 링크드인 이력서를 잘 쓰는 방법을 알아보자. 




Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 담덕

    우선 영어를 해야되죠? ㅠㅠ

    2017.03.04 13:48 [ ADDR : EDIT/ DEL : REPLY ]
  2. 다음 편이 기다려지네요. 다음 편에서 관리자님의 링크드인 이력서도 예시로 들어주시면 좋을 것 같습니다.

    2017.03.05 23:05 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2017. 3. 2. 13:45

프로그래머로서 새로운 일에 쉽게 적응하려면 어떤 마음가짐이 필요할까? 


1. '적응'에 대한 지나친 집착은 금물


빨리 적응해야겠다는 생각 자체에 지나치게 사로잡혀 있으면, 적응을 가로막는 어떤 일에도 스트레스를 받기 일쑤다. 게다가 적응을 이유로 프로그래밍 외적인 부분(가령 술자리 라거나)에 지나치게 시간을 많이 쏟게 되는 부작용도 생긴다. 적응해야겠다는 생각에 지나치게 얽매이지 말자.


중요한 것은 오히려 새로운 일이 주는 재미다.


2. 일에 대한 지나친 '소명의식'은 금물


일은 그냥 일일 뿐이니 일로서만 보자. 성공해야겠다거나 존경받아야겠다거나 하는, 뭔가 거창한 목적이 끼어들기 시작하면 부작용이 생긴다. 그 목적과 현재의 상태 사이에 간격, 또는 차이가 눈에 들어와서다. 그게 눈에 들어오기 시작하면 스트레스를 받게 마련이다. 현재의 상태에 대한 불만이 커지기 때문이다. 그러지 말자. 


3. 가장 중요한 것은 동료의 '신뢰'


사실 새로운 일에 적응하는 데 있어서 가장 중요한 것은 동료의 신뢰다. 팀원으로 일할 수 밖에 없다면, 가장 신경써야 하는 부분이다. 신뢰를 얻으려면 처음 3개월은 고생할 각오를 해야 한다. 그리고 나서는 그 고생을 바탕으로 다른 팀원을 도와줘야 한다. 독야청청해서는 신뢰고 나발이고 어렵다. 


4. 고난은 도전의 당연한 부산물이라는 사실을 받아들여라 


도전하지 않으면 고난도 없다. 고난은 도전의 댓가다. 아무런 고난 없이 적응하는 방법은 없다. 누구든 자기가 가장 잘 나간다고 생각하는 분야에서 삽질하고 좌절하게 마련이다. 거기에 가장 많은 시간을 쏟기 때문이다. 


따라서 생각을 좀 달리하면, 고난이 고난이 아닐 수도 있다. '아 뭐 어차피 겪게 되는 일인데 뭐'라고 생각하면 마음의 부담도 줄어들게 마련이다. 마음의 부담이 줄어들면 몸도 절로 편해지게 될 것이다.


5. 적응 기간에는 일에 많은 시간을 쏟자


스트레스를 내려놓은 상태에서 일에 많은 시간을 쏟으면, 자연스럽게 일을 이해하는 데 드는 시간도 줄어든다. 프로그래머로서의 경력에 가장 중요한 부분을 차지하는 것 중 하나가 '도메인 지식'을 확보하는 것인데, 도메인 지식을 쌓으려면 어쩔 수 없이 시간을 많이 들여야만 한다. 


게다가, 팀에 합류한 초반기에 일에 몰두하는 모습을 보여주면 팀원들의 신뢰를 얻는데도 도움이 된다. '저 친구는 뭐든 열심히 하는구나'라는 평판은 없는 것 보다 낫다. 


6. 주변 사람들의 평가에 너무 신경쓰지 말자


주변 사람들의 평가에 너무 신경쓰면, 쉽게 좌절하게 된다. 적응기에는 몇 번 정도는 병신취급 받아도 괜찮다고 생각해야만 한다. 


7. 관리자와 좋은 관계를 유지하자


프로그래머로서의 자긍심이 지나치게 높으면 매니저와 관계를 잘 유지하기 어렵다. 매니저가 하는 소리에는 엔간하면 귀를 열어 두고, '다 무슨 뜻이 있겠거니'라고 생각하는 것이 바람직하다. 'ㅈ도 모르는 인간이 누굴 가르치려 들어'라는 자세로 사람을 대하면, 언젠가는 그와 똑같이 당하게 마련이다. 


관리자도 인간이다. 귀를 열어주고 자기를 믿어주는 사람에게 마음을 여는 것이 인지상정이다. 적응기라면, 더더욱 관리자의 조언에 귀를 기울여 보자. 경력을 키우는 데 필요한 많은 이야기를 들려줄 것이다.


8. 자존심 너무 내세우지 말자


'내가 이 바닥에서 일한 시간이 얼만데 누굴 가르치려 들어'라는 자세를 유지하면 뭔가 새로운 것을 배우기가 어렵다. 상대방이 먼저 그런 식으로 나오지 않는다면 굳이 그렇게 굴 필요가 없다. 설사 상대방이 먼저 그런 식으로 나와도 그렇게 굴 필요는 없다. 의견 조율이 잘 안된다면 좀 더 조사한 뒤에 다시 토론해 보자고 하고, 연구해 본 다음에 결과를 나누면 그만이다. 


특히 중요한 것은, 옳은 의견이면 바로 수용하는 자세다. 상대방의 존경을 얻고 신뢰를 얻는 데는 사실 이만한 것이 없다. 게다가, 회사는 누구를 이겨먹으려고 나가는 곳이 아니라, 월급을 받은 만큼 일이 되게 만들려고 나가는 곳이다. 주어와 목적어를 혼동하는 일이 없도록 하자. 


게다가 적응기라면, 당연히 자존심 따위는 당분간 접어놔야 한다. 같이 일할만한 사람이라는 인상을 심어주려면, 겸손해지는 것이 바람직하다. 


9. 그래도 할 말은 하자


이게 가장 어려운 부분인데, 그래도 할 말은 해야 한다는 것이다. 그렇지 않으면 생각없는 사람 취급을 받기 때문이다.





Posted by 이병준
TAG 아마존

소중한 의견, 감사합니다. ^^

Thoughts2016. 10. 1. 07:19

시애틀에 온지도 일년이 지났다. 


<screaming>

아니 시발 일년이 지나다니! 벌써 일년이 지나디니! 

</screaming>


시애틀에 처음 왔을 때가 생각난다. 


<nonsense>

영어가 안되는 것 말고는 다 비슷하자나? 그래! 개발자가 일하는게 다 거기서 거기지! 아무리 아마존이 빡세다고 해도 한국에서 일했던 것 보다야 낫겠지! 그래 자신감 하나로 밀어 부치는거야! 

</nonsense>


그런 자신감으로 시작했던 아마존 생활은 곧 빈곤한 영어실력에 너덜너덜해지고... (묵념) 


아마 그 시절의 가장 큰 스트레스는 소위 시니어 스트레스가 아니었나 싶다. 시니어 개발자는 주니어 개발자의 존경을 받아야 하는 자리임은 물론, 여러 팀 간에 생기는 개발 이슈를 적절하게 조정하는 책임도 지기 때문이다. 그런데 말이 되어야 조정이고 나발이고 해 보지....  썅 


그러나 미국 생활을 처음 해 본다는 이유로 지나치게 친절히 모든 것을 이해해주었던 동료 개발자들과 매니저 덕분에  바닥이었던 자신감은 하루 하루 조금씩 회복되어가기 시작했다. 이 시기에 가장 큰 도움을 주었던 사람은 나와 direct report 관계에 있는 시니어 매니저였는데, 내가 시스템 전반을 이해할 수 있도록 적절한 프로젝트를 시의 적절하게 계속 찔러주었음은 물론 (거의 전방위로) 내가 부족한 부분을 2주 단위로 계속 지적해주어, 어디를 개선해야 하는지 고민하고 삽질하는 과정을 생략할 수 있도록 해 주었다. 가히 아마존 생활에 있어서의 가장 큰 은인이라고 봐도 과언이 아닌 셈. 


그래도 지난 일년을 돌아보면, 직전 직장에 비해 과히 힘들었다고는 할 수 없지만, 어쨌든 험난했던 것은 사실이었다.


10월~2월:

이 시기에는 거의 여섯시 반 기상 일곱시 출근 여덟시 사무실 도착 일곱시 퇴근의 강(?)행군! 누구보다 일찍 출근하고 누구보다 늦게 퇴근해주겠어! 이런 기상으로 넉달을 버텼다. 그러나 그런 기개에도 불구하고, 말이 통하지 않는 문제 때문에 대놓고 무시당하고 조롱당하기를 여러번... 날아가는 비행기를 바라보며 시발 집에 가고 싶어(갈 집은 있나)를 되뇌었던 날이 도대체 며칠이었던가.... 그러나 굴하지 않고 모든 이슈를 내 힘으로 해결해 보이겠다는 욕심에, 남들에게 묻는 대신 스스로 삽질하며 밤을 지새우기를 여러날...


3월~6월:

그렇게 삽질한 덕분인지 시니어 개발자 답게 팀내에서 생기는 이런 저런 이슈들에 대해 질문대신 대답을 해 줄 수 있는 역량이 쌓이기 시작한 것이 바로 이 때. 시애틀의 명물 가랑비가 그치고 황금같은 여름 날씨가 찾아온 덕분에 춥고 배고픈 출퇴근길을 졸업한 시기이기도 하다. 회의시간에 오고가는 이야기를 대략 80% 정도는 알아들을 수 있게 되었고, 그간 삽질에 공헌한 노고를 치하하는 상도 받았다 (Recognition Award 2016). 바닥이었던 자존감이 서서히 회복되었던 시기이기도 하다. 괴로움에 치를 떨며 잠못 이루던 시기도 끝나고, 머리만 대면 편안히 잠들 수 있게 되었다. 


7월~10월:

무척 편안하게 일할 수 있었던 시기. 어떤 식으로든 모든 팀원을 도와줄 수 있게 된 시기이기도 하다. 주도적으로 진행한 프로젝트도 생겼고, 마침내는 뭔가를 제안할 수도 있게 되었다. (제안한 프로젝트는 현재 디자인 리뷰 중이다.) 그러나 한국에 있을 때 부터 말썽이던 고관절 수술을 받는 사람에 7월 한달간 퍼포먼스는 바닥이었다...


그래, 그렇게 벌써 일년이 지났다. 


그래도 아직까지 끊임없이 묻는다. 대체 나는 왜 여기에 왔으며 왜 이렇게 힘들게 살고 있는가. 정말 내가 원했던 것은 무엇이고, 앞으로 이루고 싶은 것은 무엇인가. 


미국에 왔을 때 만 해도 그 모든 답을 알고 있다고 생각했으나, 지금 생각하면 그만큼 오만한 생각도 없는 것 같다. 그냥 하루 하루 성실하게, 즐거운 일을 해 나가며 버틸 뿐인 것이다...


그래도 시발 on-calld은 정말 버티기 힘들다.... 


Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 비밀댓글입니다

    2016.10.06 14:22 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2015. 11. 23. 15:57

미국에 오면 많은 사람들이 이케아에서 가구를 산다. 굳이 이케아에 가는 이유는 단 하나. 가구가 싸기 때문이다. 미국의 물가가 한국과 비교해서 싸다고는 하지만 월세 같은 부분은 분명 가당찮을 정도로 비싼 부분도 있고, 서비스 비용은 비싸기가 악명이 높을 정도이기 때문에 (의료비도 그 중 하나) 다들 절로 허리띠를 졸라매게 되는 곳이 이곳이다. 


이케아의 가구가 저렴한 것은 조립, 배송에 관한 부분을 고객이 책임지기 때문이다. 가구 자체의 품질로 보면 분명 경쟁력이 있는데도 불구하고 저렴하기 때문에, 많은 사람들이 찾는다. 그런데 그 가구를 힘들게 집으로 실어와 조립을 시작하고 나면... (묵념)


이케아 가구에는 소프트웨어와 비슷한 구석이 있다. 첫 번째는, 매뉴얼을 잘 읽어봐야 한다는 것이다. 대충 보고 조립에 착수하면, 부룸을 빼먹거나, 엉뚱한 곳에 꽂거나, 자재를 망치게 되는 일이 생긴다. 조립에 필요한 모든 것은 매뉴얼에 있고, 제대로 숙지하지 않아서 생기는 모든 문제는 온전히 고객의 책임이다. 그러니 이케아 가구를 조립할 때는 섣불리 조립부터 시작하는 대신, 매뉴얼을 처음부터 끝까지 주의깊게 완독한 다음에 덤비는 것이 바람직하다. 제대로 개발을 하고 싶으면 관련 문서를 정독해야 하는 것이나 비슷하다.


두 번째 비슷한 점은, 덩치가 작은 가구라고 반드시 조립하기가 쉬운 것은 아니라는 점이다. 실제로, 침대를 조립하기보다 서랍장 조립하기가 더 어렵다. 덩치가 작은 가구라고 해서 매뉴얼이 더 얇지도 않고, 부품이 더 적지도 않다. 침대 하나를 조립하는 부품들은 달랑 비닐봉지 하나에 포장되어 오지만, 서랍장 하나를 포장하는 데 필요한 부품은 비닐봉지 세 개에 포장되어 온다. 소프트웨어의 복잡성을 단순히 그 규모만으로 파악하기 어려운 것이나 비슷하다. 


세 번째로 비슷한 점은, 드라이버나 뺀찌 등의 기본 연장이 충실하면 작업 속도가 배로 빨라진다는 것이다. 전동 드릴이 있으면 제대로 조립할 가능성이 높지만, 막 드라이버 하나로 덤비면 밤을 샐 가능성이 높아진다. 제대로 된 공구를 갖추면 일이 편해질 뿐 아니라 작업 시간이 단축된다. 제대로 된 기술과 라이브러리를 갖추고 개발에 착수하면 일이 수월하게 진행되는 것이나 비슷하다. 


네 번째로 비슷한 점은, 제대로 표준화된 인터페이스가 있으면, 모든 작업이 예상 가능한 수순을 밟는다는 것이다. 이케아 가구 조립에 쓰이는 공구와 나사는 거의 전부 표준화되어 있고, 이용 방법이 비슷하다. 그러다보니 조립을 거듭하다보면 자연스럽게 숙련도가 올라간다. 잘 정의된 인터페이스를 갖춘 컴포넌트를 통해 개발을 진행하다보면 절로 속도가 올라가는 것이나 비슷하다. 


마지막으로 비슷한 점은.... 정작 조립을 진행하는 동안에는 언제나 


'시발 내가 왜 대체 이 밤 중에 이 짓을'


과 유사한 말들을 중얼거리게 된다는 점이다. 


그러나 조립 후 완성된 가구를 바라보는 뿌듯함은, 조립과정의 그 모든 괴로움을 상쇄하고도 남음이 있는 것이니... 그것이 바로 수많은 엔지니어들이 오늘 밤에도 삽질에 열중하게 되는 이유가 아닐까 한다. 



Posted by 이병준
TAG 시애틀

소중한 의견, 감사합니다. ^^

Thoughts2015. 11. 19. 06:11

지난 몇년간 써볼 기회가 없던 언어로 이런 저런 삽질을 하고 있노라면 역시 리팩터링의 백미는 다 만들어진 시스템을 뜯어고칠 때의 희열이라는 것을 새삼 깨닫게 된다. 


대개, 리팩터링 자체가 과제로 주어지는 모듈의 소스코드를 가만히 들여다보면, 어떤 공통점을 발견할 수 있다. 대체로 그런 모듈은 입문서의 소스코드 수준에서 시작했다가, 오류가 없다는 것이 검증되고 나면 수많은 이해 당사자들로부터 밀려오는 요구사항을 반영하는 과정에서 쓸데없이 커지고, 복잡해지고, 너덜너덜해진다. 요구사항이 접수되는 속도가 상상을 초월할 정도로 빠르기 때문에, 해당 모듈의 구조 자체를 검증하는 일은 자연스럽게 우선순위에서 밀린다.


"물론 명민한 개발자라면 중간 중간 불합리한 부분을 뜯어고치는 시도를 할 수도 있겠다. 그러나 대부분은 그런 시도를 포기하는데, 정말로 고칠 수 없어서라기 보다는 그 과정에서 API를 변경하게 되지는 않을까 두렵기 때문이다. API를 고쳐야 하는 일이 벌어지면, 해당 API의 소비자들과 이런 저런 조율을 하느라 굉장히 많은 시간을 소비하게 되기 때문에 어지간하면 피하는 것이다.... " 라고 이야기하는 것을 아마 이 글을 읽는 여러분도 많이 들어보셨을 것이다. 


"그러나 지금까지 겪어온 바에 따르면, 그런 이야기는 그저 핑계에 가깝다. API를 건드리지 않고도 상당수의 구조변경은 가능할 뿐 아니라, 하위호환성을 보장하기 위한 패턴을 따르면 신규 API를 도입하는 것 뿐 아니라 기존 사용자를 신규 API를 사용하도록 유도하는 것도 그다지 어렵지 않게 처리할 수 있다. 그냥 게을러서 안하는 것이다...." 라는 이야기를 하는 사람도, 아마 이 글을 읽는 여러분께서는 많이 만나보셨을 것이다. 


나는 어느쪽이었냐 하면 주로 후자 스타일로 말하는 사람이었다. 괜히 이런 저런 이야기를 하면서, 그 때 구조변경을 미뤘던 이유가 무엇이었는지 설명하는 사람들을 만나면, 어쩐지 방어적인데다 게으르게 느껴져서 별로 마음에 들지 않아하는 부류의 인간이었던 것이다. 덤으로 '니가 경험이 없어서 그렇게 말할 수도 있겠는데...'를 입밖에 내는 사람을 만나면, 그런 사람들은 아예 상종을 하지 않았다. 


그런데 지금에 와서 내가 그렇게 방어적인 개발자를 많이 만나고 실망했던 이유를 곰곰이 돌아보니, 아, 그건 전부 내가 지나치게 공격적이었기 때문이었던 것 같다. 공격적인 사람을 만나면 본능적으로 방어적이 되는 것이 사람의 본능. 내가 방어적인 사람을 많이 만났던 건 전부 내가 쓸데없이 공격적이었기 때문이었구나, 하는 생각이 드는 것이다. 


시애틀에는 공격적인 개발자는 드물다. 모두들 기꺼이 도와주려고 하고, 기꺼이 자기 의견을 나누며, 타인의 실수를 실수가 아니라 교훈으로 받아들이는 사람이 대부분이다. 아마 실패를 교훈으로 받아들이는 사회 분위기는, 바로 그런 태도에서 비롯된 것이 아닐까 싶다. 


그래서 다시 깨닫는 것은, 미국에 온 것이 내게는 자기개조의 기회이기도 하다는 것이다. 공격적이었던 나를 좀 더 겸손하고 차분한 사람으로 바꾸는 자기 개조의 기회.


"리. 요즘 너무 조용한데, 원래 그렇게 말이 없어?"


시발 영어가 안 되어서 닥치고 있는 거거든? 


아, 이렇게 한 일 년 살다보면 자연스럽게 공격적인 인간에서 차분하고 과묵하며 겸손한 인간으로 바뀌게 되지 않을까 싶다. 말이 많다 보면 자연스럽게 공격적인 사람으로 비춰지게 되기도 하는 법이니...


Posted by 이병준
TAG 시애틀

소중한 의견, 감사합니다. ^^

  1. 진지하고 나긋나긋한 듯한 문체 속에 빠져서 글을 읽다가
    꼭 말미 쯤에 터지는 '시X' 같은 욕설에 웃음이 빵터집니다. ㅎㅎ

    2015.11.19 10:18 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2015. 11. 14. 09:28

시애틀의 겨울은 춥다. 한국의 겨울에 비하면 춥다고 말할 수 있겠는가마는, 체감온도는 비슷하면 비슷하지 덜하진 않다. 가장 큰 이유는... 비다. 일주일에 하루 정도 쨍한 하늘을 볼 수 있을까, 그렇지 않으면 일주일이고 보름이고 계속 비가 내린다. 해를 볼 수 없다는 뜻이다. 


우산을 들기도 애매한 부슬비를 맞다보면, 그야말로 가랑비에 옷이 젖는다는 말을 실감하게 된다. 그렇게 일주일이고 보름이고 부슬비에 젖어 출퇴근을 하다 보면, 뼛 속 깊이 바람든다는 말이 무슨 말인지 느낄 수 있게 된다. 젊은 사람이야 그렇게 내리는 비를 낭만삼아 맞고 걸어갈 수도 있는 노릇이겠지만, 나처럼 사십대 중반의 개발자는 안그래도 안 저린 곳이 없는 마당에 비까지 맞다보면 절로 나이를 푸념하게 되고야 만다. 


"리. 한국의 겨울은 어때? 많이 춥다고 들었는데."


동료가 묻는다. 시발 여기도 만만찮다 임마 라는 말이 목구멍까지 나오다 들어간다. 


그래도 따뜻한 차 한잔을 나누며 동료들과 박터지는 요구사항 이야기를 하다 보면, 회의실의 열기는 사뭇 훈훈하다. 요구사항 회의가 그렇게 박터지는 이유는, 잘못된 요구사항을 두고 시간낭비를 하지 않기 위해 모두들 지극히 신중하기 때문이다. 물론 이런 분위기는, 나처럼 일단 코드부터 저지르고 보는 낙관적인 개발자에게는 그야말로 속터지는 분위기라고 하겠으나, 이해 당사자가 워낙 많을 때는 그 이해관계를 잘 조율하고 보는 것이 프로젝트 관리의 기본인지라, 오히려 속터져하는 나같은 사람이야 말로 욕을 먹어 마땅한 사람이라고 하겠다. 


"리. 한국에서 했던 프로젝트는 어땠어? 삼성같은 데는 많이 힘들다고 들었는데."


동료가 묻는다. 삼성 안다녔다 임마 라는 말이 목구멍까지 나오다 들어간다. 


한국에서 했던 프로젝트와 다른 점을 굳이 한 가지 꼽으라면, 여기서는 한 디파트먼트의 관리자 쯤 되기 전에는, 여러 프로젝트에 동시에 영향력을 행사하라는 요구는 하지 않는다는 점이다. 시니어에게 요구하는 것은 보통, 한 프로젝트에 관계된 여러 부서의 이해 관계를 잘 조율하는 것 정도다. 하나의 프로젝트에 관계된 사내 부서가 워낙 많은 것이 보통이니 그렇게 하는 것이 당연하다. 여러 프로젝트를 동시에 관리하는 역할을 맡기고 싶으면, 보통 그 만한 권한을 갖는 자리를 주는 것이 상례다. 그런 자리를 맡길 수 있을 때만 진급시킨다. 진급시킬 수 없어 보이면 그냥 성과에 따라 적절한 보상을 해주는 것이 일반적이다. 기술적인 리더십이 탁월한 사람은 보직과 관계없이 진급시키는 경우도 있는데, 그런 사람은 '존경'이라는 무형의 보상까지 덤으로 받는다. 


본격적으로 날씨가 구려지는 가운데 코딩과 디버깅이라는 삽질을 하다보니 손가락과 어깨에 시발 힘들어요 라는 신호가 슬슬 오기 시작한다. 그래도 한 가지 다행인 것은, 코딩과 디버깅을 번갈아 하다보면 열이 받아서 머리부터 슬슬 뜨끈해지는 통에, 시애틀의 겨울을 잠시나마 잊을 수 있다는 것이다. 


석달 기한으로 받은 일거리의 첫 번째 Phase가 끝나간다. 외벌이라, 미국까지 왔어도 살림이 확 피지 않는 것은 한국에서 직장을 옮겼을 때와 마찬가지다. 그러다보니 졸라 열심히 일해서 보너스라도 듬뿍 받아야지! 하는 생각에 사로잡히게 된다. 아 시발 이 일을 빨리 끝내야 인정 받을텐데... 이러고 있는 것이지. 


"리. 요즘 왜 그렇게 자리에서 안 일어나? 일이 그렇게 많아?"


동료가 묻는다. 너처럼 혼자 벌어 혼자 먹는 사람이 내 심정을 어찌 알겠냐. 




Posted by 이병준
TAG 시애틀

소중한 의견, 감사합니다. ^^

  1. 안녕하세요

    글에서 힘듬이 느껴지네요.

    2015.11.16 16:18 [ ADDR : EDIT/ DEL : REPLY ]
  2. 글 잘 보고 있습니다. 날씨가 추워지다 보니 건강 관리가 제일 중요한 것 같네요. 제가 다니는 학교 연구실에서도 감기, 장염, 디스크 환자들이 속출하네요.

    2015.11.17 17:46 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 네쯔

    매번 눈팅만 하다가 'X발' 이 많은것을 보고 힘내시라고 한마디 드리고 싶어서 글 남깁니다.
    항상 재밌게 잘 보고 있습니다~

    2015.11.20 11:22 [ ADDR : EDIT/ DEL : REPLY ]
  4. 오하이오공돌이

    오래 전 무슨 이유로 (아마도 프로그래밍 관련 소설을 읽었던 것 같습니다. 혹시 올림푸스 카테고리가 그것이었던가요?) 북마크에 등록해 놓았었습니다. 우연히 북마크 정리하다 방문해 보았는데 올해 미국으로 이주하셨네요. 전 2005년 미국에 가족들과 나온 공돌이(광학분야)입니다. 현재는 오하이오 클리블랜드 근방에 거주중이고요. 미국 처음 나온 곳은 플로리다 올랜도였는데 원치는 않았지만 10여년간에 걸쳐서 이번이 벌써 네번째 장소입니다 (플로리다-뉴욕주-매사추세츠-오하이오) 곳입니다.

    글들을 보면서 처음 미국에 나왔을 때의 막막함과 좌충우돌하던 시기가 생각이 나네요. 그래도 저보다는 좋은 곳(시애틀)에 정착하셨으니 (적당히 미국식으로 시골스러우면서도 적당히 한국식의 번잡함도 있는 곳?) 가족들과 행복하게 지내시길 바랍니다. 저랑 연배도 비슷하시고 (제가 쪼~끔 더 들은 것 같습니다만 ^^) 해서 친구처럼 알고 지내고 싶네요. 개인적으로는 미국에서는 한인들을 가까이 하지 않으려는 편입니다만, 이공계열의 분이시라면 통하는 것도 있을 것 같고 해서 글을 남겨봅니다. 반갑습니다.

    2015.12.06 22:33 [ ADDR : EDIT/ DEL : REPLY ]
    • 반갑습니다. 혹시라도 개인적으로 연락하시고 싶으시다면 byungjoon.lee @ gmail.com을 이용해주시면 감사하겠습니다. :-)

      2015.12.09 06:25 [ ADDR : EDIT/ DEL ]
  5. 오하이오공돌이

    미국 회사 보너스 짜던데요. 물론 회사마다 다르겠지만요. 지금 세번째 회사(한번은 회사가 다른 더 큰 회사에 머징되어 relocation까지 한 경우 포함해서요)인데 보너스는 한국보다 못하더라고요. (삼성에 다녔었습니다) 다만 base salary는 좀 낫고, 대신 세금은 겁나 많이 떼이고요. 저도 혼자 벌다 보니 항상 버겁더라고요. 요즘은 슬슬 투잡, 쓰리잡 고려중이고요.

    2015.12.07 02:47 [ ADDR : EDIT/ DEL : REPLY ]
  6. 삼성 안 다녔다 임마 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

    2016.01.09 14:03 [ ADDR : EDIT/ DEL : REPLY ]