에이전트 하네스 설계 · 4/10
컴파일한 워크플로우를 외부에서 호출할 수 있게 만든 다음, 실제 적용 대상으로 L사 상품 심사 QA를 다시 봤습니다. 기존 QA는 상품 정보와 증빙을 검토하는 여러 하위 흐름으로 나뉘어 있었고, 단계 사이의 값은 공용 저장소를 거쳐 전달됐습니다. 핵심 판정 방법과 금지 조건, 결과 형식은 단계별로 긴 시스템 프롬프트 안에 함께 들어 있었습니다.
이 구조를 하네스로 바꾼 이유는 노드 수를 줄이기 위해서가 아니었습니다. 같은 모델이 자료를 읽어 결과를 만들고, 바로 이어서 자신의 결과가 업무 규칙을 지켰는지 판단하면 생성 방법과 합격 기준이 한 컨텍스트에 섞입니다. 빠뜨리면 안 되는 필수 판정 항목도 ‘스스로 다시 확인하라’는 문장에 의존하게 됩니다. 어느 규칙 때문에 재실행됐는지 추적하기도 어렵습니다.
그래서 도메인 추출 방법과 OCR·파일 도구는 생성 경로에 남기고, 반드시 지켜야 할 판정 기준과 출력 스키마는 하네스의 판정 단계와 정책 검사로 옮겼습니다. 기존 QA 지식을 버리고 새 에이전트를 만든 것이 아니라, 업무를 수행하는 책임과 결과를 채택하는 책임을 분리한 것입니다.
5월 29일 설계를 시작해 6월 초 캔버스의 agents/harness 노드 실행 경로에 적용했습니다. 화면에 생성 노드와 판정 노드를 따로 둔 것이 아니라, 한 하네스 노드 내부에서 생성 단계와 판정 단계를 별도 상태로 나눴습니다. 생성 단계는 답 후보를 만들고, 판정 단계는 그 후보의 채택 여부와 교정 정보를 돌려줍니다. 이어서 여러 기준을 함께 평가하고, 판정 피드백을 다음 생성 입력으로 돌려보내는 Reflexion 재시도까지 연결했습니다.
핵심은 ‘모델에게 한 번 더 생각하라고 시키는 것’이 아니었습니다. 생성과 판정이 서로 다른 상태를 사용하고, 상태 머신이 판정 결과를 다음 행동으로 바꿀 수 있어야 했습니다.
판정기의 입력을 생성 대화와 분리했습니다
생성 모델에게 자신의 대화 전체를 다시 보여 주고 “잘 썼는지 확인해 줘”라고 하면 구현은 간단합니다. 하지만 도구 호출과 중간 추론, 이전 후보가 한 컨텍스트에 섞입니다. 판정 결과가 어느 후보를 대상으로 했는지 분명하지 않고, 판정 모델을 바꿀 때 생성 대화 형식까지 알아야 합니다.
독립 판정기는 입력을 좁혔습니다. 사용자의 현재 요청, 이번에 평가할 답 후보, 평가 기준을 받습니다. 필요한 경우 근거로 사용한 도구 결과를 별도 필드로 전달하지만 생성 단계의 내부 상태 전체를 넘기지는 않습니다.
출력도 자유로운 비평문 대신 구조화했습니다. 각 기준의 점수와 사유, 전체 점수, 짧은 피드백, pass 또는 retry 판단을 돌려줍니다. 상태 머신은 이 값을 보고 완료할지, 피드백을 포함해 생성 단계로 돌아갈지 결정합니다.
생성기 → 답 후보
↓
독립 판정기 → 기준별 점수·피드백
↓
상태 머신 → complete 또는 retry
이 구조에서는 판정 결과가 단순한 등급표가 아닙니다. 다음 전이의 입력입니다. 생성 모델은 ‘더 잘 써라’는 모호한 지시 대신 어떤 기준을 왜 충족하지 못했는지 받아 새 후보를 만들 수 있습니다.
여러 기준을 한 점수로 뭉개지 않았습니다
업무마다 좋은 답의 기준은 다릅니다. 요약 에이전트와 코드 생성 에이전트가 관련성, 완성도, 형식 준수, 근거 충실도를 같은 비율로 볼 이유는 없습니다. 단일 점수만 받으면 낮은 이유도 알 수 없고 다음 후보가 무엇을 고쳐야 하는지도 모호합니다.
그래서 각 기준에 이름과 설명, 가중치, 필수 여부를 두었습니다. 연속 점수는 개선 정도를 비교하는 데 쓰고, 필수 기준은 LLM 점수 계산에서 다른 장점으로 상쇄하지 않을 조건을 나타냅니다. 예를 들어 반드시 포함해야 할 필드가 빠졌다면 문장이 자연스러워도 통과시키지 않습니다. 다만 이 필수 기준도 모델 판정이므로 보안이나 결정론적 형식 보장을 대신하지는 않습니다.
캔버스에서는 판정 기준을 노드 설정으로 구성하고, 독립 산출물에서는 같은 기준을 컴파일 규격에 포함했습니다. 제품 화면에서 만든 기준이 독립 실행에서 사라지면 같은 에이전트라고 부를 수 없기 때문입니다. 판정기 모델과 기준 버전, 통과 문턱도 실행 기록에 함께 남겨 점수의 의미가 바뀐 시점을 구분했습니다.
품질과 정책을 서로 다른 문턱으로 뒀습니다
판정기를 붙이면 개인정보와 비용 한도까지 모두 평가 항목으로 넣고 싶어집니다. 하지만 LLM 판정은 정도를 비교하는 데 유용할 뿐 반드시 지켜야 하는 제한을 보장하지는 못합니다. 판정 응답이 흔들릴 때 보안 정책까지 함께 흔들려서는 안 됩니다.
관련성, 완성도, 근거 충실도, 명확성처럼 얼마나 충족했는지 볼 항목은 품질 판정기가 맡습니다. 개인정보, 금지된 도구, 사용자 승인, 토큰·비용 한도처럼 위반하면 실행할 수 없는 조건은 정책 게이트가 맡습니다. JSON 필드 존재 여부처럼 코드로 확정할 수 있는 조건도 규칙 기반 검사로 둡니다.
정책이 차단하면 품질 점수가 높아도 실행은 멈춥니다. 반대로 정책을 통과했다고 좋은 답이라는 뜻은 아닙니다. 이 구분 덕분에 ‘안전하지만 부족한 답’과 ‘내용은 좋지만 실행할 수 없는 답’이 다른 상태와 종료 이유로 남습니다.
판정 모델을 분리하되 비용을 숨기지 않았습니다
생성 모델을 판정에도 그대로 쓰면 연결은 쉽고 비용도 줄어듭니다. 다만 자신이 선호하는 표현에 관대할 수 있고, 생성 과정의 약점을 평가에서도 공유할 수 있습니다. 별도 공급자나 더 강한 모델을 쓰면 독립성은 높아지지만 지연 시간과 비용이 늘어납니다.
하네스는 한 방식을 정답으로 고정하지 않았습니다. 결정 가능한 항목은 규칙 기반 EvaluationStrategy로 검사하고, 자연어 품질은 별도의 judge_provider와 judge_model을 연결할 수 있게 했습니다. 비용이 중요한 환경에서는 본문 모델을 재사용할 수 있지만 그 결과가 독립 평가가 아니라는 점을 설정과 로그에 남깁니다.
판정 모델을 바꾸면 같은 0.8도 같은 척도라고 볼 수 없습니다. 그래서 생성 모델을 비교할 때는 판정기를 고정하고, 판정기를 바꿀 때는 기존 기준 답안의 순서가 유지되는지 다시 확인합니다. 점수 숫자보다 좋은 답이 명백히 부족한 답보다 꾸준히 높게 평가되는지가 중요했습니다.
Reflexion은 비평문이 아니라 다음 회차의 입력이었습니다
판정 결과를 만든 뒤 이를 로그에만 남기면 실행은 달라지지 않습니다. Reflexion 경로는 기준별 미달 사유를 짧은 교정 지시로 바꿔 생성 단계에 돌려보냅니다. 이때 원래 사용자 요청을 대체하지 않고, 이번 후보에서 고칠 내용으로 추가합니다.
재시도는 같은 답을 다시 호출하는 전송 복구가 아닙니다. 판정 피드백을 받은 새로운 생성 회차입니다. 그래서 품질 재시도의 횟수와 도구를 사용하며 진행한 회차를 별도로 기록했습니다. 판정기가 답을 만들거나 생성기가 스스로 통과 여부를 정하지 않게 역할을 유지했습니다.
엔진의 기본 판정 경로는 판정 공급자를 호출하지 못하거나 응답을 해석할 수 없을 때 임의의 점수를 만들지 않고 bypassed 상태와 사유를 반환합니다. 품질 검증이 필수인 제품은 이 상태를 정책으로 차단할 수 있습니다. 다만 일부 기존 QA 어댑터에는 호환성을 위해 판정 예외 시 기본 통과로 이어지는 경로가 남아 있었습니다. 따라서 bypassed가 모든 제품 통합에서 자동으로 실패를 보장한다고 말할 수는 없고, 제품 연결 계층의 실패 정책까지 함께 확인해야 합니다.
캔버스와 독립 실행에서 같은 판정을 확인했습니다
검증은 특정 답에 정확히 같은 소수점 점수가 나오는지를 보지 않았습니다. LLM 판정에는 변동이 있기 때문입니다. 대신 기준을 충분히 만족한 답이 명백히 어긴 답보다 높은지, 필수 조건을 어긴 답이 통과하지 않는지, 반려 피드백을 받은 다음 후보가 부족한 항목을 실제로 바꾸는지 확인했습니다.
같은 기준을 캔버스 노드와 독립 산출물에서 실행해 결과 구조와 전이가 일치하는지도 봤습니다. 전략을 찾지 못하거나 기준 정의가 빠졌을 때 조용히 기본 판정으로 바뀌지 않아야 했습니다. 이 검증을 거치면서 판정 기준은 화면 설정이 아니라 실행 계약의 일부가 됐습니다.
생성과 판정을 나눴다고 답이 자동으로 완벽해지는 것은 아닙니다. 달라진 점은 어느 후보를 어떤 기준으로 반려했고, 그 피드백이 다음 생성에 어떻게 들어갔는지를 설명할 수 있다는 것입니다. 이후에는 ‘점수가 정확히 어느 후보에 속하는가’라는 최신성 문제가 별도 과제로 드러났고, 이는 10편에서 다룹니다. 다음 편에서는 먼저 도구 진행, 전송 복구, 품질 재시도를 구분하고 어디에서 실행을 끝낼지 살펴봅니다.
이전 편 → 고정된 실행 계약을 하나의 MCP 도구로 내보내기(3편) 다음 편 → 재시도와 종료 조건을 분리하는 이유(5편)