유튜브 교육자료2026-08-25

[비개발자 사고법2 5강] 접수표를 다 채웠는데도 다섯 번을 다시 시켰습니다 — 잘 시키기와 별개로 '돌게 하기'가 필요한 이유, 그리고 3번 규칙

접수표를 다 채웠는데도 다섯 번을 다시 시켰습니다 — 잘 시키기와 별개로 '돌게 하기'가 필요한 이유, 그리고 3번 규칙

1강 접수표 다섯 칸도 채웠고, 3강 쪽지 다섯 장도 상황에 맞게 다 넣었습니다. 그런데 결과를 열어 보니 좋긴 한데 내가 원하던 게 아닙니다. 그래서 또 시킵니다. 또 아닙니다. 이걸 다섯 번, 열 번까지 하고 나면 이런 생각이 듭니다 — "접수표니 쪽지니, 다 소용없는 거 아닌가?" 영상은 여기에 이렇게 답합니다. 레시피가 아무리 정확해도 요리는 간을 봐야 합니다. 팔도 비빔면도 봉지에 적힌 대로 끓이지만, 먹어 보고 소금 한 숟갈을 더 넣는 건 사람입니다. 오늘은 잘 시키는 법이 아니라, 시킨 뒤에 어떻게 돌게 만들고 어디서 멈출지를 정하는 이야기입니다. 그리고 그 이름은 영상 맨 끝에 나옵니다.

▶ 먼저 영상(16분)을 보고 오시면 아래 글이 복습이자 심화가 됩니다. 아직 앞 편을 안 보셨다면 4강 「끼어들 네 지점」부터 보고 오세요 — 오늘은 그 네 지점을 사람이 매번 손으로 하지 않게 만드는 이야기입니다.

레시피를 완벽하게 써도, 간은 끓여봐야 압니다

먼저 오해부터 풀고 갑니다. 결과가 마음에 안 든다고 해서 접수표와 쪽지가 헛수고였던 게 아닙니다. 영상의 비유가 정확합니다.

🍜 팔도 비빔면 비유
봉지 뒤에 적힌 레시피는 끓이기 전에 정하는 것입니다 — 물 몇 mL, 몇 분. 그런데 실제로 끓여서 간을 보는 건 끝나고 나서입니다. 짜면 물을 더 붓고, 싱거우면 소금을 넣고, 다 됐으면 불을 끕니다. 레시피 = 접수표·쪽지(프롬프트) / 간 보기 = 결과 확인 / 불 끄기 = 멈추는 판단.

즉 프롬프트는 시작 전에 쓰는 것이고, 내가 진짜 원하는 게 나왔는지는 끝나고 나서만 알 수 있습니다. 영상의 표현으로는 이렇습니다 — "AI 에이전트도 작동해 보기 전에는 자기가 어떤 결과를 낼지 모릅니다."

우리 업무도 똑같습니다. 보고서 초안을 받았다고 그대로 팀장님께 올리지 않죠. 읽고, 고치고, 다시 바꿔 달라고 하고, 또 읽습니다. 고객 문의도 답변하고 끝이 아니라 반응을 보고 위에 보고합니다. 결과물 하나를 만드는 동안 우리는 이미 수없이 개입하고 있습니다.

왜 프롬프트를 잘 써도 한 번에 안 될까 — 네 가지 이유

영상이 정리한 네 가지입니다. 이걸 알고 있으면 "AI가 별로네"에서 "아, 이건 원래 이런 구조지"로 생각이 바뀝니다.

