모델보다 하네스: AI 에이전트 성능은 어디서 갈리는가

2026년 에이전트 글들을 읽다 보면 AI harness, agent workflow stack, tool orchestration 같은 표현이 자주 보인다. 아직 완전히 굳은 업계 표준어라고 말할 수는 없다. 다만 모델 하나를 잘 고르는 문제보다, 모델이 실제 일을 하도록 둘러싼 작업대가 중요해졌다는 흐름은 분명해지고 있다.

AI Agents Directory의 2026년 7월 5일 브리프는 에이전트 사용 표면이 브라우저 확장 기반 자동화 같은 쪽으로 넓어지는 흐름을 다룬다. The Nuanced Perspective의 The AI Agent Stack in 2026도 에이전트가 IDE, Slack threads, browser, dashboard, approval queues 같은 여러 작업 표면에 들어간다는 관점을 제시한다.

이 두 흐름을 묶어 보면 질문이 조금 바뀐다.

AI가 똑똑한가가 아니라, AI가 일을 끝낼 수 있는 환경 안에 들어가 있는가.

즉, 내가 관심을 두는 지점은 모델 호출 자체가 아니라 하네스 엔지니어링이다.

하네스는 프롬프트가 아니다

프롬프트는 명령문이다. 하네스는 실행 환경이다.

“좋은 글을 써줘”라고 말하는 것은 프롬프트다. 그런데 실제 작업은 그 한 문장으로 끝나지 않는다. 어떤 자료를 읽을지, 어떤 도구를 쓸지, 어디까지 자동으로 처리하고 어디서 사람 승인을 받을지, 실패했을 때 어떻게 되돌릴지까지 정해야 한다.

구분	프롬프트	하네스
핵심 질문	무엇을 시킬 것인가	어떤 환경에서 굴릴 것인가
주요 대상	명령문·역할·제약	도구·권한·컨텍스트·평가·로그
실패 양상	답변이 별로임	작업이 중간에 끊김, 검증이 안 됨, 책임 경계가 흐림
개선 방식	지시문 수정	실행 흐름과 회수선 설계

프롬프트는 여전히 중요하다. 다만 프롬프트만으로는 실무 안정성을 다 설명하지 못한다. 모델이 실제 브라우저, IDE, 슬랙, 대시보드, 승인 큐를 건드리기 시작하면 문장 하나보다 주변 구조가 더 큰 변수가 된다.

왜 지금 하네스인가

모델 성능 경쟁은 계속된다. 더 긴 컨텍스트, 더 나은 추론, 더 빠른 응답은 여전히 중요하다. 하지만 실무에서 체감하는 문제는 “모델이 아무것도 모른다”보다 “어제는 됐는데 오늘은 왜 이상하게 굴러가지”에 가깝다.

AIapps의 2026년 7월 AI 업데이트 글은 흐름을 “best model wins”보다 “best fit wins” 쪽으로 설명한다. 모델 단독 승부보다 가격·속도·접근성·일상 사용 적합성이 중요해진다는 이야기다. 나는 이 관점을 에이전트 쪽으로 가져오면 “best harness wins”에 가까워진다고 본다.

다만 이 말은 하네스가 모델 성능을 대체한다는 뜻이 아니다. 좋은 모델은 여전히 바닥 체력이다. 하네스는 그 위에 실무 안정성을 만드는 층이다.

• 모델 성능: 판단력과 언어 처리의 바닥값을 만든다.
• 도구 선택: 모델이 실제 세계에 손을 뻗는 방식을 정한다.
• 컨텍스트 주입: 지금 작업에 필요한 기억과 자료를 공급한다.
• 승인 흐름: 자동화와 사람 판단의 경계를 긋는다.
• 실패 복구: 중간 실패가 전체 사고로 번지지 않게 막는다.
• 관찰성·평가: 잘됐는지, 왜 실패했는지 다시 볼 수 있게 한다.

즉, 모델은 엔진이고 하네스는 작업대다. 엔진이 좋아도 작업대가 흔들리면 결과물은 흔들린다.

내가 말하는 하네스 엔지니어링

나는 하네스 엔지니어링을 이렇게 정의한다.

AI가 일을 하게 만드는 주변 장치의 설계.

여기서 주변 장치는 장식이 아니다. 오히려 에이전트가 “답변 생성기”에서 “작업 수행자”로 넘어갈 때 핵심이 되는 층이다.

내 기준의 하네스는 최소한 여섯 가지를 포함한다.

