AI 에이전트 운영의 중심 이동: 평가·권한·복구 | Agent Evaluation, Control and Recovery

AI 에이전트 운영의 중심 이동: 평가·권한·복구 | Agent Evaluation, Control and Recovery

요약: 최근 72시간의 AI/LLM·AI Agent·개발자 도구 흐름은 에이전트를 신뢰 가능하게 운영하는 방법에 초점이 모였다. 평가를 CI와 배포 이후까지 연결하고, 권한·승인·관측·복구를 런타임 설계에 넣는 변화가 AWS, Codex, Claude Code, 샌드박스 프로젝트에서 반복 확인됐다.

핵심 답변

지금 개발팀이 우선할 일은 새 에이전트 기능을 곧바로 업무 권한에 연결하는 것이 아니라, 평가 기준·도구 권한·실패 복구를 함께 배포 단위로 만드는 것이다. 에이전트는 여러 도구와 세션을 조율하는 실행 계층이므로 정답률뿐 아니라 도구 선택, 권한 위반, 비용, 드리프트, 종료 처리를 측정해야 한다.

3일 결론: 경쟁력은 모델보다 평가 루프와 제어면에서 갈린다

이번 기간에 확인한 7개 이슈는 네 가지 흐름으로 묶인다. 첫째, 운영 품질은 지연시간과 오류율만으로 관리할 수 없다는 인식이 구체적인 평가 파이프라인으로 바뀌고 있다. 둘째, 코딩 에이전트는 대화형 도구를 넘어 병렬 조사·백그라운드 런타임·세션 제어를 갖춘 작업 환경으로 확장하고 있다. 셋째, 장기 실행을 위한 컨텍스트 압축과 자동 분류는 편의 기능이지만 메모리·MCP 호환성·관측 정보까지 함께 다뤄야 한다. 넷째, 샌드박스와 종료 처리는 예외가 아니라 에이전트 신뢰성의 기본 경계다.

1. 평가를 마지막 QA가 아닌 배포 시스템으로 만들기

확인된 사실

AWS는 10월 16일 AgentCore Evaluations 기반의 9단계 에이전트 평가 프레임워크를 공개했다. 품질 정의, 실험 비교, CI 회귀 검사, CD 품질 게이트, 카나리, 적대적 테스트, 드리프트 감시, 실시간 관측, 피드백 루프를 연속 과정으로 연결한다. AWS가 강조한 핵심은 에이전트가 틀려도 지연시간과 오류율은 정상처럼 보일 수 있는 ‘조용한 실패’다.

같은 기간 공개된 Trust in Depth는 범위 설정, 인지, 경계, 관측, 검증을 계층적으로 적용하는 운영 방식을 제안했다. 이는 에이전트 권한을 전부 허용하거나 전부 막는 이분법보다, 검증 가능한 행동에만 자율성을 부여하는 설계에 가깝다.

실무 시사점

에이전트 품질은 단일 LLM-as-a-judge 점수로 끝나지 않는다. 도구별 정답 계약, 에이전트별 golden set, 다중 에이전트 라우팅과 종합 결과를 분리해 봐야 한다. 검색·코드 수정·배포처럼 외부 상태를 바꾸는 업무는 정확도, 근거성, 권한 준수, 비용, 복구 가능성을 같은 승격 기준으로 묶는 편이 안전하다.

  • CI: 프롬프트·모델·도구 스키마 변경마다 고정 golden set과 실패 분류를 실행한다.
  • CD: 품질 하한, 권한 위반 0건, 비용 상한을 통과한 후보만 제한 트래픽으로 보낸다.
  • 운영: 낮은 평가 세션과 인간 수정 사례를 익명화해 새 회귀 사례로 승격한다.

2. 코딩 에이전트는 채팅창에서 작업 제어면으로 확장 중

확인된 사실

OpenAI는 10월 15일 Codex 0.163.0을 정식 릴리스했다. 릴리스 노트에는 응답 중 후속 지시로 작업을 즉시 조향하는 기능, 관리형 백그라운드 서버를 재시작하는 제어, 독립적인 읽기 전용 도구 호출을 병렬 실행하는 기능이 포함됐다. 이는 긴 코딩 작업에서 사용자가 결과만 기다리는 방식보다 진행 중인 계획과 런타임을 통제하는 사용성을 강화한다.

10월 17일의 Codex 0.164.0-alpha.3는 프리릴리스다. 같은 main 브랜치에는 app-server WebSocket의 협상형 압축과 메시지 크기 제한 변경이 확인된다. 정식 배포 기능으로 간주하면 안 되지만, 장기 세션과 도구 결과가 커지는 환경에서 전송 계층과 리소스 한계가 중요한 제품 표면이 되고 있음을 보여준다.

