AI 제품을 운영할 때 중요한 질문은 더 이상 “가장 좋은 모델이 무엇인가”에 머물지 않습니다. 실제로는 “이 요청에는 어떤 모델이 가장 적합한가”가 더 중요합니다. 고객지원, 코드 생성, 리서치, 문서 요약처럼 제품 기능마다 요구하는 품질, 속도, 비용 기준이 다르기 때문입니다.
Merge Gateway는 이 문제를 LLM 라우팅과 거버넌스의 영역으로 다룹니다. 여러 모델을 하나의 관문 뒤에 두고, 요청의 성격과 운영 정책에 따라 적절한 모델로 보내는 중간 계층입니다.
제품 기준으로 모델을 고르는 라우터
Merge Gateway의 핵심은 모델 선택을 제품별 판단 기준에 맞게 조정할 수 있다는 점입니다. 여러 LLM을 하나의 API로 접근하게 하고, 요청을 비용·지연시간·품질 같은 기준에 따라 라우팅할 수 있습니다.1
특히 Build Your Own Router는 사용자가 “좋은 모델”의 기준을 직접 정의하도록 설계된 기능입니다. 벤치마크 가중치를 조정해 요청별로 어떤 모델을 선택할지 결정할 수 있습니다.1
이 접근이 중요한 이유는 범용 모델 순위표만으로는 실제 제품의 요구를 설명하기 어렵기 때문입니다. Merge Gateway는 HumanEval, MMLU, GPQA, GSM8K 같은 공개 벤치마크를 활용하거나 자체 벤치마크를 추가할 수 있게 합니다.1 따라서 코드 생성 제품, 리서치 제품, 고객지원 챗봇은 서로 다른 기준으로 모델을 고를 수 있습니다.
라우팅 지점은 곧 보안 지점이다
엔터프라이즈 환경에서 LLM 라우터는 단순한 성능 최적화 도구가 아닙니다. 모델 호출 직전에 프롬프트, 사용자 요청, 민감 데이터, 정책 판단이 모이는 통제 지점입니다.
Merge Gateway는 프롬프트 인젝션 공격이 모델에 도달하기 전에 이를 탐지하고 차단하는 Prompt Injection Protection 기능을 도입했습니다.2 이는 모델이 악의적인 지시를 그대로 따르기 전에 방어선을 두는 방식입니다.
또한 DLP 기능은 프롬프트 안에서 SSN, 신용카드 번호, API 키 같은 민감 데이터와 엔터티 유형을 스캔합니다.2 DLP 규칙은 상황에 따라 알림, 수정, 차단 동작으로 설정할 수 있습니다.2 즉 민감 정보가 포함된 요청을 단순히 기록하는 수준을 넘어, 실제 모델 호출 전에 처리 방식을 통제할 수 있습니다.
운영에 필요한 권한과 기록
AI 기능이 실험 단계를 지나 제품 운영으로 들어가면, “누가 무엇을 바꿨는가”도 중요한 문제가 됩니다. 모델 라우팅 규칙, 보안 정책, 접근 권한이 바뀌면 제품 동작과 리스크가 함께 달라지기 때문입니다.
Merge Gateway는 세분화된 역할을 만들고 사용자에게 할당할 수 있는 Role-Based Access Control을 추가했습니다.2 또한 플랫폼에서 수행된 모든 작업의 전체 로그를 볼 수 있는 Audit Trail도 제공합니다.2
이 기능들은 모델 성능 자체를 높이는 기능은 아니지만, 엔터프라이즈 운영에서는 필수에 가깝습니다. 라우팅과 보안 정책을 여러 팀이 함께 다룰수록 권한 관리와 감사 기록이 제품 신뢰성의 일부가 됩니다.
Merge 플랫폼 안에서의 의미
Merge는 서드파티 플랫폼의 데이터를 읽고 쓰기 위한 단일 unified API를 제공하는 플랫폼입니다.3 회계, ATS, HRIS, CRM, 파일 스토리지, 티켓팅, 지식 베이스, 채팅 카테고리를 지원하며, SFTP와 CSV 리포트 기반 업로드 워크플로도 다룹니다.3
이 플랫폼 안에서 Merge Gateway는 LLM 라우팅과 거버넌스를 담당하는 구성 요소로 설명됩니다.3 Merge Unified, Merge Agent Handler, Merge Gateway를 함께 제공하는 구조는 외부 업무 시스템 연결, 에이전트 실행, 모델 호출 통제를 하나의 운영 흐름으로 묶으려는 방향으로 볼 수 있습니다.3
개발자 관점에서도 Gateway는 모델 목록, 벤더 목록, 응답 생성 엔드포인트를 중심으로 구성됩니다. 응답에는 실제 요청을 처리한 vendor 정보도 포함됩니다.4 이는 라우팅 결과를 추적하고 운영 판단에 활용하기 위한 기본 단서가 됩니다.
배울 점: 모델 선택을 운영 정책으로 다뤄야 한다
Merge Gateway가 보여주는 방향은 분명합니다. 앞으로 LLM 인프라의 차별점은 “가장 강한 모델을 붙였다”가 아니라, 요청 단위로 어떤 모델을 선택하고 어떤 정책을 적용할 수 있느냐에 있습니다.
제품팀이 봐야 할 기준도 명확해집니다.
기능별로 어떤 벤치마크가 중요한가
비용과 지연시간을 어디까지 허용할 것인가
민감 데이터와 프롬프트 인젝션을 어디에서 차단할 것인가
라우팅 정책 변경 권한을 누구에게 줄 것인가
운영 중 발생한 변경과 호출 기록을 어떻게 추적할 것인가
Merge Gateway는 이 판단을 코드 곳곳에 흩어진 예외 처리로 두기보다, 라우터와 거버넌스 계층에서 관리하려는 시도입니다. LLM을 제품에 붙이는 단계를 넘어 실제 운영 인프라로 다루려는 팀이라면, 모델 선택을 성능 비교가 아니라 제품 정책의 문제로 봐야 합니다.
2Merge Changelog Week 2, May 2026
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.