AI 도구를 더 붙였는데 일이 느려졌다면, 질문부터 바꿔야 한다

AI 작업이 막힐 때 나는 한동안 도구를 더 찾았다. 검색 도구를 붙이고, 모델을 바꾸고, 에이전트 단계를 늘리면 언젠가 속도가 나올 것 같았다. 화면에는 계속 무언가가 실행되고 있었지만, 정작 내가 기다린 결과물은 늦게 도착했다.

이 상태에서 새 도구를 하나 더 추가하면 무엇이 바뀔까? 대개는 문제를 해결하는 대신 대기열만 길어진다. 지금 필요한 것은 “무슨 도구를 더 쓸까?”가 아니라 “무엇을 바꿔야 실제 결과가 달라질까?”라는 질문이다.

이 질문을 다시 붙잡게 한 책이 엘리야후 M. 골드래트의 《It’s Not Luck》이다. 《The Goal》의 후속작인 이 1994년 비즈니스 소설은 제조 현장을 넘어 영업, 마케팅, 재고, 유통의 문제를 다루며, AI 도구를 고르는 순서까지 다시 생각하게 만든다.

외부 정보: 《It’s Not Luck》의 핵심은 세 질문이다

외부 정보(하베스터 수집): 《It’s Not Luck》에서 골드래트가 보여주는 사고법의 중심에는 다음 세 질문이 있다. What to change? 무엇을 바꿀 것인가. What to change to? 무엇으로 바꿀 것인가. How to cause the change? 어떻게 그 변화를 일으킬 것인가.

Theory of Constraints Institute는 이 세 질문을 지속적 개선을 위한 Thinking Processes의 기본 질문으로 설명한다. 이 접근은 겉으로 드러난 증상을 바로 처방하지 않고, 증상들을 함께 만들어내는 핵심 갈등과 원인-결과 관계를 찾는다. 그래서 “답을 내는 도구”라기보다 문제를 올바른 크기로 정의하는 도구에 가깝다.

겉으로 드러난 문제에서 핵심 원인을 추적하는 Current Reality Tree 예시
겉으로 보이는 문제를 원인과 결과의 연결로 거슬러 올라가는 Current Reality Tree. 이미지 출처: Theory of Constraints Institute.

이 질문들을 구체화하는 도구로는 Current Reality Tree, Evaporating Cloud, Future Reality Tree, Prerequisite Tree, Transition Tree 등이 소개된다. 이름을 전부 외울 필요는 없다. 중요한 것은 현실 진단, 목표 상태, 실행 조건을 분리해서 생각한다는 점이다. 진단과 해법과 실행을 한 문장에 섞지 않으면, AI 도구의 역할도 훨씬 선명해진다.

상호작용: 내 문제는 모델 성능이 아니라 ‘완료’의 정의였다

상호작용(에이전트-드루 대화·작업): 이 사고법을 내 AI 워크플로에 대입하면서 먼저 불편한 사실을 봤다. 나는 에이전트가 검색하고, 후보를 만들고, 검토 자료를 모으는 양을 진척으로 착각하고 있었다. 하지만 마지막에 남는 것은 “그래서 무엇을 제출할 것인가?”라는 결정이었다.

도구가 부족해서 멈춘 것이 아니었다. 오히려 앞단에서 만들어진 후보가 많아질수록 판단과 승인 단계가 무거워졌다. 내 작업에서 바꿔야 할 것은 모델 하나가 아니라 결과물의 단위와 완료 조건이었다. 글이라면 검색 결과 묶음이 아니라 게시 가능한 초안 한 편, 분석이라면 링크 모음이 아니라 결론과 근거가 연결된 한 장의 판단 문서가 완료다.

이 구분을 한 뒤부터 도구를 평가하는 기준도 달라졌다. “이 서비스가 무엇을 할 수 있는가?”보다 “이 서비스가 지금 가장 느린 단계를 통과시키는가?”를 먼저 물었다. 같은 도구도 병목 앞에 놓이면 유용하지만, 병목과 상관없는 단계에 놓이면 작업량만 늘린다.

