가설을 쪼개라고 써놓고, 정작 우리 원장에는 성공 기준이 한 줄도 없었습니다

저희는 프로젝트를 시작할 때 가설을 세 층으로 쪼개라고 씁니다.

대가설  1개      문제의 근본 원인
  └ 중가설 2~4개   대가설이 참이면 반드시 성립해야 하는 것
      └ 소가설 1개씩  2주 안에 실제로 판정할 것

이게 저희 문서에 실제로 적용돼 있는지 확인해보기로 했습니다. 그 과정에서 두 가지가 나왔는데, 하나는 저희 결함이었고 하나는 저희 측정 방법의 결함이었습니다. 두 번째 것이 더 중요했습니다.

먼저, 측정이 틀렸습니다

작업 문서 전체를 훑어 "대가설"이 들어간 문서를 셌습니다. 3건이 나왔습니다. 낮은 숫자라 그대로 쓰려 했습니다.

그런데 그 3건을 열어봤습니다.

전부 대가설이라는 개념을 설명한 문서였습니다. 규칙을 정의한 문서, 그 규칙을 감사한 문서, 콘텐츠 소재를 적어둔 문서. 대가설을 실제로 세운 프로젝트 문서는 한 건도 없었습니다.

"3건"은 그 단어가 나오는 파일이 3개라는 뜻이었지, 그 층을 세운 프로젝트가 3개라는 뜻이 아니었습니다. 저희는 문자열을 세고 있었습니다.

한 번 더 확인해보니 더 분명해졌습니다. 이 글을 준비하면서 관련 문서를 몇 건 쓰자 같은 숫자가 6건으로 늘었습니다. 대가설을 세워서가 아니라, 대가설이라는 단어를 쓴 문서가 늘어서입니다. 지금 읽고 계신 이 글도 발행되면 그 숫자를 하나 더 올립니다.

단어를 세는 것과 실제로 하는지 보는 것은 다릅니다. 그래서 이 숫자는 이 글에서 증거로 쓰지 않았습니다.

문자열 함정이 없는 숫자 하나

대신 다른 걸 봤습니다. 저희는 모든 판단을 결정 원장에 기록합니다. 이 글을 쓰기 시작할 때 985건이었습니다.

이건 문서 본문이 아니라 기록의 칸이라, 단어가 아니라 칸이 채워졌는지를 봅니다.

• 이 결정이 성공했다고 볼 기준 — 0건
• 무엇을 보면 접을지 — 0건
• 언제 다시 볼지 — 0건

985건 중 0건이었습니다. 여기엔 해석의 여지가 없습니다.

옆에 놓고 보면 이렇게 됩니다.

결정      985건
실행    2,825건
결과       66건

결정과 실행은 쌓이는데 결과가 그 자리에 없습니다. 판정 기준을 안 적었으니 나중에 판정할 수가 없었던 겁니다.

그리고 오늘

이 숫자를 세는 과정에서 저희는 그날의 결정 세 건을 원장에 새로 넣었습니다.

그 세 건에도 성공 기준을 안 적었습니다.

세고 있던 결함을, 세는 중에 세 번 더 만들었습니다. 규칙을 몰라서가 아닙니다. 그 규칙은 저희가 썼습니다.

왜 이렇게 되나

이유는 단순했습니다. 결정하는 시점과 판정하는 시점이 다르기 때문입니다.

결정할 때는 무엇을 할지가 선명합니다. 그래서 그것만 적습니다. "무엇을 보면 이게 틀렸다고 인정할 것인가"는 그 순간 안 적어도 일이 진행됩니다. 당장은 아무 문제가 없습니다.

문제는 몇 달 뒤입니다. 그 결정을 다시 열면 무엇을 기준으로 잘됐다/안 됐다를 말할지 아무도 모릅니다. 그러면 대개 "그때는 그게 맞았다" 로 끝납니다. 판정이 아니라 회고가 됩니다.

층을 나누는 게 왜 필요한가

• 대가설은 프로젝트가 서 있는 전제입니다. 이게 틀리면 전부 다시 열어야 하니 자주 건드리지 않습니다.
• 중가설은 대가설이 참이면 반드시 따라와야 하는 것들입니다. 기각돼도 프로젝트는 삽니다.
• 소가설은 짧은 주기 안에 판정 가능한 크기로 자른 것입니다. 저희는 2주로 잡습니다.

핵심은 기각이 정상 상태가 된다는 점입니다. 중가설 하나가 틀렸다고 프로젝트가 무너지지 않으니, 틀렸다고 말할 수 있게 됩니다. 층이 하나뿐이면 가설을 부정하는 게 프로젝트를 부정하는 게 되어서, 아무도 틀렸다고 말하지 않습니다.

