계획 오류(Planning Fallacy)란 무엇인가, 스타트업이 항상 일정을 못 지키는 이유와 해결법

계획 오류(Planning Fallacy)는 우리가 일이 걸리는 시간·비용·위험을 체계적으로 과소평가하는 인지 편향입니다. 카너먼(Daniel Kahneman)과 트버스키(Amos Tversky)가 1979년에 처음 제시한 개념인데요, 스타트업이 로드맵을 2주로 잡았다가 2개월에 끝내는 일이 반복되는 핵심 원인이 바로 이것입니다. 이 글은 계획 오류의 정의와 원인(내부 관점 vs 외부 관점), 실제 프로젝트 초과 통계, 그리고 레퍼런스 클래스 예측(reference class forecasting)으로 일정 추정 정확도를 끌어올리는 실전 방법을 정리합니다.

어느 시드 스타트업의 출시 일정이 세 번 밀린 이야기
계획 오류란 무엇인가
왜 우리는 늘 낙관적으로 추정할까: 내부 관점의 함정
숫자로 보는 계획 오류: 프로젝트 초과 통계
스타트업에서 계획 오류가 비싼 이유
레퍼런스 클래스 예측: 계획 오류를 줄이는 가장 강력한 도구
실전 가이드: 우리 팀 일정 추정 바로잡기 4단계
FAQ
같이 읽으면 좋은 것들

어느 시드 스타트업의 출시 일정이 세 번 밀린 이야기

제가 자문으로 들어갔던 한 시드 단계 B2B SaaS 팀의 이야기로 시작해 보겠습니다. 창업자는 결제 연동 기능을 "넉넉하게 잡아서 3주"라고 못 박았습니다. 개발자 두 명 모두 고개를 끄덕였고, 투자자 업데이트 메일에도 그렇게 적혀 나갔습니다.

결과는 9주였습니다. 3배가 밀린 거죠. 흥미로운 건 지연의 원인이 거창한 게 아니었다는 점입니다. PG사 심사 대기 5일, 샌드박스 환경의 미묘한 버그, 한 명이 갑자기 며칠 아팠던 것, 환불 정책에 대한 내부 합의가 늦어진 것. 하나하나는 사소했지만 합치니 6주가 추가됐습니다.

제가 그 팀에게 물었습니다. "지난 분기에 잡았던 기능들, 처음 예상한 날짜에 끝난 게 몇 개나 되나요?" 잠시 침묵이 흘렀습니다. 한 개도 없었습니다. 그런데도 이번 분기 로드맵은 또 똑같이 낙관적으로 그려져 있었습니다. 과거의 자기 데이터를 눈앞에 두고도 그걸 다음 추정에 반영하지 못하는 것, 이게 바로 계획 오류의 가장 교묘한 부분입니다. 한 번 당하는 게 아니라 같은 사람이 같은 방식으로 계속 당합니다.

이 경험적인 장면을 기억해 두시면 좋겠습니다. 계획 오류는 게으르거나 무능해서 생기는 게 아닙니다. 똑똑하고 성실한 팀일수록 자기 계획을 더 구체적으로 그리기 때문에 오히려 더 깊이 빠지는 함정이거든요.

계획 오류란 무엇인가

한 줄로 요약하면, 계획 오류는 미래 과제의 소요 시간·비용·위험을 실제보다 적게 잡고 동시에 그 과제의 이득은 부풀려 보는 체계적 편향입니다.

이 개념은 행동경제학의 두 거장, 대니얼 카너먼과 아모스 트버스키가 1979년에 처음 제시했습니다. 카너먼은 인간의 판단이 고전 경제학이 가정하던 완전한 합리성과 다르다는 연구로 2002년 노벨 경제학상을 받은 인물입니다. 2003년에 로발로(Dan Lovallo)와 카너먼은 정의를 확장하는데요, 계획 오류를 "미래 행동의 시간·비용·위험은 과소평가하면서 같은 행동의 이득은 과대평가하는 경향"으로 다듬었습니다.

핵심은 "체계적"이라는 단어입니다. 계획 오류는 무작위로 빗나가는 게 아닙니다. 거의 항상 한쪽 방향, 즉 "더 빨리, 더 싸게, 더 잘 될 것"이라는 방향으로 치우칩니다. 이게 우연한 실수와 인지 편향을 가르는 결정적 차이입니다. 우연이라면 어떤 건 너무 길게, 어떤 건 너무 짧게 잡아야 평균이 맞을 텐데, 현실의 추정은 한 방향으로만 빗나갑니다.

