AI 답변의 품질을 끌어올리는 반복 루프

AI의 첫 답변은 완성본이 아니라 초안이다

AI를 처음 쓰는 사람은 대개 이런 기대를 합니다. "내가 원하는 걸 한 번에 말하면, AI가 완성본을 딱 내놓겠지."

하지만 실제 업무에서는 그렇게 되는 경우가 많지 않습니다. AI는 꽤 그럴듯한 초안을 빠르게 만들지만, 그 초안에는 빠진 내용이 있고, 논리의 점프가 있고, 독자에게 맞지 않는 표현이 있으며, 때로는 확인되지 않은 숫자나 출처가 섞여 있습니다. 그래서 AI 활용의 핵심은 "한 번에 잘 쓰는 프롬프트"가 아니라 나쁜 초안을 좋은 결과물로 끌어올리는 반복 과정입니다.

이 장에서 다룰 방법은 단순합니다.

초안 → 비판 → 개선 → 검증.

이 네 단계를 기억하면 이메일, 보고서, 기획안, 강의안, 콘텐츠, 코드 설명, 리서치 요약까지 대부분의 AI 작업 품질이 눈에 띄게 올라갑니다. AI는 한 번에 정답을 주는 마법 상자가 아닙니다. 반복할수록 선명해지는 작업 파트너입니다.

한 번에 완성하려는 순간 품질이 떨어진다

AI에게 "이 주제로 보고서 써줘"라고 요청하면 결과가 나옵니다. 문장도 매끄럽고, 구조도 있어 보입니다. 문제는 바로 그 점입니다. 너무 빨리 완성본처럼 보인다는 것입니다.

사람이 초안을 쓰면 빈틈이 눈에 보입니다. 문장이 어색하고, 구성도 덜 다듬어져 있고, 아직 조사해야 할 부분도 티가 납니다. 그런데 AI가 만든 글은 처음부터 제법 완성된 표정을 하고 나타납니다. 그래서 사용자는 검토를 건너뛰기 쉽습니다. "이 정도면 괜찮겠지" 하고 복사해 붙여넣습니다. 그 순간 AI는 도구가 아니라 위험 요소가 됩니다.

좋은 AI 활용자는 첫 답변을 완성본으로 보지 않습니다. 첫 답변은 어디까지나 재료입니다. 마치 신입 직원에게 "일단 초안 만들어봐"라고 시킨 것과 같습니다. 신입 직원이 가져온 초안을 그대로 고객에게 보내지 않듯, AI의 첫 답변도 바로 제출하면 안 됩니다.

초안의 역할은 빠르게 출발선을 만드는 것입니다. 빈 문서를 앞에 두고 고민하는 시간을 줄여 주고, 가능한 방향을 보여 주는 것. 하지만 방향이 맞는지, 빠진 것은 없는지, 표현이 과한지, 근거가 있는지는 다음 단계에서 따져야 합니다.

업무에서 AI 결과물을 다룰 때는 이렇게 생각하는 편이 안전합니다.

"AI가 답을 줬다"가 아니라, "검토할 초안이 생겼다."

이 관점 하나만 바뀌어도 AI 활용 방식은 달라집니다.

초안은 빠르게, 판단은 천천히

반복 루프의 첫 단계는 초안 생성입니다. 여기서 중요한 원칙은 완벽을 요구하지 않는 것입니다. 처음부터 "최종본 수준으로 완벽하게 작성해줘"라고 하면 AI는 그럴듯한 완성본을 만들려고 애씁니다. 그러면 오히려 빈틈이 숨습니다.

초안 단계에서는 이렇게 요청하는 것이 좋습니다.

아래 목적과 자료를 바탕으로 1차 초안을 작성해줘. 완벽하지 않아도 좋으니 핵심 구조와 주요 논점을 빠르게 잡아줘. 불확실한 부분은 단정하지 말고 [확인 필요]로 표시해줘.

이 요청에는 중요한 장치가 들어 있습니다. "완벽하지 않아도 좋다"는 말은 AI에게 초안의 역할을 알려 줍니다. "불확실한 부분은 표시하라"는 말은 그럴듯한 추측을 줄이는 안전장치입니다.

