저는 8년 차 풀스택 개발자로서 다양한 AI 서비스를 웹 애플리케이션에 통합해 온 경험이 있습니다. 처음 AI API를 도입할 때 가장 먼저 부딪힌 난관은 바로 인증 방식의 선택이었습니다. OAuth 2.0 JWT와 HMAC 서명, 두 방식의 차이를 모른 채 적용했다가 토큰 노출, 서명 위조, 재전송 공격 같은 보안 사고를 직접 겪기도 했죠. 이 글에서는 두 인증 방식의 작동 원리부터 실제 코드, 가격, 성능, 그리고 HolySheep AI라는 AI API 게이트웨이를 통한 실전 적용법까지 단계별로 설명합니다.
인증 방식이란 무엇인가요?
API를 호출할 때마다 "당신이 누구인지" 증명하는 절차가 필요합니다. 대표적인 두 방식이 OAuth 2.0 JWT와 HMAC 서명입니다. 쉽게 비유하면 다음과 같습니다.
- JWT — 영화관 티켓과 비슷합니다. 매번 입장할 때 티켓을 보여주면 되고, 티켓 안에 이름·좌석·만료 시간이 적혀 있습니다.
- HMAC — 은행 인감도장과 비슷합니다. 요청할 때마다 고유 도장을 찍어 보내야 하며, 도장이 일치해야만 요청이 통과됩니다.
OAuth 2.0 JWT 완전 기초
JWT(JSON Web Token)는 점(.)으로 구분된 세 부분으로 이루어진 문자열입니다.
- Header — 사용한 알고리즘 정보(예: HS256, RS256)
- Payload — 사용자 정보와 만료 시간 등 클레임
- Signature — Header와 Payload를 비밀키로 서명한 값
실제로 JWT는 다음과 같은 모양입니다.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
HMAC 서명 완전 기초
HMAC(Hash-based Message Authentication Code)는 메시지와 비밀키를 해시 함수로 결합한 서명입니다. 가장 흔한 변형은 SHA-256을 사용하는 HMAC-SHA256입니다.
HMAC 서명은 보통 다음 식으로 만듭니다.
signature = HMAC-SHA256(secret_key, "요청메서드\n요청경로\n본문\n타임스탬프")
- 장점 — 계산이 매우 빠르고 페이로드가 작아 모바일·IoT 환경에서도 유리합니다.
- 단점 — 비밀키가 클라이언트와 서버 양쪽에 모두 있어야 하므로 키 회전이 어렵습니다.
JWT vs HMAC 한눈에 비교 표
| 항목 | OAuth 2.0 JWT | HMAC 서명 |
|---|---|---|
| 키 구조 | 공개키/개인키 분리 가능(RS256) 또는 대칭키(HS256) | 대칭키만 지원 |
| 상태 저장 | 불필요 (Stateless) | 대부분 서버에서 검증 |
| 페이로드 크기 | 큼 (Header + Payload + Signature) | 매우 작음 (서명만) |
| 만료 처리 | exp 클레임 내장 | 별도 타임스탬프 검증 필요 |
| 계산 속도 | Base64 인코딩 + 서명 검증 | 해시 한 번으로 매우 빠름 |
| 적합한 사용처 | 다중 서비스 SSO, 사용자 컨텍스트 전달 | 서버 간 API 호출, 고성능 게이트웨이 |
| 대표 사례 | Google OAuth, Auth0, Keycloak | AWS Signature v4, Slack Signing Secret |
| 재생(replay) 공격 방어 | jti 클레임 + nonce 저장 | 타임스탬프 + nonce 동봉 |
실전 코드 1 — HolySheep AI에서 JWT 발급 후 호출
HolySheep AI는 단일 API 키로 GPT-4.1, Claude, Gemini, DeepSeek 등 모든 주요 모델을 호출할 수 있는 게이트웨이입니다. 내부적으로 OAuth 2.0 호환 JWT 토큰을 발급받아 사용합니다.
"""