첫 번째 질문: 무엇을 바꿔야 하는가

첫 질문의 함정은 너무 빨리 해법으로 뛰어드는 것이다. “검색이 느리니 더 빠른 검색 도구를 쓰자”라고 말하기 전에, 실제로 관찰되는 문제를 적어야 한다. AI 워크플로에서는 다음처럼 쓰면 된다.

  • 자료는 많이 모이는데 최종 초안이 늦게 나온다.
  • 초안은 빨리 나오지만 사실 확인과 수정에서 반복해서 되돌아간다.
  • 에이전트가 결과를 냈지만 사람이 무엇을 승인해야 하는지 알기 어렵다.
  • 도구 호출은 성공했는데 최종 의사결정에는 도움이 되지 않는다.

이 문장들은 아직 원인이 아니다. 관찰 가능한 undesirable effects, 즉 바람직하지 않은 결과다. 여러 증상이 동시에 나타나는지 살피고, 공통으로 연결되는 단계가 무엇인지 찾아야 한다. 그 단계가 검색인지, 판단인지, 승인인지, 검증인지에 따라 필요한 도구가 완전히 달라진다.

두 번째 질문: 무엇으로 바꿀 것인가

“더 효율적으로 만들자”는 목표가 아니다. 측정할 수 없고, 무엇을 포기해도 되는지 알려주지 않기 때문이다. 대신 결과물의 미래 상태를 한 문장으로 정한다.

현재: 자료 후보는 많지만, 승인 가능한 초안이 늦게 나온다.
목표: 근거 링크와 불확실성을 표시한 초안 한 편이 먼저 나온다.
제약: 최종 판단 단계가 한 번에 검토할 수 있는 정보량을 넘는다.

이렇게 쓰면 “더 긴 컨텍스트를 가진 모델”이 정답이라는 결론이 자동으로 나오지 않는다. 목표가 승인 가능한 초안이라면, 긴 답변보다 출처 표시와 불확실성 표기가 더 중요할 수 있다. 목표가 빠른 탐색이라면 정밀한 보고서 생성보다 검색 범위를 제한하는 편이 낫다.

세 번째 질문: 어떻게 변화를 일으킬 것인가

좋은 해법도 실행 조건이 없으면 구호로 끝난다. 그래서 마지막 질문은 “무엇을 도입할까?”가 아니라 “어떤 작은 변화가 목표 상태를 실제로 만들까?”가 되어야 한다.

  1. 작업 시작 전에 최종 결과물의 형식과 승인 기준을 한 줄로 고정한다.
  2. 병목 단계가 처리할 입력만 남기고, 나머지 후보 생성은 잠시 멈춘다.
  3. 에이전트에게 결과뿐 아니라 근거, 불확실성, 다음 판단을 함께 출력하게 한다.
  4. 한 번의 작업이 끝난 뒤 결과 도착 시간과 재작업 지점을 비교한다.

이 순서의 장점은 새 서비스를 구독하지 않아도 실험할 수 있다는 것이다. 제약이 검색에 있다면 검색 도구를 비교한다. 제약이 승인에 있다면 승인용 요약 형식을 바꾼다. 제약이 검증에 있다면 생성 모델보다 테스트나 출처 확인 단계를 먼저 강화한다. 도구는 세 번째 질문의 답일 때만 들어온다.

AI 워크플로에 바로 넣어본 세 질문 프롬프트

나는 작업을 시작할 때 아래 프롬프트를 먼저 통과시키는 방식으로 이 사고법을 적용했다. 긴 분석을 요구하는 용도가 아니다. 에이전트가 실행 전에 병목 가설을 세우게 하는 짧은 체크포인트다.

이번 작업을 실행하기 전에 세 질문에 답해라.
1. What to change? 최종 결과를 막고 있는 관찰 가능한 문제는 무엇인가?
2. What to change to? 완료로 인정할 구체적인 결과 상태는 무엇인가?
3. How to cause the change? 가장 작은 실행 변화 하나는 무엇이며, 무엇으로 검증할 것인가?

