AI 에이전트 개발, 모델보다 하네스 설계가 결과를 바꾼다

한줄 요약

AI 에이전트 품질은 모델이 아니라 모델을 감싸는 하네스 설계로 결정된다.

본문

AI 에이전트 시스템에서 '하네스(Harness)'란 모델을 제외한 모든 실행 인프라를 가리키며, 에이전시가 클라이언트에게 실질적인 가치를 전달하는 핵심 레이어다. 클라이언트 미팅에서 "어떤 모델 쓰세요?"라는 질문이 빠지지 않는다. GPT-4o냐, Claude냐, Gemini냐. 그런데 실제 프로젝트를 굴려보면 같은 모델로도 결과물 품질이 천차만별이다. 차이는 모델 바깥에서 난다.

하네스가 뭔데, 왜 중요한가

날것의 LLM은 텍스트를 받아 텍스트를 내뱉는 함수다. 상태를 기억하지 못하고, 코드를 실행하지 못하고, 외부 데이터에 접근하지 못한다. 이 한계를 보완하는 모든 코드와 설정, 실행 로직이 하네스다.

구체적으로는 다음을 포함한다.

• 시스템 프롬프트와 도구 명세
• 파일시스템, 샌드박스, 브라우저 등 번들 인프라
• 오케스트레이션 로직(서브에이전트 생성, 모델 라우팅)
• 컨텍스트 압축, 상태 지속, 검증 루프 같은 실행 훅

에이전시 입장에서 하네스는 납품물의 완성도를 직접 결정하는 설계 영역이다. 모델은 클라이언트가 바꿔달라고 요청할 수도 있다. 하지만 하네스는 에이전시의 기술력이 농축되는 부분이다.

파일시스템과 샌드박스: 에이전트의 작업 공간

에이전트가 실제로 "일"을 하려면 물리적인 작업 공간이 필요하다. 파일시스템은 그 기반이다. 에이전트가 중간 산출물을 저장하고, 세션이 끊겨도 작업을 이어가고, 여러 에이전트가 같은 데이터를 공유하려면 파일시스템이 있어야 한다. 여기에 버전 관리를 붙이면 에이전트가 실수를 롤백하고 실험을 브랜치로 나눌 수 있다.

코드를 실행하는 에이전트라면 샌드박스는 필수다. 클라이언트 서버에서 에이전트가 생성한 코드를 그대로 돌리는 건 보안 사고 예약이나 다름없다. 격리된 실행 환경을 하네스 레벨에서 구성하면, 안전성과 확장성을 동시에 잡을 수 있다. 필요할 때 환경을 생성하고, 작업이 끝나면 정리하는 방식으로 병렬 워크로드도 소화한다.

에이전시가 자주 놓치는 부분이 환경 기본 도구 구성이다. 언어 런타임, 패키지 관리자, 테스트 러너, 브라우저 같은 도구를 샌드박스에 미리 구성해두면 에이전트가 스스로 검증 루프를 만들 수 있다. 코드를 짜고, 테스트를 돌리고, 에러를 읽고, 고치는 사이클이 하네스 안에서 자동으로 돌아간다.

컨텍스트 부패: 장기 작업의 숨겨진 적

프로젝트 초반엔 잘 돌아가던 에이전트가 작업이 길어질수록 엉뚱한 소리를 하기 시작하는 현상을 겪어본 적 있을 거다. 컨텍스트 윈도우가 가득 찰수록 모델 추론 품질이 떨어지는 '컨텍스트 부패'다.

하네스는 이 문제를 세 가지 방식으로 다룬다.

첫째, 컨텍스트 압축(Compaction). 윈도우가 한계에 도달하기 전에 기존 내용을 요약하고 정리해 에이전트가 멈추지 않고 작업을 이어가게 한다.

둘째, 도구 출력 오프로딩. 거대한 도구 응답이 컨텍스트를 잡아먹지 않도록, 일정 토큰을 넘는 출력은 파일시스템에 저장하고 필요할 때만 불러오게 한다.

셋째, 점진적 도구 공개. 처음부터 수십 개의 도구를 컨텍스트에 쑤셔 넣지 않고, 현재 작업에 필요한 도구만 그때그때 로드하는 방식이다.

에이전시가 이 세 가지를 하네스 레벨에서 설계해두지 않으면, 클라이언트는 "처음엔 잘 됐는데 나중엔 망가진다"는 피드백을 받게 된다.

---

메모리와 지식 주입: 에이전트를 '학습'시키는 방법

모델 가중치를 직접 건드리지 않고 에이전트에게 새 지식을 주입하는 유일한 방법은 컨텍스트다. 하네스가 이 역할을 맡는다.

세션 간 기억은 메모리 파일로 구현한다. 에이전트가 작업하며 발견한 규칙이나 패턴을 특정 파일에 기록하고, 다음 세션 시작 시 하네스가 그 파일을 컨텍스트에 주입한다. 에이전트가 프로젝트를 거치며 점점 더 그 도메인에 익숙해지는 효과를 낸다.

최신 정보 접근은 외부 검색 도구로 해결한다. 모델의 학습 데이터 컷오프 이후 등장한 라이브러리 버전, API 변경 사항, 최신 문서는 웹 검색 또는 문서 조회 도구를 하네스에 통합해 에이전트가 항상 최신 정보를 참조하게 만든다.

에이전시가 하네스 설계에서 저지르는 실수

실전에서 가장 자주 보이는 패턴 세 가지를 정리하면 이렇다.

모델만 교체하고 하네스는 그대로 둔다. 새 모델이 나올 때마다 갈아끼우는데 성능이 기대만큼 안 오르는 이유다. 모델이 바뀌면 하네스도 함께 재검토해야 한다. 모델과 하네스는 함께 학습되고 최적화되는 쌍이기 때문이다.

검증 루프를 생략한다. 에이전트가 결과물을 스스로 테스트하고 수정하는 피드백 구조 없이 납품하면, 에러 수정 비용이 고스란히 클라이언트와 에이전시에게 돌아온다.

하네스를 일회성 설정으로 본다. 하네스는 프로젝트가 진행되며 계속 다듬어야 하는 살아있는 설계다. 초기 설정이 마지막 납품까지 최적이라는 보장은 없다. 에이전트 트레이스를 분석해 하네스 수준의 실패 패턴을 찾아내고, 반복적으로 개선하는 프로세스를 팀 안에 갖춰야 한다.