6개월째 개발 중인 사내 시스템이 있습니다. 처음 예상했던 3개월은 진작에 지났고, 투입 인력은 두 배로 늘었는데 완성도는 60%에 머물러 있습니다. 팀 회의 때마다 “조금만 더 하면 됩니다”라는 말이 반복됩니다. 여기서 멈추자니 지금까지 쏟아부은 수천 시간의 공수와 수억 원의 예산이 아깝고, 계속하자니 끝이 보이지 않습니다.

익숙한 상황이신가요? IT 업계에서 일하다 보면 누구나 한 번쯤 이런 딜레마에 빠집니다. 그리고 대부분은 “여기서 멈추면 그동안의 투자가 전부 날아간다”는 생각에 프로젝트를 계속 밀어붙입니다. 바로 이것이 매몰 비용 오류(Sunk Cost Fallacy)의 전형적인 모습입니다.

매몰 비용 오류란 이미 지출되어 회수할 수 없는 비용 때문에 비합리적인 결정을 내리는 인지 편향을 말합니다. 경제학 교과서에서 배우는 개념이지만, 실제로 가장 큰 피해를 입히는 현장 중 하나가 바로 IT 프로젝트입니다. 반기 결산과 프로젝트 리뷰가 집중되는 여름, 많은 IT 조직이 “이 프로젝트를 계속할 것인가”라는 무거운 질문 앞에 서게 됩니다.

이 글에서는 매몰 비용 함정이 IT 프로젝트에서 유독 강력하게 작용하는 구조적 이유를 분석하고, 프로젝트의 중단·피벗·지속을 감이 아닌 근거로 판단할 수 있는 실전 프레임워크를 소개하겠습니다. “접는 것도 실력”이라는 말이 왜 IT 의사결정에서 가장 중요한 원칙인지, 함께 살펴보겠습니다.

매몰 비용 오류, IT 프로젝트에서 유독 빠지기 쉬운 이유

매몰 비용 오류는 어떤 분야에서든 발생하지만, IT 프로젝트에서 특히 빠지기 쉬운 구조적 원인이 있습니다. 왜 숙련된 개발자와 경험 많은 PM조차 이 함정에서 벗어나기 어려운지, 그 근본 원인을 하나씩 짚어보겠습니다.

눈에 보이지 않는 투자의 축적

건설 프로젝트는 반쯤 올라간 철근 구조물이라는 물리적 증거가 남습니다. 절반까지 올렸으니 나머지 절반을 올리면 된다는 직관이 어느 정도 맞습니다. 하지만 소프트웨어 개발은 다릅니다. 수만 줄의 코드, 수백 시간의 아키텍처 논의, 무수한 버그 수정 히스토리가 Git 로그 속에 보이지 않게 쌓여 있을 뿐입니다.

이 보이지 않는 투자의 실체는 숫자로 환산하기 극히 어렵습니다. 정확히 얼마를 투자했는지 모르기 때문에 “아마 엄청나게 많이 투자했을 것”이라는 막연한 아까움이 의사결정을 지배하게 됩니다. 실제 투자 규모를 객관적으로 측정할 수 없는 환경에서, 사람은 본능적으로 투자를 과대평가하는 경향이 있습니다.

복잡도의 비선형 증가

IT 프로젝트의 복잡도는 선형이 아니라 지수적으로 증가합니다. 업계에서 자주 인용되는 ’90-90 법칙’이 있습니다. “코드의 처음 90%가 개발 시간의 90%를 차지하고, 나머지 10%의 코드가 또 다른 90%의 시간을 차지한다.” 유머처럼 들리지만 현실에 놀라울 정도로 부합하는 관찰입니다.

진행률 70%까지는 순조롭게 느껴지다가, 나머지 30%에서 통합 테스트 실패, 성능 병목, 엣지 케이스 폭발, 외부 시스템 호환성 문제가 한꺼번에 터져 나옵니다. 이 비선형성 때문에 “거의 다 왔다”는 착각이 반복되고, 팀 전체가 완료 시점을 만성적으로 과소평가하는 계획 오류(Planning Fallacy)에 빠집니다. 매몰 비용 오류와 계획 오류가 결합되면 프로젝트는 끝없는 연장전에 돌입합니다.

