안녕하세요, AI로 개발을 하고 있는 아키라 파파(あきらパパ)입니다.

오늘은 「만드는 기술」이 아니라, 그 반대인 「그만두는 기술」에 대해 이야기해보고자 합니다. 수수한 주제지만, AI가 당연해진 지금, 이 부분이 가장 효과적일 것이라는 느낌이 듭니다.

TL;DR

• AI로 「만드는」 비용은 순식간이 되었지만, 「그만두는」 비용은 낮아지지 않았다. 그래서 그만두는 판단의 중요도만 폭발적으로 상승하고 있다.
• 사람이 그만두지 못하는 것은 의지가 약해서가 아니라 「매몰 비용 (Sunk Cost)」이라는 뇌의 습성 때문이다. 이는 시스템으로 해결할 수 있다.
• 해결책은 「Kill Criteria (철수 기준)」를 시작하기 전, 냉정할 때 미리 써두는 것이다. 「무엇이」, 「언제까지」, 「어떻게 되면 철수한다」는 3종 세트로 결정한다.
• 그것을 kill-criteria.yml에 작성하고, TypeScript로 CONTINUE / REVIEW / KILL을 판정하게 하며, GitHub Actions로 기한이 지난 실험을 자동으로 찾아낸다. AI에게는 프리모템 (Pre-mortem), 기준 만들기, 매몰 비용 감지를 돕게 한다. 단, 「그만둘지/계속할지」의 최종 판단은 인간이 쥔다.
• 그만두는 것은 실패가 아니다. "오늘 그만둬줘서 고마워"라고 내일의 내가 말해줄 선택이다.

서론 — 만드는 것이 순식간이 되어, 늘어난 것은 「그만두지 못하는 것들」이었다

솔직하게 되돌아봐 주셨으면 합니다. 최근 1년 동안, 무언가 만들다가 방치해둔 것이 있지 않나요?

주말에 기세로 만든 툴. 돌아가기는 하지만 절반만 완성된 채 멈춰있는 앱. "일단 시도해볼까" 하고 세운 PoC (Proof of Concept, 개념 증명용 검증판). AI에게 부탁하면 몇 시간 만에 형태가 갖춰지기 때문에, 우리는 점점 더 새로운 것을 만들어낼 수 있게 되었습니다. 이것은 정말 대단한 일입니다.

하지만 말이죠, 여기서 이상한 일이 일어나고 있습니다. 만드는 속도는 빨라졌는데, 왜인지 수중은 점점 어질러지고 있습니다. 왜라고 생각하시나요?

답은 간단합니다. 저렴해진 것은 「만드는」 비용뿐이기 때문입니다. 「그만두는」 비용은 1mm도 낮아지지 않았습니다. 오히려 무한히 시작할 수 있게 된 만큼, 「그만두는 판단」을 하지 않으면 어중간한 것들이 눈덩이처럼 불어납니다.

이것은 제게 꽤 큰 발견이었습니다. AI 시대에 가장 희소한 것은 더 이상 「만드는 힘」이 아닙니다. 한정된 시간을 어디에 쓰지 않을지를 결정하는 힘. 그런 느낌이 듭니다.

이 기사에서는 그 「그만두는 것」을 근성이 아니라 시스템으로 다루는 방법을 써 내려가겠습니다. 심리학과 코드 양쪽에서 공략하겠습니다. 내일부터 자신의 실험에 바로 사용할 수 있는 YAML, TypeScript, GitHub Actions, 프롬프트까지 전부 남겨두겠습니다.

왜 「그만두는 것」이 가장 어려운가 — 매몰 비용과 에스컬레이션의 정체

먼저, 왜 우리는 그만두지 못하는 걸까요? 의지가 약해서일까요? 아닙니다. 뇌의 자연스러운 습성 때문이므로 자신을 탓할 문제가 아닙니다. 이 부분을 먼저 파악해두면 나중에 편해집니다.

첫 번째 습성은 「매몰 비용 (Sunk Cost)」입니다. 어려운 말 같지만 내용은 매우 친숙합니다.

