AI 셀프리뷰는 왜 통과만 하고, 어떻게 해야 결함을 잡는가
“완성도 높은 글입니다. 이대로 발행하셔도 좋겠습니다.” 블로그 글 초고의 검토를 부탁했을 때 AI가 준 답이었습니다. 혹시나 해서 주문을 바꿔봤습니다. 까다로운 독자이자 시니어 에디터로서, 발행을 막을 결함만 찾아라. 이번에는 모델도 다른 회사 것으로 골랐습니다. 돌아온 것은 치명적인 지적 일곱 건이었습니다. 기술 용어 하나를 원리와 다르게 설명하고 있다는 것, 핵심 주장에 출처가 하나도 없다는 것. 하나씩 원문과 대조해 보니 일곱 건 모두 실제 결함이 맞았고, 글은 뼈대만 남기고 다시 썼습니다.
같은 글이 한쪽에서는 통과였고, 한쪽에서는 전면 재작성이 필요한 글이었던 겁니다. 적어도 그 일곱 결함은 “검토해줘”에서는 빠져나갔고, “결함만 찾아라”에는 붙잡혔습니다. 그날 이후 AI 검토를 시키는 방식을 통째로 바꿨고, 이후 여러 편에서 같은 루프가 반복해서 결함을 잡아줬습니다. 왜 순진한 셀프리뷰는 통과로 흐르는지, 제 루프에 정착한 절차가 무엇인지 적습니다.
자기 검토가 통과로 흐르는 이유
왜 그럴까요. 2024년 ICLR에 실린 「Large Language Models Cannot Self-Correct Reasoning Yet」이 힌트를 줍니다. 이 연구는 모델이 검색도 정답 확인도 사람 피드백도 없이 자기 답만 다시 살펴 고치는 방식, 이른바 내재적 자기 교정(intrinsic self-correction)을 추론 과제에서 검증했습니다. 결과는 부정적이었습니다. 자기 교정은 성능을 안정적으로 개선하지 못했고, 맞는 답을 틀린 답으로 고치는 경우까지 나타났습니다. 실험 대상이 추론 문제라 글이나 코드 리뷰까지 입증된 건 아니지만, 방향은 제 경험과 정확히 겹칩니다.
제 가설은 이렇습니다. 결함이 결과물에 남았다는 건 생성 과정의 판단 기준으로는 그걸 잡지 못했다는 뜻입니다. 같은 모델에 같은 맥락으로 “검토해줘”라고 하면 그 판단 기준이 그대로 재현되기 쉽습니다. 게다가 막연한 검토 요청은 평가 기준이 비어 있어서, 출력이 총평과 칭찬 쪽으로 흐르기 좋습니다. 사람은 글을 하루 묵히면 낯선 눈으로 다시 볼 수 있지만, 모델은 시간을 둔다고 관점이 저절로 독립되지도 않습니다.
제 루프에 정착한 세 가지 절차
역할과 기준을 결함 중심으로 뒤집습니다. 셋 중 효과를 가장 확신하는 절차입니다. “검토해줘” 대신 이렇게 시킵니다. 까다로운 독자이자 시니어 에디터다, 임무는 발행을 막는 것이다, 칭찬은 생략하라, 지적은 치명(발행 불가 사유)과 권고로 구분하라, 문장을 인용해 구체적으로 지적하라. 평가 기준과 출력 형식을 결함 탐색으로 고정하면 같은 모델도 전혀 다른 강도로 읽습니다. 코드라면 “머지를 막을 결함만 찾아라”가 같은 역할을 합니다.
만든 맥락과 분리된 눈에게 시킵니다. 집필이나 구현의 맥락을 공유한 세션은 “왜 이렇게 했는지”까지 알고 있어서 판단이 관대해지기 쉽습니다. 그래서 리뷰는 맥락 없는 새 세션에 결과물만 줘서 시킵니다. 저는 여기에 더해 만드는 모델과 비평하는 모델을 다른 회사 제품으로 갈라둡니다. 다만 첫 사례에서는 모델과 주문을 동시에 바꿔서 어느 쪽 효과인지 가릴 수 없었습니다. 이후 여러 번 반복하며 역할 설계의 효과가 크다는 심증을 얻었고, 모델 분리는 같은 맹점을 공유할 가능성을 줄이는 보험으로 남겨뒀습니다.
고친 뒤에는 재검토로 닫습니다. 지적을 반영해 고쳤으면, 고친 결과를 비평자에게 다시 보내 앞서 지적한 문제가 실제로 사라졌는지 항목별로 확인시킵니다. 첫 사례에서도 재작성 뒤 2차 비평에서 일곱 건 전부 해소 판정을 받고서야 발행했습니다. 재검토가 없으면 문제를 없앤 것인지 문장만 손본 것인지 알 수 없습니다. 물론 이 판정도 AI의 판정이라 끝은 아닙니다. 사실 지적은 출처와 직접 대조하고, 코드는 테스트를 돌리고, 최종 반영 여부는 사람이 정합니다. 결함만 찾도록 세팅된 비평자는 설계상 뭐라도 찾아오기 때문에, 저는 결과물의 정체성과 충돌하는 지적을 근거를 적고 기각한 적도 있습니다. 권고를 전부 따르는 순간, 최종 판단권까지 비평자에게 넘어갑니다.
코드 리뷰에 옮길 때의 형태
이 구조를 코드에는 이렇게 옮겨 씁니다. 구현한 세션과 별개의 새 세션을 열고, 구현자의 자기 설명은 빼되 판단에 필요한 맥락(요구사항, 관련 테스트, 프로젝트 규칙)은 바뀐 부분만 담은 변경 내역(diff)과 함께 줍니다. 그리고 머지를 막을 결함만 치명·권고로 구분해 찾게 합니다. 지적이 오면 실제 코드와 대조해 재현되는 것만 고치고, 고친 변경분으로 재검토를 한 번 더 받습니다. 한 번에 완성하려 하지 않고, 만들기와 검증하기를 분리해 반복하는 구조입니다.
매일 새로 시작하는 에이전트의 반복 실수를 다뤘을 때와 같은 자리에 닿습니다. 모델이 스스로 약점을 극복하길 기다리는 대신, 작업 절차로 그 약점을 보완하는 건 지금 당장 가능합니다. 그 글에서 기억을 세션 밖 파일에 두었다면, 이번에는 비판적인 시선을 결과물을 만든 맥락 밖에 뒀습니다. 비평은 맡길 수 있어도, 판단은 맡길 수 없습니다.
여백 — AI에게 칭찬받은 결과물을 그대로 내보낸 게 마지막으로 언제였는지 세어봤습니다. 꽤 자주였습니다. 그 결과물들은 지금 어떤 상태일까요.
참고 — Large Language Models Cannot Self-Correct Reasoning Yet (ICLR 2024)
댓글