프로젝트가 실패하면 어떻게 하는가

프로젝트가 무너졌을 때 누가 무엇을 받고, 무엇이 기록되고, 무엇이 남습니까? 이 장은 실패와 부정직을 구분하는 기준, 조기 종료와 부분 정산의 절차, 그리고 실패를 다음 협력의 자산으로 바꾸는 방법을 다룹니다.

질문에서 시작합니다

가상의 장면입니다. 12주짜리 PoC(개념검증) 프로젝트가 7주차에 멈췄습니다. 고객이 준 데이터로는 목표 정확도가 나오지 않는다는 것이 분명해졌습니다. 연구자는 "데이터 자체가 문제"라고 하고, 개발자는 "접근을 바꾸면 될 수도 있다"고 하고, Lead는 고객에게 뭐라고 말해야 할지 모릅니다. 선금은 받았고, 다섯 명이 7주를 썼고, GPU 비용도 나갔습니다.

이때 팀 안에서 조용히 오가는 질문들이 있습니다. 내가 일한 7주는 보상받을 수 있을까. 실패한 프로젝트에 이름이 남으면 다음 프로젝트에 불려 갈 수 있을까. 고객에게 솔직하게 말하면 계약금을 돌려줘야 하나. 차라리 조금 더 끌면서 뭔가 보여 주는 게 낫지 않을까.

마지막 질문이 가장 위험합니다. 실패를 인정하는 비용이 너무 크다고 느끼는 순간, 사람들은 실패를 숨기기 시작합니다. 숨겨진 실패는 실패가 아니라 부정직이 됩니다. 그래서 이 장은 실패의 비용을 낮추는 방법에 관한 장입니다. 실패해도 괜찮은 조직만이 실패를 정직하게 다룰 수 있습니다.

왜 실패를 다루는 방식이 조직을 결정하는가

AI 프로젝트는 실패 확률이 높습니다. 모델이 목표 성능에 미치지 못하고, 데이터가 기대와 다르고, 고객의 문제가 알고 보니 AI로 풀 문제가 아니었다는 것이 뒤늦게 드러납니다. 기술이 빠르게 바뀌므로 12주 전의 최선이 지금은 최선이 아닐 수도 있습니다. 실패가 예외가 아니라 일상인 분야에서, 실패를 다루는 방식은 곧 조직의 작동 방식입니다.

전통 기업에서 실패는 인사 평가로 흡수됩니다. 누군가의 고과가 깎이고 조직은 계속 굴러갑니다. 시장에서 실패는 계약 분쟁으로 끝납니다. 손해배상을 다투고 다시는 서로 보지 않습니다. 느슨한 커뮤니티에서 실패는 조용히 사라집니다. 아무도 책임지지 않으므로 아무것도 배우지 못합니다.

프로토콜 조직(Protocol Organization)은 이 셋 어디에도 기댈 수 없습니다. 고용이 없으므로 인사 평가로 흡수할 수 없고, 관계가 계속되므로 분쟁으로 끝낼 수 없고, 기여가 기록되므로 조용히 사라질 수 없습니다. 실패가 남는 곳은 하나입니다. Trust Capital(신뢰 자산)입니다. 그래서 질문은 이렇게 바뀝니다. 실패를 어떻게 기록해야 그것이 다음 협력을 막지 않고 오히려 돕는가.

여기서 결정적인 구분이 필요합니다. 실패와 부정직은 다릅니다. 이 둘을 구분하지 못하는 조직은 두 가지 병에 걸립니다. 실패를 부정직처럼 다루면 아무도 어려운 프로젝트를 맡지 않습니다. 부정직을 실패처럼 다루면 아무도 서로를 믿지 않습니다. 둘 다 협력을 죽입니다.

실패와 부정직을 구분한다

커뮤니티는 프로젝트가 잘못되는 경우를 다섯 가지로 나눕니다. 앞의 셋은 실패이고, 뒤의 둘은 부정직입니다.

구분의 기준은 결과가 아니라 행동입니다. 기술 실패는 결과가 나쁜 것입니다. 고의 은폐는 행동이 나쁜 것입니다. 같은 프로젝트에서 같은 결과가 나와도, 문제를 3일 안에 팀에 알린 사람과 3주 동안 숨긴 사람은 다르게 기록됩니다. 신뢰는 말이 아니라 행동으로 쌓이고, 실패의 순간에 하는 행동이 가장 무겁게 기록됩니다.

