인증 기초
인증(Authentication)과 인가(Authorization)는 모든 서비스의 접근 통제를 담당하는 핵심 개념입니다. “이 사람이 누구인가?”(인증)와 “이 사람이 무엇을 할 수 있는가?”(인가)를 구분하는 것부터 시작합니다. LLM API 키 관리, 모델 서빙 엔드포인트 보호, 멀티테넌트 AI 서비스 구축 — 모두 인증/인가의 올바른 설계가 전제됩니다.학습 목표
- 인증(Authentication)과 인가(Authorization)의 차이를 명확히 구분한다
- JWT의 구조와 검증 흐름을 이해하고 보안 주의사항을 설명할 수 있다
- OAuth 2.0의 주요 Grant 흐름을 이해하고 적합한 상황을 판단한다
- RBAC 기반의 권한 설계를 ML 팀 조직에 적용할 수 있다
왜 중요한가
AI/ML 서비스에서 인증과 인가는 비용, 보안, 데이터 프라이버시의 교차점입니다. API 키가 유출되면 수백만 원의 과금이 발생할 수 있고, 모델 엔드포인트가 노출되면 누구나 추론 API를 무단으로 사용할 수 있습니다. 학습 데이터에 민감한 정보가 포함되어 있다면, 접근 권한을 올바르게 통제하지 않으면 데이터 유출 사고로 이어집니다. 인증/인가는 개발자뿐 아니라 ML 엔지니어, 데이터 사이언티스트 모두가 이해해야 하는 기본입니다. 모델을 학습시키기 위해 데이터 레이크에 접근할 때, 실험 결과를 MLflow에 기록할 때, 프로덕션 모델을 배포할 때 — 적절한 인증과 최소 권한 원칙이 적용되어야 합니다.인증 vs 인가
| 구분 | 인증(Authentication) | 인가(Authorization) |
|---|---|---|
| 질문 | ”너는 누구인가?" | "너는 이것을 할 수 있는가?” |
| 확인 대상 | 신원(Identity) | 권한(Permission) |
| 실패 시 상태코드 | 401 Unauthorized | 403 Forbidden |
| 예시 | 로그인, API 키 검증, JWT 토큰 확인 | 관리자 페이지 접근, 모델 삭제 권한 |
| 순서 | 먼저 실행 | 인증 이후 실행 |
실무에서 혼동하기 쉬운 지점
인증 방식 상세 비교
| 방식 | 동작 원리 | 장점 | 단점 | 적합 상황 |
|---|---|---|---|---|
| API Key | 고정 문자열을 헤더에 전송 | 구현 간단, 서버 간 통신 적합 | 세분화된 권한 불가, 유출 시 교체 필요 | 서버 간 통신, 외부 API 호출 |
| JWT | 서명된 토큰에 사용자 정보 포함 | 무상태, 서버 부하 낮음, 세부 클레임 | 만료 전 강제 취소 어려움, 토큰 크기 큼 | 사용자 인증, 마이크로서비스 |
| OAuth 2.0 | 인가 서버를 통한 위임 인증 | 표준화, 제3자 연동, 세밀한 범위 제어 | 구현 복잡, 러닝 커브 높음 | 제3자 서비스 연동, SSO |
| mTLS | 클라이언트-서버 양방향 인증서 검증 | 매우 높은 보안, 양방향 인증 | 인증서 관리 복잡, 설정 어려움 | 제로 트러스트, 서비스 메시 |
| SAML | XML 기반 SSO 프로토콜 | 기업 SSO 표준, 세밀한 속성 전달 | XML 복잡성, 현대적 개발에 부적합 | 엔터프라이즈 SSO (레거시) |
JWT 상세
구조: Header.Payload.Signature
JWT(JSON Web Token)는 점(.)으로 구분된 세 부분으로 구성됩니다.
표준 클레임
| 클레임 | 이름 | 설명 |
|---|---|---|
iss | Issuer | 토큰 발급자 |
sub | Subject | 토큰 대상 (보통 사용자 ID) |
aud | Audience | 토큰 수신자 (API 서버 URL) |
exp | Expiration | 만료 시각 (필수) |
iat | Issued At | 발급 시각 |
nbf | Not Before | 이 시각 이전에는 유효하지 않음 |
jti | JWT ID | 토큰 고유 식별자 (재사용 방지) |
서명 알고리즘
| 알고리즘 | 유형 | 키 관리 | 사용 상황 |
|---|---|---|---|
HS256 | 대칭키 (HMAC) | 발급자와 검증자가 같은 비밀키 공유 | 단일 서비스, 간단한 구현 |
RS256 | 비대칭키 (RSA) | 개인키로 서명, 공개키로 검증 | 마이크로서비스, 분산 검증 |
검증 흐름
OAuth 2.0 흐름
OAuth 2.0은 제3자 애플리케이션이 사용자 리소스에 접근하도록 위임하는 프레임워크입니다.Authorization Code Grant (가장 안전하고 보편적)
기타 Grant 유형
| Grant 유형 | 적합 상황 | 비고 |
|---|---|---|
| Client Credentials | 서버 간 통신 (사용자 없이) | ML 파이프라인 서비스 계정 |
| Device Code | 입력 제한 디바이스 (TV, CLI) | CLI 도구 인증 (gh auth login) |
| Implicit | 보안 취약으로 폐기됨, PKCE 사용 권장 | |
| PKCE | Authorization Code + 코드 검증 | SPA, 모바일 앱의 표준 |
RBAC 설계
RBAC(Role-Based Access Control)는 역할에 권한을 매핑하여 접근을 통제하는 모델입니다.기본 역할 정의
| 역할 | 설명 | 권한 |
|---|---|---|
viewer | 읽기 전용 | 데이터 조회, 대시보드 열람 |
developer | 개발/실험 | 실험 생성, 모델 학습, 리소스 사용 |
admin | 관리자 | 사용자 관리, 설정 변경, 리소스 할당 |
service-account | 자동화 서비스 | 특정 API만 호출 (최소 권한) |
ML 팀 역할 매핑
| 역할 | 팀 직군 | 주요 권한 |
|---|---|---|
data-engineer | 데이터 엔지니어 | 데이터 파이프라인 CRUD, 데이터 레이크 읽기/쓰기 |
ml-engineer | ML 엔지니어 | 모델 학습/평가, 실험 관리, GPU 리소스 요청 |
mlops | MLOps 엔지니어 | 모델 배포/롤백, 인프라 관리, 모니터링 설정 |
pm | 프로덕트 매니저 | 대시보드 열람, 실험 결과 조회, 보고서 생성 |
권한 매트릭스 테이블
| 리소스/액션 | viewer | data-engineer | ml-engineer | mlops | admin |
|---|---|---|---|---|---|
| 실험 결과 조회 | O | O | O | O | O |
| 데이터셋 업로드 | X | O | X | X | O |
| 모델 학습 실행 | X | X | O | X | O |
| 모델 프로덕션 배포 | X | X | X | O | O |
| GPU 할당량 변경 | X | X | X | O | O |
| 사용자/역할 관리 | X | X | X | X | O |
| API 키 발급/폐기 | X | X | X | O | O |
멀티테넌시
멀티테넌시(Multi-tenancy)는 하나의 서비스가 여러 조직(테넌트)을 격리하여 서비스하는 아키텍처입니다.테넌트 격리 전략
| 전략 | 격리 수준 | 비용 | 복잡성 | 적합 상황 |
|---|---|---|---|---|
| DB 분리 | 가장 높음 | 높음 | 낮음 | 엔터프라이즈, 규제 산업 |
| 스키마 분리 | 높음 | 중간 | 중간 | 중규모 SaaS |
| 행 수준(Row-Level) | 보통 | 낮음 | 높음 | 대규모 SaaS, 비용 민감 |
AI 서비스에서의 멀티테넌시
AI 서비스에서 멀티테넌시는 비용 격리도 중요합니다.
테넌트별 토큰 사용량 추적, GPU 할당량 관리, Rate Limit 분리가 필요합니다.
한 테넌트의 과도한 사용이 다른 테넌트에 영향을 주면 안 됩니다 (“noisy neighbor” 문제).
AI/ML 인증 패턴
LLM API 키 관리
모델 서빙 엔드포인트 인증
학습 파이프라인 서비스 계정
HuggingFace 토큰
Access Token vs Refresh Token
Access Token vs Refresh Token
Access Token: 짧은 수명(15분1시간). API 접근에 사용. 만료되면 새로 발급받아야 합니다.
Refresh Token: 긴 수명(7일30일). Access Token 재발급에 사용. 서버에 안전하게 저장.
이 패턴을 사용하면 Access Token이 탈취되어도 피해 기간을 최소화할 수 있습니다.
Refresh Token이 탈취되면 즉시 무효화(revoke)해야 합니다.
API 키 vs JWT: 언제 무엇을 사용하는가
API 키 vs JWT: 언제 무엇을 사용하는가
API 키: 서버 간 통신, 외부 API 호출, 간단한 인증이 필요할 때. OpenAI, HuggingFace가 이 방식.
JWT: 사용자별 인증이 필요하고, 토큰에 사용자 정보(역할, 권한)를 포함해야 할 때.
함께 사용: API 키로 서비스를 식별하고, JWT로 해당 서비스 내의 사용자를 인증하는 이중 구조도 흔합니다.
JWT를 세션 대신 사용할 때의 주의점
JWT를 세션 대신 사용할 때의 주의점
JWT는 **무상태(Stateless)**이므로 서버가 세션을 저장하지 않아도 됩니다.
하지만 만료 전에 강제 로그아웃(토큰 취소)이 어렵다는 단점이 있습니다.
이를 보완하기 위해: (1) 짧은 만료 시간 + Refresh Token, (2) 블랙리스트(Redis),
(3) 토큰 버전 관리(JTI 추적) 등의 방법을 사용합니다.
Zero Trust 모델에서의 인증
Zero Trust 모델에서의 인증
전통적 모델: 네트워크 경계(VPN) 안에 있으면 신뢰 → 내부 위협에 취약.
Zero Trust: “절대 신뢰하지 말고, 항상 검증하라” → 모든 요청에 인증/인가 적용.
구현 요소: mTLS(서비스 간), JWT(사용자), 컨텍스트 기반 접근 제어(디바이스, 위치, 시간).
AI/ML 인프라에서도 학습 노드 간 통신, 모델 레지스트리 접근 등에 Zero Trust 원칙이 점점 적용되고 있습니다.
체크리스트
- 인증(Authentication)과 인가(Authorization)의 차이를 명확히 설명할 수 있다
- JWT의 세 구성요소(Header, Payload, Signature)와 주요 클레임을 이해한다
- HS256과 RS256의 차이와 적합한 사용 상황을 안다
- OAuth 2.0 Authorization Code Grant 흐름을 단계별로 설명할 수 있다
- Client Credentials Grant가 ML 파이프라인에서 어떻게 사용되는지 이해한다
- RBAC로 ML 팀의 역할별 권한을 설계할 수 있다
- API 키를 환경변수로 관리하고, 용도별로 분리해야 하는 이유를 안다
- 401과 403 상태코드의 차이를 실무 상황에 적용하여 설명할 수 있다