예를 들어 고객에게 보낼 사과 이메일을 써야 한다고 해봅시다. 처음부터 완벽한 문장을 요구하기보다 먼저 상황을 정리하게 합니다.

고객 배송 지연에 대한 사과 이메일 초안을 작성해줘.
상황: 주문 상품 배송이 기존 안내보다 3일 늦어짐.
목적: 고객 불만을 낮추고, 현재 조치 상황을 설명하며, 재발 방지 의지를 전달하는 것.
톤: 책임 회피처럼 보이지 않게, 정중하고 간결하게.
포함할 내용: 사과, 지연 사유, 현재 배송 예정일, 보상 쿠폰 안내, 문의 채널.

이렇게 하면 AI는 일단 형태를 잡아 줍니다. 하지만 이 단계에서 멈추면 안 됩니다. 사과가 충분한지, 변명처럼 들리지는 않는지, 보상 안내가 과장되지는 않았는지, 고객이 궁금해할 정보가 빠지지는 않았는지 따져야 합니다.

보고서도 마찬가지입니다. "시장 조사 보고서 써줘"가 아니라 먼저 1차 구조를 만들게 합니다.

중소형 카페를 위한 구독형 원두 납품 서비스 시장 조사 보고서의 1차 초안을 작성해줘.
독자는 내부 신규사업팀이다.
포함할 내용은 시장 배경, 고객 문제, 경쟁 대안, 기회 요인, 리스크, 추가 조사 필요 항목이다.
숫자나 시장 규모는 확인되지 않으면 임의로 쓰지 말고 [자료 필요]로 표시해줘.

초안 단계에서 가장 중요한 것은 속도입니다. 판단은 그다음입니다.

비판 단계를 분리하라

많은 사람이 AI에게 "잘 써줘"라고 요청합니다. 그러나 "잘"이라는 말은 너무 흐립니다. 누구에게 잘 읽혀야 하는지, 어떤 기준으로 좋은지, 무엇을 피해야 하는지 알 수 없습니다.

그래서 두 번째 단계에서는 AI에게 작성자가 아니라 비판자 역할을 맡겨야 합니다. 이때 핵심은 초안을 고치라고 바로 말하지 않는 것입니다. 먼저 문제를 찾아내게 해야 합니다. 작성과 비판을 한 번에 시키면 AI는 자기가 쓴 답을 스스로 좋게 포장하는 경향이 있습니다. 반대로 비판만 시키면 더 냉정하게 빈틈을 찾습니다.

다음과 같이 요청해 볼 수 있습니다.

아래 초안을 수정하지 말고 먼저 비판해줘.
다음 기준으로 문제점을 찾아줘.

1. 독자가 궁금해할 내용 중 빠진 것

2. 논리적으로 모순되거나 연결이 약한 부분

3. 과장되거나 근거가 부족한 주장

4. 독자에게 불쾌하거나 부담스럽게 들릴 표현

5. 더 구체화해야 할 부분
   각 항목마다 문제 위치와 수정 방향을 함께 제안해줘.

여기서 "수정하지 말고 먼저 비판해줘"가 중요합니다. 사람도 회의에서 바로 결론을 내리기보다 문제를 먼저 나열하면 더 좋은 판단을 합니다. AI도 마찬가지입니다. 단계를 나누면 결과가 좋아집니다.

기획안의 경우에는 비판 기준을 더 날카롭게 만들 수 있습니다.

아래 신규 서비스 기획안을 투자 심사역의 관점에서 비판해줘.
특히 시장성, 차별성, 수익 모델, 실행 가능성, 리스크 대응이 약한 부분을 찾아줘.
좋은 점을 칭찬하기보다, 이 기획안이 거절될 만한 이유를 중심으로 분석해줘.

이 요청은 AI를 응원단이 아니라 심사위원으로 바꿉니다. AI는 기본적으로 사용자의 의도에 맞춰 협조적으로 답하려는 경향이 있습니다. 그래서 일부러 "거절될 만한 이유"를 찾게 해야 합니다.

보고서 초안을 점검할 때는 이렇게 물을 수 있습니다.

이 보고서를 상사가 읽는다고 가정하고 비판해줘.
상사가 "그래서 결론이 뭐야?", "근거가 어디 있어?", "이걸 왜 지금 해야 해?"라고 물을 만한 지점을 찾아줘.