기술적 자존심과 감정적 투자

개발자와 엔지니어는 자신이 설계하고 구현한 시스템에 대한 기술적 자부심을 가지고 있습니다. 이것은 평소에 코드 품질을 높이고 더 나은 솔루션을 추구하게 만드는 긍정적 동력입니다. 하지만 프로젝트 중단 결정 앞에서는 이 자부심이 강력한 저항 요소로 변합니다.

“내가 설계한 아키텍처인데 포기할 수 없다”, “이 알고리즘을 한 번만 더 최적화하면 분명 성능 목표를 달성할 수 있다”, “이 코드베이스의 잠재력을 나만 알고 있다”라는 생각은 객관적 판단과 거리가 멀지만, 본인에게는 매우 합리적으로 느껴집니다. 코드에 쏟은 감정적 에너지가 클수록 매몰 비용 오류는 더욱 견고해집니다.

조직 내 책임 회피 구조

IT 조직에서 프로젝트를 중단하면 “실패한 프로젝트의 책임자”라는 꼬리표가 붙을 수 있습니다. 반면에 프로젝트를 계속 끌어가면 적어도 당장은 아무도 책임을 지지 않아도 됩니다. 결과적으로 누구도 먼저 “이 프로젝트를 멈추자”라고 입을 열지 않게 되고, 팀 전체가 침묵 속에서 프로젝트의 느린 죽음을 방관합니다.

이 현상은 개인의 비겁함이 아니라 조직 구조의 문제입니다. 실패를 인정하고 빠르게 방향을 전환한 리더가 보상받는 문화가 없다면, 합리적인 개인이 “그냥 계속하자”를 선택하는 것은 자연스러운 생존 전략입니다. 이 구조를 바꾸지 않으면 매몰 비용 오류는 조직 전체의 만성 질환이 됩니다.

이 네 가지 요인이 복합적으로 작용하면 매몰 비용 오류는 단순한 개인의 인지 편향을 넘어 조직 전체의 의사결정 마비로 확대됩니다. 중요한 것은 이 함정을 ‘인식’하는 것만으로는 빠져나올 수 없다는 점입니다. 눈앞에 놓인 구체적인 위기 시그널을 감지하고, 구조화된 판단 기준으로 대응해야 합니다.

지금 당장 점검하세요 — 프로젝트 위기 시그널 5가지

매몰 비용 함정에 빠진 프로젝트는 겉보기에는 “느리지만 진행 중”인 것처럼 보입니다. 하지만 표면 아래에는 분명한 위기 징후가 있습니다. 다음 다섯 가지 시그널 중 세 개 이상에 해당한다면, 프로젝트의 방향을 진지하게 재검토해야 할 시점입니다.

시그널 1: 핵심 지표가 3회 연속 미달

스프린트 속도(Velocity), 번다운 차트, 마일스톤 달성률 등 프로젝트를 추적하는 정량 지표가 있을 것입니다. 한두 번의 미달은 정상 범위 안의 변동입니다. 하지만 3회 연속으로 목표치에 미달한다면 이것은 변동이 아니라 추세입니다. 특히 스프린트마다 완료하지 못한 이슈가 누적되면서 백로그가 줄어들지 않고 오히려 늘어나는 패턴이 보인다면, 현재 접근 방식에 근본적인 문제가 있다는 강력한 시그널입니다.

이 시그널을 무시하면 팀은 “다음 스프린트에는 잘 되겠지”라는 희망적 사고에 의존하게 됩니다. 3회 연속 미달 시점에 반드시 원인 분석 회의를 열고, 단순 리소스 부족인지 근본적 설계 문제인지를 구분하세요.

시그널 2: 기술 부채 상환이 신규 개발을 잠식

