중학교인가 고등학교 때로 기억합니다. 저는 보통 학생들과 다름없이 밤 늦게 집에서 공부를 하고 있었습니다. 당시 저희집과 가깝게 지내던 모 대학의 영문학과 교수님이 계셨습니다. 미국인이고 나이가 그리 많지 않았고 SF 소설 팬인데다가 유머러스하기까지 해서 저랑 죽(?)이 잘 맞았습니다.
책상에서 왼쪽에 책 펴놓고 오른쪽에 연습장 펴놓고 공부하다가 저도 모르게 깜빡 잠이 들었나 봅니다. 책상 위에 엎드려서 잠을 자고 있었습니다. 물론 오른팔을 필기하던 자세 비슷하게 벌려놓고요.
그 교수님이 그 동안 저희집에 다녀갔나 봅니다.
잠에서 깨어서 다시 공부를 시작하려고 했습니다. 어, 그런데 펼쳐진 연습장에 중앙에 제 글씨체가 아닌 게 뭔가 씌여 있더군요.
Don’t study hard.
어 라라! 열심히 공부하지 마라? 저는 무척 놀랐습니다. 누구야? 아, 맞다 교수님이 다녀가셨나보다. 장난을 치신 거로군. 저는 그냥 무시하고 빈 여백에 글자를 쓰며 공부를 계속했습니다. 연습장이 다 차서 다음장으로 넘기자 마자 또 다시 보이는 교수님의 글씨! 에이 또 뭐야!
Study well.
아아아! 절묘하게 두 개의 문장이 시차를 두고 절 찾아온 것입니다. 머리 속에서 범종이 울렸습니다.
앞 페이지에 적힌 Don’t study hard의 의미가 이젠 다르게 해석되었습니다. 동시에 Study well도 독자적 의미가 아니고, Study hard와 댓구를 이루면서 새로운 의미를 갖게 되더군요.
Don’t study hard는 두 가지 뜻으로 해석할 수 있습니다. 열심히 공부하지 마라, 혹은 힘들게 공부하지 마라.
Study well도 두 가지로 해석할 수 있습니다. well을 방법적인 면에서 보면 “공부 자체를 더 효율적인 방법으로 해라”. 결과적인 면에서 보면 “어쨌거나 공부 잘 해라”.
이에 대해서 그 교수님과 다시 이야기할 기회는 없었습니다. 아마 저는 충분히 의미가 통했다고 생각을 했나봅니다.
교수님의 don’t study hard; study well은 그 때 이후로 저에게 아주 중요한 명언이 되었습니다. 화두라고 할까요.
우 리는 문화적으로 뭔가 효과적으로 해보려는 노력을 천시하고 그냥 어려워도 힘들어도 묵묵히 열심히 하는 것을 더 쳐주는 경향이 있습니다. “저는 밤새도록 코피 터져가면서 공부했어요”라는 이야기를 하는 아이들은 잘했다고 칭찬을 받고 가치 평가로까지 이어져서 인간성도 훌륭하다고 인정 받습니다. 반면에 놀아가면서 쉬엄쉬엄, 하지만 효율적인 방법을 찾아가며 공부했다는 아이는 요령 피운다고 하거나 재주를 너무 믿는다는 식으로 그 아이의 노력, 성과, 인성 모두 깎아 내리기 일수입니다.
하지만 저는 늘 공부하면서 study well을 고민해 왔습니다. 어떻게 하면 더 재미있게 더 효율적으로 할 수 있을까. 콜라병을 따면서도 “어떻게 해야 잘 했다고 소문이 날까”라는 유행어를 남발하던 시절처럼 말이죠. 그래서 결국 지금 일까지 연결되고 있나 봅니다. 지금은 조금 확장해서 don’t work hard; work well을 고민합니다. (물론 study well도 여전히 중요한 화두입니다.)
일에 대해서는 오래된 격언이 있습니다.
It’s better to work smart than to work hard.
소프트웨어 공학의 스타, 스티브 맥코넬은 쾌속 개발에 대한 10가지 미신이라는 제목의 발표자료에서 말합니다. 마이크로소프트는 그 격언을 다음과 같이 바꿨답니다.
It’s better to work smart and hard.
아마존은 거기에 한 수 더 했습니다.
It’s better to work smart and hard and long.
그러면서 왜 이 전략이 멍청한 결과를 내는지 설명하며, “Work smart, not hard”는 여전히 유효한 말이라고 결론 내립니다.
우 리 욕심은 끝이 없죠. 많은 회사는 직원들이 똑똑하게 일하면서 열심히, 그리고 오래 일하기를 바랍니다. 열심히나 오래 일하기가 생산성에 도움이 될 거라고 믿습니다. 한 발 물러서서, 열심히나 오래가 똑똑하게 보다 생산성이 못하다고는 해도 뭔가 플러스가 될 것이라고 믿습니다.
음의 생산성(negative productivity)이란 것이 있습니다. 일을 많이 하다보면 어느 순간 실수를 저지르기 시작합니다. 그런데 지식 노동에서는 그 실수를 나중에 찾아내는 것이 쉽지가 않습니다. 스티브 말에 따르면 평균적인 소프트웨어 개발 프로젝트는 비용(시간, 인력 등)의 40%에서 80%를 이런 실수(결함, 즉 버그가 되겠죠?)를 잡아내는 데에 쓴다고 합니다. 과다하게 업무를 하다보면 debug(버그 제거)가 아니라 자기도 몰래 enbug(버 그 삽입)를 하게 됩니다. 이때부터는 음의 생산성이 됩니다. 즉, 내가 한 시간 일하면 프로젝트는 열시간 할 일이 늘어납니다. 왜 일대일로 시간이 대응되지 않냐구요? 적어도 소프트웨어 개발에서는 결함 삽입에 걸리는 시간과 그걸 고치는 데 걸리는 시간에는 막대한 차이가 있으며, 결함 직후에 바로 고치면 몰라도 그 시기가 늦춰지면(즉 나중에 결함을 발견하고 수정하려고 하면) 통상 비용이 50배에서 200배 커지는 것으로 알려져 있습니다.
고되게 일하는 것이 인지적으로는 어떤 영향이 있을까요? 바로 생각나는 것은 일이 많아지면 잠을 적게 잘 것이고, 학습과 고도의 지적활동에 수면이 차지하는 위상(최근의 연구들을 통해 수면의 중요성은 훨씬 더 높아졌습니다)을 생각해 볼 때 분명 큰 문제가 있을 겁니다. 몇가지 연구를 인용해 보죠.
The reaction time of residents who had just finished a month of heavy work schedules was 7 percent slower and they committed 40 percent more errors than when they were on a month of light schedules,
Wake Up, Doc: Lack Of Sleep Affects Young Doctors Just Like Alcohol Does
장시간 일하는 레지던트들에 대한 연구입니다만 소프트웨어 개발 업종에 종사하시는 분들에게도 똑같이 적용이 될 거라고 생각합니다.
이런 연구들을 잘 정리해 놓은 글도 있습니다. Why Crunch Mode Doesn’t Work: 6 Lessons
XP의 아버지 중 한 사람인 론 제프리즈(Ron Jeffries)도 이에 대해 글을 썼습니다.
A common effect of putting teams under pressure is that they will reduce their concentration on quality and focus instead on “just banging out code”. They’ll hunker down, stop helping each other so much, reduce testing, reduce refactoring, and generally revert to just coding. The impact of this is completely predictable: defect injection goes way up, code quality goes way down, progress measured in terms of net working features drops substantially.
다음은 좀 자극적인 결과입니다.
After 17 to 19 hours of staying awake — a normal working day for many people — reaction times are up to 50 percent slower than they are after drinking alcohol …… The effects of fatigue are thought to play a part in almost two-thirds of the road accidents in the United States, say the authors. Extended working hours, shift work, and lifestyle choices are likely to decrease the amounts of sleep we have, they conclude. The effects, which are likely to be cumulative, pose a serious risk to safety, they say.
Long Working Days With Too Few Hours’ Sleep Slow Responses As Much As Alcohol
여러분 중에 음주 코딩 하시는 분은 별로 없을 것이고 그걸 회사에서 허락하는 곳은 더 드물 겁니다. 그런데 “밤샘해서라도 일해라”고 시키는 회사는 사실 “술 먹고 코딩해라”고 말하는 것과 큰 차이가 없다는 연구 결과입니다.
음주 코딩이 있나 하면 마약 코딩도 있습니다. 회사가 직원에게 과도한 업무를 지우는 방법 중 하나가 멀티 태스킹입니다. 동시에 여러가지 일을, 여러가지 프로젝트를 진행하도록 하는 것이죠. 그 결과는?
The study, carried out at the Institute of Psychiatry, found excessive use of technology reduced workers’ intelligence. Those distracted by incoming email and phone calls saw a 10-point fall in their IQ – more than twice that found in studies of the impact of smoking marijuana, said researchers.
The Multi-Tasking Myth에서 재인용
멀티 태스킹, 멀티 프로젝트의 병폐에 대해 관심이 있으시면 다음 링크를 참고하세요.
(멀티 프로젝트의 문제에 대해서는 차후에 좀 더 자세히 다루도록 하겠습니다.)
켄 트 벡은 XP란 소프트웨어 개발 방법론을 인간성과 생산성 모두를 높히는 방법이라고 설명합니다. 여기에 더 고되게 일한다거나, 더 오래 일한다는 말은 없습니다. 조직은 더 바쁘게 일하라고 합니다. 하지만 바쁘게 일하는 것보다 빠르게 일하는 것이 중요합니다(faster, not busier). 또한 빠르게 일하는 것보다는 더 많은 가치를 더 일찍 전달하는 것이 더 중요합니다(more value sooner, not faster). 더 바쁘게 일하면서 결과 가치는 더 떨어지는 예는 TOC(제약 조건 이론) 관련 서적(더 골을 추천합니다)을 보시면 쉽게 납득하실 겁니다.
류한석님은 젊은 시절 자신의 책상 앞에 “work smarter, not harder!”라는 말을 붙여놓고 있었다고 합니다. 뭔가 더 일을 잘 해보려는 사람들은 다들 비슷한 화두를 갖고 사나 봅니다.
–김창준