이런 질문은 실제 업무 현장의 압박을 AI에게 옮겨 놓는 방식입니다. 좋은 비판 프롬프트는 AI에게 역할을 주는 데서 끝나지 않습니다. 어떤 의심을 해야 하는지까지 알려 줍니다.

개선은 비판 목록을 기준으로 진행한다

비판을 받았다면 이제 개선 단계입니다. 이때도 그냥 "반영해서 다시 써줘"라고 하면 아쉬운 결과가 나올 수 있습니다. 비판 목록 중 무엇을 반영하고 무엇을 반영하지 않을지 선택해야 하기 때문입니다.

AI가 제안한 비판이 모두 맞는 것은 아닙니다. 때로는 필요 이상으로 장황하게 만들고, 때로는 원래 의도와 다른 방향을 제안합니다. 따라서 개선 단계에서는 먼저 비판 목록을 선별합니다.

예를 들어 AI가 사과 이메일에 대해 "보상 내용을 더 강조하라"고 제안했다고 해봅시다. 하지만 회사 정책상 보상은 보조 안내일 뿐이고, 핵심은 사과와 재발 방지입니다. 그렇다면 이렇게 지시합니다.

위 비판 중 1, 2, 4번은 반영하고, 3번의 보상 강조 제안은 반영하지 마. 보상은 한 문장으로만 안내해줘. 전체 톤은 더 책임감 있게 바꾸되, 지나치게 비굴한 표현은 피해서 수정본을 작성해줘.

이렇게 하면 AI는 사용자의 판단을 기준으로 움직입니다. AI가 운전대를 잡는 것이 아니라, 사용자가 방향을 정하고 AI가 속도를 내는 구조입니다.

보고서 개선도 마찬가지입니다.

비판 목록을 반영해 보고서를 다시 작성해줘.
단, 시장 규모 수치는 아직 확인하지 않았으므로 넣지 마.
대신 "추가 확인이 필요한 지표" 섹션을 만들고, 확인해야 할 자료 목록을 정리해줘.
결론은 실행 제안 중심으로 더 분명하게 써줘.

여기서 중요한 점은 개선을 "문장 다듬기"로만 보지 않는 것입니다. 개선은 구조, 논리, 정보의 밀도, 독자 적합성, 실행 가능성을 함께 높이는 과정입니다. AI에게 문장만 예쁘게 만들게 하면 보기 좋은 빈 문서가 됩니다. 반대로 비판 목록을 기준으로 개선하게 하면 실제로 쓸 수 있는 문서에 가까워집니다.

검증은 AI 밖에서 끝내야 한다

반복 루프의 마지막 단계는 검증입니다. 여기서 많은 사람이 실수합니다. AI에게 "이 내용이 맞는지 확인해줘"라고 묻고, AI가 "네, 대체로 맞습니다"라고 답하면 안심합니다. 하지만 이것은 진짜 검증이 아닙니다.

AI의 자기검토는 유용합니다. 누락된 항목을 찾거나, 앞뒤가 맞지 않는 문장을 발견하거나, 근거가 약한 주장을 표시하는 데 도움이 됩니다. 하지만 AI가 스스로 "맞다"고 말하는 것을 최종 확인으로 받아들이면 위험합니다.

소프트웨어 검증 연구에서도 비슷한 한계가 드러납니다. ChatGPT가 프로그램 검증에 필요한 단서나 유용한 설명을 제안할 수는 있지만, 그 자체만으로 신뢰할 만한 검증자가 되기에는 아직 한계가 있다는 점이 확인되었습니다.¹ 쉽게 말해 AI는 "검토를 도와주는 조수"가 될 수는 있지만, "최종 책임을 지는 검사관"으로 두기에는 부족합니다.

따라서 검증 단계에서는 AI에게 이렇게 요청하는 것이 좋습니다.

아래 문서를 최종 검증하기 전에 점검 목록을 만들어줘.
특히 사실 확인이 필요한 주장, 계산이 필요한 숫자, 출처가 필요한 문장, 법적·정책적으로 민감한 표현을 분리해서 표시해줘.
네가 직접 사실이라고 단정하지 말고, 사람이 확인해야 할 항목으로 정리해줘.