프로젝트 초기에 속도를 위해 감수한 기술 부채는 시간이 갈수록 이자를 불립니다. 개발팀의 작업 시간 중 기술 부채 상환(리팩토링, 레거시 호환, 우회 코드 수정)에 소요되는 비율이 40%를 넘어선다면 심각한 경고입니다. 이 수치가 50%를 넘으면 사실상 팀은 새로운 가치를 창출하는 것이 아니라 과거의 결정을 수습하는 데 대부분의 에너지를 쓰고 있는 것입니다.

기술 부채가 이 수준에 도달하면 “부채를 다 갚고 나면 빨라질 것”이라는 기대도 비현실적입니다. 부채를 갚는 동안 새로운 부채가 쌓이기 때문입니다. 이 시점에서는 현재 코드베이스 위에서 계속 작업하는 것이 과연 합리적인지 근본적으로 질문해야 합니다.

시그널 3: 핵심 인력의 이탈 또는 이탈 조짐

프로젝트의 아키텍처를 이해하고 핵심 의사결정을 내렸던 시니어 멤버가 팀을 떠나기 시작하면, 이것은 단순한 인사 이동이 아닌 위기 시그널입니다. 경험 많은 엔지니어는 프로젝트의 실제 건강 상태를 가장 정확하게 파악하고 있습니다. 그들이 떠나는 것은 프로젝트의 미래에 대한 가장 솔직한 평가일 수 있습니다.

더 미묘한 형태로는 핵심 인력이 공식적으로 떠나지는 않지만, 사내 다른 프로젝트에 점점 더 많은 시간을 할애하거나 이력서를 업데이트하기 시작하는 경우가 있습니다. 1on1 미팅에서 “이 프로젝트의 방향에 확신이 없다”는 말이 나온다면 아직 잡을 수 있는 시간이 남아 있는 것이지만, 그 시간이 많지는 않습니다.

시그널 4: 원래의 비즈니스 전제가 무너졌다

IT 프로젝트는 특정 비즈니스 전제 위에서 시작됩니다. “사용자가 월 10만 명이 될 것이다”, “이 워크플로를 자동화하면 인건비를 30% 절감할 수 있다”, “경쟁사가 이 기능을 출시하기 전에 우리가 먼저 해야 한다” 같은 가정들입니다.

프로젝트 진행 도중 이 전제가 근본적으로 바뀌는 경우가 있습니다. 시장 환경이 변했거나, 경쟁사가 먼저 출시했거나, 규제가 바뀌었거나, 핵심 고객이 방향을 전환한 경우입니다. 원래의 비즈니스 전제가 더 이상 유효하지 않은데 기술적 관성 때문에 프로젝트를 계속하는 것은 매몰 비용 오류의 가장 위험한 형태입니다. 완성하더라도 시장에서 의미 있는 가치를 만들지 못할 수 있습니다.

시그널 5: 대안 기술의 등장으로 근본 경쟁력 상실

지난 2~3년간 AI와 클라우드 서비스의 급격한 발전은 많은 IT 프로젝트의 존재 이유를 근본부터 흔들었습니다. 1년 전에 팀이 직접 구축하기로 한 자연어 처리 엔진이 이제는 클라우드 API 한 줄로 더 높은 정확도를 제공합니다. 6개월간 개발한 데이터 파이프라인이 매니지드 서비스로 대체 가능해졌습니다.

이런 상황에서 “우리가 직접 만든 것이 더 커스터마이징이 가능하다”는 반론이 나올 수 있지만, 정직하게 비교해봐야 합니다. 그 커스터마이징의 가치가 추가 개발·유지보수 비용을 정당화할 만큼 큰지, 아니면 기술적 자존심이 판단을 흐리고 있는 것인지를 구분해야 합니다.

이 다섯 가지 시그널은 각각 독립적으로도 주의가 필요하지만, 복수의 시그널이 동시에 나타날 때 위험도는 기하급수적으로 커집니다. 하지만 위기 시그널을 감지했다고 해서 무조건 프로젝트를 중단해야 하는 것은 아닙니다. 핵심은 감이 아닌 구조화된 판단으로 다음 행동을 결정하는 것입니다.

Kill·Pivot·Persevere — 세 갈래 의사결정 프레임워크

