[비개발자 사고법2 5강] 접수표를 다 채웠는데도 다섯 번을 다시 시켰습니다 — 잘 시키기와 별개로 '돌게 하기'가 필요한 이유, 그리고 3번 규칙
접수표를 다 채웠는데도 다섯 번을 다시 시켰습니다 — 잘 시키기와 별개로 '돌게 하기'가 필요한 이유, 그리고 3번 규칙
1강 접수표 다섯 칸도 채웠고, 3강 쪽지 다섯 장도 상황에 맞게 다 넣었습니다. 그런데 결과를 열어 보니 좋긴 한데 내가 원하던 게 아닙니다. 그래서 또 시킵니다. 또 아닙니다. 이걸 다섯 번, 열 번까지 하고 나면 이런 생각이 듭니다 — "접수표니 쪽지니, 다 소용없는 거 아닌가?" 영상은 여기에 이렇게 답합니다. 레시피가 아무리 정확해도 요리는 간을 봐야 합니다. 팔도 비빔면도 봉지에 적힌 대로 끓이지만, 먹어 보고 소금 한 숟갈을 더 넣는 건 사람입니다. 오늘은 잘 시키는 법이 아니라, 시킨 뒤에 어떻게 돌게 만들고 어디서 멈출지를 정하는 이야기입니다. 그리고 그 이름은 영상 맨 끝에 나옵니다.
▶ 먼저 영상(16분)을 보고 오시면 아래 글이 복습이자 심화가 됩니다. 아직 앞 편을 안 보셨다면 4강 「끼어들 네 지점」부터 보고 오세요 — 오늘은 그 네 지점을 사람이 매번 손으로 하지 않게 만드는 이야기입니다.
레시피를 완벽하게 써도, 간은 끓여봐야 압니다
먼저 오해부터 풀고 갑니다. 결과가 마음에 안 든다고 해서 접수표와 쪽지가 헛수고였던 게 아닙니다. 영상의 비유가 정확합니다.
봉지 뒤에 적힌 레시피는 끓이기 전에 정하는 것입니다 — 물 몇 mL, 몇 분. 그런데 실제로 끓여서 간을 보는 건 끝나고 나서입니다. 짜면 물을 더 붓고, 싱거우면 소금을 넣고, 다 됐으면 불을 끕니다. 레시피 = 접수표·쪽지(프롬프트) / 간 보기 = 결과 확인 / 불 끄기 = 멈추는 판단.
즉 프롬프트는 시작 전에 쓰는 것이고, 내가 진짜 원하는 게 나왔는지는 끝나고 나서만 알 수 있습니다. 영상의 표현으로는 이렇습니다 — "AI 에이전트도 작동해 보기 전에는 자기가 어떤 결과를 낼지 모릅니다."
우리 업무도 똑같습니다. 보고서 초안을 받았다고 그대로 팀장님께 올리지 않죠. 읽고, 고치고, 다시 바꿔 달라고 하고, 또 읽습니다. 고객 문의도 답변하고 끝이 아니라 반응을 보고 위에 보고합니다. 결과물 하나를 만드는 동안 우리는 이미 수없이 개입하고 있습니다.
왜 프롬프트를 잘 써도 한 번에 안 될까 — 네 가지 이유
영상이 정리한 네 가지입니다. 이걸 알고 있으면 "AI가 별로네"에서 "아, 이건 원래 이런 구조지"로 생각이 바뀝니다.
| 이유 | 무슨 뜻인가 | 그래서 필요한 것 |
|---|---|---|
| ① 해 봐야 안다 | 보고서 톤이 맞는지, 고객 답변이 적절한지는 아무리 프롬프트를 잘 써도 결과가 나온 뒤에야 판단할 수 있다 | 실행 → 확인의 한 바퀴 |
| ② 매번 사람이 확인한다 | 다섯 번, 여섯 번 반복하면 정작 정확히 봐야 할 곳을 놓친다. 이메일 초안 한 장은 몰라도, 장면 30개짜리 영상 프롬프트 60개를 하나하나 다 판단할 수는 없다 | 확인 자체를 도구에게 맡기는 자리 |
| ③ 틀려도 경보가 안 울린다 | 에이전트는 에러가 나면 스스로 고쳐가며 결과를 만들어 낸다. 가스레인지는 국이 짜다고 삐 소리를 내지 않는다 — 결과물은 늘 깔끔한 모양으로 나온다 | 틀림을 잡아 줄 검사 자리 |
| ④ 내가 안 보면 시작을 안 한다 | 고객 문의가 아무리 쌓여도 내가 엔터를 치기 전까지 아무 일도 일어나지 않는다 | 사람 없이도 시작되는 자리 |
네 가지 이유가 요구하는 것을 한 줄로 붙이면 이렇게 됩니다 — 상황을 모으고 → 시켜 보고 → 확인하고 → 필요하면 다시. 우리가 업무에서 이미 하고 있는 그 순서입니다.
보일러 온도 조절기 — 사람이 하는 건 딱 하나입니다
"그럼 프롬프트 디테일하게 쓰고 도메인 지식 챙기는 게 다 소용없는 거냐"는 반박이 나올 수 있습니다. 영상의 답은 보일러입니다.
| 보일러 | AI 에이전트 | 누가 하나 |
|---|---|---|
| 몇 도로 맞출지 정한다 | 어떤 상태가 되면 끝인지 정한다 | 사람 |
| 지금 몇 도인지 잰다 | 결과를 확인한다 | 기계 |
| 낮으면 올리고, 높으면 내린다 | 어긋나면 다시 실행한다 | 기계 |
| 정한 값에 닿으면 끈다 | 조건을 채우면 멈춘다 | 기계 |
여기서 가장 중요한 건 "다 되어진 결과물 상태"입니다. 뭐가 어떻게 되면 끝인가. 그리고 이건 이미 배웠습니다 — 1강 접수표 다섯 칸 중 '기준'입니다. 그 기준이 곧 AI 에이전트를 멈추는 조건입니다.
"돌리는 건 기계가 해도, 멈추는 건 내가 정합니다." 겨울이라고 온도를 무한정 올리지 않듯이, 에이전트도 오래 돌린다고 좋은 게 아닙니다.
몇 번까지 돌릴까 — 3번 규칙
영상이 권하는 숫자는 3번입니다. 이유는 두 가지입니다.
- 토큰과 시간이 그냥 날아갑니다. "열 번 생각해서 뽑아 봐" 하면 정말 열 번 합니다. 스무 번 하라면 스무 번 합니다.
- 엉뚱한 방향으로 열 번 가면 돌아오기 어렵습니다. 갔다가 안 돌아오는 게 에이전트입니다.
세 바퀴를 돌렸는데도 마음에 안 든다면, 더 돌릴 문제가 아니라 넣은 일감이 너무 크다는 뜻입니다. 그때 돌아갈 곳은 3강 「쪼개야 할 5가지」입니다. 잘게 쪼개서 다시 시작하세요.
3번을 넘겼을 때 바꿀 것 세 가지 — 순서대로
쪼개는 것 말고도 손댈 곳이 있습니다. 영상이 제시한 순서 그대로입니다.
| 순서 | 바꾸는 것 | 구체적으로 |
|---|---|---|
| 1 | 프롬프트(접수표·쪽지) | 잘게 쪼개서 새로 쓴다. 3번 실패는 대부분 여기다 |
| 2 | 일꾼 = 모델 | 소넷으로 세 번 해도 안 되면 오퍼스로, 오퍼스도 애매하면 페이블까지 올려 본다 |
| 3 | 생각의 깊이 = 노력 수준 | 프롬프트도 바꾸고 모델도 바꿨는데 애매하면 그때 깊이를 조절한다 |
그럼 "처음부터 제일 센 모델에 제일 깊은 생각으로 두면 되지 않나요?" — 영상의 답도, 공식 문서의 답도 아니오입니다.
고객 클레임에 답장만 쓰면 되는데 깊이를 최대로 두면, 그 답장이 고객 심리에 미칠 영향과 법적 쟁점까지 굳이 안 해도 될 생각을 다 합니다. 결과적으로 느려지고 비싸집니다. 공식 문서도 최대 수준에 대해 "성능이 좋아질 수는 있지만 수확이 줄고 과하게 생각하는 경향이 있으니 널리 적용하기 전에 시험해 보라"고 적어 두었습니다.
간단한 일은 얕게, 진짜 어려운 일만 깊게. 이게 규칙입니다.
클로드 코드에서 그 자리는 어디인가 — 명령 세 가지
개념만 알면 사실 말로 시켜도 됩니다. 다만 자리를 알면 훨씬 정확해집니다.
| 자리 | 보일러로 치면 | 이럴 때 쓴다 |
|---|---|---|
/goal (목표) | 온도를 정하는 다이얼 | "이 상태가 되면 끝"을 정해 두면, 거기 닿을 때까지 스스로 다음 턴을 이어간다 |
/loop (반복) | 정해진 간격마다 다시 재기 | "20분마다 우리 페이지에 문제 없는지 확인해 줘"처럼 시간 간격으로 다시 시킨다 |
/schedule (예약) | 외출 중에도 도는 타이머 | 내가 시작하지 않아도 되게 만든다 — 내 컴퓨터가 꺼져 있어도 클라우드에서 정해진 시각에 돈다 |
| 훅(hook) | 지날 때마다 걸리는 낚싯바늘 | "파일을 고칠 때마다 우리 업무 매뉴얼과 맞는지 팩트체크해"처럼 정한 시점마다 항상 검사한다 |
/goal을 쓰는 법 — 예시 한 줄❌ "안내문 뽑아 줘. 세 번 정도 돌려 봐."
✅ "A4 한 장 안에 날짜·장소·연락처가 다 들어가고 오타가 없으면 완료. 그 상태가 될 때까지 하되 3번 넘으면 멈추고 보고해."
※ 횟수 상한은 별도 설정이 아니라 조건 문장 안에 적습니다. 공식 문서도 "몇 턴 뒤에 멈춘다" 같은 턴·시간 조건을 조건문에 넣으라고 안내합니다.
·
/goal — 완료 조건을 정하면 조건이 충족될 때까지 스스로 다음 턴을 이어가고, 매 턴 뒤 별도 모델이 충족 여부를 판정 → Keep Claude working toward a goal· 횟수·시간 상한은 조건 문장 안에 쓴다(예: "20턴 뒤 중단") → 같은 문서
·
/loop — 세션이 열려 있는 동안 정해진 간격으로 프롬프트를 다시 실행. 간격을 비우면 클로드가 스스로 간격을 정한다 → Run prompts on a schedule· 클라우드 예약(
/schedule로 설정) — 내 컴퓨터가 켜져 있지 않아도 되고 열린 세션도 필요 없다(최소 간격 1시간) → 같은 문서의 스케줄링 비교표· 훅 — 정해진 생애주기 시점에 항상 실행되는 사용자 명령. 판단이 필요한 검사는 모델이 평가하는 훅으로도 쓸 수 있다 → Automate actions with hooks
· 모델 성격 — 소넷=매일 하는 코딩 작업 / 오퍼스=복잡한 추론 / 페이블=가장 어렵고 오래 걸리는 작업 → Model configuration
· 노력 수준 최대치는 "수확이 줄고 과하게 생각하는 경향이 있으니 널리 적용 전 시험하라", 큰 모델은 검증 단계가 늘어 토큰을 더 쓰고 단가도 높다 → 같은 문서 및 모델·노력 수준 선택 안내
· 에이전트의 한 바퀴 공식 표현 — gather context → take action → verify work → repeat → Building agents with the Claude Agent SDK
· 코덱스 — 더 깊은 추론이 필요할 때 쓰는 상위 노력 수준(
xhigh)과 여러 하위 에이전트로 나눠 도는 ultra가 있다 → Models (ChatGPT Learn)※ 영상에서 한 바퀴를 "확인(verify result)"이라 부른 부분의 공식 표현은 verify work입니다. 또 영상에서 "페이블은 자주 조사한다"고 소개한 대목은 공식 문서에서 그 표현을 찾지 못해, 이 글에서는 공식 문구인 "가장 어렵고 오래 걸리는 작업용"으로만 적었습니다. 버전 번호·요금처럼 자주 바뀌는 값은 이 글에 싣지 않습니다 — 위 링크에서 직접 확인하세요.
돌게 하되, 손발은 묶어 둡니다
여기서 4강이 다시 나옵니다. 세 바퀴를 혼자 돌게 시키더라도 역할 구분은 그대로 살아 있어야 합니다.
웹페이지의 자료를 다시 조사해서 고치는 일이라면, 고치는 것까지는 돌게 두고 사이트에 배포하는 마지막 버튼은 내 손에 남깁니다. 시키면 배포까지 해 주지만, 그 앞에서 한 번 더 확인하는 게 중요합니다.
정리하면 이렇습니다 — 돌리는 범위는 넓게, 되돌릴 수 없는 행동은 반드시 사람 손에.
오늘의 단어 — 이걸 '루프'라고 부릅니다
여기까지 온 다음에야 단어를 꺼냅니다. 상황을 모으고, 해 보고, 확인하고, 필요하면 다시 — 이 한 바퀴가 루프(loop)입니다. 고리라는 뜻이죠. 보일러 온도 조절기가 계속 재고 올리고 끄는, 그 도는 구조 말입니다.
| 단계 | 쉬운 말 | 공식 표현 |
|---|---|---|
| 1 | 상황을 모은다 | gather context |
| 2 | 시켜 본다 | take action |
| 3 | 결과를 확인한다 | verify work |
| 4 | 필요하면 다시 | repeat |
요즘 유튜브에서 「루프 엔지니어링」이라는 말을 자주 보실 겁니다. 프롬프트 엔지니어링 → 컨텍스트 엔지니어링 다음은 루프 엔지니어링이라는 식이죠. 영상의 태도는 담백합니다 — 단어는 계속 바뀝니다. 얼마 전엔 또 다른 이름이 나왔습니다. 중요한 건 이름이 아니라, 에이전트가 한 번에 내 마음에 드는 결과를 내지 않는다는 사실을 전제로 구조를 짜는 것입니다.
영상이 마지막에 짚은 대로,
/goal이든 /schedule이든 훅이든 몰라도 됩니다. 개념만 알고 말로 설명하면 됩니다 — "이 상태가 되면 끝이야, 세 번까지만 해 보고 안 되면 멈추고 알려 줘." 이 한 문장이 오늘 배운 전부입니다.오늘 핵심 3가지를 점검합니다. 답을 고르고 [정답 확인]을 누르면 즉시 채점됩니다.
Q1. 접수표와 쪽지를 다 채웠는데도 결과가 마음에 들지 않습니다. 영상의 진단으로 가장 맞는 것은?
Q2. 보일러 비유에서 사람이 하는 일은 무엇이고, 그것은 1강 접수표의 어느 칸에 해당할까요?
Q3. 세 바퀴를 돌렸는데도 결과가 마음에 들지 않습니다. 가장 먼저 해야 할 일은?
🎯 루프 설계 준비도 점수
해당되는 항목을 모두 클릭해 체크하세요. 마지막에 [내 점수 보기]를 누르면 등급이 나옵니다.
- 프롬프트를 잘 써도 한 번에 안 되는 이유 네 가지를 말할 수 있다
- 내 업무에서 "이 상태가 되면 끝"을 한 문장으로 적을 수 있다
- 그 문장이 1강 접수표의 '기준' 칸과 같은 것임을 안다
- 몇 바퀴까지 돌릴지 상한을 스스로 정하고 조건 문장에 적을 수 있다
- 3번을 넘겼을 때 프롬프트 → 모델 → 깊이 순으로 손댈 수 있다
- 간단한 일에 최대 깊이를 쓰면 느려지고 비싸진다는 것을 안다
- 돌게 하더라도 되돌릴 수 없는 행동은 사람 손에 남길 수 있다
- 상황 → 실행 → 확인 → 반복이 '루프'라는 것을 설명할 수 있다
프롬프트는 시작 전에 쓰는 레시피이고, 간이 맞는지는 끝나고 나서 압니다. 그래서 필요한 게 상황 → 실행 → 확인 → 반복의 한 바퀴, 곧 루프입니다. 이 바퀴에서 사람이 쥐는 건 보일러 다이얼 하나 — "어떤 상태가 되면 끝인가". 그리고 3번까지만 돌리세요. 3번을 넘겼다는 건 더 돌릴 문제가 아니라 일감이 크다는 신호입니다. 손대는 순서는 프롬프트 → 일꾼(모델) → 생각의 깊이이고, 처음부터 제일 세게는 답이 아닙니다.
「비개발자 사고법 시즌 2」는 개념과 실전이 한 세트로 이어집니다. 유튜브 채널 구독으로 새 영상을 가장 먼저 받아보시고, AI아카데미 자료실에서 지난 편 정리와 다른 무료 자료도 함께 보세요. 온도(끝 조건)를 직접 만들어 보는 무료 학습 교재(5강)도 열려 있습니다.
혼자 하면 "어디서 멈출지"에서 막히고, 옆에서 한 번 잡아 주면 그날 우리 업무용 끝 조건 문장이 나옵니다. 온라인 강의로 처음부터 순서대로 익히거나, 1:1 컨설팅·강의 문의로 우리 업종에 맞춘 적용을 받아보세요. 외부강사 김지백이 직접 안내합니다.
자주 묻는 질문
주간 AI 실무 레터
이 글이 도움이 됐다면, 매주 현장에서 검증한 AI 활용법·새 자료를 이메일로 받아보세요. 광고 없이, 바로 쓰는 것만.
우리 조직에 맞는 AI 교육을
설계해드립니다.
위 자료의 내용을 기반으로 맞춤형 강의 커리큘럼을 구성해드립니다. 기업·공공기관·임원 대상 프로그램 모두 가능합니다.
조회수·다운로드 카운트 등 인터랙티브 기능은 자료실 인터랙티브 페이지에서 이용하실 수 있습니다.