AI가 만든 결과물이 그럴듯해 보일수록 검증은 더 중요해집니다. 이 장에서는 Claude Code에게 실행 전 계획을 받는 법, 오류가 났을 때 스스로 점검하게 하는 법, 사람이 반드시 확인해야 할 항목을 분리하는 법을 다룹니다.
이미지: 실행 전 계획과 결과 검증을 거쳐 사람이 승인하는 흐름
이 장에서 손에 남는 것
- 실행 전 "계획 먼저 받기" 프롬프트 구조 (읽을 파일 / 만들 파일 / 위험 작업 / 검증 / 승인)
- 오류 발생 시 처리 5단계 규칙 (요약 → 원인 좁히기 → 수정 → 재검증 → 옵션 제시)
- 위험도별 검증 강도 분류 (낮음·중간·높음 3단)
- 6개 대표 업무의 검증 항목 표 (PDF·엑셀·주간보고·회의록·정산·브리핑)
- 어떤 챕터에서도 재사용 가능한 "공통 자동화 프롬프트 뼈대"
- 사람이 반드시 판단할 영역 5개 (법적 판단 / 금액 최종 / 외부 발송 / 개인정보 / 결재)
예상 소요: 본문 읽기 약 30분 + 공통 프롬프트 뼈대 자기 업무에 맞춰 1회 작성 약 15분.
이미지: AI 실행 전 계획을 받고 결과 검증 후 사람이 승인하는 반복 루프
보고서 초안을 열었을 때 표가 깔끔하고 문장이 매끄러우면 마음이 놓입니다. 하지만 겉모양이 깔끔할수록 더 조심해야 합니다. 숫자가 틀렸거나, 출처가 빠졌거나, 담당자가 없는 액션아이템을 AI가 그럴듯하게 채워 넣어도 겉모양만 보면 알아차리기 어렵기 때문입니다.
AI에게 일을 맡길 때 꼭 덧붙여야 할 문장은 "검증까지 해줘"입니다. 자동화에서 가장 위험한 상황은 AI가 실수하는 순간이 아닙니다. 실수한 결과물을 그럴듯하게 내놓고, 사람이 그대로 믿는 순간입니다.
그래서 Claude Code에게는 결과물 생성과 검증을 함께 요청합니다. 오류가 발생했을 때 어떻게 처리해야 하는지도 미리 알려둬야 합니다.
AI가 만든 결과물은 종종 보기 좋습니다. 표도 있고 제목도 있고 문장도 매끄럽습니다. 그래서 더 위험합니다. 틀린 숫자도 깔끔한 표 안에 들어가 있으면 그럴듯해 보입니다. 자동화에서 필요한 태도는 "AI를 믿지 않는다"가 아닙니다. AI가 스스로 확인하게 만들고, 사람이 마지막에 확인하는 태도입니다.
실행 전 계획
실행 전에는 반드시 계획을 받습니다. Claude Code가 곧바로 파일을 만들거나 수정하기 전에 어떤 순서로 무엇을 처리할지 먼저 확인해야 합니다. 이 습관은 처음에는 느려 보여도 실제로는 사고를 줄이는 가장 빠른 길입니다. 계획에는 다음이 포함되어야 합니다.
- 읽을 파일
- 만들 파일
- 수정할 파일
- 위험한 작업 여부
- 검증 방법
- 사용자 승인이 필요한 단계
프롬프트 예시:
작업을 실행하기 전에 계획을 먼저 보여줘.
계획에는 다음을 포함해줘.
1. 읽을 파일 목록
2. 생성할 파일 목록
3. 수정하거나 이동할 파일이 있는지
4. 외부 발송, 삭제, 덮어쓰기 같은 위험 작업이 있는지
5. 완료 후 어떤 검증을 할지
내가 승인하기 전에는 파일을 변경하지 마.이 요청은 자동화의 브레이크 역할을 합니다. 특히 초보자는 Claude Code가 무엇을 할지 알기 전에는 실행하지 않는 습관을 들여야 합니다.
개발곰곰의 팁
"계획 먼저"는 초보자용 안전장치만은 아닙니다. 숙련자일수록 큰 작업 전에 계획을 먼저 봅니다. 계획을 보면 AI가 업무를 제대로 이해했는지, 위험한 행동을 하려는지 일찍 알아챌 수 있습니다.
예시: 브레이크 없는 요청
파일 정리 업무를 예로 들어보겠습니다. 아래 요청은 짧고 편해 보이지만, 실무에서는 위험합니다.
위험한 요청:
이 폴더 정리해서 필요 없는 파일은 삭제해줘.안전한 요청:
이 폴더에서 삭제 후보 파일을 찾아줘.
아직 삭제하지 말고, 삭제 후보와 이유를 표로 보여줘.
내가 승인한 파일만 삭제 계획에 포함해줘.두 요청은 비슷해 보이지만 결과가 다릅니다. 첫 요청은 원본 손실로 이어질 수 있고, 문제가 생긴 뒤에는 원인을 추적하기도 어렵습니다. 두 번째 요청은 판단권을 사람에게 남깁니다. 그래서 자동화가 실수하더라도 멈출 지점이 생깁니다.
내 업무에 적용하는 질문
내가 AI에게 시키려는 일 중 삭제, 덮어쓰기, 이동, 발송처럼 되돌리기 어려운 작업이 포함되어 있나요?
권한 모드 — 매번 적지 말고 세션에 걸어두는 안전 노브
"계획 먼저"를 매 프롬프트에 적는 대신, 세션에 한 번 걸어두는 방법도 있습니다. Claude Code에는 실행 권한을 단계로 조절하는 모드가 있어, 익숙해지는 정도에 따라 옮겨 쓰면 반복 작업의 마찰이 줄어듭니다(2026년 7월 기준, 화면에서
Shift+Tab으로 전환하거나/plan으로 지정합니다).
- 계획 모드(Plan) — 처음 다루는 폴더나 큰 작업에 씁니다. AI가 파일을 바꾸지 않고 계획만 세워 보여주고, 사람이 보고 승인합니다.
- 확인 모드(Ask) — 익숙해진 작업에 씁니다. 변경 직전마다 사람에게 묻습니다.
- 자동 편집(acceptEdits) — 매일·매주 반복하는 안정된 자동화에 씁니다. 파일 변경은 자동으로 승인하되, 외부 발송·삭제·금액 확정처럼 되돌리기 어려운 작업은 여전히 사람에게 묻습니다.
단계를 옮겨도 사람이 마지막 버튼을 쥔다는 원칙은 그대로입니다. 권한을 아예 묻지 않고 맡기는 방식도 있지만, 이 책이 지키는 승인 게이트와 충돌하므로 회사 업무에는 권하지 않습니다. 모드 이름과 전환 방법은 바뀔 수 있으니 적용 시점에 공식 문서에서 확인하세요.
오류 발생 시 처리 규칙
AI가 오류를 만났을 때 바로 멈추기만 해도 곤란합니다. 반대로 아무 설명 없이 계속 수정하는 것도 문제입니다. 좋은 방식은 오류를 요약하고, 원인을 좁히고, 수정한 뒤 다시 검증하는 흐름입니다.
오류가 발생하면 다음 순서로 처리해줘.
1. 오류 메시지를 사람이 이해할 수 있게 요약한다.
2. 가능한 원인을 3개 이하로 좁힌다.
3. 가장 가능성 높은 원인부터 수정한다.
4. 같은 검증을 다시 실행한다.
5. 그래도 실패하면 내가 선택할 수 있는 해결 옵션을 제시한다.이 규칙은 엑셀 자동화, 파일 변환, PDF 처리, 브라우저 조작 자동화에서 특히 유용합니다. 오류가 날 때마다 새로 설명하지 않아도 되도록 자주 쓰는 작업공간의 CLAUDE.md에 넣어두면 좋습니다.
핵심 포인트
오류 처리는 "다시 해봐"가 아니라 "무엇이 실패했고, 왜 실패했으며, 무엇을 고쳤고, 다시 확인했는가"의 순서로 남겨야 합니다.
개발곰곰의 팁 — 자가 치유가 닿는 곳과 닿지 않는 곳
AI가 스스로 고치는 능력에도 경계가 있습니다. 오타, 파일 경로, 권한, 이름 충돌 같은 기술적 오류는 능숙하게 되잡습니다. 하지만 "임원이 원한 건 매출 표가 아니라 전년 대비 증감률이었다" 같은 의미적 오류는 알아채지 못합니다. 형식은 맞는데 방향이 틀린 경우는 AI가 스스로 알 길이 없기 때문입니다.
그래서 자가 치유는 사람의 검수를 없애 주는 면제권이 아니라, 사람이 방향만 잡아 주면 잔손질을 맡아 주는 기능에 가깝습니다. 기술적 오류는 믿고 맡기되, "이게 정말 내가 원한 결과인가"는 끝까지 사람이 봅니다.
실제 구현 흐름
스스로 고치게 만든다는 말은 AI에게 무제한 수정 권한을 준다는 뜻이 아닙니다. 계획, 실행, 검증, 수정 요청을 한 루프로 묶는다는 뜻입니다.
1단계: 작업 계획을 먼저 보여줘.
2단계: 내가 승인하면 초안을 만들어줘.
3단계: 초안의 숫자, 출처, 누락값을 자체 검증해줘.
4단계: 검증표에 걸린 항목만 수정 후보로 제안해줘.
5단계: 원본 파일은 절대 수정하지 말고 새 파일로 저장해줘.보고서 자동화에서는 초안 파일과 검증표를 분리합니다. 예를 들어 weekly_report_draft.md와 weekly_report_checklist.md를 함께 만들게 하면, AI의 문장 생성과 검증 결과를 따로 볼 수 있습니다.
이 흐름의 입력은 원본 문서와 작업 규칙이고, 출력은 초안 파일과 검증표, 수정 후보 목록입니다.
도구 선택
Markdown, CSV, JSON처럼 diff가 쉬운 포맷을 우선 사용합니다. 최종 산출물이 DOCX나 HWPX여도 중간 검증은 텍스트와 표로 남기는 편이 안전합니다.
검증 체크
- AI가 실행 전에 계획을 제시했나요?
- 검증표가 초안과 별도 파일로 남나요?
- 수정 후보와 자동 수정 완료 항목이 구분되나요?
- 위험 작업은 승인 전 멈추나요?
안 될 때 대안
AI가 자기 검증을 형식적으로만 한다면 검증 기준을 더 작게 쪼갭니다. "검토해줘" 대신 "숫자 출처 누락, 날짜 불일치, 담당자 미정, 외부 발송 문구 포함 여부를 표로 확인해줘"처럼 항목을 지정합니다.
반론: "검증까지 시키면 시간이 두 배 걸리지 않나?"
시간은 조금 더 걸립니다. 하지만 사람이 나중에 처음부터 다시 확인하는 시간보다는 짧습니다. 숫자나 금액, 외부 발송, 결재가 포함된 업무라면 검증은 선택이 아닙니다.
그래서 모든 항목을 똑같이 깊게 검증하지는 않습니다. 업무 위험도에 따라 검증 강도를 나누면 속도와 안정성을 함께 잡을 수 있습니다.
| 위험도 | 예시 | 검증 방식 |
|---|---|---|
| 낮음 | 파일명 정리 계획, 내부 메모 초안 | 간단 체크 |
| 중간 | 주간보고서, 회의록 | 누락/출처/담당자 확인 |
| 높음 | 정산서, 외부 발송, 결재 자료 | 숫자 대조 + 사람 승인 |
결국 검증은 자동화 속도를 늦추는 장치가 아닙니다. 자동화를 실무에 쓸 수 있게 만드는 장치이며, 특히 숫자와 외부 발송이 얽힌 업무에서는 신뢰를 만드는 최소 조건입니다.
핵심 포인트
모든 업무를 똑같이 깊게 검증할 필요는 없습니다. 위험한 업무는 깊게, 가벼운 업무는 빠르게 확인하면 됩니다.
결과물 검증
업무마다 검증 기준은 달라집니다. 그래서 "검증해줘"라고만 쓰면 부족합니다. 어떤 항목을 어떤 기준으로 확인해야 하는지 함께 알려줘야 합니다.
| 업무 | 검증 항목 |
|---|---|
| PDF 보고서 | 원문 출처, 숫자 단위, 추측 여부, 누락 섹션 |
| 엑셀 취합 | 행 수, 중복, 빈 값, 합계, 날짜 범위 |
| 주간보고서 | KPI 출처, 전주 대비, 담당자, 마감일 |
| 회의록 | 결정/의견 구분, 액션아이템, 담당자, 기한 |
| 정산서 | 공급가액+부가세=합계, 발주서 대조, OCR 의심값 |
| 브리핑 | 날짜, 중복 뉴스, 출처, 민감정보 |
검증 프롬프트는 다음처럼 쓸 수 있습니다.
결과물을 만든 뒤 다음 기준으로 검증해줘.
1. 원본 데이터와 결과물의 숫자가 일치하는지
2. 누락된 파일이나 항목이 없는지
3. AI가 추측한 내용이 있는지
4. 사람이 확인해야 할 항목이 있는지
5. 외부 발송, 원본 변경, 개인정보 처리 같은 위험 작업이 포함되는지
검증 결과는 "통과 / 확인 필요 / 수정 완료" 상태로 표기해줘.개발곰곰의 팁
검증 결과는 문장보다 표가 좋습니다.
항목,상태,근거,사람 확인 필요 여부네 칸으로 받으면 나중에 확인하기 쉽습니다.
공통 자동화 프롬프트
앞으로 어떤 장을 읽든 아래 프롬프트를 기본형으로 삼으면 됩니다. 업무명과 파일명만 바꾸면 보고서, 엑셀, 회의록, 정산 검토에 모두 적용할 수 있습니다.
아래 업무를 바로 실행하지 말고 먼저 계획을 세워줘.
업무:
- [자동화할 업무를 한 줄로 적기]
입력:
- [읽을 파일 또는 폴더]
처리 규칙:
- 원본 파일은 직접 수정하지 않는다.
- 결과물은 새 파일로 저장한다.
- 숫자, 날짜, 담당자, 금액, 수신자는 출처를 표시한다.
- 확실하지 않은 내용은 추측하지 말고 "확인 필요"로 표시한다.
출력:
- 초안 파일
- 검증표
- 사람 확인 필요 항목
승인 규칙:
- 외부 발송, 원본 삭제, 덮어쓰기, 금액 확정, 결재 제출은 실행하지 않는다.
- 위험 작업이 필요하면 이유와 예상 결과를 먼저 설명하고 내 승인을 기다린다.
완료 후:
- 읽은 파일 목록
- 생성한 파일 목록
- 검증 결과
- 내가 확인해야 할 항목
을 표로 보고해줘.이 프롬프트는 만능 주문이 아니지만, 업무 자동화에서 빠지면 안 되는 뼈대를 담고 있습니다. 계획, 원본 보호, 새 결과물, 검증표, 사람 승인입니다.
사람이 판단해야 할 항목
AI가 잘하는 일과 사람이 해야 하는 일은 나눠야 합니다. AI는 숫자를 비교하고 누락을 찾고 초안을 만들지만, 법적 판단, 금액 최종 승인, 고객 발송, 인사 평가, 개인정보 처리 가능 여부는 사람이 판단해야 합니다.
Claude Code에게도 이 경계를 분명히 알려줍니다.
다음 항목은 네가 확정하지 말고 반드시 "사람 확인 필요"로 표시해줘.
- 법적 판단
- 금액 최종 승인
- 외부 고객 발송 여부
- 개인정보 처리 가능 여부
- 결재 승인 여부핵심 포인트
AI에게 맡길 일과 사람이 판단할 일을 나누면 자동화가 더 안정적입니다. 경계를 정하지 않은 자동화는 편리해 보여도 실무에서는 오래 쓰기 어렵습니다.
이 장의 결과물
| 결과물 | 무엇인가 | 다음 챕터 연결 |
|---|---|---|
| 실행 전 계획 프롬프트 | "읽을 파일 / 만들 파일 / 위험 작업 / 검증 / 승인" 실행 전 5점검을 받아내는 요청입니다. 1·2장의 좋은 지시문 **5요소(입력·규칙·작업·출력·검증)**와는 별개의 점검 항목입니다 | 2부 모든 레시피의 실행 첫 단계 |
| 오류 처리 5단계 규칙 | 요약 → 원인 좁히기 → 수정 → 재검증 → 옵션 제시 | 7장 엑셀 처리 / 16장 송장 OCR 오류 |
| 업무별 검증표 6종 | PDF·엑셀·주간보고·회의록·정산·브리핑 각각의 검증 항목 | 6~10장 각 챕터의 검증 체크 |
| 공통 자동화 프롬프트 뼈대 | 어떤 업무에도 재사용 가능한 표준 요청 양식 | 2부 모든 챕터의 첫 프롬프트 |
| 사람 판단 영역 5개 | AI에게 절대 확정시키지 않을 항목 목록 | 1부 마무리 자동화 금지 영역 |
연결 안내
- 검증이 실제로 실패하는 5개 시나리오와 수정 다이얼로그는 2부 마무리. AI가 틀렸을 때에 있습니다.
- 자동 실행으로 갈 때의 안전 게이트는 15장. Hooks, Routines, Computer Use에 있습니다.
- 사람 판단 영역의 확장(법적·인사·금융)은 1부 마무리. 자동화하지 마세요의 자동화 금지 영역 8개 표에 있습니다.
내 업무에 적용하기 — 검증·승인 흐름 워크시트
검증을 매번 처음부터 설계할 필요는 없습니다. 자기 업무 한 가지를 골라 아래 표 빈칸을 채우면 그 업무 전용 검증 흐름이 한 장에 완성됩니다.
| 항목 | 질문 | 내 답 |
|---|---|---|
| 자동화할 업무 한 줄 | 무슨 업무인가? | |
| 검증할 핵심 숫자 | 어떤 숫자가 틀리면 가장 큰 문제? | |
| 위험도 (낮음·중간·높음) | 어느 등급? | |
| 사람 확인 항목 3개 | 마지막에 사람이 반드시 볼 것? | |
| 위험 작업 (외부 발송/삭제/금액 확정 등) | 자동화 흐름에 포함되는가? | |
| 멈춤 트리거 | AI가 무엇을 발견하면 멈춰야 하나? |
답을 채우다 막히는 칸은 그 업무의 검증 절차가 사람의 머릿속에만 있다는 신호입니다. 같은 워크시트를 동료와 공유해 한 번 같이 채우면 자동화 도입 전에 회사 안에서 "검증 표준"을 합의하는 도구로도 쓸 수 있습니다.
핵심 포인트
4장의 목표는 AI가 실수하지 않는다고 믿는 것이 아닙니다. 실수하더라도 빨리 발견하고, 위험한 결정 앞에서는 멈추는 구조를 만드는 것입니다.