Genkit Middleware, 에이전트 통제권이 프롬프트 밖으로

AI 요약

• 무슨 일: Google이 Genkit에 generate() 호출과 도구 루프를 가로채는 Middleware를 추가했습니다.
  • TypeScript, Go, Dart에서 먼저 제공되고 Python 지원은 예정입니다.
  • 기본 미들웨어는 Retry, Fallback, ToolApproval, Skills, Filesystem입니다.
• 의미: 에이전트 안전장치가 프롬프트 문구가 아니라 런타임 훅과 운영 정책으로 이동합니다.
• 실무 영향: 모델 실패, 쿼터 초과, 파괴적 도구 호출, 파일 접근을 앱 코드에서 더 명시적으로 통제할 수 있습니다.
• 주의점: 미들웨어는 만능 보안 계층이 아니라 팀이 정책, 승인 UX, 관측성을 설계해야 하는 새 접점입니다.

Google for Developers가 2026년 5월 14일 Genkit Middleware를 발표했습니다. 표면적으로는 Genkit 프레임워크에 붙는 새 개발 기능입니다. 그러나 이 발표의 핵심은 더 넓습니다. AI 애플리케이션과 에이전트 앱을 운영할 때 반복해서 문제가 되는 재시도, 모델 폴백, 도구 승인, 파일 접근, 스킬 주입, 관측성을 프롬프트 바깥의 런타임 계층으로 끌어냈다는 점입니다.

지금까지 많은 AI 앱은 "조심해서 답하라", "파일을 삭제하기 전에 확인하라", "문제가 생기면 다시 시도하라" 같은 지시를 프롬프트에 넣고, 실패하면 애플리케이션 코드에서 임시 예외 처리를 덧붙이는 방식으로 성장했습니다. 데모 단계에서는 충분해 보입니다. 하지만 도구 호출이 들어가고, 모델이 여러 번 호출되고, 사용자의 실제 데이터와 파일시스템이 연결되면 이야기가 달라집니다. 실패는 단순한 오답이 아니라 잘못된 실행, 비용 폭증, 민감 정보 노출, 운영 중단으로 이어집니다.

Genkit Middleware는 이 지점을 정확히 겨냥합니다. Google의 발표문은 Genkit이 "프로덕션 준비가 된 AI 기능과 에이전트 앱"을 만들려면 강력한 모델과 좋은 프롬프트만으로는 부족하다고 설명합니다. 필요한 것은 실패한 요청의 재시도, 다른 모델로의 폴백, 파괴적 도구 호출 전 인간 승인, 그리고 각 계층의 관측성입니다. Genkit은 이를 generate() 호출과 도구 실행 루프를 가로채는 조합 가능한 훅으로 구현합니다.

Genkit은 왜 미들웨어를 꺼냈나

Genkit은 Google/Firebase 계열에서 시작한 오픈소스 AI 애플리케이션 프레임워크입니다. GitHub 저장소 설명에 따르면 JavaScript/TypeScript, Go, Python, Dart SDK를 제공하고, Google Firebase에서 프로덕션에 사용됩니다. 저장소에는 확인 시점 기준 약 6천 개의 스타와 739개 포크가 표시되어 있습니다. 단순한 샘플 프로젝트가 아니라 Google 개발자 생태계가 AI 앱의 서버 측 로직, 모델 연동, 도구 호출, 관측성을 묶기 위해 밀고 있는 프레임워크에 가깝습니다.

Genkit Middleware가 흥미로운 이유는 이 프레임워크가 모델 래퍼에서 앱 런타임으로 올라가고 있기 때문입니다. AI 앱 개발 초기에는 "어떤 모델을 부를 것인가"가 가장 큰 질문이었습니다. Gemini인지, OpenAI인지, Anthropic인지, 오픈소스 모델인지가 중심이었습니다. 그러나 에이전트 앱에서는 질문이 바뀝니다. 모델이 도구를 호출해도 되는가. 실패했을 때 어느 범위만 다시 시도할 것인가. 쿼터가 막히면 같은 요청을 더 싼 모델로 넘겨도 되는가. 파일을 쓸 때 루트 밖으로 나가지 못하게 할 수 있는가. 운영자가 나중에 왜 그런 행동이 나왔는지 볼 수 있는가.

