애플리케이션 생성과 평가를 분리하는 하네스 설계

화면을 생성한 에이전트의 완료 보고만으로 사용자 동작이 구현됐는지 판단할 수는 없습니다. 평가자는 정해진 조건에 따라 실제 화면을 조작하고, 누락된 동작과 실패 조건을 확인해야 합니다.

Anthropic의 애플리케이션 개발 하네스 사례에서는 결과를 만드는 에이전트와 평가하는 에이전트에 별도 역할을 맡기고, 평가자가 실제 화면을 조작하게 합니다. 각 에이전트에는 통과 조건과 확인 방법을 전달합니다. 개발자는 별도 평가에 든 시간과 비용을 추가로 발견한 문제와 함께 비교해야 합니다. 평가자를 분리해도 판단 오류가 사라지는 것은 아니므로 평가 조건과 피드백도 검토해야 합니다.

구현 전에 정할 평가 조건

기능 평가에는 관찰할 동작을 적습니다. 목록 표시, 저장 후 재조회, 좁은 화면의 주요 버튼 조작처럼 성공 여부를 확인할 수 있는 조건이 필요합니다.

디자인을 평가할 때는 배치와 정보 순서, 일관성, 요구한 표현과의 차이 등을 기준으로 삼을 수 있습니다. 평가자는 점수와 함께 어느 화면에서 어떤 조건을 충족하지 못했는지 설명해야 구현자가 수정할 부분을 알 수 있습니다.

원문에서는 단계별 계약에 통과 기준을 두고, 기준을 충족하지 못하면 상세 피드백을 전달합니다. 평가 결과를 받는 쪽은 무엇을 고쳐야 다음 검사에서 통과할 수 있는지 알아야 합니다.

직접 만든 파일 목록의 평가 예시입니다. 줄바꿈 같은 표시 조건과 파일 열기·저장 후 재조회 같은 동작 조건을 구분했습니다.

처음 쓰는 사람의 조작 순서

스크린샷은 배치와 시각적 상태를 보여주지만 버튼이 작동하는지는 알려주지 않습니다. 평가자는 페이지에서 클릭하고 입력하고 이동하면서 요구한 동작을 확인해야 합니다.

원문에는 음악 제작 애플리케이션에서 화면은 구현됐지만 타임라인의 클립 크기를 바꾸거나 분할하는 등 핵심 조작이 부족한 사례가 나옵니다. 기능처럼 보이는 요소와 실제 기능은 구분해야 합니다. 서버와 연결됐다는 사실도 모든 사용자 조작이 완성됐다는 근거가 아닙니다.

파일 목록 화면에서는 열기, 선택, 작업 취소와 오류 처리를 요구사항에 따라 확인합니다. 구현하지 않은 동작을 버튼 모양만으로 완료 처리하지 않습니다.

단계 사이에 전달할 상태

작업을 여러 단계로 나누면 단계 사이에 상태를 전달해야 합니다. 요구사항, 실제 구현, 검사 결과, 아직 해결하지 않은 문제를 구분합니다. 이미 실패한 시도를 길게 복사하기보다 실패 원인과 배제한 방법을 남기면 다음 선택을 정하기 쉽습니다.

대화 압축과 새 세션 시작에도 비용이 있습니다. 압축한 기록은 일부 정보를 잃을 수 있고, 새 세션은 필요한 상태를 다시 불러와야 합니다. 어떤 방법이 필요한지는 사용하는 모델과 작업의 실제 결과로 판단해야 합니다.

원문에서 모델을 바꾸면서 일부 인계 절차를 제거한 점도 중요합니다. 이전 모델의 부족한 행동을 보완하려고 만든 절차가 새 모델에서도 반드시 필요하다고 가정하지 않습니다.

현재 실패에 맞는 하네스 절차

별도 계획자, 단계별 평가, 강제 초기화는 모두 특정 실패를 줄이기 위한 방법입니다. 그 실패가 현재 환경에서도 발생하는지 확인하고 절차가 실제로 기여하는지 비교해야 합니다.

단순한 작업에 많은 역할을 넣으면 전달과 대기 시간이 늘어날 수 있습니다. 중요한 동작을 놓치는 작업에서는 별도 검토자가 누락을 발견할 수 있습니다. 원문의 실험 비용과 시간을 다른 프로젝트의 예상 비용으로 그대로 사용하면 안 됩니다. 모델, 작업량, 반복 횟수가 다르면 결과도 달라집니다.

파일 목록 화면을 비교한다면 직접 평가와 별도 평가에 같은 통과 조건을 줍니다. 각각 발견한 문제와 걸린 시간을 기록하면 별도 평가가 더 찾아낸 동작 누락과 추가 비용을 비교할 수 있습니다.

별도 평가에서 발견한 누락은 구현 기준과 기존 검사에 반영합니다. 평가 역할을 유지할지는 추가로 발견한 문제와 투입한 시간·비용을 비교해 판단합니다.