왜 우리는 늘 낙관적으로 추정할까: 내부 관점의 함정

그렇다면 왜 이런 일이 벌어질까요. 카너먼과 트버스키는 그 답을 내부 관점(inside view)과 외부 관점(outside view)의 차이로 설명합니다.

내부 관점은 지금 눈앞의 이 프로젝트만 들여다보는 방식입니다. "먼저 API를 붙이고, 그다음 테스트하고, QA 하루면 되겠지" 하는 식으로 머릿속에서 일이 순조롭게 흘러가는 시나리오를 그립니다. 문제는 이 시나리오가 거의 항상 "모든 게 계획대로 풀린 최선의 경우"라는 점입니다. 사람이 아프고, 외부 업체가 늦고, 요구사항이 바뀌는 무수한 변수는 상상 속 계획에 잘 들어오지 않습니다.

외부 관점은 정반대입니다. "이 프로젝트"가 아니라 "이와 비슷한 수많은 프로젝트들"을 봅니다. 비슷한 결제 연동을 했던 다른 팀들은 평균 몇 주가 걸렸나, 우리가 지난 분기에 잡은 기능들은 보통 추정의 몇 배가 걸렸나. 이 통계적 시선이 외부 관점입니다.

대부분의 팀이 내부 관점에만 매달립니다. 자기 계획이 구체적일수록 그 시나리오에 더 확신을 갖게 되거든요. 역설적이게도 계획을 더 정교하게 세울수록 계획 오류는 더 커질 수 있습니다. 디테일이 많아지면 "이렇게까지 꼼꼼히 봤으니 빗나갈 리 없다"는 착각이 강해지기 때문입니다. 여기에 손실 회피나 확증 편향 같은 다른 편향까지 겹치면, 과거의 실패 데이터마저 "그땐 특수한 상황이었어"라며 외면하게 됩니다.

숫자로 보는 계획 오류: 프로젝트 초과 통계

추상적인 이야기로 들릴 수 있으니 데이터를 보겠습니다.

가장 고전적인 실험은 1994년 뷜러(Buehler), 그리핀, 로스의 연구입니다. 졸업 논문을 쓰는 심리학과 학생들에게 "며칠이면 끝낼 수 있나"를 묻자 평균 33.9일이라고 답했는데요, 실제 평균 완료 기간은 55.5일이었습니다. 자기 예측대로 끝낸 학생은 약 30%에 불과했습니다. 더 흥미로운 건 "모든 게 어그러진 최악의 경우"를 가정해 달라고 했을 때조차, 그 비관적 추정마저 실제보다 짧았다는 점입니다.

대규모 프로젝트로 가면 숫자는 더 극적입니다. 옥스퍼드 사이드 경영대학원의 벤트 플뤼비에르(Bent Flyvbjerg) 연구팀이 구축한 1만 6,000건 이상의 대형 프로젝트 데이터베이스를 보면, 예산·일정·약속한 효익을 모두 지킨 프로젝트는 단 0.5%였습니다. 분야별 평균 비용 초과율은 철도 약 45%, IT 약 73%, 댐 약 96%, 올림픽은 무려 157%에 달했습니다. 시드니 오페라하우스는 처음 700만 달러에 1963년 완공 예정이었지만, 실제로는 1973년에 1억 200만 달러가 들었습니다.

소프트웨어 업계의 사정도 다르지 않습니다. 스탠디시 그룹(Standish Group)의 CHAOS 리포트는 여러 해에 걸쳐 IT 프로젝트의 일정·비용 초과를 추적해 왔는데요, 난항을 겪은 프로젝트의 평균 일정 초과율이 원래 추정의 200%를 훌쩍 넘는 경우가 흔하게 나타났습니다. 비용 역시 처음 잡은 예산의 1.8배 안팎으로 불어나는 사례가 많았습니다.

프로젝트 유형	평균 비용·시간 초과	출처 맥락
졸업 논문(개인 과제)	예측 33.9일 → 실제 55.5일	Buehler 외, 1994
철도 megaproject	약 +45% 비용 초과	Flyvbjerg DB
IT/소프트웨어	약 +73% 비용 초과	Flyvbjerg DB
올림픽	약 +157% 비용 초과	Flyvbjerg DB

이 표가 말하는 건 분명합니다. 계획 오류는 개인의 자기 관리 문제가 아니라, 조직과 산업 전체를 관통하는 구조적 패턴이라는 것입니다.

스타트업에서 계획 오류가 비싼 이유

