TL;DR

• 판단 TTL이란 의사결정에 '재판단할 시각'을 부여하는 사고방식입니다.
• TTL은 Time To Live의 약자로, 원래 캐시(Cache)나 네트워크 세계에서 '얼마나 유효한 것으로 간주할지'를 나타내는 용어입니다.
• 이 글에서는 TTL을 인간의 판단에도 응용합니다. 단, '기한이 지났으니 버린다'가 아니라, '오래된 전제를 재검토하기' 위해 사용합니다.
• Obsidian에서는 frontmatter가 포함된 Decision note를 만듭니다. frontmatter는 Markdown 파일의 맨 앞에 두는 메타데이터(Metadata)입니다.
• TypeScript로 기한이 만료된 판단을 감지하고, GitHub Actions로 주간 체크를 할 수 있습니다.
• AI에게 결단을 통째로 맡기지 않습니다. 자료 정리, 반론 생성, 놓친 부분 확인을 도와달라고 합니다.

솔직히 AI를 사용할수록 '결정하는 힘'의 중요성이 높아지고 있다고 느낍니다.

왜냐하면, AI는 선택지를 늘리는 데 엄청나게 능숙하기 때문입니다. 구현 안, 설계 안, 개선 안, 제목 안, 사업 아이디어. 물어보면 물어볼수록 계속 나옵니다.

하지만 선택지가 늘어날수록, 인간 측에서 '어떤 것으로 갈 것인가'를 결정하지 않으면 앞으로 나아갈 수 없습니다. 이 부분을 모호하게 둔 채 AI에게 작업을 맡기면, 출력물은 늘어나는데 성과는 늘어나지 않는 이상한 상태가 됩니다.

이 글에서는 그 막힘을 '판단 TTL'이라는 작은 시스템으로 분해해 나갑니다. 어려운 사상적인 이야기로 끝내지 않고, Markdown 템플릿, TypeScript 스크립트, GitHub Actions, 프롬프트(Prompt) 예시까지 다룹니다.

왜 AI 시대일수록 '결정하지 않는 비용'이 늘어나는가

AI가 없던 시대의 미루기는 비교적 눈에 잘 보였습니다. 조사하지 않았다, 쓰지 않았다, 구현하지 않았다. 손이 멈춰 있기 때문에 스스로도 '아, 진행되지 않고 있구나'라고 깨달을 수 있습니다.

하지만 AI 시대의 미루기는 조금 까다롭습니다.

조사는 진행됩니다. 요약도 늘어납니다. 초안도 나옵니다. 대화 로그도 늘어납니다. 그런데 마지막에 '그래서, 이번에는 이 안으로 간다'라는 결정이 내려지지 않습니다. 즉, 행동하고 있는 것처럼 보이는 미루기가 발생합니다.

이것은 정말 까다로운 문제입니다.

예를 들어 새로운 기능을 만든다고 가정해 봅시다. AI에게 물어보면 A안, B안, C안, 각각의 장점과 단점이 나옵니다. 추가로 물어보면 보안 관점도, UI 관점도, 운영 관점도 나옵니다. 정보는 점점 늘어납니다.

하지만 결정하지 않은 채 3일이 지나면 어떻게 될까요?

• 경쟁 상황이 변함
• 팀의 여유 시간이 변함
• 자신의 열정이 떨어짐
• 처음에 보고 있었던 전제를 잊어버림
• AI에게 똑같은 상담을 다시 하여, 또 비슷한 로그가 늘어남

정보는 늘어났는데, 의사결정의 신선도는 떨어집니다. 이 부분이 핵심입니다.

그래서 저는 미루는 습관을 '성격이 약해서'라고 보지 않는 것이 좋다고 생각합니다. 물론 마음의 문제도 전혀 없지는 않습니다. 하지만 설계로 줄일 수 있는 부분이 상당히 많습니다.

판단에 이름을 붙인다. 이유를 남긴다. 언제 재검토할지 결정한다. 오래된 판단을 기계적으로 찾아낸다.