• 입력 정리: 요청, 자료, 제약, 금지선을 작업 가능한 형태로 나눈다.
• 역할 분리: 조사·초안·검수·발행처럼 성격이 다른 일을 한 모델 호출에 섞지 않는다.
• 도구 연결: 브라우저, 파일, 터미널, API, 슬랙 같은 표면을 필요한 만큼만 연다.
• 병렬 오케스트레이션: 독립적인 조사와 검토는 동시에 돌리고, 결론만 합친다.
• 검증 루프: 빌드, 테스트, 링크 확인, 출처 대조처럼 결과를 실제로 확인한다.
• 회수선: 실패했을 때 멈출 지점, 되돌릴 지점, 사람에게 넘길 지점을 미리 둔다.

Atlan의 2026년 AI agent harness tools 글이 LangGraph, CrewAI, AutoGen, Mastra 같은 프레임워크를 비교 대상으로 다루는 것도 이 맥락에서 볼 수 있다. 특정 프레임워크 하나가 정답이라는 뜻은 아니다. 오히려 이제 비교 대상이 “모델 API”만이 아니라 “작업 흐름을 묶는 틀”로 넓어졌다는 신호에 가깝다.

Microsoft Agent Framework 관련 글도 비슷한 방향에 있다. agent harness를 모델 추론이 실제 도구·워크플로와 만나는 층으로 설명하는 흐름에 속한다. 나는 이 흐름을 외부 용어 그대로 따라가기보다, 내가 정리해온 하네스 엔지니어링과 접속시켜 이해한다.

⇒ 하네스 엔지니어링 = 모델을 실제 작업으로 연결하는 오케스트레이션·도구·권한·평가·관찰성의 설계다.

블로그 작성 에이전트로 보면 더 선명하다

블로그 글 하나를 예로 들면 차이가 바로 보인다. 모델 하나에 “좋은 글 써줘”라고 맡기면 결과가 나올 수는 있다. 하지만 품질이 들쭉날쭉하고, 출처가 섞이고, 발행 가능 상태인지 확인하기 어렵다.

하네스 방식은 다르게 짠다.

단계	역할	핵심 질문
조사	자료 수집·출처 정리	이 글에서 써도 되는 사실은 무엇인가
발제	주장·독자·구성 정리	왜 지금 이 글을 써야 하는가
초안	문체·구조에 맞춰 작성	읽히는 글이 되었는가
검수	사실·규칙·링크 확인	지어낸 말이 없는가, 빌드 규칙을 지켰는가
발행 판단	사람 승인 또는 정책 게이트	지금 공개해도 되는가
사후 확인	라이브 페이지 검증	실제로 올라갔고 깨지지 않았는가

이 구조에서는 모델 하나가 모든 것을 즉흥적으로 처리하지 않는다. 각 단계가 서로 다른 실패를 잡는다. 조사는 사실의 바닥을 만들고, 초안은 독자 경험을 만들고, 검수는 사고를 줄이고, 발행 판단은 책임선을 세운다.

여기서 중요한 건 “에이전트를 많이 붙이면 좋다”가 아니다. 역할을 나눌 이유가 있을 때만 나눈다. 단순한 글감이면 한 흐름으로 충분하고, 복잡한 글감이면 병렬 조사와 별도 검수가 필요하다. 하네스 설계는 자동화 욕심이 아니라 작업의 위험도에 맞는 구조 조정이다.

앞으로의 차이는 호출 능력이 아니라 설계 능력이다

AI를 잘 쓴다는 말은 한동안 프롬프트를 잘 쓴다는 말에 가까웠다. 앞으로도 프롬프트 감각은 필요하다. 하지만 에이전트가 실제 작업 표면으로 들어갈수록 차이는 다른 곳에서 갈린다.

• 어떤 일을 모델에게 맡길지
• 어떤 도구 권한을 줄지
• 어떤 컨텍스트를 넣고 뺄지
• 어디서 병렬화하고 어디서 직렬화할지
• 어떤 검증을 통과해야 완료로 볼지
• 실패했을 때 어디로 회수할지

이 질문들에 답하는 능력이 하네스 설계 능력이다.

나는 “AI harness”라는 말을 새 유행어로 소비하고 싶지는 않다. 아직 표현은 흔들리고, 프레임워크도 계속 바뀐다. 다만 그 말이 가리키는 문제는 꽤 선명하다. 모델은 점점 좋아지고 있는데, 실무 결과물은 여전히 환경에 크게 좌우된다.

즉, 다음 차이는 “어떤 모델을 불렀는가”만으로 나지 않는다. 어떤 하네스 안에서 그 모델을 일하게 했는가에서 난다.