사실은 앞으로의 시간이 즐거운가 하는 점만으로 「보는 것을 그만둘지」를 결정해야 합니다. 이미 지불한 티켓값은 돌아오지 않습니다. 그런데도 우리는 "여기까지 했다"를 이유로 미래의 시간까지 녹여버립니다.

두 번째가 「에스컬레이션 오브 커밋먼트 (Escalation of Commitment)」입니다. 이는 매몰 비용의 형님 격으로, 잘 풀리지 않는다는 증거가 쌓이고 있음에도 오히려 더 깊게 빠져드는 현상입니다. "조금만 더 돈을 쓰면 만회할 수 있을 거야"라고 생각하는 것이죠.

유명한 예로, FBI가 만들려고 했던 사건 관리 시스템이 있습니다. 설계도 요건도 엉망이었지만 멈추지 못했고, 결국 약 1억 7,000만 달러를 사용한 뒤 2005년에 중지되었습니다. 조직 차원에서도 이런 일이 일어납니다. 개인이라면 더더욱 일어납니다.

그렇다면 어떻게 벗어날까요? 의사결정의 세계에는 굉장히 단순하고 강력한 질문이 있습니다.

"만약 지금, 과거의 투자가 제로인 상태에서 이것을 알게 되었다면, 오늘부터 새로 시작하겠는가?"

이 질문에 "아니, 시작하지 않겠어"라고 생각한다면, 그것은 계속하는 이유가 「앞으로의 가치」가 아니라 「이미 사용한 부분」이 되어 있다는 증거입니다. 계속하든 그만두든, 판단 재료는 항상 앞으로의 일뿐입니다. 지나간 일은 판단에서 제외한다. 이것이 대원칙입니다.

그렇긴 하지만, 이 질문을 「그만두고 싶어진 순간」에 자신에게 던져봤자 대개 패배합니다. 왜냐하면 그 순간은 감정과 체면이 최고조에 달해 있기 때문입니다. 그래서 우리는 감정이 섞이지 않은 냉정한 상태에서 규칙을 미리 정해둘 필요가 있습니다. 그것이 다음 이야기입니다.

Kill Criteria (철수 기준)란 — 시작하기 전에 「끝내는 법」을 적는 것

여기서 주인공이 등장합니다. 바로 「Kill Criteria (철수 기준)」입니다.

의사결정 연구자이자 전직 프로 포커 플레이어인 애니 듀크(Annie Duke) 씨가 저서 『Quit』를 통해 퍼뜨린 개념으로, 간단히 말해 "이 상황이 되면 그만둔다/재검토한다"라는 선을 시작하기 전에 미리 그어두는 것입니다.

포커 플레이어답다는 생각이 들 수도 있겠지만, 그녀의 말에 따르면 대부분의 사람은 "그만두는 시점이 너무 늦다"라고 합니다. 너무 일찍 그만두어 실패한 사람보다, 물러날 때를 놓쳐 침몰한 사람이 압도적으로 많다는 것이죠. 따라서 철수는 근성이 아니라 사전 설계로 커버해야 하는 기술입니다.

철수 기준을 만드는 방법은 매우 간단하며, 두 가지 요소를 조합하기만 하면 됩니다.

상태 (state): 관측 가능한 조건. "사용자가 10명 늘지 않는다", "테스트가 3회 연속 실패한다"와 같이 누구나 판정할 수 있는 것 -
기한·상한 (date / budget): "다음 주말까지", "20시간을 사용하면"과 같은 시간이나 비용의 구분

이를 합치면 다음과 같습니다.

"3주 동안, 주 1회라도 사용하는 사람이 5명에 도달하지 못하면, 이 실험은 종료한다."

포인트는 이것을 냉정할 때 작성하는 것입니다. 심리학 용어로 「코ールド 스테이트 (cold state)」, 즉 머리에 피가 쏠리지 않은 평상시를 말합니다. 시작하기 전의 설레는 타이밍이나, 적어도 아무 일도 일어나지 않은 조용한 시기에 미래의 자신에게 하는 약속으로서 적어두는 것입니다.