대기업이라면 일정이 밀려도 버틸 자본이 있습니다. 하지만 스타트업에게 계획 오류는 단순한 지연 그 이상입니다. 런웨이(runway)와 직결되기 때문입니다.

상황을 그려 보겠습니다. 시드 자금으로 12개월 런웨이를 확보한 팀이 있습니다. "6개월이면 핵심 기능을 출시하고, 그걸로 시리즈 A를 노린다"는 계획을 세웠습니다. 내부 관점으로만 그린 이 계획에서 6개월이 실제로는 10개월이 됩니다. 출시가 늦어지니 유저 데이터도 늦게 쌓이고, 투자 미팅에 들고 갈 지표도 부족해집니다. 결국 런웨이가 바닥나기 직전에 불리한 조건으로 브릿지 라운드를 돌게 되죠. 기능 하나의 지연이 회사 전체의 협상력을 깎아먹는 겁니다.

기존 방식은 이랬습니다. 창업자가 직감으로 "이 정도면 되겠지" 하고 로드맵을 그리고, 안 지켜지면 "이번엔 운이 나빴다"며 넘어갑니다. 다음 분기에 또 같은 일이 반복됩니다. 과거 데이터가 추정에 피드백되지 않으니 영원히 같은 실수를 합니다.

계획 오류를 인식하는 팀은 다르게 접근합니다. 이들은 추정을 "맞히는 것"이 목표가 아니라 "체계적으로 빗나가는 방향을 보정하는 것"이 목표라는 걸 압니다. 우리 팀이 늘 추정의 1.7배가 걸린다면, 다음 추정에 1.7을 곱하는 것만으로도 계획의 현실성이 극적으로 올라갑니다. 이 작은 습관 하나가 런웨이를 지키고, 투자자 신뢰를 지키고, 팀의 번아웃을 막습니다.

레퍼런스 클래스 예측: 계획 오류를 줄이는 가장 강력한 도구

그렇다면 어떻게 보정할까요. 카너먼이 "예측 정확도를 높이는 가장 중요한 조언 하나"라고 부른 방법이 있습니다. 바로 레퍼런스 클래스 예측(Reference Class Forecasting, RCF)입니다.

이름은 거창하지만 원리는 단순합니다. "이 프로젝트가 얼마나 걸릴까"를 처음부터 새로 상상하지 말고, "이와 비슷한 프로젝트들이 과거에 실제로 얼마나 걸렸나"라는 분포에서 출발하라는 것입니다. 내부 관점을 외부 관점으로 강제 전환하는 절차죠.

플뤼비에르가 정리한 RCF의 절차는 세 단계입니다. 첫째, 지금 프로젝트와 비교 가능한 과거 프로젝트들의 집합(레퍼런스 클래스)을 정합니다. 둘째, 그 집합의 실제 결과 분포를 확인합니다. 셋째, 우리 프로젝트가 그 분포 안에서 어디쯤 위치할지를 가늠해 추정치를 조정합니다. 이 방식은 미국 계획협회의 권고를 받았고 영국, 네덜란드, 홍콩, 덴마크, 스위스 등이 대형 인프라 예산 산정에 실제로 도입했습니다.

스타트업 버전으로 옮기면 이렇습니다. "이 기능, 얼마나 걸릴까?"라고 묻는 대신 "우리가 지난 1년간 비슷한 규모로 잡았던 기능 10개가 평균 며칠 걸렸지?"라고 묻습니다. 그 평균이 추정의 1.8배였다면, 새 기능의 내부 추정에 1.8을 곱한 값을 기준선으로 삼습니다. 거창한 PMO 시스템이 필요한 게 아니라, 과거 추정과 실제를 기록한 스프레드시트 한 장이면 시작할 수 있습니다.

여기서 한 가지 주의할 점은, RCF가 만능은 아니라는 것입니다. 우리 팀의 레퍼런스 클래스 데이터가 너무 적거나, 정말 전례 없는 새로운 종류의 작업이라면 분포 자체가 빈약합니다. 그럴 땐 유사한 업계 벤치마크라도 끌어와 외부 관점의 닻을 만드는 게 아무 닻도 없는 것보다 낫습니다.

실전 가이드: 우리 팀 일정 추정 바로잡기 4단계

이론을 당장 적용할 수 있게 4단계로 정리했습니다. 초보 팀도 이번 주에 바로 시작할 수 있습니다.