이유무슨 뜻인가그래서 필요한 것
① 해 봐야 안다보고서 톤이 맞는지, 고객 답변이 적절한지는 아무리 프롬프트를 잘 써도 결과가 나온 뒤에야 판단할 수 있다실행 → 확인의 한 바퀴
② 매번 사람이 확인한다다섯 번, 여섯 번 반복하면 정작 정확히 봐야 할 곳을 놓친다. 이메일 초안 한 장은 몰라도, 장면 30개짜리 영상 프롬프트 60개를 하나하나 다 판단할 수는 없다확인 자체를 도구에게 맡기는 자리
③ 틀려도 경보가 안 울린다에이전트는 에러가 나면 스스로 고쳐가며 결과를 만들어 낸다. 가스레인지는 국이 짜다고 삐 소리를 내지 않는다 — 결과물은 늘 깔끔한 모양으로 나온다틀림을 잡아 줄 검사 자리
④ 내가 안 보면 시작을 안 한다고객 문의가 아무리 쌓여도 내가 엔터를 치기 전까지 아무 일도 일어나지 않는다사람 없이도 시작되는 자리
💡 여기서 힌트가 나옵니다
네 가지 이유가 요구하는 것을 한 줄로 붙이면 이렇게 됩니다 — 상황을 모으고 → 시켜 보고 → 확인하고 → 필요하면 다시. 우리가 업무에서 이미 하고 있는 그 순서입니다.

보일러 온도 조절기 — 사람이 하는 건 딱 하나입니다

"그럼 프롬프트 디테일하게 쓰고 도메인 지식 챙기는 게 다 소용없는 거냐"는 반박이 나올 수 있습니다. 영상의 답은 보일러입니다.

보일러AI 에이전트누가 하나
몇 도로 맞출지 정한다어떤 상태가 되면 끝인지 정한다사람
지금 몇 도인지 잰다결과를 확인한다기계
낮으면 올리고, 높으면 내린다어긋나면 다시 실행한다기계
정한 값에 닿으면 끈다조건을 채우면 멈춘다기계

여기서 가장 중요한 건 "다 되어진 결과물 상태"입니다. 뭐가 어떻게 되면 끝인가. 그리고 이건 이미 배웠습니다 — 1강 접수표 다섯 칸 중 '기준'입니다. 그 기준이 곧 AI 에이전트를 멈추는 조건입니다.

🧯 오늘의 한 문장
"돌리는 건 기계가 해도, 멈추는 건 내가 정합니다." 겨울이라고 온도를 무한정 올리지 않듯이, 에이전트도 오래 돌린다고 좋은 게 아닙니다.

몇 번까지 돌릴까 — 3번 규칙

영상이 권하는 숫자는 3번입니다. 이유는 두 가지입니다.

  1. 토큰과 시간이 그냥 날아갑니다. "열 번 생각해서 뽑아 봐" 하면 정말 열 번 합니다. 스무 번 하라면 스무 번 합니다.
  2. 엉뚱한 방향으로 열 번 가면 돌아오기 어렵습니다. 갔다가 안 돌아오는 게 에이전트입니다.
⛑️ 3번을 넘겼다는 신호의 진짜 의미
세 바퀴를 돌렸는데도 마음에 안 든다면, 더 돌릴 문제가 아니라 넣은 일감이 너무 크다는 뜻입니다. 그때 돌아갈 곳은 3강 「쪼개야 할 5가지」입니다. 잘게 쪼개서 다시 시작하세요.

3번을 넘겼을 때 바꿀 것 세 가지 — 순서대로

쪼개는 것 말고도 손댈 곳이 있습니다. 영상이 제시한 순서 그대로입니다.

순서바꾸는 것구체적으로
1프롬프트(접수표·쪽지)잘게 쪼개서 새로 쓴다. 3번 실패는 대부분 여기다
2일꾼 = 모델소넷으로 세 번 해도 안 되면 오퍼스로, 오퍼스도 애매하면 페이블까지 올려 본다
3생각의 깊이 = 노력 수준프롬프트도 바꾸고 모델도 바꿨는데 애매하면 그때 깊이를 조절한다

그럼 "처음부터 제일 센 모델에 제일 깊은 생각으로 두면 되지 않나요?" — 영상의 답도, 공식 문서의 답도 아니오입니다.