그리고 그 「상태 (state)」를 떠올리는 데 최고의 도구가 바로 「프리모텀 (pre-mortem)」입니다. 이는 인지심리학자 게리 클라인(Gary Klein) 씨가 퍼뜨린 기법으로, 방법은 다음과 같습니다.

프로젝트의 「사후 (post-mortem)」 검증(포스트모텀 = 왜 실패했는지를 나중에 조사하는 것)의 반대를 수행합니다. 아직 시작하기 전임에도 불구하고, "6개월 후, 이것은 처참하게 실패했습니다"라고 가정하고 그 이유를 전부 적어 내려가는 것입니다.

신기하게도 "무엇이 실패할 것인가?"라고 긍정적으로 묻는 것보다, "이미 실패했다, 왜인가?"라고 과거형으로 묻는 것이 사람은 더 많은 이유를 댈 수 있다고 합니다. 연구에 따르면 나오는 이유가 약 30% 정도 증가했다고 합니다. 「실패했다는 전제」를 하면 말하기 어려웠던 리스크도 입 밖으로 내기 쉬워지는 것이죠.

이 프리모텀에서 나온 「실패의 이유」를 앞서 말한 「상태 (state)」로 번역해 나갑니다. 이것이 좋은 철수 기준을 만드는 가장 빠른 지름길입니다.

구현 1: 철수 기준을 기계 판독 가능하게 만들기 (kill-criteria.yml ＋ 판정 코드)

이제 직접 움직여 봅시다. 머릿속에만 넣어두면 잊어버리기 때문에, 철수 기준은 파일에 작성하고 코드로 판정하게 만듭시다. 「잊어버릴 것을 전제」로 시스템화하는 것이 요령입니다.

먼저, 실험별 철수 기준을 하나의 YAML 파일에 작성합니다. YAML은 "항목: 값"을 나열한 것뿐인, 사람과 프로그램 모두 읽을 수 있는 설정 파일이라고 생각하면 됩니다.

# kill-criteria.yml — 실행 중인 실험의 "종료 방식"을 한 장으로 관리한다
experiments:
- id: weekend-todo-app
...

적는 내용은 어려운 것이 아닙니다. "언제까지 재검토할 것인가", "무엇이 어떻게 되면 위험 신호인가", "그때 무엇을 할 것인가". 이 세 가지만 있으면 됩니다. current (현재 값)를 주 1회 업데이트하면, 판정은 코드에 맡길 수 있습니다.

다음으로, 이 YAML을 읽어 "계속한다/재검토한다/그만둔다"를 출력하는 TypeScript를 작성합니다. 타입을 지정해 두면 기준을 잘못 작성했을 때도 바로 알아챌 수 있어 기분이 좋습니다.

// evaluateKillCriteria.ts — 철수 기준에 비추어 판정한다
type Operator = ">=" | "<=" | ">" | "<" | "==";
type Decision = "CONTINUE" | "REVIEW" | "KILL";
...

왜 굳이 코드로 만드는 걸까요? 그것은 「그만두는 판단」을 자신의 기분으로부터 분리하기 위해서입니다. 기분에 맡기면 컨디션이 좋은 날은 전부 계속하고 싶어지고, 우울한 날은 전부 그만두고 싶어집니다. 기준을 외부에 꺼내 놓으면 판정은 언제나 동일한 규칙으로 이루어집니다. 이것이 효과를 발휘합니다.

구현 2: 기한이 지난 실험을 자동으로 찾아내기 (CI로 "잊어버림" 방지)

철수 기준을 작성해도 사람은 보통 잊어버립니다. review_by 날짜 같은 것은 다음 주면 기억에서 사라져 버리죠. 그래서 「기한이 되면 알아서 어깨를 톡톡 두드려 주는」 장치를 추가합니다. 여기서 유용한 것이 GitHub Actions, 즉 정해진 타이밍에 자동으로 스크립트를 실행해 주는 시스템입니다.

