스킬캠퍼스
10강 · API 게이트웨이
강의

오늘 끝나면

API 게이트웨이

  • API 게이트웨이의 핵심 문제를 한 문장으로 설명한다
  • 오른쪽 실습에서 API이 어떻게 움직이는지 관찰한다
  • 다음 강의와 이어지는 한계를 말할 수 있다

실습 미션

통합 아키텍처 — 모델 앞단 관문 이 문장이 실제로 무슨 뜻인지 실습에서 한 번 손으로 확인한다.

성공 조건

  • 실습의 기본값을 먼저 관찰
  • 입력값이나 모드를 한 번 이상 바꿔 결과 비교
  • 왜 결과가 바뀌었는지 한 문장으로 설명

Enterprise LLM · 10

API
게이트웨이

모델 앞단에 세우는 관문임.
앱이 모델을 직접 부르지 않고, 게이트웨이가 인증·요청 제한·로깅·라우팅·캐싱을 한 곳에서 처리함.
여러 모델과 여러 앱을 한 통제 지점으로 묶는 게 핵심임 — 보안·비용·관측의 중심.

P.01Enterprise LLM · 10

앱이 모델을 직접 부르면 생기는 일

앱마다 OpenAI·Bedrock·사내 오픈소스 모델을 제 손으로 직접 부르게 두면 금방 엉킴.

앱마다 API 키를 박아 둠 — 키가 코드·로그에 흩어짐.
모델을 바꾸려면 앱을 전부 고쳐야 함.
누가 얼마를 썼는지 한눈에 안 보임. 폭주하는 앱 하나가 전체 한도를 태움.

그래서 모델 앞에 API 게이트웨이를 한 겹 끼움.
앱은 모델이 아니라 게이트웨이 한 곳만 부름. 키·라우팅·한도·로그가 전부 그 안으로 모임.
앱은 “무슨 모델인지” 몰라도 됨 — 게이트웨이가 뒤에서 정함.

N개 앱 × M개 모델 직결 vs 관문 한 겹
직결(엉킴) vs 관문 한 겹(정리)
✕ 앱이 모델을 직접 부름
사내 챗봇문서 검색코드 도우미
N×M
OpenAIBedrock사내 OSS

키 흩어짐 · 모델 교체에 앱 전부 수정 · 비용 안 보임

✓ 관문 한 곳으로 모음
사내 챗봇문서 검색코드 도우미
게이트
웨이
OpenAIBedrock사내 OSS

앱은 입구 하나만 앎 · 키·라우팅·로그가 한 곳

P.02Enterprise LLM · 10

관문 안에서 벌어지는 다섯 단계

게이트웨이는 단순 중계기가 아님. 요청 하나가 정해진 단계를 순서대로 통과함.

인증은 누가 부르는지 확인함 — API 키·SSO 토큰으로 앱·사용자를 못 박음.
요청 제한은 분당·일당 호출 수를 제한함 — 한 앱이 한도를 다 태우지 못하게 막음.

라우팅은 이 요청을 어느 모델로 보낼지 정함.
캐싱은 같은 질문이면 모델 호출 없이 저장된 답을 돌려줌 — 돈·지연을 아낌.
로깅은 누가·언제·무엇을·토큰 얼마 썼는지 전부 남김.

요청 하나가 인증 → 제한 → 라우팅 → 모델 → 로깅을 지남
요청 하나가 지나는 다섯 단계
AUTH인증키·토큰으로 누구냐 확인
RATE요청 제한분당·일당 호출 한도
ROUTE라우팅어느 모델로 보낼지
CACHE캐싱같은 질문이면 저장된 답
LOG로깅토큰·비용·내역 기록

모델 호출은 라우팅 다음 · 앞뒤로 관문이 감쌈

P.03Enterprise LLM · 10

인증 · 제한 · 로깅 — 통제의 세 축

관문이 한 곳에 모여 있어서 통제가 한 곳에서 끝남. 핵심 셋만 보면 됨.

인증으로 키 없는 호출은 입구에서 떨굼. 앱마다 키를 흩지 않고 게이트웨이가 한 곳에서 발급·회수함.
요청 제한(rate limit)으로 폭주·오작동 앱을 가둠 — 분당 N회, 토큰 일당 한도를 앱별로 다르게 잠.

로깅으로 모든 호출이 기록됨 — 프롬프트·응답·토큰 수·지연·비용.
이 로그가 비용 정산의 근거이자 감사 추적이고, 어떤 프롬프트가 새는지 보는 관측 창임.
모델을 직결했으면 이걸 앱마다 따로 박아야 했을 일을, 관문 한 곳이 대신함.