1단계 — 보정 계수 측정하기. 지난 분기에 잡았던 작업들의 "처음 추정 일수"와 "실제 소요 일수"를 나란히 적습니다. 그리고 실제를 추정으로 나눈 비율의 평균을 냅니다. 이게 우리 팀의 보정 계수입니다. 대개 1.3~2.0 사이가 나옵니다. 이 숫자를 마주하는 것만으로도 절반은 해결됩니다.

2단계 — 외부 관점으로 추정 시작하기. 새 작업을 추정할 때, 담당자에게 "얼마나 걸릴 것 같아?"라고 먼저 묻지 마세요. 대신 "지난번 비슷했던 작업이 며칠 걸렸지?"부터 묻습니다. 질문의 순서를 바꾸는 것만으로 내부 관점의 낙관이 한 박자 늦게 개입합니다.

3단계 — 추정에 보정 계수 곱하기. 팀이 내놓은 내부 추정에 1단계의 보정 계수를 곱합니다. 개발자가 "5일"이라고 하고 우리 계수가 1.7이라면, 로드맵에는 8~9일로 적습니다. 처음엔 "너무 길게 잡는 것 아니냐"는 저항이 있는데요, 데이터를 보여주면 대부분 수긍합니다.

4단계 — 사전 부검(premortem) 한 번 돌리기. 일정을 확정하기 전, 팀에게 "이 프로젝트가 두 배 늦어졌다고 상상해 보자. 무엇 때문이었을까?"를 묻습니다. 미래의 실패를 미리 상상하면 내부 관점이 놓친 위험 변수들이 드러납니다. 외부 업체 의존, 휴가, 불확실한 요구사항 같은 것들이 이때 떠오릅니다.

이 네 단계는 거창한 도구 없이 회의 30분이면 도입할 수 있습니다. 핵심은 추정을 "더 열심히 하는 것"이 아니라 "다른 방식으로 하는 것"입니다.

FAQ

계획 오류는 그냥 일정 관리를 못하는 것과 무엇이 다른가요?

일정 관리 실패는 무작위로 빗나갈 수 있지만, 계획 오류는 거의 항상 "더 빨리·더 싸게" 한쪽 방향으로만 빗나가는 체계적 편향입니다. 똑똑하고 성실한 팀일수록 자기 계획을 구체적으로 그리기 때문에 오히려 더 깊이 빠집니다. 즉 노력의 문제가 아니라 인지 구조의 문제라서, 더 열심히 한다고 사라지지 않고 추정 방식 자체를 바꿔야 줄어듭니다.

레퍼런스 클래스 예측을 적용하면 추정이 얼마나 정확해지나요?

정확도는 우리 팀의 과거 데이터가 얼마나 쌓여 있느냐에 달려 있습니다. 데이터가 풍부할수록 분포가 안정적이라 보정 효과가 큽니다. 다만 RCF의 목표는 "정확히 맞히는 것"이 아니라 "체계적 과소평가를 보정하는 것"입니다. 완벽한 예측은 불가능해도, 한쪽으로 쏠린 낙관을 걷어내는 것만으로 런웨이 계획의 신뢰도가 크게 올라갑니다.

데이터가 거의 없는 초기 스타트업도 이 방법을 쓸 수 있나요?

쓸 수 있습니다. 내부 데이터가 적으면 업계 벤치마크나 비슷한 규모의 외부 사례라도 끌어와 외부 관점의 기준선을 만듭니다. 동시에 지금부터 "추정 vs 실제"를 스프레드시트에 기록하기 시작하면, 두세 달만 지나도 자기 팀의 보정 계수를 산출할 수 있습니다. 시작이 늦을수록 영원히 직감에만 의존하게 됩니다.

계획 오류를 줄이면 시간을 얼마나 아낄 수 있나요?

직접적으로 작업 시간을 단축해 주는 기법은 아닙니다. 대신 비현실적인 일정으로 인한 재작업, 막판 야근, 투자 미팅 연기, 불리한 브릿지 라운드 같은 2차 비용을 막아 줍니다. 스타트업에서 가장 비싼 자원은 런웨이인데요, 일정 추정을 현실화하는 것만으로 그 런웨이를 지키는 효과가 큽니다.

사전 부검(premortem)은 그냥 비관적으로 생각하는 것 아닌가요?

비슷해 보이지만 다릅니다. 막연한 비관은 행동으로 이어지지 않지만, 사전 부검은 "이미 실패했다"고 가정한 뒤 구체적 원인을 역추적하게 만듭니다. 이 형식이 내부 관점이 무시한 위험 변수를 표면으로 끌어올립니다. 연구에서도 비관적 시나리오를 강제했을 때 추정이 현실에 더 가까워지는 경향이 확인됐습니다.

목차