이 요청의 목적은 AI에게 최종 판정을 맡기는 것이 아니라, 사람이 확인할 대상을 뽑아내게 하는 것입니다. 검증의 주체는 사람입니다. AI는 체크리스트를 만드는 보조자입니다.

검증할 때는 답변을 세 부분으로 나누어 보아야 합니다.

• 원문 검증: 인용문, 요약, 주장 해석이 원자료와 맞는지 확인한다.

• 계산 검증: 비율, 합계, 증감률, 평균 등 숫자를 직접 다시 계산한다.

• 출처 검증: URL, 문서명, 발행 기관, 날짜, 페이지 등 확인 가능한 근거가 있는지 본다.

특히 숫자는 반드시 따로 확인해야 합니다. AI가 "전년 대비 23% 증가"라고 썼다면 계산식을 물어보고, 원자료 숫자로 직접 다시 계산해야 합니다. 출처도 마찬가지입니다. AI가 제시한 링크가 실제로 존재하는지, 그 링크에 해당 내용이 있는지, 문서의 발행일이 맞는지 확인해야 합니다.

검증은 귀찮습니다. 하지만 검증 없는 AI 활용은 빠른 것이 아니라 불안정한 것입니다.

좋은 예시와 나쁜 예시를 함께 주면 기준이 생긴다

AI에게 품질을 가르치는 가장 좋은 방법 중 하나는 예시를 주는 것입니다. 그런데 많은 사람이 좋은 예시만 줍니다. 물론 좋은 예시는 중요합니다. 하지만 실제로는 나쁜 예시도 함께 줘야 AI가 피해야 할 선을 더 잘 이해합니다.

예를 들어 뉴스레터 도입부를 쓰고 싶다고 해봅시다. 그냥 "흥미롭게 써줘"라고 하면 AI는 흔한 문장을 꺼낼 가능성이 큽니다. "오늘날 빠르게 변화하는 시대에…" 같은 문장 말입니다. 이런 표현은 틀리지는 않지만 너무 낡았습니다.

이럴 때는 이렇게 지시합니다.

아래 기준에 맞춰 뉴스레터 도입부를 작성해줘.
좋은 예시의 특징은 따라가고, 나쁜 예시의 표현은 피해야 해.

좋은 예시: "회의가 끝났는데도 아무 일도 시작되지 않는 날이 있다. 모두가 고개를 끄덕였지만, 정작 누가 무엇을 할지는 정해지지 않았기 때문이다."
특징: 구체적인 장면에서 시작한다. 독자가 겪어본 상황을 떠올리게 한다. 추상어를 남발하지 않는다.

나쁜 예시: "현대 비즈니스 환경은 빠르게 변화하고 있으며, 효율적인 커뮤니케이션은 그 어느 때보다 중요해졌습니다."
피해야 할 점: 뻔한 시대 진단, 추상적인 표현, 누구에게나 적용되는 일반론.

이렇게 하면 AI는 "흥미롭게"라는 모호한 말을 구체적인 기준으로 이해합니다. 좋은 예시는 따라야 할 방향을 보여 주고, 나쁜 예시는 피해야 할 함정을 보여 줍니다.

보고서 문체에도 같은 방법을 쓸 수 있습니다.

좋은 문장: "이번 분기 이탈률 증가는 가격 인상 자체보다, 가격 인상 전에 충분한 안내가 없었다는 불만과 더 관련이 크다."
나쁜 문장: "고객 경험 전반에 대한 총체적 개선이 필요한 것으로 사료됩니다."
기준: 원인을 분명히 말할 것. 책임을 흐리는 표현을 피할 것. 추상어보다 관찰된 사실을 쓸 것.

AI는 언어 패턴에 민감합니다. 그러므로 "이런 느낌"이라고 말하기보다 실제 예문을 보여 주면 결과가 달라집니다. 더 좋은 방법은 좋은 예시와 나쁜 예시를 나란히 놓고, 차이를 설명하는 것입니다. 그러면 AI는 문장뿐 아니라 판단 기준까지 배웁니다.

AI에게 스스로 점검하게 하되, 믿지는 말라