이것만으로도 상당히 달라집니다.

판단 TTL이란 무엇인가: 기한이 아니라, 재판단의 시각

TTL은 Time To Live의 약자입니다. 기술 세계에서는 캐시(Cache)나 DNS 등에서 '이 정보를 언제까지 유효하다고 간주할 것인가'를 나타낼 때 자주 사용됩니다.

이를 인간의 판단에 도입하면 '판단 TTL'이 됩니다.

단, 여기서 중요한 것은 '마감(Deadline)'과 혼동하지 않는 것입니다.

마감은 언제까지 끝낼 것인가입니다. 판단 TTL은 언제 재판단할 것인가입니다.

예를 들어, 다음과 같은 차이가 있습니다.

'판단이 부패한다'라는 표현은 조금 강할지도 모릅니다. 하지만 실무에서는 정말로 일어나는 일입니다.

일주일 전에는 옳았던 판단이 오늘도 옳으리라는 보장은 없습니다. 새로운 제약 조건이 생겼을 수도 있고, 우선순위가 바뀌었을 수도 있습니다. AI가 생성한 전제가 틀렸다는 것을 나중에 깨닫는 경우도 있습니다.

그래서 판단 TTL에서는 의사결정을 다음 네 가지로 다룹니다.

• 무엇을 결정했는가
• 왜 그렇게 결정했는가
• 언제 재검토할 것인가
• 어떤 일이 일어나면 조기에 재검토할 것인가

이것은 사소해 보이지만 효과적입니다.

인간은 잊어버립니다. 게다가 자신이 왜 망설였는지를 잊어버립니다. 그래서 일주일 후에 똑같은 일로 다시 망설입니다. 이것이 쌓이면 인생도 프로덕트도 앞으로 나아가기 어려워집니다.

판단 TTL은 미래의 자신에게 '이 판단, 슬슬 재검토할 타이밍이에요'라고 건네는 메모입니다. AI에게 인생을 결정하게 만들기 위한 시스템이 아니라, 인간이 더 잘 결정하기 위한 보조 바퀴입니다.

Obsidian으로 판단이 부패하지 않는 템플릿 만들기

먼저 Obsidian에서 Decision note를 한 장 만듭니다. Obsidian이 아니더라도 Markdown을 다룰 수 있다면 VS Code나 GitHub에서도 괜찮습니다.

여기서 사용하는 것이 frontmatter입니다. Markdown 파일의 맨 앞에 ---로 감싸서 메타데이터를 작성하는 것이죠. Zenn의 기사나 GitHub의 문서, 정적 사이트 생성기(Static Site Generator)에서도 자주 등장합니다.

예를 들어, docs/decisions/2026-06-16-use-worker-queue.md라는 파일을 만들고 다음과 같이 작성합니다.

---
title: "알림 처리를 동기 실행이 아닌 큐(Queue)로 넘기기"
status: "accepted"
...

포인트는 판단을 '문장'으로만 남기지 않는 것입니다.

문장으로만 남기면 나중에 기계적으로 추출할 수 없습니다. decisionTtl과 같은 필드를 만들어 두면 TypeScript로 검출할 수 있습니다. 이것은 엄청나게 큰 차이를 만듭니다.

물론 처음부터 완벽하게 할 필요는 없습니다. 첫 번째 노트는 다음 4가지 항목만 있어도 충분합니다.

• 결정한 것
• 왜 결정했는가
• 재검토할 날짜
• 재검토 조건

이 정도라면 5분 만에 작성할 수 있습니다.

TypeScript로 만료된 판단을 검출하기

다음으로, decisionTtl이 지난 Decision note를 찾는 스크립트를 작성합니다.

여기서는 gray-matter로 frontmatter를 읽고, fast-glob으로 Markdown 파일을 찾습니다. 둘 다 표준적인 작은 라이브러리입니다.

설치 예시

npm install gray-matter fast-glob
npm install -D typescript tsx @types/node

