코딩 에이전트의 수정 피드백을 '지속 노트'로 관리하는 Opera critic 프레임워크

무엇인가

긴 호흡의 코딩 에이전트는 저장소 탐색, 편집, 테스트를 반복하면서 실패한 행동을 되풀이하거나 불필요한 탐색을 늘리고, 검증이 끝나기 전에 완료를 선언하기도 한다. 실행 중 문제를 진단해 주는 critic이 자연스러운 해법이지만, critic은 미완성된 작업을 판단해야 한다는 근본적 어려움을 안는다. 불완전한 증거만으로는 진짜 실수와 합리적인 중간 단계를 구분하기 어렵기 때문이다. 논문은 기존 critic들이 궤적 평가와 피드백 생성에 집중할 뿐, 피드백이 전달된 뒤 무슨 일이 일어나는지는 거의 추적하지 않는다고 지적한다. 그래서 세 가지 질문을 세운다. 언제 개입할 것인가, 그 피드백이 정당한가, 개입이 실제로 효과가 있었는가.

어떻게 동작하나

Opera의 핵심 설계는 모든 수정 사항을 하나의 '지속 노트(persistent note)'로 다루는 것이다. 문제가 발견되면 노트를 열고, 정당성이 확인될 때만 전달하고, 실행이 진행되는 동안 추적하고, 증거가 해결을 뒷받침하면 닫는다. 개입 시점은 하이브리드 스케줄로 정한다. k턴마다 주기적 리뷰를 돌리되, Idle(진전 없음), Repeat(반복 행동), Error(실패한 행동·도구 호출), Claim(완료 보고), Submission(최종 패치) 다섯 이벤트에서 즉시 리뷰를 발동한다. 동시 신호는 하나의 리뷰로 합치고, 이벤트 리뷰는 주기 타이머를 초기화한다. 중요한 것은 리뷰가 곧 개입이 아니라는 점으로, critic은 침묵을 선택할 수 있다.

무엇과 다른가

진단은 자유 서술이 아니라 타입이 지정된 연산자(operator)로 강제한다. 코드 수리의 단계인 Search, View, Edit, Test, Submit에 걸쳐 9개 연산자가 있고, 각각 계약(contract)으로 명세된다. 언제 적용되는지, 어떤 증거가 필요한지, 어떤 수정을 요구할 수 있는지, 언제 해결로 간주하는지, 어떤 문제는 배제하는지를 담는다. 예를 들어 repo_localization_search는 대상을 아직 못 찾은 경우, implementation_target_shift는 엉뚱한 대상을 편집하는 경우, requirement_contract_review는 요구사항을 위반한 경우, submission_readiness_review는 증거 없이 완료를 선언한 경우다. 한 번의 리뷰는 하나의 이슈와 가장 작은 수정만 다루며, 연산자는 실행 내내 계속 사용 가능하다. 노트는 동시에 최대 하나만 열려 있고, 열기·갱신 시에는 admission audit이, 닫을 때는 release audit이 개입한다. 두 감사는 제안을 수락하거나 거부할 뿐 다시 쓰지는 않는다. 특히 준수(adherence)와 해결(resolution)을 분리해 추적하는데, 에이전트가 제안을 따랐더라도 원래 문제가 남아 있으면 노트는 닫히지 않는다.

어떻게 쓰나

실험은 Terminal-Bench 2.1(89개 과제, Terminus-2), SWE-Bench Pro 100개 과제(OpenHands), DeepSWE v1.1(113개 과제, mini-swe-agent)에서 수행했다. 정책 모델은 Qwen3.5-9B, Muse-glimmer-30B, Qwen3.8-27B, Deepseek-V4-Flash-0731 네 가지이고 기본 critic은 GPT-5.6-Sol이다. Opera는 critic 없는 에이전트 대비 최대 12.4%p(Terminal-Bench 2.1), 15.0%p(SWE-Bench Pro), 8.9%p(DeepSWE) 해결률을 올렸고, 세 벤치마크 모두에서 경쟁 critic 베이스라인(SWE-PRM, SWE-Search, LLM-as-verifier, Agentic Rubrics) 중 최고 평균 해결률을 기록했다. 다만 최강 베이스라인과의 격차는 Terminal-Bench 2.1에서 1.9%p, DeepSWE에서 1.8%p인 반면, 비-critic 에이전트가 이미 강한 SWE-Bench Pro에서는 0.6%p에 그쳤다. 정책 모델별로는 약한 모델이 더 큰 이득을 봤고(Qwen3.5-9B가 Terminal-Bench 2.1에서 12.4%p, SWE-Bench Pro에서 15.0%p), Qwen3.5-9B는 DeepSWE에서 critic 유무와 무관하게 단 하나의 과제도 해결하지 못했다.

전제와 한계