위기 시그널을 감지한 뒤의 선택지는 세 가지입니다. 프로젝트를 완전히 중단하거나(Kill), 방향을 전환하거나(Pivot), 현재 경로를 유지하며 문제를 해결하거나(Persevere). 에릭 리스(Eric Ries)의 린 스타트업 방법론에서 유래한 이 세 갈래 프레임워크를 IT 프로젝트 맥락에 맞게 재구성했습니다.

Kill — 프로젝트 완전 중단

Kill은 가장 어렵지만 때로는 가장 현명한 선택입니다. 다음 조건 중 두 가지 이상이 충족되면 Kill을 진지하게 고려해야 합니다.

• 원래의 비즈니스 전제가 완전히 무효화되었다. 시장이 바뀌어서 완성하더라도 수요가 없거나, 이미 경쟁사가 시장을 선점해 진입 자체가 무의미한 경우입니다.
• 남은 작업량이 이미 투자한 양보다 크다. 50%를 완성하는 데 6개월이 걸렸는데, 냉정한 기술 검토 결과 나머지 50%에도 8개월 이상이 필요한 경우입니다. 특히 핵심 인력 이탈로 남은 팀의 역량이 감소한 상태라면 이 추정치는 더 늘어납니다.
• 동일한 목표를 10분의 1 비용으로 달성하는 대안이 존재한다. 매니지드 서비스, SaaS 솔루션, 오픈소스 프로젝트 등으로 핵심 요구사항의 80% 이상을 충족할 수 있다면, 나머지 20%의 차별화가 지금까지의 투자와 앞으로의 추가 투자를 정당화하는지 냉정하게 따져봐야 합니다.
• 프로젝트가 조직의 핵심 역량에서 벗어나 있다. “우리가 잘하는 일”이 아닌 영역에서 무리하게 내재화를 추진하고 있었다면, 차라리 외부 솔루션에 위임하고 핵심 역량에 리소스를 집중하는 것이 합리적입니다.

Pivot — 방향 전환

Pivot은 프로젝트의 핵심 자산(코드, 기술, 도메인 지식)을 보존하면서 목표나 접근 방식을 근본적으로 바꾸는 선택입니다. Kill과 Persevere의 중간이 아니라 완전히 다른 종류의 결정입니다. Pivot이 적합한 상황은 다음과 같습니다.

• 기술은 유효하지만 타겟 사용자나 시장이 달라져야 하는 경우. B2B용으로 개발하던 분석 도구가 B2C 시장에서 더 큰 가능성을 보인다든지, 내부 시스템으로 개발하던 것이 외부 고객용 제품으로 전환할 가치가 있는 경우입니다.
• 아키텍처의 일부 레이어만 문제인 경우. 데이터 레이어는 견고한데 프론트엔드 설계가 근본적으로 잘못되었다면, 프론트엔드만 완전히 새로 설계하는 피벗이 전체를 중단하는 것보다 효율적입니다.
• 원래 목표의 하위 기능이 독립적 가치를 가지는 경우. 전사 ERP를 구축하다 보니 그 안의 워크플로 엔진이 단독 제품으로서의 가능성을 보인다면, 범위를 대폭 줄이고 워크플로 엔진에 집중하는 피벗이 가능합니다.

Pivot의 핵심 원칙은 “하나만 바꾼다”는 것입니다. 타겟 사용자를 바꾸거나, 기술 스택을 바꾸거나, 비즈니스 모델을 바꾸는 것 중 한 가지만 변경합니다. 두 가지 이상을 동시에 바꾸면 그것은 Pivot이 아니라 사실상 새 프로젝트이므로 Kill 후 신규 프로젝트로 시작하는 것이 더 깔끔합니다.

Persevere — 현재 경로 유지

위기 시그널이 감지되었더라도 Persevere가 올바른 선택일 때가 있습니다. 다만, 이 경우에도 “그냥 계속한다”가 아니라 명확한 근거와 조건부 지속이어야 합니다.