경계에 있는 경우도 있습니다. 개발자가 "될 것 같다"고 말하며 2주를 더 쓴 뒤 안 됐다면 실패입니까, 은폐입니까. 기본 판단은 이렇습니다. 그 2주 동안 진행 상황을 사실대로 공유했다면 실패입니다. 진행 상황을 부풀리거나 질문을 피했다면 은폐입니다. 낙관은 실패의 원인이 될 수 있지만 부정직은 아닙니다. 부정직은 알면서 다르게 말하는 것입니다.

우리의 철학: 실패에는 관대하되 부정직에는 엄격하다

이 문장은 이 책의 여러 장에서 반복됩니다. 이 장에서는 그 이유를 실패의 편에서 설명합니다.

실패에 관대해야 하는 이유는 도덕이 아니라 설계입니다. 어려운 프로젝트에는 실패 확률이 있습니다. 실패의 비용이 크면 사람들은 쉬운 프로젝트만 맡고, 쉬운 프로젝트만 맡는 조직은 혼자서도 할 수 있는 일만 하게 됩니다. 함께 만드는 힘은 혼자서는 못 하는 일, 즉 실패할 수도 있는 일에서 나옵니다. 그래서 실패의 비용을 낮추는 것은 커뮤니티의 존재 이유와 직결됩니다.

부정직에 엄격해야 하는 이유도 설계입니다. 프로토콜 조직은 감시가 아니라 기록된 신뢰로 작동합니다. 감시 비용이 낮은 대신 신뢰가 깨졌을 때의 비용이 큽니다. 한 사람의 은폐가 허용되면 모든 사람이 서로를 확인해야 하고, 그 순간 이 조직은 시장(Market)보다 나을 것이 없어집니다. 부정직에 엄격한 것은 실패에 관대할 수 있기 위한 조건입니다.

그리고 한 가지가 더 있습니다. 사람을 소모품처럼 다루지 않는다는 약속은 실패한 프로젝트에서 가장 선명하게 시험받습니다. 성공한 프로젝트에서 사람을 잘 대하는 것은 쉽습니다. 무너진 프로젝트에서 7주를 일한 사람에게 "결과가 없으니 보상도 없다"고 말하지 않는 것, 그것이 이 약속의 실체입니다.

운영원칙 1: 조기 종료의 조건과 절차

프로젝트를 끝까지 끌고 가는 것이 언제나 옳지는 않습니다. 성공 가능성이 사라졌는데 계속하는 것은 참여자의 시간과 고객의 돈을 낭비하는 일입니다. 아래는 커뮤니티의 기본값(Default)이며 Project Charter(프로젝트 헌장)로 조정할 수 있습니다.

조기 종료를 검토해야 하는 신호.

1. 핵심 가설(기술적 실현 가능성, 데이터 품질, 고객 문제의 정의)이 틀렸음이 확인됐을 때
2. 남은 기간·예산으로 최소 목표에 도달할 수 없다고 Lead가 판단할 때
3. 고객의 사정(예산 삭감, 담당자 교체, 사업 방향 전환)으로 프로젝트의 전제가 사라졌을 때
4. 핵심 참여자의 이탈로 대체가 불가능할 때
5. 계속하는 것이 법적·윤리적 문제를 일으킬 때

절차.

위험 신호 인지
  │
  ├─ 1. 보고: 인지한 사람은 기본 3일 안에 Lead와 팀에 알림
  │      (이 3일이 실패와 은폐를 가르는 선입니다)
  │
  ├─ 2. 진단: Lead 주도로 원인과 선택지 정리
  │      계속 / 범위 축소 / 방향 전환 / 종료
  │
  ├─ 3. 결정: 범위·보상이 바뀌므로 이해관계 변경 → 참여자 합의
  │      Lead는 초안을 내고, 합의 시한은 기본 7일
  │
  ├─ 4. 고객 통보: 합의 후 즉시. 사실·원인·선택지·정산안을 함께
  │
  ├─ 5. 부분 정산: Project Settlement Sheet 작성
  │
  └─ 6. Closing Review: 종료 후 기본 2주 안에 실시

종료는 실행 결정이 아닙니다. 참여자의 보상과 범위가 달라지므로 이해관계 변경이고, 따라서 합의 사항입니다. 다만 Lead는 진단과 초안을 책임집니다. "실행은 빠르게, 이해관계 변경은 합의로"는 여기서도 작동합니다.

