AI 도구를 더 붙이기 전에, 나는 《It’s Not Luck》의 사고 프로세스를 꺼냈다

AI 도구를 더 붙였는데도 일이 안 빨라진다면, 문제는 도구가 아닐 수 있다

검색 도구를 하나 더 연결하고, 검토 에이전트를 추가하고, 더 긴 프롬프트를 만들었다. 그런데 작업은 여전히 늦다. 초안은 쌓이는데 결정은 미뤄지고, 같은 문제를 다른 표현으로 다시 묻는다. AI를 충분히 쓰고 있는데도 일이 앞으로 나아가지 않는다면, 지금 필요한 것은 새 도구가 아니라 무엇을 바꿔야 하는지 찾는 사고 도구다.

나는 이 문제를 엘리야후 M. 골드래트의 《It’s Not Luck》을 다시 보며 정리했다. 《The Goal》이 시스템의 병목을 찾아 “무엇을 바꿀 것인가”를 생각하게 했다면, 《It’s Not Luck》의 Thinking Processes(사고 프로세스)는 그다음 질문까지 밀어붙인다. 무엇으로 바꿀 것인가. 그리고 어떻게 실제 변화로 만들 것인가.

이 글의 결론은 단순하다. AI에게 해결책부터 요구하지 말고, 증상에서 핵심 갈등을 찾는 순서를 먼저 맡겨라. 그러면 도구를 늘리는 대신, 지금 작업을 막고 있는 한두 개의 가정을 확인할 수 있다.

《The Goal》 다음에 《It’s Not Luck》을 읽어야 했던 이유

《The Goal》을 읽고 나면 “모든 일을 조금씩 개선하는 것”이 전체 성과를 보장하지 않는다는 감각이 생긴다. 시스템의 흐름을 제한하는 병목을 찾아야 한다. 하지만 실제 업무에서 더 어려운 순간은 병목을 찾은 뒤다. 왜 사람들은 병목을 그대로 두는가? 왜 서로 맞는 말을 하는 팀이 계속 충돌하는가? 왜 해결책을 도입하면 다른 문제가 튀어나오는가?

이 책은 제조 현장에만 머물지 않는다. 공식 소개에 따르면 판매·마케팅·재고 관리·유통으로 Theory of Constraints(TOC)를 확장하고, 사업과 개인 상황의 갈등을 다루는 Thinking Processes를 소개한다. 즉, 병목을 “기계가 느린 곳”으로만 보지 않고 서로 양보할 수 없다고 믿는 선택 사이의 충돌로 확장한다.

외부 정보: Thinking Processes는 문제 해결 순서를 바꾼다

외부 정보(하베스터 수집): Goldratt Marketing은 TOC의 Thinking Processes가 지속적 개선을 위해 세 질문에 답한다고 설명한다. “What to change?”, “To what to change?”, “How to cause the change?”다. Theory of Constraints Institute도 이 도구들이 엄격한 원인-결과 논리로 근본 갈등과 검토하지 않은 가정을 찾아낸다고 정리한다.

고전적인 도구는 질문별로 나뉜다. Current Reality Tree(CRT)는 현재의 바람직하지 않은 결과를 원인으로 거슬러 올라가며 “무엇을 바꿀지” 찾는다. Evaporating Cloud(EC)는 두 선택이 충돌하는 이유와 그 아래의 가정을 드러낸다. Future Reality Tree(FRT)는 제안한 변화가 실제로 문제들을 없애는지 시험한다. 이후 Prerequisite Tree(PRT)와 Transition Tree(TT)가 장애물과 실행 순서를 다룬다.

핵심은 도구 이름을 외우는 데 있지 않다. 증상을 바로 고치려 하지 않고, 여러 증상을 동시에 만들어내는 구조를 먼저 찾는 데 있다. 답을 빨리 내놓는 AI의 성질과 정반대처럼 보이지만, 실제로는 AI를 더 유용하게 만드는 제동장치다.

상호작용: 내 작업의 병목은 생성 속도가 아니라 ‘멈출 기준’이었다

상호작용(에이전트-드루 대화·작업): 이 구분은 에이전트와 작업을 정리하던 대화에서 실제로 확인했다. 당시 보이는 문제는 여러 개였다. 자료를 더 찾아야 할 것 같았고, 초안은 계속 다듬어야 했고, 검토 의견은 반복됐고, 무엇을 완료로 볼지 늦게 결정됐다.

처음에는 검색이 부족하고 모델이 충분히 똑똑하지 않아서라고 생각하기 쉬웠다. 그래서 도구를 추가하는 방향으로 생각했다. 하지만 관찰한 현상을 시간 순서로 다시 놓아보니, 문제는 두 갈래로 줄었다. 작업 시작 전에 목표 결과물이 충분히 좁혀지지 않았다. 그리고 완료 여부를 판단할 기준이 생성 뒤에야 등장했다.