• 위기의 원인이 일시적이고 해결 가능한 경우. 핵심 인력 이탈이 연봉 불만 때문이고 조직이 이를 해결할 의지와 예산이 있다면, 프로젝트를 중단할 필요는 없습니다. 기술 부채가 특정 모듈에 집중되어 있고 2~3주의 집중 리팩토링으로 해소 가능하다면 이 역시 Persevere의 영역입니다.
• 전략적 중요도가 재무적 손실을 상쇄하는 경우. 프로젝트가 회사의 핵심 경쟁력 확보, 규제 대응, 보안 강화 등 금전 환산이 어려운 전략적 가치를 가진다면, 단기 비용을 감수하고 지속할 근거가 됩니다.

Persevere를 선택할 때는 반드시 타임박스를 설정하세요. “앞으로 6주간 지속하되, 6주 뒤 다음 마일스톤을 달성하지 못하면 Kill 또는 Pivot을 재논의한다”와 같이 구체적인 기한과 판단 기준을 미리 합의합니다. 기한 없는 Persevere는 매몰 비용 함정의 또 다른 이름일 뿐입니다.

세 선택지를 가르는 핵심 질문

프레임워크를 실전에서 적용할 때 다음 세 가지 질문을 순서대로 던져보세요.

• 질문 1: “만약 오늘 이 프로젝트가 처음이라면, 지금의 정보를 가지고도 시작했을까?” — 이 질문은 매몰 비용을 의도적으로 제거합니다. 답이 “아니오”라면 Kill이나 Pivot을 진지하게 고려해야 합니다.
• 질문 2: “프로젝트가 성공했을 때의 가치가 남은 투자 비용의 최소 3배 이상인가?” — 불확실성을 감안한 최소 기대 수익률입니다. IT 프로젝트의 성공 확률이 일반적으로 50% 이하인 점을 고려하면 3배는 보수적인 기준입니다.
• 질문 3: “이 리소스를 다른 곳에 투입한다면 더 큰 가치를 만들 수 있는가?” — 기회비용 관점입니다. 프로젝트에 묶인 인력과 예산이 다른 이니셔티브에서 만들어낼 가치를 함께 고려해야 비교가 완전해집니다.

이 세 질문에 정직하게 답하면, Kill·Pivot·Persevere 중 어디로 가야 하는지가 자연스럽게 드러납니다.

혼자 결정하지 마세요 — 팀 합의 기반 중단 판단법

프레임워크가 아무리 좋아도 한 사람의 판단에만 의존하면 편향을 완전히 제거할 수 없습니다. 프로젝트의 지속 여부처럼 이해관계가 얽힌 고부담 결정은 반드시 팀 합의 프로세스를 통해야 합니다. 여기서는 실전에서 검증된 세 가지 기법을 소개합니다.

프리모템(Pre-mortem) 세션

포스트모템(사후 분석)은 프로젝트가 실패한 뒤에 하는 것이지만, 프리모템은 프로젝트가 실패했다고 가정하고 원인을 미리 분석하는 사고 실험입니다. 심리학자 게리 클라인(Gary Klein)이 개발한 이 기법은 다음과 같이 진행합니다.

• 팀 전원이 모인 자리에서 “이 프로젝트가 6개월 뒤 완전히 실패했다”는 시나리오를 선언합니다.
• 각자 5분간 “왜 실패했을까”를 독립적으로 적습니다. 이때 서로의 답을 보지 않는 것이 핵심입니다.
• 돌아가며 한 사람씩 발표하고, 모든 원인을 화이트보드에 모읍니다.
• 패턴을 분류하고, 가장 빈도 높은 실패 원인이 현재 프로젝트에 이미 나타나고 있는지를 점검합니다.

프리모템의 가장 큰 장점은 “나쁜 소식을 말해도 되는” 심리적 안전망을 제공한다는 것입니다. “프로젝트가 실패할 것이다”가 아니라 “실패했다고 가정하면”이라는 프레임을 쓰기 때문에, 평소에 프로젝트 비관론을 꺼내기 어렵던 주니어 멤버도 자유롭게 의견을 낼 수 있습니다. 이 세션에서 나온 위험 요소가 앞서 다룬 5가지 위기 시그널과 겹친다면, 그것은 팀 전체가 공유하는 객관적 위기 인식입니다.