먼저 scripts/check-decision-ttl.ts를 만듭니다.

import fs from "node:fs";
import path from "node:path";
import fg from "fast-glob";
...

실행은 다음과 같습니다.

npx tsx scripts/check-decision-ttl.ts

여기서 process.exitCode = 1로 설정한 이유는, 만료된 판단이 있을 경우 CI(지속적 통합)에서 인지할 수 있도록 하기 위해서입니다.

단, 오해하지 말아야 할 점은 CI가 실패했다고 해서 나쁜 것이 아니라는 점입니다. 오히려 좋은 검출입니다. '판단을 재검토할 날이 왔다'는 것을 알게 된 것뿐입니다. 버그가 아니라 리뷰를 위한 신호인 것입니다.

이렇게 설계하면 미루는 습관은 정신론의 영역에서 관측 가능한 대상으로 변합니다.

"왠지 요즘 진척이 없네"가 아니라, "이 3건의 판단이 TTL 만료되었습니다"라고 말할 수 있습니다. 이것만으로도 다음 단계가 상당히 명확해집니다.

GitHub Actions로 주간 리뷰 만들기

로컬에서 작동한다면, 다음은 주 단위로 자동 실행합니다.

GitHub Actions는 GitHub 상에서 스크립트나 테스트를 자동으로 실행할 수 있는 메커니즘입니다. 테스트를 돌리기 위해 자주 사용되지만, 문서의 건강 진단(Health Check) 용도로도 사용할 수 있습니다.

.github/workflows/check-decision-ttl.yml을 만듭니다.

name: Check decision TTL
on:
  schedule:
...

이렇게 하면 매주 월요일에 판단 TTL을 체크할 수 있습니다. workflow_dispatch도 포함되어 있으므로 GitHub 화면에서 수동으로 실행할 수도 있습니다.

팀에서 사용한다면 이대로 CI를 실패하게 두어도 좋지만, 처음에는 조금 부드럽게 시작하는 것이 지속하기 좋습니다.

예를 들어, 첫 한 달은 CI를 실패시키지 않고 리포트만 출력합니다. 익숙해지면 영향 범위가 큰 판단만 실패하게 만듭니다. 더 익숙해지면 PR(Pull Request) 템플릿에 "Decision note가 필요한가?"라는 항목을 넣습니다.

한꺼번에 완성형을 목표로 하면 대개 무거워집니다. 우선은 주 1회 "오래된 판단을 찾는 것"만으로도 충분합니다.

AI에게 '결정 재료'와 '결정하지 않는 이유'를 분리해 달라고 하기

여기서부터 AI를 활용하는 방법입니다.

판단 TTL과 AI는 궁합이 좋습니다. 하지만 AI에게 "어떤 것을 해야 할까?"라고 통째로 맡기는 것은 위험합니다. AI는 그럴듯한 답을 내놓겠지만, 책임을 지는 것은 인간입니다.

따라서 AI에게는 역할을 나누어 부여합니다.

우선, 판단 재료의 정리부터 시작합니다.

당신은 제품 개발의 의사결정을 지원하는 리뷰어입니다.
다음 Decision note를 읽고, 의사결정에 필요한 재료를 정리해 주세요.
수행할 작업:
...

다음으로, 미루는 이유를 분해합니다.

다음 의사결정이 미뤄지고 있습니다.
"게으름 피우기 때문"이 아니라, 구조적인 이유로 분해해 주세요.
분류:
...

마지막으로, 반론을 내놓게 합니다.

당신은 조금 엄격한 기술 리뷰 담당자입니다.
다음 판단에 대해 반대 의견을 5개 제시해 주세요.
단, 비판에서 끝내지 말고, 각각에 검증 방법을 덧붙여 주세요.
...

이 세 가지를 사용하면, AI는 "결정하는 사람"이 아니라 "판단의 품질을 높이는 사람"이 됩니다.

그리고 여기서 중요한 점은, AI와 상담한 결과도 Decision note에 남겨두는 것이 좋다는 것입니다. 전부 붙여넣을 필요는 없습니다. 요점만 있으면 됩니다.

