Category
에이전트 하니스는 LLM 에이전트를 실제로 굴리는 실행 골격이다. 권한 가드, 예산·모델 라우팅, 재시도·복구, 출력 검수, 도구 호출 루프를 한데 묶는다. 프롬프트만으로는 운영이 안 되고, 자율 실행에서 비용 폭주와 권한 사고를 막는 층이 여기서 결정된다.
에이전트가 몇 분이 아니라 몇 시간씩 도는 워크로드가 늘면서, 하니스가 'crash하면 처음부터'를 버리고 워크플로 엔진의 내구성 실행(durable execution)을 흡수하고 있다. 각 도구 호출·LLM 호출을 단계로 기록해 두고, 프로세스가 죽거나 배포로 재시작돼도 마지막 성공 지점부터 이어 가는 방식이다. Cloudflare Agents SDK와 Workflows, Temporal류가 이 패턴을 에이전트 루프에 직접 끌어왔다. 실무에서 바뀌는 건 두 가지다. 첫째, LLM 호출을 멱등하게 만들고 부수효과(결제·메일)를 한 번만 실행되도록 단계 경계를 잡아야 한다. 둘째, 재개 시점에 컨텍스트를 어디서 복원할지가 중단/재개의 진짜 난제다. 단계 로그만 있고 모델 컨텍스트 스냅샷이 없으면 재개해도 에이전트가 길을 잃는다. 관측성도 요청 단위 로그에서 단계별 타임라인으로 옮겨 가야 디버깅이 된다.
코드 실행 에이전트가 늘면서 격리는 컨테이너에서 gVisor·Firecracker 같은 마이크로VM으로 빠르게 이동했다. 문제는 격리 경계가 '프로세스'에 맞춰져 있는데 위협은 '데이터 흐름'을 탄다는 점이다. 샌드박스가 커널 호출을 완벽히 가둬도, 에이전트가 읽은 악성 웹페이지의 프롬프트 인젝션이 내부 도구 호출로 번지는 lethal trifecta(민감 데이터 접근·외부 통신·신뢰 불가 입력)는 VM 경계와 무관하게 성립한다. 실측 보고들은 네트워크 egress 화이트리스트와 도구별 권한 분리 없이 마이크로VM만 둔 구성에서 데이터 유출이 재현된다고 지적한다. 결국 하니스 레벨에서 도구 호출마다 능력(capability)을 명시적으로 부여하고, 신뢰 불가 콘텐츠를 읽은 뒤에는 외부 쓰기 권한을 자동 강등하는 흐름 기반 정책이 필요하다. CPU 격리는 필요조건일 뿐 충분조건이 아니다.
장기 실행 에이전트가 200K 윈도우를 다 채우면 비용·지연이 폭증하고 추론 품질이 무너진다. Anthropic이 공개한 컨텍스트 엔지니어링 가이드의 핵심은 단순 요약이 아니라 세 층으로 나누는 것이다. 첫째, 도구 호출 결과 같은 부피 큰 토큰은 외부 파일·DB에 적재하고 핸들만 컨텍스트에 남긴다. 둘째, 누적된 히스토리는 일정 구간마다 구조화된 메모(완료 작업·미해결 결정·다음 행동)로 치환한다. 셋째, 압축 시점을 모델이 스스로 판단하지 않게 하니스가 토큰 임계치로 강제한다. 핵심 트레이드오프는 압축이 곧 정보 손실이라는 점이다. 무엇을 버릴지 결정하는 메모 스키마 설계가 에이전트 성능을 좌우하며, 요약 LLM을 한 번 더 태우면 비용이 줄어드는 대신 환각이 메모리에 영구 각인되는 위험이 생긴다.