🐢 세게만 두면 생기는 일
고객 클레임에 답장만 쓰면 되는데 깊이를 최대로 두면, 그 답장이 고객 심리에 미칠 영향과 법적 쟁점까지 굳이 안 해도 될 생각을 다 합니다. 결과적으로 느려지고 비싸집니다. 공식 문서도 최대 수준에 대해 "성능이 좋아질 수는 있지만 수확이 줄고 과하게 생각하는 경향이 있으니 널리 적용하기 전에 시험해 보라"고 적어 두었습니다.

간단한 일은 얕게, 진짜 어려운 일만 깊게. 이게 규칙입니다.

클로드 코드에서 그 자리는 어디인가 — 명령 세 가지

개념만 알면 사실 말로 시켜도 됩니다. 다만 자리를 알면 훨씬 정확해집니다.

자리보일러로 치면이럴 때 쓴다
/goal (목표)온도를 정하는 다이얼"이 상태가 되면 끝"을 정해 두면, 거기 닿을 때까지 스스로 다음 턴을 이어간다
/loop (반복)정해진 간격마다 다시 재기"20분마다 우리 페이지에 문제 없는지 확인해 줘"처럼 시간 간격으로 다시 시킨다
/schedule (예약)외출 중에도 도는 타이머내가 시작하지 않아도 되게 만든다 — 내 컴퓨터가 꺼져 있어도 클라우드에서 정해진 시각에 돈다
훅(hook)지날 때마다 걸리는 낚싯바늘"파일을 고칠 때마다 우리 업무 매뉴얼과 맞는지 팩트체크해"처럼 정한 시점마다 항상 검사한다
🎯 /goal을 쓰는 법 — 예시 한 줄
❌ "안내문 뽑아 줘. 세 번 정도 돌려 봐."
✅ "A4 한 장 안에 날짜·장소·연락처가 다 들어가고 오타가 없으면 완료. 그 상태가 될 때까지 하되 3번 넘으면 멈추고 보고해."
※ 횟수 상한은 별도 설정이 아니라 조건 문장 안에 적습니다. 공식 문서도 "몇 턴 뒤에 멈춘다" 같은 턴·시간 조건을 조건문에 넣으라고 안내합니다.
📌 공식 문서로 확인한 것 (확인일 2026-08-25)
· /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 → repeatBuilding 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이든 훅이든 몰라도 됩니다. 개념만 알고 말로 설명하면 됩니다 — "이 상태가 되면 끝이야, 세 번까지만 해 보고 안 되면 멈추고 알려 줘." 이 한 문장이 오늘 배운 전부입니다.
📝 5분 체크포인트

오늘 핵심 3가지를 점검합니다. 답을 고르고 [정답 확인]을 누르면 즉시 채점됩니다.

Q1. 접수표와 쪽지를 다 채웠는데도 결과가 마음에 들지 않습니다. 영상의 진단으로 가장 맞는 것은?

정답: C — "AI 에이전트도 작동해 보기 전에는 자기가 어떤 결과를 낼지 모릅니다." 레시피대로 끓여도 간은 먹어 봐야 압니다. 그래서 '잘 시키기'와 별개로 '실행 → 확인 → 다시'의 한 바퀴가 필요합니다.

Q2. 보일러 비유에서 사람이 하는 일은 무엇이고, 그것은 1강 접수표의 어느 칸에 해당할까요?

정답: B — 재고·올리고·끄는 건 기계가 합니다. 사람이 하는 건 "어떤 상태가 되면 끝인가"를 정하는 것 하나뿐이고, 그게 1강 접수표의 기준이자 에이전트를 멈추는 조건입니다.

Q3. 세 바퀴를 돌렸는데도 결과가 마음에 들지 않습니다. 가장 먼저 해야 할 일은?

정답: A — 3번은 "더 돌릴 문제가 아니다"라는 신호입니다. 순서는 프롬프트 쪼개기 → 일꾼(모델) 올리기 → 생각의 깊이 조절이고, 처음부터 최대치로 두면 굳이 안 해도 될 생각까지 하느라 느려지고 비싸집니다. 그리고 되돌릴 수 없는 배포는 끝까지 사람 손에 남깁니다.

🎯 루프 설계 준비도 점수

