AI 에이전트 하네스 설계: 도구와 권한, 메모리를 운영하는 법

모델 바깥의 설계가 에이전트 결과를 바꾼다

하네스 엔지니어링은 에이전트가 움직이는 환경과 넘을 수 없는 경계, 실패를 붙잡는 복구 체계를 설계하는 분야다. 어떤 도구를 보여줄지, 무엇을 기억하게 할지, 어디까지 실행할 수 있게 할지는 모델의 응답 품질과 작업 결과를 직접 바꾼다.

2026년 3월 LangChain 팀은 모델을 바꾸지 않고 하네스 최적화만으로 Terminal Bench 2.0 순위를 30위에서 5위로 옮겼다. 모델 성능이 상향 평준화될수록 조직 간 차이는 도구 카탈로그, 메모리, 권한, 검증 루프 같은 하네스 구성에서 생긴다.

프롬프트가 지시이고 컨텍스트가 정보라면, 하네스는 그 바깥에서 컨텍스트 리셋, 인계 산출물, 단계별 게이트를 제공한다. 여러 컨텍스트 창에 걸친 작업이 가능한 이유도 여기에 있다. 다만 도구와 권한을 넓게 열수록 수행 범위뿐 아니라 사고 가능성도 커진다. 하네스는 성능을 위한 설계이면서 통제를 위한 설계다.

도구·메모리·실행 경계를 함께 설계한다

도구 카탈로그는 가능한 한 작게 유지하는 편이 낫다. 도구가 늘어나면 모델의 선택 정확도는 떨어지고, 도구 정의 자체가 컨텍스트를 차지한다. 작업 유형과 단계에 필요한 도구만 노출하고, 단계가 바뀌면 카탈로그를 교체하는 동적 도구 로딩이 전량 등록보다 정확도와 토큰 사용량 측면에서 앞서는 경우가 많다.

도구 설명도 구현 세부가 아니라 운영 인터페이스다. 모델은 설명을 바탕으로 도구 선택을 판단하므로, 사용 시점과 사용하면 안 되는 경우, 인자 의미를 분명히 적어야 한다. 설명 품질이 낮으면 모델 성능과 무관하게 잘못된 호출이 발생한다. 프롬프트의 일부로 보고 리뷰 대상에 포함할 필요가 있다.

메모리는 단기와 장기로 나뉜다. 단기 메모리에는 현재 세션의 작업 상태와 중간 산출물이 들어가고, 장기 메모리에는 사용자 선호, 과거 결정, 재사용 가능한 지식이 들어간다. 무엇을 장기 기억으로 남길지 자동 판단에만 맡기기는 어렵다. 저장 기준을 규칙으로 정하고, 사용자가 저장 내용을 확인하거나 삭제할 수 있어야 한다.

실행 환경은 파일시스템 범위, 네트워크 접근, 프로세스 실행 권한을 격리하는 샌드박스로 다룬다. 워크트리나 컨테이너 단위의 격리가 일반적이다. 이는 사고를 막는 장치일 뿐 아니라 병렬 실행의 조건이기도 하다. 격리되지 않은 상태로 병렬화하면 작업 간 상호 간섭이 발생한다.

권한은 도구 단위의 최소 권한 원칙으로 설계한다. 읽기와 쓰기 도구를 나누고, 파괴적 동작에는 별도 승인 경로를 둔다. 권한은 고정된 설정일 필요가 없다. 계획 단계에서는 읽기 전용으로 두고 실행 단계에서만 쓰기를 허용하는 방식으로 범위를 바꿀 수 있다.

⤢✕

검증과 복구가 없는 자동화는 닫지 않는다

자기 검증 루프는 도구 실행 결과를 확인하고, 실패하면 재시도하는 구조다. 테스트, 린트, 스키마처럼 검증 가능한 수단이 없다면 이 루프는 자기 확신을 반복하는 데 그칠 수 있다. 따라서 검증은 각 도구 실행 직후 배치하는 편이 효과적이며, 마지막에 몰아 검증하면 실패 원인을 분리하기 어렵다.

검증 수단이 없는 작업은 자동 완료 대상으로 두지 않고 사람 확인 게이트를 둔다. 실패 복구도 재시도 상한, 대안 전략, 사람 에스컬레이션 순으로 단계화한다. 에스컬레이션 조건은 재시도 N회 실패, 동일 오류 반복, 권한 밖 요청 감지처럼 수치와 상태로 정의한다. 사람이 이어받을 때는 시도 이력, 오류 메시지, 현재 상태를 표준 형식으로 전달해야 한다.

