AI가 자기 결과에 합격점을 준다면? 만드는 에이전트와 검수하는 에이전트 나누기

AI는 다 만들었다는데, 버튼을 눌러 보니 아무 일도 일어나지 않나요? 만드는 에이전트와 검수하는 에이전트의 역할을 나누고, 제작 전에 무엇을 확인해야 합격인지 적어 보세요. 검수자에게는 완성 화면뿐 아니라 실행 가능한 결과물과 확인 기록을 넘기는 것이 핵심입니다. 다만 AI를 하나 더 붙였다는 이유만으로 결과가 정확해지지는 않습니다.

자기평가가 놓치는 것

Anthropic의 2026년 3월 24일 엔지니어링 글은 에이전트가 자신이 만든 결과물을 평가할 때 관대한 판단을 내리는 문제를 설명합니다. 특히 디자인처럼 정답을 하나로 가르기 어려운 작업에서 두드러졌다고 합니다. 제작과 평가를 분리하면 외부 피드백을 바탕으로 수정할 수 있지만, 평가자 역시 AI이므로 관대함이 저절로 사라지지는 않는다고 명시합니다.

해당 실험에서 검수 에이전트는 Playwright라는 브라우저 조작 도구로 실제 페이지를 살펴봤습니다. 개발 실험에서는 작업 전에 완료 조건과 확인 방법을 합의했고, 검수 단계에서 실행 중인 앱을 조작하며 조건 충족 여부를 확인했습니다. 이는 완성됐다는 설명만 읽고 점수를 매기는 방식과 차이가 있습니다.

OpenAI의 게임 개발 안내도 Codex가 반복 개선을 할 수 있도록 평가 스크립트와 검토 가능한 산출물을 제공하라고 안내합니다. 다만 이 자료는 자기평가 반복도 소개하며, 별도 검수 에이전트를 필수로 요구하지는 않습니다. 두 자료를 함께 읽으면 평가할 기준과 증거를 마련하고, 필요할 때 평가 역할을 분리한다는 적용 방향을 얻을 수 있습니다.

이 글은 제공된 공식 문서를 바탕으로 정리했습니다. 아래의 모임 신청 화면과 요청문은 원리를 익히기 위한 편집 예시이며, 실제로 제작하거나 실행한 결과가 아닙니다.

제작 전에 정할 합격 조건

가상의 독서 모임 신청 화면을 만든다고 해봅시다. 이름과 참석 날짜를 입력하고 신청 버튼을 누르는 간단한 화면입니다. 처음부터 ‘예쁘고 문제없이 작동하게’라고만 요청하면 제작자와 검수자가 서로 다른 완성 상태를 떠올릴 수 있습니다.

아래처럼 사용자의 행동과 기대 결과를 함께 적어 보세요. 표의 조건은 공식 제품 사양이 아니라 이 연습에서 정한 요구사항입니다.

항목	합격 조건	확인할 증거
정상 신청	이름과 날짜를 입력하고 신청하면 두 값이 확인 영역에 표시된다.	입력값, 클릭 순서, 표시된 결과 기록
빈칸 처리	이름 없이 신청하면 완료 표시가 나오지 않고 이름 입력 안내가 보인다.	이름을 비운 상태에서 수행한 확인 기록
중복 클릭	신청 버튼을 연속 두 번 눌러도 신청 결과가 두 건으로 늘지 않는다.	클릭 전후 신청 결과 개수
좁은 화면	가로 390픽셀 화면에서 입력란과 신청 버튼이 잘리지 않는다.	해당 너비의 화면과 조작 확인 기록

이번 연습은 화면 동작만 다룹니다. 새로고침 후에도 신청 내용을 보관해야 한다면 저장 요구사항을 별도로 추가해야 합니다. 화면에 이름이 나타난 것만으로 저장까지 성공했다고 판단해서는 안 됩니다.

디자인도 평가하고 싶다면 ‘고급스럽다’보다 ‘주요 신청 버튼을 다른 링크와 구별할 수 있다’처럼 관찰 가능한 기준부터 정하세요. 취향이 필요한 항목은 선호하는 예와 그 이유를 함께 전달하는 편을 권합니다. Anthropic 실험에서도 상세한 평가 예시로 평가자의 판단을 조정했습니다.

제작·검수 요청문과 전달 자료

