Google Developers Blog가 2026년 5월 14일 Genkit Middleware를 발표했습니다. Genkit은 TypeScript, Go, Dart, Python을 지원하는 오픈소스 AI 애플리케이션 프레임워크입니다. 이번 발표의 핵심은 모델 호출 주변에 재시도, fallback, 도구 승인, 파일시스템 접근, skill 주입, 커스텀 검증을 composable hook으로 끼워 넣는 구조입니다.
에이전트 앱을 실제 서비스로 만들 때 가장 자주 터지는 문제는 모델 품질이 아닙니다. API 일시 장애, quota 초과, 잘못된 도구 호출, destructive action 승인, 로그 부재, 정책 위반 응답이 먼저 터집니다. Genkit Middleware는 이 부분을 프롬프트 문장으로 해결하지 말고, generate·model·tool 레이어에 명시적인 hook으로 넣으라는 방향을 제시합니다.
이 발표는 Google 생태계 사용자에게만 의미가 있는 내용이 아닙니다. LangChain, Vercel AI SDK, 자체 agent runtime을 쓰는 팀도 같은 구조를 참고할 수 있습니다. 생산 환경의 AI 앱은 “좋은 프롬프트”보다 “실패를 통제하는 middleware”가 먼저 필요합니다.
Genkit의 generate() 호출은 tool loop로 동작합니다. 모델이 출력을 만들고, 필요한 도구를 호출하고, 도구 결과가 다시 모델 호출로 들어가며, 완료될 때까지 이 과정이 반복됩니다. Middleware hook은 이 루프의 세 레이어에 붙습니다.
첫째, generate hook은 tool loop iteration마다 실행됩니다. 컨텍스트 주입, 메시지 재작성, 대화 단위 로직에 적합합니다. 둘째, model hook은 실제 모델 API 호출마다 실행됩니다. retry, fallback, caching, latency logging 같은 기능을 여기 넣습니다. 셋째, tool hook은 도구 실행마다 실행됩니다. human-in-the-loop 승인, sandboxing, 도구별 로그 기록이 여기에 해당합니다.
이 분리는 중요합니다. 많은 팀이 에이전트 장애를 하나의 “LLM 에러”로 묶어버립니다. 하지만 모델 API 429, 도구 권한 부족, 잘못된 파일 경로, 금칙어 출력, 사용자의 승인 대기는 서로 다른 레이어의 문제입니다. 레이어별 hook을 쓰면 장애 원인과 대응 방법이 분리됩니다.
이번 발표에서 Google은 retry, fallback, tool approval, skills, filesystem middleware를 소개했습니다.
Retry는 RESOURCE_EXHAUSTED, UNAVAILABLE 같은 transient error에 대해 exponential backoff와 jitter를 적용합니다. 중요한 점은 모델 호출만 재시도하고 주변 tool loop 전체를 다시 돌리지 않는다는 설명입니다. 전체 루프를 무작정 재시도하면 도구가 중복 실행될 수 있습니다. 결제, 삭제, 티켓 생성 같은 side effect가 있는 도구라면 치명적입니다.
Fallback은 primary model이 특정 에러를 냈을 때 대체 모델로 전환합니다. 운영팀 입장에서는 비용·품질·지연시간 정책을 모델별로 나눌 수 있습니다. 예를 들어 기본은 빠른 모델, quota 초과 시 다른 provider, 고난도 판단은 상위 모델로 넘기는 식입니다.
Tool approval은 허용 목록 밖 도구 호출을 interrupt로 멈추고 사람 승인을 받게 합니다. 이 기능은 특히 파일 삭제, 외부 전송, DB 수정, 결제 관련 액션에 필요합니다. “모델에게 조심하라고 말하기”는 통제가 아닙니다. 실제 실행 직전에 멈추는 구조가 통제입니다.
Skills middleware는 SKILL.md를 스캔해 시스템 프롬프트에 주입하거나 필요한 skill을 on-demand로 불러오게 합니다. Filesystem middleware는 root directory 밖으로 나가지 못하게 path safety를 enforced하면서 파일 읽기·쓰기 도구를 제공합니다. 둘 다 에이전트가 실무 context를 다룰 때 필요한 기능입니다.
Pre-built middleware만으로 충분하지 않은 경우가 많습니다. 예를 들어 고객지원 에이전트가 경쟁사 이름을 언급하면 안 되거나, 내부 가격표를 답변하면 안 되거나, 특정 고객군에는 법무 검토가 필요한 문구를 금지해야 할 수 있습니다. 이런 규칙은 프롬프트에 적어두는 것보다 응답 이후 검사 hook으로 강제하는 편이 낫습니다.
Google 예시는 forbidden term을 검사해 모델 응답을 거부하는 content filter입니다. 이 단순한 패턴만으로도 실무에서는 꽤 많은 사고를 줄일 수 있습니다. 다만 금칙어 필터만으로는 충분하지 않습니다. 실제 운영에서는 다음 항목을 함께 봐야 합니다.
Middleware는 모델을 똑똑하게 만드는 기능이 아니라 시스템을 덜 위험하게 만드는 기능입니다. 그래서 제품팀이 아니라 플랫폼팀, 보안팀, SRE가 함께 설계해야 합니다.
이미 AI 기능을 운영 중이라면 한 번에 모든 middleware를 붙이려고 하지 않는 편이 좋습니다. 먼저 장애와 리스크가 큰 지점부터 시작해야 합니다.
1단계는 model hook에 latency, error code, token usage, provider, model name을 기록하는 것입니다. 관측성이 없으면 retry와 fallback이 효과적인지도 판단할 수 없습니다. 2단계는 retry를 transient error에만 제한적으로 적용합니다. 3단계는 destructive tool에 approval을 붙입니다. 4단계는 fallback 정책을 도입합니다. 5단계는 커스텀 policy filter를 추가합니다.
이 순서를 지키면 변경 범위가 작고, 각 단계의 효과를 측정할 수 있습니다. 반대로 처음부터 복잡한 middleware stack을 만들면 디버깅이 어려워집니다. Genkit 발표에서도 middleware stack은 순서가 중요하다고 설명합니다. outer wrapper와 inner wrapper가 무엇인지 명확해야 합니다.
출처: Google Developers Blog “Announcing Genkit Middleware”, 2026년 5월 14일 공개.
