야근은 처음에는 일정에 쫓기기 때문에 해야 하는 것으로 생각되기도 하지만, 나중에는 “어차피 밤에 하는데 뭐 하러 낮에 열심히 해” 하는 생각에 잡힌다는 것은 이미 잘 알려진 사실이다. 이는 시간을 낭비하는 것으로 개인 조직 모두 피해야 할 것이다. 시간 낭비만큼 무의미한 것은 없기 때문이다.
일의 량을 계산해서 시간 분배(타임 슬라이싱)을 잘 해서 야근을 피할 수 있는 방안을 먼저 찾는 것이 좋다. 엄청난 압박의 업무가 밀려오더라고 하루 8시간 모두 타이트한 시간을 보내는 것은 아니다. 한 4시간만 집중하면 모든 일이 가능하다고 생각한다. 오전에 두 시간, 오후에 두 시간 딱 이렇게 집중하면 대부분 일이 처리되도록 노력한다. 이는 개발자 개개인의 노력도 필요한 일이지만, 관리자가 일이 그렇게 처리 될 수 있도록 도와주어야 한다. 지식 노동의 경우 하루 1시간 이틀 동안 일하는 것과, 하루에 두 시간을 몰아서 일하는 것과 어느 쪽이 더 효율적인지는 업무에 따라 다르다. 하지만 연속적인 2시간을 할애하는 것이 더 효율적인 경우에, 이를 이틀에 걸쳐 진행했을 때 소요되는 시간은 2시간이 아니고 3시간에 가까울 것이다.
어떤 업무를 진행시키는 과정을 살펴보면, 제일 먼저 해야 할 일이 “그 업무는 무엇인가”에 대한 정의이다. 무엇을 하라고 했는지, 무엇을 알아야 이 업무를 할 수 있는 것인지 정확히 판단하는 것이야 말로 업무를 성공시키는 키 포인트임에 분명하다. 이런 관점에서 볼 때, 업무파악이 안되어서 오버타임을 해야 한다면 그것은 해야 한다. 완전히 파악하기 위해서는 일정기간의 긴 집중을 필요로 한다. 대부분의 기업에서 낮 시간에 이런 긴 연속적인 시간을 얻기는 거의 불가능하다. 낮에 연속적인 시간을 얻을 수 없다면 야근이 필요하다면 해야 한다. 업무를 파악하는 과정은 완전히 숲을 만드는 과정이며, 이 과정이 진행되는 동안에는 모든 일이 진행되지 못한다. 따라서 일정을 줄이기 위한 목적으로 오버타임을 하는 것은 나쁘지 않은 선택이다. Flexible 시간제를 운영한다면, 16시간을 Full time으로 일하고 다음 날 쉬는 것도 고려해 봄 직하다.
또 한가지 오버타임을 허용할 수 있는 경우는 업무 종료 시점 전 1주일 정도. 늘 이야기하는 막판 스퍼트. 이것도 매일 하는 것은 좋지 않으며 이 경우에라도 최대한 피할 수 있도록 시간 분배를 잘 해야 하겠다. 관리자가 알아야 할 것은 이 기간 내에 개발자 1명이 어떤 문제를 잡고 있는 경우, 두 명, 세 명을 더 투입한다고 해서 일정이 휙휙 줄어드는 것이 아니라는 것이다. 두 명, 세 명이 더 투입된 경우 어떤 과정을 겪어야 할까? 우선 먼저 문제를 잡고 있는 개발자가 나머지 개발자에게 문제에 대한 정의, 현재 진행 상황, 타겟 등을 잘 설명해야 한다. 이렇게 되는 경우는 베스트이다. 하지만 애처롭게도 문제를 잡고 있는 개발자는 문제가 뭔지 잘 모른다. 경력 1년 미만의 개발자가 문제를 잡고 있던 사람이라면 이는 100프로 관리자 잘못이다. 애처로운 경력 1년 미만 개발자는 자신이 한 일에 대해서 명확하게 나머지 두 명의 개발자에게 알려주고 물러나게 하자. 현실에서 이런 경우를 보면 진짜 애처롭다. 어찌 되었든 이런 상황에서도 문제를 정의하는 데 총력을 기울여야 할 것이다. 관리자는 별로 좋아하지 않는다. 이미 어느 정도 누군가가 진행하던 일인데 왜 다시 정의하는 미친 시간 낭비를 하느냐고 물어볼 것이다. 만일 제대로 된 개발자로서 문제를 해결하고 싶다면 약간의 눈속임을 해서 문제를 해결하는 척하면서 뒤로는 처음으로 돌아가서 정의를 다시 하면 된다. 그렇지 않은 개발자라면 그냥 하는 척 하면서 엉뚱한 원인을 끌어내면 된다. 두 가지 모두 문서상으로 문제는 해결된다. 어떤 것을 선택하는 가는 능력이 아니라 문화에 달려있다.
어떤 경우 정작 야근을 하는 이유는 유교적 정서에 따른 미안함이다. 동양적인 전체주의에서는 남이 어려움을 같이 겪는 것을 미덕으로 생각하는 경향이 있다. 이 부분은 팀웍 차원에서 바람직하다. 하지만 자발적이어야 하며 실질적인 도움을 줄 수 있는 사람들이 남아 있어야지, 관련도 관심도 없는 사람들은 있을 필요가 없다.
이 상황에서 누군가가 상사에게 “퇴근해야겠습니다” 라고 이야기를 하는 것을 들었을 때 거부감을 느낀다거나 불안함을 느끼는가? 그리고 스스로 “퇴근해야겠습니다”라고 이야기를 하는 것에 대해서 죄책감을 느끼는가? 그냥 가는 옆 사람에 대해 뻔뻔함을 느끼는가? 야근은 술자리와 같이 남아서 같이 죽도록 퍼 마셔야 하는 건가?
오버타임이 때로는 보험이 된다.
조직적 관점에서 본다면 “우린 밤까지 새고 정말 최선을 다 한 것이야”라고 당당히 이야기할 수 있을 것이다. CEO는 스마트 워킹을 이야기하지만, 중간 관리자는 스마트 워킹하는 사람의 평가를 떨어뜨린다. 이 이야기는 “대한민국 개발자 희망보고서”와 “훌륭한 프로그래머의 딜레마”에서 볼 수 있드시 정확한 현실을 대변한다. 이러한 현실에서 “우린 스마트하게 일했어”라고 이야기하는 바보 조직이 있을까?
프로젝트가 난황을 겪는다 사실 모든 것이 뒤죽박죽인 곳에서 난황을 겪는 것은 매번 발생할 수 밖에 없다. 조직의 리더들은 이 때쯤이면 가두고 잠 안 재우기 신공을 발휘한다 가둔다 쫀다 집에 못 가게 한다. 이 삼대 만능 전략이 프로젝트를 그들의 의미에서 성공적으로 마치는 방법이다. 이제는 더 이상 이 방법에 대해 의구심 조차 갖지 않는다.
실패한 경우나 문제가 터진 경우 위에서는 아래 사람들에게 묻는다. "뭐가 문제야 누가 할 수 있어 어떻게 해야해" 가 아니라, "지금까지 뭐했어 잠이나 퍼 자고 이 바보 같은 것.” 밤을 새든 안 새든 이러한 욕은 꼭 듣는다 하지만, 당신은 이 말을 듣더라도 상사가 더 막 대하지 못하게 하려고 밤을 세는가? “난 밤까지 샜어, 씨바, 머리 못 감고 눈 빨간거 안보여?”
이는 심지어 “파블로프 효과”를 이끌어낸다. 대개 처음 모여서 같이 일하는 것은 잘 된다. 그리고 스트레스가 발생하면 그것을 피할 수 있는 방법을 고안해 내기 때문에, 문제가 해결된다. “모였다. 해결되었다. 또 모으자”. 관리자의 파블로프 효과가 탄생한다. 스마트 워킹과는 전혀 다르다. 하지만 이 방법을 대신할 무언가를 찾기 전까지는 오로지 앞만 보고 “모은다”.
오버타임이 인사 평가 기준이기도 하다. 어떤 관리자는 직접 이런 이야기를 한다. “당신들 누가 일 많이 하고 누가 일 적게 했는지 어떻게 평가해? 야근 많이 하고 특근 많이 한 사람이 당연히 일을 많이 한 것이지 않나?” 맞는 말 같다. 그런데 관리자는 오버타임이 많은 사람들의 일을 줄여줄 노력은 하지 않는 것 같아 아쉽다.
외국 회사의 경우 오버타임을 하는 사람은 무능력한 사람이라는 평가를 받는다. 오죽 못났으면 정해진 시간에 일을 다 못 끝내느냐는 것이다. 과업이 명확한 경우 타당한 말이다. 하지만 과업이 불명확하며 관리자가 새벽에 전화 거는 것이 어쩔 수 없는 것으로 생각되어 지는 현실에서 오버타임은 왜 해야 하는지도 모르는 과거의 짐을 그대로 지고 가는 것일 뿐이다.