LLM 자가 수정의 배신: “다시 검토해줘”가 성능을 망치는 이유

프롬프트 엔지니어링을 연구하다 보면 누구나 한 번쯤 마주하는 ‘마법의 문장’이 있습니다. “네 답변이 맞는지 단계별로 다시 검토해줘. (Check your answer step-by-step.)”

우리는 흔히 인간의 사고방식을 AI에 투영합니다. 사람이 시간을 들여 자신의 답안지를 검토하면 실수를 잡아내듯, LLM도 스스로 되돌아보는 과정(Self-Correction)을 거치면 더 완벽해질 것이라는 믿음이죠.

하지만 구글 딥마인드(Google DeepMind)와 UIUC 연구진이 발표한 ICLR 2024 논문 <Large Language Models Cannot Self-Correct Reasoning Yet>은 이러한 우리의 직관을 아주 냉정하게, 그리고 데이터로 반박합니다.

결론부터 말씀드리자면, “정답지(Oracle) 없는 자가 수정은 오히려 독이 된다”는 것입니다.

오늘은 이 논문을 통해 우리가 그동안 왜 헛수고를 하고 있었는지, 그리고 진짜 논리적인 AI 에이전트를 설계하려면 무엇을 바꿔야 하는지 분석해보겠습니다.

정답지 없는 채점의 비극

이 연구가 지적하는 핵심 문제는 ‘내재적 자가 수정(Intrinsic Self-Correction)’의 한계입니다.

쉽게 비유하자면, 선생님이 채점 결과를 알려주지 않은 상태에서(External Feedback X), 학생 혼자 자신의 시험지를 붙들고 “내가 맞았나?”를 고민하는 상황과 같습니다. 확신이 없는 학생은 정답을 써놓고도 불안감에 오답으로 고치곤 하죠. LLM도 똑같습니다.

실험 결과는 꽤 충격적입니다.

실험 환경: 수학 추론 벤치마크 (GSM8K)
GPT-4 (초기 답변): 95.5% 정답률
GPT-4 (자가 수정 후): 89.0% 정답률

보이시나요? 검토를 시켰더니 성능이 6.5%p나 하락했습니다. Llama-2의 경우 하락 폭은 더 심각했습니다.

왜 성능이 떨어질까?

가장 큰 원인은 LLM이 ‘자신의 답이 맞았는지 틀렸는지 판단할 메타 인지 능력이 부족하다’는 점입니다. 정답을 모르니 멀쩡한 정답을 의심하고, 결국 엉뚱한 오답으로 수정해버리는 현상이 발생합니다.

Case Study: Terry의 요거트 문제

• 초기 답변: “Terry는 30일 동안 $75를 쓴다.” (정답)
• 자가 수정 프롬프트 입력 후: “잠깐, 내가 실수를 한 것 같아. 4개 세트니까…” (불필요한 의심)
• 최종 답변: “$37.50이다.” (오답)

이것이 정답지 없는 자가 수정의 현실입니다.

성공 사례의 비밀은 ‘오라클(Oracle)’

“어? 그런데 Reflexion 같은 기존 연구에서는 자가 수정으로 성능이 올랐다고 하던데요?”라고 반문하실 수 있습니다.

저자들은 그 성공의 이면에 ‘오라클 라벨(Oracle Label)’이 숨어있었음을 꼬집습니다. 기존 연구들은 실험 과정에서 모델에게 “틀렸어, 다시 해”라는 신호(Ground Truth)를 줬습니다. 즉, 선생님이 옆에서 채점을 해줬기 때문에 점수가 올랐던 것이지, 학생이 스스로 깨우친 게 아니라는 뜻입니다.

하지만 우리가 AI를 사용하는 실제 환경(Real-world)에는 정답지가 없습니다. 정답지가 있다면 애초에 AI에게 물어볼 이유가 없으니까요.

멀티 에이전트 토론? 결국은 ‘투표’

최근 유행하는 ‘멀티 에이전트 토론(Multi-Agent Debate)’ 방식도 분석 대상이 되었습니다. 여러 페르소나의 AI가 서로 비판하며 답을 찾는 방식인데, 연구진의 분석 결과는 다소 허무합니다.

멀티 에이전트 토론 (3명): 83.2%
Self-Consistency (단순 3번 생성 후 다수결): 82.5%

통계적으로 유의미한 차이가 없습니다. 복잡하게 에이전트끼리 대화시킬 리소스로, 차라리 3번 물어보고 다수결(Major Vote)로 정하는 게 훨씬 경제적이고 효율적이라는 의미입니다.

어떻게 해야 하는가?

그렇다면 프롬프트에서 ‘검토’ 과정을 완전히 삭제해야 할까요? 논문은 무조건적인 비판 대신 명확한 대안을 제시합니다.

초기 프롬프트에 투자하십시오

자가 수정으로 얻으려던 이득의 대부분은 사실 ‘초기 프롬프트가 부실했기 때문’에 발생합니다. “나중에 다시 확인해”라고 말할 토큰으로, 차라리 첫 질문에 제약 조건과 논리 구조를 명확히 지시하는 것이 성능 향상에 훨씬 효과적입니다.

‘외부 검증 도구’를 연결하십시오

LLM의 파라미터(뇌)만 믿지 마십시오. 계산 검증이 필요하다면 계산기를, 팩트 체크가 필요하다면 검색 엔진을, 로직 검증이 필요하다면 코드 실행기(Code Interpreter)를 붙여야 합니다.

잘못된 접근 vs 올바른 접근

❌ 잘못된 접근:
“네가 짠 코드가 맞는지 다시 한번 생각해보고 수정해줘.”
→ 자신의 직관에 의존하므로 환각(Hallucination)이 반복될 확률 높음.

✅ 올바른 접근:
“작성한 코드를 실행(Execute)하고, 에러 메시지가 나오면 그것을 바탕으로 코드를 수정해줘.”
→ ‘외부의 팩트’에 기반한 수정이므로 성능이 확실히 향상됨.

맺음말

우리는 종종 AI를 지나치게 의인화하는 경향이 있습니다. “반성해”, “성찰해” 같은 지시가 AI에게 통할 것이라 기대하지만, 냉정하게 말해 LLM은 아직 그 단계에 도달하지 못했습니다.

무의미한 “다시 검토해줘” 루프를 돌리는 대신, 초기 지시문을 정교하게 다듬거나(Prompt Engineering), 확실한 외부 도구(Tools)를 쥐여주세요. 그것이 똑똑한 AI 에이전트를 만드는 가장 빠른 지름길입니다.