이 질문들은 모델 선택보다 런타임 제어에 가깝습니다. 그래서 미들웨어라는 단어가 중요합니다. 미들웨어는 "모델에게 더 잘 말하는 법"이 아니라, 모델과 앱 사이에 규칙을 끼워 넣는 법입니다. Genkit 발표는 에이전트 앱의 병목이 모델 성능만이 아니라 실행 계층의 통제권이라는 점을 보여줍니다.

세 개의 훅, 도구 루프를 분해하다

Genkit 문서에 따르면 모든 generate() 호출은 도구 루프를 실행합니다. 모델이 출력을 만들고, 필요한 도구 호출이 실행되며, 도구 결과가 다시 모델에 들어가고, 모델이 완료될 때까지 이 과정이 반복됩니다. Middleware는 이 흐름의 세 계층에 붙습니다.

첫 번째는 WrapGenerate입니다. 도구 루프의 각 반복을 감쌉니다. 대화 전체를 보며 시스템 프롬프트를 주입하거나 메시지 누적을 관리하는 로직에 맞습니다. 두 번째는 WrapModel입니다. 실제 모델 API 호출을 감싸므로 재시도, 폴백, 캐싱, 콘텐츠 필터 같은 작업에 적합합니다. 세 번째는 WrapTool입니다. 각 도구 실행을 감싸며, 도구가 병렬로 실행될 수 있기 때문에 상태를 다룰 때 동시성까지 고려해야 합니다.

이 구분은 작지만 중요합니다. 예를 들어 모델 호출이 RESOURCE_EXHAUSTED로 실패했을 때 전체 도구 루프를 처음부터 다시 실행하면 이미 실행된 외부 작업이 중복될 수 있습니다. Genkit 문서는 Retry 미들웨어가 모델 API 호출만 재시도하고 주변 도구 루프는 재실행하지 않는다고 설명합니다. 재시도 범위를 잘못 잡으면 안정성을 높이려다 오히려 부작용을 키울 수 있다는 뜻입니다.

기본 미들웨어 다섯 가지

이번 발표에서 Google이 제시한 기본 미들웨어는 다섯 가지입니다. Retry, Fallback, ToolApproval, Skills, Filesystem입니다. 이름만 보면 익숙하지만, 에이전트 앱에서 이들이 함께 제공된다는 점이 핵심입니다.

Retry는 일시적 오류에 대한 재시도입니다. 문서에는 RESOURCE_EXHAUSTED, UNAVAILABLE, DEADLINE_EXCEEDED, ABORTED, INTERNAL 같은 상태가 언급됩니다. 일반 웹 서비스에서도 재시도는 흔합니다. 다만 AI 앱에서는 모델 호출 비용, 지연 시간, 도구 루프 부작용이 얽히기 때문에 어느 계층을 다시 실행하는지가 중요합니다. Genkit은 이를 모델 호출 계층에 명시적으로 붙입니다.

Fallback은 주 모델이 실패했을 때 다른 모델로 넘기는 기능입니다. 발표문 예시는 Gemini 호출이 리소스 고갈 상태로 실패할 때 Claude Sonnet으로 폴백하는 흐름을 보여줍니다. 이 부분은 Google 프레임워크가 Gemini만 고집하지 않는다는 신호이기도 합니다. Genkit 저장소 설명도 Google, OpenAI, Anthropic, Ollama 등 여러 모델 제공자를 통합할 수 있다고 밝힙니다. 모델 폴백이 프레임워크 기본 요소가 되면, 개발팀은 "최고 성능 모델 하나"보다 "실패 시에도 서비스가 이어지는 모델 포트폴리오"를 설계하게 됩니다.

