쉬운 설명
언어 모델 하나는 한 가지 일만 합니다. 글을 넣으면 글로 답하고, 그다음에는 잊어버립니다. 실제 일을 끝내려면 누군가가 모델을 반복해서 돌리고, 도구를 쥐여 주고, 무슨 일이 있었는지 기억하고, 언제 끝났는지 판단해야 합니다. 그 '누군가'가 바로 하네스입니다.
자주 뒤섞이는 두 개념을 갈라 두면 이해가 쉽습니다. AI 에이전트는 '행동' 쪽입니다. 모델이 계획을 세우고, 도구를 부르고, 결과를 읽고, 다음을 정하는 움직임이죠. 에이전트 하네스는 그 행동을 가능하게 하는 '코드' 쪽입니다. 실제로 사람이 짜고 유지보수하는 부분이 여기입니다. 모델은 추론을 대고, 하네스는 그 주위의 나머지 전부를 댑니다. 그림으로 보면 모델이 엔진이고, 하네스는 바퀴와 핸들, 브레이크, 무슨 일이 벌어지는지 알려 주는 계기판까지 포함한 자동차의 나머지 전부에 가깝습니다.
보통 하네스는 몇 가지 일을 맡습니다. 목표가 채워지거나 한계에 닿을 때까지 모델을 계속 돌리는 메인 루프를 굴립니다. MCP 같은 표준을 통해 모델을 도구에 이어, 검색하거나 파일을 읽거나 API를 부르게 합니다. 대화가 컨텍스트 창을 넘어 길어질 때 무엇을 프롬프트에 남기고 무엇을 요약하거나 버릴지 정하는 맥락 관리도 합니다. 권한도 강제해서, 모델이 적절한 관문 없이 파일을 지우거나 돈을 보내지 못하게 막습니다. 그리고 루프를 이어 가기 전에 테스트를 다시 돌리거나 출력을 점검하는 검증을 합니다.
이 골격에 따로 이름이 붙은 이유는, 에이전트의 성능을 가르는 게 모델만이 아니라 하네스이기 때문입니다. 같은 모델이라도 잘 만든 하네스 안에서는 신중하고 안정적으로 일하고, 허술한 하네스 안에서는 엉성하게 굴 수 있습니다. 그래서 팀들은 안에 어떤 모델을 넣을지와는 별개로, 하네스 자체를 설계하고 다듬는 대상으로 다루기 시작했습니다.
비유로 보면
솜씨 좋은 요리사를 주방에 들여보냈다고 생각해 보세요. 요리사는 모델이고, 재능은 이미 거기 다 있습니다. 그런데 실제로 저녁이 나오는지는 그를 둘러싼 주방, 곧 하네스에 달려 있습니다. 재료가 차려져 있는지, 다음에 뭘 만들지 적힌 주문표가 있는지, 접시가 나가기 전에 누가 점검하는지, 엉뚱한 칼을 집지 못하게 막는 규칙이 있는지 말이죠. 훌륭한 요리사도 엉망인 주방에서는 엉망을 내놓고, 같은 요리사가 잘 돌아가는 주방에서는 완성된 접시를 꾸준히 내보냅니다. 하네스는 요리사가 아니라 주방입니다.
어디에서 만나나
코딩 에이전트가 가장 또렷한 사례입니다. 저장소를 읽고 파일을 고치고 테스트를 돌리며 과제가 끝날 때까지 진행하는 도구들은 모델을 감싼 하네스이고, Claude Code와 GitHub Copilot의 에이전트 모드가 그 예입니다. 같은 형태가 자료를 가져와 주장을 검증하는 리서치·브라우징 에이전트, 실제 시스템에서 행동을 취하는 고객 지원·운영 에이전트, 그리고 프롬프트 한 번으로는 부족한 모든 장기 작업에 나타납니다. 여러 에이전트가 협력할 때는 오케스트레이션과, 에이전트가 운영 환경에서 돌아가고 누군가 그게 무엇을 왜 했는지 봐야 할 때는 모니터링과 관심사가 겹칩니다.
작은 예시
GitHub은 GitHub Copilot의 에이전트 하네스를 평가한 글을 냈습니다. 같은 코딩 과제 묶음을 두고 여러 모델로 바꿔 끼우며 성능을 잰 연구였죠. 핵심은 그 설계에 있습니다. 하네스는 고정해 두고 모델만 갈아 끼웠다는 것은, 하네스가 모델과 별개의 대상일 때만 말이 됩니다. 같은 골격, 즉 루프와 도구 접근, 맥락을 넣어 주는 방식이 각 모델을 돌렸고 결과는 모델마다 달랐습니다. 하네스와 모델을 따로 돌릴 수 있는 두 개의 다이얼로 다룬 셈입니다.
자주 하는 오해
한 줄 정리
모델은 에이전트가 얼마나 잘 '생각하는지'를 정하고, 하네스는 얼마나 잘 '작동하는지'를 정합니다. 모델을 둘러싼 루프, 도구, 맥락 처리, 권한, 점검이 하네스이고, 팀이 실제로 만들고 다듬는 부분입니다. 같은 모델이 좋은 하네스에서는 안정적이고 허술한 하네스에서는 불안정할 수 있으며, 안전과 신뢰라는 어려운 질문이 모델이 아니라 하네스에 살기 때문에, 하네스는 일급 설계 문제로 다뤄야 합니다.
자주 묻는 질문
에이전트는 '행동'입니다. 모델이 스스로 단계를 계획하고, 도구를 부르고, 결과를 읽고, 다음을 정하는 움직임이죠. 에이전트 하네스는 그 행동을 가능하게 하는 '소프트웨어'입니다. 모델을 계속 돌리는 루프, 도구로 잇는 배선, 맥락과 기억의 처리, 권한 관문, 그리고 결과마다의 검증이 여기 들어갑니다. 간단히 말하면 에이전트는 겉으로 보이는 것이고, 하네스는 사람이 만드는 것입니다. 모델은 루프 안에서 추론을 대고, 하네스는 그 루프와 주변 전부를 댑니다. 하네스를 고정한 채 모델을 갈아 끼울 수도, 모델을 고정한 채 하네스를 개선할 수도 있으며, 어느 쪽 변화든 에이전트의 성능을 바꿀 수 있습니다.
먼저 하네스를 살펴보세요. 더 센 모델이 골격에 박힌 문제를 고쳐 주지 못하는 경우가 많기 때문입니다. 과제가 길어질 때 맥락을 어떻게 관리하는지, 대화가 컨텍스트 창을 넘은 뒤 모델이 앞선 정보를 잃고 있지는 않은지 보세요. 도구가 깔끔하게 실패하고 모델이 회복할 수 있는 형태로 오류를 알리는지, 아니면 아무 응답 없이 침묵하는지 보세요. 루프를 이어 가기 전에 나쁜 결과를 잡아내는 검증 단계가 있는지, 위험한 행동이 권한 관문 뒤에 있는지도 보세요. 모델이 약해 보이는 실패의 상당수는 사실 하네스가 잘못된 맥락을 먹이거나, 도구 오류를 숨기거나, 점검 없이 행동하게 둔 결과입니다. 더 좋은 모델은 천장을 높일 수 있지만, 허술한 하네스는 어떤 모델에게도 천장을 낮춥니다.
하네스는 에이전트의 행동이 실제로 일어나는 곳이라, 위험이 모이는 자리이기도 합니다. 모델은 파일을 지우거나 결제를 보내자고 제안할 수 있지만, 그 제안을 실행할지 정하는 것은 하네스입니다. 그래서 되돌릴 수 없는 행동은 사람이 승인하는 단계가 있는 권한 관문 뒤에 둬야 합니다. 하네스는 에이전트가 어떤 도구에 닿을지 통제하므로, 지나치게 넓은 도구 접근은 실수 하나의 파급 범위를 키웁니다. 맥락도 통제하므로, 민감한 데이터를 프롬프트에 흘리거나 가져온 내용 안에 숨은 지시(프롬프트 인젝션의 사촌격)를 다음 단계로 실어 나를 수 있습니다. 또 루프가 사람 없이 얼마나 진행할 수 있는지도 통제하므로, 한계가 빠지면 에이전트가 길을 벗어난 뒤에도 한참 더 행동하게 둘 수 있습니다. 믿을 만한 모델을 고르는 것으로는 이 중 어느 것도 풀리지 않습니다. 이들은 골격 안의 선택이고, 처음부터 설계에 넣어야 합니다.