레드팀 리뷰

레드팀 리뷰는 프로젝트 지속을 주장하는 팀(블루팀)과 중단을 주장하는 팀(레드팀)으로 나누어 구조화된 토론을 하는 방법입니다. 핵심 규칙은 레드팀 역할을 자원이 아닌 지정으로 배정한다는 것입니다.

프로젝트 리더나 아키텍트처럼 프로젝트에 가장 깊이 관여한 사람을 레드팀에 배정하면 효과가 극대화됩니다. 왜냐하면 그들이야말로 프로젝트의 약점을 가장 잘 알기 때문입니다. 자신이 만든 시스템을 공격하는 역할을 강제로 맡으면, 평소에 무의식적으로 회피하던 약점이 수면 위로 올라옵니다.

레드팀 리뷰 후에는 양쪽의 논점을 정리하고, Kill·Pivot·Persevere 프레임워크의 세 질문을 팀 전체가 함께 답변합니다. 이 과정을 거치면 결정에 대한 팀의 합의 수준이 비약적으로 높아집니다.

익명 투표 + 공개 토론

가장 간단하면서도 효과적인 방법입니다. Kill·Pivot·Persevere 중 하나를 익명으로 투표한 뒤, 투표 결과를 공개하고 각자의 이유를 돌아가며 설명합니다. 익명 투표는 집단 사고(Groupthink)와 상사 눈치를 제거하고, 이어지는 공개 토론은 각 선택지의 논리를 심층 검증합니다.

실무에서는 이 세 가지 기법을 조합해서 사용할 수 있습니다. 예를 들어 프리모템 세션으로 위험 요소를 먼저 도출한 뒤, 레드팀 리뷰로 지속·중단의 논거를 날카롭게 다듬고, 마지막에 익명 투표로 팀의 합의를 형성하는 식입니다.

어떤 방법을 쓰든 핵심 원칙은 동일합니다. 결정의 근거를 문서화하세요. “왜 Kill했는가”, “왜 Persevere를 선택했는가”를 기록으로 남기는 것은 미래의 유사한 결정에서 조직의 판단력을 높여주는 자산이 됩니다. 또한 “나중에 어떻게 됐는지”를 추적하면 팀의 예측 정확도가 실제로 향상됩니다.

프로젝트를 접은 뒤에도 남는 것들 — 자산 회수 전략

Kill을 결정했다고 해서 모든 것이 사라지는 것은 아닙니다. 사실 매몰 비용 오류를 강화하는 가장 큰 착각이 바로 “중단 = 전부 낭비”라는 생각입니다. 현명하게 접으면 놀라울 정도로 많은 것을 건질 수 있습니다.

코드와 컴포넌트 재활용

프로젝트 전체는 실패했더라도 그 안의 개별 컴포넌트는 독립적인 가치를 가질 수 있습니다. 인증 모듈, 파일 업로드 처리기, 로깅 시스템, API 게이트웨이, 데이터 변환 파이프라인 같은 범용 컴포넌트를 추출하여 사내 라이브러리나 공통 모듈로 등록하세요.

이때 중요한 것은 프로젝트 종료 결정 후 2주 이내에 이 작업을 완료하는 것입니다. 시간이 지나면 코드의 맥락을 기억하는 사람이 줄어들고, 다른 프로젝트에 투입되면서 이 작업의 우선순위가 끝없이 밀립니다. 종료 결정과 동시에 “자산 회수 스프린트”를 1~2주 일정으로 잡고, 구체적인 산출물 목록을 정하세요.

기술 문서와 도메인 지식 보존

프로젝트를 진행하면서 쌓인 도메인 지식은 코드보다 더 가치 있을 수 있습니다. “이 외부 API는 문서와 다르게 동작한다”, “이 비즈니스 로직에는 이런 엣지 케이스가 있다”, “이 아키텍처 패턴은 이런 규모에서 한계를 보인다” 같은 경험적 지식은 다음 프로젝트에서 같은 실수를 반복하지 않게 해줍니다.