참고로 잘 설계된 실험에서도 목표 지표가 개선되는 경우는 3분의 1입니다. 나머지 3분의 1은 변화가 없고, 3분의 1은 오히려 나빠집니다. 기각은 예외가 아니라 기본값입니다.

오늘 한 가지만 한다면

지금 진행 중인 일 하나만 골라서 한 줄을 적어보시면 됩니다.

무엇을 보면 이게 틀렸다고 인정하겠는가

이 한 줄이 안 써지면 그 일은 아직 가설이 아니라 계획입니다. 계획은 끝낼 수는 있어도 판정할 수는 없습니다.

그리고 저희 경험에서 하나 덧붙이자면 — 그 한 줄을 적었는지 확인할 때, 문서에 그 단어가 있는지로 세지 마십시오. 저희가 그렇게 했다가 3이라는 숫자를 얻었고, 열어보니 0이었습니다.

이 글을 쓰면서 바뀐 것

과거 985건은 소급해서 채우지 못합니다. 대신 이 글을 쓰는 동안 그날의 결정 세 건에 세 칸을 채워 넣었습니다 — 성공 기준, 접을 기준, 다시 볼 날짜.

989건 중 3건입니다. 자랑할 숫자가 아닙니다. 다만 0이 아닌 첫 숫자이고, 앞으로 적는 결정이 어디서 시작하는지는 이걸로 정해졌습니다.

---

진행 중인 일이 판정 가능한 상태인지 모르겠다면
2분 진단으로 지금 먼저 손댈 과제 하나와 2주 파일럿 시작안, 사람이 꼭 확인해야 할 리스크를 정리해서 보실 수 있습니다. 편하신 만큼만 답하셔도 괜찮습니다.

STAR-T AI 사업 운영 진단 →

---

각주

① 참고자료·확인일 (측정 시각 2026-08-12 14:04 · 재측정 15:37)

• 결정 원장 985건 → 989건 (측정 중 증가) · 원장 직접 조회
• 성공 기준 / 접을 기준 / 재검토일 각 0건 → 3건 — 필드 존재 여부 조회. 3건은 이 글을 쓰며 채운 것
• 실행 / 결과 2,825 → 2,841 / 66 (본문 블록은 985건과 같은 시각 세트라 2,825 유지)
• "대가설" 문자열 검색 3건(8/10) → 6건(8/12) — ⚠️ 증거 아님. 본문에서 반례로만 사용

⚠️ 결정 원장은 매일 쌓이는 기록입니다. 위 총건수는 측정 시각 기준값이며 읽으시는 지금은 더 늘어 있습니다. 검수하는 동안에도 계속 바뀌었습니다(983 → 984 → 985 → 989). 변하지 않은 것은 "0건" 쪽입니다 — 이 글의 주장은 총건수가 아니라 그 0에 걸려 있습니다.

실험 결과가 개선·무효·악화로 각각 3분의 1씩 나뉜다는 것은 마이크로소프트가 12년간의 온라인 통제 실험을 정리해 2015년 학회에서 발표한 자료입니다.

② 이 글에 쓰지 않은 수치

• "대가설이 있는 문서 3건"을 결함의 근거로 쓰지 않았습니다. 초안에서는 이걸 제목에 넣었는데, 검수에서 문자열 카운트라 자기지시적으로 오염된다는 지적을 받고 확인해보니 사실이었습니다(3 → 6으로 증가). 숫자를 바꾸는 대신 그 실패 자체를 본문에 남겼습니다.
• 비율(%) 표기 — 분모에 로그·회의록처럼 가설이 필요 없는 문서가 대부분이라, 비율로 바꾸면 실제보다 나쁘게 읽힙니다.
• "적중률 3분의 1" — 내부 문서에는 이렇게 축약돼 있으나 원문은 개선/무효/악화 각 3분의 1입니다. 원문 쪽으로 적었습니다.
• 2주 기준의 외부 근거 — 짧은 주기를 권하는 외부 보고서가 있지만 그쪽 기준은 1주입니다. 저희 2주는 그보다 느슨하므로 남의 숫자를 근거로 빌리지 않았습니다.
• 트랙별 세부 수치 · 저희 강의·컨설팅 만족도나 실적 수치 — 주장과 무관해 뺐습니다.

③ 만든 방식
AI로 초안을 만들고 사람이 검증·편집했습니다. 초안은 사실 검수에서 한 번 반려됐습니다 — 핵심 수치가 측정 방법상 성립하지 않는다는 지적이었고, 확인 결과 맞아서 제목과 논지를 바꿔 다시 썼습니다. 생성형 이미지·음성은 사용하지 않았습니다.