Vercel AI Gateway 라우팅 규칙 공부 정리 | 모델도 방화벽이 필요하더라
Vercel AI Gateway에 모델 라우팅 규칙이 생겼다. 게이트웨이 레벨에서 모델 전환·차단을 제어하는 개념이 흥미로워서 정리해봤다.
Vercel 블로그에서 AI Gateway에 라우팅 규칙이 추가됐다는 공지를 봤다. 처음엔 그냥 작은 CLI 업데이트겠지 싶었는데, 읽어보니 “모델이 다운되거나 서비스가 종료됐을 때 코드 배포 없이 즉시 전환할 수 있다”는 부분이 눈에 들어왔다. 그 한 줄 때문에 조금 더 파봤다.
AI가 들어간 앱에서 모델을 바꾸는 게 어떤 일인지 생각해본 적이 없었는데, 이번에 공부하면서 그게 생각보다 번거로운 문제일 수 있겠다는 걸 처음으로 느꼈다.
1️⃣ 이게 뭐냐?
Vercel AI Gateway에 라우팅 규칙(routing rules)이 생겼다. 공식 표현으로는 “firewall-style rules”인데, 모델 접근을 제어하는 방화벽 역할을 한다.
두 종류가 있다.
Rewrite는 특정 모델로 들어오는 요청을 다른 모델로 투명하게 전달한다. 코드는 여전히 원래 모델을 요청하지만, 실제 응답은 다른 모델이 돌려준다. 모델에 장애가 생겼을 때 다른 걸로 트래픽을 넘기거나, 비싼 모델을 더 저렴한 걸로 교체할 때 쓸 수 있다.
Deny는 특정 모델로의 접근 자체를 막는다. 팀에서 검토가 안 됐거나 사용 승인이 안 된 모델을 차단하는 용도다. 막힌 요청에는 403이 반환된다.
두 규칙 모두 Vercel CLI로 관리하고, 팀의 AI Gateway 자격증명을 쓰는 모든 요청에 일괄 적용된다. 코드를 바꾸지 않아도 된다는 게 핵심이다.
2️⃣ 내가 든 생각
처음엔 “그냥 CLI 몇 개 더 생긴 거 아닌가”라고 가볍게 봤는데, 읽다 보니 이게 “모델을 어떻게 관리해야 하는가”라는 질문에 대한 하나의 입장에 가깝다는 걸 느꼈다.
보통 AI 모델 이름은 코드 안에 직접 박혀 있는 경우가 많다. anthropic/claude-opus-4.8 같은 문자열이 하드코딩돼 있으면, 모델을 바꾸는 건 곧 코드 수정 + 배포다. 라우팅 규칙은 그 결합을 느슨하게 만들려는 시도인 것 같다. 코드에는 모델명이 그대로 남아 있되, 실제로 어떤 모델이 응답할지는 게이트웨이 레이어에서 결정된다.
디자이너 입장에서 보면 이게 다른 식으로도 읽혔다. AI가 들어간 인터페이스를 만들 때, 어떤 모델이 뒤에 있느냐에 따라 응답의 톤이나 길이가 달라질 수 있다. 근데 그 선택이 코드 밖에서 이뤄질 수 있다는 건, 경험 레이어와 모델 선택 레이어가 어느 정도 분리된다는 의미이기도 하다. 분리가 좋은 건지는 잘 모르겠지만, 적어도 역할이 명확해지는 것 같았다.
👉🏻 “어떤 모델을 쓸지 결정하는 것”과 “그걸 코드에 직접 지정하는 것”은 사실 성격이 다른 일인데, 이 기능이 그 둘을 명시적으로 나눈다.
💡 여기서 드는 질문? Rewrite 규칙이 적용되면 요청한 모델과 실제 응답한 모델이 달라진다. 그 불일치를 어디서 추적할 수 있는지가 궁금해졌다. observability 측면에서 어떻게 처리하는지는 문서를 더 읽어봐야 알 것 같다.
⭐️ 마지막으로, 프론트엔드 공부하면서 든 생각
공부 끝에 남은 건 “추상화의 층위를 어디에 두느냐가 운영 방식을 바꾼다”는 한 줄짜리 인상이다. 모델을 코드 레이어에서 다루느냐, 인프라 레이어에서 다루느냐는 사소해 보이지만, 모델 교체 속도나 배포 비용에 직접 영향을 준다. 개발을 배우면서 “왜 이렇게 설계했을까”를 자꾸 물어보게 되는데, 이번엔 그 질문이 AI 인프라 쪽에서도 나왔다.