오랫동안 OpenAI 내부에서는 “모델 회사는 모델만 만들어야 한다”는 공감대가 있었습니다. 그런데 최근 Greg Brockman이 공개적으로 그 입장을 뒤집었습니다. 그것도 혼자가 아닙니다.
AI 뉴스레터 Latent Space가 5월 초 업계 동향을 정리하면서, 모든 주요 모델 회사가 에이전트 개발로 피벗하고 있다는 흐름을 짚었습니다. 때마침 O’Reilly도 “하네스 설계가 모델 선택보다 성능을 더 크게 좌우한다”는 논의를 다루며 같은 지점을 가리키고 있었습니다.
출처: [AINews] All Model Labs are now Agent Labs – Latent Space
모든 모델 랩이 에이전트 랩으로
몇 주 사이에 여러 곳에서 비슷한 움직임이 동시에 나왔습니다.
OpenAI의 Greg Brockman은 “모델 단독으로는 더 이상 제품이 아니다”라고 밝혔습니다. AI21은 모델 팀을 해체하고 에이전트 개발로 완전히 방향을 틀었습니다. DeepSeek는 처음으로 “Harness team”을 신설했습니다. 그동안 모델 성능 경쟁에만 집중하던 곳들이 일제히 같은 결론에 도달한 셈입니다.
업계 관계자들이 공유한 시각도 비슷합니다. 승리하는 제품은 이제 모델 하나가 아니라 모델 + 하네스 + 워크플로우 + UI + 메모리 + 경제성의 조합이라는 것입니다.
하네스란 무엇이고, 왜 모델보다 중요해졌나
하네스(harness)는 모델 주변에 감싸는 구조 전체를 뜻합니다. 어떤 도구를 쓸 수 있는지, 어떤 순서로 작동하는지, 어떤 맥락을 기억하는지를 정의하는 것들이 모두 여기 해당합니다. Claude Code 같은 도구가 대표적인 예입니다.
GitHub Copilot 초기 엔지니어인 John Berryman은 AI 제품 개발의 흐름을 이렇게 정리합니다.
- 문서 자동완성
- 챗 인터페이스
- 툴 호출 에이전트
- DAG 기반 워크플로우
- 하네스 중심 설계
단계가 올라갈수록 모델이 할 수 있는 일은 늘었지만, 신뢰성과 제어의 문제도 함께 커졌습니다. 그리고 지금은 하네스를 잘 설계하는 것이 어떤 모델을 고르는 것보다 실제 성능에 더 큰 영향을 준다는 것을 Stanford 연구가 뒷받침합니다.
전문가가 “영어로 코드를 읽는” 시대
하네스 설계가 중요해진 데는 또 다른 이유가 있습니다. 도메인 전문가가 직접 에이전트의 동작을 이해하고 수정할 수 있게 됐다는 점입니다.
Berryman이 소개한 사례를 보면, 그는 복잡한 맞춤형 애플리케이션 대신 에이전트 하네스에 “스킬(skills)”만 정의해서 납품했습니다. 스킬은 에이전트가 특정 상황에서 어떻게 행동해야 하는지를 평문 영어로 기술한 것입니다. 개발 경험이 없는 도메인 전문가도 그 내용을 읽고 문제를 파악하거나 직접 수정할 수 있었습니다.
개발자와 비개발자 사이의 병목이던 “이 기능이 왜 이렇게 작동하나요?”라는 질문이 에이전트 하네스 안에서 사라지기 시작했습니다.
모델 선택에서 하네스 설계로
“어느 모델이 가장 좋은가”는 여전히 의미 있는 질문입니다. 하지만 실제 제품 성능에서 그보다 더 결정적인 질문이 생겼습니다. “어떤 하네스를 만들었는가.”
모델 회사들이 직접 에이전트를 만들기 시작한 것도 이 흐름의 연장입니다. 모델 위에 하네스를 얹어 제품을 완성하는 구조에서, 하네스를 직접 통제하는 쪽이 사용자를 자신의 생태계에 묶어둘 수 있다는 계산이 깔려 있습니다.
참고자료:
- This Week in AI: Rethinking the Agent Harness – O’Reilly Radar
- Stanford 연구: 하네스 설계가 모델 선택보다 성능 차이를 크게 만든다 – arXiv
답글 남기기