개발자와 매니저의 시간표가 충돌하는 이유는 일의 단위가 다르기 때문이다
개발팀에서 자주 생기는 오해 중 하나는 이것이다. 매니저는 잠깐 30분만 이야기하자고 말하고, 개발자는 그 30분 때문에 하루가 깨졌다고 느낀다. 이 차이는 예민함의 문제가 아니라 작업 단위의 문제다. 폴 그레이엄은 이를 메이커의 시간표와 매니저의 시간표로 설명했다.
메이커는 길게 이어진 몰입 시간을 필요로 한다. 프로그래머, 디자이너, 작가처럼 문제를 깊게 파고드는 역할이 여기에 가깝다. 반면 매니저는 미팅, 점검, 승인, 조율처럼 짧은 블록 단위의 일정으로 일하는 경우가 많다. 둘 다 바쁘지만, 바쁨의 구조가 다르다.
개발자에게 짧은 회의 하나가 크게 느껴지는 이유
코드를 읽고 수정하는 일은 키보드를 두드리는 시간만으로 이루어지지 않는다. 맥락을 다시 불러오고, 가설을 세우고, 영향 범위를 떠올리는 시간이 필요하다. 그래서 긴 집중이 끊기면 손실은 회의 시간 그 자체보다 더 크게 느껴진다.
특히 게임 개발처럼 상태, 데이터, 도구, 런타임이 함께 얽힌 작업은 더 그렇다. 30분 회의 뒤에 바로 다시 깊은 작업으로 들어가는 것이 쉽지 않은 이유다. 작업 그 자체보다 다시 들어가는 비용이 있기 때문이다.
매니저는 왜 그 비용을 체감하기 어려운가
매니저의 일은 본질적으로 전환이 많다. 여러 팀의 상태를 보고, 우선순위를 조정하고, 결정을 내리고, 사람을 연결하는 일이 반복된다. 이 구조에서는 짧은 회의가 비교적 자연스럽다. 오히려 빈 시간이 길게 비면 뭔가 놓치고 있는 듯 느껴질 수도 있다.
문제는 이 시간 감각이 팀 전체의 기본값이 될 때다. 매니저에게 효율적인 하루가 개발자에게는 조각난 하루가 될 수 있다. 그래서 개발팀 운영에서 중요한 것은 모두를 같은 시간표에 맞추는 일이 아니라, 서로 다른 시간표가 충돌하지 않게 설계하는 일이다.
해결책은 회의를 없애는 것이 아니라 시간표를 구분하는 것이다
현실적으로 개발팀에서 회의를 없앨 수는 없다. 대신 회의와 몰입 시간을 서로 다른 자원으로 보고 관리하는 편이 낫다.
효과가 큰 방법은 대개 비슷하다.
- 깊은 작업 시간이 필요한 역할에는 연속 블록을 보호한다
- 상태 공유는 문서나 비동기 업데이트로 먼저 처리한다
- 꼭 필요한 회의는 한 번에 묶고 목적을 분명히 한다
- 즉시 답변이 필요하지 않은 질문은 메신저 대신 기록 가능한 채널로 보낸다
핵심은 회의 시간이 아니라 회복 시간까지 함께 고려하는 것이다.
마치며
개발자와 매니저의 시간 충돌은 성향 차이로 설명하기 쉽지만, 실제로는 역할 차이에서 오는 구조적 문제다. 누가 더 중요하다는 뜻이 아니라, 서로 다른 종류의 시간이 필요하다는 뜻이다.
팀이 이 점을 이해하면 회의를 무조건 줄이는 대신, 어떤 일에는 긴 몰입이 필요하고 어떤 일에는 빠른 조율이 필요하다는 사실을 같이 설계하게 된다. 생산성은 대개 그때부터 좋아진다.