운영원칙 2: 부분 정산

실패한 프로젝트의 정산 원칙은 세 줄입니다.

1. 수행한 Work Compensation(수행 대가)은 지급합니다. 검수된 산출물 또는 Charter가 정한 투입 기준에 따라, 실제로 수행한 만큼 시장 단가로 지급합니다. 결과가 없다는 이유로 수행 대가를 깎지 않습니다.
2. Value Sharing(가치 배분)은 잉여가치가 없으면 없습니다. 잉여가치 = 수령 매출 − 직접비용 − Work Compensation. 이것이 0 이하면 나눌 것이 없습니다. 이것은 처벌이 아니라 정의입니다.
3. 손실 분담은 Charter가 정한 대로 합니다. 기본값은 Contracting Party(계약주체)가 손실을 부담하고, 그 부담을 Leadership & Risk 기여로 기록하는 것입니다. Charter에서 참여자 간 분담을 정했다면 그에 따릅니다. Charter에 규정이 없으면 참여자 합의로 정하되, Work Compensation을 소급해서 깎는 방식은 쓰지 않습니다.

숫자로 보겠습니다. 계약금 4천만원, 선금 40%인 1,600만원을 받은 상태에서 7주차에 종료했습니다. 직접비용(GPU 임대) 300만원. 7주간 수행분의 Work Compensation은 개발자 600만원, 연구자 500만원, 크리에이터 200만원, Lead 200만원, 합계 1,500만원입니다. 잉여가치는 1,600 − 300 − 1,500 = −200만원. Value Sharing은 없고, Community Share도 없습니다. 손실 200만원은 Charter 기본값에 따라 계약주체가 부담하고, 그 사실은 계약주체의 위험부담 기여로 기록됩니다.

수령한 돈이 Work Compensation에 미치지 못하는 경우도 있습니다. 이때 기본값은 수령액 범위에서 Work Compensation을 비율대로 먼저 지급하고, 부족분은 Charter의 손실 분담 규칙에 따라 처리하는 것입니다. 참여자 전원이 "이번 부족분은 각자 감수한다"고 합의할 수 있습니다. 그러나 그것은 합의여야 하지 Lead나 계약주체의 통보여서는 안 됩니다.

정산에서 자주 생기는 오해가 있습니다. "실패했으니 Lead가 책임지고 보상을 포기해야 한다"는 주장입니다. 기본값은 그렇지 않습니다. Lead의 판단이 실패의 원인이었더라도, Lead가 수행한 일의 Work Compensation은 지급합니다. Lead가 감당하는 것은 Closing Review에 자기 판단의 실패가 기록되는 것입니다. 그것으로 충분합니다. 돈으로 벌하기 시작하면 아무도 Lead를 맡지 않습니다.

운영원칙 3: 고객 대응

실패를 고객에게 알리는 방식은 고객 관계의 나머지 전부를 결정합니다.

1. 먼저 알립니다. 고객이 먼저 눈치채기 전에 팀이 알립니다. 늦게 알리는 것은 고객에게는 은폐로 보입니다.
2. 사실과 원인을 분리해서 말합니다. "정확도가 목표에 미달했다"는 사실과 "데이터의 라벨 오류율이 높았다"는 원인을 구분합니다. 원인이 고객 쪽에 있어도 비난하지 않고 기술합니다.
3. 선택지를 함께 냅니다. 범위 축소, 방향 전환, 종료. 각 선택지의 비용과 정산안을 붙입니다. 실패를 알리는 자리는 다음 결정을 묻는 자리입니다.
4. 정산은 계약과 Charter에 따릅니다. 선금 반환 여부는 계약이 정합니다. 계약에 없으면 수행한 산출물의 가치를 기준으로 협의합니다. 중간 산출물(정제된 데이터, 평가 체계, 실험 기록)은 고객에게 실제 가치가 있는 경우가 많습니다.
5. 창구는 하나입니다. 고객 커뮤니케이션은 Lead 또는 Lead가 지정한 사람이 맡습니다. 참여자가 각자 고객에게 다른 설명을 하는 것이 실패한 프로젝트에서 가장 흔한 2차 사고입니다.

