25. 자기 비판과 자기 수정 유도

초안을 스스로 고치게 하기

사람은 글을 쓰고 다시 읽으며 고칩니다. 모델에게도 비슷하게, 초안을 낸 뒤 스스로 비판하고 개선하게 할 수 있습니다. 24장의 체이닝에서 "마지막 검토 단계"로 자주 쓰이며, 잘 쓰면 품질이 오릅니다. 다만 4부에서 거듭 경고했듯, 이 기법에는 분명한 한계가 있어 언제 통하고 언제 못 미더운지를 아는 게 중요합니다.

기본 형태 — 생성 후 비판

✅
"1단계: 요청에 대한 초안을 작성해.
 2단계: 그 초안을 비판적으로 검토해 약점 3가지를 찾아.
 3단계: 약점을 반영해 개선본을 작성해."

생성과 비판을 명시적으로 분리하는 것이 핵심입니다. 한 번에 "잘 써줘"보다, 일단 쓰고 → 거리를 두고 보고 → 고치는 흐름이 더 효과적인 경향이 있습니다.

📌 핵심: 자기 비판의 힘은 "거리 두기"에서 옵니다. 막 생성한 답을 검토 대상으로 다시 제시하면, 모델이 생성 모드가 아닌 평가 모드로 그것을 보게 됩니다.

비판에 기준을 준다

막연히 "검토해"보다, 무엇을 기준으로 검토할지 주면 훨씬 유용합니다(20장 검증 가능성과 연결).

✅
"다음 기준으로 초안을 점검해줘:
 - 사실 주장에 근거가 있는가
 - 요청한 형식·분량을 지켰는가
 - 모호하거나 빠진 부분은 없는가
각 기준마다 문제를 찾고, 없으면 '이상 없음'으로."

💡 팁: 체크리스트형 자기 비판은 23장의 평가 지표를 그대로 가져다 쓸 수 있습니다. "평가 기준 = 자기 비판 기준"으로 통일하면, 모델의 자기 점검이 당신의 평가와 같은 잣대를 쓰게 됩니다.

가장 중요한 한계 — 자기 환각 재확인

4부에서 반복한 경고를 다시, 그러나 더 깊이. 자기 비판의 근본 약점은 같은 모델이 같은 맥락에서 자기 답을 본다는 데 있습니다. 답을 만들 때 놓친 것을, 검토할 때도 같은 이유로 놓치기 쉽습니다. 틀린 전제 위에서 점검하면, 그 전제 자체는 의심하지 못합니다.

⚠️ 흔한 실수·미신: "모델에게 검토시켰으니 이제 믿어도 된다"는 과신입니다. 자기 비판은 명백한 실수(형식 위반, 빠진 항목, 내부 모순)를 잡는 데는 쓸 만하지만, 모델이 확신을 갖고 틀린 부분(자신 있는 환각)은 자기 검토로 잘 안 잡힙니다. 같은 맹점을 두 번 지나가는 셈이니까요.

🧪 직접 검증법: 자기 비판이 실제로 도움이 되는지 보려면, (a) 비판 단계 없는 버전과 (b) 있는 버전을 평가 세트(23장)로 비교하세요. 작업에 따라 (b)가 분명히 낫기도, 별 차이 없기도 합니다. 특히 사실성보다 형식·완결성·논리 일관성 작업에서 자기 비판이 더 잘 듣는 경향을 직접 확인해보세요.

한계를 넘는 법 — 관점·맥락 분리

자기 환각 문제를 완화하려면, 검토를 더 독립적으로 만드세요.

방법 1: 다른 관점/역할로 검토

생성할 때와 다른 역할을 부여해 검토하게 하면, 같은 맹점에 덜 갇힙니다(6장 다관점 검토와 연결).

✅
생성: "마케터로서 이 카피를 써줘."
검토: "이제 회의적인 소비자 입장에서, 이 카피의 과장·허점을 짚어줘."

방법 2: 깨끗한 맥락에서 검토

15장의 격리를 적용합니다. 초안만 새 맥락에 떼어 주고 "이 글을 평가해줘"라고 하면, 생성 과정의 합리화가 따라오지 않아 더 냉정한 검토가 됩니다.

방법 3: 다른 모델/사람으로 검토

가장 독립적인 검토는 다른 주체에서 옵니다. 다른 모델로 교차 검토하거나, 위험이 큰 작업은 사람이 봅니다. 23장 개발자 노트의 LLM-as-judge가 이 방법의 자동화 형태입니다.

flowchart TB
    draft["초안 생성"] --> w["약함: 같은 맥락 자기검토<br/>(명백한 실수만)"]
    draft --> m["중간: 다른 역할 / 깨끗한 맥락<br/>(맹점 일부 완화)"]
    draft --> s["강함: 다른 모델 / 사람<br/>(독립적 검토)"]

    classDef weak fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
    classDef mid fill:#fef9c3,stroke:#eab308,color:#713f12
    classDef strong fill:#dcfce7,stroke:#22c55e,color:#14532d
    class w weak
    class m mid
    class s strong

자기 수정의 또 다른 함정 — 과잉 수정

자기 비판을 시키면, 멀쩡한 부분까지 불필요하게 바꾸는 경우가 있습니다. "비판하라"는 지시가 "문제를 찾아야 한다"는 압력으로 작용해, 없는 문제를 만들어내기도 합니다.

💡 팁: "문제가 없으면 그대로 두라"를 명시하세요. "개선이 필요 없으면 '수정 불필요'라고 답하고 원본을 유지해"를 덧붙이면, 변화를 위한 변화를 줄일 수 있습니다.

이 장에서 배운 것

• 자기 비판은 초안을 낸 뒤 스스로 점검·개선하게 하는 기법으로, 생성과 비판을 명시적으로 분리할 때 효과적이다.
• 막연한 검토보다 기준(사실 근거·형식·완결성 등)을 주면 유용하며, 23장 평가 기준과 통일하면 좋다.
• 근본 한계는 같은 모델이 같은 맥락에서 보므로 자기 환각을 재확인할 수 있다는 것이다. 명백한 실수는 잡지만 자신 있는 환각은 놓친다.
• 한계 완화: 다른 역할로 검토, 깨끗한 맥락에서 검토, 가장 강하게는 다른 모델·사람으로 검토.
• 자기 비판은 과잉 수정을 유발할 수 있으니 "문제 없으면 그대로 두라"를 명시한다.

✍️ 확인 문제

1. "모델에게 자기 답을 검토시켰으니 사실 오류는 다 잡혔을 것"이라는 가정의 문제를, 이 장의 "같은 맥락·같은 맹점" 개념으로 반박해보세요.

1. 사실성이 중요한 작업과 형식·완결성이 중요한 작업 중, 자기 비판이 상대적으로 더 잘 듣는 쪽은 어디일지 추론하고 이유를 적어보세요.

1. (실습) 블로그 초안을 자기 비판으로 개선하되, 자기 환각 재확인 문제를 완화하도록 "관점 분리"를 적용한 2단계 프롬프트를 설계해보세요.

다음 → 26. 검색·도구와 결합하기 (RAG·도구 사용)
이전 ← 24. 프롬프트 체이닝과 분해 · 목차