💡 한 줄 요약

RubricMiddleware는 에이전트가 명확한 완료 기준에 도달할 때까지 별도 채점 에이전트의 피드백을 받아 스스로 평가하고 수정하도록 만드는 Deep Agents용 반복 검증 장치다.

📌 핵심 요약

• 글은 에이전트가 복잡한 작업에서 첫 시도만으로 완성도 높은 결과에 도달하지 못하는 문제를 출발점으로 삼는다. 테스트 통과, 금지 패턴 회피, 필수 섹션 포함처럼 성공 기준이 명확한 작업에서도 문맥이 커지고 지시가 모호해지면 품질이 흔들린다는 점을 지적한다.
• RubricMiddleware는 사용자가 ‘완료’의 의미를 루브릭으로 정의하면, 에이전트 실행이 끝나기 전에 별도의 grader sub-agent가 결과를 기준별로 평가하는 방식으로 작동한다. 기준을 만족하지 못하면 피드백이 대화에 다시 주입되고 에이전트가 다시 작업한다.
• 이 반복 루프는 모든 기준이 충족되거나, 설정된 최대 반복 횟수에 도달하거나, 실패 또는 채점기 오류가 발생할 때 종료된다. 평가 전용 하위 에이전트는 전체 대화 기록을 검토할 수 있고, 필요하면 테스트 실행이나 린트 같은 도구를 호출해 근거를 모을 수 있다.
• 설정 방식은 RubricMiddleware를 정의하고, 이를 deep agent에 middleware로 연결한 뒤, 실행 시점에 human message와 rubric 문자열을 함께 전달하는 구조다. 루브릭이 없으면 middleware는 동작하지 않으며, 에이전트의 system_prompt는 작업 방식, 루브릭은 채점 기준을 담당한다.
• 예시에서는 중복 요소를 찾는 Python 함수를 생성하는 작업에서 첫 구현이 겉보기에는 맞아 보였지만, 리스트처럼 해시할 수 없는 값이 입력에 포함될 때 TypeError가 발생해 테스트 하나에 실패했다. 채점기의 구체적 피드백을 받은 에이전트는 구현을 수정했고 두 번째 반복에서 모든 테스트를 통과했다.

🧩 주요 포인트

1. 글은 에이전트가 복잡한 작업에서 첫 시도만으로 완성도 높은 결과에 도달하지 못하는 문제를 출발점으로 삼는다. 테스트 통과, 금지 패턴 회피, 필수 섹션 포함처럼 성공 기준이 명확한 작업에서도 문맥이 커지고 지시가 모호해지면 품질이 흔들린다는 점을 지적한다.
2. RubricMiddleware는 사용자가 ‘완료’의 의미를 루브릭으로 정의하면, 에이전트 실행이 끝나기 전에 별도의 grader sub-agent가 결과를 기준별로 평가하는 방식으로 작동한다. 기준을 만족하지 못하면 피드백이 대화에 다시 주입되고 에이전트가 다시 작업한다.
3. 이 반복 루프는 모든 기준이 충족되거나, 설정된 최대 반복 횟수에 도달하거나, 실패 또는 채점기 오류가 발생할 때 종료된다. 평가 전용 하위 에이전트는 전체 대화 기록을 검토할 수 있고, 필요하면 테스트 실행이나 린트 같은 도구를 호출해 근거를 모을 수 있다.
4. 설정 방식은 RubricMiddleware를 정의하고, 이를 deep agent에 middleware로 연결한 뒤, 실행 시점에 human message와 rubric 문자열을 함께 전달하는 구조다. 루브릭이 없으면 middleware는 동작하지 않으며, 에이전트의 system_prompt는 작업 방식, 루브릭은 채점 기준을 담당한다.
5. 예시에서는 중복 요소를 찾는 Python 함수를 생성하는 작업에서 첫 구현이 겉보기에는 맞아 보였지만, 리스트처럼 해시할 수 없는 값이 입력에 포함될 때 TypeError가 발생해 테스트 하나에 실패했다. 채점기의 구체적 피드백을 받은 에이전트는 구현을 수정했고 두 번째 반복에서 모든 테스트를 통과했다.

🧠 상세 정리

1. 에이전트 작업의 ‘완료’ 문제

글은 에이전트가 점점 더 복잡한 작업을 맡고 있지만, 실제로는 마지막 완성 지점에 도달하지 못하는 경우가 많다는 문제의식에서 시작한다. 어떤 작업은 완료 조건이 비교적 분명하다. 예를 들어 코드 리팩터링은 테스트 스위트가 통과해야 끝났다고 볼 수 있고, 보고서는 요구된 모든 섹션을 포함해야 완성됐다고 볼 수 있다. 그러나 에이전트는 첫 시도에서 이런 기준을 항상 만족하지 못한다. 문맥이 커질수록 모호한 지시, 도구 오사용, 비결정적 오류가 겹치면서 결과 품질이 낮아지고, 개발자는 이를 직접 진단하고 다시 실행해야 하는 부담을 떠안게 된다.

2. RubricMiddleware의 핵심 역할

RubricMiddleware는 에이전트에게 ‘무엇이 완료 상태인지’를 알려주고, 그 기준을 만족할 때까지 계속 개선하도록 만드는 장치로 소개된다. 사용자는 루브릭을 통해 성공 기준을 정의하고, 에이전트는 그 기준에 대해 평가를 받은 뒤 부족한 부분을 수정한다. 이 방식은 테스트 통과, 금지된 패턴 회피, 필수 섹션 포함처럼 검증 가능한 기준이 있는 작업에서 특히 효과적이다. 글은 이를 Claude Code나 Codex의 /goal과 유사한 패턴으로 설명하지만, 여기서는 평가가 별도의 grader sub-agent에 의해 수행된다는 점을 차별점으로 제시한다.