AI 자기검토는 분명 쓸모가 있습니다. 초안을 만든 뒤 "네 답변의 약점을 찾아줘"라고 하면 꽤 많은 문제를 짚어냅니다. 특히 누락, 반복, 모순, 독자 불일치 같은 문제를 찾는 데 유용합니다.

하지만 자기검토에는 한계가 있습니다. AI는 자신이 만든 답변의 근거를 실제로 확인하지 않고도 그럴듯하게 설명할 수 있습니다. 심지어 앞에서는 맞다고 한 내용을 뒤에서는 틀렸다고 말할 수도 있습니다. 코드 생성과 검증 영역에서도 AI가 잘못된 코드를 맞다고 판단하거나, 취약한 코드를 안전하다고 설명하는 문제가 지적되어 왔습니다.²

그러므로 자기검토 프롬프트는 이렇게 써야 합니다.

아래 답변을 스스로 평가해줘.
단, "전체적으로 좋다" 같은 총평은 하지 마.
누락된 정보, 모순된 주장, 근거가 부족한 문장, 반례가 가능한 결론만 찾아줘.
각 문제마다 심각도를 상·중·하로 표시하고, 사람이 확인해야 할 항목을 따로 분리해줘.

이 요청은 AI의 자기검토를 칭찬 모드가 아니라 점검 모드로 바꿉니다.

또 다른 좋은 방법은 반대 질문을 던지는 것입니다.

이 결론이 틀렸을 가능성을 제기해줘.
어떤 조건에서는 이 주장이 성립하지 않을 수 있는지 반례를 들어줘.
이 문서를 비판적으로 읽는 사람이 공격할 만한 지점을 찾아줘.

AI를 잘 쓰는 사람은 AI에게 동의를 구하지 않습니다. 반대를 시킵니다. 왜냐하면 업무 품질은 동의보다 반박을 통과할 때 올라가기 때문입니다.

그럴듯한 헛소리를 잡는 네 가지 분리법

AI 답변의 가장 위험한 점은 틀린 말이 어색하게 보이지 않는다는 것입니다. 문장은 자연스럽고, 구조는 깔끔하고, 말투는 자신 있습니다. 그래서 틀린 내용도 맞는 것처럼 보입니다. 이것을 흔히 환각, 즉 hallucination이라고 부릅니다. AI가 근거 없는 내용을 실제처럼 만들어내는 현상입니다.

그럴듯한 헛소리를 잡으려면 답변을 통째로 믿거나 통째로 의심해서는 안 됩니다. 분리해야 합니다.

첫째, 인용문과 요약을 분리합니다. AI가 어떤 보고서를 요약했다면, 요약 문장을 원문과 대조해야 합니다. 특히 "저자는 A라고 주장한다" 같은 문장은 조심해야 합니다. 원문은 A를 단정한 것이 아니라 가능성으로 언급했을 수 있습니다.

둘째, 숫자와 해석을 분리합니다. "매출이 10억 원에서 13억 원으로 증가했으므로 30% 성장했다"는 계산이 맞습니다. 하지만 "따라서 고객 충성도가 높아졌다"는 해석은 별도 근거가 필요합니다. 숫자가 맞아도 해석은 틀릴 수 있습니다.

셋째, 주장과 출처를 분리합니다. AI가 "최근 연구에 따르면"이라고 쓰면 반드시 어떤 연구인지 물어야 합니다. 연구명, 저자, 발행 연도, URL, 페이지를 요구해야 합니다. 출처를 대지 못하면 그 문장은 의견이나 가설로 낮춰야 합니다.

넷째, 결론과 반례를 분리합니다. 어떤 결론이든 반대 사례가 있습니다. "무료 체험을 제공하면 전환율이 높아진다"는 말은 대체로 그럴듯하지만, 제품 특성에 따라 무료 체험이 오히려 낮은 품질의 고객만 끌어들일 수도 있습니다. AI에게 반례를 묻는 습관은 결론을 단단하게 만듭니다.

검증 프롬프트는 다음처럼 쓸 수 있습니다.

아래 답변에서 검증이 필요한 문장을 모두 뽑아줘.
표로 정리하되, 열은 '문장', '검증 유형', '필요한 근거', '검증 방법', '위험도'로 구성해줘.
검증 유형은 원문 대조, 숫자 재계산, 출처 확인, 전문가 판단, 정책 확인 중 하나로 분류해줘.