처음부터 자동으로 여러 에이전트를 연결할 필요는 없습니다. 역할 분리를 연습하려면 제작용 대화와 검수용 대화를 따로 두고 자료를 직접 전달할 수 있습니다. 다만 이것은 수동 연습 방식이며, 새 대화를 연다고 실행 도구나 결과물 접근 권한이 생기지는 않습니다.

제작자에게 보낼 요청문

독서 모임 신청 화면을 만들어 주세요.
입력 항목은 이름과 참석 날짜입니다.
첨부한 합격 조건 네 가지를 구현 범위로 삼아 주세요.
이번 범위에 새로고침 후 데이터 보관은 포함하지 않습니다.

제작 전에 각 조건을 어떻게 확인할지 적어 주세요.
완료 후에는 다음을 넘겨 주세요.
1. 결과물과 실행 방법
2. 직접 확인한 항목, 확인 절차와 결과
3. 확인하지 못한 항목과 이유
4. 알려진 문제
확인하지 못한 기능은 완료했다고 표현하지 마세요.

검수자에게 보낼 요청문

당신은 이 신청 화면의 검수자입니다.
제공한 요구사항과 합격 조건을 기준으로 결과물을 확인해 주세요.
제작자의 완료 보고는 참고 자료이며 합격 증거로 대신하지 마세요.

각 항목을 통과 / 실패 / 미확인으로 구분해 주세요.
항목마다 다음을 기록해 주세요.
- 사용한 결과물 버전
- 확인 절차와 입력값
- 기대 결과
- 실제 관찰 결과와 증거 위치
- 판정 이유

실행할 수 없는 항목은 미확인으로 남겨 주세요.
실패 항목에는 재현 순서와 필요한 수정 내용을 적어 주세요.
이번 검수에서는 결과물을 직접 수정하지 마세요.

검수자에게는 요구사항, 합격 조건, 같은 버전의 결과물, 실행 방법, 기존 확인 기록을 함께 넘기세요. 결과물 버전은 파일명이나 작업 번호로 구별해도 됩니다. 수정 전 화면을 검수하면서 수정 후 코드에 합격점을 주는 혼선을 피하기 위한 제안입니다.

검수 AI가 브라우저를 조작할 수 없다면 사람이 입력과 클릭을 수행하고 기록을 전달할 수 있습니다. 이때 AI가 확인한 것은 전달받은 기록입니다. 실제 화면을 직접 조작했다고 보고하게 해서는 안 됩니다. 화면 사진만 제공했다면 빈칸 제출이나 중복 클릭의 동작 여부는 미확인으로 남겨야 합니다.

실패를 수정 요청으로 바꾸기

‘버튼이 이상하다’는 평가는 제작자가 다음 행동을 정하기 어렵습니다. 재작업 요청은 같은 문제를 다시 일으킬 수 있는 절차로 적어 보세요. 아래는 실패가 발견됐다고 가정한 작성 예시입니다.

항목: 이름 빈칸 처리. 절차: 이름을 비우고 참석 날짜만 선택한 뒤 신청 버튼을 한 번 누름. 기대 결과: 이름 입력 안내가 나타나고 완료 표시는 나오지 않음. 가정한 관찰 결과: 신청 완료 표시가 나타남. 요청: 이름이 비어 있으면 완료 처리를 막고 안내를 표시할 것. 수정 후 같은 절차와 정상 신청 절차를 다시 확인할 것.

이처럼 기대 결과와 관찰 결과를 나눠 적으면 실패 이유가 분명해집니다. 원인을 확인하지 않았다면 ‘입력 검사 코드가 빠졌다’고 단정할 필요도 없습니다. 먼저 관찰된 실패를 전달하고, 제작자가 원인을 조사하도록 하세요.

이 연습에서는 필수 조건 하나라도 실패하거나 미확인이면 최종 통과를 보류하는 규칙을 권합니다. 보기 좋은 화면이 작동하지 않는 버튼을 상쇄하지 못하게 하려는 편집 제안입니다. 수정 뒤에는 실패 항목과 그 수정의 영향을 받을 수 있는 정상 동작을 함께 재확인하세요.

체크리스트

