이 글은 폴 그레이엄의 Maker's Schedule, Manager's Schedule을 번역한 글입니다.
2009년 7월
개발자들이 죽도록 회의를 싫어하는 이유들 중 한 가지는 다른 사람들과는 다른 형태의 시간 관리 방법을 따르고 있기 때문입니다. 회의 같은 것들은 그들에게 상당히 부담스럽지요.
시간 관리의 형태는 크게 두 가지가 있습니다. 하나를 "관리자(관점)의 시간 관리"라고 하고 다른 하나를 "개발자(관점)의 시간 관리1"라고 부르도록 하지요. 관리자 관점에서는 주로 직장 상사들을 위해서 스케줄링을 합니다. 전통적인 형태의 다이어리를 보면 일별로 나누어져 있고, 각각의 날짜에는 한시간 단위로 잘게 쪼개져 있죠. 만약 필요하다면 한 가지 일을 위해 몇 시간을 묶어서 스케줄링 할 수도 있습니다만, 기본적으로는 시간 단위로 업무가 계속 바뀐다는 것을 의미하지요.
이와 같은 방식으로 시간을 활용한다는 것은 단순히 누군가를 만나기 위해 당신의 일정표에서 비어 있는 공간을 찾고 거기에 약속을 잡으면 됩니다. 그게 끝이죠.
대부분의 영향력 있는 위치에 있는 사람들은 이런 식의 관리자 관점 시간 관리 방법을 따릅니다. 이건 뭐랄까 상부 조직에서 하부 조직으로 명령을 내리기 위한 스케줄링이죠. 하지만 개발자 혹은 작가들과 같이 무언가를 만들어 내는 사람들 사이에서는 다른 형태로 그들의 시간을 사용하는 방법이 따로 있습니다. 그들은 보통 적어도 오전/오후 단위로 시간을 묶어서 사용하는 것을 선호합니다. 한시간 만에 뚝딱 글을 쓴다거나 프로그램을 만든다거나 하는 건 불가능합니다. 그건 시작하기 조차도 충분한 시간이 아니예요.
만약 개발자 관점에서 시간 관리를 하기 시작한다면, 회의 같은 것들은 정말이지 최악입니다. 미팅 하나가 오후 전체를 날려버릴 수 있어요. 미팅 하나 때문에 오후 시간을 둘로 나눠야 하고 그 잘려진 각각은 무언가를 하기엔 너무 작을 수도 있기 때문입니다. 거기에 더해서 당신은 미팅에 참석해야 한다는 사실까지도 기억해야 합니다. 이건 관리자 입장에서라면 아무 문제가 없죠. 항상 다음 번에 무슨 일이 온다는 걸 알고 있으니까요. 그들이 궁금한건 도대체 무슨 일이 올 것인가에 대한 것 뿐입니다. 그런데, 개발자들이라면 이런 모든 것들을 죄다 생각하고 있어야 합니다.
개발자에게 있어서 회의에 참석하는 건 마치 예외를 던지는 것과 같습니다. 하나의 작업에서 다른 작업으로 손쉽게 스위칭하는 것이 개발자에게는 그렇게 단순한 문제가 아니지요. 일하는 형태를 근본적으로 변화시킨다는 데 그 문제가 있어요.
회의 하나가 하루 종일 영향을 줄 수도 있습니다. 보통은 적어도 오전 또는 오후 한나절을 날려버리지요. 게다가 종종 이게 연쇄 반응을 가져올 때가 있습니다. 내가 시간을 보내야 하는 오후 시간이 회의 때문에 둘로 쪼개진다는 사실을 깨닫는 순가 아침에 출근해서 뭔가 의욕적으로 시작하고자 하는 마음이 사라져버릴 수 있습니다. 너무 과장된 표현 아니냐구요? 하지만 당신이 개발자라면 당신의 경우를 한 번 생각해 보세요. 하루 종일 아무런 방해 없이 코딩만 한다는 생각을 해보면 뭔가가 막 용솟음치지 않나요? 역설적으로 이건 당신이 그렇게 할 수 없어서 실망한다는 걸 의미하기도 합니다. 그런 프로젝트들은 글자 그대로 당신의 능력을 제한시켜 버립니다. 이런 조그만 의욕 상실이 어쩌면 그 프로젝트들을 실패하게 만드는 데 충분할 수도 있어요.
개발자의 시간 관리 방식이건 관리자의 시간 관리 방식이건 그 자체로는 다 좋습니다. 문제는 그 둘이 부딪힐 때죠. 대부분의 의사 결정자들은 관리자 방식을 따릅니다. 따라서 그들이 원하는 방식에 따라 모든 사람들이 동조해 주길 바라지요. 하지만 시간의 블록들을 좀 더 크게 가져가고 싶어하는 직원들이 있을 경우에는 이게 발목을 잡습니다.
우리 경우는 좀 특이하죠. 제가 아는 벤처 캐피탈리스트들을 포함한 거의 모든 투자자들이 관리자 방식을 따라갑니다. 하지만 우리 Y 콤비네이터는 개발자 방식을 따라가지요. 로버트와 트레보어 그리고 저는 늘 그래왔기 때문에 그렇게 하는 것이고, 제시카 같은 경우는 대부분 우리와 동조를 맞추기 위해 그렇게 따라 합니다.
우리 같은 회사들이 더 많은 것이라는 것이 크게 놀랍지는 않습니다. 창업자들이 관리자로 전환하는 것에 거부감을 가진다고 한다면 글쎄요 딱히 미덥지는 않습니다. 왜냐하면 예전엔 청바지에서 수트로 복장을 전환하는 것에도 거부감을 가졌던 사람들이거든요.
어떻게 스타트업들에게 개발자의 시간 관리 방식을 따르게끔 조언을 할 수 있을까요? 전통적인 방식을 통해 관리자 방식을 개발자들의 근무 시간에 시뮬레이션해 보는 겁니다. 일주일에 몇 번 정도 우리가 투자한 회사들의 창업자들과 시간 약속을 잡았는데요, 이 약속들은 제 근무시간 막바지 무렵들입니다. 그리고 나서 전 등록 프로그램을 하나 만들어서 주어진 근무 시간 안에 있는 모든 약속들이 맨 마지막으로 모두 몰아넣게끔 했습니다. 제 근무 시간이 끝날 때 쯤 약속을 잡아서 창업자들을 오게 하니까 미팅 때문에 방해 받는 일들이 절대로 없더군요. (창업자들의 업무 종료 시간이 저랑 같지 않다면, 이건 그들의 시간을 방해하는 것이겠지요. 하지만 그렇게 약속을 잡았기 때문에 이건 그들에겐 반드시 가치가 있을 겁니다.) 바쁘다면 근무 시간이 늘어날 법도 한데, 하지만 그들은 절대로 약속을 어기거나 하지는 않았습니다.
90년대로 돌아가서 우리가 스타트업을 운영했을 때 쯤엔 하루 일정을 나누는 또다른 트릭을 사용했습니다. 전 보통 저녁식사 이후 새벽 세 시까지 매일같이 프로그램을 짰죠, 왜냐면 아무도 날 방해하는 사람이 없었으니까요. 그리고 나서 아침 11시까지 늘어지게 잤습니다. 일어나서는 사무실에 가서 저녁 먹기 전까지 소위 "비즈니스"라 불리는 일들을 했죠. 따로 그렇게 생각은 해 본 적은 없긴 한데, 실제로 매일 남들이 하는 이틀의 업무일을 가진 셈이었습니다. 하나는 관리자로서 또 다른 하나는 개발자로서 말이죠.
당신이 관리자로서 일을 한다면 당신은 개발자 관점에서 절대로 하길 원하지 않는 일들을 할 겁니다. 미팅에서 방관자처럼 아무 말도 안한다거나 그냥 만나서 인사나 하고 안부나 묻는 그런 미팅들 말이지요. 만약에 중간 중간 시간이 비게 된다면 아마 그건 당신이 다른 사람들을 어떤 식으로든 도울 수 있는 어떤 것이 될 지도 모르지요.
실리콘 밸리(또는 전 세계에 있는)에 있는 비즈니스맨들은 이런 방관자와 같은 미팅들을 하루 종일 합니다. 관리자 관점에서 시간 관리를 한다면 그들은 효과적으로 자유로움을 만끽합니다. 예를 들어서 "커피나 한 잔 할까요?" 라고 말하는 것과 같이 상당히 독특한 형태로 말하는 것이 그들 사이에서는 일상적입니다.
하지만 개발자 관점에서는 이런 아무 말도 안하고 가만히 앉아 있는 미팅은 정말 시간을 낭비하는 셈이죠. 아무 것도 못하고 꼼짝없이 묶여 있어야 하니까요. 다른 투자자들과 마찬가지로 우리도 이런 관리자로서 시간 관리를 한다고 가정합니다. 따라서 다른 사람들에게 우리를 소개해 줄 때도 커피나 한잔 하자는 식으로 이메일을 보냅니다. 이 시점에서 우린 두가지 선택지가 생기지요. 그들과 만나거나 만나지 않거나. 만나게 된다면 우리의 한나절이 날아가는 셈이고, 만나지 않는다면 그들을 무시하는 게 되니까 둘 다 우리에겐 좋은 선택지가 아니겠군요.
최근까지도 우린 도대체 문제의 원인이 무엇인지 명확하게 머릿속에 떠올릴 수 없었습니다. 우린 그저 우리 시간을 날려버리거나 상대방을 무시하거나 하는 식으로 밖에 할 수 없었죠. 하지만 이제 어떻게 된 것인지 깨달았습니다. 아마도 세번째 선택지가 생긴 것 같네요. 바로 지금 이렇게 두 가지 형태의 시간 관리 방법이 있다는 것을 쓰면서 말입니다. 관리자로서 시간 관리를 하는 방법과 개발자로서 시간 관리를 하는 방법 사이에 충돌이 생길 수 밖에 없다는 것이 좀 더 널리 알려지고 서로 이해할 수 있게 된다면, 결국에는 문제 해결에 다다르지 않을까요?
개발자 관점에서 시간 관리를 하는 우리 같은 사람들은 기꺼이 그런 충돌 상황을 중재할 수 있습니다. 수많은 회의가 있고 해야 한다는 것을 우린 알고 있습니다. 다만 우리가 관리자서로 시간 관리를 하고자 하는 사람들에게 원하는 것은 어떤 방식이 서로에게 더 많은 비용으로 남는 것인가를 이해하는 겁니다.
이 글을 읽느라 수고해주신 Sam Altman, Trevor Blackwell, Paul Buchheit, Jessica Livingston 그리고 Robert Morris 에게 감사 드립니다.
- 원문에는 Maker, 즉 생산자의 의미가 더 강하지만 개발자 입장에서 번역을 하다보니 그냥 개발자로 퉁쳐서 번역했다. (역자 주) ↩