ToolApproval은 에이전트 시대의 가장 직접적인 안전장치입니다. 허용 목록 밖 도구 호출을 인터럽트로 바꾸고, 사용자가 승인 플래그를 넣어 재개해야 합니다. 예를 들어 "임시 파일을 삭제하라"는 요청에서 삭제 도구가 호출되면 곧바로 실행하지 않고 승인 대기 상태로 만들 수 있습니다. 프롬프트에 "삭제 전에 물어봐"라고 쓰는 것보다 강한 제어입니다. 모델이 지시를 잘못 해석하더라도 런타임이 도구 실행을 멈출 수 있기 때문입니다.

Skills는 SKILL.md 파일을 스캔해 시스템 프롬프트에 주입하고, 필요한 스킬을 로드하는 도구를 노출합니다. 이는 에이전트 작업 지침을 코드 저장소나 조직 운영 방식과 연결하는 패턴입니다. 최근 코딩 에이전트 도구들이 저장소별 지침, 스킬, 플레이북을 다루기 시작한 흐름과 맞닿아 있습니다. 중요한 점은 스킬이 단순 문서가 아니라 모델 호출 흐름에 들어가는 미들웨어가 된다는 것입니다.

Filesystem은 파일 도구를 주입하면서 루트 디렉터리 밖으로 나가지 못하게 합니다. 문서에는 루트 경로를 벗어나는 .., 절대 경로, 심볼릭 링크를 막는 경로 안전성이 언급됩니다. 파일을 읽고 쓰는 에이전트가 늘어날수록 이 기능은 선택지가 아니라 기본 위생에 가까워집니다.

Developer UI가 중요한 이유

Google은 Middleware를 Developer UI에서도 확인할 수 있다고 설명합니다. 미들웨어를 등록하면 설정을 보고, 훅 계층을 따라 실행 흐름을 추적하고, 여러 조합을 테스트할 수 있다는 내용입니다. 이 부분은 단순 편의 기능이 아닙니다. 에이전트 앱에서 운영자가 가장 자주 마주치는 문제는 "왜 저 도구를 불렀는가"와 "어디에서 실패했는가"입니다.

로그만으로는 도구 루프를 이해하기 어렵습니다. 모델 호출, 도구 호출, 도구 결과, 재시도, 폴백, 승인 대기, 최종 응답이 모두 섞이기 때문입니다. 최근 관측성 업체들이 에이전트 타임라인과 LLM 추적을 강조하는 것도 같은 이유입니다. Genkit이 Developer UI에 미들웨어 실행을 드러낸다는 것은, 에이전트 앱 프레임워크가 로컬 개발 도구와 운영 디버깅 도구의 경계를 함께 다루려 한다는 신호입니다.

커뮤니티가 물은 것은 "막을 수 있나"였습니다

이 발표가 대형 모델 출시처럼 큰 커뮤니티 반응을 만든 것은 아닙니다. Hacker News나 GeekNews에서 큰 토론은 확인되지 않았습니다. 다만 Reddit r/Firebase에 공유된 글에서는 흥미로운 질문이 나왔습니다. 한 사용자는 Genkit Middleware가 도구 호출을 이름과 인자 기준으로 가로채고 거부할 수 있는지, 아니면 단순히 장식하거나 관측하는 수준인지 물었습니다.

이 질문은 에이전트 런타임에 대한 개발자의 실제 관심을 잘 보여줍니다. "훅이 있다"는 말만으로는 충분하지 않습니다. 중요한 것은 도구 실행을 멈출 수 있는지, 승인을 기다릴 수 있는지, 도구 인자를 검사할 수 있는지입니다. 답변에서는 ToolApproval이 도구 호출을 인터럽트로 바꾸고, 커스텀 미들웨어로 도구 파라미터를 검사할 수 있다고 설명했습니다. 즉 Genkit Middleware가 관측용 래퍼에 머무르지 않고 실행 경계에 들어가려 한다는 점이 커뮤니티의 관심사였습니다.

