작업이 너무 크면 망하는 이유
2시간 룰의 비밀
"백엔드 개발 4주면 충분하죠?"
이 말을 들으면 등골이 서늘해집니다.
"백엔드 개발"이 대체 뭔가요?
최근 한 스타트업의 WBS를 검토하다가 발견한 내용입니다. 프로젝트 일정 3개월 중 기획 2주, 디자인 2주, 백엔드 개발 4주, 프론트엔드 개발 4주, 테스트 및 배포 2주로 계획되어 있었습니다.
각자에게 "백엔드 개발"이 뭔지 물어봤습니다. PM은 "API 몇 개 만드는 거 아닌가요?"라고 했고, 개발자 A는 "DB 설계부터 API, 인증, 결제까지 다요"라고 했으며, 개발자 B는 "일단 시작하면서 정하죠"라고 했고, CTO는 "클라우드 인프라 구축도 포함이죠"라고 했습니다.
4명이 4가지 다른 생각을 하고 있었습니다.
God Object WBS: 프로젝트 관리의 안티패턴
소프트웨어 개발에 God Object라는 안티패턴이 있습니다. 하나의 클래스가 너무 많은 일을 하는 거죠.
프로젝트 관리에도 똑같은 문제가 있습니다: God Task.
God Task의 특징은 구체적으로 뭘 하는지 모호하고, 진행률 측정이 불가능하며, 완료 기준이 불명확하고, 여러 사람이 다르게 이해한다는 것입니다. "백엔드 개발" 160시간, "프론트엔드 구현" 120시간, "시스템 통합" 80시간 같은 작업들이 대표적인 예입니다.
2시간 룰: 마법의 숫자
수많은 프로젝트를 분석한 결과, 하나의 패턴을 발견했습니다.
성공하는 프로젝트의 평균 태스크 크기: 1-2시간
왜 2시간일까요?
심리학적 이유로는 인간의 집중력 한계가 있습니다. 깊은 집중은 90분, 일반 집중은 45분, 휴식 필요는 15분입니다. 이상적인 작업 단위는 깊은 집중 90분 + 휴식 15분 = 105분, 약 2시간입니다.
실무적 이유로는 오전/오후 단위로 하루를 4개 블록으로 나누기 좋고, 매일 2-3개 작업 완료로 성취감을 느낄 수 있으며, 2시간 작업은 30분이면 리뷰 가능하고, 잘못되어도 2시간만 날리면 됩니다.
실제 사례: 결제 시스템 구현
Before 방식은 God Task로 "결제 시스템 구현" 40시간만 잡았습니다. 결과는 2주 후 "진행률 50%입니다", 3주 후 "거의 다 됐어요", 4주 후 "조금만 더...", 6주 후 완료로 예정보다 2주 지연되었습니다.
After 방식은 2시간 룰을 적용했습니다. 결제 시스템 구현 40시간을 결제 프로세스 설계 4시간(결제 플로우 다이어그램 2시간, 예외 상황 정의 2시간), Stripe 연동 8시간(Stripe 계정 설정 1시간, Customer 생성 API 2시간, Payment Intent API 2시간, Webhook 처리 2시간, 에러 핸들링 1시간), 데이터베이스 6시간(결제 테이블 설계 2시간, 마이그레이션 작성 2시간, 트랜잭션 처리 2시간), 비즈니스 로직 10시간(결제 검증 로직 2시간, 재시도 로직 2시간, 환불 처리 2시간, 구독 관리 2시간, 알림 발송 2시간), 프론트엔드 8시간(결제 폼 UI 2시간, 카드 정보 검증 2시간, 3D Secure 처리 2시간, 결제 상태 표시 2시간), 테스트 4시간(단위 테스트 2시간, E2E 테스트 2시간)으로 나눴습니다.
결과는 매일 "오늘 2.1, 2.2 완료했습니다"처럼 명확하고, 1주 후 "20개 중 10개 완료"로 정확한 50%, 2주 후 "18개 완료, 2개 남음"으로 거의 완료, 2.5주에 완료로 예정보다 빠르게 끝났습니다.
작업 크기별 실패 확률
실제 데이터 분석 결과, 작업 크기별 지연 확률은 1시간 5%, 2시간 8%, 4시간 25%, 8시간 45%, 16시간 70%, 40시간+ 95%입니다.
8시간을 넘으면 반 이상이 늦어집니다.
큰 작업을 쪼개는 기술
첫 번째는 동사로 시작하기입니다. "사용자 관리" 대신 "사용자 생성 API 구현", "사용자 조회 API 구현", "사용자 수정 API 구현"처럼 구체적으로 나눕니다.
두 번째는 CRUD로 나누기입니다. "상품 관리 기능"을 Create: 상품 등록 2시간, Read: 상품 조회 1시간, Update: 상품 수정 2시간, Delete: 상품 삭제 1시간으로 나눕니다.
세 번째는 레이어별로 나누기입니다. "로그인 기능"을 DB: 사용자 테이블 생성 1시간, Model: User 모델 정의 1시간, Service: 인증 로직 구현 2시간, Controller: API 엔드포인트 1시간, View: 로그인 폼 UI 2시간으로 나눕니다.
네 번째는 시나리오별로 나누기입니다. "결제 처리"를 Happy Path: 정상 결제 2시간, 잔액 부족 처리 1시간, 카드 거절 처리 1시간, 네트워크 오류 처리 2시간으로 나눕니다.
2시간 룰 체크리스트
작업을 만들 때 확인하세요. 2시간 안에 끝낼 수 있는가? 구체적인 산출물이 있는가? 완료 기준이 명확한가? 한 사람이 할 수 있는가? 테스트 가능한가?
하나라도 "아니오"면 더 쪼개야 합니다.
실전 적용: 일일 계획
오전 4시간은 09:00-11:00 Task 1(2시간), 11:00-11:15 휴식, 11:15-13:00 Task 2(1시간 45분)로 구성합니다.
오후 4시간은 14:00-16:00 Task 3(2시간), 16:00-16:15 휴식, 16:15-18:00 Task 4(1시간 45분)로 구성합니다.
하루 4개 작업 = 명확한 진척
팀 적용 사례
사례 1은 스타트업 A팀입니다. Before는 평균 작업 크기 16시간, 프로젝트 지연율 80%, 팀 만족도 낮음이었습니다. After(2시간 룰 적용)는 평균 작업 크기 2.5시간, 프로젝트 지연율 15%, 팀 만족도 높음으로 개선되었습니다.
사례 2는 대기업 B팀입니다. 변화 과정은 1주차 "너무 잘게 나누는 거 아니에요?", 2주차 "생각보다 명확하네요", 3주차 "진행 상황이 눈에 보여요!", 4주차 "왜 이제야 이렇게 했을까요?"로 진행되었습니다.
흔한 반론과 답변
"관리 오버헤드가 너무 커요"라는 반론에는, 처음엔 그렇게 느껴지지만 명확한 진행률과 예측 가능성이 주는 이익이 훨씬 크다고 답합니다.
"창의적 작업은 시간 예측이 안 돼요"라는 반론에는, 창의적 작업도 "아이디어 도출 2시간", "프로토타입 2시간" 등으로 나눌 수 있다고 답합니다.
"긴급 작업이 자주 들어와요"라는 반론에는, 2시간 단위로 일하면 긴급 작업에도 빠르게 대응할 수 있다고 답합니다.
마무리: 작게 나누면 크게 이긴다
"Divide and Conquer"는 알고리즘만의 이야기가 아닙니다.
작업을 2시간으로 나누면:
진행률이 명확해지고, 일정 예측이 정확해지며, 팀원들이 행복해지고, 프로젝트가 성공합니다.
다음 프로젝트에서 꼭 시도해보세요.
"백엔드 개발 4주" 대신 "API 20개 × 2시간"으로.
놀라운 변화를 경험하실 겁니다.
2시간 룰로 체계적인 WBS 관리가 필요하신가요? Plexo를 확인해보세요.