Qoder Better Harness: AI 코딩 에이전트의 ‘작업 환경’을 평가하는 방법

AI 코딩 에이전트의 성과가 들쑥날쑥할 때 문제는 모델 하나에만 있지 않을 수 있다. 저장소 지침이 모호하거나, 테스트 실행 시점이 불분명하거나, 규칙 파일이 실제 작업에 반영되지 않는 경우처럼 에이전트를 둘러싼 작업 환경 자체가 병목이 될 수 있다.

Qoder의 Better Harness는 바로 이 환경을 검토하고 개선하기 위한 오픈소스 프로젝트다. 특정 모델의 한 번의 답변이나 코드 변경분만 평가하는 대신, 프로젝트 지침과 통제 장치, 검증 경로, 에이전트 설정, 지원되는 경우 실제 세션에서 일어난 작업 기록까지 살핀다. 확인된 공백에는 범위를 제한한 수정안을 제시하고, 다음 실행에서 그 수정이 충족됐는지 검증할 수 있게 하는 것이 목표다. 124

보도에 따르면 Qoder는 2026년 7월 28일 GitHub에서 Better Harness를 오픈소스로 공개했다. 5

핵심은 모델만이 아니라 ‘하네스’를 평가하는 것

코딩 에이전트는 독립적으로 일하지 않는다. 저장소 안내 문서, 명세, 도구, 권한, 스크립트, 테스트, 코드 리뷰 요건, 릴리스 점검, 사람의 인수 절차 안에서 작동한다. Qoder는 이 주변 환경을 **하네스(harness)**라고 부른다. 문서상 하네스에는 저장소 지침, 규칙, 스킬, 훅, 플러그인, 커넥터, 스크립트, 테스트 명령, 릴리스 점검, 사람의 검토 단계 등이 포함될 수 있다. 2

이 구분이 중요한 이유는 모델의 코딩 능력이 좋아도 주변 워크플로가 불명확하거나 관측되지 않으면 결과가 신뢰하기 어려울 수 있기 때문이다. 예컨대 테스트 명령은 있지만 에이전트가 언제 실행해야 하는지 알 수 없을 수 있다. 규칙 파일은 있어도 에이전트가 이를 쓰지 않을 수 있다. 실패한 작업에서 얻은 교훈을 다음 작업에 남기는 체계도 없을 수 있다. Better Harness는 구성 파일의 존재만으로 프로세스가 제대로 작동한다고 보지 않고, 이런 운영상의 취약점을 찾도록 설계됐다. 145

3계층 구조: 실무, 평가 모델, 실행 가능한 구현

Better Harness는 엔지니어링 실무와 평가 모델, 실제 실행 구현을 연결하는 3계층 프레임워크로 소개된다. 5

1. Harness Engineering 실무

첫 번째 계층은 에이전트의 작업 방식을 형성하는 실질적 장치들이다. 세션 및 CLI 패턴, 관측 가능성, 규칙, 스킬, MCP 설정, 메모리, 훅, 자동화 등이 여기에 속한다. 5

이 계층에서는 다음과 같은 질문을 던질 수 있다.

• 에이전트가 목표, 제약 조건, 저장소 맥락을 명확하게 받는가?
• 실행 경로와 권한은 적절히 통제되는가?
• 에이전트 작업이 테스트·점검·리뷰 절차와 연결되는가?
• 세션이 끝나도 유용한 교훈이 유지·관리되는 프로젝트 자산으로 남는가?

Better Harness는 먼저 목표, 맥락, 실행 진입점, 피드백 루프, 배포 방식, 학습 내용의 보존 방식을 포함해 현재 하네스를 지도화한다. 1

2. Agent Work Loop 평가

두 번째 계층은 이런 실무를 연결된 5개 배포 품질 항목으로 평가한다. Qoder 자료는 이를 작업 이해, 통제된 실행, 변경 검증, 신뢰할 수 있는 배포, 학습 내용의 포착으로 설명한다. 14

따라서 질문은 “에이전트가 그럴듯한 코드를 만들었는가?”에서 다음과 같이 바뀐다.

이 엔드투엔드 워크플로는 이해 가능하고, 통제되며, 검증되고, 배포 가능하며, 이전 작업에서 배운 내용을 반영한 변경을 반복적으로 만들 수 있는가?

이 모델은 특정 연결 고리를 찾아낸다. 필요한 장치가 빠졌는지, 통합이 끊겼는지, 단계가 실제로 실행되지 않았는지, 결과를 뒷받침할 증거가 충분하지 않은지 등을 살피는 방식이다. 1

3. 실행 가능한 구현

세 번째 계층은 실무 원칙과 평가 모델을 문서상의 가이드에만 머물지 않게 한다. Better Harness는 코딩 에이전트를 통해 실행되며, 지원 범위 안에서 프로젝트 및 세션 증거를 수집해 우선순위가 매겨진 다음 단계와 검증 방법을 제시한다. 4

현재 프로젝트 자료는 10개의 호스트 어댑터 지원을 설명한다. 공개 당시 보도에서는 지원 코딩 에이전트 환경으로 Claude Code, Codex, Qoder, Cursor 등이 언급됐다. 56

다만 어댑터 지원 범위는 바뀔 수 있으므로, 특정 호스트와의 통합 여부는 최신 어댑터 문서에서 확인할 필요가 있다. 특히 제공된 자료만으로는 OpenClaw 지원 여부를 확인할 수 없다.

증거는 어떻게 수집하나

