AI 에이전트 개발, 모델보다 '하네스 설계'가 성패를 가른다
목차(8)
한줄 요약
AI 에이전트 품질의 핵심은 모델이 아니라, 모델을 둘러싼 실행 인프라 설계에 있다.
AI 에이전트 외주 개발, 왜 모델 선택보다 설계가 중요한가
AI 에이전트 개발을 의뢰하는 고객사 대부분은 "어떤 모델을 쓰느냐"를 먼저 묻는다. GPT-4o인지, Claude인지, Gemini인지. 하지만 실제 서비스 품질을 결정하는 건 모델 선택이 아니라, 그 모델이 작동하는 방식을 설계하는 구조다.
업계에서는 이 구조를 **하네스(Harness)**라고 부른다. 모델 자체를 제외한 모든 것, 즉 시스템 프롬프트, 도구 설정, 실행 환경, 오케스트레이션 로직, 상태 관리까지가 여기에 해당한다. 날것의 모델은 텍스트를 받아 텍스트를 내보내는 함수에 불과하다. 하네스가 붙어야 비로소 실제 업무를 수행하는 에이전트가 된다.
에이전시 입장에서 이 개념을 명확히 이해해야 하는 이유는 단순하다. 같은 모델을 써도 하네스를 어떻게 짜느냐에 따라 결과물의 수준이 완전히 달라지기 때문이다. 클라이언트에게 차별화된 가치를 전달하고 싶다면, 하네스 설계 역량이 핵심 경쟁력이다.
하네스의 구성 요소, 에이전시가 실무에서 챙겨야 할 것들
실행 환경과 파일시스템
모델은 컨텍스트 윈도우 안에 있는 것만 안다. 그 바깥의 데이터는 누군가 직접 밀어 넣어주지 않으면 접근할 수 없다. 파일시스템은 이 문제를 해결하는 가장 기본적인 장치다.
에이전트에게 작업 공간을 주면 중간 결과물을 저장하고, 세션이 끊겨도 작업을 이어갈 수 있다. 여러 에이전트가 동시에 협업할 때도 공유 파일 구조가 기준점이 된다. 버전 관리 시스템을 여기에 연결하면 작업 이력 추적과 롤백도 가능해진다. 파일시스템은 단순한 저장소가 아니라 에이전트 협업의 기반 인프라다.
샌드박스와 코드 실행
에이전트가 코드를 직접 실행할 수 있어야 진짜 자율적으로 문제를 푼다. 미리 만들어둔 도구 목록에만 의존하는 에이전트는 예상 밖의 상황에 무력하다. 코드 실행 권한을 주면 에이전트가 즉석에서 필요한 로직을 만들고 검증할 수 있다.
단, 이 실행이 격리된 환경 안에서 일어나야 한다는 게 전제다. 클라이언트 서버에서 에이전트가 생성한 코드를 그냥 돌리는 건 보안 사고로 직결된다. 에이전시가 납품하는 에이전트 시스템에는 반드시 샌드박스 실행 환경이 포함되어야 한다. 격리된 실행, 허용 명령어 화이트리스트, 네트워크 제어는 협상 불가의 설계 원칙이다.
메모리와 컨텍스트 주입
모델의 지식에는 학습 시점이라는 한계가 있다. 클라이언트의 내부 정책, 최신 API 문서, 누적된 운영 노하우 같은 건 모델이 기본적으로 알 수 없다. 이 정보를 에이전트가 활용하게 만드는 유일한 방법은 컨텍스트에 주입하는 것이다.
잘 설계된 하네스는 에이전트가 스스로 배운 내용을 파일로 저장하고, 다음 세션 시작 시 그 내용을 자동으로 불러온다. 일종의 기관 기억(institutional memory)이다. 외부 지식이 필요한 경우엔 웹 검색이나 문서 조회 도구를 연결해 실시간으로 최신 정보를 끌어오게 한다.
에이전시 관점에서 이 설계는 클라이언트의 도메인 지식을 에이전트에 효과적으로 내재화하는 방법이기도 하다.
컨텍스트 관리와 장기 실행
에이전트가 긴 작업을 수행할수록 컨텍스트 윈도우가 채워지고, 성능이 저하된다. 이른바 컨텍스트 부패 현상이다. 하네스는 이 문제를 구조적으로 막아야 한다.
핵심 전략은 세 가지다. 첫째, 컨텍스트가 한계에 다다를 때 중요 내용을 압축·요약해 이어가는 로직. 둘째, 도구 실행 결과 중 덩치가 큰 출력을 파일로 오프로드하고 필요할 때만 불러오는 구조. 셋째, 시작 시점에 모든 도구를 한꺼번에 로드하는 대신 작업 흐름에 따라 필요한 도구만 순차적으로 활성화하는 점진적 도구 공개 방식.
장기 자율 실행 에이전트를 납품해야 하는 프로젝트라면 이 세 가지는 설계 단계에서 반드시 다뤄야 한다. 이것을 빠뜨리면 데모에서는 잘 돌아가던 에이전트가 실운영에서 금세 무너진다.
에이전시가 하네스 설계에서 저지르는 실수
가장 흔한 실수는 하네스를 '모델 감싸는 코드' 정도로 가볍게 취급하는 것이다. 실제로는 에이전트 시스템의 절반 이상이 하네스 안에 있다. 설계 초기에 실행 환경, 상태 관리, 컨텍스트 전략을 명확히 정의하지 않으면 후반에 전체를 뒤집는 상황이 온다.
두 번째 실수는 클라이언트가 요구한 모델에 모든 것을 맞추는 것이다. 모델은 교체된다. 오늘의 최신 모델이 6개월 뒤에도 최선일 보장이 없다. 하네스를 특정 모델에 강하게 결합하지 않고 교체 가능한 구조로 만들어두면, 모델 업그레이드 비용이 대폭 줄어든다. 유지보수 계약을 염두에 둔다면 더욱 중요한 포인트다.
세 번째 실수는 검증 루프를 생략하는 것이다. 에이전트가 작업을 완료했다고 해서 결과가 맞다는 보장은 없다. 테스트 실행, 로그 분석, 결과 비교 같은 자기 검증 메커니즘을 하네스 안에 내장해야 한다. 이것이 없으면 에이전트가 틀린 답을 자신 있게 내놓는 상황이 반복된다.
자주 묻는 질문
Q.AI 에이전트 개발을 외주로 맡길 때 하네스 설계도 포함해서 요청해야 하나요?
그렇다. 모델 연동만 요청하고 하네스 설계를 별도로 다루지 않으면, 실제 서비스에서 작동하지 않는 에이전트가 나올 가능성이 높다. 프로젝트 범위 정의 단계에서 실행 환경, 상태 관리, 도구 구성, 컨텍스트 전략까지 명시적으로 포함시켜야 한다. 하네스 설계가 곧 에이전트의 실제 동작 품질을 결정하기 때문이다.
Q.하네스를 잘 설계했는지 어떻게 판단하나요?
가장 직접적인 지표는 장기 실행 안정성이다. 단순한 데모가 아니라 복잡한 작업을 수십 단계 이상 수행할 때도 성능이 유지되는지 확인해야 한다. 컨텍스트 한계 도달 시 처리 방식, 에러 발생 시 복구 로직, 작업 중단 후 재개 가능 여부 등이 구체적인 체크포인트다. 이 항목들이 설계 문서에 명시되어 있고 테스트 케이스가 존재한다면 신뢰할 수 있는 하네스다.
Q.같은 모델인데 성능이 다르게 나오는 이유가 하네스 때문인가요?
상당수가 그렇다. 동일한 모델이라도 시스템 프롬프트 구성, 도구 설명의 품질, 컨텍스트 압축 전략, 실행 환경 설정에 따라 결과물 수준이 크게 갈린다. 모델 성능 비교 실험을 할 때 하네스 조건을 동일하게 맞추지 않으면 의미 있는 비교가 되지 않는다. 모델 교체보다 하네스 개선으로 더 큰 성능 향상을 얻는 경우도 많다.