계획의 깊이와 자가검증

AI에게 일을 맡길 때 품질은 두 곳에서 갈립니다. 하나는 시작 전에 계획을 얼마나 깊게 세우느냐이고, 다른 하나는 결과를 내놓기 전에 얼마나 다시 확인하느냐입니다. 이 장은 작업 크기에 맞춰 계획의 깊이를 고르는 법, 출력 직전에 검증하는 법, 그럴듯하지만 알맹이 없는 결과를 줄이는 법, 그리고 최종 판단은 사람이 한다는 원칙을 다룹니다.

계획에도 적정 깊이가 있습니다

모든 작업에 같은 무게의 계획을 붙이면 비효율이 생깁니다. 오타 하나 고치는 일에 설계 문서를 쓰면 흐름이 끊기고, 여러 파일을 건드리는 구조 변경을 계획 없이 시작하면 나중에 되돌릴 일이 쌓입니다. 작업 크기에 따라 세 단계로 나누면 판단이 쉬워집니다.

영향을 받는 파일의 범위가 대략의 기준입니다. 한두 문장으로 설명되고 어떤 파일이 바뀌는지 분명하면 No plan, 몇 개 파일이 바뀌지만 한 모듈 안에서 끝나면 Local plan, 여러 모듈에 걸치거나 되돌리기 어렵다면 Two-pass입니다. 파일 수보다 되돌리기 어려운 정도가 더 중요한 신호입니다. 파일은 하나뿐이어도 결제나 개인정보처럼 실수의 비용이 큰 영역이면 한 단계 위로 올립니다.

어떻게 고르는가

경계가 애매하면 한 단계 위로 올립니다. 계획이 과해서 잃는 것은 몇 분의 시간이지만, 계획이 부족해서 잃는 것은 작업 결과 자체일 수 있기 때문입니다. 다음 세 질문으로 빠르게 판단합니다.

1. 이 일을 두 문장으로 설명할 수 있는가. 설명할 수 없으면 계획이 필요합니다.
2. 틀렸을 때 한 번에 되돌릴 수 있는가. 되돌릴 수 없으면 한 단계 위로 올립니다.
3. 내가 결과를 눈으로 확인할 수 있는가. 확인 수단이 없으면 계획 단계에서 확인 방법부터 정합니다.

Local plan의 실제 모습

Claude Code에서는 계획 모드가 이 역할을 합니다. 계획 모드에서는 Claude가 파일을 읽고 계획을 제안하되, 사람이 승인하기 전에는 파일을 수정하지 않습니다. 계획 모드를 켜는 방법과 화면 표시는 버전에 따라 달라질 수 있으므로(2026년 11월 기준) 공식 문서에서 현재 방법을 확인합니다.

계획이 올라오면 다음 네 가지를 읽습니다.

• 건드리는 파일 목록이 예상과 맞는가
• 건드리지 말라고 한 부분이 목록에 들어 있지 않은가
• 확인 방법(테스트, 실행, 화면 점검)이 계획에 들어 있는가
• 중간에 막히면 어디서 멈추는가

네 가지 중 하나라도 비어 있으면 승인하지 않고 보완을 요청합니다. 계획을 읽는 일은 짧지만, 이 몇 분이 실행 뒤의 수정 시간을 크게 줄입니다.

Two-pass: 계획을 한 번 더 본다

Two-pass는 계획을 두 번 보는 방식입니다. 첫 번째 패스에서 Claude가 계획을 세우고, 두 번째 패스에서 다른 관점으로 그 계획을 검토합니다. 두 번째 검토는 같은 세션에서 "이 계획의 빠진 점과 위험을 찾아 달라"고 요청해도 되고, 새 세션을 열어 계획 문서만 넘겨 검토시켜도 됩니다. 새 세션이 낫습니다. 앞선 대화의 맥락이 없는 쪽이 계획의 허점을 더 잘 찾기 때문입니다. 새 세션과 서브에이전트를 활용하는 방법은 10장에서 다룹니다.

