HERMES, 저장소 구성 요소를 협업형 코딩 에이전트로 바꾸다

배경

터미널을 사용할 수 있는 대규모 언어 모델은 파일 수정, 테스트 실행, 버그 조사 같은 소프트웨어 작업을 자동화할 수 있다. 하지만 하나의 작업이 여러 소스 파일과 설정, 의존성, 테스트, 실행 시 동작을 넘나들면 에이전트의 안정성은 빠르게 떨어진다. 에이전트는 흩어진 정보에서 프로젝트 상태를 반복적으로 복원해야 하고, 대화 기록이 길어지면서 컨텍스트가 커지고 의미가 흔들릴 수 있다. 대규모 저장소에서는 실제로 관련된 구성 요소를 찾는 일도 어렵다.

Hugging Face Daily Papers에 소개된 HERMES는 이 문제를 모델 규모만으로 해결하지 않고, 모델이 소프트웨어와 상호작용하는 작업 환경을 다시 설계하는 접근을 제시한다.

Dev-Primitives란 무엇인가

HERMES의 핵심 추상화는 Development Primitives를 뜻하는 Dev-Primitives다. 연구진은 코드 모듈, 테스트 등 저장소의 소프트웨어 산출물에 상주형 언어 모델을 연결한다. 연결된 모델은 구성 요소를 외부에서 수동으로 관찰하는 데 그치지 않고, 해당 요소의 구현과 의존성을 바탕으로 에이전트 친화적인 인터페이스를 제공한다.

이 구조는 세 가지 기능을 목표로 한다.

• 국소적 추론: 각 구성 요소가 자신의 책임, 구현, 제약을 중심으로 설명하므로 매번 저장소 전체를 컨텍스트에 넣을 필요가 줄어든다.
• 구성 요소 간 통신: 여러 프리미티브가 자연어로 상태, 가정, 수정 제안을 공유할 수 있다.
• 국소적 수정: 실행 결과를 통해 문제가 특정 요소로 좁혀지면 해당 프리미티브가 집중적인 변경을 제안하거나 지원한다.

HERMES는 의존성을 고려한 동적 활성화 방식으로 이 프리미티브를 저장소 수준에서 운영한다. 모든 요소를 동시에 깨우는 대신 작업 내용과 의존성 구조를 바탕으로 관련성이 높은 요소를 선택한다. 또한 테스트나 실행 과정에서 얻은 증거를 수정이 필요한 구성 요소에 연결하는 버그 진단 기능도 포함한다. 결과적으로 실행, 진단, 대상 수정의 반복 루프를 구축하는 것이 목표다.

실험 결과와 해석

네 가지 소프트웨어 엔지니어링 벤치마크에서 HERMES는 대응하는 기준선보다 평균 12.4% 높은 성능을 보고했다. 강력한 활성화 모델과 진단 모델을 함께 사용할 경우, Dev-Primitives에 Qwen3-8B를 사용한 구성도 네 벤치마크 전체에서 GPT-5.6 Sol을 일관되게 사용하는 구성과의 차이를 4.5% 이내로 유지했다. Terminal-Bench 4.0에서는 추론 비용을 26.2% 줄였다.

이 결과가 작은 모델이 언제나 강력한 모델을 대체한다는 뜻은 아니다. 대신 작업 분해, 컨텍스트 라우팅, 실패 원인 추적이 코딩 에이전트의 품질과 비용에 큰 영향을 줄 수 있음을 보여준다. 모델이 아무리 강해도 관련 없는 저장소 정보를 반복해서 처리하거나 실행 오류를 올바른 파일과 연결하지 못하면 효율은 낮아진다.

의미와 남은 과제

HERMES는 저장소를 정적인 파일 묶음이 아니라, 각자 제한된 지식을 갖고 협력하는 실행 단위의 집합으로 바라본다. 이 관점은 장기 작업의 컨텍스트 부담을 줄이고, 버그 수정 과정을 실행 증거 중심으로 바꿀 가능성이 있다.

다만 활성화와 진단 모델의 품질이 전체 성능에 영향을 준다. 프리미티브의 경계를 어떻게 정할지, 자연어 통신에서 발생하는 오해를 어떻게 줄일지, 국소적인 수정이 전체 시스템의 일관성을 해치지 않도록 어떻게 검증할지는 여전히 중요한 과제다. 그럼에도 이 연구는 코딩 에이전트의 발전이 모델 크기뿐 아니라 모델과 소프트웨어를 연결하는 인터페이스 설계에도 달려 있음을 보여준다.

출처: Hugging Face Daily Papers