창업가 딥워크 블록, 무엇으로 실행 속도가 갈리나?
딥워크 블록을 "도입했는가"는 트랙션을 가르지 않는다. 블록에 무엇을 넣고, 무엇으로 지키는지가 갈린다. 도입 기준선은 주 3회 90분이며, 이후 확장 여부는 감이 아니라 산출물 지표로 판단한다. 결국 핵심은 시간을 더 버는 게 아니라, 확보한 시간을 결정과 문서의 완결로 전환하는 것이다.
- 도입 기준: 주 3회 90분부터 시작, 회의를 넣기 전에 블록부터 캘린더에 고정
- 배치 작업: 전략 문서, 제품 결정, GTM 실험 설계, 투자자료 등 고인지 작업 우선
- 보호 장치: Slack·이메일 차단 + 사이트 차단 도구 병행이 의지보다 안정적
- 근거 사례: 15분 단위 시간기록으로 실측 데이터를 확보한 창업가 사례가 존재
- 대상 한정: 1인~소규모 팀에 적합, 고객 대응 비중이 큰 팀은 길이·빈도 조정 필요
판단은 네 축에서 갈린다. 무엇을 넣을지(우선순위), 얼마나 확보할지(자원), 언제 배치할지(타이밍), 무엇으로 지킬지(보호 장치)다. 아래에서 각 축을 실제 사례와 함께 본다.
딥워크 블록에 무엇을 넣어야 실행이 쌓이나?
회의로 대체 가능한 일은 애초에 블록에 넣을 이유가 없다. 블록은 혼자 완결해야 하는 고인지 작업만 담을 때 실행이 쌓인다. 창업가 사례에서 반복적으로 등장하는 배치는 전략 문서 초안, 제품 방향 결정, GTM 실험 설계, 투자자료 작성이다. 이런 작업은 중간에 끊기면 처음부터 다시 맥락을 잡아야 하는 비용이 크기 때문에, 90분 이하로 쪼개면 오히려 완결률이 떨어진다.
반대로 이메일 회신, 일정 조율, 단순 승인 같은 작업은 딥워크 블록 밖으로 빼는 게 맞다. 이 구분이 흐려지면 블록은 이름만 남고 실질은 관리 업무로 채워진다. 실무형 운영 원칙으로 제시되는 "주간 운영체제 3분류"—딥워크·관리·커뮤니케이션—는 이 구분을 캘린더 단위로 강제하는 방식이다출처. 1인~10인 조직에서는 이 세 카테고리를 미리 나눠두지 않으면 회의와 메신저가 딥워크를 잠식하는 패턴이 반복된다.
블록은 얼마나 확보해야 시작할 수 있나?
처음부터 하루 종일을 비울 필요는 없다. 실행 권고로 확인되는 기준선은 최소 90분, 주 3회다출처. 이보다 짧으면 맥락 전환 비용 때문에 고인지 작업을 시작하기도 전에 시간이 끝나고, 이보다 길게 잡으면 초기에는 지키기 어려워 블록 자체가 무너진다.
실전 형식으로는 60120분, 특히 오전 23시간 블록이 자주 제시된다출처. 전략 문서나 제품 사고처럼 인지 부하가 큰 작업을 오전 블록에 배치하고, 오후에는 관리·커뮤니케이션으로 넘기는 식이다. 확장 시점은 임의로 정하지 않는다. 주 3회 90분을 4주 이상 유지했고, 그 기간 산출물(문서 초안 수, 결정 완료 수)이 늘었다면 그때 시간을 늘리는 게 순서다.
블록은 언제 배치해야 밀리지 않나?
타이밍의 핵심은 회의를 잡기 전에 블록부터 캘린더에 고정하는 것이다. 순서가 반대가 되면 블록은 항상 남는 시간에만 배정되고, 결국 가장 먼저 밀리는 항목이 된다. 오전 블록이 자주 권장되는 이유도 여기 있다—하루가 진행될수록 외부 요청이 쌓이면서 오후 블록은 취소될 확률이 높아진다.
하루 1회, 방해 없는 블록을 보호하라는 조언도 반복적으로 등장한다출처. 여러 개의 짧은 블록보다 하루 한 번의 긴 블록이 지키기 쉽다는 게 실무 관찰이다. 다만 팀 규모가 커지면서 실시간 대응이 필요한 역할(예: 고객 응대, 세일즈 클로징)을 겸하는 창업가라면, 오전 블록보다 특정 요일 전체를 블록으로 지정하는 방식이 더 안정적으로 작동하는 경우도 있다.
무엇으로 블록을 지켜야 실제로 유지되나?
의지만으로는 블록이 지켜지지 않는다는 게 반복 관찰이다. 실무에서 확인되는 조합은 세 가지다: 캘린더 블로킹으로 시간을 예약하고, Slack·이메일·메신저를 물리적으로 끄고, 사이트 차단 도구(Freedom 등)로 접근 자체를 막는 것이다출처. 이 중 캘린더 블로킹만 하고 알림은 그대로 두는 경우, 블록의 절반 이상이 중간에 끊긴다는 게 관련 리뷰들의 공통 지적이다.
한 번에 한 고가치 작업만 처리한다는 원칙도 함께 언급된다출처. 블록 안에서 여러 작업을 오가면 블록 자체가 관리 업무로 변질된다. Cal Newport의 2026년 관련 논의에서도 딥워크는 AI 시대에 낡은 개념이 아니라 다시 점검해야 할 운영 습관으로 다뤄지고 있어출처, 도구보다 습관의 반복이 더 중요하다는 점이 재확인된다.
실측 데이터로 딥워크 블록을 재설계한 사례가 있나?
있다. Levels Health 공동창업자 Sam Corcos는 5년간 15분 단위로 자신의 시간을 기록했고, 누적 17,784시간을 로그한 것으로 소개된다출처. 이 사례가 의미 있는 이유는 "느낌상 집중 못 했다"가 아니라 실제 데이터로 자신의 시간 배분을 재설계했다는 점이다. 이 케이스는 2025년 First Round Review 케이스 스터디에서도 핵심 근거로 반복 인용되며, 창업가 시간 배분을 가장 구체적으로 보여주는 공개 사례로 다뤄진다.
여기서 얻을 수 있는 실행 포인트는 두 가지다. 첫째, 딥워크 블록을 도입한 뒤에는 최소 몇 주간 15분 단위로라도 실제 사용 시간을 기록해봐야 계획과 실제의 괴리를 확인할 수 있다. 둘째, 이 기록은 완벽할 필요가 없다—중요한 건 "블록으로 잡은 시간 중 실제 고인지 작업에 쓰인 비율"을 대략이라도 파악하는 것이다. 일부 자료에서 언급되는 "추적 시간의 39%가 딥워크"라는 수치는 1차 출처가 명확히 확인되지 않아, 참고 정도로만 다루는 게 안전하다출처.
이 방식은 어떤 조직에 맞고, 어떤 경우엔 다르게 가야 하나?
주 3회 90분 블록은 1인~10인 규모, 특히 초기 단계 창업가에게 도입 기준으로 적합하다. 이 단계에서는 창업가 본인이 전략·제품·GTM 결정의 병목인 경우가 많아, 방해 없는 블록의 한계효용이 크다. Zoho 창업자 Sridhar Vembu도 2026년 인터뷰에서 생산성을 "더 적은 에너지로 더 많은 산출"의 문제로 설명하며, 딥워크를 오래 일하기가 아니라 고효율 산출의 장치로 해석했다출처.
반면 고객 대응이나 세일즈 클로징 비중이 큰 역할을 창업가가 직접 맡고 있다면, 매일 오전 블록보다는 특정 요일을 통째로 블록으로 지정하는 방식이 더 현실적일 수 있다. 팀이 10인을 넘어서면서 본인이 병목이 아니라 조율자 역할로 이동했다면, 블록의 목적도 "혼자 산출"에서 "핵심 결정 검토"로 옮겨가야 한다. 이 경우 블록 길이보다 빈도와 배치 요일을 먼저 조정하는 편이 낫다.
결국 무엇을 기준으로 블록을 늘리거나 줄이나?
기준은 감이 아니라 지표다. 관찰 대상은 산출물 수, 결정 완료 수, 문서 초안·배포 속도, 회의 전환율(딥워크 예정 시간이 회의로 대체된 비율), 주간 딥워크 총 시간이다. 이 지표가 몇 주간 개선되면 블록 길이나 빈도를 늘리는 실험을 하고, 정체되면 늘리기 전에 배치 작업의 종류나 방해 차단 방식부터 다시 점검하는 게 순서다. 블록을 늘리는 게 항상 정답은 아니며, 배치 작업이 잘못 선택된 경우 시간을 더 줘도 산출은 늘지 않는다.
핵심 정리
- 딥워크 블록의 성패는 도입 여부가 아니라 무엇을 넣고 무엇으로 지키는지에서 갈린다.
- 도입 기준선은 주 3회 90분, 확장은 산출물·결정 완료 수 같은 지표로 판단한다.
- 블록에는 전략 문서, 제품 결정, GTM 설계, 투자자료 등 혼자 완결해야 하는 고인지 작업만 배치한다.
- 캘린더 블로킹 + 알림 차단 + 사이트 차단 도구의 조합이 의지보다 안정적으로 블록을 지킨다.
- 1인~10인, 특히 초기 단계에 적합하며 고객 대응 비중이 큰 역할이라면 요일 단위 블록으로 조정할 수 있다.