핵심 계획의 깊이는 작업 크기가 아니라 틀렸을 때의 비용에 맞춥니다. 애매하면 한 단계 위로 올립니다.

시작 전 합의서를 기준으로 삼습니다

9장에서 다룬 합의서(헌법)는 계획과 검증이 만나는 지점입니다. 목표, 제약, 우선순위 세 가지가 적혀 있으면 계획을 검토할 때 "이 계획이 제약을 깨지 않는가"를 기준 삼아 볼 수 있고, 검증할 때도 같은 제약을 항목별로 다시 확인할 수 있습니다. 합의서가 없으면 검토 기준이 매번 기억에 의존합니다. 작업이 길어질수록 처음 정한 제약이 흐려지므로, 합의서는 계획의 출발점이자 검증의 채점표로 씁니다.

출력 직전에 한 번 더 확인시킵니다

AI가 그럴듯하지만 틀린 답을 내놓는 흔한 이유는, 내놓은 답을 스스로 다시 확인한 적이 없기 때문입니다. 사람도 쓴 글을 다시 읽지 않으면 오탈자를 놓칩니다. 자가검증은 AI에게 이 재확인을 의무로 붙이는 방법입니다. 4단계로 구성합니다.

1단계. 핵심 주장 세 개를 고릅니다

초안의 모든 문장을 검증할 필요는 없습니다. 틀리면 결과 전체가 무너지는 사실만 세 개 추립니다. 숫자, 날짜, 법적 근거, 외부 서비스의 동작 방식, 코드가 실제로 존재한다고 주장한 함수나 파일이 대표적입니다.

2단계. 독립적인 검증 질문을 만듭니다

각 주장을 초안과 떼어 놓고 "이것이 정말 맞는가"를 묻는 별도 질문으로 바꿉니다. 분리가 핵심입니다. 초안을 옆에 둔 채 검증하면 초안의 표현에 끌려가 그대로 맞다고 답하기 쉽습니다. 초안을 보지 않은 상태에서 질문만 받아 답하게 하면 어긋남이 드러납니다.

3단계. 검증 답변을 초안과 비교합니다

검증 답변이 초안과 다르면 초안을 고칩니다. 어긋나지 않았더라도 근거를 확인할 수 없는 주장은 "확인되지 않음"으로 표시하게 합니다. 모르는 것을 모른다고 적게 하는 것이 이 단계의 목적입니다.

4단계. 제약 체크리스트로 마무리합니다

마지막으로 합의서의 제약을 항목별로 다시 확인합니다. 예를 들어 "고객 실명은 쓰지 않는다", "기존 파일은 수정하지 않는다", "결과는 표로 낸다" 같은 항목이 모두 지켜졌는지 하나씩 예, 아니오로 답하게 합니다. 아니오가 있으면 고친 뒤 다시 내놓게 합니다.

이 4단계는 검증 질문을 따로 만들어 답하게 하는 연구(Chain-of-Verification)와 스스로 비판하고 고치는 연구(Self-Refine)의 발상을 업무용으로 줄인 것입니다. 이름을 외울 필요는 없고, "주장을 고르고, 따로 묻고, 비교하고, 제약을 확인한다"는 순서만 기억하면 됩니다.

한계를 알고 쓴다

자가검증이 만능은 아닙니다. 같은 모델에게 "이게 맞아?"라고 되묻는 검증에는 특히 한계가 있습니다. 1장의 가짜 판례 사례에서 챗봇은 자기가 만든 판례를 진짜라고 확인해 주었습니다. 독립된 질문, 별도의 세션, 공식 자료, 사람의 확인 가운데 하나는 반드시 거쳐야 합니다.