해당되는 항목을 모두 클릭해 체크하세요. 마지막에 [내 점수 보기]를 누르면 등급이 나옵니다.

  • 프롬프트를 잘 써도 한 번에 안 되는 이유 네 가지를 말할 수 있다
  • 내 업무에서 "이 상태가 되면 끝"을 한 문장으로 적을 수 있다
  • 그 문장이 1강 접수표의 '기준' 칸과 같은 것임을 안다
  • 몇 바퀴까지 돌릴지 상한을 스스로 정하고 조건 문장에 적을 수 있다
  • 3번을 넘겼을 때 프롬프트 → 모델 → 깊이 순으로 손댈 수 있다
  • 간단한 일에 최대 깊이를 쓰면 느려지고 비싸진다는 것을 안다
  • 돌게 하더라도 되돌릴 수 없는 행동은 사람 손에 남길 수 있다
  • 상황 → 실행 → 확인 → 반복이 '루프'라는 것을 설명할 수 있다
오늘 단 하나만 기억하세요 — "돌리는 건 기계가 해도, 멈추는 건 내가 정합니다."
프롬프트는 시작 전에 쓰는 레시피이고, 간이 맞는지는 끝나고 나서 압니다. 그래서 필요한 게 상황 → 실행 → 확인 → 반복의 한 바퀴, 곧 루프입니다. 이 바퀴에서 사람이 쥐는 건 보일러 다이얼 하나 — "어떤 상태가 되면 끝인가". 그리고 3번까지만 돌리세요. 3번을 넘겼다는 건 더 돌릴 문제가 아니라 일감이 크다는 신호입니다. 손대는 순서는 프롬프트 → 일꾼(모델) → 생각의 깊이이고, 처음부터 제일 세게는 답이 아닙니다.
📩 이 시리즈를 놓치지 마세요
「비개발자 사고법 시즌 2」는 개념과 실전이 한 세트로 이어집니다. 유튜브 채널 구독으로 새 영상을 가장 먼저 받아보시고, AI아카데미 자료실에서 지난 편 정리와 다른 무료 자료도 함께 보세요. 온도(끝 조건)를 직접 만들어 보는 무료 학습 교재(5강)도 열려 있습니다.
🚀 한 걸음 더 — 우리 회사 업무에 루프를 직접 걸어 보고 싶다면
혼자 하면 "어디서 멈출지"에서 막히고, 옆에서 한 번 잡아 주면 그날 우리 업무용 끝 조건 문장이 나옵니다. 온라인 강의로 처음부터 순서대로 익히거나, 1:1 컨설팅·강의 문의로 우리 업종에 맞춘 적용을 받아보세요. 외부강사 김지백이 직접 안내합니다.
다음 편 예고 — 이제 돌게 만들 줄은 알게 됐습니다. 그런데 돌다가 하나가 틀렸을 때는 어디로 돌아가야 할까요? 맨 처음부터일까요, 중간까지만일까요? 다음 편에서는 틀렸을 때 되돌아갈 지점에 대해 이어서 이야기합니다. 영상이 올라오면 이 자리에 자료가 이어집니다. 그때까지 4강 「끼어들 네 지점」3강 「쪼개야 할 5가지」로 손에 익혀 두세요.
#비개발자 사고법2#AI 에이전트#루프#루프 엔지니어링#AI 활용법#업무 자동화#끝 조건#3번 규칙#Claude Code#클로드 코드#코덱스#모델 선택#노력 수준##예약 실행

자주 묻는 질문