누구냐 · 얼마까지냐 · 무엇을 했냐
통제의 세 축 — 한 곳에서 끝남
인증누구냐
API 키 · SSO 토큰
키 없으면 입구컷
발급·회수 한 곳
요청 제한얼마까지냐
분당 N회 · 토큰 일당
앱별로 다르게 잠
폭주 앱 가둠
로깅무엇을 했냐
프롬프트·응답·토큰
비용 정산 근거
감사·관측 창
직결이면 앱마다 따로 박을 일 · 관문이 대신함
P.04Enterprise LLM · 10

멀티 모델 라우팅

앱은 입구 하나만 알면 됨. 그 뒤로 어느 모델을 쓸지는 게이트웨이가 규칙으로 정함.

요약·분류처럼 가벼운 일은 싸고 빠른 모델로, 추론이 깊은 일은 큰 모델로 보냄.
민감 데이터가 섞인 요청은 사내 오픈소스 모델(폐쇄망)로만 보냄 — 외부 API로 안 나감.
한 모델이 죽으면 다른 모델로 자동 전환(폴백)함.

모델 교체가 앱 수정이 아니라 게이트웨이 설정 변경으로 끝남.
GPT를 Claude로, 외부 API를 사내 모델로 바꿔도 앱은 코드 한 줄 안 고침.
벤더 잠김(lock-in)을 푸는 자리가 정확히 여기임.

같은 입구 · 뒤에선 요청마다 다른 모델로
같은 입구 · 규칙대로 다른 모델로
게이트웨이 입구 (앱은 여기만 앎)
↓ 라우팅 규칙
가벼운 일요약·분류싸고 빠른 모델Haiku · 소형
깊은 추론분석·코딩큰 모델Opus · 대형
민감 데이터고객·기밀사내 OSS폐쇄망 · 외부無
모델 장애응답 없음폴백 전환다른 모델 자동

모델 교체 = 앱 수정 아니라 설정 변경

P.05Enterprise LLM · 10

직접 흘려보기

오른쪽에서 직접 요청을 흘려 보셈.
어느 앱이 어떤 요청을 보내는지 정하면 인증 → 제한 → 라우팅 → 모델 → 로깅 순으로 흐름.

호출 수를 올리면 어느 순간 RATE 단계에서 막힘 — 모델까지 가지도 않음.
같은 요청을 또 보내면 CACHE가 맞아 모델 호출 없이 즉시 답이 옴. 비용 0.

민감 요청은 ROUTE가 사내 모델로 돌림 — 외부 API로 안 나감.
통과든 차단이든 캐시든, 마지막 LOG에 토큰·비용이 남는 게 핵심임.

Q. API 게이트웨이가 한 곳에서 주는 것은? (모델 학습 · 인증·제한·로깅·라우팅 통제 · GPU 증설 · 데이터 라벨링)정답은 인증·제한·로깅·라우팅을 한 곳에서 처리하는 통제 지점임.
게이트웨이는 앱과 모델 사이의 관문임 — 누가 부르는지 인증하고, 분당·일당 호출을 제한하고, 어느 모델로 보낼지 라우팅하고, 캐시로 중복을 막고, 모든 호출을 로깅함.
그래서 보안(키·인증)·비용(제한·캐싱·로깅)·관측(로깅)이 한 곳으로 모임. 모델 교체도 앱이 아니라 게이트웨이 설정으로 끝남.
모델을 학습시키거나 GPU를 늘리는 건 게이트웨이의 일이 아님.
앱·요청을 정하면 관문 다섯 단계를 통과한다
게이트웨이 요청 파이프 · 직접 흘려보기
요청 보내는 앱
요청 종류
분당 호출 수20 / 한도 60
앱 → 게이트웨이 → 모델
사내 챗봇문단 요약 · 20회/분
API 게이트웨이
AUTH인증 — 누구냐사내 챗봇 키 확인 · 통과
RATE요청 제한 — 한도 안인가20회 ≤ 한도 60회 · 통과
ROUTE라우팅 — 어느 모델로소형 모델 (Haiku급)
CACHE캐싱 — 본 적 있나처음 보는 요청 · 모델로
LOG로깅 — 기록 남김토큰·비용·내역 기록됨
소형 모델 (Haiku급)외부 API 호출
이 요청의 결과
상태모델 응답
호출 비용₩3

ROUTE가 소형 모델 (Haiku급)로 보냄. 토큰 800개 × 단가로 비용이 잡히고, 전부 LOG에 기록됨.

3줄 요약

  1. 1통합 아키텍처 — 모델 앞단 관문
  2. 2API 게이트웨이은 도입 방식 → RAG·연동 → SAP → 보안·거버넌스 → 운영 흐름 안의 한 칸이다.
  3. 3개념을 외우는 것보다 입력을 바꾸면 무엇이 달라지는지 보는 것이 우선이다.

완료 전 점검

복습 카드

API

통합 아키텍처 — 모델 앞단 관문

RAG

사내 문서를 검색해 답을 보강하는 방식

임베딩

의미를 숫자 벡터로 바꾼 표현