"분명히 다 계획했다고 생각했는데..."
프로젝트 중반에 이런 말을 하신 적 있나요?
처음엔 자신 있었습니다. "이번엔 완벽하게 계획했어"라고 생각했죠.
그런데 프로젝트가 진행되면서 하나, 둘, 셋... 놓친 작업들이 쏟아집니다.
"아, 이것도 해야 했구나", "저것도 빠뜨렸네" 하며 계획을 수정합니다.
당신만의 문제가 아닙니다.
인간의 뇌는 복잡한 프로젝트를 계획할 때 체계적으로 특정 작업들을 놓치도록 설계되어 있습니다.
오늘은 우리가 작업을 빼먹는 5가지 인지적 함정과 이를 극복하는 실전 전략을 알아봅니다.
더 이상 "깜빡했다"는 변명은 필요 없습니다.
함정 1: 가용성 휴리스틱 (Availability Heuristic)
"최근에 한 일만 기억난다"
우리 뇌는 최근에 경험했거나 인상 깊었던 일을 과대평가합니다.
실제 예시:
최근 웹 개발 프로젝트에서 프론트엔드 버그와 반응형 디자인 문제로 고생했다면,
다음 프로젝트 계획에서:
- 과도하게 할당: UI 테스트, CSS 작업 (60% 시간)
- 과소하게 할당: 백엔드 로직, DB 설계 (20% 시간)
- 완전히 누락: 보안 검토, 성능 최적화 (0% 시간)
최근 경험에 치우친 불균형한 계획이 만들어집니다.
극복 전략: 체크리스트 의무화
## 표준 프로젝트 체크리스트 (최소 요구사항)
### 프론트엔드 (25%)
□ UI/UX 설계
□ 컴포넌트 개발
□ 반응형 처리
□ 브라우저 호환성
### 백엔드 (35%)
□ API 설계
□ 비즈니스 로직
□ 데이터베이스 설계
□ 인증/인가
### 인프라 (20%)
□ 서버 구성
□ CI/CD 설정
□ 모니터링
□ 백업 전략
### 품질 (20%)
□ 테스트 (단위/통합/E2E)
□ 보안 검토
□ 성능 최적화
□ 코드 리뷰
체크리스트는 기억의 편향을 막는 가장 효과적인 도구입니다.
함정 2: 확증 편향 (Confirmation Bias)
"내가 아는 것만 본다"
자신의 전문 분야는 과도하게 상세하게, 모르는 분야는 대충 계획합니다.
백엔드 개발자가 만든 WBS 예시:
- 백엔드: 47개 작업, 200시간, 매우 상세함
- 프론트엔드: 3개 작업, 40시간, "UI 만들기" 수준
- DevOps: 1개 작업, 8시간, "배포하기" 수준
자신이 잘 아는 분야는 세분화하지만, 모르는 분야는 단순화합니다.
결과적으로 모르는 분야의 작업이 누락됩니다.
극복 전략: 크로스 리뷰 시스템
다양한 전문가가 WBS를 교차 검토해야 합니다.
검토자별 집중 영역:
- 프론트엔드 개발자: UI/UX 작업 검토, 프론트엔드 통합
- 백엔드 개발자: API 설계, 데이터 모델링
- DevOps: 배포 프로세스, 인프라 구성
- QA: 테스트 계획, 품질 보증
- 보안 전문가: 보안 요구사항, 취약점 분석
각 전문가가 자신의 영역에서 누락된 작업을 찾아냅니다.
자신의 약점을 아는 것이 첫걸음입니다.
함정 3: 계획 오류 (Planning Fallacy)
"최선의 시나리오만 생각한다"
모든 것이 완벽하게 진행될 거라는 환상에 빠집니다.
가정 vs 현실:
- 환경 설정: 가정 "30분이면 충분" → 현실 "버전 충돌로 반나절"
- API 연동: 가정 "문서 보고 바로 구현" → 현실 "문서 오류로 3일 삽질"
- 버그: 가정 "거의 없을 것" → 현실 "기능당 평균 5개"
- 요구사항 변경: 가정 "없을 것" → 현실 "주 2회 이상"
희망적 사고는 프로젝트의 적입니다.
극복 전략: 3점 추정과 버퍼
낙관/현실/비관 시나리오를 모두 고려해야 합니다.
3점 추정 예시:
- 낙관적: 2일 (모든 것이 완벽할 때)
- 현실적: 5일 (일반적인 경우)
- 비관적: 12일 (최악의 경우)
PERT 공식 적용:
- 예상 시간: (2 + 4×5 + 12) / 6 = 5.5일
- 표준편차: (12 - 2) / 6 = 1.67일
- 버퍼: 1.67 × 2 = 3.34일 (95% 신뢰구간)
희망적 사고는 프로젝트의 적입니다.
최악의 시나리오도 고려해야 합니다.
함정 4: 앵커링 효과 (Anchoring Effect)
"처음 들은 숫자에 묶인다"
누군가 "2주면 되겠네"라고 하면, 그 숫자에서 크게 벗어나지 못합니다.
앵커링 효과 실험:
- 시나리오 1: "이런 프로젝트는 보통 3개월" → 추정: 2.5~4개월 (평균 3.25개월)
- 시나리오 2: "빨리하면 1개월?" → 추정: 1~2.5개월 (평균 1.75개월)
- 실제 필요 시간: 6개월
첫 번째로 들은 숫자가 앵커가 되어 그 주변에서 벗어나지 못합니다.
극복 전략: 독립적 추정 후 통합
각자 독립적으로 추정한 후 통합해야 합니다.
독립적 추정 프로세스:
- 개별 추정 (서로 모르게): 개발자A 120시간, 개발자B 200시간, 개발자C 150시간, PM 180시간, 아키텍트 220시간
- 극단값 제거: 최대값(220)과 최소값(120) 제거
- 평균 계산: (200 + 150 + 180) / 3 = 177시간
첫 번째 숫자가 항상 옳은 것은 아닙니다.
여러 사람의 독립적 추정을 통합하면 더 정확해집니다.
함정 5: 더닝-크루거 효과 (Dunning-Kruger Effect)
"모르는 것을 모른다"
경험이 부족할수록 자신감은 넘칩니다.
경험과 자신감의 관계:
- 초급 (경험 1년): 자신감 90%, 실제 능력 20%, 놓친 작업 "대부분 모름"
- 중급 (경험 3년): 자신감 40%, 실제 능력 60%, 놓친 작업 "무엇을 모르는지 앎"
- 고급 (경험 10년): 자신감 70%, 실제 능력 90%, 놓친 작업 "거의 없음"
경험이 적을수록 더 많이 놓칩니다.
모르는 것을 모르기 때문입니다.
극복 전략: 멘토링과 체계적 학습
## 경험 레벨별 WBS 전략
### 초급 (경험 2년 미만)
- 반드시 시니어 리뷰 필수
- 표준 템플릿 사용 의무화
- 작업당 50% 버퍼 추가
### 중급 (경험 2-5년)
- 페어 플래닝 권장
- 과거 프로젝트 데이터 참조
- 작업당 30% 버퍼 추가
### 고급 (경험 5년 이상)
- 독립적 계획 가능
- 신규 영역만 추가 검토
- 작업당 20% 버퍼 추가
겸손은 정확한 계획의 시작입니다.
종합 전략: SPACE 프레임워크
모든 인지적 함정을 피하는 종합 전략:
SPACE 프레임워크:
- S - Standardize (표준화): 표준 체크리스트 사용
- P - Peer Review (동료 검토): 3명 이상 교차 검토
- A - Assume Worst (최악 가정): 비관적 시나리오 포함
- C - Calculate Independently (독립 계산): 앵커 없이 개별 추정
- E - Experience Matters (경험 고려): 경험 수준별 버퍼 적용
이 5가지 원칙을 따르면 인지적 함정을 피할 수 있습니다.
실전 체크리스트
□ 최근 프로젝트와 다른 유형의 작업 검토했나?
□ 내가 약한 분야를 전문가가 검토했나?
□ 최악의 시나리오를 고려했나?
□ 독립적으로 추정 후 통합했나?
□ 내 경험 수준에 맞는 버퍼를 추가했나?
핵심 정리
우리는 완벽하지 않습니다.
인지적 함정에 빠지는 것은 인간의 본성입니다.
하지만 이를 인정하고 체계적으로 대응한다면,
"깜빡했다"는 말을 하지 않아도 됩니다.
프로젝트 성공의 비밀은 천재성이 아닙니다.
자신의 한계를 아는 겸손함과 이를 극복하는 체계입니다.
다음 프로젝트 계획 시 이 5가지 함정을 기억하고, SPACE 프레임워크를 적용해보세요.
작은 변화가 큰 차이를 만듭니다.
인지적 함정 없는 체계적인 프로젝트 계획이 필요하신가요? Plexo를 확인해보세요.
