작업을 빼먹는 5가지 인지적 함정

PM의 사각지대 극복하기

"분명히 다 계획했다고 생각했는데..."

프로젝트 중반에 이런 말을 하신 적 있나요? 처음엔 자신 있었습니다. "이번엔 완벽하게 계획했어"라고 생각했죠. 그런데 프로젝트가 진행되면서 하나, 둘, 셋... 놓친 작업들이 쏟아집니다. "아, 이것도 해야 했구나", "저것도 빠뜨렸네" 하며 계획을 수정합니다.

당신만의 문제가 아닙니다. 인간의 뇌는 복잡한 프로젝트를 계획할 때 체계적으로 특정 작업들을 놓치도록 설계되어 있습니다. 오늘은 우리가 작업을 빼먹는 5가지 인지적 함정과 이를 극복하는 실전 전략을 알아봅니다. 더 이상 "깜빡했다"는 변명은 필요 없습니다.

함정 1: 가용성 휴리스틱

"최근에 한 일만 기억난다"는 함정입니다. 우리 뇌는 최근에 경험했거나 인상 깊었던 일을 과대평가합니다. 최근 웹 개발 프로젝트에서 프론트엔드 버그와 반응형 디자인 문제로 고생했다면, 다음 프로젝트 계획에서 UI 테스트와 CSS 작업에 60% 시간을 과도하게 할당하고, 백엔드 로직과 DB 설계에는 20%만 할당하며, 보안 검토와 성능 최적화는 완전히 누락하는 불균형한 계획이 만들어집니다.

극복 전략은 체크리스트 의무화입니다. 표준 프로젝트 체크리스트를 만들어 프론트엔드 25%, 백엔드 35%, 인프라 20%, 품질 20%로 균형을 맞추세요. 체크리스트는 기억의 편향을 막는 가장 효과적인 도구입니다.

함정 2: 확증 편향

"내가 아는 것만 본다"는 함정입니다. 자신의 전문 분야는 과도하게 상세하게, 모르는 분야는 대충 계획합니다. 백엔드 개발자가 만든 WBS를 보면, 백엔드는 47개 작업에 200시간으로 매우 상세하지만, 프론트엔드는 3개 작업에 40시간으로 "UI 만들기" 수준이고, DevOps는 1개 작업에 8시간으로 "배포하기" 수준입니다. 자신이 잘 아는 분야는 세분화하지만, 모르는 분야는 단순화합니다. 결과적으로 모르는 분야의 작업이 누락됩니다.

극복 전략은 크로스 리뷰 시스템입니다. 다양한 전문가가 WBS를 교차 검토해야 합니다. 프론트엔드 개발자는 UI/UX 작업을 검토하고, 백엔드 개발자는 API 설계를 검토하며, DevOps는 배포 프로세스를 검토하고, QA는 테스트 계획을 검토하며, 보안 전문가는 보안 요구사항을 검토합니다. 각 전문가가 자신의 영역에서 누락된 작업을 찾아냅니다. 자신의 약점을 아는 것이 첫걸음입니다.

함정 3: 계획 오류

"최선의 시나리오만 생각한다"는 함정입니다. 모든 것이 완벽하게 진행될 거라는 환상에 빠집니다. 환경 설정은 30분이면 충분하다고 가정했는데, 실제로는 버전 충돌로 반나절이 걸립니다. API 연동은 문서 보고 바로 구현할 수 있다고 가정했는데, 실제로는 문서 오류로 3일을 삽질합니다. 버그는 거의 없을 것이라고 가정했는데, 실제로는 기능당 평균 5개가 발생합니다. 요구사항 변경은 없을 것이라고 가정했는데, 실제로는 주 2회 이상 발생합니다. 희망적 사고는 프로젝트의 적입니다.

극복 전략은 3점 추정과 버퍼입니다. 낙관/현실/비관 시나리오를 모두 고려해야 합니다. 낙관적 2일, 현실적 5일, 비관적 12일로 추정하면, PERT 공식을 적용하여 예상 시간은 5.5일, 표준편차는 1.67일, 버퍼는 3.34일(95% 신뢰구간)이 됩니다. 희망적 사고는 프로젝트의 적입니다. 최악의 시나리오도 고려해야 합니다.