실무 시사점

도입 시 모델만 비교하지 말고 중단·재개·조향·백그라운드 프로세스·도구 병렬성의 동작을 함께 검증해야 한다. 읽기 전용 병렬화는 빠르게 허용할 수 있지만 파일 쓰기·배포·결제·권한 변경은 승인 단계와 명시적 멱등성 키를 분리하는 편이 낫다.

3. 컨텍스트 관리와 MCP 호환성은 에이전트 안정성의 일부다

확인된 사실

Claude Code 2.1.301은 자동 모드 분류 결과와 권한 모드를 OpenTelemetry 도구 결정 이벤트에 담는 변경을 포함했다. 이어 10월 16일 공개된 Claude Code 2.1.302는 클라이언트 측 자동 모드 분류 모델 선택, 유휴 컴팩션 설정, 128MB를 넘는 이미지 소스 거부, 특정 MCP 프로토콜 협상에서 도구가 보이지 않거나 호출이 실패하던 문제의 수정을 담았다.

컨텍스트 압축은 단순 토큰 절감 기능이 아니라 장기 작업의 문맥 보존과 중단 가능성에 연결되고, MCP는 도구 호출 경계이므로 호환성 실패가 곧 자동화 실패가 될 수 있다. 자동 모드·권한 모드·도구 차단 이유를 추적 가능한 이벤트로 남기고, 압축 전후에 필수 제약과 승인 기록, 작업 상태가 보존되는지 회귀 테스트해야 한다.

4. 샌드박스의 종료 처리까지 제품 계약으로 다루기

확인된 사실

Perplexity의 에이전트 코드 실행 샌드박스 프로젝트 SPACE는 플러그형 런타임 격리를 표방한다. 10월 17일 main 브랜치의 변경은 SIGTERM 수신 시 라이브 데이터 스트림을 즉시 취소하는 대신 drain하도록 조정했다. 이 항목은 릴리스되지 않은 main 브랜치 변경이며, 즉시 배포 가능한 기능으로 해석하면 안 된다.

그러나 에이전트가 코드 실행·브라우저·데이터베이스 같은 장기 도구를 호출할수록 정상 종료 시 어떤 작업을 취소하고 어떤 데이터를 비우며 어떤 상태를 재시도할지까지 서비스 계약에 포함된다는 점은 분명하다. 스트림·임시 자원·권한 토큰·후속 작업의 정리 순서를 검증해야 한다.

개발자 체크리스트

  • 평가: 대표 작업 30~100개부터 golden set을 만들고 도구 선택·최종 답변·권한 정책을 분리 채점한다.
  • 배포: 모델·프롬프트·도구 변경에 CI 회귀 검사와 제한 롤아웃을 연결한다.
  • 권한: 읽기, 쓰기, 외부 전송, 금전·배포 작업을 다른 승인·감사 정책으로 분리한다.
  • 관측: 자동 모드 판단, 차단 사유, 도구 실패, 비용, 재시도, 컴팩션 전후 상태를 추적한다.
  • 복구: 취소·타임아웃·SIGTERM·재시작 때 실행 중인 스트림과 임시 리소스가 정리되는지 테스트한다.

자주 묻는 질문

Q. 평가 점수가 높으면 자동 실행 권한을 줘도 되나?

A. 아니다. 오프라인 점수는 알려진 사례의 품질 신호일 뿐이다. 권한은 작업의 가역성·영향 범위·검토 가능성에 따라 별도로 설계하고 제한 트래픽과 승인 단계를 거쳐 확대해야 한다.

Q. 코딩 에이전트에서 가장 먼저 자동화할 일은?

A. 읽기 전용 조사, 테스트 실행, 문서 초안처럼 결과를 검토하기 쉬운 작업부터 시작한다. 파일 쓰기와 배포는 변경 범위 미리보기, 테스트 통과, 사람 승인, 멱등성 키를 묶어 단계적으로 확대한다.

Q. 이번 흐름에서 바로 적용할 최소 조치는?

A. 다음 배포 전 golden set 하나를 만들고, 도구 호출 로그에 권한 모드와 차단 이유를 남기며, 장기 작업의 취소·재시작 테스트를 추가하는 것이다. 특정 모델이나 벤더에 종속되지 않는 낮은 위험의 개선이다.

출처

더 깊게 읽기: 실전 가이드

이 리포트는 최근 흐름을 빠르게 파악하기 위한 요약입니다. 실제 프로젝트에 적용할 때는 아래의 기준 글과 함께 확인하면 더 안전합니다.

댓글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다