이건 외부 통계가 아니다. 내 작업을 에이전트와 다시 분해하면서 얻은 경험이다. 검색 호출 수를 늘리는 대신 “이 결정을 위해 반드시 확인할 근거는 무엇인가”를 먼저 물었다. 계속 개선하라고 하는 대신 “이 기준을 통과하지 못하는 부분만 표시하고, 통과하면 멈춰라”라고 요청했다.

결과적으로 에이전트가 덜 일한 것처럼 보였지만, 내가 판단할 수 있는 결과는 더 빨리 나왔다. 생산량이 줄어서가 아니라, 작업이 어느 지점에서 끝나는지 보였기 때문이다. 《It’s Not Luck》의 관점으로 말하면, 겉으로 드러난 “느린 초안”보다 아래의 갈등, 즉 더 많이 확인해야 안전하다와 빨리 결정해야 전진한다 사이의 가정을 먼저 다룬 셈이다.

AI에 Thinking Processes를 적용하는 5단계 워크플로

이 방법을 쓰기 위해 별도의 TOC 소프트웨어가 필요한 것은 아니다. 사용하는 LLM, 검색 도구, 문서 도구를 그대로 두고 질문의 순서만 바꾸면 된다. 다만 AI가 만든 원인-결과 연결은 가설이지 사실이 아니므로, 각 단계에서 실제 관찰이나 원문으로 확인해야 한다.

1. UDE를 사실 문장으로 적는다. “검색 도구가 나쁘다”가 아니라 “같은 주제를 세 번 검색했지만 결론에 필요한 근거가 매번 달랐다”처럼 관찰한 결과만 적는다.
2. CRT로 연결한다. AI에게 증상 사이의 원인-결과 연결을 제안하게 한다. 여러 증상을 설명하는 공통 원인과, 아직 근거가 없는 연결을 구분해 표시하게 한다.
3. EC로 갈등과 가정을 꺼낸다. 공통 목표, 양쪽이 지키려는 필요, 서로 반대되는 행동을 적는다. 각 연결 아래에 “왜 이것이 반드시 참이어야 하는가?”를 묻는다.
4. FRT로 해결책을 시험한다. 해결책을 바로 실행하지 말고, 그 조치가 각 증상을 없애는 경로를 써보게 한다. 새 부작용이 생기는 Negative Branch도 함께 찾는다.
5. PRT와 TT로 작게 실행한다. 장애물을 한 번에 다 없애려 하지 않는다. 첫 번째 검증 행동, 성공 조건, 중단 조건을 정하고 한 사이클만 실행한다.

이 순서가 중요한 이유는 AI가 보통 3단계로 바로 뛰어가기 때문이다. 증상을 보자마자 해결책을 추천하고, 사용자는 그럴듯한 답을 실행한다. 그 해결책이 실패하면 모델을 바꾸거나 도구를 추가한다. CRT와 EC를 앞에 놓으면 AI의 역할이 해결책 판매자에서 가설을 압축하고 숨은 가정을 드러내는 분석 파트너로 바뀐다.

복사해서 쓰는 AI 사고 프로세스 프롬프트

아래 프롬프트는 AI에게 정답을 맡기는 명령이 아니다. 너무 빨리 도구나 해결책을 추천하지 못하게 하는 작업용 템플릿이다.

아래는 내가 관찰한 작업 결과 목록이다.
원인이나 해결책으로 단정하지 말고, 다음 순서로 분석하라.

1. 관찰 사실과 이미 섞여 있는 가설을 분리하라.
2. 바람직하지 않은 결과(UDE)를 원인-결과 후보로 연결하라.
3. 가장 많은 UDE를 설명하는 공통 원인 후보를 최대 2개로 줄여라.
4. 각 후보를 유지시키는 핵심 갈등을 다음 형식으로 써라.
   - 공통 목표:
   - 필요 A / 행동 A:
   - 필요 B / 행동 B:
   - 두 행동이 충돌한다고 믿게 만드는 가정:
5. 가정을 확인하거나 반박할 관찰·문서·도구 호출을 후보마다 1개씩 제안하라.
6. 해결책은 검증 뒤에만 제안하라.
7. 해결책을 제안할 때는 원하는 결과, 예상 부작용, 첫 번째 검증 행동,
   성공 조건, 중단 조건을 함께 써라.
8. 근거가 없는 연결은 ‘미확인’으로 표시하라.

출력 형식:
- 관찰 사실
- UDE 목록
- 원인-결과 연결
- 핵심 원인 후보
- 핵심 갈등과 가정
- 확인할 근거
- 검증 후의 작은 실행

프롬프트에 작업의 목표와 완료 기준을 반드시 같이 넣어야 한다. “좋은 글을 써라”는 목표가 아니다. “독자가 20분 안에 자신의 반복 문제를 CRT와 EC로 정리하고 첫 검증 행동을 고를 수 있게 하라”처럼 결과를 좁혀야 한다. 그래야 AI가 자료를 더 많이 모으는 대신, 목적에 필요한 근거만 찾는다.

