AI 에이전트 개발, 모델보다 하네스 설계가 성패를 가른다
목차(5)
한줄 요약
AI 에이전트의 실제 성능은 모델이 아니라, 모델을 감싸는 하네스 설계 수준에서 결정된다.
본문
AI 에이전트 개발에서 하네스(Harness)란 모델을 제외한 모든 실행 인프라, 즉 도구 구성·상태 관리·실행 환경·오케스트레이션 로직의 총체를 의미한다. 클라이언트에게 AI 에이전트를 납품하는 IT 개발 에이전시라면, 어떤 모델을 쓸지보다 어떤 하네스를 설계할지가 결과물의 품질을 좌우한다는 사실을 이미 체감하고 있을 것이다.
문제는 많은 팀이 하네스를 '부수적인 설정'으로 취급한다는 점이다. 실제로는 반대다. 모델은 컨텍스트 윈도우 안의 정보만 다루고, 상태를 스스로 유지하지 못하며, 실행 환경을 자력으로 구성하지 않는다. 이 모든 공백을 채우는 것이 하네스다.
하네스를 왜 따로 설계해야 하는가
날것의 모델(raw model)은 에이전트가 아니다. 입력을 받아 텍스트를 출력하는 함수에 가깝다. 에이전시가 클라이언트에게 "AI 에이전트를 개발해드립니다"라고 말할 때, 실제로 납품하는 것의 대부분은 하네스다.
모델이 본질적으로 할 수 없는 것들이 있다. 세션 간 상태 유지, 코드 실행, 외부 시스템 연동, 작업 환경 자동 구성이 그렇다. 하네스는 이 공백을 채우는 실질적인 엔지니어링 레이어다. 동일한 모델을 사용하더라도 하네스를 어떻게 구성하느냐에 따라 벤치마크 순위가 수십 단계씩 달라지는 사례는 이미 여러 차례 확인됐다. 모델 교체보다 하네스 최적화가 더 빠르고 저렴한 성능 개선 수단인 경우가 많다.
하네스의 핵심 구성 요소 네 가지
에이전시가 실제 프로젝트에서 설계해야 하는 하네스 구성 요소는 크게 네 가지로 나뉜다.
파일시스템과 상태 관리. 모델은 컨텍스트 밖의 데이터를 기억하지 못한다. 파일시스템 추상화를 하네스에 포함시키면, 에이전트는 세션을 넘나들며 작업을 이어갈 수 있고, 중간 산출물을 저장하며, 여러 서브에이전트가 공유 작업 공간 위에서 협업할 수 있다. 버전 관리 시스템을 연동하면 에이전트가 스스로 변경 이력을 추적하고, 오류 발생 시 이전 상태로 복구하는 것도 가능해진다.
실행 환경(샌드박스). 에이전트가 생성한 코드를 운영 환경에 직접 실행하는 것은 보안과 안정성 모두에서 위험하다. 격리된 샌드박스 환경을 하네스 레벨에서 구성하면, 코드 실행·의존성 설치·외부 API 호출을 안전하게 처리할 수 있다. 허용 명령어 화이트리스트와 네트워크 격리 정책도 하네스에서 강제한다. 작업 단위로 환경을 동적 생성하고 종료하는 구조는 비용 효율성과 확장성을 동시에 확보한다.
메모리와 컨텍스트 주입. 모델의 지식 컷오프와 컨텍스트 윈도우 한계는 프로젝트 실무에서 가장 자주 부딪히는 제약이다. 하네스는 에이전트 시작 시 관련 도메인 지식, 프로젝트 규칙, 이전 세션 요약을 컨텍스트에 자동으로 주입하는 구조를 가져야 한다. 최신 라이브러리 정보나 실시간 데이터가 필요한 경우엔 웹 검색 도구나 외부 문서 조회 도구를 하네스에 포함시킨다.
컨텍스트 부패 방지 로직. 작업이 길어질수록 컨텍스트 윈도우가 불필요한 정보로 채워지고, 모델 추론 품질이 점진적으로 저하된다. 이를 컨텍스트 부패(context rot)라 부른다. 하네스는 윈도우가 임계치에 도달하기 전에 기존 컨텍스트를 압축·요약하는 로직, 대용량 도구 출력을 파일로 오프로드하는 로직, 필요한 도구만 점진적으로 로드하는 구조를 포함해야 한다.
장기 자율 실행을 설계하는 방법
클라이언트가 요구하는 에이전트 작업은 대체로 단발성 응답이 아니라, 여러 단계에 걸친 복합 작업이다. 이런 장기 자율 실행 시나리오에서 하네스는 단순한 보조 도구가 아니라 핵심 아키텍처 결정이다.
실용적인 접근은 세 가지다. 첫째, 모델이 조기 종료를 시도할 때 이를 가로채 원래 목표를 새 컨텍스트와 함께 재주입하는 루프 패턴을 구현한다. 둘째, 계획 파일을 파일시스템에 유지하고 각 실행 단계마다 진척을 기록하게 한다. 셋째, 하네스 레벨에서 테스트 스위트를 자동 실행하고 실패 결과를 피드백으로 모델에 돌려주는 자기 검증 루프를 넣는다. 이 세 가지가 맞물리면 에이전트는 수백만 토큰 규모의 작업에서도 일관성을 유지한다.
자주 묻는 질문
Q.클라이언트가 "GPT-4o 써주세요"처럼 모델을 직접 지정하면 하네스 설계가 의미 없어지는 것 아닌가?
그렇지 않다. 동일한 모델이라도 하네스 구성에 따라 결과물 품질 차이가 크다. 클라이언트가 모델을 지정하더라도, 에이전시는 해당 모델의 특성과 한계를 파악한 뒤 이를 보완하는 하네스를 설계하면 된다. 오히려 모델이 고정된 상황에서 하네스 최적화가 유일한 성능 개선 레버가 된다. 클라이언트에게 모델과 하네스를 구분해서 설명하는 것이 기술 신뢰를 높이는 데도 도움이 된다.
Q.하네스 개발에 드는 공수를 어떻게 견적에 반영해야 하나?
하네스는 별도 개발 항목으로 명시하는 것이 맞다. 프롬프트 작성, 도구 연동, 실행 환경 구성, 컨텍스트 관리 로직, 검증 루프 구현 각각을 작업 단위로 분리하면 견적 산정이 명확해진다. 초기에는 공수 산정이 어렵지만, 두세 프로젝트를 경험하면 도메인별 하네스 구성의 패턴과 소요 시간이 축적된다. 이 자산이 에이전시의 기술 경쟁력이 된다.
Q.오픈소스 에이전트 프레임워크를 쓰면 하네스를 직접 설계할 필요가 없는 것 아닌가?
프레임워크는 하네스의 기본 뼈대를 제공하지만, 클라이언트별 요구사항에 맞는 커스터마이징은 여전히 에이전시의 몫이다. 도구 구성, 샌드박스 정책, 메모리 전략, 컨텍스트 압축 방식은 프레임워크가 기본값을 제시할 뿐 자동으로 최적화되지 않는다. 프레임워크를 쓰더라도 그 위에서 어떤 하네스 레이어를 쌓느냐가 납품 품질을 결정한다.
관련 아티클
관련 사례
이 글의 키워드와 맞닿은 실제 개발 사례를 함께 보세요.
