딥워크 vs 얕은 작업: 1인 개발자의 하루를 두 모드로 쪼개는 시간 설계

1. 두 모드는 능력이 아니라 환경이다

1인 개발자는 하루 안에 기획자, 개발자, 고객지원 담당자, 마케터가 모두 됩니다. 문제는 역할이 많다는 사실보다, 서로 다른 작업 모드를 너무 자주 오간다는 데 있습니다. 핵심 기능을 설계하다가 알림을 확인하고, 다시 코딩하다가 문의에 답하면 작업마다 전환 비용이 생깁니다.

딥워크는 기획, 구조 설계, 어려운 버그 수정처럼 긴 사고가 필요한 일입니다. 얕은 작업은 CS 답변, 배포 확인, 문서 수정, 콘텐츠 예약처럼 짧게 끊어 처리할 수 있는 일입니다. 얕은 작업이 덜 중요하다는 뜻은 아닙니다. 다만 두 작업은 필요한 집중의 깊이가 다르므로 같은 시간대에 섞지 않는 편이 대체로 유리합니다.

조코헌트에 출시된 프로덕트 가운데 출시 첫 24시간 안에 업보트나 댓글 같은 반응을 하나라도 받은 비율은 67%입니다. 출시 직후의 반응 확인과 답변은 중요한 얕은 작업이지만, 핵심 기능 개발 중간에 계속 끼워 넣을 일은 아닙니다.

2. 먼저 작업을 두 바구니로 나눈다

딥워크 바구니

• 사용자 문제와 기능 범위 결정
• 데이터 모델, 핵심 로직, 주요 화면 설계
• 재현이 어려운 버그 분석
• 제품 방향을 바꾸는 의사결정

완료 기준은 “오래 앉아 있었다”가 아니라 결과물로 적습니다. 예를 들어 “결제 기능 작업” 대신 “결제 실패 상태 3가지를 정의하고 테스트한다”처럼 씁니다.

얕은 작업 바구니

• 문의와 댓글에 답하기
• 배포 상태, 로그, 알림 확인
• 소개 문구와 문서 다듬기
• 할 일 정리와 다음 작업 준비

얕은 작업은 모아서 처리할수록 좋습니다. 메시지를 볼 때마다 즉시 답하지 말고, 답변이 필요한 목록을 한곳에 쌓아 둡니다. 단, 장애나 결제 오류처럼 실제 사용을 막는 신호는 예외 규칙으로 따로 정하세요.

이 구분이 잘 되지 않는다면 바이브코딩 시대의 집중력 관리: AI 도구를 쓸수록 산만해지는 이유와 대책에서 알림과 도구를 줄이는 기준을 함께 참고할 수 있습니다.

3. 하루를 모드별 블록으로 배치한다

기본형: 깊게 만들고, 모아서 운영하기

예를 들어 하루를 다음처럼 설계할 수 있습니다.

• 첫 번째 블록: 딥워크 — 오늘의 핵심 결과물 하나 만들기
• 두 번째 블록: 얕은 작업 — CS, 배포 확인, 문서 정리
• 세 번째 블록: 딥워크 — 오전 결과를 이어서 구현하거나 검증하기
• 마지막 블록: 얕은 작업 — 피드백 기록, 내일의 첫 작업 예약

정확한 시간은 생활 패턴에 맞추면 됩니다. 중요한 것은 오전 9시부터 10시 30분까지처럼 시계의 숫자를 지키는 일이 아니라, 한 블록 안에서 모드를 바꾸지 않는 것입니다. 40분밖에 없다면 40분짜리 딥워크 블록도 충분합니다.

현실형: 하루가 깨질 때의 최소 단위

직장과 병행하거나 가족 일정이 있다면 완벽한 시간표보다 최소 단위를 정하세요. 딥워크는 2550분, 얕은 작업은 1530분처럼 예약하고, 빈 시간이 생길 때 해당 바구니에서만 꺼냅니다. 하루에 딥워크 블록 하나만 지켜도 핵심 기능은 앞으로 나아갑니다.

퇴근 후 작업 시간이 짧다면 퇴근 후 사이드 프로젝트 루틴: 직장인 인디 메이커의 평일 2시간 설계법의 방식처럼 고정된 시작 신호와 종료 기준을 붙여 보세요. “시간이 남으면 개발한다”보다 “화요일 저녁에는 기능 하나를 검증한다”가 실행하기 쉽습니다.

4. 방해를 없애는 운영 규칙을 만든다

시간 블로킹만 해 두고 알림을 그대로 두면 모드는 쉽게 무너집니다. 딥워크 블록이 시작되기 전에 메신저와 메일 알림을 끄고, 브라우저 탭을 닫고, 떠오른 잡일은 별도 메모에 적습니다. 지금 처리하지 않는다고 잊는 것이 아니라, 나중에 처리할 위치를 정하는 것입니다.

얕은 작업에도 종료 규칙이 필요합니다. “문의가 모두 사라질 때까지”처럼 끝이 없는 기준 대신 “30분 동안 새 문의를 분류하고 긴급 항목만 답한다”고 정하세요. 조코헌트 데이터에서 댓글을 하나라도 받은 프로덕트는 36%였습니다. 반응이 적더라도 계속 새로고침하며 기다리는 것은 운영이라기보다 집중력 누수에 가까울 수 있습니다.

예외는 세 가지 정도만 남겨 두면 충분합니다.

• 서비스 이용을 막는 장애
• 결제나 접근 권한처럼 즉시 확인이 필요한 문제
• 약속된 출시나 공지의 시간 제한

그 외의 알림은 기록하고 다음 얕은 작업 블록에서 처리합니다.

5. 매주 블록의 비율을 조정한다

처음부터 완벽한 비율을 찾으려 하지 마세요. 일주일 동안 각 블록에서 실제로 무엇을 했는지 간단히 기록합니다. 딥워크가 부족했는지, 얕은 작업이 예상보다 길었는지, 반복 문의를 자동화하거나 문서화할 수 있는지 확인하면 됩니다.

주간 점검 질문

• 이번 주에 제품을 실제로 전진시킨 결과물은 무엇인가?
• 얕은 작업 중 다음 주에도 반복될 항목은 무엇인가?
• 딥워크를 깨뜨린 방해는 규칙으로 막을 수 있는가?
• 다음 주 첫 딥워크 블록에서 바로 시작할 작업이 정해졌는가?

계획이 자주 무너진다면 의지가 약해서가 아니라 블록이 너무 크거나 예외가 너무 적은 것일 수 있습니다. 동기가 식어도 출시되는 사이드 프로젝트 시스템처럼 목표를 작은 산출물로 쪼개고, 하루의 성공 기준을 “모든 일을 끝내기”가 아니라 “딥워크 결과물 하나 남기기”로 바꿔 보세요. 1인 개발자의 시간 설계는 빈틈없는 통제가 아니라, 다시 집중할 수 있는 구조를 만드는 일입니다.