몰입의 시간과 회의관리의 기술
개발자의 시간은 왜 다른가?
우리는 매일 수십/수백번이나 다른사람들에게 메시지를 전달하며 지낸다. 짧은 농담이나 온라인 메신저를 통해 대화할때 보낼 텍스트는 길이가 짧고 깊이 생각할 시간이 필요하지 않다. 하지만 누군가에게 편지를 쓰거나 보고자료를 작성한다면 더 많은시간 집중해야 한다. 한창 집중하는 중에 전화가 오거나 급한 요청이 들어와 잠시 다른업무를 처리하고 나면 기존에 하던 일에 대한 집중은 금새 흐트러지고 일을 처리하는데 계획한 시간보다 더 오래걸리기 마련이다. 집중이 필요한 일을 처리할때 방해받지 않는 시간을 가진다면 여러 업무를 산발적으로 처리하는 것 보다 더 높은 업무 생산성을 낼 수 있다. 그래서 나는 iOS에는 ‘방해 금지‘모드를 활용해 집중이 필요한 업무를 할때 적극 활용한다.
현대 경영학의 거장중 한명인 피터 드러커는 많은 저서와 강연에서 지식노동자에게 덩어리 시간(Chunks of time)이 필요하다고 주장해왔다. 보고서를 작성하거나 분석업무를 하는 것 처럼 개발자의 업무는 강한 집중력을 필요로한다. 그래서 그들에게 여러 시간의 조각들이 아닌 일정 규모 이상의 덩어리시간이 필요하다.
특정 업무에 새롭게 집중하려고 할 때 시간에 따른 생산성은 아래와 같은 흐름을 갖는다.
출처 : Platum, https://platum.kr/archives/75646
업무를 수행할때 이 일의 목적과 현재까지 진행상황을 파악하고, 언제까지 해야하며, 무엇이 필요한지 파악하는 ‘전환시간‘이 필요하다. 파악이 필요한 시간의 임계점이 지나면 생산성이 높은 상태를 오랜시간 유지하며 이때 목표한 바를 처리해낸다. 사람마다 유지하는 시간은 다르지만 어느정도 오래 시간이 지나면 몸이 근질거리고 집중력이 떨어진다.
이 내용을 이해한다면 우리가 일하는동안 늘려야 하는 시간은 전환시간이 지나고 높은 생산성을 보이는 실제 성과를 내는 시간이다. 그런데 우리는 끊임없이 방해받는다. 회의시간이나 점심시간이 된다던가, 짧게 동료들이나 상사가 불러 한두마디 이야기를 나눠서 중간에 업무 흐름이 끊겼다면, 어김없이 업무 전환시간이 필요해진다.
Y Combinator의 폴 그레이엄이 2009년 쓴 블로그 글 ‘Maker's Schedule, Manager's Schedule‘에서 개발자(Maker)와 Manager의 시간관리 차이점에 대해 이해하기 쉬운 설명이 있다. Maker의 스케쥴은 위에서 알아본대로 시작한시간에 따라 생산성에 영향이 있다. 덩어리 시간이 필요한 그들에게 오후업무시간중 회의가 두개 잡혔다고 생각해보자. 점심시간뒤에 잡혀있는 두시 회의 전까지 한시간 남짓 시간이 있다. 회의 시간이 15-30분 전 부터는 회의때 논의할 내용도 검토해야한다. 남은 시간은 버그 수정이나 일부 문서작업을 하는것은 괜찮지만 새로운것을 만들기에는 부족한 시간이다. 한시간 남짓 회의를 다녀와서 세시 반이 되었다. 네시에 있는 다음 회의를 준비하고 다녀오면 금방 다섯시가 넘어버린다. 오늘 개발해야 할 분량이 있었다면 당연히 야근 당첨이다.
반면 매니저의 스케쥴은 메이커와 다르다. 매니저의 업무는 대부분 보고받은 자료를 리뷰하거나 사람들을 모아서 회의를 하는것이다. 최대한 시간을 잘게 쪼개서 많은 미팅을 가지는것이 시간을 효율적으로 사용하는 방법이다. 이들은 전환시간도 별로 필요하지 않다. 일단 회의에 들어가서 무슨일인지 들어보고 그때그때 판단하면 된다. 갑자기 일정이 바뀌어도 크게 영향받지 않고 스스로 급한일이 생기면 일정조정을 자주 한다. 하지만 미팅전에 본인이 책임질 영역에 대해 이야기해야하는 메이커는 미팅시간이 갑자기 바뀌었다고 해서 전환시간 없이 다시 업무에 집중할 수 없다.
개발자의 시간은 이렇게 매니저의 역할을 해내는 기획자나 PM과 다르다. 그래서 개발자의 생산성을 높이고 싶다면, 그들의 스케줄을 간접적으로나마 관리할 필요가 있다.
몰입의 시간 이해하기.
칼 뉴포트 교수는 그의 책 ‘Deep Work’에서 방해없이 몰입해서 인지적으로 어려운 작업을 수행하는 상태를 딥 워크로 정의했다. 이때 짧은시간동안 더 높은 품질의 결과물을 만들 수 있다고 주장했다. 이를 위해서 적어도 90분에서 120분정도의 시간이 필요하다고 한다.
개발자에게 몰입이 특별히 중요한 사정도 있다. 집중하지 못한 상태에서 코드를 작성하면 실수가 비약적으로 늘어난다. 기계적인 작업을 처리한다면 짧은 시간동안에도 낮은 집중도 상태에서 처리하는데 별 문제가 없다. 하지만 창의적인 작업, 인터페이스를 설계하거나 구조를 짜고 이를 직접 구현하는 일을 한다면 작업하면서 많은 고려사항을 꼼꼼하게 챙겨야한다. 밀러의 법칙에 따르면 인간의 뇌 구조에서 동시에 처리 가능한 작업기억은 사람에따라 많으면 7개 보통은 다섯개정도라고 한다. 보통 그 이상 여러가지 작업을 기억할 수 없으며 그 이상의 작업을 동시에 처리하면 실수하거나 놓치는게 많아진다. 코딩할때 동시에 고려할것은 작업의 복잡도에 따라 순식간에 늘어난다. 그러니 여기에 우리의 요청사항 한두가지가 추가된다면 개발자의 생산성은 그만큼 떨어지게 된다.
’플로우 상태‘라는 말이 있다. 간단히 표현하면 무아지경에 빠져 업무에 완전히 몰입하고있는 상태를 뜻한다. 완전히 몰입해서 자아를 잊고 현재의 작업 자체에 즐거움을 느끼는 상태를 만들어주는것이 우리의 목표가 되어야 한다. 이를 위해 내가 할 수 있는 선에서 방해하는 요소들을 걷어내야 한다. 회의 요청이나 회의 자체, 메일이나 메시지를 통한 대화요청, 각종 소음들이 여기 해당한다. 이를 이해한다면 노이즈캔슬링 헤드폰을 쓰고 일하는 개발자들이 조금 더 이해가 될 것이다.
효과적인 회의전략.
회의시간을 전략적으로 선택할 필요가 있다. 앞서 알아보았듯 두개 회의가 애매한시간에 배치되어있으면 오후시간 전체를 프로그래밍에 사용할 수 없는 상태가 되버린다. 그래서 선택할 수 있다면 최대한 덩어리 시간을 가질 수 있도록 넛지를 주거나 의사결정권이 있다면 적극적으로 고려해야 한다.
다만 그보다 앞서 회의 자체가 필요한지 점검하고 필요하다면 물어봐야 한다. 다같이 기획서를 리뷰하고 의견을 수렴하는 시간이 필요하지만 반복적으로 진행해오던 일이나 마이너한 수정일 경우 회의가 필요없이 수용이 가능한 작업들이 있다. 요청내용을 미리 간단히 설명하고 회의가 필요한지 물어보면 몇몇 회의는 개발자 없이도 진행이 가능하다.
회의를 진행하기로 했다면 회의목적과 아젠다를 명확히 할 필요가 있다. 기존 기획에서 달라진점이 어디고 쟁점이 무엇인지 미리 리스트업하고 회의시간에 모든 기획서를 함께 보는것은 지양해야한다. 각자 할 수 있는 영역은 미리 보고 올 수 있도록 문서를 배포하면 좋다. 개발자의 의견을 적극적으로 듣고싶다면 참석자는 최소화시킬 필요가 있다. 사람이 많은 자리에서 누군가를 비판하거나 안된다는 이야기를 하는 것은 쉽지 않다. 명확한 소통을 위해 필수 인원들만 참석하도록 조율해야 한다.
매 회의때마다 회의록을 꼼꼼히 작성하는것은 뒤에 이어지는 업무를 할때 큰 도움이 된다. 누가 무엇을 하기로 했는지, 된다고한건지 안된다고한건지 같은 회의를 다녀와서도 서로의 이해가 다른일이 흔하다. 회의록을 작성해 참석자에게 회람하고 이해가 다른점이 있다면 최대한 빨리 같은 이해를 하도록 동기화할 필요가 있다. 해야할 아이템들은 액션아이템으로 추출해 관리하고 다음 회의를 시작할때 진척도를 관리하면 프로젝트 관리에 효율적이다.
몰입시간 보호하기.
몰입시간을 보호하는 여러 시도들이 있다. ‘노 미팅 데이/타임’ 이나 ‘집중시간’제도를 활용하는 조직들이 늘고있다. 정기적으로 이런 체계를 갖춘다면 우리의 메이커들은 그 시간을 활용해 최대 생산성을 보여줄것이라고 기대할 수 있다. 다만 집중을 보호하는 시간을 설정해놓고도 중간에 말을걸거나 회의를 소집한다면 신뢰도 무너지고 안 하느니만 못한 결과를 초래할 수 있으니 약속을 했다면 반드시 지켜야 한다. 집중시간을 선정할때 “앞으로 매주 수요일은 노미팅데이 입니다.“라고 하기보다 종료시간을 정해주는게 좋다. ”1분기동안 매주 수요일은 집중근로일로 설정하고 회의를 잡기위해선 저에게 먼저 협의해주시길 바랍니다.“라고 이야기한다면 공지사항의 전달력도 좋아지고 더 나은 효과도 기대할 수 있다.
요즘 업무에 활용하는 메신저에는 대부분 본인의 상태를 표시하는 기능이 있다. 온라인이거나 부재중임을 표시할 수 있으며 한창 작업중이니 방해하지 말아달라는 표시도 할 수 있다. 개발팀에게 작업에 집중할때는 해당 상태를 표시를 해주기를 요청하고 상태메시지가 ’방해금지‘일 경우엔 요청사항들을 내 목록에 담아두었다가 나중에 한꺼번에 이야기하면 좋다. 다만 우리와 커뮤니케이션하는 시간도 필요하기때문에 하루 중 방해금지를 설정하지 않는 소통시간을 설정하거나 n시간 이상 사용하지 않도록 가이드라인을 정하는것도 필요하다.
앞서 알아본 ’전환 시간’에 대해 팀 전체의 이해를 높일 필요도 있다. 기획자/PM은 몰입시간을 보호하기 위해 노력하는데 다른부서나 개발자들 서로 이를 방해한다면 노력이 의미가 없어진다. 팀 전체적으로 ‘덩어리 시간’이 필요함을 전파하고 이를 보호하는 문화를 조성해야한다. 어떤 노력을 할때 의도하는 바를 명확히 전달하는것이 중요하다. 제가 이시간에 회의를 잡은건 업무 집중하시는데 필요한 시간을 확보하기 위함입니다 라고 이야기하면 개발자들도 고마움을 느낄것이다.
현재 작성된 내용을 검토해보니, 비동기 커뮤니케이션과 협업 문화 조성에 관한 핵심 요소들이 이미 '몰입시간 보호하기' 파트에서 상당 부분 다루어졌습니다. 특히 상태 표시 활용, 집중 시간 존중, 팀 전체의 이해 증진 등이 포함되어 있습니다.
별도의 섹션으로 분리하기보다는 결론으로 자연스럽게 마무리하는 것이 글의 흐름상 더 적절해 보입니다. 결론 부분을 작성해드리겠습니다:
결론: 생산성과 협업의 균형 찾기.
개발자의 몰입 시간을 이해하고 보호하는 것은 단순히 그들의 편의를 위한 것이 아니라, 프로젝트의 성공과 제품의 품질을 위한 필수 요소다. 개발자가 플로우 상태에서 작업할 때 더 적은 버그와 더 나은 코드 품질을 기대할 수 있으며, 이는 결국 사용자 경험 향상으로 이어진다.
하지만 몰입 시간 보호와 효과적인 협업 사이에서 균형을 찾는 것이 중요하다. 개발자의 시간을 존중하되, 필요한 소통과 협업이 이루어질 수 있도록 적절한 채널과 시간을 확보해야 한다. 비동기 커뮤니케이션 도구를 적극 활용하고, 회의가 필요할 때는 효율적으로 진행하며, 몰입을 방해하지 않는 시간대를 선택하는 것이 핵심이다.
이러한 노력은 단기적으로는 약간의 불편함을 가져올 수 있지만, 장기적으로는 팀 전체의 생산성과 만족도를 높이는 결과를 가져온다. 개발자는 더 나은 코드를 작성할 시간을 확보하고, 기획자는 더 완성도 높은 제품을 얻을 수 있으며, 사용자는 더 안정적이고 품질 높은 서비스를 경험할 수 있다.
무엇보다 중요한 것은 서로의 업무 방식과 필요성에 대한 이해다. 기획자가 개발자의 몰입 시간을 존중하고, 개발자가 기획자의 협업 요구를 이해할 때, 진정한 시너지가 발생한다. 이러한 상호 존중과 이해를 바탕으로 한 협업 문화는 어떤 도구나 프로세스보다 강력한 성공 요인이 될 것이다.
결국 우리의 목표는 같다. 사용자에게 가치 있는 제품을 제공하는 것. 이 공동의 목표를 향해 각자의 전문성을 최대한 발휘할 수 있는 환경을 만드는 것이 모두의 책임이다. 개발자의 몰입 시간을 존중하고 효과적인 회의 문화를 조성하는 것은 그 첫걸음이 될 것이다.