같은 모델이 같은 지식으로 검증하므로 모델이 애초에 모르는 사실은 걸러지지 않습니다. 이럴 때는 두 가지를 덧붙입니다. 첫째, 최신 정보나 수치는 공식 출처를 직접 확인하게 합니다(웹 검색이나 문서 조회가 가능한 환경이라면 출처를 함께 달게 합니다). 둘째, 중요한 결과는 사람이 원본 자료와 대조합니다. 자가검증은 사람의 검토 시간을 줄이는 도구이지 검토를 대신하는 도구가 아닙니다.

'AI 같은 결과'를 줄이는 법

내용은 맞는데 어딘가 밋밋하고, 어디서 본 듯한 글이 나오는 경우가 있습니다. 대개 지시가 막연해서 가장 평균적인 답이 나온 것입니다. 다음 다섯 가지를 지시에 넣으면 많이 달라집니다.

1. 읽는 사람을 정합니다. "신입 직원", "처음 문의하는 고객"처럼 구체적일수록 문장이 구체적이 됩니다.
2. 실제 자료를 붙입니다. 우리 조직의 실제 문서, 지난 답변, 말투 예시가 있으면 평균적인 문장에서 벗어납니다.
3. 쓰지 말아야 할 표현을 적습니다. "획기적", "최고의" 같은 과장 표현이나 반복되는 맺음말 습관을 금지 목록으로 줍니다.
4. 분량과 구조를 제한합니다. "세 문단 이내", "표 하나와 요약 두 줄"처럼 한계를 두면 군더더기가 줄어듭니다.
5. 첫 결과를 그대로 쓰지 않습니다. "가장 일반적인 문장 세 곳을 찾아 구체적인 문장으로 바꿔 달라"고 한 번 더 요청합니다.

디자인이나 문서 양식에도 같은 원리가 적용됩니다. 피해야 할 패턴을 목록으로 미리 합의해 두면 결과가 매번 같은 틀로 수렴하는 것을 막을 수 있습니다.

테스트와 점검은 AI가 아닌 도구에게 맡깁니다

코드를 다루는 작업에서 가장 믿을 만한 검증은 AI의 말이 아니라 실제로 실행한 결과입니다. 테스트, 문법 검사(lint), 타입 검사, 빌드가 여기에 해당합니다. 이 명령들은 같은 입력에 같은 결과를 냅니다. 이 성질을 재현성이라고 하며, 자가검증의 한계를 보완해 줍니다.

작업을 맡길 때 다음 규칙을 함께 줍니다.

• 실제로 실행한 명령의 결과만 보고합니다. 실행하지 않은 테스트를 통과했다고 쓰지 않습니다.
• 수정마다 테스트가 먼저 실패하고 수정 후에 통과하도록 합니다. 버그를 고칠 때는 같은 버그가 다시 생기지 않도록 그 상황을 재현하는 테스트를 남기게 합니다.
• 변경 전에 되돌릴 수 있는 지점(커밋)을 만듭니다. 20장에서 다룹니다.

코드가 아닌 작업에도 같은 정신이 통합니다. 데이터 분석이라면 합계가 원본 합계와 맞는지, 문서라면 인용한 수치가 원문과 같은지를 기계적으로 대조하는 단계를 둡니다.

품질을 한 번에 끌어올리는 순서

액티전스 프롬프트 카드 중 품질 파이프라인 카드는 테스트 보강, 코드 리뷰, 정리를 한 흐름으로 묶었습니다. 순서에는 이유가 있습니다. 테스트로 안전망이 없는 코드를 고치면 무엇이 깨졌는지 알 수 없으므로 테스트를 먼저 만듭니다. 리뷰하지 않은 코드를 정리하면 문제를 안은 채 모양만 다듬게 되므로 리뷰가 정리보다 앞섭니다. 즉 덮어 두지 않은 것은 리팩터링하지 않고, 검토하지 않은 것은 정리하지 않습니다. 카드의 자세한 내용은 부록 A에 있습니다.

AI 슬롭과 워크슬롭

