하네스 엔지니어링(Harness Engineering): AI 모델을 감싼 실행 환경을 설계하는 일
[핵심 요약]
하네스 엔지니어링이란? 하네스는 AI 모델을 감싼 실행 환경입니다. AI 모델에게 보여줄 정보를 고르고, 도구를 대신 실행하고, 결과가 맞는지 확인하는 층을 설계하는 것을 의미합니다.
모델을 그대로 두고 이 층만 바꿔도 결과가 달라집니다: 같은 모델의 점수가 환경에 따라 크게 벌어진 실험이 여럿 보고됐습니다.
그래서 검토의 질문이 바뀝니다: ‘어떤 AI 모델을 쓰는가’보다 ‘그 성능 수치가 어떤 환경에서 나왔는가’를 먼저 묻게 됩니다.
프롬프트를 다듬고 모델을 바꿔도 남는 문제
에이전트의 결과가 아쉬울 때 쓰는 방법은 둘 입니다. 프롬프트를 다시 쓰거나 더 좋은 모델로 갈아타는 것입니다. 그런데 실제 업무에서는 어느 쪽으로도 메워지지 않는 지점이 있었습니다.
프롬프트의 범위: 프롬프트는 모델에게 건네는 지시문입니다. 정작 결과를 좌우하는 것은 도구 설명, 참고자료, 앞선 대화까지 모델이 보는 정보 전체(컨텍스트)입니다.
긴 작업에서 흐트러지는 맥락: 며칠짜리 작업은 한 번에 담기지 않아 여러 번에 나눠 진행됩니다. 그 사이 맥락을 잃지 않고 진척을 이어 가는 일은 아직 미해결입니다.
모델 중심 확장의 한계: 모델이 유능해지면 실행 환경 의존도가 줄 것이라는 가설은 통제 실험에서 검증 실패했습니다.
하네스 엔지니어링이란 무엇인가
“하네스는 모델과 과업 사이에 놓인 실행 계층입니다.”(출처: 「Stop Comparing LLM Agents Without Disclosing the Harness」,2026.05)
쉽게 말해 모델에게 무엇을 보여줄지 고르고, 모델이 요청한 도구를 대신 실행하고, 나온 답이 맞는지 확인하고, 틀렸을 때 다시 시킬지·사람에게 넘길지·멈출지를 정하는 부분입니다.
마치 자동차의 주행 성능이 엔진 힘만으로 정해지지 않고 변속기와 브레이크가 그 힘을 노면에 어떻게 전하느냐로 갈리는 것처럼, 에이전트의 결과도 모델의 판단력만이 아니라 그 판단을 작업으로 옮기고 되돌리는 층에서 갈립니다.
하는 일은 세 가지로 나눠 보면 선명합니다.
하는 일 | 하네스가 하는 일 | 실제 구현물의 예 |
|---|---|---|
정보를 고른다(컨텍스트) | 이번 단계에서 볼 정보를 고르고 유지 | 기능 목록, 진행 기록, 컴팩션(compaction: 컨텍스트가 한계에 차오를 때, 지금까지의 내용을 요약해서 이전 내용을 대체) |
도구를 사용한다 | 바깥 세계에 손을 대는 통로 | 도구 정의, 브라우저를 대신 여는 자동화 등 |
확인하고 되돌린다 | 결과를 확인하고 틀렸을 때 되돌림 | 처음부터 끝까지 돌려 보는 점검, 변경 이력 되돌리기 |
비슷한 말들과 무엇이 다른가
비슷하게 들리는 말이 여럿입니다. 각각 무엇을 다루는 말인지만 잡아 두면 헷갈리지 않습니다.
용어 | 정의 |
|---|---|
프롬프트 엔지니어링 | 효과적인 프롬프트를 어떻게 쓸 것인가 |
컨텍스트 엔지니어링 | 최적의 토큰 집합을 선별·유지하는 전략들 |
스캐폴드 | 에이전트가 어떻게 행동할 것인가 정의하는 계층 |
하네스 | 그 행동을 실제로 돌리는 실행 루프 |
오케스트레이터 | 여러 에이전트를 조율하는 컨트롤러 |
자동차로 돌아가 보면 이렇습니다. 프롬프트는 운전자가 내리는 지시, 컨텍스트는 함께 보는 지도와 도로 정보, 하네스는 그 지시를 실제 주행으로 바꾸는 변속기와 브레이크, 오케스트레이션은 여러 대를 함께 굴리는 배차입니다.
가장 헷갈리는 둘은 이렇게 갈립니다. 하네스가 모델 하나를 실행 루프로 몰아가는 층이라면, 오케스트레이션은 에이전트를 단위로 관리하는 층입니다. 에이전트를 '모델 + 하네스'로 요약한 에이전트 용어집의 구분입니다.
다만 스캐폴드와 하네스는 아직 말이 통일되지 않았습니다. 평가하는 쪽은 스캐폴드를, 개발하는 쪽은 하네스를 쓰면서 상당 부분 같은 대상을 가리킵니다. 위 용어집처럼 둘을 다른 층으로 나누기도 합니다.
지금 하네스 엔지니어링이 논의되는 3가지 이유
1. 모델보다 실행 환경이 결과를 더 움직이는 '병목의 이동'
성능대가 비슷한 모델들 사이에서는 어떤 모델을 고르느냐보다 어떤 환경에 태우느냐가 결과를 더 크게 움직인다는 주장이 나왔습니다. 앞의 논문이 정리한 바에 따르면 환경만 바꿨을 때 같은 모델의 점수가 45.9%에서 55.4%로 올랐습니다.
2. 점수만 봐서는 알 수 없는 '측정의 조건'
앞서 든 격차를 촘촘하게 확인한 실험도 있습니다. 같은 모델인데 실행 환경만 바꿨더니 정확도가 최대 28%p까지 벌어졌습니다. 몇 점인지만큼 어떤 환경에서 낸 점수인지가 중요한 이유입니다.
3. 코드를 짜는 일에서 환경을 만드는 일로, '역할의 이동'
OpenAI는 코딩 에이전트만으로 약 5개월 동안 사내 시험용 제품을 만들었다고 밝혔습니다. 저장소는 약 100만 줄 규모인데 사람이 직접 타이핑한 코드는 0줄이었습니다. 눈여겨볼 것은 팀의 일이 바뀌었다는 점입니다. 코드를 쓰는 대신 환경을 설계하고 확인 장치를 만드는 쪽으로 무게가 옮겨 갔습니다.
TECH INSIGHT: 검토 단위가 '모델'에서 '모델과 환경’으로
기업이 AI 에이전트를 붙일 때 먼저 고르는 것은 대개 모델이었습니다. 하지만 하네스 엔지니어링 관점이 자리를 잡으면 검토 단위가 '모델'에서 '모델과 실행 환경의 조합'으로 바뀔 수 있습니다. 프롬프트 엔지니어링이 챗봇 시대의 기술이었다면, 실행 환경을 설계하는 일은 에이전트가 업무를 끝까지 수행하게 만드는 계층으로 자리 잡을 가능성이 있습니다.
다만 이 잠재력이 현실이 되려면 조건이 있습니다. 첫째, 공급사가 제시하는 성능 수치는 어떤 환경에서 낸 수치인지 확인해야 합니다. 둘째, AI가 내놓은 결과를 검사할 방법이 있어야 합니다. 셋째, 업무 규칙과 기준 문서가 AI가 읽을 수 있는 형태로 정리돼 있어야 합니다. 담당자 머릿속이나 구두 합의로만 존재하면 AI에게 넘길 수 없습니다.
즉, 하네스는 필요조건이지 충분조건은 아닙니다. 앞서 GAIA 통제 실험에서도 환경의 효과는 모델 계열에 따라 다르게 나타났고, 사전 예측 중 일부는 빗나갔습니다. 이는 한계라기보다 도입 조직이 병행해야 할 과제라고 보는 것이 정확합니다.
결국 앞으로 경쟁력은 어떤 모델을 골랐는가가 아니라, 그 모델을 어떤 환경에 태우고 무엇으로 검증하며 어디서 되돌릴 수 있게 해 두었는가에 달려 있습니다.