요즘 AI 에이전트 만들어보신 분들은 다들 비슷한 경험을 하셨을 거예요. 데모에서는 그럴듯한데, 실제 업무에 붙이면 중간에 길을 잃거나, 같은 실수를 반복하거나, 컨텍스트가 꼬여서 이상한 답을 내놓죠. 그런데 흥미로운 건, 같은 모델을 써도 어떤 제품은 잘 되고 어떤 제품은 엉망이라는 거예요. 그 차이를 만드는 게 바로 '하네스(harness)'인데요. 이 개념을 깊이 있게 다룬 글이 나와서 정리해 드릴게요.
하네스가 뭐냐면요
하네스는 원래 말에게 채우는 마구, 그러니까 말의 힘을 마차로 전달해 주는 장비를 뜻해요. AI 세계에서는 언어 모델을 감싸고 있는 모든 소프트웨어 골격을 가리켜요. 시스템 프롬프트, 도구 목록과 그 설명, 대화 기록을 관리하는 방식, 에러가 났을 때 다시 시도하는 로직, 이 전부가 하네스예요. 모델이 엔진이라면 하네스는 차체와 변속기인 셈이죠. 엔진이 아무리 좋아도 변속기가 엉망이면 차가 제대로 안 나가잖아요. 실제로 코딩 벤치마크에서 같은 모델이 하네스에 따라 점수가 수십 퍼센트포인트씩 차이 나는 게 확인되면서, 업계의 관심이 모델 자체에서 하네스 설계로 옮겨가고 있어요.
좋은 하네스의 핵심 요소들
첫 번째는 도구 설계예요. 에이전트에게 도구를 많이 주면 좋을 것 같지만, 실제로는 반대인 경우가 많거든요. 비슷한 도구가 여러 개 있으면 모델이 뭘 쓸지 헷갈려서 성능이 떨어져요. 각 도구의 설명을 명확하게 쓰고, 겹치는 도구는 과감히 합치는 게 중요해요. 도구 설명은 사실상 모델에게 주는 API 문서라서, 사람 개발자에게 문서 잘 써주는 것과 똑같은 정성이 필요하고요.
두 번째이자 제일 중요한 건 컨텍스트 관리예요. 이게 뭐냐면, 모델이 한 번에 기억할 수 있는 정보량(컨텍스트 윈도)은 한정돼 있는데, 에이전트가 오래 일할수록 대화 기록과 도구 실행 결과가 쌓여서 이 한도를 넘어버리거든요. 그래서 오래된 내용을 요약해서 압축하거나(컴팩션), 큰 작업을 하위 에이전트에게 떼어주고 결과만 받아오는 기법을 써요. 하위 에이전트 방식이 좋은 이유는, 파일 100개를 뒤지는 지저분한 탐색 과정을 본체의 기억에 남기지 않고 '결론 세 줄'만 가져올 수 있기 때문이에요. 사람으로 치면 팀장이 모든 회의에 직접 들어가는 대신 팀원에게 조사를 시키고 보고만 받는 구조인 거죠.
세 번째는 검증 루프예요. 에이전트가 코드를 고쳤으면 테스트를 돌려서 확인하고, 실패하면 그 에러 메시지를 다시 입력으로 넣어서 스스로 고치게 하는 순환 구조인데요. 이 피드백 고리가 있느냐 없느냐가 장난감과 실전 도구를 가르는 결정적 차이예요. 모델의 환각을 막는 가장 현실적인 방법이 바로 이 '외부 검증'이거든요.
업계 흐름에서 보면요
Claude Code나 Codex 같은 코딩 에이전트들이 좋은 평가를 받는 이유도 결국 하네스 완성도예요. 파일 탐색, 권한 관리, 컨텍스트 압축 같은 지루한 부분을 잘 다듬은 거죠. LangGraph 같은 프레임워크로 직접 조립하는 길도 있는데, 자유도가 높은 대신 방금 말한 것들을 전부 스스로 구현해야 해요. 최근에는 MCP(Model Context Protocol)처럼 도구 연결을 표준화하려는 움직임도 있어서, 하네스의 부품들이 점점 규격화되는 흐름이고요.
한국 개발자에게 드리는 팁
사내에 에이전트를 도입하려는 분들께는 이 순서를 권해요. 도구는 다섯 개 이하로 시작하고, 각 도구 설명을 신입 개발자에게 설명하듯 자세히 쓰고, 검증 루프부터 만든 다음에 기능을 늘리세요. 그리고 실패 사례를 로그로 모아서 하네스를 고치는 게 프롬프트를 고치는 것보다 효과가 큰 경우가 많다는 것도 기억해 두시고요. 모델은 계속 좋아지니까, 여러분이 쌓는 하네스 노하우는 다음 모델에서도 그대로 자산이 돼요.
마무리
한 줄 정리하면, 에이전트의 성능은 모델 반, 하네스 반이라는 것. 그리고 모델은 살 수 있지만 하네스는 직접 만들어야 한다는 것이에요. 여러분이 에이전트를 만들면서 겪은 가장 큰 삽질은 뭐였나요? 컨텍스트 폭발? 도구 선택 실패? 경험담 나눠주시면 재밌을 것 같아요.
🔗 출처: Hacker News