이렇게 하면 AI 답변이 하나의 매끄러운 글에서 점검 가능한 항목 목록으로 바뀝니다. 글은 믿기 쉽지만, 목록은 검토하기 쉽습니다.

모델을 비교하지 말고 역할을 나눠라

ChatGPT, Claude, Gemini 중 무엇이 제일 좋은지 묻는 사람이 많습니다. 그러나 실전에서는 "최고의 모델 하나"를 고르는 것보다 "각 모델을 어떤 단계에 배치할 것인가"가 더 중요합니다.

예를 들어 하나의 기획안을 만든다고 해봅시다. ChatGPT로 빠르게 아이디어와 초안을 만들고, Claude로 긴 문서의 흐름과 문체를 점검하고, Gemini로 자료 기반 확인이나 표 정리를 보조하게 할 수 있습니다. 물론 이 역할은 고정된 정답이 아닙니다. 사용자의 업무, 구독 환경, 파일 형식, 조직 보안 정책에 따라 달라집니다.

중요한 것은 모델을 경쟁시키는 것이 아니라, 작업 흐름 안에서 역할을 나누는 것입니다.

예를 들어 다음과 같은 방식이 가능합니다.

• 초안 작성자: 빠르게 구조를 만들고 다양한 표현을 제안한다.

• 비판자: 누락, 모순, 과장, 독자 불일치를 찾아낸다.

• 검증 보조자: 출처 확인 항목, 계산 점검 항목, 표준 형식 위반을 정리한다.

Claude for Word처럼 문서 안에서 선택한 부분을 수정하고, 변경 사항을 추적해 사람이 수락하거나 거절할 수 있는 기능은 반복 편집 과정에 특히 잘 맞습니다. 중요한 것은 AI가 고친 내용을 그대로 받아들이는 것이 아니라, 추적된 변경 사항을 사람이 검토하는 구조입니다.³

Gemini API의 구조화된 출력 기능처럼 JSON Schema에 맞춰 답변 형식을 제한하는 방식도 검증에 도움이 됩니다. 자유로운 문장으로 답을 받으면 빠진 항목을 발견하기 어렵지만, 정해진 필드로 받으면 누락과 형식 오류를 더 쉽게 찾을 수 있습니다.⁴

다만 여러 모델이 같은 결론을 냈다고 해서 그 결론이 사실이 되는 것은 아닙니다. 모델들은 비슷한 데이터를 학습했고, 비슷한 방식으로 그럴듯한 답을 만들 수 있습니다. 세 명의 AI가 같은 착각을 할 수도 있습니다. 중요한 내용은 반드시 외부 자료와 사람의 판단으로 확인해야 합니다.

반복 루프를 업무에 적용하는 법

이제 네 단계 루프를 실제 업무에 적용해 봅시다.

먼저 이메일입니다. 고객 불만 대응 메일을 작성한다면 초안 단계에서는 상황과 목적을 알려 주고 빠르게 문안을 받습니다. 비판 단계에서는 고객 입장에서 무례하게 느껴질 표현, 책임 회피처럼 보이는 문장, 빠진 안내 사항을 찾게 합니다. 개선 단계에서는 비판 중 필요한 항목만 반영해 다시 쓰게 합니다. 검증 단계에서는 날짜, 보상 조건, 문의 링크, 회사 정책과 맞는지 확인합니다.

보고서라면 초안 단계에서 목차와 핵심 논지를 만들게 합니다. 비판 단계에서는 근거 부족, 결론의 모호함, 숫자 누락, 실행 방안의 비현실성을 점검합니다. 개선 단계에서는 결론을 앞쪽에 배치하거나 표를 추가하고, 필요 없는 배경 설명을 줄입니다. 검증 단계에서는 모든 수치와 출처를 원자료로 확인합니다.

기획안이라면 초안 단계에서 문제, 대상 고객, 해결책, 수익 모델, 실행 계획을 잡습니다. 비판 단계에서는 "이 기획이 실패할 이유"를 찾게 합니다. 개선 단계에서는 차별성과 리스크 대응을 강화합니다. 검증 단계에서는 시장 규모, 비용 가정, 일정, 법적 이슈를 따로 확인합니다.

