Maker-Critic 루프를 코드 리뷰 파이프라인에 박아 넣기

생성 에이전트(Maker)와 별도의 검증 에이전트(Critic)를 분리하는 패턴이 코드·문서 워크플로의 표준 구조로 정착하고 있다. 같은 모델에 '스스로 검토하라'고 시키면 자기 출력에 관대해지는 self-evaluation 편향이 생기지만, Critic을 별도 프롬프트·별도 호출로 떼어내면 결함 검출률이 눈에 띄게 오른다. 관건은 Critic의 출력을 자연어 코멘트가 아니라 구조화된 판정(PASS/REVISION_NEEDED + 사유 + 수정 지점)으로 강제하는 것. 그래야 Maker가 다음 반복에서 기계적으로 반영하고, 2~3회 반복 후 수렴 여부를 라우터가 판단할 수 있다. 다만 Critic이 Maker와 동일한 맥락 오류를 공유하면 둘 다 같은 버그를 놓치므로, Critic에는 의도적으로 다른 관점(보안·과설계·비즈니스)을 주입해야 한다.