Samsung SDS

지난 아티클 「토큰 팩토리의 생산성을 끌어올리는 인퍼런스 기술」에서는 토큰 팩토리 내부의 생산성을 끌어올리는 기술을 다뤘다면, 이번 아티클은 공장의 문 앞에서 벌어지는 일을 다룹니다.

공장 내부가 아무리 효율적이어도, 문 앞에서 결정해야 할 일들이 남아 있습니다. 어떤 주문을 얼마나 받을지, 받아서는 안 되는 주문을 어떻게 거를지, 받은 주문을 어느 생산 라인에 배정할지입니다. 실제 AI 서비스 운영에서 이 결정이 빠지면 어떤 문제가 발생할까요?

모델 밖에서 생기는 세 가지 문제

LLM 서빙 기술을 아무리 최적화해도, 실제 AI 서비스를 운영하다 보면 또 다른 문제들이 드러납니다. 그중 가장 먼저 마주하게 되는 것이 바로 사용량 통제입니다. 기존 서비스처럼 분당 요청 수로 한도를 두면 될 것 같지만, LLM 요청은 건마다 처리해야 하는 작업량이 크게 다르다는 점에서 문제가 생깁니다. 두 사용자에게 똑같이 분당 10회를 허용해도, 요청당 2,000 토큰을 쓰는 사용자와 200 토큰을 쓰는 사용자가 가져가는 GPU 자원은 전혀 다릅니다.^[1] 그렇다고 독점을 막으려 횟수를 조이면 이번에는 반대편이 손해를 봅니다. 짧은 요청을 쓰는 사용자는 GPU가 놀고 있어도 횟수 한도에 걸려 더 쓰지 못합니다. 건수를 기준으로 삼는 한, 느슨하면 독점을 못 막고 빡빡하면 자원을 놀리게 됩니다.

받아서는 안 되는 요청의 문제도 있습니다. 모델의 지시 체계를 우회하는 Prompt Injection은 OWASP가 선정한 LLM 애플리케이션 10대 보안 위협 중 1순위에 오를 만큼 보편적인 공격입니다.^[2] 모델은 안전 기준에 맞춰 학습되지만, 애초에 그 기준을 뚫도록 만들어진 공격을 모델 스스로 막는 데는 한계가 있습니다.

GPU를 증설한 뒤에도 문제는 남습니다. 서버 한 대에서 목표한 처리량이 나온다고 해서, 서버 수를 두 배로 늘렸을 때 전체 처리량도 두 배가 되는 것은 아닙니다. 요청을 차례대로 나누기만 하면 무거운 요청이 몰린 서버에는 대기열이 쌓이고 옆 서버는 놀게 되기 때문입니다. 실제로 다중 서버 환경에서, 요청 수를 균등하게 나누는 라운드로빈은 부하를 고려해 분배하는 방식과 비교해 응답 지연이 약 세 배 나빠진다는 연구 결과가 보고되어 있습니다.^[3]

이 문제들은 서로 달라 보이지만 공통점이 있습니다. 요청이 실제 모델에서 처리되기 전에 판단해야 한다는 점입니다.

[그림1] 요청 건수 기준의 통제와 단순 분배만으로 해결하기 어려운 LLM 추론의 세 가지 운영 문제 (출처: 삼성SDS)

01 사용량 불균형 : 같은 1건, 다른 토큰 02 위험 입력 : 검사 없이 모델로 전달 03 서버 쏠림 : 한쪽은 대기, 한쪽은 유휴

Inference Gateway는 무엇이 다른가

이 판단을 별도 계층 없이 애플리케이션이 각자 처리할 수도 있습니다. 하지만 모델과 애플리케이션이 늘어나면 같은 코드가 중복되고, 정책을 바꾸려면 모든 애플리케이션을 수정해야 합니다. 무엇보다 어느 GPU 서버가 여유 있는지는 애플리케이션에서 알 수 없는 정보입니다.

그래서 전통적인 웹 서비스에서 이 판단은 API Gateway가 담당해 왔습니다. API Gateway는 사용자를 인증하고 요청량을 제한하며, 통과한 요청을 여러 서버 가운데 적합한 곳으로 전달하는 라우팅까지 맡습니다. LLM 추론에서도 필요한 역할은 같지만, 무엇을 보고 판단하는지가 다릅니다. 요청 건수가 아니라 실제 사용한 토큰을 세어야 하고, 접근 정책과 함께 프롬프트의 안전성까지 검사해야 하며, 요청을 전달할 서버를 고를 때도 연결 수 대신 요청의 처리 특성, 기존 계산 결과의 재사용 가능성, 대기 중인 요청과 GPU 상태 등 많은 것을 고려해야 합니다.