AI로 대량 생산한 그럴듯하지만 알맹이 없는 결과물을 AI 슬롭(slop)이라고 부릅니다. 업무 문서에서는 워크슬롭(workslop)이라고 합니다. 이때 일이 사라진 것이 아니라 받는 사람에게 넘어간 것입니다. 만들기가 쉬워지면 이해하고 검토하는 일이 새로운 병목이 됩니다.

진짜 손해는 시간이 아니라 신뢰입니다. "이 사람이 보낸 건 한 번 더 확인해야 한다"는 인식이 생기면 그 사람의 모든 산출물이 느려집니다. 워크슬롭의 피해를 수치로 조사한 연구가 있다고 알려져 있으나, 이 책은 원출처를 확인하기 전에는 수치를 인용하지 않습니다.

보내기 전에 세 가지를 스스로 묻습니다.

1. 내가 내용을 이해했는가
2. 근거를 직접 확인했는가
3. 받는 사람이 할 일이 줄어드는가

세 질문 중 하나라도 아니오라면 보내지 않고 손봅니다.

최종 판단은 사람이 합니다

AI는 초안을 만들고 점검을 돕지만, 발송, 게시, 결제, 배포 같은 되돌리기 어려운 결정은 사람이 합니다. 검토할 때는 다음 질문을 던집니다.

• 이 결과가 틀렸을 때 누가 어떤 피해를 입는가
• 내가 직접 확인한 것과 AI의 말을 믿은 것이 구분되어 있는가
• 근거가 필요한 주장에 출처가 있는가

검토 시간은 위험에 비례해 씁니다. 내부 메모의 오타는 훑어보면 되고, 고객에게 나가는 안내문이나 법적 판단이 걸린 문서는 원본과 대조하면서 읽습니다. 법률, 세무, 의료처럼 전문 자격이 필요한 영역은 AI의 결과를 참고 자료로만 쓰고 해당 전문가에게 확인합니다.

초안, 검수, 발송과 기록

1장의 세 단계(AI가 초안, 사람이 검수, 발송과 기록)에서 이 장이 맡는 것은 2단계입니다. 3단계의 기록도 같은 흐름에 속합니다. 무엇을 검수하고 어디를 고쳤는지가 남아야 다음 일에서 같은 실수가 반복되지 않습니다. 기록을 조직의 자산으로 쌓는 방법은 22장에서 다룹니다.

사람이 직접 코멘트로 짚는 검토

AI에게 검토를 통째로 맡기지 않고, 사람이 읽으면서 고칠 곳에 쪽과 문단 위치를 적어 한 줄씩 코멘트로 넘기는 방법이 있습니다. 반영된 결과는 새 버전 파일로 저장하게 하고, 무엇을 왜 고쳤는지는 기록 파일에 한 줄씩 남기게 합니다. 고칠 곳을 짚을 때는 네 마디로 충분합니다.

코멘트 예(가상의 예)입니다.

3쪽 둘째 문단: 근거가 오래됐어. 최신 자료로 다시 확인해줘.
5쪽 표: 앞 문단의 숫자와 정합성이 안 맞아.

검토가 쓰던 세션의 영향을 받지 않게 하는 방법도 있습니다. 쓰던 세션은 사정을 다 알아서 처음 읽는 사람이 걸리는 곳을 놓칩니다. 진행 기록을 갱신하고 세션을 닫은 뒤, 같은 폴더에서 새 세션을 열어 독자의 눈으로 검토만 시킵니다. 이때 "문서는 고치지 마"를 명시합니다. 숫자는 내 손으로 셋을 골라 원 기록까지 따라가 직접 합계를 내 봅니다. 셋이 맞으면 나머지를 믿을 근거가 생깁니다. 제안서의 흐름은 16장에서, 결과보고서의 흐름은 17장에서 자세히 다룹니다.

실습

실습 1. 자가검증 꼬리말 붙이기

