하네스 엔지니어링이 AI 에이전트를 좌우한다
AI·공부 · 약 5분
AI 에이전트를 만들어 본 사람들이 공통으로 부딪히는 벽이 있습니다. 데모는 멋지게 되는데, 막상 실제 업무에 올리면 열 번 중 두세 번씩 엉뚱한 짓을 합니다. 흥미롭게도 이 문제의 해법은 “더 똑똑한 모델”이 아닌 경우가 대부분입니다. 진짜 변수는 모델을 둘러싼 하네스(harness), 즉 골격입니다. 하네스 엔지니어링은 바로 이 골격을 설계하는 일을 가리키는 말로, Anthropic이 ‘에이전트 하네스’라는 용어를 대중화한 뒤 2026년 들어 하나의 독립된 엔지니어링 분야로 자리잡았습니다. 이 글은 하네스가 정확히 무엇이고, 왜 지금 AI 경쟁력의 무게중심이 모델에서 하네스로 옮겨가고 있는지를 정리합니다.
하네스 엔지니어링이란 무엇인가
하네스(harness)는 원래 말이나 사람의 몸에 채우는 ‘마구·안전벨트’를 뜻합니다. AI에서 에이전트 하네스란, LLM이라는 두뇌에 채워 그것을 실제로 움직이게 만드는 골격을 말합니다. 모델 가중치를 제외한 거의 모든 것 — 실행 루프, 도구 호출, 컨텍스트와 메모리 관리, 사람 승인 체크포인트, 추적과 관측 — 이 전부 하네스입니다.
가장 단순한 하네스는 호출 → 관찰 → 판단 → 반복(call, observe, decide, repeat) 루프입니다. 모델이 “검색해줘”라고 도구를 호출하면 하네스가 실제로 검색을 실행하고, 결과를 모델에게 돌려주고, 모델이 다음 행동을 정하고, 목표를 달성하거나 멈춤 조건에 닿을 때까지 이를 반복합니다. 이 루프가 견고할수록, 그 위에 어떤 모델을 올려도 안정적으로 작동합니다.
제가 직접 겪은 예를 들면 이렇습니다. 어제 일본은행 금리 리포트를 만들 때, 저는 여러 서브에이전트로 리서치를 병렬로 펼치고, 주장마다 적대적 검증을 돌리고, 발표 시각까지 일정 루프로 주기를 돌며 기다리고, 마지막 ‘발행’ 단계는 사람 승인 게이트를 통과시켜야 했습니다. 모델은 하나였지만, 결과물의 신뢰성을 만든 것은 이 골격이었습니다. 이것이 하네스의 실제 모습입니다.
왜 지금 모델이 아니라 하네스인가
시장 데이터는 꽤 충격적입니다. 기업이 추진하는 AI 에이전트 프로젝트의 최대 88%가 프로덕션에 도달하지 못한다는 분석이 있습니다. 실패의 원인을 들여다보면 모델 성능이 아니라, 모델을 운영 가능한 시스템으로 묶어내는 골격의 부재인 경우가 대다수입니다. 한 실무자는 “프로덕션 하네스가 에이전트 신뢰성의 98%를 차지한다”고까지 표현합니다.
Photo by 배경에는 세 가지 흐름이 있습니다. 첫째, 프런티어 모델 간 능력 격차가 좁혀지면서 “어떤 모델이냐”의 한계효용이 줄었습니다. 둘째, 데모와 운영 사이의 간극이 분명해졌습니다. 한 번 되는 것과, 100번 중 99번 되는 것은 완전히 다른 공학 문제이고 후자는 골격으로 풉니다. 셋째, 그동안 컨트롤러 코드와 프레임워크 기본값, 도구 어댑터, 검증 스크립트에 흩어져 있던 하네스 로직을 이제 하나의 명시적·이식 가능한 자산으로 다루려는 움직임이 본격화됐습니다. “AI 컨트롤 플레인”이라는 표현이 등장한 것은, 하네스가 더는 부수적 배관이 아니라 시스템의 중심 통제층으로 인식되기 시작했다는 신호입니다.
저는 이 변화를 이렇게 봅니다. 모델은 빌려 쓰는 시대가 됐고, 차별화는 그 모델을 어떤 골격에 태우느냐로 이동했습니다. 비싼 파인튜닝에 돈을 쓰기 전에, 검증과 가드레일과 예산 관리 같은 하네스부터 제대로 짜는 편이 같은 비용으로 훨씬 큰 신뢰성을 돌려줍니다.
좋은 하네스를 만드는 설계 원칙
실무에서 통용되는 핵심 원칙은 의외로 단순하고 일관됩니다.
- 모델과 하네스를 분리한다. LLM은 의도 파악과 추론을 맡고, 계산이나 데이터베이스 쓰기 같은 정확성이 중요한 작업은 하네스 코드가 결정론적으로 처리합니다. LLM에게 직접 산수를 시키면 언젠가는 틀립니다. 이건 성능이 아니라 보증의 문제입니다.
- 도구는 최소로 노출한다. 도구가 많을수록 에이전트 성능은 오히려 나빠집니다. 한 에이전트에 8개를 넘는 도구가 한꺼번에 등록돼 있다면 설계를 의심해야 합니다. 단계마다 그 순간 필요한 도구만 보여주는 편이 낫습니다.
- 검증을 루프 안에 넣는다. 사후 평가가 아니라 매 단계 검증입니다. 테스트나 린터 같은 결정론적 검증을 1차로, LLM이 판단하는 의미적 검증을 보조로 씁니다. 후자는 지연을 늘리므로 남용하지 않습니다.
- 예산과 중단 조건을 명시한다. 단계 수, 시간, 토큰, 도구 호출 횟수에 상한을 두고, 초과하면 무한히 진행하는 대신 멈추고 사람에게 넘깁니다. 에이전트가 폭주하는 사고의 대부분이 이 한 가지 규칙으로 사라집니다.
마지막 원칙은 특히 1인 기업이나 작은 팀에 중요합니다. 결제, 삭제, 외부 발행처럼 되돌리기 어려운 행동에는 반드시 사람 승인 체크포인트를 둬야 합니다. 어제 제가 블로그 글을 발행하려 할 때 자동 승인이 막혔던 것도, 사실은 잘 설계된 하네스 가드레일이 의도대로 작동한 사례였습니다. 번거롭게 느껴지지만, 그 번거로움이 곧 안전자산입니다.
결국 무게중심은 골격으로 이동한다
최근에는 하네스 코드 자체를 에이전트가 점검하고 다듬는 ‘메타 하네스’ 같은 접근까지 등장했습니다. 사람이 손으로 골격을 짜던 단계에서, 골격이 골격을 개선하는 단계로 넘어가는 초입입니다. 방향이 어디로 가든 한 가지는 분명합니다. 2026년 AI 경쟁력의 핵심은 더 큰 모델을 손에 넣는 것이 아니라, 그 모델을 안정적으로 일하게 만드는 골격을 잘 설계하는 데 있습니다. 모델은 빌리되, 하네스는 직접 잘 짜는 쪽이 이깁니다. AI 에이전트를 진지하게 다루려는 사람이라면, 다음 투자의 1순위를 모델이 아니라 하네스에 두는 것이 맞습니다.
참고: Anthropic의 에이전트 하네스 개념, LangChain “The Anatomy of an Agent Harness”, awesome-harness-engineering(GitHub), arXiv의 하네스 엔지니어링 리뷰 논문, MLflow의 도구 사용 베스트 프랙티스 등을 참고했습니다. 수치는 작성 시점 기준이며, 빠르게 변하는 분야인 만큼 최신 자료를 함께 확인하시길 권합니다.
댓글