이 접근의 특징은 증거 수집과 최종 평가를 분리한다는 점이다. Qoder에 따르면 주 분석 흐름이 원시 데이터를 수집한 뒤, 이를 서로 독립적이고 읽기 전용인 3개 하위 에이전트에 전달하고 결과를 종합한다. 1

세 관점은 다음과 같다.

• Project Harness: 저장소의 엔지니어링 기반. 지침, 스크립트, 점검, 배포 통제 등이 대상이다.
• Agent Customization: 에이전트별 규칙, 스킬, 훅 및 기타 설정을 본다.
• Session Evidence: 증거를 사용할 수 있는 경우, 실제 작업 중 에이전트가 무엇을 했는지 기록을 살핀다.

이 구분은 의도된 프로세스와 실제로 관찰된 프로세스를 분리하는 데 도움이 된다. 프로젝트와 설정 증거는 어떤 기능을 사용할 수 있다는 사실을 보여줄 수 있다. 세션 증거는 실제 과제에서 그 기능이 적절히 사용됐는지 확인하는 데 쓰일 수 있다. 14

‘있다’와 ‘작동한다’는 다르다

프레임워크에서 가장 실용적인 원칙은 산출물의 존재가 효과의 증거는 아니라는 것이다.

자동화 테스트 모음이 있는 저장소를 생각해 보자. 테스트가 존재한다는 것은 잠재적 역량을 의미한다. 하지만 에이전트가 변경 뒤에 관련 테스트를 실행했는지, 결과를 올바르게 해석했는지, 그 결과가 잘못된 배포를 막는 데 사용됐는지는 별개의 문제다. 규칙, 훅, 스킬, 승인 게이트도 마찬가지다. 15

Better Harness는 그래서 증거 사슬을 명시적으로 유지하려 한다. 보고서는 뒷받침되는 공백을 영향, 기대 산출물, 제한된 범위의 수정안, 수용 조건을 포함한 우선순위 Finding으로 전환한다. 증거가 빠진 부분은 확신에 찬 점수로 조용히 바꾸지 않고 그대로 드러낸다. 46

좋은 Finding이라면 팀이 적어도 다음 네 가지를 점검할 수 있어야 한다.

1. 프로젝트·설정·세션 기록에서 무엇이 관찰됐는가
2. 그것이 작업 루프에서 왜 중요한가
3. 규칙, 스킬, 훅, 스크립트, 자동화, 사람의 승인 단계 등 어떤 범위 제한형 수정이 제안됐는가
4. 수정 후 어떻게 검증할 것인가

점검하고, 고치고, 다시 측정하는 반복 구조

Better Harness는 일회성 감사 도구로만 제시되지 않는다. 흐름은 반복적이다.

1. 현재 하네스를 지도화한다.
2. 워크플로의 단절 지점과 증거 공백을 찾는다.
3. 근거가 있는 Finding에 대해 범위가 제한된 수정 작업을 만든다.
4. 정의된 수용 조건으로 수정을 검증한다.
5. 다시 검토해 갱신된 증거를 확인한다. 14

이것이 지속적 개선이라는 주장에 대한 기반이다. 도구는 워크플로가 바뀌었는지, 새로운 증거가 더 나은 평가를 뒷받침하는지 보여줄 수 있다. 그러나 수정 하나가 모든 프로젝트나 호스트 환경에서 에이전트 성능을 높였다고 단독으로 증명하는 것은 아니다. Qoder 자료도 점수 변화를 인과 증명으로 취급하기보다, 관찰된 증거와 명시적 한계를 강조한다. 46

30개 GitHub 프로젝트 검토는 어떻게 봐야 하나

공개 당시 보도에 따르면 이 프레임워크는 실제 GitHub 프로젝트 30개를 대상으로 한 초기 적용에 사용됐다. 5 이는 Better Harness가 여러 저장소에서 반복되는 하네스 공백을 드러낼 수 있음을 살핀 탐색적 적용 사례로 보는 편이 적절하다. 모든 코딩 에이전트나 저장소에서 개선 효과를 보장한다는 통제된 실증으로 해석해서는 안 된다.

제공된 1차 문서는 도구의 증거 모델, Finding 구조, 반복적 수정 흐름을 뒷받침한다. 다만 제공 자료만으로는 30개 프로젝트의 표본 선정 방식, 점수 산정 절차, 종합 결과를 독립적으로 평가할 만큼의 1차 세부 정보를 확인하기 어렵다. 정식 벤치마크와 비교하거나 광범위한 성능 주장을 할 때는 이 한계를 고려해야 한다. 14

더 측정 가능한 에이전트 엔지니어링을 향해

Qoder가 제시하는 더 큰 방향은 Harness Engineering을 AI 보조 소프트웨어 개발의 품질 인프라로 만드는 것이다. 워크플로 통제 장치에 대한 공통 언어, 관찰 가능한 증거, 비교 가능한 배포 품질 항목, 반복 가능한 개선 주기를 갖추자는 구상이다. 12

Better Harness는 이를 실무에 적용할 수 있는 형태로 제시한다. 지원되는 여러 호스트에서 에이전트 작업의 주변 조건을 점검하고, 인상이나 추측보다 증거를 바탕으로 논의하며, 제안한 워크플로 수정이 이후 실행에서도 유지되는지 시험하도록 돕는다. 모든 수정의 성공을 보장하는 도구는 아니지만, AI 코딩 워크플로를 더 살펴볼 수 있고, 검토할 수 있으며, 반증 가능한 대상으로 만든다는 데 의미가 있다. 46