• AI에게 확인한 관점
• 추가로 발견된 리스크
• 그럼에도 불구하고 채택하는 이유
• 다음에 재검토할 조건

이 네 가지가 남아 있다면, 나중에 다시 보았을 때 "왜 이 판단을 했는가"를 복원할 수 있습니다.

팀 운영에 도입할 때의 주의점

개인적으로 사용한다면 Decision note는 상당히 자유로워도 괜찮습니다. 하지만 팀에 도입한다면 약간의 규칙이 필요합니다.

우선, 모든 판단을 기록하려고 하지 마세요.

이렇게 하면 금방 파탄 납니다. 점심 메뉴를 정하는 것까지 Decision note에 적고 있다면 아무도 지속할 수 없습니다. 대상은 "나중에 다시 고민하려면 비용이 많이 드는 판단"으로 좁힙니다.

예를 들어, 다음과 같은 것들입니다.

• 기술 선정
• 아키텍처 변경
• 외부 서비스 도입
• 요금 설계
• 데이터 보관 기간
• 보안 방침
• AI 에이전트에게 맡길 작업 범위

다음으로, TTL의 초기값을 정해두면 편합니다.

물론 엄격할 필요는 없습니다. 중요한 것은 판단하는 순간 "언제 재검토할지"를 함께 결정하는 것입니다.

그리고 리뷰할 때 책임을 묻지 마세요.

"왜 기한이 지났나요?"라고 말하면 모두가 숨기고 싶어집니다. 그 대신, "이 판단, 전제가 바뀌지는 않았나요?" 정도면 충분합니다.

판단 TTL은 책임의 소재를 모호하게 만들기 위한 도구가 아닙니다. 오히려 그 반대입니다. 결정한 이유와 재검토 조건을 남김으로써, 책임 있는 변경을 더 쉽게 만들어 줍니다.

개인 개발도 마찬가지입니다.

제품을 만들다 보면, 만들기 전의 판단보다 만든 후의 현실이 더 강력합니다. 사용자가 쓰지 않거나, 생각보다 운영이 무겁거나, 다른 기능이 성장하는 경우입니다. 그런 현실에 맞춰 판단을 업데이트할 수 있는 사람이 강합니다.

AI 시대에는 만드는 속도가 빨라집니다. 그렇기에 판단을 업데이트하는 속도도 높이고 싶은 것입니다.

요약

미루는 습관은 의지만으로 고치기에는 힘듭니다.

특히 AI 시대에는 조사도, 브레인스토밍(Wall-hitting)도, 초안 작성도 쉬워졌습니다. 그렇기에 결정하지 않았는데도 진행되고 있는 것 같은 상태가 발생하기 쉽습니다.

판단 TTL은 그 상태에 이름을 붙이기 위한 작은 장치입니다.

• 판단에 재판단 시각을 부여한다
• Obsidian이나 Markdown에 이유를 남긴다
• TypeScript로 기한 만료를 검출한다
• GitHub Actions로 주간 리뷰를 수행한다
• AI에게는 재료 정리와 반론 생성을 맡긴다
• 최종 판단은 인간이 내린다

이 흐름이 만들어지면, 미래의 자신이 엄청나게 도움을 받게 됩니다.

우선, 지금 망설이고 있는 판단을 딱 하나만 골라서 Decision note를 만들어 보세요. 완벽한 템플릿은 필요 없습니다.

"무엇을 결정했는가", "왜 결정했는가", "언제 재검토할 것인가", "무엇이 일어나면 재검토할 것인가".

이 네 가지만 있으면 됩니다.

그리고 7일 후의 자신에게 넘겨주세요.

그것만으로도 미루는 습관은 조금씩 관측 가능해집니다. 관측할 수 있는 것은 개선할 수 있습니다. 여기서 시작하는 것이 가장 현실적이지 않을까 합니다.

참고 링크

Discussion