이 흐름을 한 번의 대화 안에서 모두 처리할 수도 있지만, 중요한 작업이라면 단계를 나누는 편이 좋습니다. 같은 대화창에서 이어가더라도 단계마다 역할을 분명히 바꾸세요.

지금은 초안 단계야. 완성도보다 구조를 우선해.
지금은 비판 단계야. 수정하지 말고 문제만 찾아.
지금은 개선 단계야. 아래 비판 중 선택한 항목만 반영해.
지금은 검증 단계야. 사실이라고 단정하지 말고 확인할 항목을 뽑아.

이렇게 말하면 AI의 작업 모드가 달라집니다. 사람에게 일을 맡길 때도 "일단 아이디어만 내봐"와 "최종 보고용으로 다듬어줘"는 다른 지시입니다. AI에게도 똑같이 구분해 줘야 합니다.

반복 루프를 템플릿으로 저장하라

AI 활용이 업무 운영법이 되려면 좋은 방법을 매번 새로 떠올리면 안 됩니다. 반복 가능한 템플릿으로 만들어야 합니다.

다음은 대부분의 업무에 적용할 수 있는 기본 템플릿입니다.

목적: [무엇을 만들고 싶은지]
독자/사용자: [누가 읽거나 사용할 것인지]
맥락: [왜 필요한지, 현재 상황은 무엇인지]
자료: [참고할 내용]

1단계: 먼저 1차 초안을 작성해줘. 불확실한 내용은 [확인 필요]로 표시해줘.
2단계: 초안을 바로 수정하지 말고, 누락·모순·과장·근거 부족·독자 부적합 표현을 비판해줘.
3단계: 내가 선택한 비판 항목을 반영해 수정본을 작성해줘.
4단계: 최종 제출 전 사람이 확인해야 할 사실, 숫자, 출처, 정책 관련 항목을 체크리스트로 정리해줘.

이 템플릿은 간단하지만 강력합니다. AI가 제멋대로 완성본을 내놓는 흐름을 막고, 작업을 관리 가능한 단계로 바꿉니다.

팀에서 AI를 쓴다면 이 템플릿을 공통 양식으로 만들어도 좋습니다. 예를 들어 "보고서 AI 작성 프로세스", "고객 메일 AI 검토 프로세스", "콘텐츠 발행 전 AI 점검 프로세스"처럼 업무별로 저장해 두는 것입니다. 그러면 사람마다 제각각 AI를 쓰는 것이 아니라, 조직이 같은 품질 기준으로 AI를 사용할 수 있습니다.

AI 시대의 생산성은 프롬프트 한 줄에서 나오지 않습니다. 반복 가능한 절차에서 나옵니다.

완성도는 질문이 아니라 운영에서 나온다

AI 답변의 품질을 높이고 싶다면 더 멋진 표현의 프롬프트를 찾기보다 작업 방식을 바꿔야 합니다. 초안을 빠르게 만들고, 비판을 분리하고, 선택적으로 개선하고, 마지막에는 AI 밖에서 검증해야 합니다.

이 과정을 거치면 AI는 단순한 문장 생성기가 아닙니다. 초안 작성자이자, 비판자이자, 편집 보조자이자, 검증 체크리스트 작성자가 됩니다. 하지만 최종 판단자는 여전히 사람입니다.

좋은 AI 활용자는 AI에게 모든 것을 맡기지 않습니다. 대신 AI가 잘하는 일을 반복 구조 안에 배치합니다. 초안은 AI가 빠르게 만들게 하고, 비판은 더 날카롭게 시키고, 개선은 기준에 맞춰 진행하게 하고, 검증은 사람이 책임집니다.

AI가 일의 속도를 높인다면, 반복 루프는 일의 품질을 지킵니다.

그리고 이 둘이 만날 때, AI는 비로소 "답변하는 도구"를 넘어 "함께 일하는 파트너"가 됩니다.

참고

¹Can ChatGPT support software verification?

²ChatGPT's Code Checking: Unmasking the Illusion of AI Reliability

³Use Claude for Word

⁴Structured outputs | Gemini API