에이전트 하네스 설계 · 7/10
6월 24일, 같은 코드 생성 워크플로우를 복제해 한쪽에는 내부 배포한 Qwen3.6-27B를, 다른 쪽에는 Claude Sonnet 4.6을 연결하고 실제 동작을 비교하기 시작했습니다. 첫 결과는 Qwen 2,488초, Sonnet 84초였습니다. 숫자만 보면 한 모델이 약 30배 느리다고 결론 내리기 쉽습니다.
하지만 실행 기록을 열어 보면 측정한 대상이 달랐습니다. Qwen 쪽은 긴 출력을 만든 뒤 품질 판정을 거쳐 새 후보를 만드는 과정이 반복됐습니다. 2,488초에는 한 번의 모델 응답 속도뿐 아니라 출력량, 반복 횟수, 판정과 도구 대기 시간이 모두 들어 있었습니다. 이름은 모델 비교였지만 실제로는 모델과 하네스 설정을 합친 두 실행을 비교하고 있었습니다.
앞 편에서 설정 탐색기를 만들었다고 실험 조건이 자동으로 공정해지는 것은 아닙니다. 자동 탐색은 다음 설정 후보를 찾는 장치이고, 벤치마크는 비교할 두 실행의 조건을 명시적으로 고정하는 작업입니다. 이미 마련된 상태·판정·종료 기록을 이용해 두 모델이 정말 같은 일을 했는지부터 다시 확인했습니다.
모델 이름만 바꾸면 변수는 하나가 아니었습니다
두 모델에 같은 질문을 보내면 입력은 같아 보입니다. 하지만 공급자별 기본 출력 상한이 다를 수 있고, 한 모델만 품질 재시도를 여러 번 거칠 수도 있습니다. 도구 결과를 빈 응답으로 받으면 같은 도구를 반복해서 부를 수 있습니다. 최종 답의 길이가 다르면 생성 시간뿐 아니라 판정 시간도 함께 달라집니다.
총 실행 시간과 최종 점수만 표에 적으면 숫자가 달라진 이유를 설명할 수 없습니다. 느린 모델이 실제 추론에 오래 걸린 것인지, 더 긴 답을 만든 것인지, 하네스가 한 번 더 실행한 것인지가 섞이기 때문입니다.
비교 실행에서는 생성에 쓰는 주 모델만 바꾸기로 했습니다. 과제와 입력 데이터, 시스템 지시문, 연결 도구를 그대로 두고 최대 반복 횟수와 품질 재시도 횟수, 출력 토큰 상한, 종료 조건을 맞췄습니다. 평가 기준과 판정 모델도 고정했습니다. 생성 모델과 판정 모델을 함께 바꾸면 생성 능력의 차이와 채점 성향의 차이를 분리할 수 없습니다.
이 조건은 실행 전에 스냅샷으로 남겼습니다. 결과에는 모델 이름뿐 아니라 과제와 설정, 판정기 버전을 함께 기록했습니다. 같은 이름의 워크플로우라도 설정이 바뀌었다면 같은 실험으로 합치지 않았습니다.
반복과 출력 상한을 맞추자 30배가 사라졌습니다
첫 실행을 같은 범위에서 다시 보기 위해 max_iterations=1, max_tokens=4096로 맞췄습니다. 그러자 Qwen의 실행 시간은 약 100초로 줄었습니다. 모델을 바꾸지 않았는데도 2,488초에서 약 25분의 1이 된 것입니다.
이 결과가 Qwen과 Sonnet의 속도가 같다는 뜻은 아닙니다. 최초의 30배 차이를 모델 추론 속도라고 부를 수 없다는 뜻입니다. 품질 재시도를 허용한 실행과 한 번만 생성한 실행은 서로 다른 실험입니다. 긴 답이 필요한 과제라면 4,096토큰이 부족할 수도 있습니다. 특정 상한을 정답으로 고르는 대신 두 모델에 같은 상한을 적용하고 실제로 상한에 닿았는지 남겼습니다.
이후부터 총시간을 하나로 보지 않았습니다. 모델 호출, 품질 재시도, 도구 호출이 각각 몇 번 일어났는지와 입력·출력 토큰을 함께 봤습니다. 종료 이유가 정상 완료인지 반복 또는 출력 상한인지도 나눴습니다. 짧은 실행이 더 효율적인 결과인지, 단순히 덜 생성하고 중간에 멈춘 것인지 구분하기 위해서입니다.
조건을 맞춘 뒤에도 남는 차이를 봤습니다
통제된 설정으로 도구를 사용하지 않는 여섯 개의 실무 분석·전략 과제를 다시 실행했습니다. 원격근무, B2B SaaS 진입 전략, 데이터 프로젝트 실패, 앱 마케팅, 스마트팩토리 로드맵, 이탈 개선처럼 코드 생성과는 다른 과제였습니다. 두 경로의 판정 모델은 Claude Sonnet 4.6으로 고정했습니다. 두 생성 모델의 판정 점수는 모두 0.921.00 범위였고, 과제별 차이는 0.010.05 정도였습니다. 이 과제 묶음에서는 품질 점수 차이가 크지 않았습니다.
반면 실행 시간 차이는 반복해서 나타났습니다. Qwen은 과제당 7392초, Sonnet은 3852초가 걸렸습니다. 최초의 30배와는 전혀 다른 크기지만, 같은 설정과 여섯 과제 안에서는 Qwen이 대체로 두 배가량 오래 걸렸습니다.
이제야 숫자의 범위를 제한해서 말할 수 있었습니다. ‘Qwen은 Sonnet보다 항상 느리다’가 아니라 ‘고정한 하네스 설정과 도구 없는 여섯 개의 실무 과제에서는 판정 점수가 비슷했고 실행 시간 차이가 반복해서 관찰됐다’가 확인한 사실입니다. 판정기가 비교 대상 중 하나와 같은 모델 계열이라는 점, 과제 수가 적다는 점 때문에 일반적인 모델 순위로 확장할 수는 없습니다.
평균 하나로도 결론을 내리지 않았습니다. 특정 과제에서만 도구 루프가 길어질 수 있고 공급자 부하와 네트워크 상태도 달라집니다. 과제별 분포와 최댓값, 반복 실행의 중앙값과 편차를 함께 봐야 느린 몇 건이 평균을 끌어올렸는지 지속적인 차이인지 알 수 있습니다.
도구 조건은 별도 비교 항목으로 분리했습니다
앞의 여섯 과제는 모델과 기본 실행 경로를 보기 위해 도구를 연결하지 않았습니다. 도구 조건까지 한 실험에 섞으면 호출 선택과 외부 응답 시간이 모델 생성 시간에 더해지기 때문입니다. 도구를 사용하는 비교는 별도 실행으로 나눴고, 여기서는 두 모델에 같은 도구 계약이 전달되는지를 확인했습니다.
도구 결과가 다른 의미로 전달되면 조건은 통제되지 않습니다. 도구가 예외 없이 끝났지만 빈 문자열을 반환했는데 하네스가 이를 성공으로 기록하면, 모델은 필요한 정보를 얻지 못한 채 같은 도구를 다시 부를 수 있습니다. 로그에는 모델이 헤매는 것처럼 보이지만 원인은 도구 결과 계약에 있습니다.
비교용 도구는 사용할 수 있는 결과가 있는 성공과 결과 없음이라는 정상 응답을 구분했습니다. 잠시 뒤 복구할 수 있는 오류와 입력을 고쳐야 하는 영구 오류도 나눴습니다. 모델에 전달하는 관측과 하네스가 기록하는 상태가 같은 의미를 가져야 모델마다 오류 대응 방식이 벤치마크에 섞이지 않습니다.
도구 선택도 같아야 합니다. 한쪽 실행만 전체 도구 스키마를 처음부터 보고 다른 쪽은 검색을 거쳐야 한다면 모델 호출 조건이 달라집니다. 연결 도구와 공개 방식, 검색 결과를 고정하고 실제 호출까지 같은 경로로 이어지는지 확인했습니다.
모델 비교는 하네스의 검증이기도 했습니다
실험 전에는 설정 스냅샷을 고정하고, 실행 중에는 단계별 시간과 반복 이유, 토큰과 도구 결과를 기록했습니다. 실행 후에는 같은 판정기로 과제별 결과를 평가했습니다. 이 과정을 거치자 두 모델의 차이뿐 아니라 과도한 품질 재시도, 잘못 분류된 도구 결과, 필요 이상으로 큰 출력 상한도 함께 보였습니다.
벤치마크는 모델 이름 두 개와 시간 표를 만드는 작업이 아니었습니다. 하네스가 실행 차이를 어디까지 설명할 수 있는지 확인하는 작업이었습니다. 느린 이유를 모델 추론, 공급자 대기, 도구 사용, 품질 재작성으로 나눌 수 있어야 모델 차이도 읽을 수 있습니다.
이 실험이 끝나갈 무렵에는 한 실행의 설정뿐 아니라 다음 실행에 무엇을 이어 줄지도 중요한 문제로 떠올랐습니다. 같은 실패와 교정을 매번 처음부터 반복하지 않으려면 대화 전체가 아니라 재사용할 가치가 있는 작은 상태를 적절한 범위에 저장해야 합니다. 다음 편에서는 실행 내 작업 메모와 실행 간 메모리를 나누고 네 가지 적용 범위를 설계한 과정을 다룹니다.
이전 편 → 판정 점수로 설정 후보를 탐색하는 방법(6편) 다음 편 → 실행 간 메모리의 범위와 우선순위 설계(8편)