3. 별도 채점 에이전트가 반복 루프를 구성하는 방식

RubricMiddleware가 적용된 실행에서는 기본 에이전트가 답변을 마치기 직전에 별도의 grader sub-agent가 전체 작업을 루브릭에 비추어 검토한다. 모든 기준이 충족되면 실행은 그대로 종료된다. 하나라도 부족하면 채점기가 기준별 피드백을 생성하고, 그 피드백이 다시 대화에 주입되어 에이전트가 수정 작업을 이어간다. 이 루프는 기준이 만족될 때, 설정된 최대 반복 횟수에 도달할 때, 실패가 발생할 때, 또는 채점기 오류가 발생할 때 종료된다. 즉 단순히 다시 시도하는 것이 아니라, 무엇이 부족한지를 기준별로 알려주는 구조다.

4. 구성 요소와 연결 방법

글은 최소 설정을 세 단계로 설명한다. 먼저 RubricMiddleware를 정의하면서 채점에 사용할 모델, 채점기의 역할과 좋은 결과의 조건을 담은 system_prompt, 선택적으로 호출할 수 있는 도구, 최대 반복 횟수를 지정한다. 다음으로 create_deep_agent를 만들 때 이 middleware를 전달해 기본 에이전트 위에 채점 루프를 붙인다. 이때 기본 에이전트의 system_prompt는 작업을 어떻게 수행할지에 대한 운영 지시를 담고, rubric은 채점기가 결과를 어떻게 판단할지를 담는다. 마지막으로 invoke 시점에 사용자 메시지와 줄 단위 체크리스트 형태의 rubric을 함께 전달한다.

5. 도구를 통한 근거 기반 평가

RubricMiddleware의 평가 방식은 추상적 판단에만 의존하지 않는다. 채점 에이전트는 도구가 제공될 경우 이를 호출해 실제 근거를 수집할 수 있다. 글의 예시에서는 run_test_suite 도구를 제공해, 채점기가 코드의 올바름을 말로만 추정하는 대신 테스트 실행 결과를 바탕으로 판단하도록 했다. 도구가 없을 때는 전체 대화 기록을 바탕으로 추론하지만, 도구가 있으면 테스트나 린트, 출력 검증처럼 더 직접적인 증거를 활용할 수 있다. 이 때문에 피드백은 단순한 “다시 해보라”가 아니라 어떤 기준이 왜 실패했는지에 대한 구체적인 수정 지시가 된다.

6. 실제 예시와 의미

예시 작업은 입력 리스트에서 두 번 이상 등장한 요소를 처음 나타난 순서대로 반환하는 Python 함수 find_duplicates를 작성하는 것이다. 첫 번째 결과는 겉으로는 올바르게 보였지만, 리스트처럼 해시할 수 없는 값이 입력에 있을 때 TypeError가 발생해 test_unhashable 테스트에 실패했다. 채점기는 이 실패를 구체적으로 지적했고, 에이전트는 이를 반영해 구현을 수정한 뒤 두 번째 반복에서 모든 테스트를 통과했다. 글은 이 흐름을 통해 에이전트 출력의 확률적 변동성을 개발자가 매번 직접 잡아내는 대신, 시스템이 정의된 완료 기준에 따라 처리하게 만들 수 있다고 강조한다.

🧾 핵심 주장 / 시사점

• RubricMiddleware의 핵심 가치는 에이전트에게 더 많은 지시를 주는 것이 아니라, 완료 기준을 외부화하고 그 기준에 따라 반복적으로 검증하는 실행 구조를 만든다는 데 있다.
• 이 방식은 창의적이거나 주관적인 작업보다 테스트, 체크리스트, 금지 조건, 필수 구성 요소처럼 판정 기준이 명확한 작업에서 가장 큰 효과를 낸다.
• 별도 grader sub-agent가 기준별 피드백과 도구 기반 근거를 제공하므로, 실패한 실행을 개발자가 수동으로 해석하고 재시도하는 부담을 줄이는 데 초점이 맞춰져 있다.

✅ 액션 아이템

• 원문에서 강조한 핵심 변화와 이해관계자를 기준으로 Introducing Rubrics: Build Agents that Evaluate and Correct Their Work의 영향을 정리한다.
• 다음 의사결정이나 제품/정책 판단에 연결될 수 있는 근거를 원문 문장과 함께 기록한다.
• 기사에서 제시한 수치·사례·제약 조건을 분리해 과장 없이 검토한다.
• 후속 모니터링이 필요한 발표·제품·정책 변화가 있는지 출처 링크를 기준으로 추적한다.

❓ 열린 질문

• How Box AI built enterprise content agents with Deep Agents]]" "192. 이 변화가 실제 사용자나 조직의 선택 기준을 어떻게 바꿀까?
• Interpreter Skills Building Workflows for Agents" "269. 이 근거가 다른 산업이나 지역에서도 동일하게 적용될 수 있을까?
• How to Choose the Right Sandbox for AI Agents" "215. 기사에서 아직 검증되지 않은 전제나 리스크는 무엇일까?
• Delta Channels How We’re Evolving our Runtime for Long Running Agents" "[[202. 후속 발표나 데이터가 나오면 어떤 지표를 먼저 비교해야 할까?