Inference Gateway는 이 간극을 메우기 위해 기존 API Gateway의 역할을 AI 추론 환경에 맞게 확장한 계층으로, 두 가지 역할로 구성됩니다. “이 요청을 받아들일 것인가”를 결정하는 AI Gateway와, “받아들인 요청을 어디에서 처리할 것인가”를 결정하는 추론 스케줄링(Inference Scheduling)입니다. AI Gateway가 인증과 토큰 기반 사용량, 프롬프트 안전 정책을 담당하고, 추론 스케줄링이 요청의 특성과 서버 상태를 살펴 요청을 처리할 GPU 서버를 선택합니다.

[그림 2] 삼성SDS의 Inference Gateway 구조 (출처: 삼성SDS)

요청 →

Inference Gateway

• Al Gateway : 인증 · 사용량 · 안전 →
• Intelligent Routing : 요청 · 캐시 · 서버 상태 →

• GPU 서버 A
• GPU 서버 B
• GPU 서버 C 실시간 메트릭 → Intelligent Routing

사용량과 안전 정책을 통제하는 AI Gateway

① 사용량을 통제하는 토큰 기반 Rate Limit

건수가 기준이 될 수 없다면 무엇을 확인해야 할까요? AI 추론 비용은 GPU 연산량과 밀접하게 연관되어 있지만, 요청을 받는 시점에는 전체 비용을 확정할 수 없습니다. 연산량의 상당 부분이 답변을 생성하는 과정에서 발생하는데, 답변이 몇 토큰에서 끝날지는 생성이 끝나 봐야 알기 때문입니다.

대신 쓸 수 있는 지표가 토큰입니다. 처리한 토큰 수는 연산량에 비례하면서도 요청과 응답에서 정확히 셀 수 있어, GPU 사용량의 대리 지표가 됩니다. LLM 서빙의 공정성을 다룬 연구들이 서비스 비용을 입력/출력 토큰 수의 함수로 정의하는 것도 같은 이유입니다.^[1] 상용 API도 이 방식을 사용하고 있습니다. OpenAI는 요청 수(RPM) 한도와 분당 토큰 수 (TPM) 한도를 병행 적용하고^[4], Anthropic은 요청 수에 더해 입력 토큰(ITPM)과 출력 토큰(OTPM)을 분리해 각각 한도를 두고 서비스를 하고 있습니다.^[5]

이 방식이 성립하는 것은 LLM API가 응답에 실제 사용한 입력/출력 토큰 수를 담아 반환하기 때문입니다. AI Gateway는 요청 body를 수정해 사용량이 응답에 포함되게 하고, 응답 경로에서 토큰 수를 기록해 저장소에 적재합니다. 이후 사용자별 누적된 사용량을 조회해 한도 초과 여부를 판단하고 다음 요청을 제어합니다.

[그림3] 토큰 기반 Rate Limit 전체 흐름(출처: 삼성SDS)

• 입력 200 토큰 / 입력 2,000 토큰 →
• Al Gateway : 입력 토큰 계측, 누적 사용량 · 한도 확인
• 허용 →
• 모델 →
• 제한 : 불가
• 사용량 저장소(응답 후 출력 토큰 집계) →
• Al Gateway : 누적 사용량 · 한도 확인

토큰 단위 통제 효과는 연구에서 확인되었습니다. 요청 수가 아닌 토큰 단위로 스케줄링한 과부하 실험에서, 먼저 온 순서대로 처리하는 방식은 요청을 많이 보내는 사용자가 처리 용량을 사실상 독점한 반면, 토큰 기반 스케줄링은 사용자 간 누적 서비스 격차를 일정 범위 안으로 유지하는 결과를 보였습니다.^[1]

여기까지가 “얼마나 쓸 것인가” 에 대한 통제라면, Gateway가 확인해야 할 것이 하나 더 남아 있습니다. “이 요청을 받아도 되는가”입니다.

② 위험한 입력을 걸러내는 프롬프트 가드(Prompt Guard)