도구를 추가할지 말지는 EC의 가정이 결정한다

Thinking Processes를 AI 워크플로에 넣으면 도구 선택의 기준도 바뀐다. 원인이 목표 불명확이라면 새 검색 서비스보다 입력 형식과 완료 조건을 먼저 고친다. 원인이 근거 부족이라면 더 긴 답변을 만드는 모델보다 원문을 확인할 수 있는 검색·브라우징 도구가 필요하다. 원인이 검증 지연이라면 생성 에이전트를 늘리기보다 결과 바로 뒤에 체크리스트나 테스트를 붙인다.

특히 “안전하게 하려면 더 많이 검토해야 한다”는 가정은 자주 숨는다. 실제로는 검토 항목이 무한히 늘어나 결정을 막을 수 있다. 이때 필요한 것은 검토 에이전트 하나가 아니라, 어떤 근거가 있으면 멈출 수 있는지를 먼저 정하는 것이다. AI는 그 기준을 적용하고 빠진 항목을 찾는 데 쓰면 된다.

반대로 모든 업무에 CRT와 EC를 거창하게 적용할 필요도 없다. 한 번 발생한 단순한 오류라면 바로 고치는 편이 낫다. 같은 문제가 반복되고, 여러 사람이 서로 다른 해결책을 주장하고, 도구를 추가해도 결과가 달라지지 않을 때 Thinking Processes를 꺼내면 된다. 반복되는 갈등에만 구조를 적용하는 것이 이 접근의 첫 번째 비용 절감이다.

오늘의 실험: 도구 하나를 지우고, 갈등 하나를 적어라

오늘 반복해서 시간을 빼앗긴 작업 하나를 고르자. 새 AI 서비스를 구독하기 전에 20분만 투자하면 된다.

1. 최근 일주일 동안 실제로 일어난 불편을 해결책 없이 다섯 개 적는다.
2. 그중 원인처럼 보이는 문장을 관찰 사실로 다시 쓴다.
3. AI에게 CRT 초안을 만들게 하고, 근거가 없는 연결을 표시하게 한다.
4. 가장 큰 갈등 하나를 EC 형식으로 적고, 화살표마다 숨은 가정을 한 문장씩 쓴다.
5. 가정 하나를 확인할 수 있는 읽기 전용 근거와 첫 실행 행동을 정한다.

성공 기준은 AI가 정답을 맞히는 것이 아니다. 문제의 수가 줄고, 아직 모르는 것이 분명해지고, 다음에 확인할 한 가지가 생기는 것이다. 그 상태가 되면 새 도구를 붙일지 말지도 훨씬 쉽게 결정할 수 있다.

《The Goal》이 병목을 찾아 시스템의 흐름을 바꾸게 했다면, 《It’s Not Luck》은 그 병목을 유지시키는 생각의 충돌을 보게 한다. AI 시대에 이 차이는 더 커진다. 도구는 증상을 빠르게 처리하지만, 잘못된 가정까지 자동으로 강화할 수도 있기 때문이다.

지금 반복되는 작업 하나를 골라 UDE 다섯 개와 핵심 갈등 하나를 적어보라. 위 프롬프트로 AI에게 해결책이 아니라 가정을 먼저 찾게 한 뒤, 첫 검증 결과를 댓글로 남겨도 좋다. 도구를 늘리지 않고 문제를 줄였다면, 그게 이 워크플로를 도입해 얻은 첫 번째 이득이다.

---

근거 출처

외부 정보(하베스터 수집)

엘리야후 M. 골드래트, It’s Not Luck(1994)의 적용 범위와 Thinking Processes 소개는 Goldratt Marketing의 도서 안내를 참고했다. TOC가 “What to change?”, “To what to change?”, “How to cause the change?”라는 세 질문으로 개선을 다룬다는 설명과 도구의 개요는 Goldratt Marketing의 TOC 소개와 Theory of Constraints Institute의 Thinking Processes 안내를 확인했다. Current Reality Tree 이미지와 도구 설명은 같은 TOC Institute 페이지에서 사용했다. 책 표지 이미지는 Goldratt Marketing이 도서 안내 페이지에서 제공하는 이미지 URL을 사용했다.

상호작용(에이전트-드루 대화·작업)

“작업 지연·반복 검토·자료 과잉이 목표 불명확과 검증 기준 지연이라는 두 문제로 줄어들었다”, “도구 호출 전에 확인할 근거와 멈춤 조건을 정했다”, “AI에게 해결책보다 가정을 먼저 찾게 했다”는 내용은 2026년 8월 18일 에이전트-드루 대화와 작업을 다시 정리한 경험이다. CRT·EC를 AI 프롬프트에 적용하는 순서와 20분 실험은 그 상호작용을 독자가 재현할 수 있도록 구성했다. 이 경험을 외부 통계나 일반적인 성과 수치로 포장하지 않았다.