경쟁은 모델이 아니라 운영 계층에서 벌어진다

Genkit Middleware는 LangChain/LangGraph, Vercel AI SDK, Mastra, OpenAI Agents SDK, Anthropic의 MCP 생태계와 같은 흐름 위에 있습니다. 각 도구가 쓰는 용어는 다르지만 공통 질문은 비슷합니다. 에이전트가 여러 단계로 행동할 때 상태를 어떻게 보존할 것인가. 중간에 인간을 어떻게 끼워 넣을 것인가. 도구 실행을 어떻게 제한할 것인가. 모델을 어떻게 바꿔 끼울 것인가. 결과를 어떻게 추적하고 재현할 것인가.

Google의 차별점은 Firebase와 Google Cloud, Gemini, Android/웹 개발자 생태계와 연결될 수 있다는 점입니다. Genkit은 특정 모델 하나만 호출하는 라이브러리가 아니라, 앱 프레임워크와 배포 환경까지 묶으려는 성격이 강합니다. 그래서 Middleware는 작은 기능처럼 보이지만 전략적으로는 중요합니다. AI 앱을 "모델 호출 코드"에서 "운영 가능한 앱 런타임"으로 끌어올리는 접점이기 때문입니다.

반대로 한계도 분명합니다. 미들웨어가 있다고 해서 안전한 에이전트가 자동으로 만들어지지는 않습니다. Retry 정책을 잘못 잡으면 비용과 지연 시간이 늘어납니다. Fallback은 대체 모델의 응답 스타일, 정책, 컨텍스트 처리 차이를 드러냅니다. ToolApproval은 승인 피로를 만들 수 있습니다. Filesystem은 루트 밖 접근을 막더라도, 루트 안에서 잘못된 파일을 수정하는 문제까지 해결하지는 않습니다. 결국 팀은 정책을 설계하고, 위험한 도구를 분리하고, 승인 UX를 만들고, 관측 데이터를 읽을 수 있어야 합니다.

프롬프트 엔지니어링 이후의 숙제

이번 발표를 "Google이 Genkit에 미들웨어를 추가했다"로만 읽으면 작아 보입니다. 그러나 방향은 더 큽니다. 에이전트 앱의 품질이 프롬프트 작성 능력만으로 결정되던 단계가 지나고 있습니다. 운영 가능한 에이전트에는 실패 처리, 모델 라우팅, 권한 경계, 인간 승인, 관측성이 필요합니다. Genkit Middleware는 이 요소들을 프레임워크의 1급 구성요소로 올려놓습니다.

개발팀 입장에서 중요한 질문은 "Genkit을 써야 하는가"보다 "우리 에이전트 앱에도 이런 경계가 있는가"입니다. 모델 호출이 실패하면 어디까지 재시도합니까. 어떤 도구는 자동 실행되고 어떤 도구는 승인을 기다립니까. 폴백 모델은 같은 정책을 지킵니까. 파일 접근은 어느 루트에 묶여 있습니까. 운영자는 도구 루프를 나중에 재구성할 수 있습니까. 이 질문에 답하지 못하면, 모델이 좋아져도 프로덕션 에이전트는 여전히 불안정합니다.

Genkit Middleware는 그 답을 완성하지 않습니다. 대신 답을 놓을 자리를 만듭니다. 프롬프트 한 줄에 숨어 있던 운영 규칙을 훅, 미들웨어, UI, 문서화된 정책으로 꺼내는 일입니다. AI 앱이 실제 업무와 파일, 데이터베이스, 결제, 배포 파이프라인으로 들어갈수록 이런 작은 런타임 계층이 모델 발표만큼 중요해질 가능성이 큽니다.