AI 모델은 공급자가 정한 정책과 안전 기준에 맞춰 응답을 내도록 설계되지만, 악의적이거나 의도를 벗어난 입력이 들어오면 모델이 이를 그대로 받아들여 기준에서 벗어난 응답을 만들 수 있습니다. 2025년 Microsoft 365 Copilot에서는 조작된 이메일 한 통에 숨겨진 지시문이 Copilot이 내부 문서의 민감 정보를 외부로 내보내게 만드는 취약점(EchoLeak)이 확인됐고^[6], OWASP는 프롬프트 인젝션이 이론적 위험을 넘어 기업 데이터 유출의 실질적 공격 수단이 되고 있다고 평가합니다.^[7] 입력을 미리 검사해 위반 요청을 걸러내는 프롬프트 가드가 필요한 이유입니다. 유해 콘텐츠 정책 위반은 Llama Guard 4 같은 안전 분류기가^[8], 프롬프트 인젝션과 탈옥 시도는 Llama Prompt Guard 2 같은 전용 분류기가 판정할 수 있습니다.^[9]

가드 모델을 애플리케이션이 직접 호출하면 가드 판정과 모델 응답 요청까지 왕복이 두 번이라 응답 지연과 부하가 커집니다. AI Gateway가 이 왕복을 대신하면 사용자는 한 번만 요청하고, AI Gateway가 안전으로 판정된 요청만 대상 모델로 이어주고 위반으로 판정되면 위반 카테고리의 차단 메시지를 반환합니다.

[그림4] 프롬프트 가드 요청 흐름(출처: 삼성SDS)

사용자 / 애플리케이션 : 한 번 호출 Al Gateway : Prompt Guard(입력 검사) 통과 → 대상 모델 위반 → 차단 메시지 → 차단 응답 → 사용자 / 애플리케이션

AI Gateway가 대신 맡는 일은 애플리케이션의 호출 횟수를 줄이는 데서 끝나지 않습니다. 가드 모델은 받을 수 있는 입력의 형태도, 분류 결과를 돌려주는 출력의 형태도 모델마다 다르기 때문에 요청을 모델에 맞게 가공하고 판정을 해석하는 과정이 필요합니다. 프롬프트 가드를 AI Gateway에 두면 가드 모델 교체가 애플리케이션 수정이 아니라 설정 변경의 일이 됩니다. 보안 조직은 대응 속도가 달라집니다. 앞서 본 것처럼 공격 수법은 계속 새로 보고되고 기존 필터가 우회되기도 하므로, 새로운 차단 기준을 AI 서비스에 얼마나 빠르게 적용할 수 있는지가 방어의 실질적 속도를 결정합니다.

여기까지가 AI Gateway의 역할입니다. 사용량을 세어 한도를 지키고, 입력을 검사해 위반 요청을 걸러내면, 이제 받아들인 요청이 남습니다. 이 요청을 여러 GPU 서버 가운데 어디로 보낼 것인지, 두 번째 판단인 추론 스케줄링이 다루는 문제입니다.

③ 요청과 서버 상태를 함께 보는 추론 스케줄링

AI Gateway를 통과한 요청은 실제로 토큰을 생성할 GPU 서버로 전달되어야 합니다. GPU 한 장이 처리할 수 있는 연산량은 정해져 있는데도, 같은 자원에서 나오는 결과는 요청을 어디로 보내는지에 따라 달라집니다. 지난 아티클에서 살펴본 것처럼, 요청마다 연산량이 다르고 서버마다 캐시와 대기열 상태가 다른 환경에서는 요청의 특성과 서버의 실시간 상태를 함께 보고 보낼 곳을 골라야 하기 때문입니다. 라우팅이 "요청을 나누는 일"에서 "요청과 자원을 맞추는 최적화 문제"로 바뀌는 것입니다.

이때 중요한 것은 어느 한 신호가 아니라 신호들의 균형입니다. 요청의 연산 특성, 캐시 보유 여부, 서버의 대기 상태는 단위도 성격도 달라 같은 저울에 올릴 수 있도록 정규화한 뒤 종합하는데, 한 가지 신호만 따르면 곧바로 쏠림이 생깁니다. 무거운 요청을 전부 고성능 서버로 몰면 그 서버부터 밀리고, 캐시만 보면 특정 서버에 트래픽이 집중됩니다. 모든 신호를 함께 보는 이유는 정확도를 높이기 위해서라기보다, 한쪽으로 기울지 않기 위해서입니다.

