스킬캠퍼스

오늘 끝나면

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

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

임베딩

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