• 만들기 전에 사용자 행동과 기대 결과를 합격 조건으로 적었나요?
• 제작자와 검수자에게 같은 요구사항을 전달했나요?
• 검수 대상 버전과 실행 방법이 명확한가요?
• 정상 입력뿐 아니라 빈칸·반복 클릭 같은 실패 상황도 포함했나요?
• 통과 판정에 실제 확인 기록이 있고, 못 본 항목은 미확인으로 남겼나요?
• 수정 요청에 재현 절차·기대 결과·관찰 결과를 나눠 적었나요?
• 반복 횟수나 예산의 상한, 사람이 확인할 마지막 단계를 정했나요?

한계와 주의

역할 분리는 정확성 보장이 아닙니다. Anthropic은 초기 검수 에이전트가 실제 문제를 찾아놓고도 사소하다며 승인하거나, 피상적으로만 시험했다고 설명합니다. 평가 지침을 여러 번 조정한 뒤에도 놓친 버그와 불편한 상호작용이 남았습니다. 중요한 기능은 사람이 직접 확인할 여지를 두세요.

평가를 반복할수록 언제나 좋아지는 것도 아닙니다. 해당 디자인 실험의 작성자는 마지막 결과보다 중간 결과를 선호한 경우가 있었고, 반복 과정에서 구현이 복잡해지는 경향도 관찰했습니다. 따라서 이전 결과물을 보관하고, 반복 상한에 도달하면 사람이 비교해 다음 단계를 정하도록 권합니다.

별도 평가에는 시간과 비용이 들 수 있습니다. Anthropic은 모델이 혼자 안정적으로 처리하는 범위에서는 평가자가 불필요한 부담이 될 수도 있다고 설명합니다. 짧은 작업은 명확한 조건과 사람의 확인으로 시작하고, 반복해서 놓치는 문제가 있을 때 역할 분리를 고려해 보세요.

이 글은 자동화 도구의 설치 안내가 아닙니다. 실제 자동 검수를 구성하려면 실행 환경과 도구 연결이 필요합니다. 또한 제공된 OpenAI 자료는 활용 사례를 소개하는 개요이므로 평가 스크립트의 구체적인 설정 방법까지 확인할 수는 없습니다. 자료 확인일은 2026년 9월 29일이며, 이를 새 기능 발표일로 해석해서는 안 됩니다.

자주 묻는 질문

제작자와 검수자는 반드시 다른 회사의 AI여야 하나요?

제공 자료는 다른 회사의 모델을 써야 한다고 요구하지 않습니다. 핵심은 제작과 평가의 역할, 평가 기준, 확인 절차를 구분하는 것입니다. 회사가 달라져도 평가 오류가 사라진다고 보장할 수는 없습니다.

새 대화에서 평가해 달라고 하면 충분한가요?

역할 분리 연습은 가능하지만 충분한 검수인지는 별개입니다. 검수자가 요구사항과 해당 버전의 결과물을 볼 수 있어야 하며, 동작을 판단하려면 실행이나 그에 해당하는 확인 기록이 필요합니다.

화면 사진만 보내도 기능이 정상인지 알 수 있나요?

사진으로 보이는 배치와 문구는 검토할 수 있지만 클릭 후 동작이나 데이터 저장까지 확인할 수는 없습니다. 증거가 없는 기능은 미확인으로 남기세요.

검수 AI가 높은 점수를 주면 바로 공개해도 되나요?

점수만으로 판단하지 않는 편을 권합니다. 이 글의 연습 방식에서는 필수 조건별 증거와 실패·미확인 항목을 먼저 확인하고, 사람이 핵심 동작을 마지막으로 점검합니다.

몇 번 반복하면 완성되나요?

모든 작업에 적용할 수 있는 반복 횟수는 제공 자료로 정할 수 없습니다. 작업 전에 상한을 정하고, 남은 실패 항목과 개선 정도를 보며 계속 수정할지 사람이 판단하세요.

출처

• Anthropic: Harness design for long-running application development — 2026년 3월 24일 게시. 자기평가의 관대함, 생성·평가 역할 분리, 사전 완료 조건, 실행 검수와 한계. 자료 확인일: 2026년 9월 29일.
• OpenAI: Game development 활용 사례 모음 — 평가 스크립트와 검토 가능한 산출물을 활용한 반복 개선, 오류 보고·실패 기록 기반 문제 분류 안내. 제공 텍스트에 게시일은 표시되지 않음. 자료 확인일: 2026년 9월 29일.