분석 파트는 critic의 작동 방식을 더 구체적으로 보여준다. 전달된 노트는 대부분 Edit 단계 연산자였고(예: Qwen3.8-27B의 약 80%), Search와 Submit은 드물었다. Qwen3.5-9B는 요구사항 오독을 뜻하는 requirement-contract 노트를 주로 받은 반면, 더 강한 Qwen3.8-27B와 DeepSeek-V4-Flash는 목표는 이해하되 실행 로직을 틀리는 state-transition 노트로 이동했다. 노트를 받은 시행에서 Opera는 모든 모델의 기대 성공률을 끌어올렸지만, 강한 모델일수록 구제(rescue)가 늘면서 동시에 원래 풀던 과제를 망치는 회귀(regression)도 늘었다. 연산자 제한 실험에서는 Edit 전용이나 Non-edit 전용 모두 상당한 이득을 유지했고, Non-edit 연산자는 노트의 약 5분의 1에 불과하지만 Terminal-Bench 2.1 이득의 절반 이상, SWE-Bench Pro의 4분의 3, DeepSWE의 약 5분의 4를 회복했다. 감사(audit)를 제거하면 세 벤치마크 모두 이득이 줄었는데, Terminal-Bench 2.1에서는 7.9%p에서 2.6%p로 약 3분의 2가 사라졌다. critic 모델을 바꿔도 33개 조합 중 하나를 빼고 모두 critic 없는 경우보다 나았고, DeepSWE에서 자기 비판(self-critique)만으로 Qwen3.8-27B와 DeepSeek-V4-Flash가 각각 6.2%p 향상했다. 반대로 정책이 과제를 풀 능력 자체가 없으면 자기 비판은 효과가 없었고, GPT를 critic으로 쓸 때 Qwen3.5-9B는 최소 12.4%p 오르는 반면 자기 비판은 최대 2.7%p에 머물렀다.

학습 레시피도 눈에 띈다. SWE-Bench Pro를 저장소 단위로 270개 학습 과제와 108개 홀드아웃 과제로 나누고, Qwen3.5-9B가 정책이고 Qwen3.8-27B가 critic인 Opera 유도 롤아웃과, Qwen3.8-27B가 직접 행동하는 교사 롤아웃을 비교했다. 두 소스 모두 홀드아웃 SWE-Bench Pro 해결률을 약 10%p(Opera 쪽 10.2%p) 올려 차이가 없었다. 그러나 과제 형식과 하네스가 다른 Terminal-Bench 2.1에서는 교사 롤아웃 파인튜닝이 해결률을 23.6%에서 7.9%로 떨어뜨린 반면, Opera 유도 롤아웃은 25.8%로 성능을 유지했다. 저자들은 그 이유를 데이터에 담긴 행동의 주체로 설명한다. 교사 롤아웃은 학생에게 off-policy이고, Opera 유도 롤아웃은 모든 행동이 학생에게서 나오고 critic의 영향은 컨텍스트의 노트로만 들어오는 근사 on-policy 데이터라는 것이다.

개발자 관점에서 이 논문의 실용적 함의는 critic을 '피드백 생성기'가 아니라 '상태를 가진 개입 관리자'로 다루라는 것이다. 노트를 열고 닫는 수명주기, 준수와 해결의 분리, 전달 전 감사라는 세 장치가 없으면 critic은 오히려 잘 되던 궤적을 망칠 수 있다는 것이 감사 제거 실험의 결과다. 또한 critic을 붙이는 것과 그 데이터를 학습에 쓰는 것은 별개 문제이며, 자기 정책의 롤아웃에 critic 노트를 얹은 데이터가 강자 모델 증류와 비슷한 목표 성능을 내면서 다른 하네스로의 일반화를 지킨다는 점은 실무 파이프라인 설계에 직접 참고할 만하다. 다만 자기 비판은 추론 연산을 추가하므로 이 비교는 연산량을 맞추지 않았다는 점을 감안해야 한다.

저자들이 밝힌 한계도 분명하다. 학습 결과는 단일 모델에 대한 지도 파인튜닝과 하나의 out-of-domain 벤치마크에 국한되며, 더 큰 데이터셋으로의 확장, 학습된 모델을 새 정책으로 삼는 반복, 강화학습과의 결합은 향후 과제로 남긴다. 또한 critic은 없는 능력을 대체하지 못한다는 점을 명시적으로 인정한다. DeepSWE에서 Qwen3.5-9B가 critic 유무와 무관하게 아무 과제도 풀지 못한 사례, Muse Glimmer-30B가 낮은 기저에서 해결률이 거의 3배가 되어도 절대 이득은 제한적인 사례가 그 근거다. 결국 critic은 피드백을 실행에 옮길 능력은 있지만 스스로 오류를 고치지 못하는 에이전트에서 가장 가치가 크다는 것이 이 논문의 결론이다.