4부 18장. AI에게 중간 점검을 시키는 법
4부 18장. AI에게 중간 점검을 시키는 법
지난 장에서는 멀티턴 대화를 탐색, 정리, 초안, 비평, 개선의 흐름으로 나누어 보는 방법을 살펴보았다. 이제 한 걸음 더 들어가 보자. 구조를 알고 있다고 해서 항상 잘되는 것은 아니다. 단계가 나뉘어 있어도, 중간에 방향이 조금씩 틀어지면 마지막에 가서 크게 무너질 수 있다.
많은 사람이 AI와 일할 때 저지르는 가장 비싼 실수는 마지막에만 검토하는 것이다. 처음에는 괜찮아 보여서 계속 밀고 나갔는데, 끝에 가서 보니 목표와 다르고, 중요한 조건이 빠졌고, 형식도 안 맞고, 핵심 논리도 어긋나 있는 경우가 있다. 이때는 고치는 것이 아니라 거의 다시 만드는 수준이 된다.
그래서 중요한 것이 중간 점검이다. 중간 점검은 작업을 잠깐 멈추고, 지금까지 만든 결과가 맞는 방향으로 가고 있는지 확인하는 과정이다. 쉽게 말해, 목적지를 향해 달리는 동안 한 번씩 내비게이션을 보는 일이다. 도착한 뒤에 길을 잘못 들었다는 사실을 아는 것보다, 중간에 바로잡는 편이 훨씬 싸고 빠르다.
이 장에서는 AI에게 스스로 중간 점검을 시키는 법을 다룬다. 초안만 만들게 하지 말고, 자기 결과를 다시 읽게 하고, 오류를 찾게 하고, 빠진 것을 체크하게 하고, 필요하면 다음 단계 계획까지 다시 세우게 만드는 방법이다. 잘 쓰면 AI는 단순한 작성 도구가 아니라, 자기 작업을 잠깐 멈춰 돌아보는 협업 상대가 된다.
왜 마지막 검토만으로는 늦는가
AI 작업은 생각보다 빨리 길을 잘못 든다. 문제는 그 어긋남이 초반에는 잘 안 보인다는 점이다. 특히 문장이 그럴듯하면 더 속기 쉽다. 말끔하게 써 내려간 문장을 보면, 사람은 내용까지 맞는 것처럼 느끼기 쉽다.
하지만 실제 실패는 대개 초반에 이미 시작된다. 독자가 잘못 설정되었거나, 과제가 살짝 오해되었거나, 형식 제약이 흐려졌거나, 핵심 질문 대신 주변 질문을 붙잡았을 수 있다. 이런 작은 어긋남은 처음에는 티가 안 나지만, 초안이 길어질수록 커진다. 그러다가 마지막에 가서야 "아, 이거 애초에 방향이 다르네"라는 말이 나온다.
중간 점검의 가장 큰 장점은 바로 여기에 있다. 작업이 아직 작을 때 문제를 발견하게 해 준다. 개요 단계에서 틀린 것은 몇 줄 고치면 되지만, 완성본에서 틀린 것은 구조 전체를 뜯어고쳐야 한다. 샘플 문단에서 어색한 톤을 잡으면 쉽지만, 3천 자를 다 쓴 뒤 톤이 안 맞는다고 느끼면 다시 손이 많이 간다.
그러니 중간 점검은 시간을 더 쓰는 과정이 아니다. 오히려 나중에 낭비될 시간을 앞에서 조금 쓰는 과정이다. 공사장에서 중간 점검을 한다고 일이 느려지는 것이 아니라, 나중에 벽을 허물 일을 줄이는 것과 비슷하다.
중간 점검은 무엇을 확인하는가
중간 점검이라고 하면 막연하게 "어때?"라고 묻게 되기 쉽다. 하지만 그렇게 물으면 대개 막연한 답이 돌아온다. 좋은 중간 점검은 확인 항목이 분명하다. 보통은 다음 네 가지를 본다.
방향: 지금 결과가 원래 목표와 맞는가
사실과 논리: 틀린 주장, 비약, 근거 부족은 없는가
형식과 제약: 길이, 톤, 독자 수준, 출력 형식이 맞는가
누락: 꼭 들어가야 할 내용이 빠지지 않았는가
이 네 가지를 구분하면 점검이 훨씬 날카로워진다. 예를 들어 어떤 초안은 문장은 좋지만 방향이 틀렸을 수 있다. 또 어떤 결과물은 방향은 맞지만 중요한 항목이 빠졌을 수 있다. 어떤 것은 정보는 많지만 독자 수준에 비해 너무 어렵게 쓰였을 수 있다.
즉, 중간 점검은 "좋으냐 나쁘냐"를 묻는 감상 시간이 아니다. 무엇이 맞고 무엇이 어긋났는지 분해해서 보는 시간이다.
AI가 스스로 점검하게 만드는 기본 구조
AI에게 중간 점검을 시킬 때는 "방금 쓴 내용을 점검해 줘"라고만 말하는 것보다, 점검의 순서를 함께 주는 편이 훨씬 낫다. 가장 실용적인 기본형은 다음과 같다.
먼저, AI에게 지금까지 한 일을 짧게 요약하게 한다. 그다음, 작업 기준과 현재 산출물을 비교하게 한다. 이어서 문제점과 불확실성을 찾게 하고, 마지막으로 다음 행동을 제안하게 한다.
이 흐름을 문장으로 쓰면 대체로 이런 형태가 된다.
지금까지 만든 결과를 5줄 이내로 요약해 줘.
그다음 이 결과가 우리의 목표, 독자, 형식, 길이 기준에 맞는지 항목별로 점검해 줘.
부족한 점, 틀릴 가능성이 있는 점, 빠진 점을 구분해서 써 줘.
마지막으로 다음 턴에서 무엇을 수정해야 할지 우선순위를 제안해 줘.
이 구조가 좋은 이유는 단순하다. AI가 막연한 자기평가를 하는 대신, 요약 → 비교 → 진단 → 다음 행동의 순서로 생각하게 만들기 때문이다. 사람도 일을 잘 점검할 때는 그냥 "괜찮은가?"라고 묻지 않는다. 지금 상태를 정리하고, 기준과 대조하고, 문제를 적고, 다음 조치를 정한다.
중요한 점은 점검 결과를 칭찬문이 아니라 진단서로 받는 것이다. "전반적으로 잘 되었습니다" 같은 말은 기분은 좋지만 작업에는 큰 도움이 안 된다. 반면 "핵심 메시지가 3단락 뒤에야 나온다", "초보 독자 기준으로 전문 용어 설명이 부족하다", "반론 가능성이 빠져 있다" 같은 말은 바로 수정으로 이어질 수 있다.
좋은 중간 점검은 작성자와 점검자를 분리한다
AI는 방금 쓴 자기 글에 관대해지기 쉽다. 사람도 자기가 쓴 문장에는 쉽게 빠져들듯, AI도 직전에 만든 결과를 그대로 이어 가려는 경향이 있다. 그래서 중간 점검을 시킬 때는 역할을 분리해 주는 것이 좋다.
예를 들어 방금까지는 작성자 역할이었다면, 점검 단계에서는 이렇게 바꾼다.
이제부터는 작성자가 아니라 검토자 역할이다.
방금 만든 초안을 옹호하지 말고, 실패 가능성을 먼저 찾아라.
문장 칭찬보다 내용 문제, 구조 문제, 누락 문제를 우선 지적해라.
이렇게 역할을 바꾸면 AI의 시선도 바뀐다. 물론 완벽하게 다른 존재가 되는 것은 아니지만, 적어도 한 방향으로 계속 밀고 가는 관성을 줄일 수 있다.
실전에서는 이 차이가 꽤 크다. 작성 모드에서는 자연스럽게 매끄러운 연결과 완성도를 높이려 한다. 반면 점검 모드에서는 "어디가 위험한가", "무엇이 빠졌는가", "무슨 가정이 숨어 있는가"를 보게 된다. 둘은 전혀 다른 일이다.
쉽게 말해, AI를 한 사람의 비서로만 쓰지 말고, 때로는 감리자처럼 써야 한다는 뜻이다.
언제 멈춰서 점검해야 하는가
초보자는 종종 이런 질문을 한다. "좋아요. 중간 점검이 중요하다는 건 알겠는데, 언제 해야 하죠?" 정답은 간단하다. 되돌리기 비싸기 전에 하면 된다.
특히 다음 순간에는 점검을 넣는 것이 좋다.
방향을 정한 직후: 목표, 독자, 형식을 제대로 이해했는지 확인할 때
개요나 계획을 만든 직후: 구조가 맞는지, 빠진 축이 없는지 볼 때
전체 작성 전 샘플을 만든 직후: 톤과 방식이 맞는지 확인할 때
긴 초안을 절반쯤 쓴 시점: 논리가 흐트러지지 않았는지 점검할 때
대화가 길어져 기준이 흐려질 때: 무엇을 하기로 했는지 다시 정렬할 때
반대로 아주 짧고 가벼운 작업은 모든 단계에서 점검할 필요가 없다. 문제는 길고 복잡한 작업이다. 글쓰기, 보고서, 기획, 분석, 학습 정리, 코드 설계 같은 작업은 초반의 작은 오해가 뒤로 갈수록 커지기 쉽다. 이런 작업일수록 중간 점검이 큰 효과를 낸다.
좋은 기준은 이것이다. "여기서 한 번 틀리면 뒤에서 많이 다시 해야 하나?" 그렇다면 그 지점은 점검 지점이다.
막연한 질문보다 체크리스트형 질문이 낫다
중간 점검을 실패하게 만드는 대표적인 질문은 이것이다.
"이거 괜찮아?"
이 질문은 너무 넓다. AI는 대체로 무난하고 안전한 대답을 하게 된다. "전반적으로 괜찮지만 조금 더 다듬을 수 있습니다" 같은 답이 나오기 쉽다. 그 말은 틀리진 않지만 별로 도움이 되지 않는다.
더 좋은 방법은 점검 기준을 먼저 주는 것이다. 예를 들어 글쓰기라면 다음처럼 물을 수 있다.
이 초안을 초보 독자 기준으로 검토해 줘.
첫 두 단락 안에 핵심 메시지가 분명한지,
전문 용어 설명이 충분한지,
실전 행동 단계가 보이는지,
같은 말의 반복이 있는지 점검해 줘.
각 항목마다 문제가 있으면 구체적인 문장 수준이 아니라 내용 수준에서 먼저 지적해 줘.
보고서라면 이런 식이 좋다.
이 메모가 의사결정자에게 필요한 정보를 주는지 점검해 줘.
핵심 결론, 근거, 리스크, 다음 액션이 각각 보이는지 확인하고, 빠진 항목이 있으면 우선순위대로 알려 줘.
학습용 정리라면 이렇게 바꿀 수 있다.
내가 정리한 설명에서 개념 혼동이 있는지 봐 줘.
특히 정의, 예외, 자주 헷갈리는 부분을 중심으로 틀린 가능성이 있는 문장을 표시해 줘.
핵심은 같다. 중간 점검은 감상형 질문이 아니라 검사형 질문이어야 한다.
중간 점검에서 꼭 받아야 하는 세 가지 답
AI에게 점검을 시킬 때는 세 가지를 꼭 받아 두는 편이 좋다. 첫째는 무엇이 맞는지, 둘째는 무엇이 문제인지, 셋째는 다음에 무엇을 할지다.
문제만 받아서는 안 된다. 무엇이 이미 괜찮은지도 알아야 쓸데없이 다시 쓰지 않는다. 예를 들어 구조는 맞고 사례만 부족하다면, 구조까지 뜯어고칠 필요는 없다. 반대로 장점만 받아서도 안 된다. 그건 위로는 되지만 수정에는 약하다. 마지막으로 다음 행동 제안이 없으면, 점검 뒤에 다시 우왕좌왕하기 쉽다.
그래서 이런 형식이 실전에서 잘 먹힌다.
다음 형식으로 답해 줘.
유지할 점
수정할 점
빠진 점
다음 턴에서 할 일
이 구조는 아주 단순하지만 강력하다. 유지할 점은 쓸데없는 재작업을 줄여 주고, 수정할 점은 문제를 선명하게 만들고, 빠진 점은 누락을 메우게 하고, 다음 턴에서 할 일은 작업을 앞으로 밀어 준다.
AI의 자기 점검은 만능이 아니다
여기서 한 가지는 분명히 알아야 한다. AI가 자기 작업을 점검하게 한다고 해서, 그것이 곧 진실 판정이 되는 것은 아니다. AI는 자기 모순을 발견할 때도 있지만, 틀린 내용을 그럴듯하게 정당화할 수도 있다. 특히 사실 검증이 필요한 작업에서는 자기 점검만 믿으면 위험하다.
그래서 중간 점검의 결과는 최종 판결문이 아니라 의심 목록으로 받아들이는 편이 좋다. 다시 말해, "여기가 틀렸다"보다 "여기가 틀릴 가능성이 있다"라는 식으로 다루는 것이 안전하다.
실전에서는 다음처럼 물으면 좋다.
확실한 문제와 불확실한 의심 지점을 구분해 줘.
확실하지 않은 부분은 단정하지 말고, 어떤 점이 불확실한지 이유를 적어 줘.
이렇게 하면 AI가 과하게 자신만만하게 말하는 위험을 조금 줄일 수 있다. 특히 숫자, 법률, 최신 정보, 전문 지식처럼 정확성이 중요한 영역에서는 점검 결과를 바로 믿기보다, 사람이 다시 확인하거나 별도 검증 단계로 넘기는 것이 좋다.
즉, 중간 점검은 오류를 줄이는 강력한 방법이지만, 오류를 영원히 없애는 마법은 아니다.
실전 예시: 초안이 끝나기 전에 방향을 바로잡는 과정
한 번 실제 흐름으로 보자. 당신이 "팀장이 바로 써먹을 수 있는 회의 운영 가이드"라는 글을 AI와 함께 쓰고 있다고 해 보자.
먼저 개요를 잡고, 도입부와 본문 일부를 받았다. 문장은 매끈하다. 얼핏 보면 괜찮다. 하지만 여기서 멈추지 않고 중간 점검을 시킨다.
지금까지 쓴 초안을 검토해 줘.
독자는 바쁜 팀장이고, 목적은 회의를 더 짧고 명확하게 운영하게 돕는 것이다.
다음 항목으로 점검해 줘:
실전성이 충분한가
추상적인 조언이 많은가
회의 전-중-후의 흐름이 보이는가
읽고 바로 행동할 수 있는 수준인가
각 항목의 문제를 지적하고, 다음 수정 우선순위를 제안해 줘.
이때 AI가 이런 식으로 답할 수 있다. "실전성은 있으나 행동 단계가 부족하다", "좋은 회의를 해야 한다 같은 추상 표현이 있다", "회의 전-중-후 구조가 분명하지 않다", "체크리스트가 없어 바로 실행하기 어렵다."
이제 중요한 것은, 이 답을 받은 뒤 곧바로 다시 전체 글을 길게 쓰게 하지 않는 것이다. 먼저 방향을 재정렬한다.
좋다. 그럼 전체 글의 구조를 회의 전-중-후로 재편해 줘.
추상 조언은 줄이고, 각 단계마다 팀장이 바로 할 수 있는 행동을 3개씩 넣어 줘.
그리고 체크리스트 박스를 넣을 위치도 표시해 줘.
이 한 번의 중간 점검으로 무엇이 달라졌을까. 끝까지 다 쓴 뒤에 "실용성이 약하네"라고 느끼는 대신, 초반에 구조 자체를 다시 잡았다. 방향이 틀린 채 2천 자를 더 쓰는 일을 막은 것이다. 바로 이것이 중간 점검의 힘이다.
중간 점검을 잘하는 사람은 '요약'을 먼저 시킨다
실전 고수들이 자주 쓰는 아주 강한 기술이 하나 있다. 바로 점검 전에 요약을 시키는 것이다. 대화가 몇 턴 쌓였을 때, AI에게 지금까지의 합의와 현재 상태를 먼저 정리하게 하는 것이다.
이유는 간단하다. 많은 오류는 실제 작업 자체보다, 우리가 지금 무엇을 하기로 했는지 서로 다르게 이해하는 데서 생긴다. 사용자는 이미 결정했다고 생각하는데, AI는 아직 후보 중 하나라고 받아들였을 수 있다. 사용자는 독자 수준을 초보라고 생각하는데, AI는 중급자로 쓰고 있을 수 있다.
그래서 중간 점검을 시작할 때 이렇게 말하면 좋다.
먼저 지금까지의 작업 상태를 요약해 줘.
우리의 목표, 독자, 형식, 반드시 포함할 항목, 아직 결정되지 않은 항목을 구분해서 정리해 줘.
이렇게 받은 요약을 보면 엇나간 지점이 빨리 드러난다. 만약 요약이 이미 틀려 있다면, 그 뒤의 초안도 흔들릴 가능성이 높다. 반대로 요약이 정확하면, 그다음 점검도 훨씬 정밀해진다.
즉, 요약은 단순한 정리가 아니다. 중간 점검의 기준판을 다시 세우는 일이다.
중간 점검은 대화를 끊는 것이 아니라, 일을 앞으로 보내는 것이다
어떤 사람은 중간 점검을 하면 흐름이 끊긴다고 느낀다. 계속 써 내려가는 편이 더 생산적으로 보인다는 것이다. 하지만 실제로는 반대인 경우가 많다. 중간 점검 없이 길게 달리는 작업은 겉으로만 빨라 보이고, 뒤에서 재작업 비용이 커진다.
중간 점검은 브레이크처럼 보이지만, 사실은 핸들에 더 가깝다. 속도를 줄이기 위한 장치라기보다, 방향을 바로잡기 위한 장치다. 자동차가 아무리 빨라도 핸들이 없으면 위험하듯, AI 작업도 아무리 생산적이어 보여도 중간 점검이 없으면 끝에 가서 크게 빗나갈 수 있다.
특히 AI에게 일을 길게 맡길수록, 사용자는 더 자주 "계속"이라고 말하고 싶어진다. 그럴 때 한 번쯤 멈춰서 물어야 한다.
"지금까지는 잘 가고 있는가?"
그리고 거기서 한 걸음 더 나아가야 한다.
"무엇이 잘 가고 있고, 무엇이 틀릴 가능성이 있으며, 다음에는 무엇을 고쳐야 하는가?"
이 질문을 던질 수 있으면, AI와의 대화는 단순한 연속 출력이 아니라 관리되는 작업 흐름이 된다.
바로 써먹는 중간 점검 템플릿
처음에는 아래 템플릿 하나만 기억해도 충분하다.
지금까지 만든 결과를 중간 점검해 줘.
먼저 현재 상태를 짧게 요약하고,
그다음 목표, 독자, 형식, 필수 항목 기준으로 맞는 점과 어긋난 점을 구분해 줘.
문제는 방향 문제, 내용 문제, 형식 문제, 누락 문제로 나눠서 적어 줘.
마지막으로 다음 턴에서 수정할 우선순위 3가지를 제안해 줘.
이 템플릿의 장점은 범용적이라는 것이다. 글쓰기에도 쓸 수 있고, 보고서에도 쓸 수 있고, 학습 정리나 발표안, 심지어 코드 설명 문서에도 응용할 수 있다. 작업이 다르더라도 점검의 기본 원리는 같다. 지금 상태를 요약하고, 기준과 비교하고, 문제를 나누고, 다음 행동을 정하는 것이다.
이 장의 정리
AI에게 중간 점검을 시킨다는 것은 단순히 "한번 봐 줘"라고 말하는 일이 아니다. 현재 상태를 요약하게 하고, 기준과 비교하게 하고, 문제를 드러내게 하고, 다음 행동까지 제안하게 만드는 운영 방식이다.
좋은 중간 점검이 있으면 끝에 가서 망하는 대신, 중간에 틀린 방향을 바로잡을 수 있다. 개요 단계에서 구조를 고치고, 샘플 단계에서 톤을 고치고, 초안 절반쯤에서 논리를 고치면, 마지막 작업은 훨씬 가볍고 단단해진다.
결국 AI를 잘 쓴다는 것은 많이 시키는 것이 아니라, 적절한 순간에 멈춰 세울 줄 아는 것이기도 하다. 계속 앞으로만 가게 두지 말고, 때로는 돌아보게 하라. 그 한 번의 중간 점검이, 마지막의 큰 실패를 막아 준다.
다음 장에서는 이 흐름을 더 발전시켜, 대화를 이어 갈수록 품질을 어떻게 높일 수 있는지 살펴보겠다. 한 번 잘 묻는 것보다, 여러 턴을 거치며 점점 더 나아지게 만드는 운영법이 그다음 핵심이 된다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.