평소 쓰는 요청 하나를 골라, 요청 끝에 아래 꼬리말을 그대로 붙여 보냅니다. 결과에서 검증 질문 답변과 수정된 부분이 실제로 나오는지 확인합니다.

[출력 전 자가검증 — 아래 순서를 지킨 뒤 최종본만 보여 주세요]
1. 초안에서 틀리면 안 되는 핵심 주장 3개를 고릅니다.
2. 각 주장을 초안을 보지 않은 상태로 "이것이 사실인가"를 묻는 독립 질문으로 바꿔 스스로 답합니다.
3. 답이 초안과 다르거나 근거를 확인할 수 없으면 초안을 고치고, 확인할 수 없는 내용은 "확인되지 않음"이라고 표시합니다.
4. 이 요청에서 내가 정한 제약을 항목별로 나열하고, 각각 지켰는지 예/아니오로 확인합니다. 아니오가 있으면 고친 뒤 내보냅니다.
마지막에 "검증 요약" 3줄(고른 주장, 바뀐 내용, 확인되지 않은 내용)을 붙입니다.

실습 2. 계획의 깊이 판단 연습

지금 하려는 업무 세 가지를 떠올리고, 각각 No plan, Local plan, Two-pass 중 어디에 해당하는지 AI와 함께 판단해 봅니다.

아래 작업 3가지를 각각 No plan / Local plan / Two-pass 중 하나로 분류해 주세요.
판단 기준은 (1) 두 문장으로 설명 가능한가, (2) 틀렸을 때 되돌리기 쉬운가, (3) 결과를 내가 눈으로 확인할 수 있는가입니다.
애매하면 한 단계 위로 분류하고 이유를 한 줄로 적어 주세요.
각 작업마다 시작 전에 합의해야 할 제약을 2개씩 제안해 주세요.

작업 1: (내용)
작업 2: (내용)
작업 3: (내용)

실습 3. 밋밋한 결과 다듬기

최근에 AI가 만든 글이나 답변 하나를 붙여 넣고 다음 요청을 보냅니다.

아래 글에서 어디서나 쓸 수 있는 일반적인 문장 3곳을 찾아 이유를 설명하고, 읽는 사람이 [읽는 사람 설명]이라는 전제로 구체적인 문장으로 바꿔 주세요.
과장 표현(획기적, 최고의 등)과 반복되는 맺음말은 쓰지 않습니다.
바꾼 문장은 원문과 나란히 표로 보여 주세요.

(여기에 글 붙여 넣기)

선택 과제. 보내기 전 질문 세 개

최근에 만든 결과물 하나에 "내가 이해했는가, 근거를 확인했는가, 받는 사람이 할 일이 줄어드는가" 세 질문을 적용해 봅니다. 아니오가 나온 항목을 한 줄씩 적고 고쳐서 다시 확인합니다.

정리

• 계획의 깊이는 작업 크기와 틀렸을 때의 비용에 맞춥니다. 애매하면 한 단계 위로 올립니다.
• 자가검증은 핵심 주장 고르기, 독립 질문, 비교, 제약 체크리스트의 4단계입니다.
• 자가검증은 사람의 검토를 줄여 줄 뿐 대신하지 않습니다. 최신 정보와 수치는 원본으로 대조합니다.
• 밋밋한 결과는 읽는 사람, 실제 자료, 금지 표현, 분량 제한을 지시에 넣어 줄입니다.
• 같은 모델에게 되묻는 검증은 한계가 있으므로 독립된 질문, 별도 세션, 공식 자료, 사람의 확인을 거칩니다. 워크슬롭은 일을 받는 사람에게 넘기는 것이니 보내기 전에 세 질문으로 점검합니다.
• 코드 검증은 AI의 말이 아니라 실제로 실행한 테스트와 빌드 결과를 기준으로 하고, 최종 판단은 사람이 합니다.