프로젝트 종료 시 ADR(Architecture Decision Record) 형태로 핵심 의사결정과 그 결과를 기록하세요. “왜 이 기술을 선택했는가”, “결과적으로 어떤 문제가 있었는가”, “다시 한다면 무엇을 다르게 할 것인가”를 솔직하게 남기는 것입니다. 이 문서는 조직의 기술적 판단력을 높여주는 귀중한 자산이 됩니다.

팀 역량과 관계의 보존

프로젝트가 실패해도 그 과정에서 팀원들이 습득한 기술과 경험은 사라지지 않습니다. 새로운 프레임워크를 익히고, 대규모 시스템 설계를 경험하고, 장애 대응을 해본 경험은 고스란히 팀원 개개인의 역량으로 남습니다.

프로젝트 종료 후 팀원들의 다음 배치를 신중하게 결정하세요. 이 프로젝트에서 쌓은 특정 기술이나 도메인 지식이 유용한 다른 프로젝트에 배치하면 “실패 프로젝트의 자산”이 자연스럽게 이전됩니다. 가장 피해야 할 것은 프로젝트 종료와 함께 팀을 해체하고 멤버를 각자 다른 곳에 흩어놓는 것입니다. 함께 고생하며 형성된 팀워크와 의사소통 패턴은 그 자체로 가치 있는 조직 자산입니다.

실패 회고(Retrospective) 의무화

프로젝트를 접은 뒤 가장 중요한 마지막 단계는 정식 실패 회고를 여는 것입니다. 포스트모템이라고도 부르는 이 세션에서는 비난 없이(Blameless) 다음 질문들을 다룹니다.

• 언제 처음으로 위기 시그널이 나타났는가? 그때 왜 대응하지 못했는가?
• 의사결정 과정에서 어떤 편향이 작용했는가?
• 같은 상황이 다시 온다면 몇 개월 전에 Kill/Pivot 결정을 내렸어야 했는가?
• 이 경험에서 조직이 프로세스로 제도화할 수 있는 교훈은 무엇인가?

이 회고의 결과물은 반드시 문서화하여 조직 전체가 접근 가능한 곳에 보관합니다. 실패에서 배우지 않으면 같은 실패가 반복됩니다. 하지만 실패를 체계적으로 기록하고 공유하는 조직은 실패할 때마다 더 강해집니다.

접는 것도 실력입니다

IT 업계는 “끝까지 해내는 사람”을 영웅으로 그립니다. 밤새 코딩해서 불가능해 보이던 기능을 완성하고, 데드라인 직전에 극적으로 배포하는 이야기가 미담으로 회자됩니다. 하지만 현실에서는 “멈출 때를 아는 사람”이 더 큰 가치를 만드는 경우가 훨씬 많습니다.

매몰 비용 오류를 극복하는 것은 단순히 돈을 아끼는 문제가 아닙니다. 가장 귀중한 자원인 팀의 시간과 에너지, 그리고 구성원들의 동기와 열정을 의미 있는 곳에 집중시키는 전략적 의사결정입니다. 실패하고 있는 프로젝트에 묶인 시간은 성공할 수 있는 다른 프로젝트를 시작할 기회를 빼앗습니다.

이 글에서 소개한 프레임워크를 당장 내일의 팀 회의에 적용해보세요. 5가지 위기 시그널 중 해당하는 것이 있는지 점검하고, Kill·Pivot·Persevere 세 질문을 팀과 함께 답해보세요. 처음에는 불편할 수 있지만, 이 과정을 반복할수록 팀의 의사결정 근육이 강해지고, 매몰 비용 함정에 빠지는 빈도가 확연히 줄어들 것입니다.

“접을 때를 아는 것”은 포기가 아니라, 더 나은 시작을 위한 가장 용기 있는 결정입니다.

이미지는 Leonardo AI 로 생성되었습니다.

이미지는 Claude AI 로 생성되었습니다.