다만 모든 신호를 본다는 것이 모든 신호를 똑같은 무게로 본다는 뜻은 아닙니다. 어느 신호에 무게를 둘지는 서비스 수준 목표(SLO)가 정합니다. 첫 토큰까지의 시간(TTFT)이 중요한 대화형 서비스라면 캐시 적중과 대기열을 관리하는 신호에 무게를 더 주고, 토큰 생성 간격(TPOT)이 중요한 장문 생성 서비스라면 서버의 처리 여력에 무게가 실립니다. 추론 스케줄링이 한 번 설정하고 끝나는 기능이 아니라, 서비스 수준 목표에 맞춰 비중을 조절해 가는 운영의 영역인 이유입니다. 기업 입장에서 이 계층이 갖는 의미도 여기에 있습니다. GPU를 더 사는 대신, 이미 가진 GPU에서 더 많은 토큰을 꺼내는 접근입니다.

[그림5] 서비스 수준 목표에 따라 요청 특성, 캐시 적중, 대기열과 GPU 상태의 가중치를 조절해 처리 서버를 선택하는 추론 스케줄링(출처: 삼성SDS)

SLO별 가중치(요청 특성, 캐시 적중, 대기열·GPU상태를 측정하고 GPU 서버를 선택하는 이미지

이런 접근은 Kubernetes 생태계에서 공통 구조로 구체화 되고 있습니다. 지난 아티클에서 소개한 쿠버네티스 Gateway API Inference Extension의 EPP(Endpoint Picker)는 대기열과 캐시 상태 같은 실시간 지표로 서버를 고르는 구조를 정의합니다.^[10] 삼성SDS도 이 문제를 이른 시점에 정의하고 요청 특성과 서버 상태를 함께 고려하는 트래픽 제어 방식을 특허로 출원한 바 있으며, 현재는 이를 Intelligent Routing이라는 이름으로 표준 EPP 구조 위에 플러그인 형태로 얹어 SCP에서 운영하고 있습니다. 표준 기준만으로는 하드웨어 구성이 다른 환경의 특성이나 서비스별 목표까지 담기 어렵기 때문입니다.

[그림6] 표준 EPP 파이프라인과 맞춤형 플러그인 구조 (출처: 삼성SDS)

플러그인의 구조를 나타낸 이미지

여기까지 두 갈래의 판단을 살펴봤습니다. AI Gateway가 요청을 받아들일지 정하고, 추론 스케줄링이 받아들인 요청을 보낼 곳을 정합니다. 그런데 이 판단을 하나의 경로에 모아 두면, 각각의 합을 넘어서는 일이 생깁니다.

성능·비용 ·안정성을 함께 잡는 하나의 제어 계층

한 판단이 만든 데이터가 다른 판단의 재료가 되기 때문에 두 기능을 하나의 요청 경로에 둡니다.

성능에서는 AI Gateway의 계측이 추론 스케줄링의 눈이 됩니다. 서버 쏠림의 원인이 요청마다 다른 연산량이라면^[3], 분배를 잘하기 위해 요청의 무게를 알아야 합니다. 그 무게의 지표인 토큰 수를 AI Gateway가 한도 검사를 위해 이미 세고 있습니다. 사용량 통제를 위해 수집한 토큰 데이터가 별도의 계측 없이 요청의 무게를 가늠하는 자료로 스케줄링에 이어지는 것입니다.

비용에서는 GPU 증설 판단의 단서가 생깁니다. GPU를 늘렸는데 처리량이 기대만큼 늘지 않았다면 대표적으로 전체 서버가 실제로 포화 상태인 경우와 분배가 쏠려 일부만 바쁜 경우를 살펴볼 수 있습니다. AI Gateway가 세는 사용량과 추론 스케줄링이 보는 서버별 부하를 함께 놓고 보면 어느 쪽에 가까운지 가늠할 수 있습니다. 전체가 포화 상태라면 GPU 증설을 검토할 수 있지만, 쏠림이 원인이라면 서버를 늘려도 같은 문제가 반복됩니다. 이 구분 하나가 수천만 원짜리 GPU를 몇 장 더 살지 말지 가릅니다.

안정성은 트래픽이 몰리는 순간에 판가름 납니다. 이때 필요한 것은 요청을 얼마나 받을지 정하는 일과 받은 요청을 여유 있는 서버로 보내는 일입니다. 통제 없이 다 받으면 어떤 분배로도 과부하를 막을 수 없고, 분배가 서툴면 자원이 남는데도 지연이 생깁니다. 쿠버네티스 Gateway API Inference Extension이 스케줄러 앞단에 흐름 제어(Flow Control) 계층을 통합해 포화 시 요청을 보류했다가 여유 있는 서버로 내보내도록 설계한 것도 같은 결론입니다.^[11]

[그림7] 서버의 포화 상태에 따라 요청을 대기열에 보류하고, 가용 서버로 전달하는 Flow Control 구조 (출처: 삼성SDS)

트래픽이 급증하고 FLOW CONTROL에서 포화 시 요청 보류(우선순위, 공정성으로 순서결정)가 되면 서버 포하가 덜 된 서버를 선택하는 흐름을 표현한 이미지

Inference Gateway를 도입한다고 해서 기업이 반드시 이 계층을 직접 구축해야 하는 것은 아닙니다. 자체 GPU와 모델 서버를 세밀하게 통제해야 한다면 직접 구축할 수 있지만, 인프라 운영보다 AI 애플리케이션 개발에 집중하려면 완전 관리형 추론 서비스를 이용할 수 있습니다. Samsung Cloud Platform의 Simple AI Inference는 서버리스 모델 엔드포인트와 RPM, TPM 기반 트래픽 제어, Safety Guard 및 추론 스케줄링 기능을 제공합니다. 결국 기업이 먼저 확인할 것은 Gateway의 구축 여부보다 필요한 사용량 정책과 안전 기준, SLO를 어디까지 직접 통제할 것인지입니다.

Inference Gateway의 다음 판단

Inference Gateway가 다루는 판단의 범위는 계속 넓어지고 있습니다.

요청 하나가 여러 번의 모델 호출과 도구 실행으로 이어지는 에이전트 환경에서는, “요청 한 건” 단위의 통제와 집계가 맞지 않게 됩니다. 워크플로우 전체를 하나의 단위로 취급하는 스케줄링 연구가 이어지는 등^[12][13], 통제 단위부터 다시 정의되고 있습니다.

여러 모델을 함께 운영하는 환경에서는 “어느 서버로 보낼 것인가”에 앞서 “어떤 모델로 보낼 것인가”는 질문도 중요해집니다. 요청의 의미와 난이도, 비용, 보안 요구사항 등을 바탕으로 적합한 모델이나 처리 경로를 선택하는 Semantic Routing에 대한 연구도 이어지고 있습니다.^[14][15]

마치며

AI 추론의 경쟁력은 모델과 GPU만으로 결정되지 않습니다. 같은 모델, 같은 GPU를 갖추고도 요청을 어떻게 통제하고 어디로 보내느냐에 따라 처리량과 비용, 안정성이 달라지며, 그 판단을 담당하는 계층이 Inference Gateway입니다. 앞으로의 인퍼런스 경쟁은 무엇을 확보했는가에서, 확보한 것을 얼마나 잘 운영하는가로 옮겨 가고 있습니다.

※ AI 활용 고지
본문에 사용한 이미지는 자체 기획하였으며, 이미지 제작 및 원고 검토 과정에서 생성형 AI(Claude, ChatGPT)를 활용했습니다.

References

• Sheng et al., “Fairness in Serving Large Language Models,” 18th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’24), 2024.
• OWASP Foundation, “OWASP Top 10 for LLM Applications 2025,” 2025.
• Sun et al., “Llumnix: Dynamic Scheduling for Large Language Model Serving,” 18th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’24), 2024.
• OpenAI, “Rate Limits,” OpenAI API Documentation.
• Anthropic, “Rate Limits,” Claude API Documentation.
• National Institute of Standards and Technology, “CVE-2025-32711 Detail,” National Vulnerability Database, 2025.
• OWASP GenAI Security Project, “OWASP GenAI Exploit Round-up Report: Q1 2026,” 2026.
• Meta, “Llama Guard 4 12B Model Card,” Hugging Face.
• Meta, “Llama Prompt Guard 2 22M Model Card,” Hugging Face.
• Kubernetes SIG Network, “Gateway API Inference Extension,” Kubernetes.
• llm-d, “Endpoint Picker: Flow Control,” llm-d Router Documentation.
• Luo et al., “Agentix: An Efficient Serving Engine for LLM Agents as General Programs,” 23rd USENIX Symposium on Networked Systems Design and Implementation (NSDI ’26), 2026.
• Peng et al., “HexAGenT: Efficient Agentic LLM Serving via Workflow- and Heterogeneity-Aware Scheduling,” arXiv:2605.16637, 2026.
• Ong et al., “RouteLLM: Learning to Route LLMs with Preference Data,” International Conference on Learning Representations (ICLR 2025), 2025.
• vLLM Project, “vLLM Semantic Router,” GitHub.

FAQ