매주 월요일 아침에 모든 실험의 기한을 체크하고, 지나갔다면 알려주는 설정은 다음과 같습니다.

呼ばれる側のスクリプトは、YAMLを読んで「見直し期限を過ぎてる実験」を一覧にするだけ。短くてOKです。

// scripts/check-stale.mjs — 期限切れの実験を炙り出して知らせる
import { readFileSync } from "node:fs";
import { parse } from "yaml";
...

これで、放置されたゾンビ実験が「静かに生き続ける」のを防げます。賞味期限の切れた食材を、冷蔵庫が勝手に教えてくれる感じですね。

もうひとつ、すぐ止められる仕掛けとして「キルスイッチ」も入れておくと安心です。機能フラグ（feature flag＝コードを消さずにオン/オフを切り替える旗）を1個用意しておくだけ。

// killSwitch.ts — コードを消さずに、実験を即オフにできる旗
const FLAGS: Record<string, boolean> = {
"weekend-todo-app": true, // ← false にするだけで機能停止
...

撤退を決めても、止めるのが面倒だと先延ばしになります。だから「やめる」を1行で実行できる状態にしておく。決断のハードルと、実行のハードルは、別々に下げておくのがコツです。

AIに「やめ時」を考えさせる3つのプロンプト

ここでようやくAIの出番です。といっても、AIに「やめるか決めて」と丸投げするわけじゃありません。AIは候補を広く出すのが得意で、人間は意味を判断するのが得意。だから役割を分けます。AIは下書き、人間が最終決定です。

そのまま使えるプロンプトを3つ置いておきますね。

ひとつめは、プレモーテムを手伝ってもらうプロンプト。失敗の理由を出させて、それを撤退基準の「状態」に変換させます。

あなたはリスク分析の専門家です。プレモーテムを行ってください。
# 前提
今から「{プロジェクトの一言説明}」を始めます。
...

ふたつめは、自分が書いた撤退基準をレビューしてもらうプロンプト。基準って、自分で書くとだいたい曖昧になるんですよ。「うまくいかなかったら」とか。それを測れる形に直してもらいます。

次の撤退基準のドラフトをレビューしてください。
# ドラフト
{自分のkill-criteria.ymlの中身を貼る}
...

みっつめは、いちばん大事かもしれない、埋没コスト検知のプロンプト。「やめたほうがいい気がするけど踏ん切りがつかない」ときに、自分の思考が過去に引っ張られてないかチェックしてもらいます。

継続するか迷っている判断について、埋没コストの影響を点検してください。
# 状況
{いま続けるか迷っていることと、これまでに使った時間/お金/労力}
...

この3つを通すと、「なんとなくやめられない」が「測れる判断」に変わっていきます。AIは、自分の頭の中の言語化されてないモヤモヤを、外に出して並べ直す相棒として最高なんですよね。

落とし穴と、人間とAIの役割分担

便利な道具ほど、使い方を間違えると逆効果になります。撤退基準でハマりやすいポイントを正直にまとめておきます。

基準をこっそり甘くする（撤退の撤退）: いざ期限が来ると「あと2週間あれば…」と基準のほうを書き換えてしまう。これをやると仕組みが全部無意味になります。基準の変更は、必ず日付と理由をログに残すこと -
やめること自体が目的化する: 早すぎる撤退も同じくらい危険。だから「KILL」の前に「REVIEW（立ち止まる）」を必ず挟む。撤退も継続も、forward-lookingで冷静に決める -
お金と時間しか見ていない: 撤退基準は数字だけじゃない。「これを続けると睡眠が削れる」「家族との時間が消える」も立派な状態。お金以外の資源も基準に入れる -
AIの判断を鵜呑みにする: AIは「それっぽい理由」を自信たっぷりに並べます。最終判断を渡してはいけない。AIは材料出し、人間が決める -
基準を書いて満足する: 書いただけでcurrent

（今の値）を更新しなければ、ただのお守りです。週1で見る習慣とセットでようやく機能する -
不可逆な操作を自動化しすぎる: 本番DBの削除、課金停止、公開取り下げ。こういう戻れない操作は、コードがKILLと言っても人間の確認を必ず挟む

역할 분담을 표로 나타내면 다음과 같습니다.

결국 AI에게 맡길 수 있는 것은 "생각할 재료를 빠르고, 넓고, 냉정하게 나열하는 것"까지입니다. "그래서, 어떻게 할 것인가?"를 책임지는 것은 언제나 자기 자신입니다. 하지만 재료가 갖춰져 있다면 그 결정은 훨씬 수월해집니다. 그것이 이 메커니즘의 목표입니다.

요약 — "오늘 그만둬줘서 고마워요"

내용이 길어졌으니 핵심만 요약하겠습니다.

AI로 '만드는 것'이 순식간에 이루어지는 시대에 희소한 것은 만드는 능력이 아니라, 한정된 시간을 어디에 쓰지 않을지 결정하는 능력입니다. 그만두지 못하는 것은 의지가 약해서가 아니라, 매몰 비용 (Sunk Cost)이라는 뇌의 습성 때문입니다. 그러므로 근성이 아니라 시스템으로 해결해야 합니다.

구체적으로는, 냉정할 때 "무엇이 · 언제까지 · 어떻게 되면 철수한다"를 작성하여 kill-criteria.yml에 반영하고, 코드로 CONTINUE / REVIEW / KILL을 판정하게 하며, CI (지속적 통합)를 통해 기한 만료를 찾아냅니다. AI에게는 프리모텀 (Pre-mortem)과 기준 만들기, 매몰 비용 탐지를 돕게 하고, 결정은 자신이 직접 내립니다.

마지막으로, 가장 전하고 싶은 말이 있습니다.

그만두는 것은 실패가 아닙니다.

죽어가는 실험을 의도적으로 종료하는 것은, 남은 리소스를 아직 살아있는 쪽으로 돌리기 위한 긍정적인 선택입니다. 많이 시도하고 많이 놓아주는 방식을 진심으로 실행하려면, '잘 그만두는 기술'이 반드시 세트로 필요합니다. 오히려 제대로 끝낼 줄 아는 사람만이 안심하고 많이 만들어낼 수 있습니다.

제가 선택을 고민할 때 항상 스스로에게 묻는 것이 있습니다. "이 선택, 내일의 내가 '고마워요'라고 말해줄까?"라고 말이죠. 이것은 무조건 노력하는 쪽을 택하라는 의미가 아닙니다. "오늘 과감하게 그만둬줘서 고마워요" 또한 훌륭하게 같은 축 안에 있습니다. 그만두는 것에 죄책감을 가질 필요는 없습니다.

오늘 30분 안에 할 수 있는 첫걸음을 제안합니다. 지금 안고 있는 실험이나 태스크를 하나 골라, "언제까지 재검토할 것인가"라는 날짜를 딱 하나만 정해 보세요. 그것만으로 충분합니다. 그것만으로도 미래의 당신은 "미리 끝내는 법을 생각해둬서 고마워요"라고 말해줄 것입니다.

함께, 잘 그만두어 봅시다.

참고 링크

• Annie Duke 『Quit: The Power of Knowing When to Walk Away』 (kill criteria / 사전 커밋의 사고방식): https://www.penguinrandomhouse.com/books/655329/quit-by-annie-duke/
• Gary Klein "Performing a Project Premortem" (Harvard Business Review, 2007): https://hbr.org/2007/09/performing-a-project-premortem
• The Decision Lab 「Sunk Cost Fallacy (매몰 비용의 오류)」 해설: https://thedecisionlab.com/biases/the-sunk-cost-fallacy
• Wikipedia 「Escalation of commitment (몰입의 에스컬레이션)」: https://en.wikipedia.org/wiki/Escalation_of_commitment
• Ness Labs 「Pre-mortem: anticipate failure with prospective hindsight」: https://nesslabs.com/pre-mortem-anticipate-failure-with-prospective-hindsight

Discussion