AI 에이전트 성능, 모델보다 인프라가 더 중요하다...에이전트 하네스 엔지니어링의 떠오르는 패러다임
2026년 4월 30일
2분
AI 에이전트의 성능은 모델 자체보다 그 주변의 인프라와 설정이 더 큰 영향을 미친다는 주장이 확산 중이다.
[한국정보기술신문] 구글의 웹 개발자 옹호자 애디 오스마니가 최근 발표한 에이전트 하네스 엔지니어링 원칙이 AI 업계에서 큰 주목을 받고 있다. 그는 "형편한 모델에 뛰어난 하네스가 뛰어난 모델에 형편한 하네스를 이긴다"고 주장하며 AI 에이전트 개발 패러다임의 전환을 제시했다. 이는 그동안 더 강력한 모델 개발에 집중해온 AI 업계에 새로운 관점을 던지고 있다.
에이전트 하네스란 무엇인가
에이전트 하네스는 AI 모델을 감싸고 있는 일종의 비계다. 시스템 프롬프트, 외부 도구, 실행 환경, 오케스트레이션 로직, 피드백 메커니즘이 모두 포함된다. 이들 요소들이 조화를 이루어야만 에이전트가 목표한 작업을 올바르게 수행할 수 있다는 것이 핵심이다.
기존에는 에이전트가 실패하면 모델의 한계로 돌렸다. 하지만 오스마니의 주장에 따르면 대부분의 문제는 하네스 구성의 미흡함에 있다. 즉, 적절한 설정과 인프라를 통해 더 약한 모델도 충분히 뛰어난 성능을 낼 수 있다는 의미다.
하네스의 핵심 구성 요소들
성공적인 에이전트를 위해서는 여러 인프라 요소가 필요하다. 먼저 파일시스템과 버전 컨트롤 시스템은 에이전트의 상태를 지속적으로 유지하기 위해 필수적이다. 다음으로 샌드박스 실행 환경은 에이전트가 안전하게 코드를 실행하고 시스템을 보호할 수 있도록 한다.
컨텍스트 관리 기법들은 에이전트가 장시간 작업할 때 발생하는 컨텍스트 부패 문제를 해결한다. 계획과 검증 루프는 복잡한 작업을 단계별로 해결하도록 유도한다. 마지막으로 실행 강제 훅은 에이전트의 일관성 있는 행동을 보장한다.
오류 방지에서 배우는 구조 설계
오스마니가 강조하는 중요한 원칙은 각 오류를 영구적인 안전장치로 변환하는 것이다. 에이전트가 특정 명령으로 실패하면 그 명령은 차단되고, 부적절한 행동이 발생하면 가이드라인이 업데이트된다. 이렇게 하면 같은 실수가 반복되지 않는다.
이러한 방식은 마치 성숙한 소프트웨어 엔지니어링 관행과 비슷하다. 마치 테스트 주도 개발처럼, 에이전트 개발에서도 각 실패 사례가 하네스를 더욱 견고하게 만드는 밑거름이 된다는 의미다.
도구는 많을수록 좋지 않다
하네스 설계의 또 다른 원칙은 도구의 선택에 있다. 에이전트가 사용할 수 있는 도구가 많을수록 항상 좋은 것은 아니다. 오히려 에이전트가 필요로 하는 도구들만 정교하게 선택하고 큐레이팅해야 성능이 높아진다.
예를 들어, 명확하게 정의된 소수의 도구가 있는 에이전트가 매우 많은 도구를 가진 에이전트보다 더 정확한 작업을 수행할 수 있다는 것이다. 이는 과도한 선택지가 에이전트의 판단을 흐리게 만들 수 있기 때문이다.
업계에서의 수렴 현상
흥미롭게도 현재 주요 코딩 에이전트들이 하네스 구조에서 비슷한 패턴을 보이고 있다. 클로드 코드, 커서, 코덱스 등 다양한 기업의 제품들이 각각 다른 기반 모델을 사용하면서도 구조적으로는 점점 비슷해지고 있다는 뜻이다.
이는 에이전트 하네스 설계에 있어 보편적인 원칙들이 수렴하고 있다는 신호다. 업계 전체가 어떤 인프라 구조가 효과적인지에 대해 암묵적인 합의를 이루어가고 있다는 것이다.
문서화와 추적 가능성의 중요성
오스마니는 에이전트를 위한 문서화도 실제 오류 사례와 연결되어야 한다고 강조한다. 단순히 기술 명세를 나열하는 것은 의미가 없고, 각 가이드라인이 어떤 실제 문제를 해결하기 위해 만들어졌는지 추적 가능해야 한다는 뜻이다.
이러한 원칙들이 정착되면 에이전트 개발은 더욱 체계적이고 과학적인 분야가 될 것으로 보인다. 더 이상 "이 모델은 왜 이렇게 답답한가"라는 질문만 하는 것이 아니라, "우리의 하네스를 어떻게 더 개선할 수 있는가"라는 질문으로 초점이 옮겨갈 것이기 때문이다.
한국정보기술신문 인공지능분과 이세정 기자 news@kitpa.org