Q. 프롬프트를 잘 쓰면 한 번에 되는 것 아닌가요? 접수표와 쪽지는 소용없나요?
소용없는 게 아니라 역할이 다릅니다. 프롬프트는 끓이기 전에 정하는 레시피이고, 간이 맞는지는 먹어 봐야 압니다. 영상 표현으로는 'AI 에이전트도 작동해 보기 전에는 자기가 어떤 결과를 낼지 모른다'입니다. 그래서 잘 시키기(접수표·쪽지)와 별개로, 실행하고 확인해서 필요하면 다시 돌리는 한 바퀴가 필요합니다. 접수표를 잘 쓸수록 그 바퀴가 짧아집니다.
Q. 왜 하필 3번인가요? 더 돌리면 더 좋아지지 않나요?
두 가지 이유입니다. 첫째, 열 번 생각하라면 정말 열 번 하기 때문에 시간과 토큰이 그대로 나갑니다. 둘째, 엉뚱한 방향으로 열 번 가면 돌아오기 어렵습니다. 그래서 3번까지만 돌리고, 넘어가면 '더 돌릴 문제'가 아니라 '넣은 일감이 크다'는 신호로 읽고 잘게 쪼개 다시 시작하는 편이 빠릅니다.
Q. 처음부터 제일 좋은 모델에 가장 깊은 생각으로 두면 되지 않나요?
권하지 않습니다. 공식 문서는 가장 높은 노력 수준에 대해 성능이 좋아질 수는 있으나 수확이 줄고 과하게 생각하는 경향이 있으니 널리 적용하기 전에 시험해 보라고 안내합니다. 큰 모델일수록 검증 단계가 늘어 토큰을 더 쓰고 단가도 높습니다. 고객 답장 한 통에 법적 쟁점까지 따지느라 느려지는 식입니다. 간단한 일은 얕게, 정말 어려운 일만 깊게 쓰세요.
Q. 명령어를 꼭 외워야 하나요?
아니요. 영상도 마지막에 같은 말을 합니다. 개념만 알고 말로 설명하면 됩니다. '이 상태가 되면 끝이야, 세 번까지만 해 보고 안 되면 멈추고 알려 줘' 이 한 문장이면 충분합니다. 다만 클로드 코드에는 그 자리가 실제로 있어서, 완료 조건은 목표(/goal), 시간 간격 반복은 /loop, 컴퓨터가 꺼져 있어도 도는 예약은 클라우드 예약, 정한 시점마다 항상 하는 검사는 훅으로 존재합니다.
Q. 루프 엔지니어링이라는 말이 유행이던데 꼭 알아야 하나요?
단어보다 구조가 먼저입니다. 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 루프 엔지니어링처럼 이름은 계속 바뀝니다. 중요한 건 에이전트가 한 번에 원하는 결과를 내지 않는다는 사실을 전제로 상황을 모으고, 시켜 보고, 확인하고, 필요하면 다시 도는 구조를 짜는 일입니다. 앤트로픽 공식 자료의 표현으로는 gather context, take action, verify work, repeat 입니다.
Q. 자동으로 돌게 두면 배포까지 알아서 해 버리지 않나요?
그래서 4강의 역할 구분이 그대로 살아 있어야 합니다. 자료를 다시 조사해 고치는 것까지는 돌게 두더라도, 사이트에 배포하는 마지막 버튼은 사람 손에 남기세요. 시키면 해 주지만, 되돌릴 수 없는 행동 앞에서는 한 번 더 확인하는 게 원칙입니다.
AI DIAGNOSIS · 약 4분
이 글, 읽기만 하고 끝내긴 아깝죠
약 4분 진단으로 내 AI 활용 점수와, 오늘부터 30일 액션 플랜을 받아보세요.
무료 진단 시작
NEWSLETTER · 무료

주간 AI 실무 레터

이 글이 도움이 됐다면, 매주 현장에서 검증한 AI 활용법·새 자료를 이메일로 받아보세요. 광고 없이, 바로 쓰는 것만.

어떤 목적으로 오셨나요? (선택)
이 주제로 강의 문의

우리 조직에 맞는 AI 교육을
설계해드립니다.

위 자료의 내용을 기반으로 맞춤형 강의 커리큘럼을 구성해드립니다. 기업·공공기관·임원 대상 프로그램 모두 가능합니다.

강의 소개 보기강의 문의하기

조회수·다운로드 카운트 등 인터랙티브 기능은 자료실 인터랙티브 페이지에서 이용하실 수 있습니다.