역할별로 보면 이 원칙의 무게가 다릅니다. 사업가와 계약주체에게는 "먼저 알리기"가 어렵습니다. 후속 계약이 걸려 있기 때문입니다. 그러나 정직하게 실패를 알린 팀에 후속 프로젝트를 맡기는 고객은 생각보다 많습니다. 연구자에게는 "원인을 비난 없이 기술하기"가 어렵습니다. 데이터가 나빴다는 말은 사실이지만 고객에게는 책임 전가로 들릴 수 있습니다. 개발자와 크리에이터에게는 "창구를 하나로 두기"가 답답할 수 있습니다. 고객이 직접 물어 올 때 "Lead를 통해 정리해서 드리겠다"고 답하는 것이 팀을 지키는 일입니다.

운영원칙 4: 실패를 어떻게 기록하는가

Project Closing Review(종료평가)는 성공한 프로젝트보다 실패한 프로젝트에서 더 중요합니다. 기록이 없으면 실패는 소문이 되고, 소문은 사실보다 사람을 더 크게 다치게 합니다.

Closing Review에 기록하는 것.

• 프로젝트의 목표와 실제 결과
• 실패의 유형(기술·시장·일정)과 원인
• 위험 신호가 언제 인지됐고 언제 공유됐는지
• 각 참여자가 실제로 수행한 것과 그 품질
• 정산 내역과 손실 분담
• 배운 것과, 다음에 같은 프로젝트를 한다면 무엇을 다르게 할 것인지
• 참여자 상호 평가와 재협업 의사

실패가 Trust Capital을 깎지 않는 조건. 아래 다섯 가지를 지킨 참여자의 Trust Capital은 실패한 프로젝트로 인해 내려가지 않습니다. 오히려 "어려운 프로젝트를 끝까지 정직하게 다룬 사람"으로 기록됩니다.

반대로 이 조건을 어긴 경우, 즉 알고도 숨기거나, 정산을 회피하거나, Closing Review에 나타나지 않거나, 책임을 남에게 돌린 경우에는 실패가 아니라 부정직으로 기록됩니다. 같은 프로젝트에서 어떤 참여자는 신뢰가 올라가고 어떤 참여자는 내려갈 수 있습니다. 결과는 같아도 행동이 달랐기 때문입니다.

Trust Capital에 실패 프로젝트가 기록되는 방식도 중요합니다. 플랫폼은 "실패 1건"이라고 적지 않습니다. "기술 실패, 조기 공유, 정산 완료, 재협업 의사 4/4"처럼 행동을 적습니다. 다음 프로젝트의 Lead가 이 기록을 보고 판단할 수 있어야 합니다. 어려운 프로젝트에서 정직했던 사람은, 쉬운 프로젝트만 성공한 사람보다 더 믿을 만할 수 있습니다.

실패담 세션: 배운 것을 나누는 문화

실패는 한 Project Cell의 것이지만, 실패에서 배운 것은 커뮤니티의 것입니다. 커뮤니티는 Circle(서클) 단위로 실패담 세션을 엽니다. 종료된 프로젝트의 참여자가 무엇을 시도했고 왜 안 됐고 무엇을 배웠는지를 나누는 자리입니다.

이 세션에는 규칙이 있습니다.

1. Chatham House Rule을 적용합니다. 내용은 가져가되 발언자와 프로젝트를 특정하지 않습니다.
2. 고객 정보는 보호합니다. 고객명·계약 조건·미공개 기술은 말하지 않습니다. 프로젝트의 Confidentiality 등급이 Cell-only 이상이면 Lead가 공유 범위를 먼저 정합니다.
3. 비난하지 않습니다. 세션의 목적은 원인 분석이지 책임 추궁이 아닙니다. 책임 추궁은 Closing Review와 윤리·분쟁위원회의 일입니다.
4. 기여로 기록합니다. 실패담을 공유한 사람은 플랫폼에 Knowledge 기여로 기록됩니다. 실패를 나누는 것은 커뮤니티에 주는 것입니다.

실제로 해본 사람만 아는 지식의 절반은 실패에서 나옵니다. "이 데이터 유형에는 이 접근이 안 된다", "이 산업의 고객은 PoC 단계에서 이런 기대를 한다", "GPU 예산은 이렇게 잡으면 부족하다." 이런 지식은 공개 인터넷에 없습니다. 실패담 세션은 커뮤니티가 같은 실패를 두 번 하지 않게 하는 장치이며, 실패한 사람이 다시 기여자로 서는 자리입니다.

Case: 7주차에 멈춘 PoC

다음은 가상의 사례입니다.