도구 호출 순서, 인자, 결과, 토큰 소비를 남기는 관측 로그도 빠질 수 없다. 로그가 없으면 하네스 개선은 추측에 머물고 장애 원인 분석도 할 수 없다. 쓰기와 삭제 동작은 특히 행위자, 시각, 대상을 필수로 기록해 감사 증적으로 보존한다. 작업당 토큰과 도구 호출 횟수의 상한은 폭주를 막는 장치이면서 재무 통제이기도 하며, 상한 도달 빈도는 하네스 개선 지표가 된다.

전량 등록보다 작업별 선별 노출이 맞는 이유

구분	도구 선별 노출	전량 등록
선택 정확도	높음	후보 증가로 저하
토큰 비용	낮음	정의가 컨텍스트 잠식
구현 부담	단계별 카탈로그 관리	없음
확장성	도구 증가에 강함	도구 수에 취약
적합 상황	도구 다수·복잡 작업	소수 도구

전량 등록은 처음에는 단순하다. 하지만 도구 수가 늘면 선택 오류가 증가하고 각 도구의 정의가 컨텍스트 예산을 잠식한다. 선별 노출은 작업 단계별 카탈로그를 관리해야 하지만 정확도와 비용 양쪽에서 이점이 있다. 도구가 십수 개를 넘어가는 시점부터는 선별 방식의 이득이 관리 부담을 명확히 상회한다.

영속 메모리는 사용자 선호와 과거 결정을 남겨 반복 설명을 줄이고 개인화 품질을 높인다. 반면 잘못 저장된 정보가 이후 판단을 계속 왜곡할 수 있고, 개인정보 보관 범위도 넓어진다. 저장 대상을 규칙으로 제한하고 사용자가 확인·삭제할 수 있게 하는 것이 이 위험을 관리 가능한 수준으로 낮추는 조건이다.

자체 검증은 반복 작업을 사람 개입 없이 끝낼 수 있어 처리량이 높다. 다만 안전성의 상한은 검증 수단의 품질로 결정된다. 테스트나 스키마 확인이 가능한 작업은 자체 검증으로 처리하고, 비가역적이거나 외부 영향이 있는 작업은 사람 승인으로 분리하는 것이 실무 기준이다.

운영 정책에 반영할 통제 기준

도구 노출은 기본적으로 열어두기보다, 필요가 입증된 도구만 추가하는 방식으로 시작한다. 도구 사용 빈도를 관측하고 오래 호출되지 않은 도구는 카탈로그에서 제거하는 정례 점검도 필요하다.

장기 메모리에는 사용자 선호, 재사용 가능한 사실, 반복적으로 지적된 규칙처럼 명시적으로 정의한 대상만 넣는다. 대화 원문 전체는 보관 대상이 아니다. 보관 기간과 삭제 요청 처리 절차는 개인정보 정책과 정합하게 규정한다.

도구별 권한 매트릭스를 만들고 승인 주체를 지정한다. 권한 확대에는 예외 승인 절차를 적용하며, 프로덕션 환경 접근은 별도 자격 증명과 별도 승인으로 분리한다. 개발 환경과 같은 하네스를 쓰지 않는다.

에이전트는 위임된 권한으로 동작하는 주체이므로 최소 권한, 직무 분리, 승인 게이트 같은 전통적 접근통제 원칙이 그대로 적용된다. 작업 단계에 따라 변하는 동적 스코프는 정적 역할 기반 통제보다 세밀하지만, 그만큼 정책 관리 부담도 크다.

하네스가 배포 명세가 되는 흐름

2026년에는 도구 목록, 권한, 메모리 범위 같은 하네스 구성이 형상관리 항목으로 정착하고, 에이전트 배포 시 명세로 첨부되는 관행이 확산될 전망이다. 작업 단계별 동적 도구 로딩은 프레임워크 기본 기능으로 편입되고, 전량 등록 방식은 안티패턴으로 인식될 가능성이 있다.

자기 검증 루프의 품질은 에이전트 비교의 핵심 지표로 부상하며, 검증 수단의 유무가 자동화할 수 있는 업무를 결정하게 된다. 규제 산업에서는 에이전트 활동 로그에 대한 감사 요건이 구체화되고, 관측 계층은 선택 사항이 아니라 준수 요건으로 전환될 전망이다.