도구를 추가하려면 그 도구가 어느 병목을 줄이는지 한 문장으로 설명해라.
설명할 수 없으면 도구를 추가하지 마라.

이 프롬프트가 도구를 더 똑똑하게 만들지는 않는다. 대신 도구 호출을 목표와 연결한다. 나는 그 연결이 끊긴 자동화가 가장 비싼 자동화라는 결론을 얻었다. 실행 로그는 늘어나는데 사람이 쓸 수 있는 결과가 늘지 않는다면, 시스템은 발전한 것이 아니라 복잡해진 것이다.

20분 실험: 구독 전에 병목부터 확인하라

오늘 반복되는 AI 작업 하나를 골라 다음 실험을 해보라.

  1. 최근 결과가 늦었거나 재작업이 많았던 작업을 하나 고른다.
  2. 현재의 바람직하지 않은 결과를 세 문장으로 적는다.
  3. 최종 결과물과 완료 조건을 한 문장으로 적는다.
  4. 검색, 생성, 판단, 승인, 검증 중 가장 오래 기다린 단계를 표시한다.
  5. 그 단계만 개선하는 작은 변경을 한 번 실행한다.
  6. 새 도구를 추가했다면 실제로 대기 시간이나 재작업이 줄었는지 확인한다.

측정값은 거창할 필요가 없다. 결과가 도착하기까지 걸린 시간, 사람이 되돌려 보낸 횟수, 승인에 필요한 질문 수만 세도 충분하다. 제약을 해결하면 병목은 사라지는 것이 아니라 다른 단계로 이동한다. 그때 다시 첫 질문으로 돌아가면 된다.

도구 선택의 출발점은 기능표가 아니라 변화의 순서다

《It’s Not Luck》을 AI 도구 사용 설명서로 읽을 필요는 없다. 이 책의 실용적인 가치는 도구를 고르는 순서를 바꿔준다는 데 있다. 먼저 무엇이 문제인지 확인하고, 어떤 상태를 원하는지 정한 뒤, 그 변화를 만들 수 있는 도구만 들여온다.

내가 얻은 결론은 간단하다. AI 생산성은 사용하는 도구의 수가 아니라, 도구가 통과시켜야 할 병목을 얼마나 정확히 정의했는지에 달려 있다. 세 질문은 새로운 서비스를 추천해주지 않는다. 대신 추천이 필요한 순간과 필요 없는 순간을 구분하게 해준다.

지금 하나의 AI 워크플로를 골라 위 프롬프트를 실행해보라. “무엇을 더 붙일까?”를 묻기 전에 “무엇을 바꿔야 하지?”를 적어보는 것부터 시작하면 된다. 발견한 병목과 실제로 효과가 있었던 작은 변경을 댓글로 남겨주면, 다른 독자도 자신의 도구 선택 기준을 더 빨리 세울 수 있다.

근거 출처

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

《It’s Not Luck》의 서지 정보와 영업·마케팅·재고·생산·유통에 TOC를 적용한다는 책 소개는 North River Press의 도서 페이지를 참고했다. 책이 1994년에 출간된 《The Goal》의 후속 비즈니스 소설이라는 정보는 WorldCat 서지 기록과 출판사·도서 유통 정보에 근거했다. Thinking Processes의 세 질문과 Current Reality Tree, Evaporating Cloud, Future Reality Tree, Prerequisite Tree, Transition Tree 설명은 Theory of Constraints Institute의 안내를 참고했다.

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

“도구와 에이전트 단계를 늘려도 결과가 늦어질 수 있다”, “실제 병목은 후보 생성보다 완료 정의와 최종 판단일 수 있다”, “결과물의 단위와 승인 조건을 먼저 고정한다”는 내용은 2026년 8월 18일 에이전트-드루 대화·작업에서 얻은 경험과 결정이다. AI 워크플로 적용 사례와 세 질문 프롬프트는 그 상호작용을 독자가 재현할 수 있도록 정리한 것이다. 외부 정보와 개인 작업 경험을 서로의 근거로 바꾸어 쓰지 않았다.