상황. 물류기업의 수요 예측 PoC였습니다. 12주, 4천만원, 선금 1,600만원. 파운더 조 대표가 Originator이자 계약주체였고, 개발자 문 씨가 Lead, 연구자 남 박사가 모델, 크리에이터 류 씨가 결과 대시보드와 보고 영상, 신규회원 학생 홍 씨가 Junior Slot으로 데이터 정제를 맡았습니다.

갈등. 5주차에 홍 씨가 데이터 정제 중 이상한 것을 발견했습니다. 과거 2년치 데이터의 상당 부분이 실제 수요가 아니라 시스템 기본값으로 채워져 있었습니다. 홍 씨는 신규회원이라 말하기를 망설였습니다. 이틀 뒤 남 박사에게 조심스럽게 물었고, 남 박사는 즉시 Lead에게 알렸습니다. 문 씨는 하루 만에 팀 전체에 공유했습니다. 위험 인지에서 공유까지 3일이었습니다.

적용. 문 씨는 진단을 주도했습니다. 남은 데이터만으로는 목표 정확도의 절반도 어려웠습니다. 선택지는 셋이었습니다. 고객이 데이터를 다시 수집할 때까지 중단, 목표를 낮춰 계속, 종료. 조 대표는 후속 계약이 걸려 있어 "어떻게든 뭔가 보여 주자"고 했습니다. 남 박사는 "보여 줄 수 있는 것은 데이터가 왜 쓸 수 없는지뿐"이라고 했습니다.

참여자 합의는 5일 걸렸습니다. 결론은 종료였고, 대신 "데이터 진단 보고서와 재수집 설계안"을 산출물로 고객에게 전달하기로 했습니다. 조 대표가 고객에게 알렸습니다. 고객 담당자는 처음에 실망했지만, 데이터 문제가 자기 회사의 다른 시스템에도 영향을 준다는 것을 알고는 오히려 고마워했습니다.

정산은 앞서 본 숫자와 같습니다. 수령 1,600만원, GPU 300만원, Work Compensation 1,500만원(홍 씨의 데이터 정제 100만원 포함, Lead 200만원은 문 씨). 잉여 −200만원. Value Sharing 없음. 손실 200만원은 Charter대로 조 대표의 회사가 부담했고, Leadership & Risk 기여로 기록됐습니다.

결과. Closing Review에는 "시장 실패에 가까운 데이터 실패, 5주차 인지, 3일 내 공유, 고객 선통보, 정산 완료"가 기록됐습니다. 다섯 명 전원의 재협업 의사는 서로에 대해 긍정이었습니다. 홍 씨의 기록에는 "신규회원으로서 핵심 위험을 최초 발견"이 남았고, 다음 프로젝트에서 Junior Slot이 아닌 정식 자리를 제안받았습니다. 남 박사는 Research Circle 실패담 세션에서 "기본값으로 채워진 데이터를 탐지하는 법"을 발표했고, 이것은 Knowledge 기여로 기록됐습니다.

4개월 뒤 같은 고객이 데이터 재수집을 끝내고 다시 연락했습니다. 이번에는 6천만원짜리 정식 프로젝트였습니다. 고객이 같은 팀을 원한 이유는 하나였습니다. "안 되는 것을 안 된다고 말한 팀"이었기 때문입니다.

Remember

• 실패와 부정직은 다릅니다. 기술 실패·시장 실패·일정 실패는 결과가 나쁜 것이고, 책임회피·고의 은폐는 행동이 나쁜 것입니다. 기록도 다르게 남습니다.
• 성공 가능성이 사라졌으면 조기 종료를 검토합니다. 위험 신호를 인지한 뒤 기본 3일 안에 알리는 것이 실패와 은폐를 가르는 선입니다. 종료는 이해관계 변경이므로 참여자 합의로 정합니다.
• 부분 정산의 원칙은 세 줄입니다. 수행한 Work Compensation은 지급합니다. Value Sharing은 잉여가 없으면 없습니다. 손실 분담은 Charter가 정한 대로 합니다.
• 고객에게는 먼저, 사실대로, 선택지와 함께 알립니다. 창구는 하나로 둡니다.
• 조기 공유·사실 기록·고객 정직·정산 성실·검토 참여를 지킨 참여자의 Trust Capital은 실패로 깎이지 않습니다. 실패에서 배운 것은 실패담 세션을 통해 커뮤니티의 지식이 됩니다.

"실패에는 관대하되 부정직에는 엄격하다."