함정 4: 앵커링 효과

"처음 들은 숫자에 묶인다"는 함정입니다. 누군가 "2주면 되겠네"라고 하면, 그 숫자에서 크게 벗어나지 못합니다. "이런 프로젝트는 보통 3개월"이라고 들으면 2.5~4개월로 추정하고, "빨리하면 1개월?"이라고 들으면 1~2.5개월로 추정합니다. 하지만 실제 필요 시간은 6개월입니다. 첫 번째로 들은 숫자가 앵커가 되어 그 주변에서 벗어나지 못합니다.

극복 전략은 독립적 추정 후 통합입니다. 각자 독립적으로 추정한 후 통합해야 합니다. 개발자A는 120시간, 개발자B는 200시간, 개발자C는 150시간, PM은 180시간, 아키텍트는 220시간으로 추정했다면, 극단값인 최대값 220과 최소값 120을 제거하고, 나머지의 평균인 177시간을 사용합니다. 첫 번째 숫자가 항상 옳은 것은 아닙니다. 여러 사람의 독립적 추정을 통합하면 더 정확해집니다.

함정 5: 더닝-크루거 효과

"모르는 것을 모른다"는 함정입니다. 경험이 부족할수록 자신감은 넘칩니다. 초급 개발자(경험 1년)는 자신감 90%에 실제 능력 20%로 대부분의 작업을 모릅니다. 중급 개발자(경험 3년)는 자신감 40%에 실제 능력 60%로 무엇을 모르는지 압니다. 고급 개발자(경험 10년)는 자신감 70%에 실제 능력 90%로 놓친 작업이 거의 없습니다. 경험이 적을수록 더 많이 놓칩니다. 모르는 것을 모르기 때문입니다.

극복 전략은 멘토링과 체계적 학습입니다. 초급 개발자는 반드시 시니어 리뷰를 받고, 표준 템플릿을 사용하며, 작업당 50% 버퍼를 추가해야 합니다. 중급 개발자는 페어 플래닝을 권장하고, 과거 프로젝트 데이터를 참조하며, 작업당 30% 버퍼를 추가해야 합니다. 고급 개발자는 독립적 계획이 가능하지만, 신규 영역만 추가 검토하고, 작업당 20% 버퍼를 추가해야 합니다. 겸손은 정확한 계획의 시작입니다.

종합 전략: SPACE 프레임워크

모든 인지적 함정을 피하는 종합 전략입니다. S는 Standardize(표준화)로 표준 체크리스트를 사용합니다. P는 Peer Review(동료 검토)로 3명 이상 교차 검토합니다. A는 Assume Worst(최악 가정)로 비관적 시나리오를 포함합니다. C는 Calculate Independently(독립 계산)로 앵커 없이 개별 추정합니다. E는 Experience Matters(경험 고려)로 경험 수준별 버퍼를 적용합니다. 이 5가지 원칙을 따르면 인지적 함정을 피할 수 있습니다.

실전 체크리스트

최근 프로젝트와 다른 유형의 작업을 검토했는지, 내가 약한 분야를 전문가가 검토했는지, 최악의 시나리오를 고려했는지, 독립적으로 추정 후 통합했는지, 내 경험 수준에 맞는 버퍼를 추가했는지 확인하세요.

핵심 정리

우리는 완벽하지 않습니다. 인지적 함정에 빠지는 것은 인간의 본성입니다. 하지만 이를 인정하고 체계적으로 대응한다면, "깜빡했다"는 말을 하지 않아도 됩니다. 프로젝트 성공의 비밀은 천재성이 아닙니다. 자신의 한계를 아는 겸손함과 이를 극복하는 체계입니다.

다음 프로젝트 계획 시 이 5가지 함정을 기억하고, SPACE 프레임워크를 적용해보세요. 작은 변화가 큰 차이를 만듭니다.

인지적 함정 없는 체계적인 프로젝트 계획이 필요하신가요? Plexo를 확인해보세요.